為什麼你用 SDLC 做 AI Agent 項目，註定會失敗

做 AI Agent 嘅人，十個有九個係直接開寫 code 嘅。

結果呢？寫到一半先發現 Agent 行為唔受控，測試冇辦法測，上線之後一大堆幽靈 bug。問題唔係技術唔掂，而係成個開發流程都用錯咗。

傳統軟件開發有個經典流程叫 SDLC——設計、開發、測試、部署、維護，逐個步驟做。呢套嘢用咗幾十年，核心假設係：同樣嘅輸入，永遠俾返同樣嘅輸出。

但 Agent 唔係咁玩㗎。

Agent 嘅輸出取決於 prompt、上下文、模型版本、外部工具調用……每次執行嘅結果都可能唔同。用 SDLC 嗰套「寫好測試用例、pass/fail 就搞掂」嘅邏輯去管 Agent，就好似用間尺度水咁——工具本身已經唔啱。

所以開發者社區搞咗個新框架：ADLC（Agentic Development Life Cycle）。

分別係：SDLC 將軟件當成靜態產品，ADLC 將軟件當成有生命嘅系統。

ADLC 總共有 7 個階段，每個都對應 SDLC 嘅某個環節，但做法完全唔同。

階段一：準備同假設

唔係一嚟就畫架構圖。而係要先搞清楚：用戶會點樣同呢個 Agent 互動？邊啲環節係而家人手重複做緊？Agent 到底解決邊個具體問題？

有個陷阱好多人中： skip 咗呢步直接開工，結果自動化咗錯誤嘅流程，越搞越亂。

老實講，呢步最好嘅做法係開 planning mode，等 Agent 自己幫你梳理行為模型，唔好諗 code，淨係諗流程。

階段二：範圍同問題識別

確定 Agent 做到啲咩、做唔到啲咩。關鍵動作係定義清楚人同 Agent 嘅責任邊界——邊個審核、邊個決策、邊個孭鑊。

以前唔需要咁做，因為冇 AI 參與決策。而家唔畫清楚，出事你都唔知揾邊個。

同時定死 KPI：時間、成本、延遲、可行性，全部寫低。

階段三：設計同架構

揀 Agent 模式（ReAct、Plan-and-Act、多 Agent），規劃數據流，計 token 經濟賬，揀模型同編排框架。

仲要狠啲：未寫第一行 code 之前，就要定義好「成功係點樣」。咁先可以用 TDD 嘅方式開發 Agent。延遲、準確率、幻覺率——呢啲取捨一定要預先諗定。

階段四：仿真同價值驗證

用真實數據運行原型，驗證之前嘅假設。

呢步嘅核心邏輯係：而家失敗嘅成本最低。如果原型行唔通，即係呢個 Agent 唔應該做——越早發現越好，拖到上線先冧，代價大十倍。

驗證啲咩？幻覺率、回應質素、數據質素、成本基準。運行完拎到嘅數據就係之後迴歸測試嘅 ground truth。

階段五：實現

終於到寫 code。但呢度有個關鍵分別：SDLC 嘅邏輯喺 code 同配置入面，ADLC 嘅邏輯分散喺 code、prompt、模型、工具、外部服務呢五層。任何一層變咗，成個系統行為都可能變。

仲有一點：context management 係生死線。就算你用 100 萬 token 嘅上下文窗口，塞太多無關資訊入去，Agent 嘅注意力會被稀釋，輸出品質直線下降。

喺呢個階段，開發同測試唔可以分開。每次改一樣嘢就要驗證一次，因為 Agent 系統入面一個細微改動可能引發連鎖反應。

階段六：測試

唔係傳統嘅 pass/fail。Agent 嘅測試指標係準確率分佈、幻覺率、每次交互成本。

因為 Agent 唔會行兩次完全相同嘅路徑，所以測試變成對推理能力、安全性同工具使用嘅持續評估。功能測試、非功能測試、結構測試、壓力測試，全部都要行。

階段七：部署

喺 SDLC 入面，部署即係「開發結束，進入穩定運行」。

喺 ADLC 入面，部署即係「主動監控同控制嘅開始」。模型會更新，上下文會漂移，環境會變化——呢啲嘢唔會因為你上咗線就停。

實際操作係先灰度發佈俾一細批用戶，觀察 Agent 喺真實場景下嘅表現，然後逐步放量。

部署之後仲未完。

Agent 需要持續學習。用戶嘅 👍👎 反饋、定期更新嘅數據源同 embedding、安全護欄嘅有效性監控、成本管理——呢啲全部都係長期工程。

傳統軟件嘅反饋循環係「用戶報 bug → 開發修」。Agent 嘅反饋循環係永不停止嘅持續改進過程。

做 Agent 最貴嘅唔係開發成本，係用錯流程之後嘅返工成本。ADLC 嘅核心：先諗清楚佢點樣生存，再決定點樣造。

做 AI Agent 的人，十個裏有九個是直接開寫代碼的。

結果呢？寫到一半發現 Agent 行為不可控，測試沒法測，上線後一堆幽靈 bug。問題不是技術不行，是整個開發流程就用錯了。

傳統軟件開發有個經典流程叫 SDLC——設計、開發、測試、部署、維護，一步一步來。這套東西用了幾十年，核心假設是：同樣的輸入，永遠給你同樣的輸出。

但 Agent 不是這麼玩的。

Agent 的輸出取決於 prompt、上下文、模型版本、外部工具調用……每次跑的結果都可能不一樣。用 SDLC 那套"寫好測試用例、pass/fail 就完事"的邏輯去管 Agent，就像拿尺子量水——工具本身就不對。

所以開發者社區搞了個新框架：ADLC（Agentic Development Life Cycle）。

區別就是：SDLC 把軟件當靜態產品，ADLC 把軟件當活的系統。

ADLC 一共 7 個階段，每個都對應 SDLC 的某個環節，但做法完全不同。

階段一：準備和假設

不是上來就畫架構圖。而是先搞清楚：用戶會怎麼跟這個 Agent 交互？哪些環節現在是人在重複勞動？Agent 到底解決的是哪個具體問題？

有個坑很多人踩：跳過這步直接幹，結果自動化了錯誤的流程，越做越亂。

說實話，這步最好的做法是開 planning mode，讓 Agent 自己幫你梳理行為模型，不要想代碼，只想流程。

階段二：範圍和問題識別

確定 Agent 能幹什麼、不能幹什麼。關鍵動作是定義清楚人和 Agent 的責任邊界——誰審核、誰決策、誰背鍋。

這個以前不需要，因為沒有 AI 參與決策。現在不畫清楚，出了事你都不知道該找誰。

同時把 KPI 定死：時間、成本、延遲、可行性，全寫下來。

階段三：設計和架構

選 Agent 模式（ReAct、Plan-and-Act、多 Agent），規劃數據流，算 token 經濟賬，選模型和編排框架。

更狠的是：在寫第一行代碼之前，就要定義好"成功長什麼樣"。這樣才能用 TDD 的方式來開發 Agent。延遲、準確率、幻覺率——這些 trade-off 必須提前想好。

階段四：仿真和價值驗證

用真實數據跑原型，驗證之前的假設。

這步的核心邏輯是：現在失敗的成本最低。如果原型跑不通，說明這個 Agent 不該做——越早發現越好，拖到上線再崩，代價大十倍。

驗證什麼？幻覺率、響應質量、數據質量、成本基線。跑完拿到的數據就是後面迴歸測試的 ground truth。

階段五：實現

終於到寫代碼了。但這裏有個關鍵區別：SDLC 的邏輯住在代碼和配置裏，ADLC 的邏輯分散在代碼、prompt、模型、工具、外部服務這五層裏。任何一層變了，整個系統行為都可能變。

還有一個點：context management 是生死線。就算你用 100 萬 token 的上下文窗口，塞太多無關信息進去，Agent 的注意力會被稀釋，輸出質量直線下降。

在這個階段，開發和測試不能分開。每改一個東西就要驗證一次，因為 Agent 系統裏一個小改動可能引發連鎖反應。

階段六：測試

不是傳統的 pass/fail。Agent 的測試指標是準確率分佈、幻覺率、單次交互成本。

因為 Agent 不會走兩次完全相同的路徑，所以測試變成了對推理能力、安全性和工具使用的持續評估。功能測試、非功能測試、結構測試、壓力測試，全都要跑。

階段七：部署

在 SDLC 裏，部署意味着"開發結束，進入穩定運行"。

在 ADLC 裏，部署意味着"主動監控和控制的開始"。模型會更新，上下文會漂移，環境會變化——這些事不會因為你上線了就停下來。

實際操作是先灰度發佈給一小批用戶，觀察 Agent 在真實場景下的表現，然後逐步放量。

部署之後還沒完。

Agent 需要持續學習。用戶的 👍👎 反饋、定期更新的數據源和 embedding、安全護欄的有效性監控、成本管理——這些全是長期工程。

傳統軟件的反饋循環是"用戶報 bug → 開發修"。Agent 的反饋循環是永不停止的持續改進過程。

做 Agent 最貴的不是開發成本，是用錯流程之後的返工成本。ADLC 的核心：先想清楚它怎麼活，再決定怎麼造。