用户申请修改订单地址，助手需要确认身份、找到订单、判断能否修改、询问新地址，再执行变更。答案没有一段固定标准文本，正确对话也不只有一种。评测必须让用户、Agent 和业务环境真正互动，最后检查任务是否完成。
τ-bench 系列提供了理解这种评测的具体实现。本文固定 sierra-research/tau2-bench 提交 2174a603f6d014ef94473ffa95957f6ce27100db，以文本任务的执行与评分为主线。仓库名称仍含 tau2，但快照已经包含 τ³ 的知识检索与语音扩展；不能把当前实现与早期论文或排行榜结果混为同一版本。仓库版本说明
一个任务不只是一句用户问题
领域提供政策、工具和环境，任务提供初始状态、用户情景和评测条件。Agent 看自己能够访问的政策、消息与工具结果；用户模拟器扮演提出目标并回应追问的一方；评分器保存不应提前泄露的预期。
在我们自己的售后案例里，用户想退 A1042，知道商品损坏，但未必知道后台质量核实状态。模拟用户可以提供照片说明，不能凭空替系统批准退款。用户可见事实、工具可见事实和隐藏判定条件需要隔离，否则评测很容易通过提示泄漏答案。
任务模型的字段组织可从 src/tau2/data_model/tasks.py 阅读；应结合实际领域样本，而不是只看抽象类。任务数据模型
谁负责让对话继续
运行入口 src/tau2/run.py 组织任务执行；编排层把 Agent、用户模拟器与环境连接起来，控制消息、工具调用和终止。文本 Orchestrator 与全双工语音编排并不是同一个时序模型。任务运行入口、编排实现
这使实验可以区分用户回答以后继续、工具返回以后继续，以及预算耗尽等停止原因。一个 Agent 不断询问已经回答的问题，可能最终超预算；不能只截取其中某一轮答对的消息算成功。
模拟用户本身也可能违反情景或过分配合。分析失败时需要同时检查用户与 Agent 的行为，而不是默认模拟用户永远正确。固定轨迹回放和人工抽检，是理解这个误差来源的重要手段。
最终环境怎样与期望比较
固定版本的 EnvironmentEvaluator 创建预测环境和参考环境。预测环境依据初始数据和观测轨迹恢复；参考环境从初始状态执行任务定义的预期动作。随后比较业务数据库与用户侧数据库的摘要，并执行环境断言。环境评分实现
这个机制把判断从“助手声称改了地址”推进到“环境是否变成预期状态”。但参考动作和环境代码仍然可能有问题。源码中对某些参考动作异常会记录警告；读报告时应检查这些异常，不能因为产生了数值就默认 oracle 一定正确。
状态比较也有自己的语义：如果整个受比较状态必须一致，额外的无关写入会导致失败；如果只使用局部断言，就需要确认没有漏掉禁止副作用。严格与宽松都不是绝对正确，取决于任务约束。
reward_basis 决定究竟测了什么
总入口 evaluate_simulation 按配置组织环境、动作、沟通和自然语言断言等评分。ALL 模式下，参与最终奖励的分量受任务 reward_basis 控制；其他模式可能忽略该选择。不能看到“ALL”就推断所有可能的安全检查都执行且都参与奖励。评分编排
该快照对于某些提前终止返回零奖励；对于没有评测条件的任务，则存在返回 1.0 并标注无条件的分支。后者说明配置完整性本身必须接受检查。它不是 Agent 已被充分验证的证据。
沟通正确与状态正确应分别查看。数据库没变，可能是合法拒绝，也可能是漏做任务，区别取决于该案例期待什么。给任务错误地配置奖励基础，就会稳定地产生错误排名。
稳定成功怎样计算
src/tau2/metrics/agent_metrics.py 的 pass_hat_k 使用 C(c,k)/C(n,k)，其中 n 为同一任务的运行次数，c 为成功次数，k 为抽取次数。稳定性指标实现
若四次运行有三次成功，随机选择两次共有六种组合，其中两次都成功有三种，因此估计为 0.5。至少一次成功的组合则是六种，对应 1.0。两个数字回答相反方向的问题，不能把 pass^k 的稳定性含义写成常见 pass@k 的“至少成功一次”。
from math import comb
n, c, k = 4, 3, 2
# 所有抽中的运行均成功：更关注同一任务重复执行的稳定性。
all_success = comb(c, k) / comb(n, k)
# 至少一次成功：当失败次数少于 k 时，不存在全失败组合。
all_fail_combinations = comb(n - c, k) if n - c >= k else 0
at_least_one = 1 - all_fail_combinations / comb(n, k)
print(all_success, at_least_one) # 0.5 1.0稳定性指标的历史背景可参阅 τ-bench 原始论文。计算要求 n 不小于 k。重复试验还受模型、模拟器和环境的相关性影响；这些估计不能保证真实用户重复使用时具有完全相同分布。应同时报告任务覆盖和运行配置。
把思路迁移到自己的售后系统
配套 mini_task_env.py下载 是独立教学环境，不是 τ-bench API 的复制或替代实现。它给每次运行创建初始订单和账本，提供查询与退款动作，保存事件，再由外部 oracle 核验金额、授权和副作用数量。
suite.py下载 在相同案例上比较保守策略与故意错误的策略。由于策略由代码固定，它只演示环境、轨迹和结果的关系。替换成模型驱动循环以后，还需要加入工具协议适配、Token 预算、模型错误和用户模拟器，才能测量真实 Agent 能力。
运行 τ-bench 官方实验则需要配置模型服务并支付相应成本。本文没有运行官方基准，也没有报告任何模型排名。使用时固定代码、任务数据、模型与评分设置，任务修复前后的分数不能无条件比较。
为什么还需要自己的数据集
公开领域任务可以帮助发现通用沟通和工具使用问题，但你的退款政策、权限系统、恢复机制与真实客户分布可能不同。应复用任务—环境—评分的组织思想，再加入自身事故案例、授权边界和业务 oracle。
新增知识检索和语音后，还要把证据版本、音频时间轴和互动条件纳入任务。它们扩展的是输入与环境复杂度，不改变基本要求：公开输入不能泄漏答案，评分条件需要可信，任务状态必须能够复核。
从 Ragas 到 Promptfoo，再到 τ-bench，我们分别看到语义评分、实验组织和交互环境。把这三个层面接起来，评测才有可能解释一个 Agent 为什么完成任务、为什么失败，以及下一次改动是否值得发布。
继续阅读与配套材料
上一篇：读懂 Promptfoo：怎样把案例、模型和断言组织成回归实验。
完整示例、运行方式和验证边界见评测实验指南下载。本系列的订单、政策、金额和实验数据均为教学示例。