第一天的開賽宣言提出了一個問題：

當模型不再只是單獨被呼叫的 API，而是真正參與資料取得、判斷與行動之後，原本熟悉的 System Design 有哪些地方需要重新思考？

當時列出了 RAG、Context、Agent、Production 與 Fine-tuning 等主題。
回顧前 29 篇可以發現，這些技術不是彼此分離的章節，也不是一條從簡單走向高級的升級路線。

它們其實共同修正了四個直覺：

1. AI 系統設計不是先選模型，而是先定義問題、責任與限制。
2. RAG 的重點不是找到文字，而是建立一條能保存證據的知識流程。
3. Agent 的核心不是多呼叫幾個工具，而是把部分流程控制權交給模型後，系統如何仍然可控。
4. Fine-tuning 不是遇到錯誤時的預設答案，而是完成故障歸因後，才可能選擇的行為改造手段。

因此，系列的最後就不逐篇重述各篇內容，就來看看它們最後如何形成一套可以從需求走到正式環境的設計方法。

第一個轉變：架構不是從模型開始，而是從責任開始

一開始最容易犯的錯，是產品提出一個 AI 需求後，團隊立刻討論要用哪個模型、要不要 Agent，以及向量資料庫該選哪一套。

但如果還不知道問題是否值得做、AI 能決定到哪裡、什麼結果才算成功，再完整的架構圖都只是在排列元件。

因此，整個系列最前面的核心不是某種 AI 技術，而是三個傳統 System Design 仍然成立的問題：

• 系統要完成什麼業務結果？
• 哪些錯誤可以接受，哪些後果絕對不能發生？
• 在預期流量、延遲與成本下，這件事是否值得被自動化？

AI 帶來的新變化，是輸出不再完全由程式碼決定。同一個輸入可能得到不同答案；一次使用者請求也可能放大成多次檢索、模型推論與工具呼叫。因此，Sizing 不能只看每秒請求數，還要看完成一次成功任務需要多少推論步驟、Token、工具操作與人工介入。

但這不代表第一版就要設計完整的 Agent 平台。相反，系統需要先建立最小 Baseline，讓任務至少能跑一次，並且留下可以比較的結果。沒有 Baseline，後面加入 RAG、重新編排 Context 或更換模型時，就無法證明究竟是哪個改動產生效果。

2026 年的 Google Cloud Agent 架構指引仍然把任務特性、延遲、成本與人工介入列在架構模式之前。對可預測、高度結構化的工作，官方也建議先考慮非 Agent 解法。

回顧這一段，真正留下來的不是一套固定架構，而是一個順序：

先定義責任與成功，再建立最小可比較版本；
只有 Baseline 暴露出的失敗，才有資格要求下一個元件。

第二個轉變：RAG 不是把資料塞給模型，而是保存證據

當 Baseline 回答不出企業內部政策時，最直覺的說法是：「模型不知道，所以需要 RAG。」

但一路從 Source of Truth、文件匯入、Chunking、Retrieval、Context 編排談到 Grounding 之後，可以看見「模型不知道」其實包含了許多不同問題。

• 資料可能根本沒有權威版本；
• 文件解析時可能遺失表格、標題與跨頁關係；
• 切得太碎會失去語意，切得太大又難以檢索；
• 搜尋可能找回相似文字，卻不是能回答問題的證據；
• 正確內容即使已經進入 Context，也可能因位置、衝突或資訊過量而被模型忽略。
• 最後，即使答案附上引用，也不代表每個主張真的受到來源支持。

沿著這條流程拆解後，RAG 不再只是「向量搜尋加上模型」的元件，而是一條證據供應鏈：

權威資料 → 結構保存 → 可檢索單位 → 候選證據 → Context 編排 → 有根據的回答

每一段都可能讓正確證據消失，而後面的元件無法自動修復前面遺失的資訊。

• Source of Truth 選錯，Reranking 再準也沒有用；
• 表格在解析時被拆壞，模型不可能靠更好的 Prompt 還原原始關係；
• 證據互相矛盾時，增加 Context 甚至可能讓結果更不穩定。

因此，Evaluation 的價值不是替整套 RAG 打一個總分，而是判斷問題發生在哪個邊界：

• 資料是否存在、檢索是否找到、Context 是否保留、答案是否受到證據支持。
• Trace 則進一步保存每一次執行使用的資料版本、候選內容、排序結果與模型輸出，讓錯誤可以被重建。

Microsoft 2026 年的 AI 架構總覽也把 RAG 放在更大的 Context Engineering 中理解：檢索只負責取得資料，真正的系統責任還包含模型在什麼時間、以什麼形式，看見哪些企業資訊與工具結果。

這一段最核心的收穫可以濃縮成一句話：

RAG 的品質，不取決於最後找回多少文字，而取決於正確證據能否一路存活到答案完成。

第三個轉變：Agent System Design 是在管理模型的控制權

RAG 讓系統取得資料，但多數 RAG 流程仍由程式決定：

收到問題、搜尋、整理 Context、呼叫模型，再回傳答案。

當模型開始根據中間結果決定下一步、選擇工具、反覆執行，直到它認為任務完成時，系統才真正跨進 Agent 的範圍。

因此，本系列對 Agent 採用一個可操作的定義：

Agent = Model + Harness

模型負責理解目標並提出下一個行動；Harness 則負責組裝 Context、驗證輸出、限制成本、執行工具、保存 State，以及判斷任務能不能繼續。

這個定義也解釋了後面一連串看似分散的議題。

• Loop 需要判斷是否真的有 Progress，而不是只看模型有沒有繼續輸出；
• State 保存的是系統目前相信的事實，不能直接由對話紀錄代替；
• Checkpoint 不只保存資料，還要知道中斷後從哪個合法位置 Resume；
• Memory 必須決定什麼值得寫入、何時取回，以及舊資訊何時失效。

工具與 MCP 則讓 Agent 可以接觸外部能力，但「看得見工具」和「有權執行這次操作」是兩回事。
退款、寄信或修改資料以前，Runtime 仍要重新檢查身分、權限、風險、資料版本與人工核准。Prompt 可以提醒模型遵守規則，卻不能成為唯一的安全邊界。

這一點在 2026 年變得更加明確。AWS Agentic AI Lens把 Agent 行為視為需要版本化、測試、漸進發布與回退的系統產物，也主張以明確契約與相稱的人工監督限制自主程度。NIST 的 Agent Hijacking 紅隊研究則整理超過 25 萬次攻擊，13 個受測前沿模型全部至少找到一次成功攻擊。

所以安全目標不應是期待模型永遠不犯錯，而是即使模型被誤導，執行層仍然不允許它跨越權限邊界。

正式環境還會帶來另一類問題：Agent 說退款失敗，不代表外部交易真的沒有發生。如果請求已送達付款系統，只是回應在途中遺失，直接重試可能造成第二次退款。這時候需要的不是再問模型一次，而是用固定操作身分、冪等、對帳與補償，找回外部世界的真實結果。

至於 Multi-agent，也不是因為一個任務很長就必須拆分。只有當子任務真的能平行、需要隔離 Context、使用不同權限，或能產出一份獨立驗收的成果時，多一個 Agent 才形成有價值的責任邊界。否則只是增加協調成本與新的失敗方式。

回顧整段 Agent 主題，所有元件其實都在回答同一件事：

模型可以決定下一步
但系統必須決定它看見什麼、能做什麼、何時停止，以及失敗後如何恢復。

第四個轉變：模型做不好，不代表下一步就是 Fine-tuning

當 Agent 在正式測試裡表現不穩定，最容易得到的結論是模型能力不足，需要 Fine-tuning。

但一個錯誤回答可能來自完全不同的地方：資料沒有更新、Retrieval 找錯、Context 遺失證據、工具規格改版、Parser 無法解析，或 Runtime 沒有正確恢復 State。只有把這些變因固定後，錯誤仍然穩定發生在模型行為，才真正進入模型客製化的範圍。

這也是為什麼 Fine-tuning 之前要先做故障歸因與消融實驗。它要證明「改變模型」真的對準問題，而不是用昂貴的訓練掩蓋資料或系統缺陷。

一旦問題確實位於模型，接下來也不是按流行程度選方法，而是判斷缺少哪一種學習訊號：

• SFT 讓模型從示範中學習應該產生什麼行為。
• LoRA 與 QLoRA 改變的是參數更新與保存方式，不是另一種訓練目標。
• 偏好學習處理多個可接受答案之間的取捨。
• Online RL 讓模型在可以互動與驗證結果的環境中，根據回饋調整策略。

訓練資料也不能直接把成功 Trace 全部倒進模型。一次任務最後成功，可能包含人工補救、重複操作、事後才知道的資訊，甚至模型原本做錯後被 Runtime 擋下的行動。真正需要保留的是：在當時可見的證據下，哪一步產生了值得模仿的決策。

而且訓練完成並不等於可以上線。微調後的模型只是 Candidate；Base Model、Adapter、Tokenizer、對話模板、Prompt、RAG 索引、工具規格、Parser 與推論環境，必須共同形成可重建的發布版本。新版通過不可抵銷的 Evaluation 門檻、效能驗證、Canary 與回退演練後，才有資格接手正式流量。

OpenAI 的 Agent 實務指南建議先使用能力較強的模型建立 Evaluation Baseline，再逐步測試較小模型是否仍能達標。這個順序的重點不是特定模型，而是先建立品質證據，再最佳化成本與延遲。

因此，模型客製化在整套架構裡不是最後必經的一級，而是一條有條件的支線：

先證明問題真的在模型，再決定要提供哪一種學習訊號；訓練之後，仍要回到同一套系統驗收。

把四個轉變重新組回同一筆退款

現在重新面對最初的產品需求：

希望客服 AI 能回答退款政策，符合條件時直接替使用者完成退款。

按照前 29 篇累積的判斷方式，不應先回答要使用哪個模型或 Agent Framework，而應依序做出以下決定。

這張表呈現的，正是一套以責任邊界為核心的 AI System Design。

它不是把 RAG、Agent、MCP、Memory 與 Fine-tuning 排成一條 Pipeline，而是把不同的不確定性分配給可以負責的邊界。政策事實由權威資料來源承擔；交易事實由業務系統承擔；動態路徑可以交給模型；權限由 Runtime 與人類承擔；中斷與未知結果由恢復機制處理；模型行為則由 Evaluation 與訓練流程改善。

最後形成的架構有兩個方向。橫向是退款任務的業務路徑：驗證身分、取得訂單、查找政策、形成判斷、取得核准、執行退款並確認結果。縱向則是貫穿每一步的控制與證據：State、權限、Trace、Evaluation、Recovery 與版本發布。

模型提供的是彈性，而縱向控制負責限制不可接受的後果。

面對下一個需求，可以先問這五個問題

如果要把三十天的內容壓縮成一份真正可以帶走的方法，可以留下五個問題：

1. 事實在哪裡？ 哪個資料來源或外部系統有權說明當下真相？
2. 下一步由誰決定？ 流程能否寫死，還是真的需要模型動態選擇？
3. 誰有權改變外部世界？ 權限、風險與人工核准是否在模型之外強制執行？
4. 失敗後如何找回事實？ State、Trace、Checkpoint、冪等與對帳能否讓系統安全恢復？
5. 證據支持修改哪一層？ 問題應該修資料、Prompt、Context、Workflow、模型，還是根本不值得增加複雜度？

這五個問題的順序很重要。先確認事實與責任，再決定模型可以取得多少控制權；先建立 Baseline，再讓每一次新增元件都有可驗證的理由。

2026 年的大廠架構指引並沒有把所有系統推向更複雜的 Agent。Google Cloud、Microsoft與 Anthropic反而都強調，架構模式應由任務特性決定；可預測的流程應保留確定性控制，只有真的需要彈性時才增加 Agent 或 Multi-agent。

最新實務最後仍然回到一個不新的原則：選擇最簡單、能滿足需求而且可以被驗證的設計。

AI 你怎麼看？

三十天前，這個系列從準備 AI 相關職缺面試所累積的筆記開始，重新整理 Generative AI、System Design、RAG、Agent 與 Fine-tuning。最初的目標，就是讓最後留下的成果不只是三十篇零散筆記，而是一套可以繼續延伸的 AI Engineering 知識框架。

現在回頭看，這套框架最重要的內容，不是記住多少技術名稱，而是知道一個 AI 需求應該如何被拆解。

模型可以保有探索與判斷的彈性，但不可接受的後果必須被系統限制；資料必須能指出來源，行動必須能追溯授權，失敗必須能被重建與恢復，改版也必須能證明比上一版更值得留下。

RAG、Agent、Multi-agent 與 Fine-tuning 因此不是成熟度的四個階段，而是不同問題需要時才採用的四條分支。

最後，現代 AI System Design 可以收斂成一個核心原則：

好的架構不是讓模型承擔更多，而是清楚決定每一種不確定性，應由模型、程式、資料、外部系統還是人類負責。

架構圖不是設計的起點，而是這些判斷留下來的結果。

延伸閱讀

• Google Cloud：Choose a Design Pattern for Your Agentic AI System
• Microsoft：AI Technology Overview
• Microsoft：Agentic Application Patterns
• Microsoft：AI Agent Orchestration Patterns
• Anthropic：Building Effective Agents
• OpenAI：A Practical Guide to Building AI Agents
• AWS：Agentic AI Lens Design Principles
• NIST：Insights into AI Agent Security from a Large-Scale Red-Teaming Competition