AI Agent 不是帶 function calling 的聊天機器人。它是一個能感知、推理、行動與學習的系統——自主地、跨多個步驟、帶著在行動之間持續存在的狀態。Anthropic 的打造高效 Agent 指南是理解 Agent 架構模式的最佳起點。聊天機器人回答你的問題。Agent 在你飛在天上時，幫你訂好航班、改好會議、更新團隊的 Slack。
2026 年，人人都在做 Agent。很多在生產裡壞掉——永遠迴圈、呼叫錯工具、三步前在做什麼都忘了。這份指南涵蓋防止這些失敗的架構。從工具呼叫迴圈、記憶體系統到多 Agent 編排，每個章節都有能跑的程式碼。讀完你會有一個可以 fork 再擴展的研究助理 Agent。
什麼構成 AI Agent——以及什麼不是
定義。 AI Agent 有三層：推理核心（LLM）、工具層（API、資料庫、程式執行）、記憶體層（短期對話、長期知識、工作狀態）。與簡單 LLM 呼叫的關鍵差異：Agent 在迴圈裡做自主決定。它不是只回應。它會規劃、行動、觀察結果、決定下一步。
三層：
User Query → Reasoning Core (LLM) → Decision → Tool Execution → Observation → Memory Update → Next Decision → ... → Final Response什麼時候需要 Agent，而不是簡單 LLM 呼叫。 Agent：模型需要收集資訊、執行行動、並依結果調整的多步驟任務。「研究這個主題並寫一份報告」——Agent。「摘要這篇文章」——簡單呼叫。「除錯這個錯誤、查日誌、並開一個帶修正的 PR」——Agent。「解釋這則錯誤訊息」——簡單呼叫。
如果任務能在一次 API 呼叫、不用外部工具就完成，你不需要 Agent。如果任務需要從多個來源收集資訊、執行行動、並依中間結果做決定，你需要 Agent。決策樹：一步？——簡單呼叫。帶工具的多步？——Agent。
工具呼叫迴圈：Agent 的手
核心 Agent 迴圈。每個 Agent 框架——LangChain、CrewAI、AutoGen、裸寫（不靠框架）——都實作這個的某個版本。
import json
from openai import OpenAI
client = OpenAI(
base_url="https://api.tokspan.com/v1",
api_key="ts-your-key-here"
)
class Agent:
def __init__(self, model: str, tools: list, max_iterations: int = 10):
self.model = model
self.tools = {t["function"]["name"]: t for t in tools}
self.max_iterations = max_iterations
self.memory = [] # Working memory —the agent's scratchpad
def run(self, user_query: str) -> str:
messages = [
{"role": "system", "content": "You are a research assistant. Use tools to gather information, then synthesize a report."},
{"role": "user", "content": user_query}
]
for iteration in range(self.max_iterations):
response = client.chat.completions.create(
model=self.model,
messages=messages,
tools=list(self.tools.values()),
tool_choice="auto"
)
msg = response.choices[0].message
# Agent decided to respond with text —done
if msg.content and not msg.tool_calls:
return msg.content
# Agent decided to call tools —execute and continue
if msg.tool_calls:
messages.append(msg)
for tool_call in msg.tool_calls:
tool_name = tool_call.function.name
tool_args = json.loads(tool_call.function.arguments)
result = self._execute_tool(tool_name, tool_args)
messages.append({
"role": "tool",
"tool_call_id": tool_call.id,
"content": str(result)
})
return "Agent reached maximum iterations without completing the task."
def _execute_tool(self, name: str, args: dict):
# In production: dispatch to actual functions
print(f"Calling tool: {name}({args})")
return f"Result from {name}"工具定義最佳實務。 工具的描述就是提示詞——寫清楚。包含何時使用每個工具的範例。嚴格約束參數——用列舉而不是自由文字字串。讓工具具冪等性——用相同參數呼叫相同工具兩次，應產生相同結果。工具執行失敗時，把錯誤訊息送回模型——它常常能靠試不同參數恢復。
完整的跨供應商 function calling 比較——含 OpenAI vs Anthropic vs Google vs DeepSeek 實作——見跨供應商 function calling 指南。
迴圈裡的錯誤處理。 工具執行失敗——把錯誤送回模型——模型決定：用不同參數重試、試別的工具、或告知使用者。模型從工具錯誤恢復的能力出奇地好——前提是你把錯誤送回去。默默吞掉工具失敗，會產生神秘失敗的 Agent。
記憶體系統：教你的 Agent 記住
沒有記憶體的 Agent 是一條金魚——步驟之間全忘光。三種記憶體，各有特定用途。
短期記憶體——對話紀錄。 messages 陣列。使用者說了什麼、Agent 做了什麼、工具回了什麼。以滑動視窗管理——當紀錄逼近模型脈絡上限，刪掉最舊的訊息或摘要它們。摘要觸發：總 Token 超過脈絡視窗的 80% 時，把對話最舊的 50% 摘要成單一系統訊息。
長期記憶體——向量儲存。 過去的互動、使用者偏好、學到的事實——以嵌入存進向量資料庫、依與當前查詢的相似度取得。實作：把每個重要互動嵌入——存進 ChromaDB 或 Pinecone——每個新查詢時，取最相似的過去互動前 3–5 筆——作為脈絡放進系統提示詞。這就是「Agent 記得我們上週聊過什麼」和「Agent 每次對話都從零開始」的差別。
工作記憶體——草稿紙。 Agent 目前的計畫、中間結果、假設——以 JSON 物件儲存、每個迴圈迭代更新。Agent 現在想達成什麼？試過什麼？學到了什麼？草稿紙是 Agent 的「思路」——外部化，讓它跨工具呼叫存活、且可檢查除錯。
記憶體架構。 三種記憶體在每個迴圈迭代都餵給 Agent：對話紀錄（發生什麼）＋取回的長期記憶（過去什麼相關）＋工作記憶（現在在做什麼）。LLM 把這些合成下一個決定。
多 Agent 系統：一個 Agent 不夠用的時候
帶 15 個工具的單一 Agent 做不好決定——選項太多、脈絡太多、選擇準確度退化。解法：專業化 Agent，各有焦點的工具集與清楚的責任。
編排模式：
- 主管/工作者。 一個編排 Agent 把任務分派給專業工作者 Agent。主管不做事——它協調。「研究這個主題」——主管派給研究者 Agent、分析者 Agent、寫作者 Agent——主管彙整結果。
- 對等辯論。 兩個 Agent 辯論決定的正反兩面，然後收斂。「該核准這筆貸款嗎？」——Agent A 主張核准、Agent B 主張否決——雙方互相審查論點——產出聯合建議。
- 序列管線。 Agent A 的輸出是 Agent B 的輸入。「分析這個程式庫」——程式分析器輸出報告——bug 尋找器用報告找出問題——修正生成器提出解法。
多 Agent 通訊。 用共享訊息匯流排——每個 Agent 以 {from: "researcher", to: "analyst", content: "...", type: "report"} 形式的結構化訊息發布輸出。這讓 Agent 互動圖可觀察、可除錯。出問題時，你能精確追蹤哪個 Agent 產出哪個輸出、為什麼。
多 Agent 的成本。 每個 Agent 都在做自己的 LLM 呼叫。三 Agent 系統做的 API 呼叫是單 Agent 的 3 倍。緩解：工作者 Agent 用便宜模型（DeepSeek V4 Flash、$0.14/$0.28），編排者保留旗艦模型（Claude Opus、GPT-5.5）。編排者做高風險決定。工作者執行。
這裡有一個今天就能部署的具體三 Agent 研究管線。研究者 Agent 用 Gemini 3.1 Pro（輸入 $2.00/M）搭配剛好兩個工具——網頁搜尋與文件取得——所以永遠不會迷失在工具選擇麻痺裡。輸出是結構化 JSON 簡報：{sources: [...], key_facts: [...], gaps: [...]}。
寫作者 Agent 用 GPT-5.5（輸入 $5.00/M）把簡報轉成草稿，只用一個格式化工具。審查者 Agent 用 Claude Opus 4.8（輸入 $5.00/M）逐條用原始來源比對每個主張、標記幻覺、回傳打分數的審查：{score: 1-10, issues: [...], corrected_draft: "..."}。每任務成本 $0.12–0.35——研究者消耗約 40% Token、寫作者約 35%、審查者約 25%。
訊息匯流排是 Agent 之間傳遞的簡單 Python dict——不需要框架。每個交接點記錄 {timestamp, from_agent, to_agent, payload_type, token_count}，出問題時就能追蹤每一棒。
除錯 Agent 失敗
Agent 以可預測的方式失敗。三個最常見的故障模式：無限迴圈（一直呼叫工具但從不收斂）、選錯工具（模型選了無關工具、參數也不對）、脈絡溢位（對話紀錄超過模型脈絡視窗、默默丟掉早期訊息）。各有診斷模式。
無限迴圈，把 Agent 的行動記下來看是否重複——同一工具以相同參數連叫三次，Agent 卡住了。介入：注入系統訊息說「你已經用 {args} 呼叫 {tool} 多次。結果沒有變。試別的方法，或回報你目前的進度。」
選錯工具，每個迭代記錄工具名、參數、結果——你會看出模式。一個該呼叫 query_database 卻呼叫 search_web 的 Agent，暴露的是需要重寫的工具描述，不是模型問題。
脈絡溢位，用 API 的 usage 欄位在每個迭代追蹤 total_tokens。Token 超過脈絡上限的 80%——GPT-5.5 是 1M、Claude Opus 是 200K——在下個迭代前摘要最舊的 50% 訊息。最常見的開發者錯誤：一直不檢查 response.usage.total_tokens，直到 Agent 開始產出亂碼，才發現五個迭代前脈絡就被默默截掉了。
結構化日誌是你最有效的單一除錯工具。最低限度，每個迭代記錄：{iteration, model, tool_calls, tokens_used, latency_ms, error}。跑 20 次 Agent 之後，你就有足夠資料判斷哪個故障模式最常咬你。
效能回歸也會立刻看到——一個通常 200ms 的工具呼叫突然要 2 秒，就是變成事故之前的訊號。
哪個模型配哪個 Agent 角色？
| Agent 角色 | 最佳模型 | 原因 |
|---|---|---|
| Orchestrator | GPT-5.5 | 工具使用最可靠、並行工具呼叫最佳 |
| Code Agent | Claude Opus 4.8 | SWE-bench 最高、架構推理最佳 |
| Research Agent | Gemini 3.1 Pro | 2M 脈絡利於文件分析、支援多模態 |
| Cost-Efficient Worker | DeepSeek V4 Pro | 輸出 $0.44/M，HumanEval 達 92% |
| Writer Agent | GPT-5.5 | 散文品質與文體變化最佳 |
聚合平台的優勢：一把 API key 就能存取五款模型。把每個 Agent 角色導到最佳模型。不改 Agent 程式就換模型。編排者、程式 Agent、研究者、工作者都用同一個 OpenAI SDK——只是 model 參數不同。
把不同任務導到不同模型——每個生產 Agent 系統都在用的模式——的更深層架構討論，見單一 App 多 AI 模型指南。
常見問題
我需要 LangChain 這類框架來做 Agent 嗎？
不需要。核心 Agent 迴圈約 50 行 Python——這篇文章的程式碼就是一個完整可用的 Agent。框架加的是便利（預建工具、追蹤、記憶體後端）與複雜度（抽象層、依賴樹、跨版本破壞性變更）。從零（不靠框架）開始。只有在你有具體問題需要它解決時才加框架。一頭跳進 LangChain 的開發者常常後悔——除錯框架的時間比做 Agent 還多。
哪個模型對 Agent 最好？
工具使用可靠度用 GPT-5.5——它在「用對參數呼叫對的工具」上最一致。深度比可靠度重要的複雜多步推理用 Claude Opus。長脈絡任務用 Gemini。成本效率 Agent 用 DeepSeek V4 Pro。多數生產 Agent 系統用 2–3 款模型：可靠的編排者（GPT-5.5）、深度推理專員（Claude Opus）處理複雜步驟、成本效率工作者（DeepSeek）處理大量簡單任務。
怎麼防止 Agent 永遠迴圈？
三道安全裝置。設 max_iterations（多數任務 10–20 合理）。追蹤任務完成——如果 Agent 最後 3 個行動沒產生新資訊，它卡住了；終止並回傳部分結果。每個 Agent 工作階段設預算上限——$0.50 的支出限制能在無限迴圈變成 $50 問題之前抓住它（設定支出上限與速率限制當護欄的方法，見金鑰管理與預算控制指南）。永遠要有逾時＋優雅的備援回應。
AI Agent 運作要多少錢？
簡單 Agent（3–5 次工具呼叫）：DeepSeek V4 Pro 下每任務 $0.05–0.20。複雜多 Agent（10–20 次）：混用模型下每任務 $0.50–2.00。用成本導向路由：簡單任務——便宜模型、複雜任務——旗艦模型。每任務成本應該像其他任何基礎設施成本一樣被測量與最佳化。
上生產前怎麼測 Agent 可靠度？
用 20–50 個手動標記、涵蓋 Agent 預期任務範圍的測試案例建評估台架。每個案例跑 5 次——Agent 行為是非確定性的，單次通過證明不了什麼。量兩個指標：任務完成率（Agent 有產出有效輸出嗎？）與工具選擇準確度（有沒有以正確順序呼叫正確工具？）。
完成率低於 85% 代表你的提示詞或工具描述需要改進。多 Agent 系統加第三個指標：交接正確性——每個 Agent 有沒有從上游 Agent 收到預期的輸入格式？一次壞交接會連鎖成下游失敗。
單 Agent 對多 Agent 系統什麼時候用？
從單 Agent 開始。只有撞到三個門檻之一才加第二個：工具清單超過 8–20 個函式（超過這個數，工具選擇準確度會退化，依 OpenAI 的 function calling 基準）、任務有清楚可分離、需要不同專業的子任務（研究 vs 寫作 vs 審查）、或需要獨立安全驗證（檢查主 Agent 輸出的審查者 Agent）。
過早的多 Agent 架構是 Agent 開發裡最常見的過度工程——為簡單工作流程增加延遲、成本與除錯複雜度，卻沒有等比例好處。
第一步：複製這篇文章的 50 行 Agent 迴圈、換上你自己的工具定義、把 max_iterations 設為 10、對一個非關鍵內部任務——低風險、失敗是學習機會而非事故的那種——部署。看日誌。看它在哪裡卡住。它忘了脈絡就加記憶體。工具清單變難纏就加多 Agent。學會什麼會壞的唯一方法，就是出貨某個東西然後觀察。
上面那個 50 行 Agent 迴圈是可用的起點。當你準備好把每個 Agent 角色配到最佳模型——這篇文章前段的對照表是參考——聚合端點讓你改一個字串參數，就能為每個 Agent 換模型。不需要逐家 SDK、不需要分開的帳務關係。先對低風險內部任務部署迴圈、看日誌、然後從那裡迭代。