DeepSeek 开源双层 Agent 原型:企业自研 Agent,先回答“谁指挥、谁干活”

双层到底是什么

一句话：Router 是总调度，不干执行；Worker 是执行者，不直接跟人说话。

Router 常驻在线，承接人的交互、维护全局上下文、把任务拆开发给 Worker，自己不动手。Worker 在隔离会话里并发执行，干完把结果交回 Router。官方的立论依据很直白：人一次只能跟进 3 到 5 个活跃会话，所以 Router 的存在意义就是把“人要盯的东西”压到最少——README 里的核心准则原文是 “take as little human attention as possible, and give as much value as possible”（尽量少占用人的注意力，尽量多交付价值）。默认工作模式叫 observe：只记录、不动手，主动干活要人先点头。

实测数据是这套设计最有说服力的部分：合成负载下，Super-agent 的 p50 是 12.4 分钟、p95 是 15.7 分钟，而单会话基线的 p95 是 29.5 分钟；触发速率从每分钟 1 条提到 40 条时，单个决定分摊的推理时间从 6.4 秒降到 1.6 秒。代价也写得很诚实：缓存读取的 token 是单会话的 2 到 4 倍，去掉“事件直通”后 token 消耗上升约 37%（23.23M 到 31.77M）。速度和并发，是拿真金白银的 token 换的。

企业自研 Agent，先抄这张分工表

取舍要说清楚。这套原型不解决“业务知识从哪来”，Router 再聪明，没有企业自己的流程文档和权限体系，它分派出去的任务就是空转。它也不承诺省钱——token 翻倍是明码标价。所以自研 Agent 的正确姿势是：先画分工图（谁指挥、谁干活、谁验收），再定权限边界（Worker 能碰什么系统、动什么数据），最后才谈模型选型。顺序反了，Agent 越多，乱得越快。

还有一个只有查了资料才知道的细节：这套东西上线约 1 天就在 GitHub 破了 4000 star，但 DeepSeek 官方口径始终是“研究原型”，连 Issues 都没开。热度不等于可用度，追热点的企业先分清“参考实现”和“生产工具”。

转型落点：自研 Agent 前，先开一次“分工会”

正在考虑自研 Agent 的企业，建议先不开工、开个会，回答三个问题：第一，谁当 Router——哪个岗位负责接需求、拆任务、验收结果，这个人必须懂业务，不能是纯技术岗；第二，Worker 的边界在哪——Agent 能读哪些系统、能改哪些数据、动多少钱以上的操作必须回 Router 请示，写成白纸黑字；第三，试运行期多长——默认 observe 模式跑多久、什么标准算“可以放手让它动手”。这三个问题答不上来，Agent 项目大概率会死在“没人敢用”和“没人敢管”之间。DeepSeek 的原型给的是技术答案，企业要补的是组织答案。