把 Claude Managed Agents 讲明白：Agent、Environment、Session 分别在解决什么问题

这篇文章能帮你搞懂：Claude Managed Agents 不是一个新模型，也不是另一个 SDK，它是 Anthropic 把 Agent 的 harness 和沙箱运行时打包成了一个托管服务。

---

一、先讲结论

Claude Managed Agents（下文简称 Managed Agents）是 Anthropic 在 2026 年 4 月放出的一个 Beta 服务。一句话讲：

你告诉 Anthropic 你想让 Claude 做什么、能用哪些工具，它帮你把 Agent 循环、沙箱容器、工具执行、事件流、会话持久化全跑起来。

它不是 Messages API 的替代品，也不是 Claude Agent SDK 的替代品。它是第三条路：

• Messages API — 最底层，你自己写 Agent 循环；
• Claude Agent SDK — 开源的 harness，你在自己机器/服务器上跑；
• Claude Managed Agents — 托管 harness + 托管沙箱容器，你只管对接。

什么人该关注？要把 Agent 跑成一个产品功能、又不想自己搭沙箱集群的团队。 写插件、写 CLI 工具、一次性跑本地脚本的场景，Agent SDK 就够了，不用这个。

---

二、它在解决什么问题

我先把自己踩过的坑列一下——如果你自己做过 coding agent 类产品，应该会有共鸣。

一个能真正干活的 Agent，至少要有下面这些东西：

1. Agent 循环 — 把模型的 tool_use 解析出来、去执行、把结果塞回去、直到模型不再要求工具。这部分 SDK 抽得不错，但还是得自己写状态机。
2. 沙箱 — 不能让模型跑出来的 bash 直接在你服务器上执行。于是你开始研究 Firecracker、gVisor、Docker-in-Docker、E2B、Modal……每种都要调容器镜像、调网络策略、调文件挂载。
3. 工具集 — bash、读写文件、web search、fetch、grep、glob，每个都得自己接，而且得和沙箱绑定。
4. 会话状态 — 用户把浏览器关了再打开，上下文还得能接上；Agent 跑了一个小时写的文件不能丢。于是你开始折腾 S3、Redis、Postgres。
5. 事件流 — 前端要实时显示 Agent 当前在干嘛，你得定义事件协议、SSE 推送、断线重连。
6. Prompt 缓存、上下文压缩、工具选择策略 — 这些是让 Agent 不爆预算、不爆 context 的工程细节。

这六件事加起来，是一个 5 人小团队可以做三个月的活儿。Managed Agents 把这六件事全吃掉了，你只负责：

• 定义 Agent 本身（system prompt、用哪些工具、用哪个模型）
• 告诉它容器长什么样（网络策略、预装什么）
• 发消息 + 订阅事件流

这就是它"10x faster to production"宣传语背后的技术含义——不是模型变强了 10 倍，而是把你不用写的那些管道代码算进去之后，落地路径短了一个数量级。

---

三、它是怎么工作的

整个服务围绕四个概念展开，背下来就够了：

概念	一句话
Agent	可复用的"人设" = model + system prompt + tools + MCP servers + skills，有版本号
Environment	容器模板 = 预装包、网络策略、挂载文件
Session	一次具体任务的运行实例 = 某个 Agent 跑在某个 Environment 里
Events	你和 Session 之间交换的消息流 = 用户消息、工具调用、工具结果、状态事件

这四个东西的关系大致是：

flowchart LR
    A[Agent<br/>模型+提示+工具] --> S[Session<br/>运行实例]
    E[Environment<br/>容器模板] --> S
    S -->|SSE 事件流| C[你的应用]
    C -->|发送 user.message| S

Agent 和 Environment 都是一次创建，多次复用的模板。真正会算钱、真正会消耗容器资源的是 Session。

启动一个 Session 之后，交互走的是双通道 + SSE：

sequenceDiagram
    participant App as 你的应用
    participant API as Anthropic API
    participant Container as 容器(Environment)

    App->>API: POST /v1/sessions (引用 agent + env)
    API-->>App: session.id
    App->>API: GET /sessions/{id}/stream (SSE)
    App->>API: POST /sessions/{id}/events (user.message)
    API->>Container: 启动容器 / 恢复状态
    loop Agent Loop
        API-->>App: agent.message (文本增量)
        API-->>App: agent.tool_use (开始调工具)
        API->>Container: 执行 bash / file op / web search
        Container-->>API: 工具结果
        API-->>App: agent.tool_result
    end
    API-->>App: session.status_idle (Claude 觉得做完了)
    App->>API: POST events (继续追问 / 中断)

几个细节值得注意：

• 事件发送和流订阅是两个请求，不是一次 HTTP long-polling。你先 POST /events 把用户消息丢进去，再 GET /stream 消费。API 会帮你 buffer 事件，所以谁先谁后都行。
• 状态是服务端持久化的。关掉 SSE 连接、半小时后再 stream，Agent 还在那儿；容器里 /workspace 下写的文件也还在。
• 你可以中途插话。Agent 跑着跑着方向不对，你 POST 一条新的 user.message 进去就能 steer。这在"Agent 跑三小时"这种长任务场景里非常关键——不然你只能看着它烧钱跑错路。

---

四、举一个具体例子

官方 Python 示例最短版本大致是这样：

from anthropic import Anthropic

client = Anthropic()

# 1. 定义 Agent（一次，复用）
agent = client.beta.agents.create(
    name="Coding Assistant",
    model="claude-opus-4-7",
    system="You are a helpful coding assistant.",
    tools=[{"type": "agent_toolset_20260401"}],   # 一键开所有内置工具
)

# 2. 定义 Environment（一次，复用）
environment = client.beta.environments.create(
    name="quickstart-env",
    config={
        "type": "cloud",
        "networking": {"type": "unrestricted"},
    },
)

# 3. 启动一次 Session
session = client.beta.sessions.create(
    agent=agent.id,
    environment_id=environment.id,
    title="Quickstart session",
)

# 4. 打开 SSE 流 + 发一条用户消息
with client.beta.sessions.events.stream(session.id) as stream:
    client.beta.sessions.events.send(
        session.id,
        events=[{
            "type": "user.message",
            "content": [{
                "type": "text",
                "text": "Create a Python script that generates the first 20 "
                        "Fibonacci numbers and saves them to fibonacci.txt",
            }],
        }],
    )

    for event in stream:
        match event.type:
            case "agent.message":
                for block in event.content:
                    print(block.text, end="")
            case "agent.tool_use":
                print(f"\n[Using tool: {event.name}]")
            case "session.status_idle":
                print("\n\nAgent finished.")
                break

运行之后你会看到类似这样的输出：

I'll create a Python script that generates the first 20 Fibonacci numbers...
[Using tool: write]
[Using tool: bash]
The script ran successfully. Let me verify the output file.
[Using tool: bash]
fibonacci.txt contains the first 20 Fibonacci numbers (0 through 4181).

Agent finished.

脑子里过一下这个执行过程：

1. Claude 读了你的指令，决定先用 write 工具写一个 fib.py。
2. SDK 把 agent.tool_use 事件推给你。
3. Anthropic 后端在容器里真的执行了 write，把文件写到了容器的文件系统。
4. Claude 接着调 bash 跑 python fib.py，再调 bash 做 cat fibonacci.txt 验证。
5. 全流程结束，吐 session.status_idle。

整段代码里你没写任何容器管理、任何工具 dispatch、任何状态持久化。这就是"Managed"的含义。

几个值得注意的参数：

• tools: [{"type": "agent_toolset_20260401"}] — 这是一个"全家桶 toolset"，一把梭开 bash、file、web search、web fetch 等。你也可以只开需要的，细粒度配置见 /docs/en/managed-agents/tools。
• config.networking: {"type": "unrestricted"} — 容器裸奔连外网。生产场景通常会换成 allowlist 或 deny，这个放在 Environment 上而不是 Agent 上是有道理的：同一个 Agent 可以跑在"只能连内部 API"的 env 和"能连外网"的 env 里。
• anthropic-beta: managed-agents-2026-04-01 — 所有请求必须带这个 beta header，SDK 会自动加。

---

五、它和相似方案有什么区别

容易混淆的三个东西：Messages API、Claude Agent SDK、Claude Managed Agents。

	Messages API	Claude Agent SDK	Claude Managed Agents
层级	模型调用	本地 / 自己服务器上的 harness	托管 harness + 托管容器
Agent 循环	自己写	SDK 提供	服务端跑
沙箱	没有	自己搭（Docker / bwrap / 别的）	Anthropic 提供容器
工具执行	自己接	在你的机器上执行	在 Anthropic 的容器里执行
状态	无状态	自己持久化	服务端持久化
典型形态	聊天、单次生成	CLI 工具、IDE 插件、本地 Agent	长任务、产品内嵌 Agent、异步工作流
计费	token	token	token + $0.08/session-hour

几条经验法则：

• 你在做一个 CLI 工具（类似 Claude Code、Cursor CLI）→ Agent SDK。让 Agent 操作用户自己的文件系统，只有跑在本地才合理。
• 你在做一个 SaaS 产品，里面有"让 AI 帮你干活"的按钮（比如 Notion 里的 Agent、Asana 里的任务代理）→ Managed Agents。你不希望为每个用户自己维护一堆容器。
• 你只是想让模型写段文案、总结文档，没有工具调用→ Messages API。上面两个都是杀鸡用牛刀。
• 你有非常特殊的安全 / 合规要求，必须在自己 VPC 里跑容器 → 还是 Agent SDK 自建。

另一个容易被混淆的是 MCP（Model Context Protocol）。MCP 是一个"工具提供者"协议，它不负责跑 Agent，它只负责告诉 Agent 有哪些工具能用、怎么调。Managed Agents 里可以接 MCP servers，这两个是上下层关系而不是替代关系。

---

六、局限与坑

不吹不黑，这东西目前有几个真实的约束：

1. Beta，协议会变

managed-agents-2026-04-01 里那个日期就是 beta 版本号，按经验这类 API 在 GA 之前还会有若干次 breaking change。现在写的代码，半年后可能需要改 event type 名字、改字段结构。

2. 供应商锁定程度比 Messages API 更深

Messages API 你把 prompt 改改能跑在别家模型上；Agent SDK 是开源的你可以 fork。Managed Agents 是 Anthropic 独有的产品形态，包含容器运行时、事件协议、会话存储。如果你怕锁定，心里要有数。

3. 费用模型有一个隐藏项

token 计费大家都熟，但额外的 $0.08/session-hour 是一个新的开销维度。注意是 session-hour，不是 wall-clock hour——Session idle 的时候不烧 session-hour。但如果你的 Agent 要连续跑几小时做复杂任务，这笔钱在 100 token 级的小请求里可以忽略，在大规模场景里需要放进成本模型。

4. 容器不是"你的容器"

你不能 ssh 进去 debug，不能装任意 kernel module，不能挂载任意卷。预装语言/包的范围受 Environment 配置的限制，超出范围的东西要么走 MCP，要么走 web API。自己维护基础镜像这条路暂时是不通的。

5. Rate limit 要心里有数

当前是：Create 类接口 60 req/min，Read 类接口 600 req/min，按 organization 计。批量启动 Session 的场景（比如一个任务 fan-out 成 100 个子 Agent）要主动限流。

6. "Session 长时间挂起"的生命周期细节要看清楚

Session 能持久化，但能持久化多久、空闲多久会被回收、文件系统保留多久，这些具体策略要翻 /docs/en/managed-agents/sessions 里的细节。不能假设"永远"。

7. "outcomes / multiagent / memory"还没开放

Anthropic 在 overview 里提到了自我评估（outcomes）、多 Agent 协作、长期记忆这几个功能，但都是 research preview，要单独申请。生产方案设计阶段不要假设这些功能已经有了。

---

七、最后

我的判断：

Managed Agents 是 Anthropic 第一次正式承认"Agent 不只是一次大号的 Completion，它需要自己的基础设施"，然后把这个基础设施自己做出来了。从工程角度看，这个方向是对的——过去两年做 Agent 产品的团队，没有人不在自建 harness 和沙箱上吃过苦头。

但它不是一个通用工具，它是一个有明确目标场景的产品：长时间跑、要用真工具、需要状态持久化、不想自己搭容器集群。这四条同时成立的时候它最香；任何一条不成立，都有更便宜或更灵活的替代方案。

对我个人来说最有意思的一点是：它把 "Agent" 第一次从 SDK 层面的概念，升级成了 API 层面的一等公民资源（有 ID、有版本、可列表、可复用、可引用）。这个抽象一旦稳定下来，整个生态里"Agent Marketplace""Agent Registry""Agent as a Service"这些之前看着虚的概念，都有了一个可以落地的载体。

值得关注，但先别把关键路径押上去——毕竟它还是 Beta。

---

参考

• Claude Managed Agents overview
• Quickstart
• Announcement: get to production 10x faster