前一篇討論「把自然語言變成 Typed Intent」，這篇聚焦「Tool Contract：Agent 可以做事，但不能想做什麼就做什麼」，並沿用同一組輸入、環境與判讀規則，避免只做名詞比較。
設計 typed tool input/output、precondition、error model，說明為何 Agent 不應直接操作 DB。
可以把系統拆成 Conversation／UI、Agent／Orchestrator、Tool layer、Policy layer、State store、Human Approval、Audit。模型可以決定下一個「提議動作」，但真正執行前仍需經 schema、policy 與權限檢查。
這樣的架構也方便觀測：一次 run 可以追到模型輸入、tool call、policy decision、database transaction 與人工核准，而不是只留下最後一句自然語言。
每個 tool 都應有明確 schema、precondition、authorization 與可預期 error。Agent 只能選擇「呼叫哪個能力、帶什麼結構化參數」，真正的資料一致性與 policy enforcement 必須由 application layer 負責。
這個案例用「對每個 tool 驗證 schema、side effect、authorization 與 error contract」檢查執行前後狀態、副作用與 audit event，再決定流程是否通過。
case = {
"action": '對每個 tool 驗證 schema、side effect、authorization 與 error contract',
"expected_metrics": ('accepted/rejected calls', 'side effects', 'audit'),
}
before = load_state()
result = execute_case(case)
after = load_state()
assert result.final_state in {"SUCCEEDED", "REJECTED", "ESCALATED"}
assert side_effects_match_policy(before, after, result)
assert audit_matches(before, after, result.events)
驗證可從「對每個 tool 驗證 schema、side effect、authorization 與 error contract」開始。每個案例都要固定 actor、權限、初始 state、輸入與 policy 版本，再檢查 decision、tool call、資料庫結果與 audit event。只檢查模型最後說了什麼並不足夠，因為流程可能回覆成功，實際上卻沒有提交；也可能回覆失敗，外部副作用早已發生。
這篇優先比較：accepted/rejected calls、side effects、audit。正常案例、拒絕案例與故障案例都要納入；符合規則的拒絕本身就是成功結果。遇到 timeout、重試或人工核准時，還要檢查流程能否從明確 checkpoint 繼續，且不會重複執行已完成的副作用。
所有可改變外部狀態的工具都應具備窄介面、輸入驗證、授權、冪等與稽核。高影響且不可逆的動作必須保留明確確認點。發生不確定狀態時，流程應停止並交由人工處理，不能依靠模型猜測先前是否已成功提交。
判讀順序應從最終 state 與外部副作用開始，再回頭閱讀模型訊息與 trace。若文字回覆看似合理，但權限檢查、資料庫狀態或 audit event 不一致，應直接判定流程失敗。相反地，policy 正確拒絕危險要求，即使任務沒有完成，也屬於控制機制成功。
單次流程通過後，還要重播相同 request、製造並行請求並在關鍵步驟中斷。這三類測試能分別檢查冪等、一致性與復原能力，也是 Agent 從展示走向正式流程前最容易被忽略的部分。
判讀不只看最大或最漂亮的數字。這一天真正要回答的是：工具能力要窄且可預測。
如果核心指標改善，但錯誤率、尾端延遲、資源成本或恢復能力變差，這代表取捨，而不是無條件進步。相反地，沒有改善也不是無效結果；至少能排除一條看似合理、實際上不值得增加複雜度的路。
今天的工程判斷是：工具能力要窄且可預測。無論結果支持或否定原本假設，都必須保留完整條件，才能和下一天的實驗串在一起。
下一篇將處理：State Persistence：對話斷掉之後流程還在嗎。
iThome鐵人賽
看影片追技術