Agent Tool Calling in der Praxis: KI externe APIs und Dienste aufrufen lassen
Kennen Sie das? Sie möchten, dass die KI das Wetter prüft, eine Datei liest oder eine API aufruft – und sie antwortet nur: „Ich habe keinen Zugriff auf externe Daten.“
Nervig, oder?
Das liegt nicht daran, dass die KI „nicht schlau genug“ ist, sondern daran, dass ihr eine Kernfähigkeit fehlt: Tool Calling. Heute schauen wir uns an, wie diese Technik KI vom reinen Chatten zum tatsächlichen Handeln bringt.
Was ist KI Tool Calling?
Kurz gesagt: Tool Calling gibt der KI Hände.
Klassische LLMs antworten nur aus Trainingsdaten. Fragen Sie „Wie ist das Wetter heute in Peking?“, heißt es: „Ich kann keine Echtzeitdaten abrufen.“ Mit Tool Calling kann die KI aktiv eine Funktion anfordern – z. B. eine Wetter-API – und Ihnen das Ergebnis zurückgeben.
Wie wichtig ist das? Ungefähr der Sprung vom Berater, der nur Pläne zeichnet, zum General, der selbst ins Feld zieht.
Drei gängige Ansätze
Aktuell dominieren drei Varianten:
| Ansatz | Repräsentant | Einsatz |
|---|---|---|
| Function Calling | OpenAI GPT | Strukturierte Ausgabe, einfache API-Aufrufe |
| Tool Use | Claude | Komplexe Tool-Ketten, mehrstufige Aufgaben |
| MCP | Claude Code | Standardisiertes Tool-Ökosystem |
Welcher passt? Hängt vom Bedarf ab. Einfache Fälle: OpenAI Function Calling reicht. Komplexe Agent-Systeme: Claude Tool Use. Tool-Ökosystem: MCP ist der Trend.
OpenAI Function Calling: vom Einstieg zur Praxis
Schauen wir uns OpenAIs Variante an. Function Calling ist schlank aufgebaut – im Kern drei Schritte:
- Tools definieren (der KI mitteilen, was verfügbar ist)
- Die KI wählt ein Tool (liefert Funktionsname und Parameter)
- Sie führen das Tool aus und geben das Ergebnis zurück
Ein vollständiges Beispiel
Angenommen, wir bauen ein Wetter-Tool. Zuerst das Tool-Schema:
tools = [{
"type": "function",
"function": {
"name": "get_weather",
"description": "获取指定城市的当前天气信息",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "城市名称,如'北京'、'上海'"
},
"unit": {
"type": "string",
"enum": ["celsius", "fahrenheit"],
"description": "温度单位,默认摄氏度"
}
},
"required": ["city"]
}
}
}]
Achten Sie auf description – nicht schlampig formulieren. Daran erkennt die KI, wann das Tool passt. „Wetter abrufen“ reicht oft nicht; „获取指定城市的当前天气信息“ (aktuelle Wetterdaten für eine Stadt) hebt die Trefferquote in der Praxis spürbar an.
Dann die Anfrage:
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "user", "content": "北京今天热不热?"}
],
tools=tools
)
Die KI liefert einen Tool-Call:
tool_call = response.choices[0].message.tool_calls[0]
# tool_call.function.name = "get_weather"
# tool_call.function.arguments = '{"city": "北京"}'
Sie führen die Funktion aus und geben das Ergebnis zurück:
# 执行你的天气 API 调用
weather_result = get_weather_from_api("北京")
# 把结果喂回去
final_response = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "user", "content": "北京今天热不热?"},
response.choices[0].message, # AI 的工具调用请求
{
"role": "tool",
"tool_call_id": tool_call.id,
"content": json.dumps(weather_result)
}
]
)
Die KI antwortet natürlich, z. B.: „In Peking sind es heute 28 Grad – ziemlich warm, Sonnenschutz nicht vergessen.“
Strict Mode: stabile Ausgabe
2024 führte OpenAI Strict Mode ein – es behebt instabile JSON-Schema-Treffer. Aktivierung:
tools = [{
"type": "function",
"function": {
"name": "get_weather",
"strict": True, # 加这一行
# ... 其他字段
}
}]
Danach entsprechen Parameter garantiert zu 100 % Ihrem Schema. In Produktion unbedingt einschalten – sonst warten seltsame Parsing-Fehler.
Claude Tool Use: stärkere Tool-Ketten
Claudes Tool Use unterscheidet sich in einigen Punkten von OpenAI.
Parallele Aufrufe
Claude kann mehrere Tool Calls in einer Antwort liefern. Fragen Nutzer: „Vergleiche das Wetter in Peking und Shanghai“, kommen oft zwei get_weather-Aufrufe auf einmal:
response = client.messages.create(
model="claude-sonnet-4-20250514",
messages=[{"role": "user", "content": "对比一下北京和上海的天气"}],
tools=tools
)
# response.content 可能包含两个 tool_use block
for block in response.content:
if block.type == "tool_use":
print(f"调用 {block.name},参数:{block.input}")
Besonders bei komplexen Aufgaben hilfreich. OpenAI unterstützt Parallelität ebenfalls – Claude ordnet eleganter, was parallel darf und was seriell laufen muss.
Tool-Choice-Strategien
Feinere Steuerung bei Claude:
# 自动选择(默认)
tool_choice = {"type": "auto"}
# 强制使用工具(不用工具就不回答)
tool_choice = {"type": "any"}
# 指定使用特定工具
tool_choice = {"type": "tool", "name": "get_weather"}
Wann any? Wenn die Frage ohne Tool nicht beantwortbar ist – z. B. Bestellstatus aus der Datenbank. Dann Tool-Nutzung erzwingen.
Fehlerbehandlung
Tool Calls scheitern normal: Timeout, Netzwerk, falsche Parameter. Claude bietet saubere Rückmeldung:
tool_result = {
"type": "tool_result",
"tool_use_id": tool_use.id,
"content": "API 调用失败:连接超时", # 直接告诉 AI 失败原因
"is_error": True # 标记为错误
}
Die KI versucht Alternativen oder eine freundliche Meldung – statt roher Stacktraces für Nutzer.
MCP: die Zukunft der Tool-Standardisierung
Bei Tool Calling führt kein Weg an MCP (Model Context Protocol) vorbei.
Warum MCP?
Das Tool-Ökosystem ist fragmentiert. GitHub-Tool für Claude, Slack-Tool für ChatGPT – oft doppelte Arbeit. MCP will einen Standard: einmal bauen, überall nutzen.
Architektur in Kurzform:
MCP Client(Claude Code/Claude Desktop)
↕
MCP Server(工具提供者)
↕
External Tool/API
MCP in Claude Code
Claude Code unterstützt MCP besonders gut. Mit /mcp konfigurieren:
# 添加一个远程 MCP 服务器
claude mcp add my-server --transport sse --url https://api.example.com/mcp
# 添加一个本地工具
claude mcp add local-tool --command node ./my-tool.js
Danach entdeckt Claude Code die Server-Tools automatisch – passende Anfragen lösen Aufrufe aus.
Beispiel: Ich konfiguriere get-github-issues und frage: „Welche open issues hat dieses Projekt?“ Claude ruft ab und fasst zusammen.
Idealer Zustand: Sie merken das Tool kaum – es wirkt einfach wie eine gute Antwort.
Fallstricke in Produktion
Tool Calling klingt einfach – live gibt es trotzdem Stolpersteine.
Sicherheit: der KI nicht alles erlauben
Die KI ruft vielleicht APIs auf, die Sie nicht wollen. Gegenmaßnahmen:
- Tool-Berechtigungen stufen: nur nötige Tools; sensible Aktionen mit menschlicher Bestätigung
- Eingabe validieren: KI-Parameter nie ungeprüft an APIs weitergeben
- Audit: jeden Aufruf mit Parametern und Ergebnis protokollieren
Gegenbeispiel: Nutzereingabe ungefiltert an eine DB-Query – SQL-Injection. Nicht die KI „injiziert“, aber sie leitet schädliche Eingaben weiter. KI-Parameter nie blind vertrauen.
Timeout und Retry
async def call_tool_with_retry(tool_func, args, max_retries=3):
for attempt in range(max_retries):
try:
return await asyncio.wait_for(
tool_func(**args),
timeout=10.0 # 10 秒超时
)
except asyncio.TimeoutError:
if attempt == max_retries - 1:
return {"error": "工具调用超时"}
await asyncio.sleep(1) # 等待 1 秒后重试
Token-Kosten
Tool-Definitionen und Ergebnisse verbrauchen Tokens. Große Payloads werden teuer. Tipps:
- Beschreibungen straffen: kurz, aber eindeutig
- Antworten filtern: nur nötige Felder an die KI
- Caching: gleiche Abfragen kurz cachen
Fazit
Tool Calling ist Kernfähigkeit jedes KI-Agenten. Ohne bleibt Theorie; damit wird echte Arbeit möglich.
OpenAI Function Calling: schlank, gut für Einstieg und einfache Fälle. Claude Tool Use: stärker für komplexe Agent-Systeme. MCP: Standardisierung – langfristig beobachten.
Welche Variante? Hängt vom Projekt ab. Sicherheit, Fehlerbehandlung und Performance sollten Sie aber von Anfang an mitdenken.
Referenzen
- Claude Tool Use – offizielle Dokumentation
- OpenAI Function Calling – Leitfaden
- Model Context Protocol – Spezifikation
- Claude Code – MCP-Konfiguration
- Anthropic – Advanced Tool Use (Engineering-Blog)
FAQ
Was ist der Unterschied zwischen OpenAI Function Calling und Claude Tool Use?
Wann sollte ich MCP statt direktem Function Calling nutzen?
Wie gehe ich mit fehlgeschlagenen Tool Calls um?
Wie verhindere ich, dass KI sensible APIs aufruft?
Was ist Strict Mode – soll ich es aktivieren?
6 Min. Lesezeit · Veröffentlicht am: 21. März 2026 · Aktualisiert am: 9. Juli 2026
AI Agent Engineering Guide
Wenn du über die Suche hier gelandet bist, kommst du am schnellsten weiter, indem du zum vorherigen oder nächsten Beitrag dieser Serie springst.
Vorheriger
KI-Agent-Gedächtnisverwaltung: Langzeitgedächtnis und Wissens-Governance in der Praxis
Tiefenanalyse von KI-Agent-Gedächtnissystemen: drei Gedächtnistypen, vierstufige Kognitionsarchitektur, Vergleich von sechs Frameworks. Von Mem0 bis Letta, von Vektordatenbank bis Wissensgraph – Lösungen für Agent-Amnesie und Context Rot.
Teil 4 von 16
Nächster
Computer-Use Agent: KI steuert Ihren Computer
Claude Computer Use im Detail – von der Technik bis zur Praxis: Docker-Deployment, Codebeispiele, Wettbewerbsvergleich und Sicherheits-Best-Practices für KI-Desktop-Automatisierung
Teil 6 von 16
Ähnliche Beiträge
Agent Sandbox aufbauen: Vollständiger Leitfaden für sichere KI-Codeausführung

Agent Sandbox aufbauen: Vollständiger Leitfaden für sichere KI-Codeausführung
KI-Agent-Entwicklung in der Praxis: Architekturdesign und Implementierungsleitfaden


Kommentare
Melde dich mit GitHub an, um einen Kommentar zu hinterlassen