智能體開發生命週期 (The Agent Development Lifecycle)

原始來源與檔名：20260512_2026-05-12T093133+0800-The Agent Development Lifecycle.md

來源：[[@hwchase17]] (LangChain 創辦人) / X (Twitter) — 2026-05-10 原始檔名：2026-05-12T093133+0800-The Agent Development Lifecycle.md

NAPKIN | 餐巾紙

餐巾紙公式

The Agent Development Lifecycle (ADLC): Build -> Test -> Deploy -> Monitor -> Iterate -> (Governed by Infrastructure) Traceability (Monitor) -> Datasets (Test) -> Hill Climbing (Iterate)

把 Agent 做成一次性 Demo 很簡單，但要穩定地在生產環境中運行並產生商業價值，需要一套系統化的「生命週期」。LangChain 創辦人指出，頂尖團隊不會盲目修改 Prompt，他們依賴 Trace (軌跡追蹤) 來發現錯誤，將錯誤轉化為 Eval Datasets (評估資料集)，並在部署時提供 Sandboxes (沙箱) 與 Durable Execution (持久化執行環境)。只有建立這套閉環，Agent 才能透過試錯產生真正的複利。

一句話

本文由 LangChain 創辦人 Harrison Chase 撰寫，系統性地定義了「智能體開發生命週期 (ADLC)」。文章將流程拆分為構建 (Build)、測試 (Test)、部署 (Deploy) 與監控 (Monitor)，並強調了治理 (Govern) 的重要性。作者釐清了 Agent Framework、Runtime 與 Harness 的區別，並點出：Agent 的迭代不是靠感覺，而是靠追蹤 (Traces) 轉化為資料集，進而推動基於指標的爬山算法式優化。

餐巾紙草圖

[The Agent Development Lifecycle]

      ┌──────────────────────────────────────────────┐
      │                                              │
      v                                              │
[ BUILD ]  -------->  [ TEST ]  -------->  [ DEPLOY ] -------> [ MONITOR ]
(Frameworks,          (Datasets,           (Runtimes,          (Traces,
 Runtimes,             Simulations,         Sandboxes,          LLM-as-Judge,
 Harnesses)            Evals)               Context Hubs)       Dashboards)
      │                                                          │
      └────────────────── ( The Iterate Loop ) ──────────────────┘

* GOVERNANCE wrapped around everything: Cost limits, Tool access, Discoverability.

ROUND 1: SKELETON | 骨架掃描

“這篇文章在說什麼”

核心挑戰: 讓 Agent 跑一次很容易，讓它成為可重複、安全、系統化的實踐很難。需要從「專案」思維轉變為「生命週期」思維。
BUILD (構建): 釐清了三個層次的不同：
- Frameworks (如 LangChain, CrewAI): 處理抽象（串聯模型、工具、記憶）。
- Runtimes (如 LangGraph): 處理執行（狀態管理、控制流、中斷與恢復）。
- Harnesses (如 Claude Agent SDK): 提供周邊結構（沙箱、Hooks、檔案系統）。
TEST (測試): 不追求第一天就有完美的 Eval 系統。從小的資料集開始，針對「確定性答案」測準確度，針對「開放性任務」用標準（如是否越權）進行評估。複雜任務需要模擬 (Simulations)。
DEPLOY (部署): Agent 需要持久化執行 (Durable execution，失敗能恢復) 與沙箱 (Sandboxes，安全執行代碼)。同時需要 Context Hub 來管理非代碼資產（Prompt、Skills）。
MONITOR (監控): 與傳統軟體不同，Agent 成功返回 200 OK 不代表任務做對了。必須依賴 Traces (軌跡) 來觀察它調用了什麼工具。
GOVERN (治理): 隨著 Agent 數量增加，必須控管成本 (Cost)、工具存取權限 (Audit trails + Human-in-the-loop) 與資產的可發現性 (Discoverability)。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

核心論證鏈

Traceability (可追溯性) 是優化的物理基礎: 作者強調 “agent observability powers agent evaluation”。如果沒有監控系統記錄下 Agent 的完整思考軌跡（輸入 -> 工具 A -> 輸出 -> 工具 B -> 最終答案），當使用者回報「它算錯了」時，工程師根本無從 Debug。有了 Trace，失敗案例就能直接轉化為下一輪的 Eval Dataset。
Framework vs Runtime vs Harness 的精確定義: 這是業界目前最混亂的地方。作者精準地切分了這三者：Framework 是積木，Runtime 是引擎（管狀態），Harness 是車體（管環境與護欄）。這呼應了我們在《Agent Harness Engineering》中學到的概念，也說明了為什麼很多只依賴 Framework 的專案無法落地。
Non-code 資產的治理 (Context Hub): Agent 行為的改變往往不是因為改了 Python 代碼，而是改了 Prompt 或 SKILL.md。這些「軟性代碼」需要專門的基礎設施來做版本控制與共享，避免各個團隊重複造輪子。

關鍵證據

點出了真實企業場景的需求：Human-in-the-loop。不是所有操作都能全自動，涉及金融、生產環境的操作必須暫停等待人類授權，這依賴於 Runtime 層（如 LangGraph 或 Temporal）的持久化中斷恢復能力。

邊界條件

對於小型或個人專案，這套完整的 ADLC 過於沉重。建立 Eval、部署 Sandboxes 和管理 Traces 需要專門的平台（如 LangSmith）。但對於企業級應用，這是不可妥協的基礎設施。

ROUND 3: SOUL | 靈魂提取

“還能怎么用”

知識連結: 完美縫合了本週閱讀的兩大主題！《如何打造 Multi-Agent 系統》中的 Missions 架構就是這套生命週期的具體實例；而《深度拆解 AI Agent Harness》則補齊了 Build 階段中 Harness 內部的 12 個具體模塊。
深層洞見: “An agent can return a technically successful response and still fail the task itself.” (一個 Agent 可能在技術上返回了成功的響應，但卻把任務搞砸了。) 這句話道出了 AI 時代運維的本質轉變。傳統的 Datadog 監控 CPU 和 Error Rate 已經不夠了，我們需要監控「語義層面的正確性」。
行動呼籲: 停止在 Cursor 或 ChatGPT 裡無腦地修改 Prompt 來「碰運氣」。
1. 建立一個 eval_cases.md，記下 5 個 Agent 曾經失敗的具體場景。
2. 每次修改系統 Prompt 後，手動讓 Agent 跑一次這 5 個場景。這就是你邁向「系統化 Agent 開發」的第一步。