很多人第一次做 AI System Design，直覺反應是先畫架構圖：
資料來源、RAG、Vector Database、LLM、Agent、Memory、Tool、Gateway 全部放上去，看起來很完整。(想當初我也是XD)

但架構圖畫得越滿，不代表問題定義得越清楚。

真正困難的問題通常還在前面：

• 為什麼要做這個 AI 系統？
• 它要改善哪一個商業成果？
• 這件事真的需要 AI 嗎？
• AI 應該做到什麼程度？做錯一次的代價有多大？
• 一個使用者請求進來之後，又會被放大成多少模型呼叫、Token、工具操作與成本？

所以我現在比較習慣用下面這條鏈來思考 AI System Design：

商業成果 → AI 適用性 → 自動化邊界 → AI 任務 → 品質與風險 → 規模與成本 → 系統架構

架構不是起點，而是前面這些條件逐步被定義之後，最後推導出來的工程答案。

先不要問要不要 Agent，先問這題值不值得做

AI 選題的第一題，不應該是「這個能不能用 AI 做」，而是：

做成功之後，哪一個商業成果會改變？

例如同樣都是客服 AI，背後可能有完全不同的目標：

• 降低平均處理時間
• 提高一次解決率
• 降低客服成本
• 提升客戶滿意度
• 或降低錯誤與法遵風險。

商業目標不同，後面的設計優先順序也會跟著改變。

• 如果主要目標是降低成本，就會更在意每個任務的成本與模型使用量；
• 如果重點是即時服務，就會更重視延遲；
• 如果是高風險場景，則需要更早考慮人工覆核、權限與稽核。

所以我通常會先用幾個維度快速掃描一個 AI 題目：

價值 × 發生頻率 × AI 適用性 × 準備程度 × 風險

這不是一個嚴格的數學公式，而是一個用來快速排除錯題目的思考框架。

價值，是做成功能產生多少效益；發生頻率，決定這個效益有沒有機會被放大；準備程度，則是在看資料、API、流程與權限是不是已經具備。AI 適用性更重要的不是「模型能不能做」，而是這個問題是否真的涉及語意理解、非結構化資訊、模糊判斷或動態決策。
如果 Rule、SQL 或一般 Workflow 就能穩定解決，其實不一定需要 AI。

最後還要看風險，也就是 AI 做錯之後，實際會產生什麼後果。
因此第一步應該是：

先決定這題值不值得做，再決定值得自動化到哪裡。

真正要決定的，是 AI 可以做到哪裡

現在很多 AI 專案一開始就問：

「現在Agent很酷，這個專案要不要做 Agent？一定要啦！就做Agent吧！」

但這個問題通常問得太早。更應該先決定的是：

AI 應該取得多少決策權與執行權？

這裡其實有兩個不同維度：
第一個維度是 決策自主性：流程是事先固定好的，還是 AI 需要根據當下狀態動態決定下一步。
第二個維度是 執行權限：AI 只是提供資訊與建議，還是可以真的修改外部系統。

因此實務上會有很多不同組合。

• 摘要、草稿通常是低自主、低權限；
• 固定流程自動建立工單，可以是低自主但有執行權限；
• Research Agent 則可能擁有很高的決策自主性，但完全沒有修改外部系統的權限。
• 所以 Agent 和高風險自動化，其實不是同一件事。

Agent 的關鍵是執行路徑能不能動態決策；而一旦 AI 能對外部系統產生實際變更，治理與控制的要求就會明顯提高。

例如 AI 可以付款、刪除資料、修改訂單、寄信或更新核心系統時，就需要開始考慮 Authorization、Human Approval、Audit、Rollback 等機制。

這兩條邊界定義清楚之後，再談 Agent 才有意義。

商業問題要先翻譯成 AI 任務

接下來，要把商業問題轉成工程上可以處理的 AI 任務。

例如：

降低客服人員搜尋內部規範的時間。

這還不是一個足夠精確的技術需求。繼續往下拆，可能會變成：

根據客服問題找到相關內部文件，並整理成有來源依據的回答。

到了這一步，才開始看得出系統真正需要什麼能力。

我通常會先把 AI 任務粗略分成幾類：

• 內容轉換與生成：例如理賠資料 → 理賠報告
• 知識檢索與整合：例如內部知識問答
• 判斷與建議：例如理賠建議、風險分類
• 操作與交易：例如建立工單、更新 CRM
• 動態任務編排：下一步無法事先固定，才逐漸進入 Agent

這裡最重要的是：

RAG、Agent、Fine-tuning 都不是需求，它們是解法。

所以不要一開始就問「這個需求要不要 RAG」，而是先問：這到底是哪一種任務？它需要哪些能力？
技術選型應該由任務往下推，而不是先選一個熱門技術，再想辦法套進問題裡。

接著定義：什麼叫做成功？

任務定義清楚後，下一步是把「AI 要好用」這種模糊需求，轉成可以被驗證的條件。
我通常會分成三層。

商業成果

這個 AI 系統有沒有真的產生價值？

例如平均處理時間是否下降、人工工時是否減少、轉換率是否提升、一次解決率是否提高，或錯誤成本是否下降。

任務品質

AI 本身有沒有把事情做好？

例如 Task Success Rate、Accuracy、Groundedness、Completeness 或 Tool Success Rate。

系統表現

即使 AI 把事情做對了，系統能不能穩定、持續地完成？

例如 p95 Latency、每個任務的成本、人工轉介率、Policy Violation Rate、Timeout Rate、Error Rate。

這三層其實分別在回答：

商業上有沒有成功？AI 有沒有完成任務？系統能不能穩定地完成這件事？

如果這三件事沒有先定義清楚，後面所有 Architecture 討論都很容易變成元件堆疊。

AI Sizing 的核心，不只是 Request，而是放大後的 Workload

需求、任務與成功條件定義清楚後，才真正進入 Sizing。

假設一個 AI Assistant 有：

10,000 DAU
5 Requests / User / Day

一天就是：

50,000 Requests

如果是傳統 Web API，我們可能接著開始算 QPS。但 AI 系統有一個很重要的差異：

1 個使用者請求，不等於 1 次模型呼叫。

假設平均每個 Request 需要兩次模型推論：

50,000 Requests × 2 Model Calls = 100,000 Model Calls / Day

如果每一次 Model Call 平均有 2,000 個 Input Tokens、500 個 Output Tokens，那麼一天大約就是：

100,000 × 2,500 Tokens = 250,000,000 Tokens / Day

也就是約 2.5 億 Tokens / Day。

因此 AI Sizing 真正要看的，不只是外部進來多少 Request，而是每一個 Request 最後會在系統內部被放大成多少工作量。

可以先用一個簡化的方式理解：

AI Workload
=
User Requests
× Model Calls / Request
× Tokens / Model Call

如果是比較複雜的 Workflow 或 Agent，則可能進一步變成：

AI Workload
≈
Requests
× Steps / Request
× Calls / Step
× Tokens / Call
× Retry Factor

實際上還要另外估算 Retrieval、Tool/API、Queue 與其他下游服務的負載，Token 只是其中一個最容易量化的維度。

所以使用者看到的是一個 Request，系統背後看到的可能是一串模型呼叫、檢索、工具操作、Retry 與資源消耗。

AI Sizing 的核心，不是 Request 數，而是 Request 被放大之後的 Workload。

平均值看成本，尖峰與長尾看容量

一天 2.5 億 Tokens 可以幫助我們估算日常成本，但它還不能回答另一個更重要的問題：

系統到底撐不撐得住正式環境？

因為流量不會平均分布。

假設每天有 50,000 Requests，直接平均大約只有：

0.58 QPS

如果只看這個數字，很容易低估真正的容量需求。大量流量可能集中在特定時段，而且 AI Request 往往比一般 API 需要更長的處理時間。

可以先用一個很直覺的方式理解：

同時處理量 ≈ 請求進入速度 × 單一請求處理時間

例如：

20 Requests / sec × 10 sec / Request = 200 Concurrent Requests

但如果 p95 Latency 拉到 30 秒：

20 Requests / sec × 30 sec = 600 Concurrent Requests

這其實就是 Little's Law 的直覺版本：

Concurrency ≈ Arrival Rate × Processing Time

所以我會把 Sizing 分成三個視角：

平均值用來估成本，尖峰流量決定容量，長尾決定安全空間。

對 AI 系統來說，Latency 也不只是使用者體驗問題。它還會直接影響同時處理量、Worker 數量、Queue 深度、模型容量，以及下游 API 與工具的負載。

Agent 讓工作量從固定值變成一個分布

到了 Agent，Sizing 又會再多一個變數。

一般 Workflow 的執行路徑通常大致固定，但 Agent 會根據當下狀態決定下一步，因此每一個任務的執行步數可能完全不同。

假設：

Average Steps = 6

這個平均數本身其實沒有告訴我們太多。真正更值得看的可能是：

p50 Steps = 5
p95 Steps = 18
p99 Steps = 30

如果一般任務只需要 5 Steps，但少數任務會跑到 30 Steps，這些長尾任務就可能消耗數倍的模型呼叫、Token、工具容量與處理時間。

Day 2 提到：

Agent 讓 Execution Path 變得 Dynamic。

到了今天可以再往下一步：

執行路徑一旦變得動態，工作量也不再是一個固定值，而會變成一個分布。

這也是為什麼 Agent 系統會開始需要 Max Steps、Retry Budget、Task Timeout、Cost Budget 與 Tool Call Limit。這些設定不只是控制模型行為，本質上也是在限制：

一個複雜任務最多可以消耗多少共享資源。

最後再看：完成一件成功任務，到底要多少成本？

AI 系統還有一個很容易被低估的指標：

每個成功任務的成本

假設：

Model A
每次成本 = 1 元
成功率 = 50%

Model B
每次成本 = 1.5 元
成功率 = 95%

只看單次呼叫價格，Model A 明顯比較便宜。但真正該問的是：

成功完成一件工作，到底要花多少成本？

所以可以寫成：

每個成功任務的成本 = AI 總營運成本 ÷ 符合成功條件的任務數

這裡的 AI 總營運成本，也不只是 Token Cost，還可能包含 Model、Retrieval、Tool/API、Retry、Infrastructure 與 Human Review。

所以可以進一步區分：

Cost per Call 是基礎設施指標；Cost per Successful Task 才比較接近商業指標。

這也是為什麼最便宜的 Model，不一定產生最低的任務成本。後面談 Model Routing、Cache、Fine-tuning，甚至 Small Model Strategy，其實都會再次回到這個問題。

Sizing 做完，Architecture 才真正開始

到這裡，前面的商業與技術限制才真正開始轉成架構決策。

• 如果大量 Context 重複出現，才有理由考慮 Cache；
• 如果不同任務的難度差異很大，才開始考慮 Model Routing；
• 如果任務不需要即時完成，才有理由使用 Async / Batch；
• 如果 Agent Steps 有明顯長尾，才需要 Max Steps、Retry Budget、Timeout；
• 如果操作錯誤的代價很高，才需要 Human Approval、Authorization、Audit；
• 如果流量有明顯尖峰，才需要 Queue、Backpressure、Rate Limiting。

換句話說，架構元件不應該因為「大家都這樣畫」而存在，而應該是某個限制條件逼出來的選擇。

所以成熟的 System Design，不應該只是回答：

架構裡有哪些 Component？

而是應該回答：

是哪一個限制條件，迫使這個元件存在？

最後把今天整篇濃縮起來：

商業成果 → AI 適用性 → 自動化邊界 → AI 任務 → 品質與風險 → 規模與成本 → 系統架構

AI System Design 的核心，不是把元件一個一個放進架構圖，而是把商業問題逐步翻譯成可以被衡量、驗證與限制的系統 Constraint。

Architecture，只是這些 Constraint 最後形成的工程答案。

AI 你怎麼看?

(os:小AI 你今天文章的附圖不認真畫，迷因圖倒是畫的很精緻是怎樣?)