Nota do autor: usando o exemplo de referência da linha de produção SMT da NVIDIA FOX, explicamos como delinear o agente de gestão, os agentes especializados e os pontos de revisão humana quando sistemas multiagente chegam ao chão de fábrica.
Quando uma placa de circuito dispara um alarme na estação AOI, a equipe precisa examinar imagens de inspeção, consultar registros de produção, acionar o retrabalho e ainda verificar se a temperatura do forno de refusão está anormal. As evidências ficam espalhadas por vários sistemas, e o que realmente consome tempo costuma ser a coordenação. Em 4 de novembro de 2026, a NVIDIA apresentou publicamente o Factory Operations Blueprint (FOX, na sigla em inglês), com uma arquitetura de referência baseada em agente de gestão + agentes especializados + pontos de revisão humana.
Este não é mais um artigo de divulgação sobre conceitos de multiagente. O texto usa como base factual o exemplo oficial público de linha de produção SMT (montagem em superfície) e organiza o método de divisão de responsabilidades em etapas práticas de implementação. Os métodos de decisão de revisão e o ritmo de implantação descritos aqui são recomendações práticas nossas e serão explicados separadamente das capacidades oficiais do FOX.
Valor central: ao terminar a leitura, você vai aprender a dividir agentes conforme os limites de responsabilidade, definir pontos de revisão humana de acordo com o nível de risco e montar um plano de implementação que vai da execução em modo sombra à execução controlada.
Pontos essenciais para implantar multiagentes no chão de fábrica
A chave para dividir um sistema multiagente é definir primeiro quem coordena, quem faz o julgamento especializado e quem assume a responsabilidade final. A tabela abaixo mostra a divisão básica entre os três tipos de papel; os passos seguintes giram em torno dela.
| Papel | Principais responsabilidades | Responsabilidades que não deve assumir | Valor na implantação |
|---|---|---|---|
| Agente de gerenciamento | Entender a tarefa, elaborar o plano, delegar tarefas e consolidar resultados | Substituir modelos especializados na realização de julgamentos detalhados | Conectar evidências entre sistemas e reduzir a coordenação manual |
| Agente especializado | Executar detecção, agendamento e análise dentro de um contexto delimitado, retornando evidências | Decidir sobre o fluxo geral ou alterar políticas globais além da sua alçada | Julgamentos verificáveis e fácil substituição individual |
| Ponto de revisão humana | Tratar conclusões incertas, aprovar ações de alto risco e confirmar planos de correção | Revisar item por item todos os resultados de baixo risco | Preservar os limites de responsabilidade em segurança e qualidade |
O que cabe ao agente de gerenciamento em multiagentes
O agente de gerenciamento do FOX é composto por três partes: o Modelo de Linguagem Grande (LLM) fica responsável por interpretar a tarefa, correlacionar dados, elaborar o plano e avaliar os resultados; o Agent Harness conecta ferramentas, habilidades, memória persistente e agentes especializados, usando NemoClaw por padrão e também aceitando alternativas; o NVIDIA OpenShell isola o ambiente de execução e controla as políticas de acesso a arquivos, comandos e destinos de rede.
Esse design mostra que o agente de gerenciamento não é apenas um comando, mas um ambiente de execução de longa duração. Ele precisa responder continuamente ao operador enquanto processa tarefas em segundo plano e tarefas agendadas, além de lembrar o andamento da investigação. Portanto, ao dividir as responsabilidades, o estado da tarefa, a lógica de delegação e os critérios de conclusão devem ficar na camada de gerenciamento, e não espalhados pelos agentes especializados.
Como delimitar as fronteiras dos agentes especializados em multiagentes
No FOX, os agentes especializados também são baseados em LLM e cada um tem suas próprias instruções, contexto, habilidades e ferramentas. Eles podem chamar modelos dedicados — por exemplo, usar o NVIDIA Cosmos para inspeção visual e o Kumo para detecção de anomalias em séries temporais — e então devolver as descobertas ao agente de gerenciamento, que decide o próximo passo.
Para decidir se vale a pena separar um agente especializado, considere três pontos: se ele precisa de dados ou modelos exclusivos, se tem critérios de aceitação independentes e se pode vir a chamar ferramentas de alto privilégio. Se nenhum dos três se aplicar, normalmente é mais simples transformar isso em uma habilidade do agente de gerenciamento.
Como dividir agentes de gerenciamento e agentes especializados: exemplo de linha de produção SMT
O exemplo oficial começa com um alerta de AOI. O agente de gerenciamento obtém o identificador da placa de circuito, os componentes afetados e as imagens de inspeção por meio de um servidor MCP ou de uma API, e então dispara uma segunda avaliação. O identificador da placa é o campo-chave que atravessa todo o fluxo, e o adaptador precisa preservar identificador, timestamp, unidade e referência de origem, para que os agentes seguintes possam rastrear o histórico de produção e o estado da máquina.
| Agente especializado | Entrada | Capacidade invocada | Saída | Regra de handoff |
|---|---|---|---|---|
| Agente de inspeção visual | Imagens da placa, amostras de referência, critérios de decisão já aprovados | NVIDIA Cosmos | Descobertas, evidências, incerteza | Defeito confirmado segue para tratamento e investigação; conclusão indefinida vai para atendimento humano |
| Agente de gestão de frota | Identificador da placa com defeito confirmado e destino | No exemplo, usa NVIDIA Isaac Sim e ROS 2 | Resultado da verificação de permissões e capacidades, status de conclusão | Na implantação inicial, exige aprovação do operador antes do transporte |
| Agente de análise de causa raiz | Identificador da placa, histórico de processamento, registros de inspeção e teste | Kumo Anomaly, Elasticsearch | Relatório PDF com registros de origem, medições suspeitas, possíveis causas e recomendações de correção | Encaminhado ao gerente da linha de produção para revisão |
Há dois detalhes que vale a pena aproveitar. Primeiro, o agente de inspeção visual não devolve apenas “bom” ou “defeituoso”: ele também retorna evidências e incerteza, para que o agente de gerenciamento possa decidir, com base nisso, qual caminho seguir. Segundo, a análise de causa raiz pode ser disparada por uma falha no teste funcional — mesmo que a inspeção óptica não tenha encontrado nenhum defeito visível — e não precisa depender da conclusão do agente especializado anterior.
O processo de investigação do agente de análise de causa raiz também é claro. Para um suspeito de defeito de solda, ele primeiro usa os horários de entrada e saída do forno de refusão para localizar as leituras de temperatura do forno, depois usa o Kumo Anomaly para encontrar padrões anômalos e compara com outros lotes, resultados de inspeção e o manual da máquina. Investigações históricas podem orientar a direção da busca, mas a conclusão precisa se basear no programa e nos registros atuais — e isso reduz o risco de reaproveitar experiências desatualizadas.
Também vale notar que, no fluxo de referência, a gestão de frota é demonstrada em um ambiente de gêmeo digital. Ao conectar robôs reais e AMRs (robôs móveis autônomos), é preciso fazer separadamente a integração de equipamentos específica da fábrica; não dá para tratar a aprovação na simulação como equivalente à disponibilidade na linha de produção.
Como configurar pontos de revisão humana em sistemas multiagentes
Nem sempre mais pontos de revisão humana é melhor. Com revisões excessivas, os operadores se cansam rapidamente e passam a clicar em “aprovar” por hábito; com poucas revisões, ações erradas podem afetar diretamente a linha de produção física. Usando o exemplo do FOX, a tabela abaixo pode servir como uma primeira versão da matriz de revisão.
| Cenário de decisão | Tratamento no exemplo | Forma de revisão sugerida | Revisor sugerido |
|---|---|---|---|
| Suspeita de defeito dentro de desvio aceitável | Retorna evidências e continua a produção conforme a política da fábrica | Liberação por política, com registro retido e auditoria por amostragem | Engenheiro de qualidade |
| Conclusão da inspeção visual ambígua | Encaminha para revisão humana | Julgamento humano item a item | Inspetor de qualidade |
| Defeito confirmado, necessita transporte para retrabalho | Na implantação inicial, exige aprovação prévia do operador | Aprovação antes da ação | Operador de campo |
| Reparo e reteste da placa | Concluído pelo operador antes da embalagem | Execução humana com registro dos resultados | Operador de retrabalho |
| Conclusão de causa raiz e recomendações de correção | Gera relatório para revisão do gerente da linha de produção | Decisão após revisão do relatório | Gerente da linha de produção |
As duas primeiras colunas da tabela acima vêm do exemplo oficial; as duas últimas são nossas recomendações para implementação. Ao enfrentar uma nova decisão fora da matriz, faça três perguntas em sequência:
- A ação é reversível? Consultas somente leitura e geração de relatórios são fáceis de desfazer; mover placas físicas e alterar parâmetros de processo custam mais.
- Qual é o alcance do impacto? Impactar uma única placa e impactar toda a linha de produção devem ter níveis de aprovação diferentes.
- As evidências são suficientes? Quando há evidências conflitantes, dados ausentes ou o modelo declara incerteza, deve-se encaminhar para revisão humana em vez de continuar inferindo.
É melhor não deixar as regras de revisão apenas no comando. O FOX usa uma camada de política como o OpenShell para definir as operações permitidas e os momentos que exigem revisão do operador; assim, mesmo que o modelo erre no julgamento, ele não pode contornar os limites de execução. O comando pode orientar o comportamento, mas o controle real de permissões deve ser garantido pelo ambiente de execução.
Multiagentes em produção no chão de fábrica: implementação rápida em 6 etapas
O FOX está disponível atualmente em acesso antecipado. O blueprint já inclui vários padrões, mas as partes específicas da fábrica ainda precisam ser implementadas pelos desenvolvedores. Antes de começar, deixe claro onde termina a responsabilidade de cada um: isso evita confundir a arquitetura de referência com um produto pronto para uso.
| Módulo | O que o blueprint oferece | Responsabilidade do desenvolvedor |
|---|---|---|
| Agente de gerenciamento | Ambiente persistente com habilidades, ferramentas, memória e capacidade de delegação | Definição de tarefas, critérios de conclusão e integração de aplicações |
| Conhecimento da fábrica | Padrões de ingestão e recuperação de dados | Mapeamento de identificadores, timestamps, unidades e permissões de origem |
| Agentes especializados | Exemplos de detecção, análise de causa raiz, relatórios e gestão de frota | Critérios de decisão da fábrica, novos papéis e validação de saídas |
| Integração de equipamentos | Padrões MCP e API, conexão com ROS 2 e Isaac Sim | Conexão com equipamentos físicos e estratégias de movimentação |
| Implantação | Configuração de serviços, endpoints de modelo e unidades de simulação opcionais | Seleção de recursos, configuração de endpoints e verificação de limites de acesso |
Independentemente de você adotar o FOX ou não, pode seguir estas 6 etapas:
- Escolha um único cenário de ciclo fechado: comece por um processo com uma condição de disparo bem definida, como “do alerta de AOI ao retrabalho e ao relatório de causa raiz”, e deixe claros os critérios de conclusão.
- Unifique a chave primária dos dados: mapeie MES, ERP e bancos de dados das máquinas para o mesmo conjunto de identificadores, preservando timestamps, unidades e referências de origem; manuais e SOPs também devem ser incluídos na base de conhecimento pesquisável.
- Defina o contrato de saída dos agentes: exija que os agentes especializados retornem pelo menos a conclusão, a origem das evidências e a incerteza; os nomes dos campos podem ser definidos livremente, mas precisam ser validáveis por código.
- Aplique o princípio do menor privilégio: distribua permissões de ferramentas e de acesso à rede por papel; por exemplo, a análise de causa raiz só pode ler registros de produção, enquanto somente a gestão de frota pode iniciar movimentações, e isso apenas depois de passar por verificações de permissão e capacidade.
- Execute primeiro em simulação ou no modo shadow: faça os agentes darem sugestões sem executar ações reais, use as conclusões humanas como referência de comparação e concentre a revisão em falsos positivos, falsos negativos e falta de evidências.
- Libere a automação gradualmente: comece com aprovação antes da ação; depois que os indicadores estiverem estáveis e o responsável confirmar, mude as ações de baixo risco e reversíveis para liberação por política e auditoria por amostragem.
Em cada etapa, recomenda-se deixar registros de auditoria, incluindo a versão dos dados de entrada, as ferramentas chamadas, a conclusão do modelo e quem aprovou. Os exemplos oficiais fazem os relatórios trazerem registros de origem e valores de medição suspeitos justamente para que quem revisa possa verificar as conclusões, em vez de apenas escolher entre acreditar ou não.
Seleção de modelos e configuração de interfaces para multiagentes
O FOX permite escolher modelos de ponta ou modelos abertos de acordo com os requisitos de implantação. Os exemplos citados oficialmente incluem GPT-6 Astra e NVIDIA Nemotron. Na prática, vale avaliar cada papel separadamente, sem a obrigação de que todos os agentes usem o mesmo modelo.
| Papel | Foco do modelo | Capacidade nos exemplos oficiais | Canal de validação de protótipo | Base de cobrança |
|---|---|---|---|---|
| Agente de gerenciamento | Capacidade de planejamento, chamada de ferramentas, contexto longo | GPT-6 Astra, NVIDIA Nemotron | Endpoints internos da fábrica, APIYI apiyi.com etc. | Conforme as regras de cobrança do endpoint efetivamente usado |
| Agente especializado | Controle de precisão e custo conforme a tarefa | Baseado em LLM, com chamada a modelos dedicados | Endpoints internos da fábrica, APIYI etc. | No canal APIYI, conforme a página de preços |
| Modelos de visão e séries temporais | Precisão de domínio, forma de implantação | NVIDIA Cosmos, Kumo Anomaly | Implantação preferencial conforme o blueprint | Calculado conforme a solução de implantação efetiva |
Sugestão de integração: Se quiser primeiro validar com dados anonimizados a divisão de trabalho e os comandos da camada LLM, você pode chamar os modelos abordados neste artigo via APIYI. A APIYI é compatível com os formatos de interface da OpenAI e da Anthropic; normalmente basta configurar três itens:
api_key,base_urlemodel. Consulte a documentação para saber os endereços específicos e os modelos disponíveis: https://docs.apiyi.com .Observação sobre preços: Os preços dos modelos, critérios de cobrança, preço unitário de entrada e saída e preço de cache devem seguir os dados reais da página de preços da APIYI: https://docs.apiyi.com/models . Este artigo não lista números específicos; na estimativa, recomenda-se contabilizar separadamente os volumes de chamadas das camadas de gerenciamento e especializada.
Perguntas Frequentes (FAQ)
Q1: O que é um agente gestor em sistemas multiagente?
É o coordenador responsável por entender a tarefa, criar um plano, delegar trabalho aos agentes especializados e consolidar os resultados. No FOX, ele também conecta memória, habilidades e ferramentas, além de operar por longos períodos sob restrições de políticas de acesso.
Q2: Qual é a diferença entre um agente gestor e um agente especializado?
O agente gestor se concentra em “o que fazer em seguida”; os agentes especializados se concentram em “qual é a conclusão técnica sobre este assunto”. O primeiro domina o fluxo global, enquanto o segundo realiza tarefas focadas usando apenas contexto, habilidades e ferramentas delimitados, devolvendo as evidências à camada de gestão.
Q3: Em um sistema multiagente, quais decisões devem manter revisão humana?
Recomenda-se priorizar julgamentos com conclusões ambíguas, ações em equipamentos físicos, alterações de parâmetros de processo e decisões de correção. O exemplo oficial exige explicitamente que resultados incertos sejam encaminhados para revisão humana, que o transporte inicial seja aprovado por um operador e que o relatório de causa raiz seja revisado pelo gerente da linha de produção.
Q4: Um sistema multiagente de fábrica pode ser totalmente local?
Sim. O FOX permite hospedar localmente o ambiente dos agentes, os modelos e o armazenamento de dados em uma NVIDIA DGX Station. Porém, uma implantação totalmente local exige que todos os modelos e endpoints de serviço estejam dentro da rede da fábrica, para que registros de produção, imagens, comandos e resultados de investigação permaneçam no ambiente local.
Q5: Como validar rapidamente, via API, o desenho de divisão de trabalho de múltiplos agentes?
Você pode primeiro montar dois papéis — gestor e especialista — usando amostras anonimizadas, e comparar a decomposição de tarefas e o uso de ferramentas entre modelos diferentes. Com a APIYI apiyi.com, é possível integrar no formato compatível com OpenAI ou Anthropic; consulte docs.apiyi.com para saber como configurar.
Q6: Quais são as limitações de usar modelos hospedados externamente? Como estimar custos?
Ao usar modelos externos, é preciso avaliar quais dados serão enviados ao endpoint. Processos que envolvem dados sensíveis de produção devem ser anonimizados primeiro ou migrados para modelos locais. O custo depende do número de chamadas e do comprimento do contexto. Ao usar a APIYI, o preço unitário e o preço de cache seguem https://docs.apiyi.com/models.
Pontos-chave para colocar sistemas multiagente em produção
- Agente de gestão cuida do fluxo: responsável de forma unificada pelo planejamento, delegação, acompanhamento de status e consolidação dos resultados.
- Agentes especializados cuidam do julgamento: papéis independentes definidos por dados, critérios de aceitação e permissões de ferramentas.
- Toda saída precisa vir com evidências: as conclusões devem acompanhar fontes e incertezas, facilitando a verificação a jusante.
- A revisão segue o risco: escalonada conforme reversibilidade, alcance do impacto e suficiência das evidências.
- Permissões garantidas por política: coloque as fronteiras de acesso no ambiente de execução, sem depender apenas do comando.
- Simulação não é produção em escala: conectar equipamentos reais exige integrações e processos de aprovação específicos da fábrica.
- O protótipo valida primeiro a divisão de trabalho: use dados anonimizados para comparar modelos via APIYI e só então definir o plano de implantação.
Resumo
Ao colocar sistemas multiagente em produção, o ponto central é a fronteira de responsabilidade, e não a quantidade de agentes:
- Agente de gestão: domina o objetivo global e o estado das tarefas, coordenando evidências entre sistemas e as próximas ações.
- Agentes especializados: acionam modelos e ferramentas dedicados a tarefas bem definidas e retornam descobertas verificáveis.
- Pontos de revisão humana: aplicados a conclusões incertas, ações de alto risco e à decisão final de correção, com execução forçada pela camada de política.
A recomendação é começar com um fluxo de ciclo fechado com gatilho claro, rodar em modo sombra toda a cadeia de dados, evidências e aprovação, e só depois liberar a automação aos poucos. Se precisar comparar rapidamente as opções na camada de LLM, você pode fazer a validação do protótipo com interface unificada via APIYI apiyi.com e, na fase de produção, definir o modo final de implantação conforme as fronteiras dos dados.
📚 Materiais de referência
- Blog técnico da NVIDIA: How NVIDIA Factory Operations Blueprint Coordinates AI Agents to Investigate Production Issues
- Link:
developer.nvidia.com/blog/how-nvidia-factory-operations-blueprint-coordinates-ai-agents-to-investigate-production-issues/ -
Descrição: fonte factual da arquitetura FOX, do exemplo SMT e do modelo de implantação usados neste artigo, publicado em 4 de novembro de 2026.
-
Central de documentação da APIYI: instruções de integração da interface
- Link:
docs.apiyi.com -
Descrição: consulte o método de configuração específico dos formatos compatíveis com OpenAI e Anthropic.
-
Página de preços da APIYI: lista de modelos e dados de cobrança
- Link:
docs.apiyi.com/models - Descrição: verifique a disponibilidade dos modelos, os critérios de cobrança, o preço unitário de entrada e saída e o preço de cache.
Autor: Equipe técnica da APIYI
Contato técnico: fale conosco pela página inicial do site APIYI apiyi.com; há mais materiais disponíveis na central de documentação docs.apiyi.com.
