從 PoC 到 Production：企業 AI Agent 系統工程

兩天就做出一個會查資料、會呼叫 API 的 AI agent demo，老闆很興奮——然後它在 production 待了六個月還上不了線。這篇拆解 demo 到 production 之間最容易被低估的六道鴻溝，以及為什麼「能動」離「能信任」還很遠。

把上一篇的六道鴻溝收斂成一張參考架構：從 API Gateway、Agent Runtime、Tool Registry、權限感知檢索、Memory Store 到 Model Router 與可觀測性旁路。每個元件為什麼存在、少了它會出什麼事、以及怎麼跟你既有的後端整合而不是另起一座孤島。

企業 RAG 不是「把文件丟進向量庫然後問問題」這麼簡單。從 ingestion、chunking 策略、embedding、檢索、reranking 到 source citation，拆解每一步的設計取捨與最常見的翻車點，以及為什麼「答案要附來源」是企業信任 AI 的第一道門檻。

向量庫選型是 RAG 的地基，也是最容易過度工程的地方。pgvector vs 專用向量庫（Pinecone/Qdrant/Vectorize）怎麼選？embedding 模型與維度怎麼挑？什麼時候需要 hybrid search？HNSW 和 IVF 差在哪？用一張決策表和一個「先用 Postgres」的務實建議，幫你把地基打對。

個人玩 RAG 不會遇到這個問題，但企業一定會撞牆：當不同權限的人問同一個 agent，它怎麼確保每個人只檢索得到自己有資格看的東西？拆解 pre-filter vs post-filter、權限繼承、機密分級、來源歸屬與多租戶隔離——這是把「能 demo」和「過得了資安」分開的那條線。

Tool-using agent 真正可怕的地方，不是它會講錯話，是它能操作外部系統——改資料、送訂單、動設定。從 function calling 的本質、MCP 作為標準介面，到 action boundary、approval flow、idempotency 與 rollback，談怎麼讓 agent 戴著手套動手，而不是裸手亂抓。

檢索是「公司的知識」，記憶是「這個使用者、這個任務的脈絡」，兩者不一樣。拆解短期、長期、episodic 三種記憶的用途與設計，context engineering 怎麼決定塞什麼進有限的視窗，以及一個最容易出包的點——A 使用者的記憶不能洩進 B 使用者的對話。

Multi-agent 聽起來很厲害，但大多數時候一個 agent 加好工具就夠了，而且更好 debug。談 supervisor/worker、pipeline、debate 等協作模式，handoff 怎麼傳 context，錯誤怎麼隔離不互相傳染，以及最重要的——什麼時候你「不」該用多代理。

你改了一句 prompt、換了個模型，怎麼知道系統變好還是變壞？拆解 eval harness（黃金題庫、LLM-as-judge、回歸測試）、agent 的 tracing（每一步檢索/工具/模型的 span）、token 與成本監控，以及上線後怎麼偵測品質漂移。把後端的可觀測性硬功夫，搬到會講人話的元件上。

LLM app 還是個 distributed system，延遲、可靠性、成本這三件事會互相打架，你不可能三個都要到極致。談 streaming 降感知延遲、retry/timeout/circuit breaker、prompt 與結果快取、model routing（小模型優先）、token 成本治理，以及怎麼用工程手段在這個三角上做出有意識的取捨。

把散落在各章的安全與信任機制，收斂成一張可以攤給資安和主管看的治理框架：資料分級、RBAC 權限邊界、tool registry、audit log、human-in-the-loop、eval harness、observability、成本監控。這一張圖，就是「能 demo」和「企業敢用」之間那道治理的牆。

一支小型 AI 工程團隊的成敗，不在於用了多潮的 framework，而在於有沒有建立一個可重複的 delivery loop。談 architecture/code/prompt/eval review 怎麼做、怎麼把 AI agent 的能力翻譯成 business stakeholder 聽得懂的 workflow impact 和 ROI、以及怎麼讓團隊在一個變化極快的領域裡持續交付。系列完結篇。