Claude Managed Agents 本质上是 Anthropic 为长时运行 agent 工作提供的 hosted runtime。想让 Anthropic 接管 session 和 loop 这层运行时基础设施，就选它；如果你更在意自定义 loop，或者 runtime 必须跑在你自己的进程里，那就继续用 Messages API 或 Claude Agent SDK。
截至 2026 年 4 月 10 日，这条产品线仍处在 beta 阶段，计费方式是正常 Claude token 费用加上 session runtime 费用，而且它并不是 Claude Code。大多数人真正要做的判断，不是“Managed Agents 听起来是不是更高级”，而是“这项工作值不值得把 runtime ownership 交给 Anthropic”。
“证据说明：本文基于 Anthropic 当前的 Managed Agents overview、quickstart、migration、pricing、memory preview、官方 cookbook 与 engineering 文章，于 2026 年 4 月 10 日核对。
TL;DR
| 你的真实需求 | 更适合的路线 | 为什么 |
|---|---|---|
| 想让 Anthropic 托管长时运行、异步推进的 agent runtime | Claude Managed Agents | Anthropic 帮你接管 session runtime、内建工具环境和更长寿命的运行循环 |
| 想自己掌控 message history、tool flow 和 loop 细节 | Messages API | 你保留最大控制权，代价是更多基础设施和编排工作 |
| 想让 agent runtime 留在自己代码或部署环境里 | Claude Agent SDK | 仍然用 Anthropic 模型，但 runtime 不离开你的进程 |
| 你真正想要的是本地编码代理或桌面工作流 | Claude Code 或桌面产品路径 | 那是另一条产品路线，不是 Managed Agents 的别名 |
最短的结论可以直接记成四句：
- 想把 runtime 交给 Anthropic 托管，就看 Claude Managed Agents。
- 想自己写 loop、自己控状态，就留在 Messages API。
- 想把 agent runtime 留在自己进程里，就用 Claude Agent SDK。
- 如果你其实想解决的是本地开发或桌面委托问题，去看 Claude Computer Use、Claude Code 最值得先用的 Skills 和 Claude Code 最值得先接的 MCP Servers。
Claude Managed Agents 到底是什么
Claude Managed Agents 不是一个泛泛的 “AI agents 功能包”。Anthropic 当前文档对它的定位很明确：这是一个运行在 managed infrastructure 里的预构建 agent harness，重点服务长时间运行和异步推进的任务。换句话说，它是一个 runtime surface，而不只是一个多了几个 helper 的 SDK。
官方现在围绕四个核心对象来讲这条产品线：agent、environment、session 和 events。你可以把它理解成一个更高层的运行合同。agent 负责行为与工具配置，environment 规定它能接触什么，session 是正在运行的工作单元，events 则是 session 对外发出的进度和交互信号。只要先把这四层看清，Managed Agents 就不会再像一个模糊的新词，而会更像一条清楚的工程选型路线。
它和手写的 Messages API loop 最大的区别，在于谁拥有 runtime。用 Messages API 时，你自己维护 message history、自己接 tool call、自己决定 loop 何时继续，也要自己承担执行环境的生命周期。用 Managed Agents 时，Anthropic 接管了更多 session runtime 这一层，你不用再把所有长时运行基础设施都拼在自己代码里。
它和 Claude Agent SDK 的区别，也同样不是“功能多一点少一点”这么简单。Anthropic 当前 migration 文档写得很直白：SDK 运行在你的进程里，而 Managed Agents 运行在 Anthropic 托管基础设施里。前者更像“runtime 还在我这里，只是用了 Anthropic 的 agent abstraction”；后者更像“我愿意把更多 runtime machinery 交给 Anthropic”。
还有一个必须尽早纠正的误解：Claude Managed Agents 不是 Claude Code。 Anthropic 明确要求合作方不要把 Managed Agents 说成 Claude Code 或 Claude Cowork。如果你的真实问题是本地仓库工作流、浏览器委托或桌面执行，那不是这篇文章要解决的读者任务。
什么时候 Claude Managed Agents 是对的路线
Managed Agents 真正有价值的时候，通常不是因为“它是新的”。而是因为你的难点已经不在模型本身，而在于怎么把一个会用工具、会持续推进、可能要跑较长时间的 agent runtime 稳定托起来。如果你不想继续自己维护这一整层 runtime scaffolding，Managed Agents 就开始变得合理。
Anthropic 当前公开材料反复强调的适配场景，都是 long-running、asynchronous 和 stateful 的工作。比如长时研究代理、数据分析代理、需要持续推进的内部自动化流程。这类任务的共同点不是 prompt 很长，而是运行生命周期更像一个 session，而不是一次请求结束就算完成。
官方 cookbook 里的 data analyst agent 是个很好的例子。它的价值不在于“Claude 会调工具”，因为这件事你以前也能做。真正变得具体的是：环境可以复用、文件可以挂载、事件能流式返回、输出也能在 session 里持续积累。只要你的工作负载更接近这种“持续跑一段时间、需要 hosted environment 和 session continuity”的形态，Managed Agents 的说服力就会明显上升。
另一个典型适配点，是你更想拿到 agent run 的结果，而不是把所有 orchestration 细节都当成自己的产品能力。如果你们团队的真正目标是“把这类 hosted workflow 跑稳”，而不是“我们必须拥有 runtime 内每一步的控制权”，Managed Agents 往往能少掉一大块自己搭建的基础设施。
更现实一点说，很多团队低估了自建 agent runtime 的隐性成本：状态管理、长时执行、工具重试、事件流、session 续命、环境生命周期。只要你已经意识到这些 plumbing 本身不是你们要差异化的地方，把 runtime 交给 Anthropic 托管就会更像一个工程判断，而不是追新。
什么时候 Messages API 或 Claude Agent SDK 更合适
最大的误判，是把“更托管”自动理解成“更好”。事实并不是这样。只有当你真正想把 runtime ownership 交出去时，Managed Agents 才是更好的路线。如果你们的产品本身就依赖 bespoke loop、自定义状态机、特殊工具节奏或更细粒度的 orchestration，Messages API 仍然更干净。
原因很简单：Messages API 依然是最薄、最自由的 Anthropic 路线。message history 怎么组织、tool flow 如何推进、loop 何时结束、异常如何回退、runtime 怎样接外部系统，全都还是你说了算。它更麻烦，但这种麻烦在某些场景里本来就是必要的产品能力，而不是应当外包的 plumbing。
Claude Agent SDK 更适合的情况，则是你根本不想把 runtime 移出去。只要你的核心诉求是“agent runtime 必须留在我的进程和我的部署里”，那 SDK 就比 Managed Agents 更顺手。Anthropic 自己在 migration 文档和 cookbook 中也都保留了这条边界，不是把 Managed Agents 写成唯一正确答案。
自定义工具也是一个容易被说过头的地方。Managed Agents 并不等于“从此零客户端逻辑”。Anthropic 当前文档仍然通过 events 来承接 custom tools。这意味着，如果你的系统 heavily depends on 私有服务、特殊工具流或复杂事件回调，Managed Agents 带来的“更省事”可能没有你第一眼想的那么大。
所以最稳的判断规则其实很短：
- 需要 Anthropic 托管 runtime，就选 Managed Agents。
- 需要自己拥有 loop，就留在 Messages API。
- 需要 runtime 留在自己进程里，就用 Claude Agent SDK。
只要把这三个问题分开，页面就不会退化成模糊的 feature compare。
当前价格、beta 状态和能力边界
理解 Managed Agents 时，最好把它当成一个“已经真实可用、但边界仍在变化”的 beta runtime，而不是一个完全定型的平台层。Anthropic 当前文档明确要求使用 managed-agents-2026-04-01 beta header。这个细节要保留，但它属于实现边界，不应该抢走文章的主线。
截至 2026 年 4 月 10 日，Managed Agents 当前价格由两部分组成。第一部分是正常 Claude 模型 token 费用。第二部分是 session runtime 费用，也就是 session 处于 running 状态时，按 每 session-hour 0.08 美元 计费，并且按毫秒计量。这个数字不该被写成永恒事实，但它确实会改变路线判断，因为你现在选的不只是模型，而是一种 runtime contract。
这也解释了为什么这篇文章必须先做 route choice，再讲 setup。若你的工作负载真的需要 hosted long-running session，这笔 runtime 成本可能很值；但如果你的任务短、薄，或者早就被你自己的 custom loop 很好地解决了，多加一层 hosted runtime 未必值得。
能力成熟度方面也要说清楚。Anthropic 当前文档写的是：Managed Agents 对 Claude API 账户默认可用，但 memory、multiagent 和 outcomes 仍是 research preview，需要额外 access。这个边界很重要，因为它告诉读者：核心 runtime 是真的，但周围能力还没有全部定型。
速率限制同样属于“该知道，但不该让它支配首屏”的事实。Anthropic 当前文档列出的限制是 create endpoints 60 RPM、read endpoints 600 RPM，同时还会受组织级 spend 和 usage tier 影响。做生产计划的人需要知道，但这不是你是否选择 Managed Agents 的第一判断轴。
更适合的表达方式是：这条 Hosted Runtime 路线已经足够真实，足够值得评估；但凡是价格、preview access、rate limits 和 beta header 这类 freshness-sensitive 信息，都应该带上日期来看。
一个最能说明问题的例子：托管的数据分析代理
官方 data analyst agent cookbook 是最适合拿来“落地解释” Managed Agents 的例子，因为它既具体，又不会把页面拖进长教程。这个例子里，agent 在 hosted environment 里运行，环境可复用，文件可挂载，events 可流式返回，最后产出结果。它让 “hosted runtime” 这四个字不再只是概念。
为什么这个例子重要？因为它展示的不是“Claude 可以调工具”，而是“当任务本身像一个持续进行的 session 时，Anthropic 托管 runtime 到底替你省掉了什么”。对数据分析这种工作来说，过程通常不是一次文本补全，而是多步读取、处理、生成和返回。如果你想把这些 session-level 运行机制更多交给 Anthropic，Managed Agents 就是合理路径。
这个例子也顺手说明了退出条件。Anthropic 自己在 cookbook 里也写明：如果你需要完整控制 agent loop 和 deployment，Claude Agent SDK 还是更好的路线。这不是小字，而是路线判断本身的一部分。
如果只想记一个最简 setup 轮廓，当前 Managed Agents 的使用方式可以概括成：创建 agent、创建 environment、启动 session、发送 events、流式读取结果。看到这里，你基本就能判断它是不是自己要的那条路了。
bashcurl https://api.anthropic.com/v1/agents \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "anthropic-beta: managed-agents-2026-04-01"
这个示例故意保持很短，因为真正重要的不是 curl 命令本身，而是你是否真的需要这种 hosted session runtime。
FAQ
Claude Managed Agents 和 Claude Code 是一回事吗？
不是。Managed Agents 是 Anthropic API 里的 hosted runtime surface，Claude Code 则是本地编码工作流产品。Anthropic 当前文档也明确要求不要把前者说成后者。
什么时候应该选 Managed Agents，而不是 Messages API？
当你真正想让 Anthropic 接管更多长时 loop 和 session runtime 基础设施时，就选 Managed Agents；如果你仍然需要自己掌控 loop、message history 和低层 orchestration，就继续留在 Messages API。
什么时候 Claude Agent SDK 更合适？
当你的核心要求是“runtime 必须留在自己的进程或部署环境里”时，Claude Agent SDK 更合适。Anthropic 当前 migration 文档也明确保留了这条边界。
Managed Agents 是不是意味着 Anthropic 连 custom tools 都替我全管了？
不是。它接管了更多 hosted runtime，但 custom tools 仍可能需要客户端通过 events 来响应。不要把它写成 “fully managed everything”。
当前价格怎么理解？
截至 2026 年 4 月 10 日，Anthropic 当前价格页写的是：正常 Claude token 费用，加上 session 处于 running 时每 session-hour 0.08 美元的 runtime 费用。这个数字要带日期理解。
memory、multiagent 和 outcomes 现在算全面开放了吗？
还不算。Anthropic 当前文档仍把这些能力放在 research preview 里，需要单独 access。
当前 rate limits 值得提前知道吗？
值得，但别把它放到路线判断前面。Anthropic 当前文档给的是 create 60 RPM、read 600 RPM，同时仍受组织级限制影响。真正该先回答的问题仍然是你要不要这条 hosted runtime 路线。
真正要做的判断，是 runtime 应该归谁管
Claude Managed Agents 值得关注，不是因为它换了个更响亮的新词，而是因为 Anthropic 终于把 hosted runtime 这条路线独立出来了。它解决的是一个非常具体的问题：当 agent 工作会持续运行、会异步推进、会依赖 session 生命周期时，你要不要继续自己扛 runtime 这一层。
这并不意味着所有人都该迁过去。只要你需要 custom loop，就留在 Messages API；只要你需要 runtime 留在自己进程里，就继续用 Claude Agent SDK；只有当你真的想把更多 runtime machinery 交给 Anthropic 托管时，Managed Agents 才是更对的路径。
把问题这么看，整个主题就会简单很多。读者真正要问的，不是“Managed Agents 到底新不新”，而是“这层 runtime，我到底该不该继续自己拥有”。这才是这篇文章应该帮你回答完的事。