如果你的團隊已經做出 AI 代理（AI agent）試作，下一步請先檢查六件事：資料來源能不能追溯、工具權限有沒有邊界、答案是否能用來源驗證、失敗後能不能從中斷點恢復、上線後是否看得到任務軌跡（trace），以及高風險步驟是否有人類審核。這些問題沒有解清楚，試作再會說話，也還不能放進正式流程。
Agent Development Lifecycle（ADLC，可以譯作代理上線生命週期）就是把這些檢查整理成一套流程。LangChain 在 2026 年 5 月把它分成建立、測試、部署、監控與治理；MartinFowler.com 2026-06-16 發布的 Bayer PRINCE 案例，則示範受監管企業如何把代理式檢索增強生成（agentic RAG）做成可驗證、可恢復、可審核的內部研究系統。
對資料主管、產品負責人、平台工程與企業 AI 導入團隊來說，這篇的重點是判斷「試作何時能進正式環境」，而非追逐單一模型或框架名詞。
ADLC 管的是五個交付問題
ADLC 可以先用白話理解成「AI agent 的上線驗收表」。它不綁定單一工具，重點是讓團隊在每個階段留下可檢查的交付物。
| 階段 | 讀者要確認的問題 | 最低交付物 |
|---|---|---|
| 建立（Build） | 代理要做哪個任務？能讀哪些資料？可以呼叫哪些工具？ | 任務範圍、資料來源、工具清單、禁止行為、輸出格式。 |
| 測試（Test） | 它是否真的完成任務，不能只看回答是否像樣？ | 代表性任務集、標準答案或驗收規則、失敗案例、回歸測試。 |
| 部署（Deploy） | 它在哪裡執行？中斷、權限、沙盒、回滾怎麼處理？ | 執行環境、身分與權限、狀態保存、人工審核點、回滾方案。 |
| 監控（Monitor） | 上線後是否看得到錯誤、成本、工具呼叫與任務結果？ | 任務軌跡、成本儀表板、錯誤分類、使用者回饋、線上評測。 |
| 治理（Governance） | 多個部門開始建立 agent 後，誰負責風險與改善？ | 責任人、資料分級、審核節奏、可停用機制、共用元件管理。 |
這張表適合在專案會議裡直接使用。當某一格還沒有負責人或驗收方式，就先不要把 agent 接到正式資料、客戶流程或不可逆操作。
Bayer PRINCE 案例補上的現實：資料路由會先出問題
MartinFowler.com 的〈Building Reliable Agentic AI Systems〉描述 Bayer AG 與 Thoughtworks 開發的 Preclinical Information Center（PRINCE，臨床前資訊中心）。這是一個雲端研究平台，用來協助研究人員查詢臨床前藥物開發資料。
文章指出，PRINCE 從關鍵字搜尋演進成研究助理，結合代理式檢索增強生成與文字轉 SQL，查詢多年安全研究報告與結構化資料，並可協助回答複雜問題與草擬受監管文件。
這個案例值得放進 ADLC，是因為它面對的是多資料源、多工具、多步驟、需要專家審核的內部知識系統，而非單一聊天框。研究員可能輸入一句看似簡單的問題，但背後要判斷毒理、藥理、研究編號、PDF 報告、資料表欄位與可引用證據。模型如果拿到過多資料會混亂；拿到過少資料又會漏掉關鍵內容。
PRINCE 的做法是先讓系統釐清使用者意圖，再決定應該查哪個資料源與工具。文章也提到，它會把文字轉 SQL 的資料庫結構（schema）限縮到當前問題需要的部分，避免把整個複雜資料庫塞進模型上下文。這就是很多企業代理早期會忽略的地方：可靠度先來自資料與工具路由設計，接著才是模型回答能力。
從 PRINCE 抽出的三層可靠性
| 可靠性層級 | PRINCE 案例中的做法 | 企業導入時要學什麼 |
|---|---|---|
| 資料與上下文路由 | 先釐清問題領域，再選擇檢索增強生成、文字轉 SQL 或特定資料源；SQL 只注入相關資料庫結構。 | 不要把所有文件、表格與工具一次交給模型；先建立資料分流與權威來源規則。 |
| 證據與反思 | 研究代理（Researcher Agent）收集資料，反思代理（Reflection Agent）檢查證據是否足夠，寫作代理（Writer Agent）負責整理答案與引用。 | 把「找資料、判斷資料夠不夠、寫出答案」拆開驗證，避免同一個模型一路自問自答。 |
| 控制與恢復 | 使用 LangGraph 編排流程，保存狀態，支援重試、使用者重新執行、模型備援、任務軌跡（trace）與 CloudWatch 監控。 | 上線系統要能停、能查、能重跑、能從失敗節點恢復；任務軌跡要能支援除錯與稽核。 |
這三層讓 ADLC 變得具體。建立階段要定義資料與工具邊界；測試階段要看最後答案和路徑證據；部署階段要處理狀態、恢復與權限；監控階段要追任務軌跡、成本與人工審核。AI agent 的每一步工具呼叫、資料選擇、引用、重試與人工審核，都會影響它是否能進正式流程。
實務情境：資料主管要把內部知識助手推到正式流程
讀者情境：資料主管已經用公司內部文件做出一個知識助手，能回答制度、合約、客服或研究資料問題。團隊想把它放進正式工作流，讓同事每天使用。
可以交給專案團隊的任務：
用 ADLC 檢查這個知識助手。列出 30 個真實任務，標記每個任務需要的資料源、工具權限、標準答案或驗收規則。跑完測試後，提供成功率、引用正確率、失敗類型、平均成本、人工審核需求與不適合上線的情境。
預期輸出：團隊應該交出一份上線判斷，不能只展示聊天畫面。這份判斷要說明哪些任務可以先開放、哪些任務需要人工覆核、哪些資料源還不能接入，以及哪些失敗需要回補到測試集。
怎麼驗證：抽查成功與失敗各 5 到 10 筆任務軌跡，確認 agent 讀了正確資料、引用可追溯、工具權限沒有越界、失敗訊息能讓工程或營運人員修正。若任務涉及客戶資料、合約、醫療、財務或法務，先用沙盒與匿名資料測過，再進入正式資料環境。
風險與不適用情境：如果資料來源沒有權威版本、文件更新無人負責、引用不能追溯、權限和身分沒有分開，這個 agent 應該留在內部試點。把它接進正式流程前，先補資料治理與審核責任。
上線前可以用這份檢查清單
- 任務邊界：agent 的工作是查詢、整理、草擬、更新資料，還是執行外部操作？每一類操作要分開授權。
- 資料來源：每個答案應該來自哪個文件庫、資料表或系統？是否有過期、重複或權威版本衝突？
- 工具權限：agent 可以讀取、寫入、發送、刪除或呼叫哪些系統？高風險操作是否需要人工批准？
- 測試任務集：至少準備一批高頻任務、邊界案例、容易誤解的問題與必須拒答的情境。
- 驗收規則：不要只看語氣順不順；要看答案是否有來源、欄位是否正確、工具是否用對、格式是否符合工作需求。
- 任務軌跡：保留輸入、檢索內容、工具呼叫、模型回應、引用、人工修正與最後結果，方便除錯和稽核。
- 部署恢復：長任務中斷後能否從失敗節點接續？重試會不會重複送信、重複建資料或重複扣款？
- 監控與成本：追蹤成功率、失敗類型、延遲、模型成本、工具成本與人工審核時間。
- 人工接管：定義哪些任務必須停下來請人看，哪些任務可以自動完成，誰有權停用 agent。
- 回流改善：把線上失敗、使用者修正與專家意見回補成下一輪測試資料。
如果你已經在做代理評測，可以延伸看 LLM 評估指南；如果重點是深度代理（deep agent）的任務軌跡與正式環境監控，可搭配 LangSmith 深度代理評測指南。
若 agent 會接觸敏感資料或外部工具，建議先讀 AI Agent 安全新共識 補上系統邊界。部署路線還不清楚時，再用 AI 代理正式部署指南 對照執行環境、成本與回滾方式。
和 LangChain ADLC 怎麼接起來
LangChain 的 ADLC 把流程拆成建立（Build）、測試（Test）、部署（Deploy）、監控（Monitor），外層加上治理（Governance）。PRINCE 案例提供一個更接近企業現場的對照：
- 建立（Build）：先把使用者意圖、資料源、工具、資料表結構與引用要求設計清楚。
- 測試（Test）：用資料集評測與線上流量評測檢查忠實度、答案相關性、上下文相關性、答案準確度與語意相似度。
- 部署（Deploy）：用流程編排、狀態保存、重試與模型備援處理長任務與暫時性失敗。
- 監控（Monitor）：用任務軌跡與系統監控看見錯誤、偏差、成本和需要改善的查詢類型。
- 治理（Governance）：保留專家審核、資料分級、引用追溯與人工接管，讓 agent 在受監管環境中可被信任。
這樣看，ADLC 更像一套問責方式，比流程圖更接近上線驗收表。每次新增工具、換模型、調整 prompt、擴大資料源，都應該能回到同一張驗收表：是否重新測過、是否看得到影響、是否有人知道何時該停。
官方來源
- LangChain，〈The Agent Development Lifecycle〉，用於確認 ADLC 的 Build、Test、Deploy、Monitor 與 Governance 框架。
- MartinFowler.com / Thoughtworks，Sarang Sanjay Kulkarni，〈Building Reliable Agentic AI Systems〉，2026-06-16；用於確認 Bayer PRINCE 的用途、代理式 RAG、Text-to-SQL、Researcher / Reflection / Writer Agent、評測、監控、狀態保存與人工審核設計。
重點整理
AI agent 從試作走向正式環境時，成熟度要同時看資料、工具、評測、部署、監控與治理。LangChain ADLC 提供生命週期框架；Bayer PRINCE 案例提醒團隊，可靠的企業 agent 需要清楚的資料路由、證據檢查、引用追溯、任務軌跡、恢復能力與人工接管。
先用小範圍真實任務跑完整驗收，再擴大資料和權限。當 agent 能被測試、被觀察、被審核、被停用，才有資格從 demo 進入正式工作流。