Anthropic 为什么要重做 Agent 基础设施？这篇文章把底层逻辑讲透了

这两天，Anthropic 工程团队发了一篇很值得细读的文章，主题是 Managed Agents。

如果你平时关注 AI Agent、自动化工作流、Claude Code、MCP、长期运行任务，这篇文章的价值非常高。因为它讨论的不是“怎么写一个 demo agent”，而是一个更底层的问题：

当模型越来越强，Agent 系统到底应该怎么设计，才不会很快过时？

我读完之后的最大感受是，Anthropic 这次不是在讲一个功能，而是在讲一套未来几年的 Agent 基础设施思路。

原文链接：https://www.anthropic.com/engineering/managed-agents

一、Anthropic 想解决的，到底是什么问题？

今天很多人做 Agent，常见路径都是这样：

• 直接调模型 API
• 在外面包一层 harness
• 给它接工具调用
• 再做上下文管理、状态管理、错误恢复
• 最后拼出一个能跑任务的 agent

短期看，这条路没问题。

但随着模型能力不断增强，一个很现实的问题会越来越明显：

你写的 harness，可能会比模型本身更快过时。

Anthropic 在文中举了一个很典型的例子。

他们以前发现 Claude Sonnet 4.5 在接近上下文上限时，容易因为“怕上下文不够”而提前结束任务。于是，他们就在 harness 里加了一套 context reset 机制，帮助模型继续工作。

当时这招是有效的。

但后来他们把同样的 harness 用到 Claude Opus 4.5 上，发现这个问题已经消失了。也就是说，之前专门写的补丁，反而成了没必要的负担。

这背后的结论很重要：

很多 harness，本质上都写满了“模型现在还做不到什么”的假设。可这些假设，未来会持续失效。

所以 Anthropic 的方向不是继续堆补丁，而是后退一步，重新定义 Agent 系统最稳定的那层接口。

二、Managed Agents 的核心，不是“更强的 Harness”，而是“更稳定的抽象”

这篇文章里我最喜欢的一点，是它借用了操作系统的设计思路。

早期计算机硬件变化非常快，但操作系统之所以能跨越这么多年，靠的不是把自己绑死在某一代硬件上，而是把底层能力抽象成稳定接口，比如：

• process
• file
• read()

底层硬件一直在变，但这些接口长期有效。

Anthropic 想做的，其实也是类似的事情。

他们把一个 Agent 系统拆成了三个部分：

1. Session

可以理解为“这个 agent 做过什么”的完整事件日志。

不是简单聊天记录，而是一条可持续追加、可恢复、可查询的事件流。

2. Harness

负责调用 Claude、接工具调用、驱动 agent 循环。

3. Sandbox

Claude 真正执行代码、编辑文件、运行任务的地方。

把这三部分拆开之后，系统就不需要再把所有状态绑在同一个执行环境里。谁挂了，就单独恢复谁，而不是整个 agent 一起陪葬。

这就是 Managed Agents 最核心的架构思想。

三、为什么“一体化容器”会越来越难用？

Anthropic 说，他们一开始也试过把 session、harness、sandbox 都塞进同一个容器里。

这么做最直观，开发也简单。

但问题很快暴露出来。

问题 1：容器变成“宠物”，不能轻易死

在基础设施领域有个经典比喻，叫 pets vs cattle。

• Pet：你得小心呵护，一旦出问题就得人工抢救
• Cattle：可以替换、可以重建、挂了也没关系

如果 Agent 的所有关键状态都在同一个容器里，那这个容器就会变成 pet。

后果就是：

• 它挂了，session 状态一起丢
• 它卡住了，工程师要进去排查
• 调试能力会和用户数据缠在一起
• 整体系统的恢复能力很差

这对长时间运行的 Agent 来说，是非常危险的。

问题 2：资源位置被写死了

如果 harness 和 sandbox 绑定在一起，那系统天然会假设 Claude 要访问的资源也和它在同一个环境里。

可一旦用户想让 Claude 连到他们自己公司的 VPC、私有代码库、内部工具系统，这种假设就会立刻变成限制。

换句话说，原本是工程实现细节，最后却变成了产品边界。

四、Anthropic 最关键的设计：把“脑、手、会话”分开

这篇文章最值得记住的一个比喻，就是把 Agent 系统拆成：

• 脑（Brain）：Claude + harness
• 手（Hands）：sandbox、工具、执行环境
• 会话（Session）：完整事件日志

这套拆分非常妙，因为它解决了三个长期难题。

1. 可恢复性更强

只要 session 在外部持久保存，harness 就算崩了，也可以重新拉起。

新实例只要：

• 找回 session
• 读取历史事件
• 从上次中断位置继续执行

这意味着 agent 不再依赖“某个幸运活着的进程”。

2. Sandbox 真正变成工具

Anthropic 把 sandbox 当成一个普通工具接口来调用，形式很像：

execute(name, input) -> string

这件事非常关键。

因为一旦你这样抽象，sandbox 就不再是 agent 身体的一部分，而是它随时可替换的一只“手”。

如果某个 sandbox 挂了，Claude 看到的只是一次工具失败，它完全可以决定重试，或者换一个新环境继续。

3. 系统能自然扩展到 many brains, many hands

这也是我觉得 Anthropic 特别有前瞻性的地方。

他们不是只想解决“一个 agent 跑一个任务”，而是在为未来更复杂的场景做准备：

• 多个 brain 并发
• 多个 hand 协同
• 多个 sandbox / MCP / 外部设备混合接入
• 不同 brain 之间共享或传递 hands

如果未来 Agent 真要承担越来越复杂的长期工作，这种架构几乎是必需的。

五、这篇文章里对安全的理解，也很值得注意

文章里还有一段我非常认同。

Anthropic 认为，很多人喜欢通过“限制 token 权限”来防 prompt injection，这是必要的，但还不够。

因为这种防法，默认前提还是：

模型暂时还做不到某些危险动作。

但问题是，模型会持续进步。

所以真正稳健的方案，不应该只是“希望模型别拿到凭证”，而是：

从结构上让它拿不到。

这就是他们为什么强调：

• 凭证不要暴露给 sandbox
• Git token 在初始化阶段使用，不直接暴露给 agent
• OAuth 等外部服务凭证放进 vault
• Claude 通过代理层访问 MCP 工具，而不是自己碰到真实凭证

这是一种更偏系统设计层面的安全观，而不是“功能性权限裁剪”。

六、为什么说 Session 不等于上下文窗口？

这一点也很重要。

做过长周期 Agent 的人都知道，context window 总会不够。

常见做法通常是：

• 压缩摘要
• 写记忆文件
• 裁剪旧消息

这些方法都能用，但有个共同问题：

一旦你压缩或裁剪，很多信息其实就不可逆了。

而在长任务里，你很难提前知道哪一段历史以后还会不会被重新用到。

Anthropic 的处理方式是，把 session 设计成一个独立于 Claude 当前上下文窗口之外的“可恢复上下文对象”。

什么意思？

就是：

• 当前 prompt 里放什么，由 harness 决定
• 但完整历史不丢，统一保存在 session log
• 需要的时候，可以重新按位置切片读取事件

这相当于给长周期 Agent 提供了一个真正可恢复的外部记忆层。

我觉得这是这篇文章里最有长期价值的设计之一。

七、这套设计直接带来了什么收益？

文章里有一个很具体的数据。

因为不再要求每个 session 一开始就先起完整容器，只有在真的需要 sandbox 时才去 provision，所以系统首 token 时间明显下降：

• p50 TTFT 下降约 60%
• p95 TTFT 下降超过 90%

这意味着，用户体感会直接变快。

而且，这还不是唯一收益。

更大的收益是：

• 系统更容易恢复
• 更容易接入企业内网资源
• 更适合长期任务
• 更适合未来多 agent 协同
• 更容易替换底层 harness 和 sandbox

这些其实都是 Agent 真正进入生产环境后，迟早会遇到的问题。

八、我的判断：Anthropic 不是在发布功能，而是在定义下一代 Agent Infra

如果只把 Managed Agents 理解成“Anthropic 提供的托管 Agent 服务”，其实有点低估它了。

我更倾向于把它理解成：

Anthropic 正在试图把 Agent 从一套临时拼接的工程脚手架，提升成可以长期演化的系统基础设施。

这里面最值得借鉴的，不一定是它具体的 API 形态，而是它背后的设计原则：

1. 不要把系统绑死在当前模型短板上
2. 把状态从执行进程里拿出来
3. 把执行环境当成可替换工具，而不是 Agent 本体
4. 把安全边界建立在结构隔离上
5. 把“未来变化”当成确定事实来做架构设计

这一点，对所有在做 Agent 产品、自动化平台、研究型工作流的人，都非常有参考意义。

九、最后说一句

如果你最近在思考这些问题：

• Agent 为什么一到长任务就不稳定
• 为什么上下文越长越难管
• 为什么很多 Agent demo 看着强，真进生产就脆
• 为什么 tool use、sandbox、memory、security 总是缠在一起

那这篇文章值得认真读一遍。

因为它讲的不是一个小技巧，而是一个更像“未来 Agent 操作系统”的方向。

我觉得这会是未来很长一段时间里，理解 Agent 基础设施演进的一篇关键文章。