上周，Martin Fowler 在 FOSE Europe 的演讲里，把 Harness Engineering 点名为 AI 时代的核心工程工作。
Fowler 提出了 Guide 和 Sensor 两个概念。Guide（前馈约束）告诉 Agent 怎么做，Sensor（反馈检测）告诉系统 Agent 什么时候走偏了，两者合在一起，构成 Agent 系统的骨架。他还补了一个的观察：Token 消耗量是架构质量的代理指标。Harness 越好，Agent 越省。
就在这两天，翁荔（Lilian Weng）在她的博客上发了一篇文章，圈子里一下就传开了。
她梳理了 35 篇关于 Agent harness 工程的论文，总结了 Harness 的各种模式，然后进一步提出，Harness Engineering 不只是让 Agent 更可靠，它是让 Agent 持续自我改进的基础设施。她梳理的论文涵盖 2023-2026 年的最新进展，包括 DGM、Hyperagents 这些。
最近这段时间，我的一个朋友不断跟我说，AlphaX 对未来软件开发方向的判断是：系统自动优化自己的代码和架构。
这三件事合起来，让我想把这个方向系统梳理一遍。
Fowler 说的是我们现在该怎么写好 Harness。翁荔说的是之后的事，Harness 本身怎么进化。她的文章是这篇的主要参考来源，我在这里用的论文地图也主要来自她的梳理。
这篇梳理进化搜索（Evolutionary Search）这个方向，为什么它是 Harness 的下一步，有哪些相关论文，工程挑战在哪里。
为什么下一步是进化搜索
神经网络参数可以梯度下降优化，因为损失函数对参数可微。你给出一个方向，参数就往那个方向走。
但 Harness 是代码，工作流是图，Skill 是文本，提示词是自然语言。这些都是离散空间，没有连续梯度，传统优化方法失效。你没办法对提示词求导，也没办法对工作流结构反向传播。
进化搜索不需要梯度。它只需要三件事。
| 要素 | 问题 | 在 Agent 语境下 |
|---|---|---|
| 表示 | 候选解长什么样 | 提示词 / 代码 diff / 工作流图 / skill 文件 |
| 变异 | 怎么生成新候选 | LLM 语义引导生成 / MCTS 搜索 / crossover |
| 选择 | 怎么筛选活下来的 | benchmark 分数 / 测试通过率 / 任务完成率 |
评估→选择→变异，循环往复。天然适配离散空间。
但光有三要素，还不足以解释为什么这批论文比传统遗传算法强出几个档次。
真正的质变在变异那一步。
传统遗传算法的变异是随机的，随机翻转 bit，随机交叉片段，完全不知道自己在改什么。LLM 的变异不一样，它是语义引导的有方向跳跃。模型理解什么有效，从而提出更可能有效的变体。不是盲目突变，是有判断的探索。
这是进化搜索在 AI 时代质变的根本原因。
论文全景地图
这个方向从 2023 年起步，2025-2026 年密集爆发。下面的论文地图主要参考翁荔的文章 Harness Engineering for Self-Improvement，我在她的框架上按进化深度重新排了层级，从浅到深分五层。
层级不是按发表年份，而是按「进化触及系统哪一层」。发表早的论文可以是更深的层级，发表晚的也可以是较浅的层级，取决于它在系统里动的是什么。
Level 1：提示词进化
Promptbreeder（2023，arXiv 2309.16797）
DeepMind 做的。最早把 LLM 用于进化搜索。
关键创新不只是进化提示词，而是 mutation-prompt 本身也被进化。不只进化答案，连怎么进化这件事也在进化。这是后来很多论文的起点。
Level 2：上下文 / Skill 进化
MCE（Multi-agent Collaborative Evolution，2026，arXiv 2601.21557）
进化 skill，也就是上下文管理策略。
结果是平均 +16.9%。这个数字的重要性不在于高低，而在于它说明：skill 文件本身就是可以进化的表示，不需要动代码，不需要重训模型，只需要找到更好的 skill 组合。
这是这批论文里离个人工程师实践最近的一篇。
Level 3：工作流 / Agent 设计进化
ADAS（2025，arXiv 2408.08435）
meta-agent 自动搜索 Agent 设计，候选解用代码表示。覆盖面最广，从单 Agent 到多 Agent 编排都能搜。
AFlow（2025，arXiv 2410.10762）
工作流表示为节点图，用 MCTS（蒙特卡洛树搜索）在图结构上做有方向搜索，而不是随机变异。
AFlow 和 ADAS 的差别在这里：ADAS 变异方向更随机，AFlow 的 MCTS 给了方向性。有方向的搜索通常比无方向的更快收敛。
Level 4：Harness 代码进化
这一层是目前结果最亮眼的，也是翁荔文章的重点区域。
AlphaEvolve（2025，arXiv 2506.13131）
Google DeepMind。进化代码 diff，让 Agent 自动改进自己的代码实现。
结果：打破了 Strassen 矩阵乘法算法 56 年的纪录。Strassen 算法是 1969 年提出的，之后 56 年没人在通用情况下做到更好。AlphaEvolve 用进化搜索做到了。
这件事的意义不只是 AI 在数学上超越人类，而是说明：在有明确评估标准的领域，进化搜索能探索到人类穷举不到的空间。
DGM / Darwin Gödel Machine（2025，arXiv 2505.22954）
这是和翁荔 harness 文章最直接相关的那篇。
DGM 进化的不是提示词，不是 skill，而是 Harness 代码本身。Agent 有权修改自己的 harness 代码库，把改动提交，评估结果，好的留下，差的丢掉。
结果：SWE-bench 从 20% 提升到约 50%。（⚠️ verified / lite / full 三个子集数字有差异，具体以原文为准。）
这是迄今最强的「Harness 自进化」实证。
ShinkaEvolve（2025，arXiv 2509.19349）
AlphaEvolve 的变体，改进了父代采样策略，加了 code-novelty rejection（过滤太相似的变体），提升了采样效率。工程细节层的改进。
ThetaEvolve（2025，arXiv 2511.23473）
进化 + RL + 上下文学习三者结合。探索混合优化路径，试图结合进化搜索的全局探索能力和 RL 的局部优化能力。
Level 5：改进机制进化（自指 / 递归）
这一层进化的不是代码或 skill，而是「如何进化」这件事本身。
STOP（2023，arXiv 2310.02304）
进化 scaffolding 代码，改进「改进器」本身。
这里有一个重要警示：STOP 发现，基础模型必须足够强才能启动。如果模型本身理解能力不够，变异会发散，越搜越差。这不只是 STOP 的问题，Level 4-5 的所有方法都有这个前提。
Hyperagents（2026，arXiv 2603.19461）
DGM 的扩展。进化「如何进化」的机制本身，并且让改进能够跨任务域迁移累积。
翁荔文章里专门梳理了这个方向，她的结论是：Hyperagents 是「meta-harness」思路的最新形态，核心问题从「写更好的 harness」变成了「写更好的 harness-writing 机制」。
层级汇总
| 层级 | 进化对象 | 代表论文 | 关键结果 | 个人可落地性 |
|---|---|---|---|---|
| Level 1 | 提示词 | Promptbreeder (2023) | 自进化 mutation-prompt | ⭐⭐⭐⭐⭐ 最易上手 |
| Level 2 | Skill / 上下文 | MCE (2026) | +16.9% | ⭐⭐⭐⭐ 不用动代码 |
| Level 3 | 工作流 / Agent 设计 | ADAS, AFlow (2025) | 自动搜索 Agent 编排 | ⭐⭐⭐ 需要评估器 |
| Level 4 | Harness 代码 | AlphaEvolve, DGM (2025) | SWE-bench 20%→约50% | ⭐⭐ 算力和评估门槛高 |
| Level 5 | 改进机制本身 | STOP (2023), Hyperagents (2026) | 进化「怎么进化」 | ⭐ 需要强底座模型 |
有一个规律贯穿所有层级：越深层，改动范围越大，收益越高，风险越大，评估越难设计。
真正的挑战不是变异，是评估
大多数介绍进化搜索的文章把重点放在变异算法上。哪种变异策略更好，LLM 怎么生成候选，MCTS 怎么引导方向。
这些很重要，但不是最难的部分。
最难的部分是评估器，而评估器的难点，其实是另一个问题。你的优化目标是开放问题，还是闭合问题？
我在另一篇文章《The Ops Inflection》里写过这个框架。闭合问题有明确的对错标准，可以自动验证，「代码通过率提高了吗」「benchmark 分数高了吗」，跑一下就知道。开放问题没有固定的对错，需要判断，「这个 harness 设计得好不好」「这个工作流优雅吗」，没法自动给分。
进化搜索只在闭合问题上工作。
你需要一个评估器，评估器的前提是能自动打分，自动打分的前提是问题已经闭合了。如果你的优化目标还是开放问题，评估器就没法建，进化搜索就跑不起来。
这也是 Fowler 那句「Token 消耗量是架构质量的代理指标」有意思的地方。「这个 harness 架构好不好」是开放问题，很难自动评估。但 Token 消耗量是可以测量的数字，他用这个数字把开放问题部分闭合了，变成「Token 少的 harness 比 Token 多的好」。这是一种工程取舍，不完美，但可以自动化。
进化搜索里的评估器也有同样的取舍。
评估器需要满足三个条件。可自动化，每次评估都要等人，搜索跑不起来。可信赖，benchmark 分数高了不等于真实业务好了，优化了分数有可能反而劣化实际表现。覆盖充分，测试套件稀疏，意味着进化在你看不到的地方漂移。
所以进化搜索适不适合，先问一个问题：你的目标，能不能闭合？
| 适合 | 不适合 | |
|---|---|---|
| 问题性质 | 闭合（有可自动验证的标准） | 开放（需要主观判断） |
| 示例 | 代码通过率、任务完成率、benchmark 分数 | 写作质量、设计优雅度、创意评估 |
| 搜索空间 | 大，手工探索不完 | 小，或已有明确最优 |
| 基础模型 | 足够强（STOP 的警示） | 弱模型上 Level 4-5 会发散 |
Level 4-5 对资源受限的工程师，目前主要是学习方向，不是直接落地的选项。但 Level 1-3 的方向，针对闭合问题，就有机会用上。
现在有哪些实际的例子？
AlphaEvolve（Google）
Strassen 算法只是其中一个。Google 内部还用 AlphaEvolve 优化芯片设计和数据中心冷却调度。这些不是 demo，是在跑生产的系统里做的优化。评估器是什么？芯片的功耗/面积比，数据中心的能耗。都是可以自动测量的数字，都是闭合问题。
DGM（开源可运行）
DGM 的代码是开源的，可以在自己的 SWE-bench 任务上跑。Level 4 这层不是非 Google 级资源不可，只是需要足够的 API 调用预算和一个可以自动评估的测试套件。
你现在的 Claude Code 工作流
如果你在用 Claude Code 写代码，让它跑测试，看哪里失败，再改，再跑，你其实已经在手动做一个进化搜索循环了。你是选择器，Claude 是变异器，测试套件是评估器。
进化搜索要做的事，是把你作为选择器这一步也自动化掉。
怎么和自己的 Agent 开发联系起来
如果你在构建 AI Agent 系统，进化搜索不是遥远的学术。很多基础设施你可能已经有了。
| 你已有的 | 对应进化搜索概念 |
|---|---|
| OpenSpec（稳定的 Spec 文件） | 天然评估锚点。Spec 不变，实现可进化，进化搜索的「选择」层就是你的 Spec 文件 |
| Files as Infrastructure（文件即历史） | 进化历史持久化。DGM 和 Meta-Harness 的文件系统设计思路和这个完全一致 |
| Skill 体系 | MCE 的同款表示。你的 skill 文件已经是可进化的形式，差的只是自动搜索那一步 |
| 测试套件 | 评估器的基础。有好的测试套件，你已经做了进化搜索最难的那步 |
这几件事里，评估器是最难建好的，也是最有价值的。一旦有了可信的自动化评估，进化搜索就有了起点。
我接下来想做的
我自己在用 OpenSpec + Superpowers 的框架做 Agent 开发，前段时间已经把 Harness 的思路加进来了，Guide 和 Sensor 都在。
看完这批论文之后，我发现差的那一步，是自动进化。我需要再想想怎么能结合起来，做好了，可能就有了我下一个 OpenSpec + Superpowers 的 Blog。