DeepSeek Harness团队探索Super-agent 打造更自主Agent系统

核心问题

当前的智能代理以会话为单位运行，用户同时推进多项工作时，需要在多个会话间来回切换，同时记住每个会话的上下文信息。研究发现，人类通常只能同时跟进3到5个活跃会话，注意力的限制成为了主要瓶颈。为此，研究团队提出了Super-agent方案，即一种连续、高效、主动且持久的智能代理系统。

核心设计思路

驱动方式发生了关键转变：代理不再由手动输入的提示词驱动，而是通过群消息、邮件、评论、CI结果等环境事件持续触发，工作单元也从单次对话变为持续任务。模型负责理解信息并做出决策，系统则承担调度、状态管理和故障恢复的职责。具体包含五个源自成熟系统思想的设计方向：

1. 双层架构：Router常驻运行，仅负责对话处理和任务分派，不直接执行具体工作；Worker拥有独立的上下文环境，订阅相关消息线程，完成任务后向Router汇报。用户始终只需与单一代理交互。

2. 事件驱动：通过代码按白名单和来源规则过滤无效信息，再由模型判断消息语义；已归属到特定任务的后续消息可直接通过程序传递给对应Worker，无需经过Router。

3. 上下文缓存：近期可能用到的信息直接保留在对话窗口中，过长或低频使用的信息仅保留摘要和引用，同时通过相邻关系逐步检索历史信息。

4. 异步信道：耗时较长的命令异步执行，避免对话被阻塞；即时通讯场景下采用简短回复，代码仓库和邮件场景则交付完整内容。

5. 存算分离：计算任务放在云端无状态容器中运行，状态数据存入数据库，真实运行环境保留在本地，仅部署轻量守护进程；独立的Watchdog进程负责监控各Worker是否有实质进展。

与成熟系统的对比

该架构的核心思路与Spark、Ray等成熟系统有共通之处，均体现了控制与执行分离、计算与状态分离、将计算靠近数据的设计原则。但差异主要体现在调度层：Spark和Ray的调度逻辑是固定的，任务与数据依赖关系明确，优化目标是吞吐量和资源利用率；而Super-agent的调度者是一个模型，需要解读消息、判断任务归属、决定是否行动，任务在事前未知，任务间的关系依赖语义判断。

状态处理方式也不同：Spark的分区和Ray的对象可以精确重算，而Super-agent的状态是一段对话和一系列判断结果，重算无法保证得到相同结果，因此必须进行持久化存储。此外，稀缺资源从计算资源变为上下文窗口和用户的打扰成本，批处理积压事件、内存与外存交换、异步工具调用等设计都围绕这两点展开。

方案点评

该方案通过系统层面的分工保证了任务划分的可靠性，相比依赖提示词让模型自主分工的方式更稳定，消融实验也验证了这一点。但仍存在一些未明确的问题：实验使用合成负载，仅测试了调度能力，未涉及任务质量，且对比对象并非其他成熟的多代理框架；单点Router在小团队规模下可用，但扩展所需的长程记忆机制尚未解决；事件驱动允许不可信输入持续进入系统，若云端被注入恶意提示词，连接的设备可能受影响，主动修复机制的误触发问题也未充分考量。

行业洞察

智能代理正逐步被操作系统化：会话类似进程，线程类似管道，Router类似调度器，Watchdog类似守护进程，上下文窗口类似缓存。当代理持续运行时，需要面对并发、缓存、故障恢复等传统系统问题，未来的竞争可能更多集中在系统层面。

上下文是最稀缺的资源，内存与外存交换、链式召回等设计都是用有限的窗口承载无限的历史信息，这部分设计具有可迁移性，不依赖具体的Router和Worker实现。

界面层会比底层更早出现分化：底层设计趋向统一，界面则会嵌入各领域的现有工作流，比如直接在代码提交界面中工作，无需汇聚到统一的聊天入口。

其实并无太多新鲜事物，如今看似前沿的自主代理架构，本质上是回到了早年的设计路径。十年前就有观点总结过架构的本质：架构就是取舍，任何事情都是取舍。取舍是艺术，是价值观，是经济学中的边际概念，也是香农视角下的信息处理逻辑。