Zum Hauptinhalt springen
Connic
Build

Agent-Typen

Ausführungsmodelle für modellgesteuertes Reasoning, deterministische Tool-Aufrufe und Sequenzen aus mehreren Agenten.

Zuletzt aktualisiert

Das Feld type legt fest, wie ein Agent ausgeführt wird. Connic Composer unterstützt drei Agent-Typen:

  • LLM: Aufgaben, die KI-Reasoning, Dialoge oder komplexe Entscheidungen erfordern
  • Sequential: mehrstufige Workflows, in denen Agenten in einer festen Reihenfolge arbeiten
  • Tool: deterministische Abläufe, die kein KI-Reasoning benötigen
LLM-AgentStandardmäßige KI-Agenten auf Basis von Sprachmodellen

LLM-Agenten verarbeiten Anfragen mit KI-Modellen. Sie können über Eingaben nachdenken, Tools verwenden und natürlichsprachige Antworten erzeugen. Dies ist der Standardtyp. Verwende ihn für Konversations-KI, Reasoning oder die intelligente Auswahl von Tools.

agents/assistant.yaml
version: "1.0"

name: assistant
type: llm  # Default type, can be omitted
model: connic/gpt-5.6-terra  # Connic-managed; no provider key required
description: "A helpful general-purpose assistant"
system_prompt: "You are a helpful assistant. Be concise and accurate."

Erforderlich: model und system_prompt

Sequential-AgentMehrere Agenten zu einer Pipeline verketten

Sequential-Agenten führen eine Kette anderer Agenten der Reihe nach aus. Jeder Agent erhält die Ausgabe des vorherigen Agenten als Input. Verwende sie für mehrstufige Workflows und Daten-Pipelines.

agents/document-pipeline.yaml
version: "1.0"

name: document-pipeline
type: sequential
description: "Processes documents through extraction and validation"

# Agenten werden der Reihe nach ausgeführt und erhalten jeweils den Output des vorherigen Agenten
agents:
  - assistant
  - invoice-processor

Erforderlich: die Liste agents. Jeder Agent muss in einer eigenen YAML-Datei definiert sein.

Tool-AgentEin Tool direkt und ohne KI-Reasoning ausführen

Tool-Agenten führen ein einzelnes Tool mit der eingehenden Payload aus. Da kein KI-Modell beteiligt ist, sind sie schneller und deterministisch. Verwende sie für Berechnungen, Datentransformationen oder API-Aufrufe.

agents/tax-calculator.yaml
version: "1.0"

name: tax-calculator
type: tool
description: "Calculates tax directly using the calculator tool"

# Dieses Tool direkt mit der eingehenden Payload ausführen
tool_name: calculator.calculate_tax

Erforderlich: tool_name. Verweise auf ein eigenes Tool unter tools/, zum Beispiel validation.validate_inquiry. Vordefinierte Tools und api:-Tools können nicht als ausführende Funktion eines Tool-Agenten verwendet werden.

Die Funktion muss den Parameter payload deklarieren und darf context deklarieren; jede andere Signatur wird bei der Deployment-Validierung abgelehnt: def my_tool(payload, context=None). Die Payload wird als einzelnes Dictionary übergeben und nie in einzelne Argumente aufgeteilt. Wenn ein LLM-Agent den Tool-Agenten über trigger_agent erreicht, muss im System-Prompt stehen, was er senden soll.

Vergleich der Typen

FeatureLLMSequentialTool
KI-ModellJaAbhängig von der KetteNein
Verwendet ToolsMehrere ToolsÜber Sub-AgentenEin Tool
GeschwindigkeitAbhängig vom KI-ModellGesamtdauer aller SchritteAm schnellsten
KostenPro TokenGesamtkosten aller SchritteKeine Token-Kosten

Vollständige Beispiele

LLM-Agent mit vollständiger Ausstattung

Ein Agent für die Rechnungsverarbeitung mit mehreren Tools, detaillierten Anweisungen, Wiederholungsversuchen, Reasoning und Guardrails:

agents/invoice-processor.yaml
version: "1.0"

name: invoice-processor
type: llm
model: connic/gemini-3.7-flash
fallback_model: connic/gpt-5.6-terra
description: "Extracts data from invoices and validates totals"
system_prompt: |
  You are an expert accountant specializing in invoice processing.

  Your responsibilities:
  1. Extract all relevant fields from invoices (vendor, date, line items, totals)
  2. Use the calculator tool to verify mathematical accuracy
  3. Flag any discrepancies between line items and totals
  4. Format extracted data in a structured JSON format

  Always double-check calculations before confirming totals are correct.

max_concurrent_runs: 10
max_iterations: 50
temperature: 0.7
reasoning_effort: medium
retry_options:
  attempts: 5
  initial_delay: 10
  max_delay: 60
tools:
  - calculator.add
  - calculator.multiply
  - pdf.extract_text
  - validation.check_totals
guardrails:
  input:
    - type: prompt_injection
      mode: block
    - type: pii
      mode: redact
  output:
    - type: moderation
      mode: block
    - type: system_prompt_leakage
      mode: block

Pipeline für Kundenanfragen

Ein dreistufiger Sequential-Agent für Validierung, Datenbankabfrage und Formatierung der Antwort:

agents/customer-inquiry.yaml
version: "1.0"

name: customer-inquiry
type: sequential
description: "Validate input → fetch account → format response"

agents:
  - validate-inquiry
  - fetch-account
  - format-response

Definiere jeden Schritt als eigenen Agenten:

agents/validate-inquiry.yaml
version: "1.0"

name: validate-inquiry
type: tool
description: "Validate and normalize customer inquiry payload"
tool_name: validation.validate_inquiry
agents/fetch-account.yaml
version: "1.0"

name: fetch-account
type: tool
description: "Lookup account details from Postgres"
tool_name: postgres.fetch_user_account
agents/format-response.yaml
version: "1.0"

name: format-response
type: llm
model: connic/gpt-5.6-terra
description: "Format a helpful customer response"
system_prompt: |
  You receive validated inquiry data plus account details.
  Respond concisely and include next steps when relevant.

Erstelle middleware/validate-inquiry.py, um Middleware vor und nach validate-inquiry auszuführen. Tool Hooks verwenden hooks/validate-inquiry.py. Beides erfordert keine YAML-Konfiguration.