Escolher a forma de execução em função do trabalho
Uma aplicação pode utilizar regras fixas, tarefas de modelo, processos com IA e agentes no mesmo processo. A escolha diz respeito à forma como cada parte do trabalho é executada e verificada.
O código da aplicação é adequado a regras que o negócio consegue especificar: um campo obrigatório, um cálculo, uma permissão de conta ou uma alteração permitida num registo. Um modelo acrescenta a capacidade de interpretar informação menos estruturada, consultar material relevante ou preparar uma resposta.
Um processo definido estabelece as etapas em código. Um agente permite ao modelo escolher a próxima ferramenta ou passo autorizado à medida que trabalha para um objetivo. Essa flexibilidade é útil quando a informação encontrada determina o que deve consultar ou fazer a seguir.
Considere um pedido de serviço. O software pode verificar o acesso do utilizador e registar o pedido. Um modelo pode interpretar o conteúdo. Um agente pode consultar fontes aprovadas, investigar informação em falta e preparar uma ação. A aplicação aplica depois a validação e a política de aprovação antes de alterar um registo de negócio.
As orientações de arquitetura da Anthropic distinguem processos definidos em código de agentes que orientam o seu próprio processo e uso de ferramentas. A distinção ajuda a descrever o âmbito com precisão; um produto não precisa de escolher um único padrão para todas as tarefas. Criar agentes eficazes
Definir os limites de operação juntamente com a capacidade
As instruções de um agente descrevem a sua tarefa. A aplicação envolvente impõe o que o sistema pode efetivamente fazer: os registos disponíveis, as ferramentas que pode chamar e as alterações permitidas por essas ferramentas.
Num agente que trata um pedido, isso pode significar ler um conjunto autorizado de registos, pedir os dados em falta e preparar uma atualização. O cliente decide que ações podem ser automáticas e quais exigem aprovação. Implementamos essa política na aplicação, incluindo quem a pode alterar. O desenho deve tornar as permissões e os requisitos de aprovação visíveis aos responsáveis.
- Acesso aos dados
- Que registos e material de referência podem ser utilizados por este utilizador e nesta execução?
- Ações permitidas
- Que ferramentas estão disponíveis, com que dados de entrada e verificações de permissão?
- Estado e validação
- O que aconteceu, o que falta resolver e o que tem de ser verificado antes de uma alteração?
- Revisão e recuperação
- Quando deve uma pessoa decidir, quando deve o trabalho parar e como pode um processo interrompido continuar?
Uma resposta estruturada ajuda a aplicação a interpretar o resultado. Não demonstra que todos os campos plausíveis correspondam à origem. A avaliação e a validação de negócio continuam a ter de examinar o significado, incluindo o que o sistema faz quando não consegue estabelecer uma resposta.
Avaliar capacidade e repetibilidade
Os agentes podem aumentar a capacidade de um sistema quando este precisa de adaptar o próximo passo, investigar com ferramentas ou coordenar trabalho independente. Mais computação pode justificar-se por um resultado melhor.
Mais agentes podem melhorar os resultados, com maior utilização
Estudo publicado · outubro de 2026| Configuração | Precisão média agregada | Tokens registados por caso |
|---|---|---|
| Controlador de agente único | 76.65% | 23,713 |
| EvoAgent | 79.70% | 30,037 |
Três execuções de 3 302 casos cada, em dez benchmarks de raciocínio, programação e utilização de ferramentas. A precisão do EvoAgent é superior em 3,05 pontos percentuais, com cerca de 1,27 vezes os tokens registados. Os valores de tokens estão arredondados.
Âmbito desta comparação
O estudo utiliza reimplementações normalizadas e um único modelo. Os desvios-padrão reportados nas três execuções são de 0,32 pontos percentuais para o controlador e de 0,26 para o EvoAgent; não são intervalos de confiança. Os tokens de entrada e saída registados não equivalem ao custo monetário nem ao custo operacional total. Um resultado académico agregado não demonstra o benefício para uma tarefa de negócio concreta.
Esta conclusão coloca uma pergunta concreta à aplicação: a capacidade adicional melhora o trabalho o suficiente para justificar as suas exigências operacionais? A resposta exige tarefas representativas e critérios de revisão acordados, incluindo as ações executadas ao longo do processo.
A repetibilidade merece um teste próprio. Uma demonstração bem-sucedida mostra que uma tarefa pode ser concluída uma vez. Um serviço em operação precisa também de saber com que consistência a implementação trata o trabalho.
Ter sucesso uma vez e repeti-lo são testes diferentes
Benchmark publicado · junho de 2025τ²-bench v1, Figura 3. Resultados do GPT-4.1 com quatro tentativas por tarefa. Os valores são percentagens reportadas e arredondadas. «Quatro execuções» significa que as quatro tentativas independentes têm sucesso; não significa quatro repetições dentro de uma tentativa.
Dados e interpretação
| Domínio | k = 1 | k = 2 | k = 3 | k = 4 |
|---|---|---|---|---|
| Retalho | 74% | 64% | 58% | 53% |
| Aviação | 56% | 46% | 42% | 40% |
| Telecomunicações | 34% | 26% | 22% | 19% |
O benchmark utiliza utilizadores simulados e versões históricas dos modelos. Os utilizadores também podem cometer erros. Quatro tentativas e valores arredondados limitam a interpretação. São resultados históricos de um benchmark, não classificações atuais de modelos nem resultados dos serviços da Everything Special.
Isso implica avaliar várias execuções completas, analisar falhas e testar o percurso de exceção. Estes resultados de investigação não estabelecem uma taxa de falha para a sua organização. Ilustram por que motivo um exemplo bem-sucedido é prova insuficiente para entrar em produção.
A interface disponível ao agente também conta. No artigo AutomationBench, de abril de 2026, os resultados reportados mudaram quando os mesmos modelos receberam interfaces de ferramentas diferentes. Um modo limitado disponibilizava antecipadamente ferramentas relevantes para a tarefa, eliminando parte do trabalho de descoberta. É informação útil sobre o desenho de interfaces, com uma redução privilegiada do âmbito da tarefa; não é uma poupança medida pela substituição de agentes por automação. AutomationBench v1, secção 7
Comparar a utilização do modelo antes de aumentar a escala
Uma estimativa de custos de operação precisa do volume esperado, das chamadas geradas por cada item, da informação enviada em cada chamada e da margem para repetição. Um agente pode variar os passos entre casos; um processo definido explicita parte dessa estrutura.
A calculadora abaixo permite comparar dois orçamentos de tokens. Não assume que as opções produzam a mesma qualidade. Essa é uma questão distinta, a avaliar nos testes.
Comparar um orçamento de tokens
Este cenário isola os custos de tokens do modelo. A opção A envia todos os itens para IA. Na opção B, pode alterar a proporção de itens e as chamadas necessárias para cada item tratado por IA.
Custos mensais ilustrativos de tokens do modelo · USD
Diferença com estes pressupostos: 715,00 US$ / mês
Preços, fórmula e exclusões
Exemplo de preços datado: preços base do Claude Haiku 4.5 de 1 USD por milhão de tokens de entrada e 5 USD por milhão de tokens de saída, verificados a 1 de novembro de 2026. A adequação do modelo deve ser avaliada para a tarefa.
Custo = itens × proporção com IA × chamadas × (1 + taxa de repetição) × (tokens de entrada + 5 × tokens de saída) / 1 000 000Na opção A, a proporção com IA é de 100%. As duas opções utilizam o mesmo número de tokens por chamada e a mesma margem para repetição. As chamadas reais podem ter durações diferentes e um agente pode precisar de um número variável de passos.
Exclui desenvolvimento, alojamento, integrações, ferramentas, descontos, cache, impostos, monitorização e revisão humana. A igualdade da qualidade dos resultados é um pressuposto a testar. Estima os encargos para o volume introduzido, não o custo por caso concluído com sucesso.
Preços oficiaisNuma implementação real, utilize as distribuições observadas, além das médias. Documentos longos, contexto repetido e casos difíceis podem consumir mais do que um item comum. Analise o custo dos resultados aceites e o trabalho que continua a caber às pessoas.
Medir o processo completo
O objetivo é um serviço útil em operação. A qualidade do modelo, a correção da aplicação, o comportamento das integrações e o esforço humano contribuem para esse resultado.
- Quality: resultados úteis, resultados aceites, correções e erros que chegam a outro sistema.
- People: tempo de revisão, casos por resolver e esforço de recuperação de uma execução incompleta.
- Operation: tempo de conclusão, permissões, falhas, ações repetidas e recuperação.
- Cost: utilização do modelo, custos de ferramentas, alojamento, monitorização, suporte e manutenção.
Acorde a utilização pretendida e os critérios de aceitação antes do desenvolvimento. Forneça exemplos representativos, incluindo informação em falta e pedidos invulgares. Compare as alternativas relevantes com as mesmas tarefas e registe as condições em que cada uma funciona bem.
Desenvolvemos a IA e os agentes como parte desse sistema de software: a capacidade, as ferramentas e interfaces, a avaliação e os controlos necessários à operação. A solução adequada depende do trabalho e dos resultados dos testes.
Aplicar a um processo de negócio
Os nossos serviços tecnológicos abrangem aplicações, integrações, processos com IA e agentes, com as responsabilidades de implementação e operação definidas no âmbito.
Fluxos de trabalho com IA e agentes Conhecer um âmbito de tratamento de pedidosFontes e método
Fontes primárias consultadas a 1 de novembro de 2026. Os números reproduzem resultados de investigação de versões específicas. A calculadora de tokens é um cenário próprio com preços publicados e datados. As nossas recomendações de engenharia são uma interpretação desse trabalho; não são apresentados resultados de clientes da Everything Special.