嗨，我是 Lena。读完 Anthropic 的发布公告后，我把那个标签页开了挺久。不是因为哪里看不懂——实际上那份文档的表述异常清晰——而是因为我想坐下来好好琢磨一下他们在划的那条线。这不是一个新模型。这点我立刻就理解了。但又多读了几遍之后，我才开始明白它究竟是什么，以及更有价值的部分——它不打算成为什么。
以下是我整理出来的内容。
Claude Managed Agents 到底是什么
沙箱运行时，而不是新模型
首先要说清楚的一件事：Claude Managed Agents 是一个基础设施层，不是模型升级。 这是 Anthropic 托管的 agent 运行时——一个介于你的代码和你已经在用的 Claude 模型之间的托管环境。
Claude Managed Agents 提供了将 Claude 作为自主 agent 运行所需的框架和基础设施。你不再需要自己构建 agent 循环、工具执行和运行时，而是得到一个完全托管的环境，Claude 可以在其中安全地读取文件、执行命令、浏览网页和运行代码。
我的理解方式是这样的：你定义 agent 做什么，Anthropic 负责让它跑起来所需的一切。沙箱容器、会话管理、工具执行、错误恢复、上下文处理——这是构建生产级 agent 的"第二份工作"，那个和智能无关、却让大多数团队花三到六个月才能做对的部分。Managed Agents 帮你把这件事拿走了。
Sessions、Environments 和 Agent Harness
有四个概念值得一开始就搞清楚。Agent 是模型、系统提示、工具、MCP Server 和技能的组合——定义一次，通过 ID 引用。Environment 是预装软件包和网络访问规则的云端容器。Session 是引用你的 agent 和 environment 的运行时实例。而 Harness 是 Anthropic 所说的协调这一切的管理层。
Anthropic 的工程团队将其描述为一个"meta-harness"——一项围绕接口构建的托管服务，这些接口的设计寿命要超过任何具体的实现。Harness 编码了关于 Claude 哪些事做不到的假设，而这些假设会随着模型的进步变得过时。
这种设计哲学让我觉得有意思。他们不只是在解决今天的基础设施问题。他们试图构建一个足够稳定的抽象层，让你的 agent 代码不会在 Anthropic 每次发布新模型时崩掉。比如 session log 就充当了一个在 Claude 的 context window（上下文窗口）之外的持久上下文对象——让长时间运行的任务拥有恢复点，而不是脆弱的内存状态。
Managed Agents 解决了什么
沙箱隔离与安全的工具执行
这一点是实实在在的，也非常重要。每个 session 都运行在隔离的 Linux 容器中。Agent 可以读取文件、执行 bash 命令、运行代码——配置可控的网络访问规则，且没有逃出沙箱的风险。自己试着搭过这套东西的团队都知道，这需要多大的工程量。在生产环境中做错了，后果是真的严重。
Agent 运行在安全的沙箱环境中。认证、工具执行和密钥管理由 Anthropic 的基础设施处理。你不需要自行配置服务器或编写执行隔离代码。
带检查点的长时间运行 Session
Session 能在网络断开后继续存活。一个多步骤的研究任务不会因为连接在第 34 步中断或触发速率限制而从头重来。进度和中间输出保存在 session 事件日志中。对于那些运行几分钟或几小时的任务——那些没有专用基础设施几乎不可能可靠构建的工作——Managed Agents 直接解决的就是这类问题。
作用域权限与执行追踪
每一次工具调用、每一个决策、每一个输出都可以在 Claude Console 中追踪。 作用域权限让你精确定义 agent 可以触达哪些工具和数据源。对于在受监管行业构建 agent、或处理涉及敏感系统的企业工作流的人来说，这是承重级功能——不是锦上添花。
Multi-Agent 协调（Research Preview——我要特别标明这一点）
这一点需要谨慎措辞。Multi-agent 协调——即一个 agent 启动并指挥其他 agent 来并行处理复杂工作——作为功能被列出了。但截至 2026 年 4 月 8 日公测发布时，包括 outcomes、multiagent 和 memory 在内的某些功能处于 research preview 阶段，需要单独申请访问权限。
这不是一个小的附加说明。我看到好几篇文章把 multi-agent 协调描述为已上线功能。它不是。如果你的架构依赖 agent 自主生成其他 agent，今天不要在这个假设上构建生产系统。 申请 research preview 访问权限，在功能成熟之前将其视为不稳定能力。
Managed Agents 没有解决什么
这一节是我想得最久才想清楚的。因为这个产品在它所做的事情上确实很好——而恰恰因为如此，人们很容易期望它去做那些它从未被设计来做的事情。
跨 Session 的能力持久化——运行结束，学习也结束
当一个 Managed Agents session 完成时，环境是临时的（ephemeral）。容器关闭。Agent 在那次运行中学到的、改进的或想出来的东西，不会延续到下一次。 下一个 session 仍然从相同的初始 agent 定义开始。
没有机制让 agent 在 session A 中成功的策略自动在 session B 中可用。如果 Claude 用一种特别优雅的方式解决了一个棘手的多步调试问题，那个解法存在于 session log 中——可以查阅，但不会作为可复用的能力向前传播。你可以重新阅读它。你可以手动提取它。但没有原生的继承路径。
这就是基础设施在做基础设施该做的事：可靠地运行 session，然后关闭它。 它没有声称自己是进化层。这不是批评——这是一个值得清楚理解的设计边界。
跨 Agent 继承——没有共享可复用资产的机制
和 session 持久化分开来看：Managed Agents 没有机制让一个 agent 经过验证的能力可供系统中的其他 agent 使用。Agent 之间默认不共享任何东西。每个 agent 定义都是隔离的。如果你的团队有三个 agent 都能从某个通用调试策略中受益，那个策略就存在三份——定义三次、维护三次、改进三次。
我还在试着理解这对规模化团队意味着什么。感觉不像是随机的。感觉像是一个可以解决的问题。但 Managed Agents 没有处理它，而我还没有完全想清楚正确的边界在哪里。
进化生命周期——没有验证、晋升或治理层
Managed Agents 有执行层面的治理：作用域权限、执行追踪、沙箱隔离。它没有的是能力进化层面的治理：没有"这个策略成功了 40 次应该被晋升"的验证机制，没有从"在 session 中测试过"到"成为 agent 定义的一部分"的晋升路径，没有能力如何随时间发展的血统追踪。
这是同一个大问题的两个不同层面。基础设施治理的是 agent 在一次运行中做了什么。进化治理的是 agent 能力如何随时间变化和改进。Managed Agents 正在刻意地把第一层做好。第二层仍然是开放的。
托管执行 vs 能力进化
同一个问题的两个不同层面
让我试着精确地表述这一点，因为我觉得框架的定义比任何单一功能都重要。
Managed Agents 是执行基础设施。它的工作是确保 agent 运行安全、可观测、可恢复、可扩展。它在这方面做得很好。Anthropic 的工程文章将设计围绕稳定的接口展开——这些接口被构建为能够比特定实现存活更久，以适应未来的 harness 和模型改进。
能力进化是另一个层面：agent 如何在跨运行、跨团队、跨部署的过程中积累、验证、共享和继承成功的行为。这个层面不在托管运行时中。它也不可能在——它们在不同的时间尺度上解决不同的问题。
为什么解决了基础设施不等于解决了进化差距
我反复注意到的差距是：一旦 session 结束，某些东西运行得很好，它去哪了？它在 session log 里。可以恢复。但它不会自动出现在下一次运行中。不会与其他 agent 共享。不会根据某个适应度标准被验证和晋升。
这不是托管基础设施的失败。这是技术栈不同层面的差距——一个 Managed Agents 从未被设计来填补的差距。这个区分很重要，因为那些使用 Managed Agents 并期望它解决能力复用问题的团队会撞上这堵墙，而且不会立刻明白为什么。运行时工作得很完美。问题在于它上面缺少一个进化层。
谁应该使用 Managed Agents
最佳匹配：需要生产级 Agent 运行时但不想自己搭建的团队
如果你的瓶颈是基础设施——如果你在 agent 上线之前就要花几个月搭建沙箱、会话管理、重试逻辑和执行追踪——那 Managed Agents 就在解决正确的问题。Claude Managed Agents 按两个维度计费：token 和 session 运行时长，每 session 小时 $0.08，精确到毫秒。空闲时间不计入运行时长。对于长时间运行的工作负载，相比自己搭建的替代方案，这个成本结构是合理的。
包括 Notion、Rakuten、Asana 和 Sentry 在内的早期采用者已经上线了生产用例。据报道 Rakuten 在一周内就部署了每个专业 agent。这就是基础设施运作良好的信号。
如果能力复用才是瓶颈，那就不太对了
如果你的问题是 agent 不断重复发现同样的解决方案，成功的策略无法在运行之间或团队成员之间传递，你没有办法验证和晋升有效的东西——Managed Agents 不会解决这些。运行时会可靠地运行，而进化差距仍然在那里。
限制与取舍
Beta 状态是真的。 所有请求都需要 managed-agents-2026-04-01 beta header，行为可能会在版本之间调整以改进输出。Anthropic 保留更改 harness 工作方式的权利。构建时请为应对变更做好计划。
数据流经 Anthropic 的基础设施。 对于敏感工作负载——法律文件、财务记录、专有代码——每一次工具调用和决策都运行在 Anthropic 的云中。他们的企业版有数据隐私承诺。这是否可以接受取决于你的具体合规要求。
Lock-in 值得正视。 Managed Agents 是 Claude 专属的。如果你的架构需要供应商灵活性或多模型路由，Claude Agent SDK 或直接使用 Messages API 会给你更多控制权。
常见问题
Claude Managed Agents 是什么？
一个于 2026 年 4 月 8 日公测发布的托管基础设施层。它提供一个预构建、可配置的 agent harness，运行在 Anthropic 的云中——处理沙箱执行、session 持久化、工具编排和执行追踪。它不是新模型。
Claude Managed Agents 的费用是多少？
模型推理适用标准的 Claude API token 费率，另外每 session 小时收取 10。在做决策前请到 Anthropic 的官方定价页面确认最新价格——这些数字可能变化。
Claude Managed Agents 能记住跨 session 学到的东西吗？
不能。Session 是隔离的。Agent 定义持久存在并通过 ID 引用，但运行时环境是临时的。Session 中发展出的能力和策略不会自动延续到下一个 session。跨 session 的 memory 作为 research preview 功能列出，需要单独申请访问——默认不可用。
Claude Managed Agents 和 Claude Code 有什么区别？
不同的产品解决不同的问题。Claude Managed Agents 是用于大规模部署生产 agent 的托管 API 运行时。Claude Code 是本地编码工作流工具。Anthropic 的文档明确警告合作伙伴不要将 Managed Agents 品牌标注为 Claude Code 或任何其他第一方 Anthropic 产品。
Claude Managed Agents 支持 multi-agent 工作流吗？
截至 2026 年 4 月发布，Multi-agent 协调处于 research preview 阶段，需要单独申请访问权限。它不在通用公测中。在你确认获得访问权限且功能成熟之前，不要围绕这个能力的稳定性或可用性来设计生产系统。
我大概会继续关注 research preview 功能的发展。"multi-agent 协调存在"和"multi-agent 协调已就绪"之间的差距是有意义的，而 memory 功能尤其值得密切关注——关注它对跨 session 能力持久化意味着什么（或不意味着什么）。这部分仍然没有完全尘埃落定。
