作者：望宸
DeepSeek 在 8 月开源了 DeepSeek Harness，核心思想是：一切插件化。
我们在《一切皆插件之后，Agent 工程的新范式》一文中提到过：
LangChain 范式做了各种抽象，是为了降低 Agent 开发复杂度设计的；Deepseek Harness 则是为了降低 Agent 体验和成本优化复杂度设计的。因为插件化颗粒度越细，Agent 的运行会越透明。阶段不同，框架的使命不同，就会带来不同的架构思想。想要大幅提升应用的智能，需要从架构上做创新。
但两者都属于帕累托前沿，没有绝对最好，只有取舍。 Deepseek Harness 提升了架构的透明度，但也带来了工程上的复杂度。这次开源的dsh-superagent-prototype，是对 Agent "连续实体"能力的工程拆解。
什么是 Agent "连续实体"？
dsh-superagent-prototype 提出了 Super-agent 的概念："打破 Agent 与单次手动会话的绑定，使其成为一个能跨会话保持上下文、同时推进多项复杂任务且互不干扰的"连续实体"。我们把这种 Agent 形态及其系统架构称为 Super-agent。"
听上去有点抽象，我们来看一个具体的办公场景。
早上主管在 IM 群让我撰写一份季度汇报材料，汇报时长控制在 20 分钟，随后，我把任务交给了 Agent。但到了下午，主管转发了一份+2的邮件，要求改为 10 分钟，重点讲未来规划。此时，我需要手动同步 Agent 界面外的上下文。
如果按 DeepSeek 说的"连续实体"来做，下午我收到需求变更时，Agent 会自动识别出它和早上在 IM 群里说的是同一件事，并自主更新任务。过程中，不需要人来介入。因为，多任务的上限取决于人的注意力。
DeepSeek 之所以要为"连续实体"这个场景专门开源一个插件包，是为了让 Agent 从单个会话里的长程任务，走向跨会话、跨应用、跨端持续推进多项任务，以解锁更多的生活和工作场景。
Agent "连续实体"的技术特征
上方的场景比较简单，但实际工作和生活中，多实体间的任务远比这复杂的多。当前，是人在做不同实体间上下文的传递和加工者，这显然会影响 Agent 自主性的发挥。
即便是这个简单的办公案例，但在工程实现上，要完成好几件事：接收到邮件，识别出这是同一份季度汇报的新要求，找到正在执行的任务，再让后面的工作按新要求继续。
DeepSeek 用四个形容词概括这种形态的技术特征：连续、高效、主动、持久。但中文里最难具像化的就是形容词。我们依旧借助场景来加深理解。
连续： IM、邮件是不同的交互渠道。"连续"指的是，同一个 Agent 能把不同渠道里关于同一件事的信息接起来，让任务持续推进，而不需要用户反复搬运上下文。
高效： 交互响应迅速，同时能并行、高质量地完成多个复杂任务。无需等上一个命令或任务完成，就能接受下一条指令。例如复杂任务，Agent 若干小时才能完成，期间收到不同渠道的需求，要能实现" 插话"功能，从而高效地、不必等到这个任务结束才处理新需求。
主动： 无需等待用户逐条下达指令，能持续观察环境事件并主动推进值得处理的事项，不需要介入时则保持安静。例如我们扩展下上方的办公场景，11:20，同一个 IM 群里，大家在讨论周五团建去哪儿。这和汇报无关，Agent 不用回复 ，也不影响正在做的工作。13:10，财务在群里发了第三季度的最终数据，有两项和初稿里用的数字不一样。这和汇报直接相关，Agent 则需要主动更新图表，并记下修改了哪些地方。
持久： 始终在线、直接接入用户真实的工作环境，并在长期运行中遇到异常时自动恢复。Persanal Agent 就是典型的始终在线或者说全天候任务，解锁了认知价值低、体验碎品化、流程摩擦高的生活类场景，这种持久的能力，对以周、月、年为单位的科研工作帮助也很大。
其中，连续比较容易和 Agent 的全局记忆混淆。记忆是知识层面的连续，运行层面的连续，则依赖更多的工程手段。
人的注意力是有限的，有了 Agent 后，我们扮演了在不同消息渠道和任务之间传递和加工信息的角色，Agent 的连续、高效、主动、持久正是为了释放我们的注意力，从而能解锁更多场景。
增强 Agent "连续实体"能力，需要哪些工程能力？
DeepSeek 认为单个 ReAct Loop 无法同时支持上述四个特征，底层需要一套相应的架构。在具体落地中，这套架构虽然会有不同的变体，但以下五个模块构成了支撑上述四个基础特征的基本框架：双层架构、事件驱动、面向人的交互、计算、状态与环境的分离、Watchdog。
但无论是简单任务、长程任务，还是跨实体的自主任务，都离不开 Agent 的行动主线，即任务、信息和行动。 任务定义如何推进、中断如何恢复、完成如何判定。信息定义有限模型窗口与持续增长的任务世界之间如何取舍。行动定义意图如何被授权、执行与验证。
图 1：Alibaba Cloud AI Agent Handbook 构建篇
接下来，我们会通过一些经典的软件设计思想来加深理解这些模块。
| 模块 | 熟悉的软件设计概念 | 在 Agent 中解决的问题 |
|---|---|---|
| 双层架构 | 调度与执行分离 | 协调者保持响应，执行者并行工作 |
| 事件驱动 | 消息队列、异步通信、发布---订阅、缓存 | 程序的多样化驱动 |
| 计算、状态与环境分离 | 无状态服务、共享存储、远程执行 | 更换计算实例不丢必要状态，工作环境不用整体迁移 |
| Watchdog | 健康检查、外部控制循环 | 不仅检查服务存活，还检查任务是否在推进 |
这些模块的定义和 Alibaba Cloud AI Agent Handbook 运行篇中的概念有很多共通之处，但在 Super-agent 的场景下，系统架构还有大量的演进空间。
图 2：Alibaba Cloud AI Agent Handbook 运行篇
1、为何要做双层架构？
回到之前办公场景的案例，我们来增加一个事件：Agent 正在汇报初稿，我又让 Agent 整理一批客户反馈，中间还随口问了一句"Q2 的产品留存率是多少"。三件事几乎同时到来，Agent 该怎么安排？
一种是所有事情都交给同一个会话。上下文最连续，它知道上午写了什么，也知道下午改了什么。但一个 ReAct Loop 只能一步一步往下走，改汇报的时候，客户反馈只能排队。但缺点是吞吐低，而且多任务的中间细节混杂在一起，会影响完成效果。
另一种是每来一条消息，就新开一个会话，并发最高。但下午那封邮件会被当成一件新事，新会话依赖全局记忆来保障输出效果，但是一旦上下文超出全局记忆的边界，Agent 效果就会受影响。
第一种优先上下文一贯性，第二种优先吞吐量，我们称之为会话组织上的权衡。
这和软件系统里的调度与执行分离很接近：一部分负责接收请求、安排工作，另一部分专注执行。 从团队协作看，Alibaba Cloud AI Agent Handbook 在第 11 章 Multi-Agent 协作与编排中，归纳了主管---执行、对等协作和分层编排三种常见拓扑。
图 3：Alibaba Cloud AI Agent Handbook 第11章 Multi-Agent 协作与编排
- 主管---执行： 主管协调目标和分工，执行者自主完成局部工作，关键是别让所有决定都等主管。
- 对等协作： 成员直接协商，沟通路径短，但要明确共同决策和最终交付责任。
- 分层编排： 按专业小组组织交付，减少顶层需要处理的细节，也增加层间协调成本。
这里最接近 DeepSeek 双层架构的是主管---执行：由一个入口协调，多项工作独立推进。但 DeepSeek 对"主管"的职能做了收缩。
常见的 Agent Team 里，Team Lead 往往要深入理解任务细节、拆分子任务、高频协调各个成员，自己承担了很重的推理负载。如果所有信息都必须先汇总到一个主管 Agent，再由它决定每一个步骤，主管就会成为新的上下文和执行瓶颈。
DeepSeek 的 Router 层只做两件事：承接所有入口的人类交互，处理任务之间的分派与协调。 它不介入单个任务内部怎么拆，也不亲自执行，甚至可以不配备 Bash 工具，用较轻量的模型往往就够了。 具体的工作交给 Worker 层。每个 Worker 上下文隔离，挂载完整的执行工具，通常配置能力最强的模型。Worker 不直接对外说话，而是向 Router 汇报，由 Router 统一回复用户。
双层架构也吸收了另外两种拓扑的长处。Worker 内部可以再创建 Subagent，甚至本身就是一个 Agent Team，这些对 Router 保持透明，有点像分层编排里的小组。多个 Worker 订阅了同一个讨论时，会收到相同的事件通知，有机会自己发现并解决冲突，又和对等协作里共享讨论空间的做法相似。
读到这里，可能会有两个疑问。
第一，所有入口都汇到 Router，它会不会被挤爆？
DeepSeek 的答案是批处理。 Router 上一轮推理期间到达的消息会积压下来，下一轮一起处理。Router 每一步通常是长输入、短输出，多条消息合进一次模型调用，耗时的增长远慢于消息数量的增长。压测里，需要决定的消息从每分钟约 1 条增加到约 40 条，平均每批从 1.0 条增至 2.8 条，单次请求耗时只从 2.5 秒增至 3.9 秒，分摊到每个决定上的推理时间反而从 6.4 秒降到 1.6 秒。
这和数据库批量写入的思路相似：把多次操作合在一起，摊薄每次调用的开销。但批处理提高的是有效吞吐，并不保证每条消息的等待时间都更短。 规模如果再大，Router 也可以切分成多个会话。但切得越细，分片之间的上下文就越不连续。DeepSeek 认为，在全局记忆问题解决之前，这个权衡始终存在。
第二，一个会话加上 Subagent 工具，不也能分工吗？
DeepSeek 做过对比。约 300 条消息里混着约 20 个工作请求，每种方案跑 5 次。只给中性提示词时，主会话 5 次里一次都没有调用 Subagent，所有工作都自己干，还不断被新消息打断，p95 完成时间达到 29.5 分钟。把提示词改成优先委派后，5 次里有 4 次分了工，整体仍慢于双层架构；剩下 1 次，它判断活"很小"，又自己干了。双层架构的 p50 和 p95 分别是 12.4 分钟和 15.7 分钟。
图 4：《Super-agent 设计探索：迈向更自主的 Agent 系统》
分不分工，不该取决于提示词写得好不好、模型怎么判断，而应由架构来保证。
2、事件驱动：跨实体任务的必备模块
事件驱动一词，我最早是在函数计算中接触的，因为函数计算的运行时不是常驻的，依赖外部事件触发，例如数据库的变化、网络的变化等。
那 Agent 的工作有哪些驱动方式？人的指令，以及环境中的事件，例如一封邮件、一个钉群信息、一个日历提醒、一个来自 GitHub 的 PR，甚至是一份还款提醒。
DeepSeek 把群聊消息、邮件、日程提醒、代码评审评论、CI 运行结果这类环境事件统称为 Trigger。一条 Trigger 从进入系统到被处理，要依次回答四个问题。
第一问：这条消息需要 Agent 处理吗？
接入真实的群聊和邮箱后，绝大多数消息都和 Agent 无关。11:20 大家讨论团建去哪儿，就属于这一类。如果每条消息都让大模型从头判断一遍，延迟和成本都会成为瓶颈。
DeepSeek 借用了计算机系统里 Fast Path 和 Slow Path 的思想，做了两级过滤。
- 第一级是程序规则。消息来自哪个群、哪个邮箱，发消息的人在不在白名单里，这些确定的条件直接用代码判断，在调用模型之前就筛掉大部分无关消息。
- 第二级才交给大模型。通过第一级的候选消息，由模型结合上下文和用提示词写好的策略，判断要不要行动。13:05 财务在群里发的第三季度最终数据，就需要由模型看出它和汇报是否直接相关。
这很像邮箱的收件规则加上一位秘书。广告和订阅邮件，由规则自动归档；剩下的，再由秘书判断哪些需要老板亲自处理。
第二问：这条消息该交给谁？
过滤后的消息，需要找到它该影响的任务。如果每条消息都让 Router 重新判断一次，Router 又会成为瓶颈。
DeepSeek 引入了 Thread 的概念：同一个 IM 话题、同一串往来邮件、同一个 PR 下的连续消息，构成一条 Thread。Router 根据某条 Thread 的第一条消息创建 Worker 后，这个 Worker 会订阅这条 Thread。之后同一条 Thread 里的消息，由程序直接送到 Worker 手上，不再经过 Router，这叫订阅直通。只有还没被订阅的新消息，才需要 Router 来判断和分派。
回到本文的办公场景。早上主管在 IM 群里布置汇报，Router 创建了汇报 Worker，它订阅了这个 IM 话题。下午的邮件是一条新的 Thread，先到 Router，Router 判断它和汇报是同一件事，交给汇报 Worker，Worker 再订阅这串邮件。此后邮件里的往来回复，也都走直通。
订阅是多对多的。一个 Worker 可以订阅多条 Thread，汇报 Worker 就同时订阅 IM 话题和邮件；一条 Thread 也可以被多个 Worker 订阅。Router 仍然能看到所有消息，掌握全局。如果新消息超出了当前任务的范围，Worker 也可以退订，或者交回 Router 重新分派。
这和消息系统的订阅关系很接近：先确定消息归属并建立订阅，后续按已有关系投递，不必每条消息都重新判断。 DeepSeek 在这里把已知关系交给程序，把尚不明确的归属交给模型；借用的是发布---订阅的思想，不代表实现必须依赖某一种消息队列。
直通的价值主要体现在成本上。DeepSeek 的消融实验里，去掉直通后，任务完成时间基本不变，但 Router 需要做的决定增加了约 30%，读缓存 token 从 2323 万增加到 3177 万，增幅约 37%。
第三问：怎么找到之前的那件事？
Router 能判断"下午的邮件和上午的汇报是同一件事"，前提是它还找得到上午那件事。可长期运行下来，历史任务越来越多，Router 不可能把所有历史都塞进上下文窗口。
DeepSeek 把上下文窗口当作缓存来管理，借用了编译优化里的两个词。 Inline，是把近期很可能用到的信息直接放进窗口，省掉一次工具调用；Spill，是把放不下或不常用的完整内容留在窗口之外，只保留摘要和引用，需要时再去读。
更关键的是，每条消息、每条 Thread、每个 Worker 会话都有自己的 ID，注入上下文时会附带紧密相关对象的 ID。一旦下午的邮件与汇报任务建立了关联，模型就可以从邮件所在的 Thread 找到汇报 Worker，再从 Worker 找到上午的 IM 话题。DeepSeek 称之为链式召回。
这有点像查资料时顺着参考文献往下翻。每篇文章末尾都列着下一篇的出处，不用一次把整个图书馆搬到桌上。链式召回主要解决的是近期任务与会话历史的检索；跨月甚至更长时间的长程记忆，仍是一个开放问题。
第四问：还没正式下指令，能不能先准备？
CPU 里有一种技巧叫投机执行：分支的结果还没确定，就先按最可能的方向算下去，猜对了直接用，猜错了就丢掉。DeepSeek 把这个思想用在了 Agent 上，根据环境信号在后台提前尝试，用额外的算力换人的等待时间。
继续扩展下办工厂场景。14:30，主管在群里随口说了一句"+2 最近好像更关心明年的规划"。这还不是正式要求，Agent 不必动汇报，但可以在后台先整理一份未来规划的提纲。16:10 转发的邮件到了，要求改为 10 分钟、重点讲规划，提纲马上派上用场。如果邮件一直没来，这份提纲就不需要打扰任何人。
投机执行改变的是准备的时机，不改变谁有权做决定。后台准备的内容在被确认之前只是草稿，不能当作正式要求去改动交付物。
这四个问题就是一条事件在 Super-agent 里的完整旅程：先过滤，再路由，再找回上下文，必要时提前行动。这些其实和经典互联网架构中的服务通信、消息队列的都有着共通之处。
3、计算、状态与环境的分离：全天候任务的标配
从 Personal Agent 的影响面看，全天候任务已经成为 Agent 的标配，不然无法解锁更多场景。
Agent 通常包括三个模块：推进 Agent Loop 的计算，需要持久保存的会话状态，以及本地文件、代码仓库、各种工具的执行环境。18:30，我关掉办公室的电脑下班，汇报还没改完。我们希望不依赖本地设备的工作继续在云端推进；但读取本地文件、访问特定内网等步骤，仍要等这台电脑上线。
要做到这点，需要：
第一步：计算和状态分离。
推进 Agent Loop 的计算放进云端无状态的弹性容器，Session 这类需要持久保存的状态存进数据库。容器可以水平扩展、重启或替换，新实例能够读取已有状态，而不必把任务重新当成一件新事。
这和 Web 应用处理登录状态是一个道理。如果 Session 只存在某台服务器的内存里，后续请求就需要回到能访问这份状态的节点；这台服务器重启后，未持久化的状态还可能丢失。常见做法是把 Session 放进 Redis 这类共享存储，让不同服务器都能取得同一份登录状态，不再与某台机器绑定。云端的 Agent Loop 与外部会话存储，也采用了类似的分工。
不过，共享 Session 解决的是换台服务器后还能找到状态，并不保证正在执行的工作自动恢复。Agent 还需要知道接着执行哪一步，以及上一条工具命令是否已经生效。状态保存是恢复的基础，不是恢复的全部。
这也解释了为什么 Router 可以"常驻"，计算容器却可以无状态：持续存在的是协调职责和会话状态，不要求承载它的某个进程永不退出。
第二步：计算和执行环境分离。
Agent Loop 上云之后，新问题来了： 汇报的初稿在我办公室的电脑上，财务系统只能在公司内网访问。Agent 需要的上下文，很大一部分要通过工具从这些环境里取，广义的上下文也包含了执行环境本身。
常见做法有两种。
- 在云端起一个沙箱，把环境复制过去。但真实的工作环境里有未提交的本地修改、私人凭据、只能在内网访问的服务，以及特定的硬件和工具链，复制成本高，还容易漏。
- 让用户搬到云端工作。这对大部分企业而言很难执行，因为财务、员工等私密信息需要留在本地环境。
DeepSeek 的选择是： 环境不搬，留在原地。端侧只装一个轻量的 daemon，它不保存会话状态，只负责执行命令、返回结果。这有点像 CI 系统里的 Runner：调度在中心，活在各台机器上跑，Runner 自己并不记得流水线走到了哪一步。
这和 Anthropic 提出的"脑手分离"是一个思路：大脑负责决策，双手负责执行，中间用统一的接口连接。区别在于 Anthropic 讨论的是托管服务里按需创建的沙箱，DeepSeek 接入的是用户日常使用、可能时而在线时而离线的个人电脑，也就是 BYOM（Bring Your Own Machine）。
拆完之后，一个 Agent 可以按任务需要选择具备相应文件、工具和权限的设备执行命令，并不是任意机器都能替代原来的环境。它也可以等待设备上线：第二天早上我打开办公室的电脑，云端 Agent 再核对等待中的步骤，把修改结果写回本地 PPT，并从内网财务系统核对数字，完成最后的交付。
这套设计默认云端和端侧彼此信任。一旦云端被入侵，或者被提示词注入攻破，连上来的所有设备都有风险；凭据如果进入模型的上下文，也可能泄露。
4、Watchdog：观测+恢复
持久在线，不仅是持续观测，还得在长期运行中能从异常里恢复过来。
嵌入式系统里有个经典部件，叫看门狗定时器。主程序要定期"喂狗"，一旦程序卡死、超时没喂，看门狗就把系统重启。
持久在线的分布式系统同样很难只靠主系统内部的逻辑保证长期可靠，需要在主系统之外引入一个独立的外部控制回路，即 Control Loop。
但 Agent 场景的难点在于，很多故障并不是进程崩溃。
20:00，云端汇报 Worker 的进程一切正常，可它已经第五次调整缓存数据里同一张留存率图表的配色。另一边，邮件接口从傍晚开始间歇性报错。前一种情况，传统的存活探测发现不了，进程活着，只是没有推进任务；后一种情况，重启 Agent 也解决不了，问题出在外部。所以，长期运行的 Agent 系统不仅要监控基础设施是否存活，还要监控任务本身有没有进展。
DeepSeek 的做法是，在主系统之外配置一个独立的 Watchdog Session，用定时消息驱动它定期巡检。
- 基础设施层面，处理接口报错、状态恢复失败这类故障。
- 任务层面，由模型判断每个 Worker 有没有实质进展、方向是否偏离整体目标。
发现异常就介入修复；遇到外部的偶发故障，就持续复查，直到恢复正常。回到办公场景里，Watchdog 看出汇报 Worker 在图表上空转，就提醒它这次汇报的重点是未来规划；邮件接口报错，它就隔一段时间查一次，直到接口恢复。
这很像 Kubernetes 的控制循环：不断对比期望状态和实际状态，有偏差就调整。区别在于，Kubernetes 看的是副本数、健康检查这类程序就能判断的指标，而"有没有实质进展"、"方向偏没偏"，需要模型来判断。
还有一点很有意思：Watchdog 本身也是一个具备完整工具能力的 Agent Session。维护者可以用自然语言问它"昨晚汇报任务为什么卡住了"，也可以让它在线修正主系统的行为，比如增删提示词、调整触发规则。
结语
Agent 经过了对话到动手，简单任务到长程任务的演进，目前已进入解决跨实体任务的阶段。这个阶段对软件系统架构、对工程能力提出更高的要求，这些都还需要更多的工程实践来约束和规范。我们会持续在 Alibaba Cloud AI Agent Handbook（点击文末阅读原文）这一开源项目上记录业内的最新实践，并尝试提炼出一些面向工程的设计规范和架构思路。