Boas prácticas de orquestración de axentes de IA: xestión de fallos, aprobacións e reintentos

Ter varios axentes traballando no mesmo proxecto parece extremadamente eficiente. Un planifica o traballo, outro encárgase do deseño e un terceiro escribe o código. Funciona ata que deixa de funcionar. E os fallos ocorren máis a miúdo do que che gustaría.

Evitar estes fallos require unha enxeñaría coidadosa dos fluxos de traballo. Así que vexamos que fai que os fluxos de traballo orquestrados sexan pouco fiables e exploremos as mellores prácticas de orquestración para lograr fiabilidade en produción.

Que é a orquestración de axentes de IA?

A orquestración de axentes de IA coordina varios axentes, modelos e ferramentas de IA para completar unha tarefa de varios pasos. Pero alguén —ou algo— aínda ten que decidir que axente se executa primeiro, que información recibe e que pasa despois de que remate. Este é o papel do orquestrador: un axente de IA que actúa como xestor ou unha capa de execución controlada por software.

En termos sinxelos, unha capa de orquestración divide un obxectivo en tarefas máis pequenas, fai o seguimento das dependencias, delega a execución nos axentes axeitados, xestiona o contexto compartido e combina os resultados.

Como funciona a orquestración de axentes de IA: dentro do motor de execución

Ampliar

Vexamos que pasa despois de lle dar unha tarefa a un orquestrador.

Considera un exemplo do obradoiro de Computer de Perplexity: crear un panel de intelixencia de contas con información de Salesforce, Snowflake, o correo electrónico, o calendario e noticias recentes.

1. Comprender o obxectivo e planificar o traballo. O orquestrador parte do resultado solicitado e descompono en tarefas con dependencias explícitas. No noso exemplo do panel, iso implica recompilar información de distintas fontes e convertela nun entregable finalizado. O planificador establece que pasos dependen doutros e cales se poden executar de forma independente.
2. Encamiñar as tarefas aos axentes axeitados. O orquestrador identifica as tarefas cuxas dependencias están satisfeitas e delega o traballo en axentes ou modelos especializados. As tarefas dependentes agardan polos seus requisitos previos. Perplexity Computer usa varios modelos de vangarda e encamiña as distintas partes do fluxo de traballo cara aos sistemas máis axeitados para esas tarefas. Isto tamén permite que o traballo independente se execute en paralelo.
3. Executar chamadas a ferramentas en contornos controlados. Os axentes interactúan co seu contorno mediante ferramentas, como a busca web, as API, as aplicacións conectadas, as operacións con ficheiros ou a execución de código. A capa de execución realiza estas accións e devolve os resultados aos axentes.
4. Pasar resultados e contexto entre axentes. Cando un axente remata a súa tarefa, o seguinte axente da cadea necesita o resultado relevante para continuar. Un rexistro de traspaso podería conter un ID de tarefa, unha referencia ao resultado, unha versión do esquema e metadatos da fonte. O orquestrador coordina estes traspasos mentres mantén o contexto necesario para os pasos posteriores. É importante destacar que os axentes non teñen que levar todo o historial do traballo de cada un dos outros axentes nas súas propias xanelas de contexto.
5. Rexistrar o estado de execución á parte do contexto dos axentes. A medida que os axentes inician, completan ou fallan tarefas, o motor de execución actualiza un rexistro persistente do fluxo de traballo co estado das tarefas, os intentos de execución, as referencias aos resultados e o traballo pendente. Este rexistro permite que o orquestrador faga o seguimento do progreso e retome o traballo despois dunha interrupción sen depender dun LLM para reconstruír o fluxo de traballo a partir do historial da conversa.
6. Validar os resultados e decidir que pasa a continuación. Cando unha tarefa finaliza, a capa de orquestración comproba se o seu resultado cumpre o contrato esperado e se se cumpren as dependencias da seguinte tarefa. Se se detecta un problema, o fluxo de traballo pode volver a un paso anterior para corrixilo ou pausarse. En caso contrario, avanza cara á súa finalización.

Detrás do que parece unha simple orquestración de axentes de IA hai moitas pezas en movemento. A forma en que organizas a coordinación dos axentes determina canto control tes sobre a execución. E, por suposto, toda esa coordinación supón unha sobrecarga. Por iso, non sempre compensa.

Cando deberías usar a orquestración de axentes de IA?

Considera a orquestración multiaxente cando distintas partes da tarefa requiran coñecementos especializados diferentes, o traballo independente se poida executar en paralelo ou non poidas determinar de antemán o seguinte paso.

Polo tanto, a orquestración resulta útil en tres escenarios:

• As tarefas requiren distintas especializacións. Un proxecto de programación, por exemplo, podería beneficiarse de axentes separados para a planificación, o deseño, o desenvolvemento e a revisión.
• As tarefas independentes poden executarse en paralelo. En lugar de que un só axente o complete todo de forma secuencial, varios axentes poden traballar simultaneamente e devolverlle os seus resultados a un orquestrador.
• O problema é aberto. É posible que os axentes teñan que explorar distintos enfoques, tomar decisións e colaborar en lugar de seguir unha secuencia predefinida.

Fóra diso, a orquestración non é máis que unha tendencia custosa. Máis axentes tamén implican máis coordinación e, potencialmente, maiores custos de tokens.

“Adoito comezar pola opción máis sinxela e construír a partir de aí. Se coñecemos os pasos e son repetibles, probablemente sexa un fluxo de traballo. Só vexo motivos para introducir varios axentes cando teñen responsabilidades, permisos ou usuarios diferentes”, di Josh Spilker, responsable de mercadotecnia en buscadores en AirOps.

Aínda así, sopesa os beneficios fronte ás chamadas adicionais aos modelos, os traspasos, a latencia e os puntos de fallo.

Arquitecturas de orquestración de axentes de IA e as súas vantaxes e inconvenientes

Hai tres formas habituais de estruturar a coordinación de axentes: orquestración centralizada, descentralizada e xerárquica. Escoller a arquitectura axeitada redúcese a unha pregunta: Quen controla o traballo e como se coordinan os axentes entre si?

Orquestración centralizada

Na orquestración centralizada, un único orquestrador xestiona o proceso. Divide a tarefa, delega o traballo en axentes especializados, fai o seguimento do seu progreso e combina os seus resultados.

Ampliar

Vantaxes e inconvenientes: A coordinación centralizada facilita o seguimento da execución e a aplicación de regras comúns nun único punto de control. Porén, o orquestrador pode converterse nun pescozo de botella, e un fallo seu pode interromper todo o fluxo de traballo, a menos que o sistema admita a recuperación.

Orquestración descentralizada

Na orquestración descentralizada, os axentes coordínanse de forma máis directa en lugar de depender dun único xestor que tome todas as decisións. Poden intercambiar mensaxes, ler o estado compartido e determinar de forma independente os seus seguintes pasos.

Ampliar

Vantaxes e inconvenientes: Os axentes poden funcionar sen esperar por un planificador central, o que fai que este enfoque sexa útil para o traballo exploratorio e as contribucións independentes. Pero a coordinación vólvese máis difícil cando os axentes discrepan, actualizan información compartida ou teñen que chegar a un resultado coherente.

Orquestración xerárquica

A orquestración xerárquica estende o enfoque do xestor a varios niveis. Un orquestrador de nivel superior delega responsabilidades en orquestradores subordinados, que coordinan os seus propios grupos de axentes especializados.

Pensa nun fluxo de traballo empresarial no que participan os equipos de vendas, finanzas e asuntos legais. Un orquestrador de nivel superior podería delegar cada liña de traballo nun coordinador específico do dominio. Despois, eses coordinadores xestionarían os seus propios axentes especializados e informarían dos resultados consolidados.

Esta estrutura pode axudar cando os fluxos de traballo son demasiado amplos para que un só orquestrador os xestione de forma eficaz.

Ampliar

Vantaxes e inconvenientes: As xerarquías permiten que os equipos repartan as responsabilidades de coordinación e, potencialmente, xestionen os fallos dentro de cada rama. Porén, introducen traspasos adicionais, unha xestión do estado máis complexa e unha maior sobrecarga operativa. A recuperación local tamén depende de como se implementen os puntos de control e o estado de execución.

Comparativa destas arquitecturas:

Execución secuencial, paralela e baseada en traspasos

Hai unha distinción máis que paga a pena comprender. A arquitectura determina quen coordina os axentes. O patrón de execución determina como avanzan as súas tarefas.

Estes son tres patróns de execución:

• Fluxos de traballo secuenciais: Os axentes traballan nunha orde predefinida, e o resultado dun axente convértese na entrada doutro.
• Execución paralela: Axentes independentes traballan simultaneamente.
• Execución baseada en traspasos: O control pasa dun axente especializado a outro a medida que avanza a tarefa. Isto é útil cando outro axente está mellor preparado para xestionar o seguinte paso, aínda que cada traspaso debe conservar a información necesaria para continuar.

Estes patróns non son mutuamente excluíntes nin se corresponden de forma unívoca coas arquitecturas de orquestración. O obxectivo é escoller a estrutura máis sinxela que admita as dependencias do teu fluxo de traballo, os requisitos de coordinación e unha sobrecarga operativa aceptable.

Fallos habituais na orquestración de axentes de IA

Na orquestración pode fallar calquera cousa, desde simples descoidos ata bloqueos complexos. Ás veces, un axente pode mesmo parecer que fai ben o seu traballo mentres o fluxo de traballo no seu conxunto falla. A partir da experiencia de profesionais do sector, recompilamos algúns dos erros habituais que hai detrás dos fluxos de traballo orquestrados pouco fiables. Presta atención a eles:

• Traspasos entre axentes con perda de información. Un orquestrador pásalle un plan resumido a un axente especializado, pero o resumo omite restricións, dependencias ou detalles de implementación.
• Execución prematura da agregación (fan-in). Un axente posterior comeza a agregar resultados antes de que rematen todas as tarefas previas.
• Actualizacións non deterministas do estado compartido. Axentes en paralelo escriben nas mesmas claves de estado sen unha semántica de fusión ben definida. Segundo como xestione o framework as actualizacións, isto pode provocar escrituras perdidas, datos duplicados, resultados que dependen da orde ou cambios en conflito.
• Diverxencia entre puntos de control e efectos secundarios. Unha tarefa realiza unha operación externa, pero a súa execución correcta non queda rexistrada de forma duradeira antes de que falle o proceso de traballo. Na recuperación, o orquestrador ve unha tarefa sen rematar e volve executala.
• Condicións de carreira ao retomar tras a aprobación humana. Pausar e retomar a execución introduce os seus propios problemas de sincronización.
• Bucles de delegación e amplificación de reintentos. Os axentes pásanse traballo unha e outra vez entre eles porque as súas responsabilidades se solapan, as dependencias son circulares ou as condicións de finalización son ambiguas.
• Controis a nivel de instrucións confundidos con seguridade de execución. Un orquestrador pode indicarlles aos axentes que non accedan a certos recursos nin realicen accións sensibles, pero as instrucións do modelo non aplican permisos do sistema operativo, restricións de rede nin límites de autorización. A investigación en enxeñaría de seguridade de Perplexity explica por que os axentes poden cruzar límites de seguridade mentres perseguen obxectivos lexítimos, mesmo sen instrucións maliciosas

Fíxate en que diferentes son estes fallos. Unha transición prematura do planificador ou unha escritura externa ambigua poden producir un resultado incorrecto, pero orixínanse en partes distintas do ciclo de vida da execución. Por iso, unha orquestración fiable require algo máis que mellorar os prompts ou engadir reintentos.

7 boas prácticas de orquestración de axentes de IA para a fiabilidade en produción

1. Define contratos de tarefa explícitos, criterios de aceptación e condicións de parada

Os obxectivos vagos e unha definición de feito pouco clara adoitan dar lugar a resultados decepcionantes xerados polos axentes. A solución é un contrato de prompt (un alcance de traballo para un axente): acordar o obxectivo, as restricións, o formato de saída e as condicións de fallo antes de que comece a execución.

Por exemplo, así é como poderías definir un contrato para un axente encargado de corrixir unha proba de integración que falla de forma intermitente:

• Obxectivo: Identificar e corrixir a causa dunha proba de integración inestable da API de pagamento.
• Entradas: Código fonte das probas, rexistros de fallos de CI, commits recentes e código relevante da aplicación.
• Restricións: Non desactivar probas, relaxar asercións nin modificar comportamentos da aplicación non relacionados.
• Saída esperada: Un parche de código, unha explicación da causa raíz e os resultados da execución das probas.
• Criterios de aceptación: A proba que antes fallaba supérase en 10 execucións consecutivas, e o conxunto de probas de regresión relevante tamén se supera.
• Condicións de fallo: Non se pode determinar a causa raíz, a corrección introduce regresións ou o contorno de probas necesario non está dispoñible.

Pero hai outra parte importante: cando debería parar o axente?

Un axente non debería seguir iterando indefinidamente porque non obtivo un resultado satisfactorio. Define que se considera unha finalización correcta, cando devolver unha tarefa parcialmente completada e cando parar porque non se pode cumprir un requisito. Establece unha profundidade máxima de delegación e límites de iteracións ou orzamentos de execución para que as tarefas sen resolver non se convertan en bucles infinitos.

Volvamos ao noso exemplo de CI. Poderías definir as seguintes condicións de parada:

• Éxito: A corrección supera 10 execucións consecutivas das probas e o conxunto de probas de regresión relevante.
• Límite de iteracións: O axente pode intentar como máximo dúas correccións candidatas.
• Orzamento de execución: O axente debe parar despois de 60 minutos, aínda que o problema siga sen resolverse.
• Límite de delegación: O axente pode delegar traballo nun axente especializado, sen ningunha delegación adicional a subaxentes.
• Finalización parcial: Se fallan os dous intentos ou se esgota o tempo límite, o axente devolve as súas conclusións, os cambios que intentou e os resultados das probas.
• Execución bloqueada: Se o contorno de probas non está dispoñible, o axente detense e informa do bloqueo en lugar de declarar que tivo éxito.

2. Mantén os orquestradores lixeiros e aplica traspasos estruturados

Ás veces, os desenvolvedores asígnanlle demasiadas responsabilidades a un orquestrador e, en lugar de coordinar axentes especializados, este comeza a escribir código, depurar ou realizar revisións detalladas por si mesmo. Isto crea un pescozo de botella: o orquestrador gasta o seu orzamento de contexto en detalles de implementación, atrasa a delegación e dilúe a responsabilidade sobre os resultados.

Así que deixa que os orquestradores fagan o seu traballo e aplica os traspasos facendo referencia a artefactos concretos: a tarefa orixinal, as entradas relevantes, os artefactos de saída, o estado de execución e calquera problema sen resolver.

Considera este exemplo: status: completed refírese ao traballo asignado ao axente, non a todo o fluxo de traballo. Como as probas aínda están en estado pending, o orquestrador non debería aprobar o resultado final.

3. Garda o estado do fluxo de traballo de forma persistente e controla o crecemento do contexto

O historial de conversa dun axente non é un rexistro fiable do progreso do fluxo de traballo. Cando se enche a súa ventá de contexto, a compactación automática pode eliminar detalles importantes. E se un proceso de traballo falla, o seguinte axente necesita saber que pasos se completaron realmente.

Por exemplo, se o axente de programación xera un parche e despois falla, o seguinte proceso de traballo debería recuperar o artefacto gardado e continuar desde o estado rexistrado do fluxo de traballo. Pero se o axente tamén iniciou unha execución externa de CI, o orquestrador debe conciliar esa execución por separado antes de repetir a acción

Polo tanto, mantén o estado de execución separado do contexto de traballo do axente. Garda os estados das tarefas, os intentos de execución, os pasos completados e as referencias aos artefactos nun almacenamento duradeiro. Mentres tanto, carga só as instrucións, as entradas e os resultados relevantes para a tarefa actual do axente, en lugar de encher a súa ventá de contexto con todo o historial de execución.

4. Deseña reintentos que teñan en conta os fallos e unha execución de ferramentas recuperable

Supón que o teu axente de CI inicia unha execución de probas, pero a solicitude á API esgota o tempo de espera. Non se chegou a iniciar a execución das probas ou o servizo de CI púxoa na cola e perdeu a resposta?

Un tempo de espera esgotado non significa necesariamente que unha operación fallase. Por iso, cómpre distinguir entre erros antes de decidir que pasa a continuación:

• Erros transitorios (429, 503): Reintenta cun retroceso exponencial limitado e variación aleatoria (jitter), respectando Retry-After cando se proporcione.
• Erros de validación ou de permisos (400, 403): Detente ou corrixe o problema subxacente en lugar de repetir a mesma solicitude.
• Resultados ambiguos (tempo esgotado despois dunha posible escritura): Comproba se a operación tivo éxito antes de tentala de novo.

Nota: Mesmo os erros que se poden reintentar necesitan límites. Establece un tempo de espera para cada chamada a ferramentas, limita o número de reintentos e o tempo total de reintentos, e aplica un prazo global para o fluxo de traballo para que os axentes aniñados non poidan reiniciar unha e outra vez a mesma operación. Se unha dependencia falla repetidamente, usa un disxuntor (circuit breaker) para deter temporalmente as solicitudes.

Para operacións con efectos secundarios externos, asigna unha clave de idempotencia estable a cada acción lóxica e reutilízaa en todos os reintentos. Se a API admite a deduplicación no servidor, pode recoñecer as solicitudes repetidas sen realizar a acción dúas veces. Se non a admite, consulta o sistema externo mediante un ID de correlación ou outra referencia fidedigna.

Cando non poidas determinar que pasou, detente e escala o problema.

Un exemplo da lóxica de reintentos para o noso axente de CI, expresada en pseudocódigo:

Nota sobre o código: O exemplo supón que a API de CI permite buscar execucións por ID de solicitude. O request_id só evita duplicados se o provedor garante explicitamente a idempotencia. bounded_retry() é pseudocódigo ilustrativo. En produción, os reintentos deberían estar limitados tanto por un orzamento de reintentos por operación (número máximo de intentos ou tempo transcorrido) como polo prazo global do fluxo de traballo.

Para fluxos de traballo máis longos que abarcan varios servizos, considera o patrón Saga para coordinar accións compensatorias cando fallen os pasos posteriores. Iso si, lembra que a compensación non sempre é unha reversión completa. Podes reverter unha actualización da base de datos, pero non podes desfacer o envío dun correo electrónico.

5. Encamiña e paraleliza o traballo con orzamentos de recursos explícitos

Aquí hai dúas cousas que equilibrar: canta capacidade do modelo necesita cada tarefa e cantas tarefas podes executar simultaneamente. Se fallas en calquera das dúas, arríscaste a que os axentes compitan polas cotas compartidas da API ou a depender só de modelos de razoamento caros.

Para a selección do modelo, axusta a capacidade do modelo e o esforzo de razoamento á complexidade da tarefa: algo sinxelo, pero bastante ignorado. Ten en conta que podes configurar regras de encamiñamento e avaliar os modelos ti mesmo, ou usar unha plataforma de orquestración que se encargue da selección do modelo por ti.

Por exemplo, o modo de esforzo de Perplexity Computer permíteche escoller canto esforzo merece unha tarefa sen ter que seleccionar un modelo manualmente. Escolle Lixeiro, Estándar, Alto ou Ultra, e Perplexity selecciona automaticamente o modelo orquestrador e o seu nivel de razoamento. Ese orquestrador delega despois subtarefas en axentes de apoio, que poden usar modelos de distintos provedores.

Perplexity avalía as configuracións dos modelos en canto a calidade e custo, e dá prioridade ás opcións menos caras que ofrecen resultados comparables. Tamén podes usar os controis personalizados se prefires escoller ti mesmo o modelo e o nivel de razoamento.

Para o paralelismo, o límite debería vir determinado pola túa infraestrutura e as dependencias externas. Valida os límites de taxa de solicitudes e de tokens das API compartidas e, despois, realiza probas de carga do teu fluxo de traballo cunha concorrencia crecente. Observa se mellora o rendemento ou se as solicitudes empezan a quedar en cola, a ralentizarse ou a devolver erros 429.

Para que o consumo de recursos sexa previsible, aplica límites de recursos e controis de planificación:

• Controla a concorrencia e as taxas de solicitudes: Limita as chamadas en curso por servizo e pon en cola o traballo excedente. Lembra que un límite de concorrencia por si só non fará cumprir os límites de solicitudes por minuto nin de tokens por minuto.
• Fai un seguimento dos orzamentos de tokens e de custos: Contabiliza o uso en todo o fluxo de traballo, incluídos os subaxentes, e deixa de iniciar traballo novo cando o orzamento restante sexa insuficiente.
• Aplica prazos de execución: Establece límites de tempo para as tarefas e o fluxo de traballo, e propaga a cancelación aos axentes en execución cando sexa posible.
• Respecta as dependencias: Inicia as tarefas posteriores só cando estean dispoñibles as entradas que necesitan, en lugar de lanzar todos os axentes á vez.

6. Aplica aprobacións e illa a execución dos axentes

Nunca lle pidas ao modelo que decida se as súas propias accións son seguras. En lugar diso, dálles aos axentes permisos de privilexio mínimo e aplica regras de aprobación baseadas no risco no código da aplicación. Se os axentes executan código, illa esa execución do teu contorno anfitrión e restrinxe o acceso a ficheiros, redes e credenciais. Isto limita os danos se o axente comete un erro ou executa código non seguro.

«Son escéptico cos sistemas multiaxente demasiado complicados, sobre todo cando os axentes revisan e aproban o traballo uns doutros. Podes acabar con varios axentes que se pasan con total confianza o mesmo erro sen que ninguén o detecte realmente», advirte Spilker.

Ampliar

Para as accións que requiren aprobación humana, pausa a execución e garda a operación proposta exacta:

• os seus parámetros
• o seu recurso de destino
• o seu commit ou versión do estado
• a decisión do revisor

Ademais, define que ocorre se a aprobación se rexeita, caduca ou require escalado. Isto é esencial nos frameworks que permiten retomar a execución, xa que ao retomar un nodo interrompido vólvese executar o código desde o inicio dese nodo. Calquera efecto secundario anterior á interrupción podería executarse de novo.

Así, se a aprobación se rexeita ou caduca, a solicitude péchase. Se o commit de destino, os parámetros ou os permisos cambian antes da execución, invalida a aprobación e solicita unha nova.

Spilker tampouco apoia a idea de que os axentes totalmente autónomos e de extremo a extremo sexan o obxectivo. «Para min, o mellor enfoque é crear uns poucos axentes centrados, con responsabilidades claras, permisos definidos e revisión humana nos momentos axeitados. Segues gañando eficiencia sen renunciar ao control total», conclúe.

7. Verifica os resultados de forma independente e proba o comportamento de recuperación

Algunha vez tiveches un axente que informaba de Éxito cando en realidade fallara? É molesto, por non dicir exasperante, e a solución non é rápida porque a mensaxe final do axente non che vai dicir necesariamente onde saíron mal as cousas.

Para investigalo, rastrexa o que pasou durante a execución e verifica os resultados de forma independente. Así que dediquemos un tempo a illar e resolver o problema.

Rastrexa o fluxo de traballo para identificar que saíu mal

Antes de depurar os prompts dun axente, captura todo o camiño de execución. Necesitas unha traza que conecte as invocacións de axentes, as chamadas a ferramentas, os erros e os reintentos baixo a mesma execución do fluxo de traballo.

As convencións semánticas de GenAI de OpenTelemetry proporcionan unha forma estandarizada de describir estas operacións. Por exemplo, invoke_workflow identifica a execución dun fluxo de traballo, invoke_agent a invocación dun axente e execute_tool unha chamada a unha ferramenta. Cada operación pode rexistrarse como un span co seu tempo, estado e metadatos relevantes.

Este paso proporciónache unha traza do camiño de execución, para que poidas identificar onde tropezou un axente.

Unha traza de execución ilustrativa.

Revisa os resultados de forma independente

Usa comprobacións programáticas sempre que sexa posible. Valida as saídas contra esquemas JSON, executa probas unitarias e de integración, comproba que existen os artefactos necesarios e consulta os sistemas externos para confirmar que as accións tiveron éxito realmente.

Para as saídas que requiren un xuízo subxectivo, e que polo tanto non se poden avaliar mediante comprobacións programáticas, introduce un axente revisor independente. Un enfoque é un bucle implementador–revisor–resolutor, no que un axente produce un artefacto, un revisor cun contexto novo identifica problemas e un resolutor corríxeos antes de que se volva executar a validación.

Aínda así, cómpre validar as conclusións do revisor sempre que sexa posible e, se usas avaliadores baseados en LLM para avaliacións repetidas, calibra os seus xuízos con exemplos revisados por humanos.

Inxecta fallos para probar a recuperación

Ata agora, rastrexaches o que executaron os axentes e comprobaches se os seus resultados eran correctos. Pero que acontece cando un worker falla a metade dunha tarefa ou cando unha API esgota o tempo de espera despois de aceptar unha solicitude? Sorprendentemente, o teu fluxo de traballo pode funcionar perfectamente en condicións normais, pero fallar durante a recuperación.

Para probalo, introduce fallos deliberadamente nun contorno de probas:

• Simula tempos de espera esgotados na API
• Provoca caídas dos workers entre as escrituras externas e os puntos de control
• Devolve saídas de ferramentas con formato incorrecto
• Fai caducar as aprobacións

Despois de cada proba, inspecciona a traza de execución para ver que pasos se executaron, en que punto se retomou o fluxo de traballo e se algunha acción se repetiu ou se omitiu. Despois, revisa os resultados reais.

Supón que o teu axente de CI envía unha solicitude para iniciar unha execución de probas, pero a resposta da API esgota o tempo de espera. O axente volve tentalo, recibe unha resposta correcta e informa de Success. Todo parece correcto ata que revisas o servizo de CI e descobres que se crearon dúas execucións de probas en lugar dunha.

Por iso debes verificar tanto o estado rexistrado do fluxo de traballo como os cambios reais nos sistemas externos. Unha proba de recuperación só debería superarse cando o fluxo de traballo alcanza o estado esperado sen efectos secundarios non desexados.

Engade os fallos que descubras ás túas probas de regresión para que os cambios futuros non os volvan introducir.

En definitiva, o éxito significa que o fluxo de traballo superou as comprobacións obrigatorias e que se verificaron os seus resultados externos.

Preguntas frecuentes sobre a orquestración de axentes de IA

Por que fallan os axentes de IA illados a escala empresarial?

Os axentes illados poden completar correctamente as súas tarefas individuais, pero producir resultados incoherentes en conxunto. Imaxina un axente de vendas que recupera as condicións dun cliente ás 10:00, un axente de prezos que calcula un orzamento con prezos actualizados ás 10:05 e un axente xurídico que revisa un contrato que cambiou ás 10:07. Cada axente traballa cunha instantánea diferente do negocio, polo que os seus resultados poden contradicirse entre si.

O problema acentúase a escala empresarial porque os axentes interactúan con varios sistemas que se actualizan de forma independente, funcionan con permisos diferentes e non comparten necesariamente contexto nin estado de execución.

Como se evitan os bucles infinitos de reintentos nos axentes de IA?

Establece límites en varios niveis: número máximo de reintentos de chamadas a ferramentas, número máximo de iteracións do axente, profundidade de delegación e un prazo global para o fluxo de traballo. Clasifica os fallos antes de reintentar. Para as respostas 429 transitorias, respecta Retry-After cando se proporcione. Noutros casos, usa unha espera exponencial limitada (backoff) con jitter.

Deixa de reintentar solicitudes sen cambios despois de erros de validación ou de permisos. Se un servizo descendente falla repetidamente, un disxuntor (circuit breaker) pode evitar que os axentes xeren carga adicional.

Como se retoma un fluxo de traballo de axentes de IA despois dunha caída?

O mecanismo de recuperación depende do teu contorno de execución. Con LangGraph, un checkpointer persistente como PostgresSaver almacena o estado do grafo baixo un thread_id, o que permite continuar a execución a partir do estado persistido. Con Temporal, outro worker pode reconstruír un fluxo de traballo reproducindo o seu historial de eventos. Durante a reprodución, reutiliza os resultados de actividades rexistrados previamente.

Se a aplicación se volve despregar mentres aínda hai fluxos de traballo en execución, o estado gardado e os historiais de execución poden deixar de ser compatibles. Temporal resolve isto mediante Worker Versioning e a aplicación de parches aos fluxos de traballo. Nos sistemas baseados en puntos de control, planifica as migracións de esquema e proba a recuperación con estados gardados existentes antes de despregar cambios incompatibles.

Como se proba a fiabilidade da orquestración de axentes de IA?

Executa as mesmas tarefas representativas varias veces e distingue entre pass@k (se polo menos un dos k intentos ten éxito) e pass^k (se todos os k intentos teñen éxito)

Mide os resultados por categoría de tarefa e versión do fluxo de traballo en lugar de depender dunha única taxa de éxito agregada. Fai un seguimento do éxito no primeiro intento, da coherencia entre execucións repetidas, da latencia p95, do custo por tarefa completada e da proporción que require intervención humana. Informa dos tamaños de mostra e dos intervalos de incerteza das taxas de éxito.