昨天談到：
一句：
「停。」
其實不是單純的文字指令。
Stop 本身也會改變 State。
所以它必須綁定正確的 Workflow、Action 與 Current State。
今天我要談另一句更常見的話：
「再試一次。」
這句話聽起來甚至比「停」還普通。
程式失敗了。
Retry。
API Timeout。
Retry。
Server Busy。
Retry。
這不是軟體世界每天都在做的事情嗎？
是。
但當 AI 開始具有 Authority、Tool 與 Action Capability 之後，
事情開始不一樣。

我以前很容易把所有 Retry 都看成同一件事：
第一次失敗。
再做一次。
結果成功。
很好。
但後來我們開始問：
第二次 Action，真的還是第一次 Action 嗎？

例如一個很單純的 Network Request。
第一次 Request 根本沒有到達 Server。
Timeout。
而這個操作又是明確 Idempotent。
那自動 Retry 通常很合理。
這比較接近：
Technical Retry

可是另外一種情況就不同。
假設第一次 Action：
可能已經送出去。
System 不確定有沒有執行成功。
State 可能已經改變。
Permission 原本只允許一次。
這時候如果 AI 自己想：
「剛剛好像失敗，那我再送一次。」
事情就危險了。
因為第二次可能已經是：
第二個 Action。

這也是我們後來開始把 Retry 分成兩類。
Technical Retry
例如：
Transport Failure。
Transient Error。
明確 Idempotent。
沒有新的 Authority Consumption。
沒有額外 State-changing Risk。
這種 Retry 可以被視為技術恢復策略的一部分。

另一種則是：
Authority-bearing Retry
也就是第二次嘗試會：
再次消耗 Permission。
可能改變 State。
可能造成重複 Action。
或者第一次到底有沒有成功，本身就不確定。
這時候：
Retry 可能就是新的 Decision。

我覺得這個差異非常重要。
因為如果不分，
一句：
「可以做一次。」
很容易偷偷變成：
「可以一直做到成功。」
這不是同一個 Permission。

假設 Human 給的 Authority 是：
One Action
那 System 就不能自己擴張成：
Action 1
FAIL
Action 2
FAIL
Action 3
FAIL
Action 4
……
直到成功。

這就是我們現在很在意的一條原則：
No Silent Retry

但這句話不能被誤解成：
「所有 Retry 都禁止。」
不是。
更精確地說：
No Silent Authority-bearing Retry.
也就是：
如果 Retry 本身會形成新的 Authority Consumption、State Risk 或不可判定的副作用，
就不能偷偷做。

這件事情其實跟昨天 Stop Binding 很像。
都是在問：
Human 原本的 Authority，到底綁到哪裡？
如果 Human 只允許一次，
那第一次之後，
Authority 可能就已經：
Consumed。

如果需要第二次，
System 應該重新確認：
現在 State 還一樣嗎？
第一次到底有沒有部分完成？
Context 有沒有 Drift？
Authority 還有效嗎？
這次 Retry 還在原本 Scope 裡嗎？

這時候第二次：
「再試一次」
其實已經不是技術問題。
而是：
Governance Decision。

我覺得最容易理解的例子就是：
金錢。
如果我跟 AI 說：
「幫我付款一次。」
第一次 Transaction 回傳 Timeout。
AI 不知道到底有沒有扣款。
這時候如果它直接：
「沒成功，我再付一次。」
你應該會很緊張。
因為：
Unknown Outcome ≠ Permission to Repeat.
Physical World 也是一樣。
如果某個 Command 已經送出，
只是 Feedback 暫時沒有回來，
不能因為：
「我沒看到成功訊息」
就自動再做一次。

而且 Retry 還會牽涉另一個問題：
Time。
假設我早上允許某個 Action。
執行失敗。
過了兩個小時。
System Restart。
Environment Changed。
AI 回來後看到：
「之前還有一個失敗 Action。」
它能不能自動 Resume？
我現在的答案也是：
不一定。

這就進入另一條我們很在意的原則：
No Silent Resume

不是：
所有中斷 Workflow 都必須重新從零開始。
而是：
如果中斷期間已經發生足以影響原 Permission 的：
State Change。
Context Drift。
Authority Change。
Time Change。
Material Condition Change。
那 System 不能默默假設：
「之前可以，所以現在也可以。」

這其實是很容易發生的事情。
人類會把：
「剛剛沒做完」
理解成：
「那現在繼續。」
但對 System 來說，
「剛剛」
跟：
「現在」
之間可能已經發生很多變化。
所以：
Resume 也需要 Current-State Check。

我現在會把這整件事情想成：
Human Authorization
↓
Action Attempt
↓
Failure / Unknown
↓
Reconcile Current State
↓
Check Authority
↓
Technical Retry？
or
↓
New Decision Required？

這個分類非常重要。
因為真正成熟的 Agent 不應該是：
「失敗就自己一直想辦法。」
它應該知道：
哪些問題可以技術性自我恢復。
以及：
哪些問題一跨過去，就需要重新取得 Authority。

所以我現在不反對 AI 自主 Retry。
我反對的是：
AI 自己把新的 Decision 偽裝成 Retry。
這兩件事情差很多。

目前 No Silent Retry / No Silent Resume 對我們來說是：
Governance Principle + Sandbox-scope Engineering Direction
不是說所有 Sol Runtime / Production Action 都已經全面完成 Enforcement。
這條 Claim Boundary 一樣要守住。

不過我覺得這個 Principle 已經非常重要。
因為它重新定義：
什麼叫 Autonomous Agent。
真正好的自主，不應該是：
永遠不問 Human。
而是：
知道什麼時候不需要問，也知道什麼時候必須重新問。
這才是我真正想要的 Autonomy。

所以 Day 17 最後，我會留下兩句話。
第一句：
A retry can be a new decision.
第二句：
No Silent Retry. No Silent Resume.

不是為了讓 AI 變慢。
而是避免：
原本有限的 Authority，
在 System 裡被偷偷放大。

但做到這裡，還有另一個問題。
如果我們真的遇到一個 Bug。
找到了 Root Cause。
修掉了。
結果過幾天，
同一種問題又發生。
那我會比第一次更不能接受。
因為：
第一次犯錯，
可能是未知。
第二次犯同樣的錯，
代表我們沒有把學到的東西留進系統。
Day 18，
我們來談：
我允許 Sol 犯錯，但不接受一直犯同一種錯。