目錄

重點速讀 2 分鐘｜7 分鐘深讀
  1. 為什麼要拆角色
  2. 三個角色一句話講清楚
  3. Hermes 不只是轉發器，而是控制平面
  4. 任務契約：不要只傳自然語言
  5. 狀態機：從 draft 到 done 的路徑
  6. 什麼任務可以自動，什麼任務要人工 approve
  7. 下一篇會補的安全隔離
  8. 大家都在問

第一篇已經把 Telegram 入口跑通；第二篇的重點，是把 Claude、ChatGPT Codex 和 Hermes 的責任邊界拆清楚。最穩的分工是：Claude 負責想清楚與審查，Codex 負責在隔離工作區動手，Hermes 負責驗證、排隊、審批、紀錄與回報。

  • Claude 不應該直接拿到所有 shell 權限；它更適合產生計畫、風險提示與驗收標準。
  • ChatGPT Codex 是工程執行代理，適合讀檔、改檔、跑測試、整理 diff 與回報。
  • Hermes 是控制平面，負責把外部訊息變成可追蹤的任務。
  • 三者之間最好用結構化 job contract 溝通，不要只靠聊天文字傳來傳去。
  • 這篇會給一個可沿用到後續實作的任務狀態機。
  1. 為什麼要拆角色
  2. 三個角色一句話講清楚
  3. Hermes 不只是轉發器，而是控制平面
  4. 任務契約：不要只傳自然語言
  5. 狀態機：從 draft 到 done 的路徑
  6. 什麼任務可以自動，什麼任務要人工 approve
  7. 下一篇會補的安全隔離

為什麼要拆角色

很多人做 AI 機器人的第一個衝動，是把 Telegram 或 Web UI 直接接到一個最強模型，再讓模型自己決定要不要跑 shell。這樣 demo 很快，但長期很危險：你會很難回答「是誰決定的」、「誰執行的」、「執行前有沒有審批」、「出錯時怎麼回復」。

比較穩的方式，是把系統拆成三層：想、做、回報。Claude 可以很會想，Codex 可以很會做，Hermes 則要像一個冷靜的管家，負責把事情排好、擋住危險操作、留下紀錄。

如果你未來要把這套系統接到交易所提醒、行情分析或資產看板，建議先做只讀和通知，不要一開始做自動下單。你可以用 OKX 或 Bybit 了解 API、KYC、費率、商品型態與所在地限制；但任何涉及槓桿、下單、提領、API key 權限的功能，都應該放到安全篇之後再做。

三個角色一句話講清楚

角色 在系統裡像什麼 最適合做 不應該直接做
Claude 規劃者 / 審稿者 理解需求、拆任務、寫驗收標準、審查結果、整理回覆 直接持有高權限 shell、直接保管所有密鑰
ChatGPT Codex 工程執行代理 讀 repo、改檔、跑測試、修錯、產生 diff、回報執行結果 繞過審批執行危險命令
Hermes 控制平面 / 任務管家 驗證使用者、建立 job、排隊、審批、紀錄、回傳、重試 替代模型做複雜推理，或把所有錯誤吞掉
Claude、Codex、Hermes 角色分工圖，Claude 負責規劃、Codex 執行、Hermes 管狀態與回報
Claude、Codex、Hermes 角色分工圖，Claude 負責規劃、Codex 執行、Hermes 管狀態與回報

這樣拆有一個好處：每一層犯錯時，其他層可以攔截。Claude 計畫太大，Hermes 可以要求縮小任務；Codex 想改太多檔案，Hermes 可以卡在 approve；Telegram 入口收到陌生人訊息，Hermes 可以在第一步拒絕。

Hermes 不只是轉發器，而是控制平面

如果 Hermes 只是把 Telegram 訊息轉給 Claude 或 Codex，它就太薄了。真正有用的 Hermes 至少要保存五種東西：

Hermes 應保存 用途
actor 誰發起任務，例如 Telegram user id、Slack user id、Web Console 帳號
intent 使用者想完成什麼，不等於直接命令
riskLevel 低、中、高風險，決定是否需要人工審批
workspace 任務可以碰哪個資料夾或 repo
auditTrail 每一步誰決定、誰執行、輸出是什麼

這裡要特別分清楚「意圖」和「命令」。使用者說「幫我更新文章」，這是意圖；python deploy.py 是命令。意圖可以交給 Claude 先拆，命令要經過 Hermes 的規則和審批。

任務契約：不要只傳自然語言

實作上，可以讓 Hermes 建立一個 job JSON。這不是為了炫技，而是為了讓 Claude、Codex、人類都看同一份任務資料。

{
  "jobId": "20260613-telegram-hermes-001",
  "actor": {
    "entrypoint": "telegram",
    "userId": "123456789"
  },
  "intent": "把第一篇文章的表格檢查一次，確認手機可滑動",
  "riskLevel": "medium",
  "workspace": "/srv/ai-work/articles",
  "allowedActions": [
    "read_files",
    "run_tests",
    "write_report"
  ],
  "requiresApproval": false,
  "status": "draft"
}

Claude 拿到這份 job，可以回一份 plan：

{
  "jobId": "20260613-telegram-hermes-001",
  "plan": [
    "讀取 index.html 和 CSS",
    "檢查 table-wrap 是否存在",
    "用桌機與手機 viewport 測 scrollWidth",
    "回報是否需要修正"
  ],
  "riskNotes": [
    "只讀與預覽檢查，不需要修改正式資料"
  ],
  "recommendedExecutor": "codex"
}

Codex 執行後，不應該只回一句「好了」。比較好的回報是：做了什麼、改了哪些檔案、跑了哪些檢查、還有什麼風險。

狀態機：從 draft 到 done 的路徑

最小可用的任務狀態可以這樣設計：

狀態 說明 誰可以推進
draft Hermes 收到意圖，還沒交給模型 Hermes
planned Claude 產生計畫與風險判斷 Claude / Hermes
waiting_approval 任務涉及寫檔、部署、金流或高風險操作 人類
queued 任務已允許，等待執行 Hermes
running Codex 或 runner 正在執行 Codex / runner
review 執行完成，等待人類或 Claude 檢查 Claude / 人類
done 任務完成，可回報入口 Hermes
failed 任務失敗，保存錯誤與下一步 Hermes

狀態機的價值，是讓系統不會只剩「正在跑」和「跑完了」。當你開始讓 AI 做真事，最常見的問題不是模型不聰明，而是中間狀態不清楚。

什麼任務可以自動，什麼任務要人工 approve

任務類型 例子 建議
低風險只讀 查狀態、讀 log、整理摘要 可自動
中風險寫檔 改文章、改設定、產生報告 可要求 preview 後 approve
高風險執行 部署、刪檔、改資料庫、推送通知 必須人工 approve
金流 / 交易 下單、提領、改 API key 權限 第一階段不要自動化
帳號 / KYC 登入後台、改身份資料、提交文件 不建議讓 agent 自動操作

一個簡單原則：能重跑、能還原、沒有資金風險的任務，才可以考慮自動；不可逆、會影響外部使用者、會動到錢或帳號權限的任務，都要人工確認。

下一篇會補的安全隔離

這篇先把角色和資料流拆清楚，下一篇才談主機本身要怎麼隔離：低權限帳號、工作資料夾、API key、網路、審批、audit log、備份與 kill switch。

先把分工講清楚，是因為安全不是只靠一個 Docker 或一台 VM。真正安全的 AI 主機，是入口、模型、執行器、資料夾、密鑰和人類審批都各自有邊界。

延伸閱讀

大家都在問

脆上快聊，群裡慢慢拆。

脆友問Claude 和 Codex 不能互相取代嗎

脆上怎麼說看脆 可以部分重疊，但本文刻意分工。Claude 可以協助寫程式，Codex 也可以規劃；但在可追蹤系統裡，把 Claude 當規劃與審查層、Codex 當工程執行層，責任會更清楚。

剛入坑群友問Hermes 一定要是獨立服務嗎？

老群友答 不一定。早期可以是一個 Python 程式或 Node service；等任務變多，再拆成 API、queue、worker、database。重點是它要保存狀態和權限，不只是轉發訊息。

脆友問所以為什麼要用 JSON job contract啊

脆上怎麼說看脆 因為自然語言容易模糊。JSON contract 可以明確記錄 actor、intent、workspace、riskLevel、allowedActions 和 status，後續審批、回放、除錯都比較穩。

剛入坑群友問什麼時候需要人工 approve？

老群友答 只要任務會寫檔、部署、刪除資料、改權限、碰金流或影響外部使用者，就應該進入 waiting_approval。第一階段寧可多一步確認。

剛入坑群友問這套架構會不會太重？

老群友答 如果只是自己玩，可以很輕；但一旦 AI 主機要碰 repo、後台、API key 或交易工具，這些邊界會省下很多事後補救成本。

資料查證：2026-06-13。本文參考 OpenAI Codex 官方產品與開發者文件、Anthropic Claude 產品資料、Telegram Bot API 與 OWASP Secrets / Logging Cheat Sheet；實際產品能力、API、權限與安全建議仍以官方最新資訊為準。

延伸閱讀

隨機文章