当 AI Agent 学会自我检验和做梦
Anthropic 在 Code with Claude 大会上发布 Outcomes（自我验证）和 Dreaming（自我学习）。Lance Martin 的 7 条推文 Thread 深度解读。
Magazine Article
Anthropic 发布了两个让 Agent "进化"的功能。它们解决的，恰好是 Agent 从 demo 走向生产系统时最令人头疼的两个问题。
问题：Agent 看起来做完了，但其实没做完
Lance Martin 是 Anthropic 的开发者布道师。在 Code with Claude 旧金山站，他和 Jess Yan 展示了 Outcomes：你写一份 rubric（评分标准），Agent 干完活后，系统自动启动一个独立的 grader agent——它和执行者完全隔离，只看成品和标准。不合格？打回去重做。循环有上限，你说了算。
The grader can't see the writer's reasoning and has no idea what shortcuts were taken.
"评分者看不到作者的推理过程，也不知道走了什么捷径。"
实战：一份研究报告的诞生与三次返工
官方 Cookbook 案例：Agent 写一份美国电动车快充经济性报告，要求 7 个主题全覆盖、所有引用必须可验证。
Pass 0 → 5/7
需求费用只写定性描述，没有 $/kW 数字；运营商业绩引用第三方新闻稿而非 SEC 原始文件。
Pass 1 → 6/7
Agent 找到 sec.gov 链接，但那是 8-K EX-99.1（新闻稿附件），不是 rubric 要求的 10-K 年报。评分者精确识别并退回。
Pass 2 → 7/7 ✓
Agent 找到 EDGAR 上 EVgo 的实际 10-K 文件。全部通过。
Both rejections happened because the rubric drew a line the grader could check.
"两次被拒都是因为评分标准画了一条评分者能够核实的线。"
写好评分标准比写好 Prompt 更难
Martin 的方法：让 Claude Code 帮你写评分标准。给他反馈和最终结果，它会拉取 session 日志自动更新。
| 原则 | 实操 |
|---|---|
| 每条标准必须可验证 | 不要说"覆盖需求费用"，要说"给出 $/kW 数字或运营成本百分比" |
| 让评分者"挣"到 pass | 要求具体证据（抓取的页面、追踪的公式、文件行号） |
| 描述目标而非步骤 | 不要规定具体命令，定义什么算证据 |
| 预判 Agent 的偷懒方式 | "不要用镜像站、转载或搜索摘要来佐证" |
| 明确忽略什么 | 不规定边界，评分者会在格式、风格上纠缠 |
Dreaming：Agent 之间的跨会话学习
Dreaming 解决的是"长期记忆退化"。后台进程定期扫描最近的会话，提取三类模式：反复犯的错、不同任务间收敛的工作流、跨 Agent 团队浮现的偏好。然后重写记忆存储——过时的压缩，关键的提升。
Memory lets each agent capture what it learns as it works. Dreaming refines that memory between sessions.
"记忆让 Agent 在工作中捕获学到的经验。Dreaming 在会话之间精炼这些记忆。"
Harvey 开启 Dreaming 后，任务完成率提升了约 6 倍。不改模型权重——更像是结构化的笔记整理。但效果说话：如果 Agent 不再重复犯第 11 次同样的错，谁在乎它叫"做梦"还是叫"定期记忆修剪"？
Anthropic 客户数据
- Harvey：Dreaming → 任务完成率 ~6x
- Netflix：多 Agent 编排 → 并行分析数百仓库构建日志
- Spiral by Every：Haiku 调度 + Opus 写作 + Outcomes 质量关卡
- Wisedocs：Outcomes → 审查速度提升 50%
- Anthropic 内部：Outcomes → 任务成功率 +10pts
质疑与风险
- 6x 数据缺乏外部基准：Harvey 是 Anthropic 发布的客户证言，无独立验证
- 记忆投毒风险：恶意输入可能被 Dreaming 固化到长期记忆
- "做梦"名过其实：本质是定时记忆修剪 + 模式提取，不改变模型权重
- 主观结果难评分：创造性任务的 Outcomes 标准难以量化
Socratic Dialogue
师生对话，逐步揭开 Agent 自我进化的核心洞察。
Personalized Insights
基于你的身份和工作场景，提炼最切合的发现。
1. Outcomes 本质就是 QA 测试用例
写评分标准（rubric）= 写测试用例——定义预期行为、设定 pass/fail 标准、覆盖边界条件。大多数开发者不擅长这个，但这是你的核心技能。
把 Outcomes rubric 当"Agent 测试用例"来写。从你已有的自动化测试中提取模式，翻译成 rubric。这可能也是技术自媒体的好素材。
2. Dreaming 解决的正是你日常遇到的跨 session 问题
你每天用多个 Agent（Claude Code、Codex、定时任务），它们独立运行不共享经验。你的 memory_append 和日记回顾机制已经是 Dreaming 的雏形。
评估你的 Agent 工作流中哪些反复出现的失败模式可以通过"定期回顾+记忆更新"来消除。考虑进一步结构化你的记忆系统。
3. 执行者/评分者隔离原则可以应用到你的代码审查
Outcomes 的核心设计是"执行者和评分者隔离"。写代码和审查代码应在不同上下文中进行。
在设计 code-review Agent 或自动化测试时，确保"生成"和"验证"在独立上下文中。不要让同一 Agent 既写代码又验证质量。
4. Anthropic 的战略：平台层 > 模型层
Managed Agents、Outcomes、Dreaming——这些不是模型能力，而是工程基础设施。OpenAI 和 Google 都还没整合到同一平台。
做 AI 产品时关注的不只是"用哪个模型"，而是"Agent 运行时基础设施"——记忆、验证、编排。这才是差异化。
5. 潜在风险：记忆投毒
恶意输入可能被 Dreaming 固化到长期记忆，应用到未来所有 session。
如果你实现自己的 Dreaming 机制，加上人工审核层——至少在早期。你的 memory 系统目前是即时写入的，可以考虑加"待审核"状态。
精选评论
来自 X 社区的高质量讨论。
@samzliu
我更倾向于把"做梦"看作一个"图书管理员" Agent，因为它做的事更接近策展和组织。而"做梦"更容易让人联想到模拟和世界建模，而不是记忆管理。
Instead of "dreaming" I like to think of sleep time compute tasks as a "librarian" agent since it gives better intuitions about what that agent is actually doing (curation, organization, etc.)
@SynabunAI
Dreaming 的跨会话整合是大多数 Agent 框架完全忽略的部分。它是按时效性、重要性分数来修剪，还是 Agent 自己通过 Outcomes 验证来决定？
Dreaming's cross-session consolidation is the part most agent frameworks skip entirely. Does it prune by recency, importance score, or something the agent itself surfaces through Outcomes verification?
@LeverageLoop
自我验证是 Agent 从 demo 走向生产系统的转折点。一旦产出可衡量，你终于可以调优可靠性、延迟和成本，而不是祈祷循环不出问题。
Self-verification is where agent demos start turning into production systems. Once outcomes are measurable, you can finally tune reliability, latency, and cost instead of just hoping the loop behaves.
@Utkarsh51557661
对自我验证持保留态度——结果可能是主观的。但自我学习听起来更有价值。
not into self-verification yet. seems tricky when outcomes can be subjective. self-learning sounds more valuable though.