DeepSeek开源Super-agent：一个会话接活，多个Worker并行，p95少了近一半

DeepSeek开源了一个Super-agent原型，放在DeepSeek Harness仓库里。主推推文给的数据很直接：一个router会话跟人对话并分派工作，隔离worker并行处理GitHub事件任务。自测p95完成时间从29.5分钟降到15.7分钟，对比对象是单会话使用subagents。推文链接：https://x.com/kimmonismus/status/2116905923109089285

结构不复杂。router管全局上下文、判断优先级、分派任务、统一回复。worker在自己的会话和目录里干活，处理完在原始对话里回答，比如通过拉取请求。另有一个Watchdog独立监控异常、恢复和进度检查。有网友lifcc直接画了流程图，外部事件从GitHub Issue、PR、CI和飞书消息进来，router分给修Bug、审PR、跑测试的worker。下图就是。

有网友硅基练习生JAXX把旧架构和新架构放在一起对比：旧版是单会话、串行执行、本地依赖、单终端窗口、受限的人机循环；新版是多智能体协同、并行执行、云原生和自主守护。他在回复里把痛点落到人类注意力带宽：限制Agent生产力上限的，早就不只是模型智商，还有人类有限的注意力带宽。下图是双方架构对比。

另一张图来自网友ひげまる，讲的是router层和worker层分离的两层架构，兼顾连续性和并行处理。

DeepSeek Harness的长文在这里，引用推文在这里。但别急着把它当成官方产品。有网友Aditya Batra指出，README顶部写了这不是官方DeepSeek产品，也不是文章里的同一份代码。回复里还有人问，README说部分功能不在原型里，接下来先补哪块。这个提醒很重要。原型能跑通一套思路，不等于能直接搬进团队工作流。

评论区也没有被15.7分钟带跑。Jeff Bruchado说，两个隔离worker碰同一批文件，15.7分钟可能变成一下午的merge conflict。Abhi问，两个并行worker动同一个文件时谁来解冲突。Capslock问worker到底有多隔离，共享不共享状态。MartinOL补了一刀：p95接近减半很好看，但旁边还得放每任务token数，隔离worker各自重读repo，更快也可能账单更大。zeeshan问，worker卡在flaky test，router是重派还是等。这些问题，原型还没给答案。

DeepSeek这次试的是多Agent组织方式，编码模型强不强不是重点。一个会话接人，多个worker并行干活，router做调度，watchdog做监控。编排可能和模型智能一样重要。但自测p95只是自测，冲突处理、状态共享、token成本、失败重试，都是生产环境绕不过去的账。

先别急着把团队工作流搬上去。等原型把同一个文件撞车和成本账算清楚，再谈Super-agent能不能替团队省注意力。