智能体表面的演进：使用 Claude Managed Agents 构建

把一个智能体推向生产环境，需要的远不止一个好提示词。智能体需要一个运行它所写代码的地方、访问你数据的凭证、可观测的会话，以及能随使用量扩展的基础设施。在 Applied AI 团队，我们工作在产品、研究以及基于 Claude 构建的客户交汇之处，反复看到同样的模式：正是基础设施把原型与生产级智能体区分开来。太多团队把开发周期耗费在安全、状态管理、权限管理和 harness 调优上。

Claude Managed Agents是我们用于构建和部署生产级智能体的可组合 API 套件，它将一个为性能调优的智能体 harness 与生产级基础设施相结合，让团队能够在数天而非数月内从原型走向上线。在这篇文章中，我们将介绍 Anthropic 智能体构建模块的演进历程、我们为何构建 Claude Managed Agents，以及各团队如今如何在生产环境中使用它。

智能体架构的演进

2023 年我们向开发者开放 Claude 时，API 被刻意设计得很简单：输入 token，输出 token。你发送一个提示词，Claude 返回一段补全，而 harness 和底层基础设施则由你自己搭建。

这些年来，API 逐渐变得更加丰富，但其底层的契约从未改变：一次请求，一轮模型响应，接下来做什么由你的应用决定。很长一段时间里，这就够了。总结一份文档、给一张工单分类、改写一段文字——这类工作完全可以在单轮对话中完成。

然而随着时间的推移，人们想要交托的任务不再适合这种模式。他们希望 Claude 把任务从头到尾执行完毕：查询相关信息、采取行动、查看发生了什么变化，然后决定下一步做什么。而且他们希望 Claude 在他们的工作已经依赖的系统里运行，比如代码库、内部 wiki 或工单系统。

通过 API 把 Claude 变成智能体，意味着你要自己构建循环：询问模型该做什么、运行工具、把结果反馈给模型，然后不断重复。你需要负责构建和部署智能体脚手架，而且随着模型演进可能还需要调整。对于需要完全定制的智能体，这种方式是合理的。但对于更可预测、复杂度更低的智能体工作负载，随着模型和产品的演进去持续优化这些脚手架就变得非常繁琐。

Claude Code 是我们于 2025 年推出的智能体编码工具，让 Claude 直接与你的代码库交互，其中就包含了我们自己的那套脚手架：循环、工具执行、子智能体、上下文管理，以及让它成为高效智能体的丰富能力。开发者自然也希望在各自领域的智能体中获得类似的脚手架机制。

为了让团队能够基于 Claude Code 的脚手架构建智能体，我们发布了 Claude Agent SDK。Claude Agent SDK 为开发者提供了工具，让他们能在驱动 Claude Code 的同一套机制上构建自己的智能体，而无需维护自研循环。对很多团队来说，正是从这时起智能体才变得切实可用：这套脚手架带着基础设施原语、已为 Claude 调校完毕，并且随着 Claude Code 的改进而不断进步。

不过，即便有了执行框架（harness），在生产环境中部署智能体仍然会因为以下几个原因而颇具挑战性：

• 托管与扩展。智能体在哪里运行？一个进程能为持续数小时的任务存活多久？当使用量增长时，靠什么来扩展？
• 会话管理。智能体的历史记录和执行进度存放在哪里？一次运行能否在中断后不受影响地恢复？你能否回溯并检查之前会话中发生了什么？
• 文件系统管理。做真正的工作意味着产出制品：编辑代码、写文件、构建输出。智能体从哪里获得可操作的工作空间？两次运行之间，这个工作空间又会怎样？
• 执行隔离。Claude 写出的代码必须 somewhere 执行。如果代码有问题，影响范围有多大？在生产环境中，你真正信任的边界又是什么？
• 凭证。智能体需要访问你的系统。它如何在不把专有信息暴露给它所生成代码的前提下获得这些访问权限？
• 可观测性。当一个智能体自主运行一小时后做出令人意外的举动时，你能还原它走过的每一步吗？

借助 Agent SDK，上述生产级基础设施的许多要素都通过 Claude Code 的底层机制提供。智能体拥有一个真实可用的文件系统，会话状态可以持久化保存在本地或外部存储上，可观测性数据则可通过 OpenTelemetry 导出到你现有的任何监控体系中。

然而，随着团队越来越多地构建从本地开发走向生产环境的智能体，他们需要一种方式，能在托管基础设施上大规模部署这些智能体。而且，随着模型及其周边工具链变得更加先进——运行时间更长、执行更多代码、接触更多系统、采取更多行动——扩缩容、安全性和沙箱隔离也变得更具挑战性。

这些障碍中有几个源于一个共同的架构选择：智能体框架通常[]在与它所操作的文件系统相同的容器内[]运行。容器必须先启动（付出启动开销），Claude 才能进行思考；智能体连同代码执行就运行在你的凭据旁边；而当容器消亡时，整个运行也随之消亡。

Managed Agents 通过[将“大脑”与“双手”解耦[解决了这些问题。调用 Claude 的运行框架与执行代码的沙箱分开运行，而会话（session）——一份仅追加的日志，记录每一次模型调用、工具调用及其结果——将两者连接起来。Claude 可以在任何容器创建之前就开始推理，沙箱与你的凭据保持充分隔离，并且整个运行过程可以在任意时点从其会话中完整重建。

何时以及为何使用 Claude Managed Agents[

使用 Managed Agents 构建时，用户只需定义任务、工具和防护机制，Anthropic 会在我们的基础设施上运行智能体，并处理底层的智能体循环：如何为智能体提供调用工具的执行环境、出现故障时如何恢复、多智能体编排等等。

当 harness 不随模型智能水平一同演进时，智能体就会出问题。在 Claude Sonnet 4.5 上，智能体在接近上下文末尾时会急于收尾，宁可草草了事也不利用剩余的空间——这种模式被称为"上下文焦虑"。我们的修复办法是在 harness 中加入上下文重置，其中固化了一个假设：Claude 需要帮助才能在接近上限时保持连贯。这个假设没能挺到下一个模型。在 Claude Opus 4.5 上，这种行为消失了，我们之前加入的重置反而只是额外的开销。

对大多数组织而言，维护一个 harness 是无法为其产品带来差异化的额外负担。Harness 需要针对特定的模型行为进行调优；压缩、工具执行和缓存等基础机制在 Claude 上的工作方式与其他模型不同。借助 Claude Managed Agents，harness 会随模型一同演进，让团队能够专注于真正实现智能体差异化的方面：上下文管理和领域专长。

为了让开发者能够配置构建高效智能体所需的上下文和工具，Managed Agents 围绕三种核心资源构建：智能体、环境和会话。一个 智能体（agent）是一种配置：一个模型、一个提示词、一组工具以及围绕它们的防护措施。一个 环境（environment）是智能体运行所在的执行上下文：沙箱容器、其网络规则以及其中预装的软件包，可托管在我们的云上或你控制的基础设施上。每次运行都是一个 会话（session），它将一个智能体与一个环境配对，并拥有自己的隔离沙箱实例。会话会在服务器端持久保存其完整的事件历史、沙箱状态和输出，因此长时间运行的工作可以暂停、干净地恢复，并在事后逐步追踪。使用 Managed Agents，你只需定义一次智能体和环境，然后随着工作负载的增长，针对同一配置运行多个会话。

在 Managed Agents 上面向生产环境与规模化构建

在 Applied AI 团队中，我们见证了智能体在 Anthropic 内部以及客户的系统中，从原型走向生产环境，覆盖编程、金融、客服、法律等十多个领域。这让我们清楚地看到，是什么将一个演示与一个可用于生产的智能体区分开来，以及团队常常在哪些地方陷入困境。

下面，我们分享在像 Claude Managed Agents 这样的托管服务上进行构建的最常见理由：

1. 凭据完全隔离在沙箱之外。当所有东西都在同一个容器中运行时，Claude 生成的代码就紧挨着你的凭据，因此提示词注入可能诱导模型读取自身环境，从而泄露 token。我们可以在同一容器内建立强大的防护栏来防范这一点，但将架构解耦可以实现一种安全得多的方案——把凭据完全排除在沙箱之外。MCP、CLI 和 GitHub 仓库等工具的 token 存放在独立的保险库（vault）中，由代理按需获取并解密。Managed Agents 提供开箱即用的 Vaults 来处理凭据，因此你无需自己运行密钥存储、无需在每次调用时传输 token，也不会丢失对某个智能体代表哪个终端用户执行操作的追踪。Vault 中的凭据在存储前会经过信封加密保护，检索时则需要经过签名的请求 token 进行验证。

2. 消除沙箱开销，降低延迟。延迟是许多企业团队最关注的指标之一，因为用户在等待 Claude 响应时的感受是非常直接的。在没有 Managed Agents 架构的情况下，每个会话都必须启动一个容器，即使智能体只需要思考、从不运行任何工具的会话也不例外。这些启动时间被浪费掉了，用户会将其感受为首次响应前的延迟。使用 Managed Agents 后，Claude 会立即开始推理，同时环境并行启动，而从不运行工具的会话则完全跳过容器。这意味着用户无需等待容器启动就能看到第一个 token，而到智能体需要运行工具时环境也已经就绪。在我们的测试中，这将首 token 响应时间在中位数情况下（p50）缩短了约 60%，在最慢的情况下（p95）缩短了超过 90%。

3. 可靠、持久的会话，支持会话管理、可观测性和记忆。Managed Agents 不采用请求/响应模式，而是以事件为核心来思考。一个会话是一条持续的事件流：每一次模型调用、工具调用及其结果，都会追加到一条日志中，而这条日志保存在运行智能体的进程之外。借助这种架构，你可以在智能体工作的同时，随事件流入实时获得更新，并且之后可以恢复任意会话，无需管理任何数据库或存档点。历史记录在交互之间会被保留，除非你删除该会话；当会话进入空闲状态时，其容器会被设置检查点，因此你可以从暂停处干净地继续。由于整个运行过程本身就是一份事件记录，可观测性和记忆也随之而来：Claude Developer Console 提供智能体会话的原生可视化时间线视图，以及让你深入检查任何对话记录的调试体验。Managed Agents 还附带 Memory 和 Dreaming 等功能，它们同样利用这种会话持久性。Dreaming是一个按计划运行的进程，它会审查你的智能体会话和记忆存储，提取模式，并整理记忆，从而让你的智能体随时间不断改进。Dreaming 在会话之间精炼记忆，通过读取持久化的会话日志，从反复出现的错误和用户偏好中学习改进。

4. 在 Anthropic 托管或自托管云容器之间灵活选择。默认情况下，使用 Managed Agents，你可以把编排和工具执行都委托给 Anthropic 托管的云容器。这让托管和扩缩容变得简单轻松，提供一条更快投入生产的路径。由于 Managed Agents 中“大脑”与“双手”是解耦的，双手可以位于任何地方，包括你的虚拟私有云（VPC）之内。因此，我们还为希望掌控工具执行的团队提供 自托管沙箱，使智能体的代码、文件系统和网络出站流量永远不会离开他们的环境。我们还提供 MCP 隧道，让你把 Claude 连接到运行在私有网络内的 Model Context Protocol（MCP）服务器。也就是说，自托管沙箱控制 智能体代码在哪里执行，而 MCP 隧道控制 Anthropic 如何访问你网络中的 MCP 服务器，让你能够精确掌控哪些内容留在你的边界之内。

除这些功能外，其他能力还包括让智能体根据评分标准（rubric）对自身工作打分的成果评估、多智能体编排、权限策略以及 webhooks。了解更多请看 这里。

客户如今是如何基于 Managed Agents 构建的

各行各业的客户已经用 Claude Managed Agents 在生产环境中上线了智能体。以下是几个例子：

• Notion 在 Managed Agents 上运行其 Custom Agents：团队直接从任务看板把工作分配给 Claude，Claude 会获取每个任务相关的文档、会议笔记和关联数据，完成的代码、演示文稿和网站会回到工作区供审阅。数十个任务并行运行，他们的团队曾描述过一个早期原型，把大约十二小时的工作缩短到了二十分钟。
• Rakuten 利用 Managed Agents 在产品、销售、营销和财务部门上线了专项智能体，每个都在大约一周内投入使用。
• Sentry 将其 Seer 调试智能体与一个负责编写补丁并提交 PR 的 Claude 智能体相结合，由一名工程师在数周而非数月内构建完成。
• Asana 构建了能在项目内接手任务的 AI Teammates，Atlassian 则把开发者智能体引入了 Jira 工作流。

开始使用 Claude Managed Agents

我们构建了 Managed Agents，目的是让你能尽可能轻松地通过 Claude Code 和 Claude Developer Console 在 platform.claude.com 上启动智能体。例如，Console 的快速入门让你可以从智能体模板开始，或用自然语言描述一个智能体，然后在几分钟内将其转化为一个可保障安全、可部署的生产级智能体。

在 Claude Code 中，/claude-api 技能 默认提供，为 Claude 提供详细且最新的参考资料，用于构建基于 Claude Managed Agents 的应用。我们强烈建议你使用它来获取设置 Managed Agents 应用的最佳实践。运行 /claude-api managed-agents-onboard 即可开始，它会以访谈引导的方式带你从头设置一个新的 Managed Agent。

构建托管智能体的未来

随着各团队分享他们使用 Managed Agents 构建的内容，我们发现他们过去花在生产基础设施上的时间，如今都转投到真正能体现智能体差异化的事情上：管理上下文以及为用户定制体验。现在，当新模型发布时，你只需更新智能体以使用它，重新运行评测，即可发布改进，而无需触动底层的架构。

我们期待看到你的构建成果。

开始使用 Claude Managed Agents。[

本文由 Anthropic 应用 AI 团队的技术成员 Gagan Bhat 和 Isabella He 撰写。他们感谢 Hema Thanki、Jess Yan 和 Molly Vorwerck 做出的贡献。