Anthropic Code w/ Claude 2026 — Managed Agents 三大新功能

💫

Code w/ Claude 2026 ---- 新三大功能是 AI 构建复杂系统的革命,让小白智能化的搭建系统

Dreaming · Outcomes · Multiagent Orchestration——让 agent 从“被指令驱动”走向“被结果驱动并能自我学习”。
从 Anthropic 官方博客 + 文档 + keynote，到 Simon Willison live blog、VentureBeat、SiliconANGLE、Help Net Security 等 11 家媒体的第三方观点，一文看完 5/6 旧金山发布的全貌。
Three new capabilities for Managed Agents · SF · May 6, 2026

Anthropic Code with Claude 2026 · 旧金山站 keynote · 2026 年 5 月 6 日发布
OPRAX 综合解读 · 2026 年 5 月 8 日撰写

3

大新功能 (Dreaming/Outcomes/Multiagent)

6×

Harvey 完成率提升 (Dreaming)

+10%

Outcomes 任务成功率涨幅

$0.08

/session-runtime-hour 公测价

技术 / API / 协议

产品 / 平台 / 客户

概念 / 工作流 / 范式

模型 / 算法

🔵 OFFICIAL Anthropic 官方博客 / 文档 / keynote 直出 ⚪ MEDIA 第三方媒体 KOL 独立开发者 CN 中文社区

← 左右滑动 · 键盘←→ · 点击虚线注释 →

一图速览：5/6 旧金山发布的核心要点

What was announced · TL;DR

一句话定性 Anthropic 把 Managed Agents 从“能跑”推到了“能进化”。不只是产品更新，而是 Anthropic 对“企业级 AI agent 应该是什么样子”这个问题的系统性回答。

🔵 ANTHROPIC OFFICIAL
2026 年 5 月 6 日，Anthropic 在旧金山举办的 Code with Claude 2026 开发者大会上，对其在 4 月 8 日刚刚进入公测的 Managed Agents 平台进行了首次重大功能升级。这次升级一次性带来了三个能改变企业 AI agent 落地方式的能力。[1]↗

Dreaming（做梦）——让 agent 在不工作的间歇里复盘过去会话，自动总结教训写回长期记忆，跨会话自我改进。OFFICIAL
Outcomes（结果导向）——开发者用一份 rubric（评分细则）指挥 agent，独立 grader 在自己 context 里评估输出，不达标就要求修正。OFFICIAL
Multiagent Orchestration（多智能体编排）——lead agent 拆任务给多个 subagent 并行处理，每个 subagent 可挂自己的 model / prompt / tool。OFFICIAL
同时为 Managed Agents 开放 Webhooks 等开发者集成能力。OFFICIAL
新功能可用状态：Outcomes / Multiagent / Memory 进入 public beta，Dreaming 仍是 research preview，需走 developer access program 申请。

如果用一句话概括：Anthropic 把 agent 从“被指令驱动”推进到了“被结果驱动并能自我学习”的阶段，并把这一切打包成由它来托管运行的云服务。

—— OPRAX 综合定性

大会本身：Code with Claude 2026 三城巡回

SF · London · Tokyo · 第二届开发者年会

🔵 ANTHROPIC OFFICIAL
Code with Claude 是 Anthropic 的开发者年度大会，2026 年是第二届。这一届扩展为三个国家三个城市的“巡回”：旧金山（5/6）、伦敦（5/19）、东京（6/10）。Managed Agents 三大新功能就是在 5 月 6 日旧金山站的 opening keynote 上首次公开宣布的。[8]↗

2026-05-06 · 旧金山

Opening Keynote · Managed Agents 三大新功能首发

登台讲解：Ami Vora（首席产品官）、Boris Cherny（Claude Code 负责人）、Angela Jiang（Claude Platform 产品负责人）。[11]↗

2026-05-19 · 伦敦

尚未召开

可能带来区域性公告、补充内容，或 Dreaming 转 GA 的时间点透露。

2026-06-10 · 东京

尚未召开

日本/亚太开发者面向。

同期发布的配套消息 Claude Code 与 API 用户的 5 小时使用上限翻倍、Claude Code 中的 Routines 功能、与 SpaceX 数据中心 Colossus 的容量合作。Shopify、Mercado Libre 等大客户分享了大规模代码与数据任务的实战。

⚪ KOL · Simon Willison
现场资深开发者 KOL Simon Willison（Datasette 作者）以 live blog 形式记录了整场内容。外界许多媒体报道里关于 keynote 的细节，最早其实就来自他的现场速记。但他的文章是高质量“现场笔记”，不是 Anthropic 官方稿件——要看完整原版还得回到 Anthropic Events 页面上的官方录像。[12]↗

理解“官方说什么”和“第三方怎么看”的差别，是看懂这次发布的关键。本文每段内容都会标记来源类型。

Managed Agents 平台：4 月公测，5 月升级

A managed harness for running Claude as autonomous agents

📚 BACKGROUND · 背景
什么是 Anthropic?Claude 模型的母公司,2021 年由 OpenAI 前研发副总裁 Dario Amodei 创立,与 OpenAI、Google DeepMind 一起被视为前沿大模型的“三巨头”。
什么是 Agent SDK?Anthropic 提供的开发者库,让你在自己的机器上跑 agent loop(=“自托管”路线)。和今天讲的 Managed Agents(=“Anthropic 替你跑”)是同一个公司的两条产品线,可选其一也可组合。
这些功能是“平台”不是“模型”:Dreaming/Outcomes/Multiagent 三大功能不改 Claude 模型本身,只在外面给 agent 加上“能反思”“能被打分”“能分工”的能力。

为什么要先讲平台要看懂 5/6 发布的三大新能力，得先理解 Managed Agents 平台本身——否则容易把 Dreaming、Outcomes 误解为 Claude 模型本身的能力升级，它们其实是平台层的能力。

🔵 ANTHROPIC OFFICIAL
Managed Agents 是 Anthropic 在 2026 年 4 月 8 日推出的公测产品,定位是“运行 Claude 作为自主 agent 的托管 harness”。它不是新模型、不是 AI 应用,而是一组组合式的 API + 一整套云端运行基础设施:沙盒、长时会话、上下文压缩、prompt 缓存、状态持久化、容器生命周期、错误重试、tracing、guardrail 等等都不用开发者自己再造。[13]↗

让你从原型到上线由几个月缩短到几天。

—— Anthropic 官方博客 (4 月首发版) OFFICIAL

FIG.1 · Managed Agents 平台分层 · 灰底 5/6 新增能力

计费模型 + Agent SDK 关系：“自己跑”还是“托管跑”

Pricing & Managed Agents vs Agent SDK

🔵 ANTHROPIC OFFICIAL · 三条收费线
第一条线：token，按 Claude 模型本身的标准 API 费率。第二条线：session runtime，每个 session 实际运行时间按 $0.08/小时，按毫秒计费——空闲（等用户输入、等工具确认、排队）不算钱。第三条次要线：工具消耗（如 web search 按 $10/1000 次）。[15]↗

⚪ KOL · WaveSpeed / Tygart Media / Finout
独立分析方对这套定价的成本测算[16]↗：短任务（几分钟到 1 小时内）和稀疏调用，$0.08/小时基本可以忽略；但对长跑型场景（24×7 监控类、跑几小时的研究型任务），runtime 部分会成为重要成本来源。

三种典型场景的费用感觉：

$0.0067

5 分钟客服 agent · 单次 runtime

~$700

24×7 监控 agent · 单 agent / 年

$0.4–$3

研究型 agent · 跑几小时

×1.5

建议 ROI 安全系数（预留涨价）

📚 BACKGROUND · 背景
SDK 是什么?Software Development Kit(软件开发工具包)— 一组库 + 文档,让开发者在自己的代码项目里调用某个服务。比如 AWS SDK 让你写 Python 代码就能调亚马逊云;Agent SDK 让你写代码就能在自己的机器上(本地、内网服务器、自己的云)跑一个 Claude agent。
“托管”(managed)和“自托管”(self-hosted)区别?托管 = 别人替你跑,你只用 API。自托管 = 你自己跑,数据流量沙盒都在你掌控里。例如 Notion 是托管(SaaS),WordPress 可以自托管。Managed Agents = 托管的 agent 服务;Agent SDK = 自托管路线。

Agent SDK vs Managed Agents Agent SDK 是“开发者自己跑”——一个让开发者在自己机器上跑 agent loop 的 SDK 库。Managed Agents 是“Anthropic 替你跑”——托管 harness。[17]↗

AGENT SDK · 自托管

本地原型 / 开发期

需要本地文件、私有网络；对成本可控性要求高；希望对运行时拥有完全检查能力。

MANAGED AGENTS · 托管

生产 / 长时任务

长时任务；不愿自建沙盒和断点恢复；工具都在公网或既有 MCP 后面。

业内被普遍接受的最佳实践：用 Agent SDK 在本地原型 → 验证逻辑 → 迁移到 Managed Agents 上线——享受 Anthropic 提供的可靠性和扩展性。

—— KOL WaveSpeed / Verdent / Avinash Sangle 综合 [18]↗

Dreaming · 让 agent 在“睡觉”时学习

Dreaming · the “star” feature · scheduled reflection

📚 BACKGROUND · 背景
什么是 agent?把大模型 + 工具(浏览器、文件、API)+ 一段“让它自己往前推进”的循环代码组合起来,让 LLM 像“员工”一样反复调用工具完成任务。普通聊天机器人是“问一句答一句”;agent 是“给目标 → 自己分步骤做 → 调用工具 → 得到结果”。
为什么 agent 需要“记忆”?没记忆的话,每次对话从零开始,反复踩同样的坑。Anthropic 在年初推过 agent memory(给 agent 一个可读写的“日记本”),Dreaming 在它之上加“定期翻日记本提炼经验”的能力。

为什么是“明星”功能如果说 5/6 发布的“明星”，毫无疑问是 Dreaming。这是一个非常有想象力、并且名字非常聪明的功能。从社交媒体反响看，Dreaming 是这次发布最容易被外界记住的关键词。

它要解决的空缺：传统 agent 在每个会话结束后，记忆是相对扁平的——要“从经验中提炼出更好的工作方式”，过去基本要靠人工维护 prompt 或外部脚本。一些团队会跑分析、把高频错误总结成 prompt——更新慢、不可扩展、强烈依赖工程师直觉。

🔵 ANTHROPIC OFFICIAL · Dreaming 定义
Anthropic 把 Dreaming 描述为一个 scheduled process（定时进程）：它在 agent 不工作时复盘过去的会话和 memory store，识别跨会话的共性模式，然后整理记忆。它能挖出来的是单个会话内部看不到的东西——反复出现的错误、不同 agent 自发收敛到的工作流、一个团队成员之间共享的偏好——并重新组织记忆结构，让信息密度始终保持高信号。[2]↗

人类睡觉时大脑会做的事，被借用过来命名了一个 AI 功能。这个比喻在媒体传播里非常容易抓人。

—— OPRAX 综合观察

Dreaming vs Memory · 存储层 vs 反思层

A diary vs an annual review · 日记 vs 年终总结

🔵 ANTHROPIC OFFICIAL
Anthropic 在 2026 年早些时候已经为 Claude 推出了 agent memory，让 agent 在单个会话内甚至跨会话保留偏好和上下文。[19]↗ 但 memory 只是“记下来”，Dreaming 是“消化和再组织”——一个是存储层，一个是反思层。

MEMORY · 日记本

把每天发生的事记下来

单会话内 / 跨会话保留偏好和上下文。扁平存储。

DREAMING · 年终总结

把日记本定期翻一遍提炼洞见

提炼“反复栽跟头”、“成功率最高的做法”、“共同偏好”，写回索引层。

⚪ MEDIA · The New Stack
The New Stack 报道把 Dreaming 比作 “AI agent 的整理与归档过程”。[20]↗

⚪ KOL · DEV Community
DEV Community 一篇技术解读指出，Dreaming 真正提供的是一种 continuous improvement loop——和 Outcomes 配合起来，会形成“评估—修正—跨会话学习”的循环，而且这个循环在很多场景里不需要人类介入。[21]↗

⚪ MEDIA · The Decoder
The Decoder 把焦点放在 Dreaming 与传统 fine-tune 的差别上——Dreaming 不修改模型权重，只更新长期记忆 store，因此它的“学习”更轻、更可逆、更适合频繁迭代的产品场景。[25]↗

控制粒度：自动写回，还是人工先 review

Auto-merge vs review-before-merge · 合规妥协

🔵 ANTHROPIC OFFICIAL · 控制选项
考虑到企业用户的合规与可解释性要求，Anthropic 留了一个重要选项：Dreaming 可以选择自动更新记忆，也可以让人工先 review 改动再合入。[2]↗ 这一点在很多媒体报道里被反复强调，因为它直接决定了企业是不是敢把 Dreaming 接到自己的核心工作流上。

DEEP-1 为什么 review-before-merge 是“合规妥协”

对很多受监管行业（金融、法律、医疗）来说，“AI 系统会自己改自己的记忆”听上去就要触发合规警报。所以这个选项几乎是 Anthropic 在产品层做出的合规妥协。但这也把责任放回了客户自己身上：愿意 review 多少？多频繁地 review？这些问题没有标准答案，需要每个企业自己设计审批流程。

⚪ MEDIA · Help Net Security
从安全角度提醒：Dreaming 改的是记忆，那么记忆的访问与变更必须有完整的审计日志，不然在合规审查时是无法解释的。[23]↗

实测数据：Harvey 完成率 ~6×

Harvey case · ~6× complete rate · legal industry

🔵 ANTHROPIC OFFICIAL · Harvey 案例
Harvey（一家面向法律行业的 AI 公司）用 Managed Agents 处理长篇起草和文档生成。在没有 Dreaming 的版本里，agent 经常需要重复发现“某种文件类型的正确处理方式”或“某个工具的调用模式”。
把 Dreaming 接上之后，agent 能跨会话保留这些教训。根据 Anthropic 内部测试，complete rate（完成率）提升了约 6 倍。[6]↗

Harvey LEGAL

complete rate ×6

长篇起草 + 文档生成。法律行业对 agent 的重复性流程依赖度高，Dreaming 在这种场景里能把“重复发现”这件事一次性解决。

DEEP-2 “6 倍”数字怎么读？

“6 倍”是一个相对值，不是绝对成功率。如果原本是 5% 的完成率，6 倍是 30%；如果原本是 15%，6 倍是 90%——Anthropic 在博客里没有披露基准值，所以严格意义上，这个数字的含义需要谨慎解读。但即便如此，它在媒体上被反复引用，成为这次发布最容易被记住的数据点之一。

🔵 ANTHROPIC OFFICIAL · Availability
Dreaming 目前是 research preview 形态，只通过 developer access program 提供，需要单独申请。Anthropic 没有给出转 GA 的具体时间表。[7]↗

这意味着：不是所有 Managed Agents 用户立刻就能用上 Dreaming。作为 research preview，它的接口和行为可能在没有正式版本号变更的情况下发生变化，因此不要把 production 工作流的核心可靠性赌在它现在的具体实现上。

第三方观点：“打瞌睡”还是“治理挑战”？

VentureBeat · SiliconANGLE · The Decoder

⚪ MEDIA · VentureBeat
把 Dreaming 形容为 “自我改进 AI 系统的一步”，但也指出企业部署这种“agent 自学”功能时会面临治理和审计上的挑战——比如怎么解释 agent 学到了什么、这些“梦”会不会引入偏见或不期望的行为。[22]↗

⚪ MEDIA · SiliconANGLE
直接用了一个吸引眼球的标题——“Anthropic 让 Claude agent 做梦，这样它们就不会在工作时打瞌睡了”。[24]↗ 它的核心论点：Dreaming 把 agent 从“每次都从零开始”变成“每次都比上次更聪明”，这是 enterprise 真正想要的状态。

VIEWPOINT · 决策者叙事

SiliconANGLE 的角度偏面向决策者的“叙事性”：客户买 agent 不是买一次性 demo，而是希望它能在整个组织里“生长”。Dreaming 是 Anthropic 给这个生长机制加的一层。

⚪ KOL · BuildFastWithAI
BuildFastWithAI 出了两篇评测——“Review: Is It Worth It?”和“Dreaming Explained”。[38]↗ 整体判断：值得用，但要小心成本和 lock-in。它对 Dreaming 的推荐措辞比较克制——先在非关键路径上跑一阵，建立信心后再用到 production。

Outcomes · 从“怎么做”到“成功的样子”

Outcomes · the most underrated yet most useful · Simon Willison

Outcomes 是这次发布里“最被低估、但最实用”的功能。

—— KOL Simon Willison · live blog [12]↗

📚 BACKGROUND · 背景
什么是 prompt 工程(prompt engineering)?用自然语言写一份指令,告诉大模型怎么做事 — 比如“你是资深律师,请按...格式审一份合同”。过去 3 年是 LLM 应用开发的主要技能,堆了大量 if-else、思维链、few-shot 示例。
什么是“声明式”约束?不写“怎么做”,只写“什么样算对”。比如不说“先 A 再 B 再 C”,而说“最终输出必须满足:覆盖 5 个章节、引用 3 个来源、不超 2000 字”。SQL、CSS、Kubernetes 配置都是声明式 — 你说目标,系统找路径。Outcomes 把“声明式”带到 agent 工作流。

范式反转绝大多数 prompt 工程实践，本质上是开发者用自然语言描述 “agent 应该怎么做”。Outcomes 反过来——开发者描述“成功的样子”，剩下的让 agent 自己去想办法达到。这有点像传统软件工程里把“步骤化命令”换成“声明式约束”。

🔵 ANTHROPIC OFFICIAL · 核心机制
具体来说，开发者写一份 rubric——一份评分标准，可以包含多个维度（“是否符合用户的写作风格”、“是否引用了来源”、“是否覆盖了所有要求要点”）。Managed Agents 的 harness 会自动配一个独立的 grader（打分器）。每当 agent 完成一轮工作，grader 在自己独立的 context window 里打分。[3]↗

这种“声明式”范式对工程团队的好处不只是省事——它把“agent 表现好坏”从一个主观感觉问题变成了一个有 rubric、有评分、有迭代的工程问题。agent 的输出从此可以被像测试用例一样对待。

—— OPRAX 综合解读

为什么 grader 要独立 context

Grader-in-fresh-context · the most subtle architectural decision

微妙也最关键的设计如果让同一个 agent 既“做”又“评”，它会被自己刚才的推理过程影响——人类工程师做 self-review 时也会有这种 bias。把 grader 放进一个全新的、独立的 context window 里，它能像一个“不知道前因的陌生评审”那样客观地判断输出是不是真的满足要求。

FIG.2 · grader 在独立 context 里评估，避免 agent 的 self-review bias

⚪ KOL · LLM 工程社区
这个设计在 LLM 工程社区里其实有先例——业内俗称 judge LLM。但 Outcomes 把它从一个 ad-hoc 实践变成了平台一等公民，并且和 agent 的修正循环耦合在一起，这一步是关键。

修正循环与状态机：3 次默认，最多 20 次

Default 3 iterations, configurable up to 20 · explicit state codes

🔵 ANTHROPIC OFFICIAL · 修正循环
如果 grader 判断没达标，它会指出具体的差距，agent 拿到这些差距说明再做一遍。默认会循环 3 次，最多支持配置到 20 次。[26]↗

🔵 ANTHROPIC OFFICIAL · 状态码
Outcomes 还会输出结构化的状态：

STATE · satisfied

满足

grader 判定通过 rubric 全部维度。可直接消费输出。

STATE · needs_revision

需要修改

指出具体差距，agent 在下一轮迭代。

STATE · max_iterations_reached

达到最大次数仍未达标

触发人工升级路径。

STATE · failed

失败

grader / agent 自身错误，工作流方知道是系统问题而非业务问题。

这个状态机非常重要——它使得 Outcomes 可以被嵌入到自动化流水线里。“如果 satisfied 就发邮件通知客户，如果 max_iterations_reached 就升级给人工审核。”在过去用 prompt-loop 跑 agent 的时代，这种自动化分支非常难写——你拿不到一个干净的“任务到底有没有完成”的布尔信号。

—— OPRAX 综合解读

Outcomes 数据：+10pp · Wisedocs 50%

Internal test +10 percentage points · Wisedocs 50% throughput

🔵 ANTHROPIC OFFICIAL · 内部测试
相比标准 prompt-loop，Outcomes 让任务成功率最多再提高约 10 个百分点。Anthropic 强调一个细节：越难的任务，Outcomes 带来的边际收益越大。[3]↗

这暗示什么 Outcomes 在简单任务上是“锦上添花”，在复杂任务上是“质变”。这也是它在 Simon Willison 眼里被定性为“最被低估、最实用”的原因。

Wisedocs MEDICAL · LEGAL

审阅速度 +50%

用 Managed Agents 构建文档质量检查 agent，用 Outcomes 按内部指南给每一份审阅打分。结果是审阅速度提升了 50%，同时质量保持与团队标准一致。[3]↗

⚪ OPRAX · Enterprise 风格
这是一个非常 enterprise 风格的 case：不是炫技的演示，而是把 agent 变成可考核、可控的内部工具。对很多对 LLM 还心存疑虑的传统行业来说，“我能定义清楚什么叫‘通过’”这件事本身就是把 agent 引入工作流的前提。

Wisedocs 的这个案例可以作为 onboarding 类似客户的标准模板。

—— OPRAX 综合判断

从 prompt 工程到 outcome 工程

From prompt engineering to outcome engineering · paradigm shift

⚪ MEDIA · SD Times / The New Stack
SD Times 与 The New Stack 都把 Outcomes 视为 “从 prompt-engineering 到 outcome-engineering 的转折点”——这个表述在过去几个月已经成为业内常用术语。[28]↗

长期来看，开发者会把更多时间花在写 rubric 和审 grader，而不是在 prompt 里堆砌 if-else 与 chain-of-thought 提示。

—— MEDIA SD Times 综合 [28]↗

VIEWPOINT · 招聘 JD 启示

如果这个判断成立，那么未来一段时间内，团队招聘 AI 工程师的 JD 里 “会写好的 rubric”可能比 “会写好的 prompt”更值钱。

⚪ MEDIA · Developers Digest
比较了 OpenAI Codex 的 /goal 命令和 Claude Managed Outcomes 这两种“结果导向”控制循环，结论是：Outcomes 在生产场景里更胜一筹——它有显式的修正轮和明确的最终状态码，不像 /goal 那样把这层留给开发者去 polling。[27]↗

即使你不用 Managed Agents Outcomes 的 grader-in-fresh-context 设计，是这次发布在工程理念上最值得借鉴的细节。哪怕你不用 Managed Agents，把这个设计搬到自己的 agent 系统里也能立刻拿到收益。

Multiagent · 给 agent 装上“组织”

Lead agent + subagents · the most “industrial” feature

三大功能的比喻 Dreaming 像神经科学比喻，Outcomes 像系统工程比喻，Multiagent Orchestration 则像组织架构比喻——它给 agent 装上了“组织”。

🔵 ANTHROPIC OFFICIAL · 核心机制
一个 agent 干不动一个复杂任务的时候，让 lead agent 负责拆任务、分发，让多个 subagent 各自负责一个子任务并行跑，然后把结果汇回主 agent，由主 agent 总结输出。每个 subagent 可以挂自己单独的 model、单独的 system prompt、单独的工具集。[4]↗

这意味着一支虚拟“团队”里，主 agent 可能跑在最聪明但最贵的 Opus 上，而 subagent 跑在 Haiku 上做大量 IO 密集的活——和真实工程团队里 senior 协调、junior 干活的分工很像。

—— OPRAX 综合定性

DEEP-3 为什么是平台一等公民

这种异构编排在过去自己用 Agent SDK 实现是可行的，但要写不少胶水代码：context 同步、并发控制、错误重试、子任务的可观测性等等。Multiagent Orchestration 把这一整套抽象成了平台一等公民——开发者可以专心定义“分谁干、谁干什么”，而不再操心“怎么让他们一起干”。

共享文件系统 · 客户案例 Spiral by Every

Shared filesystem · Spiral case · Haiku-lead + Opus-sub pattern

🔵 ANTHROPIC OFFICIAL · 共享文件系统
Multiagent Orchestration 让所有 agent 共享一个文件系统空间。subagent 可以把自己挖出来的证据和中间结论写到共享文件里，主 agent 来汇总。[29]↗

FIG.3 · Spiral 写作 agent · lead 跑 Haiku 接需求 · subagent 跑 Opus 并行写稿 · Outcomes rubric 打分

Spiral by Every AI WRITING

Multiagent + Outcomes + Memory 三件套

🔵 OFFICIAL
lead agent 跑 Haiku，负责接住用户请求、必要时反问，把“动笔写”delegate 给跑在 Opus 上的 subagent。当用户要“多个备选稿”，subagent 是并行跑的。每一稿再由 Outcomes 用 Every 的编辑准则和用户的 voice（声音/风格）作为 rubric 打分；只有过关的稿件会返回给用户。[4]↗

⚪ KOL · Marcus Moretti @ Every
Spiral 团队工程师 Marcus Moretti 在 Every 上撰文：迁移到 Managed Agents 之后，他真正感受到的好处不是某一个具体功能，而是“知道这一切都能跑得起来，不用再自己从零测试整套 agent primitives”。[30]↗

这是工程师视角里最有价值的反馈——它不是在说“功能炫”，而是在说“我可以省下多少 weeks 的工程时间”。

—— OPRAX 综合解读

Netflix 3000+ 工程师 · 反方观点

Netflix at scale · the “don’t use multi-agent” warning

Netflix 平台团队 PLATFORM ENG

服务 3000+ 工程师

Netflix 平台团队已经在生产环境里部署 Multiagent Orchestration。[4]↗ Anthropic 之前还专门做过一场 webinar，请 Netflix 工程负责人和 Anthropic Applied AI 团队一起讲过 Netflix 怎么把 AI agent 推广到 3000+ 工程师身上。[31]↗

Netflix 体量决定的需求单个 agent 在 3000 多人的工程组织里几乎不可能服务好所有人，必须有“管理者 agent + 一线 agent”这样的层级才能覆盖各种边界情况。Multiagent Orchestration 给这种结构化部署提供了平台支撑。

⚪ KOL · unicodeveloper · Medium
发表在 Medium 的独立作者 unicodeveloper 在 “Honest Pros and Cons”[33]↗ 里指出反方观点：多 agent 编排虽然炫，但增加了系统失败模式的数量——subagent 互相之间的隐式协议、共享文件系统的并发写入、上下文同步的时延，都是新的工程坑。

小型团队先用单 agent 跑顺，再考虑上多 agent。

—— KOL unicodeveloper · Medium [33]↗

🔵 ANTHROPIC OFFICIAL · Building Multi-Agent Systems
在 Anthropic 自己的 Building Multi-Agent Systems 文档里也有一个原则：除非任务真的复杂到一个 agent 跑不动，否则不要用多 agent。[34]↗ 这条规则被 unicodeveloper 在 Medium 上重新强调了一次。

API · Webhooks · 可用性矩阵

API paths · Webhooks open · public beta vs research preview

🔵 ANTHROPIC OFFICIAL · API 路径
新功能在 API 层的位置：

多智能体：managed-agents/multi-agent
Outcomes：managed-agents/define-outcomes
Memory + Dreaming：memory 主题章节（Dreaming 仍需 developer access）

🔵 ANTHROPIC OFFICIAL · Webhooks 开放
Webhooks 这次也对所有 Managed Agents 开发者开放了——agent 状态变化、任务完成、Outcome 评分等事件都可以推到开发者自己的 endpoint 上。[5]↗

企业级集成意义以前要做“agent 完成任务后自动给客户发通知”，得靠开发者自己 polling 或写一个 long-poll 中间层；现在直接订阅事件就好。

可用性矩阵：

PUBLIC BETA · 公测可用

Memory · Outcomes · Multiagent · Webhooks

所有 Managed Agents 用户可用。beta 不承诺向后兼容——接口可能变。

RESEARCH PREVIEW · 申请制

Dreaming

通过 developer access program 申请。行为可能在没有版本号变更下变化。

DEEP-4 production 部署的实务建议

依赖这些 API 的代码路径要做好版本封装，至少留一个 wrapper 层——将来 API 变了也不至于满项目改。把“接口可能变化”算进风险预算里。

客户案例汇总：Anthropic 的“行业横切面”

Harvey · Wisedocs · Spiral · Netflix · Shopify · Mercado Libre

Harvey LEGAL

Dreaming · 完成率 ×6

长篇起草。法律行业对 agent 的重复性流程依赖度高，Dreaming 在这种场景里能把“重复发现”一次性解决。

Wisedocs MEDICAL · LEGAL

Outcomes · 审阅速度 +50%

医疗法律文档审查。把 agent 当作“可考核员工”来用的样板。

Spiral by Every AI WRITING

Multiagent + Outcomes + Memory 三件套

lead agent 跑 Haiku、subagent 跑 Opus 的设计被许多后续报道作为“经济性 + 性能”平衡的范例引用。

Netflix PLATFORM ENG

服务 3000+ 工程师

从这个 case 看出 Anthropic 想把 Managed Agents 做成“大组织内部 agent 平台”的基础设施。

Shopify · Mercado Libre COMMERCE

大规模代码与数据任务实战

Code with Claude 2026 keynote 现场分享。共同提供了“全球大规模电商场景”的横切面。

两个销售倾向 Anthropic 在销售上的两个倾向：第一，把每个新功能都“绑”到一个具体客户的指标上；第二，主打企业级垂直场景（法律、媒体、流媒体、电商），而不是消费者 demo。这种叙事方式对决策者特别管用——它让 buyer 在内部立项时可以引用一个具体的对标案例。

选型指南：Managed Agents vs Agent SDK

When to choose which · 公认的取舍

⚪ KOL · WaveSpeed / Verdent / Avinash Sangle 综合
多位独立开发者都在博客里写过这个选型问题。[18]↗ 综合看，公认的取舍是：

MANAGED AGENTS · 选它当...

推到生产 / 长跑任务

要把 agent 推到生产
任务时间长
不想自己维护沙盒和断点恢复
工具都在公网或 MCP 后面

AGENT SDK · 选它当...

本地 / 私网 / 强可控

需要访问本地文件或私有网络
对成本可预测性要求高
需要在开发期对运行时完整内省
负载达不到 session-hour 盈亏平衡点

最常见的演进路径：用 SDK 在本地原型 → 验证逻辑 → 迁移到 Managed Agents 上线。

—— KOL 综合最佳实践

风险与争议：把好的与不好的都摆出来

6 axes of risk · vendor lock-in · pricing · governance · etc

RISK-1 Vendor lock-in

VentureBeat 最先提出。[36]↗ Memory + Dreaming 学到的东西、Outcomes 的 rubric 库、agent 的 session checkpoint，全都跑在 Anthropic 的基础设施里。导出策略目前还不是文档里的一等公民。

减少 lock-in 的可行做法：把 rubric 写成可移植的 JSON / YAML；定期把 memory 内容导出存档；关键工具走 MCP 而非内置 tool；架构层保留切换到 Agent SDK 的可能性。

RISK-2 价格不确定性

公测期 $0.08/小时只是起步价。[15]↗ 长跑型 agent（24 小时监控）按这个价跑下来，每个 agent 一年 ~$700；同时跑 1000 个，年化成本会是百万美元级。这意味着 GA 时定价策略变化会直接决定一些场景的可行性。

务实建议：在算 ROI 时，按 $0.08 打 1.5 倍安全系数，预留涨价空间。

RISK-3 Beta 状态

Outcomes、Multiagent、Memory 是 public beta；Dreaming 仍是 research preview。[7]↗ beta 不承诺向后兼容。production 部署时要把“接口可能变化”算进风险预算——至少留一个 wrapper 层。

RISK-4 记忆治理与隐私

Dreaming 学到的“模式”会不会无意间把 PII 或敏感信息写进长期记忆里？Anthropic 的回答是给了 review-before-merge 选项[2]↗，但这把责任放回了客户自己身上。Help Net Security 等媒体认为[23]↗，GA 之前 Anthropic 应该把更多的 redaction、policy enforcement、记忆审计能力放进默认体验里。

RISK-5 多 agent 系统的可观测性

Multiagent Orchestration 让“调试”变得更复杂——追踪一个失败的产物到底是 lead agent 的指挥问题，还是某个 subagent 的工具问题，还是共享文件系统上的脏数据。Anthropic 提供了 tracing，但生态里的可视化工具还在追赶。

意味着上多 agent 之前，需要先把单 agent 的可观测性做到位——日志、指标、traceID 链路，缺一个都会让多 agent 的故障排查变成噩梦。

RISK-6 “AI 是否过度自动化”的伦理讨论

少数评论员（如 The Decoder）担心：[25]↗ 让 agent 自己学习、自己评估、自己分工，意味着人类在 agent 工作流里能介入的窗口越来越窄。如果 agent 表现稳定还好，但一旦 agent 出现系统性偏差，发现的窗口可能也变窄。

在治理流程上要保留采样审核、红队对抗、周期性评估这些做法，避免一切都被 agent 自动化掉。

要点总结：7 条最重要的判断

Seven key takeaways

5/6 发布的核心是把 Managed Agents 从“能跑”推到“能进化”。Dreaming 提供跨会话学习；Outcomes 提供可验证的目标驱动；Multiagent Orchestration 提供工作分解。三者合起来构成 enterprise agent 的“三件套”。
“做梦”不是营销词。它在 Harvey 等真实客户的指标上带来了量级提升（约 6 倍）。Outcomes 在内部测试上也能让最难的任务再涨 ~10 个百分点。这些数据来自 Anthropic 自己，但有具体客户名背书，可信度比一般 demo 高。
从“prompt engineering”到“outcome engineering”是这次发布带来的真正范式转移。Outcomes 的 grader-in-fresh-context 设计，是这次发布在工程理念上最值得借鉴的细节。
定价模式相对透明，但长跑场景需要算清楚总账。短任务 runtime 费基本可以忽略；长跑任务里它可能变成主要成本。
选型决策:PoC / 验证阶段优先 Agent SDK 自托管(runtime 费可控);production 上线长任务用 Managed Agents 大幅降低运维成本;把 Outcomes 当一等公民设计 agent,效果远比花精力打磨 prompt 来得稳;对 Dreaming 持谨慎乐观,先在非关键路径接,建立信心后再向核心工作流推。
发布会本身只是第一站。伦敦（5/19）、东京（6/10）站点尚未召开，后续可能有补充内容、新区域合作公告或 Dreaming GA 时间点透露。值得跟进。
对所有产品和工程团队:最值得借鉴的不是“上 Managed Agents”这个具体决定,而是它体现出来的那套设计哲学——把 agent 变成有目标、可考核、能反思的“组织成员”,而不是停留在“prompt + 工具调用”的玩具阶段。即使你用其他模型搭自己的 agent,引入 outcome engineering、grader-in-fresh-context、lead-subagent-pattern、scheduled-reflection 这些抽象,也能让你的 agent 立刻上一个台阶。