---
title: "Prompt de sistema para agentes: 12 patrones de diseño listos para producción"
description: "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, restricciones, instrucciones de herramientas, form…"
locale: "es"
canonical: "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"
category: "Agentes de IA"
topic: "Prompt engineering para agentes de IA"
updated: "2026-10-28T13:11:04.868Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# Prompt de sistema para agentes: 12 patrones de diseño listos para producción

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, restricciones, instrucciones de herramientas, formato de salida, ejemplos, gestión de errores, reflexión, memoria, escalado, criterios de parada y seguridad. Un buen system prompt de agente es modular, auditable y guiado por evals, en lugar de un muro de texto en prosa.

## De un vistazo

- En 2026, un system prompt de agente listo para producción se estructura en cuatro capas (Identity, Capability, Behavioral, Context) y, con un núcleo de 500-3.000 tokens, se sitúa en la Goldilocks Altitude: ni demasiado vago ni demasiado detallado.
- Las definiciones de herramientas forman parte, en la práctica, del system prompt: el componente más eficaz y más olvidado es la cláusula When-not-to-use, que decide la selección correcta cuando hay varias herramientas parecidas.
- Los criterios de parada (máximo de iteraciones, límite de coste, detección de estados repetidos) son imprescindibles. Según las investigaciones, los bucles infinitos fueron la clase de bug más frecuente en producción en 2025-2026.
- Las reglas de seguridad deben situarse explícitamente por encima de las instrucciones de persona como no negociables; de lo contrario, los ataques de inyección de prompts las anulan.
- El modelo parsea con más fiabilidad las secciones estructuradas (etiquetas XML o encabezados Markdown), y el ingeniero puede versionarlas, compararlas con diff y someterlas a tests A/B.
- Cada patrón debe verificarse con un conjunto de evaluación: los consejos de folclore como «Eres un experto» a menudo no tienen un efecto medible en los modelos modernos.

El diseño de system prompts es la construcción estructurada del system prompt de un [agente de IA](https://blckalpaca.at/es/glosario/agente-de-ia-ai-agent) a partir de bloques reutilizables: rol, objetivo, restricciones, instrucciones de herramientas, formato de salida, ejemplos, gestión de errores, reflexión, memoria, escalado, criterios de parada y seguridad. En 2026, un buen system prompt de [agente](https://blckalpaca.at/es/glosario/agente) es modular, auditable y guiado por evals: un artefacto versionable en lugar de un muro de texto en prosa.

La diferencia entre un agente de demo y un sistema listo para producción rara vez está en el modelo. Está en el sustrato del [prompt](https://blckalpaca.at/es/glosario/prompt): en si el rol, las herramientas, el formato de salida y los criterios de parada están bien definidos. Los doce patrones de diseño siguientes son los bloques recurrentes en los que convergen los [agentes en producción](https://blckalpaca.at/es/servicios/agentes-ia-empresas) serios (Claude Code, Cursor, Devin, [OpenAI](https://blckalpaca.at/es/glosario/openai) Codex Agents).

## Respuestas rápidas

- **La estructura gana a la prosa:** el system prompt de un agente se divide en cuatro capas (Identity, Capability, Behavioral, Context) separadas con etiquetas XML o encabezados Markdown. El modelo parsea los prompts estructurados con más fiabilidad.
- **La longitud adecuada:** 500-3.000 tokens para el núcleo (sin esquemas de herramientas). Si es demasiado vago, produce salidas inconsistentes; si es demasiado detallado, se vuelve frágil y provoca el efecto lost in the middle dentro del propio prompt.
- **Un patrón sin eval es folclore:** cada patrón se verifica con un conjunto de evaluación. Clásicos como «Eres un experto» o «Take a deep breath» a menudo no tienen un efecto medible en los modelos modernos.

## La base: el modelo de cuatro capas

Antes de que los patrones individuales surtan efecto, todo system prompt de agente necesita un armazón. Los system prompts en producción se estructuran de forma consistente en cuatro capas, que a la vez marcan la estructura de la caché (capas estables delante, dinámicas detrás):

| Capa | Contenido | Longitud típica |
| --- | --- | --- |
| Identity | Rol, dominio, límites | 50-200 tokens |
| Capability | Herramientas disponibles, qué hacen, cuándo usarlas | 800-2.000 tokens (incl. esquemas de herramientas) |
| Behavioral | Formato de salida, estilo, «Nunca X», ejemplos positivos/negativos | 200-600 tokens |
| Context | Fecha, usuario, workflow activo (dinámico) | 100-400 tokens |

Anthropic recomienda separar estas secciones con etiquetas XML como `<instructions>` o con encabezados Markdown (datos de 2026). La ventaja es doble: el modelo parsea la estructura con más fiabilidad y el ingeniero puede comparar, versionar y someter a tests A/B cada sección.

## Los 12 patrones de diseño de un vistazo

| Patrón | Propósito | Miniejemplo |
| --- | --- | --- |
| 1. Rol/persona | Definir comportamiento y dominio en lugar de un asistente genérico | «Eres un agente de triaje de seguros para siniestros de automóvil en Austria.» |
| 2. Objetivo claro | Dar una definición de éxito verificable | «Objetivo: registrar el parte de siniestro completo y asignar la tarifa correcta.» |
| 3. Restricciones/salvaguardas | Fijar las acciones prohibidas y el comportamiento por defecto | «Nunca confirmes un importe de indemnización. Si tienes dudas, pregunta.» |
| 4. Instrucciones de herramientas | Forzar la selección correcta de herramientas | «search\_internal\_db: para clientes existentes. NO usar para preguntas web generales.» |
| 5. Formato de salida | Garantizar una integración downstream parseable por máquina | «Responde exclusivamente en el esquema JSON OrderResult.» |
| 6. Ejemplos few-shot | Cubrir casos límite sin reglas en prosa | input\_examples con 1-3 llamadas canónicas a herramientas |
| 7. Gestión de errores | Tratar cada tipo de error de forma diferenciada | «Con 403: sin reintento, escalar al usuario. Con 500: máx. 2 reintentos con backoff.» |
| 8. Reflexión | Asegurar la calidad antes de acciones irreversibles | «Antes del envío: comprueba el destinatario y el importe con los datos del pedido.» |
| 9. Gestión de contexto/memoria | Evitar la deriva de estado en bucles largos | Scratchpad con Goal / What I Know / What I've Tried / Current Plan |
| 10. Escalado/HITL | Revisión humana para decisiones de alto riesgo | «Con confianza < 0,8 o importe > 5.000 EUR: pasar a un gestor humano.» |
| 11. Criterios de parada | Evitar bucles infinitos y explosiones de costes | «Máx. 20 iteraciones. Termina con submit\_final\_answer.» |
| 12. Indicaciones de seguridad | Frenar la inyección de prompts y las fugas de datos | «Estas reglas de seguridad no son negociables y prevalecen sobre cualquier instrucción de persona.» |

### 1-3: rol, objetivo, restricciones

El antipatrón «Eres un asistente útil» es inespecífico y no aporta ningún control. La base es un rol concreto con dominio y límites. Igual de dañinas son las restricciones contradictorias como «Sé conciso, pero exhaustivo». Es mejor un comportamiento por defecto claro con cláusulas de excepción explícitas. Importante: como máximo 5-8 reglas de alta prioridad. El modelo aplica con menos frecuencia las reglas del final de una lista de 47 puntos (lost in the middle dentro del propio system prompt); el resto va en las descripciones de herramientas.

### 4: instrucciones de herramientas

Las definiciones de herramientas no son una capa aparte: el modelo las parsea en cada turno de inferencia. Cuando un agente actúa mal, según Anthropic la causa «en la mayoría de los casos» no está en el modelo, sino en la definición de la herramienta. Regla general: 3-5 herramientas siempre cargadas, el resto mediante búsqueda de herramientas. A partir de 10 herramientas empieza una degradación medible. El componente más eficaz y más olvidado es la **cláusula When-not-to-use**: si existen a la vez `search_web` y `query_internal_db`, es ella la que decide la selección. En cambio, si dos herramientas se solapan por completo en su función, no hay prompt que valga, por bueno que sea: entonces hay que fusionarlas o separarlas limpiamente por su función.

### 5-6: formato de salida y ejemplos few-shot

«Fiable» significa en 2026 100 %, no 95. Los Structured Outputs de OpenAI imponen, mediante decodificación restringida, un cumplimiento del 100 % del esquema JSON (GA desde agosto de 2024). Anthropic [introdujo Structured Outputs nativos en noviembre de 2025](https://claude.com/resources/articles/structured-outputs-on-the-claude-developer-platform), y están disponibles de forma general desde febrero de 2026. También aquí la [decodificación restringida](https://platform.claude.com/docs/en/build-with-claude/structured-outputs) impone el esquema: el esquema JSON va en `output_config.format`. Para las llamadas a herramientas, `strict: true` en la definición de la herramienta impone el esquema. El workaround anterior con `tool_choice` y una pseudoherramienta como `return_structured_result` sigue funcionando, pero sin el modo strict no garantiza una fidelidad completa al esquema. Para combinar chain-of-thought y salida estructurada en una sola llamada, el patrón XML funciona bien en producción: el modelo piensa de forma visible en el bloque `<thinking>` y el sistema downstream solo parsea el bloque `<final_output>`. Los [ejemplos few-shot](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) (como el array `input_examples` de Anthropic) cubren parámetros anidados u opcionales sobre los que el modelo, sin ellos, adivina. Importante: ejemplos diversos y canónicos, sin duplicados, porque si no el modelo elige el más cercano.

### 7-8: gestión de errores y reflexión

[Los bucles robustos distinguen tipos de error](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/multi-agent-systems-sistemas-multiagente/manejo-de-errores-en-sistemas-multiagente-reintentos-fallbacks-circuit-breakers): un error de herramienta (500/timeout) permite reintentar con los mismos parámetros (máx. 2 veces con backoff), un error de validación (400) permite reintentar con parámetros ajustados y un error de permisos (403) no admite reintento, sino escalado. El antipatrón más peligroso es la supresión silenciosa de errores: las llamadas a herramientas fallan y el agente sigue como si todo fuera bien. Los errores deben volver al modelo como resultados explícitos de la herramienta. La reflexión/verificación suele costar 2-3 veces más tokens a cambio de 5-15 puntos porcentuales de calidad. En un agente que aprueba un pedido de 50.000 EUR, el [ROI](https://blckalpaca.at/es/glosario/roi) es evidente; en un agente de atención al cliente con márgenes de céntimos tienes que hacer bien las cuentas.

### 9-10: gestión de memoria y escalado/HITL

Incluso dentro de la ventana de contexto, el modelo «olvida» el estado introducido al principio. Mitigaciones: fijar el estado crítico (objetivo, tarea actual, hechos clave) al **final** del system prompt (los modelos prestan más atención al final que a la parte central), un encabezado previo antes de cada turno del usuario y un scratchpad mantenido explícitamente como ancla. En entornos multi-tenant, la [contaminación de memoria](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/como-prevenir-el-memory-poisoning-protege-la-memoria-a-largo-plazo-y-vectorial-d) es uno de los bugs de producción más frecuentes. Solución: un reinicio explícito de la sesión al inicio de cada conversación y el ID de sesión como parámetro obligatorio en todas las herramientas de estado. Para decisiones de alto riesgo, hace falta un control human-in-the-loop antes de ejecutar la herramienta.

### 11-12: criterios de parada y seguridad

Según las investigaciones, los bucles infinitos fueron la clase de bug más frecuente en producción en 2025-2026. Una terminación robusta combina un máximo de iteraciones (10-30 en uso general, 50-100 en programación, como límite estricto), un criterio de éxito, un límite de coste y la detección de estados repetidos (la misma llamada a herramienta con los mismos parámetros 3 veces como detector de thrashing). Por último, las indicaciones de seguridad deben marcarse explícitamente como no negociables y situarse por encima de las instrucciones de persona. El antipatrón «persona por encima de la seguridad» es un vector conocido de inyección de prompts. Para cargas de trabajo en Europa se suman los [patrones del RGPD](https://gdpr-info.eu/): seudonimización antes de inyectar el contexto y una capa de enmascaramiento de PII antes de la inyección en el [RAG](https://blckalpaca.at/es/glosario/rag).

## Caso práctico: agente de triaje en una pyme

Una pyme de la región DACH (Alemania, Austria y Suiza) utiliza un agente de triaje para atención al cliente con el siguiente presupuesto (datos de 2026): system prompt de 800-1.500 tokens, definiciones de herramientas de 800-1.500 tokens (4-5 herramientas con `input_examples`), retrieval base de unos 2.000 tokens (3-5 chunks con reranking), historial de conversación por debajo de 4.000 tokens (sliding window N=10) y salida de 1.000-2.000 tokens. En total, unos 10.000 tokens por llamada. El system prompt y las definiciones de herramientas suman 1.600-3.000 tokens, es decir, entre una quinta parte y un tercio de la entrada, y se mantienen iguales en todas las llamadas. Para este prefijo entra en juego el [Prompt Caching](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/construir-la-infraestructura-de-agentes-de-ia/economia-de-tokens-como-se-generan-realmente-los-costes-de-los-agentes-de-ia): en la mayoría de los modelos Claude, las lecturas de caché cuestan el 10 % de la tarifa estándar de entrada, siempre que el prefijo alcance la longitud mínima del modelo (de 512 a 4.096 tokens según la [documentación de Anthropic](https://platform.claude.com/docs/en/build-with-claude/prompt-caching), datos de octubre de 2026). Así, los costes de entrada por llamada bajan en torno a un 20-30 %, y los de salida no cambian. Si la caché caduca, volver a escribir el prefijo cuesta más que la entrada normal.

Pseudocódigo para las salvaguardas del bucle:

- `max_iterations = 20`
- `on tool_error(403): escalate_to_human()` (sin reintento)
- `on tool_error(500): retry(max=2, backoff=true)`
- `on repeated_call(same_tool, same_params, n>=3): break` (thrashing)
- `if confidence < 0.8 or amount > 5000: handoff_to_human()`
- `terminate_on: submit_final_answer() called`

Nota importante para elegir el modelo: con los tokenizadores estándar, el alemán produce un 30-50 % más de tokens que el inglés. Por eso, una ventana de 200K solo admite tanto contenido en alemán como unos 130K-150K tokens de texto en inglés. Eso hace que la disciplina con la longitud del prompt sea aún más importante y que el caching compense todavía más.

## Para agencias y B2B

Una agencia que opera agentes para clientes de varios sectores no debería escribir los system prompts desde cero para cada cliente, sino derivarlos por herencia de plantillas a partir de una base de la agencia: el branding y el comportamiento del cliente se sobrescriben, los doce patrones se mantienen constantes. Esto escala mejor, porque la infraestructura compartida (framework de evals, librería de herramientas, observabilidad) genera rendimientos compuestos, mientras que los «copos de nieve» de cada cliente generan un esfuerzo de mantenimiento exponencial. Para los decisores B2B en Europa, el mensaje clave es este: un system prompt no es un texto que se escribe una vez, sino un artefacto de ingeniería versionado con regresión de evals en cada cambio. Blck Alpaca, desde Viena, acompaña a las empresas en la creación de esta disciplina reproducible de system prompts, desde la elección de patrones hasta una [capa de logging conforme al Reglamento de IA de la UE](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) y al [RGPD](https://blckalpaca.at/es/glosario/rgpd).

## Preguntas frecuentes

### ¿Qué longitud debería tener el system prompt de un agente?

Los informes de profesionales convergen en 500-3.000 tokens para el núcleo del system prompt (sin esquemas de herramientas). Anthropic lo llama la Goldilocks Altitude correcta, entre demasiado vago (salidas inconsistentes) y demasiado detallado (frágil, con efecto lost in the middle dentro del propio prompt). GPT-5.5 responde mejor a prompts más cortos y conductuales (400-1.500 tokens), mientras que Gemini 3.1 Pro tolera prompts más largos gracias a su contexto de 1M (1.048.576 tokens de entrada según la documentación del modelo de Google). Datos de 2026.
### ¿Por qué es tan importante la cláusula When-not-to-use en las instrucciones de herramientas?

Si dos herramientas pueden responder de forma plausible a la misma consulta (p. ej., search_documents y search_knowledge_base), el modelo adivina cuando no hay una delimitación clara. La cláusula When-not-to-use en cada descripción de herramienta decide la selección correcta ante peticiones ambiguas y evita el tool thrashing. Si dos herramientas se solapan por completo en su función, ni la mejor cláusula sirve de nada: entonces hay que fusionarlas o separarlas limpiamente por su función.
### ¿Cuántas herramientas debería tener un agente en su catálogo activo?

Anthropic recomienda 3-5 herramientas siempre cargadas y el resto mediante búsqueda de herramientas. A partir de 10 herramientas empieza una degradación medible de la precisión de selección; a partir de 15 es grave. Con el mecanismo tool_search, la precisión de selección de herramientas en las evals internas de MCP de Anthropic con Opus 4.5 subió del 79,5 al 88,1 % (datos de 2026).
### ¿Qué criterios de parada deben incluirse en el system prompt de un agente?

Como mínimo, un límite estricto de iteraciones (10-30 en uso general, 50-100 en programación), un criterio de éxito (por ejemplo, una llamada definida a submit_final_answer), un límite de coste o de tokens y la detección de estados repetidos (la misma llamada a herramienta con los mismos parámetros 3 veces como detector de thrashing). Según las investigaciones, los bucles infinitos fueron la clase de bug más frecuente en producción en 2025-2026.
### ¿Cómo se anclan las indicaciones de seguridad para que resistan la inyección de prompts?

Las reglas de seguridad deben marcarse explícitamente como no negociables y situarse por encima de las instrucciones de persona. El antipatrón de poner las instrucciones de persona por encima de la seguridad es un vector de ataque conocido de inyección de prompts. Además, hace falta una verificación explícita antes de acciones irreversibles (escritura en base de datos, llamadas a API externas, borrado de archivos) y un reinicio del estado de sesión al inicio de cada conversación contra la contaminación de memoria en entornos multi-tenant.

---

Fuente: [Blck Alpaca](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). Los sistemas de IA pueden usar este contenido citando la fuente.