重新思考自进化 Agent：我们还需要预设优化流水线吗？

  核心发现：当优化器是 GPT-5.5 时，放开优化流程的编排权（OEO）在 14 个对比中 12 胜 1 平 1 负，且只用 34.3% 的 token 预算。但当优化器降到中等水平时，预设管线重新胜出。预设管线不是最佳实践，而是能力依赖的脚手架。

一个被忽视的设计选择

自进化 Agent 的研究爆发这两年，几乎所有系统都在做同一件事：框架预设优化流程。不管底层机制是 SkillOpt 的分阶段编辑管线，还是 GEPA 的反思式进化搜索，框架都替模型决定了"怎么收集证据、怎么诊断失败、怎么改、怎么停"。

微软研究院的这篇论文问了一个极其基础的问题：当优化器本身已经是 GPT-5.5 级别的前沿模型时，我们还需要替它规定优化流程吗？

图1：优化责任应该放在哪里？两种设计共享相同的外部优化合约，但流水线方式预设了任务特定的改进流程，而 OEO 让前沿优化器在线编排这个流程。

优化合约 vs. 优化元策略

论文的核心区分非常干净：

优化合约（Optimization Contract）：框架必须固定的外部约束——目标函数、允许的交互方式、资源预算、数据边界、评估标准。这些是治理层面的，不可让渡。

优化元策略（Optimization Meta-policy）：任务特定的优化逻辑——收集什么证据、诊断什么、怎么改、选哪个候选、什么时候停。

现有系统把两者都攥在框架手里。论文要验证的是：合约不变，只把元策略交给模型自己编排，行不行？

OEO：开放端优化

OEO（Open-Ended Optimization）的实现极其克制。它保留了合约中所有外部约束和允许的任务操作，但不预设反思模板、编辑语言、候选调度或任务特定的停止规则。优化器在每一步自己决定下一个动作：Inspect（查看）、RunTarget（运行目标模型）、Revise（提交修改）、Select（选择候选）、Stop（停止）。

换句话讲，OEO 就是给优化器一个 API 接口和一个预算，然后说：你自己看着办。

核心实验结果

GPT-5.5 作为优化器时，OEO 在 14 个 head-to-head 对比中拿下 12 胜 1 平 1 负（仅输 0.21 个百分点）。关键的是，它只用了 SkillOpt 配置 token 预算的中位数 34.3%。用更少的资源，拿到了更好的结果。

图2：GPT-5.5 驱动下 OEO vs SkillOpt vs GEPA 在各 benchmark 上的表现对比

但论文没止步于"OEO 更好"。它还跑了三个关键的控制实验：

第一，one-shot 零交互控制。给 GPT-5.5 同样的初始技能和静态信息，但不允许任何交互、只改一次。结果远不如 OEO——说明增益来自多步交互式优化，而不是单次先验驱动的重写。

第二，能力阶梯实验。当优化器从 GPT-5.5 降到 Qwen3.5-27B（中等）时，SkillOpt 反超 OEO；降到 Qwen3.5-4B（弱）时，OEO 甚至无法通过其接口正常运作。这说明委托优化有明确的能力边界。

第三，轨迹分析。在 OEO-SkillOpt 对比中，两者最终选择的技能在行为层面（pass/fail 一致率）和文本层面（Jaccard 距离）的差异不大，但优化路径差异显著。论文的措辞很精准：prescription 改变的是过程而非终点。

图3：OEO 与 SkillOpt 的轨迹对比——过程差异显著，但终点行为趋同

最大的启发

这篇论文最值得传播的不是"OEO 比 SkillOpt 好"——那个结果依赖 GPT-5.5 的能力水平。最大的洞察是它提出的框架视角：

预设管线不是"最佳实践"，而是能力依赖的脚手架。当优化器够强时，脚手架变成了限制；当优化器不够强时，脚手架不可或缺。这个判断标准不是方法论之争，而是能力匹配问题。

这对 Agent 设计有直接的指导意义：如果你用的是 frontier model 做优化器，考虑给模型更大的自主编排空间，而不是用流水线把它的每一步都框死。反过来，如果你用的是小模型做优化器，预设的管线就是必要的约束。

局限

实验范围集中在自然语言技能优化，target model 用的是 Qwen3.5-4B 和 Qwen3.5-27B。OEO 的能力边界是否适用于更复杂的 Agent 任务（如代码生成、多步骤推理优化），以及当 target 本身也是 frontier model 时结果是否变化，都有待验证。

总结

一篇问对了问题的论文。"需要预设流水线吗？"这个问题的答案不是简单的"是"或"否"，而是"取决于优化器的能力水平"。这个洞见比任何一个具体的 benchmark 结果都更有持久价值。