Claude Managed Agents：当 AI Agent 有了自己的"操作系统"

2026 年 4 月 8 日，Anthropic 发了一篇博客，标题是 "Claude Managed Agents: get to production 10x faster"。

没有发布会，没有 CEO 站台演讲，甚至没有一个演示视频。就这么安安静静地上线了一个公测。

但如果你在过去半年里尝试过把任何一个 AI Agent 从 Demo 搬到生产环境，你就会知道——这可能是 2026 年到目前为止，对开发者影响最大的一次发布。

为什么？

因为 Anthropic 做了一件所有 Agent 开发者梦寐以求、却没人愿意自己干的事：它把 Agent 的"操作系统"给你包好了。

你不用再操心沙箱怎么隔离、崩溃了怎么恢复、凭证怎么不泄漏。你只需要告诉它：我的 Agent 要干什么。

听起来太美好了？让我一层一层拆给你看。

Agent 上线为什么这么难？

你一定见过这样的 Demo：有人录了一段 30 秒的视频，Agent 自动写代码、自动跑测试、自动部署，流畅得像魔法。

然后你兴冲冲地去复现，发现——

Agent 需要一个沙箱来跑代码，但你得自己搭容器编排。Agent 需要访问 GitHub，但 OAuth token 不能暴露给生成的代码。Agent 跑到一半崩了，所有上下文全丢，得从头来。Agent 要调外部 API，但权限控制、速率限制、错误重试全得你写。

这就是业界臭名昭著的 Harness Problem——Agent 的"智能"部分（大模型推理）可能只占你 10% 的工作量，剩下 90% 全是基础设施：执行环境、状态管理、安全隔离、故障恢复。

打个比方：大模型是发动机，Agent 是整辆车。发动机再牛，没有底盘、刹车、转向系统，你也没法上路。而大多数团队花在"造底盘"上的时间，比调模型的时间长 10 倍。

常见误解

很多人以为 Agent 开发的难点在 Prompt Engineering 或模型选择。实际上，模型能力早已"够用"了。真正卡脖子的是基础设施——沙箱隔离、状态持久化、凭证管理、崩溃恢复。这些东西不性感，但缺一个就上不了线。

Notion、Rakuten、Asana 这些公司能把 Agent 用到生产里，不是因为它们的 Prompt 写得比你好。而是因为它们有专门的基础设施团队，花了几个月时间把这些"脏活累活"全干了。

Anthropic 的判断是：这些活，不应该每个团队都重复造一遍。

90% 的 Agent 死在了从 Demo 到生产的路上，不是因为不够聪明，而是因为没有路。

"脑"和"手"为什么要分开？

Managed Agents 的核心架构，可以用六个字概括：脑手分离，会话持久。

具体来说，Anthropic 把一个 Agent 拆成了三个独立的组件：

Brain（脑）：Claude 模型 + Harness 循环。负责思考、决策、生成工具调用指令
Hands（手）：一次性沙箱容器。负责执行代码、读写文件、调用外部 API
Session（会话）：一条只追加的事件日志。记录 Agent 做过的每一件事

这三个组件互相独立，不共享进程，不共享内存，甚至不需要同时存在。

Managed Agents "脑手分离"三层架构

你可能会问：为什么非要分开？放在一起不是更简单吗？

Anthropic 工程团队在博客里用了一个精彩的类比：这就像操作系统里的 read() 命令。

1970 年代，read() 读的是磁盘包。2026 年，read() 读的是 NVMe SSD。硬件换了无数代，但接口从没变过。抽象比实现更长寿。

Managed Agents 的 Harness 对所有工具都只暴露一个接口：

// 无论是容器执行、MCP 工具还是外部 API，统一接口
execute(name, input) → string

容器可以随时销毁重建，模型可以换代升级，MCP 工具可以增删——但这个接口不变。

这带来了一个极其重要的实际好处：性能飙升。因为"脑"不需要等"手"准备好才开始工作。Anthropic 的内部测试数据显示，这种解耦让 p50 首 token 延迟降低了约 60%，p95 更是降低了超过 90%。

关键区别

传统 Agent 架构是"脑手一体"——模型推理和代码执行跑在同一个进程里。Managed Agents 是"脑手分离"——Brain 是无状态服务，Hands 是一次性容器，Session 是独立存储。三者解耦意味着任何一层都可以独立扩展、独立故障、独立替换。

好的架构不是让你跑得更快，而是让你摔倒了能立刻爬起来。

崩溃了怎么办？

Agent 跟传统应用有一个本质区别：它是长时运行的。

一个普通 API 调用，几百毫秒就结束了。但一个 Agent 任务——比如"帮我把这个仓库从 JavaScript 迁移到 TypeScript"——可能要跑几十分钟，甚至几个小时。中间要调用几十上百次工具。

跑这么久，崩溃是必然的。网络抖动、容器 OOM、模型超时……问题不是"会不会崩"，而是"崩了之后能不能接着来"。

这就是 Session 日志存在的意义。

想象你在打一个 RPG 游戏。如果游戏只有一个存档槽，而且存在内存里——断电就全丢。但如果游戏每走一步都自动存盘到硬盘上，断电后重新开机，你还在同一个位置。

Managed Agents 的 Session 就是这个"自动存盘"。每一次工具调用的输入输出、每一次模型的思考过程，都会实时写入一条只追加的事件流。这个事件流存在 Brain 和 Hands 之外，独立持久化。

所以当 Harness 崩溃时，恢复只需要一行：

// Harness 崩溃后，新实例接管
wake(sessionId)

// 读取事件流，从上次中断处继续
const events = getEvents(sessionId, { from: lastProcessedIndex })

新的 Harness 实例调用 wake(sessionId)，从事件流里读取上下文，直接从断点继续。不丢状态，不重复执行。

"Because the session log sits outside the harness, nothing in the harness needs to survive a crash."
—— Anthropic Engineering Blog

这句话是整个架构的灵魂：因为状态不在进程里，所以进程不需要"活着"。

有意思的是，这个设计跟分布式系统里的"事件溯源"（Event Sourcing）如出一辙。Kafka 能做到消费者挂了换一个接着消费，就是因为 offset 存在消费者之外。Managed Agents 的 Session 日志，本质上就是 Agent 世界的 Kafka。

insider 视角

Anthropic 内部测试发现，在长时任务中，Agent 的故障恢复能力直接影响任务成功率。有了 Session 日志 + 自动恢复，复杂文件生成任务的成功率比标准 Prompt 循环高出最多 10 个百分点。对于跑几十分钟的任务来说，这个差距是巨大的。

你不需要 Agent 永不崩溃。你需要的是，崩溃了跟没崩溃一样。

凭证安全怎么保证？

如果说前面讲的是"怎么让 Agent 跑得稳"，这一节要讲的是"怎么让 Agent 跑得安全"。

Agent 最让安全工程师头疼的一点是：它会生成并执行代码。

想想这个场景：你的 Agent 需要访问 GitHub 来提交 PR。它需要一个 OAuth token。但 Agent 同时也在沙箱里执行自己生成的代码。如果 token 暴露在沙箱环境变量里，那 Agent 生成的任何代码都能读到这个 token。

这不是假设场景。Prompt 注入攻击已经证明，大模型可以被诱导执行恶意指令。如果被注入的代码能拿到你的 GitHub token……后果你可以想象。

Managed Agents 的解法很干脆：凭证永远不进沙箱。

打个比方：你住酒店，前台帮你办入住。你的房间（沙箱）里有床有桌子有 Wi-Fi，但没有前台的电脑系统。你要订外卖（调外部 API），得打电话给前台，前台帮你下单。你永远拿不到前台的登录密码。

具体实现上，Anthropic 做了三层隔离：

Git 凭证：用于初始化沙箱环境（比如 clone 仓库），但凭证只在宿主机层面使用，沙箱内的代码看不到
OAuth token：存储在独立的安全保险库（Vault）中，通过一个专门的代理服务访问。Agent 调用 MCP 工具时，代理拿着会话级别的 token 去保险库换真正的凭证，然后代替 Agent 发起请求
Harness 本身：也不持有任何凭证。Harness 只是一个"路由器"，把 Agent 的工具调用请求转发给对应的执行层

凭证隔离架构：Agent 沙箱永远接触不到真实凭证

注意这个设计的精妙之处：不光沙箱拿不到凭证，连 Harness 也拿不到。整个链路中，只有 MCP 代理在那一瞬间持有凭证，用完即弃。

这意味着即使 Agent 被 Prompt 注入攻击成功了——它生成的恶意代码也拿不到任何有价值的凭证。沙箱里能看到的，只有一个会话级别的临时 token，离开这个会话就失效。

实战案例

Sentry 在接入 Managed Agents 时，把他们的调试 Agent 和代码修复 Agent 配对使用。整个过程中，Agent 可以读 Sentry 的错误日志、写 PR 到 GitHub，但凭证管理完全由平台托管。Sentry 的工程团队表示，原本需要几个月搭建的安全基础设施，现在几周就搞定了。

安全的最高境界不是"严防死守"，而是"根本就碰不到"。

开发者要写多少代码？

说了这么多架构，你可能最关心一个问题：用 Managed Agents 到底有多简单？

答案是：四步。

第一步：定义 Agent。告诉平台你的 Agent 用什么模型、什么 System Prompt、能调哪些工具、连哪些 MCP Server。

第二步：配置 Environment。选一个容器模板——要装 Python 还是 Node.js？要不要网络访问？要挂载哪些文件？

第三步：启动 Session。把 Agent 和 Environment 关联起来，开始执行任务。

第四步：发送事件，流式接收结果。通过 SSE（Server-Sent Events）实时获取 Agent 的每一步动态，中途还能插话引导方向。

用 Python SDK 写出来，核心代码大概长这样：

import anthropic

client = anthropic.Anthropic()

# 1. 创建 Agent
agent = client.beta.managed_agents.agents.create(
    model="claude-sonnet-4-6",
    system="你是一个代码审查助手，专注于发现安全漏洞",
    tools=["bash", "file_read", "file_write", "web_search"],
)

# 2. 创建 Session 并发送任务
session = client.beta.managed_agents.sessions.create(agent_id=agent.id)

# 3. 流式接收 Agent 的执行过程
for event in client.beta.managed_agents.sessions.stream(
    session_id=session.id,
    message="审查 /repo/src 目录下所有 Python 文件的 SQL 注入风险"
):
    print(event)  # 实时看到 Agent 的每一步操作

就这么多。没有容器编排，没有工具调用路由，没有崩溃恢复逻辑，没有凭证管理代码。

如果你之前自己搭过 Agent 基础设施，你会知道光是"容器编排 + 状态持久化"就得写几千行代码。现在这些全被平台吃掉了。

这就像从自己买服务器装系统，变成了用 AWS Lambda——你只管写业务逻辑，底层的事有人替你操心。

当然，这种便利不是免费的。Managed Agents 的定价是：标准 API token 费用 + 每 Session 小时 $0.08 的运行时费用。注意，空闲等待时间不计费，只有 Agent 实际在"干活"的时间才收费。

费用项	价格	说明
模型推理	标准 API 价格	按 token 计费，跟直接调 API 一样
运行时	$0.08 / Session 小时	仅活跃时间，空闲不计费
Web 搜索	$10 / 1000 次搜索	可选功能

$0.08 一小时是什么概念？比你买一杯咖啡便宜得多，但它帮你省掉的是一整个 DevOps 团队几个月的基础设施工作。

从"自己造车"到"叫一辆车"——你定义目的地，平台负责把你送到。

跟 OpenAI、跟自建方案怎么选？

你可能在想：OpenAI 不也有 Agents SDK 吗？我自己用 LangGraph 搭一套不行吗？

好问题。让我帮你理清楚这三条路的本质区别。

OpenAI Agents SDK 是一个开源框架——它给你零件和图纸，房子你自己盖。它的优势是灵活：你可以换 LLM、可以自定义一切、可以跑在自己的服务器上。但代价是，沙箱、状态管理、安全隔离这些基础设施，还是得你自己搞。

Claude Managed Agents 是一个托管服务——它给你一栋精装修的房子，拎包入住。你牺牲了一些灵活性（只能用 Claude 模型，跑在 Anthropic 的基础设施上），换来的是几乎零基础设施成本。

自建方案（LangGraph / CrewAI / 自研）是——你从买地皮开始。完全自由，但你需要的工程能力和时间投入也是最大的。

对比一下

一个简单的判断框架：如果你的 Agent 用例明确、且用 Claude 模型效果好，选 Managed Agents 最省心。如果你需要多模型切换或完全自主可控，OpenAI Agents SDK 或自建方案更合适。如果你的团队有 5 人以上的 Agent 基础设施经验，自建可能性价比最高。大多数团队？不到 5 人。

还有一个容易被忽略的点：MCP 生态。

如果你已经为 Claude Code 或 Claude Desktop 开发过 MCP Server，那这些 Server 可以几乎无改动地接入 Managed Agents。这意味着你之前在 MCP 上的投入不会浪费——反而成了你选择 Managed Agents 的加速器。

Rakuten 的案例就很说明问题：他们在产品、销售、市场、财务四个部门各部署了一个 Agent，对接 Slack 和 Teams。每个 Agent 从定义到上线，只用了一周。如果是自建方案，你光把 Slack OAuth 和沙箱隔离调通，可能就要一周。

选择的核心不是"哪个技术更好"，而是"你愿意为灵活性付出多少基础设施成本"。

Agent 基础设施的 "AWS 时刻"

回头看这整件事，Managed Agents 的意义远不止"Anthropic 发了个新产品"。

它代表的是一个信号：AI Agent 正在从"应用层竞争"进入"基础设施层竞争"。

2006 年，AWS 推出 EC2 和 S3 时，所有人都在争论"该自建机房还是用云"。20 年后，这个争论的答案已经很清楚了。不是每个公司都需要自己的机房，也不是每个 Agent 开发者都需要自己搭沙箱。

Managed Agents 做的事，本质上就是 Agent 世界的 "EC2"——把执行环境标准化、托管化，让开发者只关心"Agent 要干什么"，而不是"Agent 怎么跑起来"。

但这件事也有它的另一面。当你的 Agent 跑在别人的基础设施上时，你就依赖了这个平台的可用性、定价策略和技术方向。这跟当年上云的顾虑一模一样。

我做两个预测，给自己设个验证期：

预测一：2026 年底之前，OpenAI 和 Google 都会推出类似的 Agent 托管服务。不是"SDK"，而是"托管"——帮你跑 Agent、帮你管状态、帮你做安全隔离。Managed Agents 打响了第一枪，但这个战场不会只有 Anthropic 一家。

预测二：2027 年 Q2 之前，"Agent Infrastructure"会成为独立的融资赛道。就像 2015 年"容器编排"从 DevOps 里独立出来一样，Agent 的执行环境、状态管理、安全隔离会催生一批专门的创业公司。

回到你身边的选择。如果你正在做 Agent 相关的项目，我建议你今天就去试试 Managed Agents 的公测。不是因为它一定是最终答案，而是因为——用过托管服务之后，你才会真正理解，你之前在基础设施上花的那些时间，有多少是"不必要的"。

Agent 的竞争，正在从"谁的 Prompt 更巧妙"，转向"谁的基础设施更扎实"。

这不是预言。这是已经开始的事实。

半年后回来看看，我说得对不对。