Gary
Hsieh
2026 · taipeiloading
回到文章列表
軟體工程AI 趨勢2026-05-18

Agent 的手跟腳 / Tools，要怎麼裝到沒有狀態的 LLM 身上？

Agent 的手跟腳 / Tools，要怎麼裝到沒有狀態的 LLM 身上？

Agent 的手跟腳 / Tools，要怎麼裝到沒有狀態的 LLM 身上？從這兩個簡單的點切入：

  • 工具清冊（tool schema）＋ 工具程式碼（tool executor），或是改用機率性觸發的 TOOLS.md
  • 架構在無狀態 LLM 上的 agentic loop 的 tool use pattern

LLM 本質就是文字接龍——它沒有手也沒有腳。它能讀檔嗎？不能。能上網嗎？不能。能跑腳本嗎？更不能。它只會輸出字。

那為什麼 Claude Code 可以寫 Code、ChatGPT 可以幫你查天氣、Gemini 可以幫你搜尋網頁？因為大家在它後面裝了工具 (Tool)。

Tool 是 Agent 的關鍵零件

Tool 就是 Agent 的手跟腳。沒有 Tool，LLM 永遠是文字接龍——它再會推理、再會規劃，結論也只能輸出成文字，不會「發生」任何事。有了 tool，它才開始「行動」。

嘿嘿～所以賽博龐克成真那天，先砍斷 Tool 就對了 😎😎😎。

Anthropic 在《Building Effective Agents》部落格上介紹得很清楚：

"Agents can handle sophisticated tasks, but their implementation is often straightforward. They are typically just LLMs using tools based on environmental feedback in a loop. It is therefore crucial to design toolsets and their documentation clearly and thoughtfully."

翻成中文：agent 的核心架構其實就這三個東西——environment、tools、prompt，然後在一個 loop 裡跑。

而整個 agent design pattern，最早的學術原型是 2022 年的《ReAct: Synergizing Reasoning and Acting in Language Models》（Yao et al., arXiv:2210.03629）——把「推理」跟「行動」交錯起來，讓 LLM 一邊想一邊用工具。這就是現在所有 agent loop 的雛形。

協議只有兩件事：工具清單 ＋ 工具程式碼

實際上 Tool 怎麼安裝？沒有想像中神秘，就兩件事：

  • Schema — 一份 JSON，就是「工具清單」，告訴 LLM「你有這些能力，長這樣呼叫」
  • Executor — 真正的「工具程式碼」，跑在你的 process／harness 裡執行

LLM 只看到清單，看不到工具程式碼。LLM 供應商通常不會幫你執行你自己定義的工具程式碼——它只負責讀清單、決定點哪一個、把點單吐回給你，真正的執行跑在我們的 application／harness。

不過 LLM 供應商也有提供遠端的執行工具，像 Anthropic 跟 OpenAI 都提供 server-side tools（web search、code execution、web fetch），這類是直接在他們 infrastructure 跑，我們拿到的是執行完的結果。

Tool Use Pattern 整個脈絡長這樣

以 Anthropic 為例，

  1. messages 跟 tool schema 平行送進 API（schema 不在 messages 裡，是頂層參數）
  2. LLM 回 stop_reason = "tool_use"（OpenAI 是 finish_reason = "tool_calls"），加上要呼叫的 tool 名字、參數、跟一個 unique ID
  3. 本地端的 agentic loop 看到 tool_use，就跑對應的 executor
  4. 把結果包成 tool_result（配對同一個 ID）塞回 messages
  5. 再 call 一次 API，LLM 看到結果繼續推理
  6. 直到 stop_reason 變成 end_turn — 結束

為什麼無狀態的 LLM 可以持續使用工具？

第一，schema 跟 messages 是平行送的，不要塞進 messages 裡。Anthropic 後端會把它編譯成一段「特殊 system prompt」注入模型 context——這也意味著 schema 寫得越冗長越吃 token。

第二，tool_use.id ↔ tool_result.tool_use_id 必須配對。一個 turn 可能同時 fire 多個 tool_use（parallel tool use），下一輪要全部回應，缺一個整個流程就停掉。

每次 API call 都是 stateless，模型本身沒有記憶。真正讓「記得」這件事成立的，是 harness 每一輪把前面的 messages、tool_use、tool_result 全部重新組裝送回去。ID 配對則是這個重組過程裡的信號線——確保哪個 tool_result 對應哪個 tool_use，不會亂掉。模型看到完整重組的 history，就像「記得剛剛做了什麼」一樣。

Tool Schema 實務上怎麼寫得好

可以參考 Anthropic《Writing effective tools for agents — with agents》。挑幾個 best practice：

  • 加上 Namespace — slack_search_messages，不只是單一字串 search
  • 在 Description 欄位寫清楚使用時機 — LLM 要的是 decision criteria，不是 API doc
  • 設計 Enum — 讓無效狀態不可被表達
  • 參數名稱要描述清楚 — user_id 不是 user
  • Return 要結構化、人類可讀 — 不要無腦丟原始資料回去
  • 要簡單到小學生都看得懂（這有點太誇張了...應該路人都看得懂就好 😂）

Tool Executor 設計方式與四種 Runtime

Tool Executor 實務上就跟系統架構、寫程式都一樣，怎麼設計系統，就怎麼設計 Tool Executor，所有的 programming best practice 都可以套用上。這層 LLM 完全看不到，但對設計來說，選哪一種決定了隔離邊界、錯誤處理、延遲：

  • 同 process 函式 — 最常見的 demo 寫法，Python 直接 def read_file(path):
  • 子 process — bash tool 就是這種，fork 一個 subprocess 跑指令
  • 跨網路 RPC — MCP tool 走這條，executor 跑在另一台 server
  • 另一個 agent — agent-as-tool，executor 內部又是一個 LLM loop

👉 四種方式對 LLM 都是隱形的，它只看到 schema ＋ result。

最容易搞混的：TOOLS.md vs Tool Schema

TOOLS.md 是這一兩年現代 agent 系統蠻常見的設計慣例——把 system prompt 拆出一塊專門講「你手上這幾個 tool 在實務上可以怎麼組合用」。OpenClaw 用它描述 bash ＋ CLI 的組合用法，GitAgent 用它把 persona、memory 操作流程寫成可版本化的文件，在 system prompt level 做 agent 行為的拆解。

👉👉👉 這就是我最早卡住的地方，我分不清楚 Tool Schema 跟 TOOLS.md 的關係！！！👈👈👈

Tool Schema 是 protocol-level 的能力註冊——寫進 API 的 "tools" 欄位，模型在這個 request 的 context 裡一定看得到、能用結構化格式呼叫，粒度細。TOOLS.md（常見的命名還有 CLAUDE.md、AGENTS.md）是 prompt-level 的工具操作手冊——它放在 system prompt 裡，是一份「軟式提示」，告訴 LLM「我手上的 tool 在實務上可以這樣那樣用」。這就是簡單的告訴 LLM 我們電腦上的某個工具「可以用」的途徑。

最近一次我把股票的庫存截取工具搭配券商給的 API key 一起打包成一個指令，我就可以簡單透過修改 TOOLS.md / AGENTS.md 讓 OpenClaw 龍蝦去用這個工具。OpenClaw 的設計核心是讓 bash ＋ CLI 組合成為主要擴展路徑，TOOLS.md 描述工具怎麼組合使用，實際能力邊界靠系統上安裝什麼 ＋ bash exec policy 來決定。

LLM 真的只是「參考」，用不用、用得對不對，是模型行為問題。Schema 讓模型「有這個工具可以結構化呼叫」，TOOLS.md 告訴模型「實務上應該怎麼用」、怎麼「舉一反三」。

Tool Use Pattern 開發工具 - 自己刻 Agent Loop 還是用 SDK？

了解 Agent Loop、Tool Use Pattern 設計，在這框架下，我們有什麼開發工具可以用？

OpenAI 2023 年 6 月的《Function calling and other API updates》把 Function calling 格式定下來，後來 Anthropic 跟 Gemini 跟進，協議本身大同小異。差異在協議之上各家疊了什麼「便利層」：

  • OpenAI — 什麼都沒幫你做，要什麼自己寫
  • Claude Agent SDK — Read、Write、Edit、Bash、Glob、Grep、WebSearch 等 built-in tool 一鍵就有，custom tool ／ MCP ／ hooks 也可以加掛，還有 CLAUDE.md ／ Skills ／ subagents 整套架構
  • OpenClaw — 設計核心是讓 bash ＋ CLI 組合成為主要擴展路徑，TOOLS.md 描述工具怎麼組合使用，實際工具邊界靠 OS 安裝什麼 ＋ bash exec policy 來決定

如果想要 cross-provider？可以用 LiteLLM 包一層，同一份 schema 跑三家，但是就要自己維護 Agent Loop。

2024 年 11 月 Anthropic 又丟出《Model Context Protocol》（MCP）——讓 tool 可以跨 process、動態註冊，executor 跑在另一台 server 上，agent 動態發現。

四個 Tool Use 設計決策，設計 Agent 前先想清楚

  1. 你要 deterministic 還是 probabilistic 的 tool？

    • 走 tool schema ＋ executor → deterministic，控制力佳，適合關鍵動作
    • 走 TOOLS.md 描述 → probabilistic，擴展性大、實作輕，適合 bash ＋ CLI 組合

  2. Tool schema 清冊怎麼設計？

    • 自己抽 provider 層 — 查每家模型供應商的 tool schema 規格，通常是 JSON 格式，但欄位名稱、包裝層數各家不一樣
    • 用 LiteLLM 統一抽象 — 同一份 schema 直接跑在不同模型供應商上

  3. Executor 跑哪個 runtime？

    • 同 process ／ subprocess ／ RPC ／ sub-agent — 看隔離需求跟延遲容忍度
    • production-level 要考慮 idempotency ＋ timeout ＋ checkpoint

  4. 自己刻 Agent Loop 還是用 SDK？

    • 要極致控制 → 自己 loop（但要處理 retry ／ streaming ／ cache ／ parallel tool 一堆 edge case）
    • 要快速出貨 → Claude Agent SDK
    • 要 cross-provider → LiteLLM

Tool Use 整理起來很單純——工具清單 ＋ 工具程式碼 ＋ 一條 ID（deterministic）搭配 TOOLS.md（probabilistic），全部架構在 agentic loop 上。但圍繞這個設計的選擇很多——Schema 設計、Executor Runtime、TOOLS.md 設計、IPC 是否導入、SDK 選用、手刻 + liteLLM、工具邊界——每一個都在決定 Agent 長出什麼樣的「手跟腳」。

#AI#Agent#LLM#Claude Code#Claude