AI Agent 的核心概念#

1.1 什麼是 AI Agent#

AI Agent 是 AI Model 的「手腳」 — 一層站在 user 跟 Model 之間的程式碼，負責執行 Model 想做但做不到的事（讀檔、跑指令、查網頁、改 code⋯⋯）。

AI Model（也叫 LLM、Large Language Model、大型語言模型）就是像 Claude、ChatGPT、Gemini 這種你可以用自然語言對話的 AI 模型。本質是 純文字生成器 — 給它輸入、它產生輸出，沒有手腳。後面章節都用 Model 這個詞代表 AI Model / LLM。

舉個例子。假設你想讓 Claude 幫你做這件事：「幫我讀 README.md 然後總結」。直接丟給 Model 看，會發生什麼？

sequenceDiagram
    actor User
    participant Model
    User->>Model: "幫我讀 README.md 然後總結"
    Model-->>User: "我沒辦法直接存取你的檔案系統，<br/>請貼上內容我可以幫你總結 ⋯⋯"

Model 知道你要什麼，但它做不到 — 它只能輸出文字，沒辦法主動讀檔、跑指令、查網頁、改 code 這些「真實動作」。 沒有「手腳」幫它做事，Model 就只能停在「我做不到，請你貼給我」這一步。

加上 AI Agent 之後，Model 想做的事就有人替它執行：

sequenceDiagram
    actor User
    participant Agent as AI Agent
    participant Model
    User->>Agent: "幫我讀 README.md 然後總結"
    Agent->>Model: 將對話傳給 Model
    Model-->>Agent: "tool_use: read_file"
    Note over Agent: 執行 read_file 讀檔
    Agent->>Model: 把 tool_result 給 Model 繼續想
    Model-->>Agent: "這個專案是 ⋯⋯"
    Agent-->>User: "這個專案是 ⋯⋯"

加了 AI Agent 之後，Model 還是只會輸出文字 — 但這次它寫的是 tool_use 標記，告訴 AI Agent 該叫哪個工具。 AI Agent 站在中間：看到 tool_use 就真的去讀檔，把讀檔結果包成 tool_result 訊息再回給 Model 繼續推論，最後把 Model 的總結轉給 User。

tool_use / tool_result 是什麼？ 是 Model API 訊息結構裡的兩個欄位 — Model 不會真的執行工具，它只是在回覆裡寫一個 tool_use 標記告訴 AI Agent 該叫哪個工具；AI Agent 執行完之後，把結果包成 tool_result 訊息傳回給 Model。 1.3 / 1.5 會反覆看到這兩個詞。

「手腳」這層內部由四個東西組成，接下來四節依序拆解：

• 1.2 Executor — AI Agent 的主體，真正動手執行的程式碼
• 1.3 Message 和 Role — Model 跟 Executor 用什麼格式溝通
• 1.4 Memory — Agent 的記憶 = 一個 messages list，每輪都要重發整段歷史
• 1.5 Agent Loop — 為什麼一次任務要 Model 跟 Executor 反覆來回

1.2 Executor#

1.1 的圖把 AI Agent 當成黑盒子。打開來看，AI Agent 的核心元件叫 Executor — 後面章節會用「Executor」指 AI Agent 中那層「真正動手做事」的程式碼。 (業界其他名字：harness、scaffolding、agent runner，意思都一樣。)

Model 只會做一件事：看到對話歷史 → 輸出下一段文字 — 包括「我想呼叫 read_file」這種 tool_use 標記也是文字。 Executor 的工作就是把這種標記翻成真的去執行（讀檔、跑 shell、call API），執行結果包成 tool_result 訊息再回給 Model 繼續推論。

sequenceDiagram
    actor User
    box AI Agent
        participant Executor
    end
    participant Model
    User->>Executor: "幫我讀 README"
    Executor->>Model: 將對話傳給 Model
    Model-->>Executor: "tool_use: read_file"
    Note over Executor: 執行 read_file 讀檔
    Executor->>Model: 把 tool_result 給 Model
    Model-->>Executor: "這個專案是 ⋯⋯"
    Executor-->>User: "這個專案是 ⋯⋯"

最關鍵的一句：模型不執行任何工具，它只在回覆文字裡寫出 tool_use 標記。真正動手讀檔、跑 shell、call API 的是 executor。這個分工是後面所有設計的根。

Model 不會自己知道 executor 有哪些工具 — 是 executor 主動把一份 「工具清單」 隨對話歷史一起傳給 Model 的。 工具清單長什麼樣、怎麼傳、實作該怎麼寫 CH02 詳談。

1.3 Message 和 Role#

Executor 跟 Model 的對話靠的是 Message 。

每個 Message 至少帶兩個欄位：

• role — 誰在說話（user / assistant / system）
• content — 說了什麼（文字、tool_use 請求、tool_result ⋯⋯）

1
2
3

{"role": "user",      "content": "讀 README"}
{"role": "assistant", "content": [<tool_use: read_file>]}
{"role": "user",      "content": [<tool_result: "# Hello...">]}

Role 只有三種#

role 在 Anthropic 協定裡只有三種：

注意：沒有 tool role。工具執行結果也是用 user role。

這個設計的好處是 訊息協定極簡：永遠是 user / assistant 交替，executor 只是「代寫 user 訊息」的角色。

user      "幫我讀 README"        ← 真使用者
assistant [我要呼叫 read_file]   ← 模型決策
user      [tool_result: "..."]   ← executor 使用 user role 回覆 tool_result
assistant "這個專案是..."        ← 模型總結

1.4 Memory#

Agent 的記憶 = Message 歷史 = 一個 Messages list。
模型本身沒有記憶 — 因為他不會儲存每一次對話的 Message。

這跟 ChatGPT 網頁版「記得你問過什麼」不一樣 — 網頁版前端已經幫你把所有對話的 Message 塞回去給模型了。 Claude / GPT / 任何 Model API 都是沒有記憶的。

要讓模型「記得」事情，executor 會把所有對話的 Message（使用者的提問、tool_use、tool_result等）加到自己紀錄的 messages list，每次都是整個 messages list 一起傳送給模型，而不是只有單次對話的 message：模型看到完整的 Message 歷史，才知道下一步要做什麼。

1
2
3
4
5
6
7

messages = [ # messages list
    {"role": "user", "content": "讀 README"}, # 第一次對話的 Message
    {"role": "assistant", "content": [<tool_use: read_file>]}, # 第二次對話的 Message
    {"role": "user", "content": [<tool_result: "# Hello...">]}, # 最新對話的 Message
    # 從第一次到最新一次的對話都要一次傳給模型
]
response = client.messages.create(messages=messages, ...)

代價：對話越長，每輪傳的 token 越多，越貴越慢。 接下來 CH05 / CH06 / CH07 會把這層基礎記憶擴展成 短期 / 中期 / 長期 三層 memory 系統處理這個問題。

1.5 Agent Loop#

1.2 那張圖只示範了 一輪 工具呼叫（讀一個檔就總結完了）。真實任務通常要連續呼叫好幾個工具：

• 「列出 src/ 有哪些 Python 檔、每個做什麼」 → 先 ls src/ → 再對每個 .py 跑 read_file
• 「找出哪段 code 在處理 auth」 → 先 grep "auth" → 再對命中的檔案 read_file
• 「修這個 bug」 → read_file 找問題 → write_file 改 → run_shell 跑 test 驗

每跑完一個工具，Model 都要看結果再決定下一步。所以 Executor 必須在 Model 跟「真實工具執行」之間 反覆來回 直到 Model 回 end_turn：

%%{init: {'sequence': {'noteAlign': 'left'}}}%%
sequenceDiagram
    actor User
    box AI Agent
        participant Executor
    end
    participant Model
    User->>Executor: ① 提出需求
    loop Agent loop
        Executor->>Model: ② 發送 messages list
        alt stop_reason = tool_use
            Model-->>Executor: ③ 要呼叫某個工具
            Note over Executor: ④ 執行工具<br/>⑤ 把 tool_result 加到 messages list，回到 ②
        else stop_reason = end_turn
            Model-->>Executor: ③ 最終文字回答
            Note over Executor: ④ 跳出 [Agent loop]
        end
    end
    Executor-->>User: ⑤ 把最終回答轉給 user

上圖兩條分支來自 Model 回應裡的 stop_reason 欄位 — 它是 Model 在每次回覆時附帶的「狀態旗標」，告訴 executor 當前這一輪是「還想呼叫工具」還是「已經有最終答案」。 Executor 看 stop_reason 決定下一步走哪條路：

1. Executor 把累積的整段對話歷史發給 Model（1.4 講過：每輪都要把整段 messages 重發）
2. stop_reason = tool_use（要呼叫某個工具）→ executor 執行 Model 指定的工具 → 把結果包成 tool_result 加到對話 → 回到第 1 步
3. stop_reason = end_turn（已經有最終答案）→ executor 把 Model 的文字答案抽出來回給 user → loop 結束

沒有這個迴圈，AI Agent 就只會「呼叫一次工具就結束」，做不了多步驟任務。退出條件就一個：stop_reason = end_turn。代表 Model 認為已有足夠資訊回答 user。

stop_reason 的完整清單#

除了上面 loop 用到的 tool_use 跟 end_turn，stop_reason 其實還有別的值：

max_turns：避免無限次對話#

由於 Executor 會跟 Model 反覆來回 直到 end_turn，這層循環一旦不收斂就會 無限跑下去。常見的失控情境：

• Model 卡在「呼叫工具 → 看結果 → 又呼叫同一個工具」的死循環
• 工具持續回 error，Model 一直試新參數但都沒成功

為了避免無限來回，Agent Loop 必須加一個 最大次數 的限制：

1
2
3
4

for _ in range(max_turns):    # ← 跑超過這個次數就 raise，強制中止
    response = ...
    if end_turn: return
    if tool_use: continue

實務參考值：

• 一般問答任務：10 次夠
• 多步驟任務：30 次
• Agentic coding（讀很多檔、改很多地方）：100+ 也常見

階段檢查點#

到這裡你應該理解：

• AI Agent = Model + Executor + Loop — 三個零件構成最小架構，每個各司其職
• Executor 是手腳 — Model 想做的事都靠 Executor 執行，工具呼叫、狀態維護都在這
• Message 是 protocol — Model 跟 Executor 之間靠 messages list 溝通，user / assistant / system 三種 role 各有用途
• Model 沒記憶 — 「記得」是 messages list 累積、每輪重發給它的假象
• Agent Loop 由 stop_reason 控流 — tool_use 繼續、end_turn 收工；max_turns 防無限循環

下一章 CH02 提供工具 把這章的「Tool calling」架構落地 — 寫出三件套（run_shell / read_file / write_file）的工具定義跟實作，讓 agent 真的能動手做事。

參考資源#

• Anthropic Tool Use 文件
• 完整程式碼 — minimal_agent.py @ ch01