优化 AI Agent 的时候，你是在手动调 prompt 和参数吗？如果答案是"是"，那你的优化方式可能已经落后了。
有一组反直觉的数据：在一个叫 EvoForge 的开源系统上，GPT-5-nano（一个相对轻量的模型）跑出了 Codex CLI 2 倍的性能，是对照 baseline 的 10 倍。靠的是更聪明的优化流程，而不是更强的模型。
这说明真正的瓶颈不在模型本身，在"如何组织优化过程"。
（本文基于 jdon.com 上关于 EvoForge 的介绍，提取通用原则。原文篇幅较长，我从 EvoForge 的设计中看到了几个对任何 AI 开发者都有启发的思路。）
手动调参的陷阱
手动优化单 agent 有两个很难绕开的坑。
局部最优。 改一个 prompt、调一个参数，效果好了就留下来，但你可能只是在附近的小坡上反复横跳。真正的更优解在别处，手动搜索效率太低，很难跳出去。
重复踩坑。 你修好了一个 bug，过几周又犯了同样的错。没有系统性的机制把"失败经验"沉淀下来，每一轮都在重复交学费。
这两个问题的根因是同一个：手动优化本质上是单点搜索，没有结构化的探索和记忆机制。
EvoForge 的思路：群体进化
EvoForge 的策略很简单：一个人反复刷题不如一整个班同时刷题、互相抄作业、总结错题、再进化下一轮。
具体来说，每一代会做以下几件事：
- 变异 ：在当前最佳 agent 的基础上，生成多个变体（population）
- 并行测试 ：每个变体独立跑 benchmark，输出 0.0 到 1.0 的分数
- 失败分析 ：对每个变体的行为轨迹做语义分析，定位具体的失败点
- 知识共享 ：汇总所有变体的失败模式，提取共性问题，写入共享知识库
- 继承 ：下一代 agent 继承这些知识，避免重复同样的错误
这五步形成一个闭环，不断重复。
关键突破不在"进化"这个词本身，而在"知识在群体中传播"。每一代不是从零开始，而是带着前一代的经验继续前进。
反向直觉的设计：没有 agent 被淘汰
很多人以为进化算法就是"强者留下，弱者淘汰"。但 EvoForge 做了一个相反的设计：没有 agent 被抛弃，整个群体一起变强。
这是怎么做到的？
每一轮结束后，系统不是只保留最优 agent，而是汇总所有 agent 的失败模式，统一归纳错误类型，给出修复方向，写入共享知识库。下一代所有 agent 继承这些经验。
结果就是：哪怕某个 agent 本身很弱，它也不会一直弱，因为它继承了集体智慧。
这和单点优化形成了鲜明对比。单 agent 的问题是：你犯过的错，下次还可能再犯。而 EvoForge 的逻辑是：一个人踩坑，全体绕坑。
三层分离的设计哲学
EvoForge 还有一个设计：它把"代码逻辑"和"进化策略"彻底分开了。
系统核心由三个文件驱动：
evolve.md：定义进化规则（群体规模、选择策略、变异方式）program.md：定义 meta-agent，它负责修改 agent 本身agent.py：真正被优化的 agent 对象
人类不直接写 agent，而是写"如何进化 agent"。这个抽象层级比普通 prompt engineering 已经高了一层。
语义可观测性：知道为什么失败
AI 优化中最难的地方是：你根本不知道 agent 为什么失败。
EvoForge 引入了 Semantic Observability（语义可观测性），强制做"失败解剖"：
- 分阶段分析 agent 行为
- 找出具体的错误决策点
- 解释为什么失败
- 输出结构化的分析结果
这一步把"感觉不行"变成了"具体哪里不行"。没有这一步，进化就变成了盲目试错。
对 AI 开发者的启示
EvoForge 是一个具体的工具，但它的设计思路对所有 AI 开发者都有参考价值。
手动调 prompt 最大的问题是不可追溯、不可复现。如果你能把自己的优化过程拆成"生成变体→测试→分析→总结→迭代"的循环，哪怕不用 EvoForge，效率也会提升。
修好一个 bug 不叫优化，把 bug 的分析结果写进"共享知识库"才叫优化。对我来说，这意味着在 Claude Code 的使用中，每次失败的对话都应该被记录和分析，而不是用完就丢。
还有一点：GPT-5-nano + EvoForge 能跑赢 Codex CLI，说明流程的优化空间可能比模型升级更大。在追求更强模型之前，先问问自己：优化流程本身是不是已经最优了？
总结
EvoForge 不是在优化 agent，而是在优化"如何产生 agent"。它用群体进化代替手动调参，用语义分析代替盲目试错，用知识共享代替重复踩坑。真正的突破不在模型，而在流程设计。