一文拆解DeepSeek Harness

开发者公众号专属群聊

扫码加入获取更多一手教程、科技前沿报告

 前言

10 月 31 日，DeepSeek 发了一篇《Super-agent 设计探索：迈向更自主的 Agent 系统》，当天就在圈子里传开了。DSH 即 DeepSeek Harness，下文沿用这个简称。

网上的分享不少，但多数停在解读文章本身、复读概念。可如果把里面那些新名词先放下，会发现这条路从"小龙虾"出现之后，大家或多或少都已经试过——DSH 这篇的价值，不在于提出多少新东西，而在于把很多团队脑子里零散的想法，用一套清楚的描述串了起来。所以文章出来之后，很多人的第一反应是："原来我的 idea 和业界顶尖团队是一致的。"

恰巧，文中的很多观点，和我近半年自己做的一些尝试、调研和思考有重合。下面就从我的视角做一次解读。

01

抛开架构不谈，DSH 要解决的问题其实很简单。官方文章里有一句话很容易被略过：

据我们观察，一个人通常只能同时跟进 3 到 5 个活跃 Session。在这种设计下，单任务的上限取决于模型能力，多任务的上限取决于人的注意力。

多数人读到这句，会把它归到产品体验上：窗口切换太麻烦、界面不好用，要是有个统一看板把所有任务收拢起来看就好了。

但再往下一层，用户"管理 Session"这件事，很大程度上是从底层 LLM API 延续下来的设计范式——记忆、调度、审批、恢复，全都困在一个会话里：

• 并行上：多个任务同时跑，你得逐个查进度、逐个回结果、逐个补信息。任务并行了，协调却退回给人。所以很多时候让 AI 干活，其实很累。

• 单会话上：长程任务跑起来，聊天记录回答不了全部问题——记忆会被压缩，摘要有取舍。等任务真需要背景时，又得回去问人。

• 外部连接上：IM、会议、文档、App 里的信息，要么人手动告知，要么人手动触发，调度权还在人手里。

于是"3 到 5 个"这件事有了另一种解释：不是人的注意力只有这么多，而是本该由系统承担的记忆、调度、审批、恢复，被交给了人。

用文章里一句话概括：

Session 应当是系统的实现细节，而不应是用户的认知负担。

所以 Super-agent 真正要优化的目标，可以从两个角度看：

• 产品目标：最大化 Agent 产出，最小化人的注意力。靠并行度创造价值，靠弱化 Session 这个产品形态降低认知负担。

• 技术目标：Human out of the loop。没有人干预时，AI 也能自主感知外部信息，完成决策、调度、执行。

要达成这两点，关键不是造一个"更强的 Agent"，而是用系统架构，把现在压在人身上的决策、调度、管理接过去。

02

DSH 对 sessionless 的产品形态并没有给出明确定义：是像 Muse 那样的 personal agent 对话框？还是像 TAPD 那样的任务看板？

如果要给 Super-Agent 一个产品形态上的幻想，我脑子里 sessionless 的形态只有一个——"贾维斯"。不妨就假设，未来每个人手里都有一个"贾维斯"App。

任何事只需要一个入口。我说一句"帮我做这个"，它去做，在合适的时候答复我；我也可以随时回头问它某件事进展如何。工作、任务、进度追踪，全由它管理、调度、执行。人在这里享受到的，才是 AI 真正带来的便捷。

要实现这个能力，必须引入一个控制层，也就是 DSH 里的 Router。它可以类比主流 Personal Agent 的 Main-Agent，或者干脆就是一个意图识别器：判断一件事值不值得做、该交给谁、做到什么程度算完成。它不执行，只决策。

官方说 Router 可以很轻量，甚至能用小模型。但通读全文，有一个问题始终没说清：Router 凭什么知道你这句话该派给谁？

 2.1 sessionless的本质

抛开 Super-agent 这个名号，要弱化sessions这个产品形态，更本质的问题其实是上下文管理本身。

现实世界中，事件的上下文来自四面八方：A 项目下面挂着 A、B、C 三个群，B 项目的代码又散在 A、B、C 三个仓库。而真正决定"这次干活和什么有关"的，是与之相关的工作上下文。Session 只是一个临时的执行过程——就像我在 WorkBuddy 里建一个项目，所有 Session 都复用这个工作区的记忆，我在一个会话里面，让他接着干一件事，不需要做很复杂的交代，他便可以知道我在这个空间下，想干什么，改哪些代码，有什么历史信息。

关于上下文的管理，近半年来基本上大家都在研究这个方向，并不稀奇。DSH这套方案的解法，可以理解为Router就是充当一个管理全局上下文的角色，由他来根据历史信息，来决定这个事件/这条消息，我要派给哪个worker去执行。

但这也是我认为矛盾的点：Router 凭什么知道你这句话该派给谁?

从模型能力看：如果 Router 真的可以很轻量，那小模型能不能担这个责任？我们在单个会话里用旗舰模型聊久了都会出幻觉，何况 Router 要理解、调度、裁决全局的复杂上下文。

从安全边界看：一旦 Router 理解错意图，代价不是"答得不好"。比如一句"帮我把某个临时文件删掉"，恰好历史里有同名文件，或者模型幻觉一下，删掉的就可能是重要工作。

 2.2 管理上下文边界

所以 Router 可行的前提，不是它多聪明，而是它能看到的上下文“有边界”，即我们需要一个物理概念上或者逻辑概念上的抽象，把上下文限定在一个工作区之间。

针对前面提及的那些偏差——删错文件、派错单——根源往往不是模型能力不够，而是上下文本身没有边界：所有历史、所有项目、所有渠道糊在一起，怎么判断都是猜。

从官方原型给出的事件源看，事件无非来自三类：群聊、GitHub、项目文档，是大家办公场景中很常见的形态，而这些形态天然在逻辑概念上自带上下文的边界。以群聊为例——在工作场景里，A专项群大概率和B专项群讨论的内容不同，一个群本身就是一个自带边界的工作区Context。

开源产品如：Buzz、Raft、Cumora，在人和Agents协作，都把人和Agents的协作范围限定一个逻辑概念上的工作区/群/频道中。

而一旦上下文被限制在可控边界范围内，Router 的决策就变得可行了。

DSH 提到过几种判断事件的策略，比如 Fast Path（代码规则）和 Slow Path（LLM 决策）。我理解这套机制的前提，同样是前面说的可控边界。

如果边界是可控的，比如一个 IM 群，"谁能访问、在哪个项目里访问"就完全可以用代码规则写死，不必交给模型去猜，回归到类似workflow的思路：在什么条件下，满足什么规则，就可以去做某件事。

且后续所有上下文、所有事项都以这个边界建立关联，工作上下文得以延续，前面那些偏差也就能尽量避开。

 2.3 链式召唤机制

边界解决的是 Context 怎么组织。但单个 Context 里如果跑的是长程任务，必然会沉淀出远超窗口的上下文。

只靠压缩、没有独立机制维护，早期信息必然丢失。反过来，一股脑全塞进去也不对：挤占窗口、稀释注意力；塞得太少，模型又得反复调工具去读，执行步数上去了。

用DSH官方的话说：浪费上下文窗口，就是浪费模型的智能。

所以 DSH 设计了一个很巧的机制——链式召回。简单来讲就是把上下文窗口当 Cache，系统摘要所有对象都有ID，构成一张引用关系图，每次送给模型先只内联摘要和 ID，Agent 需要细节时，再顺着 ID 逐跳取。而放到 Router 层，这个机制同样能缓解长程任务里"早期信息丢失"的问题。

到这里，第二章回答的是“Router 看到什么”：边界决定它看哪一片，链式召回决定它看多深。但这两件事都还停在“理解”层面——理解完之后，一件事怎么被记住、被交接、换个人还能接着做，是另一套东西。

03

前面是站在 Router 的视角，看它面对多个事项时怎么决策。这一节换个视角：从一件工作本身，看它如何被定义、被延续。

以渗透测试为例。如果让 Agent 去做一次渗透，至少需要维护三样东西：渗透目标、当前已知情报、下一步目标拆解。

这其实是仿人类思考的做法——把一件事用数据结构映射出来，得到一个"工作维度上的状态机"。

换一个更日常的例子：@agent 这个 retry 逻辑超时之后会重复扣款，改成幂等的。看看 DSH 是怎么做这层数据映射、怎么定义"一件工作"的。

从表格定义上还是很难看出这里条件的层层扭转，从一个图的角度上来看：

可以发现这些概念各司其职，不是一条龙流水线，而是围绕同一条事件流做不同层面的切分：

• Source 把外部世界翻译成事件；

• Thread 把事件按线索归拢；

• Eval 做一次接单判断，Policy 给它尺子；

• Ticket 让工作有身份，Mandate 给它边界；

• Subscription 让上下文自动流动；

• Assignment 与 Executor 负责真正执行；

• Channel 把结果送回人群。

为什么这些概念不能合并，又或者是为什么不能简化？

假设简化了这里的结构，你说一句"顺便把日志降噪也做一下"，系统可能就多出一张重复工单，或者改错一个地方。所以让工作持续关注且不越界需要同时保存两样东西——事件关系（让系统找到相关 Ticket）和工作约定（限定这项工作可以做什么）。

到这里，“一件事”有了形状：有来源、有身份、有边界、有执行者、有回话的渠道。但这些还是概念——落到机器上，它需要一套静态结构来承载：谁负责判断、谁负责执行、状态存在哪、出问题谁来看。

04

为了达成前述目标，DSH 搭了一套架构。原文说得很清楚，五个模块支撑的是四个基础特征——连续、高效、主动、持久：

• 连续：在 IM、GitHub 等不同界面交互，感觉始终只有一个 Agent；

• 高效：响应快，同时能并行推进多个复杂任务；

• 主动：不等指令，持续观察环境事件并推进值得做的事；

• 持久：始终在线、接入真实环境，长期运行中能自愈。

四个特征与五个模块的对应关系是这样的：

这些模块听起来新，但追到根上，都是传统分布式系统的设计理念，这半年业界也或多或少都在往这个方向落地。

 4.1 调度与执行分离

DSH的文章里面提到了双层架构，引入了Router和Worker层，听起来像是分工，但这里的本质实现延用的是一个更加本质的角色划分：控制面与数据面。

• Router在整个系统中充当控制面：判断一件事值不值得做、该交给谁、做到什么程度算完成。 它不执行，只决策。

• Worker层在整个系统中充当数据面：拿到任务就执行，专注把一个任务交付。

 4.2 计算和状态分离：Agent as a Service

Worker 这个词不足以描述它的性质。更准确的说法是 Agent as a Service：它不是常驻的 Agent 实例，而是一个可调度、可替换的执行服务。这个差别，决定了架构能不能长——也就是能不能真的提升并行度。

网上很多人不理解：为什么非要"用户提问 → Router 分派 → Worker 执行"，把每个环节隔离开、异步化，不是徒增复杂度？

先看常驻实例的思路（Agent in the Sandbox，代表是 WorkBuddy、Codex、Claude Code）：一个实例绑着自己的记忆、工具集、性格。听起来很自然，也不需要分层和异步。但它有个死结——实例不可替代：它挂了，任务跟着挂；它慢了，任务跟着慢；它用的 Harness 过时了，任务只能跟着过时。

从服务化的角度看，状态与计算分离是必然的：把 Agent 的能力定义清楚，执行由谁来做变成可替换，把执行 Loop 做成无状态。今天用这个 Harness，明天换那个；今天跑在这台机器，明天跑在另一台；今天用这个模型，明天换更强的——对上层透明。

Worker 变成无状态服务之后，它就只是一个执行层。执行时的上下文、工具能力，由 Router 决策派发。于是 Agent 的并行度，在任务之间没有依赖的前提下，理论上等于单位时间内可并行的算力资源。

 4.3 执行与环境分离：端云协同

把计算做成无状态、状态放进数据库，还有一个直接的推论：Agent Loop 不必再住在某一台机器上，它可以被调度到任何一台空闲的机器去跑——这就是“常驻云端”的意思。

而Agent Loop 和会话状态常驻云端之后，下一个问题就来了：怎么访问任务需要的执行环境？

模型干活所需的上下文，很大一部分要靠工具调用从代码仓库、本地文件、依赖服务里取。从这个意义上说，广义的上下文也包括执行环境本身。

常见做法是把代码拉进云端沙箱、重建环境、再跑。但真实工作环境往往复制不了：未提交的本地修改、私有凭据、本地配置文件、只在特定网络里可达的服务。

既然难以同步的是环境本身，那就不必让环境跟着计算一起上云。反过来做：让云端的 Agent 通过端侧一个轻量 daemon，按需接入真实环境。这个 daemon 不保存会话状态，只负责执行命令、返回结果。

这样 Sandbox 就从"Agent 的容器"变成了"Agent 的工具"——不是 Agent in the Box，而是 Sandbox as the Agent Tool。

一个 Agent 不再受限于单台机器，可以在不同执行设备之间切换，按任务需要选择环境、执行命令、获取上下文。用户的个人设备也成了 Agent 的一个工具：我要看用户机器上的某个文件，只需要通过端云之间的契约通道，像调 E2B Sandbox 一样调这台在线设备。

这个思路与 Anthropic 提的"脑手分离"是一致的：harness 保持无状态，会话日志放在 harness 之外，执行环境通过统一接口按需接入。区别在场景——那篇讲的是托管服务，这里首先要接入的是用户日常使用、可能间歇在线的个人机器，上面有未提交的修改和本地凭据。所以它天然支持 BYOM（Bring Your Own Machine），也能接云端托管机器。

把三条路线摆在一起，取舍就很清楚，对海量用户在用的 Agent 系统来说，既想抬高智能上限，又想压低使用成本，把 Agent 做进端侧 OS、端云结合，是一个折中解。

 4.4 事件驱动：从 Trigger 到订阅直通

单会话时代，输入是用户敲的那句话。长程时代，主要输入变成了环境里发生的事：群里有人说话、CI 跑完了、有人提了 PR、监控报警了。人是其中一个来源，不再是唯一来源。

这个转变带来三个工程问题：怎么从海量事件里拿到事件；怎么筛出值得处理的、并把它定义成"一件事"；以及拿到事件之后，往模型窗口里塞什么。

DSH 的解法，是把群聊消息、邮件、日程提醒、代码评审评论、CI 结果这类环境事件统称为 Trigger，由 Trigger 统一投喂。

拿到事件先过滤。前面说过 Fast Path 与 Slow Path 两级判断，这里不再展开。

过滤之后，消息要找到它该影响的任务。但如果每条消息都让 Router 重新判断一次，Router 自己就成了瓶颈。

于是 DSH 引入订阅直通：同一个 IM 话题、同一个工作区、同一个 PR 下的消息，构成一条 Thread。Router可以与订阅过的Thread建立直接关系，由程序直接送到 Worker 手上，不再经过 Router，只有尚未被订阅的新消息，才需要 Router 判断和分派。

订阅是多对多的：一个 Worker 可以订阅多条 Thread，一条 Thread 也可以被多个 Worker 订阅。这套订阅关系和消息系统的发布订阅思想类似：先确定归属、建立订阅，后续按已有关系投递，不必每条都重新判断。

回到订阅的前提，依然是前面的上下文边界——把一个工作上下文用有边界的 Context 隔离起来。在 DSH 里，这个边界我理解为 Thread。

 4.5 面向人的交互：全双工、多信道

架构解决了"活怎么派下去"，还剩"人怎么和它说话"。这里有两个问题：后台耗时操作会不会堵住前台对话；以及在不同信道里，它该用什么方式说话。

全双工： 经典 ReAct Loop 里，模型发起一次同步的 run() 工具调用后，循环就阻塞了，直到工具执行完、结果返回，期间会话无法响应任何新输入。要消除这个阻塞，得把对话从"一问一答"的半双工，变成全双工。

DSH 的做法是把耗时的命令与子任务调用改成异步的 start() 和 stop()：模型调用 start() 后立即收到已启动的返回，循环不再等这个工具；后台执行完成后，系统再把最终结果作为一条新事件投递进会话。同时，模型也可以按需调用 stop()，主动终止跑得太久的后台命令

前台响应与后台执行就此解耦：Agent 在后台跑长任务的同时，仍能接人的输入；新输入在当前推理步结束时就被处理，不必等后台工具收尾。

多信道：双层架构已经解决了一部分问题——冗长的推理过程和密集的工具调用被隔离在 Worker 内部，由 Router 统一对外。但不同信道的带宽和习惯不一样，输出方式得跟着变：把面向单人终端的输出直接搬进群聊，很容易造成信息过载。

DSH做了不同信道输出的不同策略，且原文提到一条很实在的硬性规定：IM 场景单次回复不超过 100 词。这类规则看似琐碎，但它决定了 Agent 在群里的存在感是"同事"还是"噪音"。

云端异步： 把异步执行搬到云端、服务海量用户的 Agent 任务时，还有一个问题：异步结果怎么交回会话？RPC 回调、原地轮询都不是好答案。从系统角度看，很自然会想到消息系统。

消息系统在这里的价值有四条：

• 时间解耦：发起方不必等结果，结果以消息形式回来。

• 位置解耦：模型池和工具端可以在不同机器、不同网络——中间隔着一条通道，不是一个调用栈。

• 可靠投递：进程崩了消息还在，重启能续上。内存回调和 RPC 都做不到。

• 可控消费：消费方可以"暂时不接"，消息留在系统里等下一次。

消息系统本身很成熟，但 Agent 时代需要对它做改造。原因在于：传统异步消费假设"一个队列里的消息同质可互换"，所以一个 Topic 下挂一组消费者，谁空了谁拿。但 Agent 任务不同质——一条消息可能要跑二十分钟，一条慢消息就能拖住整个队列。

这个问题 DSH 原文没有给答案，或许内部不是使用消息系统来解耦实现，但针对消息系统上业界在Ai时代也做了很多新尝试，比如RocketMQ 的 LiteTopic。

 4.6 看门狗Watchdog

长期在线的分布式系统，很难只靠主系统内部的逻辑保证长期可靠，通常要在主系统之外放一个独立的外部控制回路，如k8s的控制循环。

但Agent 场景的难点在于：很多故障不是进程崩了，而是任务本身没进展。 传统的存活探测发现不了"模型在原地打转"，也发现不了"方向已经偏了"。

DSH 的做法是在主系统之外配一个独立的 Watchdog Session，用定时消息驱动它巡检：

• 系统本身：处理接口报错、状态恢复失败之类的系统故障。

• 业务本身：由模型判断每个任务有没有实质进展、方向有没有偏离整体目标。

发现异常就介入修复，遇到外部偶发故障，就持续复查，直到恢复。

05

回到我自己，DSH 把"系统内部怎么运转"这一半回答得相当完整，但还有三个idea在系统边界之外——或许他们能让一个 Agent 更加 Super。

一句话概括：Agent 缺三样东西——身份、感知、界面。身份决定它能进哪些系统，感知决定它什么时候该动，界面决定人怎么看到和改动它的结果。

 5.1 身份：一个有身份的 Agent

现在 Agent 都是借你的身份干活：用你的 cookie 提 PR，用你的 token 发消息。但身份不是自己给的，是平台发的。

GitHub 得愿意给它开 machine account，企业微信得愿意发它一个机器人身份，OA、日历、支付、审批——每一个系统都得在权限体系里给它留一个位置。

过去一年，我的 Coding 工具从 Claude Code、Codex 换到 CodeBuddy，再到 WorkBuddy。就 Harness 而言，绝大多数情况下交付质量差不多；但 WorkBuddy 的 Agent 身份带来了极致的便捷——我可以把所有数据资产 All in One Buddy。

所以我把"生态"理解成一句话：生态不是功能有多少，是有多少系统愿意认这个身份。

这也解释了为什么模型再强也换不来生态。模型会趋同，今天你强 3%，下个月可能就抹平了；而算力会变便宜；Harness 会开源。这些都会贬值。

但"这个 Agent 能进哪些系统、以什么身份进、被谁信任"，不会让自己变便宜。

这就是我说"最后值钱的是身份、身份背后是生态"的原因：一个 Agent 的能力上限，是它能拿到多少身份；它的价值，是这些身份连起来的那张网。

 5.2 感知：Trigger 应该感知到更多

DSH 的 Super-agent 案例里，事件源仍然是传统的那几类：GitHub、IM、问答。这些都能用 Webhook 实现，能力也现成。

但有个问题被忽略了：现在的 Trigger，主要是定时器和消息。

定时器好理解，cron 到点就跑。消息事件也好理解：有人说话、有条评论、有个 PR。这两类东西有个共同点——它们都是"发生了什么"，需要有人主动发出来。

但真实业务里，大量关键变化不是消息，是状态。

你早上打开电脑，没人会发一条消息通知 Agent。你今天的步数、心率、睡眠，也不会有人主动推送。滴滴司机接单了、换路线了、快到了——这些是订单状态的迁移，不是聊天消息。会议结束了、日程变了、邮件到了，同样如此。

这些变化的共同点是：它们都是状态，不是消息。没有人会为"司机的状态变了"发一条推送给你，但这个状态恰恰决定了 Agent 该不该动，能不能做得更加符合理想形态中的智能。

所以我认为，Trigger 的本质不是事件接入，是感知力。

在连接器的世界里，一个连接器只做到"能被调用"是不够的——那是"我什么时候问你，你什么时候答"。真正需要的是反过来：它变了，它主动告诉我。

也就是说，连接器不只是工具，还得是传感器。它要能订阅：订阅状态、订阅变化、订阅边界条件。

感知力上去了，主动服务才成立。否则所谓"主动"，不过是定时轮询一遍所有接口——那既不是感知，也撑不住系统规模。

 5.3 界面：Agent 能自己长出超级 App

过去软件的形态是：人打开界面，操作功能。Agent 是后加的，要么浮在旁边，要么藏在对话框里。

但如果 Agent 真的成为主体，界面这件事就得翻过来：不是人操作软件，而是 Agent 编排能力，界面是人看它编排结果的窗口。

这里引用Minimax的观点：https://agent.minimax.cn/docs/miniapp/overview

这要求 Agent 手里得有第三样东西。第一样是工具调用——一次性把事做完；第二样是工作台—— 能持续存状态、能被反复进出；第三样是界面——人能看到、能改、能确认。

现在的 Agent 大多只有第一样。生成一个 HTML 页面，看起来像有界面，但它是死的： 数据停在生成那一刻，要更新还得回聊天里重新交代，改完也留不下来。

一个真正的“应用”，至少要补三样：

• 持续运行。有后端在跑，能持续取数、保存结果，重启之后数据还在。

• 双向调用。Agent 能调它的工具，它也能请 Agent 在后台干活。

• 边界明确。能调什么写在声明里，权限由宿主把关，而不是靠提示词约束。

所以“超级 APP”的超级，我认为不在功能多，也不在入口统一，而在于—— Agent 能不能自己长出它需要的那个界面。

一个只能在你现成软件里点来点去的 Agent，能力上限就是你那些软件； 一个能给自己造工作台的 Agent，上限才是它自己的判断力。

 5.4 结语

写到这里，我想回到贯穿全文的那个幻想：贾维斯。

很多人记得它聪明、有性格、会调侃。但我不这么看。贾维斯真正厉害的地方，是它能调动斯塔克工业的所有系统——实验室的门、装甲库的权限、卫星的视野、财务的账。它不只是个聪明的助手，它是那个世界的一个身份。

把这个观察套回 Agent，会得到一个有点残酷的结论：单个 Agent 的能力上限，很快会被拉平。今天某家模型多会写代码，明天别家就追上了；今天某个 Harness 有巧妙设计，明天开源社区就有了。

但"它能进哪些系统、以什么身份进、被谁信任"，不会自己变便宜。这也是为什么大厂都在抢入口、抢协议、抢身份体系：模型这层迟早变成水电，身份和生态这层才是价值所在。

所以把前面几节收拢成一句话：真正的 Super，不在于它有多聪明，而在于它能连上多少东西。 只有打通生态、连接万物，才谈得上 Super。一个只能在自己一亩三分地里干活的 Agent，做得再精致，也只是个很强的工具，不是理想形态的贾维斯。

回到开头那个"3 到 5 个活跃 Session"。解法分两半：一半在架构——把记忆、调度、审批、恢复等搬进系统，解放人的注意力；另一半在生态——让这个系统拿到足够多的身份，替你走进足够多的现场。

前半部分，DSH 这篇设计探索给了很好的答案。后半部分，也许才刚刚开始。