我先说结论：Super-agent 是我想要的 Agent 工作流。它从第一性原理出发，从工程的角度思考 Agent 在更复杂的工作流中应该怎样工作。

DeepSeek Harness 团队发布的《Super-agent 设计探索：迈向更自主的 Agent 系统》，抓住了一个具体的问题：

• 让编码 Agent 同时处理几件事以后，人还得记住每个会话在做什么，把散落在群聊、Issue 和 PR 里的补充要求送到对应会话，再把结果带回来。
• 模型承担了写代码的工作，人继续承担任务分派、上下文搬运和进度追踪。任务越多，这份管理开销越显眼。

Super-agent 把这一部分也做进系统。

• Router 负责接收消息、判断是否需要行动、分配任务和对外回复。
• Worker 在各自的上下文和工作目录里执行具体任务。
• Router 的职责尽量保持轻量，耗时的编码、命令和测试交给 Worker，以便新消息到来时仍能继续接待。

更值得关注的是任务建立之后发生什么。同一个 Issue 后面又来一条评论，系统已经知道哪张工单订阅了它，程序可以把消息直接送给原来的执行会话。这条确定的关系省掉了一次重新判断“该找谁”的模型调用。文章把它归入 Fast Path，只有需要理解语义、判断新任务的事件才进入较昂贵的路径。

文章还有更多的设计细节：

• 确定性过滤先挡掉无关事件，模型再研判剩余候选。
• 上下文中的高频信息直接提供，长内容保留引用、按需召回。
• 计算、会话状态和执行环境逐步分离，让持续运行与跨设备访问成为可能。外部 Watchdog 则检查系统故障和任务进展，尝试处理长时间没有实质推进的会话。

文章最后给出了一个 GitHub 项目。我使用已配置的 DeepSeek-V4.1-Flash，完成了一次小范围的自动交付测试。公开原型只实现了文章的部分设计，下面记录的是本次实际跑通的流程。

任务很简单：在测试仓库的 README 里增加“自动交付验收”章节，创建草稿 PR；再通过同一个 Issue 追加要求，让它在原 PR 中补上一行复验标记。

整个工作的流程图如下：

追加评论可以沿订阅关系送到原 Worker，但机器人消息还可能独立进入评估。复用原工单，并不意味着这条事件完全不再经过模型研判。

下面是关键步骤的运行记录截图。

1. 从 GitHub Issue 发起任务

github-actions[bot] 发出带有 DSH-E2E-3 START 标记的评论，明确限定只修改 README、创建草稿 PR，并在原 Issue 回复结果。

2. Superagent 接单，记录授权与订阅关系

工单详情保留了触发消息、接单理由和允许修改的范围。它订阅了原 Issue，后续要求可以沿这条关系进入已有任务。图中工单处于“等待新触发”状态。

3. 在原 Issue 追加要求，接收两次交付回复

追加评论要求在同一 PR 中补上“复验标记：DSH-E2E-3-PASS”。Superagent 的两条回复分别报告草稿 PR 已创建，以及复验标记已提交。

4. 同一个 PR 留下两次提交

第 4 号 PR 中，第一次提交增加验收章节，第二次提交补充复验标记。管理记录也显示，全程是一张工单、一次派工，追问沿用了原来的执行会话。

5. 核对最终改动

文件差异中只有 README.md，共增加 6 行，包含初始要求的文字和后续追加的复验标记。PR 保持草稿，未合并。页面上的 Checks 0 表示该 PR 没有检查记录；本次验收依据是本机命令检查和远端文件、提交记录的复核。

这次跑通了“外部消息 → 自动接单 → 提交 PR → 原任务续接”的链路。它验证了系统能替人接住后续要求、把结果送回原处。