同一配置的 Agent这次成功、下次失败不能靠“多跑几次挑最好的一次”判断稳定性。先固定初始状态和验收规则给每次执行留一行记录再分别统计单次完成、至少成功一次、全部成功以及重试的代价。比如同一个设备清单整理任务第一次正确输出了汇总表第二次却漏掉异常清单。模型和提示词都没改但运行起点、工具返回、执行路径或判定过程仍可能不同。下面用设备清单做一套可照着执行的重复运行测试。任务、逐次结果和费用均为构造示例概率数字为数学演示均非 EvalDock 或任何产品实测。本文保持同一套配置重复执行比较新旧版本是否退步需要另行设计回归测试。1. 把“任务”“尝试”“用户请求”分开Anthropic 的 Agent 评测方法文章区分 task 与 trial任务规定输入和成功标准尝试是该任务的一次执行并强调每次从干净环境开始。在测试计划里先约定三个单位单位本教程中的含义记录方式任务 task固定指令、输入和验收规则的组合一个 task_id 对应一套冻结材料尝试 attempt从规定起点到结束的一次完整执行每次分配新 attempt_id失败也保留请求 request用户的一次提交可包含产品预设的内部重试关联各次尝试汇总最终结果和总成本这里把一次工具调用的自动重试放在当前尝试内另记次数重新初始化并重启整个任务算新尝试。换成其他定义也可以但必须预先说明不能统计时临时换分母。2. 先冻结起点再开始重复运行构造任务读取设备清单 CSV按部门统计设备数量缺失部门的设备另列异常清单相同设备编号按约定去重保留原文件。下面是含缺失部门的输入device_id,department D001,研发 D002,销售 D003, D004,研发该输入应得到“研发 2 台、销售 1 台”和异常设备 D003。成功必须同时满足汇总正确、异常完整、两份文件都可读取、原输入未改动并在预定时限内完成。不能只听 Agent 说“已完成”。另准备“部门完整”和“重复设备编号”两个输入。重复编号的规则要在任务里写明例如完全相同的记录只计一次、部门冲突的同编号记录转异常不能让 Agent 自行猜测业务规则。每次启动前按下面的清单检查检查项可直接采用的做法输入与验收冻结指令、CSV、参考结果、验收脚本保存校验值Agent 配置记录 Agent、模型标识、工具版本、提示词、采样参数、权限及资源上限文件与数据从只读快照复制到新的尝试目录恢复数据库、缓存、记忆等相关状态对话历史新建会话如任务依赖历史每次加载同一份初始历史输出与证据各次产物和日志分别保存验收结束后也不覆盖外部依赖记录实际响应、时间、限流和服务异常版本不可固定时注明把温度设为 0或把随机种子固定住都不能代替以上检查。若每次重置为同一随机种子只产生同一路径这反映的是该设置下的重复性要观察日常使用中的采样波动应按预先约定的方式使用独立采样并记录可控种子。执行顺序是校验起点 → 新建会话 → 运行 → 保存产物与调用记录 → 验收 → 追加记录 → 恢复起点。失败后在原会话继续提示属于恢复流程应单独统计。把工具返回固定下来可以帮助诊断但这类实验与真实外部服务条件分开报告。3. 每次追加一行失败不能被补跑替换以下是可复制的记录表头引用字段指向完整的配置、产物和证据敏感凭证不进入记录。task_id,attempt_id,request_id,config_ref,input_sha256,initial_state_ref,grader_ref,started_at,ended_at,verdict,failed_checks,artifact_ref,trace_ref,tool_retries,human_help,elapsed_seconds,cost,currency,dependency_error,excluded_reason,rerun_ofverdict建议区分 pass、fail、timeout、infra_error计算“能否拿到交付”时后三类均未通过。执行失败但未产生文件也必须留一行。尚未执行或计划缺失的次数单列不能伪装成已执行失败。费用拿不到时填 unknown不能填 0。人工补充提示要留记录补跑新建 attempt_id并通过 rerun_of 指向原尝试。诊断 Agent 能力时可以按事先约定单列已确认的设施故障但需要同时报告排除前后的分母、数量与理由。原始记录始终保留。下面是构造数据非实测同一配置3 个任务各从相同起点执行 5 次不进行人工补充或整任务内部重启。固定输入任务第 1 次第 2 次第 3 次第 4 次第 5 次通过部门字段完整通过通过通过通过通过5/5包含部门缺失通过失败通过失败通过3/5含重复设备记录失败失败通过失败失败1/5这里是3 个任务、15 次尝试、9 次通过尝试通过比例为 60%。三个任务都至少成功一次只有一个任务五次全部成功。前者适合展示“存在可用解”后者暴露了重复使用时的波动。五次只是示例规模不是“测五次就够”的建议。各任务尝试数不同时整体尝试通过比例会给运行次数多的任务更大权重任务等权平均应另算不能默认两者相等。4. passk 和 pass^k先确定要回答什么τ-bench 原始论文第 3 节把 passk 用于“同一任务 k 次独立同分布尝试中至少一次成功”把 pass^k 用于“k 次全部成功”然后在任务之间取平均。k 是每任务尝试次数。若某个固定任务的真实单次成功概率为 p且各次尝试独立同分布则有以下理论概率至少一次成功1 - (1 - p)^k 全部成功 p^k理论演示假设 p0.75、k3两者分别为 98.4375% 和 42.1875%。这是给定概率模型的计算与上表的观测估计不同也不是产品成绩。同一个固定任务“至少成功一次”和“每次都成功”回答不同问题。图中概率来自独立同分布假设非实测指标定义见 τ-bench 第 3 节EvalDock 团队绘制。实际只拿到每任务 n 次尝试、其中 c 次通过时可按论文使用组合数估计要求 1≤k≤n单任务 passk 估计 1 - C(n-c, k) / C(n, k) 单任务 pass^k 估计 C(c, k) / C(n, k)C(a,k) 表示组合数ak 时取 0分别算完每个任务再按明确的任务权重汇总。这些估计的概率解释仍依赖规定的采样条件。对于共享故障、继承状态或根据上次失败修改提示的重试不能直接宣称是独立尝试。代码生成评测原始论文给出了 passk 的组合数估计并说明把有限样本通过比例当作真实 p 代入幂公式会产生偏差。除此之外不同任务的 p 也可能不同即便知道各任务真实 p也应逐任务计算后平均不能先平均 p 再做幂运算。5. 用 Python 复算构造记录把以下代码保存为repeatability_demo.py使用 Python 3.8 或以上运行python3 repeatability_demo.py。只依赖标准库不会调用 Agent也不会发起付费请求。它计算前表的构造记录k3。fromfractionsimportFractionfrommathimportcomb# 构造数据非任何产品实测1完整验收通过0未通过。runs{完整:[1,1,1,1,1],缺失:[1,0,1,0,1],重复:[0,0,1,0,0],}k3defchoose(a,b):returncomb(a,b)ifabelse0defestimates(values,k):n,clen(values),sum(values)ifnot1knorany(vnotin(0,1)forvinvalues):raiseValueError(需要二元结果且 1 k 尝试次数)denominatorcomb(n,k)return(1-Fraction(choose(n-c,k),denominator),Fraction(choose(c,k),denominator),)results[]fortask,valuesinruns.items():at_k,all_kestimates(values,k)results.append((at_k,all_k))print(f{task}:{sum(values)}/{len(values)}, fpass{k}{float(at_k):.2%}, pass^{k}{float(all_k):.2%})successessum(sum(v)forvinruns.values())attemptssum(len(v)forvinruns.values())print(f任务{len(runs)}, 尝试{attempts}, 通过{successes}, f尝试通过比例{successes/attempts:.2%})print(f任务等权: pass{k}f{float(sum(x[0]forxinresults)/len(results)):.2%}, fpass^{k}f{float(sum(x[1]forxinresults)/len(results)):.2%})预期输出完整: 5/5, pass3100.00%, pass^3100.00% 缺失: 3/5, pass3100.00%, pass^310.00% 重复: 1/5, pass360.00%, pass^30.00% 任务3, 尝试15, 通过9, 尝试通过比例60.00% 任务等权: pass386.67%, pass^336.67%例如“缺失”任务共有 C(5,3)10 种三次组合只有 C(3,3)1 种全部成功因此 pass^3 估计为 10%。样本中的三次组合总能包含成功但pass3 估计为 100% 不等于未来保证成功。样本量与不确定性仍须报告。如果误将总体 60% 代入幂公式会得到 93.6% 和 21.6%两者都不是这组数据按上述组合数方法算出的任务等权估计。脚本用 Fraction 保留小样本的精确分数大规模统计应另行考虑计算效率与数值稳定性。6. 多试几次还要算能否选对以及付出多少passk 适合关注候选中是否出现可用结果的场景。但“五份候选里有正确答案”不等于产品最终选中了正确答案。应分别记录候选可用性、选中结果是否通过、筛选成本。重试代价构造示例一次用户请求允许最多三次尝试验收通过就停止。第一次失败用时 40 秒、费用 0.08 元第二次通过用时 55 秒、费用 0.11 元另有 10 秒等待人工检查 30 秒。可以记录“首次失败第二次通过实际执行 2 次机器执行与等待共 105 秒人工检查 30 秒可见调用费用合计 0.19 元”。若这些步骤顺序发生用户等待到检查完成共 135 秒。没有发生的第三次尝试不计入执行次数。费用单位、覆盖范围和未知费用要注明不能只报告最后一次 55 秒和 0.11 元。原始失败不因最终交付成功而消失。带错误反馈的重试会改变下一次条件故障恢复和退避等待也会影响结果。因此应直接测试“最多三次、通过即停”的整个请求策略记录最终交付与总成本不能把单次样本比例套入独立公式来许诺重试收益。7. 最后按证据决定下一步对波动任务按四个方向核查起点是否恢复、外部依赖是否变化、执行路径在哪一步分叉、相同产物的判定是否一致。先打开失败产物与实际返回再定位原因。不同路径都满足验收且代价合格时应同样判为通过。结果说明可以直接使用这个模板配置与时间范围____任务数____每任务计划/实际尝试数____ 起点恢复与验收规则____外部依赖限制____ 各任务通过次数____失败/超时/设施异常____ 排除与补跑数量及原因____原始记录位置____ 汇总权重____k____估计方法与不确定性____ 首次与最终交付____实际重试数____ 总耗时、费用覆盖、人工投入____ 关键错误与受影响用途____下一步修复/补测/限定条件试用样本量由要识别的失败、决策风险与预算决定发现关键错误应先修复不能被较高均值抵消。本组全部通过也只说明已测条件下的观察结果更多重复不能替代更多输入覆盖。EvalDock 是面向各类 Agent 的跨生态评测与选型平台为开发者提供针对性的优化方案。把相同配置的逐次表现与失败代价留下来才能把“时好时坏”变成可以定位和验证的问题。本文由 EvalDock 团队撰写。