---
title: anthropic-claude-managed-agents-platform-launch
source_url: https://mp.weixin.qq.com/s/B-Usu9rACZG-JJDN_z-Ydw
publish_date: 2026-05-08
tags: [wechat, article, claude, agent]
review_value: 7
review_confidence: 7
review_recommendation: neutral
sha256: 5bdc5cdc93693f4b176c24e782d9d4c34d3ab9b7e33d772bf966d1c385357f71
---
Anthropic 悄悄搭好了一套 Agent 基础设施 Claude Managed Agents 正式开放，智能体进入工程化时代 前几天也写了一篇介绍Claude Managed Agents的文章，今天正式发布，重新讲一下更清楚些： Claude Managed Agents AI基础设施化 2025年以来，业界谈了太多“AI Agent”这个词，但大多数讨论停留在概念层面：Agent 能做什么、理论上有多强、未来会取代多少工作。 Anthropic 上周做了一件更务实的事：把一整套让 Agent 真正能跑起来、跑得稳、越跑越好的基础设施开放出来了。 这套东西叫 Claude Managed Agents，同步发布的还有多 Agent 协作（Multiagent Sessions）、结果驱动的自我评估循环（Outcomes Loop）、Webhook 通知机制，以及一个概念上相当超前的300c做梦300d（Dreams）功能。 这不是新模型发布， 却有更大的意义， Anthropic 在悄悄铺一条让 AI Agent 变成工业品的路。 ▍ 从「会聊天」到「会干活」：Managed Agents 解决了什么问题 过去，开发者如果想让 Claude 帮忙执行复杂任务——比如分析几十份文档、写代码然后运行测试、自动化处理一批文件——需要自己搭一套「Agent 框架「： 要管理模型的上下文窗口，防止超出限制；要自己配置代码执行环境；要处理工具调用、错误重试、中间结果存储；要写轮询逻辑来知道任务是否完成…… 工作量不小，而且坑很多。 Claude Managed Agents 的定位是：把这些基础设施全部托管给 Anthropic，开发者只需要定义「这个 Agent 是干什么的「，剩下的交给平台。 官方文档的对比： Messages API 是直接调模型，适合需要精细控制的场景；Managed Agents 是一套预建好的 Agent 运行框架，适合长时间运行的异步任务。 具体来说，Managed Agents 提供了四个核心概念： Agent，就是你定义的那个「角色」——用哪个模型、系统提示是什么、能用哪些工具和 MCP 服务器； Environment，是运行容器——预装了 Python、Node.js、Go 等环境，配置好网络访问规则； Session，是一次具体的任务执行实例； Events，是你的应用和 Agent 之间互发的消息流。 打个比方：你招了一个员工（Agent），给他配了办公室和电脑（Environment），然后交代他今天要做一项工作（Session），途中随时可以发消息协调（Events）。 ▍ 多 Agent 协作：一个人搞不定的事，让团队来 Multiagent Sessions 是这次发布里技术含量最高的部分，目前处于研究预览阶段。 核心逻辑是：一个「协调者 Agent」可以把子任务分配给其他专门的「执行者 Agent」，各自独立工作，共享同一个容器和文件系统。 举个文档里给的例子： 你有一个总的工程负责人 Agent，它可以把「代码审查」交给专门的 Reviewer Agent，把「写测试用例」交给 Test Writer Agent。这三个 Agent 各自有独立的上下文窗口（所以不会互相干扰），但都在同一个文件系统里工作（所以可以读写对方的产出）。 每个 Agent 有自己的「记忆」，但共用同一个「工作台」——这是多 Agent 协作的核心设计。 从实现上看，Managed Agents 引入了「线程（Thread）」的概念。主线程是协调者的事件流；子线程在协调者决定委派任务时动态创建，并保持上下文持久化——意思是协调者可以随时和之前召唤过的子 Agent 继续聊，不需要重新说一遍背景。 这个设计有两个重要含义：一是并行处理成为可能，多个 Agent 可以同时工作；二是专业化成为可能，每个 Agent 只需要在自己擅长的领域表现好，不需要是万能的。 值得注意的一个限制：目前只支持一层委派，协调者可以调用子 Agent，但子 Agent 不能再调用其他 Agent。这是研究预览阶段的保守设计，也是合理的安全边界。 智能体编排他们终于做成了。 ▍ Outcomes Loop：让 Agent 自己知道「做完了」是什么意思 这个功能在概念上非常重要，解决了一个根本问题：Agent 怎么知道任务做好了？ 以前的做法是在 Prompt 里写要求，然后祈祷模型理解。Outcomes Loop 的做法是：你给它一份评分标准（Rubric），它会在完成工作后，召唤一个独立的「评分者 Agent「来打分。 文档里给了个很具体的例子——让 Agent 为一家公司建一个 DCF 财务模型： Rubric 里会写：收入预测需要用过去5年历史数据、至少预测5年、增长率假设要明确说明；折现率的 WACC 计算要有明确假设；产出文件是一个 xlsx，关键假设放在独立的 Assumptions 表…… 有了这份 Rubric，Agent 不再依赖「感觉上完成了」来判断，而是有了客观标准。 评分者 Agent 和执行者 Agent 使用独立的上下文窗口，刻意隔离，就是为了防止执行者的推理过程影响评估结果——这是一种防止「自欺欺人」的工程设计。 评估结果有几种：satisfied（达标，任务结束）、needs_revision（需要修改，继续迭代）、max_iterations_reached（已达最大迭代次数）。 这本质上是一个「计划-执行-评估-修正」的闭环，max_iterations 默认是3次，最多可以设到20次。 这个机制的战略意义很清晰：它让 Agent 的输出质量有了可量化的度量，而不是模糊的「大概可以」。当 Agent 能够自我评估时，它就更接近一个可靠的工作流节点，而不只是一个辅助工具。 ▍ Webhooks：Agent 不再让你一直守在旁边 这是个工程层面的体贴设计。 Agent 任务可能跑几分钟、几十分钟甚至更长。以前的做法要么是保持 SSE 长连接（服务器发送事件），要么是反复轮询 API 问「好了没「——这两种方式都很消耗资源，而且不优雅。 Webhook 的逻辑是：你在 Console 里配置一个 HTTPS 回调地址，告诉 Anthropic「任务完成了推给我「。完事后你该干嘛干嘛，等通知就行。 这是 Agent 从「工具」向「服务」进化的重要一步——工具需要你一直握着，服务是你委托出去然后等结果。 Webhook 支持多种事件类型，比如 session.status_idled（任务完成进入空闲）、session.outcome_evaluation_ended（评估结束）等。每次推送包含事件类型和 ID，收到后再去 GET 拉完整数据——这个设计防止了因为重试导致收到过期数据的问题。 另一个工程细节：Webhook 签名验证。每个推送带一个 X-Webhook-Signature 头，超过5分钟的 payload 会被拒绝。这是生产级系统该有的安全考量。 ▍ Dreams：Agent 的「睡眠学习」 这是四个新功能里最具未来感的一个，也还在研究预览阶段。 背景是这样的：Agent 在工作时可以往「记忆库（Memory Store）「里写东西，比如用户偏好、任务背景、之前的发现。但随着 Session 越来越多，记忆库会积累很多重复的、过时的、甚至互相矛盾的内容。 Dreams 就是解决这个问题的。你可以发起一个「dream「任务，让 Claude 在后台读取多个历史 Session 的记录，然后对记忆库做一次整理： 合并重复内容、用新的覆盖过时的、从大量 Session 中提炼出新的模式和洞察…… 输出是一个全新的、整理后的记忆库，原来那个不会被修改——你可以先审查，不满意可以丢弃。 Dreams 有点像人类睡眠时的记忆整理过程：白天（工作时）积累零散信息，晚上（Dreams 运行时）把这些信息重新组织成更有用的结构。 从技术实现上看，Dreams 是一个异步任务，通常需要几分钟到几十分钟，取决于输入的 Session 数量。单次最多支持100个 Session。运行时会创建一个内部 Session，你可以通过事件流实时观察它在读什么、写什么。 这个功能目前支持 claude-opus-4 . 7 和 claude-sonnet-4 . 6 两个模型。 这里有个值得关注的概念：它把「学习」变成了一个可以主动触发的操作。以前我们说大模型「一旦训练好就固定了」，Dreams 提供了一种在 Agent 应用层面持续积累经验、让记忆越来越好用的机制——虽然它改变的是 Memory Store 而不是模型权重本身，但对于构建长期运行的 Agent 来说，效果是类似的。 ▍ 这些功能合在一起，Anthropic 在做什么 把这四个功能放在一起看，会发现一个清晰的战略意图： Anthropic 不只是在卖模型能力，而是在构建一套 Agent 运行的基础设施。 这个判断有几个依据： 第一，从「调用「到「托管「。Managed Agents 把计算环境、工具执行、上下文管理都接管了，开发者不用再关心这些底层细节，专注于定义 Agent 的「职责」就够了。这和云计算从「买服务器」到「用云服务」的演变逻辑一样。 第二，多 Agent 协作让 AI 有了「组织结构」。现实世界的复杂任务往往需要协作，Managed Agents 的 Multiagent 功能让 Agent 之间可以有明确的分工——协调者负责规划和整合，执行者负责具体任务。这是从单个 AI 向 AI 工作流系统的关键跨越。 第三，Outcomes Loop 提供了质量保障机制。要在生产环境里部署 Agent，必须有可靠的质量控制手段。通过 Rubric 评分，每个任务输出都有了可量化的质量标准，失败的任务可以自动重试。这是让 Agent 从「实验品」变成「可信任的工作流节点」的必要条件。 第四，Dreams 指向了长期演化的可能性。如果 Agent 能够通过 Dreams 不断整理和提炼自己的「经验」，那它就不再是一个静态的执行系统，而是一个会随着使用而越来越好用的系统。这在当前 AI 讨论里是个非常有价值的方向：不依赖模型重新训练，而是在应用层实现持续优化。 一句话总结：Anthropic 正在把 Claude 从一个「你去调用的模型」，变成一个「能代你把事情做完的系统」。 ▍ 开发者视角：现在值不值得用 Managed Agents 目前处于 Beta 阶段，Multiagent Sessions、Outcomes 和 Dreams 是研究预览功能，需要单独申请权限。 对于想用 Claude 构建自动化工作流的开发者，这套基础设施值得认真评估，几个关键点： 一，它省掉了大量基础设施搭建的工作。如果你之前要自己管理 Agent Loop、上下文压缩、工具执行环境，现在这些都有了现成的托管方案。 二，Outcomes Loop 非常适合有明确验收标准的任务场景。报告生成、代码审查、数据分析——这些都可以用 Rubric 来定义「做完了」的标准。 三，Multiagent 对于复杂的、需要多专业协作的任务价值最大。单纯的简单任务不需要这个复杂度。 四，Beta 阶段有一定的不确定性，生产环境的使用需要做好风险评估。 最后说一点更大的背景：在 AI 行业，「推出更聪明的模型「和「让 AI 真正能在工作流里落地「是两件事。前者是智力竞赛，后者是工程能力的长期积累。 Anthropic 这次发布的，是后者。 这种工作往往不如新模型发布那么吸引眼球，但对于真正在业务场景里部署 AI 的人来说，可能是更重要的进展。 参考资料：Anthropic 官方文档 platform.claude.com/docs/en/managed-agents/