Aller au contenu principal

C-02 Exécution durable

Brique C: Agents, autonomie, exécution. Version anglaise: C-02-durable-execution

1. Rôle et responsabilités​

Garantit qu'un run survit aux crashs, redémarrages et attentes longues (approbations, timers). Par défaut la durabilité repose sur PostgreSQL : état du run, étapes et checkpoints sont persistés, et AgentLoop.resume(run_id) reprend au dernier checkpoint. L'adaptateur Temporal (enterprise_ai.runtime.temporal.build_workflow) est optionnel pour les déploiements qui exigent des workflows durables côté Temporal.

2. Position dans l'architecture et interactions​

  • Appelants : AgentLoop (SDK Python), runtimes TypeScript, Java et Go via /v1/runs.
  • Persistance : eai.runs, eai.run_steps, eai.checkpoints, eai.run_events ; le worker serveur python -m eai.worker détecte les heartbeats périmés.
  • Reprise : POST /v1/runs/{id}/resume côté API, AgentLoop.resume(run_id) côté moteur.

3. Composant open source et partie développée​

  • Moteur : architecture Navin du SDK Python, sans graphe déclaré. enterprise_ai.loop.AgentLoop reçoit les messages, prépare le contexte, gère les sessions, reprend un run après un crash, traite l'arrêt, le cron et le heartbeat, et expose serve() ; enterprise_ai.runtime.AgentRunner exécute un tour ; enterprise_ai.subagents.SubagentManager lance les sous-agents en parallèle ; enterprise_ai.loop.plan.RunPlan porte le plan ; enterprise_ai.runtime.bus.MessageBus relie canaux et moteur.
  • Adaptateurs optionnels : LangGraph (enterprise_ai.runtime.langgraph.build_graph) et Temporal (enterprise_ai.runtime.temporal.build_workflow) réutilisent les mêmes étapes ; ils ne sont pas requis.
  • Côté serveur, python -m eai.worker exécute les tâches périodiques : tick du scheduler, vidage de l'outbox d'événements, expiration des réservations de quota, détection des heartbeats périmés, rétention.
  • Open source optionnel : Temporal (adaptateur eai/integrations/temporal.py côté serveur, enterprise_ai.runtime.temporal côté SDK).

4. Modèle de données​

Tables (schéma eai, RLS tenant_id):

  • eai.runs
  • eai.run_steps
  • eai.checkpoints

Colonnes communes : id uuid, tenant_id uuid NOT NULL, created_at, updated_at ; politique RLS current_setting('app.tenant_id', true)::uuid.

5. Contrat​

  • Contrat appliqué: execution-contract
  • Schéma JSON: contracts/v1/execution-contract.schema.json
  • Champs clés: state, retry_policy, resume, errors, steps[]
  • Validation : POST /v1/contracts/{name}/validate ; application d'un manifeste : POST /v1/manifests/apply.

6. Endpoints API​

  • POST /v1/runs/{id}/resume
  • POST /v1/runs/{id}/cancel
  • GET /v1/runs/{id}

Requête POST /v1/runs/{id}/resume:

{
  "from_checkpoint": "chk_0042",
  "reason": "worker restart"
}

Réponse:

{
  "run_id": "run_01J9",
  "state": "running",
  "resume": {
    "checkpoint_id": "chk_0042",
    "attempt": 2
  }
}

7. Exemples SDK​

Python:

from enterprise_ai import EnterpriseAI

client = EnterpriseAI(base_url="<control-plane-url>", api_key="eai_xxx_secret")
client.runs.resume("run_01J9", checkpoint_id="chk_0042")

TypeScript:

import { EnterpriseAI } from "@enterprise-ai/sdk";

const client = new EnterpriseAI({ baseUrl: "<control-plane-url>", apiKey: process.env.EAI_API_KEY });
await client.runs.resume("run_01J9", { checkpoint_id: "chk_0042" });

Java:

EnterpriseAIClient client = EnterpriseAIClient.builder()
    .baseUrl("<control-plane-url>")
    .apiKey(System.getenv("EAI_API_KEY"))
    .build();
client.runs().resume("run_01J9");

Go:

c, _ := eai.NewClient(eai.WithBaseURL("<control-plane-url>"), eai.WithAPIKey(os.Getenv("EAI_API_KEY")))
c.Runs.Resume(ctx, "run_01J9")

8. Configuration​

  • Variables d'environnement : EAI_DATABASE_URL, EAI_TEMPORAL_URL, EAI_TEMPORAL_NAMESPACE, EAI_TEMPORAL_TASK_QUEUE (adaptateur Temporal optionnel)
  • Clés Helm : controlPlane.config, worker.enabled

9. Contrôles de sécurité​

  • mTLS entre le worker serveur, le Control Plane et, si l'adaptateur est activé, Temporal
  • Payloads chiffrés par codec (E-04)
  • Isolation par namespace et tenant_id
  • Toutes les requêtes portent le tenant issu du credential ; RLS PostgreSQL
  • Chaque mutation et décision de politique écrit un événement d'audit chaîné

10. Observabilité​

  • Métriques Prometheus: eai_workflow_retries_total, eai_workflow_resume_total, temporal_workflow_failed
  • Traces: spans OpenTelemetry avec conventions sémantiques GenAI (gen_ai.operation.name, gen_ai.agent.id, gen_ai.tool.name), attributs eai.tenant_id, eai.run_id, propagation traceparent.
  • Actions d'audit: run.transition

11. Unités FinOps​

  • Durée d'activité worker, nombre de reprises.
  • Émis comme Usage Event (POST /v1/finops/usage) avec tenant, projet, agent et run.

12. Modes de défaillance et résilience​

  • Crash du processus : reprise au dernier checkpoint par AgentLoop.resume(run_id)
  • Temporal non configuré : la durabilité PostgreSQL reste active, sans dépendance externe
  • Heartbeat absent au-delà de EAI_HEARTBEAT_STALE_SECONDS : le run apparaît dans GET /v1/heartbeats et le worker le signale

13. Adoption autonome (client d'un client)​

  • enterprise_ai.agent + enterprise_ai.loop + Control Plane + PostgreSQL ; Temporal optionnel (EAI_TEMPORAL_URL).
  • SDK: enterprise_ai.agent (AgentsClient, RunsClient, SessionsClient)
  • Déploiement minimal : chart Helm avec controlPlane.enabled=true et PostgreSQL ; composants externes désactivés utilisent leur repli in-process.

14. Tests d'acceptation​

  1. Tuer le worker en cours d'étape : le run reprend
  2. Annulation transmise par signal : état cancelled
  3. Accès inter-tenant refusé
  4. Erreur renvoyée en fr avec Accept-Language: fr

Preuve kit L3​

Temporal réel : l'adaptateur eai.integrations.temporal démarre un workflow durable par l'API HTTP (start_workflow, describe_workflow, workflow_result). Preuve : tests/test_runtime_temporal_durable.py lance temporal server start-dev sur des ports libres, tue le worker au milieu de l'étape 2, un nouveau worker reprend depuis l'historique : l'étape 1 n'est exécutée qu'une fois, résultat final vérifié. Outils : tools/runtime/fetch.sh (CLI temporal 1.9.1, temporalio 1.18.2 dans /tmp/toolchains/temporal-venv). NATS JetStream : publish_event pose Nats-Msg-Id (doublon écarté dans la fenêtre), IdempotentHandler applique chaque événement une seule fois, même après une relivraison ; preuve tests/test_runtime_nats_jetstream.py (nats-server 2.15.2).