这两天好几个自媒体都在转 DeepSeek Harness 团队的技术文章，说他们开源了一个原型，标题起得一个比一个猛，最常见的是“AI 开始指挥 AI 干活”，听着像又有新范式横空出世。我找来他们的官方原文仔细翻了一遍，感觉完全不是这么回事。
DeepSeek 这篇文章讲了很多具体的技术路线，但他们本质上还是在考虑怎么让 Agent 真正融入工作流。因为按照他们自己的观察，如果一个人同时跟进 3 到 5 个活跃 Session，很快就会碰到注意力瓶颈，哪个窗口聊到哪、推进到哪，人根本看不过来。所以单任务的上限看模型，但是多任务的上限就卡在人的注意力上。他们搭出来的这套 Super-agent，就是冲着这个瓶颈去的。
如果把这套架构拆开来看，我发现里面的构件几乎全是计算机系统里面用了几十年的老办法。他们先用程序规则把消息过滤一遍，如果规则处理不了，才会交给模型处理，这个走的就是 Fast Path 和 Slow Path。如果请求一下子变多，他们会先攒成一批，再一起推给模型，这个做的就是批处理。他们还把上下文当成缓存来用，高频的信息留在上下文里面做 Inline，大块的内容就移到外面做 Spill。而且他们做了存算分离，把计算和状态拆开，让执行环境留在原地，同时在外面放了一个 Watchdog 负责定时巡检。官方在文章结尾自己说没有提出全新理论，只是把计算机系统里面经典的工程思想搬进了 Agent 系统。
我觉得这篇文章真正有价值的地方，不在它有多新，而是在它有多旧。AI 时代来了，并不是要把以往的东西全盘摒弃，传统的核心理念依然非常重要。因为 Agent 要想真正在团队的工作流里扎下根，靠的是老工程的底子，但是只有验收这一件事，老办法照搬不了。
最值钱的老零件是解耦
把这些老经验放到 Agent 身上，我发现有些老原则比提示词更管用，而在这些老原则里面，最值钱的是解耦。
他们把 Super-agent 拆成了两层结构。上面的 Router 承担的是 PM 角色，它平时自己不干活，专门和人沟通，负责分派任务，甚至可以完全不给它装 Bash。底下的 Worker 都在各自独立的环境里面隔离干活，等任务跑完以后，它们会把结果汇报给 Router，再由 Router 统一汇报给人。这样一来，人就不用一直守在各个窗口前面，而是上移到决策和验收。
为什么要从结构上拆开，而不是在提示词里叮嘱一句“请把任务分派出去”？因为他们专门做过一组对比实验，数据就摆在那儿。一边是给单 Session 挂上 Subagent 工具，完全让模型自己判断要不要分派任务，另一边是 Super-agent。如果用中性提示词，模型连续跑了 5 次，结果 5 次里面是 0 委派，全都在主 Session 里面自己硬扛。因为中间只要有新消息进来，模型就会被打断，所以最后 p95 拖到了 29.5 分钟。但是如果换成“优先委派”的提示词，模型在 5 次里面有 4 次委派了，可是剩下那 1 次它觉得任务很小，还是自己下场干，结果依然拖出了一条长尾。而 Super-agent 的 p95 只要 15.7 分钟。
如果只是靠提示词管模型的行为，很多时候是靠不住的。因为 Router 手里根本没有执行工具，它除了分派任务什么都干不了，所以从结构上就把边界锁死了。平时带团队其实也是同一个道理，如果和一个技术骨干说，你现在升组长了，以后多看全局少写代码，他手一痒还是会自己上。所以真正管用的办法是做好岗位设计，把职责彻底划开，让这个岗位从一开始就不碰代码。
前两天跟团队开会，我也专门强调过这一点：传统工程时代很好的架构理念，在 Agent 时代同样应该遵守，比如解耦。一个 Agent 最简洁的方式，是把 tools、skills 分层摆好，供模型快速感知信息；而不是把很多东西揉在一起、高度耦合变成一个垂直化工具，导致大模型在思考时无法根据实际任务情况快速调用。我八月写《DeepSeek Harness 真正开源的不是代码，是替换权》的时候，聊的是怎么把稳定的接口和能换的组件拆清楚；现在看 Super-agent，是顺着同一套底座继续往前走，把解耦从底层的组件切分，直接推到了 Agent 的协作分工上。
唯独验收照搬不了
但是老工程的经验也不是样样都能照搬。以往那一套工程办法虽然管用，但是至少在验收这一环上，如果直接放到 Agent 身上，就行不通了。
这也是我前两天在会上跟团队聊的另一点：传统的工程时代和 Agent 时代有明显不同的地方。过往功能开发完毕，测一下跑通就 OK 了；但在 AI 时代更多要靠评测。因为跑通都能跑通，但受限于 AI 的幻觉、上下文处理等各方面，功能层面的跑通并不意味着真正跑通。
有意思的是，DeepSeek 这套满是老办法的方案里面，唯一真正换了思路的地方就在这里。他们在讲 Watchdog 的时候提到，如果要监控一个 Agent 系统，光靠传统的进程存活检查或者运维脚本是不够的。因为很多异常根本不是进程崩溃，而是模型陷入了无效循环，或者偏离了目标。这时候进程还好好活着，接口返回 200，日志也很干净，但是它要么在原地打转，要么早就去干别的事情了。所以他们的 Watchdog 本身也是一个 Agent，由模型去判断 Worker 到底有没有实质进展，方向到底有没有偏。
老系统看挂没挂，Agent 看偏没偏。如果验收 Agent 的时候还在用老一套标准，觉得跑通一次就算过，那不管外围架构搭得多漂亮，最后得到的也只是一个跑得很顺畅、但是不知道自己在干什么的系统。
如果拿这个标准看 DeepSeek 自己的实验，其实也是一样的道理。他们在文章里面讲得很实在，测试跑的是合成负载和简化环境，编码工作也只是用一个只消耗时间的工具来模拟，所以这些实验数据只能当成初步参考。而且在他们开源的代码仓库里面，dsh-superagent-prototype 的 README 第一句就写明了，它只是一个研究原型，不是 DeepSeek 的正式产品，和他们内部的版本，包括文章里写的设计，都不完全一样。现在架构思路理顺了，原型也跑通了，但是如果放到真实复杂的开发业务里面到底能不能扛住，最终还是要靠评测。
架构会趋同，差距在老功夫
我觉得这件事要认真看一看，因为它不只是 DeepSeek 一家的路线。
上周我在《Personal Agent 把门槛包圆了，却包不住国内的围墙》里面写过，现在行业里有好几家公司，几乎在同一个时间段走向了同一种形态，就是给每个人配一个常驻在线的个人助理。Super-agent 本质上就是 Personal Agent 里面一个很重要的架构。它常驻在后台，靠事件驱动来分发多个任务，而人只要负责做决策和验收。这种模式不仅适合个人助理，如果放到软件工程和团队协作里面，也完全是同一套解法。所以我很赞同 DeepSeek 在文章里面说的一句话，“相似的设计约束会导出相似的架构选择”。不管是国内还是海外，大家都在纷纷瞄准这个方向。
当大家的架构逐渐趋同、架子搭得都差不多的时候，再去争谁先提出这个概念其实就没有什么意义了。真正能把团队差距拉开的，到头来还是两样很笨、也很花时间的老功夫。一个是调度、隔离和解耦这些老工程扎不扎实，另一个是验收那一关有没有老老实实换成评测。
所以回到开头那个标题，我的判断是，不是 AI 在指挥 AI，是老工程在管着 AI。模型负责往前跑，老工程负责让它跑在路上，而评测负责确认它跑的方向对不对。