Rethinking Self-Evolving Agents: Do We Still Need Prescribed Optimization Pipelines? 精读

论文链接：arxiv.org/abs/2608.09629 发表时间：2026年8月 机构：Hui Xue, Fan Yang（独立研究者） 领域标签：Self-Evolving Agents, Prompt Optimization, LLM as Optimizer

一、论文背景

1.1 什么是"自进化 Agent"？

过去两年，大语言模型（LLM）从"被动回答问题的工具"快速进化为"能自主完成多步任务的行动主体"。在这个过程中，一个新概念走上了舞台中心——自进化 Agent（Self-Evolving Agent）。

所谓"自进化"，通俗地讲，就是 Agent 不仅能够完成任务，还能根据自身执行任务的反馈，自主修改自己的"操作手册"或"行为策略"，从而在下一次任务中表现更好。这相当于一个员工不仅能干活，还能自己给自己改岗位手册——干完活之后反思一下哪里做得不对，把流程改一改，下次干得更好。

更形式化一点说，自进化 Agent 通常围绕一个优化闭环构建：

1. 用当前策略执行一批任务
2. 收集执行轨迹和评分
3. 根据反馈分析哪里需要改
4. 修改策略（通常是修改上下文中的一段自然语言文档）
5. 验证修改是否真的更好
6. 回到第 1 步，循环

这个闭环和深度学习中的训练循环非常相似——只不过深度学习训练的是"权重"，自进化 Agent 训练的通常是"上下文中的自然语言策略"。

1.2 什么是"预设优化流水线"？

要理解这篇论文批判的对象，需要先理解什么叫"预设优化流水线"。

类比：工厂流水线。想象一条汽车装配流水线：第一站焊车身，第二站装发动机，第三站装车门，第四站喷漆，第五站检测。每个工位的工序、顺序、操作内容、停止条件都是事先由工程师设计好的。流水线上的工件（汽车）只能严格按这条路线走，不能跳过任何一站，也不能改变顺序。

自进化 Agent 领域的"预设优化流水线"也是这种结构——研究者事先设计好一套固定的优化流程，包括：

• 如何收集证据：执行多少任务？收集哪些信息？
• 如何反思分析：用什么样的提示让优化器分析轨迹？
• 如何修改制品：每次允许修改多少？是整体替换还是局部编辑？
• 如何选择候选：维护一个种群还是一个点？怎么比较优劣？
• 何时停止：迭代多少轮？还是连续多少次不提升就停？

比如我们前面精读过的 SkillOpt，就是典型的预设流水线：它把优化过程切分为"前向传播（执行）→反向传播（反思）→有界更新（文本学习率约束）→验证门控→Epoch 级慢/元更新"五个固定阶段，每个阶段做什么、何时做、以什么粒度做，都是框架事先规定好的。

再比如 GEPA，也是预设流水线：它规定了"维护种群 → 反思式生成语言反馈 → Pareto 前沿选择 → 进化迭代"的固定流程。

1.3 预设流水线曾经为什么是必要的？

在模型能力不那么强的时候，预设流水线几乎是唯一可行的选择。原因有三：

（1）模型自己规划不好优化过程

中等或较弱的模型面对"给你一批执行轨迹，你自己想办法改进策略"这种开放式任务时，往往会迷失。它们可能抓不住关键问题，可能一次修改幅度过大把好的内容删掉，可能不知道什么时候该停。预设流水线相当于给模型配了一套详细的操作 SOP，让模型只需要在每个工位上做局部决策。

（2）工程上的可复现性

如果让模型自由发挥，每次跑的结果可能天差地别。预设流水线把流程固定下来，保证了实验可复现，便于学术比较和工程部署。

（3）安全和资源控制

预设流水线让研究者能精确控制每一步消耗多少 token、执行多少任务、修改多少内容——这对于成本敏感的工业部署至关重要。

1.4 当前的根本矛盾

但是，时代变了。前沿模型（如 GPT-5.5）的"规划和自我反思"能力已经今非昔比。

这就引出了一个尖锐的问题：

如果一个足够强的模型可以自己规划"怎么收集证据、怎么修改、怎么选择、什么时候停"，我们还需要研究者事先给它规定一条流水线吗？

这绝不是无关痛痒的学术设问，它关系到三个非常实际的问题：

• 效率：预设流水线往往包含大量"为了安全"的冗余步骤（如固定的大批次、严格的反思分离、复杂的元更新）。如果强模型自己能找到更短的改进路径，这些冗余就是浪费。
• 适用范围：预设流水线是"一刀切"的——同一套流程用于所有任务和所有模型。但不同任务、不同模型可能需要不同的优化策略。
• 天花板：预设流水线限制了模型能做到的事情。如果流程规定"每次只能做局部编辑"，那即使全局重写更合适，模型也不能做。

论文的核心主张可以提前剧透：对于足够强的优化器，预设流水线不仅不是必需的，反而可能成为负担——关键约束（安全、数据边界、评估）仍须外部保持，但"怎么优化"应该交给优化器自己组合。

这就好比：当一个新员工成长为资深工程师之后，你给他规定的详细操作 SOP 反而会限制他发挥。真正合理的做法是——保留"不能违反安全规定"“不能泄密"“必须通过质量评审"这些不可妥协的约束，但把"怎么完成任务"交给他自己决定。

二、论文定位和关联工作

OEO 这篇论文处于一个特殊的定位——它不是"提出又一个优化流水线”，而是对整个"预设流水线范式"的反思。要理解它的位置，需要梳理三个层面的关联工作。

2.1 被反思的对象：预设流水线方法

这是论文直接比较的两种代表性预设方法。

（1）SkillOpt：有界编辑的分阶段流水线

微软 2026 年 5 月提出的预设流水线代表，把 Skill 优化严格划分为五个阶段：前向传播（执行收集轨迹）→ 反向传播（分离失败/成功轨迹分别反思，生成结构化编辑）→ 有界更新（文本学习率 + 余弦调度）→ 验证门控（严格优于才接受）→ Epoch 级慢/元更新。特点：严格、有界、可复现。在 52 个评估单元上全部最佳或并列最佳，是当前预设流水线的最强代表。

OEO 与 SkillOpt 的关键区别：SkillOpt 规定了五个阶段的固定流程，OEO 只规定五项约束，流程由优化器自组合；SkillOpt 规定编辑必须是有界的（文本学习率）且必须分离失败/成功轨迹分别反思，OEO 不限制修改形式和分析方式。

（2）GEPA：反思式进化搜索

GEPA（Genetic-Pareto Prompt Evolution）是 UC Berkeley 和 Stanford 联合提出的预设流水线代表。它把提示词优化建模为多目标进化问题：

1. 维护一个种群（多个候选提示词）
2. 用 LLM 反思执行轨迹，生成语言反馈替代标量奖励
3. 通过 Pareto 前沿选择非支配个体
4. 持续进化

GEPA 的特点：种群级、多目标、反思式。

OEO 与 GEPA 的关键区别：

• GEPA 规定了种群级进化和 Pareto 选择的固定流程，OEO 不规定候选管理方式
• GEPA 规定用语言反馈作为进化信号，OEO 让优化器自行选择信号利用方式

2.2 思想来源：开放式优化与能力涌现

OEO 的思想不是凭空出现的，它植根于几条更深的研究脉络。

（1）LLM as Optimizer 的涌现

从 OPRO（2023）开始，研究者注意到一个现象：足够强的 LLM 本身就可以充当优化器——给它一批候选解和它们的得分，它能提出更好的候选解。这个观察在之后的工作中被反复验证：TextGrad 让 LLM 充当"文本梯度计算器”，DSPy 让 LLM 充当"提示词编译器"，EvoPrompt 让 LLM 充当"进化算子"。

随着模型能力提升，一个问题自然浮现：LLM 作为优化器，需要多详细的"工作指南"？

（2）开放式-ended AI 的传统

“开放式（Open-Ended）“这个词来自一个更古老的研究领域——开放式人工生命（Open-Ended Artificial Life）和开放式进化。其核心思想是：不要为系统规定一个"终点状态”，而是为系统提供基本的规则和驱动力，让系统自行探索可能性空间。

OEO 借用了这个思想：不规定"优化流程的终点形态”，只规定"不可逾越的边界"，让优化器在边界内自由探索。

（3）脚手架理论（Scaffolding）

教育学和认知科学中有一个经典概念——脚手架（Scaffolding）：为初学者提供支撑结构，帮助他们完成超出当前能力的任务；但随着能力提升，脚手架应该逐步撤除。

这个理论直接启发了论文的核心洞见——预设流水线应该被视为"能力依赖的脚手架"。初学者（弱模型）需要详细的流水线脚手架；熟练者（强模型）应该撤除大部分脚手架，只保留安全约束。

2.3 同期反思性工作

OEO 不是唯一一项反思"预设流程是否必要"的工作。2026 年以来，随着前沿模型能力跃升，出现了几项类似的反思性研究：

• AgentAutonomy 系列：探索让 Agent 自主规划工作流而非遵循预设工作流，发现强模型在自主模式下反而表现更好
• SelfRefine 类工作的延伸：最初 SelfRefine 只是"自我修订一次"，后来延伸为"让模型自己决定修订多少次、修订什么"
• Prompt-as-Optimizer：把提示词优化完全交给一个强 LLM，不再设计复杂的优化流程

这些同期工作与 OEO 形成了一个共识：前沿模型时代，研究者需要重新审视"哪些流程是模型必需的支撑，哪些是过时的束缚"。

2.4 OEO 在研究脉络中的定位

OEO 的定位结论：它不是"又一种预设流水线"，而是对预设流水线范式的元层面反思——它问的不是"哪种流水线更好"，而是"在什么条件下，强优化器还需要流水线"。

三、问题定义

3.1 从具体场景到抽象问题

论文面对的具体场景是：给定一个目标 Agent（比如 GPT-5.5 驱动的编程 Agent），希望在特定任务集合（比如 SearchQA、SpreadsheetBench 等）上提升其表现，手段是修改它上下文中的策略文档（Skill / Prompt）。

这个场景看起来很普通，但论文把它抽象成了一个更深的问题——“预设流程的必要性"本身是一个可以被经验验证的科学问题。

让我们来建立这个抽象。

3.2 三层抽象

第一层：具体的优化问题

给定：

• 冻结的目标模型 M（要被适应的 LLM，比如 GPT-5.5）
• 执行线束 h（提供运行时基础设施）
• 训练任务集 D_tr（提供优化经验）
• 选择/评估任务集 D_sel、D_test（用于门控和报告）
• 资源预算 B（可消耗的目标交互 token 总量）
• 数据边界约束 C_data（不能把测试任务泄漏到训练）
• 安全约束 C_safety（不能产生有害修改）

求：一个策略文档 s*，使得 M 在 h 中使用 s* 时，在 D_test 上的平均得分最大化。

第二层：流程设计的元问题

上面这个优化问题，可以用无数种流程来解决。应该用哪种流程？

• 流程 A（SkillOpt 式）：固定五个阶段、有界编辑、严格门控、epoch 级慢更新
• 流程 B（GEPA 式）：种群进化、反思反馈、Pareto 选择
• 流程 C（开放式）：只规定约束，让优化器自己组合流程
• …

第三层：最本质的抽象问题（论文真正问的）

“流程的必要性"是否依赖于优化器的能力？ 即：

给定一个能力水平为 L 的优化器，是否存在一个"预设流程 P”，使得使用 P 的效果严格优于"只给约束、让优化器自组合"的效果？

形式化地说：

对于优化器能力 L，定义：
- PrescribedPerformance(L, P) = 使用预设流程 P 时的最终性能
- OpenPerformance(L) = 只给约束、让优化器自组合时的最终性能

问题：在什么 L 下，PrescribedPerformance(L, P) > OpenPerformance(L)？
在什么 L 下，PrescribedPerformance(L, P) ≤ OpenPerformance(L)？

3.3 两个类比帮助理解这个抽象

类比一：辅助轮（能力依赖的脚手架）

学骑自行车时，辅助轮（training wheels）是非常有用的——它防止初学者摔倒，让他们先学会踩踏板和转向。但是当一个孩子已经掌握了基本平衡，辅助轮反而会成为负担：它限制了倾斜、影响了转向灵活度、让骑车子比实际上更累。

预设流水线之于弱优化器，就像辅助轮之于初学者——必要的支撑。 预设流水线之于强优化器，就像辅助轮之于熟练骑手——过时的束缚。

但要注意：即便拆掉辅助轮，头盔（安全约束）还是要戴的。这就是 OEO 的核心洞见：关键约束（安全、数据边界、评估）仍须外部保持，但"怎么优化"应该交给优化器自己组合。

类比二：能人与目标（开放式优化）

想象你面对两种完成任务的方式：

• 方式 A（预设流水线）：给员工一本详细的操作手册，规定他第一步做什么、第二步做什么、每一步做到什么程度、什么时候停。员工只需要严格执行。
• 方式 B（开放式优化）：给一个资深工程师一个目标（“在 7 天内把这个功能做好”）、一个工具箱（各种工具、文档、测试环境）、一个预算（不能超 1 万块钱）、一个评估标准（通过验收测试）和一条底线（不能违反安全规范）。然后让他自己想办法完成任务。

方式 A 适合新员工——他还不知道怎么规划工作。方式 B 适合资深工程师——给他详细手册反而限制他发挥。

OEO 之于预设流水线，就是方式 B 之于方式 A——当优化器足够强时，应该把"怎么优化"的决策权交还给它。

3.4 形式化的 OEO 接口

OEO 把开放式优化的思想形式化为一个最小约束接口。它规定五项不可妥协的约束：

1. 固定目标（Fixed Objective）：优化的目标函数（任务集 + 评估函数）必须事先明确，且不可被优化器修改——这保证了优化的"方向"不被腐蚀
2. 允许交互（Permitted Interaction）：优化器可以自由地与目标 Agent 交互——执行任务、观察轨迹、查询反馈
3. 资源预算（Resource Budget）：总的目标交互 token 预算必须事先约定，且严格执行——这是效率比较的基础
4. 数据边界（Data Boundary）：训练 / 选择 / 测试集的划分必须事先固定，不允许跨集泄漏——这防止了作弊式的"虚假提升”
5. 评估（Evaluation）：最终评估必须在留出的测试集上进行，且评估方法必须独立于优化过程——这保证了结果的可比性

仅此五项。 除此之外——怎么分析轨迹、修改多少、修改什么形式、维护多少候选、什么时候停——全部交给优化器自行决定。

3.5 问题定义的精妙之处

这个形式化定义有几个值得玩味的设计：

（1）“约束"与"流程"的清晰分离

预设流水线把"约束"和"流程"混在一起——安全约束、数据边界、评估方法都被编织进具体的流程步骤中。OEO 把它们显式分离：约束是外部的、不可妥协的；流程是内部的、可组合的。

（2）“固定"的边界划得恰到好处

OEO 固定的是优化方向（目标函数）和不可逾越的边界（预算、数据、安全、评估），但不固定优化路径。这就像国家只规定"不能违法"和"必须纳税"两条底线，但让企业自行决定怎么经营——既保证了底线，又释放了自由度。

（3）“能力依赖"的隐含设计

OEO 的接口没有规定"必须用什么样的优化器”——这意味着同一个接口可以被不同能力的优化器使用。这正是论文进行能力对照实验（强 / 中 / 弱优化器）的基础。

四、问题解法

OEO 的"解法"在传统意义上很特别——它不是一个具体的算法，而是一个最小约束接口 + 一个强大的优化器。但仔细看，它仍然有清晰的机制设计。让我们分层拆解。

4.1 第一层：五项约束的工程实现

（1）固定目标的实现

目标函数 = 任务集 + 评估函数。OEO 要求这两者在优化开始前就被冻结：

• 任务集 D_tr、D_sel、D_test 一次性确定，整个优化过程不改变
• 评估函数（verifier）一次性确定，对优化器和被优化 Agent 都透明

这一约束防止了"优化器自己改评估标准"这种作弊。

（2）允许交互的实现

优化器获得一个"目标交互 API”：

• execute(skill, task) → 返回执行轨迹和评分
• batch_execute(skill, task_list) → 批量执行
• observe(trajectory) → 观察完整轨迹（消息、工具调用、输出、评分）

优化器可以自由调用这些 API，调用次数、调用顺序、调用参数都不受限——只要不超预算。

（3）资源预算的实现

资源预算 B 以目标交互 token计算——即被优化的 Agent 执行任务时消耗的 token 总量。这包括了任务输入、执行过程中的所有工具调用、最终输出。

注意一个精巧的设计：优化器自己的"思考 token"不算在预算里。这是合理的，因为优化器的工作是"想怎么改进”，而"想"本身不直接产生执行成本——产生成本的是"试"。

预算对比是 OEO 论文的一个核心维度：作者让 OEO 使用 SkillOpt 配置的预算的中位数 34.3%——即 OEO 在显著更少的预算下达到了更好的效果。

（4）数据边界的实现

训练 / 选择 / 测试集的划分在整个优化过程中严格保持：

• D_tr 用于优化器收集经验（可以多次使用）
• D_sel 用于候选之间的横向比较和门控（如果优化器选择做门控）
• D_test 完全留出，优化器在优化过程中绝对不能接触

这一约束防止了"用测试集性能反推优化策略"这种隐式泄漏。

（5）评估的实现

最终评估：

• 必须在 D_test 上进行
• 必须使用与优化过程中相同的 verifier
• 必须报告多次运行的统计量（均值 + 标准差），因为 LLM 推理有随机性

4.2 第二层：优化器的自由组合

在上述五项约束之外，优化器（比如 GPT-5.5）可以自由地决定怎么进行优化。这是 OEO 最"反传统"的部分——它不规定流程，但我们可以通过观察优化器的实际行为，归纳出它自发地组合出了哪些流程组件。

论文的轨迹分析显示，强优化器在 OEO 接口下自发地做了一些有趣的事情：

（a）自适应的批次大小

强优化器会根据任务难度自发调整每次执行多少任务。简单任务时大批次（快速收集信号），困难任务时小批次（避免噪声）。这相当于 SkillOpt 中"批次大小"的参数被动态化了。

（b）自适应的修改粒度

强优化器会根据反馈强度决定修改幅度。如果发现了一个系统性错误（比如 Agent 总是忽略某个约束），它会做较大的修改；如果只是个别案例的小问题，它做轻微修改。这相当于 SkillOpt 中"文本学习率"被自适应化了。

（c）自适应的验证频率

强优化器会自发地在重要修改后立即验证，在小修改后批量验证。这相当于 SkillOpt 中"验证门控"被情境化了。

（d）自适应的停止时机

强优化器会根据"是否还在显著提升"决定何时停止。当连续几轮修改都没有明显改进时，它会主动结束优化。这相当于 SkillOpt 中"早停策略"被智能化了。

关键观察：强优化器在 OEO 接口下自发地重组了 SkillOpt 流水线的所有组件——但它把每个组件都做得更灵活、更情境化。这就像一个资深工程师在读了操作手册之后，不是机械地执行，而是理解了每个步骤的目的，然后根据具体情况灵活运用。

4.3 第三层：OEO 的"接口契约"

OEO 实际上定义了一个"优化器即服务"的接口契约：

interface OEO {
  // 输入
  objective: (task_set, verifier)         // 固定目标
  budget: int                              // 资源预算
  data_split: (D_tr, D_sel, D_test)        // 数据边界
  safety_policy: Policy                    // 安全约束
  
  // 优化器可用的 API
  execute(skill, task) -> (trajectory, score)
  observe(trajectory) -> observation
  
  // 输出
  best_skill: Skill                        // 最终产物
  
  // 评估（外部独立执行）
  evaluate(skill, D_test) -> final_score
}

优化器在这个契约内可以自由地实现任何逻辑。

4.4 OEO vs 预设流水线的全景对比

对比的精髓：SkillOpt 和 GEPA 把所有东西都编织进流程；OEO 把"约束"和"流程"分离——约束外部化，流程内部化。

五、评估指标与实验证据

OEO 论文最核心的贡献不在于提出一个新方法，而在于用严格的实验回答了一个元问题：预设流水线是否仍然必要。这一节梳理它的评估体系和实验证据。

5.1 评估指标体系

（1）主指标：测试集得分（Test Score）——优化完成后，最终得到的 skill 在留出测试集 D_test 上的平均得分（0-100）。这是衡量优化最终效果的"金标准"——反映的不是过程"做得多少"，而是结果"做到了什么"。

（2）辅助指标：目标交互 token 消耗——优化过程中被优化的 Agent 执行任务时消耗的 token 总量。越低越好。衡量资源效率，在工业部署中至关重要——多余的预算就是多余的美元。

（3）辅助指标：胜率（Win Rate）——在多个"基准-目标-模型"三元组设置下，OEO 与预设方法的正面交锋记录（胜/平/负）。衡量方法的泛化稳健性。

（4）消融指标：优化器能力对照——固定 OEO 接口，替换不同能力水平的优化器，观察最终性能。这是论文核心主张（“预设流水线是能力依赖的脚手架”）的直接验证指标。

（5）过程指标：轨迹分析——记录优化器在 OEO 接口下的实际行为序列，分析其一致性、修改模式、流程重组方式。

衡量的是什么：“预设流程到底改变了什么”——是改变了优化器的"最终行为"，还是改变了"达成最终行为的过程"。这是论文一个很深的分析维度。

5.2 实验设置

（1）基准选择

论文在 8 个"基准-目标-模型"三元组设置下进行实验。这些设置覆盖了：

• 不同类型的任务（问答、电子表格、文档理解、数学等）
• 不同难度的任务（从简单检索到复杂推理）
• 不同的目标 Agent（GPT-5.5 等前沿模型）

选择这些基准的理由：它们是当前自进化 Agent 研究的标准基准，覆盖了 Agent 能力的主要维度，且具有可靠的 verifier（避免评估本身的噪声）。

（2）比较对象

• OEO（论文方法）：只规定五项约束
• SkillOpt（预设流水线代表 1）：有界编辑的分阶段流水线
• GEPA（预设流水线代表 2）：反思式进化搜索
• 基线：无优化（用初始 skill 直接评估）

（3）公平性保证

• 所有方法使用相同的 D_tr / D_sel / D_test 划分
• 所有方法使用相同的 verifier
• 所有方法报告多次运行的统计量
• 预算控制：OEO 被限制在 SkillOpt 配置预算的中位数 34.3%——这是一个故意设置的"劣势条件"，让 OEO 在更少资源下与 SkillOpt 比较

5.3 核心实验结果

实验 1：OEO vs 预设流水线的正面交锋（主实验）

在 GPT-5.5 驱动下，跨 8 个"基准-目标-模型"设置的 14 次正面交锋（每设置多次运行统计）：

这个结果意味着什么：OEO 在 14 次交锋中 12 次显著超越预设流水线，1 次平局，1 次仅微弱落后（差距 0.21 个百分点，几乎不可区分）。在强优化器下，预设流水线不仅没有帮助，反而成为限制。

更惊人的是效率对比：

实验 2：能力依赖对照（核心消融）

固定 OEO 接口，替换不同能力水平的优化器：

这个结果意味着什么：这是论文最关键的实验证据，直接支撑核心洞见——

• 强优化器：预设流水线是束缚，应撤除（OEO 占优）
• 中等优化器：预设流水线是必要支撑（SkillOpt 占优）
• 弱优化器：连"自组合流程"本身都做不到（OEO 无法运作）

这正是"能力依赖的脚手架"假说的直接验证。

实验 3：轨迹分析（机制层面）

分析强优化器在 OEO 接口下的行为轨迹，得到几个有趣的发现：

发现 A：预设主要改变"过程一致性"而非"最终行为"

在 OEO 和 SkillOpt 下，强优化器最终学到的 skill 在"做什么"上很相似（都会发现类似的关键规则），但优化的过程一致性差异巨大：

• SkillOpt 下：每次运行的优化过程几乎一样（固定流程的体现）
• OEO 下：每次运行的优化过程差异很大（优化器自由组合的体现）

这意味着：预设流水线主要影响的是"怎么到达"，而不是"到达哪里"。对于强优化器，无论规定路径还是自由探索，最终都能到达类似的终点；预设的作用主要是让过程更标准化。

发现 B：OEO 下优化器自发重组了流水线组件

如前所述，强优化器在 OEO 下自发地重组了批次大小、修改粒度、验证频率、停止时机——而且这些"自发版本"比 SkillOpt 的"固定版本"更灵活、更情境化。

发现 C：预设流程的"机会成本"

在 SkillOpt 下，某些情况下优化器"知道"应该做大幅修改，但被文本学习率约束禁止；或者"知道"应该跳过验证，但被流程强制要求验证。这些就是预设流程的"机会成本"——为了保证平均稳定性，牺牲了特定情境下的最优选择。

5.4 指标如何证明论文的核心主张

主张 1：预设流水线对于强优化器不是必需的

证据链：

• 实验 1：OEO 在 14 次交锋中 12 胜 1 平 1 负 → 强优化器下 OEO 效果更好
• 实验 3 发现 A：预设主要改变过程一致性，不改变最终行为 → 没有预设，强优化器也能到达类似终点

这个实验设计为什么能证明论点：作者不仅比较了"最终性能"（回答"行不行"），还分析了"优化过程"（回答"为什么行"）。双重证据让结论非常稳健。

主张 2：预设流水线是能力依赖的脚手架

证据链：

• 实验 2：OEO vs SkillOpt 在不同能力优化器下的反转 → 强优化器下 OEO 占优，中等 SkillOpt 占优，弱 OEO 无法运作

这个实验设计为什么能证明论点：固定接口、只换优化器，是证明"差异源于能力"的最干净的实验设计。如果只用强优化器比较，无法排除"OEO 总是更好"的替代解释；通过能力对照，明确锁定了"能力依赖"这一变量。

主张 3：关键约束仍须外部保持

证据链：

• 数据边界约束：所有方法都使用相同的 D_tr/D_sel/D_test 划分，没有出现"靠测试集泄漏取胜"的情况——说明数据边界是必需的外部约束
• 评估独立性：最终评估由独立的 verifier 在 D_test 上执行，不参与优化——说明评估独立性是必需的外部约束
• 安全约束：论文明确指出，OEO 不会让优化器修改安全策略——说明安全约束是必需的外部约束

这个实验设计为什么能证明论点：通过明确分离"哪些是优化器可以自由决定的"和"哪些是不可妥协的外部约束"，论文给出了一个可操作的设计原则——而不是简单地喊"自由更好"。

六、效果优势的根源解释

这一节追溯：为什么 OEO 在强优化器下优于预设流水线？ 我们要建立从"方法差异"到"机制变化"再到"指标提升"的完整因果链。

6.1 baseline 的根本局限：预设流水线的"统一尺码"问题

SkillOpt 和 GEPA 这类预设流水线的根本局限，不在于"它们的流程设计得不好"，而在于任何预设流程本质上都是一种"统一尺码"——它必须为"平均情况"设计，因此必然在"非平均情况"下表现次优。

具体来说，预设流水线有三层根本局限：

局限 1：流程参数是静态的，但最优参数是情境依赖的

SkillOpt 规定了固定的批次大小、文本学习率、验证频率。但最优的批次大小取决于任务难度——简单任务应该大批次，复杂任务应该小批次。最优的修改粒度取决于反馈强度——强信号应该大修改，弱信号应该小修改。

预设流水线无法做到这种情境适应——它必须选择一个"平均表现最好"的参数值，因此必然在具体情境下次优。

局限 2：流程步骤是固定的，但最优步骤组合是问题依赖的

SkillOpt 规定了"反思 → 编辑 → 验证"的固定序列。但有些情况下，“直接尝试"比"先反思"更高效；有些情况下，“连续多次小修改"比"一次大修改"更可靠。

预设流水线无法做到这种问题适应——它必须选择一个"对所有问题都还行"的流程，因此必然在具体问题上次优。

局限 3：流程限制是保守的，但前沿模型的能力被低估

SkillOpt 的文本学习率是为了"防止弱优化器搞砸”。但对于强优化器，这个限制是多余的——它会自然地控制修改幅度。文本学习率反而阻止了强优化器在适当时候做大刀阔斧的改进。

6.2 OEO 的根本性改变：从"静态流程"到"动态策略”

OEO 的根本改变不是"换了一个流程"，而是把"选择流程"的权力交还给了优化器。这个改变导致了三层机制变化：

机制变化 1：情境化决策

在 OEO 下，强优化器可以根据当前反馈情境化地决定：

• 这次该执行多少任务（动态批次）
• 这次该修改多少（动态学习率）
• 这次该不该立即验证（动态门控）
• 现在该不该停（动态停止）

因果链：情境化决策 → 每一步都更适合当前情况 → 单位预算内的改进更高效 → 测试集得分更高 + 预算消耗更低

机制变化 2：流程重组

在 OEO 下，强优化器可以自发重组流水线组件：

• 对于"明显错误"，跳过反思直接修改
• 对于"复杂问题"，多次反思再修改
• 对于"重要修改"，立即验证
• 对于"小修改"，批量验证

因果链：流程重组 → 跳过不必要的步骤 → 减少"机会成本" → 预算消耗大幅降低（仅 34.3%）+ 测试集得分不降反升

机制变化 3：能力释放

在 OEO 下，强优化器的"规划和反思"能力得到充分释放——它可以基于对任务的深入理解做出预设流程想不到的优化决策，可以在长程优化中保持目标一致性，可以利用元知识做出超越任何预设流程的策略。

因果链：能力释放 → 优化器做出更聪明的决策 → 发现预设流程发现不到的优化路径 → 测试集得分超越预设方法

6.3 反事实推理：去掉某个关键设计会怎样？

• 如果给 OEO 加上"文本学习率"约束：强优化器在 OEO 下经常做出"超过文本学习率"的大修改，而这些大修改往往是关键突破点。加上约束会让这些突破被禁止，OEO 退化到接近 SkillOpt 的水平——束缚重新出现。
• 如果撤掉"数据边界"约束：优化器会"自发地"用 D_test 得分指导优化，导致严重过拟合，测试分虚高但泛化差——数据边界是不可撤的脚手架。
• 如果撤掉"资源预算"约束：优化器可能无限制执行任务，效果略好但成本可能增 10 倍——资源预算是不可撤的脚手架（至少在工业场景下）。

6.4 优势根源的总结

OEO 在强优化器下的优势，根源在于：

1. 情境化决策替代静态参数——每一步更适合当前情况
2. 流程重组替代固定流程——减少机会成本
3. 能力释放替代能力束缚——发现预设流程发现不到的路径

这三个机制变化，都是因为"把流程决策权交还给了优化器"。这就是 OEO 优于预设流水线的结构性必然——不是凑巧好，而是在"强优化器 + 开放式接口"的组合下，必然优于"强优化器 + 预设流水线"。

但要注意一个关键前提：这个结论只在强优化器下成立。对于中等或弱优化器，这三个机制变化都不成立——中等优化器无法做情境化决策，无法自发重组流程，无法释放能力——所以预设流水线对它们仍然是必要的。

七、必要知识反推

假设找一个完全没有相关知识的人来复现这项工作，他必须掌握哪些必要知识？这些知识又是如何融合最终完成这篇论文的？

7.1 领域知识层

（1）自进化 Agent 的运作机制

必须深入理解自进化 Agent 是怎么工作的——它如何执行任务、如何收集反馈、如何修改策略、如何验证改进。不理解这个闭环，就无法理解"预设流水线"到底预设了什么，也无法理解"开放式优化"到底开放了什么。

（2）Skill / Harness 的实践

必须理解当前 Agent 生态中 Skill 和 Harness 的实际形态。Skill 是什么？是 Claude Code 的 .claude/skills/，是 Codex 的 AGENTS.md，是一段被插入上下文的自然语言策略。Harness 是什么？是执行 Agent 的基础设施——系统提示、工具系统、沙盒环境。这些具体实践决定了 OEO 接口要怎么设计才能落地。

（3）预设流水线的具体形态

必须深入理解 SkillOpt 和 GEPA 这两种预设流水线的具体机制——不只是知道它们存在，而是要能精确说出它们规定了哪些流程步骤、每个步骤做什么、为什么这么规定。不理解预设流水线的细节，就无法精确控制"哪些约束要保留、哪些流程要开放"。

7.2 方法论知识层

（4）LLM as Optimizer 的研究脉络

必须了解从 OPRO 到 TextGrad 到 DSPy 到 EvoPrompt 的完整脉络。知道"LLM 充当优化器"这个思想的演进，知道每一步能力提升带来的新可能。特别是理解一个关键观察：随着模型能力提升，LLM 作为优化器需要的"工作指南"越来越少。

（5）开放式-ended 优化理论

必须理解开放式人工生命和开放式进化的思想传统。知道"开放式"这个词的来源和含义，知道它与"目标导向优化"的区别。这是 OEO 思想的直接来源。

（6）能力涌现与缩放定律

必须理解 LLM 的能力如何随规模涌现。知道什么样的能力在什么规模下出现，知道"规划长程优化"这种能力大致出现在什么级别。这是论文进行"能力对照实验"的基础——必须知道选什么样的优化器来代表"强"、“中”、“弱”。

（7）脚手架理论

必须理解教育学中的脚手架理论——支撑结构应该随能力提升而逐步撤除。这是论文核心洞见"能力依赖的脚手架"的直接思想来源。

7.3 工程知识层

（8）约束接口的设计

要设计一个"最小但足够"的约束接口，需要深入工程经验：

• 哪些约束是真正不可妥协的（安全、数据、评估）
• 哪些是"为了方便"的约束（具体流程、参数、步骤）
• 如何用 API 把约束"外部化"，让优化器无法绕过

（9）预算控制与公平比较

要让 OEO 和预设方法公平比较，必须设计精确的预算控制：

• 怎么计算"目标交互 token"
• 怎么让所有方法在相同预算下比较
• 怎么处理"优化器自己的思考 token"——不算预算，但要防止滥用

（10）轨迹分析的方法论

要让"轨迹分析"有说服力，需要知道：

• 怎么记录优化器的完整决策序列
• 怎么从高维轨迹中提取有意义的模式
• 怎么区分"过程一致性"和"最终行为相似"

7.4 知识融合的关键节点

融合点 1：“预设流程 = 能力依赖的脚手架"的洞察

这个洞察融合了三方面知识：

• 自进化 Agent 的具体实践（预设流程是什么）
• 脚手架理论（支撑结构应该随能力撤除）
• 能力涌现（前沿模型已经突破"需要详细 SOP"的临界点）

化学反应：三方面知识融合后，产生了一个视角的转换——从"哪种预设流程更好"转换为"什么条件下需要预设流程”。这个视角转换是论文的核心创新。

融合点 2：“五项约束"的设计

这个设计融合了：

• 工程经验（哪些约束是真正不可妥协的）
• 开放式优化理论（最小约束 + 最大自由度）
• 实验设计方法论（公平比较需要什么前提）

化学反应：三方面知识融合后，产出了一个可操作的设计原则——不是空喊"自由更好”，而是精确指出"这五项不能开放，其他都可以开放"。

融合点 3：能力对照实验的设计

这个设计融合了：

• 能力涌现的缩放规律（选什么样的优化器代表不同能力级别）
• 实验方法论（控制变量，固定接口换优化器）
• 因果推断（怎么从实验数据推断"能力依赖"这个因果，而非相关）

化学反应：三方面知识融合后，产出了一个能直接证明核心洞见的实验设计——不是空谈"强优化器不需要预设"，而是用三档能力的对照实验直接展示反转。

八、论文中可以提取的通用性灵感

灵感 1：脚手架应该随能力提升而撤除（范式迁移类）

核心思想：任何为"辅助能力不足"而设计的支撑结构，都应该随主体能力的提升而逐步撤除——而不是永远保留。保留过时的脚手架不仅浪费，还会成为束缚。

论文证据：OEO 在强优化器下显著优于 SkillOpt；但 SkillOpt 在中等优化器下优于 OEO；弱优化器根本无法使用 OEO 接口。这直接证明了"预设流水线"是能力依赖的脚手架——该撤时要撤，不该撤时不能撤。

推广场景：新员工的详细 SOP 应随成长逐步简化为"目标 + 预算 + 底线"的开放任务；初学者的分步指引应随水平提升撤除，最终变成开放探究；新兴产业需要详细规定（脚手架），产业成熟后应转向原则导向监管；原型期的脚手架代码（mock、stub）应在产品成熟后撤除。

灵感 2：约束与流程应该显式分离（关注点分离类）

核心思想：在任何系统中，“不可妥协的约束”（安全、公平、评估独立性）和"可组合的流程"（具体怎么做）应该被显式分离——约束外部化、独立守护；流程内部化、自由组合。

论文证据：OEO 把五项约束（目标、交互、预算、数据、评估）外部化为独立守护的边界，把所有流程决策（批次、修改、验证、停止）交给优化器自由组合。这种分离让强优化器既不会越界（约束守护），又能充分发挥（流程自由）。

推广场景：组织管理把"合规底线"和"工作方式"分离——底线由合规部门守护，工作方式由团队自决定；API 设计把"安全约束"（认证、限流）和"业务流程"分离；法规制定把"禁止性规定"（不可逾越）和"指导性建议"（可灵活）明确区分；教育评估把"学术诚信"（不可妥协）和"学习方法"（可自由）分离。

灵感 3：能力是方法选择的关键变量（方法论类）

核心思想：在评估一种方法是否优于另一种方法时，必须把"使用者的能力水平"作为关键变量纳入考虑——同一种方法在不同能力水平下可能呈现完全相反的优劣。

论文证据：OEO vs SkillOpt 的优劣完全取决于优化器能力——强优化器下 OEO 胜，中等 SkillOpt 胜，弱 OEO 无法运作。如果不考虑能力变量，任何"X 优于 Y"的结论都是不完整的。

推广场景：评估开发工具必须考虑使用者技术水平（新手工具 vs 专家工具）；评估教学方法必须考虑学生水平（启发式 vs 讲授式）；评估管理模式必须考虑团队成熟度（指令式 vs 授权式）；评估优化算法必须考虑问题难度和规模。

灵感 4：过程一致性与最终结果的分离（评估类）

核心思想：在复杂系统中，“过程的可复现性"和"最终结果的质量"是两个独立的维度。强调过程一致性可能会牺牲结果质量；允许过程多样性可能会提升结果质量。

论文证据：SkillOpt 下每次优化的过程几乎一样（高一致性），OEO 下每次优化的过程差异很大（低一致性），但两者最终学到的 skill 在"做什么"上很相似。预设流水线主要改变的是"过程一致性”，而非"最终结果"。

推广场景：科研评估过度强调流程标准化可能阻碍发现更好路径；产品开发过度强调流程一致性可能让团队无法对具体问题做最优响应；创意工作过度强调流程标准化会扼杀创造力；（反向）航空、医疗等安全关键领域，过程一致性比结果多样性更重要——此时预设流程不可撤。

灵感 5：最小约束接口的设计哲学（系统设计类）

核心思想：设计一个接口（API、协议、规则）时，应该追求"最小但足够"——只规定真正不可妥协的约束，让其他一切可组合、可演化。

论文证据：OEO 的接口只规定五项约束，其他全开放。这种"最小但足够"的设计让接口可以被不同能力的优化器使用（虽然效果不同），且不会因为优化器的演进而过时。

推广场景：好的编程语言只规定必要的语法和类型规则，让编程风格自由演化；好的网络协议只规定必要的握手和校验，让上层应用自由演化；好的宪法只规定基本权利和权力结构，让法律和习俗自由演化；好的平台只规定不可逾越的底线，让生态参与者自由组合。

灵感 6：效率提升往往来自"撤除"而非"添加"（机制类）

核心思想：在成熟系统中，效率的显著提升往往不来自于添加更多机制，而是来自于撤除过时的机制——做减法比做加法更难，但也更有效。

论文证据：OEO 相比 SkillOpt 节省了约 66% 的目标交互 token——这些节省不是来自于新增的高效机制，而是来自于撤除了不必要的流程步骤（固定批次、固定学习率、固定验证、固定停止）。

推广场景：代码优化中移除不必要的抽象层往往比增加缓存更能提升性能；组织管理中减少不必要的审批环节往往比增加激励机制更能提升效率；产品设计中移除不必要的功能往往比增加新功能更能提升用户体验；法规优化中废除过时的法规往往比制定新法规更能释放活力。

灵感 7：能力边界需要被明确测试（评估类）

核心思想：任何方法的适用范围都是有限的，必须通过实验明确测试其"能力边界"——在什么条件下有效，在什么条件下失效。过早推广到边界外是有害的。

论文证据：论文不仅展示了 OEO 在强优化器下的优势，还明确测试了 OEO 在中等和弱优化器下的局限——中等下不如 SkillOpt，弱下根本无法运作。这种"明确测试能力边界"的态度，让结论更加可信。

推广场景：医学研究中新药不仅要证明在目标人群有效，还要明确测试在不适用人群的副作用；AI 安全中新方法不仅要展示成功案例，还要明确测试失败模式；政策制定中新政策不仅要论证预期效果，还要明确测试副作用和适用边界；工程实践中新技术不仅要展示优点，还要明确测试失效条件。

附录：OEO 接口的伪代码示意

class OEOInterface:
    def __init__(self, objective, budget, data_split, safety_policy):
        # 五项约束在初始化时固定，整个优化过程不可变
        self.objective = objective           # 固定目标
        self.budget = budget                 # 资源预算
        self.D_tr, self.D_sel, self.D_test = data_split  # 数据边界
        self.safety_policy = safety_policy   # 安全约束
        self.spent = 0                       # 已消耗预算
    
    def execute(self, skill, task):
        """优化器可用的 API：执行单个任务，检查预算与安全"""
        if self.spent >= self.budget:
            raise BudgetExceeded()
        if not self.safety_policy.is_safe(skill, task):
            raise SafetyViolation()
        trajectory, score = self.objective.run(skill, task)
        self.spent += trajectory.token_count
        return trajectory, score
    
    def evaluate(self, skill):
        """最终评估：在留出的 D_test 上独立执行，优化过程中不能调用"""
        return self.objective.evaluate(skill, self.D_test)


def oeo_optimize(interface, optimizer_model):
    """OEO 优化循环：优化器自由决定流程，接口守护约束"""
    skill = initial_skill
    best_skill = skill
    # 优化器自行决定循环结构、批次、修改、验证、停止
    while optimizer_model.wants_to_continue(interface.spent, interface.budget):
        tasks_to_run = optimizer_model.select_tasks(interface.D_tr)
        trajectories = [interface.execute(skill, t) for t in tasks_to_run]
        new_skill = optimizer_model.improve(skill, trajectories)
        if optimizer_model.should_validate(new_skill):
            if validate(interface, new_skill, interface.D_sel) > validate(interface, skill, interface.D_sel):
                skill = best_skill = new_skill
    return best_skill

关键点：interface 只暴露 execute——约束被封装在内部；optimizer_model 自由决定 select_tasks、improve、should_validate、wants_to_continue——流程完全自由；最终 evaluate 在 D_test 上独立执行——优化器无法接触。

写在最后

这篇论文的最大价值不在于"提出一个更强的优化方法"，而在于提出了一个视角的转换——从"哪种预设流水线更好"转换为"什么条件下需要预设流水线"。

• 对研究者：不要再沉迷于设计"更精细的预设流水线"——如果目标用户是前沿模型，应该研究"怎么最小化约束、最大化自由"。
• 对工程实践者：部署自进化 Agent 时，不要盲目照搬学术论文的预设流水线——要根据实际使用的模型能力，选择合适的"脚手架级别"。强模型用开放接口，中等模型用中等脚手架，弱模型用详细脚手架。
• 对 AI 系统设计者：要意识到"约束"和"流程"是两个独立的设计维度——约束外部化、不可妥协；流程内部化、可自由组合。
• 对 AI 发展的思考者：这篇论文是一个信号——前沿模型的能力已经强到可以让许多"曾经必要的脚手架"变成"过时的束缚"。这个趋势会继续，研究者需要敏锐地识别这种转变，及时撤除过时的脚手架。

当然，论文也明确指出了边界——关键约束（安全、数据边界、评估）仍须外部保持。无论模型多强，这些约束都不能撤。开放不等于放任，撤除脚手架不等于撤除头盔。

这是 AI 自进化研究走向成熟的一个标志：从"设计更好的流水线"到"反思流水线本身的必要性"。这种反思能力，本身就是科学进步的体现。