AI Agent 系統架構：正式上線前要補齊哪些元件
本篇是「從 PoC 到 Production：企業 AI Agent 系統工程」系列的第 2 / 12 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。
這是「從 PoC 到 Production：企業 AI Agent 系統工程」系列第 2 篇（共 12 篇）。上一篇：企業 AI Agent 為什麼卡在 PoC？。
上一篇列出 demo 到正式上線之間的六個問題。這次換個角度，把它們放回系統架構裡，看每一層該負責什麼。
先說清楚，下面是一份 reference architecture，也就是設計時可以拿來討論的參考圖，不是我在某家公司上線過的成品。實際使用時當然可以按規模刪減；這張圖的用途，是讓大家知道刪掉某一層之後，連帶少了哪一道保護。
一張圖
下面會依序看每個方塊的用途、拿掉後的影響，以及怎麼接回現有後端。大多數公司不需要為了 agent 另蓋一套孤立的系統。
API Gateway / BFF：把「使用者是誰」帶進整條鏈
不少 PoC 從入口就弄丟了使用者身分：前端直接呼叫 agent service，後面的檢索和工具則一律用高權限服務帳號執行。到了正式環境，這很容易變成越權存取。
這層做的仍然是熟悉的認證、授權、rate limiting 和輸入驗證。額外要顧好的是身分資訊：這個請求來自誰、擁有哪些權限，都要一路傳到檢索與工具層，不能中途換成一個什麼都能做的共用帳號。
- 少了它會怎樣：agent 變成一個權限放大器，任何人問都能拿到任何資料。
- 怎麼整合：它就是你現有的 API Gateway / BFF，agent 只是它後面的一個新 upstream。不要為了 agent 另外開一個沒人管的後門。
這不是架構潔癖。曾經有團隊讓 agent 用高權限服務帳號處理客服工單，攻擊者只要在工單內容裡藏一段指令，就能誘使 agent 把內部憑證貼到公開討論串。Simon Willison 把「能接觸私有資料、會讀不可信輸入、又能把內容送出去」這個組合稱為 lethal trifecta。保留原始使用者身分，並在每一層重新檢查權限，至少能拆掉其中一條危險路徑。
Agent Runtime：那顆「決定下一步」的大腦
這是整張圖的核心，也是和傳統後端最不一樣的地方。傳統 service 是「請求 → 固定流程 → 回應」；agent runtime 是一個 plan → act → observe 的迴圈：看現在的狀態 → 決定下一步（檢索？呼叫工具？回答？）→ 執行 → 看結果 → 再決定。
它本身要負責的，是這個迴圈的紀律：
- 迴圈最多跑幾輪（不然會無限想下去，燒錢又卡住）
- 每一步的決策要被記錄（不然就是鴻溝三的黑盒）
- 錯誤要能收斂，而不是把例外往上丟就當機
把這三條紀律接起來，迴圈長這樣。真正要看的不是中間那圈 happy path，是兩條岔出去的線：輪數用完要停得下來，出錯要收得回來。
flowchart TD
A["收到請求<br/>帶著使用者身分"] --> B["Plan<br/>看現在的狀態<br/>決定下一步"]
B --> C{"還有輪數<br/>可以跑嗎？"}
C -->|"用完了"| D["停下來收尾<br/>不然會無限想下去<br/>燒錢又卡住"]
C -->|"還有"| E["Act<br/>檢索？呼叫工具？回答？"]
E --> F["Observe<br/>看結果<br/>這一步的決策寫進紀錄"]
F --> G{"這一步的結果？"}
G -->|"目標達成"| H["回答使用者"]
G -->|"還沒完成"| B
G -->|"出錯"| I["收斂成失敗結果或轉人工<br/>不是把例外往上丟就當機"]
這層可以用 LangGraph、AutoGen、Semantic Kernel，也可以自己寫 while 迴圈。小系統用後者有時反而比較好查。選哪個框架其次，真正要確認的是：迴圈有狀態、可能失敗，而且每一步都留得下紀錄。
我自己的判斷方式是：如果流程需要跨請求記住進度，掛掉後還得從中間接著跑，那它已經比較像 durable workflow 或狀態機。這時該拿出 job queue、狀態持久化與 retry 策略，不必再疊更多 agent 抽象。Agent 框架可以省掉 plan-act-observe 的樣板，但流程的可靠性仍然得自己負責。
Tool Registry / MCP：agent 的手，要戴手套
Agent 真正有用，是因為它能「動手」——查資料庫、開工單、改設定。但這也是它最危險的地方。所以工具不該是散落在 code 裡的一堆 function，而該是一個有登記、有邊界、有審批的 registry。
我自己寫過 MCP server。工具改用標準介面接給模型後，最有感的其實不是少寫了多少串接，而是 agent 能做的事終於有一份清單可以盤點、審核和版本控制。對企業來說，這比「接得快」更重要。
選 MCP 並不等於把系統綁在 Anthropic。它雖然由 Anthropic 在 2024 年底提出，後來 OpenAI、Google 與多個開發工具也陸續採用，現在已由中立基金會治理。對架構比較實際的好處是：工具介面不用跟著模型供應商一起換，日後要調整底層模型會輕鬆很多。
每個工具至少要標：
-
action boundary：它是唯讀（查詢）還是會改變世界（寫入、刪除、送出）？
-
approval flow：會改變世界的，要不要人類按一下確認（human-in-the-loop）？
-
idempotency：同一個呼叫不小心跑兩次，會不會送出兩張訂單？
-
少了它會怎樣：上一篇鴻溝六——agent 用錯工具，真的會動到錢、改到資料。
-
怎麼整合：tool 後面接的就是你現有的內部 API。MCP / registry 是包在外面那層「戴手套」的設計，不是要你重寫後端。
還有一個 2026 才被認真對待的維度：工具的「描述」本身就是攻擊面。MCP 把工具描述塞進模型 context，等於把一段文字直接餵給大腦——如果這段描述被動過手腳（tool poisoning），它可以在模型不知情下夾帶指令，而近年針對真實 MCP server 的測試顯示這類攻擊的成功率高得驚人。所以 registry 的審核不只是「盤點 agent 能做哪些事」，還包括「這些工具的描述是誰寫的、有沒有被改過」——把工具當成依賴（dependency）來管，連同描述一起進版控與審查，而不是裝上就信。
（第 6 篇會專門拆 tool use 與 MCP，第 11 篇談把它升級成完整治理框架。）
Retrieval Layer：RAG，而且是帶權限的 RAG
這層讓 agent「知道公司的事」。文件、知識庫、資料庫，先變成向量存起來，問問題的時候檢索出最相關的幾段，餵給模型當依據。
但企業版的 RAG 跟 demo 版差一個關鍵字：權限。檢索的時候，必須用「上面那層傳下來的使用者身分」去過濾——只檢索這個人本來就有資格看的東西。這是一道過濾器，不是事後再補的 nice-to-have。
- 少了它會怎樣：要嘛 agent 不知道公司任何事（沒用），要嘛它什麼都知道、包括不該讓這個人知道的（資安事故）。
- 怎麼整合：向量庫可以從你既有的 PostgreSQL + pgvector 開始，不一定要先上專用向量庫。
（第 3、4、5 篇是這層的三連發：RAG 架構、向量庫與 embedding、權限感知檢索。）
Memory Store：讓 agent 記得，但別記錯人的事
Retrieval 是「公司的知識」，memory 是「這個對話 / 這個任務的脈絡」。兩者不一樣。Memory 又分短期（這輪對話）、長期（這個使用者的偏好）、episodic（這個任務做到哪、試過什麼）。
關鍵原則跟檢索一樣：記憶也有權限。A 使用者的長期記憶不能洩進 B 使用者的對話。聽起來理所當然，但在共用向量庫的設計裡很容易出包。
（第 7 篇專講 memory 與狀態管理。）
Model Router：不要每件事都用最貴的模型
把「呼叫哪個模型」抽成一層，而不是 hardcode。為什麼？因為 production 你會想要：
- 小模型優先：分類、抽取、簡單問答，用便宜快的模型就好
- 必要才升級：複雜推理才動用大模型
- fallback：主模型掛了或回垃圾，自動換一條路
這層直接對應鴻溝五（成本與延遲）。在 demo 全用最強模型沒事，乘上 production 流量就是帳單。給個量感你就懂為什麼這層值得蓋：同一個分類或抽取任務，旗艦模型和它的小型版之間，每百萬 token 的價差常常是一個數量級——把不需要推理的雜活全丟給最強模型，等於用頭等艙的票價在寄明信片。Model Router 的工作，就是讓 80% 的便宜雜活走便宜的路，只把真正需要深推理的那 20% 升級上去。
路由本身不難，難的是那兩條不在主線上的路：便宜的路走出不確定的答案要能往上升級，貴的路掛掉要有地方去。
（第 10 篇談這層背後的延遲 / 可靠性 / 成本三角。）
橫跨一切的旁路：可觀測性、Eval、Audit、Cost
圖底下這條線不是單獨一個服務，而是前面每個元件都要留下的紀錄：
-
Observability / Trace：每個請求的完整足跡——檢索了什麼、呼叫了哪些工具、每步多少 token / 多少秒。
-
Eval：一組黃金題庫，每次改 prompt / 換模型 / 調檢索，自動跑回歸。
-
Audit Log：誰、在什麼時間、透過 agent 存取了什麼資料、做了什麼動作。企業合規的底線。
-
Cost Monitor：每個功能、每個使用者燒多少錢，要看得見。
-
少了它會怎樣：鴻溝二和三——你不知道它有沒有變好，出事也查不到根因。
（第 9 篇把這條旁路整個建起來。）
回頭看整張圖
把這些元件放在一起看，AI agent 系統和一般後端沒有想像中那麼不同。Latency、retry、idempotency、狀態管理、queue、cache、權限與可觀測性，一樣都不能少；只是流程裡多了一個輸出不完全確定的模型，所以邊界要畫得更清楚。
也因此，這類系統最後考驗的仍是系統工程能力。Prompt 當然重要，但它只是整張圖裡的一部分。
下一篇從圖右側的 Retrieval Layer 開始，看看一批公司文件要經過哪些步驟，才能變成附得出來源的回答。
文章簡報
延伸閱讀
- 上一篇：企業 AI Agent 為什麼卡在 PoC？
- Agentic Engineering 是什麼？——換個角度看「用 agent 做工程」與「打造 agent 系統」的差別
- 下一篇：《RAG 架構實作：文件怎麼變成有來源可查的答案》
