Agentic AI 架構在實務中如何運作

語言模型能一次性回答問題,而 AI agent 則能持續朝目標推進工作,自行決定下一步該做什麼並使用可用的工具,並在看到結果後調整做法。agentic AI 架構正是使這種行為得以實現的結構。本指南透過實際案例,說明其核心組成與常見模式,同時也說明如何在不增加不必要複雜度的前提下選擇合適的架構。

agentic AI 架構是一種系統設計,讓一個或多個 AI agent 能透過反覆的推理與行動來追求目標。這種架構將模型與工具及工作情境連接起來,同時定義 agent 如何規劃下一步、並運用新的結果延續任務。模型提供推理能力,而架構則將這種能力轉化為可執行目標導向工作的運作系統,決定資訊如何在整個工作流程中流動,以及 agent 如何產出最終結果。

大多數 AI agent 架構都使用相同的功能性組成模組。它們的實作方式可能各不相同,但每個模組都對應一個明確的設計問題:有的決定系統如何決策與行動,有的決定系統記住什麼,還有的負責協調工作並掌控執行過程。

推理層負責將目標轉化為下一步行動。較大的任務需要拆解為輸出明確的步驟。舉例來說,「研究市場」這個目標範圍過於廣泛,而「從已核准的資料來源中辨識買家群體」則更容易執行與評估。計畫應保持可調整的狀態,因為工具故障或新出現的證據可能需要重新規劃。

工具讓 agent 得以檢視或影響模型以外的系統,搜尋與資料庫查詢就是常見的例子,商業 API 則能進一步擴展行動層的能力。每個工具都需要精確的規格與經過驗證的輸入,失敗必須被明確標示——逾時不能看起來像是空結果,部分寫入也不能看起來像是成功。

情境支撐當下的決策,而記憶則保留有用的資訊,知識來源則依需求提供事實。工作記憶可用來保存目前的計畫,而較長期的記憶則可保留已核准的偏好設定。檢索應擷取相關文件,而不是將整個語料庫都塞進提示詞中。每一項儲存的內容都需要有存取權限與來源規則。

編排負責分配工作並管理共享狀態。在單一 agent 設計中,它可能只是一個簡單的執行迴圈;在多 agent 設計中,則還需分配角色並解決依賴關係。每個 agent 都需要明確的輸入與預期輸出。編排器可以限制迭代次數與並行數量,以防止失控擴張。

防護機制界定 agent 被允許執行的範圍,能夠阻擋不安全的工具呼叫,或限制對敏感系統的存取。可觀測性則會保留 agent 決策與工具結果的紀錄,讓故障更容易被調查。人工監督則會在高影響力的行動之前加入審核步驟,例如發送款項或修改正式紀錄。這些控管機制共同確保自動化工作保持可見,並維持在約定的範圍之內。

架構模式描述控制權在系統中如何流動。以下這些 agentic AI 架構範例,將每種模式與適用的使用情境搭配呈現,圖示著重於 agent 之間的關係,而非基礎架構的細節。

單一 agent 架構只有一個決策迴圈與一個任務負責人,通常是合適的起點,因為狀態保持在本地,執行過程也容易追蹤。

舉例來說,內部支援助理可以讀取工單並搜尋已核准的知識庫,再據此草擬回覆。一個 agent 就能負責這整個流程。這種模式在範圍有限時效果良好,但若任務規模過大,可能會使單一情境負荷過重。

循序架構會將工作依序從一個專責 Agent 傳給下一個。舉例來說,一項出版工作流程可以先將原始素材交給研究 Agent,其研究成果再交給撰寫 Agent,最後由審核 Agent 檢查完成的草稿。

這種架構能釐清各階段的責任歸屬,但若早期產出品質不佳,可能限制後續每個階段的表現。每次交接都需要驗證。

平行架構會將獨立的子問題分派給多個 Agent 處理。以盡職調查任務為例,可以將產品證據與市場證據分開處理,再透過整合步驟合併結果。一家評估新市場的公司,可以指派不同 Agent 分別負責客戶需求與競爭對手動態,另一個 Agent 則檢視當地法規,待所有分支完成後,再由整合 Agent 彙整各項發現。

平行處理可以縮短耗時、提升涵蓋範圍,但也會產生重複與衝突,需要靠整合步驟來解決。

路由器會將每個請求送往具備對應工具的 Agent。舉例來說,客服路由器可以將發票問題導向計費 Agent,登入問題導向帳戶存取 Agent,產品錯誤則導向技術支援。

分類不確定時需要有備援機制,信心不足的請求可以轉交給一般 Agent 或真人處理。

階層式架構會在多個執行 Agent 之上設置一個管理者,由管理者拆解目標並檢查各執行者的成果。

這種方式適合依賴關係會變動的情境,但管理者可能成為瓶頸。結構化的執行者摘要能減輕管理者的上下文負擔。

網路或群集架構讓多個專家在任務進行過程中共享發現。舉例來說,一套事件應變系統可以連接檢查應用程式日誌與近期部署狀況的 Agent,其他 Agent 則檢視安全性警示或服務相依關係。它們持續更新共享狀態,直到系統找出可能原因並提出應對方案。

網路式設計需要訊息結構與衝突處理規則,也需要嚴謹的終止控制機制。群集架構應針對真正的規模需求而設,而非只是多 Agent 工作的預設稱呼。

生成者-評審者模式將創作與評估分開:生成者產出候選結果,評審者依既定標準檢查,並要求修改或接受結果。

這種模式適合有明確評分標準的產出。舉例來說,評審者可以檢查報告是否有來源支持及是否包含必要章節。混合架構會視需要結合多種模式,但每一項新增元素都應該解決實際觀察到的問題,而不只是讓架構圖看起來更複雜。

合適的 Agent AI 架構應依任務而定,而非跟隨潮流。先從工作流程的依賴結構與風險評估著手,再判斷專業分工或平行執行所帶來的價值,是否足以支撐更多的協調成本。

將任務繪製成依賴關係圖。如果單一執行者僅憑本地上下文就能完成每個步驟,使用單一 Agent 即可;如果每個階段都依賴前一階段經驗證的輸出,可考慮循序式 Agent;如果多個分支彼此獨立,平行式 Agent 可能會有幫助。

當請求可歸類為穩定且工具明確不同的類別時,使用路由器;當系統需要制定並監督不斷變化的計畫時,使用階層架構;網路或群集式設計則保留給範圍廣泛、且去中心化探索確有明顯效益的工作。

關鍵判斷標準在於:交接是否改變了所需的專業能力或權限範圍。如果沒有改變,再加一個 Agent 可能只會增加負擔。

正式生產系統需要一些原型階段常可忽略的控制機制。

要預期工具會失敗,並確保重試安全可行。追蹤每次執行過程,讓操作人員能看到目前的計畫與工具結果。每個工作流程也都需要明確的停止規則,例如達成成功標準或達到固定預算上限。

只賦予每個 Agent 完成其角色所需的權限。在提示詞之外驗證工具參數,並將取得的內容視為不可信資料。在 Agent 執行敏感或不可逆的操作前,要求人工核准。

在活動上下文中只保留相關資訊,長期記憶應有意識地儲存,並設定明確的存取規則。在多 Agent 系統中,使用版本檢查或事件日誌,避免各 Agent 悄悄覆寫彼此的成果。

以具代表性的任務評估整個工作流程,追蹤成功結果,而不只是模型的回應。將這項品質指標與整體延遲及成本相比較,以確認每新增一個 Agent 都能帶來可衡量的價值。

• 在還未證明單一 Agent 不足以完成任務前,就先加入多個 Agent。

• 給予 Agent 超出實際所需的上下文或工具存取權。

• 對存在嚴格依賴關係的任務使用平行執行。

• 共享狀態沒有明確的所有權或衝突處理規則。

• 缺少明確的成功標準與停止條件。

自訂架構能提供細緻的控制，但也需要投入編排與評估工作。對於想在不自行實作整套技術堆疊的情況下完成多步驟知識型工作任務的使用者，Kimi Agent 提供了通用的 Agent 體驗。

Kimi Agent 能理解目標並規劃所需的工作，接著在產品體驗中執行任務。這讓使用者無需先設計規劃器或工具循環，就能直接使用具代理能力的工作流程。

Kimi Agent 具備多種功能，例如可以生成網站、製作 PPT 簡報。這些能力能幫助使用者透過單一產品體驗，將籠統的需求轉化為結構化的成果。

Kimi 支援多模態推理與基於檔案的工作流程，能處理 PDF 與 Word 文件，也支援 Excel 與 PPT 檔案。此外，Kimi 還能處理圖片與 TXT 檔案，而影片則提供了另一種輸入格式。這讓 Kimi Agent 能夠處理超越純文字聊天內容的來源素材。

Kimi Agent Swarm 提供另一種獨立的多 Agent 能力，適合能從大規模平行執行中受益的任務。它可以協調多個專職工作單元，執行大規模搜尋或批次任務，長篇且包含多條獨立研究路徑的工作也適合採用這種方式。

具代理能力的 AI 架構能將模型的回應轉化為受控的工作流程。通常最合適的設計，是能滿足任務依賴關係與風險要求的最簡方案。先從單一 Agent 開始，定義好它可用的工具，設定明確的停止條件，再依實際發生的失敗情況進行評估，只有在需要解決特定瓶頸時，才加入路由或多 Agent 協調機制。如果你想在不自行建構編排層的情況下執行具代理能力的任務，Kimi Agent 提供了一個實用的起點。