Prácticas recomendadas de ingeniería de prompts y contexto

Reducir el gasto de tokens y proteger la calidad de la respuesta no son objetivos que compiten entre sí: la misma disciplina suele lograr ambos a la vez.

Esta es una lista de verificación independiente de prácticas para decidir qué incluir en un prompt, qué modelo lo maneja y cómo un agente de larga duración gestiona su contexto a lo largo del tiempo.

Cómo usar esta lista de verificación

• Trate cada categoría como una revisión de un prompt, tarea o agente específico, no como una auditoría global única.
• Marque los elementos en función de una carga de trabajo real, no de forma abstracta; una regla que suene bien pero que no tenga un efecto medido en su tarea no vale la pena aplicarla.
• Vuelva a visitar esta lista cada vez que las entradas, el volumen o los riesgos de una tarea cambien significativamente.
• Empareje cada regla aquí con un conjunto de evaluación real siempre que sea posible; una práctica recomendada sin una forma de medir su efecto es una suposición disfrazada de regla.

A - Minimizar lo que envía

• Envíe solo los fragmentos que una tarea necesita, no archivos o repositorios completos. Recortar a material relevante elimina tokens directamente, sin necesidad de una llamada API adicional.
• Para tareas de código, utilice un grafo de dependencias para seleccionar archivos relevantes en lugar de adivinar. Un vecindario de un solo salto de importaciones e importadores suele ser suficiente contexto para un cambio de archivo único.
• Recorte datos estructurados (JSON, filas de bases de datos) a una lista explícita de campos permitidos. Una lista de permitidos es más segura que una lista de denegados, ya que los nuevos campos añadidos posteriormente no se filtrarán silenciosamente en los prompts.
• Descarte el historial de conversación obsoleto que ya no afecta a la tarea actual. Cada turno anterior conservado en una conversación de varios turnos se vuelve a enviar como tokens de entrada en cada llamada futura.
• Mida los recuentos de tokens antes y después de recortar, no solo la intuición. Una llamada rápida a count_tokens convierte "esto se siente más pequeño" en un número que puede rastrear con el tiempo.

B - Resumir documentos largos reutilizables

• Utilice un modelo barato y rápido para precondensar documentos largos antes de enviarlos a un modelo más costoso. El costo de la llamada de resumen en sí es pequeño en comparación con el ahorro una vez que el documento se reutiliza.
• Solo resuma documentos que se referenciarán más de una vez. Un documento de uso único rara vez recupera el costo de la llamada de resumen adicional.
• Pase una instrucción de enfoque al resumidor cuando sepa lo que necesita la tarea posterior. Un resumen genérico corre el riesgo de omitir el único detalle que importaba.
• Caché de resúmenes por identidad de documento, e invalide la caché cuando la fuente cambie. Volver a resumir un documento sin cambios en cada llamada desperdicia todo el beneficio de costo.
• Evite resumir texto crítico para la precisión, como contratos o cifras exactas. La resumen es inherentemente con pérdida; extraiga la sección relevante exacta en su lugar cuando la precisión sea importante.

C - Emparejar el nivel del modelo con la tarea

• Enrute cada categoría de tarea al modelo más barato que aún cumpla su barra de calidad. Reserve modelos más potentes como Opus 4.8 para tareas que realmente necesiten un razonamiento más profundo.
• Base las decisiones de nivel en un conjunto de evaluación, no en la intuición. Una lista de verificación de niveles de modelos reduce la búsqueda, pero solo la tasa de aprobación medida confirma la elección.
• Deje que el riesgo financiero, de cumplimiento o de reversibilidad anule la aparente simplicidad de una tarea. Una tarea que parece fácil por el recuento de pasos de razonamiento aún puede justificar un nivel más alto si una respuesta incorrecta es costosa.
• Revise las decisiones de nivel cuando las entradas de la tarea o un nuevo modelo en la línea cambien el panorama. Una decisión de nivel tomada una vez en el lanzamiento puede quedar obsoleta.
• Documente qué nivel maneja qué categoría de tarea y por qué. La nivelación ad hoc y no documentada es difícil de mantener o revisar para un equipo.

D - Ajustar el esfuerzo de razonamiento deliberadamente

• Varíe el parámetro de esfuerzo de bajo a máximo en un conjunto de evaluación real, en lugar de usar el máximo por defecto. La configuración más barata que aún cumple su barra de calidad es la que se debe enviar.
• Establezca el umbral de calidad basándose en el costo de una respuesta incorrecta para esa tarea específica. Una tarea de bajo riesgo puede tolerar una barra más flexible que una relacionada con la facturación o el cumplimiento.
• Aumente el conjunto de evaluación a partir de fallos reales de producción con el tiempo. Un puñado de casos elegidos a mano se sobreajustará a lo que se le ocurrió cuando los escribió.
• Trate el esfuerzo y el tamaño del contexto como palancas independientes. Aumentar el esfuerzo no soluciona un prompt que carece del contexto necesario, y recortar el contexto no sustituye al esfuerzo en una tarea de razonamiento genuinamente difícil.
• Vuelva a ejecutar el barrido de esfuerzo cuando cambie la plantilla del prompt o la versión del modelo. El resultado de un barrido es una instantánea, no un hecho permanente sobre la tarea.

E - Gestionar el contexto del agente multivuelta

• Caché de resultados de herramientas y deduplicación de llamadas repetidas idénticas dentro de una sesión. Una llamada de herramienta redundante cuesta el doble: una vez para ejecutarla y otra vez al ser transmitida en el historial de cada turno futuro.
• Nunca caché llamadas a herramientas que mutan, solo búsquedas de solo lectura. Volver a ejecutar una escritura, como cargar una tarjeta, es el objetivo, no una redundancia a eliminar.
• Establezca un presupuesto explícito de ventana de contexto para agentes de larga duración, no uno implícito. Un presupuesto que no está documentado tiende a descubrirse solo después de que una sesión alcanza un límite estricto.
• Defina un disparador de compactación concreto y qué preserva. Sepa exactamente qué condición activa el resumen o la truncación, y qué debe sobrevivir a ella, como el objetivo original del usuario.
• Ámbito de las cachés de resultados de herramientas por sesión, no globalmente, en sistemas multiinquilino. Una caché compartida y sin ámbito puede filtrar los resultados de un usuario al contexto de otro usuario.

F - Protegerse contra la degradación del contexto

• Trate "debo incluir esto" como una pregunta real, no como un sí por defecto. El material irrelevante puede degradar la calidad de la respuesta, no solo aumentar el costo.
• Esté atento al contenido distractor: material irrelevante que se parece superficialmente a la respuesta correcta. Una variable con el mismo nombre o una definición duplicada obsoleta pueden inducir a error activamente a un modelo en lugar de ser simplemente ignoradas.
• No trate una ventana de contexto más grande como permiso para omitir el recorte. Una ventana más grande cambia lo que cabe, no lo que es relevante.
• Compare la calidad de la respuesta en un prompt recortado frente a uno acolchado cuando tenga dudas. Si la calidad no disminuye mediblemente con un prompt más pequeño, el material adicional no estaba justificando su costo.
• Equilibre contra el recorte excesivo. Cortar algo genuinamente relevante produce un fallo diferente al de la degradación del contexto; el objetivo es la relevancia, no el minimalismo por sí mismo.

G - Documentar y revisar decisiones

• Escriba los presupuestos de contexto, los disparadores de compactación y las decisiones de nivelación a medida que se toman, no después. Un registro estilo ADR hace que estas decisiones sean revisables en lugar de conocimiento tribal.
• Asigne un propietario para cada decisión de costo/calidad. Una decisión sin propietario tiende a quedar obsoleta a medida que cambia la tarea subyacente o la línea de modelos.
• Establezca una cadencia de revisión, no una decisión única. La revisión trimestral es un valor predeterminado razonable para categorías de tareas de alto volumen.
• Rastree una métrica concreta que señalaría que la configuración actual es incorrecta. La compactación que se activa con demasiada frecuencia, la caída de la tasa de aprobación o el costo que excede el objetivo son señales que merecen una alerta.

Preguntas frecuentes

Relacionado

• Cómo la ingeniería de contexto reduce el gasto de tokens - el modelo mental subyacente a cada práctica en esta página.
• Lista de verificación de niveles de modelos - un análisis más profundo de la categoría C.
• Degradación del contexto: por qué más tokens no significan mejores respuestas - el razonamiento detrás de la categoría F.
• Plantilla ADR: Establecer un presupuesto de ventana de contexto para un agente de producción - una plantilla para documentar las decisiones en la categoría G.
• Evitar llamadas de herramientas redundantes en bucles de agentes multivuelta - un análisis más profundo de la categoría E.

Versiones de Stack: Escrito contra la línea de modelos Claude actual a partir de ~junio de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (el predeterminado) y Claude Haiku 4.5 - y el SDK oficial de Python anthropic (última versión 0.x). Los nombres de modelos, precios y versiones de SDK cambian rápidamente; verifique los detalles actuales en platform.claude.com/docs antes de confiar en ellos.