chore(i18n): refresh fr translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
5b10b3888e
commit
6b9fe57222
@ -1,30 +1,30 @@
|
||||
---
|
||||
read_when:
|
||||
- Configurer Slack ou déboguer le mode socket/HTTP de Slack
|
||||
summary: Configuration de Slack et comportement d'exécution (Socket Mode + URL de requête HTTP)
|
||||
summary: Configuration de Slack et comportement à l’exécution (Socket Mode + URL de requête HTTP)
|
||||
title: Slack
|
||||
x-i18n:
|
||||
generated_at: "2026-04-07T06:49:48Z"
|
||||
generated_at: "2026-04-08T06:02:06Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 2b8fd2cc6c638ee82069f0af2c2b6f6f49c87da709b941433a0343724a9907ea
|
||||
source_hash: cad132131ddce688517def7c14703ad314441c67aacc4cc2a2a721e1d1c01942
|
||||
source_path: channels/slack.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Slack
|
||||
|
||||
Statut : prêt pour la production pour les DM et les canaux via les intégrations d'application Slack. Le mode par défaut est Socket Mode ; les URL de requête HTTP sont également prises en charge.
|
||||
Statut : prêt pour la production pour les messages privés et les canaux via les intégrations d’app Slack. Le mode par défaut est Socket Mode ; les URL de requête HTTP sont également prises en charge.
|
||||
|
||||
<CardGroup cols={3}>
|
||||
<Card title="Appairage" icon="link" href="/fr/channels/pairing">
|
||||
Les DM Slack utilisent le mode d'appairage par défaut.
|
||||
<Card title="Association" icon="link" href="/fr/channels/pairing">
|
||||
Les messages privés Slack utilisent par défaut le mode d’association.
|
||||
</Card>
|
||||
<Card title="Commandes slash" icon="terminal" href="/fr/tools/slash-commands">
|
||||
Comportement natif des commandes et catalogue des commandes.
|
||||
</Card>
|
||||
<Card title="Dépannage des canaux" icon="wrench" href="/fr/channels/troubleshooting">
|
||||
Diagnostics inter-canaux et guides de résolution.
|
||||
Diagnostics inter-canaux et guides de réparation.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
@ -33,13 +33,13 @@ Statut : prêt pour la production pour les DM et les canaux via les intégration
|
||||
<Tabs>
|
||||
<Tab title="Socket Mode (par défaut)">
|
||||
<Steps>
|
||||
<Step title="Créer une nouvelle application Slack">
|
||||
Dans les paramètres de l'application Slack, appuyez sur le bouton **[Create New App](https://api.slack.com/apps/new)** :
|
||||
<Step title="Créer une nouvelle app Slack">
|
||||
Dans les paramètres de l’app Slack, appuyez sur le bouton **[Create New App](https://api.slack.com/apps/new)** :
|
||||
|
||||
- choisissez **from a manifest** et sélectionnez un espace de travail pour votre application
|
||||
- collez le [manifeste d'exemple](#manifest-and-scope-checklist) ci-dessous et poursuivez la création
|
||||
- choisissez **from a manifest** et sélectionnez un espace de travail pour votre app
|
||||
- collez le [manifeste d’exemple](#manifest-and-scope-checklist) ci-dessous et continuez pour la créer
|
||||
- générez un **App-Level Token** (`xapp-...`) avec `connections:write`
|
||||
- installez l'application et copiez le **Bot Token** (`xoxb-...`) affiché
|
||||
- installez l’app et copiez le **Bot Token** (`xoxb-...`) affiché
|
||||
</Step>
|
||||
|
||||
<Step title="Configurer OpenClaw">
|
||||
@ -57,7 +57,7 @@ Statut : prêt pour la production pour les DM et les canaux via les intégration
|
||||
}
|
||||
```
|
||||
|
||||
Variable d'environnement de secours (compte par défaut uniquement) :
|
||||
Variable d’environnement de secours (compte par défaut uniquement) :
|
||||
|
||||
```bash
|
||||
SLACK_APP_TOKEN=xapp-...
|
||||
@ -79,13 +79,13 @@ openclaw gateway
|
||||
|
||||
<Tab title="URL de requête HTTP">
|
||||
<Steps>
|
||||
<Step title="Créer une nouvelle application Slack">
|
||||
Dans les paramètres de l'application Slack, appuyez sur le bouton **[Create New App](https://api.slack.com/apps/new)** :
|
||||
<Step title="Créer une nouvelle app Slack">
|
||||
Dans les paramètres de l’app Slack, appuyez sur le bouton **[Create New App](https://api.slack.com/apps/new)** :
|
||||
|
||||
- choisissez **from a manifest** et sélectionnez un espace de travail pour votre application
|
||||
- collez le [manifeste d'exemple](#manifest-and-scope-checklist) et mettez à jour les URL avant de créer
|
||||
- choisissez **from a manifest** et sélectionnez un espace de travail pour votre app
|
||||
- collez le [manifeste d’exemple](#manifest-and-scope-checklist) et mettez à jour les URL avant de créer l’app
|
||||
- enregistrez le **Signing Secret** pour la vérification des requêtes
|
||||
- installez l'application et copiez le **Bot Token** (`xoxb-...`) affiché
|
||||
- installez l’app et copiez le **Bot Token** (`xoxb-...`) affiché
|
||||
|
||||
</Step>
|
||||
|
||||
@ -106,9 +106,9 @@ openclaw gateway
|
||||
```
|
||||
|
||||
<Note>
|
||||
Utilisez des chemins webhook uniques pour le HTTP multi-compte
|
||||
Utilisez des chemins de webhook uniques pour le mode HTTP multi-compte
|
||||
|
||||
Donnez à chaque compte un `webhookPath` distinct (par défaut `/slack/events`) afin que les enregistrements n'entrent pas en conflit.
|
||||
Donnez à chaque compte un `webhookPath` distinct (par défaut `/slack/events`) afin d’éviter les collisions d’enregistrement.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
@ -125,7 +125,7 @@ openclaw gateway
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Liste de vérification du manifeste et des scopes
|
||||
## Liste de vérification du manifeste et des portées
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Socket Mode (par défaut)">
|
||||
@ -290,13 +290,14 @@ openclaw gateway
|
||||
</Tabs>
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Scopes d'autorisation facultatifs (opérations d'écriture)">
|
||||
Ajoutez le scope bot `chat:write.customize` si vous voulez que les messages sortants utilisent l'identité de l'agent actif (nom d'utilisateur et icône personnalisés) au lieu de l'identité par défaut de l'application Slack.
|
||||
<Accordion title="Portées d’attribution facultatives (opérations d’écriture)">
|
||||
Ajoutez la portée bot `chat:write.customize` si vous souhaitez que les messages sortants utilisent l’identité de l’agent actif (nom d’utilisateur et icône personnalisés) au lieu de l’identité par défaut de l’app Slack.
|
||||
|
||||
Si vous utilisez une icône emoji, Slack attend une syntaxe `:emoji_name:`.
|
||||
|
||||
Si vous utilisez une icône emoji, Slack attend une syntaxe `:nom_emoji:`.
|
||||
</Accordion>
|
||||
<Accordion title="Scopes facultatifs de jeton utilisateur (opérations de lecture)">
|
||||
Si vous configurez `channels.slack.userToken`, les scopes de lecture typiques sont :
|
||||
<Accordion title="Portées facultatives du jeton utilisateur (opérations de lecture)">
|
||||
Si vous configurez `channels.slack.userToken`, les portées de lecture courantes sont :
|
||||
|
||||
- `channels:history`, `groups:history`, `im:history`, `mpim:history`
|
||||
- `channels:read`, `groups:read`, `im:read`, `mpim:read`
|
||||
@ -315,30 +316,30 @@ openclaw gateway
|
||||
- Le mode HTTP nécessite `botToken` + `signingSecret`.
|
||||
- `botToken`, `appToken`, `signingSecret` et `userToken` acceptent des chaînes
|
||||
en clair ou des objets SecretRef.
|
||||
- Les jetons de configuration remplacent la variable d'environnement de secours.
|
||||
- La variable d'environnement de secours `SLACK_BOT_TOKEN` / `SLACK_APP_TOKEN` s'applique uniquement au compte par défaut.
|
||||
- `userToken` (`xoxp-...`) est uniquement dans la configuration (pas de variable d'environnement de secours) et utilise par défaut un comportement en lecture seule (`userTokenReadOnly: true`).
|
||||
- Les jetons de config remplacent la variable d’environnement de secours.
|
||||
- La variable d’environnement de secours `SLACK_BOT_TOKEN` / `SLACK_APP_TOKEN` s’applique uniquement au compte par défaut.
|
||||
- `userToken` (`xoxp-...`) est uniquement configurable dans la config (pas de variable d’environnement de secours) et adopte par défaut un comportement en lecture seule (`userTokenReadOnly: true`).
|
||||
|
||||
Comportement de l'instantané d'état :
|
||||
Comportement de l’instantané d’état :
|
||||
|
||||
- L'inspection des comptes Slack suit les champs `*Source` et `*Status`
|
||||
par identifiant (`botToken`, `appToken`, `signingSecret`, `userToken`).
|
||||
- L'état est `available`, `configured_unavailable` ou `missing`.
|
||||
- L’inspection du compte Slack suit, pour chaque identifiant, les champs
|
||||
`*Source` et `*Status` (`botToken`, `appToken`, `signingSecret`, `userToken`).
|
||||
- L’état est `available`, `configured_unavailable` ou `missing`.
|
||||
- `configured_unavailable` signifie que le compte est configuré via SecretRef
|
||||
ou une autre source de secret non inline, mais que le chemin de commande/d'exécution actuel
|
||||
n'a pas pu résoudre la valeur réelle.
|
||||
- En mode HTTP, `signingSecretStatus` est inclus ; en Socket Mode, la
|
||||
ou une autre source de secret non inline, mais que le chemin de commande ou
|
||||
d’exécution actuel n’a pas pu résoudre la valeur réelle.
|
||||
- En mode HTTP, `signingSecretStatus` est inclus ; en Socket Mode, la
|
||||
paire requise est `botTokenStatus` + `appTokenStatus`.
|
||||
|
||||
<Tip>
|
||||
Pour les lectures d'actions/répertoire, le jeton utilisateur peut être privilégié lorsqu'il est configuré. Pour les écritures, le jeton bot reste prioritaire ; les écritures avec jeton utilisateur ne sont autorisées que lorsque `userTokenReadOnly: false` et que le jeton bot n'est pas disponible.
|
||||
Pour les actions et les lectures d’annuaire, le jeton utilisateur peut être préféré lorsqu’il est configuré. Pour les écritures, le jeton bot reste prioritaire ; les écritures avec jeton utilisateur ne sont autorisées que si `userTokenReadOnly: false` et que le jeton bot n’est pas disponible.
|
||||
</Tip>
|
||||
|
||||
## Actions et contrôles
|
||||
## Actions et garde-fous
|
||||
|
||||
Les actions Slack sont contrôlées par `channels.slack.actions.*`.
|
||||
|
||||
Groupes d'actions disponibles dans l'outillage Slack actuel :
|
||||
Groupes d’actions disponibles dans l’outillage Slack actuel :
|
||||
|
||||
| Groupe | Par défaut |
|
||||
| ---------- | ---------- |
|
||||
@ -348,225 +349,230 @@ Groupes d'actions disponibles dans l'outillage Slack actuel :
|
||||
| memberInfo | activé |
|
||||
| emojiList | activé |
|
||||
|
||||
Les actions actuelles des messages Slack incluent `send`, `upload-file`, `download-file`, `read`, `edit`, `delete`, `pin`, `unpin`, `list-pins`, `member-info` et `emoji-list`.
|
||||
Les actions de message Slack actuelles incluent `send`, `upload-file`, `download-file`, `read`, `edit`, `delete`, `pin`, `unpin`, `list-pins`, `member-info` et `emoji-list`.
|
||||
|
||||
## Contrôle d'accès et routage
|
||||
## Contrôle d’accès et routage
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Politique des DM">
|
||||
`channels.slack.dmPolicy` contrôle l'accès DM (hérité : `channels.slack.dm.policy`) :
|
||||
<Tab title="Politique des messages privés">
|
||||
`channels.slack.dmPolicy` contrôle l’accès aux messages privés (hérité : `channels.slack.dm.policy`) :
|
||||
|
||||
- `pairing` (par défaut)
|
||||
- `allowlist`
|
||||
- `open` (nécessite que `channels.slack.allowFrom` inclue `"*"` ; hérité : `channels.slack.dm.allowFrom`)
|
||||
- `open` (nécessite que `channels.slack.allowFrom` inclue `"*"` ; hérité : `channels.slack.dm.allowFrom`)
|
||||
- `disabled`
|
||||
|
||||
Indicateurs DM :
|
||||
Indicateurs des messages privés :
|
||||
|
||||
- `dm.enabled` (true par défaut)
|
||||
- `channels.slack.allowFrom` (recommandé)
|
||||
- `channels.slack.allowFrom` (préféré)
|
||||
- `dm.allowFrom` (hérité)
|
||||
- `dm.groupEnabled` (DM de groupe désactivés par défaut)
|
||||
- `dm.groupChannels` (liste d'autorisation MPIM facultative)
|
||||
- `dm.groupEnabled` (messages privés de groupe désactivés par défaut)
|
||||
- `dm.groupChannels` (liste d’autorisation MPIM facultative)
|
||||
|
||||
Priorité multi-compte :
|
||||
Priorité multi-compte :
|
||||
|
||||
- `channels.slack.accounts.default.allowFrom` s'applique uniquement au compte `default`.
|
||||
- Les comptes nommés héritent de `channels.slack.allowFrom` lorsque leur propre `allowFrom` n'est pas défini.
|
||||
- Les comptes nommés n'héritent pas de `channels.slack.accounts.default.allowFrom`.
|
||||
- `channels.slack.accounts.default.allowFrom` s’applique uniquement au compte `default`.
|
||||
- Les comptes nommés héritent de `channels.slack.allowFrom` lorsque leur propre `allowFrom` n’est pas défini.
|
||||
- Les comptes nommés n’héritent pas de `channels.slack.accounts.default.allowFrom`.
|
||||
|
||||
L'appairage dans les DM utilise `openclaw pairing approve slack <code>`.
|
||||
L’association dans les messages privés utilise `openclaw pairing approve slack <code>`.
|
||||
|
||||
</Tab>
|
||||
|
||||
<Tab title="Politique des canaux">
|
||||
`channels.slack.groupPolicy` contrôle la gestion des canaux :
|
||||
`channels.slack.groupPolicy` contrôle la gestion des canaux :
|
||||
|
||||
- `open`
|
||||
- `allowlist`
|
||||
- `disabled`
|
||||
|
||||
La liste d'autorisation des canaux se trouve sous `channels.slack.channels` et doit utiliser des ID de canal stables.
|
||||
La liste d’autorisation des canaux se trouve sous `channels.slack.channels` et doit utiliser des ID de canal stables.
|
||||
|
||||
Remarque d'exécution : si `channels.slack` est complètement absent (configuration par variable d'environnement uniquement), l'exécution revient à `groupPolicy="allowlist"` et enregistre un avertissement (même si `channels.defaults.groupPolicy` est défini).
|
||||
Remarque d’exécution : si `channels.slack` est totalement absent (configuration via variables d’environnement uniquement), l’exécution utilise `groupPolicy="allowlist"` comme repli et journalise un avertissement (même si `channels.defaults.groupPolicy` est défini).
|
||||
|
||||
Résolution nom/ID :
|
||||
Résolution nom/ID :
|
||||
|
||||
- les entrées de liste d'autorisation des canaux et les entrées de liste d'autorisation des DM sont résolues au démarrage lorsque l'accès au jeton le permet
|
||||
- les entrées de nom de canal non résolues sont conservées telles que configurées mais ignorées pour le routage par défaut
|
||||
- l'autorisation entrante et le routage des canaux utilisent les ID en priorité par défaut ; la correspondance directe de nom d'utilisateur/slug nécessite `channels.slack.dangerouslyAllowNameMatching: true`
|
||||
- les entrées de liste d’autorisation de canal et de messages privés sont résolues au démarrage lorsque l’accès par jeton le permet
|
||||
- les entrées de nom de canal non résolues sont conservées telles que configurées, mais ignorées par défaut pour le routage
|
||||
- l’autorisation entrante et le routage des canaux reposent d’abord sur les ID par défaut ; la correspondance directe sur nom d’utilisateur/slug nécessite `channels.slack.dangerouslyAllowNameMatching: true`
|
||||
|
||||
</Tab>
|
||||
|
||||
<Tab title="Mentions et utilisateurs des canaux">
|
||||
Les messages de canal sont filtrés par mention par défaut.
|
||||
<Tab title="Mentions et utilisateurs de canal">
|
||||
Les messages de canal sont soumis par défaut à un garde-fou sur les mentions.
|
||||
|
||||
Sources de mention :
|
||||
Sources de mention :
|
||||
|
||||
- mention explicite de l'application (`<@botId>`)
|
||||
- modèles regex de mention (`agents.list[].groupChat.mentionPatterns`, secours `messages.groupChat.mentionPatterns`)
|
||||
- comportement implicite de réponse à un fil du bot (désactivé lorsque `thread.requireExplicitMention` vaut `true`)
|
||||
- mention explicite de l’app (`<@botId>`)
|
||||
- motifs regex de mention (`agents.list[].groupChat.mentionPatterns`, avec repli sur `messages.groupChat.mentionPatterns`)
|
||||
- comportement implicite de réponse dans le fil au bot (désactivé lorsque `thread.requireExplicitMention` vaut `true`)
|
||||
|
||||
Contrôles par canal (`channels.slack.channels.<id>` ; noms uniquement via la résolution au démarrage ou `dangerouslyAllowNameMatching`) :
|
||||
Contrôles par canal (`channels.slack.channels.<id>` ; noms uniquement via résolution au démarrage ou `dangerouslyAllowNameMatching`) :
|
||||
|
||||
- `requireMention`
|
||||
- `users` (liste d'autorisation)
|
||||
- `users` (liste d’autorisation)
|
||||
- `allowBots`
|
||||
- `skills`
|
||||
- `systemPrompt`
|
||||
- `tools`, `toolsBySender`
|
||||
- format de clé `toolsBySender` : `id:`, `e164:`, `username:`, `name:` ou joker `"*"`
|
||||
(les clés héritées sans préfixe sont toujours mappées vers `id:` uniquement)
|
||||
- format de clé `toolsBySender` : `id:`, `e164:`, `username:`, `name:` ou joker `"*"`
|
||||
(les clés héritées sans préfixe sont toujours mappées uniquement vers `id:`)
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Fils, sessions et balises de réponse
|
||||
|
||||
- Les DM sont routés comme `direct` ; les canaux comme `channel` ; les MPIM comme `group`.
|
||||
- Avec la valeur par défaut `session.dmScope=main`, les DM Slack sont regroupés dans la session principale de l'agent.
|
||||
- Sessions de canal : `agent:<agentId>:slack:channel:<channelId>`.
|
||||
- Les réponses dans un fil peuvent créer des suffixes de session de fil (`:thread:<threadTs>`) selon le cas.
|
||||
- La valeur par défaut de `channels.slack.thread.historyScope` est `thread` ; celle de `thread.inheritParent` est `false`.
|
||||
- `channels.slack.thread.initialHistoryLimit` contrôle combien de messages de fil existants sont récupérés lorsqu'une nouvelle session de fil démarre (par défaut `20` ; définissez `0` pour désactiver).
|
||||
- `channels.slack.thread.requireExplicitMention` (par défaut `false`) : lorsque la valeur est `true`, supprime les mentions implicites dans les fils pour que le bot ne réponde qu'aux mentions explicites `@bot` à l'intérieur des fils, même lorsque le bot a déjà participé au fil. Sans cela, les réponses dans un fil où le bot a participé contournent le filtrage `requireMention`.
|
||||
- Les messages privés sont routés comme `direct` ; les canaux comme `channel` ; les MPIM comme `group`.
|
||||
- Avec la valeur par défaut `session.dmScope=main`, les messages privés Slack sont regroupés dans la session principale de l’agent.
|
||||
- Sessions de canal : `agent:<agentId>:slack:channel:<channelId>`.
|
||||
- Les réponses dans les fils peuvent créer des suffixes de session de fil (`:thread:<threadTs>`) lorsque c’est applicable.
|
||||
- La valeur par défaut de `channels.slack.thread.historyScope` est `thread` ; celle de `thread.inheritParent` est `false`.
|
||||
- `channels.slack.thread.initialHistoryLimit` contrôle le nombre de messages existants du fil récupérés au démarrage d’une nouvelle session de fil (valeur par défaut `20` ; définissez `0` pour désactiver).
|
||||
- `channels.slack.thread.requireExplicitMention` (par défaut `false`) : quand `true`, supprime les mentions implicites dans les fils afin que le bot ne réponde qu’aux mentions explicites `@bot` dans les fils, même s’il a déjà participé au fil. Sans cela, les réponses dans un fil auquel le bot a participé contournent le garde-fou `requireMention`.
|
||||
|
||||
Contrôles de fil de réponse :
|
||||
Contrôles de fil de réponse :
|
||||
|
||||
- `channels.slack.replyToMode`: `off|first|all|batched` (par défaut `off`)
|
||||
- `channels.slack.replyToModeByChatType`: par `direct|group|channel`
|
||||
- secours hérité pour les chats directs : `channels.slack.dm.replyToMode`
|
||||
- repli hérité pour les discussions directes : `channels.slack.dm.replyToMode`
|
||||
|
||||
Les balises de réponse manuelles sont prises en charge :
|
||||
Les balises de réponse manuelle sont prises en charge :
|
||||
|
||||
- `[[reply_to_current]]`
|
||||
- `[[reply_to:<id>]]`
|
||||
|
||||
Remarque : `replyToMode="off"` désactive **tout** le fil de réponse dans Slack, y compris les balises explicites `[[reply_to_*]]`. Cela diffère de Telegram, où les balises explicites sont toujours honorées en mode `"off"`. La différence reflète les modèles de fil des plateformes : les fils Slack masquent les messages du canal, tandis que les réponses Telegram restent visibles dans le flux principal du chat.
|
||||
Remarque : `replyToMode="off"` désactive **tout** le fil de réponse dans Slack, y compris les balises explicites `[[reply_to_*]]`. Cela diffère de Telegram, où les balises explicites sont toujours respectées en mode `"off"`. Cette différence reflète les modèles de fil propres aux plateformes : dans Slack, les fils masquent les messages du canal, tandis que dans Telegram, les réponses restent visibles dans le flux principal de discussion.
|
||||
|
||||
## Réactions d'accusé de réception
|
||||
## Réactions d’accusé de réception
|
||||
|
||||
`ackReaction` envoie un emoji d'accusé de réception pendant qu'OpenClaw traite un message entrant.
|
||||
`ackReaction` envoie un emoji d’accusé de réception pendant qu’OpenClaw traite un message entrant.
|
||||
|
||||
Ordre de résolution :
|
||||
Ordre de résolution :
|
||||
|
||||
- `channels.slack.accounts.<accountId>.ackReaction`
|
||||
- `channels.slack.ackReaction`
|
||||
- `messages.ackReaction`
|
||||
- secours emoji d'identité d'agent (`agents.list[].identity.emoji`, sinon "👀")
|
||||
- repli sur l’emoji d’identité de l’agent (`agents.list[].identity.emoji`, sinon "👀")
|
||||
|
||||
Remarques :
|
||||
Remarques :
|
||||
|
||||
- Slack attend des shortcodes (par exemple `"eyes"`).
|
||||
- Utilisez `""` pour désactiver la réaction pour le compte Slack ou globalement.
|
||||
|
||||
## Streaming de texte
|
||||
|
||||
`channels.slack.streaming` contrôle le comportement d'aperçu en direct :
|
||||
`channels.slack.streaming` contrôle le comportement de l’aperçu en direct :
|
||||
|
||||
- `off` : désactiver le streaming d'aperçu en direct.
|
||||
- `partial` (par défaut) : remplace le texte d'aperçu par la dernière sortie partielle.
|
||||
- `block` : ajoute des mises à jour d'aperçu par blocs.
|
||||
- `progress` : affiche un texte d'état de progression pendant la génération, puis envoie le texte final.
|
||||
- `off` : désactiver le streaming de l’aperçu en direct.
|
||||
- `partial` (par défaut) : remplacer le texte d’aperçu par la dernière sortie partielle.
|
||||
- `block` : ajouter des mises à jour d’aperçu par blocs.
|
||||
- `progress` : afficher un texte de progression pendant la génération, puis envoyer le texte final.
|
||||
|
||||
`channels.slack.nativeStreaming` contrôle le streaming de texte natif Slack lorsque `streaming` vaut `partial` (par défaut : `true`).
|
||||
`channels.slack.streaming.nativeTransport` contrôle le streaming de texte natif Slack lorsque `channels.slack.streaming.mode` vaut `partial` (par défaut : `true`).
|
||||
|
||||
- Un fil de réponse doit être disponible pour que le streaming de texte natif apparaisse. La sélection du fil suit toujours `replyToMode`. Sans cela, l'aperçu de brouillon normal est utilisé.
|
||||
- Les médias et charges utiles non textuelles reviennent à la livraison normale.
|
||||
- Si le streaming échoue au milieu de la réponse, OpenClaw revient à la livraison normale pour les charges utiles restantes.
|
||||
- Un fil de réponse doit être disponible pour que le streaming de texte natif et l’état du fil assistant Slack s’affichent. La sélection du fil continue toutefois de suivre `replyToMode`.
|
||||
- Les racines de canaux et de discussions de groupe peuvent toujours utiliser l’aperçu brouillon normal lorsque le streaming natif n’est pas disponible.
|
||||
- Les messages privés Slack de niveau supérieur restent hors fil par défaut, ils n’affichent donc pas l’aperçu de style fil ; utilisez des réponses en fil ou `typingReaction` si vous souhaitez y afficher une progression visible.
|
||||
- Les médias et les charges utiles non textuelles reviennent à la livraison normale.
|
||||
- Si le streaming échoue en cours de réponse, OpenClaw revient à la livraison normale pour les charges utiles restantes.
|
||||
|
||||
Utiliser l'aperçu de brouillon au lieu du streaming de texte natif Slack :
|
||||
Utiliser l’aperçu brouillon au lieu du streaming de texte natif Slack :
|
||||
|
||||
```json5
|
||||
{
|
||||
channels: {
|
||||
slack: {
|
||||
streaming: "partial",
|
||||
nativeStreaming: false,
|
||||
streaming: {
|
||||
mode: "partial",
|
||||
nativeTransport: false,
|
||||
},
|
||||
},
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
Clés héritées :
|
||||
Clés héritées :
|
||||
|
||||
- `channels.slack.streamMode` (`replace | status_final | append`) est migré automatiquement vers `channels.slack.streaming`.
|
||||
- le booléen `channels.slack.streaming` est migré automatiquement vers `channels.slack.nativeStreaming`.
|
||||
- `channels.slack.streamMode` (`replace | status_final | append`) est migré automatiquement vers `channels.slack.streaming.mode`.
|
||||
- le booléen `channels.slack.streaming` est migré automatiquement vers `channels.slack.streaming.mode` et `channels.slack.streaming.nativeTransport`.
|
||||
- la clé héritée `channels.slack.nativeStreaming` est migrée automatiquement vers `channels.slack.streaming.nativeTransport`.
|
||||
|
||||
## Secours de réaction de saisie
|
||||
## Repli de réaction de saisie
|
||||
|
||||
`typingReaction` ajoute une réaction temporaire au message Slack entrant pendant qu'OpenClaw traite une réponse, puis la supprime lorsque l'exécution se termine. Cela est surtout utile en dehors des réponses dans les fils, qui utilisent un indicateur d'état par défaut "is typing...".
|
||||
`typingReaction` ajoute une réaction temporaire au message Slack entrant pendant qu’OpenClaw traite une réponse, puis la retire à la fin de l’exécution. C’est surtout utile hors des réponses en fil, qui utilisent un indicateur d’état par défaut « is typing... ».
|
||||
|
||||
Ordre de résolution :
|
||||
Ordre de résolution :
|
||||
|
||||
- `channels.slack.accounts.<accountId>.typingReaction`
|
||||
- `channels.slack.typingReaction`
|
||||
|
||||
Remarques :
|
||||
Remarques :
|
||||
|
||||
- Slack attend des shortcodes (par exemple `"hourglass_flowing_sand"`).
|
||||
- La réaction est best-effort et le nettoyage est tenté automatiquement après la réponse ou après la fin du chemin d'échec.
|
||||
- La réaction est appliquée au mieux et son nettoyage est tenté automatiquement une fois la réponse ou le chemin d’échec terminé.
|
||||
|
||||
## Médias, segmentation et livraison
|
||||
## Médias, découpage et livraison
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Pièces jointes entrantes">
|
||||
Les pièces jointes de fichier Slack sont téléchargées depuis des URL privées hébergées par Slack (flux de requête authentifié par jeton) et écrites dans le stockage média lorsque la récupération réussit et que les limites de taille le permettent.
|
||||
Les pièces jointes Slack sont téléchargées depuis des URL privées hébergées par Slack (flux de requêtes authentifiées par jeton) et écrites dans le stockage média lorsque la récupération réussit et que les limites de taille le permettent.
|
||||
|
||||
Le plafond de taille entrant à l'exécution est de `20MB` par défaut, sauf remplacement par `channels.slack.mediaMaxMb`.
|
||||
Le plafond de taille entrante à l’exécution est de `20MB` par défaut, sauf remplacement par `channels.slack.mediaMaxMb`.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Texte et fichiers sortants">
|
||||
- les segments de texte utilisent `channels.slack.textChunkLimit` (par défaut 4000)
|
||||
- `channels.slack.chunkMode="newline"` active le découpage prioritaire par paragraphe
|
||||
- les envois de fichiers utilisent les API de téléchargement Slack et peuvent inclure des réponses de fil (`thread_ts`)
|
||||
- le plafond de média sortant suit `channels.slack.mediaMaxMb` lorsqu'il est configuré ; sinon, les envois de canal utilisent les valeurs par défaut de type MIME du pipeline média
|
||||
- les blocs de texte utilisent `channels.slack.textChunkLimit` (valeur par défaut 4000)
|
||||
- `channels.slack.chunkMode="newline"` active un découpage privilégiant d’abord les paragraphes
|
||||
- les envois de fichiers utilisent les API d’upload Slack et peuvent inclure des réponses en fil (`thread_ts`)
|
||||
- le plafond média sortant suit `channels.slack.mediaMaxMb` lorsqu’il est configuré ; sinon, les envois par canal utilisent les valeurs par défaut par type MIME du pipeline média
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Cibles de livraison">
|
||||
Cibles explicites privilégiées :
|
||||
Cibles explicites préférées :
|
||||
|
||||
- `user:<id>` pour les DM
|
||||
- `user:<id>` pour les messages privés
|
||||
- `channel:<id>` pour les canaux
|
||||
|
||||
Les DM Slack sont ouverts via les API de conversation Slack lors de l'envoi vers des cibles utilisateur.
|
||||
Les messages privés Slack sont ouverts via les API de conversation Slack lors de l’envoi vers des cibles utilisateur.
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## Commandes et comportement des slash commands
|
||||
|
||||
- Le mode automatique de commande native est **désactivé** pour Slack (`commands.native: "auto"` n'active pas les commandes natives Slack).
|
||||
- Activez les gestionnaires de commande natifs Slack avec `channels.slack.commands.native: true` (ou globalement `commands.native: true`).
|
||||
- Lorsque les commandes natives sont activées, enregistrez les slash commands correspondantes dans Slack (noms `/<command>`), avec une exception :
|
||||
- enregistrez `/agentstatus` pour la commande d'état (Slack réserve `/status`)
|
||||
- Le mode automatique des commandes natives est **désactivé** pour Slack (`commands.native: "auto"` n’active pas les commandes natives Slack).
|
||||
- Activez les gestionnaires de commandes Slack natives avec `channels.slack.commands.native: true` (ou globalement `commands.native: true`).
|
||||
- Lorsque les commandes natives sont activées, enregistrez les slash commands correspondantes dans Slack (noms `/<command>`), avec une exception :
|
||||
- enregistrez `/agentstatus` pour la commande d’état (Slack réserve `/status`)
|
||||
- Si les commandes natives ne sont pas activées, vous pouvez exécuter une seule slash command configurée via `channels.slack.slashCommand`.
|
||||
- Les menus d'arguments natifs adaptent désormais leur stratégie de rendu :
|
||||
- jusqu'à 5 options : blocs de boutons
|
||||
- 6-100 options : menu de sélection statique
|
||||
- plus de 100 options : sélection externe avec filtrage asynchrone des options lorsque les gestionnaires d'options d'interactivité sont disponibles
|
||||
- si les valeurs d'option encodées dépassent les limites de Slack, le flux revient aux boutons
|
||||
- Pour les longues charges utiles d'options, les menus d'arguments de slash command utilisent une boîte de dialogue de confirmation avant d'envoyer une valeur sélectionnée.
|
||||
- Les menus d’arguments natifs adaptent désormais leur stratégie de rendu :
|
||||
- jusqu’à 5 options : blocs de boutons
|
||||
- 6 à 100 options : menu de sélection statique
|
||||
- plus de 100 options : sélection externe avec filtrage asynchrone des options lorsque des gestionnaires d’options d’interactivité sont disponibles
|
||||
- si les valeurs d’option encodées dépassent les limites de Slack, le flux revient aux boutons
|
||||
- Pour les longues charges utiles d’options, les menus d’arguments des slash commands utilisent une boîte de dialogue de confirmation avant d’envoyer une valeur sélectionnée.
|
||||
|
||||
Paramètres par défaut des slash commands :
|
||||
Paramètres par défaut des slash commands :
|
||||
|
||||
- `enabled: false`
|
||||
- `name: "openclaw"`
|
||||
- `sessionPrefix: "slack:slash"`
|
||||
- `ephemeral: true`
|
||||
|
||||
Les sessions de slash utilisent des clés isolées :
|
||||
Les sessions slash utilisent des clés isolées :
|
||||
|
||||
- `agent:<agentId>:slack:slash:<userId>`
|
||||
|
||||
et continuent de router l'exécution de la commande vers la session de conversation cible (`CommandTargetSessionKey`).
|
||||
et continuent malgré tout à router l’exécution de la commande vers la session de conversation cible (`CommandTargetSessionKey`).
|
||||
|
||||
## Réponses interactives
|
||||
|
||||
Slack peut afficher des contrôles de réponse interactive rédigés par l'agent, mais cette fonctionnalité est désactivée par défaut.
|
||||
Slack peut afficher des contrôles de réponse interactive rédigés par l’agent, mais cette fonctionnalité est désactivée par défaut.
|
||||
|
||||
Activez-la globalement :
|
||||
L’activer globalement :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -580,7 +586,7 @@ Activez-la globalement :
|
||||
}
|
||||
```
|
||||
|
||||
Ou activez-la pour un seul compte Slack :
|
||||
Ou l’activer pour un seul compte Slack :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -598,44 +604,44 @@ Ou activez-la pour un seul compte Slack :
|
||||
}
|
||||
```
|
||||
|
||||
Lorsqu'elle est activée, les agents peuvent émettre des directives de réponse propres à Slack :
|
||||
Lorsque cette fonctionnalité est activée, les agents peuvent émettre des directives de réponse réservées à Slack :
|
||||
|
||||
- `[[slack_buttons: Approve:approve, Reject:reject]]`
|
||||
- `[[slack_select: Choose a target | Canary:canary, Production:production]]`
|
||||
|
||||
Ces directives sont compilées en Slack Block Kit et routent les clics ou sélections vers le chemin d'événement d'interaction Slack existant.
|
||||
Ces directives sont compilées en Slack Block Kit et les clics ou sélections sont renvoyés via le chemin d’événement d’interaction Slack existant.
|
||||
|
||||
Remarques :
|
||||
Remarques :
|
||||
|
||||
- Il s'agit d'une interface propre à Slack. Les autres canaux ne traduisent pas les directives Slack Block Kit vers leurs propres systèmes de boutons.
|
||||
- Les valeurs de rappel interactives sont des jetons opaques générés par OpenClaw, pas des valeurs brutes rédigées par l'agent.
|
||||
- Si les blocs interactifs générés dépassent les limites de Slack Block Kit, OpenClaw revient à la réponse textuelle d'origine au lieu d'envoyer une charge utile de blocs invalide.
|
||||
- Il s’agit d’une UI spécifique à Slack. Les autres canaux ne traduisent pas les directives Slack Block Kit vers leurs propres systèmes de boutons.
|
||||
- Les valeurs de rappel interactif sont des jetons opaques générés par OpenClaw, et non des valeurs brutes rédigées par l’agent.
|
||||
- Si les blocs interactifs générés dépassent les limites de Slack Block Kit, OpenClaw revient à la réponse texte d’origine au lieu d’envoyer une charge utile de blocs invalide.
|
||||
|
||||
## Approbations Exec dans Slack
|
||||
## Approbations exec dans Slack
|
||||
|
||||
Slack peut agir comme client d'approbation natif avec des boutons et interactions interactifs, au lieu de revenir à l'interface Web ou au terminal.
|
||||
Slack peut agir comme client d’approbation natif avec des boutons interactifs et des interactions, au lieu de revenir à la Web UI ou au terminal.
|
||||
|
||||
- Les approbations Exec utilisent `channels.slack.execApprovals.*` pour le routage natif DM/canal.
|
||||
- Les approbations de plugin peuvent toujours se résoudre via la même surface de bouton native Slack lorsque la requête arrive déjà dans Slack et que le type d'identifiant d'approbation est `plugin:`.
|
||||
- L'autorisation des approbateurs reste appliquée : seuls les utilisateurs identifiés comme approbateurs peuvent approuver ou refuser des demandes via Slack.
|
||||
- Les approbations exec utilisent `channels.slack.execApprovals.*` pour le routage natif en message privé/canal.
|
||||
- Les approbations de plugin peuvent toujours être résolues via la même surface de boutons native Slack lorsque la demande arrive déjà dans Slack et que le type d’ID d’approbation est `plugin:`.
|
||||
- L’autorisation des approbateurs reste appliquée : seuls les utilisateurs identifiés comme approbateurs peuvent approuver ou refuser des demandes via Slack.
|
||||
|
||||
Cela utilise la même surface de bouton d'approbation partagée que les autres canaux. Lorsque `interactivity` est activé dans les paramètres de votre application Slack, les invites d'approbation s'affichent comme des boutons Block Kit directement dans la conversation.
|
||||
Lorsque ces boutons sont présents, ils constituent l'expérience d'approbation principale ; OpenClaw
|
||||
ne doit inclure une commande `/approve` manuelle que lorsque le résultat de l'outil indique que les
|
||||
approbations par chat ne sont pas disponibles ou que l'approbation manuelle est le seul chemin.
|
||||
Cela utilise la même surface partagée de boutons d’approbation que les autres canaux. Lorsque `interactivity` est activé dans les paramètres de votre app Slack, les invites d’approbation s’affichent directement sous forme de boutons Block Kit dans la conversation.
|
||||
Lorsque ces boutons sont présents, ils constituent l’UX d’approbation principale ; OpenClaw
|
||||
ne devrait inclure une commande manuelle `/approve` que lorsque le résultat de l’outil indique que les
|
||||
approbations par discussion ne sont pas disponibles ou que l’approbation manuelle est la seule voie.
|
||||
|
||||
Chemin de configuration :
|
||||
Chemin de configuration :
|
||||
|
||||
- `channels.slack.execApprovals.enabled`
|
||||
- `channels.slack.execApprovals.approvers` (facultatif ; revient à `commands.ownerAllowFrom` lorsque possible)
|
||||
- `channels.slack.execApprovals.target` (`dm` | `channel` | `both`, par défaut : `dm`)
|
||||
- `channels.slack.execApprovals.approvers` (facultatif ; utilise `commands.ownerAllowFrom` comme repli lorsque possible)
|
||||
- `channels.slack.execApprovals.target` (`dm` | `channel` | `both`, valeur par défaut : `dm`)
|
||||
- `agentFilter`, `sessionFilter`
|
||||
|
||||
Slack active automatiquement les approbations Exec natives lorsque `enabled` n'est pas défini ou vaut `"auto"` et qu'au moins un
|
||||
approbateur est résolu. Définissez `enabled: false` pour désactiver explicitement Slack comme client d'approbation natif.
|
||||
Slack active automatiquement les approbations exec natives lorsque `enabled` n’est pas défini ou vaut `"auto"` et qu’au moins un
|
||||
approbateur est résolu. Définissez `enabled: false` pour désactiver explicitement Slack comme client d’approbation natif.
|
||||
Définissez `enabled: true` pour forcer les approbations natives lorsque des approbateurs sont résolus.
|
||||
|
||||
Comportement par défaut sans configuration explicite d'approbation Exec Slack :
|
||||
Comportement par défaut sans configuration explicite d’approbation exec Slack :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -645,8 +651,8 @@ Comportement par défaut sans configuration explicite d'approbation Exec Slack :
|
||||
}
|
||||
```
|
||||
|
||||
Une configuration native Slack explicite n'est nécessaire que lorsque vous voulez remplacer les approbateurs, ajouter des filtres ou
|
||||
opter pour une livraison au chat d'origine :
|
||||
Une configuration native Slack explicite n’est nécessaire que si vous souhaitez remplacer les approbateurs, ajouter des filtres, ou
|
||||
opter pour une livraison vers la discussion d’origine :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -662,52 +668,52 @@ opter pour une livraison au chat d'origine :
|
||||
}
|
||||
```
|
||||
|
||||
Le transfert partagé `approvals.exec` est distinct. Utilisez-le uniquement lorsque les invites d'approbation Exec doivent aussi
|
||||
être routées vers d'autres chats ou des cibles explicites hors bande. Le transfert partagé `approvals.plugin` est également
|
||||
distinct ; les boutons natifs Slack peuvent toujours résoudre les approbations de plugin lorsque ces requêtes arrivent déjà
|
||||
Le transfert partagé `approvals.exec` est distinct. Utilisez-le uniquement lorsque les invites d’approbation exec doivent aussi
|
||||
être routées vers d’autres discussions ou des cibles explicites hors bande. Le transfert partagé `approvals.plugin` est également
|
||||
distinct ; les boutons natifs Slack peuvent toujours résoudre les approbations de plugin lorsque ces demandes arrivent déjà
|
||||
dans Slack.
|
||||
|
||||
Le `/approve` dans le même chat fonctionne aussi dans les canaux et DM Slack qui prennent déjà en charge les commandes. Voir [Approbations Exec](/fr/tools/exec-approvals) pour le modèle complet de transfert des approbations.
|
||||
`/approve` dans la même discussion fonctionne aussi dans les canaux et messages privés Slack qui prennent déjà en charge les commandes. Voir [Approbations exec](/fr/tools/exec-approvals) pour le modèle complet de transfert des approbations.
|
||||
|
||||
## Événements et comportement opérationnel
|
||||
|
||||
- Les modifications/suppressions de message/diffusions de fil sont mappées vers des événements système.
|
||||
- Les événements d'ajout/suppression de réaction sont mappés vers des événements système.
|
||||
- Les événements d'entrée/sortie de membre, de création/renommage de canal et d'ajout/suppression d'épingle sont mappés vers des événements système.
|
||||
- Les modifications/suppressions de messages et les diffusions de fil sont mappées en événements système.
|
||||
- Les événements d’ajout/suppression de réaction sont mappés en événements système.
|
||||
- Les événements d’arrivée/départ de membre, de création/renommage de canal et d’ajout/suppression d’épingle sont mappés en événements système.
|
||||
- `channel_id_changed` peut migrer les clés de configuration de canal lorsque `configWrites` est activé.
|
||||
- Les métadonnées de sujet/objectifs de canal sont traitées comme un contexte non fiable et peuvent être injectées dans le contexte de routage.
|
||||
- Le lanceur de fil et l'initialisation du contexte d'historique initial de fil sont filtrés par les listes d'autorisation d'expéditeur configurées, selon le cas.
|
||||
- Les actions de bloc et interactions de modal émettent des événements système structurés `Slack interaction: ...` avec des champs de charge utile riches :
|
||||
- actions de bloc : valeurs sélectionnées, libellés, valeurs de sélecteur et métadonnées `workflow_*`
|
||||
- événements de modal `view_submission` et `view_closed` avec métadonnées de canal routées et entrées de formulaire
|
||||
- Le message initial du fil et l’amorçage initial du contexte d’historique du fil sont filtrés selon les listes d’autorisation d’expéditeur configurées, lorsque applicable.
|
||||
- Les actions de bloc et les interactions modales émettent des événements système structurés `Slack interaction: ...` avec des champs riches de charge utile :
|
||||
- actions de bloc : valeurs sélectionnées, libellés, valeurs du sélecteur et métadonnées `workflow_*`
|
||||
- événements modaux `view_submission` et `view_closed` avec métadonnées de canal routées et entrées de formulaire
|
||||
|
||||
## Pointeurs vers la référence de configuration
|
||||
|
||||
Référence principale :
|
||||
Référence principale :
|
||||
|
||||
- [Référence de configuration - Slack](/fr/gateway/configuration-reference#slack)
|
||||
|
||||
Champs Slack à fort signal :
|
||||
- mode/auth : `mode`, `botToken`, `appToken`, `signingSecret`, `webhookPath`, `accounts.*`
|
||||
- accès DM : `dm.enabled`, `dmPolicy`, `allowFrom` (hérité : `dm.policy`, `dm.allowFrom`), `dm.groupEnabled`, `dm.groupChannels`
|
||||
- bascule de compatibilité : `dangerouslyAllowNameMatching` (ultime recours ; laissez désactivé sauf besoin)
|
||||
- accès canal : `groupPolicy`, `channels.*`, `channels.*.users`, `channels.*.requireMention`
|
||||
- fils/historique : `replyToMode`, `replyToModeByChatType`, `thread.*`, `historyLimit`, `dmHistoryLimit`, `dms.*.historyLimit`
|
||||
- livraison : `textChunkLimit`, `chunkMode`, `mediaMaxMb`, `streaming`, `nativeStreaming`
|
||||
- ops/fonctionnalités : `configWrites`, `commands.native`, `slashCommand.*`, `actions.*`, `userToken`, `userTokenReadOnly`
|
||||
Champs Slack à fort signal :
|
||||
- mode/auth : `mode`, `botToken`, `appToken`, `signingSecret`, `webhookPath`, `accounts.*`
|
||||
- accès aux messages privés : `dm.enabled`, `dmPolicy`, `allowFrom` (hérité : `dm.policy`, `dm.allowFrom`), `dm.groupEnabled`, `dm.groupChannels`
|
||||
- option de compatibilité : `dangerouslyAllowNameMatching` (dernier recours ; laissez-la désactivée sauf nécessité)
|
||||
- accès aux canaux : `groupPolicy`, `channels.*`, `channels.*.users`, `channels.*.requireMention`
|
||||
- fils/historique : `replyToMode`, `replyToModeByChatType`, `thread.*`, `historyLimit`, `dmHistoryLimit`, `dms.*.historyLimit`
|
||||
- livraison : `textChunkLimit`, `chunkMode`, `mediaMaxMb`, `streaming`, `streaming.nativeTransport`
|
||||
- opérations/fonctionnalités : `configWrites`, `commands.native`, `slashCommand.*`, `actions.*`, `userToken`, `userTokenReadOnly`
|
||||
|
||||
## Dépannage
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Aucune réponse dans les canaux">
|
||||
Vérifiez, dans l'ordre :
|
||||
Vérifiez, dans l’ordre :
|
||||
|
||||
- `groupPolicy`
|
||||
- liste d'autorisation des canaux (`channels.slack.channels`)
|
||||
- liste d’autorisation des canaux (`channels.slack.channels`)
|
||||
- `requireMention`
|
||||
- liste d'autorisation `users` par canal
|
||||
- liste d’autorisation `users` par canal
|
||||
|
||||
Commandes utiles :
|
||||
Commandes utiles :
|
||||
|
||||
```bash
|
||||
openclaw channels status --probe
|
||||
@ -717,12 +723,12 @@ openclaw doctor
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Messages DM ignorés">
|
||||
Vérifiez :
|
||||
<Accordion title="Messages privés ignorés">
|
||||
Vérifiez :
|
||||
|
||||
- `channels.slack.dm.enabled`
|
||||
- `channels.slack.dmPolicy` (ou hérité `channels.slack.dm.policy`)
|
||||
- approbations d'appairage / entrées de liste d'autorisation
|
||||
- `channels.slack.dmPolicy` (ou l’hérité `channels.slack.dm.policy`)
|
||||
- approbations d’association / entrées de liste d’autorisation
|
||||
|
||||
```bash
|
||||
openclaw pairing list slack
|
||||
@ -731,17 +737,17 @@ openclaw pairing list slack
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Le mode socket ne se connecte pas">
|
||||
Validez les jetons bot + app et l'activation de Socket Mode dans les paramètres de l'application Slack.
|
||||
Validez les jetons bot + app et l’activation de Socket Mode dans les paramètres de l’app Slack.
|
||||
|
||||
Si `openclaw channels status --probe --json` affiche `botTokenStatus` ou
|
||||
`appTokenStatus: "configured_unavailable"`, le compte Slack est
|
||||
configuré mais l'exécution actuelle n'a pas pu résoudre la
|
||||
valeur adossée à SecretRef.
|
||||
configuré mais l’exécution actuelle n’a pas pu résoudre la valeur
|
||||
fournie via SecretRef.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Le mode HTTP ne reçoit pas d'événements">
|
||||
Validez :
|
||||
<Accordion title="Le mode HTTP ne reçoit pas d’événements">
|
||||
Validez :
|
||||
|
||||
- signing secret
|
||||
- chemin webhook
|
||||
@ -749,25 +755,25 @@ openclaw pairing list slack
|
||||
- `webhookPath` unique par compte HTTP
|
||||
|
||||
Si `signingSecretStatus: "configured_unavailable"` apparaît dans les
|
||||
instantanés de compte, le compte HTTP est configuré mais l'exécution actuelle n'a pas pu
|
||||
résoudre le signing secret adossé à SecretRef.
|
||||
instantanés de compte, le compte HTTP est configuré mais l’exécution actuelle n’a pas pu
|
||||
résoudre le signing secret fourni via SecretRef.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Les commandes natives/slash ne se déclenchent pas">
|
||||
Vérifiez si vous vouliez :
|
||||
Vérifiez ce que vous vouliez utiliser :
|
||||
|
||||
- le mode de commande native (`channels.slack.commands.native: true`) avec les slash commands correspondantes enregistrées dans Slack
|
||||
- ou le mode de slash command unique (`channels.slack.slashCommand.enabled: true`)
|
||||
- ou le mode de commande slash unique (`channels.slack.slashCommand.enabled: true`)
|
||||
|
||||
Vérifiez aussi `commands.useAccessGroups` et les listes d'autorisation de canal/utilisateur.
|
||||
Vérifiez également `commands.useAccessGroups` et les listes d’autorisation de canaux/utilisateurs.
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## Lié
|
||||
## Liens connexes
|
||||
|
||||
- [Appairage](/fr/channels/pairing)
|
||||
- [Association](/fr/channels/pairing)
|
||||
- [Groupes](/fr/channels/groups)
|
||||
- [Sécurité](/fr/gateway/security)
|
||||
- [Routage des canaux](/fr/channels/channel-routing)
|
||||
|
||||
@ -2,13 +2,13 @@
|
||||
read_when:
|
||||
- Vous voulez comprendre comment fonctionne la mémoire
|
||||
- Vous voulez savoir quels fichiers de mémoire écrire
|
||||
summary: Comment OpenClaw se souvient des choses entre les sessions
|
||||
summary: Comment OpenClaw se souvient des choses d’une session à l’autre
|
||||
title: Vue d’ensemble de la mémoire
|
||||
x-i18n:
|
||||
generated_at: "2026-04-06T03:06:29Z"
|
||||
generated_at: "2026-04-08T06:00:58Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: d19d4fa9c4b3232b7a97f7a382311d2a375b562040de15e9fe4a0b1990b825e7
|
||||
source_hash: 3bb8552341b0b651609edaaae826a22fdc535d240aed4fad4af4b069454004af
|
||||
source_path: concepts/memory.md
|
||||
workflow: 15
|
||||
---
|
||||
@ -17,38 +17,57 @@ x-i18n:
|
||||
|
||||
OpenClaw se souvient des choses en écrivant des **fichiers Markdown simples** dans l’espace de travail de votre agent. Le modèle ne « se souvient » que de ce qui est enregistré sur le disque -- il n’y a pas d’état caché.
|
||||
|
||||
## Comment cela fonctionne
|
||||
## Fonctionnement
|
||||
|
||||
Votre agent dispose de trois fichiers liés à la mémoire :
|
||||
|
||||
- **`MEMORY.md`** -- mémoire à long terme. Faits durables, préférences et décisions. Chargé au début de chaque session DM.
|
||||
- **`MEMORY.md`** -- mémoire à long terme. Faits durables, préférences et décisions. Chargé au début de chaque session de message direct.
|
||||
- **`memory/YYYY-MM-DD.md`** -- notes quotidiennes. Contexte courant et observations. Les notes d’aujourd’hui et d’hier sont chargées automatiquement.
|
||||
- **`DREAMS.md`** (expérimental, facultatif) -- journal des rêves et résumés des cycles de rêve pour examen humain.
|
||||
- **`DREAMS.md`** (expérimental, facultatif) -- journal des rêves et résumés des passes de rêverie pour relecture humaine.
|
||||
|
||||
Ces fichiers se trouvent dans l’espace de travail de l’agent (par défaut `~/.openclaw/workspace`).
|
||||
|
||||
<Tip>
|
||||
Si vous voulez que votre agent se souvienne de quelque chose, demandez-le-lui simplement : « Souviens-toi que je préfère TypeScript. » Il l’écrira dans le fichier approprié.
|
||||
Si vous voulez que votre agent se souvienne de quelque chose, demandez-le-lui simplement : "Remember that I
|
||||
prefer TypeScript." Il l’écrira dans le fichier approprié.
|
||||
</Tip>
|
||||
|
||||
## Outils de mémoire
|
||||
|
||||
L’agent dispose de deux outils pour travailler avec la mémoire :
|
||||
|
||||
- **`memory_search`** -- trouve les notes pertinentes à l’aide d’une recherche sémantique, même lorsque la formulation diffère de l’original.
|
||||
- **`memory_get`** -- lit un fichier de mémoire spécifique ou une plage de lignes.
|
||||
- **`memory_search`** -- trouve des notes pertinentes à l’aide d’une recherche sémantique, même lorsque la formulation diffère de l’original.
|
||||
- **`memory_get`** -- lit un fichier de mémoire précis ou une plage de lignes.
|
||||
|
||||
Ces deux outils sont fournis par le plugin de mémoire actif (par défaut : `memory-core`).
|
||||
Les deux outils sont fournis par le plugin de mémoire actif (par défaut : `memory-core`).
|
||||
|
||||
## Recherche en mémoire
|
||||
## Plugin compagnon Memory Wiki
|
||||
|
||||
Lorsqu’un fournisseur d’embeddings est configuré, `memory_search` utilise une **recherche hybride** -- combinant similarité vectorielle (sens sémantique) et correspondance par mots-clés (termes exacts comme les identifiants et les symboles de code). Cela fonctionne immédiatement dès que vous disposez d’une clé API pour n’importe quel fournisseur pris en charge.
|
||||
Si vous voulez que la mémoire durable fonctionne davantage comme une base de connaissances maintenue que comme de simples notes brutes, utilisez le plugin groupé `memory-wiki`.
|
||||
|
||||
`memory-wiki` compile les connaissances durables dans un coffre wiki avec :
|
||||
|
||||
- une structure de page déterministe
|
||||
- des affirmations et preuves structurées
|
||||
- le suivi des contradictions et de la fraîcheur
|
||||
- des tableaux de bord générés
|
||||
- des synthèses compilées pour les consommateurs agent/runtime
|
||||
- des outils natifs du wiki comme `wiki_search`, `wiki_get`, `wiki_apply` et `wiki_lint`
|
||||
|
||||
Il ne remplace pas le plugin de mémoire actif. Le plugin de mémoire actif reste responsable du rappel, de la promotion et de la rêverie. `memory-wiki` ajoute à côté une couche de connaissances riche en provenance.
|
||||
|
||||
Voir [Memory Wiki](/fr/plugins/memory-wiki).
|
||||
|
||||
## Recherche dans la mémoire
|
||||
|
||||
Lorsqu’un fournisseur d’embeddings est configuré, `memory_search` utilise une **recherche hybride** -- en combinant la similarité vectorielle (sens sémantique) avec la correspondance par mots-clés (termes exacts comme les identifiants et les symboles de code). Cela fonctionne immédiatement dès que vous disposez d’une clé API pour n’importe quel fournisseur pris en charge.
|
||||
|
||||
<Info>
|
||||
OpenClaw détecte automatiquement votre fournisseur d’embeddings à partir des clés API disponibles. Si vous avez configuré une clé OpenAI, Gemini, Voyage ou Mistral, la recherche en mémoire est activée automatiquement.
|
||||
</Info>
|
||||
|
||||
Pour plus de détails sur le fonctionnement de la recherche, les options de réglage et la configuration des fournisseurs, consultez [Recherche en mémoire](/fr/concepts/memory-search).
|
||||
Pour en savoir plus sur le fonctionnement de la recherche, les options de réglage et la configuration des fournisseurs, consultez
|
||||
[Memory Search](/fr/concepts/memory-search).
|
||||
|
||||
## Backends de mémoire
|
||||
|
||||
@ -57,33 +76,42 @@ Pour plus de détails sur le fonctionnement de la recherche, les options de rég
|
||||
Basé sur SQLite. Fonctionne immédiatement avec la recherche par mots-clés, la similarité vectorielle et la recherche hybride. Aucune dépendance supplémentaire.
|
||||
</Card>
|
||||
<Card title="QMD" icon="search" href="/fr/concepts/memory-qmd">
|
||||
Sidecar local-first avec reranking, expansion de requêtes et possibilité d’indexer des répertoires en dehors de l’espace de travail.
|
||||
Sidecar local-first avec reranking, expansion de requête et possibilité d’indexer des répertoires en dehors de l’espace de travail.
|
||||
</Card>
|
||||
<Card title="Honcho" icon="brain" href="/fr/concepts/memory-honcho">
|
||||
Mémoire intersessions native pour l’IA avec modélisation utilisateur, recherche sémantique et prise en compte multi-agent. Installation via plugin.
|
||||
Mémoire intersessions native IA avec modélisation des utilisateurs, recherche sémantique et prise en compte multi-agent. Installation par plugin.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Flush automatique de la mémoire
|
||||
## Couche wiki de connaissances
|
||||
|
||||
Avant que le [compactage](/fr/concepts/compaction) ne résume votre conversation, OpenClaw exécute un tour silencieux qui rappelle à l’agent d’enregistrer le contexte important dans des fichiers de mémoire. Cette fonction est activée par défaut -- vous n’avez rien à configurer.
|
||||
<CardGroup cols={1}>
|
||||
<Card title="Memory Wiki" icon="book" href="/fr/plugins/memory-wiki">
|
||||
Compile la mémoire durable dans un coffre wiki riche en provenance avec affirmations, tableaux de bord, mode pont et workflows compatibles avec Obsidian.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Vidage automatique de la mémoire
|
||||
|
||||
Avant que la [compaction](/fr/concepts/compaction) ne résume votre conversation, OpenClaw exécute un tour silencieux qui rappelle à l’agent d’enregistrer le contexte important dans les fichiers de mémoire. C’est activé par défaut -- vous n’avez rien à configurer.
|
||||
|
||||
<Tip>
|
||||
Le flush de mémoire évite la perte de contexte pendant le compactage. Si votre agent a des faits importants dans la conversation qui ne sont pas encore écrits dans un fichier, ils seront enregistrés automatiquement avant que le résumé n’ait lieu.
|
||||
Le vidage de la mémoire évite la perte de contexte pendant la compaction. Si votre agent a des faits importants dans la conversation qui ne sont pas encore écrits dans un fichier, ils seront enregistrés automatiquement avant que le résumé n’ait lieu.
|
||||
</Tip>
|
||||
|
||||
## Rêve (expérimental)
|
||||
## Rêverie (expérimental)
|
||||
|
||||
Le rêve est un passage facultatif de consolidation en arrière-plan pour la mémoire. Il collecte des signaux à court terme, évalue des candidats et ne promeut dans la mémoire à long terme (`MEMORY.md`) que les éléments qualifiés.
|
||||
La rêverie est une passe facultative de consolidation en arrière-plan pour la mémoire. Elle collecte des signaux à court terme, évalue les candidats et ne promeut que les éléments qualifiés vers la mémoire à long terme (`MEMORY.md`).
|
||||
|
||||
Il est conçu pour maintenir une mémoire à long terme à fort signal :
|
||||
Elle est conçue pour conserver un signal élevé dans la mémoire à long terme :
|
||||
|
||||
- **Sur adhésion** : désactivé par défaut.
|
||||
- **Planifié** : lorsqu’il est activé, `memory-core` gère automatiquement une tâche cron récurrente pour un cycle complet de rêve.
|
||||
- **Avec seuils** : les promotions doivent passer des seuils de score, de fréquence de rappel et de diversité des requêtes.
|
||||
- **Révisable** : les résumés de phase et les entrées du journal sont écrits dans `DREAMS.md` pour examen humain.
|
||||
- **Sur adhésion** : désactivée par défaut.
|
||||
- **Planifiée** : lorsqu’elle est activée, `memory-core` gère automatiquement une tâche cron récurrente pour une passe complète de rêverie.
|
||||
- **À seuil** : les promotions doivent passer des seuils de score, de fréquence de rappel et de diversité des requêtes.
|
||||
- **Révisable** : les résumés de phase et les entrées du journal sont écrits dans `DREAMS.md` pour relecture humaine.
|
||||
|
||||
Pour le comportement des phases, les signaux de score et les détails du journal des rêves, consultez [Rêve (expérimental)](/concepts/dreaming).
|
||||
Pour le comportement des phases, les signaux de scoring et les détails du journal des rêves, consultez
|
||||
[Dreaming (experimental)](/fr/concepts/dreaming).
|
||||
|
||||
## CLI
|
||||
|
||||
@ -97,9 +125,11 @@ openclaw memory index --force # Reconstruire l’index
|
||||
|
||||
- [Builtin Memory Engine](/fr/concepts/memory-builtin) -- backend SQLite par défaut
|
||||
- [QMD Memory Engine](/fr/concepts/memory-qmd) -- sidecar local-first avancé
|
||||
- [Honcho Memory](/fr/concepts/memory-honcho) -- mémoire intersessions native pour l’IA
|
||||
- [Recherche en mémoire](/fr/concepts/memory-search) -- pipeline de recherche, fournisseurs et réglage
|
||||
- [Rêve (expérimental)](/concepts/dreaming) -- promotion en arrière-plan
|
||||
- [Honcho Memory](/fr/concepts/memory-honcho) -- mémoire intersessions native IA
|
||||
- [Memory Wiki](/fr/plugins/memory-wiki) -- coffre de connaissances compilé et outils natifs du wiki
|
||||
- [Memory Search](/fr/concepts/memory-search) -- pipeline de recherche, fournisseurs et
|
||||
réglage
|
||||
- [Dreaming (experimental)](/fr/concepts/dreaming) -- promotion en arrière-plan
|
||||
du rappel à court terme vers la mémoire à long terme
|
||||
- [Référence de configuration de la mémoire](/fr/reference/memory-config) -- tous les paramètres de configuration
|
||||
- [Compactage](/fr/concepts/compaction) -- comment le compactage interagit avec la mémoire
|
||||
- [Compaction](/fr/concepts/compaction) -- comment la compaction interagit avec la mémoire
|
||||
|
||||
@ -1,14 +1,14 @@
|
||||
---
|
||||
read_when:
|
||||
- Vous avez besoin d'une référence de configuration des modèles fournisseur par fournisseur
|
||||
- Vous voulez des exemples de configurations ou des commandes d'onboarding CLI pour les fournisseurs de modèles
|
||||
summary: Vue d'ensemble des fournisseurs de modèles avec exemples de configurations et flux CLI
|
||||
- Vous avez besoin d'une référence de configuration des modèles, fournisseur par fournisseur
|
||||
- Vous voulez des exemples de config ou des commandes d'intégration CLI pour les fournisseurs de modèles
|
||||
summary: Vue d'ensemble des fournisseurs de modèles avec des exemples de config + des flux CLI
|
||||
title: Fournisseurs de modèles
|
||||
x-i18n:
|
||||
generated_at: "2026-04-08T02:16:05Z"
|
||||
generated_at: "2026-04-08T06:02:59Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 26b36a2bc19a28a7ef39aa8e81a0050fea1d452ac4969122e5cdf8755e690258
|
||||
source_hash: 558ac9e34b67fcc3dd6791a01bebc17e1c34152fa6c5611593d681e8cfa532d9
|
||||
source_path: concepts/model-providers.md
|
||||
workflow: 15
|
||||
---
|
||||
@ -16,25 +16,25 @@ x-i18n:
|
||||
# Fournisseurs de modèles
|
||||
|
||||
Cette page couvre les **fournisseurs de LLM/modèles** (et non les canaux de chat comme WhatsApp/Telegram).
|
||||
Pour les règles de sélection des modèles, voir [/concepts/models](/fr/concepts/models).
|
||||
Pour les règles de sélection des modèles, consultez [/concepts/models](/fr/concepts/models).
|
||||
|
||||
## Règles rapides
|
||||
|
||||
- Les références de modèle utilisent `provider/model` (exemple : `opencode/claude-opus-4-6`).
|
||||
- Les références de modèles utilisent `provider/model` (exemple : `opencode/claude-opus-4-6`).
|
||||
- Si vous définissez `agents.defaults.models`, cela devient la liste d'autorisation.
|
||||
- Assistants CLI : `openclaw onboard`, `openclaw models list`, `openclaw models set <provider/model>`.
|
||||
- Les règles d'exécution de secours, les sondes de refroidissement et la persistance des remplacements de session sont
|
||||
documentées dans [/concepts/model-failover](/fr/concepts/model-failover).
|
||||
- `models.providers.*.models[].contextWindow` est la métadonnée native du modèle ;
|
||||
`models.providers.*.models[].contextTokens` est la limite d'exécution effective.
|
||||
`models.providers.*.models[].contextTokens` est la limite effective à l'exécution.
|
||||
- Les plugins de fournisseur peuvent injecter des catalogues de modèles via `registerProvider({ catalog })` ;
|
||||
OpenClaw fusionne cette sortie dans `models.providers` avant d'écrire
|
||||
`models.json`.
|
||||
- Les manifestes de fournisseur peuvent déclarer `providerAuthEnvVars` afin que les sondes d'authentification génériques basées sur l'environnement
|
||||
n'aient pas besoin de charger le runtime du plugin. La carte restante des variables d'environnement du cœur
|
||||
sert désormais uniquement aux fournisseurs non plugin/cœur et à quelques cas de priorité génériques
|
||||
comme l'onboarding Anthropic avec priorité à la clé API.
|
||||
- Les plugins de fournisseur peuvent également posséder le comportement d'exécution du fournisseur via
|
||||
n'aient pas besoin de charger l'exécution du plugin. La carte restante des variables d'environnement du noyau
|
||||
est désormais réservée aux fournisseurs non plugin/du noyau et à quelques cas de précédence générique
|
||||
comme l'intégration Anthropic avec priorité à la clé API.
|
||||
- Les plugins de fournisseur peuvent aussi posséder le comportement d'exécution du fournisseur via
|
||||
`normalizeModelId`, `normalizeTransport`, `normalizeConfig`,
|
||||
`applyNativeStreamingUsageCompat`, `resolveConfigApiKey`,
|
||||
`resolveSyntheticAuth`, `shouldDeferSyntheticProfileAuth`,
|
||||
@ -50,184 +50,184 @@ Pour les règles de sélection des modèles, voir [/concepts/models](/fr/concept
|
||||
`isCacheTtlEligible`, `buildMissingAuthMessage`, `suppressBuiltInModel`,
|
||||
`augmentModelCatalog`, `isBinaryThinking`, `supportsXHighThinking`,
|
||||
`resolveDefaultThinkingLevel`, `applyConfigDefaults`, `isModernModelRef`,
|
||||
`prepareRuntimeAuth`, `resolveUsageAuth`, `fetchUsageSnapshot`, and
|
||||
`prepareRuntimeAuth`, `resolveUsageAuth`, `fetchUsageSnapshot`, et
|
||||
`onModelSelected`.
|
||||
- Remarque : les `capabilities` du runtime fournisseur sont des métadonnées de runner partagées (famille de fournisseur, particularités de transcription/outillage, indications de transport/cache). Ce n'est pas la
|
||||
même chose que le [modèle de capacité public](/fr/plugins/architecture#public-capability-model)
|
||||
- Remarque : les `capabilities` de l'exécution du fournisseur sont des métadonnées partagées du runner (famille de fournisseurs, particularités des transcriptions/outils, indices de transport/cache). Ce n'est pas le
|
||||
même modèle que le [modèle public de capacités](/fr/plugins/architecture#public-capability-model)
|
||||
qui décrit ce qu'un plugin enregistre (inférence de texte, parole, etc.).
|
||||
|
||||
## Comportement de fournisseur géré par le plugin
|
||||
## Comportement du fournisseur possédé par le plugin
|
||||
|
||||
Les plugins de fournisseur peuvent désormais posséder la majeure partie de la logique spécifique au fournisseur tandis qu'OpenClaw conserve
|
||||
la boucle d'inférence générique.
|
||||
|
||||
Répartition typique :
|
||||
|
||||
- `auth[].run` / `auth[].runNonInteractive` : le fournisseur gère les flux d'onboarding/connexion
|
||||
- `auth[].run` / `auth[].runNonInteractive` : le fournisseur possède les flux d'intégration/connexion
|
||||
pour `openclaw onboard`, `openclaw models auth`, et la configuration sans interface
|
||||
- `wizard.setup` / `wizard.modelPicker` : le fournisseur gère les libellés de choix d'authentification,
|
||||
les alias hérités, les indications de liste d'autorisation d'onboarding et les entrées de configuration dans les sélecteurs d'onboarding/modèle
|
||||
- `wizard.setup` / `wizard.modelPicker` : le fournisseur possède les libellés de choix d'authentification,
|
||||
les alias hérités, les indices de liste d'autorisation pour l'intégration, et les entrées de configuration dans les sélecteurs d'intégration/de modèle
|
||||
- `catalog` : le fournisseur apparaît dans `models.providers`
|
||||
- `normalizeModelId` : le fournisseur normalise les identifiants de modèle hérités/préversion avant
|
||||
- `normalizeModelId` : le fournisseur normalise les identifiants de modèle hérités/preview avant
|
||||
la recherche ou la canonicalisation
|
||||
- `normalizeTransport` : le fournisseur normalise la famille de transport `api` / `baseUrl`
|
||||
- `normalizeTransport` : le fournisseur normalise `api` / `baseUrl` de la famille de transport
|
||||
avant l'assemblage générique du modèle ; OpenClaw vérifie d'abord le fournisseur correspondant,
|
||||
puis les autres plugins de fournisseur capables de hooks jusqu'à ce que l'un modifie réellement le
|
||||
transport
|
||||
- `normalizeConfig` : le fournisseur normalise la configuration `models.providers.<id>` avant
|
||||
que le runtime ne l'utilise ; OpenClaw vérifie d'abord le fournisseur correspondant, puis les autres
|
||||
plugins de fournisseur capables de hooks jusqu'à ce que l'un modifie réellement la configuration. Si aucun
|
||||
hook de fournisseur ne réécrit la configuration, les assistants groupés de la famille Google
|
||||
normalisent encore les entrées de fournisseur Google prises en charge.
|
||||
- `applyNativeStreamingUsageCompat` : le fournisseur applique des réécritures de compatibilité d'usage de streaming natif pilotées par les endpoints pour les fournisseurs configurés
|
||||
- `resolveConfigApiKey` : le fournisseur résout l'authentification par marqueur d'environnement pour les fournisseurs configurés
|
||||
sans forcer le chargement complet de l'authentification du runtime. `amazon-bedrock` a également un
|
||||
résolveur intégré de marqueur d'environnement AWS ici, même si l'authentification runtime de Bedrock utilise
|
||||
puis les autres plugins de fournisseur capables d'utiliser ce hook jusqu'à ce que l'un modifie réellement
|
||||
le transport
|
||||
- `normalizeConfig` : le fournisseur normalise la config `models.providers.<id>` avant
|
||||
son utilisation à l'exécution ; OpenClaw vérifie d'abord le fournisseur correspondant, puis les autres
|
||||
plugins de fournisseur capables d'utiliser ce hook jusqu'à ce que l'un modifie réellement la config. Si aucun
|
||||
hook de fournisseur ne réécrit la config, les assistants Google intégrés de la famille Google
|
||||
normalisent encore les entrées prises en charge du fournisseur Google.
|
||||
- `applyNativeStreamingUsageCompat` : le fournisseur applique des réécritures de compatibilité d'utilisation native en streaming pilotées par l'endpoint pour les fournisseurs de config
|
||||
- `resolveConfigApiKey` : le fournisseur résout l'authentification par marqueur d'environnement pour les fournisseurs de config
|
||||
sans forcer le chargement complet de l'authentification à l'exécution. `amazon-bedrock` dispose aussi ici d'un
|
||||
résolveur intégré de marqueur d'environnement AWS, même si l'authentification d'exécution Bedrock utilise
|
||||
la chaîne par défaut du SDK AWS.
|
||||
- `resolveSyntheticAuth` : le fournisseur peut exposer une disponibilité d'authentification locale/autohébergée ou autre
|
||||
basée sur la configuration sans persister de secrets en clair
|
||||
- `shouldDeferSyntheticProfileAuth` : le fournisseur peut marquer les espaces réservés de profil synthétique stockés
|
||||
comme ayant une priorité plus faible que l'authentification basée sur l'environnement/la configuration
|
||||
- `resolveDynamicModel` : le fournisseur accepte des identifiants de modèle qui ne sont pas encore présents dans le
|
||||
- `resolveSyntheticAuth` : le fournisseur peut exposer la disponibilité d'une authentification locale/autohébergée ou autre
|
||||
basée sur la config sans persister des secrets en clair
|
||||
- `shouldDeferSyntheticProfileAuth` : le fournisseur peut marquer les espaces réservés des profils synthétiques stockés
|
||||
comme ayant une priorité inférieure à l'authentification basée sur l'environnement/la config
|
||||
- `resolveDynamicModel` : le fournisseur accepte les identifiants de modèle qui ne sont pas encore présents dans le
|
||||
catalogue statique local
|
||||
- `prepareDynamicModel` : le fournisseur a besoin d'un rafraîchissement des métadonnées avant de réessayer
|
||||
la résolution dynamique
|
||||
- `normalizeResolvedModel` : le fournisseur a besoin de réécritures du transport ou de l'URL de base
|
||||
- `contributeResolvedModelCompat` : le fournisseur apporte des drapeaux de compatibilité pour ses
|
||||
modèles de fournisseur même lorsqu'ils arrivent via un autre transport compatible
|
||||
- `capabilities` : le fournisseur publie les particularités de transcription/outillage/famille de fournisseur
|
||||
- `normalizeToolSchemas` : le fournisseur nettoie les schémas d'outils avant que le
|
||||
runner intégré ne les voie
|
||||
- `contributeResolvedModelCompat` : le fournisseur contribue des indicateurs de compatibilité pour ses
|
||||
modèles fournisseur même lorsqu'ils arrivent via un autre transport compatible
|
||||
- `capabilities` : le fournisseur publie des particularités de transcription/outillage/famille de fournisseur
|
||||
- `normalizeToolSchemas` : le fournisseur nettoie les schémas d'outil avant que le
|
||||
runner embarqué ne les voie
|
||||
- `inspectToolSchemas` : le fournisseur expose des avertissements de schéma spécifiques au transport
|
||||
après normalisation
|
||||
- `resolveReasoningOutputMode` : le fournisseur choisit les contrats de sortie de raisonnement natifs ou balisés
|
||||
- `prepareExtraParams` : le fournisseur définit par défaut ou normalise les paramètres de requête par modèle
|
||||
- `createStreamFn` : le fournisseur remplace le chemin de flux normal par un transport
|
||||
entièrement personnalisé
|
||||
- `wrapStreamFn` : le fournisseur applique des wrappers de compatibilité des en-têtes/corps/modèle de requête
|
||||
- `resolveTransportTurnState` : le fournisseur fournit des en-têtes ou métadonnées
|
||||
de transport natif par tour
|
||||
- `resolveWebSocketSessionPolicy` : le fournisseur fournit des en-têtes de session WebSocket natifs
|
||||
ou une politique de refroidissement de session
|
||||
- `createEmbeddingProvider` : le fournisseur gère le comportement d'embedding mémoire quand il
|
||||
doit appartenir au plugin de fournisseur plutôt qu'au répartiteur central d'embeddings
|
||||
- `formatApiKey` : le fournisseur formate les profils d'authentification stockés en chaîne
|
||||
`apiKey` attendue par le transport au runtime
|
||||
- `refreshOAuth` : le fournisseur gère le rafraîchissement OAuth quand les
|
||||
mécanismes de rafraîchissement partagés `pi-ai` ne suffisent pas
|
||||
- `buildAuthDoctorHint` : le fournisseur ajoute des indications de réparation quand le rafraîchissement OAuth
|
||||
- `prepareExtraParams` : le fournisseur applique des valeurs par défaut ou normalise les paramètres de requête par modèle
|
||||
- `createStreamFn` : le fournisseur remplace le chemin de flux normal par un
|
||||
transport entièrement personnalisé
|
||||
- `wrapStreamFn` : le fournisseur applique des wrappers de compatibilité requête/en-têtes/corps/modèle
|
||||
- `resolveTransportTurnState` : le fournisseur fournit les
|
||||
en-têtes ou métadonnées natifs de transport par tour
|
||||
- `resolveWebSocketSessionPolicy` : le fournisseur fournit les
|
||||
en-têtes natifs de session WebSocket ou la politique de refroidissement de session
|
||||
- `createEmbeddingProvider` : le fournisseur possède le comportement des embeddings mémoire lorsqu'il
|
||||
relève du plugin de fournisseur plutôt que du commutateur central d'embeddings du noyau
|
||||
- `formatApiKey` : le fournisseur formate les profils d'authentification stockés dans la chaîne
|
||||
`apiKey` attendue par le transport à l'exécution
|
||||
- `refreshOAuth` : le fournisseur possède le rafraîchissement OAuth lorsque les rafraîchisseurs
|
||||
partagés `pi-ai` ne suffisent pas
|
||||
- `buildAuthDoctorHint` : le fournisseur ajoute des conseils de réparation lorsque l'actualisation OAuth
|
||||
échoue
|
||||
- `matchesContextOverflowError` : le fournisseur reconnaît les erreurs de dépassement de fenêtre de contexte
|
||||
spécifiques au fournisseur que les heuristiques génériques manqueraient
|
||||
- `classifyFailoverReason` : le fournisseur mappe les erreurs brutes de transport/API spécifiques au fournisseur
|
||||
vers des raisons de bascule comme la limitation de débit ou la surcharge
|
||||
- `isCacheTtlEligible` : le fournisseur décide quels identifiants de modèle en amont prennent en charge le TTL du cache de prompt
|
||||
- `matchesContextOverflowError` : le fournisseur reconnaît les erreurs spécifiques au fournisseur
|
||||
de dépassement de fenêtre de contexte que les heuristiques génériques ne détecteraient pas
|
||||
- `classifyFailoverReason` : le fournisseur mappe les erreurs brutes spécifiques au fournisseur de transport/API
|
||||
vers des raisons de basculement comme la limitation de débit ou la surcharge
|
||||
- `isCacheTtlEligible` : le fournisseur décide quels identifiants de modèle amont prennent en charge le TTL du cache de prompt
|
||||
- `buildMissingAuthMessage` : le fournisseur remplace l'erreur générique du magasin d'authentification
|
||||
par une indication de récupération spécifique au fournisseur
|
||||
par un conseil de récupération spécifique au fournisseur
|
||||
- `suppressBuiltInModel` : le fournisseur masque les lignes amont obsolètes et peut renvoyer une
|
||||
erreur gérée par le fournisseur pour les échecs de résolution directe
|
||||
erreur appartenant au fournisseur en cas d'échec de résolution directe
|
||||
- `augmentModelCatalog` : le fournisseur ajoute des lignes de catalogue synthétiques/finales après
|
||||
la découverte et la fusion de configuration
|
||||
- `isBinaryThinking` : le fournisseur gère l'UX de réflexion binaire activée/désactivée
|
||||
- `supportsXHighThinking` : le fournisseur active `xhigh` pour certains modèles sélectionnés
|
||||
- `resolveDefaultThinkingLevel` : le fournisseur gère la politique `/think` par défaut pour une
|
||||
la découverte et la fusion de config
|
||||
- `isBinaryThinking` : le fournisseur possède l'UX de réflexion binaire activé/désactivé
|
||||
- `supportsXHighThinking` : le fournisseur fait entrer certains modèles dans `xhigh`
|
||||
- `resolveDefaultThinkingLevel` : le fournisseur possède la politique `/think` par défaut pour une
|
||||
famille de modèles
|
||||
- `applyConfigDefaults` : le fournisseur applique des valeurs globales par défaut spécifiques au fournisseur
|
||||
pendant la matérialisation de la configuration selon le mode d'authentification, l'environnement ou la famille de modèles
|
||||
- `isModernModelRef` : le fournisseur gère la correspondance des modèles préférés live/smoke
|
||||
- `prepareRuntimeAuth` : le fournisseur transforme un identifiant configuré en
|
||||
jeton runtime de courte durée
|
||||
- `resolveUsageAuth` : le fournisseur résout les identifiants d'usage/quota pour `/usage`
|
||||
lors de la matérialisation de la config en fonction du mode d'authentification, de l'environnement ou de la famille de modèles
|
||||
- `isModernModelRef` : le fournisseur possède la correspondance des modèles préférés live/smoke
|
||||
- `prepareRuntimeAuth` : le fournisseur transforme un identifiant configuré en un jeton d'exécution
|
||||
de courte durée
|
||||
- `resolveUsageAuth` : le fournisseur résout les identifiants d'utilisation/quota pour `/usage`
|
||||
et les surfaces associées de statut/rapport
|
||||
- `fetchUsageSnapshot` : le fournisseur gère la récupération/l'analyse de l'endpoint d'usage tandis que
|
||||
le cœur conserve l'enveloppe de résumé et le formatage
|
||||
- `onModelSelected` : le fournisseur exécute des effets secondaires après la sélection
|
||||
du modèle comme la télémétrie ou la tenue de session gérée par le fournisseur
|
||||
- `fetchUsageSnapshot` : le fournisseur possède la récupération/l'analyse de l'endpoint d'utilisation tandis que
|
||||
le noyau conserve le shell de résumé et le formatage
|
||||
- `onModelSelected` : le fournisseur exécute des effets secondaires après sélection comme la
|
||||
télémétrie ou la tenue de session appartenant au fournisseur
|
||||
|
||||
Exemples groupés actuels :
|
||||
Exemples intégrés actuels :
|
||||
|
||||
- `anthropic` : solution de secours de compatibilité ascendante Claude 4.6, indications de réparation d'authentification, récupération
|
||||
de l'endpoint d'usage, métadonnées de TTL de cache/famille de fournisseur, et valeurs globales par défaut
|
||||
conscientes de l'authentification
|
||||
- `amazon-bedrock` : correspondance gérée par le fournisseur des dépassements de contexte et classification des raisons de
|
||||
bascule pour les erreurs Bedrock spécifiques de limitation/pas prêt, plus la famille de replay partagée `anthropic-by-model` pour des garde-fous de
|
||||
politique de relecture Claude uniquement sur le trafic Anthropic
|
||||
- `anthropic-vertex` : garde-fous de politique de relecture Claude uniquement sur le trafic
|
||||
- `anthropic` : fallback de compatibilité ascendante Claude 4.6, conseils de réparation d'authentification, récupération de l'endpoint
|
||||
d'utilisation, métadonnées cache-TTL/famille de fournisseur, et valeurs par défaut globales de config
|
||||
sensibles à l'authentification
|
||||
- `amazon-bedrock` : correspondance du dépassement de contexte possédée par le fournisseur et classification des
|
||||
raisons de basculement pour les erreurs Bedrock spécifiques de limitation/pas prêt, plus la famille de replay partagée `anthropic-by-model` pour les protections de politique de replay Claude uniquement
|
||||
sur le trafic Anthropic
|
||||
- `anthropic-vertex` : protections de politique de replay Claude uniquement sur le trafic
|
||||
de messages Anthropic
|
||||
- `openrouter` : identifiants de modèle pass-through, wrappers de requête, indications de capacité
|
||||
du fournisseur, assainissement des signatures de pensée Gemini sur le trafic Gemini proxifié,
|
||||
injection de raisonnement proxy via la famille de flux `openrouter-thinking`,
|
||||
transfert des métadonnées de routage et politique de TTL de cache
|
||||
- `github-copilot` : onboarding/connexion d'appareil, solution de secours de modèle de compatibilité ascendante,
|
||||
indications de transcription Claude-thinking, échange de jeton runtime, et récupération
|
||||
de l'endpoint d'usage
|
||||
- `openai` : solution de secours de compatibilité ascendante GPT-5.4, normalisation directe du transport OpenAI,
|
||||
indications d'authentification manquante tenant compte de Codex, suppression de Spark, lignes de catalogue synthétiques
|
||||
OpenAI/Codex, politique de réflexion/modèle live, normalisation des alias de jetons d'usage
|
||||
- `openrouter` : identifiants de modèle pass-through, wrappers de requête, indices de capacité du fournisseur,
|
||||
assainissement des signatures de pensée Gemini sur le trafic proxy Gemini, injection de raisonnement proxy
|
||||
via la famille de flux `openrouter-thinking`, transfert des métadonnées de routage,
|
||||
et politique cache-TTL
|
||||
- `github-copilot` : intégration/connexion de l'appareil, fallback de modèle à compatibilité ascendante,
|
||||
indices de transcription de réflexion Claude, échange de jeton d'exécution, et récupération de l'endpoint d'utilisation
|
||||
- `openai` : fallback de compatibilité ascendante GPT-5.4, normalisation directe du transport OpenAI,
|
||||
conseils d'authentification manquante sensibles à Codex, suppression de Spark, lignes de catalogue synthétiques
|
||||
OpenAI/Codex, politique thinking/live-model, normalisation des alias de jetons d'utilisation
|
||||
(`input` / `output` et familles `prompt` / `completion`), la famille de flux partagée `openai-responses-defaults`
|
||||
pour les wrappers natifs OpenAI/Codex, métadonnées de famille de fournisseur, enregistrement groupé du fournisseur de génération d'images
|
||||
pour `gpt-image-1`, et enregistrement groupé du fournisseur de génération vidéo
|
||||
pour `sora-2`
|
||||
- `google` et `google-gemini-cli` : solution de secours de compatibilité ascendante Gemini 3.1,
|
||||
validation native de relecture Gemini, assainissement de la relecture bootstrap, mode
|
||||
de sortie de raisonnement balisé, correspondance de modèle moderne, enregistrement groupé du fournisseur de génération d'images
|
||||
pour les modèles Gemini image-preview, et enregistrement groupé
|
||||
du fournisseur de génération vidéo pour les modèles Veo ; Gemini CLI OAuth gère également
|
||||
le formatage des jetons de profil d'authentification, l'analyse des jetons d'usage et la récupération
|
||||
des endpoints de quota pour les surfaces d'usage
|
||||
- `moonshot` : transport partagé, normalisation des charges utiles de réflexion gérée par le plugin
|
||||
- `kilocode` : transport partagé, en-têtes de requête gérés par le plugin, normalisation des charges utiles de raisonnement,
|
||||
assainissement des signatures de pensée Gemini proxifiées et politique de TTL de cache
|
||||
- `zai` : solution de secours de compatibilité ascendante GLM-5, valeurs par défaut `tool_stream`, politique de TTL de cache,
|
||||
politique de réflexion binaire/modèle live, et authentification d'usage + récupération de quota ;
|
||||
les identifiants inconnus `glm-5*` sont synthétisés à partir du modèle groupé `glm-4.7`
|
||||
pour les wrappers natifs OpenAI/Codex, métadonnées de famille de fournisseur, enregistrement intégré du fournisseur
|
||||
de génération d'images pour `gpt-image-1`, et enregistrement intégré du fournisseur
|
||||
de génération vidéo pour `sora-2`
|
||||
- `google` et `google-gemini-cli` : fallback de compatibilité ascendante Gemini 3.1,
|
||||
validation native du replay Gemini, assainissement du replay bootstrap, mode de sortie de raisonnement
|
||||
balisé, correspondance des modèles modernes, enregistrement intégré du fournisseur de génération d'images
|
||||
pour les modèles Gemini image-preview, et enregistrement intégré du
|
||||
fournisseur de génération vidéo pour les modèles Veo ; l'OAuth Gemini CLI
|
||||
possède aussi le formatage des jetons de profil d'authentification, l'analyse des jetons d'utilisation et la récupération de l'endpoint de quota
|
||||
pour les surfaces d'utilisation
|
||||
- `moonshot` : transport partagé, normalisation de la charge utile de réflexion appartenant au plugin
|
||||
- `kilocode` : transport partagé, en-têtes de requête appartenant au plugin, normalisation de la charge utile de raisonnement,
|
||||
assainissement des signatures de pensée proxy-Gemini, et politique
|
||||
cache-TTL
|
||||
- `zai` : fallback de compatibilité ascendante GLM-5, valeurs par défaut `tool_stream`, politique cache-TTL,
|
||||
politique binary-thinking/live-model, et authentification d'utilisation + récupération du quota ;
|
||||
les identifiants inconnus `glm-5*` sont synthétisés à partir du modèle intégré `glm-4.7`
|
||||
- `xai` : normalisation native du transport Responses, réécritures d'alias `/fast` pour
|
||||
les variantes rapides de Grok, `tool_stream` par défaut, nettoyage spécifique à xAI des schémas d'outils /
|
||||
charges utiles de raisonnement, et enregistrement groupé du fournisseur de génération vidéo
|
||||
les variantes rapides de Grok, `tool_stream` par défaut, nettoyage spécifique à xAI des schémas d'outil /
|
||||
charges utiles de raisonnement, et enregistrement intégré du fournisseur de génération vidéo
|
||||
pour `grok-imagine-video`
|
||||
- `mistral` : métadonnées de capacité gérées par le plugin
|
||||
- `opencode` et `opencode-go` : métadonnées de capacité gérées par le plugin plus
|
||||
assainissement des signatures de pensée Gemini proxifiées
|
||||
- `alibaba` : catalogue de génération vidéo géré par le plugin pour les références directes aux modèles Wan
|
||||
telles que `alibaba/wan2.6-t2v`
|
||||
- `byteplus` : catalogues gérés par le plugin plus enregistrement groupé du fournisseur de génération vidéo
|
||||
- `mistral` : métadonnées de capacité appartenant au plugin
|
||||
- `opencode` et `opencode-go` : métadonnées de capacité appartenant au plugin plus
|
||||
assainissement des signatures de pensée proxy-Gemini
|
||||
- `alibaba` : catalogue de génération vidéo appartenant au plugin pour les références directes de modèles Wan
|
||||
comme `alibaba/wan2.6-t2v`
|
||||
- `byteplus` : catalogues appartenant au plugin plus enregistrement intégré du fournisseur de génération vidéo
|
||||
pour les modèles Seedance texte-vers-vidéo/image-vers-vidéo
|
||||
- `fal` : enregistrement groupé du fournisseur de génération vidéo pour des fournisseurs hébergés tiers
|
||||
d'image plus enregistrement groupé du fournisseur de génération vidéo pour des modèles vidéo tiers hébergés
|
||||
- `fal` : enregistrement intégré du fournisseur de génération vidéo pour les modèles vidéo tiers hébergés
|
||||
et enregistrement du fournisseur de génération d'images pour les modèles d'image FLUX, plus enregistrement intégré
|
||||
du fournisseur de génération vidéo pour les modèles vidéo tiers hébergés
|
||||
- `cloudflare-ai-gateway`, `huggingface`, `kimi`, `nvidia`, `qianfan`,
|
||||
`stepfun`, `synthetic`, `venice`, `vercel-ai-gateway`, et `volcengine` :
|
||||
catalogues gérés par le plugin uniquement
|
||||
- `qwen` : catalogues gérés par le plugin pour les modèles texte plus enregistrements partagés
|
||||
de fournisseurs media-understanding et génération vidéo pour ses surfaces multimodales ;
|
||||
la génération vidéo Qwen utilise les endpoints vidéo Standard DashScope avec des modèles Wan groupés tels que `wan2.6-t2v` et `wan2.7-r2v`
|
||||
- `runway` : enregistrement géré par le plugin du fournisseur de génération vidéo pour des modèles natifs
|
||||
`stepfun`, `synthetic`, `venice`, `vercel-ai-gateway` et `volcengine` :
|
||||
catalogues appartenant au plugin uniquement
|
||||
- `qwen` : catalogues appartenant au plugin pour les modèles texte plus enregistrements partagés des fournisseurs
|
||||
media-understanding et génération vidéo pour ses surfaces multimodales ; la génération vidéo Qwen utilise les endpoints vidéo DashScope Standard
|
||||
avec des modèles Wan intégrés comme `wan2.6-t2v` et `wan2.7-r2v`
|
||||
- `runway` : enregistrement du fournisseur de génération vidéo appartenant au plugin pour les modèles natifs
|
||||
Runway basés sur des tâches comme `gen4.5`
|
||||
- `minimax` : catalogues gérés par le plugin, enregistrement groupé du fournisseur de génération vidéo
|
||||
pour les modèles vidéo Hailuo, enregistrement groupé du fournisseur de génération d'images
|
||||
pour `image-01`, sélection hybride de politique de relecture Anthropic/OpenAI,
|
||||
et logique d'authentification/cliché d'usage
|
||||
- `together` : catalogues gérés par le plugin plus enregistrement groupé du fournisseur de génération vidéo
|
||||
- `minimax` : catalogues appartenant au plugin, enregistrement intégré du fournisseur de génération vidéo
|
||||
pour les modèles vidéo Hailuo, enregistrement intégré du fournisseur de génération d'images
|
||||
pour `image-01`, sélection hybride de politique de replay Anthropic/OpenAI,
|
||||
et logique auth/snapshot d'utilisation
|
||||
- `together` : catalogues appartenant au plugin plus enregistrement intégré du fournisseur de génération vidéo
|
||||
pour les modèles vidéo Wan
|
||||
- `xiaomi` : catalogues gérés par le plugin plus logique d'authentification/cliché d'usage
|
||||
- `xiaomi` : catalogues appartenant au plugin plus logique auth/snapshot d'utilisation
|
||||
|
||||
Le plugin groupé `openai` possède désormais les deux identifiants de fournisseur : `openai` et
|
||||
Le plugin `openai` intégré possède désormais les deux identifiants de fournisseur : `openai` et
|
||||
`openai-codex`.
|
||||
|
||||
Cela couvre les fournisseurs qui s'intègrent encore aux transports normaux d'OpenClaw. Un fournisseur
|
||||
qui a besoin d'un exécuteur de requête totalement personnalisé relève d'une surface
|
||||
d'extension distincte et plus avancée.
|
||||
Cela couvre les fournisseurs qui s'intègrent encore dans les transports normaux d'OpenClaw. Un fournisseur
|
||||
qui a besoin d'un exécuteur de requêtes entièrement personnalisé relève d'une surface d'extension distincte et plus profonde.
|
||||
|
||||
## Rotation des clés API
|
||||
|
||||
- Prend en charge la rotation générique de fournisseur pour certains fournisseurs sélectionnés.
|
||||
- Prend en charge la rotation générique des fournisseurs pour certains fournisseurs sélectionnés.
|
||||
- Configurez plusieurs clés via :
|
||||
- `OPENCLAW_LIVE_<PROVIDER>_KEY` (remplacement live unique, priorité la plus élevée)
|
||||
- `<PROVIDER>_API_KEYS` (liste séparée par virgules ou points-virgules)
|
||||
- `<PROVIDER>_API_KEYS` (liste séparée par des virgules ou des points-virgules)
|
||||
- `<PROVIDER>_API_KEY` (clé principale)
|
||||
- `<PROVIDER>_API_KEY_*` (liste numérotée, par exemple `<PROVIDER>_API_KEY_1`)
|
||||
- Pour les fournisseurs Google, `GOOGLE_API_KEY` est aussi inclus comme solution de secours.
|
||||
- `<PROVIDER>_API_KEY_*` (liste numérotée, par ex. `<PROVIDER>_API_KEY_1`)
|
||||
- Pour les fournisseurs Google, `GOOGLE_API_KEY` est aussi inclus comme fallback.
|
||||
- L'ordre de sélection des clés préserve la priorité et déduplique les valeurs.
|
||||
- Les requêtes sont réessayées avec la clé suivante uniquement en cas de réponses de limitation de débit (par
|
||||
- Les requêtes sont réessayées avec la clé suivante uniquement sur les réponses de limitation de débit (par
|
||||
exemple `429`, `rate_limit`, `quota`, `resource exhausted`, `Too many
|
||||
concurrent requests`, `ThrottlingException`, `concurrency limit reached`,
|
||||
`workers_ai ... quota limit exceeded`, ou des messages périodiques de limite d'utilisation).
|
||||
@ -236,8 +236,8 @@ concurrent requests`, `ThrottlingException`, `concurrency limit reached`,
|
||||
|
||||
## Fournisseurs intégrés (catalogue pi-ai)
|
||||
|
||||
OpenClaw est livré avec le catalogue pi‑ai. Ces fournisseurs ne nécessitent **aucune**
|
||||
configuration `models.providers` ; définissez simplement l'authentification et choisissez un modèle.
|
||||
OpenClaw est livré avec le catalogue pi-ai. Ces fournisseurs ne nécessitent **aucune**
|
||||
config `models.providers` ; il suffit de définir l'authentification + choisir un modèle.
|
||||
|
||||
### OpenAI
|
||||
|
||||
@ -247,17 +247,17 @@ configuration `models.providers` ; définissez simplement l'authentification et
|
||||
- Exemples de modèles : `openai/gpt-5.4`, `openai/gpt-5.4-pro`
|
||||
- CLI : `openclaw onboard --auth-choice openai-api-key`
|
||||
- Le transport par défaut est `auto` (WebSocket d'abord, repli SSE)
|
||||
- Remplacez par modèle via `agents.defaults.models["openai/<model>"].params.transport` (`"sse"`, `"websocket"`, ou `"auto"`)
|
||||
- Remplacez par modèle via `agents.defaults.models["openai/<model>"].params.transport` (`"sse"`, `"websocket"` ou `"auto"`)
|
||||
- Le préchauffage WebSocket OpenAI Responses est activé par défaut via `params.openaiWsWarmup` (`true`/`false`)
|
||||
- Le traitement prioritaire OpenAI peut être activé via `agents.defaults.models["openai/<model>"].params.serviceTier`
|
||||
- `/fast` et `params.fastMode` mappent les requêtes Responses directes `openai/*` vers `service_tier=priority` sur `api.openai.com`
|
||||
- Utilisez `params.serviceTier` si vous voulez un niveau explicite au lieu du basculement partagé `/fast`
|
||||
- Les en-têtes d'attribution OpenClaw masqués (`originator`, `version`,
|
||||
- Utilisez `params.serviceTier` lorsque vous voulez un niveau explicite au lieu du basculement partagé `/fast`
|
||||
- Les en-têtes d'attribution OpenClaw cachés (`originator`, `version`,
|
||||
`User-Agent`) s'appliquent uniquement au trafic OpenAI natif vers `api.openai.com`, pas
|
||||
aux proxys génériques compatibles OpenAI
|
||||
- Les routes OpenAI natives conservent aussi `store` de Responses, les indications de cache de prompt, et
|
||||
la mise en forme des charges utiles de compatibilité de raisonnement OpenAI ; les routes proxy non
|
||||
- `openai/gpt-5.3-codex-spark` est volontairement supprimé dans OpenClaw car l'API OpenAI live le rejette ; Spark est traité comme Codex uniquement
|
||||
- Les routes OpenAI natives conservent aussi `store` de Responses, les indices de cache de prompt, et
|
||||
la mise en forme de charge utile de compatibilité de raisonnement OpenAI ; les routes proxy non
|
||||
- `openai/gpt-5.3-codex-spark` est volontairement supprimé dans OpenClaw car l'API OpenAI live le rejette ; Spark est traité comme réservé à Codex
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -272,9 +272,9 @@ configuration `models.providers` ; définissez simplement l'authentification et
|
||||
- Rotation facultative : `ANTHROPIC_API_KEYS`, `ANTHROPIC_API_KEY_1`, `ANTHROPIC_API_KEY_2`, plus `OPENCLAW_LIVE_ANTHROPIC_KEY` (remplacement unique)
|
||||
- Exemple de modèle : `anthropic/claude-opus-4-6`
|
||||
- CLI : `openclaw onboard --auth-choice apiKey`
|
||||
- Les requêtes Anthropic publiques directes prennent en charge le basculement partagé `/fast` et `params.fastMode`, y compris le trafic authentifié par clé API ou OAuth envoyé vers `api.anthropic.com` ; OpenClaw le mappe vers Anthropic `service_tier` (`auto` vs `standard_only`)
|
||||
- Remarque Anthropic : le personnel d'Anthropic nous a indiqué que l'usage de Claude CLI dans le style OpenClaw est de nouveau autorisé, donc OpenClaw considère la réutilisation de Claude CLI et l'usage de `claude -p` comme approuvés pour cette intégration, sauf si Anthropic publie une nouvelle politique.
|
||||
- Le jeton de configuration Anthropic reste disponible comme chemin de jeton pris en charge par OpenClaw, mais OpenClaw préfère désormais la réutilisation de Claude CLI et `claude -p` lorsqu'ils sont disponibles.
|
||||
- Les requêtes Anthropic publiques directes prennent en charge le basculement partagé `/fast` et `params.fastMode`, y compris le trafic authentifié par clé API et OAuth envoyé vers `api.anthropic.com` ; OpenClaw le mappe vers Anthropic `service_tier` (`auto` vs `standard_only`)
|
||||
- Remarque Anthropic : le personnel d'Anthropic nous a indiqué que l'utilisation de Claude CLI façon OpenClaw est de nouveau autorisée, donc OpenClaw traite la réutilisation de Claude CLI et l'usage de `claude -p` comme autorisés pour cette intégration tant qu'Anthropic ne publie pas une nouvelle politique.
|
||||
- Le setup-token Anthropic reste disponible comme chemin de jeton OpenClaw pris en charge, mais OpenClaw préfère désormais la réutilisation de Claude CLI et `claude -p` quand disponible.
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -289,15 +289,15 @@ configuration `models.providers` ; définissez simplement l'authentification et
|
||||
- Exemple de modèle : `openai-codex/gpt-5.4`
|
||||
- CLI : `openclaw onboard --auth-choice openai-codex` ou `openclaw models auth login --provider openai-codex`
|
||||
- Le transport par défaut est `auto` (WebSocket d'abord, repli SSE)
|
||||
- Remplacez par modèle via `agents.defaults.models["openai-codex/<model>"].params.transport` (`"sse"`, `"websocket"`, ou `"auto"`)
|
||||
- `params.serviceTier` est aussi transmis sur les requêtes Responses Codex natives (`chatgpt.com/backend-api`)
|
||||
- Les en-têtes d'attribution OpenClaw masqués (`originator`, `version`,
|
||||
`User-Agent`) sont uniquement attachés au trafic Codex natif vers
|
||||
- Remplacez par modèle via `agents.defaults.models["openai-codex/<model>"].params.transport` (`"sse"`, `"websocket"` ou `"auto"`)
|
||||
- `params.serviceTier` est aussi transféré sur les requêtes natives Codex Responses (`chatgpt.com/backend-api`)
|
||||
- Les en-têtes d'attribution OpenClaw cachés (`originator`, `version`,
|
||||
`User-Agent`) sont attachés uniquement au trafic Codex natif vers
|
||||
`chatgpt.com/backend-api`, pas aux proxys génériques compatibles OpenAI
|
||||
- Partage le même basculement `/fast` et la même configuration `params.fastMode` que `openai/*` direct ; OpenClaw le mappe vers `service_tier=priority`
|
||||
- Partage le même basculement `/fast` et la même config `params.fastMode` que `openai/*` direct ; OpenClaw le mappe vers `service_tier=priority`
|
||||
- `openai-codex/gpt-5.3-codex-spark` reste disponible lorsque le catalogue OAuth Codex l'expose ; dépend des droits
|
||||
- `openai-codex/gpt-5.4` conserve le `contextWindow = 1050000` natif et un `contextTokens = 272000` par défaut au runtime ; remplacez la limite runtime avec `models.providers.openai-codex.models[].contextTokens`
|
||||
- Remarque de politique : OpenAI Codex OAuth est explicitement pris en charge pour les outils/flux externes comme OpenClaw.
|
||||
- `openai-codex/gpt-5.4` conserve `contextWindow = 1050000` natif et une valeur d'exécution par défaut `contextTokens = 272000` ; remplacez la limite d'exécution avec `models.providers.openai-codex.models[].contextTokens`
|
||||
- Remarque de politique : OpenAI Codex OAuth est explicitement pris en charge pour les outils/flux de travail externes comme OpenClaw.
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -319,15 +319,15 @@ configuration `models.providers` ; définissez simplement l'authentification et
|
||||
|
||||
### Autres options hébergées de type abonnement
|
||||
|
||||
- [Qwen Cloud](/fr/providers/qwen) : surface du fournisseur Qwen Cloud plus mappage des endpoints Alibaba DashScope et Coding Plan
|
||||
- [Qwen Cloud](/fr/providers/qwen) : surface de fournisseur Qwen Cloud plus mappage des endpoints Alibaba DashScope et Coding Plan
|
||||
- [MiniMax](/fr/providers/minimax) : accès MiniMax Coding Plan via OAuth ou clé API
|
||||
- [GLM Models](/fr/providers/glm) : endpoints Z.AI Coding Plan ou API générales
|
||||
- [GLM Models](/fr/providers/glm) : endpoints Z.AI Coding Plan ou API générale
|
||||
|
||||
### OpenCode
|
||||
|
||||
- Authentification : `OPENCODE_API_KEY` (ou `OPENCODE_ZEN_API_KEY`)
|
||||
- Fournisseur runtime Zen : `opencode`
|
||||
- Fournisseur runtime Go : `opencode-go`
|
||||
- Fournisseur d'exécution Zen : `opencode`
|
||||
- Fournisseur d'exécution Go : `opencode-go`
|
||||
- Exemples de modèles : `opencode/claude-opus-4-6`, `opencode-go/kimi-k2.5`
|
||||
- CLI : `openclaw onboard --auth-choice opencode-zen` ou `openclaw onboard --auth-choice opencode-go`
|
||||
|
||||
@ -341,40 +341,40 @@ configuration `models.providers` ; définissez simplement l'authentification et
|
||||
|
||||
- Fournisseur : `google`
|
||||
- Authentification : `GEMINI_API_KEY`
|
||||
- Rotation facultative : `GEMINI_API_KEYS`, `GEMINI_API_KEY_1`, `GEMINI_API_KEY_2`, solution de secours `GOOGLE_API_KEY`, et `OPENCLAW_LIVE_GEMINI_KEY` (remplacement unique)
|
||||
- Rotation facultative : `GEMINI_API_KEYS`, `GEMINI_API_KEY_1`, `GEMINI_API_KEY_2`, fallback `GOOGLE_API_KEY`, et `OPENCLAW_LIVE_GEMINI_KEY` (remplacement unique)
|
||||
- Exemples de modèles : `google/gemini-3.1-pro-preview`, `google/gemini-3-flash-preview`
|
||||
- Compatibilité : la configuration OpenClaw héritée utilisant `google/gemini-3.1-flash-preview` est normalisée en `google/gemini-3-flash-preview`
|
||||
- Compatibilité : l'ancienne config OpenClaw utilisant `google/gemini-3.1-flash-preview` est normalisée en `google/gemini-3-flash-preview`
|
||||
- CLI : `openclaw onboard --auth-choice gemini-api-key`
|
||||
- Les exécutions Gemini directes acceptent aussi `agents.defaults.models["google/<model>"].params.cachedContent`
|
||||
(ou l'ancien `cached_content`) pour transmettre un handle natif du fournisseur
|
||||
`cachedContents/...` ; les hits de cache Gemini apparaissent comme `cacheRead` dans OpenClaw
|
||||
(ou l'ancien `cached_content`) pour transférer un handle natif du fournisseur
|
||||
`cachedContents/...` ; les hits de cache Gemini remontent comme `cacheRead` dans OpenClaw
|
||||
|
||||
### Google Vertex et Gemini CLI
|
||||
|
||||
- Fournisseurs : `google-vertex`, `google-gemini-cli`
|
||||
- Authentification : Vertex utilise gcloud ADC ; Gemini CLI utilise son flux OAuth
|
||||
- Attention : Gemini CLI OAuth dans OpenClaw est une intégration non officielle. Certains utilisateurs ont signalé des restrictions de compte Google après l'utilisation de clients tiers. Consultez les conditions de Google et utilisez un compte non critique si vous choisissez de continuer.
|
||||
- Gemini CLI OAuth est livré dans le plugin groupé `google`.
|
||||
- Avertissement : l'OAuth Gemini CLI dans OpenClaw est une intégration non officielle. Certains utilisateurs ont signalé des restrictions de compte Google après l'utilisation de clients tiers. Consultez les conditions de Google et utilisez un compte non critique si vous choisissez de continuer.
|
||||
- L'OAuth Gemini CLI est fourni dans le plugin `google` intégré.
|
||||
- Installez d'abord Gemini CLI :
|
||||
- `brew install gemini-cli`
|
||||
- ou `npm install -g @google/gemini-cli`
|
||||
- Activez : `openclaw plugins enable google`
|
||||
- Activez-le : `openclaw plugins enable google`
|
||||
- Connectez-vous : `openclaw models auth login --provider google-gemini-cli --set-default`
|
||||
- Modèle par défaut : `google-gemini-cli/gemini-3-flash-preview`
|
||||
- Remarque : vous **ne** collez **pas** d'identifiant client ni de secret dans `openclaw.json`. Le flux de connexion CLI stocke
|
||||
les jetons dans des profils d'authentification sur l'hôte de la passerelle.
|
||||
- Remarque : vous ne collez **pas** un identifiant client ou un secret dans `openclaw.json`. Le flux de connexion CLI stocke
|
||||
les jetons dans les profils d'authentification sur l'hôte de la passerelle.
|
||||
- Si les requêtes échouent après la connexion, définissez `GOOGLE_CLOUD_PROJECT` ou `GOOGLE_CLOUD_PROJECT_ID` sur l'hôte de la passerelle.
|
||||
- Les réponses JSON de Gemini CLI sont analysées à partir de `response` ; l'usage se replie sur
|
||||
- Les réponses JSON Gemini CLI sont analysées depuis `response` ; l'utilisation revient à
|
||||
`stats`, avec `stats.cached` normalisé en `cacheRead` OpenClaw.
|
||||
|
||||
### Z.AI (GLM)
|
||||
|
||||
- Fournisseur : `zai`
|
||||
- Authentification : `ZAI_API_KEY`
|
||||
- Exemple de modèle : `zai/glm-5`
|
||||
- Exemple de modèle : `zai/glm-5.1`
|
||||
- CLI : `openclaw onboard --auth-choice zai-api-key`
|
||||
- Alias : `z.ai/*` et `z-ai/*` sont normalisés en `zai/*`
|
||||
- `zai-api-key` détecte automatiquement l'endpoint Z.AI correspondant ; `zai-coding-global`, `zai-coding-cn`, `zai-global`, et `zai-cn` forcent une surface spécifique
|
||||
- `zai-api-key` détecte automatiquement l'endpoint Z.AI correspondant ; `zai-coding-global`, `zai-coding-cn`, `zai-global` et `zai-cn` forcent une surface spécifique
|
||||
|
||||
### Vercel AI Gateway
|
||||
|
||||
@ -390,44 +390,45 @@ configuration `models.providers` ; définissez simplement l'authentification et
|
||||
- Exemple de modèle : `kilocode/kilo/auto`
|
||||
- CLI : `openclaw onboard --auth-choice kilocode-api-key`
|
||||
- URL de base : `https://api.kilo.ai/api/gateway/`
|
||||
- Le catalogue statique de secours est livré avec `kilocode/kilo/auto` ; la découverte live
|
||||
`https://api.kilo.ai/api/gateway/models` peut enrichir davantage le
|
||||
catalogue runtime.
|
||||
- Le routage amont exact derrière `kilocode/kilo/auto` est géré par Kilo Gateway,
|
||||
et non codé en dur dans OpenClaw.
|
||||
- Le catalogue statique de secours inclut `kilocode/kilo/auto` ; la découverte live
|
||||
`https://api.kilo.ai/api/gateway/models` peut étendre davantage le
|
||||
catalogue d'exécution.
|
||||
- Le routage amont exact derrière `kilocode/kilo/auto` appartient à Kilo Gateway,
|
||||
il n'est pas codé en dur dans OpenClaw.
|
||||
|
||||
Voir [/providers/kilocode](/fr/providers/kilocode) pour les détails de configuration.
|
||||
Consultez [/providers/kilocode](/fr/providers/kilocode) pour les détails de configuration.
|
||||
|
||||
### Autres plugins de fournisseur groupés
|
||||
### Autres plugins de fournisseur intégrés
|
||||
|
||||
- OpenRouter : `openrouter` (`OPENROUTER_API_KEY`)
|
||||
- Exemple de modèle : `openrouter/auto`
|
||||
- OpenClaw applique les en-têtes documentés d'attribution d'application d'OpenRouter uniquement lorsque
|
||||
- OpenClaw applique les en-têtes d'attribution d'application documentés par OpenRouter uniquement lorsque
|
||||
la requête cible réellement `openrouter.ai`
|
||||
- Les marqueurs Anthropic `cache_control` spécifiques à OpenRouter sont de même limités aux
|
||||
routes OpenRouter vérifiées, et non à des URL proxy arbitraires
|
||||
- OpenRouter reste sur le chemin compatible OpenAI de type proxy, donc la mise en forme native des requêtes propre à OpenAI (`serviceTier`, `store` de Responses,
|
||||
indications de cache de prompt, charges utiles de compatibilité de raisonnement OpenAI) n'est pas transmise
|
||||
- Les références OpenRouter basées sur Gemini conservent uniquement l'assainissement des signatures de pensée Gemini proxifiées ;
|
||||
la validation de relecture Gemini native et les réécritures bootstrap restent désactivées
|
||||
- Les marqueurs `cache_control` Anthropic spécifiques à OpenRouter sont aussi limités
|
||||
aux routes OpenRouter vérifiées, et non à des URL proxy arbitraires
|
||||
- OpenRouter reste sur le chemin de type proxy compatible OpenAI, donc la mise en forme de requête uniquement native à
|
||||
OpenAI (`serviceTier`, `store` de Responses,
|
||||
indices de cache de prompt, charges utiles de compatibilité de raisonnement OpenAI) n'est pas transférée
|
||||
- Les références OpenRouter adossées à Gemini conservent uniquement l'assainissement des signatures de pensée proxy-Gemini ;
|
||||
la validation native du replay Gemini et les réécritures bootstrap restent désactivées
|
||||
- Kilo Gateway : `kilocode` (`KILOCODE_API_KEY`)
|
||||
- Exemple de modèle : `kilocode/kilo/auto`
|
||||
- Les références Kilo basées sur Gemini conservent le même chemin d'assainissement des signatures de pensée Gemini
|
||||
; `kilocode/kilo/auto` et les autres indications ne prenant pas en charge le raisonnement proxy
|
||||
- Les références Kilo adossées à Gemini conservent le même chemin d'assainissement des signatures de pensée
|
||||
proxy-Gemini ; `kilocode/kilo/auto` et les autres indices sans prise en charge du raisonnement proxy
|
||||
ignorent l'injection de raisonnement proxy
|
||||
- MiniMax : `minimax` (clé API) et `minimax-portal` (OAuth)
|
||||
- Authentification : `MINIMAX_API_KEY` pour `minimax` ; `MINIMAX_OAUTH_TOKEN` ou `MINIMAX_API_KEY` pour `minimax-portal`
|
||||
- Exemple de modèle : `minimax/MiniMax-M2.7` ou `minimax-portal/MiniMax-M2.7`
|
||||
- La configuration d'onboarding/clé API MiniMax écrit des définitions explicites du modèle M2.7 avec
|
||||
`input: ["text", "image"]` ; le catalogue groupé du fournisseur garde les références de chat
|
||||
en mode texte uniquement jusqu'à ce que cette configuration du fournisseur soit matérialisée
|
||||
- La configuration de l'intégration/de la clé API MiniMax écrit des définitions explicites du modèle M2.7 avec
|
||||
`input: ["text", "image"]` ; le catalogue de fournisseur intégré conserve les références de chat
|
||||
en texte seul jusqu'à la matérialisation de cette config fournisseur
|
||||
- Moonshot : `moonshot` (`MOONSHOT_API_KEY`)
|
||||
- Exemple de modèle : `moonshot/kimi-k2.5`
|
||||
- Kimi Coding : `kimi` (`KIMI_API_KEY` ou `KIMICODE_API_KEY`)
|
||||
- Exemple de modèle : `kimi/kimi-code`
|
||||
- Qianfan : `qianfan` (`QIANFAN_API_KEY`)
|
||||
- Exemple de modèle : `qianfan/deepseek-v3.2`
|
||||
- Qwen Cloud : `qwen` (`QWEN_API_KEY`, `MODELSTUDIO_API_KEY`, ou `DASHSCOPE_API_KEY`)
|
||||
- Qwen Cloud : `qwen` (`QWEN_API_KEY`, `MODELSTUDIO_API_KEY` ou `DASHSCOPE_API_KEY`)
|
||||
- Exemple de modèle : `qwen/qwen3.5-plus`
|
||||
- NVIDIA : `nvidia` (`NVIDIA_API_KEY`)
|
||||
- Exemple de modèle : `nvidia/nvidia/llama-3.1-nemotron-70b-instruct`
|
||||
@ -446,9 +447,9 @@ Voir [/providers/kilocode](/fr/providers/kilocode) pour les détails de configur
|
||||
- BytePlus : `byteplus` (`BYTEPLUS_API_KEY`)
|
||||
- Exemple de modèle : `byteplus-plan/ark-code-latest`
|
||||
- xAI : `xai` (`XAI_API_KEY`)
|
||||
- Les requêtes xAI natives groupées utilisent le chemin xAI Responses
|
||||
- Les requêtes xAI natives intégrées utilisent le chemin xAI Responses
|
||||
- `/fast` ou `params.fastMode: true` réécrit `grok-3`, `grok-3-mini`,
|
||||
`grok-4`, et `grok-4-0709` vers leurs variantes `*-fast`
|
||||
`grok-4` et `grok-4-0709` vers leurs variantes `*-fast`
|
||||
- `tool_stream` est activé par défaut ; définissez
|
||||
`agents.defaults.models["xai/<model>"].params.tool_stream` sur `false` pour
|
||||
le désactiver
|
||||
@ -460,21 +461,21 @@ Voir [/providers/kilocode](/fr/providers/kilocode) pour les détails de configur
|
||||
- Les modèles GLM sur Cerebras utilisent les identifiants `zai-glm-4.7` et `zai-glm-4.6`.
|
||||
- URL de base compatible OpenAI : `https://api.cerebras.ai/v1`.
|
||||
- GitHub Copilot : `github-copilot` (`COPILOT_GITHUB_TOKEN` / `GH_TOKEN` / `GITHUB_TOKEN`)
|
||||
- Exemple de modèle Hugging Face Inference : `huggingface/deepseek-ai/DeepSeek-R1` ; CLI : `openclaw onboard --auth-choice huggingface-api-key`. Voir [Hugging Face (Inference)](/fr/providers/huggingface).
|
||||
- Exemple de modèle Hugging Face Inference : `huggingface/deepseek-ai/DeepSeek-R1` ; CLI : `openclaw onboard --auth-choice huggingface-api-key`. Consultez [Hugging Face (Inference)](/fr/providers/huggingface).
|
||||
|
||||
## Fournisseurs via `models.providers` (personnalisé/URL de base)
|
||||
|
||||
Utilisez `models.providers` (ou `models.json`) pour ajouter des fournisseurs **personnalisés** ou des proxys
|
||||
compatibles OpenAI/Anthropic.
|
||||
Utilisez `models.providers` (ou `models.json`) pour ajouter des fournisseurs **personnalisés** ou
|
||||
des proxys compatibles OpenAI/Anthropic.
|
||||
|
||||
Beaucoup des plugins de fournisseur groupés ci-dessous publient déjà un catalogue par défaut.
|
||||
Utilisez des entrées explicites `models.providers.<id>` uniquement lorsque vous souhaitez remplacer l'URL de base,
|
||||
les en-têtes ou la liste des modèles par défaut.
|
||||
Beaucoup des plugins de fournisseur intégrés ci-dessous publient déjà un catalogue par défaut.
|
||||
Utilisez des entrées explicites `models.providers.<id>` uniquement lorsque vous voulez remplacer l'
|
||||
URL de base, les en-têtes ou la liste de modèles par défaut.
|
||||
|
||||
### Moonshot AI (Kimi)
|
||||
|
||||
Moonshot est livré comme plugin de fournisseur groupé. Utilisez le fournisseur intégré par
|
||||
défaut, et ajoutez une entrée explicite `models.providers.moonshot` uniquement lorsque vous
|
||||
Moonshot est fourni comme plugin de fournisseur intégré. Utilisez le fournisseur intégré par
|
||||
défaut et ajoutez une entrée explicite `models.providers.moonshot` uniquement lorsque vous
|
||||
devez remplacer l'URL de base ou les métadonnées du modèle :
|
||||
|
||||
- Fournisseur : `moonshot`
|
||||
@ -482,7 +483,7 @@ devez remplacer l'URL de base ou les métadonnées du modèle :
|
||||
- Exemple de modèle : `moonshot/kimi-k2.5`
|
||||
- CLI : `openclaw onboard --auth-choice moonshot-api-key` ou `openclaw onboard --auth-choice moonshot-api-key-cn`
|
||||
|
||||
Identifiants de modèle Kimi K2 :
|
||||
Identifiants de modèles Kimi K2 :
|
||||
|
||||
[//]: # "moonshot-kimi-k2-model-refs:start"
|
||||
|
||||
@ -533,9 +534,9 @@ L'ancien `kimi/k2p5` reste accepté comme identifiant de modèle de compatibilit
|
||||
|
||||
### Volcano Engine (Doubao)
|
||||
|
||||
Volcano Engine (火山引擎) donne accès à Doubao et à d'autres modèles en Chine.
|
||||
Volcano Engine (火山引擎) fournit un accès à Doubao et à d'autres modèles en Chine.
|
||||
|
||||
- Fournisseur : `volcengine` (codage : `volcengine-plan`)
|
||||
- Fournisseur : `volcengine` (coding : `volcengine-plan`)
|
||||
- Authentification : `VOLCANO_ENGINE_API_KEY`
|
||||
- Exemple de modèle : `volcengine-plan/ark-code-latest`
|
||||
- CLI : `openclaw onboard --auth-choice volcengine-api-key`
|
||||
@ -548,10 +549,10 @@ Volcano Engine (火山引擎) donne accès à Doubao et à d'autres modèles en
|
||||
}
|
||||
```
|
||||
|
||||
L'onboarding utilise par défaut la surface de codage, mais le catalogue général `volcengine/*`
|
||||
L'intégration utilise par défaut la surface coding, mais le catalogue général `volcengine/*`
|
||||
est enregistré en même temps.
|
||||
|
||||
Dans les sélecteurs de modèle d'onboarding/configuration, le choix d'authentification Volcengine préfère à la fois les lignes
|
||||
Dans les sélecteurs de modèle d'intégration/configuration, le choix d'authentification Volcengine préfère à la fois les lignes
|
||||
`volcengine/*` et `volcengine-plan/*`. Si ces modèles ne sont pas encore chargés,
|
||||
OpenClaw revient au catalogue non filtré au lieu d'afficher un sélecteur vide
|
||||
limité au fournisseur.
|
||||
@ -564,7 +565,7 @@ Modèles disponibles :
|
||||
- `volcengine/glm-4-7-251222` (GLM 4.7)
|
||||
- `volcengine/deepseek-v3-2-251201` (DeepSeek V3.2 128K)
|
||||
|
||||
Modèles de codage (`volcengine-plan`) :
|
||||
Modèles coding (`volcengine-plan`) :
|
||||
|
||||
- `volcengine-plan/ark-code-latest`
|
||||
- `volcengine-plan/doubao-seed-code`
|
||||
@ -574,9 +575,9 @@ Modèles de codage (`volcengine-plan`) :
|
||||
|
||||
### BytePlus (International)
|
||||
|
||||
BytePlus ARK donne accès aux mêmes modèles que Volcano Engine pour les utilisateurs internationaux.
|
||||
BytePlus ARK fournit un accès aux mêmes modèles que Volcano Engine pour les utilisateurs internationaux.
|
||||
|
||||
- Fournisseur : `byteplus` (codage : `byteplus-plan`)
|
||||
- Fournisseur : `byteplus` (coding : `byteplus-plan`)
|
||||
- Authentification : `BYTEPLUS_API_KEY`
|
||||
- Exemple de modèle : `byteplus-plan/ark-code-latest`
|
||||
- CLI : `openclaw onboard --auth-choice byteplus-api-key`
|
||||
@ -589,10 +590,10 @@ BytePlus ARK donne accès aux mêmes modèles que Volcano Engine pour les utilis
|
||||
}
|
||||
```
|
||||
|
||||
L'onboarding utilise par défaut la surface de codage, mais le catalogue général `byteplus/*`
|
||||
L'intégration utilise par défaut la surface coding, mais le catalogue général `byteplus/*`
|
||||
est enregistré en même temps.
|
||||
|
||||
Dans les sélecteurs de modèle d'onboarding/configuration, le choix d'authentification BytePlus préfère à la fois les lignes
|
||||
Dans les sélecteurs de modèle d'intégration/configuration, le choix d'authentification BytePlus préfère à la fois les lignes
|
||||
`byteplus/*` et `byteplus-plan/*`. Si ces modèles ne sont pas encore chargés,
|
||||
OpenClaw revient au catalogue non filtré au lieu d'afficher un sélecteur vide
|
||||
limité au fournisseur.
|
||||
@ -603,7 +604,7 @@ Modèles disponibles :
|
||||
- `byteplus/kimi-k2-5-260127` (Kimi K2.5)
|
||||
- `byteplus/glm-4-7-251222` (GLM 4.7)
|
||||
|
||||
Modèles de codage (`byteplus-plan`) :
|
||||
Modèles coding (`byteplus-plan`) :
|
||||
|
||||
- `byteplus-plan/ark-code-latest`
|
||||
- `byteplus-plan/doubao-seed-code`
|
||||
@ -641,31 +642,31 @@ Synthetic fournit des modèles compatibles Anthropic derrière le fournisseur `s
|
||||
|
||||
### MiniMax
|
||||
|
||||
MiniMax se configure via `models.providers` parce qu'il utilise des endpoints personnalisés :
|
||||
MiniMax est configuré via `models.providers` car il utilise des endpoints personnalisés :
|
||||
|
||||
- MiniMax OAuth (Global) : `--auth-choice minimax-global-oauth`
|
||||
- MiniMax OAuth (global) : `--auth-choice minimax-global-oauth`
|
||||
- MiniMax OAuth (CN) : `--auth-choice minimax-cn-oauth`
|
||||
- MiniMax clé API (Global) : `--auth-choice minimax-global-api`
|
||||
- MiniMax clé API (CN) : `--auth-choice minimax-cn-api`
|
||||
- Clé API MiniMax (global) : `--auth-choice minimax-global-api`
|
||||
- Clé API MiniMax (CN) : `--auth-choice minimax-cn-api`
|
||||
- Authentification : `MINIMAX_API_KEY` pour `minimax` ; `MINIMAX_OAUTH_TOKEN` ou
|
||||
`MINIMAX_API_KEY` pour `minimax-portal`
|
||||
|
||||
Voir [/providers/minimax](/fr/providers/minimax) pour les détails de configuration, les options de modèle et les extraits de configuration.
|
||||
Consultez [/providers/minimax](/fr/providers/minimax) pour les détails de configuration, les options de modèle et les extraits de config.
|
||||
|
||||
Sur le chemin de streaming compatible Anthropic de MiniMax, OpenClaw désactive la réflexion par
|
||||
défaut sauf si vous la définissez explicitement, et `/fast on` réécrit
|
||||
`MiniMax-M2.7` en `MiniMax-M2.7-highspeed`.
|
||||
|
||||
Répartition des capacités gérée par le plugin :
|
||||
Répartition des capacités possédées par le plugin :
|
||||
|
||||
- Les valeurs par défaut texte/chat restent sur `minimax/MiniMax-M2.7`
|
||||
- La génération d'images est `minimax/image-01` ou `minimax-portal/image-01`
|
||||
- La compréhension d'image est le `MiniMax-VL-01` géré par le plugin sur les deux chemins d'authentification MiniMax
|
||||
- La compréhension d'image est `MiniMax-VL-01`, appartenant au plugin, sur les deux chemins d'authentification MiniMax
|
||||
- La recherche web reste sur l'identifiant de fournisseur `minimax`
|
||||
|
||||
### Ollama
|
||||
|
||||
Ollama est livré comme plugin de fournisseur groupé et utilise l'API native d'Ollama :
|
||||
Ollama est fourni comme plugin de fournisseur intégré et utilise l'API native d'Ollama :
|
||||
|
||||
- Fournisseur : `ollama`
|
||||
- Authentification : aucune requise (serveur local)
|
||||
@ -685,21 +686,21 @@ ollama pull llama3.3
|
||||
}
|
||||
```
|
||||
|
||||
Ollama est détecté localement sur `http://127.0.0.1:11434` lorsque vous activez
|
||||
`OLLAMA_API_KEY`, et le plugin de fournisseur groupé ajoute Ollama directement à
|
||||
`openclaw onboard` et au sélecteur de modèle. Voir [/providers/ollama](/fr/providers/ollama)
|
||||
pour l'onboarding, les modes cloud/local et la configuration personnalisée.
|
||||
Ollama est détecté localement à `http://127.0.0.1:11434` lorsque vous l'activez avec
|
||||
`OLLAMA_API_KEY`, et le plugin de fournisseur intégré ajoute Ollama directement à
|
||||
`openclaw onboard` et au sélecteur de modèle. Consultez [/providers/ollama](/fr/providers/ollama)
|
||||
pour l'intégration, le mode cloud/local et la configuration personnalisée.
|
||||
|
||||
### vLLM
|
||||
|
||||
vLLM est livré comme plugin de fournisseur groupé pour les serveurs locaux/autohébergés
|
||||
compatibles OpenAI :
|
||||
vLLM est fourni comme plugin de fournisseur intégré pour les serveurs
|
||||
compatibles OpenAI locaux/autohébergés :
|
||||
|
||||
- Fournisseur : `vllm`
|
||||
- Authentification : facultative (selon votre serveur)
|
||||
- Authentification : facultative (dépend de votre serveur)
|
||||
- URL de base par défaut : `http://127.0.0.1:8000/v1`
|
||||
|
||||
Pour activer l'auto-détection localement (n'importe quelle valeur fonctionne si votre serveur n'impose pas l'authentification) :
|
||||
Pour activer l'auto-détection en local (n'importe quelle valeur fonctionne si votre serveur n'impose pas d'authentification) :
|
||||
|
||||
```bash
|
||||
export VLLM_API_KEY="vllm-local"
|
||||
@ -715,19 +716,19 @@ Définissez ensuite un modèle (remplacez-le par l'un des identifiants renvoyés
|
||||
}
|
||||
```
|
||||
|
||||
Voir [/providers/vllm](/fr/providers/vllm) pour les détails.
|
||||
Consultez [/providers/vllm](/fr/providers/vllm) pour les détails.
|
||||
|
||||
### SGLang
|
||||
|
||||
SGLang est livré comme plugin de fournisseur groupé pour des serveurs autohébergés
|
||||
compatibles OpenAI rapides :
|
||||
SGLang est fourni comme plugin de fournisseur intégré pour des serveurs
|
||||
compatibles OpenAI autohébergés rapides :
|
||||
|
||||
- Fournisseur : `sglang`
|
||||
- Authentification : facultative (selon votre serveur)
|
||||
- Authentification : facultative (dépend de votre serveur)
|
||||
- URL de base par défaut : `http://127.0.0.1:30000/v1`
|
||||
|
||||
Pour activer l'auto-détection localement (n'importe quelle valeur fonctionne si votre serveur n'impose pas
|
||||
l'authentification) :
|
||||
Pour activer l'auto-détection en local (n'importe quelle valeur fonctionne si votre serveur n'impose pas
|
||||
d'authentification) :
|
||||
|
||||
```bash
|
||||
export SGLANG_API_KEY="sglang-local"
|
||||
@ -743,7 +744,7 @@ Définissez ensuite un modèle (remplacez-le par l'un des identifiants renvoyés
|
||||
}
|
||||
```
|
||||
|
||||
Voir [/providers/sglang](/fr/providers/sglang) pour les détails.
|
||||
Consultez [/providers/sglang](/fr/providers/sglang) pour les détails.
|
||||
|
||||
### Proxys locaux (LM Studio, vLLM, LiteLLM, etc.)
|
||||
|
||||
@ -782,7 +783,7 @@ Exemple (compatible OpenAI) :
|
||||
|
||||
Remarques :
|
||||
|
||||
- Pour les fournisseurs personnalisés, `reasoning`, `input`, `cost`, `contextWindow`, et `maxTokens` sont facultatifs.
|
||||
- Pour les fournisseurs personnalisés, `reasoning`, `input`, `cost`, `contextWindow` et `maxTokens` sont facultatifs.
|
||||
Lorsqu'ils sont omis, OpenClaw utilise par défaut :
|
||||
- `reasoning: false`
|
||||
- `input: ["text"]`
|
||||
@ -790,13 +791,13 @@ Remarques :
|
||||
- `contextWindow: 200000`
|
||||
- `maxTokens: 8192`
|
||||
- Recommandé : définissez des valeurs explicites qui correspondent aux limites de votre proxy/modèle.
|
||||
- Pour `api: "openai-completions"` sur des endpoints non natifs (tout `baseUrl` non vide dont l'hôte n'est pas `api.openai.com`), OpenClaw force `compat.supportsDeveloperRole: false` pour éviter les erreurs 400 du fournisseur pour les rôles `developer` non pris en charge.
|
||||
- Les routes compatibles OpenAI de style proxy ignorent aussi la mise en forme native des requêtes propre à OpenAI :
|
||||
pas de `service_tier`, pas de `store` de Responses, pas d'indications de cache de prompt, pas de
|
||||
mise en forme des charges utiles de compatibilité de raisonnement OpenAI, et pas d'en-têtes
|
||||
d'attribution OpenClaw masqués.
|
||||
- Pour `api: "openai-completions"` sur des endpoints non natifs (tout `baseUrl` non vide dont l'hôte n'est pas `api.openai.com`), OpenClaw force `compat.supportsDeveloperRole: false` pour éviter les erreurs fournisseur 400 sur les rôles `developer` non pris en charge.
|
||||
- Les routes de type proxy compatibles OpenAI ignorent aussi la mise en forme de requête uniquement native à OpenAI :
|
||||
pas de `service_tier`, pas de `store` de Responses, pas d'indices de cache de prompt, pas de
|
||||
mise en forme de charge utile de compatibilité de raisonnement OpenAI, ni d'en-têtes d'attribution OpenClaw
|
||||
cachés.
|
||||
- Si `baseUrl` est vide/omis, OpenClaw conserve le comportement OpenAI par défaut (qui se résout vers `api.openai.com`).
|
||||
- Par sécurité, un `compat.supportsDeveloperRole: true` explicite est quand même remplacé sur les endpoints non natifs `openai-completions`.
|
||||
- Pour des raisons de sécurité, un `compat.supportsDeveloperRole: true` explicite est toujours remplacé sur les endpoints non natifs `openai-completions`.
|
||||
|
||||
## Exemples CLI
|
||||
|
||||
@ -812,5 +813,5 @@ Voir aussi : [/gateway/configuration](/fr/gateway/configuration) pour des exempl
|
||||
|
||||
- [Models](/fr/concepts/models) — configuration des modèles et alias
|
||||
- [Model Failover](/fr/concepts/model-failover) — chaînes de secours et comportement de nouvelle tentative
|
||||
- [Configuration Reference](/fr/gateway/configuration-reference#agent-defaults) — clés de configuration des modèles
|
||||
- [Configuration Reference](/fr/gateway/configuration-reference#agent-defaults) — clés de config du modèle
|
||||
- [Providers](/fr/providers) — guides de configuration par fournisseur
|
||||
|
||||
@ -1,51 +1,49 @@
|
||||
---
|
||||
read_when:
|
||||
- Étendre qa-lab ou qa-channel
|
||||
- Ajouter des scénarios QA adossés au dépôt
|
||||
- Créer une automatisation QA plus réaliste autour du tableau de bord Gateway
|
||||
- Extension de qa-lab ou de qa-channel
|
||||
- Ajout de scénarios QA adossés au dépôt
|
||||
- Création d’une automatisation QA plus réaliste autour du tableau de bord Gateway
|
||||
summary: Structure de l’automatisation QA privée pour qa-lab, qa-channel, les scénarios préconfigurés et les rapports de protocole
|
||||
title: Automatisation QA E2E
|
||||
title: Automatisation E2E QA
|
||||
x-i18n:
|
||||
generated_at: "2026-04-08T02:14:00Z"
|
||||
generated_at: "2026-04-08T06:00:48Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 3b4aa5acc8e77303f4045d4f04372494cae21b89d2fdaba856dbb4855ced9d27
|
||||
source_hash: 57da147dc06abf9620290104e01a83b42182db1806514114fd9e8467492cda99
|
||||
source_path: concepts/qa-e2e-automation.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Automatisation QA E2E
|
||||
# Automatisation E2E QA
|
||||
|
||||
La pile QA privée est conçue pour exercer OpenClaw d’une manière plus réaliste,
|
||||
calquée sur les canaux, qu’un simple test unitaire ne le peut.
|
||||
La pile QA privée est conçue pour tester OpenClaw d’une manière plus réaliste,
|
||||
structurée autour des canaux, qu’un simple test unitaire ne peut le faire.
|
||||
|
||||
Éléments actuels :
|
||||
Éléments actuels :
|
||||
|
||||
- `extensions/qa-channel` : canal de messages synthétique avec des surfaces de MP, de canal, de fil,
|
||||
de réaction, de modification et de suppression.
|
||||
- `extensions/qa-lab` : interface de débogage et bus QA pour observer la transcription,
|
||||
injecter des messages entrants et exporter un rapport Markdown.
|
||||
- `qa/` : ressources préconfigurées adossées au dépôt pour la tâche de démarrage et les scénarios QA
|
||||
de référence.
|
||||
- `extensions/qa-channel` : canal de messages synthétiques avec des surfaces pour les DM, les canaux, les fils, les réactions, les modifications et les suppressions.
|
||||
- `extensions/qa-lab` : interface de débogage et bus QA pour observer la transcription, injecter des messages entrants et exporter un rapport Markdown.
|
||||
- `qa/` : ressources préconfigurées adossées au dépôt pour la tâche de démarrage et les scénarios QA de référence.
|
||||
|
||||
Le flux opérateur QA actuel repose sur un site QA à deux panneaux :
|
||||
Le flux opérateur QA actuel repose sur un site QA à deux volets :
|
||||
|
||||
- Gauche : tableau de bord Gateway (Control UI) avec l’agent.
|
||||
- Droite : QA Lab, affichant la transcription de type Slack et le plan de scénario.
|
||||
- Gauche : tableau de bord Gateway (Control UI) avec l’agent.
|
||||
- Droite : QA Lab, affichant la transcription de type Slack et le plan du scénario.
|
||||
|
||||
Lancez-le avec :
|
||||
Exécutez-le avec :
|
||||
|
||||
```bash
|
||||
pnpm qa:lab:up
|
||||
```
|
||||
|
||||
Cela construit le site QA, démarre la voie Gateway adossée à Docker et expose la
|
||||
page QA Lab où un opérateur ou une boucle d’automatisation peut confier à l’agent une mission QA,
|
||||
observer le comportement réel du canal et consigner ce qui a fonctionné, échoué ou
|
||||
est resté bloqué.
|
||||
page QA Lab où un opérateur ou une boucle d’automatisation peut confier à
|
||||
l’agent une mission QA, observer le comportement réel du canal et consigner ce
|
||||
qui a fonctionné, échoué ou est resté bloqué.
|
||||
|
||||
Pour itérer plus rapidement sur l’interface de QA Lab sans reconstruire l’image Docker à chaque fois,
|
||||
démarrez la pile avec un bundle QA Lab monté par liaison :
|
||||
Pour des itérations plus rapides sur l’interface de QA Lab sans reconstruire
|
||||
l’image Docker à chaque fois, démarrez la pile avec un bundle QA Lab monté par
|
||||
liaison :
|
||||
|
||||
```bash
|
||||
pnpm openclaw qa docker-build-image
|
||||
@ -54,42 +52,45 @@ pnpm qa:lab:up:fast
|
||||
pnpm qa:lab:watch
|
||||
```
|
||||
|
||||
`qa:lab:up:fast` maintient les services Docker sur une image préconstruite et monte par liaison
|
||||
`extensions/qa-lab/web/dist` dans le conteneur `qa-lab`. `qa:lab:watch`
|
||||
reconstruit ce bundle à chaque modification, et le navigateur se recharge automatiquement lorsque le hachage
|
||||
des ressources de QA Lab change.
|
||||
`qa:lab:up:fast` conserve les services Docker sur une image préconstruite et
|
||||
monte par liaison `extensions/qa-lab/web/dist` dans le conteneur `qa-lab`.
|
||||
`qa:lab:watch` reconstruit ce bundle à chaque modification, et le navigateur se
|
||||
recharge automatiquement lorsque le hachage des ressources de QA Lab change.
|
||||
|
||||
## Ressources préconfigurées adossées au dépôt
|
||||
|
||||
Les ressources préconfigurées se trouvent dans `qa/` :
|
||||
Les ressources préconfigurées se trouvent dans `qa/` :
|
||||
|
||||
- `qa/scenarios.md`
|
||||
- `qa/scenarios/index.md`
|
||||
- `qa/scenarios/*.md`
|
||||
|
||||
Elles sont volontairement versionnées dans git afin que le plan QA soit visible à la fois pour les humains et pour
|
||||
l’agent. La liste de référence doit rester suffisamment large pour couvrir :
|
||||
Elles sont volontairement versionnées dans git afin que le plan QA soit visible
|
||||
à la fois pour les humains et pour l’agent. La liste de référence doit rester
|
||||
assez large pour couvrir :
|
||||
|
||||
- chat en MP et en canal
|
||||
- chat en DM et en canal
|
||||
- comportement des fils
|
||||
- cycle de vie des actions sur les messages
|
||||
- rappels cron
|
||||
- rappel de mémoire
|
||||
- changement de modèle
|
||||
- transfert vers un sous-agent
|
||||
- transfert à un sous-agent
|
||||
- lecture du dépôt et de la documentation
|
||||
- une petite tâche de build comme Lobster Invaders
|
||||
|
||||
## Rapports
|
||||
|
||||
`qa-lab` exporte un rapport de protocole Markdown à partir de la chronologie observée du bus.
|
||||
Le rapport doit répondre à :
|
||||
`qa-lab` exporte un rapport de protocole Markdown à partir de la chronologie du
|
||||
bus observé.
|
||||
Le rapport doit répondre aux questions suivantes :
|
||||
|
||||
- Ce qui a fonctionné
|
||||
- Ce qui a échoué
|
||||
- Ce qui est resté bloqué
|
||||
- Quels scénarios de suivi méritent d’être ajoutés
|
||||
- Les scénarios de suivi qu’il vaut la peine d’ajouter
|
||||
|
||||
## Documentation associée
|
||||
|
||||
- [Testing](/fr/help/testing)
|
||||
- [QA Channel](/fr/channels/qa-channel)
|
||||
- [Dashboard](/web/dashboard)
|
||||
- [Tests](/fr/help/testing)
|
||||
- [Canal QA](/fr/channels/qa-channel)
|
||||
- [Tableau de bord](/web/dashboard)
|
||||
|
||||
@ -1,31 +1,31 @@
|
||||
---
|
||||
read_when:
|
||||
- Expliquer comment le streaming ou le découpage fonctionne sur les canaux
|
||||
- Modifier le streaming par blocs ou le comportement de découpage des canaux
|
||||
- Déboguer des réponses par blocs dupliquées/précoces ou le streaming de prévisualisation de canal
|
||||
summary: Comportement de streaming + découpage (réponses par blocs, streaming de prévisualisation de canal, mappage des modes)
|
||||
title: Streaming et découpage
|
||||
- Expliquer comment le streaming ou le découpage en morceaux fonctionne sur les canaux
|
||||
- Modifier le streaming par blocs ou le comportement de découpage en morceaux des canaux
|
||||
- Déboguer les réponses par blocs dupliquées/précoces ou le streaming d’aperçu du canal
|
||||
summary: Comportement du streaming + du découpage en morceaux (réponses par blocs, streaming d’aperçu du canal, mappage des modes)
|
||||
title: Streaming et découpage en morceaux
|
||||
x-i18n:
|
||||
generated_at: "2026-04-05T12:41:08Z"
|
||||
generated_at: "2026-04-08T06:01:06Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 44b0d08c7eafcb32030ef7c8d5719c2ea2d34e4bac5fdad8cc8b3f4e9e9fad97
|
||||
source_hash: a8e847bb7da890818cd79dec7777f6ae488e6d6c0468e948e56b6b6c598e0000
|
||||
source_path: concepts/streaming.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Streaming + découpage
|
||||
# Streaming + découpage en morceaux
|
||||
|
||||
OpenClaw possède deux couches de streaming distinctes :
|
||||
|
||||
- **Streaming par blocs (canaux) :** émettre des **blocs** terminés à mesure que l’assistant écrit. Il s’agit de messages de canal normaux (pas de deltas de jetons).
|
||||
- **Streaming de prévisualisation (Telegram/Discord/Slack) :** mettre à jour un **message de prévisualisation** temporaire pendant la génération.
|
||||
- **Streaming par blocs (canaux) :** émet des **blocs** terminés pendant que l’assistant écrit. Ce sont des messages de canal normaux (pas des deltas de jetons).
|
||||
- **Streaming d’aperçu (Telegram/Discord/Slack) :** met à jour un **message d’aperçu** temporaire pendant la génération.
|
||||
|
||||
Il n’existe aujourd’hui **aucun véritable streaming de deltas de jetons** vers les messages de canal. Le streaming de prévisualisation est basé sur les messages (envoi + modifications/ajouts).
|
||||
Il n’existe aujourd’hui **aucun véritable streaming token-delta** vers les messages de canal. Le streaming d’aperçu est basé sur les messages (envoi + modifications/ajouts).
|
||||
|
||||
## Streaming par blocs (messages de canal)
|
||||
|
||||
Le streaming par blocs envoie la sortie de l’assistant en segments grossiers dès qu’elle devient disponible.
|
||||
Le streaming par blocs envoie la sortie de l’assistant en gros morceaux à mesure qu’elle devient disponible.
|
||||
|
||||
```
|
||||
Model output
|
||||
@ -39,130 +39,131 @@ Model output
|
||||
|
||||
Légende :
|
||||
|
||||
- `text_delta/events` : événements de flux du modèle (peuvent être clairsemés pour les modèles non streaming).
|
||||
- `chunker` : `EmbeddedBlockChunker` appliquant les limites min/max + la préférence de coupure.
|
||||
- `text_delta/events` : événements de flux du modèle (peuvent être rares pour les modèles sans streaming).
|
||||
- `chunker` : `EmbeddedBlockChunker` appliquant des limites min/max + la préférence de coupure.
|
||||
- `channel send` : messages sortants réels (réponses par blocs).
|
||||
|
||||
**Contrôles :**
|
||||
|
||||
- `agents.defaults.blockStreamingDefault` : `"on"`/`"off"` (désactivé par défaut).
|
||||
- Remplacements de canal : `*.blockStreaming` (et variantes par compte) pour forcer `"on"`/`"off"` par canal.
|
||||
- Surcharges de canal : `*.blockStreaming` (et variantes par compte) pour forcer `"on"`/`"off"` par canal.
|
||||
- `agents.defaults.blockStreamingBreak` : `"text_end"` ou `"message_end"`.
|
||||
- `agents.defaults.blockStreamingChunk` : `{ minChars, maxChars, breakPreference? }`.
|
||||
- `agents.defaults.blockStreamingCoalesce` : `{ minChars?, maxChars?, idleMs? }` (fusionner les blocs streamés avant envoi).
|
||||
- `agents.defaults.blockStreamingCoalesce` : `{ minChars?, maxChars?, idleMs? }` (fusionne les blocs streamés avant l’envoi).
|
||||
- Limite stricte du canal : `*.textChunkLimit` (par ex. `channels.whatsapp.textChunkLimit`).
|
||||
- Mode de découpage du canal : `*.chunkMode` (`length` par défaut, `newline` découpe sur les lignes vides (limites de paragraphe) avant le découpage par longueur).
|
||||
- Limite souple Discord : `channels.discord.maxLinesPerMessage` (17 par défaut) découpe les réponses hautes pour éviter le rognage de l’interface.
|
||||
- Mode de découpage du canal : `*.chunkMode` (`length` par défaut, `newline` coupe sur les lignes vides (limites de paragraphe) avant le découpage par longueur).
|
||||
- Limite souple Discord : `channels.discord.maxLinesPerMessage` (17 par défaut) découpe les réponses longues pour éviter le rognage dans l’interface.
|
||||
|
||||
**Sémantique des limites :**
|
||||
|
||||
- `text_end` : streamer les blocs dès que le chunker les émet ; vider à chaque `text_end`.
|
||||
- `message_end` : attendre que le message de l’assistant soit terminé, puis vider la sortie mise en tampon.
|
||||
- `text_end` : diffuse les blocs dès que le chunker en émet ; vide le tampon à chaque `text_end`.
|
||||
- `message_end` : attend que le message de l’assistant soit terminé, puis vide la sortie mise en tampon.
|
||||
|
||||
`message_end` utilise toujours le chunker si le texte mis en tampon dépasse `maxChars`, et peut donc émettre plusieurs segments à la fin.
|
||||
`message_end` utilise quand même le chunker si le texte mis en tampon dépasse `maxChars`, donc il peut émettre plusieurs morceaux à la fin.
|
||||
|
||||
## Algorithme de découpage (bornes basse/haute)
|
||||
## Algorithme de découpage en morceaux (limites basse/haute)
|
||||
|
||||
Le découpage par blocs est implémenté par `EmbeddedBlockChunker` :
|
||||
|
||||
- **Borne basse :** ne rien émettre tant que le tampon est < `minChars` (sauf si forcé).
|
||||
- **Borne haute :** préférer les coupures avant `maxChars` ; si forcé, couper à `maxChars`.
|
||||
- **Limite basse :** n’émet rien tant que le tampon n’a pas atteint `minChars` (sauf si forcé).
|
||||
- **Limite haute :** préfère des coupures avant `maxChars` ; si forcé, coupe à `maxChars`.
|
||||
- **Préférence de coupure :** `paragraph` → `newline` → `sentence` → `whitespace` → coupure forcée.
|
||||
- **Blocs de code :** ne jamais couper à l’intérieur de blocs ; si une coupure est forcée à `maxChars`, fermer puis rouvrir le bloc afin de conserver un Markdown valide.
|
||||
- **Blocs de code délimités :** ne jamais couper à l’intérieur ; en cas de coupure forcée à `maxChars`, ferme puis rouvre le bloc pour conserver un Markdown valide.
|
||||
|
||||
`maxChars` est limité par `textChunkLimit` du canal, vous ne pouvez donc pas dépasser les plafonds propres à chaque canal.
|
||||
`maxChars` est plafonné à la valeur `textChunkLimit` du canal, donc vous ne pouvez pas dépasser les limites propres à chaque canal.
|
||||
|
||||
## Coalescence (fusion des blocs streamés)
|
||||
|
||||
Lorsque le streaming par blocs est activé, OpenClaw peut **fusionner des segments de blocs consécutifs**
|
||||
avant de les envoyer. Cela réduit le « spam ligne par ligne » tout en fournissant
|
||||
Quand le streaming par blocs est activé, OpenClaw peut **fusionner des morceaux de blocs consécutifs**
|
||||
avant de les envoyer. Cela réduit le « spam de lignes uniques » tout en fournissant
|
||||
une sortie progressive.
|
||||
|
||||
- La coalescence attend des **périodes d’inactivité** (`idleMs`) avant de vider.
|
||||
- La coalescence attend des **périodes d’inactivité** (`idleMs`) avant de vider le tampon.
|
||||
- Les tampons sont plafonnés par `maxChars` et seront vidés s’ils le dépassent.
|
||||
- `minChars` empêche l’envoi de trop petits fragments tant qu’assez de texte ne s’est pas accumulé
|
||||
(la vidange finale envoie toujours le texte restant).
|
||||
- `minChars` empêche l’envoi de fragments minuscules tant qu’assez de texte ne s’est pas accumulé
|
||||
(le vidage final envoie toujours le texte restant).
|
||||
- Le séparateur est dérivé de `blockStreamingChunk.breakPreference`
|
||||
(`paragraph` → `\n\n`, `newline` → `\n`, `sentence` → espace).
|
||||
- Des remplacements de canal sont disponibles via `*.blockStreamingCoalesce` (y compris dans les configs par compte).
|
||||
- La valeur par défaut de coalescence `minChars` est portée à 1500 pour Signal/Slack/Discord, sauf remplacement.
|
||||
- Des surcharges par canal sont disponibles via `*.blockStreamingCoalesce` (y compris dans les configs par compte).
|
||||
- La valeur par défaut de `minChars` pour la coalescence est portée à 1500 pour Signal/Slack/Discord sauf surcharge.
|
||||
|
||||
## Rythme humain entre les blocs
|
||||
## Rythme plus humain entre les blocs
|
||||
|
||||
Lorsque le streaming par blocs est activé, vous pouvez ajouter une **pause aléatoire** entre
|
||||
les réponses par blocs (après le premier bloc). Cela rend les réponses à plusieurs bulles
|
||||
plus naturelles.
|
||||
Quand le streaming par blocs est activé, vous pouvez ajouter une **pause aléatoire**
|
||||
entre les réponses par blocs (après le premier bloc). Cela donne aux réponses en
|
||||
plusieurs bulles une impression plus naturelle.
|
||||
|
||||
- Configuration : `agents.defaults.humanDelay` (remplacement par agent via `agents.list[].humanDelay`).
|
||||
- Config : `agents.defaults.humanDelay` (surcharge par agent via `agents.list[].humanDelay`).
|
||||
- Modes : `off` (par défaut), `natural` (800–2500ms), `custom` (`minMs`/`maxMs`).
|
||||
- S’applique uniquement aux **réponses par blocs**, pas aux réponses finales ni aux résumés d’outils.
|
||||
|
||||
## "Streamer par segments ou tout d’un coup"
|
||||
## « Stream les morceaux ou tout »
|
||||
|
||||
Cela correspond à :
|
||||
|
||||
- **Streamer par segments :** `blockStreamingDefault: "on"` + `blockStreamingBreak: "text_end"` (émettre au fur et à mesure). Les canaux autres que Telegram nécessitent également `*.blockStreaming: true`.
|
||||
- **Tout streamer à la fin :** `blockStreamingBreak: "message_end"` (vider une seule fois, éventuellement en plusieurs segments si c’est très long).
|
||||
- **Pas de streaming par blocs :** `blockStreamingDefault: "off"` (réponse finale uniquement).
|
||||
- **Stream les morceaux :** `blockStreamingDefault: "on"` + `blockStreamingBreak: "text_end"` (émet au fil de l’eau). Les canaux autres que Telegram ont aussi besoin de `*.blockStreaming: true`.
|
||||
- **Tout streamer à la fin :** `blockStreamingBreak: "message_end"` (vide une fois, éventuellement en plusieurs morceaux si c’est très long).
|
||||
- **Aucun streaming par blocs :** `blockStreamingDefault: "off"` (réponse finale uniquement).
|
||||
|
||||
**Remarque sur les canaux :** le streaming par blocs est **désactivé sauf si**
|
||||
`*.blockStreaming` est explicitement défini sur `true`. Les canaux peuvent streamer une prévisualisation en direct
|
||||
**Remarque sur les canaux :** Le streaming par blocs est **désactivé sauf si**
|
||||
`*.blockStreaming` est explicitement défini sur `true`. Les canaux peuvent diffuser un aperçu en direct
|
||||
(`channels.<channel>.streaming`) sans réponses par blocs.
|
||||
|
||||
Rappel sur l’emplacement de configuration : les valeurs par défaut `blockStreaming*` se trouvent sous
|
||||
`agents.defaults`, pas à la racine de la configuration.
|
||||
Rappel sur l’emplacement de la config : les valeurs par défaut `blockStreaming*` se trouvent sous
|
||||
`agents.defaults`, pas à la racine de la config.
|
||||
|
||||
## Modes de streaming de prévisualisation
|
||||
## Modes de streaming d’aperçu
|
||||
|
||||
Clé canonique : `channels.<channel>.streaming`
|
||||
|
||||
Modes :
|
||||
|
||||
- `off` : désactiver le streaming de prévisualisation.
|
||||
- `partial` : une seule prévisualisation remplacée par le texte le plus récent.
|
||||
- `block` : mises à jour de prévisualisation par étapes segmentées/ajoutées.
|
||||
- `progress` : prévisualisation de progression/statut pendant la génération, réponse finale à la fin.
|
||||
- `off` : désactive le streaming d’aperçu.
|
||||
- `partial` : aperçu unique remplacé par le texte le plus récent.
|
||||
- `block` : mises à jour d’aperçu par étapes découpées/ajoutées.
|
||||
- `progress` : aperçu d’avancement/statut pendant la génération, réponse finale à la fin.
|
||||
|
||||
### Mappage par canal
|
||||
|
||||
| Canal | `off` | `partial` | `block` | `progress` |
|
||||
| -------- | ----- | --------- | ------- | ---------------------- |
|
||||
| Canal | `off` | `partial` | `block` | `progress` |
|
||||
| -------- | ----- | --------- | ------- | ----------------- |
|
||||
| Telegram | ✅ | ✅ | ✅ | correspond à `partial` |
|
||||
| Discord | ✅ | ✅ | ✅ | correspond à `partial` |
|
||||
| Slack | ✅ | ✅ | ✅ | ✅ |
|
||||
| Slack | ✅ | ✅ | ✅ | ✅ |
|
||||
|
||||
Slack uniquement :
|
||||
Spécifique à Slack :
|
||||
|
||||
- `channels.slack.nativeStreaming` active/désactive les appels à l’API de streaming native Slack lorsque `streaming=partial` (par défaut : `true`).
|
||||
- `channels.slack.streaming.nativeTransport` active/désactive les appels à l’API de streaming native de Slack lorsque `channels.slack.streaming.mode="partial"` (par défaut : `true`).
|
||||
- Le streaming natif Slack et l’état des fils d’assistant Slack nécessitent une cible de fil de réponse ; les DM de niveau supérieur n’affichent pas cet aperçu de type fil.
|
||||
|
||||
Migration des clés historiques :
|
||||
Migration des clés héritées :
|
||||
|
||||
- Telegram : `streamMode` + booléen `streaming` sont migrés automatiquement vers l’énumération `streaming`.
|
||||
- Discord : `streamMode` + booléen `streaming` sont migrés automatiquement vers l’énumération `streaming`.
|
||||
- Slack : `streamMode` est migré automatiquement vers l’énumération `streaming` ; le booléen `streaming` est migré automatiquement vers `nativeStreaming`.
|
||||
- Telegram : `streamMode` + booléen `streaming` sont automatiquement migrés vers l’énumération `streaming`.
|
||||
- Discord : `streamMode` + booléen `streaming` sont automatiquement migrés vers l’énumération `streaming`.
|
||||
- Slack : `streamMode` migre automatiquement vers `streaming.mode` ; le booléen `streaming` migre automatiquement vers `streaming.mode` plus `streaming.nativeTransport` ; l’ancien `nativeStreaming` migre automatiquement vers `streaming.nativeTransport`.
|
||||
|
||||
### Comportement à l’exécution
|
||||
|
||||
Telegram :
|
||||
|
||||
- Utilise `sendMessage` + `editMessageText` pour les mises à jour de prévisualisation dans les messages privés et groupes/sujets.
|
||||
- Le streaming de prévisualisation est ignoré lorsque le streaming par blocs Telegram est explicitement activé (pour éviter un double streaming).
|
||||
- `/reasoning stream` peut écrire le raisonnement dans la prévisualisation.
|
||||
- Utilise les mises à jour d’aperçu `sendMessage` + `editMessageText` dans les DM et les groupes/sujets.
|
||||
- Le streaming d’aperçu est ignoré lorsque le streaming par blocs Telegram est explicitement activé (pour éviter un double streaming).
|
||||
- `/reasoning stream` peut écrire le raisonnement dans l’aperçu.
|
||||
|
||||
Discord :
|
||||
|
||||
- Utilise des messages de prévisualisation avec envoi + modification.
|
||||
- Utilise l’envoi + la modification de messages d’aperçu.
|
||||
- Le mode `block` utilise le découpage de brouillon (`draftChunk`).
|
||||
- Le streaming de prévisualisation est ignoré lorsque le streaming par blocs Discord est explicitement activé.
|
||||
- Le streaming d’aperçu est ignoré lorsque le streaming par blocs Discord est explicitement activé.
|
||||
|
||||
Slack :
|
||||
|
||||
- `partial` peut utiliser le streaming natif Slack (`chat.startStream`/`append`/`stop`) lorsqu’il est disponible.
|
||||
- `block` utilise des prévisualisations de brouillon de type ajout.
|
||||
- `progress` utilise un texte de prévisualisation de statut, puis la réponse finale.
|
||||
- `partial` peut utiliser le streaming natif de Slack (`chat.startStream`/`append`/`stop`) lorsqu’il est disponible.
|
||||
- `block` utilise des aperçus de brouillon de style ajout.
|
||||
- `progress` utilise un texte d’aperçu de statut, puis la réponse finale.
|
||||
|
||||
## Lié
|
||||
|
||||
- [Messages](/concepts/messages) — cycle de vie et distribution des messages
|
||||
- [Retry](/concepts/retry) — comportement de nouvelle tentative en cas d’échec de distribution
|
||||
- [Channels](/channels) — prise en charge du streaming par canal
|
||||
- [Messages](/fr/concepts/messages) — cycle de vie et distribution des messages
|
||||
- [Retry](/fr/concepts/retry) — comportement de nouvelle tentative en cas d’échec de distribution
|
||||
- [Channels](/fr/channels) — prise en charge du streaming par canal
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -2,14 +2,14 @@
|
||||
read_when:
|
||||
- Configurer OpenClaw pour la première fois
|
||||
- Rechercher des modèles de configuration courants
|
||||
- Naviguer vers des sections de configuration spécifiques
|
||||
summary: 'Vue d''ensemble de la configuration : tâches courantes, configuration rapide et liens vers la référence complète'
|
||||
- Accéder à des sections de configuration spécifiques
|
||||
summary: 'Vue d’ensemble de la configuration : tâches courantes, configuration rapide et liens vers la référence complète'
|
||||
title: Configuration
|
||||
x-i18n:
|
||||
generated_at: "2026-04-05T12:42:40Z"
|
||||
generated_at: "2026-04-08T06:01:57Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: a39a7de09c5f9540785ec67f37d435a7a86201f0f5f640dae663054f35976712
|
||||
source_hash: 199a1e515bd4003319e71593a2659bb883299a76ff67e273d92583df03c96604
|
||||
source_path: gateway/configuration.md
|
||||
workflow: 15
|
||||
---
|
||||
@ -18,16 +18,16 @@ x-i18n:
|
||||
|
||||
OpenClaw lit une configuration <Tooltip tip="JSON5 prend en charge les commentaires et les virgules finales">**JSON5**</Tooltip> facultative depuis `~/.openclaw/openclaw.json`.
|
||||
|
||||
Si le fichier est absent, OpenClaw utilise des valeurs par défaut sûres. Raisons courantes d'ajouter une configuration :
|
||||
Si le fichier est absent, OpenClaw utilise des valeurs par défaut sûres. Raisons courantes d’ajouter une configuration :
|
||||
|
||||
- Connecter des canaux et contrôler qui peut envoyer des messages au bot
|
||||
- Définir des modèles, outils, sandboxing ou automatisations (cron, hooks)
|
||||
- Ajuster les sessions, médias, réseau ou l'interface utilisateur
|
||||
- Définir les modèles, les outils, l’isolation en sandbox ou l’automatisation (cron, hooks)
|
||||
- Ajuster les sessions, les médias, le réseau ou l’interface utilisateur
|
||||
|
||||
Voir la [référence complète](/gateway/configuration-reference) pour chaque champ disponible.
|
||||
Consultez la [référence complète](/fr/gateway/configuration-reference) pour tous les champs disponibles.
|
||||
|
||||
<Tip>
|
||||
**Nouveau dans la configuration ?** Commencez avec `openclaw onboard` pour une configuration interactive, ou consultez le guide [Exemples de configuration](/gateway/configuration-examples) pour des configurations complètes prêtes à copier-coller.
|
||||
**Vous débutez avec la configuration ?** Commencez par `openclaw onboard` pour une configuration interactive, ou consultez le guide [Exemples de configuration](/fr/gateway/configuration-examples) pour des configurations complètes prêtes à copier-coller.
|
||||
</Tip>
|
||||
|
||||
## Configuration minimale
|
||||
@ -40,16 +40,16 @@ Voir la [référence complète](/gateway/configuration-reference) pour chaque ch
|
||||
}
|
||||
```
|
||||
|
||||
## Modifier la configuration
|
||||
## Modification de la configuration
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Assistant interactif">
|
||||
```bash
|
||||
openclaw onboard # flux d'onboarding complet
|
||||
openclaw onboard # flux d’intégration complet
|
||||
openclaw configure # assistant de configuration
|
||||
```
|
||||
</Tab>
|
||||
<Tab title="CLI (une ligne)">
|
||||
<Tab title="CLI (commandes en une ligne)">
|
||||
```bash
|
||||
openclaw config get agents.defaults.workspace
|
||||
openclaw config set agents.defaults.heartbeat.every "2h"
|
||||
@ -57,32 +57,48 @@ Voir la [référence complète](/gateway/configuration-reference) pour chaque ch
|
||||
```
|
||||
</Tab>
|
||||
<Tab title="Interface utilisateur de contrôle">
|
||||
Ouvrez [http://127.0.0.1:18789](http://127.0.0.1:18789) et utilisez l'onglet **Config**.
|
||||
L'interface utilisateur de contrôle affiche un formulaire à partir du schéma de configuration actif, y compris les métadonnées de documentation des champs `title` / `description` ainsi que les schémas de plugin et de canal lorsqu'ils sont disponibles, avec un éditeur **Raw JSON** comme solution de secours. Pour les interfaces d'exploration détaillée et les autres outils, la gateway expose également `config.schema.lookup` pour récupérer un nœud de schéma limité à un chemin ainsi que les résumés immédiats de ses enfants.
|
||||
Ouvrez [http://127.0.0.1:18789](http://127.0.0.1:18789) et utilisez l’onglet **Config**.
|
||||
L’interface utilisateur de contrôle affiche un formulaire à partir du schéma de configuration actif, y compris les métadonnées de documentation des champs
|
||||
`title` / `description` ainsi que les schémas des plugins et des canaux lorsque
|
||||
disponibles, avec un éditeur **Raw JSON** comme solution de secours. Pour les interfaces
|
||||
détaillées et d’autres outils, la passerelle expose également `config.schema.lookup` pour
|
||||
récupérer un nœud de schéma limité à un chemin ainsi que les résumés immédiats de ses enfants.
|
||||
</Tab>
|
||||
<Tab title="Modification directe">
|
||||
Modifiez directement `~/.openclaw/openclaw.json`. La gateway surveille le fichier et applique les changements automatiquement (voir [rechargement à chaud](#config-hot-reload)).
|
||||
Modifiez directement `~/.openclaw/openclaw.json`. La Gateway surveille le fichier et applique les modifications automatiquement (voir [rechargement à chaud](#config-hot-reload)).
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Validation stricte
|
||||
|
||||
<Warning>
|
||||
OpenClaw n'accepte que les configurations qui correspondent entièrement au schéma. Les clés inconnues, types mal formés ou valeurs invalides font que la gateway **refuse de démarrer**. La seule exception au niveau racine est `$schema` (chaîne), afin que les éditeurs puissent attacher des métadonnées JSON Schema.
|
||||
OpenClaw n’accepte que les configurations qui correspondent entièrement au schéma. Les clés inconnues, les types mal formés ou les valeurs invalides amènent la Gateway à **refuser de démarrer**. La seule exception au niveau racine est `$schema` (chaîne), afin que les éditeurs puissent attacher des métadonnées JSON Schema.
|
||||
</Warning>
|
||||
|
||||
Remarques sur les outils de schéma :
|
||||
|
||||
- `openclaw config schema` affiche la même famille de JSON Schema utilisée par l'interface utilisateur de contrôle et la validation de configuration.
|
||||
- Les valeurs de champ `title` et `description` sont reportées dans la sortie du schéma pour les outils d'éditeur et de formulaire.
|
||||
- Les entrées d'objet imbriqué, génériques (`*`) et d'élément de tableau (`[]`) héritent des mêmes métadonnées de documentation lorsqu'une documentation de champ correspondante existe.
|
||||
- Les branches de composition `anyOf` / `oneOf` / `allOf` héritent également des mêmes métadonnées de documentation, afin que les variantes d'union/intersection conservent la même aide sur les champs.
|
||||
- `config.schema.lookup` renvoie un chemin de configuration normalisé avec un nœud de schéma superficiel (`title`, `description`, `type`, `enum`, `const`, bornes communes et champs de validation similaires), les métadonnées d'indication d'interface associées, ainsi que les résumés immédiats de ses enfants pour les outils d'exploration détaillée.
|
||||
- Les schémas de plugin/canal runtime sont fusionnés lorsque la gateway peut charger le registre de manifeste actuel.
|
||||
- `openclaw config schema` affiche la même famille de JSON Schema utilisée par l’interface utilisateur de contrôle
|
||||
et la validation de la configuration.
|
||||
- Considérez cette sortie de schéma comme le contrat canonique lisible par machine pour
|
||||
`openclaw.json` ; cette vue d’ensemble et la référence de configuration la résument.
|
||||
- Les valeurs `title` et `description` des champs sont reportées dans la sortie du schéma pour
|
||||
les éditeurs et les outils de formulaires.
|
||||
- Les entrées d’objet imbriqué, génériques (`*`) et d’élément de tableau (`[]`) héritent des mêmes
|
||||
métadonnées de documentation lorsqu’une documentation de champ correspondante existe.
|
||||
- Les branches de composition `anyOf` / `oneOf` / `allOf` héritent également des mêmes
|
||||
métadonnées de documentation, afin que les variantes d’union/intersection conservent la même aide de champ.
|
||||
- `config.schema.lookup` renvoie un chemin de configuration normalisé avec un nœud de
|
||||
schéma superficiel (`title`, `description`, `type`, `enum`, `const`, bornes communes,
|
||||
et champs de validation similaires), les métadonnées d’indication d’interface correspondantes et les résumés immédiats
|
||||
des enfants pour les outils d’exploration détaillée.
|
||||
- Les schémas d’exécution des plugins/canaux sont fusionnés lorsque la gateway peut charger le
|
||||
registre de manifestes actuel.
|
||||
- `pnpm config:docs:check` détecte les écarts entre les artefacts de base de configuration destinés à la documentation
|
||||
et la surface actuelle du schéma.
|
||||
|
||||
Lorsque la validation échoue :
|
||||
|
||||
- La gateway ne démarre pas
|
||||
- La Gateway ne démarre pas
|
||||
- Seules les commandes de diagnostic fonctionnent (`openclaw doctor`, `openclaw logs`, `openclaw health`, `openclaw status`)
|
||||
- Exécutez `openclaw doctor` pour voir les problèmes exacts
|
||||
- Exécutez `openclaw doctor --fix` (ou `--yes`) pour appliquer les réparations
|
||||
@ -91,20 +107,20 @@ Lorsque la validation échoue :
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Configurer un canal (WhatsApp, Telegram, Discord, etc.)">
|
||||
Chaque canal possède sa propre section de configuration sous `channels.<provider>`. Consultez la page du canal concerné pour les étapes de configuration :
|
||||
Chaque canal a sa propre section de configuration sous `channels.<provider>`. Consultez la page dédiée au canal pour les étapes de configuration :
|
||||
|
||||
- [WhatsApp](/channels/whatsapp) — `channels.whatsapp`
|
||||
- [Telegram](/channels/telegram) — `channels.telegram`
|
||||
- [Discord](/channels/discord) — `channels.discord`
|
||||
- [Feishu](/channels/feishu) — `channels.feishu`
|
||||
- [Google Chat](/channels/googlechat) — `channels.googlechat`
|
||||
- [Microsoft Teams](/channels/msteams) — `channels.msteams`
|
||||
- [Slack](/channels/slack) — `channels.slack`
|
||||
- [Signal](/channels/signal) — `channels.signal`
|
||||
- [iMessage](/channels/imessage) — `channels.imessage`
|
||||
- [Mattermost](/channels/mattermost) — `channels.mattermost`
|
||||
- [WhatsApp](/fr/channels/whatsapp) — `channels.whatsapp`
|
||||
- [Telegram](/fr/channels/telegram) — `channels.telegram`
|
||||
- [Discord](/fr/channels/discord) — `channels.discord`
|
||||
- [Feishu](/fr/channels/feishu) — `channels.feishu`
|
||||
- [Google Chat](/fr/channels/googlechat) — `channels.googlechat`
|
||||
- [Microsoft Teams](/fr/channels/msteams) — `channels.msteams`
|
||||
- [Slack](/fr/channels/slack) — `channels.slack`
|
||||
- [Signal](/fr/channels/signal) — `channels.signal`
|
||||
- [iMessage](/fr/channels/imessage) — `channels.imessage`
|
||||
- [Mattermost](/fr/channels/mattermost) — `channels.mattermost`
|
||||
|
||||
Tous les canaux partagent le même modèle de politique DM :
|
||||
Tous les canaux partagent le même modèle de politique de messages directs :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -122,7 +138,7 @@ Lorsque la validation échoue :
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Choisir et configurer des modèles">
|
||||
Définissez le modèle principal et des replis facultatifs :
|
||||
Définissez le modèle principal et les secours facultatifs :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -141,30 +157,30 @@ Lorsque la validation échoue :
|
||||
}
|
||||
```
|
||||
|
||||
- `agents.defaults.models` définit le catalogue de modèles et agit comme liste d'autorisation pour `/model`.
|
||||
- `agents.defaults.models` définit le catalogue de modèles et sert de liste d’autorisation pour `/model`.
|
||||
- Les références de modèle utilisent le format `provider/model` (par exemple `anthropic/claude-opus-4-6`).
|
||||
- `agents.defaults.imageMaxDimensionPx` contrôle le redimensionnement des images dans les transcriptions/outils (valeur par défaut `1200`) ; des valeurs plus faibles réduisent généralement l'utilisation de jetons de vision lors d'exécutions riches en captures d'écran.
|
||||
- Voir [CLI Models](/concepts/models) pour changer de modèle dans le chat et [Bascule de modèle](/concepts/model-failover) pour le comportement de rotation d'authentification et de repli.
|
||||
- Pour les fournisseurs personnalisés/autohébergés, voir [Fournisseurs personnalisés](/gateway/configuration-reference#custom-providers-and-base-urls) dans la référence.
|
||||
- `agents.defaults.imageMaxDimensionPx` contrôle la réduction d’échelle des images de transcription/d’outils (valeur par défaut `1200`) ; des valeurs plus faibles réduisent généralement l’utilisation des jetons de vision lors d’exécutions riches en captures d’écran.
|
||||
- Consultez [Models CLI](/fr/concepts/models) pour changer de modèle dans la discussion et [Model Failover](/fr/concepts/model-failover) pour la rotation de l’authentification et le comportement de repli.
|
||||
- Pour les fournisseurs personnalisés/autohébergés, consultez [Custom providers](/fr/gateway/configuration-reference#custom-providers-and-base-urls) dans la référence.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Contrôler qui peut envoyer des messages au bot">
|
||||
L'accès DM est contrôlé par canal via `dmPolicy` :
|
||||
L’accès aux messages directs est contrôlé par canal via `dmPolicy` :
|
||||
|
||||
- `"pairing"` (par défaut) : les expéditeurs inconnus reçoivent un code de jumelage à usage unique à approuver
|
||||
- `"allowlist"` : seuls les expéditeurs présents dans `allowFrom` (ou le magasin d'autorisations de jumelage)
|
||||
- `"open"` : autoriser tous les DMs entrants (nécessite `allowFrom: ["*"]`)
|
||||
- `"disabled"` : ignorer tous les DMs
|
||||
- `"pairing"` (par défaut) : les expéditeurs inconnus reçoivent un code d’appairage à usage unique à approuver
|
||||
- `"allowlist"` : seuls les expéditeurs présents dans `allowFrom` (ou dans le magasin d’autorisations appairé)
|
||||
- `"open"` : autorise tous les messages directs entrants (nécessite `allowFrom: ["*"]`)
|
||||
- `"disabled"` : ignore tous les messages directs
|
||||
|
||||
Pour les groupes, utilisez `groupPolicy` + `groupAllowFrom` ou les listes d'autorisation spécifiques au canal.
|
||||
Pour les groupes, utilisez `groupPolicy` + `groupAllowFrom` ou des listes d’autorisation spécifiques au canal.
|
||||
|
||||
Voir la [référence complète](/gateway/configuration-reference#dm-and-group-access) pour les détails par canal.
|
||||
Consultez la [référence complète](/fr/gateway/configuration-reference#dm-and-group-access) pour les détails par canal.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Configurer le filtrage par mention dans les discussions de groupe">
|
||||
Les messages de groupe nécessitent par défaut une **mention obligatoire**. Configurez des motifs par agent :
|
||||
<Accordion title="Configurer le filtrage des mentions dans les discussions de groupe">
|
||||
Les messages de groupe exigent par défaut **une mention obligatoire**. Configurez les motifs par agent :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -186,14 +202,15 @@ Lorsque la validation échoue :
|
||||
}
|
||||
```
|
||||
|
||||
- **Mentions de métadonnées** : @mentions natives (WhatsApp tap-to-mention, Telegram @bot, etc.)
|
||||
- **Mentions de métadonnées** : mentions natives avec @ (WhatsApp appuyer pour mentionner, Telegram @bot, etc.)
|
||||
- **Motifs textuels** : motifs regex sûrs dans `mentionPatterns`
|
||||
- Voir la [référence complète](/gateway/configuration-reference#group-chat-mention-gating) pour les remplacements par canal et le mode d'auto-chat.
|
||||
- Consultez la [référence complète](/fr/gateway/configuration-reference#group-chat-mention-gating) pour les remplacements par canal et le mode self-chat.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Restreindre les Skills par agent">
|
||||
Utilisez `agents.defaults.skills` comme base partagée, puis remplacez-la pour des agents spécifiques avec `agents.list[].skills` :
|
||||
Utilisez `agents.defaults.skills` pour une base commune, puis remplacez des
|
||||
agents spécifiques avec `agents.list[].skills` :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -210,15 +227,16 @@ Lorsque la validation échoue :
|
||||
}
|
||||
```
|
||||
|
||||
- Omettez `agents.defaults.skills` pour autoriser tous les Skills par défaut.
|
||||
- Omettez `agents.defaults.skills` pour autoriser les Skills sans restriction par défaut.
|
||||
- Omettez `agents.list[].skills` pour hériter des valeurs par défaut.
|
||||
- Définissez `agents.list[].skills: []` pour n'autoriser aucun Skill.
|
||||
- Voir [Skills](/tools/skills), [Configuration des Skills](/tools/skills-config) et la [Référence de configuration](/gateway/configuration-reference#agentsdefaultsskills).
|
||||
- Définissez `agents.list[].skills: []` pour n’avoir aucun Skills.
|
||||
- Consultez [Skills](/fr/tools/skills), [Configuration de Skills](/fr/tools/skills-config), et
|
||||
la [Référence de configuration](/fr/gateway/configuration-reference#agentsdefaultsskills).
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Ajuster la surveillance de l'état des canaux de la gateway">
|
||||
Contrôlez à quel point la gateway redémarre agressivement les canaux qui semblent inactifs :
|
||||
<Accordion title="Ajuster la surveillance de l’état des canaux de la gateway">
|
||||
Contrôlez l’agressivité avec laquelle la gateway redémarre les canaux qui semblent inactifs :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -240,15 +258,15 @@ Lorsque la validation échoue :
|
||||
}
|
||||
```
|
||||
|
||||
- Définissez `gateway.channelHealthCheckMinutes: 0` pour désactiver globalement les redémarrages du moniteur d'état.
|
||||
- `channelStaleEventThresholdMinutes` doit être supérieur ou égal à l'intervalle de vérification.
|
||||
- Utilisez `channels.<provider>.healthMonitor.enabled` ou `channels.<provider>.accounts.<id>.healthMonitor.enabled` pour désactiver les redémarrages automatiques pour un canal ou un compte sans désactiver le moniteur global.
|
||||
- Voir [Vérifications d'état](/gateway/health) pour le débogage opérationnel et la [référence complète](/gateway/configuration-reference#gateway) pour tous les champs.
|
||||
- Définissez `gateway.channelHealthCheckMinutes: 0` pour désactiver globalement les redémarrages de surveillance de l’état.
|
||||
- `channelStaleEventThresholdMinutes` doit être supérieur ou égal à l’intervalle de vérification.
|
||||
- Utilisez `channels.<provider>.healthMonitor.enabled` ou `channels.<provider>.accounts.<id>.healthMonitor.enabled` pour désactiver les redémarrages automatiques pour un canal ou un compte sans désactiver la surveillance globale.
|
||||
- Consultez [Health Checks](/fr/gateway/health) pour le débogage opérationnel et la [référence complète](/fr/gateway/configuration-reference#gateway) pour tous les champs.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Configurer les sessions et les réinitialisations">
|
||||
Les sessions contrôlent la continuité et l'isolation des conversations :
|
||||
Les sessions contrôlent la continuité et l’isolation des conversations :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -268,15 +286,15 @@ Lorsque la validation échoue :
|
||||
}
|
||||
```
|
||||
|
||||
- `dmScope`: `main` (partagé) | `per-peer` | `per-channel-peer` | `per-account-channel-peer`
|
||||
- `threadBindings`: valeurs par défaut globales pour le routage de sessions liées à un fil (Discord prend en charge `/focus`, `/unfocus`, `/agents`, `/session idle` et `/session max-age`).
|
||||
- Voir [Gestion des sessions](/concepts/session) pour la portée, les liens d'identité et la politique d'envoi.
|
||||
- Voir la [référence complète](/gateway/configuration-reference#session) pour tous les champs.
|
||||
- `dmScope` : `main` (partagé) | `per-peer` | `per-channel-peer` | `per-account-channel-peer`
|
||||
- `threadBindings` : valeurs par défaut globales pour le routage des sessions liées à des fils (Discord prend en charge `/focus`, `/unfocus`, `/agents`, `/session idle`, et `/session max-age`).
|
||||
- Consultez [Session Management](/fr/concepts/session) pour le cadrage, les liens d’identité et la politique d’envoi.
|
||||
- Consultez la [référence complète](/fr/gateway/configuration-reference#session) pour tous les champs.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Activer le sandboxing">
|
||||
Exécutez des sessions d'agent dans des conteneurs Docker isolés :
|
||||
<Accordion title="Activer l’isolation en sandbox">
|
||||
Exécutez les sessions d’agent dans des conteneurs Docker isolés :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -291,16 +309,16 @@ Lorsque la validation échoue :
|
||||
}
|
||||
```
|
||||
|
||||
Construisez d'abord l'image : `scripts/sandbox-setup.sh`
|
||||
Construisez d’abord l’image : `scripts/sandbox-setup.sh`
|
||||
|
||||
Voir [Sandboxing](/gateway/sandboxing) pour le guide complet et la [référence complète](/gateway/configuration-reference#agentsdefaultssandbox) pour toutes les options.
|
||||
Consultez [Sandboxing](/fr/gateway/sandboxing) pour le guide complet et la [référence complète](/fr/gateway/configuration-reference#agentsdefaultssandbox) pour toutes les options.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Activer le push adossé au relais pour les builds iOS officiels">
|
||||
Le push adossé au relais est configuré dans `openclaw.json`.
|
||||
<Accordion title="Activer le push via relais pour les builds iOS officiels">
|
||||
Le push via relais se configure dans `openclaw.json`.
|
||||
|
||||
Définissez ceci dans la configuration gateway :
|
||||
Définissez ceci dans la configuration de la gateway :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -309,7 +327,7 @@ Lorsque la validation échoue :
|
||||
apns: {
|
||||
relay: {
|
||||
baseUrl: "https://relay.example.com",
|
||||
// Facultatif. Valeur par défaut : 10000
|
||||
// Optional. Default: 10000
|
||||
timeoutMs: 10000,
|
||||
},
|
||||
},
|
||||
@ -326,35 +344,35 @@ Lorsque la validation échoue :
|
||||
|
||||
Ce que cela fait :
|
||||
|
||||
- Permet à la gateway d'envoyer `push.test`, des nudges de réveil et des réveils de reconnexion via le relais externe.
|
||||
- Utilise une autorisation d'envoi limitée à l'enregistrement transmise par l'application iOS jumelée. La gateway n'a pas besoin d'un jeton de relais déployé à l'échelle de l'installation.
|
||||
- Lie chaque enregistrement adossé au relais à l'identité gateway avec laquelle l'application iOS a été jumelée, afin qu'une autre gateway ne puisse pas réutiliser l'enregistrement stocké.
|
||||
- Garde les builds iOS locaux/manuels sur APNs direct. Les envois adossés au relais ne s'appliquent qu'aux builds officiels distribués qui se sont enregistrés via le relais.
|
||||
- Doit correspondre à l'URL de base du relais intégrée dans le build iOS officiel/TestFlight afin que le trafic d'enregistrement et d'envoi atteigne le même déploiement de relais.
|
||||
- Permet à la gateway d’envoyer `push.test`, les impulsions de réveil et les réveils de reconnexion via le relais externe.
|
||||
- Utilise une autorisation d’envoi limitée à l’inscription, transmise par l’app iOS appairée. La gateway n’a pas besoin d’un jeton de relais valable pour tout le déploiement.
|
||||
- Lie chaque inscription via relais à l’identité de gateway avec laquelle l’app iOS a été appairée, de sorte qu’une autre gateway ne puisse pas réutiliser l’inscription stockée.
|
||||
- Conserve les builds iOS locaux/manuels en APNs direct. Les envois via relais s’appliquent uniquement aux builds distribués officiellement qui se sont inscrits via le relais.
|
||||
- Doit correspondre à l’URL de base du relais intégrée dans le build iOS officiel/TestFlight, afin que l’inscription et le trafic d’envoi atteignent le même déploiement de relais.
|
||||
|
||||
Flux de bout en bout :
|
||||
|
||||
1. Installez un build iOS officiel/TestFlight compilé avec la même URL de base de relais.
|
||||
2. Configurez `gateway.push.apns.relay.baseUrl` sur la gateway.
|
||||
3. Jumelez l'application iOS à la gateway et laissez les sessions node et operator se connecter.
|
||||
4. L'application iOS récupère l'identité de la gateway, s'enregistre auprès du relais à l'aide d'App Attest et du reçu de l'application, puis publie la charge utile `push.apns.register` adossée au relais à la gateway jumelée.
|
||||
5. La gateway stocke le handle de relais et l'autorisation d'envoi, puis les utilise pour `push.test`, les nudges de réveil et les réveils de reconnexion.
|
||||
3. Appairez l’app iOS à la gateway et laissez les sessions de nœud et d’opérateur se connecter.
|
||||
4. L’app iOS récupère l’identité de la gateway, s’inscrit auprès du relais à l’aide d’App Attest et du reçu de l’app, puis publie la charge utile `push.apns.register` via relais à la gateway appairée.
|
||||
5. La gateway stocke le handle de relais et l’autorisation d’envoi, puis les utilise pour `push.test`, les impulsions de réveil et les réveils de reconnexion.
|
||||
|
||||
Remarques opérationnelles :
|
||||
|
||||
- Si vous basculez l'application iOS vers une autre gateway, reconnectez l'application afin qu'elle puisse publier un nouvel enregistrement de relais lié à cette gateway.
|
||||
- Si vous publiez un nouveau build iOS pointant vers un autre déploiement de relais, l'application actualise son enregistrement de relais mis en cache au lieu de réutiliser l'ancienne origine de relais.
|
||||
- Si vous basculez l’app iOS vers une autre gateway, reconnectez l’app afin qu’elle puisse publier une nouvelle inscription de relais liée à cette gateway.
|
||||
- Si vous publiez un nouveau build iOS pointant vers un déploiement de relais différent, l’app actualise son inscription de relais en cache au lieu de réutiliser l’ancienne origine de relais.
|
||||
|
||||
Remarque de compatibilité :
|
||||
|
||||
- `OPENCLAW_APNS_RELAY_BASE_URL` et `OPENCLAW_APNS_RELAY_TIMEOUT_MS` fonctionnent toujours comme remplacements d'environnement temporaires.
|
||||
- `OPENCLAW_APNS_RELAY_ALLOW_HTTP=true` reste une solution de développement limitée à local loopback ; ne conservez pas d'URL de relais HTTP dans la configuration.
|
||||
- `OPENCLAW_APNS_RELAY_BASE_URL` et `OPENCLAW_APNS_RELAY_TIMEOUT_MS` fonctionnent toujours comme remplacements temporaires via variables d’environnement.
|
||||
- `OPENCLAW_APNS_RELAY_ALLOW_HTTP=true` reste une échappatoire de développement limitée au loopback ; ne conservez pas d’URL de relais HTTP dans la configuration.
|
||||
|
||||
Voir [Application iOS](/platforms/ios#relay-backed-push-for-official-builds) pour le flux de bout en bout et [Flux d'authentification et de confiance](/platforms/ios#authentication-and-trust-flow) pour le modèle de sécurité du relais.
|
||||
Consultez [App iOS](/fr/platforms/ios#relay-backed-push-for-official-builds) pour le flux de bout en bout et [Flux d’authentification et de confiance](/fr/platforms/ios#authentication-and-trust-flow) pour le modèle de sécurité du relais.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Configurer heartbeat (check-ins périodiques)">
|
||||
<Accordion title="Configurer le heartbeat (vérifications périodiques)">
|
||||
```json5
|
||||
{
|
||||
agents: {
|
||||
@ -368,10 +386,10 @@ Lorsque la validation échoue :
|
||||
}
|
||||
```
|
||||
|
||||
- `every`: chaîne de durée (`30m`, `2h`). Définissez `0m` pour désactiver.
|
||||
- `target`: `last` | `none` | `<channel-id>` (par exemple `discord`, `matrix`, `telegram` ou `whatsapp`)
|
||||
- `directPolicy`: `allow` (par défaut) ou `block` pour les cibles de heartbeat de type DM
|
||||
- Voir [Heartbeat](/gateway/heartbeat) pour le guide complet.
|
||||
- `every` : chaîne de durée (`30m`, `2h`). Définissez `0m` pour désactiver.
|
||||
- `target` : `last` | `none` | `<channel-id>` (par exemple `discord`, `matrix`, `telegram`, ou `whatsapp`)
|
||||
- `directPolicy` : `allow` (par défaut) ou `block` pour les cibles de heartbeat de type message direct
|
||||
- Consultez [Heartbeat](/fr/gateway/heartbeat) pour le guide complet.
|
||||
|
||||
</Accordion>
|
||||
|
||||
@ -390,14 +408,14 @@ Lorsque la validation échoue :
|
||||
}
|
||||
```
|
||||
|
||||
- `sessionRetention`: élaguer les sessions d'exécution isolées terminées de `sessions.json` (valeur par défaut `24h` ; définissez `false` pour désactiver).
|
||||
- `runLog`: élaguer `cron/runs/<jobId>.jsonl` selon la taille et le nombre de lignes conservées.
|
||||
- Voir [Tâches cron](/automation/cron-jobs) pour la vue d'ensemble de la fonctionnalité et des exemples CLI.
|
||||
- `sessionRetention` : supprime les sessions d’exécution isolées terminées de `sessions.json` (par défaut `24h` ; définissez `false` pour désactiver).
|
||||
- `runLog` : nettoie `cron/runs/<jobId>.jsonl` selon la taille et le nombre de lignes conservées.
|
||||
- Consultez [Cron jobs](/fr/automation/cron-jobs) pour la vue d’ensemble de la fonctionnalité et des exemples de CLI.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Configurer des webhooks (hooks)">
|
||||
Activez les points de terminaison webhook HTTP sur la gateway :
|
||||
Activez les points de terminaison de webhook HTTP sur la Gateway :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -421,15 +439,15 @@ Lorsque la validation échoue :
|
||||
```
|
||||
|
||||
Remarque de sécurité :
|
||||
- Traitez tout contenu de charge utile hook/webhook comme une entrée non fiable.
|
||||
- Utilisez un `hooks.token` dédié ; ne réutilisez pas le jeton partagé de la gateway.
|
||||
- L'authentification hook se fait uniquement par en-tête (`Authorization: Bearer ...` ou `x-openclaw-token`) ; les jetons dans la query string sont rejetés.
|
||||
- `hooks.path` ne peut pas être `/` ; gardez l'entrée webhook sur un sous-chemin dédié tel que `/hooks`.
|
||||
- Gardez désactivés les drapeaux de contournement de contenu non sûr (`hooks.gmail.allowUnsafeExternalContent`, `hooks.mappings[].allowUnsafeExternalContent`) sauf pour un débogage strictement ciblé.
|
||||
- Si vous activez `hooks.allowRequestSessionKey`, définissez également `hooks.allowedSessionKeyPrefixes` pour limiter les clés de session choisies par l'appelant.
|
||||
- Pour les agents pilotés par hooks, privilégiez des niveaux de modèle modernes robustes et une politique d'outils stricte (par exemple messagerie uniquement, plus sandboxing lorsque possible).
|
||||
- Traitez tout le contenu des charges utiles hook/webhook comme une entrée non fiable.
|
||||
- Utilisez un `hooks.token` dédié ; ne réutilisez pas le jeton partagé de la Gateway.
|
||||
- L’authentification des hooks se fait uniquement par en-tête (`Authorization: Bearer ...` ou `x-openclaw-token`) ; les jetons dans la chaîne de requête sont rejetés.
|
||||
- `hooks.path` ne peut pas être `/` ; conservez l’entrée webhook sur un sous-chemin dédié tel que `/hooks`.
|
||||
- Gardez désactivés les indicateurs de contournement de contenu non sûr (`hooks.gmail.allowUnsafeExternalContent`, `hooks.mappings[].allowUnsafeExternalContent`) sauf pour un débogage strictement ciblé.
|
||||
- Si vous activez `hooks.allowRequestSessionKey`, définissez également `hooks.allowedSessionKeyPrefixes` pour borner les clés de session sélectionnées par l’appelant.
|
||||
- Pour les agents pilotés par hook, privilégiez des niveaux de modèle modernes et robustes ainsi qu’une politique d’outils stricte (par exemple messagerie uniquement plus sandboxing lorsque possible).
|
||||
|
||||
Voir la [référence complète](/gateway/configuration-reference#hooks) pour toutes les options de mapping et l'intégration Gmail.
|
||||
Consultez la [référence complète](/fr/gateway/configuration-reference#hooks) pour toutes les options de mappage et l’intégration Gmail.
|
||||
|
||||
</Accordion>
|
||||
|
||||
@ -451,7 +469,7 @@ Lorsque la validation échoue :
|
||||
}
|
||||
```
|
||||
|
||||
Voir [Multi-Agent](/concepts/multi-agent) et la [référence complète](/gateway/configuration-reference#multi-agent-routing) pour les règles de liaison et les profils d'accès par agent.
|
||||
Consultez [Multi-Agent](/fr/concepts/multi-agent) et la [référence complète](/fr/gateway/configuration-reference#multi-agent-routing) pour les règles de liaison et les profils d’accès par agent.
|
||||
|
||||
</Accordion>
|
||||
|
||||
@ -469,28 +487,28 @@ Lorsque la validation échoue :
|
||||
}
|
||||
```
|
||||
|
||||
- **Fichier unique** : remplace l'objet conteneur
|
||||
- **Tableau de fichiers** : fusion profonde dans l'ordre (les derniers gagnent)
|
||||
- **Clés sœurs** : fusionnées après les inclusions (remplacent les valeurs incluses)
|
||||
- **Inclusions imbriquées** : prises en charge jusqu'à 10 niveaux de profondeur
|
||||
- **Fichier unique** : remplace l’objet conteneur
|
||||
- **Tableau de fichiers** : fusion profonde dans l’ordre (le dernier l’emporte)
|
||||
- **Clés voisines** : fusionnées après les inclusions (remplacent les valeurs incluses)
|
||||
- **Inclusions imbriquées** : prises en charge jusqu’à 10 niveaux de profondeur
|
||||
- **Chemins relatifs** : résolus par rapport au fichier incluant
|
||||
- **Gestion des erreurs** : erreurs claires pour les fichiers manquants, erreurs d'analyse et inclusions circulaires
|
||||
- **Gestion des erreurs** : erreurs claires pour les fichiers manquants, les erreurs d’analyse et les inclusions circulaires
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## Rechargement à chaud de la configuration
|
||||
|
||||
La gateway surveille `~/.openclaw/openclaw.json` et applique les changements automatiquement — aucun redémarrage manuel n'est nécessaire pour la plupart des paramètres.
|
||||
La Gateway surveille `~/.openclaw/openclaw.json` et applique automatiquement les modifications — aucun redémarrage manuel n’est nécessaire pour la plupart des paramètres.
|
||||
|
||||
### Modes de rechargement
|
||||
|
||||
| Mode | Comportement |
|
||||
| ---------------------- | --------------------------------------------------------------------------------------- |
|
||||
| **`hybrid`** (par défaut) | Applique immédiatement à chaud les changements sûrs. Redémarre automatiquement pour les changements critiques. |
|
||||
| **`hot`** | Applique uniquement à chaud les changements sûrs. Consigne un avertissement lorsqu'un redémarrage est nécessaire — à vous de le gérer. |
|
||||
| **`restart`** | Redémarre la gateway à chaque changement de configuration, sûr ou non. |
|
||||
| **`off`** | Désactive la surveillance de fichier. Les changements prennent effet au prochain redémarrage manuel. |
|
||||
| **`hybrid`** (par défaut) | Applique à chaud les modifications sûres instantanément. Redémarre automatiquement pour les modifications critiques. |
|
||||
| **`hot`** | Applique à chaud uniquement les modifications sûres. Journalise un avertissement lorsqu’un redémarrage est nécessaire — à vous de le gérer. |
|
||||
| **`restart`** | Redémarre la Gateway à chaque modification de la configuration, sûre ou non. |
|
||||
| **`off`** | Désactive la surveillance du fichier. Les modifications prennent effet au prochain redémarrage manuel. |
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -500,44 +518,46 @@ La gateway surveille `~/.openclaw/openclaw.json` et applique les changements aut
|
||||
}
|
||||
```
|
||||
|
||||
### Ce qui s'applique à chaud vs ce qui nécessite un redémarrage
|
||||
### Ce qui s’applique à chaud et ce qui nécessite un redémarrage
|
||||
|
||||
La plupart des champs s'appliquent à chaud sans interruption. En mode `hybrid`, les changements nécessitant un redémarrage sont pris en charge automatiquement.
|
||||
La plupart des champs s’appliquent à chaud sans interruption. En mode `hybrid`, les modifications nécessitant un redémarrage sont gérées automatiquement.
|
||||
|
||||
| Catégorie | Champs | Redémarrage nécessaire ? |
|
||||
| ------------------- | -------------------------------------------------------------------- | ------------------------ |
|
||||
| Canaux | `channels.*`, `web` (WhatsApp) — tous les canaux intégrés et d'extension | Non |
|
||||
| Agent et modèles | `agent`, `agents`, `models`, `routing` | Non |
|
||||
| Automatisation | `hooks`, `cron`, `agent.heartbeat` | Non |
|
||||
| Sessions et messages | `session`, `messages` | Non |
|
||||
| Outils et médias | `tools`, `browser`, `skills`, `audio`, `talk` | Non |
|
||||
| UI et divers | `ui`, `logging`, `identity`, `bindings` | Non |
|
||||
| Serveur gateway | `gateway.*` (port, bind, auth, tailscale, TLS, HTTP) | **Oui** |
|
||||
| Infrastructure | `discovery`, `canvasHost`, `plugins` | **Oui** |
|
||||
| ------------------- | -------------------------------------------------------------------- | --------------- |
|
||||
| Canaux | `channels.*`, `web` (WhatsApp) — tous les canaux intégrés et d’extension | Non |
|
||||
| Agent et modèles | `agent`, `agents`, `models`, `routing` | Non |
|
||||
| Automatisation | `hooks`, `cron`, `agent.heartbeat` | Non |
|
||||
| Sessions et messages | `session`, `messages` | Non |
|
||||
| Outils et médias | `tools`, `browser`, `skills`, `audio`, `talk` | Non |
|
||||
| Interface utilisateur et divers | `ui`, `logging`, `identity`, `bindings` | Non |
|
||||
| Serveur Gateway | `gateway.*` (port, bind, auth, tailscale, TLS, HTTP) | **Oui** |
|
||||
| Infrastructure | `discovery`, `canvasHost`, `plugins` | **Oui** |
|
||||
|
||||
<Note>
|
||||
`gateway.reload` et `gateway.remote` sont des exceptions — leur modification **ne** déclenche **pas** de redémarrage.
|
||||
`gateway.reload` et `gateway.remote` sont des exceptions — les modifier **ne** déclenche **pas** de redémarrage.
|
||||
</Note>
|
||||
|
||||
## RPC de configuration (mises à jour programmatiques)
|
||||
|
||||
<Note>
|
||||
Les RPC d'écriture du plan de contrôle (`config.apply`, `config.patch`, `update.run`) sont limités à **3 requêtes par 60 secondes** par `deviceId+clientIp`. Lorsqu'une limite est atteinte, le RPC renvoie `UNAVAILABLE` avec `retryAfterMs`.
|
||||
Les RPC d’écriture du plan de contrôle (`config.apply`, `config.patch`, `update.run`) sont limités à **3 requêtes par 60 secondes** par `deviceId+clientIp`. En cas de limitation, le RPC renvoie `UNAVAILABLE` avec `retryAfterMs`.
|
||||
</Note>
|
||||
|
||||
Flux sûr/par défaut :
|
||||
|
||||
- `config.schema.lookup` : inspecter un sous-arbre de configuration limité à un chemin avec un nœud de schéma superficiel, les métadonnées d'indication associées et les résumés immédiats des enfants
|
||||
- `config.get` : récupérer l'instantané actuel + le hash
|
||||
- `config.patch` : chemin préféré pour les mises à jour partielles
|
||||
- `config.apply` : remplacement de la configuration complète uniquement
|
||||
- `update.run` : auto-mise à jour + redémarrage explicites
|
||||
- `config.schema.lookup` : inspecter un sous-arbre de configuration limité à un chemin avec un nœud de schéma superficiel,
|
||||
les métadonnées d’indication correspondantes et les résumés immédiats des enfants
|
||||
- `config.get` : récupérer l’instantané actuel + le hash
|
||||
- `config.patch` : chemin privilégié pour les mises à jour partielles
|
||||
- `config.apply` : remplacement complet de la configuration uniquement
|
||||
- `update.run` : auto-mise à jour explicite + redémarrage
|
||||
|
||||
Lorsque vous ne remplacez pas la configuration entière, préférez `config.schema.lookup` puis `config.patch`.
|
||||
Lorsque vous ne remplacez pas l’intégralité de la configuration, préférez `config.schema.lookup`
|
||||
puis `config.patch`.
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="config.apply (remplacement complet)">
|
||||
Valide + écrit la configuration complète et redémarre la gateway en une seule étape.
|
||||
Valide + écrit la configuration complète et redémarre la Gateway en une seule étape.
|
||||
|
||||
<Warning>
|
||||
`config.apply` remplace la **configuration entière**. Utilisez `config.patch` pour les mises à jour partielles, ou `openclaw config set` pour des clés uniques.
|
||||
@ -545,13 +565,13 @@ Lorsque vous ne remplacez pas la configuration entière, préférez `config.sche
|
||||
|
||||
Paramètres :
|
||||
|
||||
- `raw` (chaîne) — charge utile JSON5 pour la configuration entière
|
||||
- `raw` (chaîne) — charge utile JSON5 pour l’intégralité de la configuration
|
||||
- `baseHash` (facultatif) — hash de configuration provenant de `config.get` (requis lorsque la configuration existe)
|
||||
- `sessionKey` (facultatif) — clé de session pour le ping de réveil après redémarrage
|
||||
- `note` (facultatif) — note pour le sentinelle de redémarrage
|
||||
- `restartDelayMs` (facultatif) — délai avant redémarrage (par défaut 2000)
|
||||
|
||||
Les demandes de redémarrage sont coalescentes lorsqu'un redémarrage est déjà en attente/en cours, et un cooldown de 30 secondes s'applique entre les cycles de redémarrage.
|
||||
Les demandes de redémarrage sont regroupées lorsqu’un redémarrage est déjà en attente/en cours, et un délai de récupération de 30 secondes s’applique entre les cycles de redémarrage.
|
||||
|
||||
```bash
|
||||
openclaw gateway call config.get --params '{}' # capture payload.hash
|
||||
@ -577,7 +597,7 @@ Lorsque vous ne remplacez pas la configuration entière, préférez `config.sche
|
||||
- `baseHash` (requis) — hash de configuration provenant de `config.get`
|
||||
- `sessionKey`, `note`, `restartDelayMs` — identiques à `config.apply`
|
||||
|
||||
Le comportement de redémarrage correspond à celui de `config.apply` : redémarrages en attente coalescents plus un cooldown de 30 secondes entre les cycles de redémarrage.
|
||||
Le comportement de redémarrage correspond à `config.apply` : regroupement des redémarrages en attente plus un délai de récupération de 30 secondes entre les cycles de redémarrage.
|
||||
|
||||
```bash
|
||||
openclaw gateway call config.patch --params '{
|
||||
@ -589,14 +609,14 @@ Lorsque vous ne remplacez pas la configuration entière, préférez `config.sche
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## Variables d'environnement
|
||||
## Variables d’environnement
|
||||
|
||||
OpenClaw lit les variables d'environnement depuis le processus parent ainsi que :
|
||||
OpenClaw lit les variables d’environnement du processus parent ainsi que :
|
||||
|
||||
- `.env` depuis le répertoire de travail actuel (s'il existe)
|
||||
- `~/.openclaw/.env` (repli global)
|
||||
- `.env` depuis le répertoire de travail actuel (si présent)
|
||||
- `~/.openclaw/.env` (solution de secours globale)
|
||||
|
||||
Aucun des deux fichiers ne remplace les variables d'environnement déjà existantes. Vous pouvez également définir des variables inline dans la configuration :
|
||||
Aucun de ces fichiers ne remplace les variables d’environnement existantes. Vous pouvez également définir des variables d’environnement en ligne dans la configuration :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -607,8 +627,8 @@ Aucun des deux fichiers ne remplace les variables d'environnement déjà existan
|
||||
}
|
||||
```
|
||||
|
||||
<Accordion title="Import de l'environnement shell (facultatif)">
|
||||
S'il est activé et que les clés attendues ne sont pas définies, OpenClaw exécute votre shell de connexion et importe uniquement les clés manquantes :
|
||||
<Accordion title="Import d’environnement du shell (facultatif)">
|
||||
Si cette option est activée et que les clés attendues ne sont pas définies, OpenClaw exécute votre shell de connexion et importe uniquement les clés manquantes :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -618,11 +638,11 @@ Aucun des deux fichiers ne remplace les variables d'environnement déjà existan
|
||||
}
|
||||
```
|
||||
|
||||
Équivalent variable d'environnement : `OPENCLAW_LOAD_SHELL_ENV=1`
|
||||
Équivalent en variable d’environnement : `OPENCLAW_LOAD_SHELL_ENV=1`
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Substitution de variables d'environnement dans les valeurs de configuration">
|
||||
Référencez des variables d'environnement dans n'importe quelle valeur de chaîne de configuration avec `${VAR_NAME}` :
|
||||
<Accordion title="Substitution de variables d’environnement dans les valeurs de configuration">
|
||||
Référencez des variables d’environnement dans toute valeur de chaîne de configuration avec `${VAR_NAME}` :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -633,15 +653,15 @@ Aucun des deux fichiers ne remplace les variables d'environnement déjà existan
|
||||
|
||||
Règles :
|
||||
|
||||
- Seuls les noms en majuscules sont reconnus : `[A-Z_][A-Z0-9_]*`
|
||||
- Seuls les noms en majuscules sont pris en charge : `[A-Z_][A-Z0-9_]*`
|
||||
- Les variables manquantes/vides provoquent une erreur au chargement
|
||||
- Échappez avec `$${VAR}` pour une sortie littérale
|
||||
- Fonctionne dans les fichiers `$include`
|
||||
- Substitution inline : `"${BASE}/v1"` → `"https://api.example.com/v1"`
|
||||
- Substitution en ligne : `"${BASE}/v1"` → `"https://api.example.com/v1"`
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Références de secret (env, file, exec)">
|
||||
<Accordion title="Références de secrets (env, file, exec)">
|
||||
Pour les champs qui prennent en charge les objets SecretRef, vous pouvez utiliser :
|
||||
|
||||
```json5
|
||||
@ -674,16 +694,16 @@ Règles :
|
||||
}
|
||||
```
|
||||
|
||||
Les détails de SecretRef (y compris `secrets.providers` pour `env`/`file`/`exec`) se trouvent dans [Gestion des secrets](/gateway/secrets).
|
||||
Les chemins d'identifiants pris en charge sont listés dans [Surface d'identifiants SecretRef](/reference/secretref-credential-surface).
|
||||
Les détails de SecretRef (y compris `secrets.providers` pour `env`/`file`/`exec`) se trouvent dans [Gestion des secrets](/fr/gateway/secrets).
|
||||
Les chemins d’identifiants pris en charge sont répertoriés dans [Surface des identifiants SecretRef](/fr/reference/secretref-credential-surface).
|
||||
</Accordion>
|
||||
|
||||
Voir [Environnement](/help/environment) pour la priorité complète et les sources.
|
||||
Consultez [Environnement](/fr/help/environment) pour la priorité complète et les sources.
|
||||
|
||||
## Référence complète
|
||||
|
||||
Pour la référence complète champ par champ, voir **[Référence de configuration](/gateway/configuration-reference)**.
|
||||
Pour la référence complète champ par champ, consultez **[Référence de configuration](/fr/gateway/configuration-reference)**.
|
||||
|
||||
---
|
||||
|
||||
_Lié : [Exemples de configuration](/gateway/configuration-examples) · [Référence de configuration](/gateway/configuration-reference) · [Doctor](/gateway/doctor)_
|
||||
_Associé : [Exemples de configuration](/fr/gateway/configuration-examples) · [Référence de configuration](/fr/gateway/configuration-reference) · [Doctor](/fr/gateway/doctor)_
|
||||
|
||||
364
docs/fr/plugins/memory-wiki.md
Normal file
364
docs/fr/plugins/memory-wiki.md
Normal file
@ -0,0 +1,364 @@
|
||||
---
|
||||
read_when:
|
||||
- Vous voulez des connaissances persistantes au-delà de simples notes MEMORY.md
|
||||
- Vous configurez le plugin groupé memory-wiki
|
||||
- Vous voulez comprendre wiki_search, wiki_get ou le mode bridge
|
||||
summary: 'memory-wiki : coffre de connaissances compilé avec provenance, affirmations, tableaux de bord et mode bridge'
|
||||
title: Wiki mémoire
|
||||
x-i18n:
|
||||
generated_at: "2026-04-08T06:01:13Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: b78dd6a4ef4451dae6b53197bf0c7c2a2ba846b08e4a3a93c1026366b1598d82
|
||||
source_path: plugins/memory-wiki.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Wiki mémoire
|
||||
|
||||
`memory-wiki` est un plugin groupé qui transforme la mémoire durable en un
|
||||
coffre de connaissances compilé.
|
||||
|
||||
Il **ne** remplace **pas** le plugin de mémoire actif. Le plugin de mémoire actif
|
||||
reste responsable du rappel, de la promotion, de l’indexation et du dreaming. `memory-wiki`
|
||||
se place à côté de lui et compile les connaissances durables dans un wiki navigable avec des pages déterministes,
|
||||
des affirmations structurées, de la provenance, des tableaux de bord et des condensés lisibles par machine.
|
||||
|
||||
Utilisez-le lorsque vous voulez que la mémoire se comporte davantage comme une couche de connaissances maintenue
|
||||
et moins comme un empilement de fichiers Markdown.
|
||||
|
||||
## Ce qu’il ajoute
|
||||
|
||||
- Un coffre wiki dédié avec une disposition de pages déterministe
|
||||
- Des métadonnées structurées d’affirmations et de preuves, pas seulement du texte
|
||||
- Une provenance, une confiance, des contradictions et des questions ouvertes au niveau des pages
|
||||
- Des condensés compilés pour les consommateurs agent/runtime
|
||||
- Des outils natifs au wiki pour search/get/apply/lint
|
||||
- Un mode bridge facultatif qui importe les artefacts publics du plugin de mémoire actif
|
||||
- Un mode de rendu compatible Obsidian et une intégration CLI facultatifs
|
||||
|
||||
## Comment il s’intègre à la mémoire
|
||||
|
||||
Voyez la séparation ainsi :
|
||||
|
||||
| Couche | Responsable de |
|
||||
| ------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
|
||||
| Plugin de mémoire actif (`memory-core`, QMD, Honcho, etc.) | Rappel, recherche sémantique, promotion, dreaming, runtime de mémoire |
|
||||
| `memory-wiki` | Pages wiki compilées, synthèses riches en provenance, tableaux de bord, search/get/apply spécifiques au wiki |
|
||||
|
||||
Si le plugin de mémoire actif expose des artefacts de rappel partagés, OpenClaw peut rechercher
|
||||
dans les deux couches en un seul passage avec `memory_search corpus=all`.
|
||||
|
||||
Lorsque vous avez besoin d’un classement spécifique au wiki, de provenance ou d’un accès direct aux pages, utilisez plutôt les
|
||||
outils natifs au wiki.
|
||||
|
||||
## Modes de coffre
|
||||
|
||||
`memory-wiki` prend en charge trois modes de coffre :
|
||||
|
||||
### `isolated`
|
||||
|
||||
Propre coffre, propres sources, sans dépendance à `memory-core`.
|
||||
|
||||
Utilisez-le lorsque vous voulez que le wiki soit son propre magasin de connaissances organisé.
|
||||
|
||||
### `bridge`
|
||||
|
||||
Lit les artefacts mémoire publics et les événements de mémoire du plugin de mémoire actif
|
||||
via des points d’intégration publics du plugin SDK.
|
||||
|
||||
Utilisez-le lorsque vous voulez que le wiki compile et organise les
|
||||
artefacts exportés du plugin de mémoire sans accéder aux composants internes privés du plugin.
|
||||
|
||||
Le mode bridge peut indexer :
|
||||
|
||||
- les artefacts mémoire exportés
|
||||
- les rapports de rêve
|
||||
- les notes quotidiennes
|
||||
- les fichiers racine de la mémoire
|
||||
- les journaux d’événements mémoire
|
||||
|
||||
### `unsafe-local`
|
||||
|
||||
Échappatoire explicite sur la même machine pour les chemins privés locaux.
|
||||
|
||||
Ce mode est volontairement expérimental et non portable. Utilisez-le uniquement si vous
|
||||
comprenez la frontière de confiance et avez précisément besoin d’un accès au système de fichiers local que
|
||||
le mode bridge ne peut pas fournir.
|
||||
|
||||
## Structure du coffre
|
||||
|
||||
Le plugin initialise un coffre comme ceci :
|
||||
|
||||
```text
|
||||
<vault>/
|
||||
AGENTS.md
|
||||
WIKI.md
|
||||
index.md
|
||||
inbox.md
|
||||
entities/
|
||||
concepts/
|
||||
syntheses/
|
||||
sources/
|
||||
reports/
|
||||
_attachments/
|
||||
_views/
|
||||
.openclaw-wiki/
|
||||
```
|
||||
|
||||
Le contenu géré reste à l’intérieur de blocs générés. Les blocs de notes humains sont préservés.
|
||||
|
||||
Les principaux groupes de pages sont :
|
||||
|
||||
- `sources/` pour les matériaux bruts importés et les pages adossées au bridge
|
||||
- `entities/` pour les éléments durables, personnes, systèmes, projets et objets
|
||||
- `concepts/` pour les idées, abstractions, modèles et politiques
|
||||
- `syntheses/` pour les résumés compilés et les consolidations maintenues
|
||||
- `reports/` pour les tableaux de bord générés
|
||||
|
||||
## Affirmations structurées et preuves
|
||||
|
||||
Les pages peuvent contenir des `claims` dans le frontmatter structuré, pas seulement du texte libre.
|
||||
|
||||
Chaque affirmation peut inclure :
|
||||
|
||||
- `id`
|
||||
- `text`
|
||||
- `status`
|
||||
- `confidence`
|
||||
- `evidence[]`
|
||||
- `updatedAt`
|
||||
|
||||
Les entrées de preuve peuvent inclure :
|
||||
|
||||
- `sourceId`
|
||||
- `path`
|
||||
- `lines`
|
||||
- `weight`
|
||||
- `note`
|
||||
- `updatedAt`
|
||||
|
||||
C’est ce qui fait que le wiki agit davantage comme une couche de croyances que comme un simple
|
||||
dépôt de notes passif. Les affirmations peuvent être suivies, évaluées, contestées et résolues à partir des sources.
|
||||
|
||||
## Pipeline de compilation
|
||||
|
||||
L’étape de compilation lit les pages du wiki, normalise les résumés et émet des
|
||||
artefacts stables orientés machine sous :
|
||||
|
||||
- `.openclaw-wiki/cache/agent-digest.json`
|
||||
- `.openclaw-wiki/cache/claims.jsonl`
|
||||
|
||||
Ces condensés existent pour que les agents et le code runtime n’aient pas à analyser les
|
||||
pages Markdown.
|
||||
|
||||
La sortie compilée alimente aussi :
|
||||
|
||||
- l’indexation wiki de premier passage pour les flux search/get
|
||||
- la recherche de l’identifiant d’affirmation jusqu’à la page propriétaire
|
||||
- des compléments d’invite compacts
|
||||
- la génération de rapports/tableaux de bord
|
||||
|
||||
## Tableaux de bord et rapports de santé
|
||||
|
||||
Lorsque `render.createDashboards` est activé, la compilation maintient des tableaux de bord sous
|
||||
`reports/`.
|
||||
|
||||
Les rapports intégrés incluent :
|
||||
|
||||
- `reports/open-questions.md`
|
||||
- `reports/contradictions.md`
|
||||
- `reports/low-confidence.md`
|
||||
- `reports/claim-health.md`
|
||||
- `reports/stale-pages.md`
|
||||
|
||||
Ces rapports suivent des éléments comme :
|
||||
|
||||
- les groupes de notes de contradiction
|
||||
- les groupes d’affirmations concurrentes
|
||||
- les affirmations sans preuve structurée
|
||||
- les pages et affirmations à faible confiance
|
||||
- l’ancienneté obsolète ou inconnue
|
||||
- les pages avec des questions non résolues
|
||||
|
||||
## Recherche et récupération
|
||||
|
||||
`memory-wiki` prend en charge deux backends de recherche :
|
||||
|
||||
- `shared` : utiliser le flux de recherche mémoire partagé lorsqu’il est disponible
|
||||
- `local` : rechercher dans le wiki localement
|
||||
|
||||
Il prend également en charge trois corpus :
|
||||
|
||||
- `wiki`
|
||||
- `memory`
|
||||
- `all`
|
||||
|
||||
Comportement important :
|
||||
|
||||
- `wiki_search` et `wiki_get` utilisent les condensés compilés comme premier passage lorsque c’est possible
|
||||
- les identifiants d’affirmation peuvent être résolus jusqu’à la page propriétaire
|
||||
- les affirmations contestées/obsolètes/récentes influencent le classement
|
||||
- les libellés de provenance peuvent être conservés dans les résultats
|
||||
|
||||
Règle pratique :
|
||||
|
||||
- utilisez `memory_search corpus=all` pour un passage large de rappel
|
||||
- utilisez `wiki_search` + `wiki_get` lorsque le classement spécifique au wiki,
|
||||
la provenance ou la structure de croyance au niveau de la page vous importent
|
||||
|
||||
## Outils d’agent
|
||||
|
||||
Le plugin enregistre ces outils :
|
||||
|
||||
- `wiki_status`
|
||||
- `wiki_search`
|
||||
- `wiki_get`
|
||||
- `wiki_apply`
|
||||
- `wiki_lint`
|
||||
|
||||
Ce qu’ils font :
|
||||
|
||||
- `wiki_status` : mode de coffre actuel, santé, disponibilité de la CLI Obsidian
|
||||
- `wiki_search` : rechercher dans les pages wiki et, si configuré, dans les corpus mémoire partagés
|
||||
- `wiki_get` : lire une page wiki par id/chemin ou revenir au corpus mémoire partagé
|
||||
- `wiki_apply` : mutations ciblées de synthèse/métadonnées sans chirurgie libre des pages
|
||||
- `wiki_lint` : vérifications structurelles, lacunes de provenance, contradictions, questions ouvertes
|
||||
|
||||
Le plugin enregistre également un complément de corpus mémoire non exclusif, afin que
|
||||
`memory_search` et `memory_get` partagés puissent atteindre le wiki lorsque le plugin de mémoire actif
|
||||
prend en charge la sélection de corpus.
|
||||
|
||||
## Comportement de l’invite et du contexte
|
||||
|
||||
Lorsque `context.includeCompiledDigestPrompt` est activé, les sections d’invite mémoire
|
||||
ajoutent un instantané compilé compact depuis `agent-digest.json`.
|
||||
|
||||
Cet instantané est volontairement petit et à fort signal :
|
||||
|
||||
- pages principales uniquement
|
||||
- principales affirmations uniquement
|
||||
- nombre de contradictions
|
||||
- nombre de questions
|
||||
- qualificatifs de confiance/ancienneté
|
||||
|
||||
Ceci est opt-in car cela modifie la forme de l’invite et est surtout utile pour les
|
||||
moteurs de contexte ou l’assemblage d’invites hérité qui consomme explicitement des compléments mémoire.
|
||||
|
||||
## Configuration
|
||||
|
||||
Placez la configuration sous `plugins.entries.memory-wiki.config` :
|
||||
|
||||
```json5
|
||||
{
|
||||
plugins: {
|
||||
entries: {
|
||||
"memory-wiki": {
|
||||
enabled: true,
|
||||
config: {
|
||||
vaultMode: "isolated",
|
||||
vault: {
|
||||
path: "~/.openclaw/wiki/main",
|
||||
renderMode: "obsidian",
|
||||
},
|
||||
obsidian: {
|
||||
enabled: true,
|
||||
useOfficialCli: true,
|
||||
vaultName: "OpenClaw Wiki",
|
||||
openAfterWrites: false,
|
||||
},
|
||||
bridge: {
|
||||
enabled: false,
|
||||
readMemoryArtifacts: true,
|
||||
indexDreamReports: true,
|
||||
indexDailyNotes: true,
|
||||
indexMemoryRoot: true,
|
||||
followMemoryEvents: true,
|
||||
},
|
||||
ingest: {
|
||||
autoCompile: true,
|
||||
maxConcurrentJobs: 1,
|
||||
allowUrlIngest: true,
|
||||
},
|
||||
search: {
|
||||
backend: "shared",
|
||||
corpus: "wiki",
|
||||
},
|
||||
context: {
|
||||
includeCompiledDigestPrompt: false,
|
||||
},
|
||||
render: {
|
||||
preserveHumanBlocks: true,
|
||||
createBacklinks: true,
|
||||
createDashboards: true,
|
||||
},
|
||||
},
|
||||
},
|
||||
},
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
Principaux paramètres :
|
||||
|
||||
- `vaultMode` : `isolated`, `bridge`, `unsafe-local`
|
||||
- `vault.renderMode` : `native` ou `obsidian`
|
||||
- `bridge.readMemoryArtifacts` : importer les artefacts publics du plugin de mémoire actif
|
||||
- `bridge.followMemoryEvents` : inclure les journaux d’événements en mode bridge
|
||||
- `search.backend` : `shared` ou `local`
|
||||
- `search.corpus` : `wiki`, `memory` ou `all`
|
||||
- `context.includeCompiledDigestPrompt` : ajouter un instantané compact du condensé aux sections d’invite mémoire
|
||||
- `render.createBacklinks` : générer des blocs liés déterministes
|
||||
- `render.createDashboards` : générer des pages de tableau de bord
|
||||
|
||||
## CLI
|
||||
|
||||
`memory-wiki` expose également une interface CLI de premier niveau :
|
||||
|
||||
```bash
|
||||
openclaw wiki status
|
||||
openclaw wiki doctor
|
||||
openclaw wiki init
|
||||
openclaw wiki ingest ./notes/alpha.md
|
||||
openclaw wiki compile
|
||||
openclaw wiki lint
|
||||
openclaw wiki search "alpha"
|
||||
openclaw wiki get entity.alpha
|
||||
openclaw wiki apply synthesis "Alpha Summary" --body "..." --source-id source.alpha
|
||||
openclaw wiki bridge import
|
||||
openclaw wiki obsidian status
|
||||
```
|
||||
|
||||
Consultez [CLI : wiki](/cli/wiki) pour la référence complète des commandes.
|
||||
|
||||
## Prise en charge d’Obsidian
|
||||
|
||||
Lorsque `vault.renderMode` est `obsidian`, le plugin écrit du
|
||||
Markdown compatible Obsidian et peut éventuellement utiliser la CLI officielle `obsidian`.
|
||||
|
||||
Les flux de travail pris en charge incluent :
|
||||
|
||||
- la vérification d’état
|
||||
- la recherche dans le coffre
|
||||
- l’ouverture d’une page
|
||||
- l’invocation d’une commande Obsidian
|
||||
- l’accès direct à la note quotidienne
|
||||
|
||||
Ceci est facultatif. Le wiki fonctionne toujours en mode natif sans Obsidian.
|
||||
|
||||
## Flux de travail recommandé
|
||||
|
||||
1. Conservez votre plugin de mémoire actif pour le rappel/la promotion/le dreaming.
|
||||
2. Activez `memory-wiki`.
|
||||
3. Commencez par le mode `isolated`, sauf si vous voulez explicitement le mode bridge.
|
||||
4. Utilisez `wiki_search` / `wiki_get` lorsque la provenance compte.
|
||||
5. Utilisez `wiki_apply` pour des synthèses ciblées ou des mises à jour de métadonnées.
|
||||
6. Exécutez `wiki_lint` après des changements significatifs.
|
||||
7. Activez les tableaux de bord si vous voulez une visibilité sur l’obsolescence/les contradictions.
|
||||
|
||||
## Documentation associée
|
||||
|
||||
- [Vue d’ensemble de la mémoire](/fr/concepts/memory)
|
||||
- [CLI : memory](/cli/memory)
|
||||
- [CLI : wiki](/cli/wiki)
|
||||
- [Vue d’ensemble du SDK de plugin](/fr/plugins/sdk-overview)
|
||||
@ -1,14 +1,14 @@
|
||||
---
|
||||
read_when:
|
||||
- Vous souhaitez utiliser des modèles GLM dans OpenClaw
|
||||
- Vous voulez des modèles GLM dans OpenClaw
|
||||
- Vous avez besoin de la convention de nommage des modèles et de la configuration
|
||||
summary: Vue d’ensemble de la famille de modèles GLM + comment l’utiliser dans OpenClaw
|
||||
summary: Aperçu de la famille de modèles GLM + comment l’utiliser dans OpenClaw
|
||||
title: Modèles GLM
|
||||
x-i18n:
|
||||
generated_at: "2026-04-05T12:51:36Z"
|
||||
generated_at: "2026-04-08T06:00:55Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 59622edab5094d991987f9788fbf08b33325e737e7ff88632b0c3ac89412d4c7
|
||||
source_hash: 79a55acfa139847b4b85dbc09f1068cbd2febb1e49f984a23ea9e3b43bc910eb
|
||||
source_path: providers/glm.md
|
||||
workflow: 15
|
||||
---
|
||||
@ -16,12 +16,12 @@ x-i18n:
|
||||
# Modèles GLM
|
||||
|
||||
GLM est une **famille de modèles** (et non une entreprise) disponible via la plateforme Z.AI. Dans OpenClaw, les modèles GLM
|
||||
sont accessibles via le provider `zai` et des ID de modèle comme `zai/glm-5`.
|
||||
sont accessibles via le fournisseur `zai` et des identifiants de modèle comme `zai/glm-5`.
|
||||
|
||||
## Configuration CLI
|
||||
## Configuration de la CLI
|
||||
|
||||
```bash
|
||||
# Configuration générique par clé API avec auto-détection du point de terminaison
|
||||
# Configuration générique de clé API avec détection automatique du point de terminaison
|
||||
openclaw onboard --auth-choice zai-api-key
|
||||
|
||||
# Coding Plan Global, recommandé pour les utilisateurs de Coding Plan
|
||||
@ -42,17 +42,17 @@ openclaw onboard --auth-choice zai-cn
|
||||
```json5
|
||||
{
|
||||
env: { ZAI_API_KEY: "sk-..." },
|
||||
agents: { defaults: { model: { primary: "zai/glm-5" } } },
|
||||
agents: { defaults: { model: { primary: "zai/glm-5.1" } } },
|
||||
}
|
||||
```
|
||||
|
||||
`zai-api-key` permet à OpenClaw de détecter le point de terminaison Z.AI correspondant à partir de la clé et
|
||||
d’appliquer automatiquement la bonne URL de base. Utilisez les choix régionaux explicites lorsque
|
||||
vous souhaitez forcer une surface Coding Plan spécifique ou la surface de l’API générale.
|
||||
d’appliquer automatiquement l’URL de base correcte. Utilisez les choix régionaux explicites lorsque
|
||||
vous souhaitez forcer une surface Coding Plan spécifique ou une surface d’API générale.
|
||||
|
||||
## Modèles GLM intégrés actuels
|
||||
## Modèles GLM actuellement inclus
|
||||
|
||||
OpenClaw initialise actuellement le provider `zai` intégré avec ces références GLM :
|
||||
OpenClaw initialise actuellement le fournisseur `zai` inclus avec ces références GLM :
|
||||
|
||||
- `glm-5.1`
|
||||
- `glm-5`
|
||||
@ -70,6 +70,6 @@ OpenClaw initialise actuellement le provider `zai` intégré avec ces référenc
|
||||
|
||||
## Remarques
|
||||
|
||||
- Les versions GLM et leur disponibilité peuvent changer ; consultez la documentation Z.AI pour les dernières informations.
|
||||
- La référence de modèle intégrée par défaut est `zai/glm-5`.
|
||||
- Pour les détails sur le provider, voir [/providers/zai](/providers/zai).
|
||||
- Les versions et la disponibilité de GLM peuvent changer ; consultez la documentation de Z.AI pour les dernières informations.
|
||||
- La référence de modèle incluse par défaut est `zai/glm-5.1`.
|
||||
- Pour plus de détails sur le fournisseur, voir [/providers/zai](/fr/providers/zai).
|
||||
|
||||
@ -1,40 +1,40 @@
|
||||
---
|
||||
read_when:
|
||||
- Vous voulez utiliser des modèles Z.AI / GLM dans OpenClaw
|
||||
- Vous avez besoin d’une configuration simple avec `ZAI_API_KEY`
|
||||
- Vous voulez des modèles Z.AI / GLM dans OpenClaw
|
||||
- Vous avez besoin d’une configuration simple avec ZAI_API_KEY
|
||||
summary: Utiliser Z.AI (modèles GLM) avec OpenClaw
|
||||
title: Z.AI
|
||||
x-i18n:
|
||||
generated_at: "2026-04-05T12:52:51Z"
|
||||
generated_at: "2026-04-08T06:01:03Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 48006cdd580484f0c62e2877b27a6a68d7bc44795b3e97a28213d95182d9acf9
|
||||
source_hash: 66cbd9813ee28d202dcae34debab1b0cf9927793acb00743c1c62b48d9e381f9
|
||||
source_path: providers/zai.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Z.AI
|
||||
|
||||
Z.AI est la plateforme API des modèles **GLM**. Elle fournit des API REST pour GLM et utilise des clés API
|
||||
Z.AI est la plateforme d’API pour les modèles **GLM**. Elle fournit des API REST pour GLM et utilise des clés API
|
||||
pour l’authentification. Créez votre clé API dans la console Z.AI. OpenClaw utilise le fournisseur `zai`
|
||||
avec une clé API Z.AI.
|
||||
|
||||
## Configuration CLI
|
||||
## Configuration de la CLI
|
||||
|
||||
```bash
|
||||
# Generic API-key setup with endpoint auto-detection
|
||||
# Configuration générique de clé API avec détection automatique du point de terminaison
|
||||
openclaw onboard --auth-choice zai-api-key
|
||||
|
||||
# Coding Plan Global, recommended for Coding Plan users
|
||||
# Coding Plan Global, recommandé pour les utilisateurs de Coding Plan
|
||||
openclaw onboard --auth-choice zai-coding-global
|
||||
|
||||
# Coding Plan CN (China region), recommended for Coding Plan users
|
||||
# Coding Plan CN (région Chine), recommandé pour les utilisateurs de Coding Plan
|
||||
openclaw onboard --auth-choice zai-coding-cn
|
||||
|
||||
# General API
|
||||
# API générale
|
||||
openclaw onboard --auth-choice zai-global
|
||||
|
||||
# General API CN (China region)
|
||||
# API générale CN (région Chine)
|
||||
openclaw onboard --auth-choice zai-cn
|
||||
```
|
||||
|
||||
@ -43,17 +43,17 @@ openclaw onboard --auth-choice zai-cn
|
||||
```json5
|
||||
{
|
||||
env: { ZAI_API_KEY: "sk-..." },
|
||||
agents: { defaults: { model: { primary: "zai/glm-5" } } },
|
||||
agents: { defaults: { model: { primary: "zai/glm-5.1" } } },
|
||||
}
|
||||
```
|
||||
|
||||
`zai-api-key` permet à OpenClaw de détecter le point de terminaison Z.AI correspondant à partir de la clé et
|
||||
d’appliquer automatiquement la bonne base URL. Utilisez les choix régionaux explicites lorsque
|
||||
vous voulez imposer une surface spécifique Coding Plan ou API générale.
|
||||
d’appliquer automatiquement l’URL de base correcte. Utilisez les choix régionaux explicites lorsque
|
||||
vous souhaitez forcer une surface Coding Plan spécifique ou une surface d’API générale.
|
||||
|
||||
## Catalogue GLM intégré
|
||||
## Catalogue GLM inclus
|
||||
|
||||
OpenClaw initialise actuellement le fournisseur intégré `zai` avec :
|
||||
OpenClaw initialise actuellement le fournisseur `zai` inclus avec :
|
||||
|
||||
- `glm-5.1`
|
||||
- `glm-5`
|
||||
@ -72,11 +72,8 @@ OpenClaw initialise actuellement le fournisseur intégré `zai` avec :
|
||||
## Remarques
|
||||
|
||||
- Les modèles GLM sont disponibles sous la forme `zai/<model>` (exemple : `zai/glm-5`).
|
||||
- Référence de modèle intégrée par défaut : `zai/glm-5`
|
||||
- Les IDs inconnus `glm-5*` continuent d’être résolus en avant sur le chemin du fournisseur intégré en
|
||||
synthétisant des métadonnées possédées par le fournisseur à partir du modèle `glm-4.7` lorsque l’id
|
||||
correspond à la forme actuelle de la famille GLM-5.
|
||||
- `tool_stream` est activé par défaut pour le streaming des appels d’outils Z.AI. Définissez
|
||||
`agents.defaults.models["zai/<model>"].params.tool_stream` sur `false` pour le désactiver.
|
||||
- Voir [/providers/glm](/providers/glm) pour la vue d’ensemble de la famille de modèles.
|
||||
- Référence de modèle incluse par défaut : `zai/glm-5.1`
|
||||
- Les identifiants `glm-5*` inconnus sont quand même résolus de manière différée sur le chemin du fournisseur inclus en synthétisant des métadonnées propres au fournisseur à partir du modèle `glm-4.7` lorsque l’identifiant correspond à la forme actuelle de la famille GLM-5.
|
||||
- `tool_stream` est activé par défaut pour le streaming des appels d’outils Z.AI. Définissez `agents.defaults.models["zai/<model>"].params.tool_stream` sur `false` pour le désactiver.
|
||||
- Voir [/providers/glm](/fr/providers/glm) pour un aperçu de la famille de modèles.
|
||||
- Z.AI utilise l’authentification Bearer avec votre clé API.
|
||||
|
||||
@ -1,134 +1,137 @@
|
||||
---
|
||||
x-i18n:
|
||||
generated_at: "2026-04-08T02:18:25Z"
|
||||
generated_at: "2026-04-08T06:01:41Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 0e156cc8e2fe946a0423862f937754a7caa1fe7e6863b50a80bff49a1c86e1e8
|
||||
source_hash: 4a9066b2a939c5a9ba69141d75405f0e8097997b523164340e2f0e9a0d5060dd
|
||||
source_path: refactor/qa.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Refactorisation QA
|
||||
# Refactorisation de la QA
|
||||
|
||||
Statut : la migration fondamentale est finalisée.
|
||||
Statut : migration fondamentale terminée.
|
||||
|
||||
## Objectif
|
||||
|
||||
Faire évoluer la QA d'OpenClaw d'un modèle à définition répartie vers une source de vérité unique :
|
||||
Faire évoluer la QA d’OpenClaw d’un modèle à définition répartie vers une source de vérité unique :
|
||||
|
||||
- métadonnées du scénario
|
||||
- métadonnées des scénarios
|
||||
- prompts envoyés au modèle
|
||||
- configuration et nettoyage
|
||||
- logique du harnais
|
||||
- assertions et critères de réussite
|
||||
- artefacts et indications de rapport
|
||||
- artefacts et indications pour les rapports
|
||||
|
||||
L'état final souhaité est un harnais QA générique qui charge des fichiers de définition de scénario puissants au lieu de coder en dur la majeure partie du comportement en TypeScript.
|
||||
L’état final souhaité est un harnais QA générique qui charge de puissants fichiers de définition de scénario au lieu de coder en dur la majeure partie du comportement en TypeScript.
|
||||
|
||||
## État actuel
|
||||
|
||||
La source de vérité principale se trouve maintenant dans `qa/scenarios.md`.
|
||||
La source principale de vérité se trouve désormais dans `qa/scenarios/index.md` plus un fichier par scénario sous `qa/scenarios/*.md`.
|
||||
|
||||
Implémenté :
|
||||
|
||||
- `qa/scenarios.md`
|
||||
- pack QA canonique
|
||||
- identité de l'opérateur
|
||||
- `qa/scenarios/index.md`
|
||||
- métadonnées canoniques du pack QA
|
||||
- identité de l’opérateur
|
||||
- mission de lancement
|
||||
- `qa/scenarios/*.md`
|
||||
- un fichier Markdown par scénario
|
||||
- métadonnées du scénario
|
||||
- liaisons de gestionnaires
|
||||
- liaisons de handlers
|
||||
- configuration d’exécution spécifique au scénario
|
||||
- `extensions/qa-lab/src/scenario-catalog.ts`
|
||||
- parseur de pack Markdown + validation zod
|
||||
- `extensions/qa-lab/src/qa-agent-bootstrap.ts`
|
||||
- rendu du plan à partir du pack Markdown
|
||||
- `extensions/qa-lab/src/qa-agent-workspace.ts`
|
||||
- initialise les fichiers de compatibilité générés ainsi que `QA_SCENARIOS.md`
|
||||
- génère les fichiers de compatibilité initiaux plus `QA_SCENARIOS.md`
|
||||
- `extensions/qa-lab/src/suite.ts`
|
||||
- sélectionne les scénarios exécutables via des liaisons de gestionnaires définies en Markdown
|
||||
- Protocole de bus QA + UI
|
||||
- pièces jointes inline génériques pour le rendu d'image/vidéo/audio/fichier
|
||||
- sélectionne les scénarios exécutables via des liaisons de handlers définies en Markdown
|
||||
- Protocole QA bus + UI
|
||||
- pièces jointes inline génériques pour le rendu image/vidéo/audio/fichier
|
||||
|
||||
Surfaces encore réparties :
|
||||
|
||||
- `extensions/qa-lab/src/suite.ts`
|
||||
- possède encore la majeure partie de la logique de gestionnaire personnalisé exécutable
|
||||
- possède encore la majeure partie de la logique des handlers exécutables personnalisés
|
||||
- `extensions/qa-lab/src/report.ts`
|
||||
- dérive encore la structure du rapport à partir des sorties runtime
|
||||
- dérive encore la structure du rapport à partir des sorties d’exécution
|
||||
|
||||
Ainsi, la répartition de la source de vérité est corrigée, mais l'exécution reste encore principalement adossée à des gestionnaires plutôt qu'entièrement déclarative.
|
||||
Ainsi, la répartition de la source de vérité est corrigée, mais l’exécution reste encore majoritairement appuyée sur des handlers plutôt que pleinement déclarative.
|
||||
|
||||
## À quoi ressemble la vraie surface des scénarios
|
||||
## À quoi ressemble réellement la surface des scénarios
|
||||
|
||||
La lecture de la suite actuelle montre quelques classes de scénarios distinctes.
|
||||
|
||||
### Interaction simple
|
||||
|
||||
- base de référence du canal
|
||||
- base de référence des messages privés
|
||||
- suivi en fil
|
||||
- référence de base du canal
|
||||
- référence de base en message direct
|
||||
- suivi dans un fil
|
||||
- changement de modèle
|
||||
- poursuite après approbation
|
||||
- suivi après approbation
|
||||
- réaction/modification/suppression
|
||||
|
||||
### Mutation de configuration et de runtime
|
||||
### Mutation de configuration et d’exécution
|
||||
|
||||
- désactivation de skill via patch de configuration
|
||||
- réveil après redémarrage suite à l'application de la configuration
|
||||
- bascule de capacité après redémarrage de configuration
|
||||
- vérification de dérive de l'inventaire runtime
|
||||
- désactivation de skill par patch de config
|
||||
- config apply restart wake-up
|
||||
- inversion de capacité après redémarrage de configuration
|
||||
- vérification de dérive de l’inventaire d’exécution
|
||||
|
||||
### Assertions sur le système de fichiers et le dépôt
|
||||
### Assertions sur système de fichiers et dépôt
|
||||
|
||||
- rapport de découverte source/docs
|
||||
- build de Lobster Invaders
|
||||
- recherche d'artefact d'image générée
|
||||
- build Lobster Invaders
|
||||
- recherche d’artefact d’image générée
|
||||
|
||||
### Orchestration de la mémoire
|
||||
|
||||
- rappel mémoire
|
||||
- outils mémoire dans le contexte du canal
|
||||
- secours en cas d'échec mémoire
|
||||
- rappel de mémoire
|
||||
- outils de mémoire dans un contexte de canal
|
||||
- repli en cas d’échec de la mémoire
|
||||
- classement de la mémoire de session
|
||||
- isolation mémoire de fil
|
||||
- balayage memory dreaming
|
||||
- isolation de la mémoire par fil
|
||||
- memory dreaming sweep
|
||||
|
||||
### Intégration d'outils et de plugins
|
||||
### Intégration d’outils et de plugins
|
||||
|
||||
- appel MCP plugin-tools
|
||||
- visibilité des skills
|
||||
- visibilité des Skills
|
||||
- installation à chaud de skill
|
||||
- génération d'image native
|
||||
- aller-retour d'image
|
||||
- compréhension d'image depuis une pièce jointe
|
||||
- génération d’image native
|
||||
- aller-retour d’image
|
||||
- compréhension d’image à partir d’une pièce jointe
|
||||
|
||||
### Multi-tour et multi-acteur
|
||||
|
||||
- transfert à un sous-agent
|
||||
- synthèse par fanout de sous-agent
|
||||
- flux de type récupération après redémarrage
|
||||
- transfert vers un sous-agent
|
||||
- synthèse par fanout de sous-agents
|
||||
- flux de style reprise après redémarrage
|
||||
|
||||
Ces catégories sont importantes parce qu'elles déterminent les exigences de la DSL. Une simple liste de prompt + texte attendu n'est pas suffisante.
|
||||
Ces catégories sont importantes parce qu’elles pilotent les exigences du DSL. Une simple liste de prompt + texte attendu ne suffit pas.
|
||||
|
||||
## Direction
|
||||
## Orientation
|
||||
|
||||
### Source de vérité unique
|
||||
|
||||
Utiliser `qa/scenarios.md` comme source de vérité rédigée.
|
||||
Utiliser `qa/scenarios/index.md` plus `qa/scenarios/*.md` comme source de vérité rédigée.
|
||||
|
||||
Le pack doit rester :
|
||||
|
||||
- lisible par un humain en revue
|
||||
- analysable par une machine
|
||||
- analysable par machine
|
||||
- suffisamment riche pour piloter :
|
||||
- l'exécution de la suite
|
||||
- l'initialisation du workspace QA
|
||||
- les métadonnées de l'UI QA Lab
|
||||
- l’exécution de la suite
|
||||
- l’initialisation de l’espace de travail QA
|
||||
- les métadonnées de l’UI QA Lab
|
||||
- les prompts de documentation/découverte
|
||||
- la génération de rapports
|
||||
|
||||
### Format de rédaction préféré
|
||||
|
||||
Utiliser Markdown comme format de premier niveau, avec du YAML structuré à l'intérieur.
|
||||
Utiliser Markdown comme format de premier niveau, avec du YAML structuré à l’intérieur.
|
||||
|
||||
Forme recommandée :
|
||||
|
||||
@ -139,7 +142,7 @@ Forme recommandée :
|
||||
- tags
|
||||
- docs refs
|
||||
- code refs
|
||||
- remplacements de modèle/fournisseur
|
||||
- surcharges de modèle/fournisseur
|
||||
- prérequis
|
||||
- sections en prose
|
||||
- objectif
|
||||
@ -153,13 +156,13 @@ Forme recommandée :
|
||||
|
||||
Cela apporte :
|
||||
|
||||
- une meilleure lisibilité en PR qu'un énorme JSON
|
||||
- un contexte plus riche que du pur YAML
|
||||
- une meilleure lisibilité en PR qu’un énorme JSON
|
||||
- un contexte plus riche qu’un simple YAML
|
||||
- une analyse stricte et une validation zod
|
||||
|
||||
Le JSON brut n'est acceptable que comme forme intermédiaire générée.
|
||||
Le JSON brut n’est acceptable qu’en tant que forme intermédiaire générée.
|
||||
|
||||
## Forme de fichier de scénario proposée
|
||||
## Forme proposée pour un fichier de scénario
|
||||
|
||||
Exemple :
|
||||
|
||||
@ -182,11 +185,11 @@ codeRefs:
|
||||
- src/gateway/chat-attachments.ts
|
||||
---
|
||||
|
||||
# Objectif
|
||||
# Objective
|
||||
|
||||
Vérifier que les médias générés sont rattachés au tour suivant.
|
||||
Verify generated media is reattached on the follow-up turn.
|
||||
|
||||
# Configuration
|
||||
# Setup
|
||||
|
||||
```yaml scenario.setup
|
||||
- action: config.patch
|
||||
@ -199,13 +202,13 @@ Vérifier que les médias générés sont rattachés au tour suivant.
|
||||
key: agent:qa:image-roundtrip
|
||||
```
|
||||
|
||||
# Étapes
|
||||
# Steps
|
||||
|
||||
```yaml scenario.steps
|
||||
- action: agent.send
|
||||
session: agent:qa:image-roundtrip
|
||||
message: |
|
||||
Contrôle de génération d'image : génère une image de phare QA et résume-la en une phrase courte.
|
||||
Image generation check: generate a QA lighthouse image and summarize it in one short sentence.
|
||||
- action: artifact.capture
|
||||
kind: generated-image
|
||||
promptSnippet: Image generation check
|
||||
@ -213,12 +216,12 @@ Vérifier que les médias générés sont rattachés au tour suivant.
|
||||
- action: agent.send
|
||||
session: agent:qa:image-roundtrip
|
||||
message: |
|
||||
Contrôle d'inspection d'image en aller-retour : décris la pièce jointe générée du phare en une phrase courte.
|
||||
Roundtrip image inspection check: describe the generated lighthouse attachment in one short sentence.
|
||||
attachments:
|
||||
- fromArtifact: lighthouseImage
|
||||
```
|
||||
|
||||
# Attendu
|
||||
# Expect
|
||||
|
||||
```yaml scenario.expect
|
||||
- assert: outbound.textIncludes
|
||||
@ -232,11 +235,11 @@ Vérifier que les médias générés sont rattachés au tour suivant.
|
||||
```
|
||||
````
|
||||
|
||||
## Capacités du runner que la DSL doit couvrir
|
||||
## Capacités du runner que le DSL doit couvrir
|
||||
|
||||
D'après la suite actuelle, le runner générique doit faire plus qu'exécuter des prompts.
|
||||
D’après la suite actuelle, le runner générique a besoin de plus que de l’exécution de prompts.
|
||||
|
||||
### Actions d'environnement et de configuration
|
||||
### Actions d’environnement et de configuration
|
||||
|
||||
- `bus.reset`
|
||||
- `gateway.waitHealthy`
|
||||
@ -245,14 +248,14 @@ D'après la suite actuelle, le runner générique doit faire plus qu'exécuter d
|
||||
- `thread.create`
|
||||
- `workspace.writeSkill`
|
||||
|
||||
### Actions de tour d'agent
|
||||
### Actions de tour d’agent
|
||||
|
||||
- `agent.send`
|
||||
- `agent.wait`
|
||||
- `bus.injectInbound`
|
||||
- `bus.injectOutbound`
|
||||
|
||||
### Actions de configuration et de runtime
|
||||
### Actions de configuration et d’exécution
|
||||
|
||||
- `config.get`
|
||||
- `config.patch`
|
||||
@ -270,7 +273,7 @@ D'après la suite actuelle, le runner générique doit faire plus qu'exécuter d
|
||||
- `artifact.captureGeneratedImage`
|
||||
- `artifact.capturePath`
|
||||
|
||||
### Actions mémoire et cron
|
||||
### Actions de mémoire et de cron
|
||||
|
||||
- `memory.indexForce`
|
||||
- `memory.searchCli`
|
||||
@ -300,99 +303,100 @@ D'après la suite actuelle, le runner générique doit faire plus qu'exécuter d
|
||||
- `cron.managedPresent`
|
||||
- `artifact.exists`
|
||||
|
||||
## Variables et références d'artefacts
|
||||
## Variables et références d’artefacts
|
||||
|
||||
La DSL doit prendre en charge les sorties enregistrées et leurs références ultérieures.
|
||||
Le DSL doit prendre en charge les sorties enregistrées et les références ultérieures.
|
||||
|
||||
Exemples issus de la suite actuelle :
|
||||
|
||||
- créer un fil, puis réutiliser `threadId`
|
||||
- créer une session, puis réutiliser `sessionKey`
|
||||
- générer une image, puis joindre le fichier au tour suivant
|
||||
- générer une chaîne de marqueur de réveil, puis vérifier qu'elle apparaît plus tard
|
||||
- générer une chaîne marqueur de réveil, puis vérifier qu’elle apparaît plus tard
|
||||
|
||||
Capacités nécessaires :
|
||||
|
||||
- `saveAs`
|
||||
- `${vars.name}`
|
||||
- `${artifacts.name}`
|
||||
- références typées pour les chemins, clés de session, identifiants de fil, marqueurs, sorties d'outil
|
||||
- références typées pour les chemins, clés de session, identifiants de fil, marqueurs, sorties d’outils
|
||||
|
||||
Sans prise en charge des variables, le harnais continuera à faire fuir la logique de scénario vers TypeScript.
|
||||
Sans prise en charge des variables, le harnais continuera à faire fuiter la logique des scénarios vers le TypeScript.
|
||||
|
||||
## Ce qui doit rester comme échappatoires
|
||||
|
||||
Un runner entièrement déclaratif pur n'est pas réaliste en phase 1.
|
||||
Un runner purement déclaratif n’est pas réaliste en phase 1.
|
||||
|
||||
Certains scénarios sont intrinsèquement lourds en orchestration :
|
||||
|
||||
- balayage memory dreaming
|
||||
- réveil après redémarrage suite à l'application de la configuration
|
||||
- bascule de capacité après redémarrage de configuration
|
||||
- résolution d'artefact d'image générée par horodatage/chemin
|
||||
- évaluation de rapport de découverte
|
||||
- memory dreaming sweep
|
||||
- config apply restart wake-up
|
||||
- config restart capability flip
|
||||
- résolution d’artefact d’image générée par horodatage/chemin
|
||||
- évaluation du rapport de découverte
|
||||
|
||||
Pour l'instant, ceux-ci doivent utiliser des gestionnaires personnalisés explicites.
|
||||
Ils devraient pour l’instant utiliser des handlers personnalisés explicites.
|
||||
|
||||
Règle recommandée :
|
||||
|
||||
- 85-90 % déclaratif
|
||||
- étapes `customHandler` explicites pour le reste difficile
|
||||
- gestionnaires personnalisés nommés et documentés uniquement
|
||||
- uniquement des handlers personnalisés nommés et documentés
|
||||
- aucun code inline anonyme dans le fichier de scénario
|
||||
|
||||
Cela garde le moteur générique propre tout en permettant d'avancer.
|
||||
Cela garde le moteur générique propre tout en permettant d’avancer.
|
||||
|
||||
## Changement d'architecture
|
||||
## Changement d’architecture
|
||||
|
||||
### Actuel
|
||||
|
||||
Le Markdown de scénario est déjà la source de vérité pour :
|
||||
Le Markdown des scénarios est déjà la source de vérité pour :
|
||||
|
||||
- l'exécution de la suite
|
||||
- les fichiers bootstrap du workspace
|
||||
- le catalogue de scénarios de l'UI QA Lab
|
||||
- l’exécution de la suite
|
||||
- les fichiers d’initialisation de l’espace de travail
|
||||
- le catalogue de scénarios de l’UI QA Lab
|
||||
- les métadonnées de rapport
|
||||
- les prompts de découverte
|
||||
|
||||
Compatibilité générée :
|
||||
|
||||
- le workspace initialisé inclut encore `QA_KICKOFF_TASK.md`
|
||||
- le workspace initialisé inclut encore `QA_SCENARIO_PLAN.md`
|
||||
- le workspace initialisé inclut maintenant aussi `QA_SCENARIOS.md`
|
||||
- l’espace de travail initial inclut toujours `QA_KICKOFF_TASK.md`
|
||||
- l’espace de travail initial inclut toujours `QA_SCENARIO_PLAN.md`
|
||||
- l’espace de travail initial inclut désormais aussi `QA_SCENARIOS.md`
|
||||
|
||||
## Plan de refactorisation
|
||||
|
||||
### Phase 1 : chargeur et schéma
|
||||
|
||||
Fait.
|
||||
Terminé.
|
||||
|
||||
- ajout de `qa/scenarios.md`
|
||||
- ajout d'un parseur pour le contenu du pack YAML Markdown nommé
|
||||
- ajout de `qa/scenarios/index.md`
|
||||
- séparation des scénarios dans `qa/scenarios/*.md`
|
||||
- ajout d’un parseur pour le contenu YAML Markdown nommé du pack
|
||||
- validation avec zod
|
||||
- basculement des consommateurs vers le pack analysé
|
||||
- suppression de `qa/seed-scenarios.json` et `qa/QA_KICKOFF_TASK.md` au niveau du dépôt
|
||||
|
||||
### Phase 2 : moteur générique
|
||||
|
||||
- découper `extensions/qa-lab/src/suite.ts` en :
|
||||
- diviser `extensions/qa-lab/src/suite.ts` en :
|
||||
- chargeur
|
||||
- moteur
|
||||
- registre d'actions
|
||||
- registre d'assertions
|
||||
- gestionnaires personnalisés
|
||||
- conserver les fonctions helper existantes comme opérations du moteur
|
||||
- registre d’actions
|
||||
- registre d’assertions
|
||||
- handlers personnalisés
|
||||
- conserver les fonctions utilitaires existantes comme opérations du moteur
|
||||
|
||||
Livrable :
|
||||
|
||||
- le moteur exécute des scénarios déclaratifs simples
|
||||
|
||||
Commencer par les scénarios qui sont surtout prompt + attente + assertion :
|
||||
Commencer par les scénarios qui sont principalement prompt + attente + assertion :
|
||||
|
||||
- suivi en fil
|
||||
- compréhension d'image depuis une pièce jointe
|
||||
- visibilité et invocation de skill
|
||||
- base de référence du canal
|
||||
- suivi dans un fil
|
||||
- compréhension d’image à partir d’une pièce jointe
|
||||
- visibilité et invocation de Skills
|
||||
- référence de base du canal
|
||||
|
||||
Livrable :
|
||||
|
||||
@ -400,36 +404,36 @@ Livrable :
|
||||
|
||||
### Phase 4 : migrer les scénarios intermédiaires
|
||||
|
||||
- aller-retour de génération d'image
|
||||
- outils mémoire dans le contexte du canal
|
||||
- aller-retour de génération d’image
|
||||
- outils de mémoire dans un contexte de canal
|
||||
- classement de la mémoire de session
|
||||
- transfert à un sous-agent
|
||||
- synthèse par fanout de sous-agent
|
||||
- transfert vers un sous-agent
|
||||
- synthèse par fanout de sous-agents
|
||||
|
||||
Livrable :
|
||||
|
||||
- variables, artefacts, assertions sur outils, assertions sur journaux de requêtes validés en pratique
|
||||
- variables, artefacts, assertions d’outils, assertions de journal de requêtes validés
|
||||
|
||||
### Phase 5 : conserver les scénarios difficiles sur des gestionnaires personnalisés
|
||||
### Phase 5 : conserver les scénarios difficiles sur des handlers personnalisés
|
||||
|
||||
- balayage memory dreaming
|
||||
- réveil après redémarrage suite à l'application de la configuration
|
||||
- bascule de capacité après redémarrage de configuration
|
||||
- dérive d'inventaire runtime
|
||||
- memory dreaming sweep
|
||||
- config apply restart wake-up
|
||||
- config restart capability flip
|
||||
- dérive d’inventaire d’exécution
|
||||
|
||||
Livrable :
|
||||
|
||||
- même format de rédaction, mais avec des blocs d'étapes personnalisées explicites lorsque nécessaire
|
||||
- même format de rédaction, mais avec des blocs d’étapes personnalisées explicites là où nécessaire
|
||||
|
||||
### Phase 6 : supprimer la map de scénarios codée en dur
|
||||
|
||||
Une fois que la couverture du pack sera suffisante :
|
||||
Quand la couverture du pack sera suffisamment bonne :
|
||||
|
||||
- supprimer la majeure partie du branchement TypeScript spécifique aux scénarios dans `extensions/qa-lab/src/suite.ts`
|
||||
|
||||
## Prise en charge du faux Slack / des médias enrichis
|
||||
## Faux Slack / prise en charge des médias riches
|
||||
|
||||
Le bus QA actuel est d'abord orienté texte.
|
||||
Le QA bus actuel est centré sur le texte.
|
||||
|
||||
Fichiers concernés :
|
||||
|
||||
@ -439,7 +443,7 @@ Fichiers concernés :
|
||||
- `extensions/qa-lab/src/bus-server.ts`
|
||||
- `extensions/qa-lab/web/src/ui-render.ts`
|
||||
|
||||
Aujourd'hui, le bus QA prend en charge :
|
||||
Aujourd’hui, le QA bus prend en charge :
|
||||
|
||||
- texte
|
||||
- réactions
|
||||
@ -449,7 +453,7 @@ Il ne modélise pas encore les pièces jointes média inline.
|
||||
|
||||
### Contrat de transport nécessaire
|
||||
|
||||
Ajouter un modèle générique de pièce jointe de bus QA :
|
||||
Ajouter un modèle générique de pièce jointe QA bus :
|
||||
|
||||
```ts
|
||||
type QaBusAttachment = {
|
||||
@ -474,61 +478,61 @@ Puis ajouter `attachments?: QaBusAttachment[]` à :
|
||||
- `QaBusInboundMessageInput`
|
||||
- `QaBusOutboundMessageInput`
|
||||
|
||||
### Pourquoi générique d'abord
|
||||
### Pourquoi commencer par du générique
|
||||
|
||||
Ne construisez pas un modèle média réservé à Slack.
|
||||
|
||||
À la place :
|
||||
|
||||
- un modèle de transport QA générique
|
||||
- plusieurs moteurs de rendu au-dessus
|
||||
- le chat QA Lab actuel
|
||||
- un futur faux web Slack
|
||||
- plusieurs moteurs de rendu par-dessus
|
||||
- le chat actuel de QA Lab
|
||||
- un futur faux Slack web
|
||||
- toute autre vue de faux transport
|
||||
|
||||
Cela évite la duplication de logique et permet aux scénarios média de rester indépendants du transport.
|
||||
Cela évite la logique dupliquée et permet aux scénarios média de rester indépendants du transport.
|
||||
|
||||
### Travail UI nécessaire
|
||||
|
||||
Mettre à jour l'UI QA pour afficher :
|
||||
Mettre à jour l’UI QA pour afficher :
|
||||
|
||||
- aperçu d'image inline
|
||||
- aperçu d’image inline
|
||||
- lecteur audio inline
|
||||
- lecteur vidéo inline
|
||||
- puce de pièce jointe de fichier
|
||||
|
||||
L'UI actuelle peut déjà afficher les fils et les réactions, donc le rendu des pièces jointes devrait se superposer au même modèle de carte de message.
|
||||
L’UI actuelle peut déjà afficher les fils et les réactions, donc le rendu des pièces jointes devrait pouvoir se superposer au même modèle de carte de message.
|
||||
|
||||
### Travail de scénario rendu possible par le transport média
|
||||
### Travail sur les scénarios rendu possible par le transport média
|
||||
|
||||
Une fois que les pièces jointes circulent via le bus QA, nous pouvons ajouter des scénarios de faux chat plus riches :
|
||||
Une fois que les pièces jointes circuleront dans le QA bus, nous pourrons ajouter des scénarios de faux chat plus riches :
|
||||
|
||||
- réponse avec image inline dans le faux Slack
|
||||
- compréhension de pièce jointe audio
|
||||
- compréhension de pièce jointe vidéo
|
||||
- réponse avec image inline dans un faux Slack
|
||||
- compréhension d’une pièce jointe audio
|
||||
- compréhension d’une pièce jointe vidéo
|
||||
- ordre mixte des pièces jointes
|
||||
- réponse en fil avec média conservé
|
||||
- réponse dans un fil avec conservation du média
|
||||
|
||||
## Recommandation
|
||||
|
||||
Le prochain lot d'implémentation devrait être :
|
||||
Le prochain bloc d’implémentation devrait être :
|
||||
|
||||
1. ajouter un chargeur de scénario Markdown + schéma zod
|
||||
1. ajouter un chargeur de scénarios Markdown + un schéma zod
|
||||
2. générer le catalogue actuel à partir du Markdown
|
||||
3. migrer d'abord quelques scénarios simples
|
||||
4. ajouter la prise en charge générique des pièces jointes du bus QA
|
||||
5. afficher une image inline dans l'UI QA
|
||||
6. puis étendre à l'audio et à la vidéo
|
||||
3. migrer d’abord quelques scénarios simples
|
||||
4. ajouter la prise en charge générique des pièces jointes QA bus
|
||||
5. afficher une image inline dans l’UI QA
|
||||
6. puis étendre à l’audio et à la vidéo
|
||||
|
||||
C'est le plus petit chemin qui prouve les deux objectifs :
|
||||
C’est le plus petit chemin qui prouve les deux objectifs :
|
||||
|
||||
- QA générique définie en Markdown
|
||||
- surfaces de fausse messagerie plus riches
|
||||
- surfaces de messagerie simulées plus riches
|
||||
|
||||
## Questions ouvertes
|
||||
|
||||
- faut-il autoriser dans les fichiers de scénario des modèles de prompt Markdown embarqués avec interpolation de variables
|
||||
- faut-il que setup/cleanup soient des sections nommées ou simplement des listes d'actions ordonnées
|
||||
- faut-il que les références d'artefacts soient fortement typées dans le schéma ou basées sur des chaînes
|
||||
- faut-il que les gestionnaires personnalisés vivent dans un seul registre ou dans des registres par surface
|
||||
- faut-il que le fichier de compatibilité JSON généré reste versionné pendant la migration
|
||||
- si les fichiers de scénario doivent autoriser des modèles de prompt Markdown embarqués avec interpolation de variables
|
||||
- si setup/cleanup doivent être des sections nommées ou simplement des listes d’actions ordonnées
|
||||
- si les références d’artefacts doivent être fortement typées dans le schéma ou basées sur des chaînes
|
||||
- si les handlers personnalisés doivent vivre dans un seul registre ou dans des registres par surface
|
||||
- si le fichier de compatibilité JSON généré doit rester versionné pendant la migration
|
||||
|
||||
@ -5,32 +5,32 @@ read_when:
|
||||
summary: 'Commandes slash : texte vs natives, configuration et commandes prises en charge'
|
||||
title: Commandes slash
|
||||
x-i18n:
|
||||
generated_at: "2026-04-06T03:14:23Z"
|
||||
generated_at: "2026-04-08T06:02:06Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 417e35b9ddd87f25f6c019111b55b741046ea11039dde89210948185ced5696d
|
||||
source_hash: 4a7ee7f1a8012058279b9e632889b291d4e659e4ec81209ca8978afbb9ad4b96
|
||||
source_path: tools/slash-commands.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Commandes slash
|
||||
|
||||
Les commandes sont gérées par la passerelle. La plupart des commandes doivent être envoyées comme un message **autonome** qui commence par `/`.
|
||||
La commande de chat bash réservée à l'hôte utilise `! <cmd>` (avec `/bash <cmd>` comme alias).
|
||||
Les commandes sont gérées par la Gateway. La plupart des commandes doivent être envoyées sous la forme d’un message **autonome** qui commence par `/`.
|
||||
La commande de chat bash réservée à l’hôte utilise `! <cmd>` (avec `/bash <cmd>` comme alias).
|
||||
|
||||
Il existe deux systèmes liés :
|
||||
|
||||
- **Commandes** : messages autonomes `/...`.
|
||||
- **Directives** : `/think`, `/fast`, `/verbose`, `/reasoning`, `/elevated`, `/exec`, `/model`, `/queue`.
|
||||
- Les directives sont retirées du message avant que le modèle ne le voie.
|
||||
- Dans les messages de chat normaux (pas uniquement des directives), elles sont traitées comme des « indications inline » et ne persistent **pas** dans les paramètres de session.
|
||||
- Dans les messages contenant uniquement des directives (le message ne contient que des directives), elles persistent dans la session et répondent par un accusé de réception.
|
||||
- Les directives ne sont appliquées que pour les **expéditeurs autorisés**. Si `commands.allowFrom` est défini, c'est la seule
|
||||
liste d'autorisation utilisée ; sinon, l'autorisation provient des listes d'autorisation/appairages des canaux ainsi que de `commands.useAccessGroups`.
|
||||
Pour les expéditeurs non autorisés, les directives sont traitées comme du texte brut.
|
||||
- Les directives sont supprimées du message avant que le modèle ne le voie.
|
||||
- Dans les messages de chat normaux (pas uniquement composés de directives), elles sont traitées comme des « indices en ligne » et ne persistent **pas** les paramètres de session.
|
||||
- Dans les messages composés uniquement de directives (le message ne contient que des directives), elles persistent dans la session et répondent avec un accusé de réception.
|
||||
- Les directives ne sont appliquées que pour les **expéditeurs autorisés**. Si `commands.allowFrom` est défini, c’est la seule
|
||||
liste d’autorisation utilisée ; sinon l’autorisation provient des listes d’autorisation/appairages du canal ainsi que de `commands.useAccessGroups`.
|
||||
Les expéditeurs non autorisés voient les directives traitées comme du texte brut.
|
||||
|
||||
Il existe également quelques **raccourcis inline** (expéditeurs autorisés/sur liste d'autorisation uniquement) : `/help`, `/commands`, `/status`, `/whoami` (`/id`).
|
||||
Ils s'exécutent immédiatement, sont retirés avant que le modèle ne voie le message, puis le texte restant continue dans le flux normal.
|
||||
Il existe aussi quelques **raccourcis en ligne** (expéditeurs sur liste d’autorisation/autorisés uniquement) : `/help`, `/commands`, `/status`, `/whoami` (`/id`).
|
||||
Ils s’exécutent immédiatement, sont supprimés avant que le modèle ne voie le message, et le texte restant suit le flux normal.
|
||||
|
||||
## Configuration
|
||||
|
||||
@ -46,7 +46,10 @@ Ils s'exécutent immédiatement, sont retirés avant que le modèle ne voie le m
|
||||
mcp: false,
|
||||
plugins: false,
|
||||
debug: false,
|
||||
restart: false,
|
||||
restart: true,
|
||||
ownerAllowFrom: ["discord:123456789012345678"],
|
||||
ownerDisplay: "raw",
|
||||
ownerDisplaySecret: "${OWNER_ID_HASH_SECRET}",
|
||||
allowFrom: {
|
||||
"*": ["user1"],
|
||||
discord: ["user:123"],
|
||||
@ -56,144 +59,179 @@ Ils s'exécutent immédiatement, sont retirés avant que le modèle ne voie le m
|
||||
}
|
||||
```
|
||||
|
||||
- `commands.text` (par défaut `true`) active l'analyse de `/...` dans les messages de chat.
|
||||
- Sur les surfaces sans commandes natives (WhatsApp/WebChat/Signal/iMessage/Google Chat/Microsoft Teams), les commandes texte continuent de fonctionner même si vous le définissez sur `false`.
|
||||
- `commands.text` (par défaut `true`) active l’analyse de `/...` dans les messages de chat.
|
||||
- Sur les surfaces sans commandes natives (WhatsApp/WebChat/Signal/iMessage/Google Chat/Microsoft Teams), les commandes texte continuent de fonctionner même si vous définissez cette option sur `false`.
|
||||
- `commands.native` (par défaut `"auto"`) enregistre les commandes natives.
|
||||
- Auto : activé pour Discord/Telegram ; désactivé pour Slack (jusqu'à ce que vous ajoutiez des commandes slash) ; ignoré pour les fournisseurs sans prise en charge native.
|
||||
- Définissez `channels.discord.commands.native`, `channels.telegram.commands.native` ou `channels.slack.commands.native` pour remplacer le comportement par fournisseur (booléen ou `"auto"`).
|
||||
- `false` efface les commandes précédemment enregistrées sur Discord/Telegram au démarrage. Les commandes Slack sont gérées dans l'application Slack et ne sont pas supprimées automatiquement.
|
||||
- `commands.nativeSkills` (par défaut `"auto"`) enregistre nativement les commandes de **skill** lorsque c'est pris en charge.
|
||||
- Auto : activé pour Discord/Telegram ; désactivé pour Slack (Slack nécessite la création d'une commande slash par skill).
|
||||
- Définissez `channels.discord.commands.nativeSkills`, `channels.telegram.commands.nativeSkills` ou `channels.slack.commands.nativeSkills` pour remplacer le comportement par fournisseur (booléen ou `"auto"`).
|
||||
- `commands.bash` (par défaut `false`) active `! <cmd>` pour exécuter des commandes shell sur l'hôte (`/bash <cmd>` est un alias ; nécessite les listes d'autorisation `tools.elevated`).
|
||||
- Auto : activé pour Discord/Telegram ; désactivé pour Slack (jusqu’à ce que vous ajoutiez des commandes slash) ; ignoré pour les fournisseurs sans prise en charge native.
|
||||
- Définissez `channels.discord.commands.native`, `channels.telegram.commands.native` ou `channels.slack.commands.native` pour remplacer ce paramètre par fournisseur (booléen ou `"auto"`).
|
||||
- `false` efface au démarrage les commandes précédemment enregistrées sur Discord/Telegram. Les commandes Slack sont gérées dans l’application Slack et ne sont pas supprimées automatiquement.
|
||||
- `commands.nativeSkills` (par défaut `"auto"`) enregistre nativement les commandes de **Skills** lorsqu’elles sont prises en charge.
|
||||
- Auto : activé pour Discord/Telegram ; désactivé pour Slack (Slack exige la création d’une commande slash par skill).
|
||||
- Définissez `channels.discord.commands.nativeSkills`, `channels.telegram.commands.nativeSkills` ou `channels.slack.commands.nativeSkills` pour remplacer ce paramètre par fournisseur (booléen ou `"auto"`).
|
||||
- `commands.bash` (par défaut `false`) active `! <cmd>` pour exécuter des commandes shell sur l’hôte (`/bash <cmd>` est un alias ; nécessite les listes d’autorisation `tools.elevated`).
|
||||
- `commands.bashForegroundMs` (par défaut `2000`) contrôle combien de temps bash attend avant de passer en mode arrière-plan (`0` passe immédiatement en arrière-plan).
|
||||
- `commands.config` (par défaut `false`) active `/config` (lecture/écriture de `openclaw.json`).
|
||||
- `commands.mcp` (par défaut `false`) active `/mcp` (lecture/écriture de la configuration MCP gérée par OpenClaw sous `mcp.servers`).
|
||||
- `commands.plugins` (par défaut `false`) active `/plugins` (découverte/statut des plugins plus contrôles d'installation + activation/désactivation).
|
||||
- `commands.debug` (par défaut `false`) active `/debug` (remplacements à l'exécution uniquement).
|
||||
- `commands.allowFrom` (facultatif) définit une liste d'autorisation par fournisseur pour l'autorisation des commandes. Lorsqu'elle est configurée, c'est la
|
||||
seule source d'autorisation pour les commandes et les directives (`commands.useAccessGroups` et les listes d'autorisation/appairages des canaux
|
||||
- `commands.plugins` (par défaut `false`) active `/plugins` (découverte/statut des plugins ainsi que contrôles d’installation + activation/désactivation).
|
||||
- `commands.debug` (par défaut `false`) active `/debug` (remplacements à l’exécution uniquement).
|
||||
- `commands.restart` (par défaut `true`) active `/restart` ainsi que les actions d’outil de redémarrage de la gateway.
|
||||
- `commands.ownerAllowFrom` (facultatif) définit la liste d’autorisation explicite du propriétaire pour les surfaces de commandes/outils réservées au propriétaire. Elle est distincte de `commands.allowFrom`.
|
||||
- `commands.ownerDisplay` contrôle la manière dont les identifiants de propriétaire apparaissent dans le prompt système : `raw` ou `hash`.
|
||||
- `commands.ownerDisplaySecret` définit éventuellement le secret HMAC utilisé lorsque `commands.ownerDisplay="hash"`.
|
||||
- `commands.allowFrom` (facultatif) définit une liste d’autorisation par fournisseur pour l’autorisation des commandes. Lorsqu’elle est configurée, c’est la
|
||||
seule source d’autorisation pour les commandes et les directives (`commands.useAccessGroups` ainsi que les listes d’autorisation/appairages du canal
|
||||
sont ignorés). Utilisez `"*"` pour une valeur par défaut globale ; les clés spécifiques au fournisseur la remplacent.
|
||||
- `commands.useAccessGroups` (par défaut `true`) applique les listes d'autorisation/politiques pour les commandes lorsque `commands.allowFrom` n'est pas défini.
|
||||
- `commands.useAccessGroups` (par défaut `true`) applique les listes d’autorisation/politiques aux commandes lorsque `commands.allowFrom` n’est pas défini.
|
||||
|
||||
## Liste des commandes
|
||||
|
||||
Texte + natives (quand elles sont activées) :
|
||||
Source de vérité actuelle :
|
||||
|
||||
- `/help`
|
||||
- `/commands`
|
||||
- `/tools [compact|verbose]` (affiche ce que l'agent actuel peut utiliser maintenant ; `verbose` ajoute des descriptions)
|
||||
- `/skill <name> [input]` (exécute une skill par nom)
|
||||
- `/status` (affiche l'état actuel ; inclut l'utilisation/le quota du fournisseur pour le fournisseur de modèle actuel lorsque disponible)
|
||||
- `/tasks` (liste les tâches d'arrière-plan pour la session actuelle ; affiche les détails des tâches actives et récentes avec les comptes de secours locaux à l'agent)
|
||||
- `/allowlist` (lister/ajouter/supprimer des entrées de liste d'autorisation)
|
||||
- `/approve <id> <decision>` (résout les invites d'approbation exec ; utilisez le message d'approbation en attente pour voir les décisions disponibles)
|
||||
- `/context [list|detail|json]` (explique le « contexte » ; `detail` affiche la taille par fichier + par outil + par skill + celle du prompt système)
|
||||
- `/btw <question>` (poser une question latérale éphémère sur la session actuelle sans modifier le contexte futur de la session ; voir [/tools/btw](/fr/tools/btw))
|
||||
- `/export-session [path]` (alias : `/export`) (exporte la session actuelle en HTML avec le prompt système complet)
|
||||
- `/whoami` (affiche votre identifiant d'expéditeur ; alias : `/id`)
|
||||
- `/session idle <duration|off>` (gère la perte de focus automatique par inactivité pour les associations de fils focalisés)
|
||||
- `/session max-age <duration|off>` (gère la perte de focus automatique par durée maximale stricte pour les associations de fils focalisés)
|
||||
- `/subagents list|kill|log|info|send|steer|spawn` (inspecte, contrôle ou lance des exécutions de sous-agents pour la session actuelle)
|
||||
- `/acp spawn|cancel|steer|close|status|set-mode|set|cwd|permissions|timeout|model|reset-options|doctor|install|sessions` (inspecte et contrôle les sessions d'exécution ACP)
|
||||
- `/agents` (liste les agents liés à un fil pour cette session)
|
||||
- `/focus <target>` (Discord : lie ce fil, ou un nouveau fil, à une cible de session/sous-agent)
|
||||
- `/unfocus` (Discord : supprime l'association du fil actuel)
|
||||
- `/kill <id|#|all>` (interrompt immédiatement un ou tous les sous-agents en cours pour cette session ; aucun message de confirmation)
|
||||
- `/steer <id|#> <message>` (redirige immédiatement un sous-agent en cours : pendant l'exécution quand c'est possible, sinon interrompt le travail actuel et redémarre sur le message de redirection)
|
||||
- `/tell <id|#> <message>` (alias de `/steer`)
|
||||
- `/config show|get|set|unset` (persiste la configuration sur disque, propriétaire uniquement ; nécessite `commands.config: true`)
|
||||
- `/mcp show|get|set|unset` (gère la configuration du serveur MCP OpenClaw, propriétaire uniquement ; nécessite `commands.mcp: true`)
|
||||
- `/plugins list|show|get|install|enable|disable` (inspecte les plugins découverts, installe de nouveaux plugins et bascule leur activation ; propriétaire uniquement pour les écritures ; nécessite `commands.plugins: true`)
|
||||
- `/plugin` est un alias de `/plugins`.
|
||||
- `/plugin install <spec>` accepte les mêmes spécifications de plugin que `openclaw plugins install` : chemin/archive local, paquet npm ou `clawhub:<pkg>`.
|
||||
- Les écritures d'activation/désactivation répondent toujours avec une indication de redémarrage. Sur une passerelle de premier plan surveillée, OpenClaw peut effectuer ce redémarrage automatiquement juste après l'écriture.
|
||||
- `/debug show|set|unset|reset` (remplacements à l'exécution, propriétaire uniquement ; nécessite `commands.debug: true`)
|
||||
- `/usage off|tokens|full|cost` (pied de page d'utilisation par réponse ou résumé local des coûts)
|
||||
- `/tts off|always|inbound|tagged|status|provider|limit|summary|audio` (contrôle le TTS ; voir [/tts](/fr/tools/tts))
|
||||
- Discord : la commande native est `/voice` (Discord réserve `/tts`) ; la commande texte `/tts` fonctionne toujours.
|
||||
- `/stop`
|
||||
- `/restart`
|
||||
- `/dock-telegram` (alias : `/dock_telegram`) (bascule les réponses vers Telegram)
|
||||
- `/dock-discord` (alias : `/dock_discord`) (bascule les réponses vers Discord)
|
||||
- `/dock-slack` (alias : `/dock_slack`) (bascule les réponses vers Slack)
|
||||
- `/activation mention|always` (groupes uniquement)
|
||||
- `/send on|off|inherit` (propriétaire uniquement)
|
||||
- `/reset` ou `/new [model]` (indication de modèle facultative ; le reste est transmis)
|
||||
- `/think <off|minimal|low|medium|high|xhigh>` (choix dynamiques selon le modèle/fournisseur ; alias : `/thinking`, `/t`)
|
||||
- `/fast status|on|off` (si vous omettez l'argument, affiche l'état effectif actuel du mode rapide)
|
||||
- `/verbose on|full|off` (alias : `/v`)
|
||||
- `/reasoning on|off|stream` (alias : `/reason` ; lorsqu'il est activé, envoie un message séparé préfixé par `Reasoning:` ; `stream` = brouillon Telegram uniquement)
|
||||
- `/elevated on|off|ask|full` (alias : `/elev` ; `full` ignore les approbations exec)
|
||||
- `/exec host=<auto|sandbox|gateway|node> security=<deny|allowlist|full> ask=<off|on-miss|always> node=<id>` (envoyez `/exec` pour afficher l'état actuel)
|
||||
- `/model <name>` (alias : `/models` ; ou `/<alias>` depuis `agents.defaults.models.*.alias`)
|
||||
- `/queue <mode>` (plus des options comme `debounce:2s cap:25 drop:summarize` ; envoyez `/queue` pour voir les paramètres actuels)
|
||||
- `/bash <command>` (hôte uniquement ; alias de `! <command>` ; nécessite `commands.bash: true` + listes d'autorisation `tools.elevated`)
|
||||
- `/dreaming [on|off|status|help]` (active/désactive dreaming globalement ou affiche l'état ; voir [Dreaming](/fr/concepts/dreaming))
|
||||
- les éléments intégrés du cœur proviennent de `src/auto-reply/commands-registry.shared.ts`
|
||||
- les commandes dock générées proviennent de `src/auto-reply/commands-registry.data.ts`
|
||||
- les commandes de plugins proviennent des appels de plugin `registerCommand()`
|
||||
- la disponibilité réelle sur votre gateway dépend toujours des drapeaux de configuration, de la surface du canal et des plugins installés/activés
|
||||
|
||||
Texte uniquement :
|
||||
### Commandes intégrées du cœur
|
||||
|
||||
- `/compact [instructions]` (voir [/concepts/compaction](/fr/concepts/compaction))
|
||||
- `! <command>` (hôte uniquement ; une à la fois ; utilisez `!poll` + `!stop` pour les tâches longues)
|
||||
- `!poll` (vérifie la sortie / l'état ; accepte un `sessionId` facultatif ; `/bash poll` fonctionne aussi)
|
||||
- `!stop` (arrête la tâche bash en cours ; accepte un `sessionId` facultatif ; `/bash stop` fonctionne aussi)
|
||||
Commandes intégrées disponibles aujourd’hui :
|
||||
|
||||
- `/new [model]` démarre une nouvelle session ; `/reset` est l’alias de réinitialisation.
|
||||
- `/compact [instructions]` compacte le contexte de la session. Voir [/concepts/compaction](/fr/concepts/compaction).
|
||||
- `/stop` interrompt l’exécution en cours.
|
||||
- `/session idle <duration|off>` et `/session max-age <duration|off>` gèrent l’expiration de l’association au fil.
|
||||
- `/think <off|minimal|low|medium|high|xhigh>` définit le niveau de réflexion. Alias : `/thinking`, `/t`.
|
||||
- `/verbose on|off|full` active ou désactive la sortie détaillée. Alias : `/v`.
|
||||
- `/fast [status|on|off]` affiche ou définit le mode rapide.
|
||||
- `/reasoning [on|off|stream]` active ou désactive la visibilité du raisonnement. Alias : `/reason`.
|
||||
- `/elevated [on|off|ask|full]` active ou désactive le mode élevé. Alias : `/elev`.
|
||||
- `/exec host=<auto|sandbox|gateway|node> security=<deny|allowlist|full> ask=<off|on-miss|always> node=<id>` affiche ou définit les valeurs par défaut d’exécution.
|
||||
- `/model [name|#|status]` affiche ou définit le modèle.
|
||||
- `/models [provider] [page] [limit=<n>|size=<n>|all]` liste les fournisseurs ou les modèles d’un fournisseur.
|
||||
- `/queue <mode>` gère le comportement de la file (`steer`, `interrupt`, `followup`, `collect`, `steer-backlog`) ainsi que des options comme `debounce:2s cap:25 drop:summarize`.
|
||||
- `/help` affiche le résumé d’aide court.
|
||||
- `/commands` affiche le catalogue de commandes généré.
|
||||
- `/tools [compact|verbose]` affiche ce que l’agent actuel peut utiliser à cet instant.
|
||||
- `/status` affiche l’état d’exécution, y compris l’utilisation/le quota du fournisseur lorsque disponible.
|
||||
- `/tasks` liste les tâches d’arrière-plan actives/récentes pour la session en cours.
|
||||
- `/context [list|detail|json]` explique comment le contexte est assemblé.
|
||||
- `/export-session [path]` exporte la session en cours en HTML. Alias : `/export`.
|
||||
- `/whoami` affiche votre identifiant d’expéditeur. Alias : `/id`.
|
||||
- `/skill <name> [input]` exécute une skill par son nom.
|
||||
- `/allowlist [list|add|remove] ...` gère les entrées de liste d’autorisation. Texte uniquement.
|
||||
- `/approve <id> <decision>` résout les invites d’approbation d’exécution.
|
||||
- `/btw <question>` pose une question annexe sans modifier le contexte futur de la session. Voir [/tools/btw](/fr/tools/btw).
|
||||
- `/subagents list|kill|log|info|send|steer|spawn` gère les exécutions de sous-agents pour la session en cours.
|
||||
- `/acp spawn|cancel|steer|close|sessions|status|set-mode|set|cwd|permissions|timeout|model|reset-options|doctor|install|help` gère les sessions ACP et les options d’exécution.
|
||||
- `/focus <target>` associe le fil Discord ou le sujet/conversation Telegram actuel à une cible de session.
|
||||
- `/unfocus` supprime l’association actuelle.
|
||||
- `/agents` liste les agents liés au fil pour la session en cours.
|
||||
- `/kill <id|#|all>` interrompt un ou tous les sous-agents en cours d’exécution.
|
||||
- `/steer <id|#> <message>` envoie une instruction à un sous-agent en cours d’exécution. Alias : `/tell`.
|
||||
- `/config show|get|set|unset` lit ou écrit `openclaw.json`. Réservé au propriétaire. Nécessite `commands.config: true`.
|
||||
- `/mcp show|get|set|unset` lit ou écrit la configuration du serveur MCP gérée par OpenClaw sous `mcp.servers`. Réservé au propriétaire. Nécessite `commands.mcp: true`.
|
||||
- `/plugins list|inspect|show|get|install|enable|disable` inspecte ou modifie l’état des plugins. `/plugin` est un alias. Écriture réservée au propriétaire. Nécessite `commands.plugins: true`.
|
||||
- `/debug show|set|unset|reset` gère les remplacements de configuration à l’exécution uniquement. Réservé au propriétaire. Nécessite `commands.debug: true`.
|
||||
- `/usage off|tokens|full|cost` contrôle le pied de page d’utilisation par réponse ou affiche un résumé local des coûts.
|
||||
- `/tts on|off|status|provider|limit|summary|audio|help` contrôle le TTS. Voir [/tools/tts](/fr/tools/tts).
|
||||
- `/restart` redémarre OpenClaw lorsqu’il est activé. Par défaut : activé ; définissez `commands.restart: false` pour le désactiver.
|
||||
- `/activation mention|always` définit le mode d’activation du groupe.
|
||||
- `/send on|off|inherit` définit la politique d’envoi. Réservé au propriétaire.
|
||||
- `/bash <command>` exécute une commande shell sur l’hôte. Texte uniquement. Alias : `! <command>`. Nécessite `commands.bash: true` ainsi que les listes d’autorisation `tools.elevated`.
|
||||
- `!poll [sessionId]` vérifie une tâche bash en arrière-plan.
|
||||
- `!stop [sessionId]` arrête une tâche bash en arrière-plan.
|
||||
|
||||
### Commandes dock générées
|
||||
|
||||
Les commandes dock sont générées à partir de plugins de canal avec prise en charge des commandes natives. Ensemble inclus actuel :
|
||||
|
||||
- `/dock-discord` (alias : `/dock_discord`)
|
||||
- `/dock-mattermost` (alias : `/dock_mattermost`)
|
||||
- `/dock-slack` (alias : `/dock_slack`)
|
||||
- `/dock-telegram` (alias : `/dock_telegram`)
|
||||
|
||||
### Commandes des plugins inclus
|
||||
|
||||
Les plugins inclus peuvent ajouter d’autres commandes slash. Commandes incluses actuelles dans ce dépôt :
|
||||
|
||||
- `/dreaming [on|off|status|help]` active ou désactive le dreaming de la mémoire. Voir [Dreaming](/fr/concepts/dreaming).
|
||||
- `/pair [qr|status|pending|approve|cleanup|notify]` gère le flux d’appairage/configuration des appareils. Voir [Appairage](/fr/channels/pairing).
|
||||
- `/phone status|arm <camera|screen|writes|all> [duration]|disarm` arme temporairement les commandes de nœud téléphonique à haut risque.
|
||||
- `/voice status|list [limit]|set <voiceId|name>` gère la configuration de voix Talk. Sur Discord, le nom de la commande native est `/talkvoice`.
|
||||
- `/card ...` envoie des préréglages de cartes riches LINE. Voir [LINE](/fr/channels/line).
|
||||
- Commandes réservées à QQBot :
|
||||
- `/bot-ping`
|
||||
- `/bot-version`
|
||||
- `/bot-help`
|
||||
- `/bot-upgrade`
|
||||
- `/bot-logs`
|
||||
|
||||
### Commandes de Skills dynamiques
|
||||
|
||||
Les Skills invocables par l’utilisateur sont également exposées comme commandes slash :
|
||||
|
||||
- `/skill <name> [input]` fonctionne toujours comme point d’entrée générique.
|
||||
- les skills peuvent aussi apparaître comme commandes directes telles que `/prose` lorsque la skill/le plugin les enregistre.
|
||||
- l’enregistrement natif des commandes de skills est contrôlé par `commands.nativeSkills` et `channels.<provider>.commands.nativeSkills`.
|
||||
|
||||
Remarques :
|
||||
|
||||
- Les commandes acceptent un `:` facultatif entre la commande et les arguments (par ex. `/think: high`, `/send: on`, `/help:`).
|
||||
- `/new <model>` accepte un alias de modèle, `provider/model` ou un nom de fournisseur (correspondance approximative) ; si aucune correspondance n'est trouvée, le texte est traité comme corps du message.
|
||||
- Pour le détail complet de l'utilisation par fournisseur, utilisez `openclaw status --usage`.
|
||||
- Les commandes acceptent un `:` facultatif entre la commande et ses arguments (par ex. `/think: high`, `/send: on`, `/help:`).
|
||||
- `/new <model>` accepte un alias de modèle, `provider/model` ou un nom de fournisseur (correspondance approximative) ; s’il n’y a pas de correspondance, le texte est traité comme corps du message.
|
||||
- Pour la répartition complète de l’utilisation par fournisseur, utilisez `openclaw status --usage`.
|
||||
- `/allowlist add|remove` nécessite `commands.config=true` et respecte `configWrites` du canal.
|
||||
- Dans les canaux multi-comptes, `/allowlist --account <id>` ciblé configuration et `/config set channels.<provider>.accounts.<id>...` respectent aussi `configWrites` du compte cible.
|
||||
- `/usage` contrôle le pied de page d'utilisation par réponse ; `/usage cost` affiche un résumé local des coûts à partir des journaux de session OpenClaw.
|
||||
- Dans les canaux multi-comptes, `/allowlist --account <id>` ciblé sur la configuration et `/config set channels.<provider>.accounts.<id>...` respectent également `configWrites` du compte cible.
|
||||
- `/usage` contrôle le pied de page d’utilisation par réponse ; `/usage cost` affiche un résumé local des coûts à partir des journaux de session OpenClaw.
|
||||
- `/restart` est activé par défaut ; définissez `commands.restart: false` pour le désactiver.
|
||||
- Commande native Discord uniquement : `/vc join|leave|status` contrôle les canaux vocaux (nécessite `channels.discord.voice` et les commandes natives ; non disponible en texte).
|
||||
- Les commandes de liaison de fils Discord (`/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age`) nécessitent que les liaisons de fils effectives soient activées (`session.threadBindings.enabled` et/ou `channels.discord.threadBindings.enabled`).
|
||||
- Référence des commandes ACP et comportement à l'exécution : [ACP Agents](/fr/tools/acp-agents).
|
||||
- `/verbose` est destiné au débogage et à une visibilité supplémentaire ; laissez-le **désactivé** en usage normal.
|
||||
- `/fast on|off` persiste un remplacement au niveau de la session. Utilisez l'option `inherit` de l'interface Sessions pour l'effacer et revenir aux valeurs par défaut de la configuration.
|
||||
- `/fast` est spécifique au fournisseur : OpenAI/OpenAI Codex le mappe à `service_tier=priority` sur les endpoints natifs Responses, tandis que les requêtes Anthropic publiques directes, y compris le trafic authentifié par OAuth envoyé à `api.anthropic.com`, le mappent à `service_tier=auto` ou `standard_only`. Voir [OpenAI](/fr/providers/openai) et [Anthropic](/fr/providers/anthropic).
|
||||
- Les résumés d'échec d'outil sont toujours affichés lorsqu'ils sont pertinents, mais le texte détaillé de l'échec n'est inclus que lorsque `/verbose` est `on` ou `full`.
|
||||
- `/reasoning` (et `/verbose`) sont risqués dans les contextes de groupe : ils peuvent révéler un raisonnement interne ou une sortie d'outil que vous n'aviez pas l'intention d'exposer. Il est préférable de les laisser désactivés, surtout dans les discussions de groupe.
|
||||
- `/plugins install <spec>` accepte les mêmes spécifications de plugin que `openclaw plugins install` : chemin/archive local, paquet npm ou `clawhub:<pkg>`.
|
||||
- `/plugins enable|disable` met à jour la configuration du plugin et peut demander un redémarrage.
|
||||
- Commande native réservée à Discord : `/vc join|leave|status` contrôle les canaux vocaux (nécessite `channels.discord.voice` et les commandes natives ; non disponible en tant que texte).
|
||||
- Les commandes d’association aux fils Discord (`/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age`) exigent que les associations effectives aux fils soient activées (`session.threadBindings.enabled` et/ou `channels.discord.threadBindings.enabled`).
|
||||
- Référence des commandes ACP et comportement à l’exécution : [Agents ACP](/fr/tools/acp-agents).
|
||||
- `/verbose` est destiné au débogage et à une visibilité supplémentaire ; laissez-le **désactivé** en utilisation normale.
|
||||
- `/fast on|off` persiste un remplacement de session. Utilisez l’option `inherit` de l’interface Sessions pour l’effacer et revenir aux valeurs par défaut de la configuration.
|
||||
- `/fast` est spécifique au fournisseur : OpenAI/OpenAI Codex le mappent à `service_tier=priority` sur les points de terminaison natifs Responses, tandis que les requêtes Anthropic publiques directes, y compris le trafic authentifié par OAuth envoyé à `api.anthropic.com`, le mappent à `service_tier=auto` ou `standard_only`. Voir [OpenAI](/fr/providers/openai) et [Anthropic](/fr/providers/anthropic).
|
||||
- Les résumés d’échec d’outil sont toujours affichés lorsque c’est pertinent, mais le texte détaillé d’échec n’est inclus que lorsque `/verbose` est `on` ou `full`.
|
||||
- `/reasoning` (et `/verbose`) sont risqués en contexte de groupe : ils peuvent révéler un raisonnement interne ou une sortie d’outil que vous n’aviez pas l’intention d’exposer. Préférez les laisser désactivés, surtout dans les discussions de groupe.
|
||||
- `/model` persiste immédiatement le nouveau modèle de session.
|
||||
- Si l'agent est inactif, l'exécution suivante l'utilise immédiatement.
|
||||
- Si une exécution est déjà active, OpenClaw marque un changement à chaud comme en attente et ne redémarre vers le nouveau modèle qu'à un point de reprise propre.
|
||||
- Si l'activité des outils ou la sortie de réponse a déjà commencé, le changement en attente peut rester en file jusqu'à une opportunité de reprise ultérieure ou au prochain tour utilisateur.
|
||||
- **Chemin rapide :** les messages ne contenant que des commandes envoyés par des expéditeurs sur liste d'autorisation sont traités immédiatement (contournent la file d'attente + le modèle).
|
||||
- **Filtrage par mention dans les groupes :** les messages ne contenant que des commandes envoyés par des expéditeurs sur liste d'autorisation contournent les exigences de mention.
|
||||
- **Raccourcis inline (expéditeurs sur liste d'autorisation uniquement) :** certaines commandes fonctionnent aussi lorsqu'elles sont intégrées dans un message normal et sont retirées avant que le modèle ne voie le texte restant.
|
||||
- Exemple : `hey /status` déclenche une réponse de statut, puis le texte restant continue dans le flux normal.
|
||||
- Si l’agent est inactif, l’exécution suivante l’utilise immédiatement.
|
||||
- Si une exécution est déjà active, OpenClaw marque un changement en direct comme en attente et ne redémarre sur le nouveau modèle qu’à un point de nouvelle tentative propre.
|
||||
- Si l’activité des outils ou la sortie de réponse a déjà commencé, le changement en attente peut rester en file jusqu’à une opportunité de nouvelle tentative ultérieure ou au prochain tour utilisateur.
|
||||
- **Chemin rapide :** les messages uniquement composés de commandes provenant d’expéditeurs sur liste d’autorisation sont traités immédiatement (contournent la file + le modèle).
|
||||
- **Blocage par mention de groupe :** les messages uniquement composés de commandes provenant d’expéditeurs sur liste d’autorisation contournent les exigences de mention.
|
||||
- **Raccourcis en ligne (expéditeurs sur liste d’autorisation uniquement) :** certaines commandes fonctionnent aussi lorsqu’elles sont intégrées dans un message normal et sont supprimées avant que le modèle ne voie le texte restant.
|
||||
- Exemple : `hey /status` déclenche une réponse d’état, et le texte restant continue via le flux normal.
|
||||
- Actuellement : `/help`, `/commands`, `/status`, `/whoami` (`/id`).
|
||||
- Les messages ne contenant que des commandes non autorisés sont ignorés silencieusement, et les jetons inline `/...` sont traités comme du texte brut.
|
||||
- **Commandes de skill :** les skills `user-invocable` sont exposées comme commandes slash. Les noms sont normalisés en `a-z0-9_` (32 caractères max) ; les collisions reçoivent des suffixes numériques (par ex. `_2`).
|
||||
- `/skill <name> [input]` exécute une skill par nom (utile lorsque les limites de commandes natives empêchent d'avoir une commande par skill).
|
||||
- Par défaut, les commandes de skill sont transmises au modèle comme une requête normale.
|
||||
- Les skills peuvent déclarer facultativement `command-dispatch: tool` pour router directement la commande vers un outil (déterministe, sans modèle).
|
||||
- Les messages uniquement composés de commandes non autorisés sont ignorés silencieusement, et les jetons `/...` en ligne sont traités comme du texte brut.
|
||||
- **Commandes de skills :** les skills `user-invocable` sont exposées comme commandes slash. Les noms sont assainis en `a-z0-9_` (32 caractères max) ; les collisions reçoivent des suffixes numériques (par ex. `_2`).
|
||||
- `/skill <name> [input]` exécute une skill par son nom (utile lorsque les limites de commandes natives empêchent les commandes par skill).
|
||||
- Par défaut, les commandes de skills sont transmises au modèle comme une requête normale.
|
||||
- Les skills peuvent déclarer facultativement `command-dispatch: tool` pour acheminer directement la commande vers un outil (déterministe, sans modèle).
|
||||
- Exemple : `/prose` (plugin OpenProse) — voir [OpenProse](/fr/prose).
|
||||
- **Arguments des commandes natives :** Discord utilise l'autocomplétion pour les options dynamiques (et des menus à boutons lorsque vous omettez des arguments obligatoires). Telegram et Slack affichent un menu à boutons lorsqu'une commande prend en charge des choix et que vous omettez l'argument.
|
||||
- **Arguments de commandes natives :** Discord utilise l’autocomplétion pour les options dynamiques (et des menus à boutons lorsque vous omettez des arguments requis). Telegram et Slack affichent un menu à boutons lorsqu’une commande prend en charge des choix et que vous omettez l’argument.
|
||||
|
||||
## `/tools`
|
||||
|
||||
`/tools` répond à une question d'exécution, pas à une question de configuration : **ce que cet agent peut utiliser maintenant dans
|
||||
cette conversation**.
|
||||
`/tools` répond à une question d’exécution, pas à une question de configuration : **ce que cet agent peut utiliser à cet instant
|
||||
dans cette conversation**.
|
||||
|
||||
- Par défaut, `/tools` est compact et optimisé pour un balayage rapide.
|
||||
- La commande `/tools` par défaut est compacte et optimisée pour un balayage rapide.
|
||||
- `/tools verbose` ajoute de courtes descriptions.
|
||||
- Les surfaces à commandes natives qui prennent en charge les arguments exposent le même changement de mode `compact|verbose`.
|
||||
- Les résultats sont limités à la session ; ainsi, changer d'agent, de canal, de fil, d'autorisation d'expéditeur ou de modèle peut
|
||||
- Les surfaces de commandes natives qui prennent en charge les arguments exposent le même changement de mode via `compact|verbose`.
|
||||
- Les résultats sont limités à la session ; changer d’agent, de canal, de fil, d’autorisation de l’expéditeur ou de modèle peut donc
|
||||
modifier la sortie.
|
||||
- `/tools` inclut les outils réellement accessibles à l'exécution, y compris les outils du cœur, les outils de plugins
|
||||
connectés et les outils appartenant aux canaux.
|
||||
- `/tools` inclut les outils réellement accessibles à l’exécution, y compris les outils du cœur, les outils de plugins
|
||||
connectés et les outils détenus par le canal.
|
||||
|
||||
Pour modifier les profils et les remplacements, utilisez le panneau Tools de l'interface de contrôle ou les surfaces de configuration/catalogue plutôt
|
||||
que de traiter `/tools` comme un catalogue statique.
|
||||
Pour modifier les profils et les remplacements, utilisez le panneau Tools de la Control UI ou les surfaces de configuration/catalogue au lieu
|
||||
de traiter `/tools` comme un catalogue statique.
|
||||
|
||||
## Surfaces d'utilisation (ce qui s'affiche où)
|
||||
## Surfaces d’utilisation (ce qui s’affiche où)
|
||||
|
||||
- **Utilisation/quota du fournisseur** (exemple : « Claude 80% left ») s'affiche dans `/status` pour le fournisseur de modèle actuel lorsque le suivi d'utilisation est activé. OpenClaw normalise les fenêtres des fournisseurs en `% left` ; pour MiniMax, les champs de pourcentage « restant uniquement » sont inversés avant affichage, et les réponses `model_remains` privilégient l'entrée du modèle de chat plus un libellé de plan marqué par le modèle.
|
||||
- **Lignes tokens/cache** dans `/status` peuvent se rabattre sur la dernière entrée d'utilisation du transcript lorsque l'instantané de session en direct est peu rempli. Les valeurs en direct non nulles existantes restent prioritaires, et ce repli sur le transcript peut aussi récupérer l'étiquette du modèle d'exécution actif ainsi qu'un total plus important orienté prompt lorsque les totaux stockés sont absents ou plus faibles.
|
||||
- **Tokens/coût par réponse** est contrôlé par `/usage off|tokens|full` (ajouté aux réponses normales).
|
||||
- `/model status` concerne les **modèles/authentification/endpoints**, pas l'utilisation.
|
||||
- **Utilisation/quota du fournisseur** (exemple : « Claude 80 % restants ») apparaît dans `/status` pour le fournisseur du modèle actuel lorsque le suivi d’utilisation est activé. OpenClaw normalise les fenêtres des fournisseurs en `% restants` ; pour MiniMax, les champs de pourcentage restants uniquement sont inversés avant l’affichage, et les réponses `model_remains` privilégient l’entrée du modèle de chat avec une étiquette de forfait marquée par le modèle.
|
||||
- **Lignes de jetons/cache** dans `/status` peuvent revenir à la dernière entrée d’utilisation de la transcription lorsque l’instantané de session en direct est incomplet. Les valeurs en direct non nulles existantes restent prioritaires, et ce repli sur la transcription peut aussi récupérer l’étiquette du modèle d’exécution actif ainsi qu’un total orienté prompt plus élevé lorsque les totaux stockés sont absents ou plus faibles.
|
||||
- **Jetons/coût par réponse** est contrôlé par `/usage off|tokens|full` (ajouté aux réponses normales).
|
||||
- `/model status` concerne les **modèles/l’authentification/les points de terminaison**, pas l’utilisation.
|
||||
|
||||
## Sélection du modèle (`/model`)
|
||||
|
||||
@ -213,13 +251,13 @@ Exemples :
|
||||
Remarques :
|
||||
|
||||
- `/model` et `/model list` affichent un sélecteur compact numéroté (famille de modèles + fournisseurs disponibles).
|
||||
- Sur Discord, `/model` et `/models` ouvrent un sélecteur interactif avec des menus déroulants pour le fournisseur et le modèle, puis une étape Submit.
|
||||
- `/model <#>` sélectionne depuis ce sélecteur (et privilégie le fournisseur actuel quand c'est possible).
|
||||
- `/model status` affiche la vue détaillée, y compris l'endpoint du fournisseur configuré (`baseUrl`) et le mode API (`api`) lorsque disponibles.
|
||||
- Sur Discord, `/model` et `/models` ouvrent un sélecteur interactif avec listes déroulantes de fournisseur et de modèle ainsi qu’une étape Submit.
|
||||
- `/model <#>` sélectionne depuis ce sélecteur (et privilégie le fournisseur actuel lorsque c’est possible).
|
||||
- `/model status` affiche la vue détaillée, y compris le point de terminaison configuré du fournisseur (`baseUrl`) et le mode API (`api`) lorsque disponibles.
|
||||
|
||||
## Remplacements de débogage
|
||||
|
||||
`/debug` vous permet de définir des remplacements de configuration **à l'exécution uniquement** (en mémoire, pas sur disque). Propriétaire uniquement. Désactivé par défaut ; activez-le avec `commands.debug: true`.
|
||||
`/debug` vous permet de définir des remplacements de configuration **uniquement à l’exécution** (en mémoire, pas sur disque). Réservé au propriétaire. Désactivé par défaut ; activez-le avec `commands.debug: true`.
|
||||
|
||||
Exemples :
|
||||
|
||||
@ -233,12 +271,12 @@ Exemples :
|
||||
|
||||
Remarques :
|
||||
|
||||
- Les remplacements s'appliquent immédiatement aux nouvelles lectures de configuration, mais n'écrivent **pas** dans `openclaw.json`.
|
||||
- Les remplacements s’appliquent immédiatement aux nouvelles lectures de configuration, mais n’écrivent **pas** dans `openclaw.json`.
|
||||
- Utilisez `/debug reset` pour effacer tous les remplacements et revenir à la configuration sur disque.
|
||||
|
||||
## Mises à jour de configuration
|
||||
|
||||
`/config` écrit dans votre configuration sur disque (`openclaw.json`). Propriétaire uniquement. Désactivé par défaut ; activez-le avec `commands.config: true`.
|
||||
`/config` écrit dans votre configuration sur disque (`openclaw.json`). Réservé au propriétaire. Désactivé par défaut ; activez-le avec `commands.config: true`.
|
||||
|
||||
Exemples :
|
||||
|
||||
@ -252,12 +290,12 @@ Exemples :
|
||||
|
||||
Remarques :
|
||||
|
||||
- La configuration est validée avant l'écriture ; les modifications invalides sont rejetées.
|
||||
- Les mises à jour `/config` persistent après les redémarrages.
|
||||
- La configuration est validée avant écriture ; les modifications invalides sont rejetées.
|
||||
- Les mises à jour `/config` persistent après redémarrage.
|
||||
|
||||
## Mises à jour MCP
|
||||
|
||||
`/mcp` écrit les définitions de serveurs MCP gérées par OpenClaw sous `mcp.servers`. Propriétaire uniquement. Désactivé par défaut ; activez-le avec `commands.mcp: true`.
|
||||
`/mcp` écrit les définitions de serveur MCP gérées par OpenClaw sous `mcp.servers`. Réservé au propriétaire. Désactivé par défaut ; activez-le avec `commands.mcp: true`.
|
||||
|
||||
Exemples :
|
||||
|
||||
@ -270,12 +308,12 @@ Exemples :
|
||||
|
||||
Remarques :
|
||||
|
||||
- `/mcp` stocke la configuration dans la configuration OpenClaw, et non dans les paramètres de projet appartenant à Pi.
|
||||
- Les adaptateurs d'exécution déterminent quels transports sont réellement exécutables.
|
||||
- `/mcp` stocke la configuration dans la configuration OpenClaw, et non dans les paramètres de projet détenus par Pi.
|
||||
- Les adaptateurs d’exécution décident quels transports sont réellement exécutables.
|
||||
|
||||
## Mises à jour des plugins
|
||||
## Mises à jour de plugins
|
||||
|
||||
`/plugins` permet aux opérateurs d'inspecter les plugins découverts et de basculer leur activation dans la configuration. Les flux en lecture seule peuvent utiliser `/plugin` comme alias. Désactivé par défaut ; activez-le avec `commands.plugins: true`.
|
||||
`/plugins` permet aux opérateurs d’inspecter les plugins découverts et d’activer/désactiver leur statut dans la configuration. Les flux en lecture seule peuvent utiliser `/plugin` comme alias. Désactivé par défaut ; activez-le avec `commands.plugins: true`.
|
||||
|
||||
Exemples :
|
||||
|
||||
@ -289,32 +327,32 @@ Exemples :
|
||||
|
||||
Remarques :
|
||||
|
||||
- `/plugins list` et `/plugins show` utilisent la vraie découverte de plugins sur l'espace de travail actuel ainsi que la configuration sur disque.
|
||||
- `/plugins enable|disable` met à jour uniquement la configuration des plugins ; il n'installe ni ne désinstalle les plugins.
|
||||
- Après des changements d'activation/désactivation, redémarrez la passerelle pour les appliquer.
|
||||
- `/plugins list` et `/plugins show` utilisent la découverte réelle des plugins par rapport à l’espace de travail actuel et à la configuration sur disque.
|
||||
- `/plugins enable|disable` met à jour uniquement la configuration du plugin ; cela n’installe ni ne désinstalle les plugins.
|
||||
- Après des modifications d’activation/désactivation, redémarrez la gateway pour les appliquer.
|
||||
|
||||
## Remarques sur les surfaces
|
||||
|
||||
- **Les commandes texte** s'exécutent dans la session de chat normale (les messages privés partagent `main`, les groupes ont leur propre session).
|
||||
- **Les commandes natives** utilisent des sessions isolées :
|
||||
- **Commandes texte** s’exécutent dans la session de chat normale (les DM partagent `main`, les groupes ont leur propre session).
|
||||
- **Commandes natives** utilisent des sessions isolées :
|
||||
- Discord : `agent:<agentId>:discord:slash:<userId>`
|
||||
- Slack : `agent:<agentId>:slack:slash:<userId>` (préfixe configurable via `channels.slack.slashCommand.sessionPrefix`)
|
||||
- Telegram : `telegram:slash:<userId>` (cible la session de chat via `CommandTargetSessionKey`)
|
||||
- **`/stop`** cible la session de chat active afin de pouvoir interrompre l'exécution en cours.
|
||||
- **Slack :** `channels.slack.slashCommand` reste pris en charge pour une seule commande de type `/openclaw`. Si vous activez `commands.native`, vous devez créer une commande slash Slack par commande intégrée (mêmes noms que `/help`). Les menus d'arguments de commande pour Slack sont fournis sous forme de boutons Block Kit éphémères.
|
||||
- Exception native Slack : enregistrez `/agentstatus` (pas `/status`) car Slack réserve `/status`. La commande texte `/status` fonctionne toujours dans les messages Slack.
|
||||
- Telegram : `telegram:slash:<userId>` (cible la session du chat via `CommandTargetSessionKey`)
|
||||
- **`/stop`** cible la session de chat active afin de pouvoir interrompre l’exécution en cours.
|
||||
- **Slack :** `channels.slack.slashCommand` reste pris en charge pour une commande unique de type `/openclaw`. Si vous activez `commands.native`, vous devez créer une commande slash Slack par commande intégrée (mêmes noms que `/help`). Les menus d’arguments de commande pour Slack sont fournis sous forme de boutons Block Kit éphémères.
|
||||
- Exception native Slack : enregistrez `/agentstatus` (et non `/status`) car Slack réserve `/status`. La commande texte `/status` fonctionne toujours dans les messages Slack.
|
||||
|
||||
## Questions latérales BTW
|
||||
## Questions annexes BTW
|
||||
|
||||
`/btw` est une **question latérale** rapide à propos de la session actuelle.
|
||||
`/btw` est une **question annexe** rapide à propos de la session en cours.
|
||||
|
||||
Contrairement au chat normal :
|
||||
Contrairement à un chat normal :
|
||||
|
||||
- il utilise la session actuelle comme contexte de fond,
|
||||
- il s'exécute comme un appel ponctuel séparé **sans outils**,
|
||||
- il ne modifie pas le contexte futur de la session,
|
||||
- il n'est pas écrit dans l'historique du transcript,
|
||||
- il est livré comme un résultat latéral en direct plutôt que comme un message assistant normal.
|
||||
- elle utilise la session actuelle comme contexte de fond,
|
||||
- elle s’exécute comme un appel ponctuel distinct **sans outil**,
|
||||
- elle ne modifie pas le contexte futur de la session,
|
||||
- elle n’est pas écrite dans l’historique de la transcription,
|
||||
- elle est fournie comme résultat annexe en direct au lieu d’un message assistant normal.
|
||||
|
||||
Cela rend `/btw` utile lorsque vous voulez une clarification temporaire pendant que la
|
||||
tâche principale continue.
|
||||
@ -322,8 +360,8 @@ tâche principale continue.
|
||||
Exemple :
|
||||
|
||||
```text
|
||||
/btw what are we doing right now?
|
||||
/btw qu’est-ce qu’on fait en ce moment ?
|
||||
```
|
||||
|
||||
Consultez [BTW Side Questions](/fr/tools/btw) pour le comportement complet et les détails
|
||||
de l'expérience client.
|
||||
Voir [Questions annexes BTW](/fr/tools/btw) pour le comportement complet et les
|
||||
détails UX côté client.
|
||||
|
||||
@ -1,22 +1,22 @@
|
||||
---
|
||||
read_when:
|
||||
- Activation de la synthèse vocale pour les réponses
|
||||
- Configuration des fournisseurs TTS ou des limites
|
||||
- Utilisation des commandes /tts
|
||||
- Activer la synthèse vocale pour les réponses
|
||||
- Configurer les fournisseurs TTS ou les limites
|
||||
- Utiliser les commandes /tts
|
||||
summary: Synthèse vocale (TTS) pour les réponses sortantes
|
||||
title: Synthèse vocale
|
||||
x-i18n:
|
||||
generated_at: "2026-04-05T12:58:15Z"
|
||||
generated_at: "2026-04-08T06:01:59Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 8487c8acef7585bd4eb5e3b39e2a063ebc6b5f0103524abdcbadd3a7781ffc46
|
||||
source_hash: 6e0fbcaf61282733c134f682e05a71f94d2169c03a85131ce9ad233c71a1e533
|
||||
source_path: tools/tts.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Synthèse vocale (TTS)
|
||||
|
||||
OpenClaw peut convertir les réponses sortantes en audio à l’aide de ElevenLabs, Microsoft, MiniMax ou OpenAI.
|
||||
OpenClaw peut convertir les réponses sortantes en audio avec ElevenLabs, Microsoft, MiniMax ou OpenAI.
|
||||
Cela fonctionne partout où OpenClaw peut envoyer de l’audio.
|
||||
|
||||
## Services pris en charge
|
||||
@ -26,22 +26,22 @@ Cela fonctionne partout où OpenClaw peut envoyer de l’audio.
|
||||
- **MiniMax** (fournisseur principal ou de secours ; utilise l’API T2A v2)
|
||||
- **OpenAI** (fournisseur principal ou de secours ; également utilisé pour les résumés)
|
||||
|
||||
### Notes sur la synthèse vocale Microsoft
|
||||
### Remarques sur la synthèse vocale Microsoft
|
||||
|
||||
Le fournisseur de synthèse vocale Microsoft groupé utilise actuellement le service
|
||||
TTS neuronal en ligne de Microsoft Edge via la bibliothèque `node-edge-tts`. Il s’agit d’un service hébergé (non
|
||||
local), qui utilise des endpoints Microsoft et ne nécessite pas de clé API.
|
||||
`node-edge-tts` expose des options de configuration vocale et des formats de sortie, mais
|
||||
local), qui utilise les points de terminaison Microsoft et ne nécessite pas de clé API.
|
||||
`node-edge-tts` expose des options de configuration de la parole et des formats de sortie, mais
|
||||
toutes les options ne sont pas prises en charge par le service. La configuration héritée et les entrées de directive
|
||||
utilisant `edge` continuent de fonctionner et sont normalisées vers `microsoft`.
|
||||
utilisant `edge` fonctionnent toujours et sont normalisées en `microsoft`.
|
||||
|
||||
Comme ce chemin repose sur un service web public sans SLA ni quota publiés,
|
||||
considérez-le comme un effort au mieux. Si vous avez besoin de limites garanties et d’assistance, utilisez OpenAI
|
||||
considérez-le comme du meilleur effort. Si vous avez besoin de limites garanties et d’un support, utilisez OpenAI
|
||||
ou ElevenLabs.
|
||||
|
||||
## Clés facultatives
|
||||
|
||||
Si vous voulez utiliser OpenAI, ElevenLabs ou MiniMax :
|
||||
Si vous voulez OpenAI, ElevenLabs ou MiniMax :
|
||||
|
||||
- `ELEVENLABS_API_KEY` (ou `XI_API_KEY`)
|
||||
- `MINIMAX_API_KEY`
|
||||
@ -49,11 +49,11 @@ Si vous voulez utiliser OpenAI, ElevenLabs ou MiniMax :
|
||||
|
||||
La synthèse vocale Microsoft ne nécessite **pas** de clé API.
|
||||
|
||||
Si plusieurs fournisseurs sont configurés, le fournisseur sélectionné est utilisé en premier et les autres servent de solution de secours.
|
||||
Si plusieurs fournisseurs sont configurés, le fournisseur sélectionné est utilisé en premier et les autres servent de solutions de secours.
|
||||
Le résumé automatique utilise le `summaryModel` configuré (ou `agents.defaults.model.primary`),
|
||||
donc ce fournisseur doit également être authentifié si vous activez les résumés.
|
||||
|
||||
## Liens de service
|
||||
## Liens vers les services
|
||||
|
||||
- [Guide OpenAI Text-to-Speech](https://platform.openai.com/docs/guides/text-to-speech)
|
||||
- [Référence de l’API Audio OpenAI](https://platform.openai.com/docs/api-reference/audio)
|
||||
@ -66,15 +66,15 @@ donc ce fournisseur doit également être authentifié si vous activez les résu
|
||||
## Est-ce activé par défaut ?
|
||||
|
||||
Non. L’auto‑TTS est **désactivé** par défaut. Activez-le dans la configuration avec
|
||||
`messages.tts.auto` ou par session avec `/tts always` (alias : `/tts on`).
|
||||
`messages.tts.auto` ou localement avec `/tts on`.
|
||||
|
||||
Lorsque `messages.tts.provider` n’est pas défini, OpenClaw choisit le premier
|
||||
fournisseur vocal configuré selon l’ordre de sélection automatique du registre.
|
||||
fournisseur de synthèse vocale configuré selon l’ordre d’auto-sélection du registre.
|
||||
|
||||
## Configuration
|
||||
|
||||
La configuration TTS se trouve sous `messages.tts` dans `openclaw.json`.
|
||||
Le schéma complet se trouve dans [Configuration de la gateway](/fr/gateway/configuration).
|
||||
Le schéma complet se trouve dans [Configuration de la passerelle](/fr/gateway/configuration).
|
||||
|
||||
### Configuration minimale (activation + fournisseur)
|
||||
|
||||
@ -232,56 +232,56 @@ Le schéma complet se trouve dans [Configuration de la gateway](/fr/gateway/conf
|
||||
}
|
||||
```
|
||||
|
||||
Puis exécutez :
|
||||
Ensuite, exécutez :
|
||||
|
||||
```
|
||||
/tts summary off
|
||||
```
|
||||
|
||||
### Notes sur les champs
|
||||
### Remarques sur les champs
|
||||
|
||||
- `auto` : mode auto‑TTS (`off`, `always`, `inbound`, `tagged`).
|
||||
- `inbound` n’envoie de l’audio qu’après un message vocal entrant.
|
||||
- `tagged` n’envoie de l’audio que lorsque la réponse inclut des balises `[[tts]]`.
|
||||
- `inbound` envoie de l’audio uniquement après un message vocal entrant.
|
||||
- `tagged` envoie de l’audio uniquement lorsque la réponse inclut des balises `[[tts]]`.
|
||||
- `enabled` : bascule héritée (doctor la migre vers `auto`).
|
||||
- `mode` : `"final"` (par défaut) ou `"all"` (inclut les réponses d’outils/blocs).
|
||||
- `provider` : id du fournisseur vocal tel que `"elevenlabs"`, `"microsoft"`, `"minimax"` ou `"openai"` (la solution de secours est automatique).
|
||||
- Si `provider` n’est **pas défini**, OpenClaw utilise le premier fournisseur vocal configuré selon l’ordre de sélection automatique du registre.
|
||||
- L’ancien `provider: "edge"` fonctionne toujours et est normalisé vers `microsoft`.
|
||||
- `summaryModel` : modèle économique facultatif pour le résumé automatique ; la valeur par défaut est `agents.defaults.model.primary`.
|
||||
- `mode` : `"final"` (par défaut) ou `"all"` (inclut les réponses d’outil/par blocs).
|
||||
- `provider` : identifiant du fournisseur vocal tel que `"elevenlabs"`, `"microsoft"`, `"minimax"` ou `"openai"` (le basculement en secours est automatique).
|
||||
- Si `provider` n’est **pas défini**, OpenClaw utilise le premier fournisseur vocal configuré selon l’ordre d’auto-sélection du registre.
|
||||
- L’ancien `provider: "edge"` fonctionne toujours et est normalisé en `microsoft`.
|
||||
- `summaryModel` : modèle économique facultatif pour le résumé automatique ; par défaut `agents.defaults.model.primary`.
|
||||
- Accepte `provider/model` ou un alias de modèle configuré.
|
||||
- `modelOverrides` : autoriser le modèle à émettre des directives TTS (activé par défaut).
|
||||
- `allowProvider` vaut par défaut `false` (le changement de fournisseur se fait par adhésion explicite).
|
||||
- `providers.<id>` : paramètres détenus par le fournisseur, indexés par id de fournisseur vocal.
|
||||
- Les anciens blocs de fournisseur directs (`messages.tts.openai`, `messages.tts.elevenlabs`, `messages.tts.microsoft`, `messages.tts.edge`) sont automatiquement migrés vers `messages.tts.providers.<id>` au chargement.
|
||||
- `maxTextLength` : limite stricte pour l’entrée TTS (caractères). `/tts audio` échoue si elle est dépassée.
|
||||
- `modelOverrides` : permet au modèle d’émettre des directives TTS (activé par défaut).
|
||||
- `allowProvider` vaut `false` par défaut (le changement de fournisseur est activé explicitement).
|
||||
- `providers.<id>` : paramètres appartenant au fournisseur, indexés par identifiant de fournisseur vocal.
|
||||
- Les blocs de fournisseur hérités directs (`messages.tts.openai`, `messages.tts.elevenlabs`, `messages.tts.microsoft`, `messages.tts.edge`) sont automatiquement migrés vers `messages.tts.providers.<id>` au chargement.
|
||||
- `maxTextLength` : limite stricte de l’entrée TTS (caractères). `/tts audio` échoue si elle est dépassée.
|
||||
- `timeoutMs` : délai d’expiration de la requête (ms).
|
||||
- `prefsPath` : remplace le chemin JSON local des préférences (fournisseur/limite/résumé).
|
||||
- Les valeurs `apiKey` reviennent aux variables d’environnement (`ELEVENLABS_API_KEY`/`XI_API_KEY`, `MINIMAX_API_KEY`, `OPENAI_API_KEY`).
|
||||
- `prefsPath` : remplace le chemin du JSON local des préférences (fournisseur/limite/résumé).
|
||||
- Les valeurs `apiKey` se replient sur les variables d’environnement (`ELEVENLABS_API_KEY`/`XI_API_KEY`, `MINIMAX_API_KEY`, `OPENAI_API_KEY`).
|
||||
- `providers.elevenlabs.baseUrl` : remplace l’URL de base de l’API ElevenLabs.
|
||||
- `providers.openai.baseUrl` : remplace l’endpoint TTS OpenAI.
|
||||
- `providers.openai.baseUrl` : remplace le point de terminaison TTS OpenAI.
|
||||
- Ordre de résolution : `messages.tts.providers.openai.baseUrl` -> `OPENAI_TTS_BASE_URL` -> `https://api.openai.com/v1`
|
||||
- Les valeurs non par défaut sont traitées comme des endpoints TTS compatibles OpenAI, donc les noms personnalisés de modèle et de voix sont acceptés.
|
||||
- Les valeurs non par défaut sont traitées comme des points de terminaison TTS compatibles OpenAI ; les noms de modèle et de voix personnalisés sont donc acceptés.
|
||||
- `providers.elevenlabs.voiceSettings` :
|
||||
- `stability`, `similarityBoost`, `style` : `0..1`
|
||||
- `useSpeakerBoost` : `true|false`
|
||||
- `speed` : `0.5..2.0` (`1.0` = normal)
|
||||
- `speed` : `0.5..2.0` (1.0 = normal)
|
||||
- `providers.elevenlabs.applyTextNormalization` : `auto|on|off`
|
||||
- `providers.elevenlabs.languageCode` : ISO 639-1 à 2 lettres (par exemple `en`, `de`)
|
||||
- `providers.elevenlabs.seed` : entier `0..4294967295` (déterminisme au mieux)
|
||||
- `providers.elevenlabs.languageCode` : ISO 639-1 à 2 lettres (par ex. `en`, `de`)
|
||||
- `providers.elevenlabs.seed` : entier `0..4294967295` (déterminisme meilleur effort)
|
||||
- `providers.minimax.baseUrl` : remplace l’URL de base de l’API MiniMax (par défaut `https://api.minimax.io`, env : `MINIMAX_API_HOST`).
|
||||
- `providers.minimax.model` : modèle TTS (par défaut `speech-2.8-hd`, env : `MINIMAX_TTS_MODEL`).
|
||||
- `providers.minimax.voiceId` : identifiant de voix (par défaut `English_expressive_narrator`, env : `MINIMAX_TTS_VOICE_ID`).
|
||||
- `providers.minimax.speed` : vitesse de lecture `0.5..2.0` (par défaut 1.0).
|
||||
- `providers.minimax.vol` : volume `(0, 10]` (par défaut 1.0 ; doit être supérieur à 0).
|
||||
- `providers.minimax.pitch` : décalage de hauteur `-12..12` (par défaut 0).
|
||||
- `providers.microsoft.enabled` : autoriser l’utilisation de la synthèse vocale Microsoft (par défaut `true` ; pas de clé API).
|
||||
- `providers.microsoft.voice` : nom de voix neurale Microsoft (par exemple `en-US-MichelleNeural`).
|
||||
- `providers.microsoft.lang` : code langue (par exemple `en-US`).
|
||||
- `providers.microsoft.outputFormat` : format de sortie Microsoft (par exemple `audio-24khz-48kbitrate-mono-mp3`).
|
||||
- Voir les formats de sortie Microsoft Speech pour les valeurs valides ; tous les formats ne sont pas pris en charge par le transport groupé adossé à Edge.
|
||||
- `providers.microsoft.rate` / `providers.microsoft.pitch` / `providers.microsoft.volume` : chaînes de pourcentage (par exemple `+10%`, `-5%`).
|
||||
- `providers.microsoft.saveSubtitles` : écrire des sous-titres JSON à côté du fichier audio.
|
||||
- `providers.microsoft.enabled` : autorise l’utilisation de la synthèse vocale Microsoft (par défaut `true` ; sans clé API).
|
||||
- `providers.microsoft.voice` : nom de voix neuronale Microsoft (par ex. `en-US-MichelleNeural`).
|
||||
- `providers.microsoft.lang` : code de langue (par ex. `en-US`).
|
||||
- `providers.microsoft.outputFormat` : format de sortie Microsoft (par ex. `audio-24khz-48kbitrate-mono-mp3`).
|
||||
- Consultez les formats de sortie Microsoft Speech pour connaître les valeurs valides ; tous les formats ne sont pas pris en charge par le transport groupé basé sur Edge.
|
||||
- `providers.microsoft.rate` / `providers.microsoft.pitch` / `providers.microsoft.volume` : chaînes de pourcentage (par ex. `+10%`, `-5%`).
|
||||
- `providers.microsoft.saveSubtitles` : écrit des sous-titres JSON à côté du fichier audio.
|
||||
- `providers.microsoft.proxy` : URL de proxy pour les requêtes de synthèse vocale Microsoft.
|
||||
- `providers.microsoft.timeoutMs` : remplacement du délai d’expiration de la requête (ms).
|
||||
- `edge.*` : alias hérité pour les mêmes paramètres Microsoft.
|
||||
@ -289,16 +289,16 @@ Puis exécutez :
|
||||
## Remplacements pilotés par le modèle (activés par défaut)
|
||||
|
||||
Par défaut, le modèle **peut** émettre des directives TTS pour une seule réponse.
|
||||
Lorsque `messages.tts.auto` vaut `tagged`, ces directives sont nécessaires pour déclencher l’audio.
|
||||
Lorsque `messages.tts.auto` vaut `tagged`, ces directives sont requises pour déclencher l’audio.
|
||||
|
||||
Lorsqu’elle est activée, le modèle peut émettre des directives `[[tts:...]]` pour remplacer la voix
|
||||
pour une seule réponse, ainsi qu’un bloc facultatif `[[tts:text]]...[[/tts:text]]` pour
|
||||
fournir des balises expressives (rire, indications de chant, etc.) qui ne doivent apparaître que dans
|
||||
fournir des balises expressives (rires, indications de chant, etc.) qui ne doivent apparaître que dans
|
||||
l’audio.
|
||||
|
||||
Les directives `provider=...` sont ignorées sauf si `modelOverrides.allowProvider: true`.
|
||||
|
||||
Exemple de payload de réponse :
|
||||
Exemple de charge utile de réponse :
|
||||
|
||||
```
|
||||
Here you go.
|
||||
@ -309,9 +309,9 @@ Here you go.
|
||||
|
||||
Clés de directive disponibles (lorsqu’elles sont activées) :
|
||||
|
||||
- `provider` (id de fournisseur vocal enregistré, par exemple `openai`, `elevenlabs`, `minimax` ou `microsoft` ; nécessite `allowProvider: true`)
|
||||
- `provider` (identifiant de fournisseur vocal enregistré, par exemple `openai`, `elevenlabs`, `minimax` ou `microsoft` ; nécessite `allowProvider: true`)
|
||||
- `voice` (voix OpenAI) ou `voiceId` (ElevenLabs / MiniMax)
|
||||
- `model` (modèle TTS OpenAI, id de modèle ElevenLabs ou modèle MiniMax)
|
||||
- `model` (modèle TTS OpenAI, identifiant de modèle ElevenLabs ou modèle MiniMax)
|
||||
- `stability`, `similarityBoost`, `style`, `speed`, `useSpeakerBoost`
|
||||
- `vol` / `volume` (volume MiniMax, 0-10)
|
||||
- `pitch` (hauteur MiniMax, -12 à 12)
|
||||
@ -333,7 +333,7 @@ Désactiver tous les remplacements du modèle :
|
||||
}
|
||||
```
|
||||
|
||||
Liste d’autorisation facultative (activer le changement de fournisseur tout en gardant les autres réglages configurables) :
|
||||
Liste d’autorisations facultative (activer le changement de fournisseur tout en gardant les autres paramètres configurables) :
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -362,31 +362,31 @@ Champs stockés :
|
||||
- `maxLength` (seuil de résumé ; 1500 caractères par défaut)
|
||||
- `summarize` (`true` par défaut)
|
||||
|
||||
Ceux-ci remplacent `messages.tts.*` pour cet hôte.
|
||||
Ils remplacent `messages.tts.*` pour cet hôte.
|
||||
|
||||
## Formats de sortie (fixes)
|
||||
|
||||
- **Feishu / Matrix / Telegram / WhatsApp** : message vocal Opus (`opus_48000_64` provenant de ElevenLabs, `opus` provenant de OpenAI).
|
||||
- 48 kHz / 64 kb/s constitue un bon compromis pour les messages vocaux.
|
||||
- **Autres canaux** : MP3 (`mp3_44100_128` provenant de ElevenLabs, `mp3` provenant de OpenAI).
|
||||
- 44,1 kHz / 128 kb/s est l’équilibre par défaut pour la clarté de la parole.
|
||||
- **MiniMax** : MP3 (modèle `speech-2.8-hd`, fréquence d’échantillonnage 32 kHz). Le format note vocale n’est pas pris en charge nativement ; utilisez OpenAI ou ElevenLabs pour des messages vocaux Opus garantis.
|
||||
- **Feishu / Matrix / Telegram / WhatsApp** : message vocal Opus (`opus_48000_64` d’ElevenLabs, `opus` d’OpenAI).
|
||||
- 48kHz / 64kbps offre un bon compromis pour un message vocal.
|
||||
- **Autres canaux** : MP3 (`mp3_44100_128` d’ElevenLabs, `mp3` d’OpenAI).
|
||||
- 44.1kHz / 128kbps est l’équilibre par défaut pour la clarté de la parole.
|
||||
- **MiniMax** : MP3 (modèle `speech-2.8-hd`, fréquence d’échantillonnage 32kHz). Le format note vocale n’est pas pris en charge nativement ; utilisez OpenAI ou ElevenLabs pour des messages vocaux Opus garantis.
|
||||
- **Microsoft** : utilise `microsoft.outputFormat` (par défaut `audio-24khz-48kbitrate-mono-mp3`).
|
||||
- Le transport groupé accepte un `outputFormat`, mais tous les formats ne sont pas disponibles depuis le service.
|
||||
- Les valeurs de format de sortie suivent les formats de sortie Microsoft Speech (y compris Ogg/WebM Opus).
|
||||
- Telegram `sendVoice` accepte OGG/MP3/M4A ; utilisez OpenAI/ElevenLabs si vous avez besoin
|
||||
- `sendVoice` de Telegram accepte OGG/MP3/M4A ; utilisez OpenAI/ElevenLabs si vous avez besoin
|
||||
de messages vocaux Opus garantis.
|
||||
- Si le format de sortie Microsoft configuré échoue, OpenClaw réessaie avec MP3.
|
||||
|
||||
Les formats de sortie OpenAI/ElevenLabs sont fixes par canal (voir ci-dessus).
|
||||
|
||||
## Comportement de l’auto-TTS
|
||||
## Comportement auto-TTS
|
||||
|
||||
Lorsqu’il est activé, OpenClaw :
|
||||
Lorsqu’elle est activée, OpenClaw :
|
||||
|
||||
- ignore TTS si la réponse contient déjà un média ou une directive `MEDIA:`.
|
||||
- ignore la TTS si la réponse contient déjà un média ou une directive `MEDIA:`.
|
||||
- ignore les réponses très courtes (< 10 caractères).
|
||||
- résume les réponses longues lorsque cette option est activée à l’aide de `agents.defaults.model.primary` (ou `summaryModel`).
|
||||
- résume les réponses longues lorsqu’elle est activée en utilisant `agents.defaults.model.primary` (ou `summaryModel`).
|
||||
- joint l’audio généré à la réponse.
|
||||
|
||||
Si la réponse dépasse `maxLength` et que le résumé est désactivé (ou qu’il n’y a pas de clé API pour le
|
||||
@ -396,31 +396,29 @@ est ignoré et la réponse texte normale est envoyée.
|
||||
## Diagramme de flux
|
||||
|
||||
```
|
||||
Réponse -> TTS activé ?
|
||||
non -> envoyer le texte
|
||||
oui -> contient un média / MEDIA: / court ?
|
||||
oui -> envoyer le texte
|
||||
non -> longueur > limite ?
|
||||
non -> TTS -> joindre l’audio
|
||||
oui -> résumé activé ?
|
||||
non -> envoyer le texte
|
||||
oui -> résumer (summaryModel ou agents.defaults.model.primary)
|
||||
-> TTS -> joindre l’audio
|
||||
Reply -> TTS enabled?
|
||||
no -> send text
|
||||
yes -> has media / MEDIA: / short?
|
||||
yes -> send text
|
||||
no -> length > limit?
|
||||
no -> TTS -> attach audio
|
||||
yes -> summary enabled?
|
||||
no -> send text
|
||||
yes -> summarize (summaryModel or agents.defaults.model.primary)
|
||||
-> TTS -> attach audio
|
||||
```
|
||||
|
||||
## Utilisation des commandes slash
|
||||
## Utilisation de la commande slash
|
||||
|
||||
Il existe une seule commande : `/tts`.
|
||||
Voir [Commandes slash](/tools/slash-commands) pour les détails d’activation.
|
||||
Voir [Commandes slash](/fr/tools/slash-commands) pour les détails d’activation.
|
||||
|
||||
Note Discord : `/tts` est une commande Discord intégrée, donc OpenClaw enregistre
|
||||
Remarque Discord : `/tts` est une commande Discord intégrée, donc OpenClaw enregistre
|
||||
`/voice` comme commande native à cet endroit. Le texte `/tts ...` fonctionne toujours.
|
||||
|
||||
```
|
||||
/tts off
|
||||
/tts always
|
||||
/tts inbound
|
||||
/tts tagged
|
||||
/tts on
|
||||
/tts status
|
||||
/tts provider openai
|
||||
/tts limit 2000
|
||||
@ -428,28 +426,30 @@ Note Discord : `/tts` est une commande Discord intégrée, donc OpenClaw enregis
|
||||
/tts audio Hello from OpenClaw
|
||||
```
|
||||
|
||||
Notes :
|
||||
Remarques :
|
||||
|
||||
- Les commandes nécessitent un expéditeur autorisé (les règles de liste d’autorisation/propriétaire s’appliquent toujours).
|
||||
- `commands.text` ou l’enregistrement de commandes natives doit être activé.
|
||||
- `off|always|inbound|tagged` sont des bascules par session (`/tts on` est un alias pour `/tts always`).
|
||||
- La configuration `messages.tts.auto` accepte `off|always|inbound|tagged`.
|
||||
- `/tts on` écrit la préférence TTS locale sur `always` ; `/tts off` l’écrit sur `off`.
|
||||
- Utilisez la configuration si vous voulez des valeurs par défaut `inbound` ou `tagged`.
|
||||
- `limit` et `summary` sont stockés dans les préférences locales, pas dans la configuration principale.
|
||||
- `/tts audio` génère une réponse audio ponctuelle (n’active pas TTS).
|
||||
- `/tts status` inclut la visibilité de secours pour la dernière tentative :
|
||||
- `/tts audio` génère une réponse audio ponctuelle (cela n’active pas la TTS).
|
||||
- `/tts status` inclut la visibilité du secours pour la dernière tentative :
|
||||
- secours réussi : `Fallback: <primary> -> <used>` plus `Attempts: ...`
|
||||
- échec : `Error: ...` plus `Attempts: ...`
|
||||
- diagnostics détaillés : `Attempt details: provider:outcome(reasonCode) latency`
|
||||
- Les échecs d’API OpenAI et ElevenLabs incluent désormais le détail d’erreur analysé du fournisseur et l’id de requête (lorsqu’il est renvoyé par le fournisseur), qui apparaissent dans les erreurs/journaux TTS.
|
||||
- Les échecs d’API OpenAI et ElevenLabs incluent désormais les détails d’erreur du fournisseur analysés et l’identifiant de requête (lorsqu’il est renvoyé par le fournisseur), qui apparaissent dans les erreurs/journaux TTS.
|
||||
|
||||
## Outil d’agent
|
||||
|
||||
L’outil `tts` convertit du texte en parole et renvoie une pièce jointe audio pour
|
||||
la distribution de la réponse. Lorsque le canal est Feishu, Matrix, Telegram ou WhatsApp,
|
||||
l’audio est distribué sous forme de message vocal plutôt que de pièce jointe de fichier.
|
||||
la livraison de la réponse. Lorsque le canal est Feishu, Matrix, Telegram ou WhatsApp,
|
||||
l’audio est livré comme message vocal plutôt que comme pièce jointe de fichier.
|
||||
|
||||
## RPC gateway
|
||||
## RPC Gateway
|
||||
|
||||
Méthodes de gateway :
|
||||
Méthodes Gateway :
|
||||
|
||||
- `tts.status`
|
||||
- `tts.enable`
|
||||
|
||||
Loading…
Reference in New Issue
Block a user