每個團隊在打造 AI Agent 時，都會撞上同一堵牆。
你從一個提示詞和幾項工具開始。
它運作得很好。
然後需求增加了。更多邊際案例。更多團隊。更多風險。
突然間，你的「Agent」變成了一篇 3000 字的系統提示詞，試圖同時完成五項工作。
解決方案不是更強力的提示詞工程。
而是選對模式。
以下是每個生產級 Agent 系統都會用到的 15 種模式——以及你該在何時使用它們。
在選擇模式之前
並非所有任務都需要 Agent。
一項任務需要 Agent 的條件是：
→ 單次模型呼叫無法產生可靠的結果
→ 模型必須在執行階段在工具或資料來源之間做選擇
→ 任務需要規劃、驗證或迭代優化
→ 工作流程存在無法硬編碼的真實不確定性
當輸入到輸出的路徑是可預測的時，通常不需要 Agent。
摘要。分類。簡單提取。模板化生成。
這些作為直接模型呼叫更快、更便宜、更可靠。
把它們包裝成 Agent 只會增加延遲和失敗點，卻沒有任何好處。
模式 1 — 單一 Agent
最簡單也最常見的起點。
一個模型。一組系統提示詞。一組有邊界的工具。
模型決定呼叫哪個工具，觀察結果，然後持續操作，直到它掌握足夠資訊來回答。
實際範例： 一個客戶支援 Agent，可以查詢訂單狀態、檢查運送資訊，如果無法解決問題就建立工單——只用 2-3 項工具和一個明確的任務。
使用時機： 任務定義明確、工具組小，且單一 Agent 能掌握完整上下文而不混淆。
失效時機： 當你不斷添加工具，系統提示詞超過一頁時。這表示你需要不同的模式——而不是更長的提示詞。
模式 2 — 多 Agent 循序執行
專門化的 Agent 按固定順序執行。每個 Agent 的輸出作為下一個的輸入。
實際範例： 合約審查流程——一個 Agent 提取義務，下一個識別風險，第三個撰寫採購摘要。順序永遠不變。
使用時機： 工作流程有明確、可重複的階段，且每個階段產出正是下一個階段需要的。
失效時機： 當順序實際上需要根據過程中發現的內容而改變時。循序流程假設路徑是固定的——如果不是，你需要更動態的方案。
模式 3 — 多 Agent 平行執行
獨立的子任務同時執行，然後合併成一個總覽。
實際範例： 凌晨 2 點的生產事故。三個 Agent 同時調查日誌、指標和近期部署——而不是一個接一個——因為在故障期間每分鐘都很重要。
使用時機： 子任務真正獨立，且速度很重要時。
失效時機： 當任務實際上依賴彼此的結果時。強迫依賴性的工作平行執行只會造成競態條件和不完整的上下文。
模式 4 — 迴圈
重複一系列步驟，直到滿足退出條件。
實際範例： 一個資料清理 Agent，先分析雜亂的 CSV 資料，提出清理計畫，檢查是否通過品質標準，如果沒通過就重試——最多進行固定次數。
使用時機： 任務需要多次嘗試，且你可以定義一個明確、可檢查的停止條件。
失效時機： 沒有可靠的退出條件。沒有它，你會得到失控的成本和一個可能永遠不會終止的系統。
模式 5 — 審查與批判
一個評判 Agent 審查另一個 Agent 的輸出，提出批評，並提供具體可行的回饋。
實際範例： 一份生成的報告在交給人類之前，由一個獨立的「評論家」Agent 審查，標記出薄弱的論點、缺失的證據或不清楚的段落。
使用時機： 品質比速度更重要，且你希望系統內建第二意見，而不是事後才加上。
失效時機： 當評論家 Agent 與生成者使用相同的盲點時。基於類似假設訓練的審查者不會發現同樣的錯誤。
模式 6 — 迭代優化
一個帶有品質分數門檻的回饋迴圈。生成者不斷優化，直到越過門檻。
實際範例： 一個行銷文案生成器，根據品牌指南對自己的草稿評分，並不斷重寫直到達到最低品質分數——不是一次性的通過/失敗檢查，而是逐步改善。
使用時機： 輸出品質確實多變，且「夠好」有可衡量的門檻。
失效時機： 評分函數模糊或可被操控。如果模型可以誇大自己的分數而沒有實質改善，迴圈只是在浪費 tokens。
模式 7 — 協調器
一個中央路由 Agent 根據實際請求內容，將請求導向專門的 Agent。
實際範例： 支援工單被路由到帳務、技術、帳戶、運送或詐騙專家——每個專家擁有狹窄的上下文，而不是一個 Agent 試圖知道所有事。
使用時機： 你有真正不同的請求類型，需要不同的上下文、工具或決策邏輯。
失效時機： 路由本身變得模糊。如果請求無法乾淨地歸入一個類別，協調器就變成新的瓶頸和錯誤路由的來源。
模式 8 — 階層式任務分解
一個根 Agent 將複雜目標分解成較小的子目標，委派給專門的工人，然後將所有結果綜合成一個答案。
實際範例： 「明年我們應該擴展到哪 3 個國家？」被分解為競爭分析、法規研究、物流可行性與市場規模——每個由不同的專家處理，然後合併。
使用時機： 問題太廣泛，無法一次推理完成，但可以乾淨地分解成獨立的專業領域。
失效時機： 子目標實際上並非獨立。如果工作流程需要即時互相影響，事先分解會失去這種互動。
模式 9 — 群體
多個專門 Agent 參與共享討論，挑戰彼此的假設，然後由一個主持人綜合出最終建議。
實際範例： 公司是否該推出訂閱方案？研究、工程、財務和支援 Agent 各自在多次回合中辯論觀點，然後主持人權衡取捨。
使用時機： 沒有單一「正確」答案——你需要一個由真正競爭觀點塑造的、充分推理的決策。
失效時機： 你需要快速、確定的答案。群體模式刻意緩慢且探索性強——如果你需要速度，這是錯誤的工具。
模式 10 — ReAct（推理與行動）
Agent 在推理與行動之間交替：決定要調查什麼、呼叫工具、觀察結果、決定是否已有足夠證據。
實際範例： 「佇列處理器似乎卡住了」——Agent 搜尋文件、檢查服務健康狀態、關聯發現，然後才建議修復方案。調查路徑不是預先定義的，而是取決於過程中發現的內容。
使用時機： 回答問題的路徑確實無法事先規劃——它取決於每一步揭露的內容。
失效時機： 調查長時間進行卻無法收斂。務必限制推理-行動循環的次數，否則你會有無限探索的風險。
模式 11 — 人在迴圈中
Agent 調查並提供建議，但由人類對任何有風險或模糊的事項做出最終決定。
實際範例： 退款審核——低風險、明確的案例自動處理。高金額、詐騙訊號或政策例外則暫停，等待人工審核後才完成。
使用時機： 決策涉及真實的財務、法律或聲譽風險，且完全自動化還不可接受時。
失效時機： 你只把它當作 UI 功能，而不是架構功能。你需要持久的狀態、審查者分配、超時處理和升級路徑——而不只是一個「暫停」按鈕。
模式 12 — 規劃與執行
一個規劃 Agent 事先建立完整的結構化計畫——可審查、可修改——然後再由執行者逐步執行。
實際範例： 「將工作機群從 10 個實例擴展到 20 個，驗證佇列清空，更新 runbook。」完整的計畫在執行前就可見，不像 ReAct 那樣路徑逐步浮現。
使用時機： 你希望計畫在執行前可審查或可批准——對於有實際後果的操作很重要。
失效時機： 環境變化速度比計畫執行速度快。盲目執行過時的計畫比沒有計畫更糟。
模式 13 — 反思
Agent 評估自己的失敗，反思哪裡出錯，並將該記憶帶入下一次嘗試。
實際範例： 一個程式碼生成 Agent 編寫腳本，腳本在執行時失敗，Agent 分析實際錯誤，記錄要修正的內容，然後重試——每次嘗試都變得更聰明，而不是重複同樣的錯誤。
使用時機： 失敗具有資訊性，且自我修正確實能改善下一次嘗試。
失效時機： 失敗模式是隨機或彼此無關的。反思只在有實際模式可學習時才有幫助。
模式 14 — 自訂邏輯
混合模式：確定性程式碼處理絕不能出錯的規則，而模型負責判斷、草稿和例外處理。
實際範例： 一個退款工作流程，購買驗證和詐騙檢查以嚴格的確定性規則執行——絕不委派給模型——而客戶回覆草稿和路由建議則保持 Agent 化。
使用時機： 工作流程有真實的分支邏輯，涉及法律或財務後果，且你需要精確區分什麼是確定性、什麼是彈性。
失效時機： 團隊模糊界線，讓模型做出應該硬編碼的決策。資格、權限和資金移動絕對不該由模型單獨決定。
模式 15 — 事件驅動 Agent
Agent 不等待被呼叫。它訂閱事件串流，並在條件觸發的瞬間採取行動。
實際範例： 一個詐騙偵測 Agent，在可疑交易事件觸發的瞬間立即反應——而不是等到支援工單最終浮現，那時傷害已經造成。
使用時機： 時機比任何事都重要，等待人類請求意味著錯過行動的時機窗口。
失效時機： 觸發條件定義不佳。一個充滿模糊觸發器的嘈雜事件串流會讓系統不斷「狼來了」——或者更糟，錯過真正的訊號。
模式選擇——匹配不確定性，而不是跟風
正確的模式匹配你工作中不確定性的形狀：
→ 不確定該用哪個工具 → 單一 Agent 或 ReAct
→ 不確定該路由到哪裡 → 協調器
→ 不確定品質 → 審查與批判 或 迭代優化
→ 不確定執行路徑 → 規劃與執行 或 ReAct
→ 不確定如何自我修正 → 反思 或 迴圈
→ 不確定業務風險 → 人在迴圈中 或 自訂邏輯
→ 不確定問題結構 → 階層式分解 或 群體
→ 無法等待請求 → 事件驅動 Agent
如果任務只需要一個可靠的工具呼叫，群體模式並不比單一 Agent 更高級。
如果你的計畫到第三步就過時了，規劃與執行並不是 ReAct 的升級。
最可靠的生產系統，不是最自主的系統。
它們把自主性放在能創造價值的地方——並在其他地方加以限制。
生產級 Agent 系統的 10 條規則
- 從最簡單的可用模式開始。一個有乾淨工具合約的單一 Agent，勝過一個有薄弱合約的多 Agent 系統。
- 把工具描述寫得像合約一樣。模型只從描述中知道工具的作用——而不是你的意圖。
- 限制每次請求的迭代次數、工具呼叫次數和花費。沒有預算限制的 Agent 是個隨時會在帳單上出現的負債。
- 記錄完整的行動軌跡。工具呼叫、引數、輸出、最終決策。沒有這些，事故調查就是猜測。
- 將不可逆的操作放在確定性檢查或人類審批之後。永遠不要讓模型成為資金移動或生產變更前的唯一關卡。
- 用真實的失敗案例來評估，而不只是快樂路徑。快樂路徑的正確性是原型。邊際案例的正確性才是產品。
- 在系統提示詞變得不可讀之前，按責任分離提示詞。「但是不要在 Y 時做 X」這類句子滲入提示詞，表示 Agent 在做兩項工作。
- 將多 Agent 系統視為分散式系統。部分失敗、超時、重試和可觀測性不是選項。
- 模型審查不能取代確定性驗證。用評判者來改善品質。用測試和權限檢查來確保正確性。
- 偏好更簡單的模式——不是因為簡單總是更好，而是因為你節省下來的複雜度預算，可以花在更好的工具、更好的提示詞、更好的評估上。
這就是全部 15 種模式。
大多數團隊失敗不是因為選錯了模式。
而是因為他們從未問過自己，到底要解決的是哪種不確定性。
選對模式。匹配問題的形狀。不要在不值得的地方添加自主性。
如果這篇文章對你有幫助：
→ 轉發分享給你團隊中所有打造 Agent 的工程師
→ 追蹤 @sairahul1 以獲得更多這類解析
→ 收藏這篇文章——你每次開始新的 Agent 專案時都會回來參考
我撰寫關於 AI、打造產品，以及那些不需要你就能運作的系統。
