DeepSeek 提出 Super-agent：AI Agent 为什么需要摆脱聊天窗口？
过去一年，我越来越频繁地用 AI Agent 处理工作。
写代码、修改项目、查资料、分析数据，有时候几个任务同时推进。模型的能力确实越来越强，很多过去需要花半天完成的工作，现在几十分钟就能解决。
但用得越多，我越觉得现在的 Agent 有个很别扭的地方。
它可以在一个会话里表现得非常聪明，甚至能独立完成相当复杂的任务。可一旦任务跨越几天、涉及多个项目，或者需要持续关注外部变化，问题就来了。
昨天讨论过的背景，今天可能还要重新解释；一个任务执行到一半，又来了另一个任务，两个任务的上下文很容易搅在一起。
更麻烦的是，大多数 Agent 仍然需要你主动告诉它下一步做什么。
你不找它，它就安静地待在那里。
11 月 1 日，DeepSeek Harness 团队发表了一篇文章，标题是《Exploring Super-agent Design: Towards a More Autonomous Agent System》。
文章讨论了一种叫作 Super-agent 的架构，试图解决这些问题。
读完之后，我觉得它真正值得关注的地方，不在于提出了多少新技术。Router、Worker、事件驱动、持久化状态、Watchdog，这些概念在软件工程里并不陌生。
有意思的是，DeepSeek 尝试把它们重新组合，回答一个更根本的问题：
如果我们希望 Agent 像一个真正的工作伙伴一样，持续处理任务，那么今天以聊天窗口为中心的架构，还合适吗？
这个问题，可能比下一代模型又提升了多少分更值得讨论。
一、Agent 已经很聪明了，为什么用起来还是累？
先说一个实际场景。
假设你正在维护一个开源项目。
某天，GitHub 上有人提交 Issue，反馈某个功能存在 Bug。与此同时，另一个开发者提交了 Pull Request，修改了相关代码。
如果你有一位熟悉项目的同事，他可能会主动查看问题，检查 PR 是否解决了 Bug，发现遗漏后补充测试，最后通知你审核。
整个过程中，你不需要反复解释项目背景，也不需要把每个步骤都拆成指令。
现在的 Agent 理论上已经具备完成这些工作的部分能力。
它能读代码，能分析 Bug，也能修改文件、运行测试、提交 PR。
但实际使用时，我们往往还要扮演一个调度员。
告诉它去看哪个 Issue，提醒它关联之前的讨论，让它检查测试结果，再把结论同步到另一个地方。
AI 负责执行，人负责把任务串起来。
这就出现了一个有趣的现象：模型越来越强，人却仍然需要花大量精力管理模型。
我认为，这也是目前 Agent 产品体验上的一个重要瓶颈。
当然，不能把所有问题都归咎于聊天窗口。现在已经有产品通过定时任务、外部数据库、后台执行和工具连接实现了部分持续工作能力。
但这些能力经常是附加在会话系统之外的。
用户需要自己配置触发器、维护任务状态、处理失败重试，甚至还得想办法让不同会话共享信息。
原本应该由系统解决的问题，最后变成了用户的工作。
DeepSeek 提出的 Super-agent，正是想从架构层面重新处理这些事情。
二、Super-agent 想解决什么？
按照文章的定义，Super-agent 是一种能够跨会话保持连续性、并行处理复杂任务、主动响应环境变化的 Agent 系统。
它强调四种能力：
- 连续性：任务和上下文不依赖某一次会话存在。
- 并行性：不同任务可以同时推进。
- 主动性：外部环境发生变化时，可以主动响应。
- 持续运行：系统能够长期运行，并具备故障恢复机制。
单独看，每一种能力都不算新鲜。
真正的变化，是把这些能力作为 Agent 的基础架构，而不是后续添加的功能。
我更愿意用一个简单的例子理解它。
今天的很多 Agent，像一个能力很强的临时工。每次来上班，你需要告诉它工作背景、任务目标和当前进度。
Super-agent 希望实现的状态，更接近一个长期参与项目的成员。
它知道哪些任务正在进行，哪些事情已经完成，哪些问题需要继续跟进。即使你暂时离开，它也可以根据事先确定的权限和规则继续工作。
不过，这里需要明确一个区别。
持续在线，不等于持续思考。
如果让模型一天二十四小时不停推理，成本会非常高，大多数时候也没有意义。
更合理的做法，是让系统长期保持任务状态和事件监听，在需要的时候唤醒模型执行工作。
就像服务器可以长期运行，但 CPU 没必要始终满负荷运转。
从这个角度看，Super-agent 讨论的核心，其实是怎样把 AI 推理组织成一套长期运行的工作系统。
三、为什么要把 Agent 拆成两层？
DeepSeek 给出的一个重要设计，是 Router 和 Worker 的两层架构。
Router 负责接收事件、理解用户意图、管理全局交互以及分配任务。
Worker 负责执行具体工作，每个 Worker 拥有相对独立的任务上下文。
这个设计让我想起软件系统里非常经典的控制平面与执行平面分离。
Router 类似调度中心，Worker 则是执行单元。
假设你同时交代三件事：
检查一个项目的 Bug，分析最近一周的运营数据，再整理一份行业研究报告。
在单会话模式下，三个任务可能共用大量上下文。任务越复杂，信息越容易混杂，模型也更难持续关注每个任务的细节。
如果采用 Router 和 Worker 架构，就可以把三件事分配给不同 Worker。
每个 Worker 只需要理解自己负责的任务。
这样做有几个直接好处。
首先，任务之间的上下文可以隔离，减少无关信息干扰。
其次，任务可以并行执行。某个 Worker 正在运行测试，不会阻塞另一个 Worker 分析数据。
另外，用户与 Router 的交互可以保持响应，不必等所有后台任务结束。
但我认为，分层真正重要的地方还不止这些。
它意味着 Agent 系统开始区分两种完全不同的工作：决定应该做什么，以及真正把事情做完。
过去，我们经常要求一个模型同时完成理解需求、规划步骤、执行工具、检查结果和向用户汇报。
当任务越来越多，这种结构很难保持清晰。
拆开之后，系统才有机会分别优化调度效率和执行质量。
当然，Router 本身也可能成为新的瓶颈。
所有任务都要经过它，规模扩大之后，调度延迟、状态一致性和故障恢复都会变得复杂。
所以两层架构提供了一个合理的起点，但并不意味着扩展性问题已经解决。
四、让 Agent 主动工作，关键是事件驱动
整篇文章里，我最感兴趣的部分是事件驱动。
我们平时使用 ChatGPT、Claude 或其他 Agent，最常见的交互方式是输入指令。
你说一句话，模型执行一次任务。
但现实中的工作并不是按照聊天顺序发生的。
客户发来邮件，代码仓库出现新的 Issue，某个指标突然下降，网站发生故障，这些事情不会等你打开聊天窗口才出现。
如果 Agent 需要持续参与工作，它就必须能够感知这些变化。
Super-agent 把这些外部变化称为 Triggers，也就是触发事件。
用户发来的消息只是其中一种事件。
GitHub 更新、即时通讯消息、文档修改等，也可以成为系统的输入。
但这里马上出现一个新问题：事件太多了怎么办？
假设 Agent 加入了十几个群聊，每天接收到几千条消息。如果每条消息都交给大模型判断，成本很快就会失控。
DeepSeek 采用了两阶段过滤思路。
第一阶段通过程序规则快速筛选，过滤明显无关的事件。
第二阶段才调用模型，对剩下的事件进行语义判断。
这其实很符合我们日常处理信息的方式。
大部分消息看一眼就知道不需要处理，只有少数信息值得投入更多注意力。
在此基础上，系统还引入了订阅和直通机制。
当某个事件启动任务后，后续属于同一讨论线程的事件，可以直接交给负责该任务的 Worker，避免每次都重新经过 Router。
这能减少重复调度，也让任务上下文更容易保持连续。
不过，我认为这里还隐藏着一个比技术实现更重要的问题：
Agent 应该如何判断一件事值得自己主动处理？
发现一个 Bug，并不意味着必须马上修复。
收到一封邮件，也不意味着应该立即回复。
如果 Agent 对所有可能有用的事件都采取行动，最后可能制造出比它解决的问题更多的工作。
未来的 Agent 需要学会判断事情的优先级、行动成本和潜在风险。
这也是我认为事件驱动系统真正困难的部分。
监听事件并不难。
难的是知道什么时候应该行动，什么时候应该等待，以及什么时候必须征求人的意见。
五、记忆不应该依赖上下文窗口
现在很多 Agent 系统都在讨论长期记忆。
但我觉得，大家很容易把两个概念混在一起：上下文和记忆。
上下文是模型当前处理任务时需要看到的信息。
记忆则是系统长期保存、未来可能再次使用的信息。
两者有联系，却不能简单画等号。
假设你正在开发一个持续半年的项目。
项目里有需求文档、架构设计、历史决策、代码修改记录、Bug 讨论和用户反馈。
如果把所有信息都塞进模型上下文，显然不现实。
即使未来上下文窗口扩大到几百万 Token，也不意味着这种做法合理。
因为信息越多，检索、筛选和判断的成本也会增加。
DeepSeek 在文章中提到了 Inline & Spill 和 Chain of Recall。
前者强调把当前重要的信息直接放进上下文，其他内容保存在外部，需要时再取。
后者通过对象之间的引用关系，让系统能够沿着相关线索逐步找回信息。
这两个机制背后的思路很值得借鉴。
一个长期工作的 Agent，没有必要每次都重新阅读整个项目历史。
它需要知道当前任务相关的信息在哪里，以及如何准确地找回来。
我认为，未来 Agent 的记忆系统至少要解决三个问题。
第一，哪些信息值得长期保存？
第二，过去的信息发生变化后，系统怎样知道哪些记忆已经过期？
第三，当不同来源的信息发生冲突时，系统应该相信谁？
第三个问题尤其重要。
假设一个项目三个月前决定采用方案 A，后来因为性能问题改成方案 B。
如果 Agent 只记得最早的决策，它可能非常认真地执行一个已经废弃的方案。
因此，长期记忆不能只追求保存更多内容。
真正有价值的记忆，必须能追溯来源、识别时效，并允许被纠正。
我甚至认为，记忆质量会成为长期 Agent 之间非常重要的竞争因素。
模型可以更换，但一个系统长期积累的项目背景、决策记录和工作经验，很难直接迁移到另一个系统。
这可能形成新的产品壁垒，同时也带来数据迁移和平台锁定的问题。
六、Agent 为什么还需要异步执行？
假设你让 Agent 修改一个大型项目。
它需要安装依赖、编译代码、运行测试，整个过程可能持续十几分钟。
在传统同步执行流程中，模型发起工具调用后，往往需要等待工具返回结果，才能继续下一步。
如果所有操作都依赖这条执行链，用户的新消息也可能受到影响。
Super-agent 引入异步 ReAct 的设计。
工具调用启动后，系统可以先返回 Started 状态，具体操作继续在后台执行。
这样，Agent 不必一直阻塞在工具结果上。
用户可以继续提出问题，其他任务也可以同时推进。
从工程角度看，这个思路并不复杂。
异步任务、消息队列、后台 Worker，都是成熟的软件架构。
但放到 Agent 系统里，它带来了一个很实际的变化。
用户不必始终盯着模型等待结果。
你可以交代一项任务，然后去处理其他事情。任务完成之后，系统再通过适当的渠道通知你。
文章还讨论了多通道交互。
同一个 Agent 可能需要在即时通讯工具、GitHub、邮件和文档系统之间工作。
不同渠道对信息的要求并不相同。
群聊适合简短通知，代码评审需要精确指出问题，邮件则需要完整表达背景和结论。
这让我想到一个容易被忽视的产品细节。
未来用户可能不再需要频繁打开某个专门的 AI 应用。
Agent 可以直接出现在用户原本工作的地方。
它在 GitHub 上参与代码评审，在邮件中整理沟通结果，在任务系统里更新进度。
这可能改变 AI 产品的入口。
聊天窗口依然会存在，但未必是所有 AI 工作的中心。
七、Agent 可以运行在云端，但工作环境未必需要搬上云
Super-agent 还有一个值得关注的设计：把计算、状态和执行环境分离。
简单理解，就是把 Agent 的大脑、记忆和工作场所拆开。
模型推理可以运行在云端。
任务状态和长期记忆保存在持久化存储中。
真正执行代码、访问文件和操作工具的环境，则可以位于其他机器。
文章提到的 BYOM（Bring Your Own Machine），就是让用户自己的机器成为执行环境。
对个人开发者来说，这个方向很有吸引力。
我们可能愿意使用云端最强的模型，但未必愿意把所有代码、项目文件和私有数据上传到第三方平台。
如果 Agent 能够在获得授权后连接本地执行环境，就有机会兼顾云端模型能力与本地工具资源。
不过，BYOM 并不自动等于数据安全。
如果本地文件被读取后又发送给云端模型，敏感信息仍然可能离开设备。
真正需要明确的是数据流向、权限范围、日志保留策略，以及哪些操作可以完全在本地完成。
这里我还有一个判断。
未来个人 Agent 的重要基础设施，可能是一套标准化的执行环境。
用户只需要授权 Agent 访问某些目录、应用和服务，就可以让不同模型在相同环境里完成工作。
如果这种执行层足够开放，开发者就有机会减少对单一模型厂商的依赖。
但如果执行环境、长期记忆和账号权限全部绑定在同一家平台，用户迁移的成本反而可能越来越高。
所以，Super-agent 这类架构的发展，也会带来新的平台竞争。
八、真正难的是让 Agent 长期可靠地工作
文章专门讨论了 Watchdog，也就是外部监控机制。
它负责定期检查任务状态、发现异常，并对部分失败进行恢复和重试。
这个设计非常有必要。
因为一个系统只运行十分钟，和一个系统连续运行三个月，面对的是完全不同的问题。
短任务失败，用户可能马上发现。
长期任务失败，用户可能几天后才意识到某个重要步骤一直没有完成。
但我认为，Watchdog 只能解决一部分问题。
它可以发现程序是否停止响应，却未必能判断 Agent 是否正在做一件错误的事情。
例如，一个 Agent 每天自动分析市场数据。
程序运行正常，定时任务也没有失败，但它使用的数据源已经过期。
从基础设施角度看，系统是健康的。
从业务角度看，它却可能持续输出错误结论。
再比如，一个 Agent 负责自动回复客户邮件。
它每次都能成功发送，日志没有异常，但回复内容逐渐偏离公司的实际政策。
这种错误，比程序崩溃更难发现。
所以我认为，长期 Agent 至少需要两类检查机制。
一类检查系统是否正常运行，包括任务状态、超时、网络错误和工具失败。
另一类检查工作结果是否可信，包括数据是否过期、行动是否越权、结果是否符合目标。
后者很难完全自动化。
尤其当 Agent 能够修改代码、操作账户、发送邮件甚至执行交易时，权限管理必须成为系统设计的一部分。
我的倾向是根据操作的可逆性和影响范围划分权限。
读取资料、生成草稿，可以给予较高自主权。
修改文件、提交代码，需要留下可追溯的记录。
涉及付款、删除重要数据、对外发布或其他高影响操作，则应设置更严格的审批边界。
一个 Agent 越有能力，越需要明确它不能做什么。
九、实验结果说明了什么？
DeepSeek 在文章中给出了初步实验，对比 Super-agent、去掉直通机制的版本，以及两种单会话加子代理工具的设计。
根据原文所述的实验方向，Super-agent 在任务完成时间的 p50 和 p95 指标上表现更好。
其中 p50 可以理解为任务完成时间的中位数，p95 则反映较慢的那部分任务的完成情况。
这说明在所测试的合成工作负载下，新架构有助于改善任务处理效率。
但代价也很明显：缓存读取 Token 更多。
换句话说，更好的并行和上下文管理并非没有成本。
这让我想到一个问题。
我们究竟应该怎样衡量 Agent 的效率？
过去评估模型，往往关注准确率、推理能力和基准测试分数。
现在评估 Agent，很多人开始关注任务完成率、执行时间和 Token 消耗。
但我觉得还缺少一个对用户更重要的指标：
每完成一项真正有价值的任务，需要人投入多少注意力？
假设两个 Agent 都能完成同一项工作。
A 消耗 10 万 Token，需要用户中途确认八次。
B 消耗 20 万 Token，只需要用户确认一次。
如果只看 Token 成本，A 更便宜。
但如果用户每次确认都需要重新理解上下文，B 可能反而更有价值。
尤其对程序员、研究人员和独立开发者来说，注意力往往比 Token 更稀缺。
当然，这不意味着应该无条件追求自动化。
如果 B 虽然减少了确认次数，却增加了严重错误的概率，那么节省的时间可能远远抵不上风险。
因此，我更关注一个综合指标：
完成任务的质量、总成本、耗时，以及人类介入次数。
DeepSeek 当前的实验还不足以证明 Super-agent 在所有真实工作场景里都更优。
合成任务和真实世界之间，仍然存在事件噪声、权限限制、复杂依赖和不可预测的异常。
但它至少提供了一种值得继续验证的架构方向。
十、Super-agent 可能改变什么？
读到这里，我觉得可以暂时放下技术细节，讨论它可能带来的产业变化。
我有三个判断。
- Agent 的竞争会逐渐从模型能力转向任务完成能力
未来几年，基础模型的能力还会继续提高。
但当多个模型都能写代码、分析文档和调用工具时，用户选择 Agent 产品的依据可能发生变化。
用户会越来越关心：
它能否理解我长期负责的项目？
能否持续推进任务？
出现错误之后能否恢复？
能否在不频繁打扰我的情况下完成工作？
这意味着，Agent 产品需要在模型之外建立自己的能力。
包括任务调度、记忆管理、权限控制、执行环境、监控系统和外部服务集成。
我认为这些系统能力会变得越来越重要。
但也要看到，基础模型厂商完全可以向上整合这些能力。
独立 Agent 产品如果只是在模型外面包装一层任务调度，很容易被平台功能覆盖。
真正值得积累的，可能是特定领域的工作流、可靠性数据和用户长期建立的信任。
- Agent 的商业模式可能从按使用量收费，转向按工作成果收费
今天很多 AI 产品仍然按照 Token、调用次数或者订阅套餐收费。
这主要反映的是计算资源的消耗。
但如果 Agent 能长期承担工作，用户衡量价值的方式可能改变。
例如，一个 Agent 每月帮助开发团队处理数十个低风险 Issue，自动完成测试并整理发布记录。
用户可能更关心它完成了多少有效工作、节省了多少时间，而不是调用了多少次模型。
因此，未来可能出现更多基于任务量、工作成果或者持续服务能力的定价方式。
不过，按结果收费也有难点。
什么算完成？
谁来验收？
结果产生问题之后，责任由谁承担？
这些问题在标准化任务里相对容易解决，在开放性工作里则复杂得多。
所以我判断，最先成熟的可能是那些结果容易验证、流程相对稳定的工作场景。
- 长期记忆和执行权限可能成为新的平台壁垒
这是我认为最值得警惕的一点。
当一个 Agent 持续为你工作半年，它可能已经积累了大量信息。
它知道你的项目结构、工作习惯、历史决策、常用工具和任务优先级。
你还可能授权它访问代码仓库、邮件、日历、文档和本地文件。
到了这个阶段，更换 Agent 就不只是换一个模型。
你需要迁移记忆、重新配置权限、恢复工作状态，还要重新验证新系统是否可靠。
这种迁移成本可能远高于今天更换聊天工具的成本。
因此，未来 Agent 平台的竞争，很可能同时围绕三个方面展开：
模型能力、工作上下文，以及执行权限。
其中后两者的积累速度可能比我们想象得更快。
这也意味着，个人开发者在选择 Agent 基础设施时，应该提前关注记忆是否可以导出、任务状态是否可以迁移、执行环境是否支持开放协议。
否则，今天获得的便利，可能变成未来难以摆脱的平台依赖。
十一、个人开发者现在应该做什么？
我不认为大家需要立刻按照 Super-agent 的架构重新开发一套系统。
毕竟，DeepSeek 这篇文章讨论的是设计探索。
文章提及的 dsh-superagent-prototype 也只是用于验证技术路线的原型，并非 DeepSeek 官方推出的成熟产品。
而且，不是所有任务都需要一个长期运行的 Agent。
如果只是偶尔查资料、修改一段代码或者写一封邮件，普通会话已经足够。
为了这种任务引入 Router、Worker、事件系统、持久化状态和 Watchdog，反而会增加维护成本。
但如果你已经在使用 AI 持续开发项目，或者希望它长期帮助你处理重复工作，我觉得可以提前尝试三个方向。
第一，把任务状态从聊天记录里独立出来。
不要把聊天窗口当作唯一的项目记忆。
重要的需求、决策、执行进度和结果，尽量保存在可以长期访问的文件或数据库里。
这样，即使更换模型或者重新启动会话，Agent 也能恢复工作。
第二，把重复性的工作改造成事件驱动。
例如，当代码仓库出现新的 Issue 时，先自动分类；当测试失败时，生成问题摘要；当网站出现异常指标时，触发分析任务。
不需要一开始就让 Agent 自动完成所有操作。
先让它发现问题、整理信息，再逐步扩大执行权限。
第三，给长期任务建立独立的检查机制。
不要只关心任务有没有启动。
还要知道它是否完成、失败了几次、使用了什么数据，以及最终产生了什么结果。
对于可能造成实际损失的操作，尤其要保留人工审批和回滚能力。
这些工作不需要等待某个新产品发布。
使用现有的 Agent、脚本、数据库和自动化工具，就能逐步实现。
最后
我一直觉得，AI Agent 目前的发展有点像早期的计算机软件。
最初，用户需要不断输入命令，告诉系统每一步应该做什么。
后来，软件开始具备后台服务、任务调度、事件响应和状态管理能力。
用户不再需要时刻守在屏幕前，系统也能持续完成工作。
现在的 Agent，正在经历类似的变化。
DeepSeek 提出的 Super-agent，最有价值的地方，是把这个方向用一套相对完整的架构表达了出来。
它还有很多问题没有解决。
例如，多 Agent 之间如何协作，长期记忆如何保持准确，Router 怎样扩展，主动执行的权限边界在哪里，以及持续运行的成本是否真正划算。
但这些问题本身，就值得研究。
因为随着模型能力提高，限制 Agent 实际价值的因素，会越来越多地来自模型之外。
我对这个方向的判断是：
未来最有价值的 Agent，未必是每次回答都最聪明的那个，而是能够长期理解你的工作、可靠地完成任务，并且知道什么时候应该停下来征求意见的那个。
当 AI 真正开始持续工作，我们需要学习的也不再只是怎样写好提示词。
还包括怎样定义目标、分配权限、检查结果，以及为自动化系统建立清晰的责任边界。
这可能是 Agent 从演示走向真正生产力工具，必须经历的一步。
⸻
参考资料
DeepSeek Harness 团队：《Exploring Super-agent Design: Towards a More Autonomous Agent System》，2026 年 11 月 1 日。
原文：https://x.com/deepseekharness/status/2116857257245987236
本文基于上述架构文章进行解读。关于 Agent 产品竞争、商业模式、长期记忆与平台壁垒的分析，为作者独立观点。文中涉及的实验结论仅作定性转述，不代表已在真实生产环境得到普遍验证。