Comment voir le JSON envoyé au modèle et sa réponse

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

# Comment voir le JSON envoyé au modèle et sa réponse

Ce guide montre comment garder, pour chaque appel au modèle, la requête exacte envoyée par mm et la réponse exacte renvoyée par le serveur — pour vérifier un prompt système, les définitions d'outils, une clé d'échantillonnage, ce qu'un autre agent a reçu, ou ce qu'un modèle a vraiment répondu. Il suppose que vous lancez déjà `mm` avec un fichier de configuration.

## Étapes

1. Activez la trace, pour une exécution :

   ```bash
   AGENT_TRACE=true mm agent.yaml
   ```

   ou durablement, dans la configuration :

   ```yaml
   trace:
     enabled: true
     dir: .mm/traces   # la valeur par défaut
   ```

   La bannière se termine par `| trace: /chemin/absolu/.mm/traces` tant qu'elle est active.

2. Posez une question comme d'habitude. Chaque appel au modèle laisse une paire de fichiers :

   ```text
   .mm/traces/20261007-123237.903-bob-0001.request.json
   .mm/traces/20261007-123237.903-bob-0001.response-200.sse
   ```

   Une question peut faire plusieurs appels : un par aller-retour avec les outils, plus un résumé de compaction. L'`acp.name` de l'agent figure dans chaque nom, donc un agent appelé par `ask_agent` ou `/ask` — il hérite de `AGENT_TRACE` — écrit ses propres fichiers à côté des vôtres (`…-jan-0001…`).

3. Lisez la requête. C'est le corps exactement tel qu'envoyé, indenté :

   ```bash
   jq '{model, temperature, stream_options, chat_template_kwargs}' .mm/traces/*-0001.request.json
   jq -r '.messages[] | "\(.role): \(.content | tostring | .[0:120])"' .mm/traces/*-0001.request.json
   jq -r '.tools[].function.name' .mm/traces/*-0001.request.json
   ```

4. Lisez la réponse. Une réponse en streaming (`.sse`) est faite des lignes du serveur telles qu'elles sont arrivées, un chunk `data: {…}` chacune ; reconstituez le texte de la réponse avec :

   ```bash
   grep '^data: {' .mm/traces/*-0001.response-200.sse | sed 's/^data: //' \
     | jq -rj '.choices[0].delta.content // empty'; echo
   ```

   son raisonnement avec `.choices[0].delta.reasoning_content`, ses appels d'outils avec `.choices[0].delta.tool_calls`, ses comptes de tokens avec `.usage` (le dernier chunk). Une réponse sans streaming est un fichier `.json`, indenté. Un statut d'erreur figure dans le nom (`.response-400.json`) ; un appel resté sans réponse laisse `.response-error.txt`.

5. Désactivez-la quand vous avez fini : les fichiers contiennent vos prompts, le contenu des fichiers lus et les sorties des commandes, en entier. `.mm/` est ignoré par git dans ce dépôt ; ajoutez-le aussi au `.gitignore` de votre projet.

## Variantes

- **Dans un éditeur (ACP).** Un `trace.dir` relatif est dans le `cwd` de la session — le projet ouvert par l'éditeur — et non dans le répertoire d'où l'éditeur a lancé `mm`. Mettez `AGENT_TRACE` dans les réglages de l'agent de l'éditeur (`env`), ou `trace.enabled` dans le fichier : l'éditeur ne voit pas les variables de votre shell.
- **Ailleurs.** `trace.dir: /tmp/mm-traces` rassemble les appels de tous les projets au même endroit.
- **Seulement les agents interrogés.** Mettez `trace.enabled: true` dans le fichier de cet agent au lieu d'utiliser `AGENT_TRACE`.
- **Ce que mm ajoute.** La requête porte déjà ce que mm ajoute lui-même — `stream_options.include_usage`, `return_progress` pour un serveur llama.cpp, `chat_template_kwargs.enable_thinking: false` sur un résumé — la trace sert donc aussi à vérifier ces ajouts.

## Voir aussi

- Les clés `trace` et les noms des fichiers : [référence de la configuration](../reference/configuration.md)
- `AGENT_TRACE` : [référence de la ligne de commande](../reference/cli.md)
- Pourquoi le raisonnement arrive dans son propre champ : [Modèles à raisonnement](../explanation/thinking-models.md)