2026-11-02 16:00:00
智猩猩AI整理
编辑：没方
前天，DeepSeek团队发布了一篇名为《Super-agent设计探索：迈向更自主的Agent系统》的技术文章。
并同步开源技术原型dsh-superagent-prototype，该项目在github上已收获1万星标。
据DeepSeek团队观察，一个人通常只能同时跟进3-5个活跃Session。
随着模型执行复杂任务的能力不断增强，限制Agent进一步发挥的因素，正在从模型本身转向人的注意力。
他们这次探索的重点是让Agent摆脱传统单Session的工作方式。
Agent不需要用户手动管理多个对话窗口，在不同工作渠道之间能够保持上下文，并行推进多项任务。
为此，团队设计了五个核心模块。
（1）Router + Worker：一个负责协调，多个负责干活
这是整套架构最核心的设计，将Agent分成两个层级：Router和Worker。
例如，用户同时提出三个需求：修复一个Bug、检查一个Pull Request，以及开发一个新功能。
Router接收到这些任务后，可以分别创建三个Worker，让它们独立推进各自的工作。执行过程中，Worker不直接与用户交互，而将进展和结果汇报给Router，再由Router统一向用户反馈。
这样一来，底层虽然运行着多个独立Session，但用户不需要感知和管理这些Session。
无论从即时通讯还是GitHub等渠道发起任务，都可以通过同一个Router衔接上下文、协调工作。
既减少了用户在多个对话窗口之间切换和管理的注意力消耗，也避免了多个Agent各自回复造成的交互混乱。
（2）事件驱动：让Agent主动发现任务
传统Agent通常需要用户输入指令才能开始工作，而Super-agent希望改变这种被动模式。
为此，团队将群聊消息、邮件、日程提醒、GitHub评论、CI运行结果等外部信息统称为Trigger（触发事件）。系统会持续监听这些事件，并先通过程序规则过滤掉大量无关信息，再让大模型判断哪些事件值得处理。
为了避免每条新消息都重新经过Router分配，系统还引入了Thread订阅机制。
简单来说，同一个GitHub Issue、Pull Request或IM讨论话题下的连续消息，会被组织成一个Thread。
当Router为初始事件创建Worker后，该Worker就可以订阅对应的Thread。同一Thread后续产生的新消息，会直接发送给已经订阅的Worker，不必每次都经过Router重新分配。
值得注意的是，Thread与Worker之间采用多对多的订阅关系：一个Worker可以同时订阅多个相关Thread，同一个Thread也可以被多个Worker订阅。
例如，多个Worker在同一个Pull Request或讨论话题中开展工作时，只要订阅了同一个Thread，就能同时收到该Thread下的新消息，及时了解彼此的操作，并尝试自行解决协作冲突，而不需要彼此直接通信。
Worker会将关键结论汇报给Router，再由Router向用户反馈，并同步更新全局记忆。
（3）异步ReAct Loop：干活时也能及时回复
过去Agent调用一个耗时较长的工具时，需要等工具执行结束，才能继续处理新的输入。
DeepSeek团队提出异步ReAct Loop，将耗时任务改为异步启动。
比如，Agent接到一个需要运行十几分钟的代码测试任务，可以先启动任务并返回“Started”，随后继续接收用户的新消息。等后台任务执行完成，系统再把结果发送回来。
因此，前台沟通和后台执行就不再相互阻塞。
值得一提的是，这套异步任务机制已经在DeepSeek Harness中实现，但目前尚未默认开启。
（4）计算、状态与执行环境分离：不再依赖一台设备
传统本地Agent通常将模型运行、会话状态和代码执行环境放在同一台机器上。一旦电脑休眠或断网，Agent就无法继续工作了。
Super-agent尝试将这三者拆开，分为两个层次进行解耦：
计算与状态分离：将负责推进Agent运行流程的计算放在云端，而将需要长期保存的会话状态单独存储。这样，即使计算进程重启或替换，任务上下文也能得到保留，Agent不再受单台设备运行周期的限制。
计算与执行环境分离：Agent Loop放在云端，但代码仓库、本地文件、工具链等执行环境仍然可以留在用户自己的设备上。用户只需在端侧部署一个轻量级的Daemon（守护进程），它不保存会话状态，只负责接收云端Agent发来的命令、在本地执行，并将执行结果返回给云端。
这意味着，Agent可以在云端持续运行，同时按需调用用户本地的开发环境，既保留了本地代码、文件和工具链，又不必为了使用云端Agent，将整个开发环境迁移到云端。
（5）Watchdog：给Agent安排一个监工
让Agent执行长期任务，难免会遇到接口报错、进程崩溃、任务卡住，甚至模型陷入无效循环等问题。
团队为此设计了Watchdog，即一个独立运行的监控Agent。它由定时消息驱动，在主Agent系统之外形成Control Loop。
它不仅检查系统是否正常运行，还会判断Worker有没有取得实际进展、执行方向是否偏离目标。一旦发现异常，就可以尝试介入修复，并持续检查系统是否恢复。
01
开源社区点赞：这套架构把
很多工程经验串起来了
李博杰对这套设计给出了相当积极的评价，认为dsh-superagent不仅整合了多种Agent工程实践，还将一些计算机系统中的经典设计思想真正落地。
他认为Sessionless需要让Agent具备真正的「活人感」
有事及时响应、说话简洁，没事尽量不打扰用户。
他认为，2026年初OpenClaw将多渠道Sessionless架构带入了Agent社区，但在不同渠道的交互细节上，仍有不少值得打磨的地方。
认可Super-agent将计算机系统中的事件驱动架构引入Agent
在他的理解中，飞书消息、GitHub Issue等外部信息都可以作为事件输入。事件进入系统后，先经过程序规则和Jev类轻量模型过滤，再交给大模型处理，避免每条消息都直接调用大模型。
更重要的是，DeepSeek通过Thread组织事件，让同一数据源下的任务保持关联，同时允许不同数据源并行处理。李博杰将这种设计比作Linux中的epoll机制，认为这是将成熟的计算机系统事件处理思路引入Agent的一次实践。
异步ReAct Loop让他看到了Agent执行方式的一次重要演进。
李博杰提到，GPT-6模型已经原生支持异步工具，而DeepSeek Harness也将这一能力落实到了异步ReAct Loop中。
他认为，异步执行已经逐渐成为Coding Agent不可或缺的能力，自己早在2025年初提出的异步ReAct思路，如今也终于在工程实践中得到落地。
认可了Super-agent「脑手分离」和「存算分离」的设计。
相比Claude Code、OpenClaw等主要运行在端侧的Agent，以及Manus等依赖云端沙盒的方案，将Agent融入端侧操作系统，再结合云端计算能力，可能是更值得探索的方向。
总体来看，这些设计观点并非凭空创造的新理论，而是Agent开发者在长期工程实践中逐渐形成的共识。
DeepSeek团队将它们整合到一套架构中，并通过开源原型落地验证，具有相当的参考价值。
02
另一种声音：idea清仓大甩卖？
当然，并不是所有开发者都看好这套架构。
开发者Yuu提出的一个核心质疑是：这套架构混合了太多不同的设计思路，很难判断究竟哪些设计真正提升了性能，哪些反而带来了额外负担。
在他看来，Router + Worker未必是最佳实践。
对于一个简单的交互，为什么还需要经过Router分配给Worker，再由Worker返回Router，最后才反馈给用户？
这种多层工作流可能增加不必要的调度开销，不一定适合所有Agent任务。
他还从工程演进的角度提出了自己的理解。
DeepSeek可能是先把Coding Agent接入群聊，随后发现多个任务容易串上下文、长任务执行时无法及时响应新消息，于是引入Router和Worker；接着为了解决事件响应问题，增加Trigger机制；又因为Worker长期执行时可能失控，进一步引入Watchdog。
在他看来，每一步都是针对实际问题增加一项机制，最后形成的系统看起来更像是多个补丁的组合，而不是一套足够简洁、统一的最佳架构。
03
DeepSeek已用Super-agent
参与DSH自身迭代
DeepSeek团队基于这套思路构建的内部Super-agent已投入日常使用，参与问题复现与修复、代码审查，以及DeepSeek Harness自身的迭代。
从内部实践到开源技术原型，DeepSeek也在探索如何让Agent更好地处理多项任务、保持持续响应，让用户不必再为管理多个Session和等待任务完成而分心。
至于这套架构能否成为通用的Agent方案，还有待检验......
END
关注+星标，获取AI前沿进展与开源一线动态
关注公众号
智猩猩AI的公众号