一个被迫的架构选择

想象这样一个场景：你的Agent系统在生产环境里跑了一天，突然容器崩溃了。不是业务逻辑的问题，就是这个容器死了。最恐怖的不是容器重启——而是会话丢失了。用户的整个工作上下文、已执行的步骤、中间结果，全部消失。

你得打开shell进容器看看发生了什么。但问题是：这个容器里既放着Claude的推理过程，又放着用户的代码执行环境，还有数据库凭证。光是进去调试，就已经是个安全灾难。

Managed Agents 组件抽象

这是早期Agent系统设计者必然碰到的痛点。当把所有东西塞进一个容器时，系统本质上变成了"宠物"而不是"家畜"——用云计算领域的老比喻。宠物需要手工呵护、个性化配置、不能随意替换；家畜是标准化的、可互换的、出问题直接换新的。

Anthropic最近发布的Managed Agents架构，核心思想就是一次彻底的脑手分离。这不是功能升级，而是系统观的根本改写。

旧设计暴露的三个矛盾

在单容器架构下，系统维护者面临三个无法同时满足的需求：

**第一个矛盾：稳定性与可观测性。**当会话、推理逻辑、沙箱执行全部耦合在一个进程里，故障诊断就变成了"薛定谔的bug"。WebSocket事件流告诉你"出错了"，但看不出是Claude生成了坏指令、网络丢包、还是容器卡住了。

想要进去debug，就得直接访问生产数据和凭证所在的环境——这本身就是个安全洞。系统越来越像一个黑盒，非要人工干预才能恢复。

**第二个矛盾：连接灵活性与假设耦合。**容器设计天然假设所有资源都在本地或同一个网络内。当企业客户说"Claude能连到我们的VPC吗"，答案只能是"可以，但你们得跟我们做网络对等"。这个假设被硬编码到了推理循环里，改不了。

**第三个矛盾：性能与成本。**每个新会话都要从零开始启动容器、克隆代码库、启动进程、拉取待处理事件。即使这个会话根本不需要执行代码，只是想问个问题，也要等一整套基础设施启动。

用户能感受到的Time to First Token（TTFT）从用户提问到收到第一个回复字符的延迟，被人为地打了个很长的基础设施税。

脑手分离的系统设计

Anthropic的解决方案借鉴了操作系统的古老智慧。Unix设计哲学里，进程、文件、socket这些抽象之所以能活50年，是因为它们定义了接口而不是实现。read()命令不关心底下是磁带还是SSD，只要接口一致。

Managed Agents复用了这个模式。系统被虚拟化为三个独立的抽象层：

Brain（脑）： Claude本身加上推理循环（harness）。它决策、规划、调用工具。

Hands（手）： 所有的执行环境和工具接入点。可能是代码沙箱、Git仓库、HTTP接口、MCP服务，甚至物理设备。

Session（会话）： 一个不可变的事件日志。记录了这个Agent从开始到现在的所有动作、思考、观察。

关键的架构转变是：这三层之间只通过定义明确的接口交互。

Brain不再在容器里

在旧架构里，推理循环住在容器内部。新设计里，Brain变成了一个无状态的微服务。它调用手（Hands）的方式统一：execute(name, input) → string。

一个代码执行请求、一个Git操作、一个API调用，在Brain看来都是同样的接口。容器不再是特殊的——它就是一个可执行的工具。

这带来的直接好处：容器可以出故障，Brain继续存活。如果容器崩溃了，Brain会像处理任何工具调用失败一样处理它——询问Claude"要重试吗"。需要的话，一个新容器按标准配置provision({resources})重新启动。

没有人手调试，没有数据丢失。系统从"宠物"变成了"家畜"。

Session活在容器外部

会话日志从容器内迁移到了独立存储。推理循环执行每一步时，都向Session写入emitEvent(id, event)。

这样一来，Brain可以出故障。wake(sessionId)把一个新的Brain实例唤醒，它能够getSession(id)拉取完整的事件历史，从最后一个已完成的事件之后继续工作。

没有什么需要在Brain内部存活下来——它的存在只是为了处理一个工作单位，完成就释放。

对于超长任务，这个设计还解决了一个经典的长上下文问题。Claude的上下文窗口有限，传统方案要么丢弃旧信息（不可逆），要么用摘要压缩（可能丢失关键细节）。

Brain、hands 与 session 解耦

新方案让Claude通过getEvents()接口随时查询Session中的历史事件。需要回顾某个决策的前因后果？就切片查询对应的事件范围。

Brain可以在拉取事件后进行任意的上下文工程处理——组织格式以优化prompt cache命中率、提取关键信息、添加注释——然后再放入Claude的上下文窗口。

关键是：历史是完整的、持久化的、可回溯的，处理是灵活的、可替换的。

Hands成为可互换的工具

容器以前是Agent唯一能执行代码的地方。现在它只是众多"手"之一。Git服务器、API网关、MCP服务、甚至手机上的应用——只要实现execute(name, input) → string接口，就能接入。

Brain根本不知道、也不关心一个手的物理实现。它看到的就是：发送请求，得到结果。一个手故障了，Brain要么重试，要么尝试另一只手，要么告诉Claude"这条路走不通"。

这个设计的威力在于：多个Brain可以共享一组Hands，或者一个Brain可以调度到多个Hands。假设你有五个Claude推理实例和十个代码沙箱。旧方案需要创建五个容器，每个容器绑定特定的计算资源，很多时候是浪费。

新方案里，Brain是无状态的，只在需要的时候才去invoke沙箱。

这也直接解决了企业客户的VPC连接问题。Brain可以远程部署，Hands可以在客户的网络内。Brain通过一个代理调用远程Hands，不需要直接网络连接。

安全边界的重构

单容器架构有个致命的安全假设：生成的代码和凭证在同一个沙箱里运行。任何提示词注入只需要让Claude读取环境变量，立刻就能拿到数据库密钥、OAuth令牌。有了这些，攻击者可以生成新的、不受约束的会话。

脑手分离从结构上消除了这个风险。凭证不再可能被代码访问。

具体做法有两种模式：

绑定模式： Git仓库的访问令牌在沙箱初始化时就用上了——克隆仓库、配置本地Git remote。之后的git push和git pull完全在本地执行，Agent永远看不到那个令牌。

代理模式： 对于自定义工具和MCP服务，Anthropic支持OAuth的代理转发。Claude调用工具时，不是直接传令牌，而是通过一个代理。代理拿着会话关联的令牌标识去安全的vault里查询实际凭证，然后代表会话调用外部服务。

Harness从不接触任何凭证。

这种设计下，即使Claude的代码被注入恶意指令，也拿不到任何凭证。最多是生成错误的代码、调用不存在的工具，但无法越界。

性能杠杆：TTFT的60%-90%改善

脑手分离最直观的收益体现在时间上。用户提问到收到第一个回复字符（TTFT），在Anthropic的数据里，中位数下降了60%，95百分位下降了超过90%。

这怎么做到的？因为Brain不再需要容器一启动就跑。

旧方案：启动容器→拉启动脚本→克隆代码库→启动进程→拉待处理事件→开始推理。这个链路即使空转，用户也得等。

新方案：拉待处理事件→开始推理→需要执行时才invoke容器。很多简单的问题根本不需要沙箱，Brain立刻就能回答。

具体来说，容器是通过Brain发出的一个工具调用execute(name, input)来启动的。如果这个会话不需要执行代码，那个容器就永远不会被启动。推理可以在毫秒级别开始，而不是等容器从冷启动中唤醒。

这个改进对用户体验的影响是非线性的。首次交互的延迟直接影响用户对系统的心理评价。一个60%的TTFT改进，在感知上就像换了个新系统。

落地的工程检查表

如果你要在自己的Agent系统里应用脑手分离的思想，以下是必须审视的核心问题：

第一层：状态管理

• 你的会话上下文现在存在哪里？容器进程内存？如果崩溃了能恢复吗？

• 是否所有的决策点都被完整记录了？能否让新的Brain实例从任意一个检查点恢复？

• 你的上下文管理策略是不可逆的（丢弃+摘要）还是可查询的（保存+切片）？

第二层：执行隔离

• Brain和执行环境现在是否耦合？有没有可能把推理逻辑和代码执行分开部署？

• 你的系统能否同时连接多个不同的执行环境（比如本地沙箱+客户VPC+公有云函数）？

• 多个推理实例能共享一组执行环境吗，还是每个Brain都得绑定一个沙箱？

第三层：安全边界

• 凭证现在存在哪里？生成的代码能否直接访问它们？
• 有没有办法让凭证在代码执行前就"被消费"（比如在初始化时绑定），而不是在执行时才传递？

Session 作为可查询的上下文对象

• 外部工具的认证是否经过一个不信任的代理，而不是让Agent代码直接持有令牌？

第四层：可观测性与恢复

• 推理循环的每一步都被持久化记录了吗？
• 如果Brain崩溃，你能否通过日志判断是哪一层出的问题（Brain逻辑vs执行环境vs网络）？
• 容器故障时，系统能否自动重试或迁移，而不需要人工介入？

第五层：性能指标

• 你有没有衡量TTFT的能力？它现在是多少？
• 空容器启动占了多少比例的首次响应延迟？
• 是否有会话完全不需要执行环境，却仍在等待容器启动？

多脑多手的复杂性

脑手分离解锁了新的扩展维度。

多个Brain，一组Hands。 当Claude变得更聪明，一个Brain不够了——可能需要并行跑多个独立的推理任务，或者多个Claude实例协作。新架构下，这些Brain可以共享相同的Hands。

不需要部署多套基础设施，只需要启动更多的无状态推理循环。资源利用率大幅提升。

一个Brain，多个Hands。 更复杂的是让一个Brain学会在多个执行环境之间推理。一个任务可能需要在沙箱里写代码、通过API调用外部服务、在Git仓库里提交、在客户的VPC里运行数据处理。

Brain必须理解这些执行环境的特点，决定何时使用哪一个。

这比单容器模式要求更高的Agent智能。早期模型干不了这个事，所以最初的设计就是单容器。但随着Claude变强，这个限制反而成了瓶颈。Managed Agents把这个决策权还给了模型。

Hands之间的委派。 一个更激进的设计空间是：Brain可以把一个Hand作为参数传递给另一个Brain。比如一个专家Brain处理AI训练任务，它需要调用数据处理Brain来预处理数据。

两个Brain的会话是独立的，但它们能通过接口互相引用对方的Hands。这开启了分布式Agent系统的可能性。

元架构：为未来的不确定性设计

这是Managed Agents设计的最深层的哲学。

操作系统的伟大之处不是它当时支持的程序——而是它定义了那么少的抽象，以至于现在写的程序仍然能在50年前的接口上运行。

open()、read()、write()这几个系统调用从未改变，但它们能适应从磁带到SSD、从单核到多核、从本地到分布式的所有变化。

Anthropic把这个思想推到了Agent系统上。他们意识到：我们不知道未来的Claude会需要什么样的推理循环。

现在Claude Code是一个很好的通用harness。但也许未来会出现专为长期规划优化的harness、为多智能体协作优化的harness、为在线学习优化的harness。

Managed Agents不试图预测这些。它只定义了最小的、稳定的接口：

• 需要操作持久化状态（Session）的能力。
• 需要执行计算（Hands）的能力。
• 需要扩展到多个Brain和多个Hands的能力。

Beyond这些，everything是可替换的。什么样的推理策略、什么样的提示词工程、什么样的上下文管理——这些都可以在harness层进化，而不需要改动系统其他部分。

这就是为什么论文里引用了Eric Raymond关于"programs as yet unthought of"的论断。这个系统的设计目标根本不是满足今年的产品需求——而是给未来十年的Claude留出足够的想象空间。

生态的分化与整合

这个架构变化会如何影响开发者生态？

短期内，Managed Agents会成为企业Agent应用的默认基础设施。不需要自己维护容器、担心故障恢复、设计安全沙箱的企业，会直接用Anthropic提供的托管服务。这会降低Agent应用的进入门槛。

Many brains many hands 架构

但更深远的影响在于：harness变成了一个独立的生态。

CloudFlare有workers、AWS有Lambda，都是基于相同的底层执行模型延伸出的开发者生态。

未来可能会有类似的局面：Anthropic定义了Brain/Hands/Session接口，然后：

• 开源社区贡献新的harness实现，针对特定领域优化。

• 工具厂商（比如代码编辑器、IDE、数据平台）主动实现Hands接口，让Claude能更深度地集成。

• 企业客户开发内部的自定义Brain，用统一的Hands基础设施。

这会打破现在"一个Claude实例对应一个应用"的模式，变成"一个Claude实例可以调度多个服务"的网络型架构。

同时，可观测性和调试工具会成为新的商业机会。既然Session是完整的、持久化的、可查询的，那就有机会产生：日志分析工具、Agent行为追踪、性能剖析、异常检测这一整套工程工具。

最终，这会推动Agent系统从"黑魔法"变成"工程学"。不再是猜prompt、碰运气；而是能够观测、诊断、迭代的可控系统。