DeepSeek Super-agent技术文章与架构讨论 · 话题榜 · TwKit

@MinLiBuilds

今晚的作业来了。 DeepSeek 官方发了一篇超长技术文。 讲的是 Super-agent，一个更自主的 Agent 系统。 核心观点： 单任务，瓶颈是模型。 多任务，瓶颈是人。 一个人同时最多盯 3 到 5 个 Session，再多脑子就炸了。 他们的解法是 Router + Worker 双层架构。 Router 只管跟你聊、分派任务。 Worker 在后面隔离并发地干活。 再加上事件驱动、全双工打断、外部 Watchdog 看门狗。 跟人类组织形式越来越像了。 实测完成时间 p95，从 29.5 分钟降到 15.7 分钟，差不多快一倍。 原型已经开源。 我自己每天带着十几个 bot 跑，这篇说的问题全踩过。 巨长，但值得今晚泡杯茶慢慢啃。 原文👇

@tianyi

Super-agent 文章的官方英文版发布啦～ 做 Agent 产品，DeepSeek 有一流的模型、算法、基建，有优秀的研究员和工程师。但是，目前优秀的产品经理和设计师的数量还远远不够。 欢迎想做世界一流 Agent 产品的优秀产品经理和产品设计师给 DeepSeek 产品部投简历。

@AYi_AInotes

梁圣牛逼，全体起立，DeepSeek 刚发布的这篇1.4 万字的Super-agent 技术长文强烈推荐，喵的终于把 Agent 最大的遮羞布扯下来了： 做不好往往不是模型不够强，而是人根本管不过来。 甚至说推翻了以对话框为中心的旧范式都不为过，核心就做了一件事：把人从管理会话的苦力活里彻底解脱出来。 很多人以为 Agent 落地的瓶颈在模型能力，DeepSeek 在文章里指出了真相：真正的瓶颈在人的注意力。 也就是说当单任务执行不再需要人盯，以一个对话框为基本单位的旧产品形态该被淘汰了。 大家默认以为大模型落地的最大阻碍是推理能力不够强，全网都在拼命卷参数、刷跑分，试图靠单个对话框包办一切。 但真正的分水岭从来不在单点智力，而在系统对人类注意力的极致释放。 一个正常人同时最多只能跟进 3 到 5 个活跃会话，如果系统永远把切窗口、催进度、理上下文的负担甩给用户，算力再高也只是个把人累死的玩具。 DeepSeek 给出的解法极其冷峻：彻底打碎单会话机制，搭一套长期存活的 Super-agent 架构。 前端常驻一个轻量 Router 只管对接多渠道派活，中间派生出上下文完全隔离的 Worker 专攻单点任务，老任务后续事件靠订阅直通直达负责人，再配上一个独立的 Watchdog 巡检死循环。 任务完成时间直接从单会话的 29.5 分钟压到 12.4 分钟，聊天软件里的回复甚至被焊死在 100 字以内，不该发声时绝不打扰。 这对所有做 AI 落地和业务管理的团队是一个极度清醒的提醒：未来的核心壁垒不在于模型多会答题，而在于谁能把混乱的会话调度降维成一条不用人肉盯梢的自愈流水线。

@leon7hao

Deepseek 回回都不让人周末省心，super agent 看完了，确实是没有新东西。以一篇论文的形式描述了 multi-agent loop 把这个坑占了下来，但是论文最重要的实验部分只有短短的两个小节。 无论做 agent 还是用 agent 搞得多了大家很容易得到相同的结论，人的注意力是有限的，human 在 loop 里越多，整个系统的效率越低。

@bojie_li

dsh-superagent（DeepSeek 刚开源的主动 coding agent 架构）非常赞。 1. Router-Worker 架构实现了 sessionless，Router 负责与用户交互，调度消息和事件，维持记忆和全局上下文，多个 Worker 并行执行具体任务。 Sessionless 不是简单把多个 session 合成一个 session，难的是实现活人感，有事响应及时、说话简洁，没事少打扰用户。 2025 年在 Pine 做全球首个 personal agent 的时候，Pine 的用户都是不懂 AI 的普通人，总是抱怨 agent 跟用户说话啰嗦，agent 忙着干活的时候不搭理用户、不响应紧急事件。为了让 agent 在文字沟通中也具备活人感，我们引入了前台 agent 跟用户沟通，后台 agent 实际干活。在全双工语音架构中，也是前台 full duplex 说话，后台做长程任务。 Router agent 在电话、短信、Web、邮件等多种渠道跟用户和第三方交互时，适合的信息密度不同，因此 agent 必须知道该用何种渠道跟用户交互，不同渠道的交互规范也不同。 2026 年初，OpenClaw 把这个多 channel 的 sessionless 架构带给了 agent 社区。但 OpenClaw 在多 channel 交互细节上仍然有很多待打磨的地方。 2. 事件驱动的 agent 架构，飞书消息、GitHub issues 都是事件，事件首先经过规则和 Jev 类轻量模型过滤，再送给 LLM 处理。 事件驱动的难点在于，单一的 ReAct loop 可能来不及处理所有事件，也就是 25 年我们遇到的 agent 忙着干活的时候不响应新的事件。但简单交给独立的 agent 来做，又会导致 agent 上下文割裂，不同 agent 的决策互相打架。 dsh-superagent 的解法是根据数据源把事件组织成 thread，每个 thread 在同一时间只有一个实例（Eval），这样不同数据源可以并行处理，相同数据源可以批量处理，就像 Linux epoll 一样。dsh-superagent 把计算机系统的经典 event driven 架构引入到了agent。 3. 异步 ReAct loop，也就是工具调用可以异步执行。以往长时间运行的工具都要像 Claude Code 一样利用后台命令、monitor 等机制来实现异步化。GPT-6 模型原生支持了异步工具。dsh-superagent 把耗时的命令与子任务工具调用改为异步的start() 和 stop()，构成异步 ReAct Loop。 2025 年初我刚提出异步 ReAct loop 的思想时，有些人认为没有必要，有些人认为模型很难支持。今天异步执行命令已经成为 coding agent 必不可少的能力，异步 ReAct 这个思想也终于落地了。 4. dsh superagent 采用了“脑手分离”、“存算分离”的思想，harness 无状态，因此脑可以在端侧也可以在云上，摆脱了单机生命周期限制。Claude Code、OpenClaw 等 agent 仅在端侧，Manus 等 agent 需要昂贵的云侧沙盒，其实把 agent 做进端侧 OS，端云结合是最正确的设计。 从 2025 年至今，我们坚持 agent 无状态化，不做 E2B sanbox 这种重量级的沙盒，很多人好奇我们怎么做到通用 agent 成本还这么低的。这种架构对 agent 开发确实带来了很多约束和麻烦，但对一个服务数百万用户的系统来说是值得的。 5. dsh superagent 的 Watchdog 是非常实用的设计，我在本地也用蓝色大肥鱼做了一个“监工” agent，专门处理 provider 429、rate limit、agent 崩溃、VPN 出问题等。agent 一崩，人在睡觉，几个小时时间就浪费了。对工具调用不太稳定，经常死循环或者早停的模型，watchdog 就更重要了。 6. 在事件内容和工具调用结果注入上下文时，dsh superagent 充分利用了局部性原理，直接喂进去摘要和 ID，agent 需要更多细节时再根据 ID 读取细节。系统中的主要对象都有 ID，构成一张引用图，可以按需读取，便于 agent 协作。 这也是很多 agent 初学者最容易犯的错误：要么把信息一股脑灌进上下文，要么只留摘要导致信息缺失。需要让每个对象有 ID 或路径，渐进式披露。 上述架构设计观点在我的开源书《深入理解 AI Agent》里面基本都有，当然也不是我原创的，是大家做 agent 摸爬滚打的共识。很高兴 dsh superagent 把这些设计原则都开源落地了。