读:EvoForge——用群体进化优化 AI Agent
优化 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"。它用群体进化代替手动调参,用语义分析代替盲目试错,用知识共享代替重复踩坑。真正的突破不在模型,而在流程设计。