今天 DeepSeek Harness 团队发表了最新的架构文章《Super-agent 设计探索：迈向更自主的 Agent 系统》

在文章描述中，Super-agent 要解决的问题，是单会话 Agent 在持续工作中的组织能力不足：任务执行会阻塞新指令，不同会话之间缺少上下文关联，多任务并行依赖人来协调，本地设备离线又会中断运行。

这些问题已经超出了单次模型推理的范围。即使模型能够独立完成一次代码修改，我们仍然需要有人记住任务进展、转达需求变更、处理执行冲突，并判断什么时候应该介入。

文章给出的方案，是把这些协调工作交给一套持续运行的系统：Router 维护全局交互与任务关联，Worker 隔离执行具体任务；环境事件驱动任务推进，订阅机制减少重复路由；计算、状态和执行环境分离，外部 Watchdog 负责发现运行异常。

从传统软件工程角度看，这套设计涉及职责分离、快慢路径、批处理、局部性、异步执行、存算分离和外部控制回路。我们需要分析的是，这些策略分别消除了什么约束，又把复杂度转移到了哪里。

双层架构的职责分离

单 Session 同时承担交互、协调和执行，问题在于这三类工作对上下文和响应时间的要求不同。

交互需要及时响应，协调需要保留跨任务信息，执行需要深入局部细节。

把它们放在同一个循环里，耗时工具会阻塞对话，执行日志会占据全局上下文，新消息又会不断打断当前工作。

Router 与 Worker 的拆分，对应软件工程中的职责分离。Router 接收请求、关联历史、分派任务、汇总结果；Worker 持有完整工具，在独立上下文中完成工作。复杂任务内部仍然可以使用 Subagent 或 Agent Team，上层无需了解其内部组织方式。

这里需要落实到能力边界。只在提示词里要求主会话「尽量委派」，执行路径仍由模型临场选择。原文实验中，中性提示下的单 Session 在五次运行里都没有调用 Subagent；强调优先委派后，仍有一次选择自行执行，形成长尾。

因此，对于持续接收消息的入口，我们应当限制它亲自执行耗时任务。文章甚至提出不给 Router 配备 Bash 工具。相比反复调整委派提示词，这种约束更容易检查，也更容易保持。

代价是跨层通信。Worker 需要汇报，Router 需要理解汇报，多个 Session 还会增加上下文读取开销。任务数量少、执行时间短时，这些成本未必划算。它更适合多个相对独立的长任务持续到达的场景。

上下文隔离也有边界。两个 Worker 修改同一个 Pull Request，仍然可能发生冲突。共同订阅 Thread 能让它们看到彼此的动作，但事件可见性不能保证修改兼容。原文对此只主张提供自行发现和解决冲突的机会，工程上不能把它理解为完整的并发冲突处理机制。

全局节点

Router 保留了一个全局协调点，也引入了潜在瓶颈。

文章选择先控制这个节点的工作量：不执行具体任务，不参与任务内部的高频协作，已确定归属的事件尽量直通 Worker。Router 的吞吐量取决于需要它判断的事件数量，而非外部消息总量。

另一个优化是积压事件的批处理。Router 推理期间到达的事件，在下一轮统一注入。由于路由任务通常具有长输入、短输出的特征，多条事件合并后，可以共享一次调用中的部分开销，输入在 Prefill 阶段并行计算。

压力测试中，待决策事件从每分钟约一条增加到约四十条，平均 batch 从 1.0 增加到 2.8，单次请求耗时从 2.5 秒增加到 3.9 秒。这个结果支持在当前负载范围内继续使用单 Router。

但批处理改善的是单位决策的计算效率。事件仍然可能经历排队，单次请求也会变长。不能用分摊推理时间下降，直接推导用户等待时间下降。

我们在评估这种方案时，需要同时观察排队时间、响应尾延迟和批量判断的准确性。模型一次能够可靠处理多少事件，同样构成上限。

过早分片也有成本。Router 一旦拆开，任务关联和历史记忆就需要跨分片协调。对于当前规模尚未触及瓶颈的团队，先做直通和批处理，比提前承担上下文分裂更合适。

事件分级处理

持续接入群聊、评审和 CI 后，大部分消息都不需要 Agent 行动。每条消息都调用模型判断，会把低价值流量转化为持续推理开销。

文章采用 Fast Path / Slow Path：来源、群组、白名单等确定条件由程序处理，需要理解意图的候选事件再交给模型。

两层策略的划分依据，应当是判断是否稳定、是否依赖语义。明确忽略某个来源，可以固化为程序规则；某段讨论是否包含值得复现的缺陷，需要结合上下文判断。

过滤位置越靠前，节省的后续开销越多，误过滤的影响也越难补救。程序层直接丢弃的消息，语义层没有机会重新判断。因此，适合放入快速路径的是稳定的准入条件。对含义不确定的事件过度使用硬规则，会压缩系统的主动发现能力。

事件路由使用了相同策略。

新 Thread 需要 Router 判断任务归属；Worker 建立订阅后，后续事件由程序直通。这里借用了发布订阅式的组织方式，把已建立的关联保存下来，避免每次重新推理。

订阅可以多对多，既支持一个任务跨 IM 与 GitHub 推进，也支持多个 Worker 关注同一个工作对象。不过，Thread 内可能出现任务范围变化。Worker 需要取消订阅或交回 Router，否则快速路径会持续沿用过时的归属关系。

这意味着直通机制省去的是重复决策，系统仍需保留重新分类的出口。

上下文按需展开

持续运行后，上下文管理面对的矛盾会越来越突出：完整历史无法常驻窗口，只保留摘要又可能漏掉执行所需的细节。

文章把上下文窗口视为 Cache，通过 Inline & Spill 控制信息进入窗口的方式。

近期大概率使用的信息直接 Inline，例如关联对象 ID、相邻消息、评论所在讨论的局部内容。长文本与低频内容 Spill 到窗口外，在窗口内保留摘要和续读入口。

这个设计利用了局部性。正在处理一条评审意见时，附近评论通常比几周前另一项任务的日志更有价值。直接提供局部信息，可以减少工具往返；限制注入长度，则避免长日志占满窗口。

难点在于摘要和截断的位置。截断过早，模型需要连续读取；截断过晚，低价值文本又会增加每轮上下文成本。摘要遗漏关键条件，还可能让模型在没有继续读取的情况下作出错误判断。

因此，我们不能只统计节省了多少 token，还要检查为了补齐信息增加了多少调用，以及模型是否遗漏了必要的续读。

链式召回进一步把 Trigger、Thread 和 Worker Session 组织成引用图。当前消息可以指向 Thread，Thread 再指向 Worker，Worker 又关联其他信道中的讨论。

对于沿任务关系查找历史，这种结构有较清晰的路径。它也存在逐跳调用的延迟，而且依赖关联信息完整。原文将其定位于近期任务和会话历史的按需检索，跨月运行的长程记忆仍是开放问题。

有了历史存储和引用图，距离稳定理解长期项目状态，仍有一段工程距离。

主动执行成本

投机执行，我更愿意称其为提前运行，或者预热运行。

它允许 Agent 在请求尚未明确时，先根据环境信号进行后台尝试。例如群聊中出现缺陷反馈，系统先复现并寻找修复方案，确认结果有价值后再交付。

它适合存在提前量、验证路径相对清晰、无效结果可以丢弃的工作。等待人工明确指派的时间，被用于后台计算。

这个操作是有代价的。

这个代码一部分是算力：错误判断会启动最终无人采用的任务。另一部分是人的注意力：即使后台不发消息，提交的修复也需要审查。静默只能减少过程打扰，无法消除结果验收成本。

原文采用「确认问题并找到简单修复方案后再交付」的策略，实际上同时设置了问题确认门槛和交付门槛。对研发场景，这比看到讨论就立即发送建议更合理。

我们还需要区分可以丢弃的计算结果与已经发生的外部动作。复现记录、候选方案可以不采用，已提交的 Pull Request 已经进入协作流程。投机范围扩大时，应当重新评估交付频率和审核负担。

原文没有提供主动任务的采纳率和无效执行比例，因此现阶段能讨论机制，不能据此断言它一定降低团队总成本。

面向人的交互

全双工

经典 ReAct Loop 里，一次同步 run() 会阻塞整个循环。文章把耗时命令和子任务改为异步的 start() 与 stop()：调用后立即返回 Started，后台完成后结果作为新事件投递进会话；模型也可以主动 stop() 掉跑太久的命令。

这就是把阻塞 I/O 换成了事件循环加回调，前台响应和后台执行解耦。新输入在当前推理步结束后就能被处理。

这一机制已在 DeepSeek Harness 中实现，但尚未默认开启。我们的理解是异步化会带来一些模型层面的新问题：后台结果到达时，模型需要把它和若干轮之前发起的调用对上；多个后台任务并发时，结果到达顺序不确定；模型可能忘记自己还有任务在跑，或者重复发起。传统异步编程靠 Future、任务 ID 和状态机解决这些问题，在 Agent 里需要靠事件注入的结构设计和模型自身的跟踪能力，稳定性要靠大量评测去压。

从传统软件工程经验来看，异步往往是问题或 BUG 的重灾区，是个大坑，这也是过往需要组件，甚至编程语言着重处理异步的原因。

多信道

群聊和终端的信息密度完全不同。双层架构已经把冗长推理和工具调用关在 Worker 内部，剩下的是按信道定制输出规范：IM 低打扰，只在需要决策或验收时通知，只问直接问题、给简短结论，他们验证过一条硬性规定是单次回复不超过 100 词；GitHub、邮件、文档这类异步信道则要结构化、高密度，PR 按项目规范写清背景、改动和验证结果。

在软件工程里，这相当于同一个领域服务前面挂多个表现层适配器。「100 词」这种硬约束比「请简洁」这种模糊指令好执行，也好验证。

存算分离

本地 Agent 把三样东西绑在同一台机器上：推进 Agent Loop 的计算、需要持久化的会话状态、代码仓库和工具链等执行环境。文章分两步解绑。

第一步，计算和状态分离。 Agent Loop 放进云端无状态弹性容器，Session 等状态进数据库。容器可以水平扩展、重启、替换，连续性由存储保证。这是十二要素应用里「进程无状态」的标准做法，没有争议。

第二步，计算和执行环境分离。 这一步的判断更有意思。常见做法要么是在云端沙箱里重建环境，要么让用户迁到云端开发。文章指出，真实环境里有未提交的修改、私有凭据、内网依赖、特定硬件和工具链，同步成本高且容易漏。他们的选择是环境留在原地，端侧只部署一个不保存会话状态的轻量 daemon，只负责执行命令和返回结果。

这和 CI 系统的 self-hosted runner、Kubernetes 的 kubelet 是同一种结构：控制逻辑在中心，执行代理在边缘。文章也提到，这和 Anthropic 提出的「脑手分离」思路一致，区别在于后者讨论托管服务里的按需沙箱和客户 VPC 资源，这里优先要接入的是用户日常使用、间歇在线的个人机器，即 BYOM（Bring Your Own Machine）。

间歇在线带来了一个新能力：设备重新上线后，云端自动触发需要在该设备上执行的任务。工程上这要求一个按目标设备分组的待执行队列，以及任务的幂等设计，否则设备反复上下线会导致重复执行。文章没有展开这部分，但落地时必须处理。

这个设计默认云端和端侧互相受信任。云端 Agent Loop 持续接收外部事件，一旦被服务端入侵或者提示词注入攻破，所有连接的端侧设备都有被控制的风险。爆炸半径是全部设备。需要慎重考虑落地的安全策略。

外部进展检查

传统存活探测可以判断进程是否退出，却难以判断 Agent 是否在重复无效操作。

Watchdog 将检查放到主系统之外，通过定时消息驱动独立 Session，检查基础设施异常，也检查 Worker 是否取得实质进展、是否偏离目标。这对应外部 Control Loop。

它补充了两类不同的观测：系统是否运行，任务是否推进。

难点在于后者。长时间分析可能合理，短时间内大量调用工具也可能没有产出。模型判断提供了语义能力，同时带来了判断错误和额外推理成本。

检查过密，会增加开销和干预机会；检查过疏，异常任务可能消耗很久才被发现。具有完整工具权限的 Watchdog 还能修改提示词与触发规则，其干预会影响主系统后续行为。

所以，Watchdog 应当被视为辅助恢复机制。它的引入不能证明系统已经实现可靠自愈。原文没有给出异常检测准确率和恢复成功率，这部分仍需要长期运行数据。

落地范围选择

这套设计当前最有依据的适用范围，是信息可以共享、任务相对独立、工作信道稳定的小团队。

在这个范围内，先划清 Router 与 Worker 的职责，再引入订阅直通和上下文按需读取，能够针对会话阻塞、重复路由和历史查找建立可检查的机制。异步执行与存算分离，则需要结合实际任务时长和环境条件推进。

扩展到更大的组织后，全局上下文同时成为权限边界。哪些任务可以共享信息、哪些实例必须隔离，需要先于跨实例协作确定。

我们从这篇文章能获得的工程启发，是把持续运行拆成若干可单独分析的系统问题，并为每个问题选择合适的约束。已有实验给出了调度层面的初步证据；安全、长期记忆和恢复能力，还不足以支撑同样强的结论。落地计划应当保留这种区别。

以上。