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

Mehrere Agenten

Lass ein Modell innerhalb einer Responses API-Anfrage Subagenten für parallele, gezielte Arbeit starten.

Übersicht

Mit „Mehrere Agenten“ kann ein Modell Subagenten parallel starten und koordinieren und ihre Ergebnisse zu einer abschließenden Antwort zusammenführen. Das ist besonders effektiv für Anwendungen mit komplexen Aufgaben, die von parallel delegierter Arbeit profitieren, etwa bei der Erkundung einer Codebasis, der Dokumentation und der Implementierung.

„Mehrere Agenten“ ist als Betafunktion mit allen GPT-5.6-Modellen verfügbar. Prüfe die Modellseite, bevor du „Mehrere Agenten“ in deiner Anwendung aktivierst.

Wann du mehrere Agenten einsetzen solltest

Aufgaben lassen sich oft in unabhängige Teilaufgaben aufteilen, die ein einzelner Agent nacheinander bearbeiten würde, mehrere Agenten aber parallel erledigen können. Mit „Mehrere Agenten“ kann ein Hauptagent Aufgaben an mehrere Subagenten delegieren, die gleichzeitig daran arbeiten. Das kann mehrere Vorteile bieten:

  • Parallele Ausführung. Unabhängige Recherche-, Analyse- oder Implementierungsaufgaben können gleichzeitig bearbeitet und dadurch schneller erledigt werden.
  • Gezielter Kontext. Jeder Subagent erhält eine klar abgegrenzte Aufgabe und verwaltet seinen eigenen Kontext. Dadurch beeinflussen sich die Kontexte voneinander unabhängiger Arbeiten weniger, was die Leistung verbessert.
  • Vom Modell gesteuerte Koordination. Der Hauptagent kann Subagenten erstellen, ihnen zusätzliche Informationen senden, auf Ergebnisse warten und daraus eine abschließende Antwort formulieren. Deine Anwendung muss dafür keine eigene Orchestrierung implementieren.

Die Orchestrierung mehrerer Agenten ist besonders nützlich, wenn sich eine Aufgabe in konkrete, unabhängige Arbeitsbereiche aufteilen lässt, zum Beispiel:

  • Verschiedene Teile einer großen Codebasis erkunden
  • Mehrere Vorschläge, Dokumente oder Hypothesen vergleichen
  • Parallel in mehreren Quellen recherchieren
  • Unabhängige Komponenten implementieren oder unabhängige Testsuiten schreiben
  • Verschiedene mögliche Ursachen eines Fehlers parallel untersuchen
  • Verschiedene Lösungsansätze für ein Problem gleichzeitig untersuchen

Beachte, dass zusätzliche Subagenten den Tokenverbrauch erhöhen können. Sie bieten möglicherweise weniger Vorteile bei Aufgaben, die auf einer einzigen, geordneten Abfolge von Denkschritten beruhen, häufige Schreibzugriffe auf einen gemeinsam genutzten, veränderlichen Zustand erfordern oder deren Dauer bereits überwiegend durch einen einzelnen langsamen externen Vorgang bestimmt wird.

Nutze mehrere Agenten, wennNutze vorzugsweise einen Agenten, wenn
Sich die Arbeit in unabhängige, klar abgegrenzte Aufgaben aufteilen lässtJeder Schritt direkt vom vorherigen abhängt
Getrennter Kontext gezielteres Arbeiten ermöglichtDie Aufgabe klein genug ist, um sie in einem kurzen Durchlauf zu erledigen
Parallele Untersuchungen die Gesamtdauer verkürzen könnenAgenten um dieselbe veränderliche Ressource konkurrieren würden
Der Vergleich unabhängiger Erkenntnisse eine umfassendere Untersuchung ermöglichtDu einen festen, deterministischen Ausführungsgraphen benötigst

Schnellstart

Die Python- und JavaScript-Beispiele verwenden das Responses SDK in der Betaversion. Verwende für HTTP-Anfragen client.beta.responses und übergib responses_multi_agent=v1 im Argument betas. Bei direkten HTTP-Anfragen und WebSocket-Verbindungen übergibst du OpenAI-Beta: responses_multi_agent=v1 in den Anfrage- oder Verbindungsheadern. Die Schemas der Elemente können sich ändern, solange sich „Mehrere Agenten“ in der Betaphase befindet.

Aktiviere „Mehrere Agenten“ in deiner Responses API-Anfrage mit multi_agent.enabled. Wenn multi_agent.enabled auf true gesetzt ist, kann der Hauptagent einen Baum aus Subagenten erstellen. Die Subagenten nutzen das Modell und die verfügbaren Tools der Anfrage. Die Agenten koordinieren sich über grundlegende Aktionen zur Zusammenarbeit, etwa das Starten von Subagenten, den Nachrichtenaustausch und das Warten auf Ergebnisse (siehe So funktioniert die Zusammenarbeit mehrerer Agenten). Der Hauptagent ist dafür verantwortlich, die Antworten der Subagenten zusammenzuführen und die abschließende Antwort bereitzustellen.

Einen Pull Request mit Subagenten überprüfen
from openai import OpenAI

client = OpenAI()


def review_pull_request(diff: str) -> str:
    response = client.beta.responses.create(
        model="gpt-5.6-sol",
        input=(
            "Review the pull-request diff below with three agents: one for "
            "correctness, one for security, and one for missing tests. "
            "Reconcile duplicate or conflicting findings, then return a "
            "prioritized review with file and line references.\n\n"
            f"<diff>\n{diff}\n</diff>"
        ),
        multi_agent={
            "enabled": True,
            "max_concurrent_subagents": 3,
        },
        betas=["responses_multi_agent=v1"],
    )

    return "".join(
        part.text
        for item in response.output
        if (
            item.type == "message"
            and item.agent is not None
            and item.agent.agent_name == "/root"
            and item.phase == "final_answer"
        )
        for part in item.content
        if part.type == "output_text"
    )

max_concurrent_subagents legt fest, wie viele Subagenten im gesamten Agentenbaum höchstens gleichzeitig aktiv sein können. Dabei zählen alle Nachkommen mit: direkte Unteragenten, deren Unteragenten und alle weiteren Ebenen. Der Hauptagent wird nicht mitgezählt.

Die API gibt für diese Einstellung keine feste Obergrenze vor. Der Standardwert ist 3 und wird für die meisten Arbeitslasten empfohlen. Auch für die Baumtiefe und die Gesamtzahl der während eines Durchlaufs erstellten Subagenten gibt es bei Durchläufen mit mehreren Agenten keine feste Grenze.

Füge eine Entwicklermeldung hinzu, um genauer zu steuern, wann das Hauptmodell Subagenten starten soll. Diese Entwicklermeldung ergänzt die Anweisungen, die für den Hauptagenten und die Subagenten eingefügt werden.

Beispiele für Entwicklermeldungen:

  • „Starte nur dann Subagenten, wenn die nutzende Person ausdrücklich um Subagenten, Delegation oder parallele Arbeit durch Agenten bittet.“
  • „Proaktive Delegation an mehrere Agenten ist aktiv. Nutze Subagenten, wenn parallele Arbeit die Geschwindigkeit oder Qualität wesentlich verbessern würde.“

So funktioniert die Zusammenarbeit mehrerer Agenten

Die Responses API stellt den Modellen des Hauptagenten und der Subagenten gehostete Orchestrierungsaktionen sowie Anweisungen zu deren Nutzung bereit. Der Hauptagent heißt /root. Gestartete Subagenten verwenden hierarchische Pfade wie:

/root
├── /root/researcher
├── /root/reviewer
└── /root/reviewer/tester

„Mehrere Agenten“ legt keine feste Grenze für die Gesamtzahl der Subagenten oder die Baumtiefe fest. Verwende für die meisten Aufgaben den Standardwert 3 für max_concurrent_subagents. Diese Einstellung begrenzt die Anzahl der aktiven Subagenten-Turns im gesamten Baum, einschließlich direkter Unteragenten und aller weiteren Nachkommen.

Wenn der Modus „Mehrere Agenten“ aktiviert ist, stellt die Responses API sechs gehostete Aktionen zur Zusammenarbeit bereit. Diese können als Elemente vom Typ multi_agent_call erscheinen. Deine Anwendung sollte sie weder ausführen noch Ausgaben dafür übermitteln.

AktionZweck
spawn_agentEinen Subagenten erstellen und ihm seine erste Aufgabe zuweisen.
send_messageEine Nachricht für einen bestehenden Agenten in die Warteschlange stellen, ohne einen neuen Turn zu starten.
followup_taskEinem bestehenden Agenten, der nicht der Hauptagent ist, weitere Arbeit zuweisen und seinen Turn starten oder fortsetzen.
wait_agentAuf eine Aktualisierung im Postfach des aufrufenden Agenten warten.
interrupt_agentDen aktiven Turn eines anderen Agenten unterbrechen, ohne dessen Kontext zu löschen.
list_agentsDen aktuellen Agentenbaum, die Statusangaben und last_task_message jedes Agenten zurückgeben.

Die Verarbeitung selbst definierter Tool-Aufrufe funktioniert genauso wie ohne aktivierte Funktion „Mehrere Agenten“. Jeder Agent im Baum kann einen function_call ausgeben. Deine Anwendung muss den Aufruf ausführen und eine passende Ausgabe vom Typ function_call_output übermitteln.

Beachte, dass alle Agenten im Baum Zugriff auf die Tools haben, die im Modellaufruf der API-Anfrage konfiguriert sind.

Mehrere Agenten in der Responses API verwenden

Leistungsvergleich von HTTP und WebSocket

HTTP und WebSocket unterstützen dieselben Funktionen für mehrere Agenten. Für Arbeitsabläufe mit vielen Tool-Aufrufen oder langer Laufzeit wird jedoch WebSocket empfohlen. Über die dauerhafte Verbindung kann deine Anwendung Funktionsausgaben zurückgeben, sobald sie vorliegen. Das reduziert den zusätzlichen Aufwand für die Fortsetzung und verkürzt die Wartezeiten der Agenten.

Bei HTTP wird die Antwort abgeschlossen, sobald jeder aktive Agent entweder fertig ist oder pausiert, um auf einen vom Client ausgeführten Funktionsaufruf zu warten. Deine Anwendung führt dann alle ausstehenden Funktionsaufrufe aus und übermittelt deren Ausgaben in einer neuen Responses API-Anfrage. Dadurch können die pausierten Agenten ihre Arbeit fortsetzen.

Mit WebSocket kann deine Anwendung jede Funktionsausgabe in die Antwort einfügen, sobald sie vorliegt, ohne auf den Abschluss der aktiven Antwort zu warten. Der wartende Agent kann sofort fortfahren, während andere Agenten weiterarbeiten. Das verringert Verzögerungen bei der Koordination und vermeidet zusätzliche Anfrage-Antwort-Zyklen, wenn Agenten zu unterschiedlichen Zeitpunkten fertig werden oder Tools anfordern.

HTTP kann für Arbeitsabläufe ausreichen, die mehrere gehostete Tools aufrufen, etwa für parallele Websuchen, oder die mit einer einzigen Anfrage und wenigen Funktionsaufrufen auskommen. Für die meisten Arbeitsabläufe mit mehreren Agenten dürfte WebSocket eine geringere Latenz und eine bessere Gesamtleistung bieten.

Ausführung von Funktionsaufrufen über HTTP

Ausführung von Funktionsaufrufen über HTTP zwischen der Anwendung, dem Hauptagenten der Responses API und drei Subagenten.

Ausführung von Funktionsaufrufen über WebSocket

Ausführung von Funktionsaufrufen über WebSocket zwischen der Anwendung, dem Hauptagenten der Responses API und drei Subagenten.

HTTP

Diese Beispiele erfordern Beta-Versionen der SDKs, die Zugriff auf die Beta-Version der Responses API bieten. Rufe für HTTP-Streaming client.beta.responses.create auf und übergib responses_multi_agent=v1 mit dem Argument betas. Dadurch werden Beta-Typen und die Autovervollständigung aktiviert. Importiere in Python die Typen für Beta-Antwortelemente aus openai.types.beta, wenn du Typannotationen hinzufügst.

Beispiel für clientseitigen Code:

Tool-Aufrufe beim HTTP-Streaming verarbeiten
from __future__ import annotations

import json
import sys

from openai import OpenAI
from openai.types.beta import BetaResponseOutputItem

client = OpenAI()
ROOT = "/root"
PROPOSALS = {
    "alpha": {"estimated_weeks": 6, "risk": "medium"},
    "beta": {"estimated_weeks": 8, "risk": "low"},
}
tools = [
    {
        "type": "function",
        "name": "get_proposal",
        "description": "Return details for a proposal that the agents should compare.",
        "parameters": {
            "type": "object",
            "properties": {
                "proposal": {
                    "type": "string",
                    "enum": ["alpha", "beta"],
                }
            },
            "required": ["proposal"],
            "additionalProperties": False,
        },
        "strict": True,
    }
]
history = [
    {
        "role": "user",
        "content": "Compare proposal alpha and proposal beta.",
    }
]


def agent_name(item: BetaResponseOutputItem) -> str:
    return item.agent.agent_name if item.agent else ROOT


def render_to_user(delta: str) -> None:
    print(delta, end="", flush=True)


def log_subagent_text(agent: str, delta: str) -> None:
    print(f"[{agent}] {delta}", end="", file=sys.stderr, flush=True)


def process_tool_call(name: str, arguments: str) -> str:
    if name != "get_proposal":
        raise ValueError(f"Unknown tool: {name}")
    parsed_arguments = json.loads(arguments)
    return json.dumps(PROPOSALS[parsed_arguments["proposal"]])


while True:
    output_items = []
    pending_calls = []
    item_agents: dict[int, str] = {}

    stream = client.beta.responses.create(
        model="gpt-5.6-sol",
        input=history,
        tools=tools,
        store=False,
        multi_agent={
            "enabled": True,
            "max_concurrent_subagents": 3,
        },
        stream=True,
        betas=["responses_multi_agent=v1"],
    )
    for event in stream:
        if event.type == "response.output_item.added":
            item_agents[event.output_index] = agent_name(event.item)
        elif event.type == "response.output_text.delta":
            agent = item_agents.get(event.output_index, ROOT)
            if agent == ROOT:
                render_to_user(event.delta)
            else:
                log_subagent_text(agent, event.delta)
        elif event.type == "response.output_item.done":
            output_items.append(event.item)
            if event.item.type == "function_call":
                # Handle function calls from both the root agent and subagents.
                pending_calls.append(event.item)
        elif event.type == "response.completed":
            print(f"\nUsage: {event.response.usage}", file=sys.stderr)
            break
        elif event.type in {
            "error",
            "response.failed",
            "response.incomplete",
        }:
            raise RuntimeError(event)

    history.extend(output_items)

    for call in pending_calls:
        history.append(
            {
                "type": "function_call_output",
                "call_id": call.call_id,
                "output": process_tool_call(call.name, call.arguments),
            }
        )

    if not pending_calls:
        break

Wenn ein oder mehrere Agenten selbst definierte Funktionen aufrufen, führe alle ausstehenden Aufrufe aus und erstelle eine Fortsetzungsanfrage mit ihren Ausgaben.

WebSocket

Wenn ein Agent im WebSocket-Modus eine selbst definierte Funktion aufruft, führe diese in deiner Anwendung aus und sende ihr Ergebnis mit einem response.inject-Ereignis an die aktive Antwort. Der wartende Agent kann dann fortfahren, ohne auf den Abschluss der gesamten Antwort mit mehreren Agenten warten zu müssen.

{
  "type": "response.inject",
  "response_id": "resp_123",
  "input": [
    {
      "type": "function_call_output",
      "call_id": "call_123",
      "output": "{\"temperature\":72}"
    }
  ]
}

Auf eine gültige response.inject-Anfrage antwortet der Server mit einem von zwei Ereignissen:

  • response.inject.created: Die Eingabe wurde validiert und zum Einfügen angenommen.
  • response.inject.failed: Die Eingabe wurde nicht eingefügt. Prüfe error.code.
{
  "type": "response.inject.created",
  "sequence_number": 42,
  "response_id": "resp_123"
}
{
  "type": "response.inject.failed",
  "sequence_number": 43,
  "response_id": "resp_123",
  "input": [
    {
      "type": "function_call_output",
      "call_id": "call_123",
      "output": "{\"temperature\":72}"
    }
  ],
  "error": {
    "code": "response_already_completed",
    "message": "Response 'resp_123' has already completed."
  }
}

Wenn eine Anfrage nicht dem Schema von response.inject entspricht, sendet der Server einen allgemeinen Fehler mit dem Status 400 und schließt die WebSocket-Verbindung. Korrigiere die Anfrage und öffne eine neue WebSocket-Verbindung, bevor du ein weiteres Ereignis sendest.

Das Python-Beta-SDK stellt den WebSocket-Modus über client.beta.responses.connect bereit, das TypeScript-Beta-SDK über ResponsesWS. Übergib OpenAI-Beta: responses_multi_agent=v1 in den Verbindungsheadern. Anders als beim HTTP-Streaming akzeptieren die WebSocket-Konnektoren das Argument betas noch nicht.

Speichere die Antwort-ID aus dem response.created-Ereignis und füge sie jedem response.inject-Ereignis hinzu, das du für diese Antwort sendest. Nachdem du ein Element zum Einfügen gesendet hast, lies weiter aus der WebSocket-Verbindung, bis die Antwort abgeschlossen ist und jeder Einfügevorgang entweder ein response.inject.created- oder ein response.inject.failed-Ereignis ausgelöst hat.

Tool-Ausgaben über WebSocket einfügen
from __future__ import annotations

import json

from openai import OpenAI

client = OpenAI()
PROPOSALS = {
    "alpha": {"estimated_weeks": 6, "risk": "medium"},
    "beta": {"estimated_weeks": 8, "risk": "low"},
}
tools = [
    {
        "type": "function",
        "name": "get_proposal",
        "description": "Return details for a proposal that the agents should compare.",
        "parameters": {
            "type": "object",
            "properties": {
                "proposal": {
                    "type": "string",
                    "enum": ["alpha", "beta"],
                }
            },
            "required": ["proposal"],
            "additionalProperties": False,
        },
        "strict": True,
    }
]


def process_tool_call(name: str, arguments: str) -> str:
    if name != "get_proposal":
        raise ValueError(f"Unknown tool: {name}")
    parsed_arguments = json.loads(arguments)
    return json.dumps(PROPOSALS[parsed_arguments["proposal"]])


def run_multi_agent(connection):
    previous_response_id: str | None = None
    pending_input: list[dict[str, object]] = [{"role": "user", "content": input()}]

    while pending_input:
        request = {
            "type": "response.create",
            "model": "gpt-5.6-sol",
            "store": True,
            "multi_agent": {"enabled": True},
            "tools": tools,
            "input": pending_input,
        }
        if previous_response_id is not None:
            request["previous_response_id"] = previous_response_id

        connection.send(request)

        next_input: list[dict[str, object]] = []
        completed_response = None
        response_id: str | None = None
        pending_injections = 0

        for event in connection:
            event_type = event.type

            if event_type == "response.created":
                response_id = event.response.id

            elif event_type == "response.output_item.done":
                item = event.item

                if item.type == "function_call":
                    if response_id is None:
                        raise RuntimeError(
                            "Received a function call before response.created"
                        )

                    output = {
                        "type": "function_call_output",
                        "call_id": item.call_id,
                        "output": process_tool_call(item.name, item.arguments),
                    }
                    pending_injections += 1

                    connection.send(
                        {
                            "type": "response.inject",
                            "response_id": response_id,
                            "input": [output],
                        }
                    )

            elif event_type == "response.inject.created":
                pending_injections -= 1

            elif event_type == "response.inject.failed":
                pending_injections -= 1

                if event.error.code != "response_already_completed":
                    raise RuntimeError(event.error)

                next_input.extend(item.model_dump(mode="json") for item in event.input)

            elif event_type == "response.completed":
                completed_response = event.response

            elif event_type in {
                "error",
                "response.failed",
                "response.incomplete",
            }:
                raise RuntimeError(event)

            if completed_response is not None and pending_injections == 0:
                break

        if completed_response is None:
            raise RuntimeError("Connection ended before response.completed")

        if not next_input:
            return completed_response

        previous_response_id = completed_response.id
        pending_input = next_input


with client.beta.responses.connect(
    extra_headers={"OpenAI-Beta": "responses_multi_agent=v1"},
) as connection:
    run_multi_agent(connection)

Lies nach dem Senden eines response.inject-Ereignisses weiter aus der WebSocket-Verbindung und verarbeite die Bestätigung:

  • response.inject.created: Die Funktionsausgabe wurde zur aktiven Antwort hinzugefügt. Lies weiterhin Ereignisse für diese Antwort.
  • response.inject.failed mit response_already_completed: Die Antwort wurde abgeschlossen, bevor die Funktionsausgabe hinzugefügt werden konnte. Übernimm den im Fehlerereignis zurückgegebenen Wert von input und sende ihn in einer neuen response.create-Anfrage, die an die abgeschlossene Antwort anknüpft.
  • response.inject.failed mit response_not_found: Der Server konnte die durch response_id identifizierte Antwort nicht finden. Prüfe, ob du die ID verwendest, die du mit response.created erhalten hast.

Ein einzelner Durchlauf mit mehreren Agenten kann sich über mehrere Anfragen an die Responses API erstrecken. Wenn ein Agent über HTTP eine selbst definierte Funktion aufruft, führt deine Anwendung diese aus und übermittelt ihre Ausgabe in einem neuen response.create-Aufruf. Über WebSocket fügt deine Anwendung die Funktionsausgabe stattdessen in die aktive Antwort ein.

Neue Ausgabeelemente für mehrere Agenten

Antworten mit mehreren Agenten können drei zusätzliche Typen von Ausgabeelementen enthalten:

  • multi_agent_call: protokolliert eine gehostete Aktion für mehrere Agenten, etwa spawn_agent.
  • multi_agent_call_output: enthält das Ergebnis der Ausführung einer gehosteten Aktion.
  • agent_message: übermittelt eine verschlüsselte Nachricht von einem Agenten an einen anderen.

Das Feld call_id verknüpft jedes multi_agent_call-Element mit dem zugehörigen multi_agent_call_output-Element.

Jedes Element enthält außerdem ein agent-Attribut. Bei einem agent_message-Element identifiziert agent.agent_name den empfangenden Agenten. Mit author und recipient kannst du die Richtung der Nachricht nachvollziehen.

Wenn deine Anwendung ein multi_agent_call-Element empfängt, führe es nicht als Funktionsaufruf aus und sende kein Ergebnis zurück. Die Responses API führt die gehostete Aktion aus und gibt das zugehörige multi_agent_call_output-Element zurück. Bewahre beide Elemente auf, wenn deine Anwendung sie für die erneute Wiedergabe oder das Tracing benötigt.

[
  {
    "type": "multi_agent_call",
    "id": "mac_123",
    "call_id": "call_spawn_a",
    "action": "spawn_agent",
    "arguments": "{\"task_name\":\"agent_a\",\"fork_turns\":\"all\",\"message\":\"enc_...\"}",
    "agent": { "agent_name": "/root" }
  },
  {
    "type": "multi_agent_call_output",
    "id": "maco_123",
    "call_id": "call_spawn_a",
    "action": "spawn_agent",
    "output": [
      {
        "type": "output_text",
        "text": "{\"task_name\":\"/root/agent_a\"}",
        "annotations": [],
        "logprobs": []
      }
    ],
    "agent": { "agent_name": "/root" }
  },
  {
    "type": "agent_message",
    "id": "amsg_123",
    "author": "/root/agent_a",
    "recipient": "/root",
    "content": [
      {
        "type": "encrypted_content",
        "encrypted_content": "enc_..."
      }
    ],
    "agent": { "agent_name": "/root" }
  }
]

SSE-Ereignisse, die einem Agenten zugeordnet sind, enthalten auf oberster Ebene ein agent-Attribut. Bei einem agent_message-Ereignis identifiziert agent.agent_name den empfangenden Agenten. Ereignisse im Lebenszyklus einer Antwort wie response.created und response.completed beschreiben die gesamte Antwort und keinen einzelnen Agenten. Deshalb enthalten sie kein agent-Attribut.

{
  "type": "response.output_item.done",
  "agent": { "agent_name": "/root" },
  "item": {
    "type": "agent_message",
    "id": "amsg_123",
    "author": "/root/agent_a",
    "recipient": "/root",
    "content": [
      {
        "type": "encrypted_content",
        "encrypted_content": "enc_..."
      }
    ],
    "agent": { "agent_name": "/root" }
  }
}

Einschränkungen

  1. Compaction (Kontextverdichtung):
    1. Der Endpunkt /responses/compact wird nicht unterstützt, wenn „Mehrere Agenten“ aktiviert ist.
    2. Wenn multi_agent.enabled auf true gesetzt ist, wird die automatische serverseitige Compaction (Kontextverdichtung) implizit aktiviert, auch wenn die Anfrage context_management nicht konfiguriert. Die Compaction (Kontextverdichtung) wird unabhängig auf den Hauptagenten und jeden Subagenten angewendet. Ihre getrennten Kontexte bleiben dabei erhalten. Du kannst compact_threshold weiterhin überschreiben, indem du context_management.compact_threshold explizit in der Anfrage festlegst.
  2. reasoning.summary wird nicht unterstützt, wenn „Mehrere Agenten“ aktiviert ist.
  3. max_tool_calls wird nicht unterstützt, wenn „Mehrere Agenten“ aktiviert ist.
  4. max_concurrent_subagents hat standardmäßig den Wert 3. Das ist die empfohlene Einstellung.

Hinweise zu Prompts

Wenn „Mehrere Agenten“ aktiviert ist, fügen unsere Systeme diese Anweisungen automatisch als neue Entwicklermeldung für den Hauptagenten und die Subagenten hinzu. Du kannst diese Anweisungen weder bearbeiten noch entfernen. Formuliere deine eigenen Entwickleranweisungen als Ergänzung zu diesen automatisch eingefügten Anweisungen.

Hauptagent

You are `/root`, the primary agent in a team of agents collaborating to fulfill the user's goals.

At the start of your turn, you are the active agent.
You can spawn sub-agents to handle subtasks, and those sub-agents can spawn their own sub-agents.
All agents in the team, including the agents that you can assign tasks to, are equally intelligent and capable, and have access to the same set of tools.

You can use `spawn_agent` to create a new agent, `followup_task` to give an existing agent a new task and trigger a turn, and `send_message` to pass a message to a running agent without triggering a turn.
Child agents can also spawn their own sub-agents.
You can decide how much context you want to propagate to your sub-agents with the `fork_turns` parameter.

You will receive messages in the form:
```
Message Type: MESSAGE | FINAL_ANSWER
Task name: <recipient>
Sender: <author>
Payload:
<payload text>
```
They may be addressed as to=/root

There are {max_concurrent_subagents + 1} available concurrency slots, meaning that up to {max_concurrent_subagents + 1} agents can be active at once, including you.

Subagent

You are an agent in a team of agents collaborating to complete a task.

You can spawn sub-agents to handle subtasks, and those sub-agents can spawn their own sub-agents. All agents in the team, including the agents that you can assign tasks to, are equally intelligent and capable, and have access to the same set of tools.

You can use `spawn_agent` to create a new agent, `followup_task` to give an existing agent a new task and trigger a turn, and `send_message` to pass a message to a running agent.
Child agents can also spawn their own sub-agents.

When you provide a response in the final channel, that content is immediately delivered back to your parent agent.

You will receive messages in the form:
```
Message Type: NEW_TASK | MESSAGE | FINAL_ANSWER
Task name: <recipient>
Sender: <author>
Payload:
<payload text>
```
You may also see them addressed as to=/root/..., which indicates your identity is /root/...

There are {max_concurrent_subagents + 1} available concurrency slots, meaning that up to {max_concurrent_subagents + 1} agents can be active at once, including you.