Agents, outils et contexte long¶

Kimi K3 est présenté comme un « modèle agentique multimodal natif ». Ce chapitre définit précisément ce que cela signifie.

Qu'est-ce qu'un agent ?¶

Un modèle de langage seul ne peut rien faire d'autre que produire du texte. Un agent est la combinaison de trois éléments :

┌──────────┐   demande d'action   ┌──────────┐   exécution   ┌─────────────┐
│  MODÈLE  │ ───────────────────► │  HARNAIS │ ────────────► │ ENVIRONNEMENT│
│          │ ◄─────────────────── │          │ ◄──────────── │  (sandbox)   │
└──────────┘     observation      └──────────┘    résultat   └─────────────┘

Le modèle décide quoi faire.
Le harnais (harness, scaffold) est le programme qui exécute réellement les actions et remet les résultats dans le contexte.
L'environnement est ce sur quoi on agit : un terminal, un navigateur, un système de fichiers, une API.

Erreur fréquente

Croire que le modèle « exécute » les outils. Il ne fait qu'émettre une demande structurée. C'est le harnais qui exécute et qui décide de ce qui revient dans le contexte. Deux harnais différents donnent des performances très différentes avec le même modèle — un point crucial pour lire les benchmarks, voir Comprendre les benchmarks.

L'appel d'outil¶

Le modèle reçoit dans son contexte une déclaration d'outils : nom, description, schéma des arguments. Quand il veut en utiliser un, il produit un bloc structuré que le harnais sait analyser.

Chez Kimi K3, ce bloc vit dans un canal dédié du message assistant. Le corps d'un message assistant est organisé en trois canaux :

Canal	Contenu
`think`	La trace de raisonnement
`response`	La réponse visible par l'utilisateur
`tools`	Les appels d'outils

Chaque appel porte des attributs tool et index ; l'index numérote les appels parallèles au sein d'un même message, et chaque message de résultat répète la paire tool/index, ce qui associe sans ambiguïté chaque résultat à son appel.

Un détail qui compte : les arguments typés

Dans la plupart des formats, les arguments d'outil sont un objet JSON. Un extrait de code doit donc être échappé dans une chaîne JSON — avec ses guillemets, ses retours à la ligne, ses antislashs. C'est fragile et coûteux en jetons.

Kimi K3 traite les arguments de type chaîne comme du texte brut, et ne sérialise de façon compacte que les autres types. Le code devient un « citoyen de première classe » plutôt qu'une chaîne échappée.

Le format XTML¶

Kimi K3 abandonne les balises textuelles (<tool_call>) au profit de trois jetons réservés : [open], [sep], [close], plus [end_of_msg].

Un élément s'écrit :

[open]tag attr="valeur"[sep] … contenu … [close]tag[sep]

C'est isomorphe à du XML, mais chaque frontière structurelle est un jeton unique. Trois conséquences :

Aucune ambiguïté de tokenisation aux frontières d'éléments (un < dans le code de l'utilisateur ne peut pas être confondu avec une balise) ;
Décodage sous contrainte simplifié : un analyseur syntaxique peut forcer la grammaire au niveau des jetons ;
Analyse en flux (streaming) triviale.

Les trois objectifs déclarés du format sont l'extensibilité (ajouter des capacités par de nouveaux formats de message rétrocompatibles, sans réviser le gabarit), la faible taxe d'alignement (le format doit s'apprendre avec peu de données supervisées) et la convivialité de décodage.

Les messages d'options¶

Idée notable : les options de requête (tool_choice, response_format, thinking-effort) ne sont pas une syntaxe spéciale. Ce sont de courtes instructions en langage naturel injectées dans le contexte.

Leur placement encode leur portée, et il est dicté par le cache KV :

Type	Position	Raison
Options globales (déclaration d'outils, effort)	Avant tous les messages	Elles changent rarement ; les modifier invalide le cache de toute façon
Options ponctuelles (`tool_choice`, `response_format`)	Après tous les messages	Un changement par requête laisse le cache de l'historique intact
Options intercalées	Au milieu	Permet le chargement dynamique d'outils en cours de session

La leçon de conception

Le format de conversation est co-conçu avec le cache KV. Ce n'est pas un détail cosmétique : placer une option au mauvais endroit peut multiplier par dix le coût d'une session agentique.

Le raisonnement préservé (preserved thinking)¶

Kimi K3 fonctionne toujours en mode réflexion. En mode think, le canal de raisonnement est conservé dans l'historique — même vide — de sorte que le modèle observe une structure de message cohérente d'un tour à l'autre.

Conséquence pratique impérative

L'API exige que le message assistant complet soit renvoyé tel quel dans messages, y compris reasoning_content et tool_calls. Ne renvoyer que content dégrade le comportement du modèle.

La documentation officielle donne un exemple : après avoir listé cinq nombres dans son raisonnement et n'en avoir affiché que trois, le modèle peut citer les deux autres au tour suivant — uniquement si le raisonnement a été réinjecté.

Le long horizon¶

Une tâche long-horizon s'étale sur des centaines ou des milliers d'appels d'outils. C'est le régime que Kimi K3 vise explicitement.

Le rapport cite pour ses tâches d'assistant personnel : un environnement persistant sur plusieurs jours simulés, des dizaines d'événements interdépendants répartis entre applications, et « un seul déploiement peut impliquer jusqu'à des milliers d'appels d'outils et des millions de jetons de contexte ».

Trois difficultés spécifiques :

Difficulté	Manifestation	Réponse de Kimi K3
Dérive	L'agent perd de vue l'objectif initial	RL sur des tâches à vérificateur final
Accumulation de contexte	Le contexte dépasse 1 M	Compaction, mémoire, sous-agents
Récupération d'erreur	Une action échoue, l'agent boucle	Environnements avec retour du vérificateur et budget de soumissions limité

La compaction de contexte¶

Quand le contexte sature, le harnais résume l'historique ancien et le remplace par ce résumé. C'est une opération avec perte.

Un chiffre à retenir du rapport

Sur BrowseComp, Kimi K3 est évalué avec une compaction déclenchée à 300 K jetons, et obtient 91,2 %. Évalué sans aucune gestion de contexte, avec la fenêtre complète de 1 M, il obtient 90,4 %.

Autrement dit : la compaction ne dégrade pas — elle améliore légèrement. C'est contre-intuitif, et le rapport ne l'explique pas. Une hypothèse raisonnable : un contexte résumé est moins bruité qu'un contexte brut de 900 K jetons.

Les environnements en boîte blanche¶

Un risque majeur du RL agentique : le modèle surapprend un harnais particulier — un schéma d'outils, une invite système, un protocole d'interaction — et se dégrade avec un autre.

Kimi K3 y répond par un environnement RL unifié en boîte blanche : le harnais est décomposé en modules configurables et composables (interfaces d'outils, invites système, stratégies de gestion de contexte, compétences, mémoires, sous-agents). En les recombinant, l'environnement peut instancier des harnais courants — Kimi Code, Claude Code, Codex, OpenClaw, Hermes — ou des harnais entièrement nouveaux.

Pendant l'entraînement, différentes configurations sont construites dynamiquement pour différents groupes de tâches.

Pourquoi c'est important

C'est une réponse directe à une critique récurrente des modèles agentiques : « il ne marche bien qu'avec son propre outillage ». Les résultats sur MIRA Bench, un harnais interne explicitement hors distribution, servent de test — et Kimi K3 y est justement plus faible (64,1 contre 72,9 pour Claude Fable 5), ce qui suggère que la généralisation cross-harnais reste imparfaite.

Vérification de compréhension¶

Pourquoi la déclaration d'outils est-elle placée avant les messages et le tool_choice après ?

Le cache KV est un cache de préfixe : il ne peut réutiliser que ce qui précède le premier changement. La déclaration d'outils change rarement ; quand elle change, tout le contexte est invalidé de toute façon, autant la mettre en tête. tool_choice change potentiellement à chaque requête : le placer en fin de contexte laisse tout l'historique réutilisable.

Qu'est-ce qu'un « swarm » d'agents ?

Une orchestration où un agent principal délègue des sous-tâches à plusieurs sous-agents travaillant en parallèle, puis synthétise. Kimi K3 obtient son meilleur écart relatif sur ce type de tâche (Swarm Bench : 76,3 contre 73,2 pour GPT-5.6 Sol), et une étude de cas décrit l'analyse de 391 événements d'ondes gravitationnelles « avec plus de 20 sous-agents concurrents ».

Chapitre précédent : Vision et multimodalité

Fin de la partie Fondations. Vous disposez maintenant de tout le vocabulaire nécessaire. La suite : Présentation de Kimi K3.