一個內部 Agent 同時支援兩件事：

查看目前 Status
修改 Status

介面只有一個對話框。

使用者不用先選 Read 或 Write。

某天下午，他問：

「幫我看看這張如果切到 Pending Review，後面還會卡什麼？」

Agent 先讀目前狀態。

再檢查 Transition 條件。

到這裡都沒問題。

接著它又送出一次 Tool Call。

Transition completed.
Current status: Pending Review

使用者原本只是想看「如果改了會怎樣」。

正式 Workflow 卻已經往前走了一步。

技術上只多一個呼叫。

工作上卻跨過 Read 與 Write 的 Boundary。

同一個入口，不代表底層可以沒有兩條路

很多 Agent 產品都追求自然入口：

不要讓使用者先理解工具，直接說工作就好。

這個方向本身沒有問題。

真正有問題的是，如果 Inspect、Simulation 與 Execute 在底層沒有可辨識的分界，使用者就很難知道自己什麼時候真的改變了正式系統。

例如：

看看目前狀態
看看如果改了會怎樣
把它改成 Pending

三句話很接近。

但前兩句都應該停在 Read / Analysis。

最後一句才是 State-changing Action。

所以 Source 裡的通用模式不是「所有事情都要人工批准」。

而是：

Read / Inspect
↓
Precheck
↓
Decision / Approval when required
↓
Write / Execute
↓
Verify resulting state

Write 必須有自己的 Gate。

Day 15 處理 Decision，這一篇處理執行邊界

前一篇的裂縫發生在：

討論還沒完成，Decision 就被當成已成立。

這一篇即使 Decision 已經很清楚，也還要分另一件事：

目前是在模擬結果，還是真的要改 State？

例如使用者說：

如果改成 Closed，還會有哪些 Child 沒完成？

這句話的目標是知道後果。

即使 Target、Transition、條件全部都已經解析完成，也不代表需要執行。

這就是 Read / Write Gate 的價值。

它不是幫模型理解語意而已。

而是替正式系統留下清楚的責任切點。

Gate 不是多一顆固定的 Yes / No 按鈕

如果 Intent 已經明確：

把這張工作單切到 Pending Review。

Target、Operation、方向都清楚。

系統可以直接做 Precheck，再執行。

真正需要 Gate 的是跨層時的判斷：

• 現在仍是 Read / Inspect 嗎？
• Target 是否已經明確？
• 這一步是否會改變正式 State？
• 必要前置條件是否成立？

只要仍停在 Preview，就不應因為「下一步已經算得出來」而順手執行。

後來，同一個對話框真的有兩條路

UI 沒有拆成兩套。

底層則改成：

Read / Inspect path
→ current state
→ simulation / explanation

Write path
→ precheck
→ execute
→ readback

隔週有人再問：

「如果把這張切到 Closed，還有哪些 Child Item 沒完成？」

Agent 回：

Current state: In Progress
If moved to Closed, 2 child items would remain open.
No state change was executed.

使用者看完說：

「那先不要動。」

正式 Status 沒有改。

等兩張 Child 都處理完，他才補一句：

「現在幫我 Close。」

同一個入口。

同一支 Agent。

差別只是 Preview 和 Execute 終於不再共用一條沒有邊界的路。