主题
第 18 章 · Agent 调优总览
核心观点 + 逻辑框架（调优篇 · 数据飞轮：运行事实 → 可复用样本 → 验证的改动）
▍速览
一句话版（开场，约 20 秒）
Agent 上线后要持续回答两组问题：任务有没有做好，以及做好花了多少代价。调优的本质是数据飞轮——把每次真实运行留下的事实整理成可复用样本，用评估找出问题，用实验检验修改，再把验证有效的变更带回运行环境，让下一轮真实任务提供新反馈。会做、做完和稳定交付是三个层次，必须在自己业务上建立评估。
一段话版（完整表达，约 90 秒）
传统应用靠代码规定行为，Agent 把一部分决策交给模型，同一个任务可能走出不同路径，对话顺利结束、接口没有报错都不足以说明办对了。公开基准也提醒这一点：会做、做完和稳定交付是不同层次——OSWorld 2.0 长流程任务严格完成率只有 20.6% 而部分得分 54.8%，τ-bench 的 pass¹ 是 61.2%、同一任务八次全成功的 pass⁸ 低于 25%。因此上线后要持续回答两组问题：任务有没有做好、做好花了多少代价——回答正确的轨迹可能反复查了相同资料，Token 减少的执行也可能省掉了必要验证。数据飞轮把一次执行留下的事实整理成可复用样本，用评估发现问题、用实验检验修改、把有效变更带回运行环境。架构分三段：运行事实与数据生产（Agent 运行→Trace/Trajectory→Pipeline 清洗提取→业务 Dataset→AI 标注与人工复核）、持续评估标注与质量资产（评估结果与证据、持续评估、黄金/回归版本）、优化候选对照实验与运行反馈（问题与候选、实验计划、实验结果评估、受控发布）。两条反馈路径同时推进：改进数据和判断方法（题目级 Rubric），改进 Agent 行为（Skill/工具描述/重试逻辑）。模块边界要守住：轨迹组织不能凭空补出业务事实，Pipeline 不能替代人工确认，评估不能代替候选执行，保存了一个版本不等于运行中的 Agent 已经使用它。第一轮从一个业务问题开始走完闭环——找真实问题、持续收集、把业务要求写成带 rubric 的题库、先知道哪里没做好、让新旧两版做同一份题、采用有效方案继续接收反馈。
- 命题 上线后持续回答两组问题：任务有没有做好、做好花了多少代价
- 层次 会做 / 做完 / 稳定交付是三个层次，须自建评估
- 闭环 数据飞轮：轨迹→Pipeline→Dataset→评估→实验→变更回运行
- 边界 各模块不越权：轨迹不补事实、Pipeline 不代人工、评估不代执行
- 起步 从业务问题走通第一轮六步，留下题库+评分+管线
收尾
没有分数只有修改方向会盲改，有了分数没有闭环会空转——评估与调优必须通过真实任务连起来。
▍逻辑框架（记忆卡片）
① 命题：数据飞轮——把运行经验变成经过验证的改进
- 一次排障修好眼前问题，未必帮得了下一次：原因在工程师记忆里、Trace 散在日志里、修复记录在另一个系统，几周后同类问题换表述再现，仍然从头查
- 飞轮动作：整理运行事实为可复用样本 → 评估找出问题 → 实验检验修改 → 带回有效变更 → 新任务结果提供下一轮反馈
- 数据在调优中承担两种作用：帮助判断应该改哪里，也帮助拒绝没有效果或带来退化的修改——样本增加、经验入库、候选生成都只是过程产物
有效变更进入运行后，新任务的结果才提供下一轮反馈；评估负责把"好不好"落实为可检查的标准，调优负责据此改变系统。
② 三层次：会做、做完与稳定交付
- 传统应用：代码规定行为，确定性逻辑可预测可复现，围绕功能契约写测试
- Agent：目标、工具、约束交给运行时决策，同一任务因上下文/反馈/生成不同走出不同路径；接口没报错 ≠ 办对了（退款要确认是哪笔订单、适用规则、结果核实）
公开基准证据（快照，非当前最高分）：SWE-Bench Pro GPT-5.4 端到端 57.7% ｜ OSWorld-Verified GPT-5.4 75.0%、人类 72.4% ｜ OSWorld 2.0 长流程严格完成率 20.6% vs 部分得分 54.8%（完成中间步骤≠交付完整结果）｜ τ-bench pass¹ 61.2%、pass⁸ 低于 25%（一次做对≠重复可靠）。必须在自己业务上建立评估。
- 左：传统应用 执行路径：检查代码规定的固定分支 正确性：验证接口契约与状态转换 故障定位：查找代码或依赖的异常 变更验证：检查功能与历史场景
- 右：Agent 应用 执行路径：看模型为何选此路、反馈怎样影响后续行动 正确性：同时验目标达成 + 业务约束 + 交付结果 故障定位：区分理解 / 上下文 / 工具使用 / 恢复策略 变更验证：观察重复执行稳定性 + 质量·成本·延迟
③ 两条反馈路径
- 改进数据和判断方法：运行结果暴露评估标准不合适（"有哪些功能"与"如何配置评估"两类题的规则写在同一评估器里），改为 Dataset 题目级 Rubric 逐题填写，修改变量映射重跑实验
- 改进 Agent 行为：评估确认缺配置步骤→补 Skill；工具用错→改工具描述；超时反复提交→查重试与结果核实逻辑；修改先成候选，经同条件实验与回归再决定采用
两条路径同时推进；运行结果既改进判断标准，也改进执行行为。
④ 模块地图：主干与旁路
- 主干：真实运行 → 轨迹组织（Trace→Trajectory）→ Pipeline 加工（任务组织/清洗去重/字段提取/场景筛选，按范围或周期执行）→ 不同用途 Dataset → 评估与实验 → 优化
- 旁路：AI 标注 Pipeline（独立标注任务、更新原集合标注字段）、人工复核（保留机器结论与人工纠正）、复核评语校准 Evaluator 标准与版本
- 模块使用：Trace/Trajectory 找答错/反复操作/耗时长原因；Pipeline 把运行记录变成质检和评估器可直接用的样本；Dataset+复核积累可复用验收题；Evaluator 持续评估发现需改进场景；Experiment 新旧同题对比决定是否换模型/Prompt/上线改动；Trace2Optimizers 把有效方法沉淀为 Skill/工具/经验召回
各模块不必排成只能向前走的流水线：评估结果写回 Dataset 供复核，复核修正样本或评估器，优化候选回实验，已采用的 Skill/Harness/经验又改变后续轨迹；发布接入 Agent 所在系统的交付流程。
⑤ 模块边界四不
- 轨迹组织不能凭空补出业务事实：超时后再次提交、第一次已成功——必须先补齐业务结果并建立关联，轨迹与 Pipeline 才能把相关调用组织为同一任务样本
- Pipeline 不能替代人工确认：业务口径、参考答案与评分要求由产品/业务人员确认
- 评估不能代替候选执行：评估指出结果核实有问题，改动是否有效必须由实验验证，实验要覆盖成功、失败、结果不确定
- 保存了一个版本 ≠ 运行中的 Agent 已经使用它：发布走交付流程，采用前先受控
各环节把自己的输入、产物与实际执行记录关联起来，才能沿着结果追到原因、再沿变更检查效果。
⑥ 第一轮六步：从业务问题开始走通
- 1 找到真实问题：选团队确实想解决的（客服漏操作步骤/研发反复读同一批日志/报告引用过期数据），在 Agent 轨迹中打开用户仍在追问的任务
- 2 持续收集：少量直接入数据集；需日常质检就建 Pipeline，提取问题/回答/轨迹引用，预览后持续写入候选集
- 3 把业务要求写成题库：产品/客服确认参考答案，每题 rubric 写明应含步骤，选入黄金集
- 4 先知道哪里没做好：建评估器对已知题试评，确认能指出遗漏再用于真实任务；持续评估找新问题，人工补回题库
- 5 让两个版本都做题：补 Skill 或调知识与 Prompt，同一份黄金集跑新旧两版，看目标题改善、正常题不退化、成本时延可接受
- 6 采用并继续反馈：验证通过的版本交应用发布流程，确认实际生效；新问题继续成为下一轮题目
一轮留下的不止一个改过的 Prompt，还有可复用题库、评分要求、改动前后结果、持续收集的管线——换模型或升级产品时直接续用。分工：业务人员确认目标与正确要求，应用团队改动接入，测试运营用固定题库+运行反馈检查效果。
▍逻辑全景图（数据飞轮三段闭环：生产 → 评估标注 → 实验反馈）
Pipeline 生产数据，标注沉淀基准，评估发现问题，实验验证候选；有效变更回到真实任务
- 01 运行事实与数据生产
- 02 持续评估标注与质量资产
- 03 优化候选、对照实验与运行反馈
示意 · 按原书图 1 Agent 数据飞轮总体架构重绘
▍书中关键图（SVG 重绘版·示意）① 会做 / 做完 / 稳定交付：四个基准的证据
| 基准 | 考察能力 | 结果 | 模型（时间） | 读法 |
|---|---|---|---|---|
| SWE-Bench Pro | 软件工程端到端完成 | 57.7% | GPT-5.4（2026-03） | 在该任务与配置下，端到端完成仍有改进空间 |
| OSWorld-Verified | 桌面操作 | 75.0% / 47.3%；人类参考 72.4% | GPT-5.4 / GPT-5.2 | 能力进步快，业务交付仍要逐项确认 |
| OSWorld 2.0 | 长流程（108 任务 / 500 步） | 严格 20.6%；部分得分 54.8% | Claude Opus 4.8（2026-07） | 完成许多中间步骤 ≠ 交付完整结果 |
| τ-bench | 业务规则 + 用户交互 | pass¹ 61.2%；pass⁸ 低于 25% | GPT-4o 零售任务（2024-06） | 一次做对之后，还要检查重复执行可靠性 |
| 共同边界 | 会做（能部分完成）→ 做完（严格完成）→ 稳定交付（重复可靠），三个层次各有证据 | — | — | 快照代表各自测试条件下的结果，不代表当前最高分，也不能直接换算为企业业务成功率；pass⁸ = 同一任务八次执行全部成功，区别于“八次中至少成功一次”的 pass@8；部分得分不等于完整成功率 |
示意 · 按原书第 18.1 节 Benchmark 表重绘