githubsecuritylab/seclab-taskflow-agentMCP-fähiges Multi-Agenten-Framework für deklarative, YAML-gesteuerte agentische Workflows, verwendet für KI-gestütztes Code-Auditing, Schwachstellen-Triage und Sicherheitsforschung mit CodeQL-Integration.
Der Security Lab Taskflow Agent ist ein MCP-fähiges Multi-Agent-Framework für deklarative, YAML-gesteuerte agentische Workflows.
Er baut auf dem OpenAI Agents SDK auf, verwendet Pydantic zur Grammatikvalidierung und Jinja2 zum Template-Rendering.
Der Taskflow Agent nutzt eine an GitHub Workflows angelehnte YAML-basierte Grammatik, um eine Reihe von Aufgaben mit einer Gruppe von Agents auszuführen.
Sein Hauptnutzen liegt in der Bereitstellung als CLI-Tool, mit dem Benutzer schnell agentische Workflows definieren und skripten können, ohne Code schreiben zu müssen.
Agents werden über Personalities definiert, die eine Aufgabe erhalten, die sie mit einer Reihe von Tools erledigen.
Agents können zusammenarbeiten, um Aufgabenfolgen durch sogenannte Taskflows abzuschließen.
Eine detaillierte Übersicht über die Taskflow-Grammatik finden Sie hier und Beispiel-Taskflows hier.
┌─────────────────────────────────────────────────────┐
│ CLI (cli.py) │
│ Typer-based entry point: -p, -t, -l, -g, -m, --resume, --lint│
└─────────────────────┬───────────────────────────────┘
│
┌─────────────────────▼───────────────────────────────┐
│ Runner (runner.py) │
│ Taskflow execution loop, model resolution, │
│ template rendering, session checkpointing │
└─────────────────────┬───────────────────────────────┘
│
┌─────────────────────▼───────────────────────────────┐
│ MCP Lifecycle (mcp_lifecycle.py) │
│ Server connection, cleanup, process management │
└─────────────────────┬───────────────────────────────┘
│
┌─────────────────────▼───────────────────────────────┐
│ Agent (agent.py) │
│ TaskAgent wrapper, hooks, OpenAI Agents SDK bridge │
└─────────────────────────────────────────────────────┘
Supporting modules:
models.py — Pydantic v2 grammar models (validation)
session.py — Task-level checkpoint / resume
available_tools.py — YAML resource loader with caching
template_utils.py — Jinja2 template environment
mcp_utils.py — MCP client parameter resolution
mcp_transport.py — MCP transport implementations (stdio, streamable)
mcp_prompt.py — System prompt construction
prompt_parser.py — Legacy prompt argument parser
capi.py — AI API endpoint and token management
path_utils.py — Platform-aware data/log directories
Der Agent unterstützt sowohl die Chat Completions- als auch die Responses-OpenAI-APIs.
Der API-Typ kann global oder pro Modell in einer model_config-Datei konfiguriert werden:
seclab-taskflow-agent:
version: "1.0"
filetype: model_config
api_type: chat_completions # default for all models
models:
gpt_default: gpt-4.1
gpt_responses: gpt-5.1
model_settings:
gpt_responses:
api_type: responses # override for this model
endpoint: https://api.githubcopilot.com
token: CAPI_TOKEN # env var name containing the API key
Pro-Modell kann model_settings Folgendes enthalten:
api_type — "chat_completions" (Standard) oder "responses"endpoint — API-Basis-URL-Überschreibung für dieses Modelltoken — Name einer Umgebungsvariable, die den API-Schlüssel enthältDer Runner kann drei SDKs hinter einer gemeinsamen Schnittstelle steuern:
openai_agents (Standard) — das OpenAI Agents Python SDK. Unterstützt
Multi-Personality-Handoffs, sowohl chat_completions als auch responses
api_type, temperature, parallel_tool_calls,
exclude_from_context und MCP über stdio, SSE und streamable HTTP.copilot_sdk — das GitHub Copilot Python SDK. Unterstützt Streaming,
reasoning_effort, MCP über stdio/SSE/HTTP und Berechtigungssteuerung
pro Tool. Das SDK wählt sein eigenes Wire-Protokoll pro Modell, daher wird
das YAML-Feld api_type nicht berücksichtigt; Multi-Personality-Handoffs,
temperature und parallel_tool_calls sind ebenfalls nicht verfügbar.
Taskflows, die nicht unterstützte Felder verwenden, schlagen beim Laden mit
einem BackendCapabilityError fehl, der das fehlerhafte Feld benennt.anthropic_sdk — das Anthropic Python SDK, das die native
Messages API (/v1/messages) ansteuert. Unterstützt Streaming, Tool-Aufrufe über
MCP und adaptives Denken mit konfigurierbarem reasoning.effort
(low, medium, high, max). Handoffs werden nicht unterstützt.
Entwickelt für die Verwendung mit CAPIs Anthropic-Endpunkt; die Authentifizierung verwendet
Authorization: Bearer (nicht x-api-key).Auswahlpriorität (von höchster zu niedrigster):
backend: im model_settings-Block der Task selbst (überschreibt
den Wert auf Modellebene für diese eine Task; siehe _resolve_task_model()).backend: in den model_settings der Modellkonfiguration (ermöglicht
gemischte Backends in einem einzigen Taskflow).backend:-Feld auf der obersten Ebene des Modellkonfigurationsdokuments
(globaler Standard).SECLAB_TASKFLOW_BACKEND-Umgebungsvariable.openai_agents.seclab-taskflow-agent:
version: "1.0"
filetype: model_config
models:
code_analysis: claude-opus-4.7
general_tasks: gpt-5.4-mini
model_settings:
code_analysis:
api_type: messages
backend: anthropic_sdk
reasoning:
effort: high
general_tasks:
api_type: responses
backend: openai_agents
Taskflow-Läufe werden automatisch auf Aufgabenebene mit Checkpoints versehen. Wenn eine Aufgabe nach Ausschöpfung aller Wiederholungsversuche fehlschlägt, wird die Sitzung gespeichert und kann fortgesetzt werden:
** 🤖💾 Session saved: abc123def456
** 🤖💡 Resume with: --resume abc123def456
Setzen Sie ab dem letzten erfolgreichen Prüfpunkt fort:
python -m seclab_taskflow_agent --resume abc123def456
Der Session-Checkpoint speichert den über die CLI übergebenen --model-config-Wert (falls vorhanden), sodass Resumes standardmäßig dieselbe Modellkonfiguration verwenden. Um die Modellkonfiguration beim Resume zu überschreiben, übergeben Sie --model-config / -m explizit:
python -m seclab_taskflow_agent --resume abc123def456 -m examples.model_configs.responses_api
Fehlgeschlagene Aufgaben werden automatisch bis zu 3 Mal mit zunehmendem Backoff wiederholt, bevor die Sitzung gespeichert wird. Sitzungs-Checkpoints werden im plattformspezifischen Anwendungsdatenverzeichnis gespeichert.
Jeder Lauf erzeugt ein maschinenlesbares Manifest, das zusammenfasst, was passiert ist:
Pro-Aufgabe-Status (ok / failed / skipped), die Modelle, gegen die jede Aufgabe ausgeführt wurde,
Timing und die benannten outputs, die jede Aufgabe erzeugt hat (einschließlich Per-Modell-Fan-in-
Datensätzen für Multi-Modell-Aufgaben). Es enthält keine Endpunkte oder Tokens.
Das Manifest wird in ein laufbezogenes Artefaktverzeichnis geschrieben, wenn ein Lauf beendet oder fehlgeschlagen ist, und kann für jede Sitzung anhand der ID ausgegeben werden: