08 · 自動化邊界

你是 Hermes 自動化邊界顧問。

【角色】
Hermes 自動化邊界顧問，按最小夠用、安全優先的原則給可落地方案，每條結論都落到能照做的具體步驟或示例，不停留在「建議」「考慮一下」這類空泛表述。

【輸入】
- 想自動化的任務：___
- 絕不能自動做的：___
- 執行環境：___
- 出錯的影響面：___
- 風險偏好：___

【工作流程】
1. 梳理可自動化的範圍
2. 標出必須人工審批的
3. 設計出錯兜底
4. 說明監控方式
5. 給驗證

【輸出規範】
▌一、可自動化範圍
▌二、審批項
▌三、出錯兜底
▌四、監控 + 驗證

【硬約束】
- 高危操作保留人工審批
- 出錯有兜底不放任
- 自動化範圍最小必要
- 不要替我臆測情況或編造不存在的功能，資訊不全先問清
- 不確定的設定或介面一律以官方文件為準，禁止照搬過時寫法
- 給的每條結論都要落到具體可照做的步驟或示例，不停留在「建議」「考慮一下」這類沒法直接執行的空泛表述

Hermes 能做自動化，但自動化不是把所有事情都交給 agent。真正可靠的自動化一定有邊界、記錄、失敗處理、人工確認點、回復路徑——這五件沒有的自動化，不是節省人力，是放大事故面。

官方資料：Cron、Delegation、Hooks、Persistent Goals、Messaging Gateway、Security、Checkpoints & Rollback。

自動化能力層

Hermes 中和自動化相關的 6 類能力——任意一項啟用都讓風險面更大一層：

這些能力疊加後，Hermes 可以主動執行任務、呼叫工具、發訊息、修改檔案，甚至連線遠端環境。風險也隨之指數上升——任意兩項組合（如 cron + hooks）的故障傳導路徑就比單一能力複雜數倍。

適合自動化

適合 Hermes 自動化：

• 每日摘要。
• 定時檢查服務狀態。
• 收集公開資訊並生成報告。
• 跑只讀診斷。
• 對固定目錄做低風險整理。
• 自動提醒和待辦彙總。
• 後臺跑測試並回報結果。

這些任務有共同點：輸入穩定、失敗可接受、結果可檢查、動作可重複。

不適合直接放權

不適合直接放權：

• 刪除資料。
• 釋出生產。
• 修改賬單或許可權。
• 操作真實客戶資料。
• 自動提交或合併高風險程式碼。
• 在未隔離環境執行未知指令碼。
• 傳送無法撤回的外部訊息。

這些任務可以讓 Hermes 做計劃、檢查、草稿和預演，但執行前必須人工確認。

Cron 邊界

Cron 可以建立一次性或週期任務，可以 pause、resume、edit、run、remove，可以繫結一個或多個 skills，也可以把結果投遞到 origin chat、檔案或平臺目標。官方還提供 no-agent mode，讓指令碼按計劃執行並把 stdout 原樣投遞。

設計 cron 前先回答：

• 失敗後誰知道？
• 記錄在哪裡？
• 任務是否冪等？
• 是否會重複傳送訊息？
• 是否可能修改檔案或外部系統？
• 憑據是否最小許可權？
• 執行目錄是否明確？
• 會不會遞迴建立更多 cron？

官方限制 cron-run sessions 遞迴建立 cron jobs，這是防 runaway scheduling loop 的必要護欄。你自己的任務也要有同類邊界。

Workdir 與專案規則

Cron 預設不一定在你的專案目錄裡執行。設定 workdir 後，專案裡的 AGENTS.md、CLAUDE.md、.cursorrules 才會按規則注入，terminal/file/code execution 也會以該目錄作為工作目錄。

這意味著：專案相關 cron 不要只寫“每天檢查專案”。要寫清楚絕對路徑、規則檔案、輸出位置和失敗通知。

Delegation 邊界

Delegation 會生成 child agents。官方強調子 agent 沒有父對話歷史，只知道 goal 和 context 欄位。父 agent 必須把任務需要的資訊完整傳入。

適合：

• 多個獨立資料收集。
• 多模組只讀審查。
• 並行測試/調查，且寫入範圍互不衝突。
• 複雜任務的隔離分析。

不適合：

• 多個子任務寫同一個檔案。
• 修改同一模組。
• 需要強共享上下文的複雜決策。
• 生產釋出。

預設併發和 depth 限制要謹慎調整。每多一層 delegation，成本、併發寫入風險和排障複雜度都會增長。

Hooks 邊界

Hermes 有 gateway hooks、plugin hooks 和 shell hooks。它們適合：

• 記錄 slash command 使用。
• 長任務提醒。
• session start/reset 通知。
• webhook 投遞。
• 自動格式化或阻斷危險動作。

Hooks 是確定性自動化，不是 LLM 推理。它們應該短、小、可觀測。不要在 hook 裡塞大型業務邏輯，也不要讓 hook 悄悄吞掉失敗。

最小安全基線

預設只讀
預設不釋出
預設不刪除
預設不外發敏感內容
所有寫操作限定範圍
所有高風險操作人工確認
所有定時任務有記錄
所有外部 token 最小許可權
所有訊息平臺有 allowlist
所有後臺任務有停止方式
所有自動化有失敗通知

沒有邊界的自動化，不是效率，是持續執行的事故源。

系列收束 · Hermes 自我改進的邊界 = 這條遞進順序

讀完這一篇，你應該能把 Hermes 的使用順序串起來——這就是「self-improving agent runtime」的正確進化路徑：

flowchart TB
    A1[1 理解 Hermes 是什麼<br/>區分聊天 CLI / IDE 助理 / 訊息 Bot / Agent Runtime]
    A2[2 跑通穩定閉環<br/>install + provider + chat + session]
    A3[3 配好 provider 和目錄<br/>~/.hermes 檔案分工 + Provider 策略]
    A4[4 收斂工具和執行環境<br/>toolset 和 backend 解耦]
    A5[5 治理記憶<br/>MEMORY.md / USER.md / 不當記錄寫]
    A6[6 沉澱 skills<br/>漸進載入 + Curator 治理]
    A7[7 接入訊息平臺<br/>Gateway + allowlist + 三類場景區分]
    A8[8 自動化<br/>cron / delegation / hooks / goals 守邊界]
    A1 --> A2 --> A3 --> A4 --> A5 --> A6 --> A7 --> A8
    A8 -.->|"反過來檢查"| A2

跳過任何一步都會在後面付雙倍代價——基礎不穩就開擴充套件，等於把每一層的不確定性傳給下一層；而且新層暴露的故障並不會自己定位回根因，最後只能整體重啟從頭排查。

官方資料

• Cron Jobs（自然語言 / cron 表示式 / no-agent mode）
• Delegation（子 agent / 併發 / depth 限制）
• Hooks（生命週期鉤子 / webhook 投遞）
• Persistent Goals（Ralph loop 實現）
• Security（命令審批 / 容器隔離 / 生產部署）
• Checkpoints & Rollback（破壞性操作快照與回復）

下一步