托管 agent：别让做产品的团队变成基础设施公司
造一个 agent，起步容易、收尾难。一个「在循环里调模型」的原型，一个下午就能拼出来。但把它变成能在生产里稳定跑的东西——撑住长任务、熬过重启、管好上下文、不超预算——才是绝大多数工作真正所在的地方。
Claude Developer Platform 上的托管 agent（managed agents） 接手这些「没有差异化价值的重活」，让你不必每做一个产品就把同样的基础设施重造一遍。
反正你最后都得造的那些东西
当团队从零造生产级 agent 时，几乎总会写出同一套支撑系统：
| 系统 | 干什么 |
|---|---|
| 执行循环 | 调模型、跑工具、把结果喂回去、再循环——同时处理错误和重试 |
| 上下文管理 | 对话变长时把它控制在模型窗口内，总结或裁剪历史而不丢主线 |
| 状态持久化 | 让一个长跑 agent 熬过进程重启，从断的地方接着跑 |
| 工具编排 | 注册工具、路由调用、安全地执行它们 |
| 可观测性 | 看清 agent 做了什么、为什么、在哪出的错 |
这些没一样是你产品里有意思的部分，但每一样都是必需的。 这是每个团队都要交的一笔税。
这里说的「托管」是什么意思
一个托管 agent 把上面那堆基础设施搬到平台上。你只定义 agent——它的指令、它的工具、它的模型——平台替你跑那个循环：调模型、执行工具、在步骤之间持久化状态、随任务增长管理上下文。
agent 跑在服务端。 你不用在自己机器上保活一个进程去照看长任务；你启动 agent，它就独立地继续跑下去，哪怕是几个小时的活。
上下文处理是内建的
长跑 agent 最难的部分之一，就是在上下文填满的过程中让它保持连贯。托管 agent 自动处理这件事——按需压缩、总结历史，让 agent 能在长任务上一直干下去，而不用你去写那些管理窗口的记账代码。
这一点和我们在别处讲过的 context engineering（上下文工程） 工作直接相连：决定留什么、总结什么、丢什么，是 agent 持续表现的核心；把这件事交给平台来做，就移除了一大块复杂度。
工具，包括我们替你跑的那些
agent 的能力上限，就是它能调用的工具。 托管 agent 既支持你自己定义的工具，也支持一组 Anthropic 托管的工具——比如代码执行和网页搜索——它们跑在服务端，不用你来预备基础设施。
因为工具执行发生在平台上，那些通常让工具变麻烦的事——给代码执行加沙箱、管理速率限制、保护凭据——都帮你处理好了，不再是你要解的问题。
可观测性与控制权
把执行循环交给平台，不能意味着失去对它的可见性。托管 agent 把 agent 在做的事暴露出来——它走的每一步、调的每个工具、消耗的 token——这样你能调试行为、理解成本。
你也保留着那些要紧的控制权：一个 agent 被允许花的预算、它被准许用的工具，以及它该在哪个点停下来交回给人。
这是给谁用的
托管 agent 面向的，是想发布代理式功能、但不想为此变成一家基础设施公司的团队。
如果你的价值在于领域逻辑——agent 为你的用户做了什么——而不在于「让它跑起来的那些管道」，那么托管这条路能让你把力气花在真正让你与众不同的地方。
总结
我们认为这是开发者平台自然的下一步：不只是一个「返回一段补全」的 API，而是一个能让 agent 在真实时间跨度上、对真实任务持续工作的地方。