核心 GUIDE
Verification Loop
可靠 Agent 会反复比较“预期状态”和“实际观测状态”，再根据差异决定继续、修复、升级人工或停止，而不是一路相信自己的叙述。
核心心智模型
Verification Loop 是围绕任务建立的 Feedback Control：先定义 Postcondition，再执行 Action，从 Environment 独立观测结果，把 Evidence 与 Postcondition 比较，并用差异决定下一步。
为什么重要
长 Workflow 如果只在最后检查一次，早期错误会经过多次 Tool Call 被放大；而反复让同一个 Model 自我反思，又可能只是继续继承原错误。Verification Loop 在关键 State Transition 后引入外部 Evidence，让 Runtime 在更多成本和 Side Effect 累积之前发现 Drift。
01
在真正改变 State 的节点验证
执行重要 Action 前，先说明预期产生什么 State Transition。执行后从环境收集 Evidence，验证是否满足 Postcondition，并把结果分类为 satisfied、failed 或 ambiguous。只有已验证状态才允许继续；失败则局部 Repair，不确定 Side Effect 则先 Reconcile，无法安全确认 Truth 时升级人工或停止。
02
例子：Agent 更新一次 Deployment
Agent 修改 Configuration、执行 Deployment，Command Exit Code 返回成功。Verification Loop 随后检查实际部署 Version、Health Endpoint 与关键 Smoke Assertion。如果新版本根本没有 Rollout，系统会修复这一 Stage，而不是直接宣布完成或继续做无关后续操作。
常见失败模式
- 把 Tool Return Status 当成 Task Outcome 的最终 Verification。
- 只在长且不可逆 Workflow 的最后一步做检查。
- 让同一个 Model Statement 同时扮演 Claim 与 Verifier。
工程启发
- 把 Verification 放在有意义的 State Transition 后，而不是每个微小 Token-level Action 后。
- 选择真正可能反驳 Model 预期的 Evidence。
- 把 Ambiguous Verification 设为一等状态，并提供 Reconciliation 或 Escalation。
关键结论
- 01Verification 把 Open-loop Agent 变成 Feedback Control。
- 02Checkpoint Evidence 可以限制错误传播。
- 03下一步应基于 Observed State，而不是 Narrated State。
用于这些学习路径
这个 Concept 会在多个 canonical 学习路径中复用。
来自 Knowledge Graph 的相关知识点
这些关系直接来自 canonical graph，不维护第二套 Guide 分类体系。