DeepSeek 又掀桌子：3.7 万行 Agent 代码直接摊开，默认只敢开 3 个并发

10 月 31 日晚上 20:05，DeepSeek 往 GitHub 推了个仓库。24 分钟后，公众号才发出那篇《Super-agent 设计探索》。

朋友圈已经在说"又掀桌子"了。掀是真的：三万七千行、一个提交、零删除。设计文章还没发，能跑的代码先上线——先有东西，再有说法。

但掀开之后露出来的，跟正在转的那版说法不太一样。所有人都在说它多任务并行、能同时推进几十件事，可这套代码里默认只开 3 个。

我把它 clone 下来数了一遍。截至 11 月 1 日 20:45，仓库 5379 星、509 fork，216 个文件，一个提交，+37068 / -0⁠。

本文目录

• 一、先把事实摆齐
• 二、37068 行是怎么构成的
• 三、它要解决的那个问题
• 四、五个模块里，只有两个真新
• 五、那组实验数字在说什么
• 六、读代码才知道的四个默认值
• 七、438 行提示词才是真正的制度
• 八、它不是什么
• 九、想试的话
• 十、最后

一、先把事实摆齐

三个细节。

建仓到提交隔了 2 小时 33 分。不是边写边推，是攒完一次放出来，-0 行删除也是这个意思。

运行时依赖只有两个。zod 校验参数，proper-lockfile 做进程互斥，数据库直接用 Node 内置的 node:sqlite⁠。没有 express，没有 redis，剩下 36 个包全是开发依赖。

Issues 是关的。跟 DSH 主仓库一样，这里不收 bug。

二、37068 行是怎么构成的

测试 14960 行，源码 15587 行，比值 0.96。

把 3302 行锁文件刨掉，人写的部分是 33766 行，其中 44% 是测试。四个最大的测试文件——runtime.spec.ts 1796 行、core-engine.spec.ts 1621 行、sources.spec.ts 1407 行、runtime-concurrency.spec.ts 943 行，加起来 5767 行，占全部测试的 38.5%，几乎都压在并发和状态上。

"3.7 万行"如果按"团队当天手写"来读确实吓人，按"公开了一个敢让人跑的仓库"来读才正常。测什么说明怕什么：并发把状态搞乱，比模型答错更让他们紧张。

三、它要解决的那个问题

官方说得很直接：一个人通常只能同时跟进 3 到 5 个活跃 Session。

所以瓶颈不在模型。单任务的上限看模型，多任务的上限看人的注意力。

文章里我最认同的一句：

让用户手动管理 Session，在很大程度上是从底层 LLM API 延续下来的设计惯性；Session 应当是系统的实现细节，而不应是用户的认知负担。

现在的产品形态，一堆侧边栏会话、一堆标签页，本质就是把 API 的 session_id 搬到了界面上。这篇文章的立场是：那是实现细节，不该让人拿注意力去付账。

四、五个模块里，只有两个真新

官方列了五个：双层架构、事件驱动、面向人的交互、存算分离、Watchdog。

双层架构不新。Router 派活、Worker 干活，就是调度器加执行器，操作系统课第一章。Agent Team 也是这个形状，区别在负载：Agent Team 的主会话要理解任务细节、高频协调，推理负担很重；这里的 Router 工具集小一圈，只处理任务之间的关系。

存算分离和 Watchdog 也不新：前者是 Web 后端二十年的默认做法，后者是分布式系统的外部控制回路。

有意思的是两个地方。

一是订阅直通。一个 PR 下面的后续评论，不再回 Router 排队，直接送到订阅了这条 Thread 的 Worker，Router 只负责新任务的冷启动和跨任务协调。算不上架构创新，更像把一个全局节点的流量砍掉一半。消融实验里去掉直通，完成时间几乎没变，但 Router 要做的决定多了 30%，读缓存 token 从 2323 万涨到 3177 万，涨了 37%。也就是说直通不提升质量，只省钱、省延迟。

二是授权模型。媒体报道基本没提，它才是这套东西能不能进团队的关键。每个请求变成一张工单，每张工单带一份不可变的授权，记着凭什么能做、范围到哪、依据哪一版策略（代码里是 mandate-v3）。授权是按一件事发的，不是按一个 Agent 发的。

团队真正怕的不是 Agent 干不完活，是它干了不该干的事。

五、那组实验数字在说什么

实验是合成的：一次跑约 300 条消息，其中约 20 条是真活儿，其余是闲聊、跟进、叫停和 CI 消息。工作本身用一个"只消耗时间"的工具代替。每个方案跑 5 次。

第一次看这组数，我以为是"架构赢了两倍"。读了说明才知道不是这么回事。

中性提示下，模型 5 次里一次都没委派，全在主会话里干，不断被新消息打断，p95 飙到 29.5 分钟。换成"优先委派"之后，5 次里有 4 次委派了，剩 1 次它自己判断"这活儿很小"，亲自上手，形成一条长尾。

所以这不是架构比提示词强，是把判断从模型手里拿走了。

"这条消息该不该开新活"，交给人写规则、交给程序做准入，比让模型临场判断稳。同理"我该不该自己干"也不该由它那一刻决定——Worker 只能看见自己订阅的 Thread，想多管闲事也没有消息进来。

这个思路值得抄，哪怕你根本不跑它的代码。

六、读代码才知道的四个默认值

① Router 主会话被禁止 sleep⁠。

src/app/sessions.ts 里有个 noWait 守卫，用正则抓命令位置上的 sleep——开头，或者 ;&|({! 反引号 换行之后，或者 do、then、while 这类关键字之后。抓到就拒，回一句：报告、跟进、新候选和后台结果自己会作为消息到来，别把这一轮耗在等待上。

理由很硬。Router 是全局序点，它一堵，后面的全堵在队头。

② 命令超过 5 秒，必须走后台。

同一个文件里，Router 把 shell 等待压到 5 秒，job_output 也压到 5 秒。standard 预设下这两个默认值分别是 60 秒和 30 秒，超过 30 秒的 timeoutMs 会被直接拒掉。

③ 人的追问有一条单独通道。

reserve(ticketId, by: 'launch' | 'wake' | 'person')⁠，第三种 person 就是人插话用的。任务排得再多，正在等结果的人也得插得进去。

④ 默认值极保守。

eval.mode 默认 observe（只看不干），maxWorkers 默认 3，评估超时 120 秒。

三个 Worker。不是三十个。

七、438 行提示词才是真正的制度

prompts/ 15 个文件、438 行。不是人设，是行为守则，语气接近法条：

• 不许扩需求。「Do not expand a request's scope, add implementation plans, acceptance criteria or policy checklists: workers derive requirements from the original source.」
• 接活先回执。要带原 trigger_id 调 orchestrator_ack⁠，回一句针对这件事的具体确认，模板就长这样："收到：把设置页那个"保存更改"按钮改成"保存"。"
• 100 词是硬上限。「100 words is a hard ceiling, not a writing target.」超了传输层直接拒发，还堵住绕过去的路子：不许长复句、分号串、bullet list、连发多条。
• 没有请求的进展汇报，永远不授权打扰人。「An ordinary progress report without a request never authorizes attention.」

最后一条我读到的时候停了一下。大多数 Agent 产品的默认行为是做了什么就汇报什么，这套反过来：汇报是内政，找人要授权。

八、它不是什么

不把这几条说清楚，容易被标题带跑：

1. 不是产品。README 第一行就写着「Research prototype for reference only, not an official DeepSeek product.」
2. 不是文章里那套完整方案。公开版经过改写，和内部版本、和文章描述都不一致，文章里有些设计只是"未来方向"，原型里没有。
3. 不是团队级助理。它绑定一个 GitHub 仓库，可选接飞书。不是多仓库编排器，也不是桌面控制器。
4. 不是安全沙箱。两个预设都以 danger-full-access 跑在操作者的系统用户下，默认不弹审批，Worker 能按路径执行程序，也能读你的 home 目录。文档自己写得很直白：这些包装"establish defaults, not a security boundary"。它给的建议是用一个只放 Agent 凭据的专用系统账号——那是隔离建议，不是它做的隔离。
5. 不是"AI 自己写完了自己"。相当一部分工程活确实由 coding agent 完成，这是团队自己说的；但那不等于零人工，也不等于当天手写 3.7 万行。

还有一条官方也承认的软肋：云端 Agent Loop 一旦被提示词注入攻破，它连着的所有端侧设备都有被控制的风险；就算云端没事，凭据进了上下文就可能泄。让 Agent 不接触凭据却能用凭据，这件事现在还没有答案。

九、想试的话

1. 别照着文档自己配。README 让你直接对编码 Agent 说：读 SETUP.md⁠，带我装。它会一次问一个问题，最后把整套计划给你过一遍再动手。
2. 用专用 GitHub 账号，别用主账号。
3. 拿一个不重要的仓库先试，别一上来就接主力项目。
4. 先用 observe 模式跑一周。它会记下"本来会接哪些活"但不执行。看完这份清单，再决定要不要开 auto⁠。

这个顺序——先看它想干什么，再决定让它干什么——比任何提示词技巧都值得学。换个 Agent 也一样，先让它只输出判断，观察几天，再放手。

十、最后

读完那 438 行提示词，我关掉编辑器坐了会儿。

我们平时聊 Agent，聊的都是模型会不会、准不准、快不快。这套东西让我想到的是另一件事：当模型的判断"差不多够用"之后，决定一个系统好不好使的，是它被允许做什么、被允许说多少话。"100 词是硬上限"第一次看觉得苛刻，后来想想，我在群里被两三个 AI 同时刷屏时最想要的就是这一条。还有那句"没有请求的进展汇报，永远不授权打扰人"——这话其实是在说我，写东西经常把过程铺得满满当当，读者要的只是结论。

所以这篇给我最大的触动不是 Router 和 Worker。是我自己在想：如果真给我一个常驻 Agent，我能不能像这份 prompts 一样，把"什么算干完了""什么时候该来找我"写清楚？写不清楚，给它再强的模型，也只是多一个需要我盯着的窗口。

安全那节我还是不太安心。端侧 daemon、长期在线、本机凭据，这三样凑一起，风险面和收益面差不多大，而文章给的是"开放问题"，不是"解决方案"。我暂时不敢把它挂在那台装满密钥的开发机上。

至于"掀桌子"——掀掉的是"Agent 得先有平台、有界面、有云"这个默认假设。它没掀"人得管着机器"这条，反而把这条一寸一寸写进了代码：默认只看不干，默认三个并发，默认一百词封顶。这也是我看完不慌的原因。它把 Session 从产品概念降级成实现细节，这一步走对了；但要让这东西真进团队，最难的不是并发，是信任。

互动问题⁠：如果你要给自己接一个这样的常驻 Agent，第一件交给它的事会是什么？我的答案是"每天把群里和仓库里没人认领的问题整理成一张待办"——只调查、不动手，先看它判断得准不准。