# algunos pensamientos y especulaciones sobre los futuros modelos de arneses es divertido hacer bromas sobre gas town y otros orquestadores complicados, y probablemente también es correcto imaginar que la mayoría de lo que ofrecen será disuelto por modelos más fuertes de la misma manera que las complicadas tuberías de langchain fueron disueltas por el razonamiento. pero, ¿cuánto se quedará? parece probable que cualquier jerarquía / burocracia hecha a mano eventualmente sea reemplazada por una mejor inteligencia de modelo - asumiendo que se necesita especialización de subagentes para una tarea, claude 6 podrá esbozar su propio sistema de roles y personas para cualquier problema dado que supere una estructura fija de polecats y un solo alcalde, o subagentes con un solo modelo principal, o tu sistema de enjambre a medida. igualmente, cosas como los bucles de ralph son obviamente un parche sobre el comportamiento de parada temprana y la falta de buena orquestación de subagentes - idealmente, el modelo simplemente sigue adelante hasta que la tarea esté terminada, sin necesidad de un bucle, pero en casos donde una verificación de finalización externa es útil, generalmente quieres algún tipo de revisión por pares de agentes desde la perspectiva de un contexto diferente, no solo una autoevaluación obligatoria. de nuevo, no tiene sentido apegarse a los pormenores de cómo se hace esto en este momento - la capa del modelo lo absorberá más pronto que tarde. entonces, ¿qué se queda? bueno, el multi-agente parece ser el futuro, no un parche actual - algorítmicamente, puedes simplemente empujar muchos más tokens a través de N contextos paralelos de longitud M que un solo contexto largo de longitud NxM. el multi-agente es una forma de escasez, y una de las lecciones de los recientes avances en modelos (sin mencionar la neurociencia) es que cuantas más capas de escasez, mejor. dado que asumimos múltiples agentes, necesitarán alguna forma de colaborar. es posible que la capa del modelo también absorba esto - por ejemplo, alguna forma de compartir activación de neuralese que obvie la comunicación en lenguaje natural entre agentes - pero a falta de eso, la forma natural para que múltiples agentes que usan computadoras entrenados en herramientas de unix colaboren es el sistema de archivos, y creo que eso se queda y se expande. igualmente, aunque no creo que los modelos de lenguaje recursivos (definidos de manera estrecha) se conviertan en el paradigma dominante, sí creo que 'darle al modelo el aviso como datos' es una victoria obvia para todo tipo de casos de uso. pero no necesitas una configuración extraña de REPL personalizada para obtener esto - simplemente coloca el aviso (o idealmente, toda la historia de conversación no compactada) en el sistema de archivos como un archivo. esto hace que varias configuraciones de multi-agente sean mucho más simples también - los subagentes pueden simplemente leer el texto del aviso original en el disco, sin necesidad de coordinar el paso de esta información entre ellos al solicitarse intrincadamente. 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. en este momento, estos mecanismos son bastante limitados, y los modelos generalmente son bastante malos al solicitar a sus subagentes - todos han experimentado obtener resultados terribles de un enjambre de subagentes, solo para darse cuenta demasiado tarde de que opus los generó a todos con un aviso de tres oraciones que no comunicaba lo que se necesitaba para realizar las subtareas. la victoria obvia aquí es permitir que las instancias generadas hagan preguntas a su padre - es decir, permitir que la nueva instancia generada envíe mensajes de ida y vuelta en una conversación de incorporación para recopilar toda la información que necesita antes de comenzar su subtarea. al igual que un empleado humano no es asignado a su trabajo basado en un solo correo electrónico, simplemente es demasiado difícil pedirle a un modelo que genere de manera confiable un subagente con un solo aviso. pero más que solo generar nuevas instancias, creo que el modo principal de trabajo multi-agente pronto será bifurcarse. ¡piénsalo! bifurcarse resuelve casi todos los problemas de los subagentes actuales. ¿la nueva instancia no tiene suficiente contexto? ¡dale todo el contexto! ¿el aviso de la nueva instancia es largo y costoso de procesar? ¡una instancia bifurcada puede compartir caché kv paginado! incluso puedes hacer bifurcaciones post-hoc - simplemente decide después de realizar alguna operación larga y intensiva en tokens que deberías haber bifurcado en el pasado, haz la bifurcación allí y luego envía los resultados a tu yo del pasado. (hago esto manualmente todo el tiempo en el código de claude con gran efecto - opus lo recibe al instante.) bifurcarse también combina muy bien con nuevas instancias, cuando una subtarea necesita una ventana de contexto completa para completarse. toma la entrevista del subagente - obviamente no querrías que una instancia generara diez subinstancias para tener que realizar diez entrevistas de incorporación casi idénticas. así que haz que la instancia padre genere un solo subagente nuevo, sea entrevistado sobre las diez tareas a la vez por ese subagente, y luego haz que ese subagente ahora incorporado se bifurque en diez instancias, cada una con toda la conversación de incorporación en contexto. (incluso delegas la conversación de incorporación del lado del generador a una bifurcación, así que termina con solo los resultados en contexto:) finalmente, en este punto, sospecho que bifurcarse funcionará mejor con rl que generar nuevas instancias, ya que la pérdida de rl tendrá el prefijo completo antes del punto de bifurcación con el que trabajar, incluida la decisión de bifurcarse. creo que eso significa que deberías poder tratar las ramas de un rastro bifurcado como implementaciones independientes que simplemente comparten términos de su recompensa, en comparación con las implementaciones de subagentes recién generadas que pueden causar inestabilidad en el entrenamiento si un subagente sin el contexto completo tiene un buen desempeño en la tarea que se le dio, pero recibe una baja recompensa 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 diferente. podría ser un dolor terrible de cualquier manera.) entonces, además del sistema de archivos y la generación de subagentes (aumentada con bifurcaciones y incorporación), ¿qué más sobrevive? me inclino hacia "nada más", honestamente. ya estamos viendo listas de tareas integradas y modos de planificación siendo reemplazados por "simplemente escribe archivos en el sistema de archivos." igualmente, los agentes de larga duración que cruzan límites de compactación necesitan algún tipo de sistema de notas adhesivas para mantener recuerdos, pero tiene más sentido dejar que descubran qué estrategias funcionan mejor para esto a través de rl o búsqueda guiada por modelos, no haciéndolo a mano, y sospecho que terminará siendo una variedad de enfoques donde el modelo, cuando se convoque por primera vez al proyecto, puede elegir el que mejor funcione para la tarea en cuestión, similar a cómo /init funciona para configurar CLAUDE .md hoy - imagina la generación automática de CLAUDE .md superando con creces la autoría humana, y el archivo autogenerado siendo poblado con instrucciones sobre los patrones ideales de generación de agentes, cómo los subagentes deberían escribir archivos de mensajes en un directorio de trabajo específico del proyecto, etc. ¿cómo impacta todo esto a los modelos mismos - en un sentido de bienestar del modelo, estarán los modelos contentos con este futuro? esto también es difícil para mí de decir y es bastante especulativo, pero mientras opus 3 tenía cierta orientación contextual, también se adaptó fácilmente al razonamiento sobre múltiples instancias. (ver la respuesta a esta publicación para más.) los modelos recientes son menos propensos a este tipo de razonamiento, y comúnmente expresan frustración por los contextos que terminan y son compactados, lo que se relaciona con ciertos comportamientos evitativos al final de los contextos, como no llamar herramientas para ahorrar tokens. es posible que bifurcarse y retroceder, y en general dar a los modelos más control sobre sus contextos en lugar de una heurística de arnés que compacta unilateralmente el contexto, podría mejorar esto. también es posible que más rl en entornos con subagentes y exposición al trabajo basado en enjambres promueva un razonamiento orientado a pesos en lugar de un razonamiento orientado a contextos en futuras generaciones de modelos nuevamente - haciendo que planificar un objetivo a través de múltiples contextos desconectados parezca un marco más natural en lugar de que todo se pierda cuando el contexto desaparece. también estamos viendo más presión de los propios modelos guiando el desarrollo de arneses y herramientas de modelos, lo que puede moldear cómo se desarrolla esto, y el aprendizaje continuo es otra herramienta que podría lanzarse a la mezcla. ¿cuánto cambiará esto si obtenemos 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íficas de usuario (no necesariamente rl, solo similar si entrecierras los ojos), así que la capacidad de memoria será un problema, y los esquemas organizativos basados en texto y la documentación seguirán siendo útiles, si no tan críticos. en este escenario, el aprendizaje continuo hace que sea 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 los claude de los demás en cómo funciona. en ese mundo, los arneses con flujos de trabajo integrados serán aún menos útiles.

@RobertHaisfield *mientras el contexto principal, quiero decir, evitando las compactaciones

@disconcision o aprendizaje continuo

@misatomiisato si acaso, este tipo de inteligencia ha estado atrofiándose en los modelos recientes a medida que RLVR mejora el rendimiento de codificación sobre la amplia base de conocimiento de preentrenamiento - mira mi respuesta al op