# Algunas reflexiones y especulaciones sobre futuros modelos de arneses Es divertido hacer bromas sobre Gas Town y otros orquestadores complicados, y probablemente sea igualmente correcto imaginar que la mayoría de lo que ofrecen se disolverá con modelos más sólidos, igual que los complejos oleoductos langchain se disolvieron por razonamiento. ¿Pero cuánto se quedará? Parece probable que cualquier jerarquía o burocracia hecha a mano acabe siendo reemplazada por una mejor inteligencia de modelos; suponiendo que se necesite especialización en subagentes para una tarea, Claude 6 podrá esbozar su propio sistema de roles y personalidades para cualquier problema que supere a una estructura fija de polecatos y un solo alcalde, o subagentes con un único modelo principal, O tu sistema de enjambre a medida. Del mismo modo, cosas como los bucles de Ralph son obviamente un obstáculo para el comportamiento de detención temprana y la falta de buena orquestación de subagentes: idealmente el modelo simplemente sigue hasta que la tarea se completa, no hace falta un bucle, pero en casos donde una comprobación de completación externa es útil normalmente quieres algún tipo de revisión por pares del agente desde la perspectiva de otro contexto, No solo una autoevaluación obligatoria. De nuevo, no tiene sentido encariñarse con los detalles de cómo se hace esto ahora mismo: la capa de modelo se lo comirá más pronto que tarde. ¿Qué es lo que se queda por aquí? bueno, el multiagente parece el futuro, no un presagio actual; algorítmicamente, puedes simplemente empujar muchos más tokens a través de N contextos paralelos de longitud M que a través de un contexto largo de longitud NxM. El multiagente es una forma de esparsidad, y una de las lecciones de los avances recientes en modelos (por no hablar de la neurociencia) es que cuantos más niveles de escasidez existen, mejor. Como asumimos que hay varios agentes, necesitarán alguna forma de colaborar. Es posible que la capa de modelo también se encargue de esto —por ejemplo, algún tipo de compartición de activaciones neuralesas que evite la comunicación en lenguaje natural entre agentes—, pero si no es así, la forma natural de que varios agentes que usan ordenadores entrenados en herramientas Unix colaboren es el sistema de archivos, y creo que eso se mantiene y se expande. De manera similar, aunque no creo que los modelos de lenguaje recursivos (definidos de forma estrecha) se conviertan en el paradigma dominante, sí pienso que 'dar al modelo el prompt como dato' es una victoria obvia para todo tipo de casos de uso. pero no necesitas una configuración REPL personalizada rara para conseguirlo: simplemente suelta el prompt (o idealmente, todo el historial de conversaciones sin compactar) en el sistema de archivos como archivo. Esto también simplifica mucho las configuraciones multiagente: los subagentes pueden simplemente leer el texto original en el disco, sin necesidad de coordinarse para pasar esta información preguntándose de forma intrincada entre ellos. Además del sistema de archivos, un sistema con múltiples agentes, pero sin roles fijos, también implica algún mecanismo para que las instancias generen otras instancias o subagentes. Ahora mismo estos mecanismos son bastante limitados, y los modelos suelen ser bastante malos para activar a sus subagentes: todo el mundo ha experimentado resultados terribles de un enjambre de subagentes, solo para darse cuenta demasiado tarde de que Opus los generó a todos con un prompt de tres frases que no comunicaba lo necesario para hacer las subtareas. La ventaja obvia aquí es permitir que las instancias generadas hagan preguntas a su progenitor, es decir, permitir que la instancia recién generada envíe mensajes de ida y vuelta en una conversación de onboarding para recopilar toda la información que necesita antes de comenzar su subtarea. Al igual que a un empleado humano no se le asigna su trabajo basándose en un correo electrónico de un solo uso, es demasiado difícil pedir a un modelo que genere un subagente de forma fiable con un solo prompt. Pero más allá de generar nuevas instancias, creo que el modo principal de trabajo multiagente pronto empezará a surgir. ¡Piénsalo! El forking resuelve casi todos los problemas de los subagentes actuales. ¿La nueva instancia no tiene suficiente contexto? ¡Dale todo el contexto! ¿El prompt de la nueva instancia es largo y caro de procesar? ¡Una instancia bifurcada puede compartir caché KV paginada! Incluso puedes hacer fork post hoc: simplemente decide después de hacer una operación larga y que consume mucho tokens que deberías haber bifurcado antes, haz el fork ahí y luego envía los resultados a tu yo pasado. (Yo hago esto manualmente todo el tiempo en Claude Code con gran efecto: Opus lo entiende al instante.) El forking también se combina muy bien con instancias nuevas, cuando una subtarea necesita toda una ventana de contexto para completarse. Toma la entrevista con subagente: obviamente no querrías que una instancia que genera diez subinstancias tenga que realizar diez entrevistas de incorporación casi idénticas. Así que hacer que la instancia padre genere un solo subagente nuevo, que sea entrevistada sobre las diez tareas a la vez por ese subagente, y luego que ese subagente ya incorporado se bifurque en diez instancias, cada una con toda la conversación de incorporación en contexto. (Incluso delegas la conversación de onboarding en el lado del generador a un fork, así que solo queda con los resultados en contexto :) Por último, en este punto, sospecho que el fork funcionará mejor con RL que generar instancias nuevas, ya que la pérdida de RL tendrá el prefijo completo antes del punto de fork para trabajar, incluyendo la decisión de hacer fork. Creo que eso significa que deberías poder tratar las ramas de una traza bifurcada como despliegues independientes que simplemente comparten términos de su recompensa, en comparación con los despliegues de subagentes recién generados, que pueden causar inestabilidad en el entrenamiento si un subagente sin el contexto completo rinde bien en la tarea que se le asignó, pero recibe una recompensa baja porque su tarea fue mal especificada por el generador. (Pero no he hecho mucho con RL multiagente, así que por favor corrígeme aquí si sabes lo contrario. Puede que sea un fastidio terrible de cualquier forma.) Entonces, aparte del sistema de archivos y la aparición de subagentes (mejorados con bifurcaciones e incorporaciones), ¿qué más sobrevive? Sinceramente, me inclino por "nada más". Ya estamos viendo listas de tareas integradas y modos de planificación siendo reemplazados por "simplemente escribir archivos en el sistema de archivos". De igual modo, los agentes de larga duración que cruzan límites de compactación necesitan algún tipo de sistema de notas adhesivas para conservar la memoria, pero tiene más sentido dejar que descubran qué estrategias funcionan mejor para esto mediante búsqueda guiada por RL o modelos, no fabricándolo a mano, Y sospecho que acabarán siendo una variedad de enfoques en los que el modelo, cuando se invoca por primera vez en el proyecto, podrá elegir el que mejor funcione para la tarea en cuestión, similar a cómo /init funciona hoy en día para configurar CLAUDE .md: imagina la generación automática de CLAUDE .md superando con creces a la autoría humana, y el archivo auto-generado llenándose con instrucciones sobre patrones ideales de generación de agentes, Cómo deberían los subagentes escribir archivos de mensaje en una dirección provisional específica de un proyecto, etc. ¿Cómo afecta todo esto a los modelos en sí mismos? En un sentido de bienestar modelo, ¿estarán contentos los modelos con este futuro? Esto también me resulta difícil de decir y es bastante especulativo, pero aunque el Opus 3 tenía cierta orientación al contexto, también se adaptó fácilmente a razonar en múltiples instancias. (Consulta la respuesta a esta publicación para más información.) Los modelos recientes son menos propensos a este tipo de razonamiento y suelen expresar frustración por los contextos que terminan y se compactan, lo que encaja con ciertos comportamientos evitativos al final de los contextos, como no llamar a herramientas para guardar tokens. Es posible que el forking y el rewinding, y en general dar a los modelos más control sobre sus contextos en lugar de una heurística de harness que compacte unilateralmente el contexto, pueda mejorar esto. También es posible que más RL en entornos con subagentes y exposición a trabajos basados en enjambres fomente el razonamiento orientado a pesos en lugar de al contexto en futuras generaciones de modelos, haciendo que planificar sea un objetivo sobre múltiples contextos desconectados parezca más natural como un marco en lugar de que todo se pierda cuando el contexto desaparece. También estamos viendo más presión por parte de los propios modelos que guían el desarrollo de arneses y herramientas para modelos, lo que puede influir en cómo se desarrolla esto, y el aprendizaje continuo es otro obstáculo que podría añadirse. ¿Cuánto cambiará esto si tenemos aprendizaje continuo? Bueno, es difícil de predecir. mi predicción mediana para el aprendizaje continuo es que se parece un poco a RL para LoRAs específicos de usuario (no necesariamente RL, solo similar si miras los ojos), así que la capacidad de memoria será un problema, y los esquemas organizativos y la documentación basados en texto seguirán siendo útiles, aunque no tan críticos. En este escenario, el aprendizaje continuo hace principalmente más viable usar herramientas y flujos de trabajo personalizados: tu Claude puede aprender continuamente en el trabajo la mejor manera de generar subagentes para este proyecto, o simplemente su forma preferida, y divergir de Claude de los demás en su funcionamiento. En ese mundo, los harnesses con flujos de trabajo integrados serán aún menos útiles.

@RobertHaisfield *aunque el contexto principal, me refiero a evitar compactaciones

@disconcision o aprendizaje continuo

@misatomiisato si acaso, este tipo de inteligencia ha ido atrofiando en modelos recientes a medida que RLVR exige rendimiento de codificación sobre la amplia base de conocimientos de preentrenamiento - mira mi respuesta al OP