Blog
Notes sur le harnais, les modèles qui le font tourner, et ce qui change quand un nouveau modèle arrive.
Synchroniser la mémoire sans « dernière écriture gagnante »
Deux machines, un seul ensemble de notes, l'une modifiée pendant que l'autre dormait. Tout système de synchronisation répond à ce cas, et la plupart y répondent par une comparaison d'horodatages qui écarte silencieusement l'un des deux côtés. C'est acceptable pour un brouillon qu'on peut retaper. Ça ne l'est pas pour le fichier qu'un agent lit avant chaque tour, car ce qui est écarté, c'est la ligne que vous avez écrite pour qu'une chose ne se reproduise pas.
Les ids de modèles n'ont rien à faire dans du TypeScript
Un id de modèle est le fait qui évolue le plus vite dans tout ce système. Les fournisseurs les renomment, les retirent, publient une variante datée, modifient discrètement la cible de l'alias non daté, et en réservent la moitié selon le compte qui les demande. Compilez cela dans un paquet et vous êtes certain que le paquet sera faux en quelques semaines — pas cassé de façon évidente, ce qui donnerait au moins lieu à un rapport de bug, mais faux de cette manière particulière où un sélecteur propose à quelqu'un un modèle que sa clé ne peut pas appeler.
Une règle deny est la seule frontière dont vous disposez
Tout ce qu'un harnais d'agent appelle par ailleurs une permission est un jugement sur le coût. Cela mérite d'être dit clairement, car l'interface ne le dit pas : une demande d'approbation, un mode nommé Auto et un réglage de répertoires accessibles en écriture ont l'air de la même nature, et un seul d'entre eux est une limite que le système tiendra quoi qu'il arrive.
Changer de modèle en cours de session ne coûte rien
Et c'est un choix de conception, pas une fonctionnalité. La plupart des outils pour agents sont écrits pour un seul fournisseur, puis adaptés aux autres. Cet ordre a l'air d'un détail d'implémentation. C'est en réalité tout le sujet.