早上九点，五个终端窗口同时亮着。
一个 Agent 在等接口权限，一个卡在跑不完的测试里，第三个刚发现，它要改的模块正被第一个改着。群里又弹出一条补充说明，你得先分辨这句话该转给谁。
模型没出错，五个都能干活。忙不过来的是人。
DeepSeek Harness 团队把这个现象说得很直白：一个人同时能盯住的活跃会话，大概三到五个。再往上加，瓶颈就从模型转移到人身上。36氪微博
10 月 31 日晚，他们发了篇《Super-agent 设计探索》，把思路和原型一起开源。解法不是让一个 Agent 同时干五件事，而是把“维持全局”和“动手执行”拆开。36氪知乎
Router 负责接待、记背景、派活。按设计，它不碰具体执行；提示词里写得很死，不许看代码、日志和技术讨论，也不许替 Worker 解决阻塞。知乎
Worker 拿到完整工具，在独立上下文里干活，只向 Router 汇报，不直接找人。
派活的不干活，干活的不说话。
他们把人的注意力当成了预算。官方原型的第一条原则，是占用尽量少的人类注意力，提供尽量多的价值。一条通知、一个设置项、一个面板按钮，都得证明自己值这份注意力。知乎36氪
实现上，群里的大部分消息先用确定性规则筛掉：频道、发件人、来源范围，连模型都不调用。
剩下的才交给模型判断，这是吐槽，还是真有事。
同一话题的后续消息直接送到对应的 Worker，不再经过 Router。公开的消融数据里，仅这一个设计就省下了约 30% 的决策次数和 37% 的读缓存 Token。知乎
于是有了那个被反复引用的场景。群里有人报 Bug，没人 @ 它，它自己复现、修好，带着前后对比截图提了 PR。复现不了，就全程安静。微博36氪
这套设计最不寻常的地方，是它不把“会话”当产品。Session 是早期大模型 API 留下的习惯，用户要管的是任务，不是窗口。36氪
所以原型里，工作项有自己的状态，授权在接单时就被固定成一份不可更改的 Mandate；新消息可以进来当上下文，但不能顺带扩大权限。知乎知乎专栏
数据也有，但要看清边界。公开实验用了约 300 条消息，混着 20 个左右的工作请求。知乎
单会话配强委派提示词，p95 是 29.5 分钟；两层架构 p50 12.4 分钟，p95 15.7 分钟。知乎微博
注意，实验把真实编码换成了只消耗时间的工具，测的是调度，不是模型写代码的能力。知乎
代价也摆在那儿。多 Session 设计会带来更多 token 消耗。36氪
公开的只是研究原型，不是官方产品，部分设计还没实现。36氪
Worker 以操作者的系统用户身份执行命令，目录和命令包装不构成安全隔离。知乎
所以，它没解决最后一关：验收。假设 Agent 一小时交 20 个 PR，每个仍要人花 4 分钟看，一小时就是 80 分钟的评审量。窗口少了，评审量没少。知乎
我更愿意把它看成一次“把协调成本从人身上挪走”的尝试，而不是“AI 管 AI”的新物种。
它值不值得学，不看发了多少消息、提了多少 PR，而看每份被人接受的结果，到底省下了多少人的分钟。
下一代 Agent 的竞争，可能不在谁更会干活。会干活已经不稀奇，知道什么时候不叫人，才稀奇。
