問題
資安團隊經常在聊天工具裡收到審查請求：一份 Terraform、一份 SaaS 設定態勢匯出檔、一包廠商的 SOC 2 文件、一張架構圖，或一疊稽核證據。用一個通用 prompt 處理這些東西，效果很差。它把找問題、對應法規框架與提出修補混在一起，容易把不相干的控制項硬套到文件上，或是去修沒有人發現的問題。
我們要的是第一輪審查：一致、有邊界、每個結論都能回溯到文件中的證據，而且不必每次由人挑選審查者。
做法
Hermes 跑在 Hermes Agent 上，這是開源、可自行架設的 agent 框架。審查團隊由 11 個 skill 組成，職責嚴格切開：
- 單一入口。
security-lead是使用者在 Slack 唯一會對話的 skill，負責分類請求，自己不做任何技術分析。 - 單一 orchestrator。 一個在背景執行的 orchestrator，在同一個生命週期內跑完整場審查。
- 專責 reviewer。 七個領域 reviewer（SaaS 設定態勢、AWS、Snowflake PCI、應用程式安全、廠商風險、稽核證據、架構），加上三個核心角色：弱點發現者、法遵 reviewer、修補工程師。
每個 reviewer 只輸出一張固定格式的表，不多說，也都不提修補方案。修補工程師只修交給它的 finding，不得重新審查。法遵 reviewer 先判斷適用性，文件缺乏範圍證據時回答「Cannot Assess」，不硬套控制項。
運作方式
- 受理。
security-lead讀取文件，依路由表選路線：AWS 審查交給 AWS 與法遵 reviewer，廠商審查交給廠商與稽核證據 reviewer，不明確的請求交給架構、資安與法遵。它從不一次派出所有 reviewer。 - Phase A。 orchestrator 平行執行選定的 reviewer，並把它們的表格視為正式（canonical）結果。
- Phase B。 只有具體的技術 finding 才會交給修補工程師，而且該審查類型要允許修補。廠商與稽核證據審查改為輸出後續追問與風險決策點。
- 報告。 orchestrator 存下一份五段固定結構的報告，並在 Slack 回覆摘要與完整報告附件，手機也能直接開啟。內文用繁體中文，程式碼與識別字維持英文。
有兩個執行期細節很重要。delegation 深度至少要是 2，否則 orchestrator 會被降級為末端 worker，無法啟動 reviewer。而且頂層 delegation 在背景執行，所以各階段要放在 orchestrator 裡，不能拆成多輪聊天。
成果
- 11 個 skill、一份設計文件與一組 Python 契約測試（contract test）已就緒。測試檢查每個 skill 的 front matter 有效、
security-lead含完整路由表與單一 orchestrator 契約、領域 reviewer 拒絕直接請求並導回security-lead，以及修補只依據正式 finding。 - agent 本身在使用前先經過審查：安裝腳本先審閱、不直接 pipe 給 shell；指令在容器內執行；API key 放在 macOS keychain；並在容器中通過 7/7 項行為檢查，包括唯讀任務、未經核准不 commit、不讀取真實機密。
- 端到端：從 Slack 請求到存檔報告的完整流程已經跑通。契約測試仍然只證明檔案彼此一致；在真實文件上的審查品質要逐案判斷。
學到的事
- 把「找問題、對應法規、提修補」分開。每個角色只有一種窄輸出，且被禁止做別人的工作，虛構的 finding 就更難藏身。
- 檢查管線，不只檢查 prompt。像 delegation 深度這種執行期限制，會在 skill 文字沒有任何錯誤的情況下改變行為，所以契約測試與部署指南都把它記下來。
- 隔離優先於核准提示。最初安裝的版本中，容器隔離與人工指令核准互斥，我們選擇真正的隔離，而不是一個人人都會習慣性點掉的提示。