For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Hauptnavigation

Tool-Suche

Lade zurückgestellte Tools zur Laufzeit, damit Modelle nur die Definitionen importieren, die sie benötigen.

Mit der Tool-Suche kann das Modell bei Bedarf dynamisch nach Tools suchen und sie in seinen Kontext laden. So musst du nicht alle Tool-Definitionen vorab in den Modellkontext laden und kannst den gesamten Token-Verbrauch und die Kosten möglicherweise senken. Für optimale Kosten und Latenz ist die Tool-Suche so konzipiert, dass sie den Cache des Modells erhält. Wenn das Modell neue Tools findet, werden sie am Ende des Kontextfensters eingefügt.

In der Responses API unterstützen nur gpt-5.4 und neuere Modelle tool_search.

Die folgende Konfiguration und die Beispiele verwenden die Responses API. Informationen zum sitzungsbasierten Laden von Funktionen und zur automatischen MCP-Erkennung findest du unter Agents API.

Um die Tool-Suche in der Responses API zu aktivieren, musst du zwei Schritte ausführen:

  1. Füge tool_search als Tool zu deinem tools-Array hinzu.
  2. Wenn du Funktionen verwendest, kennzeichne diejenigen, deren Laden du zurückstellen möchtest, mit defer_loading: true. Wenn du MCP-Server verwendest, setze defer_loading: true in der Tool-Definition des MCP-Servers.

Verwende nach Möglichkeit Namensräume

Du kannst die Tool-Suche mit zurückgestellten Funktionen, Namensräumen oder MCP-Servern verwenden. Wir empfehlen jedoch, nach Möglichkeit Namensräume oder MCP-Server zu nutzen. Unsere Modelle wurden hauptsächlich darauf trainiert, diese zu durchsuchen. Außerdem lassen sich damit in der Regel deutlich mehr Token einsparen.

Bei Namensräumen gilt defer_loading für die Funktionen innerhalb des Namensraums, nicht für das Namensraumobjekt selbst.

Zu Beginn einer Anfrage sieht das Modell weiterhin den Namen und die Beschreibung aller durchsuchbaren Elemente. Bei einem Namensraum oder MCP-Server sieht es zunächst also nur dessen Namen und Beschreibung. Details zu den einzelnen enthaltenen Funktionen werden erst sichtbar, wenn das Tool für die Tool-Suche sie lädt. Bei einer einzelnen zurückgestellten Funktion sieht das Modell weiterhin den Funktionsnamen und die Beschreibung. In der Praxis stellt die Tool-Suche hier also hauptsächlich das Laden des Parameterschemas zurück.

Um möglichst viele Token einzusparen, empfehlen wir, zurückgestellte Funktionen in Namensräumen oder MCP-Servern zu gruppieren. Klare, übergeordnete Beschreibungen sollten dem Modell einen guten Überblick über deren Inhalt geben, damit es gezielt suchen und nur die relevanten Funktionen laden kann. Für eine bessere Token-Effizienz und Modellleistung solltest du jeden Namensraum möglichst auf weniger als 10 Funktionen beschränken.

{
    "tools": [
      {
        "type": "namespace",
        "name": "crm",
        "description": "CRM tools for customer lookup and order management.",
        "tools": [
          {
            "type": "function",
            "name": "list_open_orders",
            "description": "List open orders for a customer ID.",
            "defer_loading": true,
            "parameters": {
              "type": "object",
              "properties": {
                "customer_id": { "type": "string" }
              },
              "required": ["customer_id"],
              "additionalProperties": false
            }
          }
        ]
      },
      {
        "type": "tool_search"
      }
    ]
  }

Namensräume können sowohl zurückgestellte als auch sofort verfügbare Tools enthalten. Tools ohne defer_loading: true lassen sich sofort aufrufen, während zurückgestellte Tools im selben Namensraum über die Tool-Suche geladen werden.

Arten der Tool-Suche

Wähle zwischen zwei Arten der Tool-Suche:

  • Gehostete Tool-Suche: OpenAI durchsucht die zurückgestellten Tools, die du in der Anfrage deklariert hast, und gibt die geladene Teilmenge in derselben Antwort zurück.
  • Clientseitig ausgeführte Tool-Suche: Das Modell gibt einen tool_search_call aus, deine Anwendung führt die Suche durch und du gibst einen passenden tool_search_output zurück.

Beginne mit der gehosteten Tool-Suche, wenn die infrage kommenden Tools beim Erstellen der Anfrage bereits bekannt sind. Nutze die clientseitig ausgeführte Tool-Suche, wenn das Ermitteln von Tools vom Projektzustand, vom Mandantenzustand oder von einem anderen System abhängt, das deine Anwendung steuert.

Die gehostete Tool-Suche ist der einfachste Weg, wenn du bereits alle Funktionen, Namensräume oder MCP-Server kennst, die das Modell durchsuchen soll. Du deklarierst sie vorab, fügst {"type": "tool_search"} hinzu und überlässt der API die Entscheidung, was geladen wird.

Gehostete Tool-Suche konfigurieren
from openai import OpenAI

client = OpenAI()

crm_namespace = {
    "type": "namespace",
    "name": "crm",
    "description": "CRM tools for customer lookup and order management.",
    "tools": [
        {
            "type": "function",
            "name": "get_customer_profile",
            "description": "Fetch a customer profile by customer ID.",
            "parameters": {
                "type": "object",
                "properties": {
                    "customer_id": {"type": "string"},
                },
                "required": ["customer_id"],
                "additionalProperties": False,
            },
        },
        {
            "type": "function",
            "name": "list_open_orders",
            "description": "List open orders for a customer ID.",
            "defer_loading": True,
            "parameters": {
                "type": "object",
                "properties": {
                    "customer_id": {"type": "string"},
                },
                "required": ["customer_id"],
                "additionalProperties": False,
            },
        },
    ],
}

response = client.responses.create(
    model="gpt-6-astra",
    input="List open orders for customer CUST-12345.",
    tools=[
        crm_namespace,
        {"type": "tool_search"},
    ],
    parallel_tool_calls=False,
)

print(response.output)

Wenn das Modell entscheidet, dass es ein zurückgestelltes Tool benötigt, enthält die Antwort vor dem eigentlichen Funktionsaufruf zwei zusätzliche Ausgabeelemente:

  • tool_search_call, das den gehosteten Suchschritt protokolliert.
  • tool_search_output, das die geladene und nun aufrufbare Teilmenge enthält.
Antwort der gehosteten Tool-Suche
[
  {
    "type": "tool_search_call",
    "execution": "server",
    "call_id": null,
    "status": "completed",
    "arguments": {
      "paths": ["crm"]
    }
  },
  {
    "type": "tool_search_output",
    "execution": "server",
    "call_id": null,
    "status": "completed",
    "tools": [
      {
        "type": "namespace",
        "name": "crm",
        "description": "CRM tools for customer lookup and order management.",
        "tools": [
          {
            "type": "function",
            "name": "list_open_orders",
            "description": "List open orders for a customer ID.",
            "defer_loading": true,
            "parameters": {
              "type": "object",
              "properties": {
                "customer_id": { "type": "string" }
              },
              "required": ["customer_id"],
              "additionalProperties": false
            }
          }
        ]
      }
    ]
  },
  {
    "type": "function_call",
    "name": "list_open_orders",
    "namespace": "crm",
    "call_id": "call_abc123",
    "arguments": "{\"customer_id\":\"CUST-12345\"}"
  }
]

Im gehosteten Modus ist execution auf server und call_id auf null gesetzt.

Bei komplexeren Aufgaben kann das Modell auch mehrere Namensräume oder MCP-Server mit demselben tool_search_call laden. Benötigt es beispielsweise Funktionen aus verschiedenen Namensräumen, um eine Aufgabe zu erledigen, kann es diese gemeinsam durchsuchen und laden, bevor es die anschließenden Funktionsaufrufe ausführt.

Die clientseitig ausgeführte Tool-Suche gibt deiner Anwendung die volle Kontrolle darüber, wie Tools ermittelt werden. Das ist nützlich, wenn die verfügbaren Tools von Informationen abhängen, die sich nicht sinnvoll in der anfänglichen tools-Liste deklarieren lassen.

Konfiguriere das Tool tool_search mit execution: "client" und einem Schema für die Suchargumente, die deine Anwendung erwartet:

Clientseitig ausgeführte Tool-Suche konfigurieren
from openai import OpenAI

client = OpenAI()

first_response = client.responses.create(
    model="gpt-6-astra",
    input="Find the shipping ETA tool first, then use it for order_42.",
    tools=[
        {
            "type": "tool_search",
            "execution": "client",
            "description": "Find the project-specific tools needed to continue the task.",
            "parameters": {
                "type": "object",
                "properties": {
                    "goal": {"type": "string"},
                },
                "required": ["goal"],
                "additionalProperties": False,
            },
        }
    ],
    parallel_tool_calls=False,
)

search_call = next(
    item for item in first_response.output if item.type == "tool_search_call"
)

loaded_tools = [
    {
        "type": "function",
        "name": "get_shipping_eta",
        "description": "Look up shipping ETA details for an order.",
        "defer_loading": True,
        "parameters": {
            "type": "object",
            "properties": {
                "order_id": {"type": "string"},
            },
            "required": ["order_id"],
            "additionalProperties": False,
        },
    }
]

second_response = client.responses.create(
    model="gpt-6-astra",
    input=[
        *first_response.output,
        {
            "type": "tool_search_output",
            "execution": "client",
            "call_id": search_call.call_id,
            "status": "completed",
            "tools": loaded_tools,
        },
    ],
)

print(second_response.output)

Im ersten Durchgang gibt das Modell einen tool_search_call aus und hält dann an:

Aufruf der clientseitigen Tool-Suche
[
  {
    "type": "tool_search_call",
    "execution": "client",
    "call_id": "call_abc123",
    "status": "completed",
    "arguments": {
      "goal": "Find the shipping ETA tool for order_42."
    }
  }
]

Deine Anwendung führt anschließend die Suche durch und gibt einen tool_search_output mit den Tools zurück, die sie laden möchte:

tool_search_output zurückgeben
[
  {
    "type": "tool_search_output",
    "execution": "client",
    "call_id": "call_abc123",
    "status": "completed",
    "tools": [
      {
        "type": "function",
        "name": "get_shipping_eta",
        "description": "Look up shipping ETA details for an order.",
        "defer_loading": true,
        "parameters": {
          "type": "object",
          "properties": {
            "order_id": { "type": "string" }
          },
          "required": ["order_id"],
          "additionalProperties": false
        }
      }
    ]
  }
]

Im nächsten Durchgang lässt sich das geladene Tool wie eine normale Funktion aufrufen:

Aufruf einer geladenen Funktion
[
  {
    "type": "function_call",
    "name": "get_shipping_eta",
    "namespace": "get_shipping_eta",
    "call_id": "call_xyz456",
    "arguments": "{\"order_id\":\"order_42\"}"
  }
]

Im Client-Modus ist execution auf client gesetzt und call_id definiert. Übernimm in deinem tool_search_output denselben Wert für call_id aus dem tool_search_call.

Fortgeschrittene Nutzung

Beschreibe Namensräume klar

Beschreibe Namensräume klar und mit Bezug auf ihren Anwendungsfall. Anhand dieser Beschreibung entscheidet das Modell, wann es eine Teilmenge der Funktionen in diesem Namensraum lädt. Vermeide übermäßig lange Beschreibungen. Nimm ausführlichere Details stattdessen in die Beschreibungen der zurückgestellten Funktionen auf, die nur bei Bedarf geladen werden.

Verstehe, was geladen wird

tool_search_output.tools enthält die Liste der Tools, die das Modell dynamisch geladen hat. Das Modell kann jedes dieser Tools in späteren Durchgängen aufrufen. Im Client-Modus musst du dasselbe Tool daher nicht in jedem Durchgang erneut laden. Tools, die nicht in diesem Array aufgeführt sind, stehen dem Modell nicht zur Verfügung. Wenn du ein geladenes Tool deaktivieren möchtest, kannst du es aus dem tool_search_output-Element entfernen, in dem du die geladenen Tools definierst. Beachte jedoch, dass eine Änderung dieser Tool-Auswahl den Cache des Modells ab dieser Stelle ungültig macht.

Fortgeschrittene Muster zum Einfügen von Tools

Die meisten Integrationen deklarieren Tools im Parameter tools der Anfrage. Die clientseitig ausgeführte Tool-Suche unterstützt auch fortgeschrittenere Muster, bei denen deine Anwendung Tools zurückgibt, die in der ursprünglichen Anfrage nicht enthalten waren. Behandle dies als fortgeschrittenen Arbeitsablauf: Validiere die zurückgegebenen Schemas sorgfältig und stelle nur vertrauenswürdige Tool-Definitionen bereit.

Tool-Suche und Caching

Alle Tools werden am Ende des Kontextfensters des Modells geladen. Das gilt sowohl für die gehostete als auch für die clientseitig ausgeführte Tool-Suche. Dadurch bleibt der Cache des Modells über mehrere Anfragen hinweg erhalten. Das senkt die Gesamtkosten und erhöht die Geschwindigkeit.

Füge Tools an einer bestimmten Stelle in der Eingabe hinzu

Für fortgeschrittene Arbeitsabläufe kannst du mit einem additional_tools-Eingabeelement Tools an einer bestimmten Stelle in der Unterhaltung verfügbar machen. Das ist nützlich, wenn deine Anwendung Tools außerhalb des normalen Ablaufs der Tool-Suche lädt oder die Reihenfolge von Tools beibehalten muss, die während einer vorherigen Antwort hinzugefügt wurden.

Setze role auf developer und füge die gewünschten Tools dem Array tools des Elements hinzu:

{
    "type": "additional_tools",
    "role": "developer",
    "tools": [
      {
        "type": "function",
        "name": "get_customer",
        "description": "Look up a customer by ID.",
        "parameters": {
          "type": "object",
          "properties": {
            "customer_id": { "type": "string" }
          },
          "required": ["customer_id"],
          "additionalProperties": false
        }
      }
    ]
  }

Tools in einem additional_tools-Element werden erst verfügbar, nachdem dieses Element in der Eingabe erscheint. Wenn du Konversationselemente manuell wieder als Eingabe übergibst, behalte die Position des Elements bei, damit das Modell an derselben Stelle der Konversation dieselben Tools sieht.

Agents API

Die Agents API lädt Funktionsdefinitionen standardmäßig sofort. Um ausgewählte Funktionen erst bei Bedarf zu laden, füge { "type": "tool_search" } zu agent.tools hinzu und setze defer_loading: true für jede Funktion, die der Agent bei Bedarf finden soll. Das Hinzufügen von tool_search verzögert nicht das Laden aller Funktionen.

Deine Sitzungsanfrage enthält weiterhin die vollständige Funktionsdefinition einschließlich Name, Beschreibung und Argumentschema. Die Tool-Suche ändert den Zeitpunkt, zu dem diese Definition das Modell erreicht. Nachdem die Funktion gefunden wurde, verarbeitet deine Anwendung den Funktionsaufruf und gibt das Ergebnis wie gewohnt zurück. Informationen zur Verarbeitung von Ergebnissen findest du unter Funktionen.

Setze OPENAI_API_KEY, bevor du dieses Beispiel ausführst:

Funktionen als Werkzeuge nur bei Bedarf laden
import OpenAI from "openai";
const client = new OpenAI();

const result = await client.beta.agents.sessions.create({
  agent: {
    model: "gpt-6-astra",
    tools: [
      {
        type: "tool_search",
      },
      {
        type: "function",
        name: "lookup_account",
        description: "Find an account by its account number.",
        parameters: {
          type: "object",
          properties: {
            account_id: {
              type: "string",
            },
          },
          required: ["account_id"],
          additionalProperties: false,
        },
        defer_loading: true,
      },
    ],
  },
  environment: {
    type: "none",
  },
  input: [
    {
      role: "user",
      content: [
        {
          type: "input_text",
          text: "Look up account 42.",
        },
      ],
    },
  ],
});
console.log(result.id);

Eine Strategie zum Laden von Funktionen wählen

StrategieKonfigurationGeeignet fürKompromiss
Sofortiges LadenLass defer_loading weg oder setze es auf false.Eine kleine Anzahl von Funktionen oder Funktionen, die für die meisten Aufgaben benötigt werden.Ungenutzte Definitionen belegen Platz im Kontext. Wird eine Definition geändert, kann ein zwischengespeichertes Präfix ungültig werden.
Verzögertes LadenSetze defer_loading: true und füge tool_search hinzu.Einen großen Katalog, aus dem jede Aufgabe nur wenige Funktionen benötigt.Die Suche erfordert einen zusätzlichen Schritt und setzt voraus, dass das relevante Werkzeug gefunden wird.

Sofort und verzögert geladene Funktionen lassen sich in einer Sitzung der Agents API kombinieren. Dies wird jedoch im Allgemeinen nicht empfohlen. Gib verzögert geladenen Funktionen eindeutige Namen und Beschreibungen. Vergleiche anhand repräsentativer Anfragen die Aufgabenerfüllung, den Verbrauch an Eingabe-Token und die Latenz, bevor du eine Standardeinstellung wählst.

MCP- und Plug-in-Werkzeuge

MCP-Werkzeuge werden in der Agents API automatisch erkannt, wenn das Modell und der Anbieter die Tool-Suche unterstützen. Die Laufzeitumgebung verzögert das Laden von MCP-Werkzeugen und fügt die Tool-Suche hinzu, sobald durchsuchbare, verzögert geladene Werkzeuge verfügbar sind. Dies gilt für Remote-MCPs, Executor-MCPs und MCP-Werkzeuge, die von Plug-ins bereitgestellt werden.

Du musst nicht eigens für MCP-Werkzeuge { "type": "tool_search" } hinzufügen oder auf einem MCP-Server das Flag defer_loading auf Funktionsebene setzen. Konfiguriere den Server mithilfe von MCP-Verbindungen. Die zuvor in diesem Leitfaden beschriebene Konfiguration der Responses API gilt nicht für MCP-Server der Agents API.

  • Verwende Funktionsaufrufe, um aufrufbare Funktionen und benutzerdefinierte Tools zu definieren.
  • Unter Tools verwenden findest du einen Überblick über die Tools in Responses.