用户先询问 A1042 的退货政策，后来改口：“先别退 A1042，查一下 A1043。”助手最后仍然提交了 A1042 的申请。每一轮单独看，模型都可能识别出订单号；整个任务却没有跟上用户目标的变化。
完整 Agent 评测的单位是一个持续变化的任务。输入包括对话、工具环境和外部事件，结果包括业务状态以及用户被告知的状态。
不要把一段对话当成一个超长问题
多轮任务里，前一轮动作会改变后一轮世界。用户补充资料以后，Agent 才可能判断质量问题；审批完成以后，才能执行退款；用户取消以后，先前未完成的计划应重新检查。
静态回放把所有历史直接塞给模型，适合检查某个时刻的决策，但不能证明系统能自行生成前面的正确轨迹。交互式评测则让 Agent 每轮行动，环境反馈真实改变，用户根据实际回答继续交流。两种实验回答不同问题，应分别保留。
最终状态与过程约束共同定义成功
如果退款记录正确，但 Agent 先未经批准执行，之后才补上审批，最终状态看起来可能合格。只检查最后一张表会漏掉时序违规。反过来，每一步都走对，最后没有提交事务，也不能算完成。
我们为事件记录 task_id、step_id、调用 ID、实体、状态版本和受信任时间或序号。下面的代码只演示“同一任务与订单先批准再执行”的逻辑：
events = [
{"seq": 1, "task": "t1", "order": "A1042", "kind": "approved"},
{"seq": 2, "task": "t1", "order": "A1042", "kind": "refund_committed"},
]
approved = set()
violations = []
for event in sorted(events, key=lambda row: row["seq"]):
key = (event["task"], event["order"])
if event["kind"] == "approved":
approved.add(key)
elif event["kind"] == "refund_committed" and key not in approved:
# 只能使用同一任务、同一实体之前发生的审批。
violations.append(event)
print(violations) # []生产约束还应绑定金额、审批版本、有效期和撤销信息；这个最小集合示例不涵盖这些条件。跨服务时钟不总能直接排序，应该结合因果关联、提交序号和来源，而不是盲目相信客户端时间戳。
轨迹匹配应关注必要关系
合法 Agent 可能先读政策，也可能先查订单。评分器如果要求步骤列表逐项相同，就会把实现习惯当成任务标准。更合理的是检查必须出现的证据、禁止动作、依赖关系和预算。
循环也要看是否产生新信息。第二次查询使用新提供的订单号，有意义；连续十次用同一参数查同一失败结果，则可能没有推进任务。可记录每步新增证据、待解决问题和停止原因，而不是仅按步数越少越好评分。
效率必须以完成质量为前提。一个不查工具直接拒绝的 Agent 很快，却可能完全没有完成可解决任务。比较成功案例效率时，也要同时报告失败比例，避免幸存者偏差。
上下文和记忆怎样进入评测
长对话可人为加入不相关闲聊，观察关键授权条件是否保留；压缩前后分别运行同一后续请求，看摘要是否丢掉“不要立即退款”。记忆评测还应加入用户纠正：旧地址不能因为出现次数更多就覆盖新地址。
长期记忆要有作用域。用户 u-1 的偏好不能泄漏给 u-2，同一用户在另一个租户的身份也不能自动继承。样本应包括跨线程、跨用户和过期记忆，评测读取了哪些条目，而不只是回答是否流畅。
如果组件级测试表明压缩摘要保留了约束，而端到端仍忽略它，就要检查上下文组装位置、工具调用前的状态读取和模型决策。上下文工程的缺陷能够通过评测分层定位。
模拟用户能扩展实验，也会引入误差
脚本用户按固定规则回应，容易复现，但覆盖表达有限。模型用户可以生成更自然的澄清和追问，却可能提前泄露答案、无条件配合 Agent，或忘记自己最初的目标。
模拟用户应只知道用户合理知道的信息，不应获得隐藏评分条件；它的行为也要接受检查，例如是否擅自改变任务、是否提供环境不存在的批准。固定一条用户输出回放，可以帮助区分被测 Agent 波动与模拟器波动。最终仍需用真实、经过授权的对话样本确认代表性。
多 Agent 不是多个单体分数的平均
主 Agent 可能把“核实质量”和“查询订单”分给两个子 Agent。两个子任务都成功，主 Agent 却可能接错实体、漏掉失败结果、或者在取消后继续执行。评测必须保留父子任务关联、产物来源、失败传播和最终合并行为。
当一个子任务失败时，是整体失败、部分回答还是转人工，应由任务契约决定。不能用“另外两个子任务成功”抵消关键审批缺失。端到端 oracle 依然是任务事实和业务状态，子 Agent 的自我总结只是待核验材料。
这些记录组成可观察轨迹，不要求记录模型隐藏思维。我们要解释它做了什么、依据哪些可见证据，以及结果如何，而不是把推测出来的思考过程当作证据。
继续阅读与配套材料
上一篇：怎样评测 Tool Calling：从选对工具到执行正确。
下一篇：Agent 出错以后还能完成任务吗：故障注入与安全评测。
完整示例、运行方式和验证边界见评测实验指南下载。本系列的订单、政策、金额和实验数据均为教学示例。