編按：本文綜合整理自 Martin Fowler 官網案例研究〈Building Reliable Agentic AI Systems〉（作者 Sarang Sanjay Kulkarni，Thoughtworks），並加入 Siami 編輯部觀點與分析。原文基於 Bayer AG 與 Thoughtworks 共同發表於 Frontiers in Artificial Intelligence 的同儕審稿論文。
當企業認真想把 LLM 做成「每天生產線員工都會打開的工具」，困難往往不是模型不夠聰明，而是圍繞模型的那一圈工程——context 要怎麼管、agent 之間要怎麼協調、錯誤要怎麼救、可不可以解釋給監管機關聽。Bayer 的 PRINCE（Preclinical Information Center）把這件事做完了，而且把整個過程寫成一篇長文發在 Martin Fowler 官網。這份案例值得每一個想做「生產等級 LLM 應用」的工程團隊仔細讀。
PRINCE 想解決的問題：幾十年的 PDF 怎麼變成可查詢的資料？
Bayer 的臨床前研究環境，就像多數大型藥廠一樣，被兩種極端形態的資料夾擊：
- 高度結構化的研究資料庫（compound、study ID、species、route 等等欄位齊全）。
- 埋藏在 PDF 報告裡的敘述性內容——毒性、藥理、臨床觀察，往往要靠研究員一篇一篇打開讀。
這個組合讓研究員在「找一個特定 compound 在某個 study 的某段臨床觀察」時，要嘛在 metadata 系統拼命下 filter、撈到一堆無關結果，要嘛手動翻 PDF。兩個都很慢，而且「資料孤島」問題在歷次系統遷移後更嚴重：metadata 可能不齊、可能標錯，唯一真正可靠的「黃金標準」往往只剩下那份核准過的 PDF 報告本身。
Generative AI 出現後，RAG 給了 PRINCE 一次重新定位的機會：把 filter 介面換成自然語言問答介面。但這只是開始。真正難的是——怎麼讓研究員「敢用」。
PRINCE 的三段演進：Search → Ask → Do
PRINCE 不是一次到位的系統，而是有意識地分三段演進：
- Search 階段：把不同臨床前 domain 的 metadata 整合成「單一可搜尋入口」，研究員下 filter 撈資料。
- Ask 階段：導入 RAG，開始支援自然語言提問，能直接從 PDF 報告裡抽答案。連掃描的歷史報告都能查。
- Do 階段：把 PRINCE 升級成「主動研究助理」——能拆解任務、編排行程、串接多個資料源、起草法規文件草稿。
從 Search 到 Ask 到 Do 的演進，背後反映的是一個策略：先讓研究員願意打開系統，再讓系統慢慢長出能直接動手做事的能力。
這三段不是「加模組」而已，而是「整個 workflow、評估方式、可解釋性設計」都要跟著改。
系統架構：四個獨立 context 區的設計
PRINCE 的後端用 LangGraph 編排，搭配 FastAPI 服務，前端是 React 對話介面。架構圖展示了 4 個獨立 context 區，這是整份文件最值得抄筆記的部分：
| 階段 | Context 用途 | 避免的問題 |
|---|---|---|
| Think & Plan | 規劃 context（要選哪個工具、走哪條路） | 避免 LLM 在規劃階段就被不相關的檢索結果干擾 |
| Researcher | 檢索 context（RAG + Text-to-SQL 回傳的 chunk） | 避免 prompt 變成「什麼都塞進去的大雜燴」 |
| Reflection | 證據 context（驗證資料是否足夠） | 避免寫手階段的 LLM 看見還沒驗證的草稿 |
| Writer | 合成 context（最終要寫的內容） | 避免 LLM 在生成時被「未通過驗證的內容」誤導 |
context discipline（context 紀律）這個原則貫穿整個架構：「context window 變大，不代表你可以不必決定『哪些不該讓模型看到』。」這也是 Siami 在很多客戶專案中看到的核心教訓——以為 context 變大就萬能，結果 prompt 越長、模型越難 steer、評估越難做。
底層資料分布：
- OpenSearch：所有研究報告的向量表示（核心知識庫）
- Amazon Athena：經 ETL 整理過的結構化資料
- PostgreSQL + LangGraph checkpointer：每個節點執行後的 state 都落庫
- DynamoDB：應用層級的 broader state
韌性設計也很紮實：LLM 呼叫失敗會自動 retry，retry 多次仍失敗才換備援模型；agent 還會被告知錯誤 context，自己規劃替代路線。
Agentic RAG 的四個核心代理
1. 釐清使用者意圖（Clarify User Intent）
第一步不是直接執行，而是先確認「你要問什麼」。研究員輸入查詢後，PRINCE 會：
- 試圖從 query 中識別資料範圍（哪些 domain、哪些 study）
- 自動推薦可能相關的資料源（使用者可接受、修改或覆寫）
- 在意圖模糊時主動提問、確認範圍（fail-fast 機制）
這一步是整個 workflow 的「範圍守門員」——把後續 agent 收到的 context 限縮在合理範圍。
2. 思考與規劃（Think & Plan）
這個步驟直接借鑑 Anthropic 的 Think tool 概念，給系統一個「專屬空間」去推理下一步該做什麼。關鍵字是「process reflection」（流程反思）：它評估的是「我現在走的路對不對、有沒有在朝目標前進」，不是「資料本身對不對」。
為什麼這個小步驟在多代理系統裡特別關鍵？原文給了一個很具體的場景：「如果一個任務要執行 50 步，每一步都要問：我在對的方向嗎？我有沒有偏離？」沒有 Think & Plan 這個節點，agent 會線性衝刺，途中出錯也難以回頭。
另一個意想不到的價值：當 PRINCE 從 2 個工具擴張到十幾個工具時，模型在「選哪個工具」這件事上會猶豫——因為不同 domain 的工具語意重疊。Think & Plan 給了模型一個「先想再動」的空間，工具選擇準確率大幅提升。
3. 研究代理（Researcher Agent）
研究代理負責把 query 變成答案。PRINCE 用的是混合檢索策略：
- RAG：處理非結構化資料（PDF 報告）
- Text-to-SQL：查結構化資料（Amazon Athena 上的 metadata）
這套混合策略不是 PRINCE 發明的，但它在醫療合規場景的價值特別高——研究員問的問題常常是「在某個 study 裡有沒有出現 piloerection（毛髮豎立）」這種結合結構化 metadata 跟敘述性症狀描述的混合查詢。
RAG 流程細節值得單獨提：
- Ingestion：PDF → 抽取文字 → 結構化 JSON → 切塊（保留科學 context）→ 加 metadata → 嵌入 → OpenSearch 向量庫
- Query-time 流程（這是精華）：
Query → [關鍵字抽取] → 「piloerection」「ataxia」「半閉眼」「稀便」
→ [metadata filter 抽取] → study_id = T123456-2
→ [Query expander] → 額外生成 5 種同義問法（同一個症狀換個說法）
→ [加權混合搜尋] → 撈約 20 個 chunk
→ [Re-ranker] → 挑出 top 7 個最相關的 chunk
→ [最終 prompt] → 送進 LLM 生成答案這套流程的核心精神是：不要相信單一檢索結果。用關鍵字 + metadata filter + query expansion 三路並進，再用 cross-encoder re-ranker 收斂。原文有個關鍵警告：「如果擴張到 50 個 domain，現在這個 researcher 就管不動了——必須拆成 domain-specific 的子代理。」
4. 反思代理（Reflection Agent）
研究代理的輸出會先送進 Reflection Agent 驗證：「證據足夠嗎？引用是否支持結論？是否有幻覺風險？」這是 PRINCE 跟一般 RAG 最大的差異——多了一層「證據檢查」，而不是直接把檢索結果丟給寫手。
這個設計對醫療合規場景至關重要。法規文件錯一個數字可能就是召回事件。Reflection Agent 不只是「找錯」，而是要求研究代理補資料或重新檢查。
5. 寫手代理（Writer Agent）
所有 reflection 通過的證據才會送進 Writer Agent。寫手的工作是「組裝答案」，不是「生成答案」——這是 Siami 認為這份案例最值得學的一點：LLM 應該被當成「編輯」而不是「作者」。
為什麼這件事重要
這份案例的可貴之處，不在於 PRINCE 用了什麼新技術——RAG、multi-agent、LangGraph 都是 2025-2026 年的主流選項。真正難得的是，Bayer 把一個「真實上線、每天有研究員在用、合規必須過」的系統背後的工程決策全部攤開來講。
Siami 認為有三個層次的價值：
- 對企業 AI 團隊的工程參考：context discipline、四階段 context 分區、reflection agent 驗證、process reflection 設計——這套 SOP 適用於任何「生產等級 LLM 應用」，不只醫療。
- 對「agentic 是不是過度工程」的辯論提供實證：HN 上對這篇文章的質疑集中在「這些多代理架構到底有沒有真的比較好」。PRINCE 的設計哲學是「先試簡單，必要時再拆」——這跟 BN 業界主流的「微服務偏好」是不一樣的。Siami 認為這個保守立場更值得學習。
- 對 LLM 監管合規的方法論：在歐美藥廠、醫療、金融場景，LLM 上線不只是技術問題，更是法規問題。PRINCE 把「可解釋性」「人類在迴圈中」「可審查軌跡」當成 first-class concern，不是事後補上——這給整個行業立了標竿。
數據解讀與質疑
原文跟配套的 Frontiers in AI 期刊論文揭露了一個容易被略過的數字：PRINCE 的整體使用者滿意度是 3.1/5.0。作者 Sarang Kulkarni 在 HN 回應中澄清，這是「feature completeness」評分，不是「準確率」——很多被扣分的項目是「這功能還沒做」，不是「做了但錯」。但 Siami 認為這個澄清反而凸顯了更深的問題：
- 生產環境的 LLM 應用，「能做到什麼」跟「做對了什麼」是兩件事。一個 chatbot 看起來 80% 答對，累積下來研究員會懷疑剩下 20% 是不是藏在重要決策裡。
- 論文本身承認幻覺仍是營運風險——他們靠的是「線上即時評估 + Langfuse trace」去抓，不是「模型本身不會產生幻覺」。這跟很多 vendor 銷售話術差異極大。
- 架構越華麗，eval 越要跟上。HN 上的質疑派 AJRF 講得很直白：「30 段解釋你見過最標準的 RAG，2 段講 eval，這個比例不對。」
原文沒有講到「哪個模型」的細節，這是 agentdev001 在 HN 提出的合理質疑——小模型、frontier 大模型、fine-tuned 開源大模型，需要塞進的 context 完全不一樣。「中間放了一個 model」卻不講清楚，後面所有的「為什麼這樣設計」都會打折扣。
Siami 觀點
PRINCE 案例給 Siami 最深的啟發不是「multi-agent 很強」，而是**「multi-agent 的價值在於 context discipline，不在於角色多」**。
很多台灣企業的 AI 專案在嘗試 multi-agent 時，會直覺地設計「Researcher」「Writer」「Reviewer」「Planner」這種角色分工，然後期待神奇效果。但 PRINCE 揭示的真相是：
- 角色名稱只是「system prompt + 輸出契約」的標籤
- 真正的價值是「每個階段只看到它該看到的 context」
- 評估比架構重要——沒有扎實 eval 系統，再多角色都是 vibe-y 的流程圖
另一個值得台灣企業借鏡的：Sarang Kulkarni 在文章開頭就承認「AI 工具在構思、列大綱、修改草稿的過程中有用到」。在歐美，這種透明揭露是 LLM 應用的業界標準（也是 Frontiers 期刊要求）。在台灣，多數企業對外宣傳 AI 專案時仍然傾向「我們純手工打造」——這是種值得反思的溝通文化差異。
最後，PRINCE 強調的「Harness Engineering」（護具工程，圍繞模型搭建的編排、恢復、可觀測性）跟「Context Engineering」（context 工程，把資訊塑形並路由給對的 agent），這兩個詞是 2026 年 LLM 工程界最重要的概念。Siami 預期，未來一年所有嚴肅的企業 AI 報告都會引用這套框架。
重點摘要
- PRINCE = Preclinical Information Center，Bayer × Thoughtworks 合作，把幾十年的臨床前研究 PDF 報告變成可查詢、可分析、可起草法規文件的 AI 助理。
- LangGraph 編排、FastAPI 後端、React 前端，混合 RAG + Text-to-SQL，搭配 OpenSearch + Athena + PostgreSQL + DynamoDB 多元資料源。
- 四個獨立 context 區：Think & Plan、Researcher、Reflection、Writer——每個階段只看到它該看的 context，嚴守 context discipline。
- 核心 SOP：意圖釐清 → 流程反思 → 混合檢索 → 證據驗證 → 答案組裝。Reflection Agent 是把 PRINCE 跟一般 RAG 拉開差距的關鍵。
- Harness Engineering（編排、恢復、可觀測）跟 Context Engineering（資訊塑形、路由）——這是 2026 年企業 AI 工程最重要的兩個新學科。
- 生產環境滿意度 3.1/5（feature completeness）——架構成熟但產品仍在前進。透明揭露是這份案例最可貴的地方。
引用與延伸閱讀
- Building Reliable Agentic AI Systems（Martin Fowler 官網原文）
- Hacker News 討論串（151 points，34 則回應）
- Frontiers in Artificial Intelligence 收錄之同儕審稿論文：PRINCE 完整商業影響與產品演進細節
- Lance Martin on Delphina：From Context Engineering to AI Agent Harnesses — LangChain 高階工程師對 context/harness 工程的延伸論述
- Harness engineering: Leveraging Codex in an agent-first world（OpenAI 官方） — 同一時期 OpenAI 對 harness engineering 的工程實戰
- Apache Burr: Build reliable AI agents and applications（HN 297 點） — 開源社群對「可靠 agent」架構的對照觀點
編按：本文綜合整理自 Martin Fowler 官網案例研究〈Building Reliable Agentic AI Systems〉（作者 Sarang Sanjay Kulkarni，Thoughtworks），並加入 Siami 編輯部觀點與分析。原文基於 Bayer AG 與 Thoughtworks 共同發表於 Frontiers in Artificial Intelligence 的同儕審稿論文。
網友熱門留言 (12)