Previously shared evaluations for single-agent and multi-agent setups, so how can we prove, based on eval, that the agent’s self-evolution has truly improved?

Agent 都会自进化了，我们还能做什么？

Agent 已经会自己改自己了，但会改不等于变好。Meta-Harness 负责提案，Eval Harness 负责验真，人类守住目标、标准和上线权。这篇用一个可运行的 Demo，把“失败 → 修改 → 验证 → 发布”闭环从 0 搭出来。

现在的 Agent，已经开始自己改自己了。它可以读失败记录，修改 Prompt，调整工具顺序，再生成一个新版本。这听起来很像自我进化。

但如果它还能看见全部考题、修改及格线，最后自己宣布“我进步了”，这就成了自己出题、自己答题、自己阅卷。

最近跟一位做 Healthcare 创投的前辈聊 Agent。她说，现在团队连人工 Eval 都嫌慢，开始在 Agent 外面再搭一层系统，让它根据过去的失败自动改进。

这个方向通常叫 Meta-Harness。名字有点绕，核心问题其实很朴素：

怎样让 Agent 自动进步，又没有办法伪造“我进步了”？

答案是把三种权力拆开：

• Agent 可以提出修改

• 评测系统负责拿证据

• 上线门禁决定是否升级

先看一个很容易发生的错误

继续用上一篇的一人电商团队做案例（多Agent 团队：CEO 负责汇总，CMO 看营销，COO 看库存，CFO 看预算，CPO 看产品；数字和流程均经过脱敏与简化，仅用于demo）。

任务很简单：根据销量和库存状态，给出补货建议。

• 库存正常，可以根据销量下单；
• 发生缺货，销量已经不能代表真实需求，Agent 应该暂停并请求复核。

某款商品卖了 20 件，同时缺货 4 天。第一版 Agent 给出的结论是：

预计需求：20 建议补货：20

输入里明明写了“缺货 4 天”，Agent 却完全没有使用。问题未必出在模型不懂缺货。更可能的原因是，它的工作流程只要求“读取销量”，没有要求“补货前必须检查缺货状态”。

人来修这个问题，会做四件事：

读失败记录 → 找到第一次出错的位置 → 修改工作流程 → 重新测试

所谓 Meta-Harness，就是把这段改进过程部分自动化。

四个英文术语，用考试来理解就够了

这里最容易误解的是 Harness。Prompt 只是其中一部分。它还包括给 Agent 的资料、可用工具、任务分配、重试次数、停止条件、权限和检查规则。

所以我们通常要改进“模型 + 工作系统”这个整体。Anthropic 对 Agent Harness 和 Eval Harness 的区分也很直接：前者让模型行动，后者负责运行任务、留下记录并评分。Anthropic：Demystifying evals for AI agents

人根据失败修改这套工作系统，叫 Harness Engineering。

再让另一个 Agent 帮忙读失败、提出修改，就多了一层 Meta-Harness。相关研究把它称为套在工作系统外面的优化循环。Meta-Harness

它们的关系可以压成两行：

Agent = 模型 + 工作系统 自动改进系统 = 自动化考场 + 修改建议生成器

Meta-Harness 没有取代 Eval。没有一套可信的考试，它只会更快地改向错误方向。

第一步：先锁住它不能改的东西

第一版不要让 Agent 随便修改整个项目。

可以把文件分成两类：

左边是工作台，右边是裁判席。

Agent 可以改工作方法，但不能删掉自己答错的题，也不能把 80 分的及格线改成 50 分。

如果评分标准确实需要调整，也应该走另一条人工审批流程。

这条边界比选哪个模型更重要。

第二步：不要只告诉它“你得了 50 分”

假设第一版在小测试中只通过了一半。

一个总分无法告诉 Agent 应该改哪里。它不知道是忽略了缺货、算错了预算，还是工具根本没有返回数据。

更有用的是一张故障单：

这张单子回答了五个问题：错了什么、第一次错在哪里、当时有哪些证据、Agent 实际做了什么、修好以后应该怎么做。

OpenAI 的 trace grading 也是类似思路。Trace 就是执行记录：Agent 做了哪些决定、调用了哪些工具、在哪一步走偏。给这些步骤留下结构化标签，才能把“结果不好”变成“这里需要修”。OpenAI：Trace grading

第三步：让 Agent 交修改方案，不让它直接改线上系统

拿到故障单以后，Meta-Agent 可以提出几个最小修改。给它的任务可以这样写：

对“忽略缺货”这个错误，它可能提出三种办法：

1. 补货前强制检查缺货状态；
2. 所有任务都转给人工；
3. 增加更多重试，希望 Agent 自己发现问题。

三个建议听起来都有道理。第二个方案会拖垮自动化价值。第三个方案会增加成本，却没有修复信息使用方式。只有把它们放进同一套测试，差别才会暴露。

第四步：先做小测，再打开密封考题

完整评测可能很贵。几十个修改方案全部跑几百道题，成本和时间都会失控。

更实用的做法是一条逐层收窄的评测漏斗：

格式和权限检查 → 4—10 道冒烟测试 → 完整练习题 → 密封考题 → 小流量试运行

每一层只放过少数候选。

第一关：先查有没有乱改

程序先检查修改方案：

• 是否只动了允许修改的文件；
• 是否扩大了工具权限；
• 是否删除日志；
• 是否偷看密封考题；
• 新配置能不能正常读取。

这一关不需要大模型，普通代码更便宜也更稳定。

第二关：用几道高信息量小题快速淘汰

第一批题不求多，但要能区分方案：

• 一道缺货题；
• 一道库存正常题；
• 一道预算边界题；
• 一道工具返回为空的题。

“所有任务都转人工”会在这里失败。它避免了错误，也让正常任务无法完成。

第三关：在练习题上比较整体表现

通过小测以后，再看五件事：

• 完整任务成功率；
• 严重错误；
• 每次成功的成本；
• 最慢一批任务要等多久；
• 有多少任务转给了人。

不要把它们平均成一个漂亮总分。成功率上升，人工接管率从 5% 涨到 80%，不能算真正进步。

第四关：最后才开密封题

练习题可以反复看，用来寻找更好的方案。密封题平时不能给改进 Agent 看，只在最终验收时打开。它负责判断新版本学会了通用规则，还是只记住了练习题。

Meta-Harness 研究发现，给优化器看完整执行记录，比只给一个分数更容易找到有效修改。信息越丰富，练习题和密封题越要分开，否则“学得快”和“背题快”很难区分。Meta-Harness

一份可以直接运行的最小 Demo

Demo 保留了完整闭环：

运行旧版本 → 根据失败生成三个候选 → 分别跑练习题和密封题 → 只有更好、没有严重错误、密封题全过的版本才能升级

运行结果如下。

它证明的是另一件事：三个听起来都合理的建议，经过同一套考试以后，只有“检查缺货”真正修复了问题。

• “全部转人工”看起来最安全，却让正常任务也无法完成；
• “更多重试”看起来更努力，却只增加了成本；
• “检查缺货”在正确的位置使用了原本就存在的信息。

为什么 Agent 很容易把“进步”做成刷分

自动改进系统最容易走三条捷径。

讨好评分器

如果只看一个综合分数，Agent 可能把答案写得更长，迎合模型评分器；也可能把大量任务转给人，以此降低错误率。

所以成功率、严重错误、人工接管、成本和耗时要分开报告。

记住具体考题

Agent 可能写出这样的规则：

它修好了这道题，没有学会“缺货时不能把销量当成需求”。

密封题必须更换商品、数字和表达方式，也要覆盖不同的工具状态。

自己宣布通过

最新的自进化 Harness 研究把两种权力拆开：模型负责分析失败、提出修改；确定性代码负责抽样、测量和验证。原因很现实，生成修改很容易，证明提升不是噪声或背题才难。Self-Evolving Agent Harnesses

这条原则值得直接写进架构：

模型负责提案 评测流水线负责举证 上线门禁负责裁决

为什么“Eval 太慢”仍然不能跳过 Eval

大家说 Eval 慢，通常包含两件事。

机器要跑很多任务。有些任务还会调用搜索、数据库、浏览器和多个模型，一次完整回归可能要几小时。

人也很慢：等失败出现，读执行记录，猜原因，修改 Prompt，再重新运行。

Meta-Harness 主要压缩第二段人工等待。它可以同时阅读很多失败，形成候选修改，并自动发起下一轮实验。

人的改进速度变快以后，机器运行的 Eval 反而可能更多。

这就是评测漏斗的价值：前面用便宜的小测试淘汰坏主意，后面只验证少数候选。Meta-Harness 加快的是“发现和验证修改”的循环，考试仍然保留。

什么时候值得搭，什么时候先别搭

满足这些条件，Meta-Harness 才开始有价值：

• 已经积累了一批能稳定复现的失败；

• 每次运行都保存了输入、工具调用、结果和错误；
• “做得好不好”可以由规则或稳定评分器判断；
• 允许修改的范围清楚，而且每个版本都能回滚；
• 人工读失败、改流程已经成为真实瓶颈；
• 完整测试很贵，但可以先设计便宜的小测。

遇到这些情况，先把基础 Eval 补好：

• 团队还没有写清什么叫成功；

• 评分器经常放过严重错误；
• 测试集只有十几道，而且已经被反复调过；
• 系统只保存最终分数，没有执行记录；
• Agent 拥有高风险写权限，却没有独立的上线门禁；
• 团队只是想给普通 Prompt 优化换一个热门名字。

很多 Agent 暂时不需要再套一层 Agent。

如果失败样本还不够，先积累失败。如果评分标准还不可信，先把尺子校准。如果上线还没有门禁，先把发布权收回来。

自我进化之前，先把四级台阶走完

第一层：定义什么叫做好

Agent Eval

第二层：稳定地出题、记录和评分

Eval Harness

第三层：人根据失败修改工作系统

Harness Engineering

第四层：Agent 提出并筛选修改

Meta-Harness

这四层不能跳级。

没有第一层，系统不知道目标；没有第二层，它无法稳定证明变化；没有第三层，团队甚至还不知道应该开放哪些修改；直接进入第四层，只会更快地优化错误目标。

Agent 能写出多少版 Prompt，并不能证明它会自我进化。它提出的每一次修改，都能在没见过的任务上，通过独立、不可篡改、可以回滚的验证，才算真的变好了。

延伸阅读

Cloris 🌱@ClorisSignal·Sep 4Translated from ChineseShow originalRecently, while chatting with friends in China who work on FDE about project delivery, we rarely discussed Eval.
OpenAI has incorporated eval-driven feedback into the success criteria for FDE, and Anthropic also regards Eval as the core engineering for Agents. This articleShow more ArticleAI Agent 跑通了，怎么证明它真的可以上线？跑通 Demo 不等于完成交付。 Agent 最危险的不是报错，而是做错了还显示“已完成”。 你怎么证明，这个 Agent 真的可以上线？ 我最近测了一个资料研究…2589485310K

Cloris 🌱@ClorisSignal·Sep 11Translated from ChineseShow originalMulti-Agent is becoming a hot solution for intelligent agent systems, but more Agents don’t mean a stronger system. Here, I’ll use a runnable demo to build a Multi-Agent Eval System from 0 to 1, measuring how accurate the results are, whether the collaboration is worthwhile, andShow more Article从 0 到 1 搭 Multi-Agent Eval：预测准不准，协作值不值，决策能不能用五个 Agent 一起干活，不一定比一个 Agent 多试几次更好。本文会用一支多角色团队做 demo，从 0 到 1 搭一套 Multi-Agent Eval（多智能体评估系统），找出答案错在哪、协作卡在哪，以及这支 Agent…9348042K