Standing Orders
長期指令向您的代理程式授予永久操作授權用於定義的程式。與其每次都授予個別工作指令，您定義具有明確範圍、觸發器和升級規則的程式 — 代理程式在這些邊界內自主執行。 這是告訴您的助手「每週五傳送每週報告」與授予長期授權的區別：「您擁有每週報告。每週五編譯它、傳送它，只在看起來有問題時升級。」為什麼要長期指令？
沒有長期指令：- 您必須為每個工作提示代理程式
- 代理程式在請求之間閒置
- 常規工作被遺忘或延遲
- 您成為瓶頸
- 代理程式在定義邊界內自主執行
- 常規工作在排程上自動發生，無需提示
- 您只參與例外和核准
- 代理程式在閒置時間中富有成效地工作
它們如何工作
長期指令在您的代理程式工作區檔案中定義。推薦的方法是直接將它們包含在AGENTS.md 中（每個 session 自動注入），以便代理程式始終在內容中擁有它們。對於較大的設定，您也可以將它們放在專用檔案（如 standing-orders.md）中，並從 AGENTS.md 參考它。
每個程式指定：
- Scope — 代理程式授權執行的操作
- Triggers — 何時執行（排程、事件或條件）
- Approval gates — 執行前需要人工簽核的內容
- Escalation rules — 何時停止並要求協助
長期指令的解剖
```markdown程式：每週狀態報告
授權： 編譯資料、產生報告、傳遞給利益相關者 觸發： 每週五下午 4 點（經由 cron 工作強制） 核准大門： 標準報告無大門。將異常標記為人工檢查。 升級： 如果資料來源不可用或指標看起來不尋常（>2σ 來自常態）執行步驟
- 從設定的來源拉取指標
- 與上一週和目標進行比較
- 在 Reports/weekly/YYYY-MM-DD.md 中產生報告
- 經由設定的頻道傳遞摘要
- 登錄完成至 Agent/Logs/
不要執行的內容
- 不要將報告傳送至外部方
- 不要修改來源資料
- 不要在指標看起來不好時略過傳遞 — 準確地報告 ```
長期指令 + Cron 工作
長期指令定義什麼代理程式授權執行。Cron 工作定義何時發生。它們一起工作： ``` 長期指令：「您擁有每日收件匣分類」 ↓ Cron 工作（每日上午 8 點）：「按長期指令執行收件匣分類」 ↓ 代理程式：讀取長期指令 → 執行步驟 → 報告結果 ``` Cron 工作提示應參考長期指令，而不是複製它： ```bash openclaw cron add—name daily-inbox-triage
—cron “0 8 * * 1-5”
—tz America/New_York
—timeout-seconds 300
—announce
—channel bluebubbles
—to “+1XXXXXXXXXX”
—message “Execute daily inbox triage per standing orders. Check mail for new alerts. Parse, categorize, and persist each item. Report summary to owner. Escalate unknowns.” ```
範例
範例 1：內容與社交媒體（每週週期）
```markdown程式：內容與社交媒體
授權： 起草內容、排程貼文、編譯參與報告 核准大門： 所有貼文前 30 天需要擁有者檢查，然後長期核准 觸發： 每週週期（星期一檢查 → 週中起草 → 週五簡報）每週週期
- 星期一： 檢查平臺指標和受眾參與
- 星期二–四： 起草社交貼文、建立部落格內容
- 星期五： 編譯每週行銷簡報 → 傳遞給擁有者
內容規則
- 語音必須符合品牌（請參閱 SOUL.md 或品牌語音指南）
- 從不在公開內容中識別為 AI
- 可用時包括指標
- 將重點放在受眾價值上，而不是自我推廣 ```
範例 2：財務操作（事件觸發）
```markdown程式：財務處理
授權： 處理交易資料、產生報告、傳送摘要 核准大門： 無分析大門。建議需要擁有者核准。 觸發： 檢測到新資料檔案或排定的月度週期新資料到達時
- 檢測指定輸入目錄中的新檔案
- 解析並分類所有交易
- 與預算目標進行比較
- 標記：異常項目、臨界值違規、新循環費用
- 在指定的輸出目錄中產生報告
- 經由設定的頻道將摘要傳遞給擁有者
升級規則
- 單項 > $500：立即警示
- 類別 > 預算 20%：在報告中標記
- 無法識別的交易：要求擁有者進行分類
- 處理後 2 次重試失敗：報告失敗，不要猜測 ```
範例 3：監控與警示（連續）
```markdown程式：系統監控
授權： 檢查系統健康狀態、重新啟動服務、傳送警示 核准大門： 自動重新啟動服務。如果重新啟動失敗兩次則升級。 觸發： 每個 heartbeat 週期檢查
- 服務健康端點應答
- 磁碟空間超過臨界值
- 待處理工作不是過時的（>24 小時）
- 傳遞頻道可運作
回應矩陣
| 條件 | 動作 | 升級？ |
|---|---|---|
| 服務下線 | 自動重新啟動 | 僅限重新啟動失敗 2x |
| 磁碟空間 < 10% | 警示擁有者 | 是 |
| 過時工作 > 24h | 提醒擁有者 | 否 |
| 頻道離線 | 登錄並在下一個週期重試 | 如果離線 > 2 小時 |
執行驗證報告模式
長期指令在與嚴格執行紀律相結合時效果最佳。長期指令中的每個工作都應遵循此迴圈：- 執行 — 進行實際工作（不只是確認指令）
- 驗證 — 確認結果正確（檔案存在、訊息已傳遞、資料已解析）
- 報告 — 告訴擁有者完成了什麼以及驗證了什麼
執行規則
- 每個工作遵循執行驗證報告。無例外。
- 「我會這樣做」不是執行。執行它，然後報告。
- 「完成」而沒有驗證無法接受。證明它。
- 如果執行失敗：使用調整後的方法重試一次。
- 如果仍然失敗：報告失敗和診斷。從不默默失敗。
- 從不無限期重試 — 最多 3 次嘗試，然後升級。 ```
多程式架構
對於管理多個問題的代理程式，使用清晰邊界將長期指令組織為單獨的程式： ```markdown長期指令
程式 1：[領域 A]（每週）
…程式 2：[領域 B]（每月 + 隨需應變）
…程式 3：[領域 C]（視需要）
…升級規則（所有程式）
- [常見升級標準]
- [適用於所有程式的核准大門] ```
- 其自己的觸發節奏（每週、每月、事件驅動、連續）
- 其自己的核准大門（某些程式需要比其他更多的監督）
- 清晰邊界（代理程式應知道一個程式在何處結束，另一個開始的位置）
最佳做法
執行
- 以較窄的授權開始，並隨著信任建立而擴展
- 為高風險行動定義明確的核准大門
- 包括「不要執行的內容」部分 — 邊界與許可同樣重要
- 結合 cron 工作以進行可靠的基於時間的執行
- 每週檢查代理程式日誌以驗證長期指令被遵循
- 隨著您的需要演進更新長期指令 — 它們是活躍文件
避免
- 第一天授予廣泛授權（「按您認為最好的方式執行任何操作」）
- 略過升級規則 — 每個程式需要「何時停止並要求」條款
- 假設代理程式會記住口頭指令 — 將所有內容放在檔案中
- 將問題混合在單個程式中 — 為不同領域分離程式
- 忘記使用 cron 工作強制 — 沒有觸發的長期指令變成建議
相關
- Cron Jobs — 排程長期指令的強制
- Agent Workspace — 長期指令存在的地方，包括自動注入的啟動程序檔案的完整清單（AGENTS.md、SOUL.md 等）