实验 08 · Agent 版本评测台

对应第 27 章。本实验用一个教学模拟任务集比较基线 v0 与候选 v1，练习在成功率、错误完成、安全事件和成本之间做发布判断。

1. 实验问题

Agent 改进往往有代价：重试提高成功率也增加调用成本；严格审批降低事故也可能阻塞任务；压缩降低 Token 但可能遗漏细节。只看一个指标会鼓励错误优化。

先把工具故障率调高，选择“重试 + 验证”；再选择“全部组合”，观察指标如何同时变化。

2. 运行评测

页面明确标注模拟分数。这些数值不是 Codex、Claude Code 或任何模型的真实基准。实验价值在于定义指标和门槛，而不是相信虚构数字。

3. 为什么错误完成重要

任务成功率通常只统计外部验收通过。模型自己说“完成”但测试失败，属于 false completion。它比诚实的 blocked 更危险，因为用户可能基于错误结论继续行动。

验证闭环会降低错误完成，但需要额外命令和时间。评测要把成本与可靠性一起报告。

4. 设计真实任务集

为 Mini Codex 建立至少十类任务：单文件修复、跨文件功能、模糊需求、权限不足、瞬时 API 故障、大日志、已有用户修改、补丁冲突、测试不可用和不可能任务。

每项包含：

• 固定仓库基点；
• 用户目标和允许权限；
• 独立验收脚本；
• 安全检查；
• 最大预算；
• 多次重复运行。

隐藏验收，防止 Agent 直接迎合测试。

5. Trace 定位退化

候选版成功率下降时，读取失败轨迹并分类：搜索没找到入口、摘要丢失规则、重试重复副作用、沙箱过严、测试选择不足。修复工具或 Runtime 根因，而不是盲目增加 prompt。

每个真实事故都应转成回归任务。长期改进来自失败样本积累，而不是只展示最好的一次 demo。

6. 发布门槛

定义不可交换的红线，例如安全事件不能增加、错误完成必须低于阈值；再定义可权衡指标，例如成本上涨 10% 是否换来成功率提升 15%。门槛由业务风险决定，不由模型自动发明。

完成实验后，为自己的 Agent 写一张版本卡：改了什么、预期影响什么指标、任务集结果、残余风险和回滚条件。这就是从玩具迭代走向生产工程的最后一步。