Unha caixa de chat pode limitarse a responder preguntas, iniciar un fluxo con regras ou dar acceso a un axente que escolle ferramentas. Por iso, ver unha conversa non abonda para saber que sistema hai detrás. Tamén pode existir un axente que traballe a partir dun evento, sen que ninguén lle escriba nun chat.
A diferenza útil aparece cando o proceso necesita consultar datos, decidir un seguinte paso e, quizá, propoñer un cambio. Neste artigo comparamos tres deseños sobre unha mesma petición e sinalamos onde deben estar os permisos e a revisión. Os casos son exemplos de aplicación, non proxectos de clientes.
Tres deseños baixo unha interface parecida
Un chatbot é, en primeiro lugar, unha forma de interacción. Pode responder con texto, buscar nunha base documental ou chamar unha función. Un fluxo de traballo establece no código a orde dos pasos e as condicións para avanzar. Nun axente, o modelo escolle parte dos pasos e das ferramentas segundo o que atopa durante a tarefa.
A distinción entre fluxo predefinido e axente dirixido polo modelo é a que emprega Anthropic na súa guía de arquitecturas. Non é unha clasificación de calidade: un fluxo sinxelo pode resolver mellor unha tarefa estable, con menos custo e máis facilidade para reproducir erros.
| Criterio | Chatbot de consulta | Fluxo con regras | Axente con ferramentas |
|---|---|---|---|
| Obxectivo | Responder unha pregunta | Executar pasos coñecidos | Escoller pasos nunha tarefa variable |
| Quen decide o seguinte paso? | A aplicación busca e presenta | O código e as condicións | O modelo propón; a aplicación valida |
| Acceso a sistemas | Pode consultar fontes autorizadas | Operacións definidas no fluxo | Ferramentas acoutadas por identidade e permiso |
| Control clave | Fontes e resposta verificable | Validación de cada transición | Límites de pasos e aprobación das accións |
Exemplo de aplicación: «En que estado está o meu pedido?»
Imaxinemos un equipo que recibe unha consulta sobre un pedido. Un chatbot conectado a información pública pode explicar como consultar o estado, pero non coñece ese pedido. Se a aplicación autentica a persoa e dispón dunha ferramenta de lectura, pode obter o estado e mostralo. Iso segue sen esixir un axente: un fluxo fixo de identificar, consultar e responder pode abondar.
A petición cambia se hai dous pedidos posibles, a data de entrega non está confirmada e a persoa pide modificar o destino. O sistema debe solicitar aclaración, consultar a fonte correcta e preparar unha proposta. Un axente podería decidir cal destas consultas facer primeiro, pero non debería converter unha resposta ambigua nun cambio irreversible.
O fluxo resolve o caso coñecido; o axente pode investigar excepcións dentro de límites.
- Petición
A persoa pregunta polo seu pedido.
- Fluxo fixo
Identificar, consultar e responder nunha orde definida.
- Excepción
Hai pedidos ambiguos ou falta unha data.
- Axente acoutado
Escolle consultas permitidas e prepara a resposta.
- Aprobación
Unha persoa revisa calquera cambio de destino.
Exemplo conceptual. As consultas e as modificacións precisan permisos distintos.
A autonomía non concede permisos
Que o modelo propoña «cambiar o enderezo» non significa que poida facelo. A aplicación debe verificar a identidade, o pedido concreto, o permiso de escritura e as condicións da operación. Unha ferramenta de consulta non debería aceptar argumentos que lle permitan escribir; unha ferramenta de cambio debe devolver a proposta exacta para revisala.
As ferramentas con funcións claras reducen a ambigüidade. Anthropic recomenda deseñar ferramentas con límites e propósitos distinguibles. Na práctica, é máis doado avaliar «consultar_estado_pedido» e «preparar_cambio_enderezo» ca unha ferramenta xenérica con acceso amplo ao ERP.
- Define que datos pode consultar cada identidade e comproba o permiso no servidor.
- Separa lectura, preparación e execución dunha modificación.
- Mostra á persoa revisora o dato orixinal, a proposta e a súa fonte.
- Limita tempo, número de chamadas e condicións de parada do axente.
- Conserva unha saída manual se non hai información suficiente.
Cando chega cun fluxo e cando probar un axente
Comeza polo camiño máis sinxelo que cumpra a tarefa. Se as entradas, as regras e as excepcións principais se poden enumerar, un fluxo con regras facilita probar resultados. Se a tarefa obriga a investigar fontes diferentes e a escoller consultas segundo o que apareza, un axente acoutado pode merecer unha proba.
| Pregunta | Sinal para un fluxo | Sinal para probar un axente |
|---|---|---|
| Pódese fixar a orde dos pasos? | Si, con poucas excepcións | Non, depende da información atopada |
| Que risco ten un erro? | Pódese validar cada transición | Precisa revisión antes de actuar |
| Hai fontes e ferramentas? | Unha consulta definida abonda | Varias consultas posibles e permisos claros |
| Como se avaliará? | Casos con resultado esperado | Casos, trazas de ferramentas e condicións de parada |
Unha puntuación xenérica do modelo non resolve a decisión. Proba peticións reais, casos ambiguos e fallos das ferramentas; conta a tarefa completa, incluída a revisión. A guía sobre que é un axente de IA desenvolve a arquitectura e a avaliación. Para un proceso concreto, o servizo de axentes de IA permite delimitar as operacións.
Do coñecemento ao proceso
Definamos as accións que necesitas
Trae unha tarefa real, os sistemas que consulta e os cambios que podería preparar. Podemos comparar un fluxo con regras cun axente acoutado e decidir que revisar antes de actuar.
Falemos do teu proceso ↗
