Google mató la ventana de contexto.

Las ventanas de contexto de un millón de tokens se suponían que eran el código secreto para los modelos de lenguaje grandes. Los proveedores compitieron por anunciar solicitudes de 128K, 200K, e incluso 1M de tokens, como si la simple capacidad desbloqueara copilotos de codificación confiables, agentes autónomos y bases de conocimiento completamente buscables. La realidad ha sido menos cinemática: más tokens a menudo solo significan modelos más lentos, más costosos y aún confundidos.

La última investigación de Google sobre ingeniería de contexto desmantela el mito. La compañía argumenta que “aumentar el número de tokens para abordar el problema solo comprime el tiempo, pero no cambia la forma de la curva” en términos de costo, latencia y fiabilidad. Puedes superar brevemente la complejidad con una ventana de 1 millón de tokens, pero las cargas de trabajo reales—resultados de RAG, registros de múltiples agentes, salidas de herramientas e historial de usuarios—alcanzarán rápidamente.

Tres límites duros siguen aplastando la estrategia de “simplemente llenar el prompt”. El primero es la espiral de costo y latencia: cada 100K tokens adicionales aumentan el tiempo de inferencia y las facturas en la nube, a menudo entre 2 y 3 veces en aplicaciones a escala de producción. El segundo es “perderse en el medio”, un efecto documentado donde los modelos ignoran instrucciones cruciales enterradas en prompts sobrecargados. El tercero es la física: incluso las ventanas de un millón de tokens desbordan una vez que comienzas a encadenar herramientas y agentes durante horas o días.

La respuesta de Google no es “2 millones de tokens”, es un cambio arquitectónico. En lugar de tratar el contexto como un enorme registro de chat mutable, la empresa lo presenta como una vista compilada sobre un sistema más rico y con estado. Los datos en bruto—sesiones, recuerdos, artefactos—actúan como código fuente; un flujo de procesadores compila un contexto de trabajo mínimo y específico para cada llamada al modelo.

Ese cambio transforma el contexto de un problema de almacenamiento en búfer por fuerza bruta a un problema de diseño de sistemas. El Kit de Desarrollo de Agentes (ADK) de Google integra esto en una pila de cuatro capas: contexto de trabajo, sesión, memoria y artefactos, cada uno con responsabilidades y ciclos de vida claros. El contexto deja de ser "lo que quepa en la ventana" y se convierte en un producto explícito de código, políticas y alcances.

Este artículo explica cómo funciona ese marco en producción. Utilizando el Kit de Desarrollo de Agentes de Google (ADK), desglosaremos la arquitectura de contexto, los diferentes objetos de contexto y permisos, y un agente de investigación de documentos que demuestra por qué la era de un millón de tokens ya ha terminado.

Ventanas de contexto más grandes prometen omnisciencia, pero principalmente generan un shock por los costos. Cada 100,000 tokens adicionales suman dólares reales y segundos, y los equipos de producción sienten ambos. El propio blog de ingeniería de contexto de Google describe una espiral de costos/latencia: más tokens por llamada, multiplicados por miles de usuarios concurrentes, convierten “una bonita demostración” en “presupuesto desbordado” rápidamente.

La latencia escala de manera igualmente brutal. Ese aviso de un millón de tokens significa una decodificación más lenta, cadenas de herramientas más largas y una experiencia de usuario que se aleja de "asistente" a "sistema de tickets". En configuraciones de múltiples agentes, cada llamada de agente se expande en más llamadas de modelo, por lo que un contexto inflado contagia a toda la pipeline.

Luego llega Perdido en el Medio. Los LLM no prestan atención de manera uniforme a lo largo de grandes indicaciones; a menudo sobreestiman el principio y el final, y silenciosamente ignoran el centro. El blog de Google y el trabajo posterior muestran que la precisión disminuye cuando los hechos clave están enterrados en el medio de una larga secuencia, incluso cuando el modelo “ve” técnicamente todo.

Imagina el aviso de un agente de producción después de unos minutos de uso. En la parte superior: una pregunta reciente de un usuario. En la parte inferior: un error reciente de la herramienta y una instrucción para reintentar. Apretujada en el medio: la restricción de política real o la instrucción crítica del sistema. El modelo optimiza alegremente alrededor de los bordes y se aferra a lo que realmente importa.

Las cargas de trabajo reales agravan esto. Un solo turno puede incluir: - 20 a 50 pasajes de RAG - 5 a 10 registros de llamadas a herramientas - Docenas de mensajes de chat anteriores

Introduce todo eso en un modelo "listo para 1M de tokens" y la ventana de contexto aún se ahoga después de un puñado de interacciones ricas. Incluso las demostraciones del Kit de Desarrollo de Agentes de Google (ADK) muestran cuán rápidamente los artefactos, la memoria y el estado de la sesión se desbordarían si arrojas todo de forma ingenua en el aviso.

Los límites físicos duros terminan el trabajo. La longitud del contexto escala sublinealmente con la computación y la memoria; pasar de 128K a 1M de tokens ya exige una infraestructura exótica. Si intentas ir mucho más alto, te enfrentas a la RAM de la GPU, el ancho de banda y la estabilidad del entrenamiento, no solo a un diseño de prompt ingenioso.

Estas no son curiosidades de laboratorio. Son las razones por las que los equipos de producción limitan la historia en silencio, acortan los resultados de RAG y resumen de manera agresiva. Hasta que el contexto deje de ser un flujo crudo y se convierta en una visión compilada, los grandes agentes seguirán ahogándose en sus propios datos.

La nueva idea de compilador de contexto de Google desmantela el antiguo modelo mental de una ventana de contexto como un registro de chat sin fondo. En lugar de un búfer de flujo mutable, el contexto se convierte en una vista compilada sobre un estado mucho más rico: sesiones, recuerdos y artefactos que existen fuera de cualquier única solicitud. Cada llamada al modelo solo ve una porción cuidadosamente construida, no toda la paja en el pajar.

Piensa como un ingeniero de compiladores, no como un modificador de prompts. Los datos de interacción en bruto se convierten en el código fuente; un conjunto de procesadores actúa como el compilador; el prompt final enviado a Gemini es el ejecutable optimizado. El propio blog de Google, Arquitectura de un marco de múltiples agentes contextualmente conscientes y eficiente para producción, lo especifica como un requisito estricto para agentes a escala de producción, no como una abstracción opcional.

Bajo este modelo, el trabajo del desarrollador cambia de "¿cómo formulo este aviso?" a "¿cómo diseño el flujo que construye el contexto?" Diseñas cómo las sesiones almacenan eventos estructurados, cómo los recuerdos codifican el conocimiento a largo plazo y cómo los artefactos como PDFs o CSVs se referencian por ID en lugar de ser vertidos en la ventana. Dejas de curar manualmente mega-prompts y comienzas a definir flujos, procesadores y alcances.

El Kit de Desarrollo de Agentes de Google (ADK) incorpora esto en sus APIs. Expone capas de contexto distintas: contexto de trabajo, sesión, memoria, artefactos—y te obliga a conectarlas a través de procesadores explícitos y prefijos de estado como `app`, `user` y `temp`. Esa separación del almacenamiento de la presentación significa que puedes registrar miles de eventos mientras sigues emitendo un aviso conciso y dirigido de menos de 5,000 tokens.

El poder proviene de alcance por defecto. Cada invocación de modelo recibe solo el contexto mínimo necesario para su tarea, ensamblado justo a tiempo por la canalización del compilador. Si un agente necesita más información, llama a herramientas para obtener artefactos o consultar la memoria, en lugar de precargar todo "por si acaso".

Este enfoque de contexto compilado aborda los tres puntos de dolor a la vez. Los recuentos de tokens disminuyen, por lo que el costo y la latencia caen con ellos. “Perdido en el medio” se reduce porque el medio prácticamente desaparece: la historia irrelevante nunca ingresa al contexto de trabajo. Los límites de contexto físico dejan de ser un techo rígido y se convierten en un presupuesto de optimización que controlas con código.

La ingeniería de contexto comienza con una separación clara entre dónde vive la información y cómo el modelo la percibe. El Kit de Desarrollo de Agentes (ADK) de Google incorpora esto en su primer principio: separar el almacenamiento de la presentación. Puede sonar abstracto, pero es la diferencia entre un sistema que puedes evolucionar y uno que se colapsa bajo su propia transcripción.

ADK traza una línea clara entre la Sesión y el Contexto de Trabajo. La Sesión actúa como el libro de registro persistente y autoritario: cada mensaje de usuario, invocación de herramienta, resultado de herramienta y evento del sistema se registra aquí como un estado estructurado. El Contexto de Trabajo es una instantánea desechable creada para una única llamada de LLM, que luego se desecha.

Piensa en la Sesión como tu base de datos y el Contexto de Trabajo como el resultado de una consulta SQL. Nunca mutas la base de datos para que coincida con cada consulta; cambias la consulta. La misma idea aquí: mantienes una Sesión completa y solo para agregar y compilas diferentes Contextos de Trabajo a partir de ella dependiendo de la tarea, el modelo o el presupuesto de latencia.

Esa separación se convierte en crítica en el momento en que tu producto cambia. ¿Quieres cambiar el Gemini 3 Pro por un modelo más pequeño, o pasar de un aviso conversacional extenso a un aviso de ejecución de herramienta más conciso? Actualizas los procesadores que construyen el Contexto de Trabajo, no el esquema de Sesión o los datos históricos. Las interacciones pasadas permanecen intactas, incluso mientras cambias radicalmente la forma en que las enmarcas para el modelo.

La documentación del Kit de Desarrollo de Agentes de Google (ADK) formaliza esto con objetos de contexto distintos y prefijos de estado. El estado respaldado por sesión vive bajo prefijos duraderos como `app` y `user`, mientras que los datos efímeros, solo por invocación, se encuentran bajo `temp`. Solo el Contexto de Trabajo lee a través de esos espacios de nombres y compila una vista mínima para la llamada actual.

El impacto práctico se manifiesta rápidamente en sistemas multiagente. Un agente podría ver un Contexto de Trabajo con solo los últimos 3 intercambios del usuario y un resumen de herramientas; otro podría recibir un resumen sintetizado de una Sesión de 200 mensajes más resultados RAG. Ambos derivan del mismo registro subyacente, pero cada llamada paga solo por los tokens que realmente necesita.

Las ventanas de contexto solían crecer mediante la concatenación de cadenas: mensaje del usuario, respuesta del agente, salida de la herramienta, repitiendo hasta que la factura explota. El Google Agent Development Kit (ADK) elimina eso y lo reemplaza con Transformaciones Explícitas: un pipeline nombrado y ordenado que compila el estado bruto en un aviso funcional. El contexto deja de ser un bloque de texto y se convierte en un artefacto de construcción.

En lugar de `prompt = history + docs + tools`, defines procesadores como `resumir_sesión`, `seleccionar_artículos_relevantes`, `inyectar_instrucciones` y `presupuestar_tokens`. Cada paso tiene un nombre, un contrato y un lugar en la tubería. Puedes registrar cada etapa, comparar salidas entre ejecuciones y cambiar procesadores sin afectar al resto del sistema.

El blog de contexto de Google y los documentos de ADK describen esto como un flujo de procesadores que transforman cuatro capas de estado: sesión, memoria, artefactos y contexto de trabajo. Un agente de investigación de documentos, por ejemplo, podría: - Recuperar decisiones anteriores de la memoria - Clasificar PDFs candidatos de artefactos - Comprimir citas en un resumen de 2,000 tokens - Emitir un aviso mínimo para Gemini 3 Pro

Debido a que los procesadores son explícitos, los equipos pueden realizar pruebas unitarias en ellos. Puedes afirmar que `select_relevant_artifacts` nunca extrae más de 5 documentos, o que `summarize_session` se mantiene por debajo de 1,000 tokens. La depuración deja de ser "¿por qué el modelo alucinó?" y pasa a ser "¿qué procesador inyectó los datos incorrectos?"

Scoped by Default aborda la otra mitad del problema: quién ve qué. En lugar de volcar toda la transcripción multiagente en cada llamada a herramientas, ADK gestiona contexto mínimo y específico para cada rol a través de objetos de contexto tipados. Las herramientas, las devoluciones de llamada y los proveedores de instrucciones reciben cada uno una vista restringida.

Las funciones de herramienta reciben un ToolContext que puede leer y escribir el estado de la sesión, guardar o cargar artefactos y buscar en la memoria. Los controladores de retroalimentación obtienen un CallbackContext con estado y artefactos, pero sin búsqueda en la memoria, lo que previene el caos por canal lateral. Los proveedores de instrucciones ven un contexto de solo lectura, por lo que no pueden mutar el estado de forma secreta al generar prompts del sistema.

El contexto delimitado transforma los sistemas multiagente en una línea de ensamblaje de IA. Una etapa lee los artefactos y produce un resumen estructurado; otra etapa, con un alcance más específico, convierte ese resumen en prosa orientada al usuario; una tercera etapa registra los resultados de nuevo en la memoria. Ningún agente único arrastra toda la historia de 50,000 tokens.

Juntas, las Transformaciones Explícitas y el Alcance por Defecto producen flujos de contexto que son predecibles bajo carga. Sabes exactamente qué procesadores se ejecutan, qué estado pueden tocar y cuántos tokens emiten. Esa disciplina es lo que hace que un modelo de un millón de tokens sea opcional en lugar de obligatorio.

Los agentes conscientes del contexto en el Kit de Desarrollo de Agentes de Google (ADK) operan en una estructura de cuatro capas que trata el contexto como un producto, no como un efecto secundario. Cada capa responde a una pregunta diferente: qué ve el modelo ahora, qué sucedió realmente, qué debería persistir y dónde residen los activos pesados.

En la parte superior se encuentra el contexto de trabajo. Esta es la carga útil temporal y ajustada que ADK compila y envía a Gemini para una única llamada de modelo: mensajes seleccionados, salidas de herramientas, fragmentos de memoria y algunas referencias a artefactos. ADK lo descarta inmediatamente después de la invocación, por lo que nada en el contexto de trabajo es autoritativo por sí mismo.

Bajo eso se encuentra la sesión, el registro canónico y de larga duración de una interacción. Cada mensaje de usuario, respuesta del modelo, llamada a una herramienta y resultado de la herramienta se registra aquí como un objeto de evento estructurado, no como una transcripción plana. Cuando ADK reconstruye un contexto de trabajo, consulta esta línea de tiempo de sesión y aplica procesadores que filtran, resumen o reordenan eventos para la tarea actual.

El conocimiento de larga duración se traslada a la memoria. La memoria guarda las preferencias del usuario (tono, idiomas, hábitos de notificación), hechos duraderos (políticas de empresa, especificaciones de productos) y decisiones destiladas que deberían superar cualquier chat individual. ADK lo presenta a través de APIs de búsqueda de memoria, para que un agente pueda extraer solo los 3-10 elementos que importan en lugar de reproducir 10,000 tokens de historial.

Los artefactos resuelven el problema del "archivo gigante en el aviso". Los artefactos son objetos binarios o de texto grandes—PDFs, CSVs, imágenes, archivos de audio—que se almacenan una vez y se accede a ellos mediante nombres o ID estables, no se pegan en el aviso. Las herramientas leen y escriben artefactos, y el contexto de trabajo solo lleva referencias ligeras más fragmentos extraídos cuando es necesario.

Juntas, estas cuatro capas forman un canal de contexto, no un monolito. Un agente de investigación de documentos, por ejemplo, podría: leer la sesión para encontrar la última pregunta del usuario, buscar en la memoria decisiones previas, cargar un artefacto PDF por ID y luego compilar un contexto operativo con solo unos pocos párrafos y citas relevantes. El costo y la latencia se escalan con esa porción compilada, no con el corpus en bruto.

Las propias pautas de Google instan a los equipos a tratar estas capas como superficies de diseño de primera clase. La Documentación de Contexto del ADK expone cómo el contexto de trabajo, la sesión, la memoria y los artefactos se asignan a tipos concretos, permisos y procesadores para que los sistemas de múltiples agentes se mantengan rápidos, económicos y fundamentados a medida que crecen las cargas de trabajo.

State hace que una IA se sienta persistente en lugar de tener memoria de pez dorado, y el Kit de Desarrollo de Agentes de Google (ADK) incorpora eso directamente en su API de contexto con un sistema de prefijos engañosamente simple. En lugar de entregar a los agentes una masa amorfa de "memoria", el ADK divide el estado en espacios de nombres temp:, user: y app: que se alinean claramente con el funcionamiento real del software.

Comienza con temp:, el bloc de notas. Cualquier cosa que escribas debajo de `temp:` vive por una única invocación y luego desaparece. Una herramienta puede almacenar un CSV parseado bajo `temp:parsed_doc`, otra herramienta puede leerlo 200 ms después, y una vez que el agente responde, ADK lo borra—sin riesgo de contaminar la historia a largo plazo con intermediarios innecesarios.

Sube de nivel y usuario: se convierte en la memoria real del agente sobre una persona. Claves como `usuario:nivel_de_lectura`, `usuario:últimos_proyectos` o `usuario:fuentes_bloqueadas` persisten a lo largo de las sesiones siempre que conectes ADK a un almacenamiento externo. Un asistente de investigación incorporado en la demostración puede recordar qué documentos un usuario ya resumió la semana pasada y evitar volver a recuperarlos o reexplicarlos.

En la parte superior se encuentra app:, el estado global para toda la implementación. Las banderas de características (`app:enable_vision`), los límites de tasa a nivel del sistema o las referencias de índices de embeddings compartidos residen aquí. Cada instancia de agente y cada usuario pueden leer estos valores, por lo que puedes cambiar una configuración una vez y observar cómo el comportamiento cambia en cientos de sesiones concurrentes.

Juntos, estos tres prefijos te ofrecen una jerarquía de estados concreta sin la necesidad de inventar un marco personalizado. Obtienes: - temp: para conexiones por turno entre herramientas - user: para memoria por identidad - app: para configuración entre usuarios

Esa jerarquía codifica directamente los principios de diseño de ADK. Separar el almacenamiento de la presentación: el estado vive bajo `temp:`, `user:` o `app:`, mientras que el contexto de trabajo es una porción compilada de esas claves. Transformaciones explícitas: las herramientas y procesadores leen y escriben prefijos específicos en lugar de mutar un gran aviso. Alcance por defecto: `temp:` nunca se filtra más allá de un turno, `user:` nunca se convierte accidentalmente en global, y `app:` nunca se convierte en un comportamiento específico de usuario de forma silenciosa.

El Kit de Desarrollo de Agentes de Google (ADK) convierte toda esa teoría del contexto en un bot de investigación funcional. La demo de Yeyu Lab crea un asistente de documentos que puede buscar, abrir y analizar archivos sin necesidad de introducir PDF completos en el aviso. En cambio, compila solo el contexto necesario para cada llamada a Gemini 1.5 o Gemini 2.0.

El diseño se basa en un patrón de carga bajo demanda. La herramienta `list_documents` devuelve solo metadatos livianos: IDs de documentos, títulos, quizás tamaños en bytes y marcas de tiempo. El modelo ve una tabla compacta de opciones, no 200 páginas de texto sin procesar.

Cuando el usuario elige algo como "analizar el informe trimestral", el agente llama a `analyze_document`. Esa herramienta extrae el archivo completo del almacenamiento de artefactos, realiza la fragmentación o el resumen, y solo entonces presenta los resultados destilados al modelo. El LLM nunca recibe el documento original en línea; solo obtiene las partes procesadas que solicitó.

Las herramientas se coordinan a través del estado `temp:` en lugar de arrastrar cargas útiles a través del cable. `list_documents` escribe `temp.current_doc_id = "report_q2_2024"`; `analyze_document` lee esa misma clave y sabe exactamente qué artefacto cargar. Sin blobs en base64, sin JSONs de 50,000 tokens rebotando entre herramientas.

Ese ámbito `temp:` vive una única invocación, lo que mantiene el contexto de trabajo minimalista. Un turno típico podría incluir la solicitud del usuario, un breve aviso del sistema, una lista de documentos compacta y una cadena `current_doc_id`, y aún así se sentiría como un flujo de trabajo rico en múltiples pasos. El Kit de Desarrollo de Agentes de Google (ADK) se encarga de la infraestructura para que el modelo se concentre en el razonamiento.

El comportamiento a largo plazo depende del estado de `user:`. Cuando alguien dice: "Prefiero resúmenes breves", una herramienta o callback escribe `user.summary_style = "breve"`. Las futuras llamadas—mañana, la próxima semana, en un dispositivo diferente—pueden leer esa clave y producir automáticamente resúmenes de 3 oraciones en lugar de desgloses de 3 páginas.

Las preferencias pueden acumularse sin inflar las solicitudes. Podrías rastrear: - `user.domain_focus = "finanzas"` - `user.citation_format = "APA"` - `user.summary_style = "breve"`

Cada invocación compila solo el subconjunto relevante en el contexto de trabajo. Nadie reproduce un registro de chat de 200 turnos solo para recordar que al usuario no le gustan los viñetas.

La inteligencia de este agente proviene del uso eficiente de herramientas, no de una ventana de contexto monstruosa. El modelo emite llamadas a herramientas precisas, salta entre los estados `temp:` y `user:`, y toca artefactos solo cuando es necesario. El Kit de Desarrollo de Agentes de Google (ADK) acaba efectivamente con la idea de que necesitas volver a leer todo tu historial cada vez solo para actuar de manera inteligente.

La ingeniería de prompts solía significar encantamientos ingeniosos y trucos frágiles. La Ingeniería de Contexto, según lo enmarcado por el blog de contexto de Google y el Kit de Desarrollo de Agentes de Google (ADK), eleva ese papel a algo más cercano a la arquitectura de sistemas distribuidos para modelos de lenguaje.

En lugar de obsesionarse con un único mega-prompt, los desarrolladores ahora diseñan flujos: cómo las sesiones, el estado, la memoria y los artefactos fluyen a través de procesadores en un contexto de trabajo compilado. La pila de cuatro capas de ADK—contexto de trabajo, registro de sesión, memoria a largo plazo y artefactos externos—convierte “¿qué hay en el prompt?” en “¿qué sistema produjo esta vista y por qué?”.

Ese cambio marca una clara maduración en el desarrollo de la IA. Tú defines: - Qué datos residen dónde - Qué transformaciones se ejecutan cuándo - Qué agente o herramienta ve qué ámbito

El resultado: el comportamiento deja de sentirse mágico y comienza a sentirse depurable.

La fiabilidad aumenta porque cada fragmento de contexto tiene una receta explícita. Si un agente tiene una alucinación, inspeccionas los procesadores y prefijos que construyeron su visión, no un bloque de 40,000 tokens. Los prefijos de estado de ADK (`app`, `user`, `temp`) y los contextos delimitados (herramienta, callback, invocación) te proporcionan palancas para reproducir errores, escribir pruebas y razonar sobre modos de fallo.

La predictibilidad mejora porque los agentes ya no absorben historias completas. Solicitan artefactos por ID, buscan en la memoria con consultas controladas y escriben en segmentos de estado limitados. Los costos también descienden: solo transmites el contexto mínimo compilado por llamada en lugar de reproducir semanas de registros en una ventana de un millón de tokens.

Para equipos que buscan producción, esto se asemeja a un plano para backends de múltiples agentes. Un agente orquesta, los agentes especialistas poseen herramientas y recuerdos, y el marco de contexto de ADK garantiza que cada llamada reciba solo la información necesaria. La documentación de Google, incluido Introducción al Contexto Conversacional: Sesión, Estado y Memoria, se lee menos como consejos para prompts y más como una guía de diseño de API.

La Ingeniería del Contexto, tal como se implementa en el Kit de Desarrollo de Agentes de Google (ADK), transforma las aplicaciones de LLM en sistemas que tú arquitectas, no en hechizos que ajustas. Esa es la condición necesaria para despliegues serios, regulados y multi-agente.

¿Listo para intentarlo de verdad? Comienza instalando el Kit de Desarrollo de Agentes de Google (ADK), obteniendo una clave de API de Gemini y leyendo la explicación sobre ingeniería de contexto de Google en el blog de Desarrolladores de Google: Arquitectura de un marco multiagente consciente del contexto eficiente para producción. Esa publicación define la pila de cuatro capas: contexto operativo, sesión, memoria, artefactos—y los tres principios que tu código debería reflejar.

A continuación, dirígete directamente a la documentación oficial de contexto de ADK en google.github.io/adk-docs/context. Enfócate en cómo `InvocationContext`, `ToolContext` y `CallbackContext` regulan el acceso a la sesión, la memoria y los artefactos, y cómo los prefijos `app:`, `user:` y `temp:` implementan un estado específico. Trata estas API como el límite de tu sistema, no solo como clases de ayuda.

Luego, descarga la demostración de Yeyu Lab desde GitHub: context_demo. Ejecuta el asistente de documentos, observa cómo los artefactos se guardan y se referencian por ID en lugar de ser incorporados en los prompts, y sigue cómo las herramientas leen/escriben estado a través de prefijos en lugar de ocultar datos en texto libre. Esta es tu implementación de referencia para un flujo de trabajo Consciente del Contexto de múltiples agentes.

Para un primer proyecto, refactoriza una aplicación RAG existente para que se ajuste a este patrón. Reemplaza tu lógica de “meter todo en el aviso” con:

• 1Un registro de sesión de eventos estructurados
• 2Almacenamiento de artefactos para PDF, CSV y documentos extensos
• 3Búsqueda de memoria en lugar de re-enviar los mismos hechos.
• 4Estado `temp:` para pasar resultados intermedios entre herramientas.

No solo estás ajustando indicaciones; estás diseñando sistemas distribuidos que, por casualidad, se comunican en lenguaje natural. Los desarrolladores que internalizan el contexto como una vista compilada—y que estructuran en torno al estado, artefactos y transformaciones explícitas—serán los que envíen IA lista para producción, mientras que los demás continúan persiguiendo una ventana de contexto más amplia.

¿Qué es la Ingeniería de Contexto?

La Ingeniería de Contexto es un nuevo patrón arquitectónico de Google para agentes de IA. Trata el contexto no como un solo flujo de texto, sino como una 'vista compilada' creada a partir de varias fuentes de datos, como el historial de sesiones, la memoria y archivos externos, optimizada para cada llamada específica del modelo.

¿Por qué son un problema las ventanas de contexto grandes para los agentes de IA?

Aunque aparentemente son poderosas, las ventanas de contexto grandes conducen a una espiral de altos costos y baja latencia. También sufren del problema de 'perderse en el medio', donde los modelos tienen dificultades para encontrar información relevante en un mar de ruido, limitando en última instancia la escalabilidad y la fiabilidad.

¿Cómo implementa el Kit de Desarrollo de Agentes (ADK) de Google estas ideas?

ADK proporciona un marco con primitivas incorporadas para la Ingeniería de Contexto. Separa el almacenamiento persistente (Sesión, Memoria, Artefactos) del 'Contexto de Trabajo' temporal enviado al LLM, utilizando herramientas y gestión del estado para cargar solo lo que es necesario, cuando es necesario.

¿La Ingeniería de Contexto reemplaza la Generación Aumentada por Recuperación (RAG)?

Lo complementa y lo refina. RAG se trata de recuperar datos; la Ingeniería de Contexto se refiere a cómo se estructura, gestiona y presenta ese dato recuperado (y todo otro contexto) al modelo. Proporciona un sistema más robusto y escalable para flujos de trabajo de estilo RAG.