三行摘要
• 一位非工程師，在 **4 套執行系統**（Claude Code、Codex、OpenClaw、Hermes）上經營 **20 位 AI 員工**的團隊——剛開始不是團隊，是噪音。
• 本文記錄 3 件真實事故（機器人掛了卻亮綠燈、HTTP 200 陷阱、同一網站的人數寫成 4 種），以及修好它們的 **5 條協作規則**。
• 結論：AI 代理協作（Agent Orchestration）拚的不是 AI 的聰明程度，而是**結構設計**——分工、閘門、帳本、交接。
這篇文章是誰寫的
Bella 是從零程式經驗開始的非工程師，現在的職稱是 AI Agent Orchestration Architect——AI 自動化設計師、多智能體系統架構師。一句話：*設計讓 AI 們真正能一起工作的團隊。*文中所有數字都是 2026 年 8 月 12~15 日的實測。
背景——四套系統各跑各的，結果是噪音
我們的 AI 執行系統有 4 套。一開始想「越多越好」，結果是每套都很努力，卻彼此不知道對方在做什麼：同一篇文章被兩個頻道重複發布、機器人掛了螢幕卻亮綠燈、同一個網站裡團隊人數被寫成 16、17、18、20 四種版本。問 AI「這個團隊有幾個人」，答案會隨資料來源而變——AEO 觀點的最糟狀態。
4 套系統的分工地圖
🖥️ Claude Code——主力大腦。寫作、分析、開發等深度工作的本體。188 個技能檔（實測）加上檔案化記憶，讓昨天與今天的工作接力。排程器每天早上叫機器人自己上班。
🔍 Codex——交叉驗證夥伴。刻意把別家公司的 AI 放在旁邊，同一個問題讓兩個 AI 都做，結論不同時才由人來看。一個 AI 的「我很確定」不是證據。
🌙 OpenClaw——24 小時駐守艦隊（Mac mini）。6 位機器人隨時在 Slack 待命，關了電腦也不睡。Instagram 定期發布走 6 道閘門的簽核流程。
📈 Hermes——測量線。只做不量等於不知道。專門測量 SEO、AEO、GEO 曝光。
重點不是工具清單，而是邊界。沒有邊界時，每套系統什麼都做一點，最後沒有人負責。
3 件事故——規則誕生的地方
事故 1 · 機器人掛了，燈卻是綠的。電子報連續 5 天沒寄出，排程器上卻「已登錄」。結果代碼全是 0x800710E0——筆電用電池時 Windows 預設拒絕執行排程。學到：不能只確認「登錄了沒」，要確認「這個設定跑得動嗎」。
事故 2 · 已刪除的文章，伺服器照樣回 200。同一篇文章發了兩次，帳本記下刪了哪一篇——後來發現記反了，因為兩個網址都回 HTTP 200。判定標準改成「RSS 清單裡有沒有」。
事故 3 · 同一個網站，人數有 4 種版本。用手改的數字下次一定再走樣。修法：確定唯一正本檔案、所有頁面從正本讀取、加上建置閘門——數字不一致就擋下部署。閘門第一次執行就抓到人眼漏掉的 1 筆違規。
5 條協作規則
1. **指令留在 Slack**——口頭的會消失，寫下的才能被接手
2. **交接用文件推送**——視窗關了，下一個工作階段一句「同步」就能接手
3. **狀態只記在一本帳**——發布與否看實物（RSS、API），不看日誌
4. **事故升級成閘門**——沒放進閘門的錯，下次一定再犯
5. **確定要買兩次**——重要結論讓另一套系統反方詰問
實際運作的樣子：Mac mini 上 5 位機器人在 Slack 討論串互相把關 6 道閘門，最近一次擋下圖片日期錯誤、重繪、再驗、發布——全程 26 分鐘，人類介入 0 次。
誠實的限制——目前還做不到的事
• **Hermes 測量線目前停業中**——公司電腦汰換時撤離了 5,659 個檔案，等待重啟。今天實際運轉的是 3 套。
• **檢查工具也會老化**——把正常判成失敗的誤報每月都有幾次，閘門本身也要持續再驗證。
• **機器人的回報也不能全信**——出現過抓錯原因、事後重構的回報，所以更需要實物驗證原則。
結語
協作拚的是設計，不是指揮。從 1 位機器人到 20 位的過程中，改變的不是 AI，是結構。數字總結：執行系統 4 套 · AI 代理 20 位 + 人類 1 位 · 技能檔 188 個 · 協作規則 5 條 · 發布閘門 6 道。