DeepSeek 开源 Super-Agent：让 AI 接单之后，还能把事情跟到底 • AI Logs

你在 GitHub Issue 里让 Agent 修一个问题。它交了代码，测试没过；你补充复现条件，同事又在 PR 里指出一个边界情况。如果还要把这些讨论复制回聊天窗口，再解释一遍前因后果，协调工作就仍然是你的。

DeepSeek 开源的 Super-Agent 想接下这部分工作：在团队原本使用的工具里接单，写代码，跟进后续反馈。它目前是研究原型，面向一个 GitHub 仓库运行，依托 DeepSeek Harness，也可以接入飞书。

交了 PR，还得接着做

有权限的人提出请求后，系统建立工单，分配独立的 Agent 会话和工作目录。后续评论和 CI 信息继续送进这个会话，Agent 在原任务范围内处理，再把结果回复到原来的对话。

这里有个容易忽略的区别：模型回答结束、PR 提交、修改合并，是三个不同的进度。有 PR 待审时，工单的 ready 表示等待评审，系统还要跟踪 PR 的关闭或合并情况，才能按规则结束工单。

程序重启也需要接得上。项目用 SQLite 保存工单、事件、决策和待执行工作。按文档设计，中断的执行恢复时，会先检查工作目录、Git 历史和 GitHub 上已经发生的操作，再决定下一步，避免从头再来。

平时用编码 Agent，最费神的往往就是这些收尾工作：追问测试结果、补上下文、提醒它处理评审意见。Super-Agent 把它们纳入了同一张工单。

假设原任务是修复登录页，有人在相关讨论里说“顺便把支付模块重做一下”。Agent 看到了这句话，就能照做吗？

项目把上下文和授权分开处理。订阅线程的消息可以供执行器参考，却不会自动扩大任务范围。超出范围的请求，要交回系统重新路由。

接单前，系统先检查身份和请求条件，再让模型处理需要语义理解的判断。明确请求可以直接路由；从讨论里推断出来的工作，则需要规则评估。接受任务时，还会记录授权依据、任务范围、策略版本和匹配的规则。

这份记录能回答一个实际问题：Agent 为什么开始做这件事，又是谁允许它做到这一步的？

主动接单容易添乱。把一句闲聊当成需求，或者为小问题开出一堆 PR，都会增加团队的审查负担。

所以，推断任务默认使用 observe 模式：评估之后，只记下“本来会接单”，不创建任务。团队可以先看看它挑的事情值不值得做，再决定放开哪些规则。

off 不接纳推断任务；auto 允许通过评估、且匹配启用规则的候选成为任务。明确请求在三种模式下都可以工作。

沟通也采用类似的克制：确认一次请求，工作时保持安静；有结果、需要决定或无法完成时，再回到原对话。监督面板优先展示需要人处理的事项。

比起反复汇报“正在分析”，团队更需要知道哪一步卡住了、需要选哪个方案，以及 PR 什么时候可以审查。

任务范围有记录，命令执行却没有同样强的隔离。执行器以操作者的操作系统用户身份运行命令，无须逐次审批。工作目录和命令包装器不构成安全沙箱。

自动合并也主要靠交付要求中的提示词约束，宿主没有专门的合并决策逻辑。要强制执行评审要求，还得配置 GitHub 分支保护。

这会直接影响部署方式：用什么账号运行、能访问哪些凭据、哪些分支允许写入，都需要在模型之外设好。公开代码与内部版本、设计文章也不完全一致，不能把文档里的所有设计都当成已经落地的功能。

如果团队已经用 Issue、PR 和 CI 协作，可以先给它一个范围清楚的小任务，观察从接单到评审的全过程。除了看代码有没有改对，也记一下人介入了几次：哪些是在做必要的判断，哪些只是替它补上下文、催进度。

省下后面这些事，才是我对这个项目最具体的期待。