AWR
GitHub
Français
English中文Españolहिन्दीPortuguêsРусский日本語한국어DeutschFrançais

Connectez votre agent

Voir la source sur GitHub

AWR n'exécute pas votre agent. Le client agent (Codex, Claude Code, Kimi, Cursor, Grok) fait le travail avec ses propres outils ; AWR fournit les faits courants du projet, le contexte de travail, les réservations et une mémoire de session récupérable pour le même projet initialisé. Les étiquettes de fournisseur et de modèle dans les enregistrements de session AWR ne sont que des métadonnées — elles ne lancent ni ne configurent jamais le client.

Chaque client pris en charge suit le même schéma :

  1. Construisez les deux exécutables depuis un checkout AWR :
cargo build --locked -p awr-cli -p awr-mcp
  1. Initialisez le projet cible depuis son manifeste source relu (voir Démarrage rapide), puis enregistrez le serveur awr-mcp auprès du client, en pointant --project vers le chemin absolu du projet. Chaque serveur se lie à une seule racine de projet canonique ; donnez aux serveurs de projets différents des noms distincts.
  2. Vérifiez la connexion — un fichier de configuration sur le disque n'est pas une connexion active — et confirmez l'identité du projet avec une lecture d'état avant tout travail.
  3. Suivez le cycle de vie de session partagé : démarrez ou reprenez une session, lisez le contexte, enregistrez un point de contrôle avant la passation, terminez quand vous vous arrêtez. Voir CLI et Outils MCP.

Les sections ci-dessous donnent pour chaque client les chemins de fusion, la configuration et les mises en garde. Lorsqu'un client documente des hooks de cycle de vie automatiques, considérez-les comme non vérifiés tant que vous n'avez pas vu un déclenchement réel et son reçu ; le processus manuel de point de contrôle/reprise fonctionne toujours.

Codex

Codex ne charge la configuration de projet que pour les projets de confiance ; ses clients CLI, bureau et IDE partagent la configuration MCP sur le même hôte. Choisissez l'une des deux options : fusionner le modèle de configuration MCP dans le .codex/config.toml du projet (en remplaçant ses deux chemins, en préservant la configuration existante), ou enregistrer au niveau utilisateur :

codex mcp add awr -- /absolute/path/to/awr-mcp \
  --project /absolute/path/to/initialized/project
codex mcp get awr --json

Dans la vue /mcp du client, confirmez un serveur awr connecté et vérifiez l'identité du projet avant de travailler ; un serveur configuré n'est pas une preuve de connexion active. Outils de lecture attendus : awr_project_status, awr_work_ready, awr_work_get, awr_context_compile, awr_search. Outils de mutation : awr_work_transition, awr_event_append, awr_evidence_record. Le serveur ne requiert pas de clé API de modèle.

Codex est le seul client doté d'un installateur pour les hooks de cycle de vie automatiques : utilisez awr client install pour prévisualiser la configuration exacte avant --accept. L'installation préserve les hooks existants et n'approuve jamais leur confiance automatiquement. Codex documente SessionStart (startup|resume|clear|compact), PreCompact (manual|auto) et SessionEnd (consultatif, délai court). Vérifiez la livraison réelle des déclencheurs dans le client — d'ici là, enregistrez vos points de contrôle manuellement avant toute passation ou compaction.

Claude Code

Claude Code se connecte via un adaptateur contrôlé nommé (identifiant d'adaptateur claude_code). Il n'est pas auto-démarrable : AWR ne lancera pas Claude Code pour vous, et ne l'arrêtera pas de lui-même — ces étapes vous reviennent. Ce que l'adaptateur prend en charge, c'est la lecture d'état, la reconnexion/reprise et l'analyse des résultats.

Chemin opérateur :

  1. Démarrez Claude Code vous-même.
  2. Liez-le à AWR avec le client générique et l'identifiant de conversation natif :
awrj client bind --client generic --external-session claude:<native-id> \
  --work "$AWR_WORK" --session "$AWR_SESSION"
  1. Quand vous avez besoin des observations AWR, rapportez les phases via le rapport d'exécution externe du CLI partagé.
  2. En cas de nouvelle tentative, reconnectez la même identité d'exécution avant de commencer quoi que ce soit de nouveau.

Kimi

Ce guide cible Kimi Code 0.41.0 (inspecté le 2026-09-08) ; les versions plus anciennes de kimi-cli utilisent des chemins de configuration et des options différents, donc vérifiez d'abord kimi --version et kimi --help. Utilisez l'outil terminal de Kimi pour appeler le CLI AWR, et connectez éventuellement le même projet via MCP stdio en fusionnant ce serveur dans le .kimi-code/mcp.json du projet (niveau utilisateur : ~/.kimi-code/mcp.json), en préservant les autres entrées :

{
  "mcpServers": {
    "awr": { "command": "/absolute/path/to/awr-mcp",
      "args": ["--project", "/absolute/path/to/initialized/project"],
      "cwd": "/absolute/path/to/initialized/project" }
  }
}

La configuration de projet requiert la confiance de l'espace de travail. Utilisez /mcp-config pour la configuration et /mcp pour inspecter l'état des connexions ; les serveurs ajoutés en éditant la configuration rejoignent les sessions nouvellement créées. Confirmez l'identité du projet avec awr_project_status. L'étiquette de fournisseur pour les métadonnées de session Kimi est moonshot.

Les propres commandes de Kimi kimi --continue, kimi --session <kimi-conversation-id> et /compact opèrent sur sa conversation ; leurs identifiants sont distincts des identifiants AWR. Après une compaction, compilez le contexte pour la même session AWR active — une reprise AWR explicite n'est réservée qu'à une vraie passation. Kimi documente les hooks SessionStart, SessionEnd, PreCompact et PostCompact, mais cette intégration n'installe aucun adaptateur automatique ; utilisez le processus manuel de point de contrôle.

Cursor

Vérifié contre Cursor 3.18.9 (2026-09-17). N'exécutez pas awr client install pour Cursor (Unsupported), et ne passez pas --client cursor à bind (InvalidInput) — utilisez l'identité de client générique montrée ci-dessous. Fusionnez le modèle stdio dans le .cursor/mcp.json du projet ou le ~/.cursor/mcp.json utilisateur :

{
  "mcpServers": {
    "awr": { "type": "stdio", "command": "/absolute/path/to/awr-mcp",
      "args": ["--project", "/absolute/path/to/initialized/project"] }
  }
}

La table de champs stdio de Cursor exige "type": "stdio" et n'accepte pas cwd. AWR n'a besoin que d'un command absolu plus --project. Rechargez la fenêtre et consultez Output → MCP Logs en cas d'échec au démarrage ; quand les deux fichiers de configuration existent, confirmez dans Customize lequel la fenêtre d'agent a attaché. Deux mises en garde :

Outils groupés. Dans l'arborescence source actuelle, le tools/list par défaut renvoie huit outils de domaine (awr_query, awr_context, awr_work, awr_evidence, awr_session, awr_continuity, awr_change, awr_compaction) plutôt que des noms d'outils à plat. Sondez l'état via awr_query :

{"child_tool": "awr_project_status", "arguments": {}}

Les noms à plat restent appelables mais ne figurent pas dans le catalogue par défaut ; ne définissez AWR_MCP_TOOL_EXPOSURE_MODE=flat que si votre build de Cursor ne peut pas router via les domaines. Les versions packagées n'exposent pas le awr_query groupé — construisez depuis l'arborescence source pour cette voie, et vérifiez d'abord le catalogue d'outils de votre build.

Cloud Agents ne peuvent pas atteindre un awr-mcp sur portable ni 127.0.0.1 ; ils ont besoin d'une porte d'entrée HTTPS accessible avec des racines de projet côté serveur. Le service HTTP partagé d'AWR utilise un jeton bearer (pas OAuth Cursor) :

{
  "mcpServers": {
    "awr": { "url": "http://127.0.0.1:8080/mcp",
      "headers": { "Authorization": "Bearer ${env:AWR_ENGINEERING_TOKEN}" } }
  }
}

Pour l'identité, liez le client générique avec l'identifiant de conversation natif, en échouant s'il est vide afin de ne jamais lier le littéral cursor: :

: "${HOST_CONVERSATION_ID:?set the native host conversation ID first}"
AWR_EXTERNAL="cursor:${HOST_CONVERSATION_ID}"
awrj client bind --client generic --external-session "$AWR_EXTERNAL" \
  --work "$AWR_WORK" --session "$AWR_SESSION"

Cursor documente les hooks sessionStart, sessionEnd et preCompact dans .cursor/hooks.json, mais il n'existe pas d'installateur pour ce dialecte — enregistrez vos points de contrôle manuellement jusqu'à ce que vous ayez un déclencheur de hook réel et un reçu de point de contrôle.

Grok

Vérifié contre Grok Build 1.0.13 (2026-09-08). Utilisez l'outil terminal de Grok pour appeler le CLI AWR, ou connectez son client MCP stdio depuis le répertoire du projet :

cd /absolute/path/to/initialized/project
grok mcp add --scope project awr -- /absolute/path/to/awr-mcp \
  --project /absolute/path/to/initialized/project
grok mcp doctor awr --json

add --scope project écrit ou met à jour .grok/config.toml (la portée utilisateur est la valeur par défaut quand l'option est omise) ; utilisez un nom de serveur distinct si awr désigne déjà un autre projet. La table équivalente est :

[mcp_servers.awr]
command = "/absolute/path/to/awr-mcp"
args = ["--project", "/absolute/path/to/initialized/project"]

Utilisez /mcps dans Grok Build pour inspecter et rafraîchir les connexions, puis appelez awr_project_status et vérifiez l'identité du projet. La confiance du projet est un prérequis séparé : un dossier non approuvé laisse le serveur non démarré, donc passez d'abord en revue le projet dans le processus de confiance normal du client. L'étiquette de fournisseur pour les métadonnées de session Grok est xai.

La continuation native de conversation de Grok est séparée de la reprise de session AWR :

grok --cwd "$AWR_PROJECT" --continue
grok --cwd "$AWR_PROJECT" --resume <grok-conversation-id>

Le --session-id de Grok crée une nouvelle conversation — ce n'est ni un identifiant AWR ni une option de reprise. Après une compaction native, compilez le contexte pour la même session AWR active ; n'utilisez le processus de reprise AWR explicite que pour une vraie passation.

Grok Build documente les événements de session et de compaction dans son système de hooks, mais aucun adaptateur automatique n'est installé ici ; utilisez le processus manuel de point de contrôle jusqu'à ce que vous ayez vérifié un déclencheur réel et son reçu. Les connecteurs personnalisés de Grok web exigent une URL MCP accessible — un chemin d'exécutable local ne peut pas être saisi comme cette URL ; le service HTTP partagé d'AWR peut jouer ce rôle, mais le déployer et satisfaire les exigences d'authentification du connecteur est une étape séparée que ce guide ne vérifie pas.

Prochaines étapes

  • Outils MCP — l'ensemble complet des outils que votre client peut appeler une fois connecté.
  • Flux de travail quotidien — la boucle démarrer, travailler, pointer, reprendre, quel que soit le client utilisé.