AI-LECTURER 速報課|2026-07-25|約 26 分鐘

Claude 官方食譜大公開:讓 AI 自己寫程式碼呼叫工具,工具再多也不塞爆對話

取材:Claude Cookbook(Hacker News(AI 高人氣))
📍 真實場景
獨立接案工程師阿凱,正在幫客戶做一個要操作兩百多支內部系統工具的 AI 客服機器人

他讓 Claude 串接客戶公司裡的請假系統、報帳系統、客戶名單查詢等好幾百支工具,想做出一個什麼都能問、什麼都能辦的 AI 助理

😖 卡住的地方:工具一多,Claude 每次回答前都要先把一堆工具說明塞進對話裡,回應變慢、帳單爆炸,還常常選錯工具,或是一件事要來回好幾輪對話才辦完
💡 這課會教他 Anthropic 官方食譜書裡的兩招真功夫:讓 Claude『寫程式碼』一次串好幾支工具、少來幾輪對話;還有用『語意搜尋』讓 Claude 自己從幾千支工具裡找到對的那幾支,不用全部塞進提示詞

🧭 這到底是什麼(白話版)

「Claude Cookbook」是 Anthropic 官方自己整理的一本『食譜書』,裡面收錄了他們實際測試過、真的有效的開發技巧,不是隨便寫寫的入門教學。這次上熱門的重點,是教開發者怎麼解決一個很實際的麻煩:當你想讓 Claude(一款AI)幫你操作很多不同系統的功能,也就是常說的工具呼叫讓AI不只回答文字,還能實際去操作外部系統,例如查資料庫、送出表單、開機器手臂,工具一多,AI 就開始變笨重、變貴、變慢。

第一招叫『程式化工具呼叫』(Programmatic Tool Calling,簡稱 PTC)。以前的做法是:AI 每次只能決定呼叫『一支』工具,呼叫完要把結果傳回去,AI 才能決定下一步該呼叫哪一支,像接力賽一樣一棒接一棒、每一棒都要停下來交接。PTC 讓 Claude 直接『寫一段程式碼』,程式碼裡可以連續呼叫好幾支工具、自己做判斷、自己整理資料,整段丟進一個程式碼執行環境一個讓AI寫的程式碼可以真的被執行、跑出結果的隔離小房間,AI寫完程式碼馬上能看到執行結果裡跑一次就好,不用一直來回交接,省下時間也省下權杖AI處理文字的最小計價單位,白話講就是AI界的字數計費單位,用越多字通常花越多錢、跑越慢

第二招叫『用嵌入搜尋找工具』。如果一個 AI 系統串接了成千上萬支工具(大公司內部系統真的可能這麼多),沒辦法每次都把全部工具的說明塞進對話裡——那樣上下文AI這次對話記得的所有內容,包括你打的字、AI回的字、還有它讀過的工具說明會直接爆掉。解法是先用語意搜尋不是比對關鍵字,而是讓電腦理解意思相近的東西,例如你打怎麼退貨也能找到寫著退款流程的說明,只挑出跟這次任務最相關的幾支工具說明,才交給 Claude。

食譜書裡還有其他幾招:長時間掛著跑的 AI 任務,系統會自動幫對話『瘦身』(context compaction);分析圖表或文件時,給 Claude 一支『裁圖工具』讓它自己放大看細節;還有怎麼下指令讓 Claude 做出來的網頁設計不要千篇一律。這些都是 Anthropic 自己內部驗證過、開發者可以直接抄的實戰做法,不是空泛的『AI 概念課』。

🎯 為什麼值得你花時間

工具一多,AI 系統就會『卡住』很多真實系統要串接的不是一兩支工具,是幾十到幾千支(想想一間大公司的請假、報帳、客服、倉儲系統全部加起來)。如果每次對話都要把所有工具說明念一遍給 AI 聽,上下文AI這次對話記得的所有內容,包括你打的字、AI回的字、還有它讀過的工具說明會被塞爆,AI 也更容易選錯工具。這篇食譜直接示範怎麼解決,這是很多想用 AI 做企業內部助理的人一定會撞到的牆。
AI 開發正在從『一問一答』走向『自己寫劇本』PTC 代表一個轉變:以前是你設計好每一步該呼叫哪支工具、AI 只能『選』;現在是 AI 自己寫出一整段邏輯完整的程式碼,決定要做哪些步驟、用什麼順序。這代表 AI 開始承擔更多『怎麼把任務拆解、串起來』的工作,而不只是回答問題。
這是官方親自下海整理的『能落地』做法,不是道聽塗說這份食譜是 Anthropic 自己整理、自己測過的技巧集合,會隨時間持續更新最新的最佳實務。跟坊間很多『聽說 AI 要這樣用』的二手心得不一樣,這是原廠第一手的施工手冊,開發者可以直接照著抄,風險比較低。

⚙️ 它是怎麼運作的

1
先準備好一堆『工具』開發者要先幫每一項功能寫好說明書,例如『查詢庫存』『送出報帳單』,這就是工具呼叫讓AI不只回答文字,還能實際去操作外部系統,例如查資料庫、送出表單、開機器手臂要先做的準備工作,就像先把家裡每一支遙控器都貼好標籤。
2
工具太多的話,先做一次『語意篩選』如果工具庫有幾千支,系統會先用語意搜尋不是比對關鍵字,而是讓電腦理解意思相近的東西,例如你打怎麼退貨也能找到寫著退款流程的說明技術,把使用者這次的需求拿去跟所有工具說明「比像不像」,只留下最相關的幾支交給 Claude,而不是全部塞過去。
3
Claude 不是『選一支工具』,是『寫一段程式碼』拿到篩選過的工具後,Claude 直接寫出一段程式碼,裡面依序呼叫好幾支工具、做條件判斷、把結果組合起來——這就是程式化工具呼叫(PTC)跟以前『一次只能呼叫一支』最大的不同。
4
程式碼丟進隔離小房間裡真的執行這段 Claude 自己寫的程式碼,會被放進程式碼執行環境一個讓AI寫的程式碼可以真的被執行、跑出結果的隔離小房間,AI寫完程式碼馬上能看到執行結果裡實際跑一次,跑出來的結果 Claude 自己看得到,可以馬上判斷要不要再修正。
5
一次把整理好的結果回傳,不必來回好幾輪傳統做法裡,AI 每呼叫一支工具就要停下來等你把結果傳回去,一個任務常常要來回四五輪對話。PTC 把這些步驟包進同一段程式碼一次跑完,省下的來回次數直接反映在回應速度跟權杖AI處理文字的最小計價單位,白話講就是AI界的字數計費單位,用越多字通常花越多錢、跑越慢花費上。
傳統『一次呼叫一支工具』 vs. 程式化工具呼叫(PTC)
比較項目傳統工具呼叫程式化工具呼叫(PTC)
每一步怎麼決定AI 每次只能決定呼叫『一支』工具,呼叫完要等結果回來才能決定下一步AI 一次寫出一整段程式碼,裡面可以連續呼叫好幾支工具、自己做判斷
對話要來回幾輪工具串越多步驟,對話來回的輪數越多常常一輪就能把多步驟的任務做完
速度與費用每一輪都要重新讀一次完整上下文,延遲跟權杖花費會一直疊加省下中間反覆的來回,延遲跟花費明顯降低

🔍 程式碼漫遊(點有 ● 的行看白話講解)

這段程式在幹嘛:模擬公司裡有 10 支工具(真實情況可能有幾千支),先用陽春版的『語意搜尋』從裡面篩出跟使用者問題最相關的 3 支,再把這 3 支交給 Claude 決定要呼叫哪一支,而不是把全部工具塞給它。

def text_to_vector(text):
💬 這個函式是整套『語意搜尋』的地基——負責把一段文字變成電腦看得懂的一串數字。
bigrams = [text[i:i + 2] for i in range(len(text) - 1)]
💬 把句子切成一對一對相鄰的字,這是最簡化版的嵌入向量把一段文字轉換成一串數字,讓電腦可以用數學距離判斷兩段文字意思像不像做法,正式產品會換成訓練過的模型(例如 Anthropic 常建議搭配的 Voyage AI)。
def cosine_similarity(vec_a, vec_b):
💬 算出兩個向量『指向的方向』有多接近,方向越接近,代表兩段文字的意思越像。
def find_relevant_tools(user_query, top_k=3):
💬 這就是語意搜尋不是比對關鍵字,而是讓電腦理解意思相近的東西,例如你打怎麼退貨也能找到寫著退款流程的說明的關鍵:把使用者的問題拿去跟工具庫裡每一支工具的說明『比像不像』,只留下最像的幾支。
scored.sort(key=lambda pair: pair[0], reverse=True)
💬 依相似度由高到低排序,等一下只挑分數最高的前幾名。
tools=[to_claude_tool_schema(tool) for tool in relevant_tools],
💬 重點在這裡:丟給 Claude 的 tools 清單只有篩選過的 3 支,不是原本的 10 支(實務上可能是從幾千支篩到幾十支)——這樣上下文AI這次對話記得的所有內容,包括你打的字、AI回的字、還有它讀過的工具說明才不會被工具說明塞爆。
elif block.type == "tool_use":
💬 當 Claude 判斷『這件事要靠工具解決』,它不會直接亂回答,而是回傳一個 tool_use 區塊,告訴你它想呼叫哪支工具、帶什麼參數。

🛠️ 動手做:打造一支會『先篩工具、再交給 Claude』的迷你助理

這是一個真實小專案:下載(或複製)檔案,照步驟在你電腦上跑起來。

📄 smart_tool_picker.py ⬇ 下載
"""
smart_tool_picker.py
教學示範:當公司裡的工具多到爆炸(想像 200 支工具),
怎麼用「語意搜尋」先篩出跟使用者需求最相關的幾支工具,
再交給 Claude 決定要呼叫哪一支,而不是把 200 支工具說明全部塞進提示詞。

執行前準備:
  1. pip install anthropic
  2. 設定環境變數 ANTHROPIC_API_KEY(去 Anthropic Console 申請)
"""

import math
import os
from collections import Counter

import anthropic

# 模擬公司裡「多到爆炸」的工具清單(實務上可能有幾百到幾千支)
TOOL_LIBRARY = [
    {"name": "query_leave_balance", "description": "查詢員工目前剩餘的特休天數"},
    {"name": "submit_leave_request", "description": "送出請假申請,需要開始日期、結束日期、假別"},
    {"name": "query_expense_status", "description": "查詢一筆報帳單目前審核到哪個階段"},
    {"name": "submit_expense_report", "description": "送出新的報帳單,附上金額與收據描述"},
    {"name": "search_customer_profile", "description": "用客戶姓名或編號查詢客戶基本資料"},
    {"name": "query_order_status", "description": "查詢一筆訂單目前的出貨進度"},
    {"name": "book_meeting_room", "description": "預約會議室,需要日期、時段、人數"},
    {"name": "query_payroll_date", "description": "查詢這個月薪水什麼時候會入帳"},
    {"name": "reset_employee_password", "description": "重設員工的內部系統登入密碼"},
    {"name": "query_warehouse_stock", "description": "查詢某項商品在倉庫的目前庫存數量"},
]


def text_to_vector(text):
    """把一段文字轉成「字元二連字」的出現次數向量,
    這是最陽春版的語意搜尋:用重疊的字元組合,粗略估計兩段文字像不像。
    正式產品通常會改用像 Voyage AI 這種訓練過的嵌入模型,準確度高很多。"""
    text = text.replace(" ", "")
    bigrams = [text[i:i + 2] for i in range(len(text) - 1)]
    return Counter(bigrams)


def cosine_similarity(vec_a, vec_b):
    common = set(vec_a) & set(vec_b)
    dot = sum(vec_a[k] * vec_b[k] for k in common)
    norm_a = math.sqrt(sum(v * v for v in vec_a.values()))
    norm_b = math.sqrt(sum(v * v for v in vec_b.values()))
    if norm_a == 0 or norm_b == 0:
        return 0.0
    return dot / (norm_a * norm_b)


def find_relevant_tools(user_query, top_k=3):
    """從整個工具庫裡,只挑出跟使用者需求最相關的 top_k 支工具。"""
    query_vec = text_to_vector(user_query)
    scored = []
    for tool in TOOL_LIBRARY:
        tool_vec = text_to_vector(tool["description"])
        score = cosine_similarity(query_vec, tool_vec)
        scored.append((score, tool))
    scored.sort(key=lambda pair: pair[0], reverse=True)
    return [tool for score, tool in scored[:top_k]]


def to_claude_tool_schema(tool):
    return {
        "name": tool["name"],
        "description": tool["description"],
        "input_schema": {"type": "object", "properties": {}},
    }


def main():
    user_query = "我想請下週三的特休,要怎麼申請"
    relevant_tools = find_relevant_tools(user_query, top_k=3)

    print("=== 語意搜尋篩出的候選工具 ===")
    for tool in relevant_tools:
        print(f"- {tool['name']}:{tool['description']}")

    client = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
    response = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=1024,
        tools=[to_claude_tool_schema(tool) for tool in relevant_tools],
        messages=[{"role": "user", "content": user_query}],
    )

    print("\n=== Claude 的回應 ===")
    for block in response.content:
        if block.type == "text":
            print("文字回覆:", block.text)
        elif block.type == "tool_use":
            print(f"Claude 決定呼叫工具:{block.name},參數:{block.input}")


if __name__ == "__main__":
    main()
  1. 按 Windows 鍵,打字「PowerShell」,按 Enter 開啟終端機
  2. 在終端機打 pip install anthropic 按 Enter,安裝 Anthropic 官方的 Python 工具包
  3. 去 console.anthropic.com 申請一組 API 金鑰(第一次要先綁信用卡儲值)
  4. 在終端機打 setx ANTHROPIC_API_KEY "你的金鑰",把金鑰存成環境變數(存完要關掉終端機重開一次才會生效)
  5. 把 smart_tool_picker.py 存到你電腦裡,例如 D:\claude_demo\smart_tool_picker.py
  6. 在終端機打 cd D:\claude_demo 切換到那個資料夾,再打 python smart_tool_picker.py 執行
  7. 觀察終端機印出的『語意搜尋篩出的候選工具』——你會看到它從 10 支工具裡自動挑出跟『請假』最相關的幾支,而不是把全部工具塞給 Claude

🧠 工程思維透鏡(資深工程師看到的是什麼)

🔭 為什麼不乾脆把所有工具說明都塞給 Claude,反正它讀得快?
問題不在『讀得快不快』,而在成本跟精準度。工具說明塞越多,每次對話要處理的權杖AI處理文字的最小計價單位,白話講就是AI界的字數計費單位,用越多字通常花越多錢、跑越慢就越多,錢跟時間都在燒;而且選項一多,AI 選錯工具的機率也會上升。資深工程師看到『幾千支工具』的需求,第一反應通常不是『把它們全塞進去』,而是先做一層『篩選』或『分類』,這是任何大型系統設計都會用到的老招式——先縮小範圍,再精準處理。
🔭 讓 AI『自己寫程式碼』來呼叫工具,會不會太危險、失控?
這正是程式碼執行環境一個讓AI寫的程式碼可以真的被執行、跑出結果的隔離小房間,AI寫完程式碼馬上能看到執行結果存在的原因——把 AI 寫的程式碼關進一個『隔離房間』裡跑,就算程式碼寫錯,影響範圍也被限制在那個房間裡,不會直接碰到真正的資料庫或正式環境。這是工程上很常見的取捨:『給 AI 更大的自由度來換取效率』,同時用『限制它能碰到什麼』來控制風險,而不是完全不給自由度。
🔭 這篇食譜為什麼要把『語意搜尋』跟『工具呼叫』兜在一起講,而不是分開介紹?
因為這兩招其實是在解決同一件事的『前後兩段』:語意搜尋負責『先縮小範圍』,工具呼叫(特別是 PTC)負責『把縮小後的範圍有效率地執行完』。很多人學 AI 工程容易把每個技巧當成獨立招式背,但資深工程師看的是『這些招式怎麼串成一條線,一起解決同一個規模問題』——這篇食譜示範的正是『從幾千支工具,到一次精準又省錢的任務完成』這條完整路徑。

📝 隨堂考(點選答案,立即回饋)

Q1. 如果一間公司的 AI 助理要串接 2000 支內部工具,按照這篇食譜的做法,比較合理的做法是?
✅ 食譜裡『用嵌入搜尋找工具』的做法,就是先做語意篩選再交給 Claude,避免把上下文塞爆,也降低選錯工具的機率。
Q2. 『程式化工具呼叫(PTC)』跟傳統工具呼叫最大的差別是什麼?
✅ 傳統做法是一次呼叫一支工具、等結果回來才能決定下一步;PTC 讓 Claude 直接寫程式碼,一段裡面連續呼叫多支工具並自己整理結果。
Q3. 讓 Claude 自己寫的程式碼丟進『程式碼執行環境』裡跑,這個設計主要是為了什麼?
✅ 隔離的執行環境讓 AI 有自由度自己寫程式碼解決問題,同時把可能出錯的影響範圍限制住,是效率與風險之間的工程取捨。
Q4. 這篇食譜主要是想解決哪一種痛點?
✅ 整份食譜的核心痛點,就是工具規模一大,傳統一問一答式的工具呼叫會拖慢速度、拉高成本、也容易選錯,這也是 PTC 跟語意搜尋兩招要解決的問題。

🃏 翻牌記憶卡(先想答案,再點開對答)

工具呼叫(Tool Calling)點我翻面
讓 AI 不只回答文字,還能實際去操作外部系統,例如查資料庫、送出表單。
PTC(程式化工具呼叫)點我翻面
讓 Claude 直接寫一段程式碼,一次連續呼叫多支工具、自己做判斷整理結果,不用一輪一輪來回。
語意搜尋(Semantic Search)點我翻面
不比對關鍵字,而是理解『意思』相近的東西,用來從成千上萬支工具裡篩出最相關的幾支。
嵌入向量(Embeddings)點我翻面
把一段文字轉成一串數字,讓電腦能用數學距離判斷兩段文字的意思有多接近。
程式碼執行環境(Code Execution Environment)點我翻面
一個隔離的小房間,讓 AI 寫的程式碼可以真的被執行、馬上看到結果,同時限制它能碰到的範圍。

✅ 離開前自測(全勾=這課真的學會了)

0%