DeepSeek开源超级代理,9篇设计文档讲团队怎么用agent

1. 一次commit的发布

2026年10月31日,deepseek-ai 组织下多了个仓库:dsh-superagent-prototype。只有一个commit,一次性整体发布,几小时内star涨到六百多。README第一句先把姿态放低:研究原型,不是官方产品,大量工程是编码代理写的,代码风格可能不一致,用前自己审。

但别被这句话劝退。docs/目录下是9篇按编号排的设计文档——000哲学、001领域模型、002授权、003执行、004提示词、005面板、006部署、007架构、008如何加一个新来源,每篇只依赖它之前的篇目,官方建议按顺序读。这不是随手丢出来的demo,是DeepSeek把内部跑的东西——"给整个团队打工的agent"——连同设计说明书一起摊开了。README还提到一篇论文《Exploring Super-agent Design: Towards a More Autonomous Agent System》,我搜了一圈,arXiv上还没有,应该是没发或者快发了。

它跑在DeepSeek Harness(社区里叫dsh,那个据报道开源两天9.5万星、口号"Everything is a Plugin"的agent框架)上,以插件bundle的形式存在。这句话信息量不小:DeepSeek没有另起炉灶做"超级agent产品",而是在自家agent框架上用插件验证一套团队协作设计。

2. 它怎么干活

定位一句话:面向单个GitHub仓库的主动式编码代理,顺带能监听飞书。

被授权的团队成员在GitHub issue或飞书群里对它提需求,它走一条完整的流水线:把请求立案成工单(Ticket),开一个自己的会话和独立目录,在里面干活,干完在原对话里回复——通常是提一个PR。整个过程有个Web面板,但面板不是仪表盘,它只显示一件事:哪些事在等人处理。

流水线的每个环节都有明确的主人。来源(Source)负责把GitHub事件翻译成触发(Trigger);线程(Thread)是一段按时间排好的对话;评估(Eval)决定这个触发接不接——接的话发一张"授权"(Mandate),写清能干什么、干到什么强度、依据哪一版规则;工单拿着授权开工;后续这个issue或PR上的消息会自动扇出到工单,不用再@它。

订阅机制是这里最巧的一笔:工单一旦立案,就订阅了发起它的线程,之后任何人在这条线程里补充信息,都会直接送达执行器。同事在PR里补一句"顺便把测试也改了",代理听得见,不用重新喊它。

3. 全篇的题眼:少占人的注意力

9篇文档的核心是000那篇,字不多,但每一条都冲着一个行业共识去:agent越能干越好。DeepSeek的立场相反——一个能为整个团队行动的agent,同样可能浪费整个团队的注意力。所以第一原则是:尽可能少占人的注意力,尽可能多地给价值。每条消息、每个通知、面板上每个元素,都按"消耗谁的注意力"计价,产出抵不过成本就删掉。

落到代理行为上是五条规矩:

只在被要求时行动。 没人要求的工作,必须有团队写好的规则背书,而且这类主动工作起初只能跑在"仅记录"模式——代理先只写日志说"我本会去做这件事",团队看着日志觉得合理了,才放开手。

只在有人必须行动时说话。 接单时确认一次、说清自己要干什么,干活过程全程沉默,干完、卡住、需要决策了才再开口。确认限100词。

一次只问一个问题。 用结构化形式问,保证真的落到该回答的人头上,不是甩一篇长报告让人自己找重点。

按影响而非工作量决定停手。 本地改动做到"能被审查"为止,碰到需要设计决策的地方就停下来问,不自作主张往下推。

诚实汇报。 草稿标注未完成,失败就报失败,绝不为了不提问而绕过限制。

对运营者的要求也直白:从窄处开始,允许名单先短一点;代理太吵就把提示词改得更严,而不是发更多消息去解释噪音;别用它批量产出PR刷存在感;它以团队账号说的话,运营者要负责读。

这些不是口号。003执行文档里能看到它们怎么变成机制:自动合并默认关闭,开启也只对工单自己开的PR生效,要求已就绪、批准覆盖最新提交、增删行数合计不到200行——而且不能用代理账号去合并,因为GitHub会把合并记到启用者头上。"防止代理批量塞PR烦同事"这条原则,最后落在三个具体条件和一条账号规则上。

4. 被否决的概念,比被采纳的更值钱

001领域模型篇给了完整的领域设计:来源、触发、线程、评估、授权、工单、派工、订阅,每个概念有定义、有规则、有一段"为什么它存在"。授权不可变,记录策略版本;工单只有评估能创建;执行器在领域之外,通过派工连接进来。

最有分量的是文档末尾"被否决的概念"一节,列了十几条想过但砍掉的设计。挑几条感受一下:

把"人"做成实体、跨来源映射身份——否决。 人就是触发上的一条元数据,允许名单属于策略,同一个人在GitHub和飞书是两个账号这件事,交给提示文本解释。少一个实体,少一类同步问题。

执行器宣称"有人要求我停止"——不采信。 只有评估能决定工作结束的强度,执行器的自由文本不算数。这一条等于拿幻觉风险当输入做设计。

策略变更时取消运行中的工单——否决。 会产生半成品。变更被记录下来送达工单,但不撤销已发的授权。

"追加到工单"作为一种决定——否决。 追加就是订阅扇出,不需要评估再判一次。

做系统设计的人都知道这种清单有多稀缺:公开的设计文档几乎只写"我们为什么这样选",没人写"我们考虑过什么、为什么不行"。这份否决清单等于把踩坑路径也开源了。

5. 工程底子对得起设计文档

007架构篇是开发者向的,几个选择值得单独说。

整个系统只有一个Engine是领域状态的写入者,所有命令同步执行、单事务修改聚合;发消息、启动执行器这类外部动作走"先存储、后执行"的持久化效果队列——事务提交后才执行,失败按指数退避重试,典型的outbox模式。存储是单个SQLite文件。

对agent系统来说更关键的是测试:约40个测试文件,其中有个model-surface.spec,专门盯"模型能看到的一切"——工具、提示词、技能、输入——按角色检查预算漂移。翻译成人话:哪天有人改了提示词,让模型多看到不该看的东西,测试直接红。这类测试在agent项目里罕见,但恰恰是agent系统最该有的。

并发控制也做得细:每个工单占一个worker槽位,上限之外多留一个专门给人——新任务排不上队,人的消息永远插得进去。后台作业超过30分钟强杀,结果留给执行器下一轮读。

还有个不太常见的事实:README自己说,这个项目大量代码是编码代理写的。一个研究"团队怎么和agent协作"的项目,本身大部分由agent写出来——这既是卖点也是提醒。

6. 我的判断

丑话说在前面:这是原型,官方声明与内部版本、与那篇还没公开的论文都不一致,部分设计属于未来方向,没有实现。star涨得快,也带着DeepSeek的情怀溢价,别拿Harness两天的热度直接套在它头上。

但这9篇文档的价值不太依赖代码成熟度。现在做agent的方案分两类:一类比谁更能干,benchmark一路涨;另一类开始认真回答"agent怎么在人类组织里自处"——什么时候说话、什么时候闭嘴、做错了算谁的。第一类不缺人做;第二类公开的、成体系的设计,这是我见到的第一份。

在做agent产品、或者正琢磨怎么让agent进团队工作流的,直接去读docs/,按编号读一遍,一两个小时的事,比大部分二手解读都值。想跑起来的,SETUP.md是写给编码代理看的——你对自己的agent说一句"读这个仓库的SETUP.md,和我一起装dsh-superagent",它会一次问一个短问题、展示完整计划然后自动装。一个讲"少占注意力"的系统,连安装方式都贯彻了这条原则。