上一篇我們用 RAG(第 518 篇)解決了模型「不知道」的問題——讓它讀懂你的私有知識庫。但你很快就會撞上下 一個天花板:模型再聰明,也只能「動嘴」,不能「動手」。它沒辦法幫你查匯率、讀資料庫、開一張工單。這一篇,我們就把大模型從「聊天機器人」升級成「會做事的 Agent」。
一、LLM 和 AI Agent 差在哪?
打個比方:你問 LLM「怎麼去機場」,它會給你一份完美的路線攻略;但 AI Agent 像你自己叫的計程車——你只說目標「去機場」,司機自己導航、繞路、找停車位,最後把你送到目的地。LLM 負責回答問題,AI Agent 負責完成任務。
- LLM(單輪對話):你問 → 它答 → 結束。答案好不好,全看它腦內的知識。
- AI Agent(任務迴圈):給目標 → 模型規劃 → 呼叫工具行動 → 觀察結果 → 決定下一步 → 直到任務完成。
這個「規劃 → 行動 → 觀察」的循環,就是 Agent 的靈魂,學術上有個名字叫 ReAct(Reasoning + Acting)。
二、核心零件:Function Calling(工具呼叫)
很多人以為模型會「執行」函數,其實不然。模型只會說:「我想呼叫 get_exchange_rate,參數是 USD 和 HKD」——真正動手執行的,是你的程式碼。你把執行結果回傳給模型,它再決定下一步,這就是 Function Calling 的全部真相。
整個流程只有四步:
- 你定義一份工具清單(名稱 + 參數 JSON Schema),隨每次請求發給模型;
- 模型判斷需要外部資料時,回傳 tool_calls 而不是普通文字;
- 你的程式碼執行對應的本地函數,把結果塞回對話訊息;
- 模型拿到結果後繼續推理,直到它認為任務完成,才輸出最終答案。
三、動手實戰:寫一個最小可用 Agent
步驟 1:定義工具(以 OpenAI 相容格式為例)。
const tools = [
{
type: "function",
function: {
name: "get_portfolio",
description: "查詢使用者投資組合的持倉與損益",
parameters: {
type: "object",
properties: {
ticker: { type: "string", description: "股票代碼,如 2800.HK" }
},
required: ["ticker"]
}
}
}
];步驟 2:寫本地執行器,真正的「髒活」都在這一層。
function executeTool(name, args) {
if (name === "get_portfolio") {
return db.query(
"SELECT * FROM holdings WHERE ticker = ?", [args.ticker]
);
}
throw new Error("unknown tool: " + name);
}步驟 3:Agent 迴圈——本體其實只有一個 while。
async function runAgent(userGoal) {
const messages = [{ role: "user", content: userGoal }];
for (let i = 0; i < 10; i++) { // 硬性設上限,防止無限循環
const res = await llm.chat({ messages, tools });
const msg = res.choices[0].message;
messages.push(msg);
if (!msg.tool_calls) return msg.content; // 模型表示:任務完成
for (const call of msg.tool_calls) {
const result = executeTool(
call.function.name,
JSON.parse(call.function.arguments)
);
messages.push({
role: "tool",
tool_call_id: call.id,
content: JSON.stringify(result)
});
}
}
return "任務未在限定步數內完成";
}重點:Agent 不是新模型、也不是新 API,就是「迴圈 + 工具」這個架構模式。你已經會的 chat completions,加上一個 while 迴圈,就是一個 Agent 的最小骨架。
四、讓 Agent 可靠的三個工程細節
- 工具描述是第一生產力:description 寫得糊塗,模型就會亂叫工具。要用使用者的語言寫清楚「這個工具做什麼、什麼時候該用、什麼時候不該用」。
- 最小權限原則:查詢類工具可以隨便給;刪除、下單、付款這類「不可逆」操作,必須加人工二次確認——跟我們做後台管理系統的刪除功能是一個道理。
- 可觀測性:把每一輪的 tool_calls 和執行結果都寫進日誌。Agent 出錯不是崩潰,而是「優雅地走錯路」,沒有日誌你根本不知道它錯在哪一步(思路可以接上前面前端監控那一篇)。
特別注意:成本會隨迴圈放大。每一輪都要把完整對話歷史重發一次,Agent 跑十輪的 token 消耗可能是普通對話的十倍以上,記得控制上下文長度、及時裁剪舊的工具結果。
五、前端工程師的 Agent 落地場景
- 智慧客服:接上工單系統的查詢/建立工具,讓 Agent 自己查進度、開工單、回覆使用者;
- 資料問答:接一個只讀的 SQL 查詢工具,讓業務同學用自然語言就能拉報表;
- 開發助理:接 codebase 檢索 + 測試執行工具,讓 Agent 自己跑測試、讀報錯、改程式碼。
回顧這個系列的三塊積木:第 511 篇學會「接模型」、第 518 篇學會「餵知識」、這一篇學會「給工具」——三塊拼完,你已經具備做出生產級 AI 應用的全部基礎了。
互動話題:你第一個想讓 Agent 自動化的任務是什麼?每天整理資訊、跑測試,還是幫忙盯資料?留言聊聊,我會挑幾個場景在下篇展開實作!