DeepSeek V4 Pro API: Function Calling nutzen

DeepSeek hat V4 Pro am 12. August 2026 aus der Vorschauphase entlassen, und die Berichterstattung zur Markteinführung hebt agentische Arbeitsabläufe hervor: Codierung, Tool-Nutzung und Langzeitaufgaben, die Dutzende von Schritten miteinander verketten, ohne den Faden zu verlieren. Diese Positionierung lässt ein API-Feature wichtiger erscheinen als jedes andere, nämlich die Funktionsaufrufe, und es ist genau die Funktion, die in den Leitfäden der Startwoche noch nicht behandelt wurde. Jedes Tutorial endet bisher bei Chat-Vervollständigungen.

Dieser Artikel geht weiter: Definieren Sie ein Tool-Schema, führen Sie Ihren ersten Tool-Aufruf mit dem Standard-Python-openai-SDK durch, erstellen Sie den vollständigen Agenten-Loop und testen Sie das Ganze dann in Apidog, bevor Ihr Agent in Betrieb genommen wird. Falls Sie noch keinen DeepSeek API-Schlüssel haben, richten Sie ihn mit unserem Leitfaden zur Nutzung der DeepSeek V4 API ein, und kommen Sie dann hierher zurück.

Button

Kurzfassung

deepseek-v4-pro (GA-Build DeepSeek-V4-Pro-0813) unterstützt Funktionsaufrufe im OpenAI-Stil: Senden Sie ein tools-Array, empfangen Sie tool_calls, geben Sie Ergebnisse als tool-Nachrichten zurück. Das Standard-openai-SDK funktioniert mit https://api.deepseek.com.
Der vollständige Agenten-Loop besteht aus etwa 30 Zeilen Python: aufrufen, ausführen, anhängen, wiederholen, bis das Modell keine Tools mehr anfordert. Parallele Aufrufe und strukturierte Ausgaben werden unterstützt; der Denkmodus fügt reasoning_content hinzu.
Die automatische Präfix-Zwischenspeicherung berechnet den Cache-Hit-Eingang mit 0,003625 $ pro Million Tokens, 120-mal günstiger als ein Miss. Das macht tiefe Agenten-Loops erschwinglich.
Die Qualität der Tool-Aufrufe variiert je nach Ihrem Harness und den Schemas. Testen Sie Ihre tatsächlichen Tools mit dem Live-Modell, nicht mit Benchmarks.

Warum Tool-Aufrufe der Hauptanwendungsfall von V4 Pro sind

DeepSeek hat V4 Pro für Agenten entwickelt, und das Datenblatt liest sich wie eine Checkliste für Agenten-Runtime:

Spezifikation	DeepSeek V4 Pro
Architektur	Sparse MoE: 1,6 T Gesamtparameter, 49 Mrd. aktiv pro Token
Kontextfenster	1 Mio. Tokens
Maximale Ausgabe	384.000 Tokens
Eingabepreis	0,435 $/M Tokens (Cache Miss), 0,003625 $/M (Cache Hit)
Ausgabepreis	0,87 $/M Tokens
Funktionsaufrufe	OpenAI-kompatibles `tools`-Array und `tool_calls`-Antworten
Weitere Oberflächen	Anthropic Messages-Format, DeepSeek Responses API

Jede Zeile entspricht einem Agentenproblem: Das 1-Millionen-Token-Fenster speichert die gesamte Tool-Ergebnishistorie eines langen Agenten, die 384.000-Token-Ausgabegrenze lässt Raum für große strukturierte Payloads, und die Präfix-Zwischenspeicherung macht die Schleifenökonomie praktikabel. Das Modell ist auf OpenRouter als deepseek-v4-pro-0813 für Anbietervergleiche gelistet.

Ein Hinweis vor dem Code. In der Hacker News Launch-Diskussion berichteten Entwickler, dass die Leistung von Tool-Aufrufen stark von der Implementierung abhängt: Dasselbe Modell schnitt je nach Framework, Prompt-Struktur und Schema-Stil besser oder schlechter ab. Benchmarks sagen Ihnen nicht, wie es mit *Ihren* Tool-Schemas umgeht. Testen Sie mit Ihren tatsächlichen Definitionen.

Wie DeepSeek-Funktionsaufrufe funktionieren

Funktionsaufrufe bedeuten nicht, dass das Modell etwas ausführt. Es antwortet mit einer strukturierten Anfrage, „rufe `get_order` mit `{\"order_id\": \"ORD-10442\"}` auf“, anstatt mit Prosa. Ihr Code führt die Funktion aus, gibt das Ergebnis zurück, und das Modell fährt mit echten Daten fort. Der Zyklus:

Sie senden messages plus ein tools-Array, das jede Funktion im JSON-Schema beschreibt.
Das Modell entscheidet, dass ein Tool benötigt wird, und antwortet mit tool_calls und finish_reason: "tool_calls".
Ihr Code parst die Argumente und führt die eigentliche Funktion aus.
Sie fügen das Ergebnis als role: "tool"-Nachricht hinzu, die mit der ID des Aufrufs verknüpft ist.
Das Modell fordert entweder ein weiteres Tool an oder liefert seine endgültige Antwort.

Wenn Sie mit OpenAI-Funktionsaufrufen gearbeitet haben, ist dies dasselbe Wire-Format; die meisten Agenten-Codes lassen sich durch Ändern der Basis-URL und des Modellnamens portieren. Die offizielle DeepSeek-Dokumentation behandelt auch einen Anthropic-kompatiblen Messages-Endpunkt und eine Responses-API, aber dieser Leitfaden konzentriert sich auf die OpenAI-kompatible Oberfläche.

Schritt 1: Client einrichten

Installieren Sie das SDK und richten Sie es auf DeepSeek aus:

pip install openai
export DEEPSEEK_API_KEY="sk-..."

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
)

Das ist die gesamte Einrichtung. Jedes Beispiel verwendet model="deepseek-v4-pro", was auf den GA-Build DeepSeek-V4-Pro-0813 verweist.

Schritt 2: Ein Tool-Schema definieren

Wir werden einen Support-Agenten für einen Online-Shop erstellen. Sein erstes Tool sucht Bestellungen nach. Eine Tool-Definition besteht aus drei Teilen: einem Namen, einer Beschreibung und einem JSON-Schema für die Parameter.

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_order",
            "description": (
                "Sucht eine Kundenbestellung anhand ihrer ID. Gibt den Bestellstatus, "
                "den Spediteur, die Sendungsverfolgungsnummer und das voraussichtliche Lieferdatum zurück. "
                "Verwenden Sie dies immer dann, wenn der Benutzer fragt, wo sich eine Bestellung befindet oder "
                "in welchem Zustand sie sich befindet."
            ),
            "parameters": {
                "type": "object",
                "properties": {
                    "order_id": {
                        "type": "string",
                        "description": "Die Bestell-ID, formatiert wie 'ORD-10442'.",
                    }
                },
                "required": ["order_id"],
            },
        },
    }
]

Die Beschreibung ist keine Zierde: Das Modell entscheidet anhand dieser Beschreibung, wann ein Tool aufgerufen werden soll. Vage Beschreibungen sind der Hauptgrund, warum ein Modell ein Tool ignoriert oder das falsche auswählt.

Die lokale Funktion, die das Schema beschreibt, als Stub für einen echten Bestellservice:

def get_order(order_id: str) -> dict:
    """Stub für Ihren echten Bestellservice."""
    fake_db = {
        "ORD-10442": {
            "status": "shipped",
            "carrier": "DHL",
            "tracking_number": "4281337005",
            "estimated_delivery": "2026-08-15",
        },
        "ORD-10587": {
            "status": "processing",
            "estimated_ship_date": "2026-08-14",
        },
    }
    return fake_db.get(order_id, {"error": f"Unbekannte Bestell-ID: {order_id}"})

Schritt 3: Ihren ersten Tool-Aufruf tätigen

Senden Sie eine Frage, die das Modell ohne das Tool nicht beantworten kann:

messages = [
    {"role": "system", "content": "Sie sind ein Support-Agent für einen Online-Shop."},
    {"role": "user", "content": "Wo ist meine Bestellung ORD-10442?"},
]

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=messages,
    tools=tools,
)

message = response.choices[0].message
print(message.tool_calls[0].function.name) # get_order
print(message.tool_calls[0].function.arguments) # {"order_id": "ORD-10442"}

Anstatt zu antworten, fordert das Modell Sie auf, `get_order` auszuführen. Die rohe Antwort-Payload sieht so aus:

{
  "id": "chatcmpl-8f3a1c",
  "object": "chat.completion",
  "model": "deepseek-v4-pro",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "",
        "tool_calls": [
          {
            "id": "call_0_f1c29a44",
            "type": "function",
            "function": {
              "name": "get_order",
              "arguments": "{\"order_id\": \"ORD-10442\"}"
            }
          }
        ]
      },
      "finish_reason": "tool_calls"
    }
  ],
  "usage": {
    "prompt_tokens": 312,
    "completion_tokens": 24,
    "total_tokens": 336,
    "prompt_cache_hit_tokens": 0,
    "prompt_cache_miss_tokens": 312
  }
}

Drei Details sind wichtig. `finish_reason` ist `"tool_calls"`, was Ihrem Loop mitteilt, dass das Modell eine Ausführung wünscht. Jeder Aufruf enthält eine `id`, die Sie mit dem Ergebnis zurückgeben müssen. Und `arguments` ist ein JSON-*String*, den Sie selbst parsen, erwarten Sie also, dass er gelegentlich fehlerhaft sein kann.

Schritt 4: Die Funktion ausführen und das Ergebnis zurückgeben

Führen Sie die Funktion aus und hängen Sie dann zwei Nachrichten an: den Assistant-Zug, der `tool_calls` enthält, und eine `tool`-Nachricht, die Ihr Ergebnis enthält.

import json

tool_call = message.tool_calls[0]
args = json.loads(tool_call.function.arguments)
result = get_order(args)

messages.append(message) # the assistant turn containing tool_calls
messages.append({
    "role": "tool",
    "tool_call_id": tool_call.id, # must match the id from the response
    "content": json.dumps(result),
})

final = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=messages,
    tools=tools,
)
print(final.choices[0].message.content)
# Ihre Bestellung ORD-10442 wurde mit DHL versandt und wird voraussichtlich am
# 15. August 2026 ankommen. Sendungsverfolgungsnummer: 4281337005.

Die Verknüpfung mittels tool_call_id ist strikt: Jeder tool_calls-Eintrag benötigt eine passende tool-Nachricht vor dem nächsten Modellzug, andernfalls schlägt die Anfrage fehl.

Schritt 5: Der vollständige Agenten-Loop

Echte Agenten verketten Aufrufe: Eine Bestellung nachschlagen, eine Rückgaberichtlinie prüfen, eine E-Mail entwerfen, wobei jeder Schritt vom vorherigen abhängt. Das Muster: Das Modell immer wieder aufrufen und alles ausführen, was es anfordert, bis es eine normale Antwort zurückgibt.

TOOLS_BY_NAME = {"get_order": get_order}

def run_agent(client, messages, tools, max_rounds=10):
    """Führt das Modell aus, bis es eine endgültige Antwort produziert oder das Limit erreicht."""
    for _ in range(max_rounds):
        response = client.chat.completions.create(
            model="deepseek-v4-pro",
            messages=messages,
            tools=tools,
        )
        message = response.choices[0].message
        messages.append(message)

        if not message.tool_calls: # keine Tool-Anfragen: wir sind fertig
            return message.content

        for tool_call in message.tool_calls:
            fn = TOOLS_BY_NAME.get(tool_call.function.name)
            try:
                if fn is None:
                    raise ValueError(f"Unbekanntes Tool: {tool_call.function.name}")
                args = json.loads(tool_call.function.arguments)
                result = fn(args)
            except Exception as exc:
                result = {"error": str(exc)} # Fehler an das Modell zurückmelden
            messages.append({
                "role": "tool",
                "tool_call_id": tool_call.id,
                "content": json.dumps(result),
            })

    raise RuntimeError(f"Agent hat nicht innerhalb von {max_rounds} Runden abgeschlossen")

Frameworks und Agenten-SDKs sind Ausarbeitungen dieses Loops. Die `max_rounds`-Begrenzung wandelt ein Modell, das sich bei einem fehlschlagenden Tool-Aufruf festfährt, in einen sauberen Fehler um, anstatt in eine offene Rechnung.

Parallele Tool-Aufrufe

Fragen Sie nach zwei Nachschlagevorgängen, „vergleiche den Status von ORD-10442 und ORD-10587“, und V4 Pro wird oft beide in einem Durchgang zusammenfassen:

"tool_calls": [
  {
    "id": "call_0_a7d1",
    "type": "function",
    "function": { "name": "get_order", "arguments": "{\"order_id\": \"ORD-10442\"}" }
  },
  {
    "id": "call_1_b3e9",
    "type": "function",
    "function": { "name": "get_order", "arguments": "{\"order_id\": \"ORD-10587\"}" }
  }
]

Der `run_agent`-Loop handhabt dies bereits: die innere `for`-Schleife beantwortet jeden Aufruf mit seiner eigenen `tool_call_id` (jeder Aufruf benötigt ein passendes Ergebnis vor dem nächsten Zug), und Sie können den Batch gleichzeitig ausführen. Dies ist eine andere Philosophie als GPT-5.6s programmatische Tool-Aufrufe, bei der das Modell Orchestrierungscode in einer Sandbox schreibt; DeepSeek behält die Ausführung und die Vertrauensgrenze in Ihrer Laufzeitumgebung.

Denkmodus plus Tools

V4 Pro bietet drei Denkmodi, sodass Sie den Aufwand für die Argumentation bei schwierigen Planungsrunden erhöhen und ihn bei Routineabfragen überspringen können (siehe die offizielle Dokumentation für Modusnamen und Standardwerte). Wenn das Denken aktiviert ist, gibt die API die Spur des Modells als `reasoning_content` zusammen mit allen Tool-Aufrufen zurück:

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=messages,
    tools=tools,
    extra_body={"thinking": {"type": "enabled"}},
)

message = response.choices[0].message
print(message.reasoning_content) # die Planungsspur
print(message.tool_calls) # die Aufrufe, auf die es sich geeinigt hat

Die Spur zeigt, warum das Modell ein Tool ausgewählt hat, was normalerweise der Punkt ist, an dem sich ein schlechtes Schema offenbart. Entfernen Sie reasoning_content, bevor Sie den Assistant-Turn zur Historie hinzufügen, und reservieren Sie das Denken für planungsintensive Turns, da Reasoning als Ausgabe mit 0,87 $/M berechnet wird.

Fehlerbehandlung: Wenn das Modell einen Aufruf falsch ausführt

Fehlerhafte Tool-Aufrufe sind selten, aber ein Agenten-Loop verstärkt jeden Fehlermodus. Das wesentliche Muster: Nie bei einem fehlerhaften Aufruf abstürzen, das Problem als Tool-Ergebnis zurückgeben und das Modell es erneut versuchen lassen. Das deckt sowohl Argumente ab, die bei `json.loads` fehlschlagen, als auch Werte, die Ihre Geschäftsregeln verletzen:

from jsonschema import ValidationError, validate

schema = tools[0]["function"]["parameters"]

try:
    args = json.loads(tool_call.function.arguments)
    validate(instance=args, schema=schema)
    result = get_order(**args)
except (json.JSONDecodeError, ValidationError) as exc:
    result = {
        "error": f"Ungültige Argumente: {exc}",
        "hint": "Rufen Sie get_order erneut mit einem order_id-String wie 'ORD-10442' auf.",
    }

Das Feld hint ist wichtig: Eine einzeilige Korrektur führt in der Regel zu einem korrigierten Wiederholungsversuch in der nächsten Runde. Behandeln Sie Agentenfehler auch als Sicherheitsereignisse. Ein Modell, das dazu gebracht wird, delete_order mit vom Angreifer gelieferten Argumenten aufzurufen, ist nur so gefährlich wie der dahinterliegende Schlüssel, was für API-Schlüssel mit geringsten Berechtigungen für KI-Agenten spricht. Begrenzen Sie die Anmeldeinformationen, damit ein falscher Aufruf nicht zu einem Zwischenfall werden kann.

Tool-Aufrufe mit Apidog testen und debuggen, bevor Sie sie bereitstellen

Jedes Tool ist ein dünner Wrapper um eine API, und das Modell ist nun ein Konsument dieser API. Wenn der zugrunde liegende Endpunkt mehrdeutig oder fehlerhaft ist, übernimmt das Modell all dies. Hier verdient Apidog seinen Platz im Loop:

Entwerfen Sie zuerst die zugrunde liegende API. Definieren Sie GET /orders/{order_id} als Spezifikation in Apidogs visuellem Designer; das JSON-Schema Ihres Tools ergibt sich direkt aus der Spezifikation, sodass die beiden nicht unbemerkt auseinanderdriften können.
Mocken Sie es, bevor das Backend existiert. Apidogs intelligenter Mock-Server liefert realistische Antworten aus dem Schema, sodass der Agenten-Loop gegen get_order läuft, während der eigentliche Dienst noch aufgebaut wird.
Überprüfen Sie die Roh-Payloads. Senden Sie denselben messages + tools-Body von Apidog an https://api.deepseek.com und lesen Sie das rohe tool_calls-JSON direkt; eine falsch verschachtelte properties oder doppelt kodierte Argumente werden bei einer einzigen Überprüfung sichtbar.
Verwandeln Sie Konversationen in Testszenarien. Überprüfen Sie finish_reason und Argumentformen und führen Sie die Suite bei jeder Schemaänderung aus; angesichts der auf Hacker News berichteten Harness-Empfindlichkeit ist eine Regressionssuite über Ihre realen Schemas der Benchmark, der die Produktion vorhersagt. Siehe Einen KI-Agenten in ein Apidog-Testharness einbinden für ein tieferes Muster.

Laden Sie Apidog kostenlos herunter, um mitzumachen; der Mock-Server und die Testszenarien sind im kostenlosen Tarif enthalten.

Was Agenten-Loops kosten (und warum das Caching darüber entscheidet)

Agenten-Loops lesen die gesamte Konversation in jeder Runde erneut: In Runde zehn werden Ihr System-Prompt, Tool-Schemas und neun Runden von Ergebnissen zum zehnten Mal abgerechnet. Die automatische Präfix-Zwischenspeicherung von V4 Pro durchbricht diese Kurve; der Input jeder Runde ist der der vorherigen Runde plus ein bisschen mehr, sodass fast das gesamte Präfix mit 0,003625 $/M statt 0,435 $/M abgerechnet wird. Das erneute Lesen einer 100.000-Token-Konversation kostet ungecached etwa 0,0435 $, aber gecached etwa 0,0004 $; prompt_cache_hit_tokens im Nutzungsblock zeigt Ihre tatsächliche Trefferquote an.

Um diese Rate hoch zu halten, mutieren Sie niemals frühere Nachrichten und halten Sie das `tools`-Array über alle Runden hinweg byte-stabil. Unser Primer zu was Prompt-Caching ist, behandelt die Mechanismen. Und wenn `deepseek-v4-flash` mit 0,14 $/0,28 $ verlockend aussieht: Es ist gut für einmalige Tool-Routings, aber es verschlechtert sich bei Loops, die mehr als 10 Aufrufe verketten, sodass Wiederholungsversuche die Einsparungen auffressen; Pro ist die sicherere Standardeinstellung für Agenten.

FAQ

Kosten Tool-Definitionen Tokens?

Ja, das `tools`-Array wird bei jeder Anfrage als Input verwendet. Halten Sie es stabil, und es wird nach der ersten Runde dem gecachten Präfix hinzugefügt, wobei es ab diesem Zeitpunkt zum Cache-Hit-Preis abgerechnet wird.

Kann ich Funktionsaufrufe mit strukturierten Ausgaben kombinieren?

Ja. Ein häufiges Muster: Tools holen die Zwischendaten ab, ein strukturiertes Ausgabeschema formatiert die endgültige Antwort, sodass nachfolgender Code keine Prosa parsen muss.

Zusammenfassung

Funktionsaufrufe auf DeepSeek V4 Pro sind absichtlich unaufregend zu implementieren: OpenAI-kompatible Schemas, ein tool_calls-Array, eine tool-Nachricht mit einer ID. Der Loop in Schritt 5 ist die gesamte Architektur, und die Cache-Hit-Preisgestaltung macht es billiger, als die meisten Teams erwarten. Was Benchmarks Ihnen nicht sagen können, ist, wie sich das Modell mit *Ihren* Schemas verhält. Entwerfen Sie die unterstützenden APIs bewusst, mocken Sie sie frühzeitig und pflegen Sie eine Regressionssuite von Tool-Aufruf-Szenarien in Apidog, damit Schemaänderungen Ihren Agenten nicht unbemerkt lahmlegen können.

Button