Le moteur d’exécution DAG de FIM One a été conçu avec une retenue délibérée. Plusieurs modèles courants dans les frameworks multi-agents ont été évalués et intentionnellement exclus. Cette page documente ces décisions et le raisonnement qui les sous-tend.Documentation Index
Fetch the complete documentation index at: https://docs.fim.ai/llms.txt
Use this file to discover all available pages before exploring further.
Remise — Non nécessaire
Motif : Remise explicite de tâche entre agents, où un agent termine son travail et cède le contrôle au suivant. Raison de l’exclusion : Les chaînes linéaires DAG couvrent déjà naturellement la remise de tâche séquentielle. Quand l’étape B dépend de l’étape A, l’exécuteur attend que A se termine, puis transmet le résultat d’A dans le contexte de B via le mécanisme de dépendance. C’est structurellement équivalent à une remise — mais sans nécessiter une couche d’abstraction séparée. Ajouter un protocole de remise explicite dupliquerait ce que les dépendances d’étapes fournissent déjà, sans expressivité supplémentaire.Rétroaction — Non nécessaire
Motif : Les étapes en aval renvoyant les résultats aux étapes en amont pour une réévaluation (également appelée rétropropagation des résultats). Raison de l’exclusion : La boucle de re-planification du PlanAnalyzer couvre déjà ce cas d’usage. Une fois que toutes les étapes sont terminées, l’analyseur évalue si l’objectif initial a été atteint. Si ce n’est pas le cas (et que la confiance est inférieure au seuil d’arrêt), il déclenche une re-planification complète avec le contexte des résultats de la ronde précédente — y compris ce qui s’est mal passé et ce qui a été appris. Il s’agit d’une approche plus grossière mais plus robuste que la rétroaction par étape. La rétroaction par étape crée des boucles de rétroaction complexes qui sont difficiles à déboguer et peuvent entraîner des cycles infinis. La boucle de re-planification réalise le même effet correctif avec un modèle d’exécution plus propre : planifier, exécuter, évaluer, re-planifier si nécessaire.Équipes (Communication inter-agents) — Non nécessaire
Modèle : Plusieurs agents spécialisés communiquant entre eux pendant l’exécution, négociant la propriété des sous-tâches ou collaborant sur un état partagé. Pourquoi exclu : Les chaînes de dépendances DAG sont suffisantes pour les tâches avec dépendances de données. Quand l’étape C a besoin des résultats à la fois de l’étape A et de l’étape B, les arêtes de dépendance expriment cela directement. L’étape C reçoit les sorties de A et B dans son contexte — aucun protocole de messagerie inter-agents requis. Le modèle DAG est plus simple et plus prévisible que la communication agent-à-agent. Les agents n’ont pas besoin de négocier ; le planificateur détermine la structure d’exécution à l’avance, et l’exécuteur applique le flux de données par la résolution des dépendances. Cela évite la surcharge de coordination et la non-déterminisme que la messagerie multi-agents introduit.agent_hint / role_hint — Non nécessaire
Modèle : Un indice explicite indiquant à l’exécuteur quel type d’agent ou de persona devrait gérer chaque étape (par exemple, « utiliser l’agent chercheur » ou « utiliser l’agent codeur »). Pourquoi exclu : La combinaison de trois champs existants fournit déjà des conseils suffisants :task— La description en langage naturel de ce que l’étape doit accomplir. Une tâche bien rédigée signale implicitement l’expertise requise.tool_hint— Suggère quels outils l’étape doit utiliser (par exemple,web_search,python_exec). Cela contraint l’approche d’exécution de manière plus précise qu’une étiquette de rôle vague.model_hint— Contrôle si l’étape utilise le modèle rapide ou le niveau de raisonnement, ce qui est la décision d’exécution la plus impactante.
agent_hint ou role_hint serait redondant avec ces trois champs et introduirait un autre axe de configuration que le LLM planificateur doit maîtriser. Maintenir la surface des indices réduite diminue les erreurs de planification.
Orchestration Multi-Agent Profonde — Stratégiquement Différée
L’exclusion « Teams » ci-dessus est un argument d’ingénierie : les arêtes du DAG expriment déjà les dépendances de données. Cette section ajoute un argument stratégique : la tendance de l’industrie selon laquelle les capacités du modèle absorbent la complexité d’orchestration.Pourquoi les modèles absorbent la couche d’orchestration
Les hiérarchies multi-agents ont émergé comme une solution de contournement aux limitations des modèles — si un modèle ne pouvait pas gérer une tâche complexe, vous la décomposiez entre des agents spécialisés. Chaque génération de modèles de pointe érode cette justification :| Capacité du modèle | Ce qu’il remplace |
|---|---|
| Fenêtres de contexte en expansion (200K → 1M tokens) | Division du contexte entre agents pour tenir dans les limites |
| Réflexion étendue / chaîne de pensée | Pipelines explicites d’agents Planificateur → Exécuteur |
| Boucles natives d’agents (Claude Code, Codex) | Exécution multi-étapes orchestrée par le framework |
| Protocoles multi-agents natifs (Google A2A, OpenAI Swarm) | Coordination d’agents au niveau du framework |
Le coût de la profondeur
Même lorsque les modèles manquent de capacités, les hiérarchies profondes d’agents entraînent des coûts composés :- Multiplication des tokens — chaque niveau d’imbrication réinjecte les invites système et le contexte. À trois niveaux de profondeur, la dépense totale en tokens peut être 5 à 10 fois celle d’une approche à agent unique.
- Accumulation de latence — chaque niveau est un aller-retour LLM complet. Les utilisateurs attendent la chaîne la plus lente.
- Compression lossy de l’information — les agents délégués retournent des résumés, pas des données brutes. Chaque niveau perd en fidélité.
- Opacité du débogage — « quel niveau a mal compris la tâche ? » est presque impossible à diagnostiquer à une profondeur > 2.
Position de FIM One
La délégation à un niveau viaCallAgentTool est le juste équilibre : « Je suis un généraliste, mais cette sous-tâche nécessite l’expert SQL. » Cela couvre la grande majorité des besoins réels de délégation sans les coûts croissants des hiérarchies plus profondes.
L’orchestration multi-agent profonde est reportée indéfiniment — non pas parce qu’elle est difficile à construire, mais parce que la trajectoire des modèles de pointe suggère qu’elle deviendra inutile. La valeur de FIM One réside dans la couche d’approvisionnement en outils (Connecteurs, MCP, Gouvernance), et non dans la profondeur d’orchestration que les modèles internalisent rapidement.