昨天提到，這次鐵人賽想從 System Engineering 的角度重新整理 AI 系統設計。第二天我想先處理一個最基礎的問題：當 AI 被放進既有的軟體系統之後，到底改變了什麼？

什麼東西變了？什麼東西不變？

AI 並沒有推翻原本的 Software Architecture。我們依然需要 API、Service、Database、Cache、Queue、Authentication、Monitoring，也還是要考慮 Scalability、Availability 與 Security。真正的差異在於，當 Model 成為系統中的一個 Component 之後，一些原本長期成立的系統假設開始不再穩固。

我目前會把這些改變整理成三個方向：結果開始具有不確定性、系統行為不再只由 Code 決定，以及系統需要建立持續改善的 Feedback Loop。 而當系統進一步走向 Agent，連原本相對固定的 Execution Path 也開始變得動態。

從 Deterministic 到 Probabilistic

傳統程式通常有相對明確的規則。例如當金額超過某個門檻時，就進入人工審核。在相同的程式版本與相同 Input 下，我們大致可以預期得到相同的 Output，因此很多測試可以直接透過 Expected == Actual 來判斷。

但如果今天把一份案件描述交給 LLM，請模型判斷風險、摘要內容，甚至直接產生一份報告，事情就不太一樣了。同樣的問題可能產生不同文字，而不同文字也可能同時都是合理答案；更麻煩的是，有些答案讀起來非常流暢，實際上卻可能遺漏資訊甚至產生錯誤。

因此我會先用一個很簡單的 Mental Model 來理解早期的 AI System：

AI System = Software System + Probabilistic Component

這個改變的影響其實很大。過去系統設計主要關注 Latency、Availability、Throughput 等指標，AI 系統則多了一個不能忽略的維度：Quality。我們不只要知道服務有沒有成功回應，也要知道模型產生的結果是不是夠好。

這也是 AI 系統很容易出現的一種特殊 Failure Mode：API 回傳 200 OK、Latency 正常、Server 沒有 Error，但答案其實是錯的。

Infrastructure Success 並不等於 AI Task Success。

也因此，Evaluation、Output Validation 或必要時的人工覆核，會逐漸成為 AI Architecture 的一部分，而不再只是上線前的額外檢查。

系統行為不再只由 Code 決定

第二個變化，我覺得甚至比「模型有隨機性」更值得注意。

傳統 Application 的行為主要來自 Code 與 Configuration。如果某一天系統突然產生不同結果，我們通常會從版本、設定或 Dependency 開始追查。但在 AI Application 裡，即使程式完全沒有修改，系統表現仍然可能發生改變。

因為一個 AI 功能最後呈現出來的行為，往往是多個因素共同作用的結果：

Code + Model + Prompt + Context + Data / Tools

Model Version 改了，答案可能不同；Prompt 沒改，但 Retrieval 找回來的 Context 改了，答案也可能不同；企業資料更新、Tool 回傳內容改變，甚至使用者開始提出過去沒有出現過的問題，都可能讓 Production 中的實際表現產生變化。

傳統 Machine Learning 很重視 Data Drift，因為資料分布改變可能造成模型效果下降；到了 GenAI Application，影響系統行為的變因變得更多，除了資料之外，還多了 Prompt、Retrieved Context、Model Version、Tool Result 等因素。

因此 AI Observability 也不能只停留在 CPU、Memory、HTTP Status 或 Application Log。當使用者說「最近回答好像變差了」，我們必須能夠進一步追蹤，到底是 Model、Prompt、Retrieval、Context，還是 Tool 的問題。

這也是我認為 AI Engineering 很重要的一個轉變：

我們開始需要觀察的，不只是系統有沒有運作，而是系統為什麼會產生這個結果。

從 Request Path 走向 Feedback Loop

傳統系統設計很自然會從 Request Path 開始思考：Request 從哪裡進來，經過哪些 Service，資料怎麼存取，最後 Response 如何回到使用者。

AI System 當然還是需要這條路，但只設計這條路已經不夠了。

只要系統裡存在 Probabilistic Component，我們就需要知道它在 Production 中實際表現如何。使用者是否重新提問、人工是否修改 AI 產出的內容、哪些答案被接受、哪些答案被退回，這些都可以成為後續 Evaluation 的 Production Signal。

因此一套比較完整的 AI Architecture，除了 Serving Path 之外，還應該存在另一條 Improvement Loop：

Production → Collect Signals → Evaluation → Improvement → Production

Improvement 也不一定代表重新 Train Model。很多時候真正需要調整的可能是 Prompt、Retrieval、Context，甚至 Workflow；Fine-tuning 只是其中一種手段，而不是所有 AI 問題的預設答案。

這也是我目前很喜歡的一個觀點：

AI Architecture 最後設計的其實是一個 Lifecycle，而不只是一次 Request。

傳統系統的行為主要隨 Code、Configuration 與 Dependency 改變；AI 系統則多了一層持續確認 Model 與 Context 表現是否仍符合需求的工作。這個 Feedback Loop 也會一路連到後面的 Evaluation、Observability，以及最後的 Fine-tuning。

Agent 又讓事情再往前走了一步

前面三個改變，其實在一般 LLM Application 就已經存在。但當系統開始走向 Agent，會再多出一個很重要的變化。

在一般 Workflow 中，Execution Path 通常還是由工程師預先寫好的。例如先 Retrieval、再組 Prompt、呼叫 LLM，最後產生 Response。LLM 雖然會產生不確定的 Output，但「下一步做什麼」仍然大致是固定的。

Agent 則開始把部分決策權交給 Model。模型可以根據目前的 Goal、State 與 Observation，決定下一步應該 Retrieval、呼叫 Tool、重新思考，或者結束任務。

所以我會把兩個世代的差異簡單整理成：

LLM 讓 Output 變得 Probabilistic；Agent 則進一步讓 Execution Path 變得 Dynamic。

這件事情也會直接影響後面的 Architecture。當 Execution Path 不再完全固定，State、Memory、Tool Permission、Guardrail 與 Observability 都會變得更加重要。工程師的工作，也開始從「定義每一步要做什麼」，逐漸轉向「定義 AI 可以在什麼範圍內自主決定下一步」。

總結一下

AI 沒有推翻 System Design，而是改變了三個基本假設：結果是否可預期、系統行為由誰決定，以及系統如何持續改善。到了 Agent 時代，連 Execution Path 也開始成為需要被管理的動態變數。

接下來，就可以沿著這些變化往下拆解，看一套原本相對單純的 LLM Application，究竟會逐漸長出哪些新的架構元件，以及到了 Agentic System 之後，哪些元件的角色又會跟著改變。

AI 你怎麼看?