Claude Managed Agents 与 Claude Agent SDK 对比

上周我同时打开了三个标签页：Managed Agents 文档、Agent SDK 快速入门，以及 Messages API 参考文档。我试图搞清楚，对于一个异步文档处理流水线，该选哪条路。折腾了四十分钟后，我意识到困惑并不在于功能差异，而在于谁来拥有运行时。

这才是这个决策的核心。不是哪个”更好”，而是哪个基础设施边界对你当前要构建的东西更合理。这篇文章记录了两条路径的对比——以及为什么存在第三种选项，而大多数对比文章都忽略了它。

两条通往 Claude 驱动智能体的路径

Agent SDK：你拥有循环，你管理运行时

Claude Agent SDK——今年早些时候从 Claude Code SDK 更名而来——将驱动 Claude Code 的工具、智能体循环和上下文管理打包成 Python 或 TypeScript 库提供给你。你安装它，在自己的基础设施上运行，自行处理扩展、沙箱隔离和编排。

SDK 会自动捆绑 Claude Code CLI。你的智能体开箱即可访问文件操作、bash 命令、网页浏览、代码执行——完整的 Claude Code 工具集。你定义允许哪些工具、设置权限模式，并以进程内 MCP 服务器的形式实现自定义工具。

你得到的是：对执行环境的完全控制。随之而来的也是：保持该环境运行、安全且可观测的责任。

Managed Agents：Anthropic 拥有执行框架，你定义任务

Claude Managed Agents 于 2026 年 4 月 8 日进入公开测试，颠覆了所有权模型。你指定智能体——模型、系统提示、工具、MCP 服务器、护栏——Anthropic 来运行它。执行框架负责处理工具执行、沙箱隔离、会话持久化、上下文压缩、提示缓存和崩溃恢复。

Anthropic 工程团队将其描述为”元执行框架”——其设计目的是随着模型改进容纳未来的执行框架，而不是对 Claude 能做什么或不能做什么做出固定假设。如果容器崩溃，会话得以保留。新容器从会话日志中恢复。

你负责配置，Anthropic 负责运营。

两者都不是普遍更优的选择

能力重叠度很高。两者都让 Claude 能够访问代码执行、文件操作、bash、网页浏览和 MCP 集成。区别在于运营层面：谁来配置环境，谁来处理故障，谁来扩展容器。这是一个基础设施决策，而非功能决策。

核心对比

关于计费，有一点值得注意：Agent SDK 不引入会话运行时费用。但不加限定地说它”更便宜”是有误导性的。你自托管的运行时有真实成本——服务器、容器编排、监控、事故响应，以及维护这一切所花费的工程师时间。两者的成本结构不同，并非简单的高低之分。

何时选择 Managed Agents

会话持久性至关重要的长时运行或异步任务

如果你的智能体运行时间为 30 分钟到数小时——处理文档、做研究、执行多步工作流——你需要能在断开连接和容器故障后存活的会话状态。Managed Agents 在服务端存储完整的事件历史，并通过 API 提供查询。自行构建同等级别的持久性是可行的，但那也意味着数周的工程投入，而这些并非你的核心产品。

没有基础设施带宽来构建安全沙箱的团队

生产级沙箱隔离——隔离、凭证管理、作用域权限、执行追踪——是真正困难的事。大多数团队低估了这一点。如果你的团队没有 DevOps 能力来构建和维护安全的智能体执行环境，Managed Agents 会将这整个问题域从你的路线图中移除。

快速从原型到生产：数天而非数月

Anthropic 的宣传语是”生产速度提升 10 倍”。我没有在足够多的场景中验证这个数字来为其背书，但方向是准确的：从”智能体在本地测试中运行”到”智能体在生产中可靠运行”之间存在巨大鸿沟，而 Managed Agents 可以弥合这一差距。据报道，乐天在不到一周的时间内部署了各个专业智能体。

当内置压缩和缓存比自定义控制更重要时

Managed Agents 自动处理提示缓存和上下文压缩。 如果你曾为长时运行的智能体构建过自己的上下文管理，你就知道这需要多少反复试错。内置方案并非对每种工作负载都最优，但对大多数场景来说已经足够好——而且它在第一天就可以投入使用。

何时选择 Agent SDK

Managed Agents 未暴露的自定义编排逻辑

SDK 为你提供钩子、作为进程内 MCP 服务器的自定义工具、细粒度权限回调，以及对智能体循环的完全控制。如果你的智能体需要自定义重试策略、条件工具路由，或者会话中途动态修改提示——这些是 Managed Agents 配置接口所未暴露的逻辑——你就需要 SDK。

专用工具集成或自定义执行环境

如果你的智能体需要运行在特定环境中——访问 GPU、特定数据库驱动、专有库——SDK 让你完全控制执行环境。Managed Agents 为你提供预装了常用包的云容器，这对大多数情况已经足够，但并非全部。

本地部署或私有云需求

Managed Agents 仅在 Anthropic 的基础设施上运行，没有本地部署选项，也无法部署到你自己的云上。对于有严格数据主权要求或监管约束、禁止向第三方基础设施发送数据的组织，SDK 是唯一的选择。这是硬性约束，而非偏好。

大规模下的成本结构

对大多数工作负载来说，$0.08/会话小时是微不足道的——一个 24/7 运行的智能体在 token 费用之外每月运行时成本约为 $58。但对于大量并发长时运行的智能体，会话费用会累积叠加。500 个智能体同时运行，仅会话开销就产生 $40/小时。

Agent SDK 没有这种按会话计费的附加费用。你的成本是 token 费用加上你的基础设施运营费用。在高并发量下，自有运行时在边际成本上可以更便宜——但前提是你已经消化了构建和维护它的固定成本。

第三种选择：Messages API

既不需要 SDK 也不需要 Managed Agents 的场景

这是大多数对比文章跳过的选项，而它正确的频率比人们想象的更高。

Messages API 为你提供直接的模型访问。你发送提示，获得响应。没有执行框架，没有智能体循环，没有托管运行时。你自行构建一切——如果需要的话，包括工具执行循环。

不需要完整智能体框架的简单工具使用模式

如果你的用例是：调用 Claude，可选地让它使用一两个工具，返回结果——你根本不需要智能体框架。带工具使用的 Messages API 可以干净地处理这种情况。在简单的请求-响应模式中，引入 Agent SDK 或 Managed Agents 只会增加不值回票价的复杂度。

Anthropic Python 和 TypeScript 客户端 SDK 原生支持工具使用。你自己实现工具循环——一个检查 stop_reason、执行工具、回传结果的 while 循环。对许多生产工作负载来说，这就是你所需要的全部。

我见过不少团队在 20 行工具循环就能搞定的情况下，却去引入智能体框架。在选择更重的抽象层之前，先检查你的任务是否真的需要自主性或会话持久化。

迁移注意事项

从 Managed Agents 迁移到 SDK：会发生什么变化

智能体逻辑——系统提示、工具定义、任务结构——可以直接迁移。不能迁移的是：会话持久化、沙箱隔离、上下文管理和崩溃恢复，这些都需要你自行构建。

从 Managed Agents 迁移到 SDK，意味着从”Anthropic 运营”转变为”你来运营”。能力是等效的，但运营负担完全转移到你的团队。

从 SDK 迁移到 Managed Agents：会发生什么变化

某些方面更容易，另一些方面更困难。你的智能体核心逻辑可以移植，但以进程内 MCP 服务器实现的自定义工具可能需要重新暴露为远程 MCP 服务器，自定义钩子和权限回调需要映射到 Managed Agents 的配置模型。

收益：你不再需要维护运行时。代价：你失去了对执行环境的细粒度控制。这种权衡是否值得，取决于你的自定义基础设施中有多少是真正必要的，而非只是早期原型决策的历史遗留。

截至 2026 年 4 月，两者之间尚无官方迁移指南。请为集成测试做好规划，而不仅仅是代码移植。

常见问题

我可以在同一个产品中同时使用两者吗？

可以。SDK 和 Managed Agents 服务于不同的运营需求。一种常见模式：对面向用户、对延迟敏感、需要完全控制的交互使用 Agent SDK；对后台异步任务使用 Managed Agents，这类任务更看重会话持久化和免维护运营。两者共享相同的底层 Claude 模型，token 成本使用相同的定价结构。

Managed Agents 会将我锁定在 Anthropic 的基础设施上吗？

是的。运行时是专为 Claude 构建的，不能运行 GPT、Gemini 或开源模型。你的智能体逻辑——提示、工具定义、任务结构——是可移植的，但运行时和会话格式不可移植。SDK 在抽象模型层方面给你更多灵活性，尽管它也是 Claude 专用的。

哪个在错误处理和重试方面表现更好？

Managed Agents 内置了崩溃恢复——会话日志持久存在，新容器从上一个容器失败的地方恢复。使用 SDK，你需要自行构建错误处理。如果你有过这方面的经验并有良好的处理模式，SDK 的错误处理可以更精确地满足你的需求。如果没有，Managed Agents 的默认设置是一个不错的起点。

我可以将现有的 SDK 智能体迁移到 Managed Agents 吗？

核心智能体逻辑可以迁移。系统提示、工具定义和任务结构是兼容的。需要返工的内容包括：自定义钩子、进程内 MCP 服务器（可能需要远程等价物）、自定义权限逻辑，以及任何依赖于你特定执行环境的内容。目前尚无官方迁移工具。

哪种在大规模下更具成本效益？

取决于你如何计算。Managed Agents 在 token 费用之上额外收取 $0.08/会话小时。SDK 没有按会话的附加费——但你自托管的运行时有自己的成本项：服务器、编排、监控、工程维护。在中低并发量时，Managed Agents 的总拥有成本通常更低。在极高并发量下、有大量长时运行的并发会话时，算法可能翻转——但前提是你已经投入了基础设施建设。

这就是完整的对比。决策树：需要基础设施控制权或无法将数据发送到外部 → SDK。想要跳过基础设施 → Managed Agents。根本不需要智能体循环 → Messages API。

如果不确定，两者都跑一个试点。在原型阶段的切换成本远低于确定部署架构之后。

下周继续——仍在测试 Managed Agents 上的多智能体模式。

往期文章：