從混亂到清晰：打造可靠企業多代理系統的五個關鍵教訓

當一家中型科技公司找上 Zokforce，希望我們協助設計一套由多個 AI 代理驅動的人資領域人才管理系統時，我們以為自己很清楚前方的挑戰。從商業角度來看，這個案子很有說服力：自動化招募流程、簡化新人到職作業、減少人工的人資作業。技術做法看起來也很直接：為每個領域部署專責代理，透過中央調度代理加以協調，粗重的工作就交給 AI。

接下來的六個月，我們反覆試錯，也換來得之不易的洞見，從根本改變了我們開發多代理系統的方式。本文分享這段歷程：這不是一則數據漂亮、包裝精美的成功故事，而是打造複雜 AI 系統時真實而混亂的樣貌、我們犯過的錯，以及在克服這些挑戰的過程中學到的教訓。

充滿希望的開端

初始架構在紙上看起來相當優雅。我們設計了五個彼此協作的專責代理：

招募代理職缺刊登 · 履歷篩選

調度代理所有代理都透過它進行協調

薪酬代理薪資 · 福利

到職代理文件處理 · 系統權限

績效代理目標設定 · 考核評估

計畫：

• 招募代理：處理職缺刊登、篩選履歷、安排面試
• 到職代理：協調文件處理、系統權限開通與訓練時程
• 薪酬福利代理：計算薪資、管理福利、產生報表
• 績效管理代理：設定目標、管理考核流程、蒐集回饋
• 調度代理：分派任務、監控流程、解決衝突

每個代理在自己的領域內獨立運作，由調度代理確保交接順暢。客戶的人資團隊可以專注於策略性工作，例行作業則交給代理處理。

接著，我們試著把它部署上線。

教訓 1：規格陷阱——當「清楚」的指示其實不夠清楚

問題出在哪裡

檢視執行日誌後，我們發現一個根本問題：我們的指示模稜兩可。我們要求代理「依據職缺要求篩選履歷，找出合格的候選人」。聽起來很清楚，對吧？但我們並沒有定義：

• 「合格」以可衡量的標準來說代表什麼
• 如何處理邊界案例（例如：經驗略低於要求、但技能出眾的候選人）
• 職缺要求互相矛盾時該怎麼辦（要求 10 年經驗，卻只給新手薪資）
• 何時該把不確定的決策往上呈報，何時可以自行決定

代理用自己的解讀填補了這些空白，而這些解讀在每次執行時都會不可預期地改變。

更深層的問題

這正是研究所稱的規格錯誤，也是多代理系統中最常見的失敗模式。問題不在於 LLM 看不懂指示，而在於它們非常擅長找出我們從未想過、卻同樣說得通的解讀。

其中一次令人印象特別深刻的失敗，發生在我們要求到職代理「為新進員工建立帳號」時。它替第一位員工在所有系統中都建立了帳號；替下一位只開通了電子郵件；替第三位則在人資資料庫中建立了重複的帳號。同一條指示，三種不同解讀，毫無一致性可言。

我們學到的事

Evaluate each resume against the following criteria:

1. Required qualifications (must have ALL):
   - [List with exact matching rules]
   
2. Preferred qualifications (weight each):
   - [List with scoring rubric]
   
3. Disqualifying factors (immediate rejection):
   - [Explicit list]

For candidates scoring 80-100: Auto-advance
For candidates scoring 60-79: Flag for human review
For candidates scoring below 60: Auto-reject with reason code

If any criterion is ambiguous or missing, mark as 
"INSUFFICIENT_INFO" and request clarification.

即便如此還是不夠。我們必須加入限制條件驗證：代理在處理之前，必須先確認已取得所有必要資訊，並以我們能用程式驗證的結構化格式輸出評分結果。

教訓 2：協調惡夢——當代理之間無法溝通

問題出在哪裡

我們來來回回花了好幾天修正通訊協定。我們在訊息中加入更多欄位，接著薪酬代理抱怨它需要的是另一組欄位。我們又把那些欄位加上去，然後績效管理代理又需要另一種資料結構。

不到兩週，我們就有了五種不同的訊息格式，完全沒有互通性，而且代理一收到預期外的輸入就乾脆停止回應。

更深層的問題

2 個代理 = 1 條路徑

4 個代理 = 6 條路徑

5 個代理 = 10 條路徑

協調複雜度呈平方級成長每一次互動都可能造成溝通誤解、資料遺失或格式不符。

這就是困擾多代理部署的協調失敗問題。每個代理單獨來看功能都正確，但整體行為卻一片混亂。問題會呈指數級擴大：2 個代理 = 1 個潛在協調點，4 個代理 = 6 個潛在協調點，5 個代理（我們的系統）= 10 個潛在協調點。

我們學到的事

{
  "message_id": "uuid",
  "conversation_id": "uuid",
  "sender_agent": "recruitment",
  "receiver_agent": "onboarding",
  "message_type": "TASK_DELEGATION",
  "timestamp": "ISO8601",
  "payload": {
    "action": "initiate_onboarding",
    "entity_id": "emp_12345",
    "entity_type": "employee",
    "required_data": {
      "employee_info": {...},
      "employment_details": {...}
    }
  },
  "callback_required": true,
  "callback_timeout_seconds": 300
}

更重要的是，我們落實了嚴格的介面合約。每個代理都會公開一份 schema，明確定義它需要哪些資料、會輸出哪些資料。調度代理在傳遞每則訊息之前，都會依據這些合約進行驗證。

如果某個代理試圖送出不完整的資料，訊息會在邊界就被退回，而不是等到接收端代理已經嘗試處理、又莫名其妙地失敗之後。

教訓 3：記憶碎片化問題——當上下文消失

問題出在哪裡

深入調查後，我們發現代理其實根本記不得筆電已經訂購：它為了回應第一個問題而擷取了這項資訊、產生回覆，然後立刻就忘了。被問到後續問題時，它完全沒有上一輪互動的上下文。

這並非個案。代理經常「忘記」自己做過的決定、與剛提供的資訊自相矛盾，或是索取早已收到的資料。

更深層的問題

這就是上下文碎片化問題：每個代理各自維護短暫的工作記憶，而對話一往下進行，這些記憶就消失了。在橫跨數小時甚至數天的企業流程中，這會造成根本性的可靠度問題。

更糟的是，當多個代理需要協同作業時，它們對情況各自只掌握不同的片段。招募代理知道候選人談到了更高的薪資，到職代理卻不知道，薪酬代理則按照標準的錄取金額處理。三個代理，三種不同的現實，換來一位非常憤怒的新進員工。

我們學到的事

第 1 層工作階段記憶短暫

30 分鐘

範圍

僅限目前對話

儲存

Redis 快取（TTL 30 分鐘）

目的

支援自然的多輪對話

第 2 層任務記憶持久

一個業務流程

範圍

一個業務流程的完整期間

儲存

PostgreSQL，以 workflow_id 為鍵

目的

在代理交接之間維持連續性

第 3 層共享知識庫永久

全時段

範圍

所有代理、全時段

儲存

向量資料庫 + 結構化資料

目的

提供一致的事實基準

每次代理行動前都注入上下文，確保一致性。

第 1 層：工作階段記憶（短暫）——僅限目前對話，使用 TTL 為 30 分鐘的 Redis 快取，支援自然的多輪對話

第 2 層：任務記憶（持久）——涵蓋一個業務流程的完整期間，使用以 workflow_id 為鍵的 PostgreSQL，在代理交接之間維持連續性

第 3 層：共享知識庫（永久）——所有代理、所有時間，向量資料庫 + 結構化資料，提供一致的事實基準

關鍵在於，我們加入了對話歷史注入：在任何代理處理請求之前，調度代理都會提供先前互動中所有相關的完整上下文，而不只是當下的查詢。

教訓 4：驗證缺口——當沒有人檢查成果

問題出在哪裡

一陣恐慌隨之而來。我們展開調查，理出了事件的來龍去脈：

1. 績效管理代理建議依績效調薪（正確：3-5%）
2. 薪酬代理處理調薪（錯誤：把 3-5% 解讀成 300-500%）
3. 薪資系統照單執行（盡責地：按代理指定的金額發薪）

沒有人發現這個錯誤。每個代理都假設上一個代理已正確完成工作。系統沒有驗證層、沒有合理性檢查，也沒有判斷「這個結果合理嗎？」的能力。

這絕不是唯一的驗證失誤。我們還發現：

• 到職代理建立的使用者帳號，權限明顯有誤
• 招募代理寄面試邀請給早已被淘汰的候選人
• 績效管理代理用錯誤的公式計算績效分數

更深層的問題

補上驗證缺口，往往是團隊最後才做的事。大家以為只要每個代理都「夠聰明」，系統就能正常運作。這種想法錯得很危險。

問題在於 LLM 是信心機器：即使輸出毫無道理，它們仍會以高度信心產生結果。在多代理系統中，一個代理信心滿滿的錯誤，會成為下一個代理信心滿滿的輸入，形成沒有人質疑的連鎖失敗。

我們學到的事

各層攔下的錯誤比例

第 1 層結構驗證約 40%Schema 驗證 · 型別檢查 · 缺漏欄位偵測。低成本、自動化，攔下格式與結構錯誤。

第 2 層業務規則驗證約 35%限制條件檢查 · 範圍驗證 · 邏輯驗證。例如：薪資變動超過 20%、不可能的日期。

第 3 層跨代理一致性約 15%調度代理維護不變條件 · 狀態核對。確保各代理的相關決策保持一致。

第 4 層人工審查約 10%低信心決策 · 邊界案例 · 靜默失敗。代理自評信心分數，分數過低即觸發審查。

驗證為強制且具阻擋性未通過就不能繼續。

第 1 層：結構驗證——每個代理的輸出都會依據 schema 檢查。型別錯誤、缺漏欄位、格式不正確的資料都會立即被攔下（攔下約 40% 的錯誤）

第 2 層：業務規則驗證——自動檢查是否違反業務邏輯。例如：薪資變動超過 20%、重複建立帳號、不可能的日期（攔下約 35% 的錯誤）

第 3 層：跨代理一致性檢查——調度代理維護跨代理的不變條件。如果招募代理將某人標記為「已錄用」，到職代理就必須有對應的任務（攔下約 15% 的錯誤）

第 4 層：依信心分數進行人工審查——代理自行回報信心分數，低信心的決策會自動轉交人工審查（攔下邊界案例並防止靜默失敗，約 10% 的錯誤）

關鍵在於，我們讓驗證成為強制且具阻擋性的步驟：驗證未通過，代理就不能進行下一步。

教訓 5：複雜度爆炸——當代理越多反而越糟

問題出在哪裡

每新增一個代理，系統複雜度都呈指數級增加：

• 代理越多 = 協調點越多
• 協調越多 = 失敗模式越多
• 失敗模式越多 = 除錯時間越長
• 除錯越多 = 開發越慢

到了第七個代理，我們把 80% 的時間花在排除協調問題上，只有 20% 用於實際功能開發。更糟的是，系統變得極其複雜，連我們自己都無法可靠地預測它的行為。

壓垮駱駝的最後一根稻草，是合規代理與薪酬代理陷入了無窮迴圈：合規代理把一筆薪資計算標記為可能不合規，薪酬代理重新計算，合規代理又標記新的計算結果，如此無止境地重複。系統陷入死結長達 47 分鐘，最後才因逾時而終止。

更深層的問題

這就是組合爆炸問題。協調成本會隨代理數量呈平方級成長：

• 四個代理的系統有 6 條協調路徑
• 七個代理的系統有 21 條協調路徑
• 十個代理的系統有 45 條協調路徑

研究也證實了這個殘酷的事實：增加更多代理，往往反而降低效能。協調的額外負擔超過了專業分工帶來的好處。

我們學到的事

決策 1：合併代理

• 把合規檢查併入薪酬代理（同一領域）
• 把學習發展併入績效管理（共用流程）
• 從七個代理減回五個

決策 2：限制代理之間的直接溝通

• 改用中心輻射式（hub-and-spoke）架構，而非網狀架構
• 所有溝通都經由調度代理
• 消除代理之間的相互依賴

決策 3：單一代理優先原則

• 新增代理之前，我們會先問：「現有代理能否透過更好的提示來處理這件事？」
• 只有在單一代理方案明顯失敗時，才會新增代理

結果呢？系統可靠度大幅提升。回應時間縮短，除錯變得可以掌控，團隊終於能真正理解並推斷系統的行為。

全局視角：我們希望早點知道的事

回顧過去，這些教訓有一條共同的主線：多代理系統之所以失敗，不是因為 AI 的極限，而是因為架構與設計上的決策。

我們遇到的失敗，與業界研究的結果高度吻合：

• 32% 規格錯誤
• 28% 協調失敗
• 24% 驗證缺口
• 再加上系統規模擴大時層層累積的複雜度

如果重來，我們會這樣做：

我們現在的進展

六個月後，這套人資系統已在正式環境中運作。它並不完美，仍需持續監控與調整，但已經可靠到人資團隊願意把真實流程交給它處理。

更重要的是，我們已將這些教訓內化，運用在未來的多代理專案中。如今我們會以適度的審慎態度面對這類專案：從簡單開始，只有在有明確效益支持時才增加複雜度。

成功需要的不只是強大的 AI 模型，還需要深思熟慮的系統設計、嚴謹的測試，以及在複雜度失控時勇於簡化的謙遜。