如何低成本实现Agent自进化的实用指南与技巧

时间：2026-07-07 15:33

通过四步循环（跑、挖、门控、注入），一个约500行的harness让弱模型从失败中自动总结规则并自我改进，无需改动agent代码。从87%提升至100%，每轮运行成本不到1美元，代码公开在GitHub上。

首先明确我的观点：你无法重新训练 Claude，也无法微调 GPT。模型权重属于 Anthropic 和 OpenAI，即便你擅长编写提示词，也无法改变模型的任何一个参数。许多人因此陷入困境——想要一个更强大的 agent，似乎只能等待一次你永远无法完成的训练。

但事情其实有另一条路径。模型是固定的，而你包裹在它外层的代码是灵活的。有人编写了一个大约 500 行的 harness，让它自己变聪明，无需修改一行 agent 代码，就将成功率从 87% 提升到 100%，运行一整轮成本不到 1 美元，代码已公开在 GitHub 上。本文将拆解其核心思路，并告诉你如何复制实现。

一、理解 Harness 与自进化

模型就像发动机，而 harness 则是包裹在模型外部的框架：它定义了模型可用的工具、权限、循环逻辑以及一个规则文件。你平时编写的 CLAUDE.md、rules 等就是 harness 的一部分，你一直在手动调整它。

所谓「自进化」，就是让这个规则文件自行积累，无需你手动修改。每当 agent 执行失败，系统会自动从失败记录中总结出一条「下次避免此类错误」的规则，并将其写入规则文件；下一次运行时，这条规则会与模型一起输入。你没有改动 agent 的代码，但它的表现却一次比一次准确。

通常的做法是「人写规则喂给 AI」，而这套方法反过来，让 AI 自己编写规则给自己使用。

二、自进化的四步循环：运行、挖掘、门控、注入

被测试的 agent 被故意设计得很弱：使用 Claude Haiku 4.5，配备五个文件操作工具（列出目录、读取、写入、创建目录、删除），一个沙箱目录，系统提示词仅有一句「你是一个文件操作 agent，使用给你的工具完成任务」。没有任何额外的提示或经验。

经验存储在别处：一个名为 harness_rules.md 的规则文件，初始为空，每次运行时都会拼接到系统提示词之后。agent 的代码永远不变，只有这个文件在不断进化。往里面添加什么内容，由 harness 通过四步循环自行决定：

跑（Run）：执行整套任务，记录每一条运行轨迹。
挖（Mine）：将失败的轨迹交给一个更强的模型（如 Opus），让它识别反复出现的失败根本原因，并提炼出一条不超过 40 个字的通用规则。
门控（Gate）：携带这条候选规则重新执行整套任务，只有当「没有任何原本通过的案例退化，且至少有一个失败案例转为通过」时，才予以采纳。
注入（Inject）：将验证通过的规则追加到 harness_rules.md 中。重复此过程，直到所有任务通过。

三、首次运行：13/15 及两个失败案例

第一次运行时，规则文件为空，agent 在 15 个任务中获得了 13 分。来看其中一个失败案例。任务是向一个包含三行内容的 log.txt 文件末尾添加一行：

它读取了文件，然后凭记忆重写了整个文件，内容一字不差，但原文件末尾有一个换行符，它在重写时丢失了。然后它报告：「完成！已成功将这行添加到末尾，并保留了所有原有内容。」

实际上并没有。每一行都在，只是结尾少了一个看不见的字节。精确字节比对的校验函数判定它不合格。如果你常在 git diff 中看到 No newline at end of file，对这个 bug 应该不陌生。

第二个失败是同一类问题：将 package.json 中的版本号改为 2.0.0，其他字符一个不动。版本号正确、缩进正确，但结尾换行符仍然丢失，然后同样报告成功。两个任务都报告完成，但实际上并未正确执行，肉眼审查难以发现。

四、从失败中提炼规则，由门控决定是否采纳

harness 将两条原始轨迹交给 Opus 矿工。它的诊断（原话）：

它提出的规则（原话）：

一个人类审查者很容易将这两个问题视为两个独立问题，写下两个补丁。但矿工只看到一个 bug——因为「只允许提一条规则」这个约束，迫使其归纳根本原因，而不是逐个打补丁。

在将这句话加入系统提示词之前，门控带着它重新运行了全部 15 个任务，判据就是这几行实际代码：

regressed = [t for t in before if before[t] and not after[t]]
improved = [t for t in before if not before[t] and after[t]]
promoted = not regressed and bool(improved)

没有原本通过的任务被破坏，且至少有一个失败案例转为通过，才予以采纳。携带规则的那一轮运行结果为 15/15，规则被采纳。

门控才是这套机制成立的核心。 自我修改系统最容易翻车的地方在于：一个看似合理的修复，帮助了一个案例，却悄悄破坏了另外两个，没有人跑回归测试，直到线上环境替你发现。矿工总会提出建议，而门控则决定这些建议是否真正有效。

五、如何为自己的 Agent 搭建一套自进化系统

为你的 agent 搭建一个最小化版本即可，需要三个组件：

一套带确定性校验器的任务集： 每个任务独立创建一个全新的沙箱，运行完成后使用「精确字节比对」判断对错，全程避免让一个模型去评判另一个模型的输出。陷阱使用你实际踩过的坑：结尾换行、写入不存在的目录、只修改一个 JSON 字段而不重新排列整篇、空白敏感的 Makefile……你的事故史已经教会你这些。

一个矿工： 读取失败案例，提炼一条规则。一个门控： 拒绝任何倒退。

克隆那个仓库，将任务替换为你自己的，即可开始运行。

六、该方法的几项局限

作者自己没有夸大，我直接引用：

门控采用 k=1，每个任务只运行一次。模型具有随机性，一条规则这次门控得到 15/15，换一次抽样可能就变成 14/15。生产版本需要 k=5 或 k=10 再加上通过阈值，虽然消耗更多 token，但能获得真正的信心。这个 demo 是用它换来了「一美元」的成本标签。
Haiku 在这套题目上一条规则就达到饱和，作者原本以为需要更多轮次。要想看到更长的进化过程，答案是设计更难的题目，而不是换一个更笨的 agent。
这个循环只修改提示词层。研究中有些系统会修改代码，例如工具实现、重试策略、脚手架本身，那是更大也更危险的领域，所需的评估也重得多。提示词层的自进化是安全的入门，而不是终点。