Anthropic 把评估做成了产品：Outcomes 背后的真实故事
1. 你写过这个循环
18 个月前，当你第一次把 Claude Agent 部署到生产环境时，你写了一个评估标准（rubric）、写了一个评分器（grader）、写了评分器说”不通过”时的重试逻辑。你写了一个 while not satisfied 循环。
2026 年 5 月 6 日，Anthropic 在 Code with Claude San Francisco 上把这个循环做成了 API 端点，取名为 Outcomes。
这是新闻。下面的故事更大——Outcomes 是 Anthropic 决定出售的第一个”马具层”（harness layer）。
2. 四项发布
Anthropic 在 5 月 6 日向 Managed Agents 发布了四项内容，没有新模型：
| 功能 | 状态 | 作用 |
|---|---|---|
| Outcomes | 公开 Beta | 评估循环即服务 |
| Multi-Agent Orchestration | 公开 Beta | 多 Agent 编排 |
| Webhooks | 公开 Beta | 生命周期钩子 |
| Dreams | 研究预览 | 跨会话记忆整合 |
媒体焦点在 Dreams 上——能让 Agent 在会话之间整合记忆，在 Harvey 上的任务完成率提升了六倍。但架构意义最深的是 Outcomes。
3. Outcomes 是什么
评估标准（rubric）是一个 Markdown 文档。你描述”成功”长什么样。Agent 做工作。当 Agent 认为完成时，一个独立的 Claude 实例接收输出、读取你的 rubric、评估质量——在它自己的上下文窗口里运行。
关键设计：评分器不看到 Agent 的推理过程。 它不看 Agent 走了哪些工具调用路径。它只看到最终输出和 rubric。这防止了评分器被 Agent 的”看起来很有道理但其实是错的”推理影响。
循环默认最多跑三次，上限二十次。你可以写 rubric 来指定每次迭代是放松还是收紧标准。
Outcomes 在旧架构中对应的是 500 行代码。在 Managed Agents 中对应的是四行 API 调用和一份 Markdown 文件。
五个状态：
| 状态 | 含义 |
|---|---|
| satisfied | 发布 |
| needs_revision | 指出问题，再来一次 |
| max_iterations_reached | 尝试次数耗尽 |
| failed | 评分器无法评估 |
| error | 系统错误 |
性能数据：
- 内部基准：Outcomes 在困难任务上比标准 prompt 方式提升 10 个百分点，在领域特定任务上提升 8.4 个百分点
- 客户数据：Wisedocs 用 Outcomes 审核文档，审核速度提升 50%——这个 50% 不是基准测试，是实际生产中的数据
4. 真正的故事：4 月 8 日的架构重构
5 月 6 日的发布不是路线图——路线图已经在 4 月 8 日发布了。5 月 6 日是”税收”：四个依赖同一个底层重构的功能，各自收一次费。
4 月 8 日，Anthropic 发布了一篇工程博客《Scaling Managed Agents: Decoupling the brain from the hands》。几乎没人引用它。它不发布任何功能。它描述 Managed Agents 如何围绕三个原语重建：
Session（会话） 只追加的事件日志。通过 getEvents() 读取，emitEvent() 写入。工具调用、结果、模型响应、用户消息都在一个持久化的日志里。你可以把 session 看作 Agent 活动的完整审计轨迹。
Brain（大脑） Claude 本身 + 调用 Claude 并路由工具调用的 harness 循环。从 harness 角度看，brain 故意无状态——恢复就是打开另一个 brain，读取同一个 session。如果第一个 brain 崩溃了，第二个 brain 可以从 session 日志的断点处接上。
Hands（手） 实际执行代码的沙箱、MCP 服务器、工具。从 brain 角度看，所有 hands 长得一样：execute(name, input) → string。无论底下是 Python 解释器、bash shell 还是外部 API，brain 不关心。
Anthropic 用 Unix 的 read()/write() 做类比——跨硬件代际工作的抽象层。效果：首次 token 时间 p50 下降 60%，p95 下降 90%+。
为什么这个重构对 Outcomes 重要
在旧的耦合架构中，评估循环是你的问题——因为没有共享的基础设施来挂第二个评估器。Agent 的 brain 把 session 保存在内存里。工具调用和模型响应用同一个进程处理。
4 月 8 日的解耦改变了这一切。session 是持久化且可查询的。两个 brain 可以读同一个 session。 一个是 Worker。第二个隔离的 brain 是 Grader。
这就是 Outcomes 的机械原理：第二个 brain 接入你的 session 日志，通过你定义的 rubric 来评分。 Grader 读取 Worker 的输出，打分，把结果写回 session。Worker 在下一轮迭代中读取 feedback。
5. 马具层正在被拆解
5 月 6 日发布的是四个层的拆解。每一项曾经都是你的代码：
| 层 | 产品 | 你之前做的 |
|---|---|---|
| 验证 | Outcomes | while not satisfied 评估循环 |
| 记忆 | Dreams | 定时 cron 任务总结会话 |
| 编排 | Multi-Agent | asyncio 调度器 + 自定义分发表 |
| 生命周期 | Webhooks | 轮询 API 检查任务完成 |
每个 harness 层都变成可以单独购买的产品。你不再构建它们——你组合它们。
这就是为什么 Outcomes 最先发布——在四个中，验证是最干净的提取层。记忆有策略和审计复杂性。编排有成本控制复杂性。Webhooks 有兼容性复杂性。验证只有：rubric → API → 结果。
6. 你该怎么做
文章给出三个具体建议，按杠杆排序：
停止写评估循环，开始写 rubric
Outcomes 处理循环、评分器、迭代上限、结构化反馈、重试逻辑、可观测性。你的工作变成定义成功标准。一个 Markdown 文件比 500 行 Python 容易维护得多。
停止构建记忆整理管道，开始调度 Dreams
大多数运行小时级或天级任务的团队都有自建的记忆层——六个月后成了负债。没有人愿意维护那段代码，但每个人都依赖它。
停止运行编排器，开始定义子 Agent 规格
如果你的 Agent 已经在协调并行工作，你有一个编排器。它可能用 asyncio、有自定义调度表、两年前加上的——你已经忘了它怎么工作的。
7. 诚实的权衡
- 硬约束：模型——Managed Agents 只跑 Claude。不支持 GPT、Gemini 或开源模型。如果你的栈当前是多模型的，这个路径不通。
- 软约束：数据——Session、记忆存储、dreams 和 grader 上下文都跑在 Anthropic 的基础设施上。对于受监管行业（金融、国防、医疗）需要认真评估。
- 软约束：API 稳定性——接口设计意图稳定（Anthropic 引用了 Unix 系统调用的持久性作为目标），但还没有长期历史数据来证明。
建议采用顺序
Outcomes 先上——最高的杠杆，最低的承诺。一个 Markdown 文件加一个 API 调用。可以在单个工作流上试点，随时可以回退。
应该继续自己写的部分： rubric、Agent 模板、工具定义、prompt、业务逻辑——一切编码”你的产品做什么”的东西，而不是”你的产品底层怎么做”的东西。
8. 观点
这篇文章最有价值的洞察不是 Outcomes 本身，而是”马具层正在变成 SKU”这个观察。回想过去一年 Anthropic 的工程投入——Claude Code、Claude Agent SDK、Managed Agents——全都在做同一件事：把每个生产 Agent 底下的那层基础设施，从你的代码库搬进他们的产品目录。
这不是一个功能加了价格标签。是每个生产 Agent 底下的那层代码，从你的代码库转移到了 Anthropic 的产品目录。
正确做法不是全部迁移。正确做法是删代码：停止写评估循环，开始写 rubric。
原始资料
- 《New in Claude Managed Agents: dreaming, outcomes, and multiagent orchestration》 — claude.com/blog/ (May 6, 2026)
- 《Scaling Managed Agents: Decoupling the brain from the hands》 — Anthropic Engineering Blog (April 8, 2026)
- 《Building Effective Agents》 — Erik Schluntz & Barry Zhang (December 2024)
- Simon Willison’s live blog of Code with Claude SF — simonwillison.net