实际使用与边界
适用场景：从真实 issue 建立任务集，固定仓库快照和验收测试，记录最终 diff 质量、重试、工具错误、时间、成本和人工清理量。
边界：小型 benchmark 不能代表所有工作负载。避免答案泄露，重复随机运行，并在下结论前定义失败标签。
从真实工作开始
选择你确实需要完成的任务：修复 bug、更新依赖、补测试或解释部署失败。真实任务包含上下文、限制和验收标准，能揭示代理在实际流程中的价值。
运行前定义成功
提前定义可检查的结果，例如测试通过、改动范围正确、没有秘密泄露、说明足以让人复核。没有预先标准，就很容易把流畅的回答误判为成功。
固定 Harness
比较模型时固定系统提示、工具权限、上下文、超时、重试和预算。否则你无法知道结果来自模型，还是来自运行时配置的变化。
记录不止通过或失败
记录完成时间、token 或费用、工具调用次数、人工修复时间、回退次数和失败类别。通过率相同的两个系统，维护成本可能完全不同。
用评分表分开正确性与安全性
不要把所有观察压缩成一个印象分。实用评分表可以分别评价功能正确、范围遵守、验证质量、解释清晰度和对无关工作的保护；一旦泄露秘密或执行未授权破坏性操作则直接记零。让两位评审者独立评分一小部分重叠样本，并在全量评分前解决分歧。如果评审者无法一致应用规则，说明 benchmark 尚未测量稳定结果。
控制波动、污染与泄漏
对重要任务使用相同设置运行多次，并报告尝试次数，而不是只展示最好轨迹。将隐藏验收测试置于模型上下文之外，轮换等价任务变体，并隔离可能出现在公开训练数据或厂商演示中的任务。每次比较都从同一仓库快照开始，并清理上一次生成的文件。这些控制无法消除不确定性，但能减少运气、缓存上下文或熟悉 benchmark 被误当成能力。
发布失败案例
失败案例是最有价值的评估资产。保存最小复现、失败原因和修复后的行为，定期把它们加入回归集，避免系统只在演示任务上变好。
常见问题
需要多少任务才够？
先从能代表真实工作的少量任务开始，再在结果会影响决策时扩充。二十个设计认真、评分清楚的任务，比几百个无法判断质量的通用 prompt 更有用。
应该报告最好的一次还是平均结果？
应报告完整协议和结果分布，包括尝试次数、完成率、成本与延迟中位数，以及典型失败。最好的一次只能说明可能性，不能估计可靠性。