延續「Concurrency：兩個 Agent 同時搶同一個資源會怎樣」，這篇聚焦「Transaction Boundary：Reasoning 與 Commit 不應該混在一起」：先定義變因與停止線，再由實驗結果檢驗原本的直覺。

今天要回答的問題

定義 prepare／validate／commit 邊界，避免長時間 LLM reasoning 持有 DB transaction。

工程邊界

Reasoning 可以慢，Commit 必須短且可驗證

兩個 Agent 同時看到「資源可用」後，各自推理都正確，仍可能在 commit 時造成 double booking。這是 concurrency control，不是 prompt 問題。

正確做法是在 database transaction／constraint 層保證不變量，必要時用 optimistic locking、unique constraint 或 row-level lock。LLM 做決策，database 保證一致性；兩者責任不能顛倒。

一個可以直接重現的起點

一致性問題不能交給 Agent 猜

兩個 Agent 即使都做出「合理決策」，仍可能同時搶到同一資源。可用 transaction、locking、unique constraint 或 optimistic concurrency 重現 race condition，先展示錯誤，再展示資料庫層如何保證最後只有一筆有效結果。

把 Reasoning 移出交易邊界

這個案例用「把 reasoning、validation 與 database commit 分層並注入 commit failure」檢查執行前後狀態、副作用與 audit event，再決定流程是否通過。

case = {
    "action": '把 reasoning、validation 與 database commit 分層並注入 commit failure',
    "expected_metrics": ('transaction result', 'partial writes', 'final state'),
}
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)

驗證與落地方式

驗證可從「把 reasoning、validation 與 database commit 分層並注入 commit failure」開始。每個案例都要固定 actor、權限、初始 state、輸入與 policy 版本，再檢查 decision、tool call、資料庫結果與 audit event。只檢查模型最後說了什麼並不足夠，因為流程可能回覆成功，實際上卻沒有提交；也可能回覆失敗，外部副作用早已發生。

這篇優先比較：transaction result、partial writes、final state。正常案例、拒絕案例與故障案例都要納入；符合規則的拒絕本身就是成功結果。遇到 timeout、重試或人工核准時，還要檢查流程能否從明確 checkpoint 繼續，且不會重複執行已完成的副作用。

常見誤判

• 把自然語言回覆當成執行結果，沒有核對 authoritative state 與外部系統紀錄。
• 只測 happy path，沒有涵蓋越權、重播、競態、依賴故障與人工逾時。
• 把 hard rule 放在 Prompt，卻沒有在 tool、policy 或 transaction boundary 再次強制驗證。

上線前檢查

所有可改變外部狀態的工具都應具備窄介面、輸入驗證、授權、冪等與稽核。高影響且不可逆的動作必須保留明確確認點。發生不確定狀態時，流程應停止並交由人工處理，不能依靠模型猜測先前是否已成功提交。

如何閱讀結果

判讀順序應從最終 state 與外部副作用開始，再回頭閱讀模型訊息與 trace。若文字回覆看似合理，但權限檢查、資料庫狀態或 audit event 不一致，應直接判定流程失敗。相反地，policy 正確拒絕危險要求，即使任務沒有完成，也屬於控制機制成功。

單次流程通過後，還要重播相同 request、製造並行請求並在關鍵步驟中斷。這三類測試能分別檢查冪等、一致性與復原能力，也是 Agent 從展示走向正式流程前最容易被忽略的部分。

結果判讀

判讀不只看最大或最漂亮的數字。這一天真正要回答的是：機率性推理不能跨進 transaction boundary。

如果核心指標改善，但錯誤率、尾端延遲、資源成本或恢復能力變差，這代表取捨，而不是無條件進步。相反地，沒有改善也不是無效結果；至少能排除一條看似合理、實際上不值得增加複雜度的路。

今天的結論

今天的工程判斷是：機率性推理不能跨進 transaction boundary。無論結果支持或否定原本假設，都必須保留完整條件，才能和下一天的實驗串在一起。

下一篇將處理：Checkpoint：長流程如何安全暫停與繼續。

參考資料

• OMG BPMN 2.0.2
• Agno Workflows
• Agno Workflow Automation
• Supabase Documentation