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链接：
https://github.com/DeepSeek-ai/dsh-superagent-prototype
- 微信文章介绍：
