Automation

常設命令

常設指令會授予你的代理程式針對已定義計畫的永久執行權限。你不必針對每項工作提示代理程式,而是定義具有明確範圍、觸發條件與升級規則的計畫,代理程式便會在這些界線內自主執行:“你負責每週報告。每週五彙整並傳送,只有在發現異常時才升級處理。”

為什麼需要常設指令

**沒有常設指令:**你必須針對每項工作提示代理程式,例行工作可能遭到遺忘或延誤,而你會成為瓶頸。

**有常設指令:**代理程式會在已定義的界線內自主執行,例行工作會按時完成,而你只需處理例外狀況與核准事項。

運作方式

常設指令定義在你的代理程式工作區檔案中。建議直接將其納入 AGENTS.md(每個工作階段都會自動注入),讓代理程式始終能在情境中取得這些指令。若設定規模較大,也可以將其放在 standing-orders.md 等專用檔案中,並從 AGENTS.md 參照該檔案。

每個計畫會指定:

  1. 範圍 - 代理程式獲授權執行的事項
  2. 觸發條件 - 執行時機(排程、事件或條件)
  3. 核准關卡 - 採取行動前需要人工核准的事項
  4. 升級規則 - 何時停止並尋求協助

代理程式會在每個工作階段透過工作區啟動檔案載入這些指令(如需自動注入檔案的完整清單,請參閱代理程式工作區),並依據這些指令執行;同時搭配排程工作來強制執行定時工作。

常設指令的組成

markdown
## 計畫:每週狀態報告 **權限:**彙整資料、產生報告、傳送給利害關係人**觸發條件:**每週五下午 4 點(透過排程工作強制執行)**核准關卡:**標準報告不需要核准。標記異常情況以供人工審查。**升級條件:**資料來源無法使用,或指標看起來異常(偏離常態 >2σ) ### 執行步驟 1. 從已設定的來源擷取指標2. 與前一週及目標比較3. 在 Reports/weekly/YYYY-MM-DD.md 中產生報告4. 透過已設定的頻道傳送摘要5. 將完成紀錄寫入 Agent/Logs/ ### 不可執行的事項 - 不得將報告傳送給外部人士- 不得修改來源資料- 不得因指標表現不佳而略過傳送,應如實報告

常設指令搭配排程工作

常設指令定義代理程式獲授權執行的事項排程工作定義工作的執行時機。兩者搭配運作:

text
常設指令:“你負責每日收件匣分類”排程工作(每天上午 8 點):“依常設指令執行收件匣分類”代理程式:讀取常設指令 → 執行步驟 → 回報結果

排程工作的提示應參照常設指令,而不是重複其內容:

bash
openclaw cron add \  --name daily-inbox-triage \  --cron "0 8 * * 1-5" \  --tz America/New_York \  --timeout-seconds 300 \  --announce \  --channel imessage \  --to "+1XXXXXXXXXX" \  --message "依常設指令執行每日收件匣分類。檢查郵件中的新警示。解析、分類並保存每個項目。向負責人回報摘要。將未知事項升級處理。"

範例

範例 1:內容與社群媒體(每週週期)

markdown
## 計畫:內容與社群媒體 **權限:**草擬內容、安排貼文、彙整互動報告**核准關卡:**前 30 天所有貼文都需要負責人審查,之後採常設核准**觸發條件:**每週週期(週一審查 → 週中草擬 → 週五簡報) ### 每週週期 - **週一:**審查平台指標與受眾互動- **週二至週四:**草擬社群貼文、建立部落格內容- **週五:**彙整每週行銷簡報 → 傳送給負責人 ### 內容規則 - 語調必須符合品牌風格(請參閱 SOUL.md 或品牌語調指南)- 在公開內容中絕不可表明自己是 AI- 有可用指標時應將其納入- 著重為受眾提供價值,而非自我宣傳

範例 2:財務作業(事件觸發)

markdown
## 計畫:財務處理 **權限:**處理交易資料、產生報告、傳送摘要**核准關卡:**分析不需要核准。建議需要負責人核准。**觸發條件:**偵測到新資料檔案,或到達每月排程週期 ### 新資料到達時 1. 偵測指定輸入目錄中的新檔案2. 解析所有交易並加以分類3. 與預算目標比較4. 標記:異常項目、超出門檻、新增的定期費用5. 在指定輸出目錄中產生報告6. 透過已設定的頻道將摘要傳送給負責人 ### 升級規則 - 單一項目 > $500:立即發出警示- 類別超出預算 20%:在報告中標記- 無法識別的交易:請負責人進行分類- 重試 2 次後仍處理失敗:回報失敗,不得猜測

範例 3:監控與警示(持續執行)

markdown
## 計畫:系統監控 **權限:**檢查系統健康狀態、重新啟動服務、傳送警示**核准關卡:**自動重新啟動服務。若重新啟動失敗 2 次,則升級處理。**觸發條件:**每個心跳偵測週期 ### 檢查項目 - 服務健康狀態端點是否有回應- 磁碟空間是否高於門檻- 待處理工作是否未過期(>24 小時)- 傳送頻道是否正常運作 ### 回應矩陣 | 狀況             | 動作                     | 是否升級?                   || ---------------- | ------------------------ | ---------------------------- || 服務中斷         | 自動重新啟動             | 僅在重新啟動失敗 2 次時      || 磁碟空間 < 10%   | 警示負責人               | 是                           || 工作過期 > 24h   | 提醒負責人               | 否                           || 頻道離線         | 記錄並於下個週期重試     | 若離線 > 2 小時              |

執行、驗證、回報模式

常設指令搭配嚴謹的執行紀律時,效果最佳。常設指令中的每項工作都應遵循此循環:

  1. 執行 - 實際完成工作(不要只確認收到指令)
  2. 驗證 - 確認結果正確(檔案存在、訊息已傳送、資料已解析)
  3. 回報 - 告知負責人完成了哪些工作,以及驗證了哪些事項
markdown
### 執行規則 - 每項工作都遵循「執行、驗證、回報」。不得例外。- “我會處理”不代表已執行。先完成,再回報。- 未經驗證就說“已完成”不可接受。必須提出證明。- 如果執行失敗:調整方法後重試一次。- 如果仍然失敗:回報失敗並附上診斷。絕不可默默失敗。- 絕不可無限重試,最多嘗試 3 次,之後必須升級處理。

此模式可避免代理程式最常見的失敗情況:確認收到工作,但未實際完成。

多計畫架構

對於管理多種事項的代理程式,請將常設指令整理為界線清楚的獨立計畫:

markdown
## 計畫 1:[領域 A](每週) ... ## 計畫 2:[領域 B](每月 + 隨需) ... ## 計畫 3:[領域 C](視需要) ... ## 升級規則(所有計畫) - [共通升級條件]- [適用於所有計畫的核准關卡]

每個計畫都應具備:

  • 專屬的觸發頻率(每週、每月、事件驅動、持續執行)
  • 專屬的核准關卡(部分計畫需要比其他計畫更多的監督)
  • 清楚的界線(代理程式應知道一個計畫在哪裡結束,另一個計畫從哪裡開始)

最佳實務

建議做法

  • 從有限的權限開始,隨著信任建立再逐步擴大
  • 針對高風險動作定義明確的核准關卡
  • 加入“不可執行的事項”章節,界線與權限同樣重要
  • 搭配排程工作,確保定時執行的可靠性
  • 每週審查代理程式日誌,以確認常設指令確實獲得遵循
  • 隨需求演變更新常設指令,這些是持續維護的文件

避免事項

  • 第一天就授予廣泛權限(“做任何你認為最好的事”)
  • 省略升級規則,每個計畫都需要“何時停止並詢問”的條款
  • 假設代理程式會記住口頭指令,請將所有內容寫入檔案
  • 在單一計畫中混合不同事項,應為不同領域建立獨立計畫
  • 忘記使用排程工作強制執行,沒有觸發條件的常設指令只會成為建議

相關內容

  • 自動化:快速瀏覽所有自動化機制。
  • 排程工作:強制依排程執行常設指令。
  • 掛鉤:用於代理程式生命週期事件的事件驅動指令碼。
  • 網路鉤子:傳入的 HTTP 事件觸發條件。
  • 代理程式工作區:常設指令的存放位置,包括自動注入啟動檔案的完整清單(AGENTS.mdSOUL.md 等)。
Was this useful?
On this page

On this page