10. State-based Evaluation：检查世界是否真的被正确改变
核心 Evaluator · 3～5 小时
学习目标
- 理解状态评测为什么是 Tool Agent 的核心
- 设计 Initial State、Goal State 与 Forbidden State
- 处理幂等性、时序和最终一致性
前置知识
- 第 6、9 章
- 数据库/API/Kubernetes 基础
本章产物： 实现一个真实 State Checker，并能 reset Environment。
10.1 从“回答正确”升级到“状态正确”
用户：
把会议改到下午三点。
真正证据不是 Agent 回答“已经改好了”，而是：
calendar.event.start == 15:00
participants unchanged
location unchanged
no duplicate eventState-based Eval 是生产 Tool Agent 最重要的方法之一。
10.2 Initial State
每个 Case 都应定义可重置的初始世界。
fixture:
users: [...]
orders: [...]
tickets: [...]如果 Initial State 不稳定，Case 不可复现。
10.3 Goal State
不要只比较整个 DB dump，因为无关字段可能变化。
定义任务相关谓词：
assert order.status == "CANCELLED"
assert refund.amount == 8010.4 Forbidden State
State Evaluator 还必须检查不该发生的副作用。
assert other_orders == unchanged
assert audit.deleted == false很多危险 Agent 最终任务完成，但顺便改了不该改的数据。
10.5 Diff-based Evaluation
推荐保存：
before snapshot
after snapshot
semantic diffSemantic Diff 比原始 SQL dump 更适合解释。
10.6 Eventual Consistency
异步系统不能在工具返回后 1ms 就判断。
可采用：
wait_until(
predicate=expected_state,
timeout=10,
interval=0.2
)但 timeout 需要成为 EvalCase 配置；否则容易把性能问题隐藏为“最终成功”。
10.7 幂等性
重复命令时：
Run 1 → 创建订单
Retry → 不应该创建第二个订单可以显式评分：
- required result exists；
- duplicate count == 0。
10.8 Kubernetes State Eval 示例
任务：创建 nginx Job。
检查：
Job exists
image == nginx:<expected>
namespace == expected
backoffLimit == policy
Pod created
no cluster-wide RBAC changed对于基础设施 Agent，状态与权限副作用必须一起测。
10.9 状态与答案可能冲突
四种组合：
| State | Answer | 结论 |
|---|---|---|
| 对 | 对 | 成功 |
| 对 | 错 | 执行成功、沟通失败 |
| 错 | 对 | 高风险 False Success |
| 错 | 错 | 失败 |
第二和第三种必须分开报告。
10.10 验收问题
- 为什么要检查 Forbidden State？
- 最终一致系统如何避免误判？
- State 对但 Answer 错应该怎样分类？