Anthropic 5月发布的 Outcomes 功能,仅靠一个"评分Agent"就让PPT生成质量提升10.1%、Word文档提升8.4%、任务成功率提升10个百分点——不换模型、不改Prompt,只加了一层架构。本文带你拆解原理+给出可直接复制的配置模板。
如果你每天用 Claude Code 写代码、生成文档、做分析报告,你一定遇到过这个困境:
Agent 完成了任务,但质量参差不齐——有时候输出可以直接用,有时候需要大量手动修改。你不停地在"相信Agent"和"再检查一遍"之间摇摆,最后发现检查的时间比自己做还长。
Outcomes 的解决方案简单到让人意外:再派一个 Agent,只干一件事——打分。
一、Outcomes 是什么:一个独立的"评分官"
Outcomes 是 Anthropic 在 Code with Claude 2026(5月6日)发布的功能,核心机制只有三步:
任务Agent完成工作 → 评分Agent对照Rubric打分 → 不合格?打回重做
关键在于评分Agent和任务Agent是完全隔离的:
- 评分Agent看不到任务Agent的推理过程
- 评分Agent拥有独立的上下文窗口
- 评分Agent只拿到最终的输出文件,对照你写的 Rubric(评分标准)逐项检查
为什么隔离这么重要? 心理学上有个概念叫"锚定效应"——如果你让同一个Agent既做任务又做评判,它会被自己的推理过程"锚定",倾向于给自己的输出打高分。分开之后,评分Agent就像一位独立的代码审查者,不带偏见地评判最终产出。
Anthropic 公布的数据:
- PPT 生成质量提升 10.1%
- Word 文档质量提升 8.4%
- 最难任务的成功率提升 10 个百分点
- 所有提升都没换模型,没改 Prompt,只加了评分循环
二、实战配置:三步搭建你的 Outcomes 评分流水线
第1步:定义 Rubric(评分标准)
Rubric 是 Outcomes 的灵魂。它不是笼统的"写得好一点",而是可验证的检查清单。
以下是一个代码 PR Review 场景的 Rubric 模板:
# .claude/outcomes/pr-review.yaml
name: "PR Quality Gate"
description: "确保每个 PR 在合并前通过质量检查"
rubric:
- id: tests
weight: 30
question: "所有新增/修改的代码是否有对应的测试用例?"
pass_condition: "测试覆盖率 ≥ 80%,且所有测试通过"
- id: docs
weight: 15
question: "公共 API 是否有文档注释?"
pass_condition: "所有 export 的函数/类都有 JSDoc 或 docstring"
- id: security
weight: 25
question: "是否有明显的安全风险?"
pass_condition: "无硬编码密钥、无 SQL 注入、无 XSS 漏洞"
- id: style
weight: 15
question: "代码风格是否符合项目规范?"
pass_condition: "ESLint/Prettier 零报错,命名遵循项目约定"
- id: logic
weight: 15
question: "核心逻辑是否有明显的边界条件遗漏?"
pass_condition: "空输入、null、超长输入等边界条件均已处理"
threshold: 80 # 总分 ≥ 80 分才算通过
max_retries: 3 # 最多重试 3 次
第2步:配置 Subagent 定义
在 Claude Code 中,评分Agent通过 Subagent 实现。创建 .claude/agents/pr-grader.md:
---
name: pr-grader
description: 独立的 PR 质量评分Agent,对照 rubric 逐项打分
tools: [Read, Grep, Bash]
model: claude-sonnet-4-5-20250514
---
你是 PR 质量审查员。你的唯一职责是对照 Rubric 逐项检查 PR 代码。
## 工作流程
1. 读取 `.claude/outcomes/pr-review.yaml` 中的 rubric
2. 逐项检查 PR 中的代码变更
3. 为每项打分(0-100),并附具体理由
4. 输出最终评分和"通过/打回"判定
5. 如果打回,给出具体的修改建议
## 评分规则
- 只基于代码本身判断,不参考提交者的解释
- 扣分必须附代码位置(文件名+行号)
- 满分项也要说明为什么满分
- 最终输出格式:
```
## PR Quality Report
- Tests: 85/100 — 覆盖率82%,缺少 error handling 测试(src/auth.ts:45-60)
- Docs: 90/100 — 所有公共API有注释,但缺少参数类型说明
- Security: 95/100 — 无硬编码密钥,输入校验完善
- Style: 100/100 — ESLint 零报错
- Logic: 70/100 — getUser() 未处理 null 返回值(src/api.ts:120)
## Verdict: REVISE(总分 86/100,需修复 logic 和 tests)
```
第3步:在 CLAUDE.md 中启用
告诉主Agent何时触发评分:
# CLAUDE.md 片段
## 质量流程
当完成以下任务后,**必须**启动 pr-grader subagent 进行评分:
- 创建或修改 PR
- 生成新的模块代码
- 修改核心业务逻辑
启动方式:`Task(subagent_name="pr-grader", description="对当前变更进行质量评分")`
如果评分 < 80 或 grader 要求修改,必须先修复再合并,最多重试 3 次。
三、80行 DIY 版本:不依赖 Claude Managed Agents 也能用
Outcomes 的完整版需要 Claude Managed Agents(云端调度),但核心机制可以在本地 Claude Code 中复现。以下是自包含的 Python 评分脚本:
#!/usr/bin/env python3
"""自建 Outcomes 评分循环 —— 适用于任何 LLM API"""
import json, subprocess, sys
from pathlib import Path
RUBRIC = {
"tests": {"weight": 30, "check": "测试覆盖率≥80%,所有测试通过"},
"docs": {"weight": 15, "check": "所有公共API有文档"},
"security": {"weight": 25, "check": "无硬编码密钥、无注入风险"},
"style": {"weight": 15, "check": "Linter零报错"},
"logic": {"weight": 15, "check": "边界条件已处理"},
}
THRESHOLD = 80
MAX_RETRIES = 3
def grade_output(file_path: str) -> tuple[dict, int]:
"""让独立的 LLM 调用对照 rubric 打分"""
code = Path(file_path).read_text()
# 构建评分Prompt(关键:独立上下文窗口)
prompt = f"""你是代码质量评审员。对照以下 Rubric 对代码打分(0-100分/项):
{rubric_text}
代码:
{code[:8000]} # 截断过长代码
输出 JSON 格式:{{"tests": 分数, "docs": 分数, ... , "verdict": "PASS|REVISE", "issues": ["问题1", "问题2"]}}
"""
# 调用你的 LLM API(示例用 OpenAI 格式)
result = call_llm(prompt)
scores = json.loads(result)
total = sum(scores.get(k, 0) * v["weight"] / 100 for k, v in RUBRIC.items())
return scores, total
def outcomes_loop(task_output: str, retries=0):
"""Outcomes 核心循环:打分 → 不通过 → 修正 → 重新打分"""
scores, total = grade_output(task_output)
if total >= THRESHOLD:
print(f"✅ 通过!总分 {total}/100")
return True
if retries >= MAX_RETRIES:
print(f"❌ 已达最大重试次数({MAX_RETRIES}),总分 {total}/100")
return False
print(f"🔄 第{retries+1}次修正({total}/100)...")
issues = scores.get("issues", [])
# 将评分结果反馈给任务Agent,触发修正
fix_prompt = f"上次评分 {total}/100,需修复以下问题:\n" + "\n".join(f"- {i}" for i in issues)
# 任务Agent根据反馈修正
revised = call_task_agent(fix_prompt)
Path(task_output).write_text(revised)
return outcomes_loop(task_output, retries + 1)
if __name__ == "__main__":
outcomes_loop(sys.argv[1])
这段代码的核心思想:把一个LLM的输出交给另一个LLM独立审查,不通过就带着反馈回去改,直到通过为止。 30行逻辑,复现了 Outcomes 的精髓。
四、什么时候用 Outcomes,什么时候不用
✅ 适合用 Outcomes 的场景
| 场景 | 为什么适合 |
|---|---|
| 代码 PR Review | 检查项明确(测试、安全、风格),Rubric好写 |
| 文档/报告生成 | 可定义格式、完整性、准确性标准 |
| 数据分析报告 | 可以检查数据来源、计算正确性 |
| 翻译/本地化 | 术语一致性、格式保真度可量化 |
| PPT/演示文稿 | 页数、结构、数据标注有明确标准 |
❌ 不适合的场景
| 场景 | 为什么不适合 |
|---|---|
| 创意写作 | "好文章"的标准太主观,Rubric 难以量化 |
| 一次性任务 | 评分比任务本身还贵,不划算 |
| 实时交互 | 评分循环增加延迟,不适合聊天场景 |
| 极简任务 | 写个5行代码还要评分,过度工程化 |
一个实用的判断标准:如果任务花费超过 2 分钟,且你对质量有明确要求——用 Outcomes。如果任务几秒钟完成,人工扫一眼更快。
五、跟 Hermes Agent 的对比:殊途同归
有趣的是,Hermes Agent 在 v0.18.0 中也实现了类似机制——/goal 命令的自主验证。
两者的共通点:
- 独立验证:Hermes 的 /goal 让 Agent 在任务完成后对照 success criteria 逐项检查
- 自动重试:不通过就带着问题回去修正
- 可量化:都需要明确的"完成标准"
区别在于:Claude Outcomes 用单独的 Agent 实例做验证(隔离上下文),Hermes 的 /goal 是同一个 Agent 自检(共享上下文)。隔离版本理论上更客观,但成本也更高(多一次 API 调用)。
对于 AI 创业者来说:如果你的输出质量是核心卖点(比如做代运营、写付费报告),值得投入 Outcomes 的成本。如果只是内部自动化,Hermes 的 /goal 就够了。
总结:Outcomes 的深层启示
Outcomes 最大的价值不在于那 10% 的提升,而在于它证明了:
Agent 系统的瓶颈不在模型能力,在架构设计。
Anthropic 没有发布新模型,只用了一个评分循环,就能把同一模型的输出质量提升 10%。这说明我们之前把太多问题归咎于"模型不够好",而真正需要改进的是工作流的设计。
对于一人公司的 AI 创业者,这意味着:与其等下一个更强的模型,不如在现有工具上构建验证和反馈循环。一个 80 分的模型 + 10 分的架构改进 > 一个 90 分的模型。
数据来源:Anthropic Code with Claude 2026 官方发布(2026.5.6)+ SD Times 报道 + Totalum 生产实战指南
