AI Agent 架構解剖

00核心心智模型

LLM 是一個無狀態的函數：文字進去，文字出來。它不記得你、沒有 session、 碰不到你的資料庫、也不會主動做任何事。整個 AI 架構裡其他所有元件的存在， 都是為了兩件事 —— 餵它該知道的，以及幫它做它想做的。

01五層架構總覽

不管用什麼框架、什麼供應商，成熟的 LLM 應用都會長出這五層加上一組橫切關注。 層與層之間的關係是「上層指揮下層」，而不是「上層包含下層」。

控制權的形狀

這張圖比分層圖更重要。它回答一個關鍵問題：誰呼叫誰？ 答案是 —— Orchestrator 呼叫所有人，沒有人呼叫 Orchestrator。

02模型層 — 引擎

這層應該被抽象成一個介面。把模型當成可替換的零件，不要讓業務邏輯知道它在跟誰講話。 開源權重模型（可自架、可換供應商）與閉源 API 模型的最大差異就在這裡：後者換掉的成本高得多。

兩類常見的模型形態

03上下文層 — 最被低估的一層

Context window 是整個系統唯一的工作記憶。所有能力層元件最終都在爭奪這塊空間。 Context engineering 已經取代 prompt engineering 成為主要的工程課題 —— 問題從「怎麼把話說好」變成「有限空間裡該放什麼、什麼時候放、什麼時候丟」。

三個必須理解的量

04Tools — 讓模型能影響外界

Tool 是你定義的一個可執行 function。你用結構化的 schema 把它「介紹」給模型， 模型判斷該不該用，然後 —— 關鍵在這裡 —— 由你執行，不是由模型執行。

一個 tool 的三個部分

{
  "name": "search_orders",
  // description 就是 prompt：模型靠讀這段文字決定要不要呼叫
  "description": "當使用者要查詢訂單狀態或歷史時使用。
                  若使用者是要建立新訂單，改用 create_order。",
  "input_schema": {
    "type": "object",
    "properties": {
      "customer_id": { "type": "string" },
      "status": { "type": "string", "enum": ["pending","shipped","done"] }
    },
    "required": ["customer_id"]
  }
}

完整的一次來回

並行工具呼叫

「Tool calling 一定要多輪來回」是常見誤解。回應裡的工具請求是一個陣列 —— 模型可以在同一次生成裡要求呼叫多個工具，這叫 parallel tool calling，不增加往返次數。

真正觸發多輪的條件只有一個：模型需要看到執行結果，才能決定下一步該做什麼。 如果執行成功後你只要回一句模板訊息，那永遠是一去一回。

05Skills — 讓模型知道「怎麼做」

Tool 回答「我能做什麼」，Skill 回答「我該怎麼做」。 它是一包打包好的流程知識，通常是一個資料夾：

my-skill/
├── SKILL.md          ← frontmatter: name + description（常駐 context）
│                        body: 完整步驟、規範、範例（按需載入）
├── scripts/          ← 輔助腳本，需要時才執行
└── references/       ← 參考文件，需要時才讀

核心機制：漸進式揭露

這解決一個真實的困境 —— 「怎麼做一件事」的知識量遠大於「能做什麼」。 你不可能把 30 頁的品牌規範塞進一個 tool 的 description， 但可以做成 skill，讓它只在相關時才進到上下文。

為什麼值得這麼麻煩

而且這是每一輪都要重傳的固定成本。十輪對話就是十倍浪費。 更重要的是 context rot —— 塞太多不相關的指令，模型反而會變笨。

description 是整包 skill 最重要的一行

它是唯一常駐上下文的內容。寫爛了，這個 skill 就永遠不會被觸發。

挑選 skill 的四種設計

實務上常是混搭：用 D 處理明確的（副檔名、路徑、使用者角色），B 處理其餘。

06MCP — 工具的插座

MCP（Model Context Protocol）不是一種能力，而是一個標準化的傳輸協定。 它把工具從「寫死在你的程式裡」變成「可插拔的外部伺服器」。

07Retrieval 與 Memory

Retrieval / RAG — 事實來源

模型的權重在訓練時就凍結了，而且不包含你的私有資料。 RAG 就是在呼叫模型之前（或之中）撈出相關資料塞進上下文。 關鍵是它有兩種模式，決定權的位置不同：

典型的檢索管線

使用者問題
   → 查詢改寫      把口語問題轉成好的搜尋語句（一次 LLM 呼叫）
   → 混合檢索      向量（語意相似）＋ 關鍵字（精確命中）並行
   → 重排序        用專門的小模型把最相關的排到前面
   → 取前 N 名塞進上下文

每一步都可以省略，也都可以換成更複雜的做法。 混合檢索幾乎總是勝過單一檢索 —— 向量找得到「意思接近」，關鍵字找得到「就是這個詞」。

Memory — 狀態

常被混為一談，其實是三種完全不同的東西：

08能力層對照 — 五個容易混淆的詞

這五個東西經常被放在一起講，但它們解決的是完全不同的問題。

09控制層 — 誰在指揮

Agent Loop：「Agent」這個詞的定義

有迴圈就是 agent，沒迴圈就不是。整個概念可以壓縮成十行程式碼：

messages = [system_prompt, user_input]

while True:
    response = llm(messages, tools)      # 想
    messages.append(response)

    if not response.tool_calls:        # 它不想再用工具了
        return response.text             # → 結束

    for call in response.tool_calls:
        result = dispatch(call)           # 做
        messages.append(tool_result(call.id, result))
    # 迴圈繼續：把結果餵回去，讓它決定下一步

Workflow 還是 Agent？這是最重要的架構決策

其他控制層元件

10橫切關注 — 上線後才知道多重要

Guardrails 護欄

Observability 可觀測性

LLM 應用的除錯難度遠高於傳統程式，因為同樣輸入可能有不同輸出。 沒有完整紀錄，事後根本無法重現問題。每一次呼叫至少要存：

• 完整的輸入內容 —— 不只是使用者那句話，是整包送出去的東西
• 模型、參數、版本 —— 供應商靜默更新模型是真實會發生的事
• input／output token 數 —— 成本歸因的唯一依據
• 延遲，分解到每個階段 —— 慢在檢索、模型、還是工具執行
• 工具呼叫序列 —— agent 迷路時的唯一線索
• 失敗發生在哪一層 —— 模型層？驗證層？執行層？

Eval 評估

沒有 eval 就沒辦法改進。 改了 prompt 之後，你憑什麼說變好了？靠感覺試三個 case 不算。

Sandbox 執行沙箱

一旦你給 agent 執行程式碼或操作檔案的能力，就需要隔離環境（容器、VM、獨立工作目錄）。 模型會寫出破壞性的指令，不是因為惡意，是因為它在解決問題 —— 而它不知道那個目錄裡有你三年的資料。

11誰是模型、誰是程式碼

架構圖上的一個框，不代表一個服務、一個模型、或一個進程。 很多框只是「同一顆 LLM 的第 N 次呼叫，換了不同的 system prompt」。

Planner、Router、Judge 這些聽起來像獨立系統的元件，實作起來往往就是一個函數， 裡面包一次 LLM 呼叫。理解這件事，能讓你看架構圖時不再被術語嚇到。

# 「Planner 元件」的全部實作
def plan(task: str) -> list[str]:
    resp = llm(
        system="你是任務規劃器。把使用者的目標拆解成 3-7 個"
               "可獨立執行的步驟。只輸出 JSON 陣列，不要解釋。",
        user=task,
    )
    return json.loads(resp)

三種呼叫模式的取捨

12成熟度階梯

實務上該按這個順序往上加。每往上一層，成本、延遲、除錯難度都是跳躍式增加 —— 往上加要因為「真的需要」，不是因為「比較潮」。

13常見誤解與術語

六個值得糾正的直覺

術語速查

一句話收尾

LLM 是唯一會思考的元件，但它什麼都做不到。 其他所有元件的存在，都是為了餵它該知道的，和幫它做它想做的。

→延伸閱讀

這頁是全景總覽 —— 講元件之間的關係、取捨與邊界。 每個主題還有一篇專門深入的筆記：