githubsecuritylab/seclab-taskflow-agentFramework multi-agents compatible MCP pour des workflows agentiques déclaratifs pilotés par YAML, utilisé pour l'audit de code assisté par IA, le triage des vulnérabilités et la recherche en sécurité avec intégration CodeQL.
L'Agent Taskflow du Security Lab est un framework multi-Agent compatible MCP pour des workflows agentiques déclaratifs pilotés par YAML.
Construit au-dessus du OpenAI Agents SDK, il utilise Pydantic pour la validation de grammaire et Jinja2 pour le rendu de templates.
L'Agent Taskflow s'appuie sur une grammaire basée sur YAML, à la manière des GitHub Workflows, pour exécuter une série de tâches à l'aide d'un ensemble d'Agents.
Sa principale proposition de valeur est d'être un outil en ligne de commande qui permet aux utilisateurs de définir et scripter rapidement des workflows agentiques sans avoir à écrire de code.
Les Agents sont définis via des personnalités, qui reçoivent une tâche à accomplir, avec un ensemble d'outils.
Les Agents peuvent coopérer pour accomplir des séquences de tâches via ce que l'on appelle des taskflows.
Vous trouverez un aperçu détaillé de la grammaire des taskflows ici et des exemples de taskflows ici.
┌─────────────────────────────────────────────────────┐
│ 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
L'agent prend en charge à la fois les API OpenAI Chat Completions et Responses.
Le type d'API peut être configuré globalement ou par modèle dans un fichier model_config :
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
Les model_settings par modèle peuvent inclure :
api_type — "chat_completions" (par défaut) ou "responses"endpoint — remplacement de l'URL de base de l'API pour ce modèletoken — nom d'une variable d'environnement contenant la clé APILe runner peut piloter trois SDK derrière une interface commune :
openai_agents (par défaut) — le SDK Python OpenAI Agents. Prend en charge
les transferts multi-personnalités, les deux api_type chat_completions et
responses, temperature, parallel_tool_calls,
exclude_from_context, et MCP via stdio, SSE et HTTP streamable.copilot_sdk — le SDK Python GitHub Copilot. Prend en charge le streaming,
reasoning_effort, MCP via stdio/SSE/HTTP, et le contrôle des permissions
par outil. Le SDK sélectionne son propre protocole de communication par modèle,
donc le champ YAML api_type n'est pas honoré ; les transferts
multi-personnalités, temperature et parallel_tool_calls ne sont
pas non plus disponibles. Les taskflows qui utilisent des champs non pris en
charge échouent au chargement avec une BackendCapabilityError nommant le
champ fautif.anthropic_sdk — le SDK Python Anthropic, pilotant l'API native
Messages (/v1/messages). Prend en charge le streaming, l'appel d'outils via
MCP, et la réflexion adaptative avec reasoning.effort configurable
(low, medium, high, max). Les transferts ne sont pas pris en charge.
Conçu pour être utilisé avec le point de terminaison Anthropic de CAPI ;
l'authentification utilise Authorization: Bearer (et non x-api-key).Ordre de priorité de sélection (du plus élevé au plus faible) :
backend: par tâche dans le bloc model_settings de la tâche elle-même (remplace
la valeur au niveau du modèle pour cette tâche ; voir _resolve_task_model()).backend: par modèle dans le model_settings de la configuration du modèle (permet
de mélanger les backends dans un seul taskflow).backend: au niveau supérieur du document de configuration du modèle
(valeur par défaut globale).SECLAB_TASKFLOW_BACKEND.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
Les exécutions de Taskflow sont automatiquement sauvegardées au niveau des tâches. Si une tâche échoue après avoir épuisé les tentatives, la session est sauvegardée et peut être reprise :
** 🤖💾 Session saved: abc123def456
** 🤖💡 Resume with: --resume abc123def456
Reprendre à partir du dernier point de contrôle réussi :
python -m seclab_taskflow_agent --resume abc123def456
Le point de contrôle de session conserve la valeur --model-config fournie par la CLI (le cas échéant), de sorte que les reprises utilisent la même configuration de modèle par défaut. Pour remplacer la configuration du modèle lors d'une reprise, passez explicitement --model-config / -m :
python -m seclab_taskflow_agent --resume abc123def456 -m examples.model_configs.responses_api
Les tâches échouées sont automatiquement réessayées jusqu'à 3 fois avec un backoff croissant avant que la session ne soit sauvegardée. Les points de contrôle de session sont stockés dans le répertoire de données d'application spécifique à la plateforme.
Chaque exécution produit un manifeste lisible par machine résumant ce qui s'est passé :
statut par tâche (ok / failed / skipped), les modèles sur lesquels chaque tâche a été exécutée,
le timing, et les outputs nommés que chaque tâche a produits (y compris les enregistrements
de fan-in par modèle pour les tâches multi-modèles). Il ne contient aucun endpoint ni token.