作者：Raynaaa（Echoverse回响宇宙）

10 月 31 日晚，DeepSeek Harness 团队发了一篇长文《Super-agent 设计探索》，同时在 GitHub 开源了配套原型。说白了，这是一个常驻在 GitHub 仓库和飞书群里的 Coding Agent：有人提需求，它自己开工单、干活、提 PR，再回到原来的对话里交差。

看到 Super-agent 这个名字时，我其实没有特别兴奋。Agent 的名字越来越大，用法却没怎么变：给它一个任务，它执行，做完再等下一个。

但文章里的一个例子让我停了下来。DeepSeek 内部有个产品用户群，有人抱怨 macOS 桌面端的一个毛病，说自己每天要误触几十次。群里没人 @ Super-agent，它自己在后台复现、查到根因，修好提了 PR。

这篇文章没把重点放在模型能做多复杂的任务上，而是想回答一个更基础的问题：

如果 AI 已经越来越能独立干活，为什么人还要花那么多时间管它？

我的判断是：Agent 接下来的瓶颈，可能已经不在模型，而在人的注意力，以及把模型组织起来干活的那套系统。这会一路影响到 AI 产品的入口、证明价值的方式，以及 Agent 公司之间到底比什么。

01｜AI 越能干，人反而越忙了？

现在的 Coding Agent 已经很强了，从读项目到提交 Pull Request，一次任务里都能做完。但如果同时开五个 Agent，分别开发功能、修 Bug、分析数据、研究竞品、整理文档，问题就来了。理论上，手里有五个能并行干活的助手；实际上，人一直在五个窗口之间切换，查进度、补上下文、确认操作、处理异常。

AI 确实干了更多活，但人也成了五个 AI 的项目经理。

DeepSeek 在文章里给了一个数：根据团队观察，一个人通常只能同时跟进 3 到 5 个活跃会话。

这个数不是严格的科学上限，但它点出了一个很现实的瓶颈：单任务的上限看模型，多任务的上限看人的注意力。

我觉得这是现在很多 Agent 产品被低估的成本。我们经常算 AI 省了多少执行时间，却很少算用 AI 本身要花多少管理时间。如果一个 Agent 帮人省了两个小时，却要人每十分钟看一次状态、补一次指令，它创造的实际价值就没有想象中那么高。

那 DeepSeek 打算怎么把人从调度员的位置上换下来？

02｜每一层设计，都在替人省一种注意力

DeepSeek 这次没有训练一个更强的模型，而是重新设计了 Agent 的运行方式。我把它拆成五层，每一层都对应着人原本要花的一种注意力。

第一层，Trigger 和 Eval：不用人去叫它，也不用人帮它筛消息。

普通 Agent 从一条 Prompt 开始，Super-agent 的输入则是事件（Trigger）：群聊消息、GitHub 评论、CI 测试结果都算。中间有一道 Eval：先用程序规则筛一遍，再让模型判断值不值得做，值得做才开一张工单（Ticket）。在 DeepSeek 的模拟测试里，每轮约 300 条消息只有约 20 条是真正的工作请求，九成以上要挡在门外。

第二层，Router 和 Worker：不用人在窗口之间切换、干等结果。

Router 是常驻的调度员，只负责跟人说话、派活、收结果；Worker 是一个个独立干活的 Agent，配最强的模型。Router 派完活就去处理别的消息，不用等。开源代码里还有一个 WorkerSlots，限制同时跑多少个 Worker。

第三层，会话隔离：不用人反复交代背景。

每个 Worker 围绕一个任务建自己的会话和工作目录。多任务管理从“一个越来越长的 Prompt”，变成了“几个独立的任务和它们各自的状态”。

第四层，持久化：中断之后不用重新解释任务。

开源版用一个 SQLite 数据库存下事件、工单、决策和执行进度，Worker 中途断了，重启后按工单状态接着做。

模型负责思考和执行，系统负责记住工作进行到了哪里。

第五层，Watchdog：不用人隔一会儿去看一眼。

设计文章里的 Watchdog 是一个单独的会话，定时检查每个 Worker 有没有实质进展。开源原型里我没找到这样一个会话，只有临时故障自动重试、重启后恢复这类基础处理。DeepSeek 也写明了，开源代码和内部版本不一样。

这些办法单看都不新。那它到底新在哪？

03｜并行靠架构，不靠模型自觉

很多人会觉得，这不就是给 Agent 套了个工单系统？GitHub 的 Copilot 早就能把 issue 直接指派给 AI，让它在后台提 PR 了。区别在于谁来当调度员。用 Copilot，还是人决定哪个 issue 交给 AI、什么时候交；Super-agent 想把调度员这个位置也交给系统。

DeepSeek 的测试正好说明，这一步为什么得靠架构。测试用的就是前面那个模拟环境，拿 Super-agent 和“单个会话 + 派子任务的工具”对比，后者又分中性提示词和鼓励派活两种。每种方案跑 5 轮，写代码的步骤换成了只耗时间的模拟工具，所以测的是调度，不是代码质量。

结果是，Super-agent 一半的任务在 12.4 分钟内完成，95% 在 15.7 分钟内完成；单会话、中性提示词的方案，95% 的任务要 29.5 分钟，慢了差不多一倍。更有意思的是，这个单会话方案跑了 5 次，一次都没把活分出去；换成鼓励派活的提示词，5 次里仍有 1 次模型觉得活不大，自己干了。

能不能并行，不能指望模型自觉，得写进架构。

也要说清楚，这个测试没测人花了多少注意力。PR 照样要有人审，派错的活照样要有人纠正，到底省下多少，得等真实环境的数据。

调度交给了系统，人还需要一直守着聊天框吗？

04｜产品层：为什么 Agent 的入口可能不再是聊天框？

过去几年，聊天几乎成了 AI 产品的默认入口。很多产品已经有了 Agent 能力，用法还是输入 Prompt、等待执行、接收结果。可一旦 Agent 能自己听事件、派活、记住进度，人就不必每次都从聊天框把它叫醒。

比如一个产品增长 Agent，接入了业务数据、知道要盯哪些指标，某个渠道的转化突然掉了，它自己启动分析、定位异常，再把真正需要人判断的问题交出来。（这是我推想的产品形态，不是 DeepSeek 原型已有的功能。）这时产品的主界面更像一个工作台，上面列着哪些任务在跑、哪些做完了、哪些等人拍板。DeepSeek 的原型里已经有这个雏形：一个网页面板，只显示需要人处理的事。

但入口从“人去找 AI”变成“AI 来找人”以后，新的风险是它太爱找人。一个每天主动推三十条建议的 Agent，人大概只会觉得烦。做运维的人对此不陌生：告警一多，大家就开始无视告警。

DeepSeek 在设计原则里，第一条就是尽可能少占用人的注意力，尽可能多给出价值。

原型的默认设置也相当克制：没人 @ 它的消息默认收不到；就算让它接收群里所有消息，也只记一笔“本来会接”，不动手；想让它像开头那样悄悄修 bug，得切到自动模式，再自己写规则。它在群里的回复也不超过 100 个词。

好的 Agent 不是每天主动做一百件事，而是能判断哪三件值得做、哪一件必须让人拍板、什么时候该闭嘴。

DeepSeek 自己也承认这一步还没想清楚：设计文章列的四个待解决问题里，有一个就是：人看不到一个个会话窗口以后，该怎么跟 Agent 协作。

可用户如果不再天天打开产品，AI 公司又怎么证明自己有用？

05｜商业层：用户不用天天打开，AI 公司怎么证明价值？

AI 产品最爱讲日活、会话数和使用时长。对常驻型的 Agent，这些指标可能会失灵，甚至要反着读：用户天天打开、聊很久的 Agent，也可能只是难管。

用量也会骗人。DeepSeek 的一次测试里，Super-agent 读了约 2,323 万缓存 token，单会话方案只读了约 605 万，差不多 3.8 倍。按用量看，它是更费的那个；可缓存读取本来就便宜：测试没说用的是哪个模型，按 DeepSeek 自家 Flash 模型重复读缓存的价格（每百万 token 0.02 到 0.04 元）算，多读的 1,700 多万 token 也就几毛钱（这只是缓存一项的差价，不是全部成本），换来的是任务能并行。

token 越来越便宜，人的注意力不会。

所以衡量这类 Agent，我觉得得换一套指标：每项任务人要介入几次；不需要人干预就做完的任务占多少；人每监督一小时，对应多少有效的工作产出。这几个不是 DeepSeek 验证过的，是我想提的评价框架。

但只盯“少介入”是危险的，还得配一个反向指标：它主动做错了多少，人花了多少时间纠错。Agent 不再等人下指令以后，它主动做错了，算谁的？

传统 Agent 犯错，至少还有一条人写的指令当起点。Super-agent 自己听消息、自己判断哪件事值得做、自己排优先级再派给 Worker，错误可能在执行之前就发生了；Worker 又是并行的，一个错误判断可能同时变成好几项错误执行。DeepSeek 的做法是按影响大小决定停在哪，涉及设计决策的改动就停下来问人。这能缩小出错的范围，但出了错算谁的，最后还得写进授权边界里。

收费方式也会跟着变。客服软件公司 Intercom（今年已改名 Fin）的 AI 客服，按不同类型的有效结果收费：解决一个问题，或者按客户事先配好的流程（比如退款）办完再交给人，各收 0.99 美元；帮销售筛出一条合格线索，收 9.99 美元；它自己答不了、转给人工的，不收钱。它收钱看的是做成了什么，跟聊了多少次无关。当然，很多工作说不清结果算谁的，这种收法不会适用于所有 Agent。

那么，当大家都在用差不多的模型，Agent 公司之间最后比什么？

06｜竞争层：模型能力趋同之后，Agent 公司的壁垒在哪？

如果 Agent 的可靠性越来越取决于系统设计，竞争就多了一个维度：除了比谁的模型更聪明，还要比谁能把模型组织成一个可靠的工作系统。模型当然还重要，但模型能力和系统能力，可能正在变成两个相对独立的竞争维度。

但我不认为架构本身会是壁垒。DeepSeek 自己就用 MIT 协议把这套原型开源了，用的又都是事件、队列、持久化这些传统软件的办法，谁都能抄。做这一层的也不只是没有模型的公司，DeepSeek 自己、GitHub 都在做。

我觉得难抄的是两样东西。一是 Router 的判断力：什么事值得做、什么时候该打扰人，没有标准答案，只能在真实团队里一次次被纠错之后调出来，而这些纠错记录不会跟着代码一起开源。这对创业公司不算好消息，纠错记录最多的往往是部署量最大的大厂；小公司的机会，可能在于先在一个窄场景里攒下这份判断力。二是授权：Agent 要接进客户的群聊、代码仓库和本地设备，客户愿意交出多大的权限，取决于它过去犯错少不少、出了错说不说得清。DeepSeek 自己也把安全列为待解决的问题：云端的 Agent 一旦被攻破，所有连着它的机器都有风险。

所以我会提一个假设：

未来优秀的 Agent 公司，未必是拥有最强模型的公司，而是最擅长把模型变成可靠的工作系统、让人少操心，又能让客户放心交出权限的公司。