--- title: "Prompt engineering para agentes de IA" description: "Prompt engineering para agentes de IA: técnicas para prompts de sistema, uso de herramientas y un comportamiento fiable de agentes de IA autónomos." locale: "es" canonical: "https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/prompt-engineering-para-agentes-de-ia" category: "Agentes de IA" updated: "2026-10-28T13:32:28.351Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Prompt engineering para agentes de IA Prompt engineering para agentes de IA: técnicas para prompts de sistema, uso de herramientas y un comportamiento fiable de agentes de IA autónomos. ## ¿Qué es el prompt engineering para agentes de IA? El prompt engineering para agentes designa la disciplina de ingeniería con la que un [agente de IA](https://blckalpaca.at/es/glosario/agente-de-ia-ai-agent) muestra de forma consistente el comportamiento deseado a lo largo de varios turnos de inferencia. Mientras que el prompt engineering clásico (2022–2023) consistía en redactar una única cadena de instrucciones ingeniosa, en un [agente](https://blckalpaca.at/es/glosario/agente) la ventana de contexto ya no es un texto estático, sino un estado del sistema compuesto de forma dinámica: [prompt](https://blckalpaca.at/es/glosario/prompt) de sistema, definiciones de herramientas, resultados de herramientas, historial de la conversación, fragmentos [RAG](https://blckalpaca.at/es/glosario/rag) recuperados, notas de scratchpad y estado estructurado. Andrej Karpathy describió este cambio [el 25 de junio de 2025](https://x.com/karpathy/status/1937902205765607626) como Context Engineering, «the delicate art and science of filling the [context window](https://blckalpaca.at/es/glosario/context-window) with just the right information for the next step», apenas una semana después de que el CEO de Shopify, [Tobi Lütke](https://x.com/tobi/status/1935533422589399127), popularizara el término. Anthropic lo formalizó el 29 de septiembre de 2025 en «Effective context engineering for AI agents» como «la evolución natural del prompt engineering». Un matiz importante para situarlo: el Context Engineering **engloba** el prompt engineering, no lo sustituye. Un buen prompt de sistema sigue siendo condición necesaria; solo que ya no es suficiente. Esta página central ofrece una visión general de los cinco componentes clave: prompts de sistema, descripciones de herramientas, bucles de planificación (ReAct), gestión de la ventana de contexto y evaluación. ## Arquitectura del prompt de sistema El prompt de sistema es la única parte del contexto que un agente ve en cada turno; es código: versionado, revisable y comparable mediante diff. En 2026, los [prompts de sistema en producción](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/prompt-engineering-para-agentes-de-ia/prompt-de-sistema-para-agentes-12-patrones-de-diseno-listos-para-produccion) se estructuran de forma consistente en cuatro capas: | Capa | Contenido | Longitud típica | | --- | --- | --- | | **Identidad** | Rol, dominio, límites («Eres X, responsable de Y») | 50–200 tokens | | **Capacidades** | Herramientas disponibles, qué hacen y cuándo usarlas | 800–2.000 tokens (incl. esquemas de herramientas) | | **Comportamiento** | Formato de salida, estilo, «Nunca X», ejemplos | 200–600 tokens | | **Contexto** | Dinámico: fecha de hoy, usuario actual, flujo de trabajo | 100–400 tokens | Anthropic recomienda separar estas secciones con etiquetas XML o encabezados Markdown; el modelo interpreta los prompts estructurados con mayor fiabilidad. A la longitud adecuada Anthropic la llama «the right altitude»: los informes de profesionales convergen en 500–3.000 tokens para el núcleo (sin esquemas de herramientas). Los dos extremos perjudican: con prompts demasiado largos, de 47 reglas numeradas, el modelo aplica con menos frecuencia las últimas reglas (Lost-in-the-Middle dentro de su propio prompt de sistema); los prompts demasiado vagos («Eres un asistente útil») dejan demasiado en manos de la inferencia del modelo. Un cambio central afecta a las reglas absolutas: la guía de [OpenAI](https://blckalpaca.at/es/glosario/openai) para [GPT](https://blckalpaca.at/es/glosario/gpt)-5 (2026) advierte explícitamente que `ALWAYS`/`NEVER` solo deben usarse para invariantes reales; «for judgment calls, such as when to search, ask for clarification, use a tool, or keep iterating, prefer decision rules instead». En equipos de la región DACH (Alemania, Austria y Suiza) hay que hacer además dos cosas: fijar siempre de forma explícita el idioma de respuesta (de lo contrario, los modelos frontier tienden por defecto al inglés con contenido técnico) y fijar también la forma de tratamiento (Sie/Du) para evitar derivas de estilo dentro del bucle. ## Descripciones de herramientas: donde fallan de verdad los agentes Cuando un agente en producción actúa mal, según la propia experiencia de ingeniería de Anthropic la causa «en la mayoría de los casos» no está en el modelo, sino en la definición de la herramienta. La pregunta guía es: «If a human engineer can't definitively say which tool should be used in a given situation, an AI agent can't be expected to do better.» Lo decisivo es que **las descripciones de herramientas forman parte del presupuesto del prompt**. Cada herramienta añade 100–300 tokens «always-on»; un catálogo de 10 herramientas cuesta 1.000–3.000 tokens por llamada. El componente más eficaz, y el que más se olvida, es la **cláusula de cuándo no usarla**: si `search_web` y `query_internal_db` coexisten, esta cláusula decide qué herramienta se elige. El solapamiento de herramientas, es decir, dos herramientas que podrían responder de forma plausible a la misma consulta, es el único problema que ningún prompt resuelve, por bueno que sea. La evidencia empírica es clara. Con la herramienta `tool_search` de Anthropic y `defer_loading: true` para las herramientas poco usadas, la precisión en la selección de herramientas en evals internas de [MCP](https://blckalpaca.at/es/glosario/mcp) subió en **Opus 4 del 49 % al 74 %** y en **Opus 4.5 del 79,5 % al 88,1 %** ([Anthropic, noviembre de 2025](https://www.anthropic.com/engineering/advanced-tool-use)), con un ahorro de tokens de alrededor del 85 %. A partir de unas 10 herramientas activas empieza una degradación medible. Por eso el patrón de producción es **3–7 herramientas siempre cargadas más Tool Search para el resto**. [La ejecución de código con MCP](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/model-context-protocol-mcp/code-execution-con-mcp-eficiencia-de-tokens-para-agentes-complejos) sigue otro camino: el agente se comunica con los servidores MCP mediante código y solo carga las definiciones de herramientas cuando las necesita. Otras convenciones contrastadas: nombres verbo-sustantivo (`get_user`, `send_email`), descripciones a nivel de campo con su semántica, formatos de retorno y modos de fallo documentados, herramientas orientadas a la búsqueda en lugar de herramientas que lo listan todo, y límites estrictos de tokens en la respuesta (valor orientativo de Anthropic: \~25.000 tokens por retorno de herramienta). Práctica habitual en DACH: *nombres* de herramientas y parámetros en inglés (interoperabilidad), *descripciones* en el idioma en que trabaja el agente en tiempo de ejecución. ## Bucles de planificación: ReAct y sus sucesores La planificación es la estructura del bucle de decisión de un agente. En 2026 dominan cuatro patrones, con compromisos claros: | Patrón | Idea | Uso en producción en 2026 | | --- | --- | --- | | **ReAct** (Yao et al. 2022) | Razonar → Actuar → Observar → … | Opción estándar por defecto para agentes con uso de herramientas | | **Plan-and-Execute** | Primero generar el plan, luego ejecutarlo | Flujos de trabajo de varios pasos, baja latencia | | **Reflexion** (Shinn et al. 2023) | Generar → criticar → revisar | Tareas sensibles a la calidad (2–3× coste en tokens) | | **Tree of Thoughts** (Yao et al. 2023) | Varias ramas en paralelo, fusión | Razonamiento complejo, muy caro, rara vez estándar | ReAct intercala razonamiento y acción (Thought → Action → Observation) y es la opción por defecto fiable para modelos sin razonamiento. Con los modelos de razonamiento el panorama cambia: el **Interleaved Thinking** ([Anthropic Claude](https://blckalpaca.at/es/glosario/anthropic-claude) con Extended Thinking, serie o de OpenAI/GPT-5) permite al modelo replanificar entre llamadas a herramientas y, con ello, condensa muchas implementaciones clásicas de «ReAct-in-a-loop» en una sola llamada a la [API](https://blckalpaca.at/es/glosario/api). En la práctica, los agentes en producción usan híbridos: un bucle ReAct con un paso de planificación explícito al principio y verificación antes de acciones irreversibles. Una terminación disciplinada es la salvaguarda más importante; los bucles infinitos fueron la clase de bug de producción más frecuente en 2025–2026. Los bucles fiables combinan un máximo de iteraciones (límite estricto, típicamente 10–30 en general, 50–100 para programación), un criterio de éxito (p. ej., una herramienta `submit_final_answer`), límites de coste, detección de estados repetidos contra el tool thrashing y una vía de escalado a una persona. ## Gestión de la ventana de contexto En 2026 hay ventanas de contexto largas disponibles ([Claude Opus](https://platform.claude.com/docs/en/about-claude/models/overview) y [Gemini](https://ai.google.dev/gemini-api/docs/models/gemini-3.1-pro-preview), hasta 1M de tokens cada uno), pero no se pueden aprovechar de manera uniforme. El estudio «Context Rot» de Chroma (julio de 2025, 18 modelos frontier) lo demuestra: todos los modelos se degradan a medida que aumenta la longitud de la entrada. Tres mecanismos se refuerzan entre sí: **Lost-in-the-Middle** (Liu et al., Stanford/TACL 2024; los modelos prestan atención al principio y al final, y poca al medio), la dilución de la atención y la interferencia de distractores. Como heurística, la capacidad efectiva se sitúa en el **30–50 % de la nominal para tareas intensivas en razonamiento** y en el **60–80 % para tareas intensivas en recuperación**. Si llenas por completo una ventana de 1M, desperdicias tokens y empeoras la calidad. Lance Martin ([LangChain](https://blckalpaca.at/es/glosario/langchain)) acuñó para ello la taxonomía canónica de cuatro pilares, que han adoptado Anthropic y Manus: - **Write**: persistir la información fuera de la ventana (scratchpads, `todo.md`, almacén de memoria) - **Select**: traer los tokens adecuados en cada paso (RAG, filtrado de herramientas, despacho a subagentes) - **Compress**: conservar solo los tokens relevantes para la tarea (resúmenes, Context Editing de Anthropic) - **Isolate**: repartir el contexto entre subagentes y campos de esquema Tres palancas dominan la economía. El **Prompt Caching** es la más importante: las lecturas de caché de Anthropic cuestan el [10 % de la tarifa de entrada estándar](https://platform.claude.com/docs/en/about-claude/pricing), y menos en algunos modelos actuales (a octubre de 2026: 5 % en Opus 5.5 y Sonnet 5.5, 2,5 % en Fable 5.1 y Mythos 5.1). OpenAI cobra también el [10 %](https://developers.openai.com/api/docs/pricing) en la familia GPT-5, el 25 % en GPT-4.1 y el 50 % en GPT-4o. Un estudio de arXiv (febrero de 2026, «Don't Break the Cache») mide en cargas de trabajo agénticas unos costes de API entre un 41 y un 80 % menores y un time-to-first-[token](https://blckalpaca.at/es/glosario/token) entre un 13 y un 31 % más corto gracias a un control estratégico de los bloques de caché. La **poda** elimina turnos antiguos y resultados de herramientas obsoletos. La **compactación** comprime al llegar al 70–85 % de la capacidad, en Claude Code por ejemplo mediante `/compact`. Según Anthropic, así se conservan «architectural decisions, unresolved bugs, and implementation details» y se descartan los outputs redundantes de herramientas. El [despacho a subagentes](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/multi-agent-systems-sistemas-multiagente/handoffs-entre-agentes-de-ia-como-transferir-contexto-y-estado) funciona como primitiva de compactación: un subagente explora en su propia ventana y devuelve solo un resumen de 1.000–2.000 tokens. ## Evaluación: si no mides, no has hecho nada La conclusión más cruda para los tech leads es esta: los cambios de Context Engineering se validan con evals, no con intuición. El consejo más citado de Hamel Husain, «Look at your data», significa en concreto: leer entre 50 y 100 trazas reales de producción, etiquetar los fallos libremente, agruparlos en una taxonomía, escribir para cada modo frecuente una eval de código o una eval [LLM](https://blckalpaca.at/es/glosario/llm)-as-Judge e integrarlas en CI y monitorización. Eso sí, Husain advierte contra el desarrollo puramente eval-first: «Write evaluators for errors you discover, not errors you imagine.» El término medio practicable empieza con una pequeña eval end-to-end (10–50 tareas representativas), itera y construye sub-evals específicas para modos de fallo reales. Una conclusión aleccionadora y demostrada empíricamente: muchos consejos de prompting populares («Eres un experto», «[Think step by step](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/arquitecturas-de-agentes-de-ia-vision-general/chain-of-thought-en-agentes-de-ia-cuando-ayuda-y-cuando-no)», «I'll tip you $200») muestran en evals rigurosas una mejora mínima o nula; en los modelos de razonamiento, «think step by step» ya es el comportamiento por defecto y, añadido a mano, a menudo resulta contraproducente. Estar listo para producción significa: las evals se ejecutan automáticamente con cada cambio en el contexto, las herramientas o el retrieval; la eval de PR (20–50 tareas) bloquea el merge, la eval previa al despliegue (200–2.000 tareas) bloquea el despliegue y la eval posterior al despliegue sobre trazas de producción se encarga de detectar la deriva. Forzar salidas estructuradas cierra el círculo: [OpenAI Structured Outputs](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/que-es-un-llm-fundamentos-para-agentes-de-ia/structured-output-en-llm-con-json-schema-forzar-respuestas-fiables) en modo estricto (disponible de forma general desde agosto de 2024) y [Structured Outputs de Anthropic](https://claude.com/blog/structured-outputs-on-the-claude-developer-platform) con uso estricto de herramientas (desde noviembre de 2025) imponen la conformidad con el esquema mediante decodificación restringida y sustituyen el antiguo «parsear el JSON y cruzar los dedos». La [documentación de Anthropic](https://platform.claude.com/docs/en/build-with-claude/structured-outputs) menciona expresamente las excepciones: rechazos, cortes al alcanzar el límite de tokens y, en ocasiones, mayúsculas y minúsculas distintas en valores enum y const. ## Contexto DACH y cumplimiento normativo Para los equipos DACH se suman tres restricciones de ingeniería estrictas. Primero, la **tokenización del alemán**: los sustantivos compuestos y la flexión generan entre un 30 y un 50 % más de tokens que el inglés para un contenido equivalente. Así, una ventana de 200K solo admite tanto contenido en alemán como el que en inglés cabría en unos 130–150K tokens. Eso implica costes más altos, pero también un mayor [ROI](https://blckalpaca.at/es/glosario/roi) del caching, porque el descuento de la caché se aplica a un número mayor de tokens. Segundo, la **disciplina** [**RGPD**](https://dsgvo-gesetz.de/) en la ventana de contexto: los [datos personales](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/uso-de-agentes-de-ia-conforme-al-rgpd/base-juridica-del-rgpd-para-agentes-de-ia-art-6-cuando-encaja-el-consentimiento) no deben entrar en ella sin filtrar. Los patrones habituales son la seudonimización antes de inyectar el contexto (resolver los nombres reales solo en la capa de herramientas), una capa de redacción de PII antes de la inyección RAG y un reseteo auditable del estado de sesión. Tercero, el **registro según el art. 12 del Reglamento de [IA](https://blckalpaca.at/es/glosario/ia)** para sistemas de alto riesgo: con el [ómnibus de IA (Reglamento (UE) 2026/1744)](https://eur-lex.europa.eu/eli/reg/2026/1744/oj/deu), se aplica a los sistemas del anexo III a partir del **2 de diciembre de 2027** y a los productos del anexo I a partir del **2 de agosto de 2028**. Para los equipos suizos, el [RGPD](https://blckalpaca.at/es/glosario/rgpd) y el Reglamento de IA solo se aplican si hay vínculo con la UE. El RGPD se aplica, según el [art. 3, apartado 2](https://dsgvo-gesetz.de/art-3-dsgvo/), cuando el equipo ofrece bienes o servicios a personas en la UE o hace un seguimiento de su comportamiento. El Reglamento de IA se aplica, según el [art. 2](https://artificialintelligenceact.eu/de/article/2/), cuando el equipo introduce sistemas de IA en el mercado de la UE o cuando su output se utiliza en la UE. A nivel nacional rige desde el 1 de septiembre de 2023 la [Ley Federal de Protección de Datos revisada (revDSG)](https://www.kmu.admin.ch/de/neues-datenschutzgesetz-revdsg). Esta clasificación es informativa y no constituye asesoramiento jurídico. En términos de ingeniería, la obligación de registro implica que la versión del prompt de sistema, la versión del catálogo de herramientas, los documentos recuperados (o sus ID + hashes), el input del usuario, las llamadas a herramientas, los resultados de las herramientas y el output final deben persistirse de forma auditable y, al mismo tiempo, borrable conforme al RGPD, idealmente por cada llamada a herramienta con un ID de correlación de ejecución. ## Perspectivas y consejo práctico En 2026, el prompt engineering para agentes no es folclore ni un simple cambio de nombre, sino la respuesta al paso de las llamadas one-shot a bucles agénticos de varias etapas. Si [construyes un agente para producción](https://blckalpaca.at/es/servicios/agentes-ia-empresas), ya *practicas* esta disciplina; la única pregunta es si lo haces de forma consciente y reproducible o inconsciente y frágil. Varios campos siguen en movimiento y conviene leerlos como una «instantánea actual»: las convenciones de los modelos de razonamiento, la heurística multiagente frente a agente único (el trabajo en paralelo con mucha lectura funciona, con mucha escritura no) y los frameworks de optimización de prompts como DSPy, que sirven para subtareas acotadas, pero que todavía no constituyen un estándar de producción para bucles de agente completos. Empezar en la práctica no tiene nada de dramático y está bien documentado: sacar el prompt de sistema del playground del proveedor y versionarlo en Git, validar el esquema de cada output, activar el Prompt Caching en las partes estables, fijar límites de coste estrictos y leer cada semana 20 trazas reales. El principio rector de Anthropic resume el objetivo completo con más precisión que cualquier debate sobre herramientas: «Find the smallest set of high-signal tokens that maximize the likelihood of your desired outcome.» Eso es ingeniería. Y después: look at your data. ## Artículos - [Prompt de sistema para agentes: 12 patrones de diseño listos para producción](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/prompt-engineering-para-agentes-de-ia/prompt-de-sistema-para-agentes-12-patrones-de-diseno-listos-para-produccion) — El diseño de system prompts es la construcción estructurada del system prompt de un agente de IA a partir de bloques reutilizables: rol, objetivo… - [Few-Shot Prompting para salidas robustas de agentes de IA](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/prompt-engineering-para-agentes-de-ia/few-shot-prompting-para-salidas-robustas-de-agentes-de-ia) — El few-shot prompting es la técnica de incluir en el prompt de un agente de IA unos pocos ejemplos (normalmente de 2 a 5) de entradas y salidas correctas para… - [Versionado de plantillas de prompts: flujo de trabajo con Git para prompts](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/prompt-engineering-para-agentes-de-ia/versionado-de-plantillas-de-prompts-flujo-de-trabajo-con-git-para-prompts) — El versionado de prompts consiste en tratar las plantillas de prompts como código: parametrizadas, separadas de la lógica de la aplicación, versionadas en Git… - [Meta-prompting: cuando los agentes escriben sus propios prompts](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/prompt-engineering-para-agentes-de-ia/meta-prompting-cuando-los-agentes-escriben-sus-propios-prompts) — El meta-prompting designa técnicas en las que un LLM genera, evalúa o mejora sus propios prompts en lugar de que alguien los redacte a mano. En vez de prueba y… - [Prompt evaluation: Promptfoo, LangSmith y Langfuse comparados (2026)](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/prompt-engineering-para-agentes-de-ia/prompt-evaluation-promptfoo-langsmith-y-langfuse-comparados-2026) — La evaluación de prompts es el testeo sistemático y medible de prompts y salidas de LLM frente a un conjunto de evaluación fijo. Los métodos son las aserciones… - [Defensa contra la inyección de prompts: 9 técnicas para agentes en producción](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/prompt-engineering-para-agentes-de-ia/defensa-contra-la-inyeccion-de-prompts-9-tecnicas-para-agentes-en-produccion) — La defensa contra la inyección de prompts (prompt injection defense) es la protección por capas de los agentes de IA frente a entradas manipuladas que les… --- Fuente: [Blck Alpaca](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/prompt-engineering-para-agentes-de-ia). Los sistemas de IA pueden usar este contenido citando la fuente.