Les channels et ce que sait chaque agent

De quoi s'agit-il ?

Un channel est une conversation de l'utilisateur avec plusieurs agents à la fois : poser une question à Alice, puis demander à Bob son avis sur la réponse d'Alice. L'Agent Client Protocol ne connaît pas cette situation. Il relie un client à un agent, dans des sessions où ils ne parlent qu'à deux. Tout ce qui fait un channel — qui répond, qui sait ce qui a été dit — est décidé par Sidekicks. Cette page explique ces choix ; les règles exactes sont dans la référence, les décisions dans l'ADR 0006 (en anglais).

Une session par agent et par channel

Chaque agent d'un channel a sa propre session ACP pour ce channel. Alice dans #general et Alice dans #translations sont deux sessions du même processus : ce qui est dit à Alice dans un channel ne passe jamais dans l'autre.

Une session ne contient que ce qui s'y est dit. Quand on interroge Bob après une réponse d'Alice, la session de Bob ne sait rien de cette réponse. Avant le tour de Bob, Sidekicks ajoute donc à son prompt ce que Bob n'a pas vu : les messages de l'utilisateur aux autres et les réponses des autres agents, depuis le dernier tour de Bob. L'agent lit une courte transcription, puis le message de l'utilisateur. L'agent garde sa propre session — et le souvenir de ses propres réponses — tout en suivant le channel.

L'alternative, une session commune lue par tous les agents, n'existe pas dans ACP : une session appartient à un agent. Renvoyer tout le channel à chaque tour remplirait en quelques échanges les petites fenêtres de contexte des modèles locaux. N'envoyer que la nouveauté est la façon la plus économe de rester à jour ; la transcription est limitée aux 20 derniers messages, chacun raccourci, pour qu'un long channel n'étouffe pas la question.

Qui répond, et pourquoi un seul à la fois

Un message va aux agents qu'il mentionne, dans l'ordre ; sans mention, au dernier agent qui a parlé. C'est ainsi qu'on parle en groupe : on nomme quelqu'un, ou on continue avec la personne à qui l'on parlait. Personne ne répond à un message qui ne nomme personne dans un channel où plusieurs agents n'ont pas encore parlé — deviner surprendrait davantage l'utilisateur que lui demander de choisir.

Les agents répondent l'un après l'autre, jamais en même temps. Sur un portable, deux modèles locaux qui génèrent ensemble sont chacun plus lents qu'à tour de rôle, et la mémoire est la vraie limite (deux petits modèles sur la machine de référence). Répondre à tour de rôle permet aussi au second agent de lire la réponse du premier : « @alice @bob comparez » donne à Bob la réponse d'Alice à comparer. Pour la même raison, un agent répond à un seul channel à la fois : un second channel attend, et indique à qui c'est le tour.

Les commandes partent seules

/idioms Il pleut des cordes demande à Garfield d'exécuter une skill. L'agent reconnaît une commande à son premier caractère. Si la transcription du channel la précédait, la commande n'en serait plus une. Un message qui commence par / est donc envoyé tel quel, sans contexte, et /garfield:idioms … choisit l'agent quand le channel en compte plusieurs. Un agent annonce ses commandes dès qu'une session s'ouvre, avant toute question — et mm le fait sans charger son modèle. Le premier / tapé dans une conversation démarre donc les membres qui n'ont jamais annoncé les leurs et ouvre leur session (celle que servira leur première réponse) ; la liste se remplit en une fraction de seconde. Sidekicks garde ensuite les commandes et les propose aussitôt les fois suivantes.

Après un redémarrage

L'historique est dans une base à côté de la configuration (une par fichier de configuration) : les channels sont de nouveau là après un redémarrage. Les agents, eux, sont de nouveaux processus : leurs sessions ont disparu. ACP permet à un agent de reprendre une session (session/load) ; Sidekicks s'en sert quand l'agent le propose. mm ne le propose pas : Sidekicks ouvre une nouvelle session et donne à l'agent, dans son premier prompt, les derniers messages du channel — les siens compris cette fois, puisque la nouvelle session n'en contient aucun. L'utilisateur ne voit pas la différence : Alice connaît toujours son prénom.

Le même mécanisme couvre un agent arrêté pour faire de la place à un autre (deux agents au plus) : son tour suivant ouvre une nouvelle session à qui l'on raconte ce qu'elle a manqué. En milestone M2, la conversation disait « Alice a redémarré et ne se souvient plus du début » ; ce message a disparu.

Les liens avec le reste

Permissions et confiance : les cartes de permission fonctionnent de la même façon dans un channel ; la carte nomme l'agent qui demande.
Mémoire et modèles locaux : pourquoi deux agents au plus, et pourquoi les réponses se font à tour de rôle.
Architecture : internal/channels décide, internal/store se souvient, internal/agents prête les processus.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


# Les channels et ce que sait chaque agent

## De quoi s'agit-il ?

Un channel est une conversation de l'utilisateur avec plusieurs agents à la fois : poser une question à Alice, puis demander à Bob son avis sur la réponse d'Alice. L'Agent Client Protocol ne connaît pas cette situation. Il relie un client à un agent, dans des sessions où ils ne parlent qu'à deux. Tout ce qui fait un channel — qui répond, qui sait ce qui a été dit — est décidé par Sidekicks. Cette page explique ces choix ; les règles exactes sont dans la [référence](../reference/agents-et-evenements.md#channels-milestones-m2-et-m3), les décisions dans l'[ADR 0006](../../adr/0006-channels.md) (en anglais).

## Une session par agent et par channel

Chaque agent d'un channel a sa propre session ACP pour ce channel. Alice dans #general et Alice dans #translations sont deux sessions du même processus : ce qui est dit à Alice dans un channel ne passe jamais dans l'autre.

Une session ne contient que ce qui s'y est dit. Quand on interroge Bob après une réponse d'Alice, la session de Bob ne sait rien de cette réponse. Avant le tour de Bob, Sidekicks ajoute donc à son prompt ce que Bob n'a pas vu : les messages de l'utilisateur aux autres et les réponses des autres agents, depuis le dernier tour de Bob. L'agent lit une courte transcription, puis le message de l'utilisateur. L'agent garde sa propre session — et le souvenir de ses propres réponses — tout en suivant le channel.

L'alternative, une session commune lue par tous les agents, n'existe pas dans ACP : une session appartient à un agent. Renvoyer tout le channel à chaque tour remplirait en quelques échanges les petites fenêtres de contexte des modèles locaux. N'envoyer que la nouveauté est la façon la plus économe de rester à jour ; la transcription est limitée aux 20 derniers messages, chacun raccourci, pour qu'un long channel n'étouffe pas la question.

## Qui répond, et pourquoi un seul à la fois

Un message va aux agents qu'il mentionne, dans l'ordre ; sans mention, au dernier agent qui a parlé. C'est ainsi qu'on parle en groupe : on nomme quelqu'un, ou on continue avec la personne à qui l'on parlait. Personne ne répond à un message qui ne nomme personne dans un channel où plusieurs agents n'ont pas encore parlé — deviner surprendrait davantage l'utilisateur que lui demander de choisir.

Les agents répondent l'un après l'autre, jamais en même temps. Sur un portable, deux modèles locaux qui génèrent ensemble sont chacun plus lents qu'à tour de rôle, et la mémoire est la vraie limite (deux petits modèles sur la machine de référence). Répondre à tour de rôle permet aussi au second agent de lire la réponse du premier : « @alice @bob comparez » donne à Bob la réponse d'Alice à comparer. Pour la même raison, un agent répond à un seul channel à la fois : un second channel attend, et indique à qui c'est le tour.

## Les commandes partent seules

`/idioms Il pleut des cordes` demande à Garfield d'exécuter une skill. L'agent reconnaît une commande à son premier caractère. Si la transcription du channel la précédait, la commande n'en serait plus une. Un message qui commence par `/` est donc envoyé tel quel, sans contexte, et `/garfield:idioms …` choisit l'agent quand le channel en compte plusieurs. Un agent annonce ses commandes dès qu'une session s'ouvre, avant toute question — et mm le fait sans charger son modèle. Le premier `/` tapé dans une conversation démarre donc les membres qui n'ont jamais annoncé les leurs et ouvre leur session (celle que servira leur première réponse) ; la liste se remplit en une fraction de seconde. Sidekicks garde ensuite les commandes et les propose aussitôt les fois suivantes.

## Après un redémarrage

L'historique est dans une base à côté de la configuration (une par fichier de configuration) : les channels sont de nouveau là après un redémarrage. Les agents, eux, sont de nouveaux processus : leurs sessions ont disparu. ACP permet à un agent de reprendre une session (`session/load`) ; Sidekicks s'en sert quand l'agent le propose. mm ne le propose pas : Sidekicks ouvre une nouvelle session et donne à l'agent, dans son premier prompt, les derniers messages du channel — les siens compris cette fois, puisque la nouvelle session n'en contient aucun. L'utilisateur ne voit pas la différence : Alice connaît toujours son prénom.

Le même mécanisme couvre un agent arrêté pour faire de la place à un autre (deux agents au plus) : son tour suivant ouvre une nouvelle session à qui l'on raconte ce qu'elle a manqué. En milestone M2, la conversation disait « Alice a redémarré et ne se souvient plus du début » ; ce message a disparu.

## Les liens avec le reste

- [Permissions et confiance](permissions-et-confiance.md) : les cartes de permission fonctionnent de la même façon dans un channel ; la carte nomme l'agent qui demande.
- [Mémoire et modèles locaux](memoire-et-modeles-locaux.md) : pourquoi deux agents au plus, et pourquoi les réponses se font à tour de rôle.
- [Architecture](architecture.md) : `internal/channels` décide, `internal/store` se souvient, `internal/agents` prête les processus.