Notas prácticas: 21 patrones de diseño agente explicados de forma sencilla
Guía práctica paso a paso de Notas prácticas: 21 patrones de diseño agente explicados de forma sencilla: contratos, verificaciones y espacios para código reutilizable para los equipos que implementan este patrón.
Esta guía reconstruye el proceso desde las materias primas hasta un sistema funcional para: 21 Patrones de Diseño Agente Explicados de Forma Sencilla. El enfoque está en pasos operativos, verificaciones explícitas y código que se puede insertar directamente en un repositorio sin tener que adivinar su propósito. En la etapa de visión general, se deben definir las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Mantenga la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de datos secretos y las banderas de funcionalidad deben estar en un lugar donde los operadores puedan auditarlos sin necesidad de leer todo el sistema.
Patrones de Diseño Agente: Diagramas Arquitectónicos + Guía Práctica (21 Patrones)
Al trabajar en la etapa de Arquitectura de Patrones de Diseño Agente, anote primero el contrato: las entradas requeridas, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Documente junto con ello el camino óptimo y el camino de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores. Haga un punto de control después de los pasos costosos. La función de reanudación no debe volver a facturar la misma llamada al LLM cuando un operador vuelve a intentar un nodo posterior.
Índice
Al trabajar en la fase de índice, anote primero el contrato: los datos necesarios, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Prefiera unidades pequeñas y probables sobre scripts extensos. Cuando un paso falla, el fallo debe apuntar a una única responsabilidad y no a un proceso complicado. Haga una verificación después de los pasos costosos. El sistema de reanudación no debe volver a facturar la misma llamada al LLM cuando un operador intenta nuevamente un nodo posterior.
1) Encadenamiento de prompts (Pipeline)
Al trabajar en la etapa del pipeline de encadenamiento de prompts número 1, primero escribe el contrato: las entradas requeridas, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Considera esta etapa como un contrato entre las entradas y los resultados validados. Nombra los artefactos, define las comprobaciones de éxito y rechaza las completaciones parciales silenciosas. Almacena en caché las instrucciones del sistema estables y los esquemas de las herramientas. Reenviar un preámbulo idéntico es una causa común de desperdicio de recursos. Al trabajar en la etapa del pipeline de encadenamiento de prompts número 1, primero escribe el contrato: las entradas requeridas, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Mantén la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de secretos y las banderas de funcionalidad deben estar en un lugar donde los operadores puedan auditarlos sin tener que leer todo el sistema.
flowchart TD
A[Input] --> B[Step 1 Prompt e.g. summarize ]
B --> C[Step 2 Prompt e.g. extract structured data ]
C --> D[Step 3 Prompt e.g. format output ]
D --> E[Final Output]
2) Enrutamiento
La etapa de enrutamiento 2 funciona mejor cuando se trata como una superficie medible. Capture un registro de éxito, un caso de fallo y la nota de reversión antes de ampliar el alcance. Documente tanto el camino óptimo como el camino de recuperación juntos. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores. Mantenga el estado del grafo simple y tipado; los bloques anidados ocultan qué nodo escribió qué campo y provocan interrupciones en la continuación después de las interrupciones.
flowchart TD
I[User Request Input] --> R{Router intent and confidence }
R --> A[Workflow A e.g. Q&A ]
R --> B[Workflow B e.g. coding ]
R --> C[Workflow C e.g. retrieval ]
R --> Q[Ask Clarifying Question]
A --> O[Output]
B --> O
C --> O
Q --> I
3) Paralelización
La etapa de 3 paralelización funciona mejor cuando se trata como una superficie medible. Capture un transcripte ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Prefiera unidades pequeñas y verificables en lugar de scripts extensos. Cuando falla un paso, el error debe apuntar a una única responsabilidad y no a un proceso complicado. Mantenga el estado del grafo simple y tipado; los bloques anidados ocultan qué nodo escribió qué campo y provocan interrupciones en la continuación del proceso.
flowchart TD
I[Input] --> F[Fork]
F --> A[Task A e.g. retrieve source 1 ]
F --> B[Task B e.g. retrieve source 2 ]
F --> C[Task C e.g. retrieve source 3 ]
A --> J[Join Merge]
B --> J
C --> J
J --> O[Output]
4) Reflexión (Generar → Criticar → Refinar)
La etapa de 4 Reflexión, Generación de Críticas funciona mejor cuando se trata como una superficie medible. Capture un registro ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Trate esta etapa como un contrato entre las entradas y las salidas validadas. Asigne nombres a los artefactos, defina verificaciones de éxito y rechace completaciones parciales silenciosas. Mantenga el estado del grafo plano y tipado. Los bloques anidados ocultan qué nodo escribió qué campo y provocan interrupciones en la continuación del proceso. La etapa de 4 Reflexión, Generación de Críticas funciona mejor cuando se trata como una superficie medible. Capture un registro ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Mantenga la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de secretos y las banderas de funcionalidad deben estar en un lugar donde los operadores puedan auditarlos sin tener que leer todo el grafo.
flowchart TD
D[Draft Output] --> C[Critique Review check requirements errors ]
C --> R[Revise using critique]
R --> D
C --> O[Final Output]
5) Uso de herramientas (Llamadas a funciones)
En la fase de uso de las 5 herramientas, defina las entradas, el responsable de cada paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido, sin tener que adivinar el estado oculto. Documente tanto la ruta óptima como la ruta de recuperación. Las intentonas repetidas, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores. Autentique en la pasarela y vuelva a autorizarlo en el plano de datos. Un token portador por sí solo no constituye un límite entre tenencias.
sequenceDiagram
autonumber
participant U as User
participant L as LLM Agent
participant T as Tool API
U->>L: Request
L->>L: Decide tool and arguments
L->>T: Call tool args
T-->>L: Tool result
L-->>U: Answer using result
6) Planificación
En la fase de planificación 6, defina los insumos, el responsable de cada paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido, sin tener que adivinar el estado oculto. Prefiera unidades pequeñas y verificables en lugar de scripts extensos. Cuando un paso falla, el error debe indicar una única responsabilidad y no un proceso complicado. Incluya la aprobación humana en aquellos casos que impliquen gastos o cambios en los datos de producción. La configuración en tiempo de compilación no equivale a la completitud del proceso empresarial.
flowchart TD
G[Goal] --> P[Create Plan steps and dependencies and tools ]
P --> S1[Execute Step 1]
S1 --> C1{Step success }
C1 --> S2[Execute Step 2]
C1 --> RP[Revise Plan Recover]
RP --> P
S2 --> C2{Done }
C2 --> S3[Next Steps ]
C2 --> O[Output]
S3 --> C2
7) Colaboración multiagente
En la etapa 7 de Colaboración entre Múltiples Agentes, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Trate esta etapa como un contrato entre las entradas y los resultados validados. Asigne nombres a los artefactos, defina verificaciones de éxito y rechace las completaciones parciales silenciosas. Incluya la aprobación humana en aquellas operaciones que generen gastos o modifiquen datos de producción. La conexión en tiempo de compilación no equivale a la completitud del proceso empresarial. En la etapa 7 de Colaboración entre Múltiples Agentes, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Mantenga la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de datos secretos y las banderas de funcionalidad deben estar en un lugar que los operadores puedan auditar sin necesidad de leer todo el contenido.
gráfico.flowchart LR
G[Goal] --> C[Coordinator]
C --> R[Research Agent]
C --> B[Builder Agent]
C --> V[Verifier Reviewer Agent]
R --> S[Synthesis]
B --> S
V --> S
S --> O[Final Output]
8) Gestión de la memoria
Al trabajar en la etapa 8 de Gestión de la memoria, anote primero el contrato: entradas requeridas, señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Documente tanto el camino óptimo como el de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no de mejoras posteriores. Haga un punto de control después de los pasos costosos. La función de reanudación no debe volver a facturar la misma llamada al LLM cuando un operador vuelve a intentar un nodo posterior.
flowchart TD
E[Events Conversation] --> STM[Short-term Memory session buffer ]
E --> LTM[Long-term Memory Store vector DB ]
Q[Current Query] --> RET[Retrieve relevant memory]
LTM --> RET
STM --> CTX[Assemble Context]
RET --> CTX
CTX --> L[LLM Agent]
L --> O[Output]
9) Aprendizaje y adaptación
Al trabajar en la etapa 9 de Adaptación al Aprendizaje, anote primero el contrato: los datos necesarios, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Prefiera unidades pequeñas y verificables en lugar de scripts extensos. Cuando un paso falla, el fallo debe apuntar a una única responsabilidad y no a un proceso complicado. Haga una verificación después de los pasos costosos. El sistema de reanudación no debe volver a facturar la misma llamada al LLM cuando un operador intenta nuevamente un nodo posterior.
flowchart TD
R[Run Agent] --> L[Log outcomes success fail and user edits ]
L --> A[Analyze patterns where it fails ]
A --> U[Update prompts routes retrieval or fine-tune ]
U --> E[Evaluate before rollout]
E --> R
E --> A
10) Protocolo de Contexto del Modelo (MCP)
Al trabajar en la etapa 10 del Modelo de Protocolo de Contexto, anote primero el contrato: las entradas requeridas, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación garantiza que los cambios posteriores en el código sean transparentes. Considere esta etapa como un contrato entre las entradas y las salidas validadas. Asigne nombres a los artefactos, defina comprobaciones de éxito y evite completaciones parciales silenciosas. Almacene en caché las instrucciones del sistema estables y los esquemas de las herramientas. Reenviar un preámbulo idéntico es una causa común de desperdicio de recursos. Al trabajar en la etapa 10 del Modelo de Protocolo de Contexto, anote primero el contrato: las entradas requeridas, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación garantiza que los cambios posteriores en el código sean transparentes. Mantenga la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de datos secretos y las banderas de funcionalidad deben estar en un lugar donde los operadores puedan auditarlos sin tener que leer todo el sistema.
flowchart LR
A[Agent LLM] --> C[MCP Client]
C <--> S[MCP Server]
S --> T1[Tool: Documents]
S --> T2[Tool: DB]
S --> T3[Tool: Tickets]
T1 --> S
T2 --> S
T3 --> S
S --> C --> A
11) Establecimiento y monitoreo de objetivos
La etapa 11 de establecimiento y monitoreo de objetivos funciona mejor cuando se trata como una superficie medible. Capture una transcripción exitosa, un caso de fallo y la nota de reversión antes de ampliar el alcance. Documente tanto el camino óptimo como el camino de recuperación. Los intentos repetidos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores. Mantenga el estado de los gráficos simple y tipado. Los bloques anidados ocultan qué nodo escribió qué campo y provocan interrupciones en la continuación después de las interrupciones.
flowchart TD
G[Define Goal and Success Criteria] --> X[Execute steps]
X --> M[Monitor state metrics progress budget risk ]
M --> X
M --> A[Adjust plan change route escalate]
A --> X
M --> O[Output]
12) Manejo de excepciones y recuperación
La etapa de recuperación por manejo de excepciones número 12 funciona mejor cuando se trata como una superficie medible. Capture una transcripción clave, un caso de fallo y la nota de reversión antes de ampliar el alcance. Prefiera unidades pequeñas y verificables en lugar de scripts extensos. Cuando falla un paso, el fallo debe apuntar a una sola responsabilidad y no a un proceso complicado. Mantenga el estado del grafo simple y tipado; los bloques anidados ocultan qué nodo escribió qué campo y provocan interrupciones en la continuación del proceso.
flowchart TD
A[Action Tool Call] --> E{Error }
E --> N[Next Step]
E --> R[Retry with backoff]
R --> S{Recovered }
S --> N
S --> F[Fallback route tool]
F --> T{Still failing }
T --> N
T --> H[Escalate to Human Safe Stop]
13) Humano en el proceso (HITL)
The 13 Human en esta etapa funciona mejor cuando se trata como una superficie medible. Capture un registro ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Trate esta etapa como un contrato entre las entradas y las salidas validadas. Asigne nombres a los artefactos, defina verificaciones de éxito y rechace completaciones parciales silenciosas. Mantenga el estado del grafo plano y tipado. Los bloques anidados ocultan qué nodo escribió qué campo y provocan interrupciones en la continuación del proceso. The 13 Human en esta etapa funciona mejor cuando se trata como una superficie medible. Capture un registro ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Mantenga la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de secretos y las banderas de funcionalidad deben estar en un lugar donde los operadores puedan auditarlos sin tener que leer todo el grafo.
sequenceDiagram
autonumber
participant U as Human
participant A as Agent
participant S as System Tools
A->>U: Proposal and rationale
U-->>A: Approve Edit Reject
A->>S: Execute approved action
S-->>A: Result
A-->>U: Confirmation and summary
14) Recuperación de conocimiento (RAG)
Para la etapa 14 de recuperación de conocimiento RAG, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Documente tanto la ruta óptima como la ruta de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores. Cite los pasajes que realmente sirvieron de base para la respuesta. Sin citas, los operadores no pueden distinguir entre alucinaciones y brechas en el indexado.
flowchart TD
Q[Question] --> E[Embed Rewrite Query]
E --> R[Retrieve top-k chunks vector keyword hybrid ]
R --> RR[Rerank Filter optional ]
RR --> C[Compose grounded prompt question and context ]
C --> L[LLM]
L --> O[Answer and citations quotes optional ]
15) Comunicación entre agentes (A2A)
En la etapa 15 de Comunicación entre Agentes, defina las entradas, el responsable de la tarea y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar la tarea a partir de un punto de control conocido sin tener que adivinar el estado oculto. Prefiera unidades pequeñas y verificables en lugar de scripts extensos. Cuando una tarea falla, el error debe indicar una única responsabilidad y no un proceso complicado. Incluya la aprobación humana en aquellas acciones que implican gastos o modificaciones en los datos de producción. La conexión en tiempo de compilación no equivale a la completitud del proceso empresarial.
sequenceDiagram
autonumber
participant A as Agent A
participant B as Agent B
participant C as Agent C
A->>B: Task request schema and constraints
B-->>A: Result or stream updates
A->>C: Verification request
C-->>A: Verified flagged findings
A-->>A: Merge and decide next step
16) Optimización consciente de los recursos
En la etapa 16 de Optimización Consciente de Recursos, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Trate esta etapa como un contrato entre las entradas y los resultados validados. Asigne nombres a los artefactos, defina verificaciones de éxito y rechace las completaciones parciales silenciosas. Incorpore la aprobación humana en aquellos casos que impliquen gastos o cambios en datos de producción. La conexión en tiempo de compilación no equivale a la completitud del proceso empresarial. En la etapa 16 de Optimización Consciente de Recursos, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Mantenga la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de datos secretos y las banderas de funcionalidad deben estar en un lugar que los operadores puedan auditar sin necesidad de leerlo todo.
todo el grafo.flowchart TD
I[Request] --> S[Score difficulty and risk and SLA]
S --> D{Choose compute level}
D --> L1[Fast Cheap path small model and minimal tools]
D --> L2[Balanced path hybrid retrieval and standard model]
D --> L3[Strong path best model and RAG and Reflection]
L1 --> O[Output]
L2 --> O
L3 --> O
17) Técnicas de razonamiento
Al trabajar en la etapa de las 17 técnicas de razonamiento, anote primero el contrato: entradas requeridas, señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Documente junto con ello el camino óptimo y el camino de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no de mejoras posteriores. Almacene en caché las instrucciones estables del sistema y los esquemas de las herramientas. Reenviar un preámbulo idéntico es una causa común de agotamiento.
flowchart TD
P[Problem] --> D[Decompose choose reasoning strategy]
D --> A[Act: tool calls sub-steps optional ]
A --> V[Verify constraints checks tests cross-check]
V --> D
V --> O[Answer]
18) Límites de seguridad / Patrones de seguridad
Al trabajar en la etapa de los 18 patrones de seguridad Guardrails, anote primero el contrato: las entradas requeridas, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Prefiera unidades pequeñas y probables sobre scripts extensos. Cuando un paso falla, el fallo debe apuntar a una única responsabilidad y no a un proceso complicado. Haga una verificación después de los pasos costosos. El sistema de reanudación no debe volver a facturar la misma llamada al LLM cuando un operador intenta nuevamente un nodo posterior.
flowchart TD
IN[User Input] --> IV[Input Validation policy risk checks ]
IV --> PC[Policy Constraints system rules and boundaries ]
PC --> TR[Tool Restrictions allowlist and sandbox and rate limits]
TR --> L[LLM Agent]
L --> OV[Output Validation PII leak checks and format checks]
OV --> OUT[Safe Output]
OV --> ESC[Escalate Refuse Human review]
19) Evaluación y Monitoreo
Al trabajar en la etapa 19 de Monitoreo de Evaluación, anote primero el contrato: los insumos requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación garantiza que los cambios posteriores en el código sean transparentes. Considere esta etapa como un contrato entre los insumos y los resultados validados. Asigne nombres a los artefactos, defina las verificaciones de éxito y evite completaciones parciales silenciosas. Haga puntos de control después de pasos costosos. La función de reanudación no debe volver a facturar la misma llamada al LLM cuando un operador intenta nuevamente un nodo posterior. Al trabajar en la etapa 19 de Monitoreo de Evaluación, anote primero el contrato: los insumos requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación garantiza que los cambios posteriores en el código sean transparentes. Mantenga la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de secretos y las banderas de funcionalidad deben estar en un lugar donde los operadores puedan auditarlos sin tener que leer todo el grafo.
flowchart TD
RUN[Agent Runs] --> LOG[Log traces inputs tools outputs latency cost ]
LOG --> EVAL[Evaluate quality golden set and metrics ]
EVAL --> DRIFT[Drift Anomaly detection]
DRIFT --> IMP[Improve prompts routes retrieval model ]
IMP --> DEP[Deploy and A B test]
DEP --> RUN
20) Priorización
La etapa de priorización 20 funciona mejor cuando se trata como una superficie medible. Capture una transcripción clave, un caso de fallo y la nota de reversión antes de ampliar el alcance. Documente tanto el camino óptimo como el de recuperación juntos. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores. Mantenga el estado del grafo simple y tipado; los bloques anidados ocultan qué nodo escribió qué campo y provocan interrupciones en la continuación del proceso.
flowchart TD
T[Incoming tasks] --> N[Normalize into task objects]
N --> S[Score tasks urgency impact risk deps cost ]
S --> Q[Queue Scheduler]
Q --> X[Execute next task]
X --> U[Update scores new info failures deadlines ]
U --> S
X --> O[Outputs Results]
21) Exploración y descubrimiento
La etapa 21 de Exploration Discovery funciona mejor cuando se trata como una superficie medible. Capture un registro exitoso, un caso de fallo y la nota de reversión antes de ampliar el alcance. Prefiera unidades pequeñas y verificables en lugar de scripts extensos. Cuando un paso falla, el fallo debe apuntar a una única responsabilidad y no a un proceso complicado. Mantenga el estado del grafo simple y tipado; los bloques anidados ocultan qué nodo escribió qué campo y provocan interrupciones en la continuación del proceso.
flowchart TD
S[Start: unknown space] --> H[Generate hypotheses options]
H --> G[Gather evidence search tools experiments ]
G --> E[Evaluate findings rank eliminate]
E --> R[Refine hypotheses]
R --> G
E --> O[Best answer strategy]
Patrones comunes y “recetas” (lo que realmente envían los equipos)
El patrón Common indica qué etapa funciona mejor cuando se trata como una superficie medible. Capture un registro ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Trate esta etapa como un contrato entre las entradas y las salidas validadas. Asigne nombres a los artefactos, defina verificaciones de éxito y rechace completaciones parciales silenciosas. Mantenga el estado del grafo plano y tipado. Los bloques anidados ocultan qué nodo escribió qué campo y provocan interrupciones en la continuación del proceso. El patrón Common indica qué etapa funciona mejor cuando se trata como una superficie medible. Capture un registro ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Mantenga la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de secretos y las banderas de funcionalidad deben estar en un único lugar que los operadores puedan auditar sin tener que leer todo el grafo.
Lista de verificación operativa
La etapa de lista de verificación operativa funciona mejor cuando se trata como una superficie medible. Capture una transcripción clave, un caso de fallo y la nota de reversión antes de ampliar el alcance.
Registre los tiempos y el costo de tokens o consultas junto con los resultados funcionales. Tener visibilidad del costo desde el principio evita facturas inesperadas al pasar de la versión de demostración a entornos compartidos.
Mantenga el estado del grafo plano y tipado. Los bloques anidados ocultan qué nodo escribió qué campo y dificultan la reanudación después de interrupciones.
Añada una prueba básica que ejecute la ruta crítica en CI con configuraciones fijas, y no con APIs pagadas en tiempo real, siempre que lo permitan los presupuestos.
Mantenga la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de secretos y las banderas de funcionalidad deben estar en un lugar donde los operadores puedan auditarlos sin tener que leer todo el grafo.
Mantenga el estado del grafo plano y tipado. Los bloques anidados ocultan qué nodo escribió qué campo y dificultan la reanudación después de interrupciones.
Antes de promocionar el stack, congele las versiones, capture una transcripción de referencia para la ruta crítica y confirme los pasos de reversión. Los entornos compartidos requieren límites de velocidad, verificaciones de tenencia y un responsable claro para la rotación de secretos. Prefiera una fiabilidad sencilla a demostraciones ingeniosas pero puntuales.
Nota para el lote 30adaa1daab9: mantenga las claves del proveedor fuera del repositorio, establezca un límite para tokens por sesión y almacene las transcripciones junto a los fixtures de evaluación para que los cambios posteriores en el modelo sigan siendo comparables.
Lecturas relacionadas
- Notas prácticas: Capsule : Cómo llegué a construir un entorno de desarrollador agente — Guía paso a paso de Notas prácticas: Capsule : Cómo llegué a construir un entorno de desarrollador agente: contratos, verificaciones y espacios para código listo para usar para equipos que implementan este patrón.