深入 DeepSeek Harness 的 Super-agent 架构

DeepSeek Harness 正在主张改变智能体的设计单位。对话不应再是产品边界，模型调用不应再拥有工作本身，一台机器也不应再决定工作发生在哪里。取而代之的，应当是一个持续存在的协作智能体：路由层、隔离的 Worker、事件基础设施、持久状态与外部 Watchdog 在接口背后处理真正困难的部分。

本文完整改编自 DeepSeek Harness 的文章《探索 Super-agent 设计：走向更自主的智能体系统》。原文以中文撰写，同时发布了机器翻译的英文版本。本文面向技术读者重写原有论证，并对照另一份公开代码仓库 dsh-superagent-prototype 核查实现层面的说法。这个区分很重要：文章描述的是一套架构和研究方向；仓库明确属于研究代码，不是 DeepSeek 的官方产品，也不是可投入生产使用的正式版本。

为什么会话不再是产品

过去一年，编程智能体和其他单任务智能体跨过了一道重要门槛。它们已经能够调用工具解决相当复杂的问题，也越来越多地承受一段没有人类逐步监督的执行过程。模型协调子智能体的能力也在提高。人的角色因此从底层执行向上移动，转向选择方向、审查结果和做出批准。

更强的模型还催生了新应用。最近出现了大量个人智能体，它们直接连接聊天、日历、邮件和工作平台，监听信息流并协助完成日常任务。个人助理只是这种长期在线、事件驱动工作方式的一种表现。同样的能力也适用于软件开发、运维、研究以及其他协作工作。

现在的限制因素转向了架构。主流智能体产品仍然把一次会话同时当作模型上下文容器和用户的项目管理单位。一个人同时处理几项任务时，只能在彼此隔离的窗口之间切换，还要记住哪个窗口知道哪些信息。DeepSeek Harness 团队表示，按照他们的经验，一个人通常只能同时跟踪大约三到五个活动会话。单个任务的质量也许受模型能力限制，多任务生产力却被人的注意力限制。

把本地单会话智能体接到 MCP 服务器、命令行界面或外部消息服务上，并不能消除这条边界。会话仍会阻塞在耗时操作上，无关任务的上下文仍会互相污染，机器休眠或断网时工作仍会停止。维持这套系统继续运行，本身又成了用户的一项工作。

DeepSeek Harness 把提出的系统称为 Super-agent：它是一个持续存在的智能体，在多次交互之间保持上下文，同时推进多项复杂任务，而不要求用户管理这些任务背后的会话。

团队列出了四个必须同时成立的性质：

• 连续。用户可以在 IM、GitHub、邮件或其他已有工作空间中与同一个智能体交流，不必猜某个会话是否掌握了相关信息。一个渠道里做出的决定，应当传递到另一个渠道所触发的工作中。
• 高产。智能体能迅速回应，并并行推进多项复杂任务。上一条命令尚未结束时，用户就可以给出下一条指令；与此同时，每项任务仍要获得足够集中的上下文，以产出高质量结果。
• 主动。智能体不等每一步指令。它观察相关事件，判断哪些值得处理，在没有必要时保持沉默。主动不等于对每件事都发表意见。
• 持久。智能体始终在线，能触达真实工作所在的环境，并能在长时间运行中从故障里恢复。

单独一个 ReAct 循环无法提供这四种性质。它们必须由循环周围的系统来提供。DeepSeek Harness 把系统拆成五个部分：用两级 Router 与 Worker 架构提供连续性和并发能力；用事件驱动的 Trigger 提供主动性；用跨渠道、全双工交互维持响应；把计算、状态和执行环境拆开；再用外部 Watchdog 保证持久运行。

团队还认为，个人智能体和商业编程智能体很可能会收敛到类似结构。两者的用例不同，却都需要一个持续在线、响应事件并并发执行工作的系统。约束相似，操作系统和分布式系统使用了几十年的许多思路便重新变得重要。

另一个内部案例里，智能体在未被 @ 的情况下观察公开产品群。用户描述一个可复现的双击故障后，智能体在后台复现问题并提交 Pull Request。这比响应直接命令强得多，也解释了为什么必须有准入规则和较窄的操作范围。

一眼看懂五部分系统

架构图明确划出了职责边界。聊天、GitHub、邮件和其他环境中的输入会变成 Trigger。Fast Path 与 Slow Path 在长期存活的 Router 决定是否开始工作、在哪里开始之前先做过滤。Worker Session 执行隔离的任务，持久状态位于 Worker 之外，外部 Watchdog 观察整个系统并修复故障。

这张图颠倒了常见智能体示意图的中心。大多数图把模型放在正中，再用工具围住它。这里，模型只是控制系统中的一个组件。调度、准入、状态持久化、执行触达和故障恢复不是提示词问题，而是基础设施问题。

Router 与 Worker：不串行执行，也不丢失连续性

一个系统若既要连续交互，又要保持高任务吞吐，就会直接面对连续性与并发之间的权衡。把所有事件送进同一个会话，能最大化共享上下文。这个会话看得到一切，但 ReAct 循环仍只能一步一步推进。任务因此变慢，吞吐下降，不同任务的无关细节还会污染上下文。

为每个事件新建会话则把问题反过来。并发提高了，相互关联的任务却不再拥有全局上下文。结果彼此脱节，多个会话还可能同时回复同一个人，却不知道其他会话的存在。

DeepSeek Harness 把这两类职责拆成两个逻辑层：

• 长期存活的 Router 层接收来自所有渠道的交互，维护全局记忆，负责对外沟通并分派新工作。
• 上下文隔离的 Worker 层并行执行实际任务。每个 Worker 拥有完整的执行工具，并专注于一项工作。

有了这层划分，会话就变成实现细节。用户不应因为 LLM API 提供彼此分离的上下文窗口，就必须亲手切分工作。产品可以提供项目视图、任务面板、Issue 讨论串或领域专用界面，而不必让每个视图与一个执行会话一一对应。

Router 被有意设计得很浅

Router 是系统的全局序列点、协调点和记忆。它接收人的交互并跟踪跨任务关系，同时被刻意禁止亲自执行任务。在作者的设计中，它完全可以没有 Bash 工具：它只和人交流、分派工作。

这正是该结构与常见 Agent Team 的区别。Team Lead 通常会把一项复杂任务拆成相互耦合的子任务，深入推理依赖关系，并频繁协调成员。Super-agent 的 Router 工作在更高层。它判断出现了新任务，把任务分配出去，跟踪相关 Thread 与 Worker，并转达少量无法在本地处理的冲突。具体任务如何分解，由 Worker 在自己的范围内负责。

职责浅，较轻量的模型也能胜任，顺带还让批处理变得自然。Router 进行推理时，新到的 Trigger 会排队，并合并到下一次调用中。平稳的小流量下，每个事件都能迅速得到处理；突发流量下，Router 一次 prefill 可以处理更大一批。因为 Router 的输出很短，输入又主要是上下文，请求延迟的增长会远慢于批次大小，直到上下文长度或决策准确率成为限制。

团队的简单实现使用一个长期存活的 LLM 会话作为 Router。未来如果规模需要，也可以分片，但分片会在 Router 层重现同一个连续性问题：分片越细，吞吐越高，每个分片能看到的全局上下文越少。

Worker 执行任务，但不代表系统发言

每个 Worker Session 只承担一项任务，拥有隔离上下文和完整执行工具。最强的模型与最深入的领域推理应当放在这一层，因为 Worker 的输出决定代码、分析或其他结果的质量。

Worker 不直接回复用户，而是向 Router 报告，由 Router 负责所有对外沟通。这样多个会话就不会在同一段对话里给出互相竞争的答案。Worker 仍可通过共享环境协作。如果两个 Worker 订阅同一个 Pull Request Thread，它们都会收到新评论，也都有机会发现冲突。只有无法通过共享 Thread 处理的跨任务协调，才需要 Router 介入。

Worker 内部也可以有子智能体或完整的 Agent Team，Router 无需知道。这个递归边界很有用：复现问题、审查 Pull Request、开发功能等独立任务可以并发推进；当某项任务足够复杂时，每个 Worker 又能在内部采用更丰富的结构。

Trigger 把环境变成输入

主动系统不能主要靠人不断往会话里输入提示词来驱动。它的输入应当是一串半结构化事件。DeepSeek Harness 把这些事件称为 Trigger。Trigger 可能来自群聊消息、邮件、日历提醒、Pull Request 审查、Issue 更新或 CI 结果。

真实事件流大部分是噪声。让大模型从零检查每条消息既浪费算力，又增加延迟。因此设计借鉴系统工程中的 Fast Path 与 Slow Path：稳定、廉价的判断交给确定性代码，模型推理留给确实需要语义判断的模糊情况。

第一层策略定义“只响应明确请求”“视为候选”或“忽略”等条件。第二层接收剩余事件及其上下文，用自然语言策略判断是否值得采取行动。自然语言规则是刻意留下的扩展点：团队可以改变准入行为，而不必修改路由代码。

Thread 与直通路由

同一个 Pull Request、IM 话题或邮件链上的连续事件构成一个 Thread。Router 为 Thread 中第一个事件创建 Worker 后，该 Worker 会订阅这个 Thread。同一 Thread 后续的事件直接送到已订阅的 Worker，不再额外经过一轮 Router。

订阅关系是多对多的。一个 Worker 可以订阅多个相关 Thread，一个 Thread 也可以有多个 Worker。因此共享 Pull Request 中的事件会同时扇出给所有感兴趣的 Worker。Worker 仍向 Router 汇报结论，由 Router 更新全局记忆并发送对外回复。

Router 会持续观察尚未被认领的事件，以维护全局状态，但只评估那些还没有归属者的事件。这相当于在事件路由里把昂贵的冷路径与廉价的稳态路径分开。

把上下文窗口当作缓存

事件持续到达后，决定往上下文里放什么就变成一个系统问题。信息太多会稀释注意力并塞满窗口，信息太少又会迫使模型反复调用工具、增加推理步骤。作者借用了编译器与存储系统中的两个操作来描述上下文注入：

• Inline 把很快可能需要的信息直接放进上下文窗口。
• Spill 把体积大或很少使用的内容留在窗口外，只在窗口里保留摘要或引用，需要时再通过工具调用展开。

过程从最小上下文开始：对象 ID 和简短摘要。系统再依据局部性逐步内联相关对象，例如一条消息开头的几十个字符、聊天中相邻或被引用的消息、审查讨论附近的评论。长内容会在较小的阈值处截断，并替换为指向完整对象的指针。

把同一规则应用到所有对象，就形成了 Chain of Recall。Trigger、Thread 和 Worker Session 都获得稳定 ID。一个被召回的对象进入上下文时，会携带相邻对象的 ID。Router 可以从当前消息出发，顺着引用找到它所属的 Thread，再进入拥有该 Thread 的 Worker Session，继续沿引用跳到相关的代码审查讨论。

推测执行替人买回注意力

智能体还可以借用计算机体系结构中的推测执行。环境信号可能足以支持在结果是否会被使用尚不确定时，就提前启动后台工作。结果后来有用，就交付；没有用，就丢弃。额外的后台计算换取了一部分用户等待和介入的时间。

个人智能体可以在用户开口前读取会议邀请、检查日历冲突、收集相关信息并起草回复。在 DeepSeek Harness 团队内部，团队配置了“静默复现并修复”的策略。有人报告疑似问题或提出改动时，智能体会尝试复现并寻找简单修复。只有问题和修复都得到确认，它才发言。

跨渠道的全双工交互

两级调度在上下文层面保持了连续性，却并不能自动让交互响应迅速。经典 ReAct 循环调用同步 run() 工具时会阻塞。命令返回之前，会话无法处理新消息。一次很长的构建或测试，会让正在工作的智能体看起来像离线。

DeepSeek Harness 用异步 start() 和 stop() 取代阻塞式工具调用。start() 立即返回“Started”确认，工具继续在后台运行，最终结果作为新事件送回会话。命令运行太久或已经无关时，模型可以调用 stop()。

文章明确指出，DeepSeek Harness 实现了异步任务机制，但没有默认开启。评估这套设计时，这个细节很重要：架构思想已经存在，默认产品行为却可能仍比目标状态更同步。

响应性还包含沟通维度。详细推理和原始工具日志也许适合单用户终端，却会淹没群聊。由于 Worker 不直接对外说话，Router 可以把结果转换成适合当前渠道的沟通方式。

作者建议 IM 只进行轻量回复，并且只在人需要决定或签核时通知。问题要直接，结论要短，智能体应尽可能少打断人。他们报告，每次回复最多一百词的硬限制效果不错。GitHub、邮件和文档等异步渠道则适合结构化、信息密集的回复，包括问题背景、改动描述、验证证据和项目约定。

这不是表面上的提示词调优。渠道选择会影响打断成本。一条技术结论即使正确，如果细节层级不适合当前渠道，也可能降低团队生产力。

分离计算、状态与执行环境

本地编程智能体通常把三件事绑在同一台设备上：Agent Loop 的计算、必须跨轮次保留的会话状态，以及包含仓库、依赖、凭据和工具链的执行环境。这种绑定让本地工作很方便，也意味着机器休眠、断网或重启时智能体会停止，还使它无法触达任务真正所属的另一台机器。

DeepSeek Harness 分两步解耦这套栈。

计算变得弹性，状态保持持久

Agent Loop 可以运行在无状态云容器里，会话状态则存入数据库。容器能够重启、横向扩展或被替换，而任务不会因此消失。用户笔记本离线不再终止长期运行的智能体，因为笔记本已不是 Agent Loop 的宿主。

执行环境留在工作真正发生的地方

当任务可以从仓库重建时，云端沙箱很有用。真实工作环境却经常包含未提交改动、私有凭据、内网依赖、专用硬件和本地工具链。把这些全部拉进新沙箱既昂贵又容易出错。要求每位用户把工作迁到云上，干扰可能更大。

另一种做法是让笨重的执行环境留在原处，通过轻量 endpoint daemon 把它接到云端智能体。daemon 不保存会话状态，只执行命令并返回结果。云端的 Agent Loop 因而可以根据任务需要，在执行设备之间切换。

作者把它与 Anthropic 提出的“把大脑和双手解耦”相比较。两者都让 harness 保持无状态，把会话日志存放在外部，并按需连接执行环境。区别在主要受众。Anthropic 的讨论围绕托管服务、按需沙箱和客户 VPC 资源；DeepSeek Harness 首先要连接人们已经在用的个人机器，包括只会在间歇时刻在线的设备。

这类设备重新上线后，云端智能体可以恢复那些必须在它上面运行的工作。这不仅是远程控制。智能体拥有持久身份，也拥有一组可在任务生命周期内变化的执行端点。

Watchdog 必须检查进展，而不只是存活

持久运行不只依赖持久状态。分布式系统还需要一个独立控制循环，修复主循环无法自行修复的故障。智能体系统还多了一种更少见的故障：进程健康，推理却陷入无产出的循环，或者漂离了用户目标。

因此，DeepSeek Harness 使用一个由定时消息驱动、运行在系统外部的 Watchdog Session。它处理 API 错误、状态恢复失败等基础设施故障，也让模型判断每个 Worker 是否在取得实质进展，是否偏离任务要求。外部暂时性故障会被反复重试，直到解决。

Watchdog 本身也是带工具的智能体，而不是固定仪表盘或狭窄的存活探针。维护者可以用自然语言询问它某个环节为什么失败。它可以检查系统，在主系统继续运行时增删提示词或调整 Trigger 规则。这让运维调试成为一等能力，也提出重大的安全与治理要求：一个拥有足够能力修复系统的观察者，同时也是高价值攻击目标。

初步实验究竟说明了什么

文章报告了两项实验，运行在合成工作负载和简化环境中。作者明确提醒，这不是完整基准，部分设置还可以更严谨。结果只应被看作调度行为的证据，而不是系统能更快完成任意工程工作的证明。

端到端消融实验

四种设计处理同一种事件流：每次运行约 300 条消息，其中约 20 条是工作请求；其余是闲聊、追问、取消和 CI 消息。编程由只消耗时间的工具模拟。每种设计运行五次，测量从提出工作请求到收到结果消息的区间。

设计	任务完成时间，p50 / p95	每次运行的缓存读取 token
Super-agent	12.4 / 15.7 分钟	23.2M
Super-agent，不使用直通	12.6 / 15.5 分钟	31.8M
带子智能体工具的单会话，中性提示词	20.4 / 29.5 分钟	6.1M
带子智能体工具的单会话，委派优先提示词	13.8 / 29.0 分钟	10.8M

两级设计完成任务更快，尾部延迟也比单会话设计更紧。由于同时维护多个独立上下文，它消耗了更多缓存读取 token。核心权衡就在这里：token 换来隔离、更短的完成时间和更少的人力协调。

与单会话比较，也是在比较提示词的运气。使用中性提示词时，模型五次运行都没有调用子智能体。工作留在主会话中，不断被新消息打断，p95 达到 29.5 分钟。使用委派优先提示词时，模型五次中有四次委派，平均表现改善，但有一次把工作判断为“很小”，坚持在主会话里完成，形成了长尾。提示智能体去委派，并不等于把委派写进架构。

直通机制的影响不同。去掉直通几乎不改变完成时间，但 Router 每次运行做出的决定增加约 30%。缓存读取 token 总量从 23.2M 上升到 31.8M，多了约 37%。在这个工作负载中，直通不是延迟优化，而是减少冗余路由和推理开销。

Router 批处理

第二项实验单独测试 Router。Router 使用真实模型，Worker 使用模拟模型。研究者逐步提高需要 Router 决策的 Trigger 到达率，从每分钟约一个提高到约四十个。

低到达率下，平均批次大小为 1.0；高到达率下为 2.8。单次请求时间只从 2.5 秒增至 3.9 秒。平均到一个决策上的推理时间则从 6.4 秒降到 1.6 秒。一次决策可能包含多个模型请求，所以每个决策的总耗时可以高于单次请求时间。

这个结果解释了为什么第一项实验中移除直通并没有压垮单一 Router：系统通过批处理吸收了更高事件率。它不能证明一个 Router 可以无限扩展，但说明对中等规模团队而言，单个长期存活的 Router 是合理的默认值。只有当测量结果表明收益足以抵消全局上下文的损失时，才应引入分片。

架构尚未解决的四个问题

这些实验只能在简化环境中支持核心调度主张。DeepSeek Harness 列出了四个仍然开放的大方向。

1. 扩展 Router 与 Worker 拓扑

单个 Router、Thread 订阅，以及较少的 Worker 直接通信，以较低的工程成本覆盖了团队大部分日常工作。当任务更大、耦合更紧时，设计应如何变化还没有答案。团队仍要确定何时分片 Router、分多细、Worker 何时应点对点通信，以及哪种协作拓扑最有效。

模型与系统协同设计是另一条路径。专门训练模型判断事件、批量分派和沿召回链检索，可能进一步提高 Router 吞吐与决策质量。记忆最终会成为更硬的限制。Chain of Recall 能按需取回近期任务历史，但连续运行数月乃至更久的系统需要更强的长期记忆设计。

2. 设计没有会话的产品

如果会话从用户工作流中消失，应该由什么取代？聊天窗口不是必然形态，它成为交互中心有一部分来自路径依赖。一部分交互会迁移到领域专用界面，例如 Issue Tracker 和 Pull Request。会话也可以因为用户熟悉而继续可见，但一个可见对话不必再对应一个内部会话。

更困难的交互问题发生在任务中途。文章更多讨论任务启动与签核，而当前模型仍会在关键细节上需要人的输入。产品必须让人能够查看、接管或协作处理后台工作，同时不破坏那些让工作高效的自主性。

3. 定义上下文与权限边界

这套架构假设一个 Super-agent 实例在其范围内拥有全局上下文。组织场景会让这个假设变复杂。如何部署实例，实际上就是决定哪些团队共享上下文、哪些团队必须隔离。

隔离实例出现后，它们需要跨权限边界进行智能体间通信。个人智能体可能需要与团队的 Super-agent 协作，却不能继承后者的全部数据和权限。文章中的 A2A 指广义的 agent-to-agent 通信，并不特指某个协议。不同上下文、不同权限的智能体如何安全可靠地协作，仍未解决。

4. 安全与隐私

事件驱动扩大了攻击面。聊天消息、Issue、代码、文档和外部工具结果都可能包含不可信输入。提示词注入或恶意仓库指令可能试图让智能体背叛用户，或攻击执行环境。

云端循环与 endpoint daemon 的设计隐含假设云端和每个端点互相信任。端点持有私有代码、敏感数据和凭据。如果攻击者攻破云端 Agent Loop，所有已连接端点都可能暴露。即使服务器没有被攻破，凭据只要在正常执行过程中进入模型上下文，也可能泄漏。

作者的结论很直接：智能体必须能够使用凭据，却永远看不到凭据。有用的 Super-agent 需要从大量环境取回上下文，同时维持强隔离、最小权限和可审计的行动边界。

原型做了什么，不能证明什么

公开的 dsh-superagent-prototype 之所以有用，正因为它比文章描绘的完整愿景更窄。它是采用 MIT 许可证的 TypeScript 插件，面向 DeepSeek Harness，描述一个服务单个 GitHub 仓库的主动编程智能体，并可选接入飞书。它监听事件，为允许的请求创建工作项，在隔离的智能体会话和目录中执行，并在原对话中回复，通常还会提交 Pull Request。

项目的运行原则更接近注意力核算，而不是追求自主完成的数量：

尽可能少占用人的注意力，尽可能多地创造价值。智能体只在被请求，或书面团队规则允许时行动；只在必须由人行动或可以使用结果时才发言。

实现包含架构图中可以预期的基础构件：类似 Router 的主会话、隔离的 Worker Session、Trigger 准入、Thread 订阅、GitHub 与飞书事件源、Worker 槽位、重试、效果持久化，以及展示待人工处理事项的管理面板。文档还说明了恢复行为、后台任务、合并规则，以及 working、waiting、blocked、failed 与 ready 等状态的区别。

仓库同样明确写出局限。它是研究代码，不是生产级软件，也不是 DeepSeek 官方产品。为了公开发布，它经过改编，并不等同于内部版本，也不等于文章中提到的每一种实现。文章中的一些想法属于未来方向，而不是已经交付的行为。原型用于验证部分技术路线，不能证明完整的 Super-agent 已被解决。

真正的转变：从调用走向协作

文章没有提出新的模型架构，也没有声称一条提示词就能产生自主性。它的贡献是把熟悉的系统思路带进智能体栈：分离控制与执行，区分快速与慢速准入，选择性缓存上下文，批量处理排队工作，利用推测执行，独立持久化状态，并从系统外部监控任务进展。

这些想法之所以重要，是因为瓶颈正在移动。当模型在单项任务上需要的逐步监督越来越少，人的注意力就成为稀缺资源。团队不可能靠开更多聊天窗口、靠人脑记住哪个智能体知道什么来获得更多杠杆。团队需要的是一个始终作为单一协作者存在的智能体，由系统负责管理会话、分派工作、保存上下文，并在人真正能发挥作用时把注意力重新路由过去。

文章中描述的内部 DeepSeek Harness 实例已经用于复现和修复问题、回答代码审查问题，以及开发 DeepSeek Harness 本身。公开原型展示了其中较小的一部分行为。两者都更适合被理解为方向上的证据：智能体不再只是一个等待命令的聊天窗口，而会逐渐成为基础设施，在工作已经发生的环境中提供持续、有边界的协作。

---

来源：DeepSeek Harness，《探索 Super-agent 设计：走向更自主的智能体系统》，2026-11-01 发布于 X。原始帖子：x.com/DeepSeekHarness/status/2116857257245987236。X Article：x.com/i/article/2116829218935857152。系统由 Yujia Qiao 与 DeepSeek Harness 团队实现和描述；Yujia Qiao 实现系统并撰写原文。本文根据原文英文机器翻译完整改编，并对照公开原型文档核查实现边界。