10月31日晚，DeepSeek 的 Harness 团队在官方渠道发布长文《Super-agent 设计探索：迈向更自主的 Agent 系统》，同步开源研究原型，官方披露的初步实验显示，其任务完成效率优于单 Session 方案。标题问的"差多少"，量化答案就在原文 7.1 节：同一份多任务合成负载下，Super-agent 任务完成时间的 p50 与 p95 分别为 12.4 分钟与 15.7 分钟，而主流单会话形态在最差情况下的尾部耗时接近它的两倍。 但先说清边界：省下来的时间发生在"调度层"，不代表 AI 写单个功能变快了。IT之家知乎
这个实验是一场调度赛，不是代码速度赛。DeepSeek 让约 300 条群聊与 CI 消息同时涌入系统，其中仅约 20 条是工作请求，每种方案重复跑 5 次，真正的编码工作被换成一个只消耗时间的工具——实验只考调度，不考执行。 单 Session 方案慢下来的方式很真实：不是模型不会干活，而是它不肯可靠地分工——中性提示下，5 次运行一次都没有调用 Subagent，所有工作挤在主会话里排队；换成提示优先委派，5 次里也只稳定委派了 4 次。对普通用户来说，瓶颈其实更早出现：一个人通常只能同时跟进 3 到 5 个活跃 Session，开三五个任务窗口来回切换的活儿，最终都摊回人身上。 双层架构要解决的正是这一点：Router 只对外接需求、派活，不亲自执行；Worker 在隔离上下文里只做自己订阅的那件事。"要不要分工"从提示词玄学变成了系统规定。知乎知乎
代价也被原文透明地写了：同时维护多个独立会话，Super-agent 单次实验的读缓存 token 高于单 Session，是用更多 token 换更短且更稳定的完成时间。 省的部分同样有数字：Router 压测中，需要决策的事件到达速率从约每分钟 1 条提到约 40 条时，平均 batch 大小从 1.0 升到 2.8，单次请求耗时仅从 2.5 秒增至 3.9 秒，摊到每个决定的推理时间反而从 6.4 秒降到 1.6 秒；而拿掉"订阅直通"后任务完成时间基本不变，Router 要做的决定却多出约 30%、总读缓存 token 增加约 37%。 换句话说，省下来的不是执行算力，是中枢的推理开销和人的注意力。知乎知乎
对干活效率更直接的答案，藏在真实运行案例里：团队内部的 Super-agent 实例，可以让同一个开发任务在 IM 和 GitHub 之间连续推进，群里出现 Bug 反馈时，没有人 @ 它，它也会自己定位根因并提交修复 PR。 动起来的机制是预先配置的"静默复现并修复"规则：先在后台试，确认问题、找到简单修复办法，再把结果交出来，没有可用结果就保持安静。 省掉的正是"人在几个会话页之间来回唤醒 AI、复制报错、解释上下文"的手工活——公开原型的 README 也把原则写得很直白：尽可能少占用人的注意力，尽可能多地提供价值。知乎知乎知乎
不过，"效率差一半"这个结论目前能信到什么程度？团队自己在原文里把话收得很严：实验基于合成负载与简化环境，部分设置还可以更加严谨，以下结果仅作为初步参考。 有拆解文章说得更直白：那组 12.4 分钟对 29.5 分钟的数据是方向性信号，不是成绩单。 开源的 dsh-superagent-prototype 也不是产品：仓库明确标注研究代码不能直接投产，公开版经过改造，文章讨论的一些设计尚未实现。知乎知乎知乎
社区的技术审视同样尖锐：Super-agent 把行动权开到最大，在投机执行设闸、PR 身份归属、接管粒度三个机制问题答完之前不能押注。 安全也是原文第 8.4 节自认的未解问题：云端 Agent 一旦被攻破，其连接的全部端侧设备都面临被控制的风险。知乎知乎
所以回到标题：对"同时开好几个 AI、人来回当调度器"的场景，效率差现在有硬数据——同为 p95 口径，15.7 分钟对 29.5 分钟，最差情况耗时约减一半，代价是更高的 token 账单；对"单个任务写得快不快"，原文压根没测，也轮不到别人替它下结论。真正值得盯的下一个信号很具体：这套架构走出合成负载后，能不能在真实仓库、真实需求和真实权限边界里，交出第二份长这样曲线的数据。
