一个被迫的架构选择想象这样一个场景你的Agent系统在生产环境里跑了一天突然容器崩溃了。不是业务逻辑的问题就是这个容器死了。最恐怖的不是容器重启——而是会话丢失了。用户的整个工作上下文、已执行的步骤、中间结果全部消失。你得打开shell进容器看看发生了什么。但问题是这个容器里既放着Claude的推理过程又放着用户的代码执行环境还有数据库凭证。光是进去调试就已经是个安全灾难。Managed Agents 组件抽象这是早期Agent系统设计者必然碰到的痛点。当把所有东西塞进一个容器时系统本质上变成了宠物而不是家畜——用云计算领域的老比喻。宠物需要手工呵护、个性化配置、不能随意替换家畜是标准化的、可互换的、出问题直接换新的。Anthropic最近发布的Managed Agents架构核心思想就是一次彻底的脑手分离。这不是功能升级而是系统观的根本改写。旧设计暴露的三个矛盾在单容器架构下系统维护者面临三个无法同时满足的需求**第一个矛盾稳定性与可观测性。**当会话、推理逻辑、沙箱执行全部耦合在一个进程里故障诊断就变成了薛定谔的bug。WebSocket事件流告诉你出错了但看不出是Claude生成了坏指令、网络丢包、还是容器卡住了。想要进去debug就得直接访问生产数据和凭证所在的环境——这本身就是个安全洞。系统越来越像一个黑盒非要人工干预才能恢复。**第二个矛盾连接灵活性与假设耦合。**容器设计天然假设所有资源都在本地或同一个网络内。当企业客户说Claude能连到我们的VPC吗答案只能是可以但你们得跟我们做网络对等。这个假设被硬编码到了推理循环里改不了。**第三个矛盾性能与成本。**每个新会话都要从零开始启动容器、克隆代码库、启动进程、拉取待处理事件。即使这个会话根本不需要执行代码只是想问个问题也要等一整套基础设施启动。用户能感受到的Time to First TokenTTFT从用户提问到收到第一个回复字符的延迟被人为地打了个很长的基础设施税。脑手分离的系统设计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、碰运气而是能够观测、诊断、迭代的可控系统。