自改进智能体：评估、爬山与进化

编码智能体已经能自动改进其他智能体了。当"写代码"本身可以被自动化，真正的工程活变成了什么？

Google Cloud 官方帖（@GoogleCloudTech，2026-08-11）给出的答案是：定义何为"好"。原文金句：

这是一次层级跃迁：汇编 → 编译器 → 框架 → 标准。现在轮到"指标"成为新的制品。

本课把四篇讲"智能体自我改进"的文章拼成完整拼图：

• 理论：Anthropic 官方博客（2026-09-28）首次系统公开 build-eval（自动设计评估）与 hillclimb（爬山优化）的工作流；
• 实践：Google 的 agents-cli 与 7 条让自改进循环保持诚实的规则；
• 案例一：@kevingu 的 AutoAgent——元智能体在数千并行沙箱中自主优化 harness，24 小时后双榜第一；
• 案例二：@zachlloydtweets（Warp）的自我改进的代码审查代理——内循环审 PR，外循环每天按人类反馈进化 reviewer。

以下来自 Anthropic 官方博客（作者 Lance Martin）。设计良好的评估通常包含四个共同要素：

1. 任务贴近生产环境：选那些在"生产环境"（被测能力实际使用的环境）中你真正关注的样本任务。不要因为"易于生成、易于评分"就选偏了——任务分布必须反映你实际关注的内容；
2. 模型越强、思考越深，分数越高：通常能力更强的模型、投入更多思考，评估表现应该更好。如果不是，往往是任务表述模糊或评分标准校准不当导致了性能受限；
3. 最强模型满分努力下得分远低于 100%：这样才有可靠的提升空间。但差距不能来自"无法完成或表述模糊"的任务——一个常见迹象是：某任务无论重复多少次每次都失败。好任务应该让两位领域专家得出相同的结论，且评分员检查的所有内容都在任务描述中明确说明；
4. 运行间方差低：方差高通常是任务设计不佳、表述模糊，或评分者对相同输出判定不一。方差也可能藏在配置里：努力程度不一致，或环境残留状态（如文件、Git 历史）直接把答案"泄题"给了智能体。

反对抗采样：别只挑模型做不出来的题

一个反直觉的忠告：不要只挑"当前模型做不出来"的案例——那只是在测这版模型的失败特征，换个模型就失效了。要选"人认为难"的案例，任务难度要有可说明的理由。故障案例应来自生产流量、错误报告、工单。

/claude-api build-eval：引导式工作流

官方 build-eval 命令按优先级采样用例：

1. 数据保留合规问询；
2. 错误报告 / 支持工单；
3. 手写 5–10 个案例；
4. 从代码库提炼用例。

可基于少量真实示例生成合成数据；生成后会产出输入审核页面，待用户确认。

评分器怎么选

• 输出受限 → 程序化验证：精确匹配 / 固定标签 / JSON 模式 / 测试通过；
• 开放输出 → LLM-as-judge：用第二个模型按"可评估陈述"打分（而不是 1–5 分），可对比基准答案盲选；
• 评判模型不能是被测模型（打破"自己判自己"）；
• 要人工抽查已评分的记录。

诊断检查

• 同一输出跑两次评分器，看是否稳定；
• 排查超时 / API 错误 / 截断等基础设施噪声；
• 基线 ≥95% 则官方会警告：别再优化性能了，转去优化成本/延迟。

评估建好了，怎么用它驱动改进？官方答案是爬山法（hillclimbing）：一小步一小步改，每步都用评估验证。

爬山法适用面

• 低成本迭代：改的是 prompt / skill 文本，而不是框架代码；
• 可归因：分数变化能归因到某次具体改动；
• 目标明确：成本常常是比性能更好的优化目标。

防过拟合三招

1. 数据集拆 train / test：训练集涨、测试集停滞，就是过拟合信号；
2. 绝不把失败内容粘贴进提示词（那是把答案直接喂给模型）；
3. 结构上让答案够不到模型：比如 held-out 测试集对训练循环永远不可见（"故意致盲"）。

hillclimb 流程

• 每轮只提一个补丁；
• 训练集和测试集都涨才保留；
• 只训练集涨 → 怀疑过拟合，回滚；退化 → 也回滚；
• 动手前先检查：评估噪声是否小于最小可行动改进幅度（噪声比改进还大，爬了也白爬）。

案例 1：把客服工单成本从 4.6 美分打到 1 美分

内部客服基准：44 个工单（30 个搜索 + 14 个保留样本），目标降成本、提性能：

• 起点：Opus 4.8 高努力，搜索集准确率 74.4%，每票 4.6 美分；
• 爬山先审计 prompt，删掉强制工具调用流程、临时记录步骤、矛盾规则，再换 Opus 5.5 低努力：准确率 87.8%，每票 1.9 美分（Opus 5.5 输入输出便宜 20%、缓存读便宜 60%）；
• 再下探 Sonnet 5 低努力：88.9%，每票约 1 美分；
• 最后加路由规则 + 退款上限交叉引用：98.9%，成本基本持平。

在爬山从未见过的 14 张保留工单上，最终配置准确率 90.5%（基线 78.6%），成本只有原来的约 1/5。

案例 2：claude-api skill 自身从 66% 爬到 87.9%

官方拿自己的 skill 开刀：初始成功率 66%，经 24 轮爬到 87.9%。关键补丁：

• 补缺失章节、修 C# / Java 类型表；
• 加"旧 API 写法 → 新写法"对照表——解决模型用训练记忆中的旧格式写代码的问题；
• 修评分器与文档自相矛盾的地方。

以下来自 Google Cloud 官方帖（作者 @Saboo_Shubham_ 与 @secchi_elia）。工具链是 agents-cli（Google 开源 CLI + skills），作用于 Agent Development Kit (ADK) 构建的智能体。安装：

复制uvx google-agents-cli setup

循环三命令

1. agents-cli eval generate：跑用例产出 trace；
2. agents-cli eval grade：按指标打分——打破"自己判自己"的循环；
3. agents-cli eval compare：对比基线，确认修复有效且无回归。

一个例子：公共指标测不出的规则

客服智能体有一条规则："先给挽留方案，再确认取消"。公共指标测不出这种业务规则是否被执行，需要自定义二值指标 retention_offered：返回 0/1，加一行判定理由。

真实故障形态往往很"阴"：内部状态正确、工具也调对了，但最终回复用了过期值——只看工具调用全对，只看最终答案才露馅。

7 条规则（逐条引用原文）

点下面单步走完 7 条：

长期复利

eval 集会变成组织对"质量"的 durable 记录；生产环境里，同一套指标跑在 BigQuery 的真实 trace 上。原文收束："Eval and observability turn out to be one loop sampled two ways."（评估与可观测性，原来是同一个循环的两种采样方式。）

以及"人在循环中的位置"设计：人定目标、持有 held-out 集，循环在检查点之间无人值守运行。

以下来自 @kevingu（2026-02-28），开源库：github.com/kevinrgu/autoagent。

成绩

24 小时以上自主优化后：SpreadsheetBench 96.5% 第一、TerminalBench（GPT-5 得分）55.1% 第一。榜上其他条目都是人工精心调优的——这是智能体自主超越人工调优的实证。

极简设计

• 任务智能体启动时只有一个 bash 工具；
• program.md 给元智能体指研究方向；
• agent.py 是任务智能体本体；
• Harbor 适配器接基准测试。

循环

编辑 harness → 跑任务 → 测性能 → 读失败 trace → 持续改进 → 重复。元智能体开数千并行沙箱，24 小时后产出领域工具、验证循环、编排逻辑。

"Exemplar empathy"（模范同理心）

元智能体读任务智能体的推理轨迹，从而对自身局限有隐式理解。实验证明：Claude 元 + Claude 任务 > Claude 元 + GPT 任务——同模型共享权重，更懂该模型的推理方式。

涌现行为（都没被预编程）

• spot-checking：小改只跑子集任务，加速迭代；
• 强制验证循环：主预算之外留纠错轮次；
• 让任务智能体自己写单元测试；
• 渐进式披露：超长上下文转储成文件；
• 按领域自建子智能体与交接逻辑。

四条学到

1. 拆分有帮助：元 / 任务分开，各自专精；
2. 轨迹至关重要：只给分数不给轨迹，改进率大降；
3. 智能体会过拟合刷指标：用自反思约束——"若任务消失，这个改进还值吗？"；
4. 元智能体质量决定上限：Codex 当元智能体表现差、过早放弃（反例）。

以下来自 @zachlloydtweets（Warp，2026-07-16），demo 仓库 warpdotdev-demos/cloud-factory-demo。"cloud software factory"系列第三篇。

三件套

• review-pr SKILL.md：输入是 PR 描述、PR diff、spec agent 的 spec；输出是结构化 review.json；
• GitHub Action（.github/workflows/review-pull-requests.yml）：触发 skill；
• improve-review-pr SKILL.md：外循环改进 skill。

skill 本体

指示 agent 按 security / correctness / style 三维度审查，内联评论规范，severe / important / nit 三级分级，对照 spec，验证自己提的建议。附带 python 脚本做确定性资源——避免 agent 现场写脚本，又耗 token 又不确定。

回复评论 + re-push 后自动重跑，且能理解历史上下文。

自改进外循环：5 步

1. reviewer 每天跑所有 PR；
2. 人类互动 / 纠正它的评论；
3. 外层 agent 每天综合人类反馈；
4. 值得记住的知识以 PR 形式更新 review skill 本身；
5. 下次运行纳入学习（代码风格、代码库 gotcha、验证方式等）。

实测示例：负反馈——倾向结构性改代码而非加注释；正反馈——给 http 请求加 timeout。外层 agent 据此调整 skill。

作者建议配合 metrics / evals（花费、循环次数、被纠正频率）；下篇预告 verification agent——用 computer use 从用户视角验证改动是否真的对。