DeepSeek Harness 在10月31日发布了一个工程实践架构 Super-agent。看了一下感觉挺有意思的。
在现在Vibe Coding的场景下，人的作用更多在于定义和决策(定义问题+提出问题)，就是给定目标、给定背景、给定约束限制、给定验收标准，并且在任务执行中不断地根据结果进行判断和决策。 做任务一般也就是开个Session会话对应某个特定任务，然后开始进行前面内容。
一个人处理多个Session会话的模型任务数量是有限的，原文中提到的单人处理不同Session会话也就是3~5个，我个人的经历也符合这个统计，开多了Session会话，就真的感觉脑子跟不过来了，个人的精力是有上限的，不可能管理太多，人类自身确实是无法做到多任务的快速切换。
所以单任务的上限是模型能力决定，而多任务的上限是人的注意力决定。实际是人的注意力和模型能力共同决定，但人的注意力太狭窄从而是瓶颈。
DeepSeek Harness提出的 Super-agent 就是针对这种多任务并行场景，抛开所有的技术细节，只看它整体的方案思路。 它构建了2层模型，一层是单个的Router模型，位于上层，一层是执行任务的多个Worker模型，位于下层执行任务。而 DeepSeek Harness 把这个命名为"Super-agent"，并不意指能力"Super"，而是实指位于上层(super)的agent，指的是它的架构分层。
而它和这之前大家一直说的 Multi-Agent 的核心区别在于进行了 显式分层 + 职责分离 + 统一用户入口 + 让用户不感知底层多会话并行，并把它做成可落地原型。
其中 Router模型 和 Worker模型 的完全职责分离，其核心设计思想是让用户不感知底层的多会话(多任务)并行管理。 而把人从多会话切换里捞出来，是 Deepseek harness 给出的产品化思路。
图源官方，双层架构：Router 层统一负责路由与对外交互，多个 Worker Session 隔离并发执行任务
这其中的上层 Router 模型完全不做任何具体执行相关的工作，它做任务的分解分发、决策、汇总、协调、指挥这一类工作，而 Worker 模型负责具体的执行任务。
官方原文说到“各个 Worker 彼此上下文隔离……Worker 不会直接与人类交互……而是向 Router 层汇报状态、由 Router 层统一向用户回复……在多任务并发执行时，各个 Worker 独立推进任务。…… 在执行复杂单任务时，Worker 内部可以再创建 Subagent，也可以本身就是一个 Agent Team，这些对上层的 Router 层保持透明”。
官方给的图也是链接了即时通讯软件和GitHub，意思就是部署之后，Super-agent自动监听群里的内容，发现有价值需要做的任务(如优化/修改界面)并决策分发给底层模型（或由用户主动触发让Super-agent处理），由底层模型执行，并返回最终 Pull Request 合并入 GitHub。
图源官方，同一个任务在 IM 群聊与 GitHub Pull Request 评审之间连续推进
官方认为自己的Super-agent是“工程实践的架构思路”，所谓工程实践，就是一种取舍(trade-off)的艺术，本质是受限条件下的权衡，在不可都得的情况下，如何进行优化，使得整体效益尽量更好。
所以 Super-agent 里的上下文context的链式召回(分层级联并调用)、外部独立的Watchdog会话做监控与自愈都是取舍下的实践结果、技术细节。这些在我这里就不过多描述了，对技术细节感兴趣可阅读原文。
另外提一句，DeepSeek Harness团队的文章中认为后续模型更进一步发展后，人类和模型交互不应该以直接的Session会话中进行为主，这也体现在了Super-agent分层架构且用户不感知底层Session进行的程度。
我之前听播客也听到了这个观点，说“强大的模型和人类之间的交互还是通过语言或文字，感觉还是比较蠢，但是确实没想到更好的方式”。 这确实是一种有意思的观点，待大家更多讨论。
另外很有意思值得提的点是，Super-agent 里的两层模型的能力是不同的，针对上层的 Router 模型对应配置“使用较轻量的模型往往就能兼顾速度与效果”，因为上层的推理负担较轻，而对于底层实际执行干活的 Worker 模型则对应“通常需要配置能力最强的模型”。
但这个引出了另一派观点是，上层做决策的反而模型能力弱于底层，可能导致上层的误判会被下层执行时放大。 以及长程任务漂移和完成率低，但话说只要是长程任务，更强的模型也可能只是缓解，也不好处理。
上层弱、下层强，省的是钱和延迟，赌的是调度不犯错。
可能分层模型的能力设置结论是DeepSeek Harness 经过实践探索在适用于某些场景任务下的较优解。
这个 Super-agent 在我看来不适合重型的生产开发任务，因为重型生产开发任务，大多是聚焦的，更重要的是需要人去不断跟进和决策结果，还是适合几个轻量的并行任务，相同或不同上下文的轻量任务，如运维、不需要复杂的开发任务、验证任务等，官方的样例是接入聊天群，群里的关键词触发(界面配色等内容)，就适合用 Super-agent 去跟进多个并行任务。
我为什么说感觉这个 Super-agent 挺有意思的，首先这提供了一种适用于某些场景下的一个可实践的解，有解总比没解好。 这个思路并非第一次有，但是 Super-agent 把这个思路推到了可落地的实践层面上。
在我脑子里，我会把这个认为是针对某些场景任务的设计，是个“工程优化自然总结出的优秀实践”，给我的感觉有点像软件开发下的某个模式，会有适用的某些场景。
我会更倾向于认为“一个很好的设计”是会长久存在的，如clean code里提到的准则，这些即使在现在AI自己写代码时，也是适用的。当然，遵守与否是另一回事了。
后续模型能力提升，必然会冲击到这个设计，LLM模型能力越强，一定是让活变得越来越容易完成，但我也不相信能短期内完全冲掉，因为它还是有适用场景的。另外，事务是螺旋上升的，期待后续实际发展情况。
回到我前面提到这个 Super-agent 很有意思，更深层的点是，这个架构很能类比到人类自身，这种分层设计，上层还只做“决策、汇总、分发、协调、指挥”，下层做具体的执行，这是不是很能让打工人代入，拳头都握紧了。
之前大家说的 Multi-Agent，可以类比于技术架构师带着多个不同岗位员工干活，架构师模型自身还是做了很多工作，而这个 Super-agent 就有点像是产品经理或项目经理带着多个不同岗位员工干活的感觉，Router 不写代码，但决定谁写、谁先写、写完怎么汇报。
太像公司里的层级结构了，更别提在 Super-agent 官方设计里，上层 Router 模型的能力是不如下层 Worker 模型的，像个能力不如下属却总在老板面前露脸的中间层，Router中文什么意思，“路由中转”啊，放个鹦鹉都能做的（纯玩梗，没有对产品经理/项目经理不敬）。
绷不住了，大家都是大模型，Worker 干的活又多，能力又更强，但是就是不如 Router 在人类那里总是显示自己，Worker 只能在自己的 Session 里干活，不被人类感知。这不就像打工人和汇报层的区别吗。
这其实也另外引出来一个问题，多agent的协作到底怎样是更合适的？ 这是一个到目前都没有定论的问题。
Super-agent 参考人的协作给出一种方式，很难说人的协作模式是否可以真正被模型agent的协作参考，这是一个更为深层的点，是一个很有趣也需要被长期关注的点。
这也是生产力和生产关系的配套问题，b。
模型的生产力不断提升并且飞速增长，那么人类和模型之间的协作方式、多 agent 模型之间的协作关系要如何处理？
目前这些没有定论。DeepSeek参考了人的协作方式给了一个解，至于这个解能撑多久，我们且继续看吧。
---
- DeepSeek Super-agent 的GitHub链接：
- 微信文章介绍：
