Enxeñaría do contexto para axentes de IA de longo horizonte

En conxunto, a análise de Arize, o artigo de arXiv sobre desbordamento da xanela de contexto, a explicación de produción de Redis e a comparativa de enxeñaría de arnés de Atlan apuntan a un cambio práctico no deseño de axentes. Os axentes de longa duración están a avaliarse menos polo tamaño da xanela de contexto do modelo e máis pola capa de control que a rodea. Arize concreta ese cambio. Nomea ferramentas de axentes e sistemas de memoria/arnés xa lanzados, incluídos Pi, OpenClaw, Claude Code e Letta, como exemplos de enxeñaría do contexto a nivel de arnés, e describe un simulador interactivo que mostra como se enche unha xanela de 200K tokens.

Os detalles públicos dispoñibles nas fontes citadas son desiguais. Arize dá cifras concretas de implementación para Pi, OpenClaw, Claude Code e Letta. Un artigo de investigación sobre como resolver o desbordamento da xanela de contexto en axentes de IA ofrece un mecanismo máis xeral para manexar saídas de ferramentas que poden superar calquera xanela práctica. A explicación de Redis sobre desbordamento da xanela de contexto resume os síntomas en produción: erros duros de API, degradación silenciosa da calidade, acumulación de saídas de ferramentas e máis latencia a medida que medran os prompts. A comparativa de Atlan sobre enxeñaría de prompts, contexto e arnés achega unha metáfora de pila útil: a enxeñaría de prompts dá forma á mensaxe, a enxeñaría do contexto dá forma ao que ve o modelo e a enxeñaría de arnés dá forma a todo o contorno do axente.

A noticia importante non é que as xanelas de contexto sexan demasiado pequenas. Iso os creadores xa o saben. O punto máis útil é que os sistemas de axentes citados están a converxer en catro mecanismos de arnés que manteñen vivo o traballo cando a transcrición deixa de ser unha fonte segura de verdade.

Un axente superficial le ficheiros, chama ferramentas, engade o resultado e agarda que o modelo poida con el. Un axente deseñado primeiro desde o arnés bloquea ou reconfigura entradas grandes antes de que cheguen ao modelo.

Unha forma máis clara de ler o primeiro conxunto de límites é:

• Pi: as lecturas de ficheiros paran nas 2.000 liñas ou 50KB, o que chegue antes. O contido devolto inclúe unha pista de continuación que lle indica ao modelo que intervalo de liñas se mostrou e como continuar con offset e limit. OpenClaw herda ese comportamento e despois engade límites separados: os ficheiros de arranque limítanse a 12.000 caracteres por ficheiro e 60.000 caracteres en total. Os resultados das ferramentas reciben outro orzamento de 16.000 caracteres ou o 30% da xanela de contexto, o que sexa menor.

Claude Code usa un deseño de dúas portas. Segundo Arize, comproba un límite de 256KB antes de abrir un ficheiro e despois conta os tokens do resultado contra un orzamento de 25.000 tokens tras a lectura. Mesmo para ficheiros por baixo do límite, por defecto devolve 2.000 liñas desde o comezo e trunca as liñas de máis de 2.000 caracteres. Se o modelo volve ler o mesmo intervalo dun ficheiro e o ficheiro non cambiou, Claude Code pode devolver un stub en vez de repetir todo o contido.

Iso non é só optimización. Cambia o modo de fallo. En vez de permitir que unha lectura grande desprace a tarefa, o arnés converte «ler todo» en «ler unha porción controlada». Se o modelo necesita máis, pode pedilo. Para creadores que deseñan arneses de axentes desde cero, esta é a primeira liña de defensa: non deixes nunca que os datos externos en bruto se convertan por defecto na transcrición.

O seguinte patrón é tratar o contexto como unha xanela de visualización, non como almacenamento.

Pi e Claude Code expoñen a paxinación mediante offset e limit. OpenClaw engade truncamento de cabeceira/cola nalgúns lugares, conservando o principio e o final cando é menos probable que o medio importe. Arize di que OpenClaw usa unha división do 75% de cabeceira / 25% de cola para ficheiros de arranque demasiado grandes, e pode conservar tanto a cabeceira como a cola nos resultados de ferramentas cando a cola parece importante, como erros, chaves de peche de JSON ou palabras clave con aspecto de resumo.

Letta vai máis lonxe ao facer que os ficheiros vivan fóra do prompt. Os ficheiros cargados procésanse, divídense en fragmentos e incrústanse nun almacén vectorial, o que lle dá ao axente visualización directa, busca exacta e busca semántica. Cando un ficheiro está aberto no contexto, Letta mostra unha vista xestionada cuxo tamaño escala co contexto do modelo: 5.000 caracteres para contexto de 8K, 15.000 para 32K, 25.000 para 128K e 40.000 para 200K+. O número de ficheiros abertos simultaneamente tamén escala, de 3 para modelos pequenos ata 15 para os moi grandes, cunha política LRU que expulsa os ficheiros aos que se accedeu menos recentemente.

Esta é a mesma idea de deseño que hai detrás do RAG en produción: non metas todo o corpus no prompt; recupera a parte que importa. A diferenza é que os arneses de axentes deben facelo continuamente, a través de ficheiros, saídas de ferramentas, memoria e plans intermedios. A mesma restrición aplícase aos sistemas RAG: a recuperación non vai só de relevancia, senón tamén de preservar orzamento de contexto abondo para o paso real de razoamento.

Redis fai unha observación relacionada: xanelas de contexto máis grandes non eliminan a necesidade de xestión do contexto. Prompts de sistema, documentos recuperados, historial da conversa e saídas de ferramentas compiten todos polo mesmo espazo. Mesmo antes de chegar a un límite duro, os modelos poden degradarse a medida que a información relevante queda soterrada en entradas longas.

O desbordamento é o fallo evidente. A perda de obxectivo é máis silenciosa. O axente aínda ten espazo para responder, pero esquece o obxectivo orixinal, perde unha restrición ou empeza a optimizar unha subtarefa local.

Aí é onde importa a compactación. Feita mal, a resumición substitúe un historial desordenado pero fiel por unha historia ordenada pero con perdas. Feita ben, preserva o estado da tarefa, o traballo recente, os elementos pendentes e a integridade das chamadas a ferramentas.

Arize informa de que Pi activa a compactación cando os tokens de contexto estimados superan a xanela de contexto menos os tokens de reserva, cunha reserva por defecto de 16.384 tokens. Conserva aproximadamente os 20.000 tokens máis recentes e resume o contido máis antigo nunha mensaxe de usuario sintética anteposta á cola conservada. Tamén evita cortar pares chamada-a-ferramenta/resultado-da-ferramenta.

OpenClaw engade unha política de historial máis agresiva. Cando o historial supera o 50% da xanela de contexto, divide as mensaxes en fragmentos de masa de tokens equivalente, descarta o fragmento máis antigo, resume o contido descartado mediante unha resumición por etapas e varias pasadas, e repara o emparellamento chamada/resultado de ferramentas. Tamén realiza un baleirado previo á compactación: unha quenda axéntica silenciosa dálle ao axente a oportunidade de persistir estado en ficheiros de memoria antes de que desapareza o historial. Por separado, poda resultados de ferramentas na memoria con comportamento de recorte suave e limpeza dura sobre unha TTL de caché de 5 minutos.

Claude Code compacta preto do final da xanela. Arize di que o seu disparador é a xanela de contexto efectiva menos un búfer de 13.000 tokens, o que sitúa a compactación arredor dos 167K tokens para un modelo con contexto de 200K. O seu prompt de resumición pide seccións estruturadas que cubran a solicitude principal, conceptos técnicos, ficheiros e código, erros e correccións, resolución de problemas, mensaxes do usuario, tarefas pendentes, traballo actual e seguinte paso. Tras a compactación, pode volver anexar ata 5 ficheiros lidos recentemente dentro dun orzamento de tokens.

O patrón é claro: a compactación non é «resumir o chat». É crear puntos de control. Un axente de longa duración necesita o equivalente a un ficheiro de gardado: obxectivo, restricións, decisións, identificadores abertos, evidencias recentes e seguinte acción.

Algunhas saídas nunca deberían colocarse na xanela de contexto.

O artigo de arXiv concrétao cun fluxo de traballo de ciencia de materiais. Unha ferramenta xera unha estrutura de grade electrónica para unha molécula: unha matriz 3D de dimensións 128 × 128 × 128, cun total de 2.097.152 elementos float32. Esa saída supera con moito a xanela de contexto de LLMs amplamente usados. Pero a seguinte ferramenta necesita a grade como entrada.

A solución proposta é almacenar valores grandes fóra do contexto do modelo e devolver identificadores curtos, ou punteiros. Os envoltorios de ferramentas inspeccionan as entradas para ver se son valores en bruto ou rutas de memoria. As saídas demasiado grandes almacénanse na memoria de execución baixo unha ruta, e as ferramentas posteriores poden recibir o punteiro e resolvelo internamente. O modelo manipula referencias, mentres o arnés preserva os datos completos. Nun experimento comparativo no que ambos métodos tiveron éxito, o enfoque baseado en punteiros usou aproximadamente sete veces menos tokens ca o fluxo de traballo tradicional, segundo o artigo.

Esta é a separación máis limpa entre razoamento e transporte de datos. O modelo non necesita «ver» unha matriz de 2 millóns de elementos para pasala a outra ferramenta. Necesita saber que a matriz existe, que representa e que operación debería consumila despois.

A mesma lóxica aplícase máis alá dos arrays científicos. Respostas JSON grandes, PDFs, logs, embeddings, ficheiros multimedia e exportacións de bases de datos adoitan pertencer ao almacenamento, non ao prompt. Para sistemas construídos arredor de ferramentas MCP ou conectores API personalizados, pasar punteiros debería ser unha decisión de deseño de primeiro nivel, non un parche tras o primeiro desbordamento.

Unha xanela de contexto de 200K tokens parece grande ata que un axente empeza a actuar. Un prompt de sistema, definicións de ferramentas, uns cantos documentos recuperados, lecturas de ficheiros, logs, trazas de erro e resumos poden consumila máis rápido do esperado. O enfoque práctico non é o grande que parece a xanela sobre o papel, senón a velocidade coa que os axentes a gastan en tempo de execución. A guía de Redis sobre memoria de axentes apunta cara a memoria externa e duradeira para o estado que debería sobrevivir entre chamadas, mentres que o enfoque de enxeñaría do contexto de Atlan separa mellores prompts dunha mellor ensamblaxe de contexto. Xuntos, tratan a xanela de contexto menos como un almacén e máis como un conxunto de traballo restrinxido.

A lección máis profunda é que unha xanela de contexto é un recurso escaso en tempo de execución. Tratala como «memoria» é útil, pero só se o arnés se comporta como un sistema operativo: asigna, expulsa, paxina, compacta, deduplica e persiste. A distinción de capas de Atlan é útil aquí. A enxeñaría de prompts non pode arranxar un lector de ficheiros que envorca 80.000 tokens irrelevantes na seguinte chamada. A enxeñaría do contexto pode mellorar o conxunto de traballo. A enxeñaría de arnés decide se ese conxunto de traballo está protexido desde o principio.

Isto tamén cambia como deberían avaliar os equipos os axentes. Un prompt de demostración non abonda. A avaliación de longo horizonte debería incluír transcricións crecentes, lecturas de ficheiros repetidas, saídas de ferramentas grandes, chamadas a ferramentas fallidas, continuacións tras a compactación e tarefas nas que o seguinte paso correcto depende dunha restrición inicial. A nosa guía de enxeñaría do contexto para axentes cobre a versión dese problema do lado do modelo; a capa de arnés é onde se volve operacional.

Primeiro, pon orzamentos en cada fonte de contexto. Ficheiros, saídas de ferramentas, fragmentos recuperados, insercións de memoria e historial de conversa deberían ter límites explícitos. Un único máximo global de tokens é demasiado basto.

Segundo, fai que o truncamento sexa accionable. Se o arnés corta contido, o modelo debería saber que intervalo viu e como pedir máis. O truncamento silencioso é peor ca o rexeitamento porque crea traballo confiado sobre datos ausentes.

Terceiro, compacta arredor do estado, non da prosa. Os resumos deberían preservar o obxectivo do usuario, restricións, decisións, tarefas pendentes, ficheiros tocados, resultados de ferramentas que importan e o seguinte paso inmediato. Os pares de chamadas a ferramentas deberían manterse intactos.

Cuarto, move os valores grandes fóra do prompt. Gárdaos, ponlles nome e pasa punteiros polas ferramentas. Isto é especialmente importante para axentes que chaman APIs, procesan documentos ou coordinan sistemas multi-axente.

Por último, proba a perda de obxectivo por separado do desbordamento. Un axente pode quedar por baixo da xanela dura e aínda así desviarse. A pregunta correcta non é só «aceptou a API o prompt?». É «a seguinte acción segue servindo á tarefa orixinal?»

O resumo seguinte converte eses patróns nunha lista de comprobación rápida antes das preguntas frecuentes.

• Os axentes de longo horizonte fallan tanto por desbordamento de contexto como por perda de obxectivo, así que o arnés debe xestionar máis que a lonxitude do prompt.
• Os sistemas de axentes en produción usan orzamentos ríxidos en ficheiros, saídas de ferramentas e historial antes de que os datos en bruto cheguen ao modelo.
• A paxinación, a busca e as vistas xestionadas tratan o contexto como unha xanela de visualización limitada, non como almacenamento permanente.
• A compactación funciona mellor como punto de control: preserva obxectivos, restricións, decisións, traballo pendente e integridade das chamadas a ferramentas.
• As saídas grandes de ferramentas adoitan pertencer ao almacenamento externo, con punteiros curtos pasados entre ferramentas en vez de valores completos no prompt.

Esta sección responde ás preguntas prácticas detrás da enxeñaría do contexto para axentes de longo horizonte: que se desborda, como se perden os obxectivos e que patróns de arnés manteñen o traballo no bo camiño.

O desbordamento de contexto acontece cando o prompt acumulado dun axente, o historial, os datos recuperados, os ficheiros e as saídas de ferramentas superan a xanela de contexto útil do modelo ou degradan a calidade antes de chegar ao límite duro.

A perda de obxectivo acontece cando a tarefa orixinal aínda está presente nalgún punto da transcrición pero xa non guía a seguinte acción do axente, a miúdo tras historiais longos ou unha mala resumición.

Establecen orzamentos por fonte, paxinan lecturas de ficheiros, recuperan só vistas relevantes, compactan o historial arredor do estado, deduplican lecturas repetidas e almacenan saídas grandes fóra do prompt.

Os punteiros permiten que o modelo se refira a valores grandes almacenados na memoria de execución, como matrices, logs ou PDFs, mentres as ferramentas posteriores resolven os datos completos sen colocalos na xanela de contexto.

Non. As xanelas máis grandes axudan, pero os prompts de sistema, as definicións de ferramentas, os documentos recuperados, os logs e o historial seguen competindo polo espazo, e a información relevante pode quedar soterrada antes de chegar a un límite duro.