智能体架构：让“大脑”与“双手”分离

为什么要把“大脑”与“双手”分开？

构建智能体时，一个关键问题是：负责保存任务进展的系统，是否必须与执行代码的环境绑定在一起？

Anthropic 在 Managed Agents 中采用了分离设计：将会话日志和智能体运行框架（harness）与代码执行沙箱解耦。可以把前者理解为“大脑”，把后者理解为执行操作的“双手”。

运行框架可以持续存在，执行环境则按需创建。这样，即使某个沙箱发生故障，也不必让整个智能体会话随之消失。

早期的一种实现方式，是把整个编程智能体放进沙箱，再通过 API 提供访问。这样，环境和智能体的启动都会增加首次响应前的准备工作；如果沙箱消失，运行中的智能体也会一起中断。

将这些组件拆开后，平台可以在保持执行隔离的同时，分别优化启动延迟与运行可靠性。这里的重点不是取消沙箱，而是避免把会话的存续完全绑定在沙箱上。

这类分离也提供了一个重要的安全边界：如果服务凭证从未进入沙箱，沙箱中的生成代码就无法直接读取该凭证。

讨论中的设计将凭证单独保管，通过代理为请求附加认证信息，并配合对沙箱网络访问目标的限制。

这并不意味着单靠一项设计就能解决全部安全问题，但它明确了凭证管理、代码执行与网络控制之间的职责边界。

设计智能体运行时时，可以先回答三个问题：

这些问题比是否使用某个特定框架更基础，也能帮助团队判断哪些部分应该持久化、哪些部分可以重建。

模型能力升级并不只意味着替换一个模型名称，还可能改变应用的集成要求。

例如，跨轮次保留思考块的要求，会影响开发者已有的运行框架。即使某项变更有其保护模型推理的目的，也仍然需要考虑客户现有应用的兼容性。

因此，早期访问测试的价值不只是获得一个基准分数。客户在自己的框架中运行评测，能够暴露平台内部产品未覆盖的任务、环境和异常行为。

评测是否贴近真实用户任务，比单独追求一个漂亮分数更重要。

Managed Agents 也被用于探索记忆和多智能体工作流。

其中，Dreaming 的实现思路是：由一个智能体检查另一个智能体此前完成的工作，再将整理出的记忆写回。这是利用相同的底层智能体能力，组合出更高层行为的例子。

但讨论中的未来平台能力应被视为规划，而不是已经交付的功能承诺。记忆与学习依然重要，团队也表示，随着模型部署难度增加，近期更多注意力转向了安全。

另一条设计思路是让基础运行框架保持相对简单，把验证器、并行智能体等策略留给开发者在上层探索。

改进运行框架的过程，也因此越来越接近研究：确定目标、测量行为、检查失败，再持续迭代。模型可以协助构建和分析评测，但评测是否真正代表用户工作，仍需要人的判断。

对于正在搭建智能体系统的团队，值得优先检查的不是增加多少功能，而是会话状态、执行环境、凭证和评测之间，是否已经划出了清晰边界。