本頁譯自英文文件。指令、識別名稱與範例保持原樣。執行環境 7.24.4 · SDK 2.6.7。 英文原文

迴圈模式與排程工作

狀態：有效 範圍：目前狀態 上次審閱：2026-08-27 負責人：ax-code runtime

AX Code 有三個可組合的自動化基本單位：

/loop — 重複提示

/loop <interval> <prompt>   start (interval like 30s, 5m, 1h)
/loop status                show runs, busy-skips, and the prompt
/loop stop                  stop the loop

範例：

/loop 5m check CI for new failures and fix any you find
/loop 30m drain the review queue

規則：

• 間隔界限：30 秒到 24 小時。每個工作階段一個迴圈——開始新的會取代舊的。
• 工作階段忙碌時觸發的一拍會被略過並計數，絕不排入佇列——迴圈不能堆積回合。
• 每一拍都是一般的提示回合：權限、問題、自主上限與完成閘門全部適用。自主關閉時，一拍只會停在第一個權限提示。
• 每個迴圈硬上限 500 次執行，然後迴圈會自行停止並通知。
• 迴圈只存在於後端行程：重新啟動後不會留下。可持久的排程請用下方的排程工作。

把 /goal 與 /loop 搭配

/goal 擁有目標（「所有測試都通過，沒有未關閉的檢閱發現」）； /loop 提供持續檢查的心跳。先建立目標會 執行專用的計畫撰寫器，把可檢閱的契約存在 .ax-code/goals/ 之下（專案不是 git worktree 時則在 AX 資料目錄）。若規劃失敗，目標保持暫停——/goal resume 會重試 它。衡量此目標 diff 的 Git 範圍檢查使用計畫當時的 HEAD （{BASELINE}），而不是 origin/main，除非目標指名該遠端。 目標完成仍受驗證閘門約束：agent 不能在編輯後、沒有通過的驗證執行時把目標標成完成；而且當計畫 存在時，還必須為每個接受條件提供證據。

/goal keep main green: fix any CI failure the loop finds
/loop 10m check CI status and act on failures

目標保證是選擇加入

/goal <objective> 會立即開始：它不附加凍結的接受契約， 因此完成與否由 agent 維持的工作計畫（待辦事項）加上 最後一次變更後通過的驗證來判斷。/goal view（以及目標對話框的 「檢視目標細節」）會明確說明——「沒有保證契約」——因此狀態 絕不是你必須推斷的事。

/goal --assure <objective> 會先執行計畫撰寫器，凍結接受 條件、來源參照與可執行檢查；完成時還要求每個必要檢查都有 目前成功的回執（verify_project 及其 goalCheck id）。當目標的「完成」必須可證明、而不只是被描述時，請使用它。

--assure 可以與預算旗標以任一順序組合 （/goal --assure --budget 500000 <objective>）。被取代的目標若有有效契約，/goal replace <objective> 會保留 保證，因此取代絕不能悄悄削弱一個已經有保證的目標。

目標預算與上限

作用中的目標會提高每次執行的自動延續上限（session.max_continuations） ——執行會繼續，直到目標完成、受阻、暫停或 受到預算限制。改由下列項目限制它：

• Token 預算（/goal --budget N …）：用盡時，agent 得到一個 收尾回合，然後目標變成 budget_limited。
• 時間預算（/goal --time-budget 30m …）：以秒、 分鐘（m）或小時（h）表示的實際時間限制，可與 token 預算以任一 順序組合。它限制 token 預算看不到的經過工作——遠端訓練 工作、長時間工具呼叫、供應商停滯。觸發時適用相同的收尾回合與 budget_limited 轉換。
• 累計步驟上限：作用中目標的執行共用超長後盾， 共 max_steps × 40 個步驟（預設 20,000），而不是一般 自主上限 max_steps × (max_continuations + 1)。可用 session.max_total_steps 覆寫。
• 厄運迴圈偵測、影響範圍上限，以及僅工具回合的斷路器，在整個過程中仍然適用。

目標 CLI（無頭）

相同的目標控制可在 TUI 之外、於 ax-code goal 下使用：

• ax-code goal status [--json] — 顯示目前目標（-s/--session 用來 選擇工作階段；預設為專案中唯一可恢復的目標，若選擇會含糊則錯誤）。
• ax-code goal pause／ax-code goal clear — 暫停或清除它。
• ax-code goal resume — 恢復目標，並以無頭方式驅動它直到 安定。沒有 --attach 時，它會在行程內啟動專案；有 --attach http://localhost:4111 時，則改為驅動正在執行的伺服器。結束 代碼遵循無頭目標契約：0 完成、3 受阻、4 受預算限制、6 暫停／非終態、1 工作階段錯誤、124 閒置 逾時（--idle-timeout-ms，預設 10 分鐘）。事件以 JSONL 串流到 stdout （--event-log PATH 也會記錄它們），最後一行 Goal <status>: <objective> 會送到 stderr。

目標執行接近步驟上限時，agent 會收到一次 收斂警告，要求它驗證並完成目標，或留下 乾淨的交接。若仍然達到上限，目標會暫停——不是 失敗——並可用 /goal resume 再次接手（若需要更多餘裕，請先提高 session.max_total_steps）。

排程工作——可持久、可對話

直接詢問 agent；它使用 schedule_task、list_scheduled_tasks 與 manage_scheduled_task 工具：

• 「14:30 提醒我檢查部署。」
• 「每個工作日上午 9 點，摘要新的 CI 失敗。」
• 「列出我的排程工作。」／「暫停 CI 摘要工作。」

由 agent 建立與管理的排程變更會請求 schedule 權限。唯讀執行不能變更或觸發排程。若要無人值守地 以無頭方式建立，請使用明確的 ax-code schedule 指令，或為 agent 設定 明確的 schedule 權限授予；廣泛的萬用字元授予 不會授權排程變更。

相同的工作也可以不開啟 TUI，從 shell 管理：

ax-code schedule list                 # status, next run, schedule, id, title
ax-code schedule show <id>            # details plus the five most recent runs
ax-code schedule runs <id>            # run history: fired, failed, skipped and why
ax-code schedule pause|resume <id>
ax-code schedule delete <id>
ax-code schedule run <id>             # trigger now; requires a live runtime

pause/resume/delete 在專案的受管執行環境正在 執行時會透過它（立即生效，TUI 即時更新），否則直接寫入專案 資料庫。run 需要即時後端——用 ax-code runtime start 啟動一個——因為單次 CLI 行程不得認領它 無法完成的工作。所有讀取子指令都接受 --json。

排程支援單次執行、每日／每週時間，以及 5 欄 cron 運算式，各自可帶選用的 IANA 時區。工作持久保存在 專案資料庫，並在該專案的 AX Code 後端 執行時觸發（60 秒排程器掃瞄、原子認領——即使開了 數個後端，工作也只觸發一次）。排程前進與可持久佇列插入共用 同一個資料庫交易，因此崩潰不能在沒有留下可復原工作的情況下推進發生項。 ax-code run 與 ax-code stats 這類單次指令不會認領到期 工作。請用 ax-code runtime start 啟動持久後端來分派 它們。

錯過的發生項預設為 catchUpPolicy: "run_once"：停機之後， AX Code 會把任何積壓合併成一次執行。若過時的工作應 前進而不執行，請使用 "skip"。工作也可以把 maxRunDurationMs 設為一 秒到 72 小時；逾時的執行會被取消並記錄為失敗。

若要跨越行程與主機重新啟動來運作，請在監督程式下執行後端。systemd、launchd 與 PM2 範例以及精確的復原語意，見長時間執行的作業。

長時間無人值守執行

對於數小時的自主工作階段，超長模式加入執行期限（最多 72 小時）、請求節奏與壓縮調整。對於已宣告能力支援長時間 agent 工作的模型，它會自動啟用（100 萬上下文的推理 模型，例如 Alibaba 路由上的 Qwen 3.7+ Max／Plus，以及 z.ai 路由上的 GLM 5.x），也可以依工作階段、依專案，或透過 AX_CODE_SUPER_LONG 強制。執行參與會被記錄（super-long run engaged）， 而且供應商節奏只在執行開始後的寬限時窗之後才開始 （預設 2 小時，super_long.pacing_grace_minutes），因此 agent 執行的高產能 早期階段保持完整的工具呼叫輸送量； 長跑尾段則依模型宣告的速率限制等級調整節奏。