原始来源：DeepSeek · 研究原型
发现渠道：GitHub Trending
一个面向团队的编程 Agent 即使能持续工作，也可能让所有人不断看消息、补充背景、收拾失败。DeepSeek 开源的 dsh-superagent 从这个问题出发：它监听一个 GitHub 仓库，也可接入飞书，把获准的请求变成独立工单，在自己的会话和目录里执行，最后回到原讨论交付结果。README 明确说，这是供参考的研究原型，既非正式产品，也不完全等同于内部实现；文章描述的部分方向尚未实现。
它把业务任务和模型会话拆开保存。工单记录输入、分派和报告，执行会话负责工作；一个会话停下，并不自动表示任务已经交付。面板按“等回答、等审核、受阻、失败、排队”等条件呈现状态。后台命令或子任务尚在运行时，工单仍占用工作槽位；需要人介入时则释放槽位，让别的任务继续。人的消息还享有额外唤醒容量，避免所有执行位繁忙时连纠偏都进不去。
执行文档进一步区分输入投递重试、后台工作结束和中断恢复。未进入会话历史的输入会被保留，忙碌中的分派中断后带恢复说明重启。这样的细节让“少打扰人”落实到可观察状态，但不等于提供业务事务回滚。公开讨论中已有使用者报告 Node 24 下服务状态误判，以及 GitHub 通知迟到导致提及被漏读；他提供了修补分支和测试说明，本期未运行这些补丁。
可信度 65 · 重要性 78 · 新颖度 65
技术与主题
Agent 系统 · AI 编程 · 任务状态机 · 事件游标 · 中断恢复
mikel38487
在 Ubuntu 26.04 / WSL2、Node 24.22.2、dsh 0.2.1-rc.5 上的自述试用；补丁尚未由本期复跑。
忠实转述（非原句）：他安装原型后，发现服务实际在运行，状态命令却找不到进程。另一次问题更隐蔽：GitHub 较晚送来的提及落在读取窗口之外，线程游标继续前移，评论此后也不会再被读到。他报告了两次现场复现，并把线程自己的读取位置用于修复；公开了分支与回归测试结果。
编辑评读
值得借鉴的是把“暂时没说话”拆成不同原因。等待工具结果、等待新触发、需要人作决定，表面都可能安静，下一步却不同。若界面只显示运行中或已完成，用户只能反复追问；工单保存明确的等待对象，才有机会把这种追问变成按需接手。这里的收益首先是状态可解释，尚不能据此认定人工时间已经减少。
迟到通知的问题也说明，业务入口必须和模型能力分开检查。一个要求根本没进入执行会话，再聪明的模型也无法补救；重试时若游标已越过那条评论，反复运行仍会漏掉它。投递重试只能补送输入，不能撤销已写入仓库的错误结果。因此评估长任务系统时，可以在同一任务里加入迟到输入、中断和人工修订，观察是否漏接或重复执行，并记录恢复花费的人时。这是由公开缺陷推导出的测试建议，不是本期完成的压力测试。
核查依据
- 原始方法说明及本条所述比较边界；具体范围见research-audit。
- 原始方法说明及本条所述比较边界；具体范围见research-audit。
- 原始方法说明及本条所述比较边界；具体范围见research-audit。