當公司裡有多個 Agent 之後，下一個問題不是「每個 Bot 能不能完成自己的工作」，而是「一個 Bot 做到一半，能不能把工作可靠地交給另一個 Bot」。

如果交接只是一句「請接手」，看起來很自然，工程上卻幾乎無法驗證。接手者不知道目標、輸入、限制、已完成到哪裡，也不知道前一個 Bot 是真的完成，還是只產生了一段看似合理的文字。

我在 Hermes 的多 Bot 工作流裡，把 bot-to-bot 協作當成正式的任務交接，而不是 Bot 之間互相聊天。

先分清楚：對話不是交接

Bot 對話適合探索想法；任務交接則需要可追蹤、可恢復、可驗收。前者可以容許上下文跳躍，後者必須讓沒有讀過原始對話的接手者，也能從封包開始工作。

一個最小交接封包至少包含：

一、任務目標與背景。
二、指定 owner 與接手者。
三、輸入來源及其權限範圍。
四、已完成項目與尚未完成項目。
五、輸出格式與驗收標準。
六、限制條件、風險與不能做的事。
七、證據位置，例如檔案路徑、URL、message ID 或查詢時間。
八、下一個最小可驗證步驟。

這些欄位不是為了讓文件看起來完整，而是為了降低接手者重新猜測的成本。

Peer DM 只傳任務，不傳模糊期待

在實作上，Bot 之間可以用 peer DM 傳送交接內容，也可以把任務放到 kanban 或共用佇列。工具形式不是最重要的，重要的是訊息要能被讀回，並且有明確狀態。

我會把狀態拆成幾個階段：待處理、處理中、待驗證、已完成、阻塞。只有「已完成」可以進入下一個正式流程，但「已完成」不能只由執行者自己宣告，必須附上可讀回的證據。

例如，研究 Bot 交給內容 Bot 的輸出，不應只是「資料整理好了」，而應該包含 raw 檔案位置、去重後筆數、來源連結、摘要檔位置，以及內容 Bot 要檢查的缺口。這樣內容 Bot 才能針對輸入工作，而不是再猜一次研究 Bot 做過什麼。

驗證交接，而不是相信交接

跨 Bot 最容易出錯的地方，是第一個 Bot 的推論被第二個 Bot 當成事實。解法不是禁止 Bot 協作，而是把證據與推論拆開。

接手者開始工作前，先做三個檢查：

第一，輸入檔案真的存在，而且不是空檔。
第二，來源與筆數符合交接封包的描述。
第三，關鍵結論能回到原始資料核對。

若任一項不成立，狀態應該回到阻塞，並把具體缺口退回 owner。不要為了讓看板變綠，就自行補造缺少的資料。

這套做法也適用於公司流程。工程 Bot 交給客服 Bot 的案件，應包含客戶、設備、處理紀錄、目前風險與下一步；客服 Bot 回交給工程 Bot 時，則要保留客戶回覆、時間與授權範圍。每次交接都留下誰在什麼時間交了什麼，之後才有辦法追責與復盤。

一次失敗的交接

我曾經遇過一個流程：前一個 Bot 已經產生報告，但沒有明確區分「已抓到的資料」與「模型推測」。下一個 Bot 直接沿用摘要，最後報告看起來很完整，卻有幾個來源無法回讀。

問題不在模型不夠聰明，而在交接介面沒有要求證據。後來我把 raw、衍生摘要與最終草稿分開保存，交接封包只把路徑與驗收條件交給下一個 Bot。接手者必須讀回 raw，確認後才可以把結論寫進正式文件。

這也讓恢復變得簡單：如果最後歸納失敗，只要保留前一階段的檔案，就能從「待驗證」恢復，不必整條流程重跑。

不要讓 Bot 互相跨越權限

多 Bot 協作還有一個常被忽略的風險：接手不代表取得所有權限。私人 Profile、公司資料、客戶資料與部門 Bot 的輸入輸出仍然要隔離。

交接封包應明確標註可讀來源與不可外傳內容。需要修改正式資料、分享文件或對外發送時，仍須經過既定授權，不因為「另一個 Bot 已經同意」就跳過人類核准。

Bot-to-bot 的最小治理規則

我的交接檢查清單

派工前，先寫清楚目標、輸入、輸出與驗收。執行中，每個階段留下原始檔與中間結果。交接時，指定 owner、狀態、證據與下一步。接手後，先讀回證據再採用結論。遇到缺口就阻塞回報，不用推測填空。跨權限資料則停止並要求正式授權。

結語

Bot-to-bot 協作的核心，不是讓多個模型彼此講更多話，而是建立一個可靠的交接介面。當任務有 owner、輸入、輸出、狀態、證據與驗收標準，多 Bot 才會從「一群會聊天的助手」變成可以共同交付工作的系統。

今天的實際證據是：我把跨 Bot 工作拆成可追蹤的交接封包，要求接手前讀回檔案、來源與狀態；只有驗證通過，才允許把結果寫入正式文件或進入下一個流程。