目標模式與收尾

長任務最常見的失敗方式不是答錯，而是過早停下：模型說「大致做完了」，測試卻從沒跑過。mu 有好幾樣東西對付這個問題，都建立在同一份紀錄上：你真正要的是什麼，也就是任務框架。

任務框架

任務框架記著目標、你的硬性約束（你的原話，以及你在哪裡說的）、目前的子目標和驗收項目。驗收項目也是模型逐項勾掉的待辦清單。

你傳的每則訊息都判定一次（task.frame）：新任務、新的硬性約束、一次糾正、新的子目標，還是沒有變化。只有發生變化時，才讓模型重寫任務框架，所以一句「謝謝」什麼也不花。/frame 顯示目前的任務框架。它跟著對話樹走：分叉或回退之後，那個分支的任務框架會回來。

目標模式

/goal packages/api 的測試全部通過，並且 README 寫明了新參數

代理立刻開始，一直做到條件成立。只輸入 /goal 會顯示目標、它的狀態、上一次檢查的理由和下一步；沒有目標時，會問你要一個條件。/goal clear 結束目標。在桌面版，從傳送框設定目標；目標列顯示它的狀態。

每次代理想停下，都會有一個模型讀取證據並決定：達成、繼續（附一個具體的下一步），還是需要你。證據包括：目標、還沒完成的驗收項目、改過之後還沒檢查的檔案、最後一次測試、建置或 lint 的執行及結果、這次執行做了什麼，以及收尾的那則訊息。事實勝過說法：只要還有沒完成的驗收項目或沒驗證的改動，結論就一定是「還沒有」，不管收尾訊息怎麼說。只有負責檢查的模型沒給出答案時，才由 Jev（goal.met）回答。

在下面這些情況下，它會自己停下，並告訴你原因：

暫停之後，你的下一則訊息會讓目標接著進行。重新開啟的工作階段會把正在執行的目標帶回來，但處於暫停狀態，不會直接執行。

每一輪結束時的檢查

沒有目標時，每一輪仍然有這些檢查：

• 完成核對（turn.completion）。模型說做完了時，mu 會問有沒有什麼驗證過它。沒有的話，提醒一次去檢查，例如跑一下測試。
• 半路停下（turn.continue）。一次執行以「接下來我跑一下測試」結束卻沒去做，或者對你已經要它做的事還在問要不要動手，就會被送回去接著做，每則訊息最多兩次。難以復原或超出這台機器的步驟，例如推送、發布、刪除或付款，從不會這樣推著去做。

偏離和死路

• 偏離監控（turn.drift）。每六次工具呼叫，mu 檢查一次工作是否還在為目標服務。另一種失敗是原地打轉，由規則來抓：最近八次呼叫裡，同一個呼叫出現三次。
• 判定回退（turn.rewind）。代理原地打轉，或者一條指令一直失敗時，判定器會問這條路是不是死路。只有確定是死路、又沒有進展時，才會提議回到這一輪的檢查點，並附上一則說明：試過什麼、為什麼放棄。提議會等你兩分鐘；你不回答，執行就繼續。它從不自己回退。

手動回退

/checkpoints 列出目前分支的快照，最新的在前：編號、回合、時間、之後改了多少個檔案。/rewind 退回到最新的一個，/rewind 3 退回到 3 號；它先顯示哪些檔案會被放回、刪除或還原，再問你要退回檔案、對話，還是兩者都退回。/rewind undo 撤銷一次回退。更多內容請見權限與安全。