LangChain 在 2026 年 5 月 9 日提出 Agent Development Lifecycle，也就是 ADLC。它把 AI agent 的開發流程整理成四個主要階段：Build、Test、Deploy、Monitor，外層再加上 Governance。
這個概念重要，是因為很多公司已經過了「做出 agent demo」的階段，真正問題變成：如何穩定地做第二個、第三個、第十個 agent，而且每次都能測試、上線、觀察、改善。
ADLC 的四個階段
| 階段 | 要解決的問題 |
|---|---|
| Build | agent 用什麼框架、工具、prompt、skills、MCP、context？ |
| Test | 怎麼知道 agent 比上一版更好，而不是只是看起來更會說話？ |
| Deploy | agent 在哪裡執行？怎麼保存狀態、等待審核、恢復中斷？ |
| Monitor | 上線後怎麼看 tool calls、成本、失敗模式、使用者回饋？ |
ADLC 的核心不是流程圖，而是把 agent 變成一種可以被工程化管理的系統。
Build：先定義 agent 的工作邊界
Build 階段不是立刻寫 prompt，而是先釐清 agent 屬於哪一種系統。
常見選擇包括：
- Agent framework：組合模型、工具、retrieval、structured output 和 agent loop。
- Agent runtime：支援 state、branch、pause、resume、durable execution。
- Agent harness：提供 prompts、skills、MCP servers、hooks、middleware、filesystem。
- No-code 或 low-code agent builder：讓流程擁有者也能參與設計。
如果只是單回合查詢，簡單 tool calling 可能夠用。如果是多步驟、跨系統、會改資料的任務，就需要更明確的 runtime 和治理設計。
Test：不要靠感覺判斷 agent 好不好
Agent 測試的難點是：很多任務沒有唯一正解。
例如客服 agent 的回答可能有多種合格方式；coding agent 可能用不同路徑修同一個 bug；研究 agent 可能引用不同資料但都能形成合理結論。
因此測試通常需要混合幾種方法：
- Ground truth eval：有明確答案的任務，例如分類、抽取欄位、更新指定資料。
- Criteria-based eval：檢查是否有引用來源、是否遵守政策、是否有問清楚需求。
- LLM-as-judge：評估語氣、完整度、任務完成度與 groundedness。
- Code-based checks：檢查格式、schema、工具呼叫、權限與 forbidden pattern。
- Multi-turn simulation：模擬多輪對話和實際任務流程。
測試集不需要第一天就完美，但要能抓住明顯退步。Production trace 之後也應該逐步回流，補成更強的 eval dataset。
Deploy：agent 不一定適合傳統 stateless server
很多 agent 不是單次 request-response，而是會跑很久、會暫停、會等人、會寫檔案、會恢復。
部署時要看：
- Durable execution：中斷後能不能接續？
- Human-in-the-loop：高風險操作前能不能停下來？
- Sandbox：程式執行和檔案操作是否隔離？
- Context hub：prompt、skills、流程知識是否能版本化？
- Tool access：agent 可以代表誰呼叫哪些工具？
- Audit trail：每個工具呼叫是否能追到 agent、使用者和授權條件？
如果 agent 會接觸財務、客戶、內部文件或 production 系統，這些部署條件不是可選項。
Monitor：agent 成功回應不等於任務成功
傳統系統監控常看 latency、error rate、uptime。Agent 還需要看更多東西。
例如：
- 它是否呼叫了正確工具？
- 它是否用了錯誤 context？
- 它是否跳過必要批准？
- 它是否完成了使用者真正目標？
- 它是否花太多步驟才完成任務？
- 它是否在特定情境下反覆失敗？
這就是 trace 的價值。Trace 不是只看 log，而是看 agent 的整條 trajectory：輸入、model calls、tool calls、retrieval、context、輸出和最後 action。
Governance：規模化之後一定會出現
當公司只有一個 agent 時，治理可以很輕。但當不同部門都開始建立 agent，就會出現幾個問題：
- 成本誰負責？
- 哪些 agent 正在運作？
- 哪些工具被哪些 agent 使用？
- 哪些 prompts、skills、policies 可以重用？
- 哪些 agent 有權接觸敏感資料？
- 發生錯誤時誰能追蹤和停用？
治理的目的不是讓團隊變慢，而是避免 agent 數量增加後變成不可見、不可控、不可比較。
實務導入清單
如果要把 ADLC 用進公司流程，可以先做一版簡化清單：
| 項目 | 最低要求 |
|---|---|
| Build spec | 說清楚 agent 任務、工具、資料來源、禁止行為 |
| Eval dataset | 至少 20 到 50 個代表性任務與已知 edge cases |
| Deployment plan | 說明 runtime、sandbox、審核點與 rollback |
| Trace policy | 定義 trace 保存、遮罩和存取權限 |
| Cost dashboard | 追 agent、team、model、tool call 的成本 |
| Review cadence | 定期檢查失敗案例並回補 eval |
這樣不會太重，但能避免 agent 只靠個人經驗維護。
官方來源
結論
ADLC 的價值，是把 AI agent 從「能跑一次」提升到「能重複開發、測試、部署、監控、治理」。
未來企業比較成熟的 agent 團隊，不會只看模型榜單或單一工具功能，而會建立一套自己的 agent development lifecycle：每次改 prompt、換模型、加工具，都能被測試、被觀察、被審核，最後回到下一輪改善。