社区

一句话概括

单任务的上限取决于模型能力，多任务的上限取决于人的注意力。

现有 Agent 以单个 Session 为单位、彼此独立，人手动切换时只能盯住 3～5 个。Super-Agent 把上下文管理与并发放到系统底层，从用户侧淡化 Session，让人始终面对一个 Agent。

四个目标特征：连续、高效、主动、持久。

---

五个模块速览

模块	解决的问题	关键机制
双层架构	吞吐与连续性的权衡	Router 只分派，Worker 只执行
事件驱动	从被动问答转为主动发现	Trigger / Thread、两级过滤、直通路由
多信道交互	前台对话被后台任务阻塞	异步 ReAct Loop，全双工
计算/状态/环境分离	关机停工、换机丢环境	存算分离 + BYOM
Watchdog	进程活着但循环死锁、目标偏离	外部控制回路，定时消息驱动

---

1. 双层架构：Router / Worker

矛盾：单 Session 连续性强但吞吐低；多 Session 吞吐高但割裂。

• Router｜常驻全局路由层，汇总跨任务信息与决策，只分发不执行。角色像秘书/大总管，多节点结构，但轻量模型就能胜任——它不管任务细节。
• Worker｜执行具体任务，上下文彼此隔离，挂载完整工具，专注单一任务，需要最强模型，彼此不通信。可 fork subagent，自身即可成一个 Agent Teams。

关键立场：Session 不能成为用户负担。要求用户把自己当项目经理的 multi-agent 产品，路线就错了。

---

2. 事件驱动：从被动到主动

日常用 LLM 是拉取式（给 prompt 才响应）。Super-Agent 引入 Trigger——群聊消息、邮件日程、代码评审评论、CI 结果等环境事件，据此主动发现任务。

两级降噪

1. 程序层（Fast Path）：规则先筛，滤掉噪音
2. 语义层（Slow Path）：剩下的进 LLM，按提示词策略判断是否行动

大部分消息在第一层就被拦下，根本轮不到模型。

直通路由（关键优化）

过滤后的消息直接投给 Worker，全局 Router 只负责新任务冷启动 + 跨任务协调——避免 Router 成为瓶颈。

Thread：连续的上下文线

• Trigger 是一个点，Thread 是一串相关 Trigger 连成的线（PR、邮件往来、IM 话题）
• 一个 Worker 可同时订阅多条 Thread
• Slow Path：新 Thread 无人认领 → Router 判断归属 → 建 Worker 并订阅
• Fast Path：已有订阅 → 程序直接投递

Inline / Spill（上下文注入）

浪费上下文窗口是大忌。

• Inline：近期很可能用到的信息直接内联进窗口，省去工具往返
• Spill：超预算/低频的完整信息留在窗口外，窗口内只留引用或摘要，按需读取

类比操作系统内存换页，但关键差异：缺页由硬件内核自动处理，LLM 没有这个机制——模型得**自己意识到"我缺什么"**再主动读回来。所以这套机制对模型能力要求更高，换个模型效果差别很大。

链式召回（Chain of Recall）

给 Trigger / Thread / Worker 都编 ID，注入时顺带带上下一跳 ID，对象在底层连成一张引用图。

例："昨天那个问题修得怎么样了？" → 消息挂 Thread ID → 查到 Worker → Worker 挂 PR 的 Thread ID → 查到修改记录。

靠的不是巨大记忆库，而是一张能实时渲染的地图。

投机执行

借鉴 Speculative Execution：结果未确定时，按环境信号在后台提前尝试，用额外算力换人类的等待成本。有价值就交付，没价值就丢弃。

---

3. 多信道交互：异步 ReAct Loop

传统 ReAct 是阻塞的：run() 发出去，整个循环卡住等结果，新消息只能排队。

改为异步：start() 立即返回已启动 → 继续 loop → 调工具 → 后台跑完再回传结果。等价于网络里的全双工通信。

同类能力其实已有：Claude Code 的后台 subagent 可与主对话并行；ChatGPT 长任务运行中也能补充要求。DSH 已实现该机制，但尚未默认开启。

---

4. 计算、状态与环境的分离

三个概念先拆开：

• 计算 = Agent Loop 在跑的过程
• 状态 = 会话记录、任务记录
• 环境 = 代码仓库、本地文件、工具链

三步解耦：

1. 计算 × 状态：Agent Loop 放云端可替换容器，状态单独入库。容器挂了换一个，状态还在就能续跑。
2. 计算 × 环境：反向操作——本地环境不动，端上装轻量 daemon，只负责执行命令、回传结果。

为什么不把环境搬上云：真实环境有未提交的改动、私有凭据、特定硬件和工具链，搬上去跑出来结果大概率不一样。

这就是 BYOM，Bring Your Own Machine——个人电脑、甚至时不时才在线的机器都能接入。

⚠️ 前提：云端与端侧必须互相信任。云端一旦被攻破，它连着的所有设备都危险。

---

5. Watchdog：外部控制回路

持久在线的分布式系统，很难只靠主系统内部逻辑保证长期可靠。

关键洞察：Agent 挂掉往往不是进程丢了，而是 LLM 内部循环死锁或偏离执行目标——传统心跳/存活探测和监控脚本对此无能为力。

解法：在主系统之外引入独立的 Control Loop，即 Watchdog Session：

• 定时消息驱动
• 及时介入、发现异常、纠偏、故障恢复
• 本身也是一个 Agent Session，开发者可以直接向它询问错误原因

---

底层视角：所有 Agent 架构终归要回到计算机系统

"所有 Agent 架构，绕来绕去还是绕不开计算机底层的那些玩意。"

贯穿全文的类比清单：

Agent 概念	计算机系统原型
Inline / Spill	内存页换入换出
链式召回	指针 / 引用图
Worker fork subagent	CPU 线程 fork
投机执行	Speculative Execution
存算分离	Compute-Storage Separation
Watchdog	外部看门狗定时器

---

对我有用的几条结论

1. 别把 Session 甩给用户。需要用户当"项目经理"去切换多个 Agent 的产品，路线是错的。
2. 过滤要在最便宜的一层做完。绝大多数事件不值得动用模型。
3. 上下文预算要有显式的经济观。Inline 常用、Spill 冷数据，只留引用。
4. Router 用轻模型，Worker 用强模型。分派不需要聪明，干活才需要。
5. 保活 ≠ 心跳。真正要防的是"进程活着但目标跑偏"。
6. 抽象最终会撞上底层。Session 共享、缓存、线程、文件系统这些问题，绕不过去。