代理调用接口并得到成功响应，为什么用户仍说事情没办好？接口可能执行了合法动作，却不是用户真正需要的动作。二〇二四年提出的τ-bench用模拟用户对话、业务工具与规则构造评测，并比较对话结束后的数据库状态和目标状态；它也提出pass^k指标观察多次运行的一致可靠性。本文讨论其评测思路，不引用旧模型成绩判断今天的系统。
这一方法把注意力从“能否生成调用参数”转向“流程结束后发生了什么”。对企业应用而言，后者往往更贴近验收：记录有没有被正确更新，不允许的操作是否被阻止，用户的限制条件有没有被保留。
最终状态要比成功提示更具体
假设用户要求修改一条预约，但不改变其他安排。测试系统就应检查目标预约是否按要求更新，以及其他记录是否保持原样。代理说“已经完成”只能算输出，不能作为事实证明。验收应从业务存储或可信工具返回结果中读取状态。
对于无法直接读取最终状态的外部操作，可以记录确认编号和状态查询结果，并把仍未确认的部分明确展示给用户。测试流程也应区分提交成功、等待处理和最终完成，避免把异步任务的第一步当成全部工作结束。
重复测试揭示不稳定路径
同一任务只跑一次，容易碰巧得到好结果。多次重复可以帮助团队观察代理是否每次都遵守业务条件。还应记录失败类型：是信息不足、工具异常、参数错误，还是规则判断失误。不同原因需要不同修复，而不是一概增加重试次数。
重复运行时，测试环境必须能恢复到相同起点，否则第二次可能受到第一次操作影响。对写入动作设置独立测试账号和可清理的数据，也能减少评测本身的风险。模型版本、工具描述与业务规则修改后，都需要重新检查关键流程。
我们的工程结论是，代理验收至少要同时看结果、边界和一致性。漂亮的对话与完整的调用轨迹可以帮助排查，却不能代替业务状态。只有把“做了动作”和“办对事情”分开，团队才有机会知道下一次升级到底改善了什么。
归档说明：本篇于二〇二六年十月十二日补写并上线，按十月十一日栏目归档；文中资料在该归档日期前已公开。