给 AI 开一个编码会话，它能修一个问题；把它放进团队的 GitHub 仓库，问题就变成了：谁可以让它开工，新消息该接着哪件事处理，什么时候需要人介入？10 月 31 日公开的 DeepSeek Super-agent 研究原型，开始处理这组问题。

　　它面向单个 GitHub 仓库，以 DeepSeek Harness 插件包的形式运行，可接收 GitHub 事件，也可选接飞书。模型负责理解和编码，系统负责把请求组织成能够持续跟进的工作。

先看一个结果：4条事件，只建2个工作项

　　同一条 Issue 评论收到两次，应跳过重复事件；同一讨论又来了跟进，应接回原任务。下面的独立 Python 教学例子共收到4条事件，最终只创建2个工作项。它演示事件去重与讨论归并，未运行 Super-agent。

　　图：独立 Python 教学例子的实际结果。E2 的重复投递被跳过，同一讨论的跟进回到 T1，最终只有两个工作项；未运行 Super-agent。

和普通编码会话相比，多了什么

　　图：DeepSeek 官方组织仓库的 README。作者明确说明这是研究原型，并非 DeepSeek 正式产品；公开实现与内部版本、设计文章不完全相同。

使用方式	谁组织后续工作	读者应关注什么
单次编码会话	人把需求和反馈继续交给会话	当前修改是否正确
Super-agent研究原型	系统关联事件、讨论、工作项和执行会话	请求会不会重复开工，评审是否有位置接回

　　这一点会影响上手预期：设计文章谈到的方向，不能全部当成下载后就能用的功能。官方仓库采用 MIT 许可，现有文档已经写清事件、任务、执行、面板和故障恢复的具体规则，适合从这些实际对象理解它。

对象	它回答的问题	具体例子
Source / Trigger	从哪里来了一条新事件？	某条 Issue 评论
Thread	这条消息属于哪段讨论？	Issue #12 的讨论串
Eval / Mandate	是否启动工作，允许做到哪里？	接受修复请求，记录范围和规则版本
Ticket	持续跟进的是哪件事？	修复空搜索词处理
Assignment / Executor	这次由谁执行？	专属 worker 会话和目录
Channel	结果回到哪里？	原 Issue、PR 或飞书讨论

一条修复请求怎样走完流程

　　以一个公开学习项目为例：页面搜索框收到空字符串时应显示提示。下面是教学场景，用来对应项目文档中的事件流。

1. 允许发起任务的人在 Issue 中请求修复。GitHub Source 将这条评论转成 Trigger，记录到对应 Thread。
2. 新工作经过 Eval 判断。接受后创建 Ticket，并留下 Mandate，说明是谁提出、依据什么规则、处理范围是什么。
3. Ticket 获得 Assignment。Executor 使用 worker-<ticket id> 会话，在自己的工作目录修改代码并检查结果。
4. 产生 PR 后，结果通过原来的 Channel 回到讨论。收到相关跟进时，系统把消息交回对应工作项，避免重新开一件重复任务。
5. 需要补充信息、遇到阻塞或等待评审时，面板把“需要人处理”的事项提出来。

　　Trigger 还有一个容易忽略的约束：同一条事件重复接收，不应创建两个 Ticket。 GitHub 轮询、重连和重启都可能再次看到旧事件，系统需要记住读到了哪里，而不能只靠模型说“我好像处理过”。

　　这个结果背后需要两种不同的记录。第一种记“事件是否已经接收”，防止重复消息触发重复工作；第二种记“这段讨论属于哪件任务”，让后续评论接回原任务。事件ID负责去重，讨论与工作项的关联负责持续跟进。

　　开头的教学例子只在当前进程内保存这两种关系。实际系统还需要持久保存接收进度和任务关联，才能在重启后继续工作。真正需要评估的，是消息到任务再到反馈的整条链路。

Router与Worker分开，解决的是谁被谁拖住

　　可以把它看成“接单台＋执行工位＋任务账本”：Router接收消息并判断交给哪项工作，Worker负责具体修改，宿主持久保存任务状态。执行者暂时停止对话，不代表任务记录消失。

环节	负责什么	为什么需要单独处理
Router路由	接收请求、关联讨论、分配跟进	新消息到来时能找到正在处理的工作
Worker执行	修改文件、运行检查、提交产物	一项工作的长操作不应占住全部接单逻辑
宿主状态与面板	保存进度，显示阻塞和待评审项	人能知道什么时候需要介入
Channel反馈	将结果送回原讨论	请求人不必去另一个会话追问

　　例如，Worker 已经提交 PR，并报告 ready，但 PR 仍未关闭，此时面板可以显示 Awaiting review。这个状态告诉人“该看改动了”，而不是误报“整个任务已结束”。没有 PR 的任务，ready 则可以结束该工作项。

　　执行中的 shell 命令也可能转入后台。文档规定，仍有后台工作时，Ticket 继续占用执行槽位，不能因为前台一轮对话结束就当成空闲。并发上限约束的是实际执行资源。

独立目录还不等于安全沙箱

　　每个 Ticket 有自己的目录，但官方说明：没有配置 prepare 命令时，Worker 从空目录开始；使用 Git worktree 准备仓库只是典型配置，并非自动保证。想隔离代码改动，需要明确准备目录与分支。

　　更关键的是，Executor 以操作系统用户身份执行命令。文档直言，目录和命令包装器建立的是默认行为，并不构成安全隔离。测试这种原型时，应使用专门的学习仓库和受限凭据，不能因“每任务一个目录”就给它整台机器的敏感访问能力。

哪类任务值得先试

　　适合的起点是范围清楚、反馈位置固定、能通过测试或人工评审判断结果的仓库任务，例如补一个回归用例、处理一个小型 Issue、根据 CI 结果继续修改 PR。面板则优先回答：现在什么事情需要我，系统有没有问题，某件工作走到了哪一步。

　　判断这类系统有没有用，可以观察一条完整链路：同一请求是否只建一次工作项，后续评论是否回到正确任务，重启后是否保留进度，最后是否把结果送回原讨论。接任务、执行、交付能连起来，团队才不需要替 AI 手动搬运上下文。

　　资料：DeepSeek Super-agent 官方仓库与 README、执行与恢复说明。