學習 / 實作
具身智能實踐（十）：恢復次數受控了，為什麼任務反而沒完成？
具身智慧 / 探索 · 工程案例
12回合對照無限恢復、兩次預算與400ms冷卻：分別記錄啟停、驗收窗口、終止原因和最終任務結果。
這篇之後，已經有了哪些結果？
保留本文發表時的結論與下一步構想；以下是已發布的後續內容，不代表所有侷限皆已解決。
繼續探索
繼續探索
瀏覽統計暫不可用
本文目錄 7
從乾淨環境重現 · 本篇固定版本
以下為 Windows PowerShell，Python 3.12。使用新目錄；不要在有未儲存改動的工程裡切換版本。每篇固定提交不同，首篇的舊提交不包含後續實驗。
git clone https://github.com/VirtualSelect/hohoo-embodied-agent.git hohoo-embodied-agent-study
cd hohoo-embodied-agent-study
git checkout 497d0df30c1f66de50fb38b930f0c6ea069d9634
python -m venv .venv
$py = '.\.venv\Scripts\python.exe'
& $py -m pip install -r requirements-lock.txt
& $py experiments/vl01_exit_release_budget/run.py --out outputs/my-run
& $py experiments/vl01_exit_release_budget/audit.py outputs/my-run預期得到原始軌跡、摘要與稽核結果。請使用新的輸出目錄，避免覆蓋舊結果；不同實驗對既有目錄的處理並不相同。E8–E10 共用一組實驗入口。以上指令不呼叫模型；先執行數值部分，影片回放依正文單獨執行。
排錯：找不到實驗目錄先核對提交；匯入失敗檢查解譯器與安裝環境；OpenGL 錯誤僅影響需要渲染的步驟。Linux/macOS 將解譯器替換為 .venv/bin/python，尚未在這些平台複測。
查看本篇固定程式碼 ↗恢復消融已經提醒過我們，反覆恢復不能只看路徑是否平滑。系統還需要回答：最多嘗試幾次？恢復之前至少等待多久？什麼時候明確放棄？
本輪復用E5的新鮮觀測門控，加入恢復次數與最短保持時間。一個容易期待的結論是“限制越多越好”；實際結果沒有這么簡單。
1. 固定恢復的證據要求
搬運時觀測年齡達到60ms，進入保持；恢復必須有停止之後的新鮮、連續、合格觀測，取樣時間跨度至少100ms。雙指接觸、方塊高度和夾持距離仍必須通過。
恢復後，從實測夾爪位置重新規劃500ms搬運路徑，再執行既有下降、釋放、後退。每次保持最多800ms，超過就中止。三策略只改變次數/最短等待限制：
| 策略 | 最大恢復次數 | 最短保持時間 |
|---|---|---|
unlimited |
本回合不設次數上限 | 0，仍需證據窗口 |
budget-two |
2 | 0，仍需證據窗口 |
budget-two-cooldown |
2 | 400ms，仍需證據窗口 |
“無限”仍受12秒回合時長和800ms單次保持期限約束，並非可以在真實系統里無限運行。預算計算的是實際獲準的恢復，不把每次收到包都當成一次恢復。
2. 四種通信條件
無擾動；一次丟包4.6–4.84s；從4.3s起每440ms丟前140ms、到6.94s結束；從4.3s起永久丟包。通信故障不直接修改物體狀態，也不偽造新的正常時間戳。
本輪仍只監測搬運，故障窗口綁定絕對模擬時間。不同保持時長會改變路徑進度與暴露，這點必須保留在解釋里，不能說是整個任務範圍內純粹的預算效應。
四條件各三策略，共12個確定性物理回合；其余場景、物理參數與初態相同。
3. 完整結果
| 條件 | 無次數上限 | 兩次預算 | 兩次預算＋冷卻 |
|---|---|---|---|
| 無擾動 | 0次恢復，完成 | 0次，完成 | 0次，完成 |
| 一次丟包 | 1次，完成 | 1次，完成 | 1次，完成 |
| 周期性丟包 | 6次，完成 | 2次，預算中止 | 2次，預算中止 |
| 永久丟包 | 0次，等待超時中止 | 同左 | 同左 |
周期丟包中，無上限策略雖然反覆啟停，最終仍完成放置；兩種有界策略按設計停止，方塊還被夾著，沒有完成任務。這不是需要藏起來的壞結果，而是清楚展示了“限制工作量”和“盡可能完成任務”的權衡。
4. 冷卻為什麼沒有擋住下一次立刻停機
周期故障中首次保持發生在4.342s。沒有冷卻的策略在4.542s恢復；冷卻策略等待至4.742s才恢復。然而下一次觀測過期在4.782s就發生了，恢復後只運行了40ms。
400ms最短保持約束的是“過去已經等夠多久”，並不能保證“未來至少穩定多久”。這次恢復時最新觀測仍新鮮，過去連續窗口也合格，下一段通信故障卻已經臨近。把冷卻時間叫作穩定性保證會超出它實際檢查的內容。
如果需要減少短暫恢復，可以研究更長的連續健康窗口、鏈路質量估計或明確的升級處理，但必須另做協議和對照。本篇沒有靠事後調參把曲線修漂亮。
5. 次數、冷卻和期限如何排序
BudgetGate復用已有門控，在滿足恢復證據時再檢查預算。預算已用完就進入 aborted；尚有預算但未達到最短保持時間，就繼續等待。800ms保持期限在基類中優先檢查，因此再好的觀測也不能越過已到期的等待上限。
if resumes >= cap:
abort("budget")
elif now - hold_tick < cooldown:
keep_waiting()
else:
resume_after_revalidation()預算中止沿用保持目標，並沒有自動鬆爪。本例刻意沒有把E8退出動作直接混進來，否則最終放置變化又可能來自退出策略。下一步應將兩者明確組合，並重新驗證，而不是因為兩個模塊各自有測試，就宣布組合也可靠。
6. 驗收了什麼，沒有驗收什麼
16項測試包括門控邊界與證據篡改檢出。獨立審計檢查32回合的96份記錄、11份源檔案指紋；對E10逐次核對恢復次數、停止後連續取樣窗口、新鮮度、冷卻與等待期限。
這不是獨立重算整個物理過程或形式化安全證明。所有資料來自固定教學場景，沒有測硬件制動、負載變化、感測器誤差分布或跨場景成功率。完整VL01和M4/M5仍保持原有學習狀態。
python experiments/vl01_exit_release_budget/run.py --out evidence/my-budget-series
python experiments/vl01_exit_release_budget/audit.py evidence/my-budget-series讀完可以試著先寫預期：如果預算設為0，在首次有足夠恢復證據時會怎樣？如果冷卻比保持期限還長呢？這些邊界已在單元測試中運行，它們比“加一個重試計數器”更接近實際控制器需要面對的問題。
同方向繼續閱讀
寫給未來的自己合上文章前，留下一點自己的理解。
你的私人學習便箋，只存在目前瀏覽器，不會上傳或公開。清理瀏覽器資料會遺失，請匯出留存。三種語言共用這篇文章的便箋。
下一篇已發布內容：具身智能實踐（十一）：已經放好了，為什麼還要撤銷“完成”？ →
目前學習位置
探索 / 具身智能
- ○ 具身智能實踐（九）：鬆爪命令成功，不等於放置完成
- ○ 具身智能實踐（十）：恢復次數受控了，為什麼任務反而沒完成？
- ○ 具身智能實踐（十一）：已經放好了，為什麼還要撤銷“完成”？
繼續探索
繼續探索
接下來，走哪條路？
- 具身智能實踐（八）：檢測到掉落以後，夾爪應該做什麼？ →
15回合固定場景對照保持、鬆爪、鬆爪後退：報警相同，退出動作不同，最終放置也不同。
- 具身智能實踐（九）：鬆爪命令成功，不等於放置完成 →
五條真實軌跡同時檢查單幀與持續窗口：錯誤觀測、延遲鬆爪和完成後的外力揭示驗收範圍。
依據文章關聯與同主題已發布內容整理，不使用隨機推薦。