Super-agent 设计探索：迈向更自主的 Agent 系统

01

双层架构

原文 §2 · 连续性与吞吐量的权衡

每条事件都交给同一 Session，上下文最连续，但受单个 ReAct Loop 串行速度限制，耗时且细节混杂；每条事件都新开会话，吞吐最高，但缺少全局上下文、结果割裂，多个会话各自回复又造成混乱。解法是把“维护全局连续性”与“高并发执行”拆到两层。

Router 层

常驻的全局路由层，承接所有入口的人类交互，是所有跨任务信息与决策的汇总点，充当全局序点、协调点与记忆。为避免成为性能瓶颈，它不直接执行具体任务、甚至不配备 Bash 工具。与常见 Agent Team 不同，它只处理任务之间的高层关联与分派，不介入单任务内部拆解；任务常常没有想象中复杂，较轻量的模型即可兼顾速度与效果。

批处理（Batching）

上一轮推理期间到达的事件会积压，在下一轮一并注入。Router 每步是长输入、短输出，把多条 Trigger 合并进一次调用，Prefill 阶段并行计算，单次耗时增长远慢于 batch 大小。因此在一定范围内，积压越多，单个决定分摊的推理时间越低；上限取决于上下文长度与模型一轮能准确处理多少条事件。

Worker 层

上下文彼此隔离、挂载完整执行工具、在独立上下文中专注完成单一任务，通常配置能力最强的模型。它不直接与人类交互，推理与工具调用不输出到外部信道，而是向 Router 汇报状态、由 Router 统一回复，从而在保障并发与质量的同时避免多会话各自回复的混乱。

Worker 之间

同层 Worker 通常不需要直接通信。冲突多出现在同一个 Pull Request 等共享工作环境，只要它们订阅了对应 Thread，就会收到相同的事件通知，有机会自行发现并解决；少数跨任务协同由 Router 中转。每个 Worker 内部还可以再建 Subagent 或本身就是一个 Agent Team，对上层透明。

双层架构 · [2]

Router 层常驻 Session · 人类交互 · 全局记忆 · 分派

Worker SessionThread A · 隔离上下文

Worker SessionThread B · 隔离上下文

Worker SessionThread C · 隔离上下文

已订阅 Thread 的后续事件由程序直通对应 Worker，不再经过 Router；Worker 的关键结论仍回路 Router，由它统一对外并同步全局记忆。

Session 应当是系统的实现细节，而不应是用户的认知负担。 — 原文 2. 双层架构

02

事件驱动

原文 §3 · Trigger 的生命周期

主动性的前提是换驱动方式：主要输入不再是人类逐条键入的提示词，而是群聊消息、邮件与日程提醒、代码审查评论、CI 运行结果这类半结构化环境事件，即 Trigger。一条事件从进入系统到被处理，依次有四个递进问题。

Trigger→ 程序层过滤 · Fast Path→ 语义层判断 · Slow Path→ Router 分派 / 新建 Worker→ Thread 订阅后直通 Worker

两级过滤

真实事件流“高噪音、低触发率”，逐条调模型成本难以承受。借 Fast Path / Slow Path 思路：程序层针对事件来源、群组范围、用户或机器人白名单做确定性准入，在调模型前滤掉大部分无关消息；通过准入的候选事件才交给语义层，由模型按提示词策略与上下文判断是否需要行动。语义层同时是自然语言扩展点，可随时开关或新增策略。

订阅与直通

同一个 PR、同一个 IM 话题或同一封往来邮件串下的连续事件构成一条 Thread。初始事件经 Router 创建 Worker 并建立订阅后，后续事件由程序直接发往该 Worker；Router 仍可观测全部事件以掌握全局，但只判断和分派尚未被订阅的新事件。订阅是多对多的：一个 Worker 可订阅多个 Thread，同一 Thread 也可被多个 Worker 订阅。

Inline & Spill

把有限的上下文窗口当 Cache 管理。Inline：把近期很可能用到的信息直接内联，省掉工具往返；Spill：超出预算或低频使用的完整信息留在窗口外，只保留引用或摘要。做法从“只给 ID 和摘要”开始，按局部性先附紧密关联对象的 ID，再附时空相邻内容，超出上限则截断并留续读入口。

链式召回

Trigger、Thread、Worker Session 等对象各有唯一 ID，注入时内联下一跳关联对象的 ID，底层因此构成一张引用图。每次召回同样遵循 Inline & Spill，返回结果里又内联下一跳的摘要与 ID，模型可顺着引用逐跳按需展开——从一条消息找到所在 Thread，再找到相关 Worker 与它关联的另一个评审 Thread。

投机执行

结果还不确定时，先按环境信号在后台尝试，用额外后台算力换人类的等待与介入成本：有价值就交付，没价值就丢弃。个人场景中收到会议邀约，可先核对冲突、搜集背景、备好草稿；研发群里配一条“静默复现并修复”策略，确认问题且找到简单修复方案才交付，否则全程安静。

上下文预算

系统输入从有限的人类提示词变成环境持续产生的半结构化事件，注入过多会挤占窗口、稀释注意力，过少则迫使模型反复调工具读取、增加执行步数。原文的一句话概括：浪费上下文窗口，就是浪费模型的智能。

03

面向人的交互

原文 §4 · 全双工 · 多信道

双层架构在上下文层面保证了跨信道的连续；要在体验上同时做到连续与高效，还要解决两件事：后台耗时操作不能阻塞前台对话，输出方式要匹配不同信道的带宽与人的使用习惯。

异步 ReAct Loop

经典 ReAct Loop 中，同步的 run() 会阻塞到工具返回，期间无法响应任何新输入。改为异步的 start() 与 stop()：调用 start() 立即收到“已启动”，循环不再等待；后台完成后把结果作为一条新事件投递进会话；模型也可按上下文 stop() 终止过长的后台命令。新输入在当前推理步结束后即被处理。该机制已在 DeepSeek Harness 实现，尚未默认开启。

IM 等即时信道

侧重低打扰的轻量沟通：像人类同事一样只在需要决策或验收时发送通知，只问直接问题、给简短结论。团队验证过一条简单有效的硬性规定——单次回复不超过 100 词。

GitHub / 邮件 / 文档

侧重结构化、高信息密度的异步交付：创建或更新 PR 时按项目规范写清问题背景、改动说明与验证结果；个人助手场景则直接起草结构化的邮件与文档摘要。

04

计算、状态与环境的分离

原文 §5 · 存算分离 · BYOM

本地 Agent 默认把推进 Loop 的计算、需要持久保存的会话状态、以及代码仓库与本地工具链等执行环境绑在同一台设备上：设备休眠或离线，Agent 就停止运行。按存算分离的思路，分两步解耦这三者。

第一步：计算与状态

推进 Agent Loop 的计算做成无状态，放进云端弹性容器，可水平扩展、重启或替换；需要持久保存的 Session 等状态存入数据库。连续性由持久化存储保障，Agent 因而不受单台本地设备的生命周期限制，实现云端持久在线。

第二步：计算与执行环境

真实环境往往含未提交的本地修改、私有凭据、内网服务依赖与特定工具链，在云端重建成本高且易遗漏，要求用户整体迁往云端也不现实。于是让 Loop 在云端、重状态环境留在原地，端侧只部署不保存会话状态的轻量 daemon，只负责执行命令与返回结果。

BYOM

Bring Your Own Machine：把日常开发机或个人电脑接入云端 Agent，也支持云端托管机器与按需创建的计算环境。Agent 可在不同执行设备间切换，按任务选择环境取上下文；也支持间歇在线设备——某台个人设备重新上线后，由云端 Agent 自动触发并完成需在该设备执行的任务。

与“脑手分离”的关系

思路与 Anthropic 提出的 Decoupling the brain from the hands 一致：harness 保持无状态、会话日志存放在 harness 之外、通过统一接口按需接入执行环境。区别在场景——那篇文章面向托管服务（按需沙箱与客户 VPC 内资源），这里首先要接入的是用户日常使用、可能间歇在线的个人机器。

05

Watchdog

原文 §6 · 主系统之外的控制回路

持久在线的分布式系统很难仅靠主系统内部逻辑保证长期可靠，需要在主系统之外引入独立的外部控制回路（Control Loop）。

独立 Session

在主系统外部配置独立的 Watchdog Session，由定时消息驱动，构成外部 Control Loop，处理接口报错、状态恢复失败等基础设施故障。

不只探活

仅靠进程存活探测或监控脚本不够：许多异常不是进程崩溃，而是模型陷入无效循环或偏离目标。Watchdog 还要由模型判断各个 Worker 是否有实质进展、方向是否偏离整体目标；发现异常及时介入，遇到外部偶发故障则持续复查直到恢复。

可对话的维护者

它本身也是具备完整工具能力的 Agent Session：维护者可以用自然语言询问故障原因，也可以让它在线修正主系统行为，例如增删提示词、调整触发规则。

Super
Agent

四个基础特征

连续

高效

主动

持久

支撑它的五个模块