Agent Tool

In Frameworks wie LangChain oder n8n definierst du Tools. Ein Tool besteht aus:

1. Name: calculator
2. Description: "Useful for calculating math problems." (Extrem wichtig! Das LLM liest das, um zu entscheiden, ob es das Tool nutzt).
3. Schema (Input): Welche Daten braucht das Tool? (z. B. { "expression": "string" }).
4. Function: Der eigentliche Code (Python/JS), der ausgeführt wird.

User: "Was ist 25 mal 43?" Agent (denkt): "Das ist Mathe. Ich nutze calculator mit 25 * 43." System: Führt 25 * 43 aus -> Ergebnis 1075. Agent: "Das Ergebnis ist 1075."

1. OpenAI Function Calling (Tool Calling)

Früher (ReAct) musste man dem LLM sagen: "Antworte bitte so: Action: [Name]". Das war fehleranfällig (Halluzinationen, falsches Parsing). OpenAI hat Modelle (GPT-4) speziell darauf trainiert ("fine-tuned"), JSON-Output für Tools zu generieren. Du schickst im API-Call eine Liste von tools (als JSON Schema). Das Modell antwortet nicht mit Text (content), sondern mit einem speziellen tool_calls Objekt. Das ist deterministisch und typ-sicher.

2. Toolkit & Multi-Tool Usage

Agenten können Zugriff auf Dutzende Tools haben (Toolkit). Moderne Modelle sind "Parallel Tool Use" fähig. User: "Wie ist das Wetter in Berlin und München?" Agent: Ruft get_weather ZWEIMAL parallel auf (einmal Berlin, einmal München). Das spart Latenz.

3. Human-in-the-Loop (Approval)

Manche Tools sind gefährlich (delete_database, send_money). Hier baut man einen "Human Approval" Schritt ein. Agent wählt Tool -> System pausiert -> Admin bekommt Nachricht "Agent will Geld senden. Erlauben?" -> Admin klickt Ja -> Tool läuft.

1. Schema Engineering & Halting Problems

Das Beschreiben von Tools als JSON Schema (OpenAPI Specs) erfordert "Schema Engineering", was fast noch wichtiger als Prompt Engineering wird. Das LLM verliert den Faden, wenn ein Tool 30 optionale Parameter hat. Oft erfindet es Parameter, die es gar nicht gibt. Best Practice ist es, strikte enum Arrays für String-Parameter bereitzustellen. Zudem gibt es das Agent Halting Problem: Der Agent gerät in eine unendliche Schleife -> Ruft Tool auf -> Tool failt -> Ruft Tool mit gleichem dummen Parameter auf. Production-Setups erfordern Hard-Limits (z. B. max 5 Tool-Calls pro Loop) und ein Tool, das explizit GiveUp erzwingt.

2. Structured Outputs vs. Agent State (Memory)

Wenn ein Agent ein "SQL Query" Tool nutzt, bekommt er vielleicht 5.000 Zeilen JSON zurück. Schiebt er das in sein Context Window, crasht er entweder oder wird unendlich teuer (Agent Cost Optimization!). Lösung: Opaque References oder Memory-Bound Tools. Das Tool gibt dem Agenten nicht die Daten, sondern ein Handle/UUID: "Ich habe die 50MB PDF durchsucht, hier ist die UUID des Reports". Das LLM hat dann Zugriff auf ein zweites Tool answer_from_report(id, question). Der Agent schiebt also nur Pointer hin und her, anstatt Raw Data.

3. ReAct Pattern (Reasoning and Acting)

Das Fundament der meisten Legacy-Agenten vor den nativen "Tool-Calling" LLMs war ReAct. Die Grundstruktur zwingt den Agenten in eine Loop: Thought: Was muss ich tun? -> Action: Führe Tool X aus -> Observation: Tool-Output. Diese explizite "Gedanken"-Spur (Thought) zwingt das Sprachmodell zur Chain-of-Thought (CoT), was drastisch reduziert, dass es einfach Tools rät. Moderne Setups nutzen zwar native API-Calls für die Action, erzwingen die Thought aber nach wie vor in einem vorgeschobenen Output-JSON-Feld.