overmind-mcp
Version:
Orchestrateur universel agents IA multi-modeles via MCP. Inclut le protocole 'Custom-Nickname' pour identifier vos agents avec des surnoms originaux (The Chaos Prophet, Shadow Sniper, etc.), l'isolation mémoire (Private Memory Context) et le support pour
557 lines (416 loc) • 21.4 kB
Markdown
# Hermes x Overmind — Config Provider Map
## Ordre de resolution (qui gagne, qui perd)
Chaque variable suit cette priorite (la premiere gagne):
```
process.env (env du parent, herite par le spawn)
↓
Workflow/.env (~/.env)
↓
settings_[agent].json → env (apres interpolation $VAR par process.env)
↓
HERMES_HOME/.env (~/.overmind/hermes/.env) ← DERNIER MOT (v3.1: HERMES_HOME injecté par HermesRunner)
```
**Detail du code** (`NousHermesRunner.ts` l.268-456):
1. `agentCustomEnv = { ...process.env, ...settings.env }` (line 268 puis 384)
2. Puis lit `overmindHermesSubPath/.env` (le `.hermes/.env` de l'agent) et fait `agentCustomEnv[key] = value` (line 437-456) — ce qui OVERRIDE tout ce qui precede.
3. Finalement ecrit ce `agentCustomEnv` dans le `.env` final de l'agent (line 722-732) avec dedup sur les cles `*api_key` / `*auth_token`.
Donc le `.hermes/.env` de l'agent a **toujours le dernier mot**. Si tu mets `MINIMAX_API_KEY=*** dans le .hermes/.env, il ecrase `MINIMAX_API_KEY` du process.env et du settings.
**MAIS** pour `OPENROUTER_API_KEY` uniquement:
- Hermes lit d'abord `HERMES_HOME/.env` puis `os.environ`
- Si present dans `auth.json` avec status `exhausted` → skip
- Si present dans `HERMES_HOME/.env` (meme vide `""`) → **PREND LA PRIORITE sur process.env**
**MAIS** pour tous les autres providers (zai, minimax-cn, etc.):
- Hermes lit `HERMES_HOME/.env` → si vide/null → lit `os.environ`
- `os.environ` contient tout ce que le parent a passe (donc le `.env` du Workflow)
## Les 5 fichiers cles
| Fichier | Role |
|---|---|
| `HERMES_HOME/.env` | API keys globales Hermes (~/.overmind/hermes/.env) (fallback) |
| `Workflow/.env` | Variables du workflow (DB, tokens, etc.) |
| `settings_[agent].json` | Config par agent (model, provider, tokens, MCP) |
| `HERMES_HOME/.hermes/config.yaml` | Config systeme Hermes (model.default, provider, etc.) |
| `HERMES_HOME/auth.json` | Credential pool — status des tokens (ok/exhausted), URLs par provider |
## Les 2 endpoints Z.AI (DECOUVERTE CRITIQUE)
Z.AI a **deux endpoints distincts** — confusion entre les deux causait des erreurs 402:
| Endpoint | URL | Usage |
|---|---|---|
| **Coding** (celui qu'il faut) | `https://api.z.ai/api/coding/paas/v4` | Inference LLM (Hermes, Overmind) |
| **Non-coding** (ancien, different billing) | `https://api.z.ai/api/paas/v4` | Autre chose (pas le meme systeme de facturation) |
**Comment le credential pool est seed:**
| Source dans .env | Cle dans auth.json | base_url assignee |
|---|---|---|
| `ZAI_ANTHROPIC_FALLBACK_KEY` | `zai[0].access_token` | `https://api.z.ai/api/coding/paas/v4` ✅ |
| `Z_AI_API_KEY` | `zai[1].access_token` | `https://api.z.ai/api/paas/v4` ❌ (ancien) |
Le premier entry (priority 0) est utilise en premier. C'est celui qui est seed par `writeAuthJson()` dans `NousHermesRunner.ts` → `ZAI_ANTHROPIC_FALLBACK_KEY`.
## Provider → Ce qu'Hermes attend
### Z.AI (id: `zai`)
| Param | Valeur attendue | Source dans Hermes |
|---|---|---|
| Provider ID | `zai` | config.yaml ou settings |
| API Key | `ZAI_ANTHROPIC_FALLBACK_KEY` (cle primaire) ou `Z_AI_API_KEY` (fallback ancien) | `HERMES_HOME/.env` → `os.environ` |
| Base URL | `https://api.z.ai/api/coding/paas/v4` | credential pool (seed par writeAuthJson) |
| Model | `glm-5.2` | settings `env.ANTHROPIC_MODEL` |
```json
// settings_[agent].json — Z.AI correct
{
"env": {
"ANTHROPIC_AUTH_TOKEN": "$ZAI_ANTHROPIC_FALLBACK_KEY",
"ANTHROPIC_BASE_URL": "https://api.z.ai/api/coding/paas/v4",
"ANTHROPIC_MODEL": "glm-5.2"
}
}
```
```bash
# .env minimal pour Z.AI
ZAI_ANTHROPIC_FALLBACK_KEY=<your-zai-key-here>
```
Le credential pool `auth.json` est ecrit par `writeAuthJson()` dans `NousHermesRunner.ts`. La cle `ZAI_ANTHROPIC_FALLBACK_KEY` est envoyee par `agentCustomEnv` → Hermes seed le credential pool avec le bon endpoint.
### Z.AI Multi-Token (E/Y)
Deamon a 2 tokens Z.AI (E=primary, Y=secondary). Le credential pool peut contenir les deux:
| Token | Label dans auth.json | Cle dans .env |
|---|---|---|
| Primary | `ANTHROPIC_AUTH_TOKEN_E` | `ANTHROPIC_AUTH_TOKEN_E` = `<your-zai-token-E>` |
| Secondary | `ANTHROPIC_AUTH_TOKEN_Y` | `ANTHROPIC_AUTH_TOKEN_Y` = `<your-zai-token-Y>` |
Pour qu'un agent utilise le token Y (secondary) au lieu de E (primary), le settings doit utiliser `$ANTHROPIC_AUTH_TOKEN_Y` au lieu de `$ANTHROPIC_AUTH_TOKEN_E`.
### MiniMax CN (id: `minimax-cn`)
| Param | Valeur attendue | Source dans Hermes |
|---|---|---|
| Provider ID | `minimax-cn` | config.yaml ou settings |
| API Key | `MINIMAX_CN_API_KEY` **uniquement** | `HERMES_HOME/.env` → `os.environ` |
| Base URL | `https://api.minimaxi.com/anthropic` | hardcoded dans ProviderConfig |
| Model | `MiniMax-M3` | settings `env.ANTHROPIC_MODEL` |
```json
// settings_[agent].json — MiniMax correct
{
"env": {
"ANTHROPIC_AUTH_TOKEN": "$MINIMAX_CN_API_KEY",
"ANTHROPIC_BASE_URL": "https://api.minimaxi.com/anthropic",
"ANTHROPIC_MODEL": "MiniMax-M3"
}
}
```
```bash
# .env minimal pour MiniMax CN
MINIMAX_CN_API_KEY=ton_token_minimax_ici
```
**auth.json** stocke sous `MINIMAX_CN_API_KEY`.
#### MiniMax CN par défaut (convention)
Le préfixe `sk-cp-` est partagé entre MiniMax GLOBAL (`api.minimax.com`) et
MiniMax CN (`api.minimaxi.com`). L'URL est le seul signal qui disambiguïse.
Pour les setups où TOUS les tokens MiniMax sont CN (cas le plus commun),
le runner a un fallback par défaut : quand un token `sk-cp-*` est détecté
sans URL explicite, on bascule sur CN.
Controlable via env var :
```bash
# Défaut (recommandé pour les setups CN-only)
OVERMIND_MINIMAX_DEFAULT=cn # sk-cp-* sans URL → minimax-cn
# Pour les setups GLOBAL-only
OVERMIND_MINIMAX_DEFAULT=global # sk-cp-* sans URL → minimax
# Strict mode (jamais d'inference, URL obligatoire)
OVERMIND_MINIMAX_DEFAULT=auto # sk-cp-* sans URL → minimax (no override)
```
Si une URL explicite est présente dans `ANTHROPIC_BASE_URL`, elle gagne
toujours sur `OVERMIND_MINIMAX_DEFAULT`.
### OpenRouter — BANNIR pour LLM
| Param | Valeur attendue | Source |
|---|---|---|
| Provider ID | — | **Ne PAS utiliser** |
| API Key | `OPENROUTER_API_KEY` | `HERMES_HOME/.env` → `os.environ` |
| Base URL | `https://openrouter.ai/api/v1` | hardcoded |
| Guardrail | — | Force 404 si active |
**PROBLEME:** Si `OPENROUTER_API_KEY` est present (meme dans `OVERMIND_EMBEDDING_KEY` route via NousHermesRunner), Hermes le detecte et tente OpenRouter pour l'inference.
**auth.json** a une entree OpenRouter — si le status est `exhausted`, Hermes ne retry plus mais peut quand meme picker le provider "openrouter" dans le credential pool.
## Ne PAS passer --provider au CLI Hermes (NOUVEAU en 2.8.28)
Le runner Overmind **ne passe plus** le flag `--provider` au CLI Hermes.
Découverte empirique (le `Hermes-MiniMax-2.bat` du bureau marche mais
le sniperbot échoue) :
| Commande | Résultat |
|---|---|
| `hermes chat -q --provider minimax-cn ...` | **401** (bug plugin upstream) |
| `hermes chat --yolo` (sans --provider) | **200 OK** |
**Cause** : le flag `--provider` explicite active un code path buggé
dans le plugin Hermes upstream (`hermes-agent/plugins/model-providers/minimax/`)
qui envoie un format d'auth header rejeté par `api.minimaxi.com`.
**Fix appliqué** : le runner retire `--provider` de `cleanArgs` mais
loggue le `resolvedProvider` à INFO pour debug. Hermes auto-détecte
le bon provider depuis l'env var :
- `MINIMAX_CN_API_KEY` → plugin `minimax-cn`
- `MINIMAX_API_KEY` → plugin `minimax` (GLOBAL)
- `ZAI_ANTHROPIC_FALLBACK_KEY` ou `GLM_API_KEY` → plugin `zai`
- `ANTHROPIC_AUTH_TOKEN` avec préfixe `sk-ant-` → plugin `anthropic`
`ANTHROPIC_BASE_URL` et `ANTHROPIC_MODEL` sont toujours passés, donc
Hermes a assez d'info pour ne pas se tromper.
## HERMES_HOME resolution (multi-OS, multi-install)
Chaque agent Hermes a son propre HERMES_HOME. Le path est resolu de maniere
deterministe par `getAgentHermesHome(agentName)` dans `src/lib/config.ts`.
Ordre de resolution (la premiere gagne):
```
OVERMIND_AGENT_HOME (env var, set par l'install ou systemd)
↓
<workspace>/.overmind/hermes/agent_<name>/.hermes (legacy, si deja existant)
↓
$HOME/.overmind/hermes/agent_<name>/.hermes (Linux/Mac sudo npm -g)
%LOCALAPPDATA%\overmind\hermes\agent_<name>\.hermes (Windows npm -g)
%USERPROFILE%\overmind\hermes\agent_<name>\.hermes (Windows fallback)
```
Pour un agent nomme `sniperbot_analyst`:
- Dev local (workspace = `~/overmind-mcp`):
`Workflow\.overmind\hermes\agent_sniperbot_analyst\.hermes` (si deja cree)
- Prod Linux: `~/.overmind/hermes/agent_sniperbot_analyst/.hermes`
- Prod Windows: `%LOCALAPPDATA%\overmind\hermes\agent_sniperbot_analyst\.hermes`
**Pourquoi c'est important**: avant, le runner Overmind calculait HERMES_HOME
depuis `process.cwd()`. Si le sniper etait lance depuis `~/overmind-mcp/`
et le runner depuis `Workflow\`, ils lisaient des `.hermes/.env` differents
et ecrivaient dans des `auth.json` differents. Maintenant, c'est cwd-independent.
Pour forcer un chemin explicite (ex: deploy Docker), set:
```bash
export OVERMIND_AGENT_HOME=/var/lib/overmind/hermes
```
## Comment Hermes decide quel provider utiliser
Il y a DEUX niveaux de decision:
### Niveau 1: Overmind runner (avant spawn)
`NousHermesRunner.writeAuthJson()` (l.782-918) vote entre 3 signaux pour determiner le `effectiveProvider` qui sera seed dans `auth.json` et le `.env` de l'agent:
1. **Token prefix** (le plus fiable) — `detectTokenProvider()` reconnait:
- `sk-cp-...` ou `sk-mm-...` → `minimax`
- `32hex.32hex` ou 32-char hex → `zai`
- `sk-ant-...` → `anthropic`
- `sk-or-...` → `openrouter` (mais BLOQUE pour LLM par la suite)
- `sk-...` (autre) → `openai`
2. **BASE_URL** (tres fiable, plus specifique que le token pour CN vs GLOBAL) — `api.minimaxi.com` → `minimax-cn`, `api.minimax.com` → `minimax`, `api.z.ai/api/coding/paas/v4` → `zai`, `anthropic.com` → `anthropic`, `openai.com` → `openai`.
3. **ANTHROPIC_PROVIDER** hint du settings (le moins fiable).
**Cas special CN vs GLOBAL**: `sk-cp-` est ambigu entre `minimax` et `minimax-cn` (meme prefix). Si l'URL dit `minimaxi` (avec le `i`), c'est CN. Si `minimax` (sans le `i`), c'est GLOBAL. **L'URL gagne dans ce cas precis** parce qu'elle est la seule a desambiguïser.
### Niveau 2: Hermes upstream (apres spawn)
Hermes relit son `auth.json` + `HERMES_HOME/.env` + `os.environ` avec sa propre logique (dans `hermes_cli/auth.py`):
```
1. Si `provider` explicite dans config.yaml → utilise ce provider
2. Sinon si `ANTHROPIC_BASE_URL` contient openrouter → "openrouter"
3. Sinon lit model name → compare avec model_defaults par provider
- "glm-*" → "zai"
- "MiniMax-*" → "minimax-cn"
4. Sinon fallback: model.default dans config.yaml
```
**Le runner a deja vote au Niveau 1** — donc ce que tu mets dans `auth.json` (via `writeAuthJson()`) determine ce qu'Hermes verra au Niveau 2. Si le runner a seed `minimax-cn` mais que `config.yaml` dit `provider: minimax`, Hermes va probablement se plaindre. **Garde les deux alignes** ou laisse le runner ecrire le `config.yaml` (ce qu'il fait deja a chaque run).
## Comment NousHermesRunner passe les vars a Hermes
Le runner lit `settings_[agent].json` → applique `interpolateEnvVars()` qui remplace `$VAR` par `process.env[VAR]` → envoie le tout dans `agentCustomEnv` au processus Hermes.
```typescript
// Ce que NousHermesRunner.ts passe a Hermes (agentCustomEnv)
const agentCustomEnv = {
...process.env, // HERMES_HOME/.env + Workflow/.env fusionnes
PYTHONIOENCODING: 'utf-8',
OPENROUTER_API_KEY: process.env.OPENROUTER_API_KEY || '', // VIDE (fixe)
NVIDIA_API_KEY: process.env.NVIDIA_API_KEY || process.env.NVAPI_KEY,
ANTHROPIC_AUTH_TOKEN: s.env.ANTHROPIC_AUTH_TOKEN, // interpolate
ANTHROPIC_BASE_URL: s.env.ANTHROPIC_BASE_URL, // interpolate
ANTHROPIC_MODEL: s.env.ANTHROPIC_MODEL, // interpolate
};
```
Puis lance Hermes avec `--env-file` pour discord_llm + Workflow `.env` (via startpipeline.js).
## Le probleme de OPENROUTER_API_KEY
**AVANT le fix:**
```typescript
OPENROUTER_API_KEY: process.env.OPENROUTER_API_KEY || process.env.OVERMIND_EMBEDDING_KEY,
```
→ Si `OPENROUTER_API_KEY` vide mais `OVERMIND_EMBEDDING_KEY` present → passe quand meme une cle OpenRouter a Hermes → Hermes detecte `OPENROUTER_API_KEY` → tente OpenRouter → 404 guardrail.
**APRES le fix:**
```typescript
OPENROUTER_API_KEY: process.env.OPENROUTER_API_KEY || '',
```
→ `OVERMIND_EMBEDDING_KEY` n'est plus redirige. Si `OPENROUTER_API_KEY` absent du `.env`, Hermes recoit string vide et ne pick pas OpenRouter.
## Comment Hermes obtient la API Key (le vrai flux)
Le `ANTHROPIC_AUTH_TOKEN` dans `settings.json` **ne passe pas directement** dans le body de la requete API. Hermes utilise son propre credential pool:
```
settings_[agent].json
"env": {
"ANTHROPIC_AUTH_TOKEN": "$ZAI_ANTHROPIC_FALLBACK_KEY", ← Runner remplace $VAR → "token_reel"
"ANTHROPIC_BASE_URL": "https://api.z.ai/api/coding/paas/v4",
"ANTHROPIC_MODEL": "glm-5.2"
}
↓ (interpolateEnvVars par NousHermesRunner)
agentCustomEnv envoye a Hermes:
ANTHROPIC_AUTH_TOKEN=token_reel
ANTHROPIC_BASE_URL=https://api.z.ai/api/coding/paas/v4
ANTHROPIC_MODEL=glm-5.2
MAIS Hermes ne lit PAS ANTHROPIC_AUTH_TOKEN directement.
Hermes lit le CREDENTIAL POOL (auth.json) + les .env vars listees dans api_key_env_vars.
Credential pool est seed par:
ZAI_ANTHROPIC_FALLBACK_KEY → "zai" avec base_url coding ✅
Z_AI_API_KEY → "zai" avec base_url non-coding (ancien)
MINIMAX_CN_API_KEY → "minimax-cn"
```
Le `$VAR` dans `ANTHROPIC_AUTH_TOKEN` est juste une convenience pour que le token traverse le runner et arrive dans `process.env` du subprocess Hermes. C'est `process.env.ZAI_ANTHROPIC_FALLBACK_KEY` qui seed le credential pool.
## Le flow complet (Z.AI par exemple)
1. `Workflow/.env` contient `ZAI_ANTHROPIC_FALLBACK_KEY=<TOKEN>`
2. `startpipeline.js` charge `.env` → `process.env.ZAI_ANTHROPIC_FALLBACK_KEY`
3. ` NousHermesRunner` lit `settings_zai.json` → `interpolateEnvVars()`
- `$ZAI_ANTHROPIC_FALLBACK_KEY` → `process.env["ZAI_ANTHROPIC_FALLBACK_KEY"]` → `"<TOKEN>"`
- `ANTHROPIC_AUTH_TOKEN="<TOKEN>"` (valeur concrete maintenant)
4. `agentCustomEnv` envoye a Hermes:
- `ANTHROPIC_AUTH_TOKEN=<TOKEN>`
- `ANTHROPIC_BASE_URL=https://api.z.ai/api/coding/paas/v4`
- `ANTHROPIC_MODEL=glm-5.2`
5. Hermes fait son propre lookup:
- `load_pool("zai")` → `_resolve_api_key_provider_secret("zai")`
- Cherche `ZAI_ANTHROPIC_FALLBACK_KEY` via `_get_env_prefer_dotenv()` dans `HERMES_HOME/.env` puis `os.environ`
- Trouve dans `os.environ` (herite du parent)
- `writeAuthJson()` ecrit dans `auth.json` avec base_url `https://api.z.ai/api/coding/paas/v4`
6. API call → utilise le credential pool entry pour `zai` avec le bon endpoint
## OPENROUTER et Les Embeddings
**`OVERMIND_EMBEDDING_KEY`** = clef OpenRouter pour les **embeddings uniquement** (PostgresMemoryProvider du Workflow). Elle est dans le `.env` Overmind. Hermes n'a pas besoin de la voir pour l'LLM inference.
**NousHermesRunner ne doit jamais forwarder de clef OpenRouter a Hermes.** OpenRouter n'est pas un provider LLM dans ce setup. Si `OPENROUTER_API_KEY` arrive jusqu'a Hermes, il detecte la clef et tente OpenRouter pour l'inference → 404 guardrail.
**Fix applique:**
```typescript
OPENROUTER_API_KEY: process.env.OPENROUTER_API_KEY || '',
```
## Le config.yaml ecrit par NousHermesRunner (exemple sniperbot_analyst)
```yaml
mcp_servers:
memory-server:
url: "http://localhost:3099/mcp"
discord-server:
url: "http://localhost:3141/mcp"
x-mcp-server:
url: "http://localhost:3142/mcp"
postgresql-server:
url: "http://localhost:5433/mcp"
model:
default: glm-5.2
provider: z-ai
tts:
provider: elevenlabs
voice: charlie
voice_id: IKne3meq5aSn9XLyUdCD
model: eleven_multilingual_v2
```
Ce config est ecrit dans `.overmind/hermes/agent_<name>/.hermes/config.yaml` a chaque run. Les valeurs viennent de `settings_<agent>.json` + defaults.
## Checklist pour ajouter un nouveau provider
1. **Verifier le ProviderConfig** dans `hermes-agent/hermes_cli/auth.py`
- Verifier `api_key_env_vars` (les vars que Hermes cherche)
- Verifier `inference_base_url` (URL par defaut)
- Verifier `base_url_env_var` (optionnel, surcharge URL)
2. **Ajouter dans Workflow/.env**
```bash
MAISON_API_KEY=cle_api_du_fournisseur
```
3. **Ajouter dans settings_[agent].json**
```json
{
"env": {
"ANTHROPIC_AUTH_TOKEN": "$MAISON_API_KEY",
"ANTHROPIC_BASE_URL": "https://api.fournisseur.com/v1",
"ANTHROPIC_MODEL": "model-name"
}
}
```
4. **Verifier auth.json** — apres premiere utilisation, Hermes stocke le token avec status.
- Si `exhausted` → Hermes skip ce provider automatiquement
- Si `ok` → utilise le token
5. **NE JAMAIS** faire de mapping `AUTRE_CHOSE_API_KEY → OPENROUTER_API_KEY` — ca force OpenRouter.
6. **Pour eviter OpenRouter:** pas de `OPENROUTER_API_KEY` dans `HERMES_HOME/.env`
## Resume
| Tu veux... | Utilise ces vars |
|---|---|
| Z.AI (glm-5.2) | `ZAI_ANTHROPIC_FALLBACK_KEY` dans `.env` + settings `$ZAI_ANTHROPIC_FALLBACK_KEY` |
| Z.AI secondary (token Y) | `ANTHROPIC_AUTH_TOKEN_Y` dans `.env` + settings `$ANTHROPIC_AUTH_TOKEN_Y` |
| MiniMax CN | `MINIMAX_CN_API_KEY` dans `.env` + settings `$MINIMAX_CN_API_KEY` |
| Embeddings OpenRouter | `OVERMIND_EMBEDDING_KEY` (pour embeddings, PAS LLM) |
| Eviter OpenRouter LLM | Pas de `OPENROUTER_API_KEY` dans `HERMES_HOME/.env` |
## Gemini / @google/gemini-cli (id: `gemini`)
Le runner `gemini` utilise **`@google/gemini-cli`** (npm, v0.43.0) en headless mode.
Le CLI est installé via `npm install -g @google/gemini-cli` et disponible dans le PATH.
### Installation
```bash
npm install -g @google/gemini-cli
gemini --version # → 0.43.0
```
### Flags CLI utilisés
| Flag | Valeur | Rôle |
|---|---|---|
| `-p` / `--prompt` | prompt text | Mode headless (non-interactif) |
| `--approval-mode` | `yolo` | Auto-approve tous les outils |
| `--session-id` | UUID | Session persistante entre appels |
| `--acp` | (flag) | Active le protocol agent (ACP) |
| `--model` | `antigravity/<MODE>` | Passe le mode Antigravity comme contexte |
| `--output-format` | `json` | Output structuré pour parser session_id |
### Commandes equivalents (CLI direct)
```bash
# Test quick
gemini -p "Dis-moi bonjour" --approval-mode yolo
# Avec session
gemini -p "Analyse ce code" --approval-mode yolo --session-id <uuid> --acp
# Mode PLAN
gemini -p "Planifie cette tache" --model antigravity/PLAN --approval-mode yolo --acp
# List sessions
gemini --list-sessions
```
### Modes Antigravity (parametre `mode`)
Le mode est passe via `--model antigravity/<MODE>` pour donner du contexte au modele.
|| Mode | Usage |
|---|---|
| `GENERAL` | Mode par defaut, taches polyvalentes |
| `CONTEXT_CHECK` | Verification de contexte code |
| `PLAN` | Planification de taches complexes |
| `COMMAND` | Execution de commandes shell |
| `CASCADE` | Execution en cascade multi-agents |
| `EVAL` | Evaluation et revue de code |
| `ANTIGRAVITY_REVIEW` | Revue automatique Antigravity |
| `MQUERY` | Recherche multi-source |
| `COMMIT_MESSAGE` | Generation de messages de commit |
| `CHECKPOINT` | Sauvegarde de checkpoint |
| `FAST_APPLY` | Application rapide de patches |
### Utilisation Overmind (run_agent)
```typescript
// run_agent avec runner: 'gemini'
const result = await runAgent({
runner: 'gemini', // GeminiRunner → gemini CLI npm
prompt: 'Analyse ce code',
agentName: 'expert_python',
mode: 'GENERAL', // GENERAL, PLAN, COMMAND, CASCADE, EVAL, etc.
autoResume: false,
configPath: './Workflow',
});
// ou directement via run_gemini.ts
const result = await runGeminiAgent({
prompt: '...',
mode: 'PLAN',
});
```
### Configuration agent
Chaque agent stocke sa config dans `.antigravity/agent_<nom>/`:
- `mcp.json` — serveurs MCP actifs (copies depuis settings_<agent>.json)
- Session store — sessions persistees
### Verification installation
```bash
gemini --version
# → 0.43.0
gemini mcp list
# → liste les MCP servers configures
```
### Erreurs connues
| Erreur | Cause | Fix |
|---|---|---|
| `GEMINI_CLI_NOT_INSTALLED` | `@google/gemini-cli` pas dans le PATH | `npm install -g @google/gemini-cli` |
| `EXIT_CODE_1` | Session invalide ou prompt rejete | Retry sans sessionId |
| `TIMEOUT` | Reponse > 15min | Augmente `CONFIG.TIMEOUT_MS` |
### Ce qui a change (historique)
|| Avant (session 2025) | Maintenant |
|---|---|---|
| Spawn `language_server_windows_x64.exe` avec flags inexistants | Spawn `gemini` (npm bin) avec flags reels |
| `--mode --prompt-file --session --output-format` (flags Go inexistants) | `-p --approval-mode yolo --session-id --acp --model --output-format json` |
| Auth via OAuth interne Antigravity IDE | Auth via Google account du CLI npm |
| Config `.antigravity/<agent>/` | Config `.antigravity/<agent>/` (MCP + sessions) |