超越提示：衡量与优化大语言模型工具代理框架

# 超越提示词：衡量与优化 LLM 工具-智能体运行框架
来源：https://arxiv.org/html/2609.05736
Haibo Ruan，Wenjie Chen  
附属单位：Pei-fen Tu，Usman Abbasi，Joel Hesch  
附属单位：Airbnb, Inc., 美国  
附属单位：{mia.zhao, haibo.ruan, wenjie.chen, pei-fen.tu, usman.abbasi, joel.hesch}@airbnb.com

###### 摘要

LLM 工具智能体可以在不重新训练模型的情况下，通过修改固定模型周围的运行框架进行改进，这些框架包括提示词、工具接口、中间件、状态处理和恢复逻辑。我们将此场景研究为针对固定模型多轮工具智能体的资源受限框架选择问题，搜索范围限定在提示词和*工具边界*中间件上：编辑是在工具边界处的受保护拦截，而非对智能体执行逻辑的任意重写。我们提出了一个优化器无关的协议，报告平均保留提升、最差条件提升、可重复性、已记录的成本诊断指标，以及 RelLift₉₅(B)（RelLift₉₅(B)），即在预算 B 下选定的框架在保留集上增益的保守估计。我们使用仅提示词和提示词加中间件优化器实例化了该协议，其中包括 PRISM，它在帕累托搜索中对故障进行聚类，并将修复路由至提示词、工具边界中间件或联合编辑层面。在 BFCL 多轮、τ²-Retail 和 τ²-Telecom 任务上，PRISM 获得了平均 14.2、14.9 和 10.1 个百分点的保留提升，并在所有三个基准测试上实现了正的经验 RelLift₉₅。组件消融实验表明，其优势主要归因于故障层面路由和编辑模式约束。跨优化器的结果表明，某些搜索过程可能偶尔发现较大增益，但仍可能选择脆弱的更新，因此应将所选框架的可靠性与平均保留提升一同报告。

## 1 引言

使用外部工具的多轮对话智能体是智能体优化的严苛测试平台：在面向客户的服务工作流中，智能体必须跟踪对话状态、遵循策略、正确调用 API、从缺失信息中恢复，并使环境处于预期状态。τ²-bench 和伯克利函数调用排行榜 (BFCL) 捕获了该场景的互补方面（动态用户交互、有状态执行、可执行函数调用）(Barres et al., 2025 (https://arxiv.org/html/2609.05736#bib.bib2))，并暴露了一种部署矛盾：更强大的系统可能更可靠，但生产环境中的智能体仍必须满足延迟和运行时成本约束 (Chen et al., 2024 (https://arxiv.org/html/2609.05736#bib.bib4))。我们研究*智能体框架优化*是否能在不改变模型权重的情况下改善这种权衡。框架是围绕固定目标模型的运行时控制层，包括提示词、工具接口、上下文构建、状态管理、中间件、恢复逻辑和评估钩子。先前关于指令优化、轨迹反射提示词进化以及推理与行动智能体的研究表明，改变这个外围层可以显著影响下游行为 (Opsahl-Ong et al., 2024 (https://arxiv.org/html/2609.05736#bib.bib14); Agrawal et al., 2026 (https://arxiv.org/html/2609.05736#bib.bib1); Yao et al., 2023 (https://arxiv.org/html/2609.05736#bib.bib17))。我们精确地将优化层面限定为提示词加上*工具边界*中间件：当故障在工具边界处可局部观察和检查时，中间件才起作用，而不是任意重写智能体执行逻辑。主要问题并非一个框架能否提升某个基准测试的分数，而是自动化的框架搜索过程是否值得信赖：报告的增益可能依赖于搜索期间使用的修复示例、随机化的优化器选择或智能体评估中的方差，并且可能附带限制实际价值的搜索成本 (Bjarnason et al., 2026 (https://arxiv.org/html/2609.05736#bib.bib3))。因此，我们沿着四个轴评估框架搜索过程：有效性（相对于基线框架的保留提升）；修复分布鲁棒性（增益是否在不同修复集上持续存在）；同协议可重复性（效果是否在相同搜索协议下重现）；以及效率（可靠获得增益所需的预算）。我们在三个多轮工具使用任务上实例化了此协议：BFCL 多轮、τ²-Retail 和 τ²-Telecom (Barres et al., 2025 (https://arxiv.org/html/2609.05736#bib.bib2))，并使用用户模拟。我们比较了 BetterHarness 风格的爬山法、MIPROv2 (Opsahl-Ong et al., 2024 (https://arxiv.org/html/2609.05736#bib.bib14))、GEPA (Agrawal et al., 2026 (https://arxiv.org/html/2609.05736#bib.bib1)) 和 PRISM（我们提出的针对提示词和中间件更新的分解优化器）。本文有三个贡献。首先，我们将框架改进构建为一个预算约束的选择问题，并询问选定的框架在保留数据上的可靠性如何，使用 RelLift₉₅ 估计器来衡量。其次，PRISM 根据故障的根本原因进行聚类，将每个修复路由到可以进行局部检查的层面。第三，PRISM 在循环中选择候选方案时，不仅考虑通过率，还考虑可靠性，而不仅仅是分数。进化搜索、帕累托保留和故障聚类本身并非新方法：PRISM 构建在 GEPA 风格的骨架之上 (Agrawal et al., 2026 (https://arxiv.org/html/2609.05736#bib.bib1))，并在与所有基准相同的执行基板上运行。组件消融实验（第 6.1 节 (https://arxiv.org/html/2609.05736#S6.SS1)）检查了是否是这些新组件（而非继承的组件）带来了结果。

## 2 背景与相关工作

先前工作表明，模型周围的框架是一个重要的优化层面：BetterHarness 将评估失败视为框架爬山法的训练数据，在部署前进行保留评估和回归检查 (Trivedy, 2026 (https://arxiv.org/html/2609.05736#bib.bib15))，而 Deep Agents profiles 显式地暴露了该层面，在 τ²-bench 风格的任务上获得了特定配置文件的收益 (LangChain, 2025 (https://arxiv.org/html/2609.05736#bib.bib12); Hollon and Chase, 2026 (https://arxiv.org/html/2609.05736#bib.bib9))。一条工作线优化固定模型周围的文本：OPRO 使用模型本身作为指令优化器 (Yang et al., 2024 (https://arxiv.org/html/2609.05736#bib.bib16))，EvoPrompt 将进化算子应用于提示词种群 (Guo et al., 2024 (https://arxiv.org/html/2609.05736#bib.bib8))，TextGrad 在复合系统中传播文本反馈 (Yuksekgonul et al., 2024 (https://arxiv.org/html/2609.05736#bib.bib18))，DSPy 使用 MIPROv2 作为其指令优化器来编译语言模型程序 (Khattab et al., 2024 (https://arxiv.org/html/2609.05736#bib.bib11); Opsahl-Ong et al., 2024 (https://arxiv.org/html/2609.05736#bib.bib14))。GEPA 通过帕累托池上的轨迹反射进化提示词，并报告性能优于这些早期方法 (Agrawal et al., 2026 (https://arxiv.org/html/2609.05736#bib.bib1))，因此我们将 GEPA 和 MIPROv2 作为基准，而非所有祖先方法。第二条工作线编辑智能体*代码*：ADAS 在智能体程序上进行搜索 (Hu et al., 2025 (https://arxiv.org/html/2609.05736#bib.bib10))，Meta-Harness 重写框架源码 (Lee et al., 2026 (https://arxiv.org/html/2609.05736#bib.bib13))，Trace 优化智能体计算图 (Cheng et al., 2024 (https://arxiv.org/html/2609.05736#bib.bib6))。这些系统在离线状态下处理编码、数学或分类任务，在无约束的程序空间中搜索，并且在目标中未设置资源限制。我们的场景在三个轴上均不同：具有模拟实时用户的多轮对话工具智能体，围绕固定模型和工具 API 的受限工具边界修复，以及部署包络线位于分数本身之内（第 4.4 节 (https://arxiv.org/html/2609.05736#S4.SS4)）。NeoSigma 研究了多轮场景下的自动框架修复 (Chen et al., 2026 (https://arxiv.org/html/2609.05736#bib.bib5))。这些工作证实框架搜索可以改善智能体行为，但它们报告的是不同的证据片段：验证提升、执行效率、回归检查或单一的最终分数。在重复的搜索和发布周期中，仅报告单一的验证提升是不够的：维护已部署智能体的团队会分批收到故障报告，而本周的批次与上周的批次在分布上不同，通常在种类上也不同 (Gama et al., 2014 (https://arxiv.org/html/2609.05736#bib.bib7))。这样的团队需要一个在不同批次间可靠的过程；因此，我们沿着第 1 节 (https://arxiv.org/html/2609.05736#S1) 的四个轴评估搜索过程本身。

## 3 评估协议与指标

我们评估返回固定目标模型框架的优化器程序。该协议是优化器无关的：它将每个程序视为返回候选框架的黑盒，声明其预记分卡搜索成本，然后在保留的记分卡数据上进行评估。

#### 角色划分。

每次运行将基准数据分为三个角色，在整个论文中使用。*修复*分割 D_repair 用于提出和测试框架编辑。*门控*分割 D_gate 用于接受候选方案，并进行最终的记分卡前选择。*记分卡*分割 D_score 在整个搜索过程中被保留，且仅在最终报告时触及一次。开发数据意味着修复和门控数据的并集。除非另有说明，基线框架和返回框架在相同的记分卡案例上进行评估，因此提升是配对比较。

#### 基准接口。

对于基准 b、框架 h、数据分割 D 和报告指标 m，令 S_{b,m}(h, D) ∈ [0,1] 为基准原生分数，当基准报告实例分数时，取所有实例分数的平均值。无效执行（崩溃、超时、无效操作、协议违规）根据基准的失败规则进行计数。

#### 有效性。

令 h₀ 为基线框架。对于运行 i，令 hᵢ 为在记分卡评估前返回的框架。保留记分卡提升为

Δᵢ,ₘ = S_{b,m}(hᵢ, D_{score,i}) - S_{b,m}(h₀, D_{score,i})，

以百分点报告。MeanLiftₘ 是各次运行的平均配对提升，报告时附带配对置信区间。

#### 稳定性与可重复性。

为衡量改进是否依赖于开发数据，我们在预定义的条件下重复相同的协议：随机分割、故障来源、领域或时间批次的到达生产故障。WorstLiftₘ 是跨条件的最低平均提升（最弱的批次），RepRateδ,ₘ 是提升至少为 δ 的运行比例，其中 RepRate₀,ₘ（RR₀）是提升为正的运行比例。

#### 效率与预算约束可靠提升。

效率询问在固定的预记分卡搜索预算下，一个程序可以可靠地获得多少保留提升。对于运行 i，令 Cᵢ 为在声明的会计约定下的预记分卡搜索成本，涵盖最终记分卡评估之前的搜索时间活动（提案、候选评估、过滤、修复和选择）；最终的保留记分卡评估总是被排除在外，并且给定约定中定价的组件会随约定一起说明（我们的定义在附录 F (https://arxiv.org/html/2609.05736#A6) 中）。令 \bar{C} 为各次运行的平均成本。在预算 B 下，可负担的独立优化器运行次数为 N_B = ⌊B / \bar{C}⌋。每次运行返回一个框架 hᵢ 和一个预记分卡选择统计量 Gᵢ（门控分数、验证分数或优化器的内部预记分卡标准），计算时不访问 D_score。在预算 B 下，我们在可负担的 N_B 次运行中选择 i*(B) = argmax_{i∈R_B} Gᵢ，选定框架的保留提升为 L_B = Δ_{i*(B), m}。我们的预算约束可靠提升指标为

RelLift_γ(B) = Q_{1-γ}(L_B)，

即在重复使用相同协议下选定保留提升的下 (1-γ) 分位数，通过在观察到的优化器运行上进行自助法估计：每个自助样本有放回地抽取 N_B 次运行，选择预记分卡统计量 Gᵢ 最高的运行，并记录所选运行的保留提升。RelLift 是一个*部署侧*诊断指标，特意置于优化器循环之外：它是经验性的下尾估计，并非对未来记分卡、模拟器种子或修复分布的覆盖保证。使用记分卡信息选择的结果仅作为预言机上限报告。

## 4 实验

每个优化器在固定的执行预算下进行搜索，仅使用预记分卡信息选择一个框架，并在保留的记分卡案例上评估一次。主要比较使用 gpt-5.4-mini 作为内部执行模型，claude-opus-4.7 作为外部提案模型；第 6.2 节 (https://arxiv.org/html/2609.05736#S6.SS2) 在固定另一个角色的情况下变化每个角色。

### 4.1 基准测试

我们在 BFCL 多轮和 τ²-bench 的两个领域：τ²-Retail 和 τ²-Telecom 上进行评估。BFCL 测试可执行的多步函数调用：如果最终工具调用状态与基准预言机匹配，则用例通过。τ²-bench 领域测试具有对话状态、任务策略和工具介导状态变更的模拟服务智能体；如果最终模拟器结果满足基准成功标准，则用例通过。我们报告 BFCL 使用 pass¹，τ² 领域使用基准的 pass⁴ 实现（每个任务四次模拟器执行）。这些任务强调不同的故障模式：BFCL 强调在固定 API 下的模式正确调用，而 τ² 领域增加了更长期的策略遵循、状态跟踪、缺失信息恢复和模拟器随机性。

### 4.2 运行协议

每个优化器运行使用第 3 节 (https://arxiv.org/html/2609.05736#S3) 中定义的互斥的修复、门控和记分卡分割。对于 BFCL，每次运行使用 100 个修复案例、100 个门控案例和一个互斥的 600 案例记分卡分割，分割在每个种子下独立重新抽取。对于每个 τ²-bench 领域，记分卡分割包含 74 个任务实例；修复和门控的大小在附录 E.4 (https://arxiv.org/html/2609.05736#A5.SS4) 中报告。在 τ² 领域，四个分割种子的抽取方式使得四个修复集两两互斥，四个门控集也两两互斥（每个领域的 114 个任务中，每个角色占 4×20=80 个），因此每次运行必须从不同批次的故障案例中改进框架，模拟部署团队随时间收到的互斥错误批次。在单个种子内，修复、门控和记分卡分割是互斥的；跨种子时，由于每个种子的记分卡保留了 114 个任务中的 74 个，一个种子的修复集可能与另一个种子的门控或记分卡集重叠。在此解读下，WorstLift 是最弱的批次，RR₀ 是程序仍然交付结果的批次比例。每个基准-优化器组合针对四个分割种子，每个种子下最多进行四次相同协议的独立重复。