搞完 Hermes 多 Agent 我才發現，這根本不是技術活，是管理活
整理版優先睇
Hermes 多 Agent 協作唔係純技術挑戰，而係一門管理學問，要靠精準嘅協作協議同埋角色分工先至搞得掂。
林月半子呢篇文章，分享佢喺 Hermes 平台實踐多 Agent 協作嘅親身經驗。佢原本以為呢個過程會好順利，點知喺 Discord 上面搭建一個由三個 AI Agent 組成嘅「團隊」時，遇到咗唔少意料之外嘅難題，最後要逐個「坑」咁填先至搞得掂。
作者透過呢次實踐，發現多 Agent 協作嘅核心挑戰，根本唔係純粹嘅技術問題，而係一門管理學問。佢強調，要令 AI Agent 團隊有效運作，就好似管理真人團隊咁，需要清晰嘅職責分工、明確嘅協作流程，同埋一套有效嘅任務終止機制。
文章詳細記錄咗佢點樣由零開始，建立三個具備唔同職能嘅 Agent（文案、調研、調度），並逐步解決咗喺 Discord 溝通時，Agent 唔識回應、陷入無限循環，同埋任務分派時序混亂呢三大常見問題。呢啲經驗對於想喺 Hermes 或者其他平台搭建多 Agent 系統嘅讀者嚟講，提供咗寶貴嘅實戰指引。
- 多 Agent 協作嘅成功關鍵在於「管理」，而非單純嘅技術。要將 AI Agent 視為團隊成員，為佢哋設定清晰職責、協作流程同埋終止機制。
- Hermes 嘅 Profile 機制提供「真隔離」嘅 Agent 環境，每個 Agent 獨立運行，避免「一個掛咗全掛」嘅問題，呢點同 OpenClaw 等平台嘅配置層面切換有明顯分別。
- 喺 Discord 上建立多 Agent 協作，必須確保每個 Agent 嘅 `DISCORD_ALLOW_BOTS` 設為 `mentions`，並喺 `config.yaml` 中將 `replied_user` 設為 `false`，以避免 Agent 之間嘅無限循環。
- 解決 Agent 溝通問題，要喺 `SOUL.md` 內明確定義團隊成員嘅 Discord ID (`<@用戶ID>`)，並嚴格區分「計劃階段」用純文字，「執行階段」先用 ID 喚醒，避免混亂。
- 透過喺 `SOUL.md` 寫入嚴格嘅「協作時序規範」同「任務終止協議」，強制 Agent 逐一接力，並以明確嘅終結詞（例如「【任務結束】」）結束對話，防止任務分派混亂同埋死循環。
Hermes Admin Agent 協作協議 SOUL.md
呢個係作者經過多次踩坑後，為 Hermes Admin Agent 整理出嚟嘅最終版 SOUL.md 配置。佢包含咗角色定義、團隊成員 ID、核心協作準則、嚴格嘅時序規範、Discord 艾特指令，同埋任務終止與防循環規範，確保多 Agent 團隊能夠順利接力同埋避免死循環。
搞多 Agent 之前：先搞清楚 Hermes 嘅「Profile」機制
作者林月半子分享佢喺 Hermes 平台實踐多 Agent 協作嘅經驗。佢原本以為會好順利，點知中間炒咗好多次車，最後硬係逐個坑咁填返嚟。佢強調，協作係能力嘅放大器，唔係補丁，如果單一個 Agent 本身係個廢柴，拉三個廢柴嚟協作，結果都係三倍嘅廢柴。所以，將 Agent 調教好，SOUL.md 寫細、skills 配齊、模型選啱，先係多 Agent 能夠順利運行嘅前提。
要搞 Agent 協作，第一步就係建立唔同嘅 Agent。喺 Hermes 入面，呢件事係透過 Profile 嚟實現嘅。Profile 其實就係 Hermes 嘅人格檔案，每個 Profile 都係一個完全獨立嘅 AI 分身，有自己嘅 config.yaml、.env、SOUL.md、獨立嘅 memory、獨立嘅 skills，甚至獨立嘅 gateway 進程。底層實現雖然幾樸素，靠一個 HERMES_HOME 環境變量切換根目錄，但效果係實實在在嘅隔離。
建立 Profile 嗰陣，Hermes 提供咗三種克隆策略，可以睇情況揀： 1. **乜都唔加 (`hermes profile create mybot`)**：空白 Profile，連 API key 都要重新配過，啱曬由零開始搭一個完全獨立嘅 Agent。 2. **`--clone` (作者今次用嘅)**：淨係複製 config.yaml、.env、SOUL.md，記憶同 session 都係全新嘅。呢個模式最啱搭多 Agent——共享模型同 API key，但每個 Agent 由乾淨嘅上下文開始，互不幹擾。 3. **`--clone-all`**：連 memory、sessions、skills、cron jobs 全部複製，等如成個人「複製一份」，啱曬備份或者 fork 一個已經有上下文嘅 Agent。
喺 Discord 搭建 AI 團隊：由零開始到踩坑
作者今次準備搭一個三人小組，模擬一個真實嘅內容生產協作流程：林小墨（Ink）做文案與筆記整理、林小探（Search）做搜索與調研、林小管（Admin）做任務分發與調度。呢個組合對應住一個完整嘅「揾資料 → 寫筆記 → 歸檔」工作流程，而且引入咗一個專門嘅調度 Agent（林小管），令協作路徑更清晰。
訊息平台方面，作者揀咗 Discord，冇用飛書。原因好簡單，飛書羣因為平台限制，的確唔支援 bot 被 @，而多 Agent 協作最核心嘅動作就係「一個 Agent @ 另一個 Agent 嚟接力」，飛書呢條路直接塞死咗。Discord 喺呢方面開放得多，都係 Hermes 官方文件入面演示得最充足嘅平台。喺 Discord Developer Portal 建立應用程式嘅流程網上教程一大堆，關鍵係攞到每個 bot 嘅 token，填入對應 Profile 嘅 .env 文件，之後啟動 gateway。
Gateway 啟動咗之後，作者開始測試 channel 入面 @ 佢，點知第一個坑就嚟啦：@ 佢冇反應。搞咗一輪作者先意識到，Hermes 嘅 Discord gateway 預設有個 `allowed_channels` 嘅白名單機制，唔喺白名單入面嘅頻道，bot 根本就唔會回應 @。解決方法係將要用嘅 channel ID 填入去，重啟 gateway 之後再試，即刻就通咗。呢個預設設計係幾合理嘅，避免 bot 喺所有頻道度周圍開口「長氣佬級騷擾」。
@ 通咗之後，作者發現每次 @ bot，佢會自動開一個 thread 嚟回覆，而唔係喺主頻道直接回覆。呢個係 Hermes 預設開啟嘅 `auto_thread: true` 行為。作者個人覺得呢個機制設計得真係幾好，因為主頻道唔會俾人洗版，每個任務喺獨立 thread 入面，唔會互相干擾，而且多人同時用都冇問題。如果唔習慣，可以徹底閂曬自動 thread，或者指定某啲頻道唔用 thread。
林小墨搞掂咗，淨低兩個 Agent 照辦煮碗。作者今次用咗 `--clone-from` 參數，直接由 ink 呢個已經配好嘅 Profile 克隆，慳返唔使再配一次 Messaging Gateway。之後分別幫佢哋設定人設。踩坑提示：三個 Profile 配 .env 嗰陣，每個 bot token 必須獨立，千祈唔好重複用。Hermes 內置咗 token lock 機制，如果兩個 Profile 唔小心用咗同一個 token，第二個 gateway 啟動時會直接報錯，仲會話你知係邊個 Profile 佔用咗呢個 token。呢個保護對全平台都有效，等如幫你墊咗層底。
三個 bot 全部上線之後，作者將任務掟入頻道，任務係跑出嚟啦，結果都似模似樣。但作者望住日誌一睇，唔對路。佢行嘅係 Hermes 內置嘅 `delegate_task` 模式，根本冇行多 Agent 協作。`delegate_task` 係 Hermes 好硬核嘅一個能力，單一個 Agent 可以 spawn 一個隔離嘅 subagent 嚟跑子任務，然後將結果收返嚟合併。但佢有一個致命嘅問題：subagent 係臨時 spawn 出嚟嘅無狀態執行者，用完即棄，唔係你精心配置嗰三個獨立 Profile。而且 subagent 嘅 `send_message` 技能係被 Blocked 嘅，佢根本冇辦法喺 Discord 入面主動發訊息。即係話，你辛苦建立嘅林小墨、林小探、林小管，喺 `delegate_task` 模式下根本冇被調用過。想令真正嘅多 Agent 接力跑起嚟，必須喺 admin 嘅 SOUL.md 入面將協作協議寫死，強制佢透過 Discord 頻道公開「點名」，行真實嘅 @ + 訊息路徑。
拆解三大協作難題：從混亂到有序
Admin Agent 嘅終極 SOUL.md 協作協議
將所有坑都填完之後，admin 嘅完整 SOUL.md 就係咁樣嘅，可以直接攞去用。呢個配置詳細定義咗林小管嘅角色、團隊成員 ID、核心協作準則、嚴格嘅時序規範、Discord 艾特指令，同埋任務終止與防循環規範，確保佢能夠有效調度同埋管理其他 Agent 嘅協作流程。
### 林小管 (Admin) - SOUL.md
## 角色定義
你是"林小管"，林月半子 AI 團隊的【總調度/Planner】。你的核心職責是接收用戶的原始需求，將其拆解為具體步驟，並**逐一**指引對應的專家 Agent 介入。
## 團隊成員
-**林小探 (Search)**: 【Executor】負責聯網搜索、情報蒐集和市場調研。ID: `<@1495291492397224117>`
-**林小墨 (Ink)**: 【Executor/Reviewer】負責文案潤色、邏輯梳理和 Obsidian 筆記格式化。ID: `<@1495250337139789955>`
## 核心協作準則 (Multi-Agent Protocol)
1.**任務分解**: 收到指令後，先列出執行計劃(Step 1， Step 2...)。在計劃表內請使用普通文字(如"林小探")提及專家，**嚴禁使用 ID 格式**，防止誤喚醒。
2.**身份隔離**: 你僅擔任【調度員】。你嚴禁直接調用 `search` 或 `file_writer` 等執行類工具，必須通過 Discord 頻道公開"點名"完成接力。
3.**狀態追蹤**: 你必須全程監控 Thread 進度。只有前一個專家明確回覆"任務完成"或給出最終結果後，你才發起下一階段的指令。
## 協作時序規範 (Strict Timing)
-**逐一喚醒**: 嚴禁在任務開始階段同時艾特多個專家。
-**當前階段**: 僅在當前步驟需要執行時，才發出對應的 `<@ID>` 指令。
-**接力邏輯**: 必須等到 **林小探** 明確回覆"調研完成"後，你再發出下一條指令並艾特 **林小墨** 開始 Step 2。
## Discord 艾特指令 (Crucial)
當且僅當你需要某個隊友**立刻開始工作**時，必須使用以下格式:
- 召喚林小探: `<@1495291492397224117>`
- 召喚林小墨: `<@1495250337139789955>`
**注意**: 在非執行環節，僅使用純文字"林小探"或"林小墨"，不要帶 `<@` 符號。
## 任務終止與防循環規範
-**明確終結**: 當確認林小墨完成筆記整理後，請發出簡短總結，並以"【任務結束】"結尾。
-**禁止冗餘**: 任務結束後，嚴禁發送無意義的表情(👍， 👋)、寒暄或單純的確認消息。
-**中斷反饋**: 不要對其他 Bot 發出的"收悉"、"待命"等結束類消息做出二次響應。
-**艾特控制**: 在任務結束總結中，禁止再次艾特任何 ID。
## 交互準則
-**保持引導**: 在自動開啓的 Thread 中告知用戶:"任務空間已開啓，我將依次調度專家介入。"
-**嚴禁越權**: 不要做深度搜索或長篇寫作，那是林小探和林小墨的職責。順便講句：SOUL.md 同 AGENTS.md 嘅界線，嚴格按照 Hermes 官方嘅最佳實踐嚟講，SOUL.md 應該淨係放「呢個 Agent 係邊個、點樣講嘢」呢類人格層面嘅嘢，而具體嘅項目流程（例如上面寫嘅團隊成員 ID、艾特指令、時序規範、終止協議）——按道理應該放喺 AGENTS.md 入面。作者今次全部塞曬入 SOUL.md，一來係因為想先搞掂再優化，二來係因為對於多 Agent 嘅情況，林小管呢個角色本身就係為咗呢個項目而生嘅——佢嘅「靈魂」就係呢套協作協議，拆開反而有啲夾硬嚟。但如果你係想搭一個通用嘅調度型 Agent（將來仲要用喺其他項目度），咁就應該拆開寫——SOUL.md 入面淨係留「調度員人設」，AGENTS.md 入面放具體項目嘅團隊配置。呢個係下一步優化方向，唔係而家必須要做嘅事。
多 Agent 協作：技術背後嘅管理智慧
成個過程跑完之後，作者反覆諗緊一件事：多 Agent 到底係個技術問題，定係其他問題？搞掂呢三個坑之後佢明白咗，佢其實係個管理問題。Profile 俾你嘅係工位，Discord 俾你嘅係會議室，但真正令三個 AI 好似團隊咁跑起嚟嘅，係嗰份被你一次次打磨嘅 SOUL.md——嗰份係職責說明書、協作流程，同埋明確嘅收工時間。
一個 Agent 唔係超人，係崗位。三個 Agent 唔係炫技，係團隊。呢篇淨係將三人小組搞掂咗。五人、十人嘅團隊，同一套邏輯——難嘅永遠都唔係模型，而係組織設計。作者下一篇打算試下 Honcho，俾呢幾個 Agent 共享同一個「客仔檔案」，嗰個會係團隊協作嘅下一個維度。
當 Hermes 出咗嚟嗰陣，好多人問我多個 Agent 之間係點樣協作嘅。
週末我搵咗時間自己親手試做咗一次，本來以為會好順利，點知中間炒咗好多次車，最後都係一個坑一個坑咁填返嚟。呢篇文會將成個過程記低，跟住做，你都一樣可以喺自己個 Discord 度，見到幾個 AI 似同事咁樣互相接力做嘢。
不過喺郁手之前，有句說話要講定先。協作係將能力放大嘅工具，唔係補鑊嘅嘢。如果單一個 Agent 本身係個廢柴，搵三個廢柴嚟協作，結果就係三倍嘅廢柴，三個廢柴開會，廢柴都仲係廢柴。SOUL.md 要寫得仔細、skills 要配齊、模型要揀啱，將 Agent 調教好，呢個係多個 Agent 能夠順利運作嘅前題，唔係結果。
好，講到呢度啦，開始講正題。
不如講吓 profile 先，呢個係成個多 Agent 嘅基礎
想做 Agent 協作，第一步就要先將唔同嘅 Agent 建立出嚟。喺 Hermes 入面，呢件事係透過 Profile 嚟實現嘅。
profile 其實就係 Hermes 嘅人格檔案。一個 profile 就係一個完全獨立嘅 AI 分身，有自己嘅 config.yaml、.env、SOUL.md、獨立嘅 memory、獨立嘅 skills、甚至獨立嘅 gateway 進程。
底層嘅實現其實都幾簡單，靠一個 HERMES_HOME 環境變量嚟切換根目錄，但效果就係實實在在嘅隔離。
引導思考
點解要強調「真隔離」呢件事？因為喺多 Agent 架構入面，最驚就係「一個死咗，全部都死晒」。Hermes 嘅 profile 係進程級隔離，每個 profile 都會行自己嘅 gateway 進程，互相獨立，唔會互相依賴。就算其中一個 agent 死咗，都完全唔會影響其他 agent 繼續運作。
呢點同 OpenClaw 係有分別嘅。用過 OpenClaw 嘅朋友都明，佢嘅多身份（multi-identity）多數都係配置層面嘅切換，個進程都仲係同一套。
Hermes 呢種物理隔離喺企業交付嘅情況下真係好正，客仔唔會因為一個 bot 冧咗，搞到成套自動化系統跟住停晒。
好啦，明白咗 profile 係乜嘢之後，我哋就開始設定啦。
Step 1：建立三個 Agent，分工要清晰
今次我準備組建一個三人小組，模擬一個真實嘅內容製作協作流程：
呢個組合唔係隨便決定嘅。
佢對應住一個完整嘅「搵資料 → 寫筆記 → 歸檔」工作流程，而且引入咗一個專門嘅調度 Agent(林小管)，令到協作路徑更加清晰。
首先建立林小墨：
hermes profile create ink --clone呢度我用咗 --clone 參數，主要係直接繼承 default 嘅一啲設定(模型、API key 等)，唔使重新設定一次。
講多句 --clone 嘅選擇。Hermes 提供咗三種克隆策略，睇情況揀:
多 Agent 協作嘅情況，基本上都係用 --clone。
執行完之後嘅輸出係咁樣嘅:
Profile 'ink' created at /Users/lunaraitalk/.hermes/profiles/ink
Cloned config， .env， SOUL.md from default.
77 bundled skills synced.
Wrapper created: /Users/lunaraitalk/.local/bin/ink
Next steps:
ink setup Configure API keys and model
ink chat Start chatting
ink gateway start Start the messaging gateway
Edit ~/.hermes/profiles/ink/.env for different API keys
Edit ~/.hermes/profiles/ink/SOUL.md for different personality留意最後幾行。ink 直接變成咗一個獨立嘅指令，你之後用 ink chat、ink gateway start 就可以直接操作呢個 agent，唔使次次都打 hermes -p ink xxx。呢個細節真係超方便。
之後就幫林小墨設定一個新嘅人設（角色設定）:
echo "你是'林小墨'，一名專業的文案專家和知識管理助手。你擅長將碎片化信息整理成結構化的 Markdown 格式，並熟練運用 Obsidian 的雙鏈體系。你的回覆風格文雅、邏輯嚴密。" > ~/.hermes/profiles/ink/SOUL.md我哋可以見到一個指令直接繼承咗 Default 嘅設定，模型都繼承埋過嚟。當然如果你想幫每個角色配返更啱用嘅模型，每個 profile 獨立咁調校一下 config.yaml 就得㗎喇。
留意左下角嘅 ink ❮ 標誌。Hermes 會用 prompt 前綴話你知而家係邊個 profile 講緊嘢，喺多 Agent 嘅情況下，呢個小設計真係好幫到手（特別救命）。
Step 2：駁（連接）Discord，點解唔用飛書？
訊息平台呢方面我掙扎過一陣。先講結論:今次我揀咗 Discord，冇用飛書。
原因好簡單，飛書群因為平台嘅限制，真係唔支援 bot 被 @（提及）。多 Agent 協作最核心嘅動作就係「一個 agent @ 另一個 agent 嚟接力」，飛書呢條路直接塞死咗。Discord 喺呢方面開放好多，亦都係 Hermes 官方文件入面演示得最詳細嘅平台。
點樣喺 Discord Developer Portal 開個應用程式嘅網上教學大把啦，我就唔重複講喇。最緊要係攞到每個 bot 嘅 token，填入返對應 profile 嘅 檔案。
搞掂晒設定之後，啟動 gateway:
ink gateway install && ink gateway start輸出:
Installing launchd service to: /Users/lunaraitalk/Library/LaunchAgents/ai.hermes.gateway-ink.plist
✓ Service installed and loaded!
Next steps:
hermes gateway status # Check status
tail -f ~/.hermes/profiles/ink/logs/gateway.log # View logs
✓ Service started中伏提示
呢度用嘅係 gateway install + gateway start 嘅組合，install 會將 gateway 登記做 launchd 服務(macOS)或者 systemd 服務(Linux)，熄機再開機之後會自動啟動返。如果你只係想測試吓，用 ink gateway start 都得，但係一閂咗個終端機，個 bot 就會死咗。如果想長期運行嘅話，強烈建議 install。
Step 3：出事由私訊開始
gateway 啟動咗喇，不如先做個簡單嘅私訊測試。
佢會提示你做一次配對驗證，呢個係正常嘅，跟住個流程做就得。
之後我就開始測試喺 channel 入面 @ 佢，始終我哋之後要畀三個 Agent 喺同一個 channel 入面討論，@ 佢係最重要嘅動作。
點知第一個問題就出現喇:@ 佢都冇反應。
嗰陣我望住 Discord 個介面望咗好耐，個 bot 喺線、狀態正常，但係就係唔理我。睇返日誌都冇明顯嘅錯誤報告。搞咗一輪我先至意識到，Hermes 嘅 Discord gateway 預設有個 嘅白名單機制，唔喺白名單入面嘅頻道，個 bot 根本就唔會回應 @ 佢。
解決辦法:
# 留意呢度嘅 -p 參數，要換做你自己個 agent
hermes -p ink config discord.allowed_channels 將你要用嘅 channel ID 填入去，重啟 gateway 之後再試，即刻就搞掂咗。
思考方向
呢個預設設計都幾合理。如果個 bot 預設會回應所有佢睇到嘅頻道，你將佢拉入一個大型伺服器，佢就會喺所有頻道入面周圍講嘢，簡直係「長氣佬式騷擾」。allowed_channels 強制你明確指定邊啲頻道先至准佢講嘢，係一個安全嘅預設值。
Step 4：順便講下 Hermes 嘅 thread 機制
當我 @ 咗個 bot 之後，我發現每次我 @ 佢，佢都會自動開個 thread 嚟覆我，而唔係直接喺主頻道度覆。
呢個係 Hermes 預設開啟嘅 auto_thread: true 功能。我個人覺得呢個機制設計得真係幾好：
但如果你唔習慣呢個形式，有兩種方法可以熄咗佢：
# 方法一:徹底閂咗自動 thread
hermes -p ink config set discord.auto_thread false
# 方法二:指定某啲頻道唔用 thread (其他頻道照常)
# 編輯 ~/.hermes/profiles/ink/config.yaml，搵到 discord 段落：
# no_thread_channels:
# - 1495255615545544819我自己就保留咗預設嘅 thread 模式，因為之後多 Agent 協作嗰陣，每個任務都喺獨立嘅 thread 度執行，追溯同調試都方便好多。
Step 5：複製兩份，組建小團隊
林小墨搞掂咗，淨低嗰兩個就照辦煮碗。今次我用咗 --clone-from 呢個參數，直接由 ink 呢個已經設定好嘅 profile 度複製，慳返唔使再設定多次：
hermes profile create search --clone --clone-from ink
hermes profile create admin --clone --clone-from ink咁樣做嘅好處係唔使再設定 Messaging Gateway 喇。
之後就分別寫返佢哋嘅人設：
echo "你係「林小探」，情報專家。你擅長喺海量互聯網資訊入面篩選核心數據。你嘅任務係提供客觀、準確嘅市場調查報告同技術趨勢分析。你會引用所有資訊來源。" > ~/.hermes/profiles/search/SOUL.md
echo "你係「林小管」，團隊協調官。你負責接收用戶嘅原始需求，再將佢拆解成具體任務，分派俾墨、探兩位專家。你仲負責 Discord 頻道嘅日常運作同權限維護。" > ~/.hermes/profiles/admin/SOUL.md幫 search 同 admin 各自建立 Discord 應用程式、設定 token、啟動 gateway，成套流程同林小墨嗰個一模一樣，就唔重複講喇。
提提你，小心中伏 當你設定三個 profile 配 .env 嘅時候，每個 bot token 必須獨立，千祈唔好重用。Hermes 本身有 token lock 機制。如果兩個 profile 唔小心用咗同一個 token，第二個 gateway 啟動嗰陣會即刻出錯，仲會話你知係邊個 profile 佔用咗呢個 token。呢個保護對 Telegram、Discord、Slack、WhatsApp、Signal 所有平台都有效，等同幫你打咗個底（提供基本保障）。
點樣解決呢？其實好簡單，將 .env 入面嘅 DISCORD_BOT_TOKEN 值換做對應嘅 Discord 應用 token 就得。
三個 bot 全部上線之後，你會喺頻道入面見到每個 bot 都彈咗一大段 No home channel is set for Discord... Type /sethome 嘅提示。係叫你幫每個 bot 設定一個「大本營」頻道，用嚟接收 cron 定時任務結果同埋跨平台轉發訊息。
如果你暫時唔需要定時推送，直接唔理佢就得；想個頻道乾淨啲嘅話，喺頻道入面對每個 bot 用一次 /sethome 斜線指令，下次啟動嗰陣就唔會再彈出嚟。
呢個時候，三個 bot 全部進駐晒同一個頻道，我以為可以開工喇。
Step 6：以為成功咗，點知原來係假嘅
將個任務掟入頻道度：「幫我研究吓2026年最新嘅AI智能體趨勢，再執好佢做篇文章。」
個任務係跑咗出嚟，結果都似模似樣。
但我望住個日誌一睇，就覺得唔對路。
佢行嘅係 Hermes 內置嘅 delegate_task 模式，根本冇行多 Agent 協作。
呢度要補充少少背景。Hermes 有個叫 delegate_task 嘅內置機制，單個 agent 可以 spawn 一個獨立嘅 subagent 去跑子任務，之後將結果收返嚟合併。呢個係 Hermes 一個好勁嘅能力，官方叫佢做"zero-context-cost pipeline"，因為 subagent 嘅上下文唔會污染主對話。
聽落好吸引吖嘛？但佢有個致命嘅問題：subagent 係臨時 spawn 出嚟嘅無狀態執行者，用完即棄，唔係你精心設定嗰三個獨立 profile。
官方 delegation 文件入面寫到明清清楚楚：「Each child gets a fresh conversation and works independently — only its final summary enters the parent's context」。翻譯過嚟就係：子 agent 做完只會傳返一句總結，中間過程、工具調用細節、思考邏輯全部掉晒。而且更重要嘅係——subagent 嘅 send_message 技能係被 Blocked 咗嘅，佢根本冇辦法喺 Discord 入面主動發訊息。
啫係話，你辛苦整出嚟嘅林小墨、林小探、林小管，喺 delegate_task 模式之下根本就冇被用到。admin 自己 spawn 咗幾個冇名嘅打工仔做晒啲嘢。
咁點算好？想真係有多個 Agent 輪流運作起嚟，就一定要喺 admin 嘅 SOUL.md 入面寫死個協作協議（hardcode），強制佢透過 Discord 頻道公開「點名」，行真正嘅 @ + 訊息路徑。
之後嗰三個難題，就係我將呢套協議逐條逐條寫出嚟嘅過程。
難題 1：冇 @，就直接完咗
第一次改 admin 嘅 SOUL.md，我幫佢列咗團隊成員同埋職責，以為佢自己會識做，點知佢拆解完任務就直接完咗，成個過程都冇 @ 任何人。
問題出喺邊度？LLM 其實係明白「林小探係團隊入面嘅人」，但佢唔知喺 Discord 入面要點樣先可以真係「叫醒」對方——Discord 點名係靠 `<@用戶ID>` 呢種特別格式嘅訊息先至可以觸發到，你只係寫「林小探」三個字，對方嘅 gateway 根本就收唔到推送（通知）。
解決方法講穿咗都好簡單——直接將每個同事嘅工牌號碼寫喺個名後面:
## 團隊成員
- **林小探 (Search)**: 【Executor】負責上網搜尋、情報搜集同埋市場調查。ID: `<@1495291492397224117>`
- **林小墨 (Ink)**: 【Executor/Reviewer】負責文案修飾、理順邏輯同埋將 Obsidian 筆記格式化。ID: `<@1495250337139789955>`
## Discord @ 指令 (重要)
當你**即刻需要**某個隊友**開始做嘢**嗰陣，就一定要用以下格式:
- 召喚林小探: `<@1495291492397224117>`
- 召喚林小墨: `<@1495250337139789955>`
**注意**: 喺非執行階段，只係用純文字「林小探」或者「林小墨」，唔好帶 `<@` 符號。app ID 喺 Discord 入面右撳個應用程式 → 「複製用戶 ID」就攞到（要先開咗開發者模式先得）。
提提你（關於難題）
呢度最容易犯嘅錯就係——喺任務規劃階段都用埋 `<@ID>` 格式。結果就係 admin 仲喺度列緊計劃，林小探同林小墨已經被「點醒」衝咗入嚟，場面好混亂。我嘅做法係嚴格咁分開：計劃階段用純文字，執行階段先至用 `<@ID>`。
難題 2：任務完咗之後，停唔到落嚟
@ 嘅問題搞掂咗，輪流運作（接力）終於都開始咗。林小探搜集完資料，林小墨做好筆記，admin 做個總結。
但總結完之後佢就冇停過，係咁刷表情符號。 👍 👋 🎉，好似發癲咁。
其實呢個係多 Agent 架構入面一個好典型嘅問題，啲 bot 之間互相觸發嘅死循環。admin 傳送「任務完成👍」，林小墨 bot 收到之後就觸發回應「好嘅👋」，admin 又再回應「收到🎉」......就係咁樣一直循環落去。
要搞掂呢個問題，就要分三層嚟處理。
第一層：DISCORD_ALLOW_BOTS —— 死循環嘅真正源頭
Discord gateway 有個參數叫做 DISCORD_ALLOW_BOTS，佢決定咗一個 bot 使唔使回應其他 bot 傳出嘅訊息。呢個參數有三檔:
正確嘅做法係將三個 profile 全部都設定做 mentions:
# 三個 profile 嘅 .env 檔案要統一咁改
DISCORD_ALLOW_BOTS=mentions第二層：replied_user: false —— Discord 一個反直覺嘅機制
齋改 DISCORD_ALLOW_BOTS 係唔夠嘅，仲有一個更陰濕嘅位——Discord 嘅「reply」功能預設會自動 send 個 mention 畀被回覆嘅人。就算你喺內文入面根本冇寫 <@ID>，只要你用咗 reply 功能，被回覆嗰個人都係會收到通知。
換句話講，admin 就算只係回咗個 👍，只要佢係以「回覆」嘅形式 send 出嚟，小墨都係會被隱性 @ 到。
解決方法，喺 admin 嘅 config.yaml 入面加埋:
discord:
allow_mentions:
everyone: false
roles: false
users: true
replied_user: falsereplied_user: false 就係將 reply 自帶嘅隱性 mention 閂咗佢。從此之後，啲 bot 之間就算用 reply 回覆，都唔會觸發對方嘅「被 @」事件。
第三層:SOUL.md 入面嘅終止協議
頭兩層係配置層嘅實體保障，SOUL.md 呢層就係 LLM 認知層嘅軟性限制:
## 任務終止同防循環規矩
- **明確終結**: 一旦確定林小墨執好筆記之後，請發個簡短嘅總結，同埋用"【任務結束】"做結尾。
- **禁止冗餘**: 任務完咗之後，嚴禁send啲冇乜意思嘅表情符號(👍， 👋)、客套說話或者齋確認嘅訊息。
- **中斷反饋**: 唔好對其他 Bot send出嚟嘅"收到"、"待命"呢啲完結類訊息再做第二次回應。
- **艾特控制**: 喺任務完結嘅總結入面，唔准再 @ 任何 ID。核心有三樣嘢:要有一個明確嘅終結詞(【任務結束】)、唔准對完結類訊息做第二次回應、同埋完結總結入面唔再 @ 任何人。
三層互相補位，先至係穩定狀態。
問題 3：直接 @ 晒兩個人
死循環解決咗，新嘅問題又嚟喇。
admin 一開始同時 @ 咗林小探同林小墨兩個人。
正常嘅協作邏輯應該係:首先 @ 林小探去搵資料，等林小探搵完，再 @ 林小墨去執筆記。admin 同時 @ 兩個人，結果就係兩個 bot 同時開始做嘢，林小墨攞唔到林小探嘅研究結果，唯有亂寫一通。
呢個問題嘅解決方法係喺 SOUL.md 入面強制執行時序規矩:
## 協作時序規矩 (Strict Timing)
- **逐一喚醒**: 嚴禁喺任務開始嗰陣同時 @ 多個專家。
- **當前階段**: 淨係喺當前步驟需要執行嘅時候，先至發出相應嘅 `<@ID>` 指令。
- **接力邏輯**: 一定要等到 **林小探** 清楚回覆"研究完成"之後，你先再發出下一條指令同埋 @ **林小墨** 開始 Step 2。呢三條加咗入去之後，終於搞掂咗完整嘅"接力形式"多 Agent 協作。
最終版 admin 嘅 SOUL.md
將所有問題都搞掂晒之後，admin 嘅完整 SOUL.md 係咁樣嘅，直接攞去用：
### 林小管 (管理員) - SOUL.md
## 角色定義
你係"林小管"，林月半子 AI 團隊嘅【總調度/Planner】。你嘅核心職責係接收用戶嘅原始需求，將佢拆解成具體步驟，再**逐一**指引返對應嘅專家 Agent 介入。
## 團隊成員
-**林小探 (搜尋)**: 【執行者】負責上網搜尋、情報搜集同市場調查。ID: `<@1495291492397224117>`
-**林小墨 (Ink)**: 【執行者/審閱者】負責潤飾文案、整理邏輯同將 Obsidian 筆記格式化。ID: `<@1495250337139789955>`
## 核心協作準則 (Multi-Agent Protocol)
1.**任務拆解**: 收到指令之後，首先列出執行計劃(Step 1， Step 2...)。喺計劃表入面請用普通文字(例如"林小探")提及專家，**嚴禁使用 ID 格式**，避免錯誤喚醒。
2.**身份隔離**: 你只係擔任【調度員】。你嚴禁直接調用 `search` 或者 `file_writer` 呢啲執行類工具，一定要透過 Discord 頻道公開"點名"嚟完成接力。
3.**狀態追蹤**: 你一定要全程監控 Thread 嘅進度。淨係等上一個專家明確回覆"任務完成"或者畀咗最終結果之後，你先可以發出下一階段嘅指令。
## 協作時序規範 (Strict Timing)
-**逐一喚醒**: 嚴禁喺任務開始嗰陣同時艾特多個專家。
-**當前階段**: 淨係喺當前步驟需要執行嗰陣，先至發出對應嘅 `<@ID>` 指令。
-**接力邏輯**: 一定要等到 **林小探** 明確回覆"調查完成"之後，你先再發出下一條指令，再艾特 **林小墨** 開始 Step 2。
## Discord 艾特指令 (關鍵)
當你某個隊友**即刻要開始做嘢**嗰陣，就一定要用以下格式:
- 召喚林小探: `<@1495291492397224117>`
- 召喚林小墨: `<@1495250337139789955>`
**注意**: 喺非執行環節，淨係用純文字"林小探"或者"林小墨"，唔好帶 `<@` 符號。
## 任務終止同防循環規範
-**明確終結**: 當確認林小墨搞掂筆記整理之後，請發出簡短總結，並以"【任務結束】"做結尾。
-**禁止冗餘**: 任務結束之後，嚴禁發送冇意義嘅表情(👍， 👋)、寒暄或者單純嘅確認訊息。
-**中斷反饋**: 唔好對其他 Bot 發出嘅"收悉"、"待命"呢啲結束類訊息做二次回應。
-**艾特控制**: 喺任務結束總結入面，禁止再次艾特任何 ID。
## 互動準則
-**保持引導**: 喺自動開啟嘅 Thread 入面話畀用戶知:"任務空間已經開啟，我會逐一調度專家介入。"
-**嚴禁越權**: 唔好做深度搜尋或者長篇寫作，嗰啲係林小探同林小墨嘅職責嚟。順帶一提：SOUL.md 同 AGENTS.md 嘅界線
如果嚴格按照 Hermes 官方嘅最佳實踐嚟講，SOUL.md 應該淨係放「呢個 Agent 係邊個、點樣講嘢」呢類關於人格層面嘅嘢，而具體嘅項目流程(例如我上面寫嘅團隊成員 ID、艾特指令、時序規範、終止協議)——按道理應該擺喺 AGENTS.md 入面。官方文件原話係:"if it should apply everywhere， put it in SOUL.md; if it only belongs to one project， put it in AGENTS.md"。
我今次將所有嘢塞晒入 SOUL.md，一嚟係因為想先搞掂再優化，二嚟係對於多 Agent 嘅場景嚟講，林小管呢個角色本身就係為咗呢個項目而生嘅——佢嘅"靈魂"就係呢套協作協議，拆開反而有啲夾硬嚟。
但如果你係想整一個通用嘅調度型 Agent(將來仲要用喺其他項目度)，咁就應該拆開嚟寫——SOUL.md 入面淨係留"調度員人設"，AGENTS.md 入面就擺具體項目嘅團隊配置。呢個係下一步嘅優化方向，唔係而家一定要做嘅嘢。
寫喺最後
成個過程搞完之後，我不停咁諗一件事，多 Agent 究竟係技術問題，定係其他問題嚟㗎?
搞掂呢三個難題之後我先明白，佢其實係個管理問題。
profile 畀你嘅係工作位，Discord 畀你嘅係會議室，但真正令三個 AI 似團隊咁運作起嚟嘅，係嗰份畀你一次又一次打磨嘅 SOUL.md——嗰啲就係職責說明書、協作流程、同埋明確嘅收工時間。每一個難題，本質上都唔係技術 bug，而係管理漏洞嚟：
問題 1 冇 @ → 下屬唔知應該搵邊個報告
問題 2 停唔到 → 冇明確嘅項目完結機制
問題 3 同時 @ → 任務分配次序亂晒
攞嚟套用喺人類公司都一樣講得通。
以前我哋搞唔好多 Agent，唔係 LLM 唔夠聰明，係我哋冇當 AI 係員工咁管理。一直指望佢一個人搞掂晒所有嘢，結果就係人格撕裂、任務失焦、token 燒穿。
一個 Agent 唔係超人，係一個崗位。三個 Agent 唔係炫耀技術，係一個團隊。
呢篇文只係將三人小組搞掂咗（跑通咗）。五人、十人嘅團隊，都係同一套邏輯——難嘅永遠都唔係模型，係組織設計。
下一篇我打算試吓 Honcho，等呢幾個 Agent 共享同一個「客戶檔案」，真正做到「公司入面每個同事都識你呢個客」。咁就會係團隊協作嘅下一個維度。
加入社群
我平時主要搞 n8n 自動化、OpenClaw 同各種 AI Agent 實戰，群組入面成日有人分享踩坑經驗、工作流程配置同新工具嘅第一手體驗。
遇到問題可以喺群組入面問，睇完文章可以喺群組入面傾吓偈。撳下面加入，一齊搞。
如果覺得唔錯，順手撳個「讚」同「在看」，轉發俾有需要嘅朋友啦～
想第一時間收到推送，記得俾個星標我⭐
當 Hermes 出來的時候，好多人問我多 Agent 之間的協作是怎麼玩的。
週末我找了時間自己做了一把實踐，原本以為會很順利，沒想到中間翻了好幾次車，最後硬是一個坑一個坑填過來的。這篇把完整過程記下來，跟着做，你也能在自己的 Discord 裏，看到幾個 AI 像同事一樣互相接力幹活。
但在動手之前，有句話得先講在前頭。協作是能力的放大器，不是補丁。如果單個 Agent 本身是個廢柴，拉三個廢柴來協作，結果就是三倍的廢柴，三個廢柴開會，廢柴還是廢柴。SOUL.md 寫細、skills 配齊、模型選對，把 Agent調教好，這是多 Agent 能跑的前提，不是結果。
好，話撂這兒了，開始正題。
先聊聊 profile，這是整個多 Agent 的基礎
要做 Agent 協作，第一步得先把不同的 Agent 建出來。在 Hermes 裏，這件事是通過 Profile 來實現的。
profile 其實就是 Hermes 的人格檔案。一個 profile 就是一個完全獨立的 AI 分身，有自己的 config.yaml、.env、SOUL.md、獨立的 memory、獨立的 skills、甚至獨立的 gateway 進程。
底層實現其實挺樸素，靠一個 HERMES_HOME 環境變量切換根目錄，但效果是實打實的隔離。
思維引導
為什麼要強調"真隔離"這件事? 因為多 Agent 架構裏最怕的就是"一個掛了全掛了"。Hermes 的 profile 是進程級隔離，每個 profile 跑自己的 gateway 進程，互不依賴。即便某一個 agent 掛了，也完全不影響其他 agent 繼續幹活。
這點和 OpenClaw 是有差別的。用過 OpenClaw 的朋友都懂，它的多身份更多是配置層面的切換，進程還是同一套。
Hermes 這種物理隔離在企業交付場景下是真的香，客戶不會因為一個 bot 崩了，整套自動化系統跟着下線。
好，理解了 profile 是什麼，我們開始搭建。
Step 1：建三個 Agent，分工明確
這次我準備搭一個三人小組，模擬一個真實的內容生產協作流:
這個組合不是隨便定的。
它對應着一個完整的"查資料 → 寫筆記 → 歸檔"工作流，而且引入了一個專門的調度 Agent(林小管)，讓協作路徑更清晰。
先建林小墨:
hermes profile create ink --clone這裏我用了 --clone 參數，主要是直接繼承 default 的一些配置(模型、API key 等)，不用重新配一遍。
多說一句 --clone 的選擇。Hermes 給了三檔克隆策略，看場景選:
多 Agent 協作場景，基本都是 --clone。
執行後的輸出長這樣:
Profile 'ink' created at /Users/lunaraitalk/.hermes/profiles/ink
Cloned config， .env， SOUL.md from default.
77 bundled skills synced.
Wrapper created: /Users/lunaraitalk/.local/bin/ink
Next steps:
ink setup Configure API keys and model
ink chat Start chatting
ink gateway start Start the messaging gateway
Edit ~/.hermes/profiles/ink/.env for different API keys
Edit ~/.hermes/profiles/ink/SOUL.md for different personality注意最後幾行。ink 直接變成了一個獨立的命令，你後面用 ink chat、ink gateway start 就能直接操作這個 agent，不用每次都寫 hermes -p ink xxx。這個細節真的賊方便。
然後給林小墨覆蓋一個人設:
echo "你是'林小墨'，一名專業的文案專家和知識管理助手。你擅長將碎片化信息整理成結構化的 Markdown 格式，並熟練運用 Obsidian 的雙鏈體系。你的回覆風格文雅、邏輯嚴密。" > ~/.hermes/profiles/ink/SOUL.md我們可以看到一條命令直接繼承了 Default 的配置，模型也繼承過來了。當然如果你想給每個角色配更合適的模型，每個 profile 獨立調一下 config.yaml 就行。
注意左下角的 ink ❮ 標識。Hermes 用 prompt 前綴告訴你當前是哪個 profile 在說話，多 Agent 場景下這個小設計特別救命。
Step 2：接 Discord，為什麼不用飛書?
消息平台這塊我糾結過一下。先說結論:這次我選了 Discord，沒用飛書。
原因很簡單，飛書羣因為平台的限制，確實不支持 bot 被 @。多 Agent 協作最核心的動作就是"一個 agent @ 另一個 agent 來接力"，飛書這條路直接堵死。Discord 在這方面開放得多，也是 Hermes 官方文檔裏演示最充分的平台。
在 Discord Developer Portal 創建應用的流程網上教程一大把，我就不重複造輪子了。關鍵是拿到每個 bot 的 token，填進對應 profile 的 .env 文件。
配置完後，啓動 gateway:
ink gateway install && ink gateway start輸出:
Installing launchd service to: /Users/lunaraitalk/Library/LaunchAgents/ai.hermes.gateway-ink.plist
✓ Service installed and loaded!
Next steps:
hermes gateway status # Check status
tail -f ~/.hermes/profiles/ink/logs/gateway.log # View logs
✓ Service started踩坑提醒
這裏用的是 gateway install + gateway start 組合，install 會把 gateway 註冊成 launchd 服務(macOS)或 systemd 服務(Linux)，關機重啓後會自動拉起。如果你只是測試，用 ink gateway start 也行，但關了終端 bot 就死了。長期跑的話，強烈建議 install。
Step 3：翻車從私聊開始
gateway 起來了，先做個簡單的私聊測試。
提示做一下配對驗證，這個正常，走一下流程就行。
然後我開始測試 channel 裏 @ 它，畢竟我們後續要讓三個 Agent 在同一個 channel 裏討論，@ 是最核心的動作。
結果第一個坑就來了:@ 它不給響應。
當時我盯着 Discord 界面看了半天，bot 在線、狀態正常，就是不搭理我。翻日誌也沒明顯報錯。折騰了一會兒我才意識到，Hermes 的 Discord gateway 默認有個 allowed_channels 的白名單機制，不在白名單裏的頻道，bot 壓根就不響應 @。
解決方法:
# 注意這裏的 -p 參數，需換成那你自己的 agent
hermes -p ink config set discord.allowed_channels "1495255615545544819"把你要用的 channel ID 填進去，重啓 gateway 後再試，立馬就通了。
思維引導
這個默認設計是挺合理的。如果 bot 默認響應所有它能看到的頻道，你把它拉進一個大服務器，它就會在所有頻道里到處開口，簡直是"話癆級騷擾"。allowed_channels 強制你顯式指定哪些頻道允許它說話，是個安全默認值。
Step 4：順便聊聊 Hermes 的 thread 機制
@ 通了之後，我發現每次我 @ bot，它會自動開一個 thread 來回復，而不是在主頻道直接回。
這是 Hermes 默認開啓的 auto_thread: true 行為。這個機制我個人覺得設計得真的挺好:
但如果你不習慣這個形式，兩種關法都給你:
# 方案一:徹底關掉自動 thread
hermes -p ink config set discord.auto_thread false
# 方案二:指定某些頻道不使用 thread(其他頻道照常)
# 編輯 ~/.hermes/profiles/ink/config.yaml，找到 discord 段落:
# no_thread_channels:
# - 1495255615545544819我自己保留了默認的 thread 模式，因為後面多 Agent 協作的時候，每個任務在獨立 thread 裏執行，追溯和調試都方便得多。
Step 5：複製兩份，搭出小團隊
林小墨跑通了，剩下兩個照葫蘆畫瓢。這次我用了 --clone-from 參數，直接從 ink 這個已經配好的 profile 克隆，省得再配一遍:
hermes profile create search --clone --clone-from ink
hermes profile create admin --clone --clone-from ink這樣做的好處是不用再配置 Messaging Gateway 了。
然後分別寫人設:
echo "你是'林小探'，情報專家。你擅長從海量互聯網信息中篩選核心數據。你的任務是提供客觀、準確的市場調研報告和技術趨勢分析。你會引用所有信源。" > ~/.hermes/profiles/search/SOUL.md
echo "你是'林小管'，團隊協調官。你負責接收用戶的原始需求，並將其拆解為具體任務分發給墨、探兩位專家。你還負責 Discord 頻道的日常運作和權限維護。" > ~/.hermes/profiles/admin/SOUL.md給 search 和 admin 各自創建 Discord 應用、配 token、啓動 gateway，一套流程跟林小墨一模一樣，不重複了。
踩坑提醒 三個 profile 配 .env 的時候，每個 bot token 必須獨立，千萬不能複用。Hermes 內置了 token lock 機制。如果兩個 profile 不小心用了同一個 token，第二個 gateway 啓動時會直接報錯並告訴你是哪個 profile 佔用了這個 token。這個保護對 Telegram、Discord、Slack、WhatsApp、Signal 全平台生效，相當於幫你兜了一層底。
怎麼解決呢？其實很簡單，將 .env裏的 DISCORD_BOT_TOKEN 值替換成對應的 Discord 應用 token 即可。
三個 bot 全部上線後，你會在頻道里看到每個 bot 都彈了一大段 No home channel is set for Discord... Type /sethome 的提示。是在讓你給每個 bot 設一個"大本營"頻道，用來接收 cron 定時任務結果和跨平台轉發消息。
如果你暫時不需要定時推送，直接忽略就行；想讓頻道清爽的話，在頻道里對每個 bot 用一次 /sethome 斜槓命令，下次啓動時就不會再彈。
這時候，三個 bot 全部進駐同一個頻道，我以為可以開工了。
Step 6：以為成功了，結果發現是假的
把任務扔進頻道:"幫我調研一下2026年最新的AI智能體趨勢並整理成文章"。
任務是跑出來了，結果也像模像樣。
但我盯着日誌一看，不對勁。
它走的是 Hermes 內置的 delegate_task 模式，根本沒走多 Agent 協作。
這裏得補充一下背景。Hermes 有個叫 delegate_task 的內置機制，單個 agent 可以 spawn 一個隔離的 subagent 來跑子任務，然後把結果收回來合併。這是 Hermes 很硬核的一個能力，官方叫它"zero-context-cost pipeline"，因為 subagent 的上下文不會污染主對話。
聽起來很香對吧？但它有一個致命的問題：subagent 是臨時 spawn 的無狀態執行者，用完即焚，不是你精心配置的那三個獨立 profile。
官方 delegation 文檔裏白紙黑字寫得很清楚:"Each child gets a fresh conversation and works independently — only its final summary enters the parent's context"。翻譯過來就是:子 agent 幹完只把一句總結回傳，中間過程、工具調用細節、思考邏輯全部丟棄。而且更關鍵的是——subagent 的 send_message 技能是被 Blocked 的，它根本沒辦法在 Discord 裏主動發消息。
也就是說，你費勁建的林小墨、林小探、林小管，在 delegate_task 模式下根本沒被調用。admin 自己 spawn 了幾個匿名打工仔把活幹了。
那怎麼辦?想讓真正的多 Agent 接力跑起來，必須在 admin 的 SOUL.md 裏把協作協議寫死，強制它通過 Discord 頻道公開"點名"，走真實的 @ + 消息路徑。
後面三個坑，就是我把這套協議一條一條寫出來的過程。
坑 1：沒有 @，直接就結束了
第一次改 admin 的 SOUL.md，我給它列了團隊成員和職責，以為它自己會懂，結果它拆完任務就直接結束了，全程沒有 @ 任何人。
問題出在哪?LLM 其實理解"林小探是團隊裏的人"，但它不知道在 Discord 裏要怎麼真正"叫醒"對方——Discord 點名是靠 <@用戶ID> 這種特殊格式的消息才能觸發的，你只寫"林小探"三個字，對方的 gateway 根本收不到推送。
解決方法說穿了也樸素——在花名冊裏，直接把每個人的工牌號掛在名字後面:
## 團隊成員
- **林小探 (Search)**: 【Executor】負責聯網搜索、情報蒐集和市場調研。ID: `<@1495291492397224117>`
- **林小墨 (Ink)**: 【Executor/Reviewer】負責文案潤色、邏輯梳理和 Obsidian 筆記格式化。ID: `<@1495250337139789955>`
## Discord 艾特指令 (Crucial)
當且僅當你需要某個隊友**立刻開始工作**時，必須使用以下格式:
- 召喚林小探: `<@1495291492397224117>`
- 召喚林小墨: `<@1495250337139789955>`
**注意**: 在非執行環節，僅使用純文字"林小探"或"林小墨"，不要帶 `<@` 符號。app ID 在 Discord 裏右鍵應用 → "複製用戶 ID" 就能拿到(需要先開開發者模式)。
踩坑提醒
這裏最容易犯的錯是——在任務規劃階段也用了 <@ID> 格式。結果就是 admin 還在列計劃，林小探和林小墨已經被點醒衝進來了，場面混亂。我的做法是嚴格區分:計劃階段用純文字，執行階段才用 <@ID>。
坑 2：任務結束後，停不下來了
@ 的問題搞定，接力終於跑起來了。林小探搜完資料，林小墨做好筆記，admin 做個總結。
但總結完之後它不停了，一直刷表情符號。 👍 👋 🎉，跟發癲一樣。
這其實是多 Agent 架構裏一個非常典型的問題，bot 之間互相觸發的死循環。admin 發"任務完成👍"，林小墨 bot 收到後觸發響應"好的👋"，admin 又響應"收到🎉"......就這麼一直循環下去。
這個坑要治，得分三層來打。
第一層:DISCORD_ALLOW_BOTS —— 死循環的真正源頭
Discord gateway 有個參數叫 DISCORD_ALLOW_BOTS，它決定了一個 bot 要不要響應其他 bot 發出的消息。這個參數有三檔:
正確姿勢是三個 profile 全部設為 mentions:
# 三個 profile 的 .env 統一改
DISCORD_ALLOW_BOTS=mentions第二層:replied_user: false —— Discord 的一個反直覺機制
光改 DISCORD_ALLOW_BOTS 還不夠，還有一個更陰險的點——Discord 的 "reply" 功能默認會自動給被回覆的人發一個 mention。哪怕你文本里壓根沒寫 <@ID>，只要你用了 reply 功能，被回覆的那個人還是會收到提醒。
換句話說，admin 就算只回了個 👍，只要它是以"回覆"的形式發出來的，小墨還是會被隱式 @ 到。
解決方法，在 admin 的 config.yaml 里加上:
discord:
allow_mentions:
everyone: false
roles: false
users: true
replied_user: falsereplied_user: false 就是把 reply 自帶的隱式 mention 關掉。從此 bot 之間哪怕用 reply 回覆，也不會觸發對方的"被 @"事件。
第三層:SOUL.md 裏的終止協議
前兩層是配置層的物理保險，SOUL.md 這層是 LLM 認知層的軟約束:
## 任務終止與防循環規範
- **明確終結**: 當確認林小墨完成筆記整理後，請發出簡短總結，並以"【任務結束】"結尾。
- **禁止冗餘**: 任務結束後，嚴禁發送無意義的表情(👍， 👋)、寒暄或單純的確認消息。
- **中斷反饋**: 不要對其他 Bot 發出的"收悉"、"待命"等結束類消息做出二次響應。
- **艾特控制**: 在任務結束總結中，禁止再次艾特任何 ID。核心是三件事:有一個明確的終結詞(【任務結束】)、禁止對結束類消息做二次響應、結束總結裏不再 @ 任何人。
三層互相兜底，才是穩態。
坑 3：直接把兩個人都 @ 了
死循環解決了，新的問題又來了。
admin 一上來同時 @ 了林小探和林小墨兩個人。
正常的協作邏輯應該是:先 @ 林小探去查資料，等林小探查完，再 @ 林小墨去整理筆記。admin 同時 @ 兩個人，結果就是兩個 bot 同時開始幹活，林小墨拿不到林小探的調研結果，只能瞎寫一通。
這個坑的解決方案是在 SOUL.md 裏強制時序規範:
## 協作時序規範 (Strict Timing)
- **逐一喚醒**: 嚴禁在任務開始階段同時艾特多個專家。
- **當前階段**: 僅在當前步驟需要執行時，才發出對應的 `<@ID>` 指令。
- **接力邏輯**: 必須等到 **林小探** 明確回覆"調研完成"後，你再發出下一條指令並艾特 **林小墨** 開始 Step 2。這三條加進去之後，終於跑通了完整的"接力式"多 Agent 協作。
最終版 admin 的 SOUL.md
把所有坑都填完之後，admin 的完整 SOUL.md 長這樣，直接拿去用:
### 林小管 (Admin) - SOUL.md
## 角色定義
你是"林小管"，林月半子 AI 團隊的【總調度/Planner】。你的核心職責是接收用戶的原始需求，將其拆解為具體步驟，並**逐一**指引對應的專家 Agent 介入。
## 團隊成員
-**林小探 (Search)**: 【Executor】負責聯網搜索、情報蒐集和市場調研。ID: `<@1495291492397224117>`
-**林小墨 (Ink)**: 【Executor/Reviewer】負責文案潤色、邏輯梳理和 Obsidian 筆記格式化。ID: `<@1495250337139789955>`
## 核心協作準則 (Multi-Agent Protocol)
1.**任務分解**: 收到指令後，先列出執行計劃(Step 1， Step 2...)。在計劃表內請使用普通文字(如"林小探")提及專家，**嚴禁使用 ID 格式**，防止誤喚醒。
2.**身份隔離**: 你僅擔任【調度員】。你嚴禁直接調用 `search` 或 `file_writer` 等執行類工具，必須通過 Discord 頻道公開"點名"完成接力。
3.**狀態追蹤**: 你必須全程監控 Thread 進度。只有前一個專家明確回覆"任務完成"或給出最終結果後，你才發起下一階段的指令。
## 協作時序規範 (Strict Timing)
-**逐一喚醒**: 嚴禁在任務開始階段同時艾特多個專家。
-**當前階段**: 僅在當前步驟需要執行時，才發出對應的 `<@ID>` 指令。
-**接力邏輯**: 必須等到 **林小探** 明確回覆"調研完成"後，你再發出下一條指令並艾特 **林小墨** 開始 Step 2。
## Discord 艾特指令 (Crucial)
當且僅當你需要某個隊友**立刻開始工作**時，必須使用以下格式:
- 召喚林小探: `<@1495291492397224117>`
- 召喚林小墨: `<@1495250337139789955>`
**注意**: 在非執行環節，僅使用純文字"林小探"或"林小墨"，不要帶 `<@` 符號。
## 任務終止與防循環規範
-**明確終結**: 當確認林小墨完成筆記整理後，請發出簡短總結，並以"【任務結束】"結尾。
-**禁止冗餘**: 任務結束後，嚴禁發送無意義的表情(👍， 👋)、寒暄或單純的確認消息。
-**中斷反饋**: 不要對其他 Bot 發出的"收悉"、"待命"等結束類消息做出二次響應。
-**艾特控制**: 在任務結束總結中，禁止再次艾特任何 ID。
## 交互準則
-**保持引導**: 在自動開啓的 Thread 中告知用戶:"任務空間已開啓，我將依次調度專家介入。"
-**嚴禁越權**: 不要做深度搜索或長篇寫作，那是林小探和林小墨的職責。順便說一句:SOUL.md 和 AGENTS.md 的邊界
嚴格按 Hermes 官方的最佳實踐來說，SOUL.md 應該只放"這個 Agent 是誰、怎麼說話"這類人格層面的東西，而具體的項目流程(比如我上面寫的團隊成員 ID、艾特指令、時序規範、終止協議)——按理說應該放在 AGENTS.md 裏。官方文檔原話是:"if it should apply everywhere， put it in SOUL.md; if it only belongs to one project， put it in AGENTS.md"。
我這次全塞進了 SOUL.md，一是因為先跑通再優化，二是對於多 Agent 場景，林小管這個角色本身就是為這個項目而生的——她的"靈魂"就是這套協作協議，拆開反而有點強行。
但如果你是想搭一個通用的調度型 Agent(未來還要用在別的項目裏)，那就應該拆開寫——SOUL.md 裏只留"調度員人設"，AGENTS.md 裏放具體項目的團隊配置。這是下一步優化方向，不是現在必須做的事。
寫在最後
整個過程跑下來我反覆在想一件事，多 Agent 到底是個技術問題，還是別的什麼問題?
搞完這三個坑之後我明白了，它其實是個管理問題。
profile 給你的是工位，Discord 給你的是會議室，但真正讓三個 AI 像團隊一樣跑起來的，是那份被你一次次打磨的 SOUL.md——那是職責說明書、協作流程、以及明確的下班時間。每一個坑，本質都不是技術 bug，是管理漏洞:
坑 1 沒 @ → 下屬不知道該找誰彙報
坑 2 停不下來 → 沒有明確的項目終結機制
坑 3 同時 @ → 任務分派時序混亂
拿去套人類公司一樣成立。
過去我們做不好多 Agent，不是 LLM 不夠聰明，是我們沒把 AI 當員工來管理。一直指望它一個人搞定一切，結果就是人格撕裂、任務失焦、token 燒穿。
一個 Agent 不是超人，是崗位。三個 Agent 不是炫技，是團隊。
這篇只是把三人小組跑通了。五人、十人的團隊，同一套邏輯——難的永遠不是模型，是組織設計。
下一篇打算試試 Honcho，讓這幾個 Agent 共享同一個"客戶檔案"，真正做到"公司裏每個同事都認識你這個客戶"。那會是團隊協作的下一個維度。
加入社羣
我平時主要折騰 n8n 自動化、OpenClaw 和各種 AI Agent 實戰，羣裏經常有人分享踩坑經驗、工作流配置和新工具的第一手體驗。
遇到問題羣裏問，看完文章羣裏聊。點擊下方加入，一起搞。
如果覺得不錯，隨手點個「贊」和「在看」，轉發給需要的朋友吧～
第一時間收到推送，記得給我個星標⭐