打破文字監獄：LLM 工具呼叫（Tool Use）與函式呼叫（Function Calling）的實作與應用

自主 AI 代理的進化之路：打破大腦罐子，賦予 LLM 現實世界的行動力

想像一下這個畫面：你身邊有一個絕頂聰明的天才朋友，他讀遍了世界上所有的書籍、智商高得嚇人，基本上就是一本行走的活字典。你問他任何歷史事件或艱深的科學理論，他都能對答如流。

但是，他被關在一個完全沒有網路、與世隔絕的房間裡。

這意味著他的知識永遠停留在房間門被鎖上的那一天。他無法幫你查今天晚上的即時天氣、沒辦法幫你訂餐廳，他甚至連自己房間裡的電燈開關都按不到。他唯一能做的，就是不斷地跟你說話。這個情境，正是傳統大型語言模型（LLM）最真實的處境。我們常常被 ChatGPT 展現出流暢、博學的對話能力所震撼，但回歸本質，它的知識是靜態的。如果我們沒有在它與外部世界之間建立起橋樑，它解決現實問題的能力就會遇到一道非常硬的瓶頸。而這場演化歷史的關鍵轉捩點，就是工具呼叫（Tool Use / Function Calling）。這項核心技術正在打破文字生成的枷鎖，在那個關著聰明朋友的房間牆上鑿出一個洞，並遞給他一隻連上網的手機、一台計算機，甚至是一把車鑰匙。

一、 機制拆解：文字與程式碼的無縫交接

工具呼叫聽起來很像魔法，但在底層工程設計上，它是一套極其嚴謹的協定。

想像 LLM 是這家餐廳的「明星主廚」。當客人（使用者）點了一杯新鮮蘋果汁，主廚本人是不會親自去切蘋果或按果汁機的。

在廚房（系統）開始運作之前，必須經歷以下三個核心階段：

1. 工具定義（宣告階段）

開發者必須先用 LLM 聽得懂的格式，給主廚一份詳細的「廚房設備清單」。明確告訴它：廚房裡有一台果汁機，名字叫做 blender_tool，它的用途是把水果打成汁，需要帶入的參數是「水果種類」與「攪拌時間」。

2. LLM 決策階段（結構化輸出）

當客人點了蘋果汁，主廚的大腦（推理引擎）開始研判，對照清單後決定：「要完成這個請求，我必須使用 blender_tool」。此時，主廚並不是親自動手，而是寫了一張結構化的電子表單——也就是 JSON 格式的點菜單。這張 JSON 表單會精準標示："tool": "blender_tool", "arguments": {"fruit": "apple", "time": 30}。到目前為止，LLM 所做的依然只是「生成文字」，它根本沒有碰到任何實體系統。

3. 框架執行（二廚接手）

主廚把這張 JSON 單子遞出去後，廚房裡的「二廚」——也就是代理框架（Agent Framework）或編排層會接手。二廚看懂了表單，轉身去啟動真正的果汁機（執行程式碼）。程式碼跑完、果汁打好後（取得執行結果），二廚再把這杯果汁端回主廚面前。最後，主廚看著結果，將其轉化為親切的人類語言對客人說：「新鮮蘋果汁已經準備好了！」

        ① 工具定義              ② LLM 決策              ③ 框架執行
    ┌────────────────┐    ┌────────────────┐    ┌────────────────┐
    │ 開發者描述外部函式 │    │ LLM 判斷需要工具 │    │ 代理框架攔截    │
    │ 名稱、用途、參數  │───→│ 生成結構化 JSON  │───→│ 實際執行程式碼  │
    │ blender_tool    │    │ {"fruit":"apple",│    │ 結果回傳給 LLM │
    │ fruit, time     │    │  "time":30}      │    │                │
    └────────────────┘    └────────────────┘    └────────────────┘
                         LLM 自始至終只做「生成文字」，實際執行由框架完成

這樣的系統為代理（Agent），它扮演一個協調與管理者的角色，完美解決了強大的自然語言推理能力與現實世界龐大外部功能之間的鴻溝。

以下是用 TypeScript 搭配 OpenAI SDK 實作上述三步驟的完整範例：

import OpenAI from 'openai'

const openai = new OpenAI()

// 模擬一個實際執行的天氣工具函數（避免外部 API 呼叫失敗）
async function mockFetchWeather(location: string) {
  return {
    location,
    temperature: 15,
    condition: 'Overcast',
    precipitation: '20%'
  }
}

// 1. 工具定義：告訴 LLM 廚房裡有什麼設備
const tools = [
  {
    type: 'function' as const,
    function: {
      name: 'get_weather',
      description: '取得指定城市的即時天氣',
      parameters: {
        type: 'object',
        properties: {
          location: { type: 'string', description: '城市名稱' },
        },
        required: ['location'],
      },
    },
  },
]

// 2. LLM 決策：生成 JSON 點單
const response = await openai.chat.completions.create({
  model: 'gpt-4o',
  tools,
  messages: [{ role: 'user', content: '倫敦天氣如何？' }],
})

const message = response.choices[0].message
const finishReason = response.choices[0].finish_reason
const toolCall = message.tool_calls?.[0]

// 3. 框架執行：二廚接手，呼叫真正的工具（模擬 API）
if (finishReason === 'tool_calls' && toolCall) {
  const { location } = JSON.parse(toolCall.function.arguments)
  const weatherResult = await mockFetchWeather(location)

  // 將結果回傳給 LLM，讓主廚轉換為人類語言
  const final = await openai.chat.completions.create({
    model: 'gpt-4o',
    messages: [
      { role: 'user', content: '倫敦天氣如何？' },
      // 必須把 LLM 的第一個回應（包含 tool_calls）原封不動帶回上下文
      message, 
      { 
        role: 'tool', 
        tool_call_id: toolCall.id, 
        content: JSON.stringify(weatherResult) 
      },
    ],
  })
  console.log(final.choices[0].message.content)
  // 「倫敦目前多雲，氣溫 15°C，降雨機率 20%。」
}

4. 觀念澄清：Tool Use 廣義 vs. Function Calling 狹義

在深入探討之前，有必要先釐清一組常被混用的關鍵名詞。技術文件與開發社群中，「Function Calling」與「Tool Use」經常交替出現，但它們的範疇並不完全重疊。

• Function Calling（狹義）：專指 LLM 輸出結構化 JSON 以呼叫預先定義好的程式碼函數的行為。它是底層的技術機制，重點在於「模型生成參數 → 系統執行對應函數」這條精確的道路。
• Tool Use / Tool Calling（廣義）：概念遠比 Function Calling 寬泛。一個「工具」可以是傳統的程式函數，也可以是複雜的 API 端點、資料庫查詢、外部服務，甚至是另一個 AI 代理。Tool Use 強調的是代理作為協調者，在數位資源與智慧實體的多樣生態系中發號施令的能力。

區分兩者是因為這直接影響系統架構的設計格局。理解這個區別後就會明白為什麼總結中提到的「代理互相呼叫」並非科幻，而是 Tool Use 廣義概念下的自然延伸。

二、 工具代理的六大超能力場景

                使用者：「幫我安排出差行程」
                        │
        ┌───────────────┼───────────────┐
        │               │               │
        ▼               ▼               ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ ① 讀取API    │ │ ② 網頁檢索   │ │ ③ 計算分析   │
│ 查詢即時股價  │ │ 倫敦天氣物價 │ │ 1500÷股價    │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
       │                │                │
       ▼                ▼                ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ ④ 資料庫互動  │ │ ⑤ 傳送通訊   │ │ ⑥ 控制系統   │
│ 比對可用餘額  │ │ 發送 Email   │ │ 物聯網裝置   │
└──────────────┘ └──────────────┘ └──────────────┘

經驗法則：每當代理需要突破 LLM 內部知識的界限、與外部世界互動時，就應該啟用工具呼叫模式。具體來說，凡是需要即時數據（如天氣、股價）、存取私有或企業內部資訊、執行精確數學計算、執行程式碼腳本，或是觸發真實世界的系統操作（如發送 Email、控制物聯網設備）的任務，都是工具呼叫的典型適用場景。反之，若任務僅涉及常識問答、歸納摘要或風格改寫等純文字生成範疇，則不需要動用工具。

當 LLM 裝備了工具，它在日常與企業場景中便能瞬間解鎖六大超能力。想像你對著 AI 助理說出一段日常工程指令：「幫我查蘋果公司最新股價，算算看如果我花 1500 美金買進，以現在的預算下週去倫敦出差還夠不夠用？順便發封 Email 通知長官我明天開會遲到。」

在幕後，這個代理會同時觸發多重工具呼叫：

1. 讀取結構化 API：呼叫特定服務的 API，取得精準的結構化資料，如金融 API 回傳 JSON 格式的即時股價。
2. 非結構化網頁檢索：透過搜尋引擎或網頁爬取，獲取散落在網路各處的非結構化即時資訊，如倫敦天氣與當地物價。
3. 計算與資料分析（避開幻覺）：大模型本質是機率模型，數學通常很糟糕，容易一本正經地胡說八道（幻覺）。但此時代理不需要自己算數學，它只要把公式封裝成 JSON 丟給計算機工具，讓真正的計算機程式算出精確到小數點後兩位的數字，完美避開幻覺。
4. 與資料庫互動：存取企業內部的財務試算表或資料庫，比對使用者的個人可用餘額。
5. 傳送通訊：確認出差預算無誤後，自動呼叫電子郵件服務，提取主管的聯絡資訊，發送一封語氣得體的信件。
6. 控制系統與物聯網裝置：在授權範圍內，進一步控制實體世界的硬體（如關閉沙盒環境、調整物聯網設備）。

用 Vercel AI SDK 實作這個多重工具呼叫的場景，只需定義工具後讓 LLM 自行調度：

import { openai } from '@ai-sdk/openai'
import { generateText, tool } from 'ai'
import { z } from 'zod'

// 模擬外部工具的實際執行
const fetchStockAPI = async (ticker: string) => ({ ticker, price: 180 })
const sendMail = async (to: string, subject: string) => `Email sent to ${to}`

const result = await generateText({
  model: openai('gpt-4o'),
  tools: {
    getStockPrice: tool({
      description: '查詢股票即時價格',
      parameters: z.object({ ticker: z.string().describe('股票代碼，例如 AAPL') }),
      execute: async ({ ticker }) => fetchStockAPI(ticker),
    }),
    calculateBudget: tool({
      description: '計算預算是否足夠',
      parameters: z.object({ amount: z.number(), budget: z.number() }),
      execute: async ({ amount, budget }) => ({ isEnough: budget >= amount }),
    }),
    sendEmail: tool({
      description: '發送 Email 通知主管',
      parameters: z.object({ to: z.string(), subject: z.string() }),
      execute: async ({ to, subject }) => sendMail(to, subject),
    }),
  },
  prompt: '查 AAPL 股價，計算 1500 USD 夠不夠買，夠的話發信到 manager@company.com 通知主管',
})

// Vercel AI SDK 會自動調度並依序執行完所有需要呼叫的工具
console.log(result.text)

三、 開發框架的碰撞：LangChain 瑞士刀 vs. CrewAI 企業部門

在實作端，開發者如何把這些工具交給代理？開源社群中兩大框架代表了截然不同的設計哲學：

1. LangChain：快捷便利的萬能瑞士刀

LangChain 極強調整合的便利性。開發者可以使用一個簡單的 @tool 裝飾器（Decorator），它就像一張「神奇條碼貼紙」。你本來就有一段普通的 Python 程式碼用來查天氣，只要在程式碼正上方貼上標籤，LangChain 就會瞬間把它轉換成 LLM 能夠理解、並能寫入 JSON 點單的標準化工具。

開發者只要使用內建的 createToolCallingAgent，搭配代理執行器（AgentExecutor），就能把大腦與一整排工具綁在一起，快速誕生一個配備萬能瑞士刀的通用型代理。

import { tool } from '@langchain/core/tools'
import { ChatOpenAI } from '@langchain/openai'
import { ChatPromptTemplate } from '@langchain/core/prompts'
import { createToolCallingAgent } from 'langchain/agents'
import { AgentExecutor } from 'langchain/agents'
import { z } from 'zod'

const getWeather = tool(
  async ({ location }) => {
    // 模擬 API 回傳
    return JSON.stringify({ location, temp: 15, status: 'Cloudy' })
  },
  {
    name: 'get_weather',
    description: '取得指定城市的天氣',
    schema: z.object({ 
      location: z.string().describe('城市名稱，例如 London') 
    }),
  },
)

const llm = new ChatOpenAI({ model: 'gpt-4o', temperature: 0, streaming: false })

// LangChain Tool Calling Agent 強制需要 Prompt Template 且包含 agent_scratchpad
const prompt = ChatPromptTemplate.fromMessages([
  ['system', '你是一個貼心的天氣小助手。'],
  ['placeholder', '{chat_history}'],
  ['human', '{input}'],
  ['placeholder', '{agent_scratchpad}'],
])

const tools = [getWeather]
const agent = createToolCallingAgent({ llm, tools, prompt })
const executor = new AgentExecutor({ agent, tools })

const result = await executor.invoke({ input: '倫敦天氣如何？' })
console.log(result.output)

2. CrewAI：專業分工的企業架構

然而，LangChain 的全能超人模式有一個致命傷：當你貪心地把 100 個工具全部塞給同一個 AI 時，它的上下文視窗會被塞爆。同時閱讀 100 個工具的說明書極易導致 AI 認知過載、混淆，進而亂用工具，產生嚴重的幻覺。

CrewAI 則走向完全不同的哲學——專業分工。它不在於打造一個會 100 種工具的超人，而是組建一個有組織的企業部門。

在 CrewAI 的架構中，開發者會定義一個明確角色為「高階財務分析師」的代理，且只配備給他專屬的股票查詢工具（如 get_stock_data）。這個工具設計得極為細緻，若找不到程式碼，會嚴格引發錯誤訊號（如 ValueError）。分析師代理收到失敗訊號時，不會當機，而是運用 LLM 的推理能力去理解：「哦，我剛剛輸入的股票程式碼可能有錯。」接著自己想辦法修正、換個方式查，展現出極高的系統穩定性。

如果要用 TypeScript 實作「代理互相呼叫」——也就是總結中提到的場景——可以將另一個代理包裝成工具：

// 以下為概念示意，實際 API 依所選框架而定
const researchAnalyst = createAgent({ /* 研究分析師代理 */ })

const seniorAnalyst = createAgent({
  tools: [
    {
      name: 'delegate_to_research',
      description: '將研究任務委派給研究分析師',
      execute: async (task: string) => researchAnalyst.run(task),
    },
  ],
})
// 資深分析師可以視情況把任務丟給研究分析師

這種「代理即工具」的設計模式，正是 Tool Use 廣義概念的最佳體現。

四、 企業級火力展示：Google ADK 的無菌沙盒與自動化安全分水嶺

當我們把目光移向科技巨頭 Google 所打造的企業級解決方案——Google ADK (Agent Development Kit) 時，這套工具生態系展現出了更高維度的基礎設施優化。

1. Google 搜尋工具的內建原生支援

在 Google ADK 中，開發者不需要自己費工串接複雜的第三方 API。系統直接原生內建了 Google 搜尋工具，幾行程式碼就能直接拉入搜尋引擎的即時力量。

2. 安全的無菌室：內建程式碼執行沙盒

為了解決大模型精確計算的痛點，ADK 提供了一個高度安全的隔離沙盒解析器。當代理遇到複雜的資料分析或統計時，它會「自己寫一段程式碼」，然後把程式碼丟進這個與外界完全隔離的無菌沙盒裡去跑，跑出絕對精確的答案後再拿來回覆。這讓 AI 具備了在安全環境下自我打造工具的能力。

3. 帶有出處屬性的 Vertex AI Search

對於極度注重正確性的企業客戶，ADK 的企業搜尋代理可以直接翻找企業私有雲端資料庫。最驚豔的是，它產出的每一個回答，都會嚴格附上資料來源屬性（Attribution）（例如：「我是看了 2025 年 Q4 內部財報的第三頁得出這個結論的」），完美滿足企業的稽核與溯源機制。

技術分水嶺：Vertex AI 擴充功能（Extensions）vs. 函式呼叫（Function Calling）

在企業級應用中，有一個本質上的技術分水嶺，這直接影響了企業對「效率」與「安全控制」的權衡：

• Vertex AI 擴充功能（Extensions）：屬於自動執行模式。因為有企業級安全基礎設施的背書，主廚（LLM）的 JSON 單子一開出來，系統不需要經過人工攔截，機器手臂直接就把程式碼跑完、把菜炒好端出去。這帶來了極致的流暢度與高效能。
• 函式呼叫（Function Calling）：屬於手動/客戶端執行模式。主廚把單子開出來後，系統會暫停，把控制權交回給「餐廳經理」（開發者或主系統）。經理可以先看一眼、確認這項操作安全無虞，才手動放行去執行。

如果這個工具的功能不是查天氣，而是去刷卡扣款五十萬、或者是刪除整個客戶資料庫，全自動化會帶來極大的毀滅性風險。手動執行的函式呼叫，就在不可逆的實體操作觸發前，保留了一個至關重要的「人類確認中斷點（Human-in-the-loop）」。這就像發射飛彈前的最後確認，將核心控制權牢牢鎖在人類手裡。

五、Tool Use 對 UI/UX 的影響

Tool Use / Function Calling 不僅改變了 AI 系統的架構，更從根本上重塑了使用者與應用程式互動的方式。以下從五個層面探討這項技術對 UI/UX 設計帶來的衝擊與啟發。

1. 從 UI 操作到意圖委派的典範轉移

傳統 UI 的互動邏輯是使用者操作介面——點擊按鈕、填寫表單、等待結果。使用者必須理解操作的每個步驟與順序。Tool Use 將互動模式轉向意圖委派：使用者不再需要理解操作細節，只需要描述目標。這讓 UX 從程序導向轉變為意圖導向。

然而這也帶來全新的設計挑戰：當使用者只是說了一句「幫我安排出差行程」，代理可能在背後呼叫了五個以上的工具（查股價、算匯率、比對預算、訂機票、發郵件）。使用者如何知道代理正在做什麼、做到哪一步了？傳統的 loading spinner 完全不夠用。

2. 透明度設計：代理活動饋送（Agent Activity Feed）

解決上述挑戰的關鍵在於透明度設計。UI 需要設計類似終端機或 Slack 訊息流的「代理活動饋送」，逐步顯示代理的思考與行動軌跡：

🤖 正在查詢 AAPL 即時股價...
✅ 股價 $245.30
🤖 正在換算 1,500 USD → TWD...
✅ 約 48,750 TWD
🤖 正在比對出差預算...
✅ 預算足夠
🤖 正在發送郵件...
✅ 已寄出至 manager@company.com

這種逐步揭露的設計讓使用者在每個環節都保持知情，即使代理在背後經歷了失敗與重試（例如查不到股票代碼 → 自動猜測正確代碼 → 重新查詢），使用者看到的是一段代理展現問題解決能力的流暢過程，而非令人困惑的錯誤訊息。

3. 風險分級與確認機制

文章第四章提到的 Extensions（自動執行）與 Function Calling（手動執行）的技術分水嶺，直接對應到 UI 上的確認機制設計。不同的工具根據其風險等級，需要不同的互動模式：

這就像發射飛彈前的那個「你確定嗎？」對話框——只是現在設計的不是一個對話框，而是一整套根據工具權重動態變化的確認流程。系統需要能夠判斷每次工具呼叫的風險等級，並自動選擇對應的 UI 模式。

4. 錯誤恢復與容錯體驗

工具呼叫不可能永遠成功——API 可能掛掉、資料庫可能連不上、參數格式可能錯誤。傳統 UI 的典型做法是顯示一個錯誤訊息，然後要使用者自己想辦法。但在代理模式下，UI 可以讓代理自動嘗試修復，並將修復過程可視化：

• 代理嘗試 A 方法 → 失敗（UI 顯示灰色狀態）
• 代理自動切換 B 方法 → 成功（UI 顯示綠色狀態）
• 最終結果回報給使用者

這讓錯誤體驗從令人挫折的「死路」，轉變為代理展現解決問題能力的過程，甚至能夠建立使用者對系統的信任感。

5. 可逆性與責任歸屬的 UX 設計

總結中提到的代理責任歸屬問題，UI/UX 的回應是可逆性設計與稽核軌跡：

• 操作回溯：每項工具呼叫都應該有 audit log，讓使用者可以回溯「代理做了什麼、用了什麼資料、誰授權的」
• Undo / Rollback 機制：例如「代理剛剛寄了一封信 → 提供撤回按鈕」或「代理修改了資料 → 提供一鍵還原」
• 呼叫鏈視覺化：顯示完整的代理協作鏈「你 → 代理 A → 代理 B → 代理 C → 執行結果」，類似 Git 的 commit graph

這些設計不僅提升了使用者對 AI 系統的信任感，更在責任歸屬尚有法律爭議的今日，提供了務實的透明度解決方案。

六、Tool Use 對 UI 實作的技術挑戰

Tool Use 不僅影響 UX 設計，也為前端的實際開發帶來了幾個具體的技術挑戰：

1. 元件作為工具（Component as Tool）

UI 元件本身可以被包裝成工具給 LLM 呼叫。例如一個 showChart 工具，LLM 決定何時要畫圖、傳什麼資料進去。這意味著前端需要有一套工具註冊機制，讓元件暴露為 LLM 可呼叫的函式，且每個工具都要有明確的 schema 定義（參數型別、回傳值）：

const chartTool = tool({
  description: '繪製股價趨勢圖',
  parameters: z.object({
    ticker: z.string().describe('股票代碼'),
    period: z.enum(['1d', '1w', '1m', '1y']).describe('時間區間'),
  }),
  execute: async ({ ticker, period }) => {
    // 回傳結構化資料，由前端對應的 ChartComponent 渲染
    return { ticker, period, data: await fetchChartData(ticker, period) }
  },
})

2. 多步驟狀態管理

代理一次可能呼叫三五個工具，每個都有獨立生命週期（pending → loading → success / error）。UI 不能再只用一個 isLoading boolean 搞定，需要類似 multi-step state machine 的設計：

type ToolCallState = {
  id: string
  toolName: string
  status: 'idle' | 'running' | 'success' | 'error'
  args: unknown
  result?: unknown
  error?: Error
}

type AgentSession = {
  steps: ToolCallState[]
  finalOutput: string | null
}

每個 ToolCallState 對應 UI 上的一個步驟卡片，獨立控制自己的載入、完成或失敗狀態。

3. Streaming + Tool Call 交錯渲染

LLM 可以同時生成文字和觸發工具呼叫，且可能交錯發生——講一句話 → 呼叫工具 → 拿到結果 → 再講下一句。前端要能處理這種非線性的串流渲染。Vercel AI SDK 的 useChat 已支援 tool_calls 與 tool_results 的掛鉤，但實作上要注意每個 tool call 之間 UI 的連續性，避免畫面閃爍或順序錯亂：

const { messages } = useChat({
  onToolCall: ({ toolCall }) => {
    // 在 tool call 開始時，UI 立即顯示一個「正在執行⋯」的卡片
    addStep({ id: toolCall.id, toolName: toolCall.name, status: 'running' })
  },
  onToolResult: ({ toolCall, result }) => {
    // 拿到結果後，更新對應卡片的狀態與內容
    updateStep(toolCall.id, { status: 'success', result })
  },
})

4. 取消與競態條件

當使用者發出新指令時，前一批工具呼叫可能還在進行中。這需要 AbortController 鏈——不只是取消 LLM 的請求，還要連帶取消所有正在執行的工具（如已發出的 API 請求）。如果沒處理好，可能會出現舊結果覆蓋新畫面的競態條件：

const abortController = new AbortController()

async function executeAgent(prompt: string) {
  // 取消前一批所有進行中的工具呼叫
  abortController.abort()
  const newController = new AbortController()
  // 將 signal 傳遞給所有工具執行函式
  const result = await runAgent(prompt, { signal: newController.signal })
}

5. 工具回傳值的 UI 繫結

工具回傳的 raw JSON（如股價 { price: 245.30 }）需要對應的 UI 元件來渲染。這裡有兩種實作路線：

• 約定式繫結：約定工具名稱與元件名稱一一對應（getStockPrice → <StockPriceCard />），由一個 Router Component 根據工具名稱自動選擇渲染元件。
• 宣告式繫結：工具定義時就直接指定 UI 元件，LLM 回傳的結果自動傳入對應的 component props。這更有彈性，但需要更完善的元件註冊機制。

const tools = {
  getStockPrice: tool({
    description: '查詢股票即時價格',
    parameters: z.object({ ticker: z.string() }),
    execute: async ({ ticker }) => fetchStock(ticker),
    // 宣告式繫結：指定結果給哪個 UI 元件渲染
    uiComponent: 'StockPriceCard',
  }),
}

這些技術挑戰的核心都在於：UI 不再只是資料的展示層，而必須成為代理與使用者之間的即時協調層。從被動顯示資料，轉變為主動管理非同步工具呼叫的生命週期。

總結：當代理開始互相發號施令

工具呼叫，就是那把將 AI 從與世隔絕的圖書館學者，變成現實世界超級行動者的關鍵鑰匙。下次看到手機裡的 AI 代理完美規劃好出差行程、查好即時匯率並發出確認信時，我們將知道這背後不是魔法，而是結構嚴謹、在幕後高速飛奔的 JSON 點菜單。然而，這項技術也將我們推向了一個更深層的未來課題：在先進的設計模式中，工具的定義甚至包含了「去呼叫另一個 AI 代理」。當任務過於複雜時，代理 A 可以把代理 B 當成工具呼叫；代理 B 為了查資料，又跑去呼叫了代理 C，這張網絡會愈織愈大。如果有一天，代理 C 在執行過程中因為某個工具的邊緣錯誤，執行了一筆錯誤的金融交易導致嚴重虧損。在這一層又一層、宛如黑盒子般複雜的代理協作網路中，我們到底該追究誰的責任？是寫下最初那句模糊指令的使用者？是寫出底層工具程式碼的開發者？還是這條決策鏈上的某個 AI 節點？當 AI 代理開始互相發號施令，人類的責任歸屬，將是我們在享受高度自動化之餘，下一個必須共同面對的最大挑戰。

參考資料

• 第5章：工具調用(函式呼叫)