Agent Harness, Loop et Graph : trois couches au cœur des agents d’IA fiables
Pourquoi les agents peu fiables manquent généralement d’un élément essentiel : le harnais entourant le modèle, un cycle basé sur des preuves et un graphe explicite, accompagnés de modèles de code et d’une liste de contrôle pour le débogage.
Sources: Harness, Loop, and Graph: What I Learned Building the Same AI Agent Three Different Ways
Noms familiers mais incompris
Les expressions « agent harness engineering » et « loop engineering » apparaissent si souvent dans les publications sociales et les articles de blog qu’elles donnent l’impression d’être comprises. La familiarité est trompeuse, et une petite panne suffit généralement à le révéler.
Imaginez un agent de recherche dont la tâche est de récupérer des articles arXiv, de les synthétiser et de compiler un résumé hebdomadaire. Trois essais se déroulent sans problème. Puis une requête API soumise à une limitation de fréquence échoue silencieusement, sans que le code ne s’en aperçoive, et l’agent commence à inventer des résumés d’articles qu’il n’a jamais ouverts. Le modèle n’y est pour rien, tout comme la requête initiale. Ce qui manque, c’est un moyen pour le code environnant de distinguer un article réellement lu d’une fabrication plausible. Ce manque existe bel et bien, il a un nom, et les ajustements de la requête n’y changent rien.
Créer le même agent à trois reprises permet de mettre en évidence des distinctions concrètes : une première version adaptée à l’environnement, une autre destinée aux boucles de rétroaction, et une troisième pour un contrôle explicite du flux de travail. Ce domaine n’a que dix-huit mois d’existence sous sa forme actuelle, ce qui explique que les noms utilisés soient encore controversés. Cependant, les distinctions sous-jacentes sont réelles et correspondent à des décisions d’ingénierie concrètes. Ainsi, lorsqu’un agent ne fonctionne pas, il indique quel des trois niveaux doit être corrigé en premier.
Un modèle de langage, pris isolément, se contente de traduire du texte en texte. Une mémoire entre les appels n’existe que si vous la fournissez. L’accès aux fichiers, les commandes de shell et les appels API nécessitent tous des infrastructures que quelqu’un doit mettre en place, et le modèle ne peut pas vérifier ses propres réponses sans une vérification externe. Ceux qui développent des agents en 2024 l’ont découvert lorsque une démonstration fluide échouait dès la première action inattendue de l’utilisateur.
Le secteur a réagi en cessant de considérer « l’agent » comme un seul élément. Il s’agit en réalité de trois problèmes d’ingénierie distincts superposés au modèle.
LAYER QUESTION IT ANSWERS FAILS AS
----------------------------------------------------------------------
Harness What can the agent see and touch? Missing tools,
(environment, tools, memory, lost state, blown
permissions, execution limits) budgets, leaks
----------------------------------------------------------------------
Loop How does one attempt turn into a Confident wrong
correct one? (retry, verify, stop) answers, infinite
spinning, silent
failure
----------------------------------------------------------------------
Graph What is the actual shape of the work? Wrong step order,
(sequence, branches, parallel paths, no recovery path,
human checkpoints) no visibility
----------------------------------------------------------------------
Chaque couche est la plus facile à comprendre en construisant sa version la plus simple, en la brisant, puis en consultant les documents de recherche et de framework pour savoir pourquoi elle a échoué.
Le harnais : ce que l’agent peut voir et toucher
La définition la plus claire se trouve dans une note technique de LangChain, qui résume l’idée en une équation : l’agent égale le modèle plus le harnais. Le modèle fournit le raisonnement. Le harnais fournit tout ce dont le raisonnement a besoin pour interagir avec le monde réel, c’est-à-dire des outils, de la mémoire, du contexte, des permissions, ainsi que des contraintes qui l’empêchent de faire quelque chose de coûteux ou de dangereux.
Un modèle mental courant et simpliste pour « fournir des outils à un agent » consiste à écrire quelques fonctions Python et à les décrire dans le prompt du système. Cela convient pour une démonstration, mais cela ne fonctionne pas pour des tâches dépassant la durée d’une fenêtre de contexte, ni pour des appels d’outils qui échouent à 2 heures du matin sans témoin. En pratique, ce cadre s’avère avoir six responsabilités distinctes.
- L’injection de contexte détermine ce que le modèle voit avant chaque étape de raisonnement : le message de l’utilisateur, mais aussi les documents récupérés, les conversations précédentes, l’état du projet et les politiques de l’organisation. Il est facile de surestimer l’importance de ce contexte. Inclure l’ensemble d’un arbre de fichiers ainsi que le journal git dans chaque appel nuit à la précision, car le modèle est submergé par des tokens irrelevants ; un contexte plus restreint et soigneusement sélectionné est généralement supérieur à un contexte plus vaste mais non filtré.
- Les actions transforment une décision en effet concret dans le monde, qu’il s’agisse d’une requête API, d’une commande en ligne de commande, d’une écriture dans une base de données ou d’un clic dans un navigateur. Le Model Context Protocol joue un rôle clé à cet égard, et il a connu de nombreux changements cette année. Il a vu le jour à la fin de 2024 en tant que méthode standard permettant aux agents de trouver et d’invoquer des outils, évitant ainsi aux équipes de devoir créer une intégration personnalisée pour chaque API. D’après les spécifications de juillet 2026, il dispose d’un noyau sans état fonctionnant derrière des balanceurs de charge classiques sans sessions persistantes, d’une extension Tasks d’AWS pour gérer les tâches qui dépassent la durée d’une seule requête, ainsi que d’une autorisation plus stricte basée sur OAuth et OpenID Connect. La source indique plus de dix mille serveurs en production publics et des téléchargements de SDK dépassant 97 millions par mois. Construire aujourd’hui un outil de gestion sur une couche d’outils qui n’est pas MCP ou similaire nécessite une justification solide.
- La persistance désigne tout ce qui doit survivre à une redémarrage, à une panne ou à la fermeture complète d’une fenêtre de contexte, comme les points de contrôle, l’état de session, la mémoire vectorielle et l’historique Git. Le premier agent de recherche ne conservait rien de tout cela, si bien qu’une interruption de connexion effaçait quarante minutes de travail accompli. Écrire un petit point de contrôle JSON après chaque sous-tâche terminée était plus efficace pour assurer la fiabilité que n’importe quelle modification des instructions.
- Le contrôle d’exécution regroupe les règles de tentative répétée, les délais d’attente, les budgets de tokens et de dépenses, le routage des modèles, les limites imposées aux sous-agents générés ainsi que les étapes où une personne doit valider le travail. Sans lui, un agent bloqué dans un cycle d’essais et d’échecs toute la nuit peut transformer une tâche simple en une opération extrêmement complexe.
- La sécurité et la gouvernance concernent l’accès aux outils selon le principe du moindre privilège, la gestion des secrets, le sandboxing, les journaux d’audit et les listes d’autorisation. Le code généré par le modèle doit toujours s’exécuter dans un environnement sandbox. Un agent de codage a été surpris sur le point d’exécuter
rm -rfsur un dossier qu’il avait à tort pris pour un artefact de compilation. Aucune malveillance n’était présente, il s’agissait simplement d’une erreur combinée à des permissions lui permettant de causer des dommages. - L’observabilité comprend les traces, les journaux des appels aux outils, l’utilisation des tokens, la latence et les résultats d’évaluation. Cela semble peu intéressant tant qu’un agent ne se met pas à se comporter de manière anormale en production, sans qu’il n’y ait de trace de ce qu’il a réellement fait par rapport à ce qui était supposé.
Voici un framework minimal mais fonctionnel en Python. Un modèle Ollama local le pilote, il n’est donc pas nécessaire de clé API, et le passage à un modèle hébergé ne nécessite qu’une seule ligne de code.
import json
import subprocess
import requests
from datetime import datetime
OLLAMA_URL = "http://localhost:11434/api/chat"
MODEL = "llama3.1"
# --- Action surface: the only two things this agent is allowed to do ---
def read_file(path: str) -> str:
with open(path, "r") as f:
return f.read()[:4000] # cap it, don't blow the context window
def run_tests() -> str:
result = subprocess.run(
["pytest", "-q"], capture_output=True, text=True, timeout=60
)
return result.stdout[-2000:] + result.stderr[-2000:]
TOOLS = {"read_file": read_file, "run_tests": run_tests}
TOOL_SCHEMA = [
{
"type": "function",
"function": {
"name": "read_file",
"description": "Read a file from the project",
"parameters": {
"type": "object",
"properties": {"path": {"type": "string"}},
"required": ["path"],
},
},
},
{
"type": "function",
"function": {
"name": "run_tests",
"description": "Run the project's pytest suite",
"parameters": {"type": "object", "properties": {}},
},
},
]
# --- Persistence: cheap but real ---
def checkpoint(state: dict, path: str = "checkpoint.json"):
with open(path, "w") as f:
json.dump({**state, "saved_at": datetime.utcnow().isoformat()}, f)
# --- Execution control: hard ceilings, not suggestions ---
MAX_TOOL_CALLS = 8
def harness_run(user_task: str):
messages = [{"role": "user", "content": user_task}]
calls_made = 0
while calls_made < MAX_TOOL_CALLS:
response = requests.post(
OLLAMA_URL,
json={"model": MODEL, "messages": messages, "tools": TOOL_SCHEMA, "stream": False},
).json()
msg = response["message"]
messages.append(msg)
if not msg.get("tool_calls"):
return msg["content"] # model is done, no more tools needed
for call in msg["tool_calls"]:
name = call["function"]["name"]
args = call["function"].get("arguments", {})
if name not in TOOLS:
result = f"error: tool {name} is not permitted"
else:
result = TOOLS[name](**args)
messages.append({"role": "tool", "content": str(result)})
calls_made += 1
checkpoint({"messages": messages, "calls_made": calls_made})
return "stopped: hit the tool call ceiling before finishing"
Rien ici n’est sophistiqué, et c’est justement la leçon : un harness représente une gestion minutieuse autour d’un modèle qui ne tient pas de registre. Pour un modèle hébergé, remplacez le bloc requests.post par une appel via l’SDK d’OpenAI ou d’Anthropic. Le schéma de l’outil ainsi que les mécanismes de sauvegarde restent inchangés, car ils ne dépendent pas de celui qui répond.
Les plaintes selon lesquelles le modèle serait devenu moins intelligent remontent presque toujours au harness. Un outil peut avoir renvoyé des données obsolètes, le contexte peut être encombré d’informations irrelevantes, ou les permissions peuvent être trop larges ou trop restreintes, forçant l’agent à essayer de faire quelque chose à quoi il n’a jamais eu accès. Examinez d’abord le harness avant d’éditer les prompts ou de changer de modèle, car c’est généralement là que réside le problème.
La boucle : comment une tentative devient une bonne tentative
Si le harnais décide de ce que l’agent peut toucher, la boucle détermine comment il passe d’une première tentative à un bon résultat. C’est la couche le plus souvent sous-estimée, car l’idée de « simplement lui permettre de réessayer » semble triviale tant que l’agent ne réessaie pas réellement.
L’échec classique concerne une boucle auto-correctrice qui demande au modèle, après sa réponse, s’il est convaincu que celle-ci est correcte. La réponse est toujours oui. Un modèle qui évalue ses propres réponses sans aucun signal externe se donne presque toujours la note maximale, car il n’y a rien contre quoi il puisse échouer. Il s’agit d’un problème bien documenté et non d’une erreur isolée : une boucle ne disposant d’aucune preuve permettant d’échouer croira toujours avoir réussi.
La solution consiste à cesser de demander au modèle de s’évaluer lui-même et à fournir un arbitre extérieur au cycle : un ensemble de tests avec des résultats positifs ou négatifs, un validateur de schéma, un compilateur, une règle de linting, ou une deuxième recherche indépendante qui confirme ou contredit la première réponse. Les cycles basés sur des preuves prennent en compte l’état du monde, tandis que ceux basés sur la confiance se concentrent sur ce que ressent le modèle.
La technique Ralph Wiggum et pourquoi un cycle rudimentaire fonctionne
Un schéma appelé « Ralph Wiggum » a gagné en popularité après avoir été décrit par l’ingénieur Geoffrey Huntley en 2025. En résumé, il est extrêmement simple : un cycle Bash envoie sans cesse la même requête à un agent de codage jusqu’à ce que la tâche soit terminée, et les progrès sont enregistrés dans des fichiers et des commits Git plutôt que dans la mémoire du modèle concernant la conversation.
#!/bin/bash
# ralph.sh - crude but surprisingly effective
while true; do
claude -p "$(cat PROMPT.md)" --dangerously-skip-permissions
if git diff --quiet HEAD~1 HEAD -- STATUS.md && grep -q "DONE" STATUS.md; then
echo "Task complete."
break
fi
sleep 5
done
On dirait que cela ne devrait pas fonctionner, et après une petite refonte, sa rudesse s’avère être justement son avantage. En éliminant le contexte conversationnel à chaque étape et en forçant l’enregistrement des progrès dans l’historique Git et les fichiers d’état, on évite la dégradation du contexte, et on empêche l’agent de se convaincre qu’il a déjà terminé quelque chose qu’il n’a pas fait. Ce n’est pas élégant. C’est cependant basé sur des preuves par hasard, puisque Git et le système de fichiers ne mentent pas pour flatter le modèle.
Voici un petit cycle du même type, basé sur des preuves, pouvant à nouveau être exécuté localement avec Ollama, qui considère un test échoué comme la seule signification acceptable de « pas encore terminé ».
def evidence_loop(task_description: str, max_attempts: int = 5):
attempt = 0
history = []
while attempt < max_attempts:
attempt += 1
code = generate_patch(task_description, history) # calls the model
apply_patch(code)
test_output = run_tests() # external evidence
passed = "failed" not in test_output.lower()
history.append({
"attempt": attempt,
"patch": code,
"test_output": test_output,
"passed": passed,
})
if passed:
return {"status": "success", "attempts": attempt}
# feed the *actual failure*, not a vague "try again"
task_description = (
f"{task_description}\n\nPrevious attempt failed with:\n{test_output}\n"
"Fix the specific failure above."
)
return {"status": "gave_up", "attempts": attempt, "history": history}
Regardez la dernière ligne avant le retour, car c’est elle qui exprime l’idée principale. La boucle ne dit pas « essayez plus fort ». Elle fournit au modèle l’échec réel du test, car ce sont des preuves concrètes extérieures qui rendent la deuxième tentative meilleure que la première, et non un simple relance aléatoire. Chez la plupart des agents, l’amélioration la plus significative en termes de fiabilité provient du remplacement de « Est-ce que cela a l’air correct ? » par une vérification externe réelle adaptée à la tâche.
Il est également essentiel de savoir quand s’arrêter. Une boucle sans limite stricte en termes de tentatives, de coûts ou de temps n’est pas un agent fiable. C’est un bug qui attend de causer des problèmes.
Le graphe : lorsque la tâche comporte des branches réelles
Une sangle maintient le corps de l’agent et une boucle lui permet d’améliorer ses tentatives au fil du temps, mais aucune de ces deux notions ne décrit une tâche structurée en forme d’arbre : faire ceci, puis choisir l’une de trois actions en fonction du résultat, attendre l’approbation d’un humain, puis exécuter deux vérifications en parallèle et les fusionner.
C’est cela, l’ingénierie de graphes. C’est généralement le niveau auquel les gens s’opposent, car une boucle semble suffisante pendant longtemps, mais elle cesse de l’être lorsque le travail n’est pas une succession linéaire menant à un seul test de validation. Les boucles ne sont bonnes qu’à une chose : essayer, vérifier et réviser jusqu’à ce qu’une condition soit remplie. Elles deviennent gênantes lorsque l’étape suivante dépend du résultat obtenu, lorsque deux sous-tâches peuvent être exécutées simultanément, ou lorsque quelqu’un doit donner son accord avant de poursuivre. Intégrer tout cela dans une seule demande en espérant que le modèle gardera le fil des choses a fonctionné pour certaines équipes, mais c’est fragile. Une fois que la prise de décision par branches devient réelle, le flux de contrôle doit figurer dans une structure explicite, et non dans ce que le modèle improvise à chaque fois.
Le génie de graphes rend le flux de travail explicite. Les nœuds représentent des étapes, telles qu’une appel d’agent, un appel d’outil, un validateur ou un point de contrôle humain, tandis que les arêtes désignent les conditions qui font passer l’exécution d’un nœud à l’autre. En examinant le graphique, on peut voir précisément quel chemin a suivi l’exécution, ce qui est particulièrement important lorsque survient un incident en production à minuit et qu’il faut savoir ce qui s’est réellement passé plutôt que ce que l’on suppose.
LangGraph est généralement le choix privilégié dans ce cas. Il représente un flux de travail sous forme de graphe orienté, transmet des états typés d’un nœud à l’autre, utilise des arêtes conditionnelles pour les branches, et intègre un système de points de contrôle permettant à une exécution d’être arrêtée, redémarrée ou ramenée à un état antérieur.
from langgraph.graph import StateGraph, END
from typing import TypedDict
class AgentState(TypedDict):
task: str
draft: str
review_passed: bool
attempts: int
def draft_node(state: AgentState) -> AgentState:
state["draft"] = generate_draft(state["task"])
return state
def review_node(state: AgentState) -> AgentState:
state["review_passed"] = run_validator(state["draft"])
state["attempts"] += 1
return state
def needs_human(state: AgentState) -> str:
if state["review_passed"]:
return "approved"
if state["attempts"] >= 3:
return "escalate" # branch: give up automating, ask a human
return "retry"
graph = StateGraph(AgentState)
graph.add_node("draft", draft_node)
graph.add_node("review", review_node)
graph.set_entry_point("draft")
graph.add_edge("draft", "review")
graph.add_conditional_edges(
"review",
needs_human,
{"approved": END, "retry": "draft", "escalate": "human_approval"},
)
Un boucle simple a du mal à expliquer facilement ce que fait cet outil : une vérification donnant trois résultats (terminé, essayer à nouveau, s’arrêter et demander de l’aide à une personne), chacun menant vers une direction différente. Le parcours d’escalade est important ; il fait la différence entre un agent qui abandonne silencieusement après une troisième tentative infructueuse et un autre qui transmet à un humain l’historique complet des tentatives effectuées.
AutoGen de Microsoft a ajouté quelque chose de similaire cette année, appelé GraphFlow, pour la même raison. Plusieurs agents ou workflows ramifiés rendent difficile la compréhension d’une boucle implicite, tandis qu’un graphe peut être examiné directement.
Afin de déterminer où chaque framework excelle réellement, plutôt que de se fier aux pages de marketing, quatre d’entre eux ont été testés sur un petit projet : un pipeline de révision de documents comprenant une branche de validation et une étape d’approbation par un humain.
FRAMEWORK ORCHESTRATION MODEL STRONGEST AT STATE / PERSISTENCE
--------------------------------------------------------------------------------------------
LangGraph Directed graph, typed Complex branching, Built-in checkpointing,
state, conditional edges long-running workflows, time-travel debugging
human-in-the-loop
--------------------------------------------------------------------------------------------
CrewAI Role-based "crew" of Fast prototyping, Sequential task output
agents, sequential or multi-agent brainstorm passing, lighter state
hierarchical process style collaboration model
--------------------------------------------------------------------------------------------
OpenAI Agents SDK Explicit agent handoffs Minimal-friction start Ephemeral context
inside the OpenAI variables by default
ecosystem
--------------------------------------------------------------------------------------------
AutoGen / GraphFlow Multi-agent conversation Agent-to-agent Conversation history
plus optional graph layer negotiation, graph- plus graph state
for explicit control based orchestration
--------------------------------------------------------------------------------------------
La leçon à retenir est pratique : si le flux de travail tient sur une page sous forme de liste simple de étapes, aucun framework graphique n’est nécessaire, et une boucle bien conçue au sein d’un cadre solide suffit, avec moins de code à maintenir. Dès que vous dessinez le flux de travail et qu’il comporte des branches, un framework graphique commence à se révéler utile immédiatement, principalement en économisant du temps de débogage plutôt que par des avantages en temps de exécution.
Comment s’empilent les trois couches
Ces approches ne sont pas concurrentes. Elles s’empilent verticalement, et voici à quoi ressemble cette structure une fois que vous avez utilisé les trois.
+--------------------------------------------------------------+
| GRAPH - decides which node runs next, where branches |
| are, where a human has to approve |
+--------------------------------------------------------------+
| LOOP - inside a given node, drives attempt -> verify -> |
| revise until the evidence says stop |
+--------------------------------------------------------------+
| HARNESS - underneath both, provides the tools, memory, |
| permissions, and limits that make any of it |
| possible to execute safely |
+--------------------------------------------------------------+
| MODEL - the reasoning engine none of the above exists |
| without |
+--------------------------------------------------------------+
Dans un flux de travail LangGraph, un nœud de brouillon peut exécuter une boucle basée sur des preuves plusieurs fois avant de transmettre à nouveau le contrôle au graphe. Cette boucle interne ne fonctionne que parce que l’infrastructure sous-jacente permet au modèle d’exécuter des tests, de lire des fichiers et de se remémorer ses tentatives précédentes. Si l’on retire n’importe quel niveau, le reste cesse de fonctionner, ce qui explique pourquoi il était toujours difficile d’améliorer un « agent » monolithique.
Penser en trois niveaux permet d’effectuer le débogage de manière nettement plus rapide. Voici la liste à vérifier, dans l’ordre, avant d’affiner un prompt.
SYMPTOM LIKELY LAYER TO CHECK FIRST
----------------------------------------------------------------------
Agent doesn't know something it should Harness -> context injection
Agent "can't" do something it should be Harness -> action surface /
able to do permissions
Agent forgets earlier progress after a Harness -> persistence
restart or long run
Costs or run time spiral unexpectedly Harness -> execution control
Agent confidently reports success on Loop -> swap confidence checks
work that's actually wrong for external evidence
Agent retries the same mistake Loop -> is it seeing the actual
repeatedly without improving failure, or just "try again"?
Agent takes the wrong path when a task Graph -> is the branching logic
has more than one possible outcome explicit, or implicit in a
single prompt?
No human ever gets a chance to catch a Graph -> is there an approval
bad decision before it ships node, or is it all automatic?
Un tableau comme celui-ci aurait permis d’éviter toute une fin de semaine à consacrer aux reproches envers l’instruction, alors que le problème venait en réalité d’un point de contrôle manquant.
Questions en suspens
Certaines choses restent non résolues, et il serait erroné de conclure en se montrant plus sûr que ne le permettent les preuves.
Tout d’abord, le vocabulaire évolue constamment. L’« ingénierie de harness » n’existait qu’à petite échelle avant cette année, et dans un an, elle pourrait être intégrée à une notion plus large d’« ingénierie d’agent », où les termes harness, loop et graph deviendraient des sous-catégories plutôt que des domaines de spécialisation.
Deuxièmement, l’approche de Ralph Wiggum semble légèrement défaillante, même lorsqu’elle fonctionne. Fournir un seul prompt à un modèle dans une boucle simple et compter sur l’historique Git comme unique mémoire ressemble à un pansement sur un harnais dépourvu de véritable persistance. Elle convient aux refacteurs de petite envergure et à portée restreinte, mais on ne devrait pas encore s’y fier pour des cas impliquant des branches réelles ou des conséquences importantes.
Troisièmement, les frameworks graphiques pourraient encore évoluer. Le système de sauvegarde de LangGraph est excellent, mais les équipes adoptent parfois un framework graphique complet pour un flux en trois étapes qui ne se ramifie jamais, simplement parce que c’est à la mode. Un flux de travail linéaire peut rester linéaire.
Une affirmation résiste à tout cela : un agent peu fiable est presque jamais corrigé par un meilleur prompt. Le problème réside presque toujours dans l’un des trois niveaux, et les questions ci-dessus permettent de déterminer lequel.
Commencer à développer l’agent de recherche dès aujourd’hui signifierait d’abord construire le système de support nécessaire et de le considérer comme une infrastructure de soutien ennuyeuse, plutôt que comme un élément ajouté en dernier. Un cycle basé sur des preuves serait mis en place dès le premier jour, au lieu de se fier à l’évaluation automatique du modèle, car ce seul changement permet de corriger plus de bugs que tout autre. Un cadre graphique attendrait que le flux de travail puisse être représenté sur papier avec des branches visibles.
Le modèle a attiré toute l’attention pendant trois ans, mais la fiabilité en environnement de production provient du travail d’ingénierie qui l’entoure. Ce travail est bien moins spectaculaire et bien plus gérable que l’argument selon lequel le modèle ne serait pas assez intelligent. La plupart du temps, il l’est. Il ne lui a simplement pas été fourni l’environnement, les retours ou les informations nécessaires pour le montrer.
Lectures complémentaires
- Les concepts de LangGraph expliqués simplement : état, mémoire et orchestration — Avant d’écrire du code : ce que signifient l’orchestration, l’exécution en temps réel, les agents à état, la mémoire à court et long terme, ainsi que les systèmes multi-agents et l’intervention humaine dans LangGraph.
- Créer un système DeepAgents Harness : permissions, sous-agents et approbation humaine — Construction pratique d’un outil de planification de conception de système avec DeepAgents : backends de fichiers, règles de permissions, sous-agents, mécanismes d’approbation, compétences et MCP, ainsi que les cas où le jugement du modèle échoue encore.