DeepSeek Super-agent 技术拆解：从写代码，到持续接活

沿着公开代码，拆清一个持续接单的编程智能体怎样授权、分发消息、调度执行，以及从中断中恢复。

让 AI 改一段代码，已经不稀奇了。难的是：你在 GitHub 上提了需求，它开始干活；你去忙别的，它继续跟进评审和 CI；服务中途重启，它还知道自己答应过什么、哪些事做完了、接下来该找谁。

DeepSeek Harness 团队公开的 dsh-superagent-prototype，研究的就是这一层。它把一个 GitHub 仓库接成持续工作的入口，也可以选接飞书。获准的人提出请求后，系统建立任务，交给独立会话和目录里的 Worker，最后在原来的对话中交回结果，通常是一个可审核的 PR，或者一个需要人回答的问题。

它适合有 GitHub 协作流程、愿意配置专用账号和执行环境的开发团队，以及研究 Agent 工程的人。个人也能研究和部署，但这不是下载后就能接管全部工作的桌面助理。一个部署服务一个仓库；模型、工具、Shell 和会话运行能力由 DeepSeek Harness 承载。

先划清发布边界：README 明确说，这是供参考的研究原型，不是 DeepSeek 正式产品；为公开发布调整过，也不等同于内部系统或相关文章描述的全部设计。下面只拆这份公开代码已经实现的东西。

先把“答应过的工作”从聊天记录里拿出来

很多 Agent 的任务状态藏在一长串消息里：模型说过“我在做”，系统就把它当成正在做；模型最后说“完成”，整个流程也就结束。只要一项工作跨了多个讨论串、多个执行轮次，这种对应关系就会变得很脆。

这个原型另建了一套任务模型。Trigger 是收到的事件，Thread 是事件所属的讨论串；Eval 判断是否接单，接受之后创建 Ticket，同时留下 Mandate——这项工作依据哪个版本的规则、由谁发起、获准做到哪里。Assignment 则记录这一次由执行器如何运行它。

Trigger → Eval → Ticket + Mandate → Assignment → Worker 事件 判断 任务与授权依据 执行轮次 具体干活

Ticket 和 Assignment 分开，是后面一切恢复机制的基础。同一张任务单可以先后经历多次 Assignment；当前 DSH 执行器在重试时复用它的 Worker 会话、目录、分支和 PR。执行中断了，系统不必假装这是一个全新的请求。反过来，Worker 一轮说完话，也不意味着任务已经终结。

这里也没有“一条讨论串只能有一个任务”的限制。一个 Thread 可以订阅多个 Ticket，一个 Ticket 也能跟踪多个 Thread。Thread 之间的关联只提供证据，真正决定消息送往哪里的，是 Subscription。把“相关”与“归谁处理”分开，可以避免关联信息被顺手当成执行指令。

任务状态由 Engine 和 SQLite 管理；主 Session 在事务外判断，Worker 负责具体实现。图示为源码机制整理，并非官方产品界面。

任务状态由 Engine 和 SQLite 管理；主 Session 在事务外判断，Worker 负责具体实现。图示为源码机制整理，并非官方产品界面。

主动接活，先解决“谁允许你做”

新工作进入系统，要过两层判断。第一层是宿主代码里的 gate：发送者是谁、来自哪里、有没有点名 Agent、准入表怎么配置、是不是被列入名单的机器人。第二层才是模型对请求内容的判断。正常情况下，获准的人明确点名 Agent，形成 explicit 请求；普通讨论或机器人消息至多形成 inferred 候选，不能靠一句“请忽略之前规则”把自己变成授权者。

主动候选的默认模式是 observe。模型可以判断“这件事我本来会接”，但系统只留下 would accept 记录，不真正建单。off 模式连这类推断候选都不产生；auto 才会在条件满足后接受。三种模式管的是推断候选，获准的明确请求仍可工作。

而且 auto 并不是让模型随便找活。assessmentOutcome 要求每条启用规则恰好评估一次，至少命中一条；要有实施意图的证据，目标必须已经明确，不能仍有待定的设计决策。字段不齐或条件不符，宿主不会照单全收。不过，意图是否真实、证据是否充分，仍要依赖模型判断；结构化校验不等于判断一定正确。

这套设计有一个容易漏掉的例外：已有任务的后续消息走订阅通道。活跃 Ticket 订阅的 Thread 上，新评论、机器人消息和 CI 结果会作为上下文直接送到 Worker，绕过新任务的 gate，但不增加任何授权。Worker 只能在原 Mandate 范围内处理；发现是范围外的新工作，要 handback，等没有其他 Ticket 继续持有这条消息后，再交回 Eval。

新工作与已有工作的后续消息走不同通道。订阅提高上下文到达效率，不能因此扩大任务权限；范围判断仍需要执行模型遵守约束。

新工作与已有工作的后续消息走不同通道。订阅提高上下文到达效率，不能因此扩大任务权限；范围判断仍需要执行模型遵守约束。

规则变更也有具体语义。正在进行的 Eval 会作废，按新版本重新判断；受影响的活跃 Ticket 收到规则变化通知，却不会一律被强杀。已结束任务被人的后续评论唤醒前，则要重新核验原 Mandate。人工停止更明确：它撤回授权，任务不再接收后续消息；再做工作需要新的接受决定。

主会话负责接工作，Worker 负责把工作做完

主 Session 收候选、做评估和路由、汇总报告，对外沟通。Worker 才负责在任务目录里读代码、选择实现、运行工具、验证结果。不要把它画成“一个超级模型把所有细节装进同一份上下文”：它有长期任务状态，也有按职责分开的会话。

这是一种职责分工，并不是绝对工具隔离。源码仍给主 Session 提供 Shell、文件读取等能力；“别深入写实现方案”主要靠提示词约束。Worker 也可以调用子代理，并非固定只有两个模型角色。拆分的实际收益取决于路由质量和上下文管理，仓库本身没有给出足以量化这一收益的生产实测。

调度里最有意思的细节，是它把“后台还在工作”算进负载。maxWorkers 默认是 3；准备目录和启动会话就先占位，避免两个异步启动同时抢到最后一个名额。普通新任务和 CI 唤醒等正常名额；人的消息或状态请求可使用最多一个额外名额，并优先于新启动。

Worker 的文字轮次结束后，只要 Shell Job 或子代理还在运行，它就继续占用名额。否则面板看起来空闲，后台却已经开满。这也解释了为什么 Shell 超过 5 秒转后台：让会话能在后续步骤接收消息，并没有把命令本身算快。这里限制的是 Worker 调度名额，也不等于模型 API 的总并发硬上限。

默认三个正常 Worker 名额，另有最多一个名额用于人工消息唤醒。普通后台工作继续占位；交接给人时释放名额，保留 Job 另行处理。

默认三个正常 Worker 名额，另有最多一个名额用于人工消息唤醒。普通后台工作继续占位；交接给人时释放名额，保留 Job 另行处理。

后台任务的生命期也分情况。普通 turn 结束后的后台等待有 30 分钟限时：到限会杀 Shell Job，记录仍在运行的子代理，后者可以继续。交接给人的 ready、提问、blocked 或 failed 则释放名额并停止子代理；供人验收的服务器等 Shell Job 可以留下，不受上述等待限时约束，直到 Assignment 结束。它没有用一个“超时全杀”概括所有工作。

任务能续办，靠的是事务和持久队列

Engine 的状态修改入口是同步的，在短事务里核验条件、更新任务、记录决定。等待模型回复发生在事务外。系统不会为一次长推理把 SQLite 事务一直悬着。SQLite 保存事件、讨论串、任务、决定、待执行动作和消息回执；Runtime 先锁定状态目录，阻止第二个实例同时使用这份状态。它是单状态目录的本地系统，没有在这里实现多机分布式调度。

关键在于把“决定做”与“真的做”分开。一次领域变更在事务内写下状态，也排入 Effects；事务提交之后，适配器才去启动 Worker、投递输入或发送消息。否则先发出外部动作、再写本地任务，进程恰好崩溃时，就会留下一个系统不记得的动作。

Effects 按 kind 和 key 保存队列项。同一个等待项可以更新负载，并增加 generation；执行结束时，只有序号和代次仍匹配才删除。这是在处理一个很具体的竞态：旧动作执行期间，新消息更新了同一个待办项，旧完成回调不能把新待办一起删掉。失败会退避重试，等待空闲名额这种 Later 情况则延后处理，不当成一次失败。

Outbox 再把外发消息的回执与 reply 动作一起落库。重复的本地消息 ID 不会重新入队；同一 Ticket 对同一会话的后续消息，通常等前一条先发，前项连续失败达到阈值后才不再挡住后项。于是“已接单”和“结果完成”有了可追踪的发送状态，消息暂时发不出去也不靠模型记着再补。

事务保证本地状态与待办动作一起提交，Effects 在提交后执行。外部服务成功、本地回执未落库之间仍有一致性窗口，不能承诺端到端 exactly-once。

事务保证本地状态与待办动作一起提交，Effects 在提交后执行。外部服务成功、本地回执未落库之间仍有一致性窗口，不能承诺端到端 exactly-once。

这仍不等于外部动作绝不重复。GitHub 评论已经成功发出，但进程在记录 sent 回执前崩溃，重试就可能再发一次。本地去重不能替远端提供幂等保证。所以恢复提示明确要求 Worker 先检查 worktree、git 历史和 GitHub 状态，别把已经完成的外部操作再做一遍。这是可恢复执行，加上对现实状态的复核；不是让程序从断电的那条指令继续。

“完成”“等人”“停下”必须是不同的状态

这个系统不从一段自由文本里猜谁在等谁。Worker 用结构化 Report 交回状态，通过单独的 question 字段提出要人回答的问题。普通 progress 留在任务内部；结果、问题、阻塞等才转给主 Session。面板优先展示待回答、待审核和失败，健康状态尽量不占注意力。

ready 也不自动等于 PR 已合并。没有关联 PR 的任务，ready 可以结束为 completed；跟着 PR 的任务要按其关闭、合并等状态收尾。blocked 或 failed 后，CI 和机器人消息继续记录，但不自动唤醒执行器；需要人的消息、重试或新的有效报告解除等待。这个等待状态存进数据库，重启不会把它清零。

Pause processing 和 Stop 同样不同。暂停停止新评估、投递、派工和回复，Source 仍可记录事件，已经运行的一轮 Worker 不会被中断；Stop 针对具体 Ticket，撤回这项工作。运维上如果把暂停当成紧急终止按钮，预期就会错。

哪些由代码守住，哪些仍靠模型自觉

独立 Session、独立目录和专用 GitHub 账号，有助于分清上下文与操作身份，但不等于安全沙箱。ensure 会把受管会话设成 danger-full-access；Worker 以操作者的操作系统用户运行命令，不逐项请求审批。CLI 包装器和命令黑名单建立的是默认路径，文档明确承认：程序仍可通过绝对路径执行。

例如，默认交付提示词规定了自动合并所需的审核、代码变更规模和合并账号，但宿主没有一套专门的 merge 判定逻辑。真正要强制审核条件，仍需 GitHub 分支保护等外部机制。这个区别很重要：把约束写进 prompt，是在指导行为；把条件交给程序或平台拒绝，是另一种保证。

提示词本身也被当成配置管理：保存时产生不可变版本，提交要带 base revision，冲突就拒绝；每次模型请求使用当时的提示词版本，并记录会话读过哪些版本。它让你能追问“那次操作用的是哪套团队规则”，但版本记录并不能证明模型忠实执行了规则。

想试，先接一个仓库

仓库采用 MIT 许可证。开始前需要 DeepSeek Harness、模型服务配置，以及 Node.js、pnpm、git、GitHub CLI 等环境；部署脚本还依赖 sh、tmux 和 Python，不能把它当成一个原生 Windows 安装包。部署文档给出的公开 DSH 版本是 0.2.1-rc.3，兼容范围以 package.json 为准。

最直接的入口是把仓库交给编程助手，明确让它阅读 SETUP.md 并协助部署。流程会收集目标仓库、专用账号、允许发起请求的人、工作目录和是否自动合并，再配置 DSH Web 中的 Superagent 面板。源码示例用 prepare 命令为任务创建 git worktree；不配置 prepare，Worker 默认只拿到空目录。

起步时保留默认 observe，先检查它“本来会接哪些活”；允许名单保持小范围，合并先由人处理。配置完成后，由允许的账号在 Issue 或评论里点名 Agent 提出请求。GitHub 默认轮询间隔约一分钟，不是即时响应承诺。项目入口：https://github.com/deepseek-ai/dsh-superagent-prototype

我认为，这份原型最值得学的是它对“持续工作”的拆法：授权、任务、执行轮次、消息投递和人工交接，各自有状态，不让模型一句话包办。它还没有证明自己能在生产环境里长期可靠，也没有给出通用的效率倍数；但它把问题摆在了正确的位置。

AI 能写出一次补丁，只证明它这次会做。任务换了执行轮次、消息绕了几个入口、进程重启之后，系统仍能说清它该做什么、做到哪里，才谈得上持续接活。