YAOTU INSIGHTS

DeepSeek开源Super-agent:从替你写代码,到替团队接任务?

DeepSeek开源Super-agent:从替你写代码,到替团队接任务?
给 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 或飞书讨论一条修复请求怎样走完流程以一个公开学习项目为例页面搜索框收到空字符串时应显示提示。下面是教学场景用来对应项目文档中的事件流。允许发起任务的人在 Issue 中请求修复。GitHub Source 将这条评论转成 Trigger记录到对应 Thread。新工作经过 Eval 判断。接受后创建 Ticket并留下 Mandate说明是谁提出、依据什么规则、处理范围是什么。Ticket 获得 Assignment。Executor 使用worker-ticket id会话在自己的工作目录修改代码并检查结果。产生 PR 后结果通过原来的 Channel 回到讨论。收到相关跟进时系统把消息交回对应工作项避免重新开一件重复任务。需要补充信息、遇到阻塞或等待评审时面板把“需要人处理”的事项提出来。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、执行与恢复说明。