AI 越来越能干了，人却可能越来越忙。
这听起来有些奇怪。
以前，我们使用 AI，主要是让它回答问题。后来，AI 学会了编写代码、操作浏览器、搜索资料，甚至能独立完成一项复杂任务。
按理说，人应该越来越轻松。
但如果你已经开始频繁使用 Coding Agent，或者让多个 Agent 同时处理工作，可能会发现一个新问题：
你让 AI 帮你写代码，它开着一个窗口；让它研究竞品，又开一个窗口；接着让它修改 PPT、整理资料、处理邮件，窗口越来越多。
每个 Agent 都在工作，你却得不停地切换。
这个任务进行到哪里了？那个任务有没有遇到错误？刚才对第三个 Agent 说过的话，第五个知道吗？
有时候，为了让它们协同，你还要亲自把一个窗口的结果复制到另一个窗口。
AI 开始替人干活，人却开始替 AI 管理工作。
2026 年 10 月 31 日，DeepSeek Harness 团队发表了一篇技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，讨论的正是这个问题。
文章提出了一种新的 Agent 系统架构：Super-agent。
它的目标不是让单个模型再聪明一点，而是让 AI 不再被一个个聊天窗口困住，能够跨任务、跨应用、跨设备持续工作。
这听起来像是在做一个更强的 AI 助理，但如果仔细拆解，会发现它涉及的其实是一个更基础的问题：
当 AI 已经学会完成任务，我们该怎样组织它的工作？
01 AI 的新瓶颈，不在模型身上
DeepSeek 在文章开头提出了一个观察：
在他们的实践中，一个人通常只能同时跟进三到五个活跃的 Session。
Session，就是我们熟悉的会话。你打开一个 Coding Agent，让它完成某项工作，就可以把这一轮交互理解为一个 Session。
这个观察并不是严格的人类认知能力上限，但它揭示了一种现象。
模型可以并行工作，人却很难同时管理大量相互独立的工作上下文。
假设现在有十个 Agent，每个 Agent 都能独立完成一项复杂任务。
你同时启动它们，理论上可以获得十倍的并行执行能力。
问题是，它们可能在不同时间向你提出问题，需要你检查结果、协调冲突、补充背景，甚至修改原来的目标。
如果这些工作都要通过你来衔接，十个 Agent 就不一定比三个更高效。
DeepSeek 因此区分了两种不同的瓶颈：
单任务的上限，主要取决于模型能力；多任务的上限，则可能取决于人的注意力。
这是一个很重要的变化。
过去 AI 行业大量研究都集中在提升单次任务的完成能力。
比如增加推理能力、扩大上下文窗口、增强工具调用，让一个 Agent 能够完成以前做不到的事情。
但当单个 Agent 已经可以独立工作较长时间，新的问题就出现了。
谁来分配任务？谁来跟踪进度？谁来处理不同任务之间的关系？谁决定哪些事情需要人类介入？
这些问题未必需要更聪明的模型，却需要更好的系统架构。
计算机的发展曾经经历过类似的过程。
早期计算机一次只能方便地运行有限的工作。后来，操作系统通过进程、线程、任务调度等机制，让不同程序能够共享计算资源，并由系统负责协调。
用户不需要亲自安排 CPU 下一秒执行哪个程序。
同样，如果未来每个人都拥有大量 Agent，我们也不应该亲自管理每个 Agent 的会话和执行过程。
管理 AI 的工作，本身就应该成为 AI 系统的工作。
02 DeepSeek 做了一件事：把接话和干活分开
为了解决这个问题，DeepSeek 提出了 Router 和 Worker 双层架构。
可以把它理解成一个团队。
你只需要和一个负责统筹的人沟通。
你说：“帮我准备下周的产品发布。”
他会把工作拆成若干可以独立推进的任务，分别交给负责资料、设计、文案和技术的人。
你不需要跑到每个人那里重复介绍背景，更不必每天逐个询问进度。
等到事情出现冲突，或者需要你做决定时，再由负责统筹的人找你。
Super-agent 的思路与此类似。
它有两个层次。
Router 负责接收信息、理解任务关系、分派工作和与用户沟通。
Worker 负责执行任务，每个 Worker 有自己的上下文和工具。
这里有一个很容易忽略的细节。
Router 并不是一个能力更强、负责指挥所有工作的超级模型。
恰恰相反，DeepSeek 希望 Router 尽量轻。
它不应该亲自写代码、运行复杂命令，甚至可以不给它 Bash 这样的执行工具。
真正复杂的工作交给 Worker。
为什么要这样设计？
因为协调与执行是两种不同的工作。
协调需要知道任务之间有什么关系、哪些工作已经分派、谁需要收到什么信息。
执行则需要深入具体任务，阅读大量代码、调用工具、分析错误、反复尝试。
如果把这两件事放在同一个 Session 里，就容易产生两个问题。
一是任务执行会阻塞沟通。
比如 Agent 正在等待一条耗时命令返回，此时你希望修改另一项任务，它可能无法及时处理。
二是上下文容易互相干扰。
写代码时产生的大量日志、调试信息，和另一项研究任务并没有什么关系，却可能被塞进同一个上下文窗口。
Router/Worker 架构的价值，就是把这两种工作分开。
Router 维持全局连续性，Worker 保持任务独立性。
而且一个 Worker 内部还可以继续调用 Subagent，或组成自己的 Agent Team。
也就是说，整个系统不是简单地把一个大模型替换成很多小模型，而是重新划分了不同工作的责任。
这就引出了原文一个很有冲击力的判断：
Session 应当是系统的实现细节，而不应成为用户的认知负担。
什么意思？
我们现在习惯打开一个聊天窗口、创建一个新对话，实际上很大程度上是在适应大模型 API 的组织方式。
但用户真正关心的，从来不是开了几个 Session。
用户关心的是事情有没有完成。
在未来的个人 AI 助理中，你可能始终只面对一个助理，但它背后已经启动了几十个独立执行过程。
这些过程如何创建、暂停、恢复、结束，都可以由系统管理。
就像我们使用手机时，不需要亲自安排操作系统里的进程一样。
从这一刻开始，聊天窗口不再天然等于工作的边界。
03 Agent 不再等你开口，而是开始接收环境中的事件
仅仅有 Router 和 Worker，还不足以构成真正的个人助理。
因为传统 Agent 有一个特点：你不向它发出指令，它通常就不会开始新的工作。
DeepSeek 想改变这一点。
它引入了一个很关键的概念：Trigger。
Trigger 可以理解成触发事件。
比如：
收到一封会议邀请邮件，是一个事件。
GitHub 上有人提交了代码评审意见，是一个事件。
某项测试失败、某个日程即将开始、某项工作需要审核，也都可以成为事件。
以前，这些事情往往需要人看见以后，再告诉 Agent 应该怎么处理。
现在，系统可以直接接入事件源，根据事先设定的规则，判断是否需要采取行动。
但这里马上出现一个新问题。
如果 Agent 能够看到大量外部信息，它怎么知道哪些事情值得处理？
想象它进入一个有几百人的工作群。
每天可能有上千条消息，大部分只是普通交流。
如果每条消息都交给大模型深入判断，不仅成本高，而且很容易产生无意义的工作。
所以 DeepSeek 使用了两级过滤。
第一层是程序规则。
比如消息来自哪里、发送者是否在白名单、是否明确提到了 Agent。这些能够明确判断的事情，直接用代码处理。
第二层才是语义判断。
当一条消息通过第一层过滤后，再让模型结合上下文判断：这是不是一项真正需要处理的工作？
这种做法借用了计算机系统中的 Fast Path 和 Slow Path。
能快速确定的事情，走快路径；需要复杂理解的事情，才走慢路径。
它背后的原则很朴素：
不要把每一项判断都变成模型推理。
接下来还有一个更巧妙的设计。
假设你让 Agent 修改一个 GitHub 项目。
Router 已经把任务交给 Worker A。
后来，有人在同一个 Pull Request 里补充了一条评审意见。
按照传统做法，Router 又要读一遍消息，再判断应该把它交给谁。
但实际上，这条消息明显属于 Worker A 正在处理的任务。
所以 DeepSeek 引入了 Thread 订阅机制。
一个任务开始执行后，Worker 可以订阅相关的 Thread。
此后，这条 Thread 上的新消息，就可以由程序直接交给对应 Worker，不必每次都经过 Router 重新分派。
这有点像你已经知道某个项目由哪个同事负责，后续项目资料就直接送到他那里。
只有出现新的任务或者跨任务协调问题，才需要重新找负责人。
这个设计看起来很小，却减少了大量重复协调。
DeepSeek 的实验显示，去掉这种直通机制，任务完成时间基本没有变化，但 Router 需要做的决定增加了约 30%，系统读取的缓存 Token 增加了约 37%。
也就是说，直通机制不一定让单项工作更快，却能减少系统管理工作的开销。
这恰恰是 Super-agent 的一个重要方向：
不只是让 Agent 更能干，还要让整个 Agent 系统少做无效的事。
04 上下文不是越大越好，而是需要的时候能找到
前面的架构解决了任务分工，但还有一个问题：
Router 如何记住所有工作？
假设这个系统已经运行了半年。
你在不同时间交给它几十个项目，产生了大量聊天记录、代码修改、文档和任务状态。
某天，你突然问：
“上个月那个产品方案，最后为什么没有采用？”
Router 不可能把过去半年所有信息都一直放在上下文窗口里。
上下文窗口再大，也有容量和成本限制。
而且，把大量无关信息塞进去，还可能干扰模型的注意力。
DeepSeek 在这里借用了另一个计算机系统思想：
把模型的上下文窗口当成缓存。
缓存是什么？
你可以把它理解成工作桌面。
桌面上应该放现在需要使用的东西，而不是把整个档案室的资料全部堆上来。
真正重要的是，需要某份资料时，能够迅速找到。
DeepSeek 采用两个基本动作：Inline 和 Spill。
Inline，就是把很快可能用到的信息直接放进上下文。
Spill，则是把暂时用不到的大量信息保存在外面，只留下摘要或引用。
如果需要完整内容，再通过工具读取。
这还不够。
系统需要知道不同信息之间有什么联系。
例如，一条消息属于哪个 Thread，哪个 Worker 负责这项任务，这个 Worker 又关联了哪些代码评审。
于是，系统给这些对象建立唯一标识，并通过引用把它们连接起来。
当 Router 想寻找一项过去的工作，就可以沿着这些关系逐步找回相关信息。
DeepSeek 将这种方式称为 Chain of Recall，链式召回。
这里有一句很值得记住的话：
浪费上下文窗口，就是浪费模型的智能。
不过，这套方法也有边界。
它擅长找回已经建立关联的任务历史，却不一定能发现那些过去没有明确关联、后来才体现出价值的信息。
比如，你半年前在一个项目中总结的经验，可能适用于今天一个完全不同的项目。
但两个项目没有共享 Thread，也没有共同的任务标识。
系统怎样发现这种关联？
这就从上下文管理问题，进入了更困难的长期记忆问题。
保存过去发生过什么，和理解过去的哪些经验对现在有用，是两件不同的事。
05 合上电脑，Agent 还在跑，真正改变的是什么？
传统本地 Agent 经常把三件事情绑在一起：
推着 Agent 运行的计算、需要保留的会话状态，以及实际执行任务的电脑环境。
如果你的电脑关机或休眠，这三件事情往往一起停止。
DeepSeek 希望把它们拆开。
计算可以在云端运行。
任务和会话状态可以保存在持久化数据库里。
真正的工作环境则不必全部搬到云端，可以继续留在你自己的电脑上。
例如，你的电脑里可能有尚未提交的代码、本地开发环境、私有工具以及公司内网资源。
要把这些东西完整复制到云端，并不容易，也不一定安全。
所以可以让云端 Agent 持续运行，在需要访问本地环境时，通过电脑上的轻量服务连接它。
DeepSeek 把这种方案称为 BYOM，Bring Your Own Machine。
这样一来，即使你合上电脑，云端 Agent 仍然可以处理其他不依赖这台电脑的工作。
需要使用本地环境的任务，则可以等待设备重新上线后继续推进。
因此，“合上电脑，Agent 还在跑”并不意味着离线电脑还能执行命令。
它真正意味着：
Agent 的生命周期，不再必须与某一台电脑的生命周期绑定。
这是个人助理成为长期服务的重要条件。
但运行时间变长以后，又会产生新的问题。
以前 Agent 执行几分钟，出了问题，人可能很快就能发现。
现在它可能连续工作几小时，甚至几天。
如果它一直在重复无效步骤怎么办？
如果程序没有崩溃，却逐渐偏离了最初的目标怎么办？
DeepSeek 因此设计了一个独立的 Watchdog，也就是看门狗。
它不只是检查程序是否在线，还要观察 Worker 有没有实质进展，是否陷入循环，是否需要恢复或调整。
这说明 Agent 系统的健康标准正在变化。
传统程序经常检查的是：它有没有正常运行？
长期 Agent 还要检查：它是不是仍然在做正确的事情？
当然，让另一个模型监督当前模型，并不能自动保证结果正确。
Watchdog 自己也可能判断错误。
因此，未来仍然需要外部验证、任务约束、人工接管和可检查的执行记录。
一个系统还在运行，不等于它还在朝正确的方向前进。
06 这些工程设计，真的有效吗？
DeepSeek 并没有只提出架构，也做了初步实验。
他们构造了一组包含约 300 条消息的工作负载，其中大约 20 条是真正的工作请求，其余是普通聊天、后续意见、取消请求和 CI 消息。
然后比较不同的 Agent 组织方式。
一种是 Super-agent，采用 Router/Worker 双层架构。
另一种是单 Session 加 Subagent 工具，由模型自己决定什么时候应该把任务交给其他 Agent。
结果发现，在这组实验中，Super-agent 的任务完成时间中位数为 12.4 分钟，p95 为 15.7 分钟。
而使用中性提示词的单 Session 方案，p95 达到了 29.5 分钟。
其中一个很有意思的现象是：
在五次实验中，使用中性提示词的主模型一次也没有调用 Subagent，而是把所有工作留在主 Session 里执行。
于是，新消息不断打断它，完成时间变得不稳定。
即使修改提示词，要求它优先委派任务，也仍然会遇到模型自行决定不委派的情况。
这揭示了系统设计中的一个朴素道理：
如果某项分工对于系统稳定性非常重要，就不要完全依赖模型临场决定。
当然，这次实验有很明确的限制。
编码工作由只消耗时间的模拟工具代替，每种方案也只运行五次。
因此，它主要说明这套架构在模拟负载下改善了调度表现，不能据此认定 Super-agent 更擅长编写代码或处理真实复杂任务。
而且，维护多个 Worker 本身也会增加 Token 开销。
所以这不是一次免费的性能提升。
它本质上是一种交换：
用更多机器资源和系统复杂度，换取更好的任务并发、协调效率和完成时间稳定性。
真正值得进一步验证的是，这种交换在多长的任务、多大的团队和多少并发量下最划算。
还有一项成本，实验尚未充分衡量。
那就是人的注意力。
如果一个系统完成二十项工作，需要用户介入三十次；另一个系统完成同样的工作，只需要用户介入五次，而且任务质量与安全性没有下降，那么后者显然创造了额外价值。
这也正好对应 DeepSeek 开源原型中的一条设计原则：
尽可能少地占用人的注意力，尽可能多地创造价值。
它甚至要求，Agent 不要为了展示自己正在工作而频繁发消息。
只有需要人作决定，或者确实有可用的结果时，才应该主动出现。
这或许比让 Agent 看起来更加活跃更重要。
07 这是不是下一代个人 AI 助理的架构？
我的判断是：是，但还不是完整答案。
DeepSeek 这次探索的价值，在于它把 Agent 从一次次独立的任务执行，推向了一个持续运行的工作系统。
它给出了一种可行的组织方式：
一个统一的交互和协调入口，背后是多个独立执行的 Worker。
系统可以持续接收环境事件、管理任务状态、恢复工作，并在必要时请求用户介入。
这套思想并不只适用于写代码。
想象一个未来的个人助理。
早晨，你收到会议邀请，它先检查日程冲突，准备会议相关资料。
白天，你交代它跟进几个项目，它在后台分别推进。
下午，某项任务遇到必须由你决定的问题，它才来询问。
晚上，你想了解今天做了什么，它可以从各个任务中整理结果，而不是要求你打开十个聊天窗口逐个查看。
这种体验背后，很可能需要类似 Super-agent 的持续状态、事件处理、任务调度和执行机制。
但我们必须区分架构设想和已经实现的产品。
DeepSeek 公开的 dsh-superagent-prototype 目前主要是一个面向单个 GitHub 仓库的研究原型，可接收 GitHub 和可选的飞书消息。
官方也明确说明，原型不等于正式产品，论文中的部分设计尚未在公开代码中实现。
它还不是一个能够全面管理个人生活的成熟 AI 助理。
更重要的是，即使未来把这些工程机制全部实现，也仍然有三个困难的问题。
第一个问题：它能记住任务，但能不能理解长期目标？
假如三个月前，你让 Agent 优先寻找稳定工作。
三个月后，你决定创业，开始把时间和资金投入新项目。
一个保存了全部聊天记录的 Agent，当然能找到这两段信息。
但它知道哪个目标现在有效吗？
知道新目标是否完全取代旧目标吗？
如果两者发生冲突，它应该自行判断，还是重新向你确认？
这不是简单增加上下文窗口就能解决的。
它需要一种能够持续更新的用户目标模型。
第二个问题：它能持续执行，但谁决定它可以做什么？
一个个人助理可能同时连接邮件、文件、日历、工作平台和本地电脑。
这意味着它不仅掌握信息，还可能拥有修改信息、发送消息、执行命令的能力。
如果一封不可信的邮件包含诱导指令，Agent 会不会把它误认为用户授权？
如果一个 Worker 处理公司项目，能否访问私人资料？
如果用户改变主意，已经启动的任务如何取消、回滚或重新授权？
未来的个人助理必须将信息、权限和行动区分开来。
它可以知道一件事，不代表它就被允许依据这件事采取任何行动。
第三个问题：它能积累历史，但会不会真正从经验中成长？
这可能是最值得深入研究的问题。
假设一个 Agent 已经陪你工作了三年。
它完成了几千项任务，保存了大量工作记录，也能随时找到过去的资料。
那么，它是否真的比第一天更有能力？
未必。
因为保存经验、调用经验和从经验中形成新能力，是三个不同的过程。
一个系统可能拥有大量历史，却仍然重复犯同样的错误。
也可能把过去某个场景中有效的方法，错误地迁移到另一个场景。
真正的能力形成，至少需要从经验中提炼规律、在新任务中使用这些规律，并且通过独立评估证明这种方法确实让任务完成得更好。
这并不必然要求修改大模型的参数。
它也可能表现为更好的任务策略、更成熟的工具使用方式、更可靠的 Skill，或者更准确的环境判断。
但无论采用哪一种方式，都需要回答同一个问题：
过去的经验，究竟在什么条件下变成了未来能够稳定使用的能力？
这比让 Agent 保存更多记忆困难得多。
08 AI 能一直工作，然后呢？
回头看 DeepSeek 的这次探索，会发现它做的事情其实非常朴素。
Router/Worker 借用了控制与执行分离的思想。
事件过滤借用了 Fast Path 和 Slow Path。
上下文管理借用了缓存与局部性。
后台执行借用了异步和投机执行。
长期运行借用了存算分离和外部监督。
这些都不是计算机科学中的全新发明。
但它们被重新组合起来，开始解决一个新的问题：
怎样让一组具备推理和行动能力的模型，像一个可靠的系统一样长期工作？
这也许是 Agent 技术演进中一个值得重视的节点。
过去，我们主要努力让 AI 学会完成任务。
现在，我们开始让 AI 系统学会组织任务、协调任务，并在没有人持续盯着的情况下推进任务。
在这一阶段，用户不再需要亲自管理每一个 Session，可能只是最先出现的变化。
接下来，更多工作会从人转移到系统：状态维护、信息召回、事件判断、异常恢复，以及不同 Agent 之间的协调。
但这条路还没有走完。
任务调度可以交给系统，人的长期目标却不是简单的任务队列。
一个真正有价值的个人助理，除了知道现在该做什么，还需要理解为什么做、什么时候不该做，以及过去的经验究竟能为未来提供什么帮助。
因此，我更愿意把 Agent 接下来的演进理解成三个阶段：
第一阶段，让模型能够完成任务。
第二阶段，让系统能够持续组织任务。
第三阶段，让经验能够转化为经过验证的持久能力。
DeepSeek Super-agent 认真推进了第二阶段，也为第三阶段提供了一种可能的运行基础。
它还没有给出所有答案。
不过，它让我们看到，未来的 AI 助理应该是一个可以持续协作、能够接受监督、也能在适当时候把判断权交还给人的系统。
而当我们真的能够让 Agent 一直工作以后，可能还有一个更值得追问的问题：
一个陪你工作了三年的 Agent，究竟应该比第一天多会些什么？
这个问题的答案，或许会决定下一代个人 AI 助理最终能够走多远。
资料来源
DeepSeek Harness，《Exploring Super-agent Design: Towards a More Autonomous Agent System》，2026 年 10 月 31 日。原文发布于 DeepSeek Harness 官方账号。
DeepSeek 官方开源原型：dsh-superagent-prototype
官方原型设计哲学：000 Philosophy
官方原型系统架构：007 Architecture
官方原型授权机制：002 Authorization
>/作者：王零壹，920.org.cn（AI Research Institute）创始人，港大AIBT研究生，前上市公司 CMO。长期研究 AI 产品、Agent 架构与商业增长，并持续观察技术变迁如何重塑人的工作、判断与生活。
*著有《AIGC从0到1》系列丛书、及东方寓言小说《飞将军》；
*善于洞察先机，中文互联网第1个意识到OpenClaw范式价值的人（1月26日）；
关注我，一起AIGC从0到1~
