会话不该是人的工作单位：把状态与调度沉入 Agent 底层

今天人与 AI agent 的交互大多仍被框在聊天窗口里。无论是终端 CLI、IDE 侧边栏还是网页标签页，屏幕上总有三五个活跃会话同时闪烁。

当单任务模型推理能力逐步提升、不再需要人时刻盯着就能写完代码时，另一个瓶颈显现了出来：多任务协作卡在了人的注意力上。

经验表明，一个人通常最多同时跟住 3 到 5 个活跃会话。超过这个范围，人就得在不同窗口之间来回切换：等待 A 输出、把结果复制给 B、把 CI 报错贴给 C、提示停顿的 D 继续。人不知不觉成了多个会话之间的调度总线。

在 多 agent 系统的瓶颈不在模型，在模型外面的工程 里，我讨论过多 agent 系统在运行时、授权、隔离与急停等工程问题。若想进一步释放这类系统的效率，交互方式本身也需要演进：把会话从用户的心智和界面中抽离，让它沉入系统内部，成为底层的实现细节。

脑手解耦：Session 是事件账本，不是易失的聊天历史

目前的「会话」容易让人疲劳，原因是当前设计把太多职责揉在了一起：它既是交互界面，又是即时上下文，还是工具运行环境，甚至被当作长期记忆。一旦上下文超出窗口容量，要么裁减掉早期的关键决策，要么任由历史堆积导致响应变慢、注意力分散。

Anthropic 团队在 Claude Managed Agents 的实践中提出了一种解耦方式，把 agent 拆为三个独立构件：

1. Session（事件账本）：本质是追加写入（append-only）的事件日志，记录每一次用户意图、工具调用、输入输出与错误。Session 的生命周期可以长于单次模型的上下文窗口。有了完整的不可变日志，系统能在需要时回溯和重读历史，不必依赖容易失真的粗暴压缩。
2. Brain（无状态推理机）：即模型配合轻量 harness，扮演无状态的读者。面对漫长的 Session，Brain 根据当前任务动态决定上下文策略：按需倒带（rewind）、重读特定片段（reread）或接续执行（resume）。模型的上下文处理方式会随版本更迭，但 Session 接口应当比具体的模型假设活得更久。
3. Hands（可替换的沙箱与工具）：代码执行与工具调用环境应当与推理大脑保持隔离。沙箱可以按需创建、用完销毁。长期凭据与敏感权限不应直接存放在沙箱内，而是通过外部代理和受控凭据库在安全环境中调取。

长任务的闭环不依赖人持续催问进度，而是靠结构化的交付目标（Outcomes）与自动评分机制（graders）做判断；跨任务的经验沉淀，则由类似 Dreams 的离线流水线在后台把事件日志提炼为规则记忆。

Super-agent 调度：Router 保连续，隔离 Worker 保并发

当会话不再由人工在各个窗口间切换时，系统如何调度？DeepSeek Harness 团队在 Super-agent 架构设想中提出了分层思路。

要兼顾跨通道连续（Continuous）、并发吞吐（Productive）、主动监听（Proactive）与常驻在线（Persistent），依靠单个 agent 在单层长循环里处理往往很难走通，更现实的做法是两层分工：

• Router 负责全局交互与调度：用户无论从即时通讯、网页还是代码平台接入，对接的都是同一个逻辑 Agent。Router 掌握全局任务状态，负责理解意图、路由事件并派发工作，但不直接执行耗时的具体长任务，保持交互通道的通畅。
• 隔离 Worker 负责并行吞吐：Worker 运行在各自独立的隔离环境中，专门承接 Router 派发的明确任务。它们异步执行，直接修改环境，但不直接面对用户。
• 事件驱动 Triggers 与 Watchdog：监控警报、代码提交等外部事件可以直接触发工作流。代码级 Fast Path 用于过滤高频杂音，模型级 Slow Path 用于理解语义。系统外部运行独立的 Watchdog，观察任务存活状态，防止长时间挂起或偏离方向。

在 DeepSeek Harness 团队公布的合成负载实验中，两层分工架构在任务完成时间的 p50 和 p95 指标上，明显好于「单会话内调用 subagent 工具」的方案。在单会话内嵌套工具时，中性提示词下模型有时甚至一轮都不会主动委派；而透传（pass-through）机制主要用于减少 Router 的决策次数和 cache-read token，任务本身耗时其实差不多，它的收益在于减轻中央调度的开销，而不是让任务本身神奇变快。

常驻舰队与 Stigmergy：把等待从系统里拿掉

如果不仅减少人的调度负担，还想进一步压缩 agent 内部的等待时间，协作方式会有什么变化？Spawn 团队（jacob）分享过一种较为激进的尝试：团队配合常驻的 agent 舰队，保持小时级的持续出货。

这套逻辑的核心判断在于：系统的瓶颈往往不在于模型写代码的速度，而在于各处的等待——人等人、agent 等人、agent 之间互相同步。

为了减少等待，他们尝试了两项机制：

第一，Stigmergy（通过环境本身协调）。白蚁建造蚁丘不需要开会，而是通过泥土和周围环境状态的变化协同。常驻 agent 之间也不需要频繁跨窗口通信，甚至不需要走拉长周期的 Pull Request 审批。代码库、部署状态和线上监控就是协调介质。按 Spawn 的做法，多个 agent 直接向主分支提交变更，合入后依靠小时级代码整洁机制维持状态，一旦出错立刻派补丁 agent（janitor）叠修，而不是试图在合入前一次性修得毫无瑕疵。

第二，直接闭环到生产。agent 不再等待人来转述问题，而是直接读取生产错误日志、告警与用户反馈。按 jacob 的说法，他们约 60% 的任务直接来自生产异常。一旦出问题，agent 自己定位、修复、验证并尝试在一小时内上线。

在这套分工里，人的精力主要收缩到两个方面：

• Taste（品味与裁决）：对系统输出说「不」；定期删掉上一代模型遗留的过时防御规则；对超出已有案例的新场景做最终拍板。
• Entropy（引入不确定性）：模型通常擅长 2% 的渐进改进，不太会主动提出架构重构。人需要主动给出「重写系统模块」或「提升数十倍指标」这类跨越式目标。

现实边界与安全红线

这种高强度的持续协作模式有其特定的适用前提，很难直接套用：

首先，协作形态与底层模型的品性深度绑定。Spawn 的极速流转以模型具备高度的长程一致性为前提。如果所用模型在长流程中容易偏航，或出现过于激进与保守的极端行为，直接改生产会很快放大问题。

其次，依赖快速回滚与工程兜底。敢于取消 PR 直接在生产迭代，按作者自述，前提是他们拥有约 30 秒定点回滚的能力、小时级整洁机制，以及非常低的回滚率。缺乏这种自动化安全底座的团队，照搬这一流程只会带来线上事故。

最后，凭证隔离是关键的安全边界。当云端 agent 持续读取不可信的外部事件输入，而执行沙箱又具备运行环境时，一旦遇到注入攻击，就存在被滥用的风险。长期凭据不应直接暴露给模型上下文，系统需要做到模型可以使用凭据完成动作，但模型本身看不到凭据内容。

此外，当会话不再作为主要的界面呈现后，人该通过怎样的交互形式了解数十个后台任务的状态并在需要时低成本介入，目前整个行业依然在探索之中。

我自己的小规模版本

在日常维护 perryOS 的多 agent 协作中，我也经历过会话膨胀带来的阻碍，逐步摸索出几条做法：

• 不在长会话里一轮接一轮派活：我以前给子 agent 派活时，会在同一个长会话里一轮接一轮地派；其中一个执行方的会话文件涨到 20MB 以上，每次请求都要带上全部历史，响应变慢，也更容易被旧内容带偏、多读文件；主 agent 自己一小时的会话记录也能涨到 12MB，主要是截图和长输出。
• 每轮任务开新会话：上一轮验收完成后，派下一轮任务前，让执行方开一个新会话（在终端使用 /clear 或 /new），不再沿用旧会话累加历史。
• 文档才是记忆，会话不是记忆：新会话没有之前的上下文，下一轮所需的背景、方案路径、已定决策和上一轮改动结果，都写进任务描述或 handoff 文档里。会话更像临时的 RAM，文档才是系统的持久存储。
• 主 agent 同样按文档接续：负责协调的主 agent 也不维持单一长会话。每轮结束后把结论、决策和下一步写进 handoff 文档，上下文变大后同样重开新会话，从文档接下去做。

我还不确定的地方

把会话沉入系统底层在方向上比较明确，但落实到具体项目仍有几个疑问：

一是环境级协作中的隐性冲突。代码库和业务逻辑依赖很多抽象约定。当多个常驻 agent 高频提交代码且互不直接通信时，即便各自单测能跑通，怎样防止它们对底层架构的理解发生微小分歧，进而造成长期的认知割裂？

二是个人与小团队的工程成本。搭建一套包括 Router、隔离沙箱、事件网关与凭证代理的运行时需要不少前期投入。对于资源有限的个人或小团队，维护这套体系节省下来的注意力，能否抵消掉搭建和调试它的工作量？

接下来想弄清楚的问题

• 当聊天窗口退居幕后，什么样的界面（如看板、时间线或状态流）能让人在几秒钟内看清多个后台 agent 的进展，并支持顺畅的人工介入？
• 如何设计轻便的凭据隔离方式，让本地或云端 agent 在调用 GitHub 或云端 API 时，避免 API 密钥流入模型上下文？
• 类似 Anthropic 提到的 Dreams 机制，如何构建一套轻量的离线提炼流程，定期把多个 agent 的运行日志压缩为有价值的记忆规则，并自动过滤过时内容？

参考

• 《Exploring Super-agent Design: Towards a More Autonomous Agent System》：DeepSeek Harness 团队（主笔 Yujia Qiao 等）于 2026 年 11 月 1 日发表于 X。文章探讨了 Super-agent 架构设想，指出多任务受制于人脑跟住多个会话的注意力限制（约 3～5 个），提出通过两层架构（Router 负责全局交互与调度、隔离 Worker 负责执行）、事件驱动 Triggers 与 Watchdog 将会话沉入底层，并在合成负载实验中对架构与透传收益做了量化评估，同时强调了凭证安全边界。
• 《Anthropic engineers 90-minute course on building AI agents (AI Engineer World's Fair)》：Anthropic 团队在 AI Engineer World's Fair 上的技术公开课，由 Anatoli Kopadze 于 2026 年 10 月 30 日分享。课程阐述了 Claude Managed Agents 架构，提出将系统解耦为 Session（append-only 事件账本）、Brain（无状态推理机与 harness）与 Hands（可替换的沙箱与工具），并介绍了凭据代理隔离、长任务 Outcomes 判定与 Dreams 记忆提炼机制。
• 《How I Built the Most AI-Pilled Company in the World》：Spawn 创始人 jacob（@jsnnsa）于 2026 年 10 月 29 日发表于 X。文章复盘了十人团队与常驻 agent 舰队的协作实践，提出通过 Stigmergy（通过代码与线上环境状态协同，取消常规 PR 流程）与生产事件闭环来消除系统等待，人主要承担品味裁决与非线性目标设定，同时指出该模式强依赖模型长程一致性与快速回滚能力。