核心 GUIDE
使用 Tool Result 之前先 Validation
Tool Call 返回响应并不等于 Business Action 已成功；Runtime 仍需要验证 Shape、Semantics 与 Intended Action 的关系。
核心心智模型
Tool Output 穿过 Trust Boundary。把它当成 External Input：Parse、Validate Contract、Classify Ambiguity，然后才允许它更新 Workflow State 或触发下一个 Side Effect。
为什么重要
API 会返回 Partial Success、Stale Data、Unexpected Enum、Empty Field，也会出现 Transport-level Success 但 Business-level Failure。如果 Agent 把每个 Response 原样塞回 Model，Malformed 或 Misleading Tool Data 就会变成 Authoritative Context。Validation 让 Runtime 保持控制，也让 Recovery Decision 可显式处理。
01
验证 Structure、Semantics 与 Postcondition
先检查 Response 是否匹配 Expected Schema 与 Version，再验证 Domain Constraint，例如 Identifier、Status Combination 与 Required Evidence。Side-effecting Tool 必须区分 Request Accepted 与 Confirmed Completion，并在需要时 Reconcile Ambiguous State。最后把 Raw Response 转换成更小、可信的 Structured Observation，再交给 Agent。
02
例子：Payment API 返回 HTTP 200
Payment Tool 返回 HTTP 200，但 JSON 中 Business Status 是 `pending_review`。如果把 HTTP Success 当成业务完成，Agent 就会告诉用户 Payment 已结束。Validator 应把它映射成 Typed PENDING State，并阻止 Fulfillment，直到后续 Authoritative Status 确认完成。
常见失败模式
- 把 Transport Success 当成 Business Success。
- 把未 Validation 的 Third-party Response 直接写入 Authoritative Agent State。
- 把 Unknown Field 或 Status 静默 Coerce 成熟悉 Value。
工程启发
- 为每一个 Agent Tool 定义 Typed Result Contract。
- 无法确认 Completion 时显式建模 UNKNOWN 与 PENDING。
- 保留 Raw Tool Evidence 用于 Debug，同时只给 Model 暴露 Validated Observation。
关键结论
- 01Tool Response 是 Evidence，不是自动 Trusted State。
- 02Validation 应发生在 Runtime Boundary。
- 03显式 Ambiguous State 可以防止自信但危险的 Follow-up Action。
来自 Knowledge Graph 的相关知识点
这些关系直接来自 canonical graph，不维护第二套 Guide 分类体系。