核心 GUIDE
Agent Tool Contract
Tool Contract 定义 Agent 能请求什么、Runtime 保证什么、可能如何 Failure，以及哪些 Side Effect 需要更强 Control。
核心心智模型
Tool 是 Application Boundary，不是 Magic Capability。Contract 应让 Input Schema、Permission、Side Effect、Result State、Idempotency 与 Error Semantics 足够明确，使 Runtime 可以独立 Enforcement。
为什么重要
Model 以 Probabilistic 方式选择 Tool Call，因此 Ambiguous Description 与过度 Permissive API 会直接变成 Safety / Reliability Problem。设计良好的 Contract 会缩小 Action Space，让 Deterministic Code 在高后果 Request 到达外部系统前先 Reject Invalid Request，也让 Model 在执行后获得 Structured Observation。
01
围绕 Business Action 与 Invariant 设计 Tool
Domain 允许时，优先暴露 Narrow Typed Operation，而不是 Generic Shell-like Power。明确 Required Permission、Validation Rule、Reversible / Irreversible Effect、Idempotency Behavior、Timeout Semantics 与 Structured Result State。Runtime 独立于 Model Enforcement 这些 Rule，并只返回下一步 Decision 真正需要的 Evidence。
02
例子：Issue Customer Credit
不要给 Agent 一个 Generic `execute_payment`，而是提供 `issue_support_credit`，参数限定 Customer ID、Bounded Amount、Reason Code 与 Operation ID。Runtime Enforcement Account Scope 与 Amount Limit，超过 Threshold 需要 Approval，并返回 `COMPLETED`、`PENDING` 或 `REJECTED` 以及 Authoritative Transaction Reference。
常见失败模式
- 明明可以使用 Narrow Domain Action，却给 Model 一个 Broad Generic Tool。
- Permission 只写在 Tool Description 中，没有 Runtime Enforcement。
- 只返回 Free-form Success Text，没有 Structured Status 与 Identifier。
工程启发
- 用 Bounded Business Action 命名 Tool，并明确 Side Effect。
- Permission 与 Invariant 在 Runtime Code 中 Validation，绝不只依赖 Prompt。
- Result State 要考虑 Recovery，包括必要时的 UNKNOWN 与 PENDING。
关键结论
- 01Tool Design 决定 Agent 的 Safe Action Space。
- 02Runtime Enforcement 比 Persuasive Instruction 更强。
- 03好的 Contract 同时让 Execution 与 Recovery 明确。
来自 Knowledge Graph 的相关知识点
这些关系直接来自 canonical graph，不维护第二套 Guide 分类体系。