SuperAgent工作机制概念封面。生成插画用于解释分工，不代表产品界面。

把AI接进GitHub，再拉进飞书群，它就能当开发同事了吗？

最初看起来很简单：有人提需求，AI去改，最后交一个PR。但真正放进团队，你很快会碰到另一串问题：群里随口一句“这里不好看”，算不算让它重做？评审补了意见，谁负责接着改？三个任务同时跑，能不能别动同一份工作目录？服务重启之后，它还记不记得刚刚发过什么？

DeepSeek团队公开的 dsh-superagent-prototype，把这些事做成了一套运行在DeepSeek Harness上的开发协作系统。这篇就围绕SuperAgent展开：沿着一件修复任务走完流程，再打开对应源码，看看它做得好在哪里、哪些地方仍要人兜底。

本文对照的是10月31日公开的6337fc8版本。项目定位为研究原型，并非DeepSeek正式产品；以下是公开源码和文档解读，尚未部署实测。官方仓库

官方仓库原页面，2026年11月3日截图。

1．SuperAgent到底是什么：一套会接单的开发系统

先把三个名字分开。

模型负责理解需求、分析代码、决定下一步调用什么工具。DeepSeek Harness提供会话、工具、权限预设和插件等运行能力。SuperAgent是装在Harness里的一个bundle，用这些能力组织团队开发工作。

当前原型围绕一个GitHub仓库运行，GitHub是主要入口，也可以接入飞书。它有自己的Agent账号，能够接收消息、评论、推送分支、开PR，再把结果送回原来的讨论。真正执行时，每项工作有独立会话和目录。

因此，“Super”落在整套协作安排上：它把消息入口、授权、任务分配、执行、结果回传和人工处理串起来。使用者不必为每个Issue重新开一个聊天框，再手工把各处信息搬来搬去。

源码里的package.json也把它描述为面向单个仓库的主动Agent。评估模型和执行模型可以分别配置；没有单独设置时，使用Harness配置中的默认模型。不要把这个项目和一款新发布的模型混为一谈。项目说明／部署文档

按公开实现绘制的中文结构图。SuperAgent组织工作，Harness提供运行能力，模型完成判断与执行。

2．从一句需求，到一张有来历的工单

下面始终用同一个假设案例：同事在GitHub Issue里@机器人，让它修复“导出按钮点两次，会重复提交”的问题，并补上回归测试。

入口模块先接收事件，留下来源、发送者、讨论线程和原文。文档把这样的事件叫Trigger，把GitHub、飞书这类接入来源叫Source。接收到消息，还没有等于接到了任务。

接下来分两层处理。第一层是确定性的准入检查：这个身份能不能发起工作，有没有直接叫Agent，接收范围有没有开放相应权限。第二层才轮到模型判断任务内容、范围和已有工作的关系。

通过之后建立Ticket，也就是工单，并附上Mandate。它记录这项工作获准执行的范围、强度、依据的策略版本，以及相关发送者和接收方式。之后需要扩大范围，不能靠执行器一句“我顺便做了”就把授权改掉。

Assignment则表示这张工单当前派给哪个执行器。同一张工单在恢复、重试的过程中可以有不同派工记录，所以Ticket并不直接等于某个正在运行的模型会话。

名称	放到这个修复例子里
Source / Trigger	GitHub入口，以及同事提出要求的那条事件
Thread	Issue及其后续讨论
Eval	判断事件能否成为工作、是否已有归属
Mandate	允许修什么，按哪一版规则接下的
Ticket	修复导出重复提交这件工作
Assignment / Executor	当前派工，以及实际改代码的执行器

这套记录的价值在后面才看得出来：同一条Trigger被重复接受，只建立一张工单；任务出问题时，也能追溯是谁提出的、接单依据是什么。Engine负责统一写入这些核心状态，外部模块通过限定接口请求修改，避免各处各记一套账。任务模型／Engine源码

官方文档中的任务流：事件进入评估，工单带着授权交给执行器，后续讨论通过订阅继续送达。

3．主动接单之前，先过“这句话真让我干了吗”这一关

这是我读源码时最愿意停下来看的部分。

团队里的话并不总是任务。“导出重复了，帮忙修一下”有明确对象和动作；“这页感觉怪怪的”却没有给出期望结果。模型如果把后一种话直接扩写成重新设计页面，产出可能很多，返工也会很多。

src/policy.ts里的主动研判结果包含几个很具体的字段：有没有提出实施要求、目标依据是什么、是否还需要设计决定，以及支持判断的证据。

代码中的directionAllowed要求：确实提出了实施要求，目标不能仍是未确定状态，也不能还有悬而未决的设计决定。进入规则研判的接单结果还要覆盖全部启用规则，每条只评一次；接单需要匹配规则和意图证据。模型不能只返回一句“我认为值得做”就算通过。

默认规则也相当克制：一类是纠正措辞、错字、标点和既有翻译；另一类是目标明确的局部视觉修复，比如恢复已有标准下的间距或对齐。它没有默认宣布“所有群聊都可以转成开发需求”。

assessmentOutcome与目标判定的官方源码页面。规则覆盖、目标方向和意图证据都有明确检查。

主动候选还有三个模式：off不接纳推断候选；observe照常评估，但把肯定结果记成“本来会接”，不建立实际工作；auto才允许满足条件的推断候选被接受。默认是observe。

明确请求在三种模式下都能工作。 所以观察模式的用法是：正常@它试几个任务，同时查看它对其他消息作出的接单判断。确认规则与团队习惯相符之后，再考虑开放主动执行。

策略调整的生效时机也值得留意：更改会通知受影响的运行任务，并不会立刻取消全部在途工作；已经结束的任务恢复前会重新校验授权。真要立刻停下一件工作，面板里的Stop是直接操作，和仅仅调整一条规则不是一回事。

这里有个边界：宿主代码能校验身份、模式和结果结构，语义理解仍依赖模型。它可能误判目标是否清楚，也可能漏掉含蓄提出的请求。observe提供了观察和调整的机会，并没有让语义误判从此消失。授权文档／策略源码

官方模式表。observe控制推断工作，不会把所有明确请求一起关掉。

4．主Agent派工，Worker改代码：分工具体到哪里

SuperAgent的主会话负责路由、接单、派发和转达问题，具体的技术判断交给执行器。执行器读取原始需求、仓库和AGENTS.md，再调查、实现和验证。

在导出按钮的例子里，主会话不该提前拍板“加一个防抖就行”。重复提交也可能需要请求状态管理、幂等处理或其他修复，要由读过代码的执行器判断。转手时保留原始请求，才能减少主Agent转述造成的信息损失。

每张Ticket有独立的Worker会话和任务目录。准备命令可以用git worktree从本地克隆创建不同工作副本：按钮修复在一个目录，文档更新在另一个目录，方便分别改动和提交。没有配置准备命令时，执行器开始时拿到的可能只是空目录，这也是部署中必须填好的部分。

当前源码的普通Worker并发默认值为3，可以配置。并发满了也不能让人永远排在新任务后面：执行器调度为人工跟进或状态请求保留了一个额外槽位。它让人追问已有工作时有机会及时唤醒执行器，不被连续新接单堵住。

WorkerSlots源码中的并发预留。额外槽位用于人的跟进，并非所有新任务都能超过上限。

长命令也有专门处理。主会话与Worker的前台命令超过5秒会转成后台作业，好让下一步有机会处理新消息。后台作业或子Agent仍在跑时，任务继续占着Worker槽位，状态仍是工作中。文档还规定了一轮结束后的后台时限，以及交给人评审时如何释放槽位。

这些安排会改善调度，但多开目录不等于多项修改自动兼容。两件任务碰到同一个接口，分别测试通过，合在一起仍可能冲突。并发提高了同时处理工作的能力，合并后的集成质量仍需靠测试和评审保障。执行文档／Worker实现

5．评审意见怎么跟上来，为什么不会每句都重新开单

导出按钮修好、PR开出来后，工作通常还没结束。评审可能补一句：“接口失败后，按钮也应该恢复可点。”

SuperAgent通过Subscription让工单订阅相关讨论。任务自己的Issue、PR和评审意见可以继续把上下文送给同一个执行器。Worker判断是否属于原范围；如果是，就继续处理；如果超出范围或属于另一张工单，则交回路由层。

“送给它看”与“允许它做”是分开的。执行器可以关注相关Issue获取信息，但这类仅供参考的订阅不会带来新的授权。外部引用和机器人消息也不能自行把任务范围扩大。

这点在跨讨论时尤其有用。群里有人明确引用某个PR，主会话可以据此关联已有工作；仅仅话题相似，不足以随手挂过去。否则两件都叫“导出”的需求，很容易混到同一个Worker里。

我认为它比单纯的聊天记忆更适合追踪团队工作：任务有明确归属，后续消息也有可查的去向。代价是订阅、跟进归属和移交规则较多。团队如果Issue写得乱、PR互相没有引用，模型仍然需要猜，机制不能替人补齐所有业务背景。提示词与分工

中文示意：原任务的跟进交给执行器，越界需求重新路由，仅供参考的讨论不扩大授权。

6．它怎么记住进度：SQLite、持久队列和Outbox

Agent执行到一半重启，最怕两件事：已经做过的又做一遍，该继续的却没人接。

SuperAgent在这里采用的是应用工程里很熟悉的办法。Store管理SQLite数据库，任务、事件、输入、判断和待执行动作有持久记录。Effects保存要对外执行的动作，状态事务提交之后才开始处理。

可以把它理解成先登记“这条消息需要发送”，再去真正发送。发送失败，保留记录，按照退避策略重试；服务停掉，尚未处理的队列行留在数据库里，下次继续。

源码里的Outbox.send很短，下面摘出核心三行：

store.atomic(() => {
  if (store.receipts.add(message)) effects.enqueue('reply', message.id, {})
})

同一个消息ID的回执重复添加会被忽略。投递时先看回执是否仍是pending，来源有没有启用，目标是否还接收消息，以及同一工单、同一讨论里更早的消息是否还在等待。正常情况下，确认接单的消息应当先于最终结果出去；前一条反复失败，也有相应的故障处理。

官方Outbox源码：回执与待投递动作一起登记，投递结果再写回。

这能减少丢进度和内部重复排队，却不能据此承诺“外部世界永远只执行一次”。代码是先等待外部发送，再登记发送结果；外部已接收、进程却在登记前退出，仍是需要考虑的崩溃窗口。这是从调用顺序得到的工程判断，不是本次复现到的故障。

重启恢复时，Worker还会被要求检查目录、git历史和GitHub现状，再重复外部操作。持久记录加上现场核对，比一句“继续上次任务”更有依据；实际效果仍取决于外部接口、恢复路径和执行器判断。架构文档／Outbox源码／Effects源码

先提交本地记录，再执行外部动作。回执记录本地状态，不能把它理解成跨所有系统的绝对一次性保证。

7．开了PR怎么算交付，自动合并又是另一回事

源码和默认提示词对交付要求分得比较细。

执行器报告ready，表示结果准备好交给人使用或审查；如果还关联着开放的PR，任务通常还需要继续跟踪PR。创建了一个分支或草稿PR，并不等于已经完成。

UI修改的默认要求尤其具体：PR里要同时有Before和After视觉证据，标明修改前后的版本，保持场景、视口、主题和有关UI状态一致。只有After截图，不能算视觉证据完整。读到这里，我觉得这条非常值得直接抄进自己的团队规范：界面有没有改对，不能只让AI写“看起来正常”。

自动合并也不是装上就全开。默认交付要求没有指定合并CLI时，PR由人合并。配置了对应工具之后，默认指令仍要求PR就绪、增删总行数少于200行、所需批准覆盖当前提交；有可见UI变化时，还需要明确谁有权批准。

这里的“小于200行”是当前默认提示词的条件，不是宿主代码替GitHub强制执行的合并门禁。文档明确说宿主没有专门的合并决策逻辑。真正要求批准才能合并，应当配置GitHub分支保护和旧批准失效规则。项目自己也区分了“模型应遵守的要求”和“平台实际拦得住的动作”。交付要求原文

默认交付要求原页面：UI前后证据、评审及合并条件。

8．我认可的优点：有用在这些细节里

读完之后，我最认可的是它把开发协作中的几个常见问题落实到了具体对象和流程上。

第一，工作有来历。 工单带着授权和策略版本，后续判断、派工与输入有记录。比起从聊天里翻“它怎么会改这个”，更容易定位到接单环节。

第二，能处理接单之后的连续过程。 后续补充、评审、CI、失败和恢复都能进入同一件工作的生命周期。实际使用中，最耗人的往往就是这些跟进。

第三，允许先观察主动行为。 在现有仓库上跑observe，先查看它想接什么，再调规则，是一种比较容易逐步试用的办法。

第四，它认真限制无效沟通。 设计要求任务确认一次，工作时少说，有结果、需要决定或确实卡住时再联系。管理面板也先显示需要人处理的事。对于团队工具，这比刷满“正在努力”的消息实用得多。

这些安排能否省下时间，还得看任务接得准不准、交付能否通过评审。光把流程装齐，算不出“比人快几倍”。设计原则

官方设计文档要求减少对人类注意力的占用，并反对批量制造无价值工作。

9．缺点也要摆出来：最贵的未必是Token

部署和维护并不轻。 Harness版本、模型服务、Agent专用GitHub用户账号、CLI凭据、任务目录、状态数据库都要配好；飞书还会增加应用权限和机器人配置。一个人偶尔改几行代码，用现成编程助手可能更直接。SuperAgent的额外成本，要靠持续的团队协作需求来摊。

运行权限需要另做隔离。 部署指南明确说明，相关会话以操作者的系统用户权限执行命令。包装器选择默认凭据、任务目录分开，都不是安全沙箱；Worker仍可能按绝对路径运行程序、接触用户目录。专用系统账号、仅放必要凭据等隔离措施，应当在试用之前就准备好。

语义判断与代码质量仍是模型能力问题。 宿主能限制流程和字段，不能保证模型理解业务、补全测试或识别所有隐含约束。规则写得含糊，它可能接错；规则过窄，又可能漏掉有价值的工作。多Agent也会增加调用次数和调度开销，是否划算需要按任务统计。

单仓库定位限制了覆盖范围。 当前部署围绕一个GitHub仓库，GitHub Enterprise Server不受支持。跨多个服务协调变更、组织级权限和复杂发布流程，不能直接套用成已经具备的功能。

系统复杂度会转化成运营工作。 消息拉取失败、凭据失效、Worker受阻、投递失败和评估超时，都可能需要人处理。面板能把问题摆出来，但它不会让维护工作消失。SQLite和队列提供了恢复基础，也不能单凭这些设计就断言已经具备大规模高可用部署能力。部署指南／面板文档

官方部署指南对专用环境、Agent账号及运行权限的说明。

10．哪些团队值得试，怎么判断有没有真省事

我认为最适合先试的，是有稳定代码仓库、正常使用Issue和PR、已经有基本测试，而且经常被零碎需求打断的小团队。

可以从文案修正、目标明确的局部样式修复、可复现的小Bug入手。把授权名单收窄，主动模式留在observe，先用明确请求验证整条流程。PR先让人合并，确认代码质量、消息归属和权限配置之后，再讨论进一步自动化。

涉及付款逻辑、数据迁移、身份权限、跨服务改造的任务，人工决策和验收成本更高。我不会因为入口已经接通，就把它们一起扔给无人看管的队列。

评价也不该只数PR数量。我的试用记录会至少包含下面这些项：

观察项	真正想知道什么
接单是否正确	误接了多少，漏了多少，规则怎么调
结果是否可审查	能否复现问题，修改和测试是否对应
人工花了多久	从补充需求到评审、修正，总共用了多少时间
外部动作是否干净	有没有重复评论、重复PR、错误关联
失败能否恢复	重启、API失败之后，是否能接回原来的工作
总成本	模型调用、执行环境和人的维护时间

管理面板首先回答“现在有什么需要我处理”，再展示系统情况和任务历史。

我的判断是：SuperAgent最值得研究的，是把AI从一次性的代码会话，组织成能够持续接收请求、跟进任务、交回结果的工作系统。任务本身越明确、仓库越容易验证，这套安排越可能发挥作用。

我会先看它能不能把那件重复提交的小Bug修好，测试补对，评审意见接住，然后在真正需要人时把问题讲清楚。这一件事走顺了，再逐步扩大任务范围，比先让它一天开几十个PR更有说服力。

---

资料与截图核对：2026年11月3日。公开源码版本6337fc823ce20251c8de8085948165c81aaa701e，代码与文档遵循MIT许可。本文阅读了任务模型、授权、执行、提示词、部署和架构文档，并对照policy.ts、core/engine.ts、executor/dsh.ts、app/effects.ts及app/outbox.ts等实现；未运行部署及性能测试。封面为生成概念插画，中文机制图为依据源码绘制的示意，其余配图为官方仓库真实截图。

个人原创，转载说明出处。