超越 Prompt 工程：LLM Tool-Agent Harness 的量化测量与优化协议 · 干货攻略

链接: https://arxiv.org/abs/2609.05736
分类: x-tips
来源: X @hwchase17 (Harrison Chase)
作者: Jay
更新: 2026-09-11

这是什么

论文 "Beyond Prompts: Measuring and Optimizing LLM Tool-Agent Harnesses"（arXiv:2609.05736，EMNLP 2026）来自 Airbnb 团队，核心贡献有两层：

第一层：量化评估协议。 论文指出，对 harness（围绕固定模型的运行时控制层）的优化效果不能只看均值提升，必须在预算约束下评估"可靠提升"。为此论文提出 RelLift95(B) 指标——在预算 B 下，对 5000 次 held-out 实验取 5% 分位数，作为保守可靠提升估计。

第二层：PRISM 优化器。 基于"故障根因路由"的进化算法，将 Agent 失败聚类后分配到不同的修复表面（Prompt / Middleware / Joint）分别突变，而非把一切丢给同一个 prompt 优化器。

Harness 在此语境的定义：围绕固定模型的运行时控制层，包含 prompts、tool interfaces、context construction、state management、middleware、recovery logic 和 evaluation hooks。论文特别强调：edits are guarded intercepts at the tool boundary, not arbitrary rewriting of agent execution logic（编辑是 tool boundary 上的受守护拦截，而非对 Agent 执行逻辑的任意改写）。

为什么值得关注

谁分享的：@hwchase17（Harrison Chase，LangChain CEO）于 2026-09-10 发帖推荐，LangChain 官方博客随后发文详解。

解决什么问题：当前 Agent 开发中一个普遍困境——换 harness 带来了大分数提升，但这个提升依赖搜索时见过的修复样本、随机 optimizer 选择的偶然性、以及评估本身的方差。换一批测试数据，分数可能大打折扣。论文将这个问题形式化为预算受限的 harness 选择，并给出可操作的评估框架。

LangChain 的工程佐证：LangChain 博客记录了一次真实实验（Terminal Bench 2.0，GPT-5.2-Codex）——仅改 harness，52.8% → 66.5%，提升 13.7 分。他们的做法是先 trace 全量错误，再将错误分析封装为 Agent Skill，批量生成修复建议，最后定向修改 system prompt / tools / middleware 三类组件。这与论文中 PRISM 的"故障路由"思路高度一致。

** Bookmark 价值**：无论你是在做 Agent 评测、还是生产环境调优，都会遇到"分数看起来好了但不稳定"的问题。这篇论文给出了系统性的度量框架和 PRISM 这个可复用的优化思路。

核验过程

官方来源

arXiv abstract + HTML 全文（https://arxiv.org/abs/2609.05736，2026-09-04 v1，2026-09-09 v2）： - RelLift95(B) 定义：取 5000 次 held-out 实验的 5% 分位数，量化预算 B 下的保守可靠提升。 - PRISM 在 BFCL multi-round、τ²-Retail、τ²-Telecom 三个 benchmark 上分别取得 +14.2 pp、+14.9 pp、+10.1 pp 的 mean held-out lift，且三 benchmark 均得到正的 RelLift95。 - PRISM 为 factorized evolutionary optimizer，population cap 5，十代进化；每代做三件事：选最优 viable frontier parent、用 analyst LLM 按 root cause 将失败聚类（标记修复表面为 Prompt / Middleware / Joint）、路由到对应 mutation slot。 - 消融实验（§6.1）证明增益主要来自 failure-surface routing 和 edit-pattern constraint，而非 inherited GEPA skeleton。 - 基线对比：BetterHarness-style hill climbing、MIPROv2、GEPA。 - 18 页，9 图，10 表，EMNLP 2026 接收。

LangChain 官方博客（https://www.langchain.com/blog/improving-deep-agents-with-harness-engineering）： - 验证了 harness 工程在生产中的落地路径：Terminal Bench 2.0，GPT-5.2-Codex，仅改 harness，52.8% → 66.5%（+13.7 pp）。 - LangChain 对 harness 的 knob 分类与论文一致：System Prompt、Tools、Middleware。 - 关键实践：trace 全量错误 → 批量分析 → 定向修改；与论文的 failure routing 思路吻合。

交叉验证

搜索 "PRISM harness optimizer LLM agent tool agent"：搜索结果均指向 arxiv:2609.05736 的同一摘要，无其他独立来源给出不同数字。PRISM 的 benchmark 数字（14.2 / 14.9 / 10.1 pp）在搜索结果中一致复现。

搜索 "Harness Engineering for LLM Agents Survey"：一篇 survey（preprints.org, 2026.06）引用了本论文，将其置于 harness optimization 的学术脉络中，与 DSPy MIPROv2、TextGrad、GEPA、Meta-Harness 并列，证实了论文在领域内的位置。

LangChain 博客（另一篇）：Prosus AI Tech Blog 的 "Beyond Prompt Optimization: Optimizing the Whole Agent Harness" 进一步扩展了 meta-harness 概念（可修改 planner/executor 边界和 dispatcher），与论文结论互补。

官方说法与原帖的差异

原帖（@hwchase17）描述本文"把 harness 优化建模为预算选择，edits 是 tool boundary 上的 guarded intercepts 而非 rewrite"——这一描述与论文 abstract 中的表述完全一致，无冲突。

⚠️ 未核验处：论文未公开 GitHub repo（截至 2026-09-11），PRISM 的具体实现细节（如 analyst LLM 的 prompt、mutation operator 的具体形式）需要读 PDF 才能确认，攻略正文基于 abstract 和 HTML 页面的信息，不含未核验的性能数字。

⚠️ 未核验处：τ²-Retail 和 τ²-Telecom 的具体任务类型和难度分布，原帖和 abstract 均未展开，仅以 benchmark 名称出现。

上手步骤

理解 harness 的三层组件

Harness = {
  Prompt:        system prompt / instructions
  Tools:         tool interfaces + schema
  Middleware:    hooks around model calls & tool calls
  State:         context construction / state management
  Recovery:      retry logic / fallback strategies
  Eval:          evaluation hooks + scoring
}

论文将优化范围限制在 Prompt + Middleware 两个表面，并要求 edits 是 tool boundary 上的受守护拦截。

评估协议：RelLift95(B)

核心指标定义（来自论文）：

RelLift95(B) = Quantile_0.05({z_j}_{j=1}^{5000})

其中 z_j = Δ_{i_j}，是第 j 次预算 B 下的 held-out lift。不是均值，而是 5% 分位数*——意味着在最差的 5% 情况下 harnness 仍能带来多少提升。这是一个比 mean 更保守、更能反映"可靠性"的指标。

四个评估维度： 1. Effectiveness：mean held-out lift（均值提升） 2. Repair-distribution robustness：修复集变换后 lift 是否持续 3. Same-protocol repeatability：同一协议多次运行是否复现 4. Efficiency：预算 B 下可靠提升的代价

PRISM 的工作流

For each generation (up to 10):
  1. Select best viable frontier parent
  2. Analyst LLM clusters failures by root cause
     → label each cluster's fix surface: Prompt | Middleware | Joint
  3. Route clusters to 3 constrained mutation slots
  4. Pareto retention: keep candidates by pass rate + reliability
  5. Return selected harness with RelLift95(B) report

LangChain 的工程实践（生产参考）

Step 1: Run agent on benchmark → collect full traces in LangSmith
Step 2: Spawn parallel error-analysis agents
         → synthesize findings across runs
Step 3: Aggregate feedback → targeted harness changes
         (System Prompt / Tools / Middleware)
Step 4: Re-run eval → compare RelLift95

他们的 Middleware 示例：PreCompletionChecklistMiddleware（在 Agent 退出前注入检查清单，强制做一次验证 pass）。这正是论文所说"middleware helps when failures are locally observable and checkable at the tool boundary"的工程实现。

关键工程工具链（社区延伸）

Strands Harness Optimizer（strands-labs/harness-optimizer）：开源实现，将 Formula 作为可优化参数，用 rollout trajectory 更新，benchmark 报告 AppWorld 72.6% → 95.8%。
Harbor（harborframework.com）：benchmark 编排工具，支持 sandbox 管理和自动评分。
Opik（Comet）：Agent 评测 + trace + prompt 版本管理一体化平台。
LangSmith：trace 全量 LLM 调用和中间状态。

坑与适用边界

1. harness 改进不解决模型能力不足的问题 论文明确：优化的是 harness，不是模型本身。如果模型在某个任务上根本不具备能力，harness 调优是有限度的。

2. RelLift95 需要足够大的采样 RelLift95 基于 5000 次 held-out 实验，对小团队来说评测成本高。如果只跑几十个样本，RelLift95 不可信。

3. Middleware 不是银弹 论文将 middleware 定位为"tool boundary 上的可检查失败"的拦截点。涉及 Agent 内部决策逻辑的错误，middleware 无法修复，需要改 Prompt 或 Joint。

4. benchmark 过拟合风险 BFCL、τ²-bench 都是特定格式的 tool calling 评测。如果你的 Agent 场景不在这些 benchmark 覆盖的范围内，PRISM 的超参数（population=5，generations=10）可能需要重新调优。

5. "edits as guarded intercepts" 是约束不是优势 论文有意将搜索范围限制在 tool boundary，是为了可检查性和安全性。但这意味着复杂的跨步骤推理优化不适用这个框架。

一句话结论

PRISM 将 Agent harness 的故障修复路由到 Prompt / Middleware / Joint 三个表面，并在 Pareto 前沿上同时优化 pass rate 和可靠性，配合 RelLift95(B) 指标给出预算约束下的保守提升估计——这比单纯报告均值提升更能反映生产环境中的真实收益。

核验来源：arXiv:2609.05736 (EMNLP 2026) · LangChain 官方博客 · strands-labs/harness-optimizer (GitHub) · ai-boost/awesome-harness-engineering