Managed Agents

Anthropic 托管的 agent 沙箱：你不用管容器、不用管长任务持久化，把任务丢过去等结果。

上一节讲的 Agent SDK 是"在你自己机器上跑一个 Claude agent"。这一节讲的 Managed Agents 是把 agent 整个搬到 Anthropic 服务器上跑，你只负责发任务和取结果，中间的沙箱、超时、状态持久化都不用管。

它到底解决什么问题

自己跑 Agent SDK 有几个绕不开的运维成本：

• 沙箱：Claude 要跑 Bash、要改文件、要装依赖，你得给它一个隔离环境，一般是 Docker 容器或者虚拟机，容器起停、镜像管理都要自己搞。
• 长任务：一个复杂的重构或者大规模分析可能跑几十分钟甚至几小时，进程挂了就白跑，得自己做断点续跑或者外部 orchestrator。
• 多用户共享：如果你做的是 SaaS，要给不同用户提供 agent 服务，容器编排、资源配额、隔离审计一整套要自建。
• 并发：几十上百个 agent 同时跑，你得有 K8s、有队列、有监控。

Managed Agents 把这些活都揽了。你调它的 API 丢一段任务描述过去，它在自己内部起一个隔离环境，跑完把结果推给你。

什么场景选它

用一个简单判断：任务够长、够贵、够麻烦，就丢给托管服务。几类典型场景：

• 异步批处理：夜里跑一遍全部仓库的安全审计，凌晨 3 点开始清晨 8 点结果就位。你的 CI 机器不用整晚开着。
• 面向终端用户的 agent 产品：你做一个 AI 客服或 AI 研发助手 SaaS，用户请求峰谷不均，让 Anthropic 帮你弹性扩缩，比自建便宜且省心。
• 长 running 任务：一次任务几十分钟、需要连接一大堆 MCP 服务、中间可能失败重试。托管环境自带持久化和恢复机制。
• 要求高隔离的场景：多租户共享一个后端时，不想让 A 用户的 agent 有任何可能碰到 B 用户的数据。

什么场景不适合

• 本地开发调试：你就想在自己笔记本上试个 prompt，绕一圈调远端反而慢。
• 强依赖本地文件系统：agent 要读你机器上真实的项目源码，托管环境没法直接访问，得先把上下文 upload 过去。
• 对每毫秒延迟都敏感的实时交互：托管服务本身有网络往返和调度延迟，做实时聊天不合算。
• 小任务、单轮调用：直接走 Messages API 或本地 Agent SDK 更简单。

概念层的使用流程

托管 Agent 服务的心智模型是任务提交 + 状态查询：

1. 用 API 创建一个 agent 会话，指定模型、允许的工具、系统提示词、MCP 连接。
2. 发送任务（一段用户 prompt 或者结构化输入）。
3. 服务器起沙箱、跑循环、写日志。你拿到一个任务 ID。
4. 用任务 ID 轮询或订阅事件流，实时拿到 tool 调用、中间产物、最终结果。
5. 任务结束，服务器可以按需保留一段时间供你调阅审计日志。

对上层业务代码来说，这套 API 比 Agent SDK 更接近"云服务 job 队列"的心智，不像 SDK 那样贴近 agent 循环细节。

三者放在一起看

层次	谁跑 agent 循环	谁管沙箱	典型场景
Messages API	你的代码	你	单次调用、自研框架
Agent SDK	Anthropic 官方包，在你进程里	你	本地脚本、自建服务
Managed Agents	Anthropic 服务器	Anthropic	SaaS、批处理、长任务

三层不是替代关系而是叠加关系：底下都是 Messages API，Agent SDK 是它上面的循环封装，Managed Agents 又把 SDK 搬到远端并加上运维层。真实项目里经常混用——本地 Agent SDK 跑开发调试，生产环境切到 Managed Agents 承接长任务。

成本考量

托管服务省心不是免费的。除了 token 消耗本身，你还要为托管环境付一份运行时费用，通常按会话时长或者 CPU 时间计费。做架构决策时可以这样估算：

• 如果你已经有成熟的容器编排（K8s、Fargate、Cloud Run 都行），沙箱其实不算大成本，自建 Agent SDK 更便宜。
• 如果团队里没有专门的 SRE、没做过容器安全加固，或者预期任务并发波动很大，托管的运维分摊下来其实划算。
• 早期原型阶段直接用托管，跑通 PMF 再决定要不要迁到自建。

小结

这一节没有具体的 API 请求示例，因为 Managed Agents 的核心不在于某一个特定的字段，而在于它把 agent 的运行位置从你的机器搬到了云端这个心智转变。真到落地的时候，去查官方文档拿最新的接口签名即可，本节想让你记住的是"什么时候该选它、什么时候别选它"。