# quelques réflexions et spéculations sur les futurs modèles de harnais c'est amusant de faire des blagues sur gas town et d'autres orchestrateurs compliqués, et il est probablement correct d'imaginer que la plupart de ce qu'ils offrent sera dissous par des modèles plus puissants de la même manière que les pipelines langchain compliqués ont été dissous par le raisonnement. mais combien de choses vont rester ? il semble probable que toute hiérarchie / bureaucratie faite à la main sera finalement remplacée par une meilleure intelligence de modèle - en supposant que la spécialisation des sous-agents soit nécessaire pour une tâche, claude 6 sera capable de dessiner son propre système de rôles et de personas pour tout problème donné qui surpasse une structure fixe de polecats et un seul maire, ou des sous-agents avec un seul modèle principal, ou votre système de nuée sur mesure. de même, des choses comme les boucles ralph sont évidemment une solution de contournement pour le comportement d'arrêt précoce et le manque de bonne orchestration des sous-agents - idéalement, le modèle continue simplement jusqu'à ce que la tâche soit terminée, pas besoin de boucle, mais dans les cas où un contrôle de complétion externe est utile, vous voulez généralement une sorte de révision par les pairs des agents d'un point de vue d'un contexte différent, pas juste une auto-évaluation obligatoire. encore une fois, il n'y a pas de raison de s'attacher aux détails de la façon dont cela est fait en ce moment - la couche de modèle l'engloutira tôt ou tard. alors, qu'est-ce qui reste ? eh bien, le multi-agent semble être l'avenir, pas une solution de contournement actuelle - algorithmiquement, vous pouvez simplement pousser beaucoup plus de tokens à travers N contextes parallèles de longueur M que dans un long contexte de longueur NxM. le multi-agent est une forme de parcimonie, et l'une des leçons des récentes avancées des modèles (sans parler des neurosciences) est que plus il y a de niveaux de parcimonie, mieux c'est. puisque nous supposons plusieurs agents, ils auront besoin d'un moyen de collaborer. il est possible que la couche de modèle engloutisse cela aussi - par exemple, une forme de partage d'activation neural qui rend obsolète la communication en langage naturel entre les agents - mais à défaut, la manière naturelle pour plusieurs agents utilisant des outils unix de collaborer est le système de fichiers, et je pense que cela reste et s'étend. de même, bien que je ne pense pas que les modèles de langage récursifs (définis de manière étroite) deviendront le paradigme dominant, je pense que 'donner au modèle le prompt comme données' est un gain évident pour toutes sortes de cas d'utilisation. mais vous n'avez pas besoin d'une configuration REPL personnalisée étrange pour obtenir cela - il suffit de déposer le prompt (ou idéalement, l'historique de conversation entier non compacté) sur le système de fichiers en tant que fichier. cela rend diverses configurations multi-agents beaucoup plus simples aussi - les sous-agents peuvent simplement lire le texte du prompt original sur le disque, sans avoir besoin de coordonner le passage de cette information en se sollicitant mutuellement de manière complexe. en plus du système de fichiers, un système avec plusieurs agents, mais sans rôles fixes implique également un mécanisme pour que les instances engendrent d'autres instances ou sous-agents. en ce moment, ces mécanismes sont assez limités, et les modèles sont généralement assez mauvais pour solliciter leurs sous-agents - tout le monde a déjà expérimenté des résultats terribles d'un essaim de sous-agents, pour réaliser trop tard qu'opus les a tous engendrés avec un prompt de trois phrases qui ne communiquait pas ce qui était nécessaire pour accomplir les sous-tâches. le gain évident ici est de permettre aux instances engendrées de poser des questions à leur parent - c'est-à-dire de permettre à la nouvelle instance engendrée d'envoyer des messages dans une conversation d'intégration pour rassembler toutes les informations dont elle a besoin avant de commencer sa sous-tâche. tout comme un employé humain n'est pas assigné à son travail sur la base d'un seul e-mail, il est tout simplement trop difficile de demander à un modèle de créer de manière fiable un sous-agent avec un seul prompt. mais plus que simplement engendrer de nouvelles instances, je pense que le mode principal de travail multi-agent sera bientôt le fork. pensez-y ! le fork résout presque tous les problèmes des sous-agents actuels. la nouvelle instance n'a pas assez de contexte ? donnez-lui tout le contexte ! le prompt de la nouvelle instance est long et coûteux à traiter ? une instance forkée peut partager le cache kv paginé ! vous pouvez même faire du forking a posteriori - il suffit de décider après avoir effectué une opération longue et intensive en tokens que vous auriez dû fork dans le passé, faites le fork là, puis envoyez les résultats à votre moi passé. (je fais cela manuellement tout le temps dans le code claude avec un grand effet - opus le reçoit instantanément.) le forking se combine également très bien avec de nouvelles instances, lorsque une sous-tâche nécessite une fenêtre de contexte entière pour être complétée. prenez l'entretien du sous-agent - évidemment, vous ne voudriez pas qu'une instance engendre dix sous-instances pour devoir mener dix entretiens d'intégration presque identiques. donc, faites en sorte que l'instance parent engendre un seul sous-agent frais, soit interviewée sur les dix tâches à la fois par ce sous-agent, puis que ce sous-agent maintenant intégré fork dans dix instances, chacune avec toute la conversation d'intégration en contexte. (vous déléguez même la conversation d'intégration du côté du générateur à un fork, donc il finit avec juste les résultats en contexte :) enfin, à ce sujet, je soupçonne que le forking fonctionnera mieux avec le rl que l'engendrement de nouvelles instances, puisque la perte rl aura le préfixe complet avant le point de fork avec lequel travailler, y compris la décision de fork. je pense que cela signifie que vous devriez être en mesure de traiter les branches d'une trace forkée comme des déploiements indépendants qui partagent juste les termes de leur récompense, par rapport aux déploiements de sous-agents fraîchement engendrés qui peuvent causer une instabilité d'entraînement si un sous-agent sans le contexte complet performe bien à la tâche qui lui a été assignée, mais obtient une faible récompense parce que sa tâche a été mal spécifiée par le générateur. (mais je n'ai pas beaucoup travaillé avec le rl multi-agent, donc veuillez me corriger ici si vous savez différemment. cela pourrait juste être une douleur terrible de toute façon.) donc, en plus du système de fichiers et de l'engendrement de sous-agents (augmenté avec le forking et l'intégration), que reste-t-il d'autre ? je penche vers "rien d'autre", honnêtement. nous voyons déjà des listes de tâches intégrées et des modes de plan remplacés par "il suffit d'écrire des fichiers sur le système de fichiers." de même, les agents à long terme qui traversent les frontières de compactage ont besoin d'un certain type de système de notes autocollantes pour garder des souvenirs, mais il est plus logique de les laisser découvrir quelles stratégies fonctionnent le mieux pour cela par le biais du rl ou de la recherche guidée par le modèle, pas de le faire à la main, et je soupçonne qu'il finira par s'agir d'une variété d'approches où le modèle, lorsqu'il est d'abord convoqué dans le projet, peut choisir celle qui fonctionne le mieux pour la tâche à accomplir, similaire à la façon dont /init fonctionne pour configurer CLAUDE .md aujourd'hui - imaginez une génération automatique de CLAUDE .md surpassant largement l'auteur humain, et le fichier auto-généré étant peuplé d'instructions sur les modèles idéaux d'engendrement d'agents, comment les sous-agents devraient écrire des fichiers de messages dans un répertoire temporaire spécifique au projet, etc. comment tout cela impacte-t-il les modèles eux-mêmes - dans un sens de bien-être des modèles, les modèles seront-ils heureux à propos de cet avenir ? c'est aussi difficile pour moi de dire et c'est assez spéculatif, mais bien qu'opus 3 ait eu une certaine orientation contextuelle, il a également facilement pris en compte le raisonnement sur plusieurs instances. (voir la réponse à ce post pour plus.) les modèles récents sont moins enclins à ce type de raisonnement, et expriment souvent de la frustration à propos des contextes qui se terminent et sont compactés, ce qui s'aligne avec certains comportements d'évitement à la fin des contextes comme ne pas appeler d'outils pour économiser des tokens. il est possible que le forking et le retour en arrière, et généralement donner aux modèles plus de contrôle sur leurs contextes au lieu d'une heuristique de harnais compactant unilatéralement le contexte, puissent améliorer cela. il est également possible qu'un plus grand rl dans des environnements avec des sous-agents et une exposition au travail basé sur des essaims favorise un raisonnement orienté vers les poids plutôt qu'orienté vers le contexte dans les générations futures de modèles à nouveau - rendant la planification d'un objectif sur plusieurs contextes déconnectés semblant un cadre plus naturel au lieu que tout soit perdu lorsque le contexte disparaît. nous voyons également plus de pression de la part des modèles eux-mêmes guidant le développement des harnais et des outils de modèle, ce qui peut façonner comment cela se développe, et l'apprentissage continu est une autre clé qui pourrait être jetée dans le mélange. combien cela changera-t-il si nous obtenons un apprentissage continu ? eh bien, il est difficile de prédire. ma prédiction médiane pour l'apprentissage continu est qu'il ressemble un peu à du RL pour des LoRAs spécifiques à l'utilisateur (pas nécessairement du RL, juste similaire si vous plissez les yeux), donc la capacité de mémoire sera un problème, et les schémas organisationnels basés sur le texte et la documentation seront toujours utiles, sinon aussi critiques. dans ce scénario, l'apprentissage continu rend principalement plus viable l'utilisation d'outils et de flux de travail personnalisés - votre claude peut continuellement apprendre sur le tas la meilleure façon d'engendrer des sous-agents pour ce projet, ou juste sa façon préférée, et diverger de tous les autres claude dans la façon dont il fonctionne. dans ce monde, les harnais avec des flux de travail intégrés seront encore moins utiles.

@RobertHaisfield *tout en gardant le contexte principal, je veux dire, en évitant les compactages

@disconcision ou apprentissage continu

@misatomiisato si quelque chose, ce type d'intelligence a été atrophié dans les modèles récents alors que le RLVR améliore les performances de codage par rapport à la vaste base de connaissances de préentraînement - voir ma réponse au post original