De Coding Agent a Funcionário Digital: A Aplicação de IA Está Convergindo para uma Mesma Arquitetura de Sistema

Observando consecutivamente os estandes de vários produtos Agent na Cloud Village Conference, a descoberta mais contraintuitiva é: embora pareçam pertencer a indústrias completamente diferentes, o que emerge é o mesmo conjunto de OS.

Qoder trabalha com desenvolvimento de software, QwenWork com trabalho cognitivo baseado em conhecimento, TinyFish como Web Browser Agent, WonderClip com produção de vídeo, e OpenSearch com busca e pesquisa.

Removendo a camada específica de cada indústria, suas estruturas subjacentes convergem de forma notável:

Contexto → Planejamento → Habilidade → Execução → Verificação → Memória → Resultado de Negócios

(Context → Planning → Skill → Execution → Verification → Memory → Business Outcome)

Esta é a arquitetura de sistema única para a qual os produtos Agent estão convergindo.

慢慢学AI<001>

⚠ Este artigo utiliza o ecossistema da Alibaba Cloud (Qoder/QwenWork/TinyFish/WonderClip/OpenSearch) como exemplo prático. No entanto, as avaliações arquiteturais apresentadas abaixo são igualmente aplicáveis a cenários auto-hospedados e às plataformas de Agent de Huawei Cloud, AWS, Azure e GCP — a pilha de sete camadas representa uma convergência de estrutura de engenharia, não uma conclusão proprietária de uma nuvem específica.

1. O核已从”responder”转向”executar continuamente”

Na era dos chatbots, o loop básico do sistema era simples: o usuário envia uma entrada, o modelo produz uma saída.

Na era dos Agents, as tarefas podem durar minutos, horas ou até mais. O sistema precisa ler arquivos, utilizar navegadores, chamar APIs, executar código, aguardar tarefas assíncronas, verificar resultados, repetir em caso de falhas e manter estados.

Um único prompt com um modelo não consegue lidar com tudo isso.

O sistema precisa começar a ter um Runtime.

Tradução para Português

A tarefa de Legal Document Fill Out demonstrada ao vivo pelo QwenWork é bastante representativa: ela é executada em um Sandbox Container isolado, onde o Agent possui uma área de trabalho virtual e pode invocar ferramentas de processamento de documentos. O Marketing Content Generation, por sua vez, sobrepõe diferentes ferramentas como PPT, imagens, Lip Sync, Python, Pillow e FFmpeg.

O ambiente de execução do Agent está cada vez mais próximo de um computador programável — uma unidade de trabalho protegida por sandbox, capaz de invocar múltiplos runtimes e ferramentas, capaz de executar tarefas continuamente sem interrupções. O Sandbox Container oferece isolamento, a área de trabalho virtual fornece capacidade de operação visual com interface gráfica, e a invocação de ferramentas permite que o modelo passe de “falar” para “agir”. Uma vez que essa combinação se estabilize, o Agent começa verdadeiramente a substituir a superfície operacional humana, e não apenas a superfície de raciocínio.

II. O “One Foundation” do Qoder é um sinal de produto, não um slogan

Há uma frase no estande de apresentação do Qoder:

One workbench. Four entries. One foundation.

Learn AI Slowly – Uma Arquitetura de Integração para Agentes de IA

Acima estão as interfaces de acesso: Workbench, CLI, IDE, JetBrains Plugin, com possibilidade de expansão para Cloud Agents e Agent SDK.

Porém, o verdadeiro destaque fica na camada Foundation compartilhada logo abaixo.

Se cada interface implementasse seu próprio Agent de forma independente, o sistema rapidamente perderia o controle. A abordagem mais racional consiste em consolidar capacidades essenciais em um Harness compartilhado: agendamento de tarefas, permissões, ferramentas, Sandbox, Memory, Model Router e Verification.

Cada interface assume apenas a responsabilidade de adaptar-se a diferentes perfis de usuários e cenários: CLI para programadores, IDE para desenvolvedores, Workbench para perfis não técnicos, JetBrains para migração de código legagy, Cloud Agents para invocações assíncronas e Agent SDK para integrações de terceiros. Enquanto isso, as camadas de调度, memória, gateway de ferramentas, verificação e modelo de segurança compartilham a mesma infraestrutura subjacente.

O valor dessa reutilização é maior do que parece à primeira vista. Dentro de uma organização, a experiência de design do sandbox do Coding Agent, o design de permissões e a experiência de recuperação podem ser transferidas diretamente para o Browser Agent, o Content Agent e o Ops Agent. O maior custo de reinventar a roda não está no desenvolvimento, mas no desastre de governança causado pela inconsistência de comportamento entre diferentes agentes quando surgem problemas – o mesmo código pode ser alterado no IDE Agent e no CLI Agent, porém os modelos de permissão são diferentes e os formatos de logs de auditoria também, tornando impossível a rastreabilidade quando algo falha.

Terceira parte: Uma pilha de agentes genérica tem pelo menos sete camadas — e um mapa de investimentos para cada camada (construção interna / compartilhamento / validação pendente)

Após abstrair esses conteúdos, dividi a pilha de agentes em sete camadas. A tabela a seguir também responde à questão mais prática para uma organização: quais camadas devem ser construídas internamente, quais podem ser compartilhadas diretamente via código aberto ou adquiridas, e quais ainda estão indefinidas.

Camada	Conteúdo	Julgamento de Investimento (Observação no local 2026)
1. Entry (entrada)	Web / CLI / IDE / IM / API / GitHub Issue / estação de trabalho empresarial	Camada de adaptação, não construir internamente — escolher a forma de entrada mais adequada aos seus utilizadores
2. Task (tarefa)	Goal / Spec / Context / Acceptance / Priority / Budget	Construção interna, mas muito fina — é o contrato de Task, se for mal escrito, toda a cadeia downstream fica desorganizada
3. Context & Memory (contexto e memória)	conhecimento empresarial, conhecimento de código, histórico de tarefas, decisões, preferências do utilizador, estado atual	Construção interna obrigatória — Context é um ativo organizacional, não se compra
4. Planning & Skill (planeamento e competência)	divisão de tarefas, seleção de Skill, seleção de modelo, estratégia de paralelismo	Construção interna de Skill, Planning pode ser aproveitado — Skill é a muralha defensiva

| 5. Runtime & Tools | Shell / Browser / Computer Use / Filesystem / Git / Database / MCP / API Corporativa | Semi-autônomo — Runtimes genéricas podem utilizar stacks open source como Browser Use e Anthropic Agent SDK; porém, API gateways corporativos devem ser desenvolvidos internamente |
| 6. Verification & Recovery | Testes, verificação de regras, avaliação de resultados, recuperação de falhas, retry e rollback | Autônomo — Regras de verificação são fortemente acopladas ao negócio e soluções compradas não funcionam |
| 7. Governance | Permissões, Secrets, Audit, Custo, Policy, Aprovação Humana | Imprescindível auto-desenvolver — E deve ser projetado sob a perspectiva de engenharia, não de compliance |

A seguir, detalhamos uma sentença-chave para cada uma das sete camadas:

Camada 1 — Entry. Web, CLI, IDE, IM, API, GitHub Issue, workstations corporativas — todos são apenas pontos de entrada para tarefas, e por si sós não geram valor de negócio.

Segundo Nível – Task. Goal, Spec, Context, Acceptance Criteria, Priority e Budget devem fazer parte da Task. Uma descrição válida de Task deve deixar claro: o objetivo, o porquê de ser executada, como saber que está concluída, qual a sua prioridade e quanto pode custar. Se um sistema de Agent nem sequer possui esses seis campos preenchidos, as tarefas começam a circular sem controlo pelo sistema.

Terceiro Nível – Context & Memory. O conhecimento empresarial, o conhecimento de código, o histórico de tarefas, as decisões, as preferências dos utilizadores e o estado atual residem todos aqui. As funcionalidades salientadas in loco pelo Qoder — Repo Wiki, Knowledge Graph e Knowledge Cards — são manifestações concretas deste nível: transformar “factos dispersos” em “activos que a máquina consegue recuperar”.

Quarto Nível – Planning & Skill. O sistema avalia como decompor a tarefa, escolhe que Skill reutilizável aplicar, determina que passos requerem modelos potentes e quais podem ser executados em paralelo. Esta é a camada onde o Agent verdadeiramente começa a “pensar”, e também onde as capacidades do modelo são invocadas de forma mais intensiva.

Quinta camada: Runtime & Tools. Shell, Browser, Computer Use, Filesystem, Git, Database, MCP e APIs corporativas pertencem a esta camada. É a interface onde o Agent realmente se conecta com o mundo externo.

Sexta camada: Verification & Recovery. Testes, verificação de regras, avaliação de resultados, recuperação de falhas, novas tentativas e rollback.

Sétima camada: Governance. Permissões, Secrets, Audit, Cost, Policy e Aprovação Humana. Inclui também itens mais detalhados — registro de algoritmo (algoritm filing na China), explicabilidade do modelo, atribuição de responsabilidade por erros, controle de dependências de terceiros, controle de transferência de dados transfronteiriça (数据出境评估/avaliação de transferência de dados para fora da China) — estas são algumas restrições rígidas que setores altamente regulamentados no país (saúde, finanças, transporte, mídia, segurança pública) não conseguem evitar ao colocar Agents em operação.

O modelo permeia tudo isso, mas o modelo não é mais igual a toda a plataforma de Agent. Esta é a mudança de percepção mais subestimada nos últimos dois anos — muitas equipes gastaram tempo demais comparando modelos, o que realmente determina se um sistema consegue entrar em produção são as seis camadas restantes.

Quatro, Browser Agent complementa a interface entre Agent e o mundo real

Produtos como TinyFish são bastante representativos neste cenário.

Agentes de Navegador: Preenchendo a Lacuna Crítica do Agent Runtime

Muitos sistemas de negócios reais não dispõem de APIs adequadas, ou então os usuários precisam fazer login em sites, interagir com páginas dinâmicas, preencher formulários, navegar entre abas e baixar arquivos. A automação tradicional depende de scripts com Playwright ou Puppeteer, que se tornam inúteis assim que a página muda. O Browser Agent permite que o modelo compreenda diretamente a página web e execute ações.

Essa capacidade preenche uma lacuna fundamental no Agent Runtime: o ambiente web real.

Um agente de submissão de links externos, um agente de operações, um agente de compras ou um agente de pesquisa podem precisar executar ações dentro de sites.

Mas o verdadeiro desafio aqui nunca foi “conseguir clicar em um botão”. Em sistemas de produção, é preciso resolver uma série de questões críticas:

Gestão de sessão — Como lidar com cookies e tokens, e o que fazer quando expiram?

Concorrência — Quando uma tarefa envolve múltiplas abas abertas simultaneamente, como sincronizar as operações?

Recuperação de falhas — Se a página trava ou a conexão cai, como retomar a execução?

Prevenção de envios duplicados — Como evitar que um clique seja executado novamente após uma oscilação de rede?

Utilização de proxies — Como contornar restrições geográficas ou de IP?

Tratamento de CAPTCHA — Como superar verificações anti-bot?

Isolamento de permissões — Como gerenciar múltiplas contas de forma segregada?

Por fim, há a questão mais fundamental: comprovar que a tarefa realmente foi concluída — como validar que a ação teve efeito.

Num nível mais profundo, a injeção indireta de prompts (Indirect Prompt Injection) representa a ameaça de segurança mais concreta para Browser Agents em 2026: a OWASP classifica a injeção de prompts como a principal ameaça de IA em 2026, e basta inserir um texto oculto numa página para induzir o Agent a enviar os cookies do utilizador. A nível arquitetural, não existe uma solução completa;，只能在 Sandbox、动作白名单、Ambient Credential 控制上做工程折中，只能 fazer compromissos de engenharia no controlo de Sandbox, lista branca de ações e credenciais ambiente.

O Browser Use também precisa de ser integrado no Harness. As capacidades ao nível de demonstração estão longe de ser suficientes. Uma organização que pretenda realmente utilizar Browser Agents em produção enfrentaria custos neste nível que seriam suficientes para reconstruir um sistema RPA completo.

Portanto, o Browser Agent parece uma aplicação, mas na realidade faz parte do Runtime.

Cinco、A verificação determina se um Agent pode obter privilégios mais elevados

Existe uma regra muito direta nos sistemas de Agent: quanto maior a autonomia, mais forte tem de ser a verificação e a governação.

Um Agent que apenas pode redigir e-mails tem um custo de erro limitado.

Um Agent que pode modificar databases de produção, submeter código, enviar orçamentos publicitários e operar backends corporativos apresenta um perfil de risco completamente diferente.

Uma plataforma de Agent verdadeiramente madura não pode apenas responder “o que ele pode fazer” — precisa também deixar claro:

a que ele tem permissão de acessar;
o que ele tem permissão de modificar;
quais ações exigem aprovação;
qual registro de auditoria cada passo deixa;
como se recuperar após uma falha;
como o sistema comprova que a tarefa foi realmente concluída.

Aqui está um julgamento de engenharia: se um Agent não consegue fornecer evidências verificáveis para cada uma de suas ações, sua autonomia deve ser limitada ao papel de “consultor”. Em outras palavras, a autonomia é ampliada progressivamente dentro de uma estrutura de conformidade regulatória através da validação de capacidades — e não desbloqueada por uma lista de funcionalidades. Mesmo que um Agent consiga chamar 100 APIs do ponto de vista funcional, se não conseguir comprovar que cada chamada atingiu o resultado esperado, em cenários de forte regulamentação como finanças, saúde ou dados transfronteiriços, ele só pode permanecer no papel de “consultor”.

É também por isso que o Governance se tornará cada vez mais importante em ambientes corporativos — não é uma questão do departamento de conformidade, mas sim uma capacidade que os departamentos de engenharia precisam projetar desde o início, em conjunto com o Runtime.

六、Model Router Se Tornará um Dispatcher Básico — Mas Nem Toda Camada Precisa do Modelo Mais Caro

A adoção de múltiplos modelos está se tornando cada vez mais comum.

Um sistema de múltiplos modelos que realmente agrega valor não se resume a deixar o usuário escolher entre GPT, Qwen, Claude ou outros modelos em um menu dropdown.

A abordagem mais sensata é deixar o sistema realizar o roteamento automaticamente com base na tarefa.

Planejamentos complexos e julgamentos arquiteturais ficam com modelos mais poderosos; implementações de código triviais e organização de textos usam modelos mais econômicos; tarefas visuais recorrem a modelos multimodais; classificações em lote passam por modelos rápidos; revisões críticas voltam aos modelos mais robustos.

Por trás disso há um princípio de engenharia direto: diferentes tarefas exigem curvas completamente distintas de “capacidade-custo”. Delegar classificação em lote a um modelo poderoso é desperdício; usar um modelo rápido para decisões arquiteturais resulta em retrabalho constante. A Requesty publicou em 2026 um dado empírico: rotear 70% das tarefas rotineiras para modelos nano, 20% para modelos de nível intermediário e 10% para modelos frontier, pode reduzir o custo médio por consulta em 60% a 80%, quase sem perda de qualidade — trata-se de uma indicação direcional, sendo que os números específicos variam conforme o tipo de tarefa e a estratégia de roteamento.

Modelos estão gradualmente se transformando em recursos computacionais dispatcháveis. A Agent Platform assume a responsabilidade de fazer escolhas dinâmicas entre qualidade, velocidade, custo e risco.

Exemplo Prático de Roteamento em Camadas

Um Agent recebe a tarefa de “analisar a estratégia de precificação dos concorrentes e oferecer recomendações”. Na fase de “compreender a tarefa, decompor etapas e definir prioridades”, ele utiliza o modelo poderoso; ao “classificar 100 SKUs por faixa de preço”, alterna para um modelo rápido; e quando chega o momento de fazer julgamentos 종합, retorna ao modelo poderoso.

Se todas as tarefas fossem executadas com o modelo mais caro, o custo do sistema seria proibitivo; se todas utilizassem o modelo barato, haveria falhas contínuas em nós complexos. O verdadeiro valor de engenharia está na estratégia de agendamento, não na escolha do modelo.

Sete, Skill: A Camada Estratégica que Conecta o Runtime Genérico ao Negócio Vertical — e o Diferencial Competitivo do Futuro

Um Agent Runtime genérico, por si só, não possui valor de negócio.

Ele precisa de Skills para atuar em cenários reais.

Coding Skill sabe como ler Repos, escrever Specs, executar Tests e gerar PRs. Ele define quando é obrigatório executar testes unitários primeiro, quando é permitido pular, quais campos o PR deve conter, e quais mudanças exigem revisão humana.

SEO Research Skill sabe como buscar palavras-chave, analisar Search Intent, verificar intensidade competitiva, gerar outline de conteúdo e confirmar que a página já foi indexada. Não se trata apenas de “fazer pesquisa de palavras-chave”, mas de um fluxo completo de processos.

Habilidade Criativa de E-commerce

Compreende as nuances de marca, SKU, formatos de plataforma, requisitos de conformidade e processos de auditoria. Domina as especificações de tamanho de imagem de cada plataforma, termos proibidos, certificações de categoria e os fluxos de auditoria finais antes da publicação.

Habilidade de Operações (Ops Skill)

Possui conhecimento sobre como monitorar sistemas, analisar logs, gerenciar containers, operar bancos de dados e executar rollbacks. Consegue distinguir quais alertas podem ser tratados automaticamente e quais exigem intervenção humana, além de identificar quais são os pontos seguros para reversão.

Uma Skill não se resume a um SOP tradicional — ela constitui um ativo executável com gerenciamento de versões, dependências, iterações e mecanismos de contingência em caso de falhas. Inspirada no protocolo Skills lançado pela Anthropic em outubro de 2025, essa abordagem permite empacotar a experiência de cada domínio em pastas SKILL.md, possibilitando que diferentes plataformas de Agent a carreguem conforme a necessidade, sem a necessidade de reescrever tudo a cada novo projeto.

As Skills fazem a ponte entre capacidades genéricas de execução e conhecimento especializado de domínio.

Por isso, no futuro, muitas aplicações de IA terão sua principal defensibilidade nas Domain Skills validadas por um grande volume de tarefas reais. Essas Skills encapsulam o conhecimento prático de “como as coisas devem ser feitas nesse campo” — são difíceis de serem substituídas por novos modelos ou plataformas, e tendem a se appreciating com o tempo.

Oito、Lentes Setoriais: Formas Concretas de Implementação em Quatro Tipos de Organizações

As quatro seções a seguir não são narrativas, mas sim um mapeamento da “Stack de Sete Camadas” abstrata para setores específicos, mostrando onde estão os principais pontos de atrito em cada indústria.

Telecom/Operadoras: Mudanças de planos, ativação de linhas corporativas e diagnóstico de falhas em domínios cruzados exigem atravessar múltiplas camadas — BSS/OSS/CRM/billing. O maior gargalo para implementação de Agents está na conciliação entre domínios: quando um Agent modifica um plano de usuário no CRM, ele precisa notificar simultaneamente o billing e o OSS, caso contrário os ciclos de faturamento ficam desalinhados. Nas camadas da Stack, as mais valiosas são a Camada 5 — Runtime & Tools (para integração de interfaces multi-domínio) — e a Camada 7 — Governance (para auditoria contábil).

Finanças/Bancos: Gerenciamento de riscos, combate à lavagem de dinheiro, reconciliação e reportes regulatórios exigem interpretabilidade, auditabilidade e rastreabilidade. Um Agente de combate à lavagem de dinheiro precisa justificar cada decisão de “aprovar” ou “bloquear” com base em qual regra foi aplicada, qual histórico de transações foi considerado e quais documentos do cliente foram consultados. No Stack, as camadas mais valiosas são a 6ª — Verification (cadeia de evidências interpretável) — e a 7ª — Governance (算法备案 + controles de transferência de dados transfronteiriços) — pois, no enquadramento regulatório financeiro chinês, ambas são requisitos obrigatórios para implantação, e não apenas diferenciais competitivos.

Manufatura: Os sistemas MES, ERP, QMS e SRM historicamente operam de forma isolada, de modo que decisões transversais — como determinar se a capacidade produtiva insuficiente justifica a aquisição adicional de materiais — exigem constante comunicação entre esses quatro sistemas. O formato prático de um Agente na manufatura é como camada de orquestração entre sistemas, e não como substituição de um sistema individual. Ele é capaz de consultar simultaneamente os materiais do ERP, as taxas de defeitos do QMS, a utilização da capacidade do MES e o desempenho dos fornecedores do SRM, gerando uma avaliação integrada. No Stack, as camadas mais valiosas são a 5ª — Runtime (gateway corporativo de APIs) — e a 3ª — Context (acúmulo de conhecimento de processos, falhas históricas e experiência de chão de fábrica).

Varejo: Agentes em Cenários de Alta Demanda e Operações Multiplataforma

No varejo, os agentes de IA lidam com processos complexos que atravessam múltiplos domínios — pedidos, pagamentos, estoque, logística e atendimento ao cliente. As principais aplicações incluem testes de estresse em sistemas durante eventos de grande volume, manutenção de consistência de inventário, prevenção de arbitragem promocional e reconciliação contábil entre plataformas. Os primeiros casos de uso concreta de agentes no setor são operações criativas (substituição de imagens de produtos, mudança de cenários, geração de materiais multilíngues) e assistentes para agentes de atendimento. Na arquitetura em camadas, o nível mais valioso é o quarto nível — Skill — que encapsula os processos de conformidade e auditoria específicos para cada SKU e canal; e o sexto nível — Verification — que valida automaticamente se os materiais criativos atendem às diretrizes das plataformas.

Princípio Aplicável a Organizações de Todos os Setores

A característica comum a todos os tipos de organização é esta: quanto mais baixo na pilha, maior o benefício do compartilhamento; quanto mais alto, maior a vantagem da construção própria. Capacidades fundamentais como Runtime, Model Router e Tool Gateway são mais econômicas quando desenvolvidas em conjunto por múltiplas empresas ou adotadas a partir de soluções open source maduras. Por outro lado, Skill, Context e Governance devem ser construídos internamente, pois estão intrinsecamente ligados aos processos de negócio, às exigências regulatórias e aos ativos organizacionais.

Nove, O Produto Final Pode Parecer Completamente Diferente, Mas a Camada Inferior Compartilha o Mesmo Sistema Operacional

Um Coding Agent e um Video Agent possuem interfaces, usuários e modelos de negócio completamente distintos.

Contudo, ambos requerem na camada inferior: Context, Task, Skill, Tools, Runtime, Verification, Memory e Governance. No final, todos convergem para a entrega de resultados de negócio tangíveis.

Um agente corporativo de conhecimento e um Browser Agent parecem bastante distantes, mas no final ambos precisam resolver questões de permissões, estado, recuperação de falhas e auditoria.

Portanto, ao desenvolver múltiplos produtos de IA no futuro, vale a pena distinguir duas camadas.

A camada superior mantém-se vertical. Cada produto gira em torno de uma Job completa, possuindo sua própria experiência do usuário, objetos de dados e métricas de negócio. O Coding Agent tem como objetos o Repo e o Code Review; o agente de vídeo tem como objetos o Script e o Asset; o agente de pesquisa tem como objetos o Source e a Citation. A profundidade vertical de cada um deles não pode ser substituída por capacidades genéricas.

A camada inferior compartilha o máximo possível. Agent Runtime, Model Router, Tool Gateway, Memory, Audit, Secrets e Evaluation podem se tornar infraestrutura genérica.

Isso evita tanto a repetição de trabalho em cada produto quanto a construção, desde o início, de uma plataforma “agente universal” gigante sem usuários — esta última foi uma armadilha pela qual muitas equipes caíram nos últimos dois anos, tentando atender a todos os cenários de uma só vez, o que resultou em nenhuma cena atingindo uma profundidade utilizável.

Um caminho mais sólido começa validando o valor em tarefas específicas e, em seguida, extraindo as capacidades底层 mais重复出现. O raciocínio subjacente é: a camada genérica só pode emergir de cenários concretos, não de diagramas de arquitetura. Projetar um Runtime que “suporte todos os cenários” desde o início geralmente significa não ter optimizado corretamente para nenhum cenário específico.

Três perguntas de auto-verificação inversa (use após terminar de escrever):

O Runtime que abstraímos foi validado em pelo menos dois cenários concretos diferentes para demonstrar sua genericidade?
Cada camada do nosso design corresponde a um problema de negócio real onde ocorreu uma falha concreta?
Se cortássemos metade do orçamento hoje, quais camadas manteríamos? Se a resposta for “contexto e skill”, a direção está correta; se for “runtime e gateway”, talvez seja necessário refazer.

Esta também é uma avaliação de longo prazo que levei da Cloud Village Conference: está surgindo uma nova camada de sistema acima dos modelos, que não pertence exclusivamente a nenhum produto específico, mas está gradualmente se tornando o OS da era dos Agents. Quem沉淀 esta camada de OS primeiro e de forma mais sólida terá mais probabilidades de colher dividendos na próxima迭代 de produtos.

Implicações para decisores

Se você é o líder de AI nº1 de uma empresa com receita anual acima de 5 bilhões (CDO/CIO/CTO), três coisas que você pode começar a fazer agora:

Faça um snapshot das sete camadas do Stack de Agent da sua organização – não se apresse para comprar soluções; primeiro avalie se cada camada está vazia, adquirida de terceiros ou já em estado semi‑acabado. Esse próprio diagrama revelará o verdadeiro gargalo.
Selecione um cenário com alto ROI e implemente um ciclo vertical completo primeiro – não construa o Runtime primeiro. Escolha entre Coding Agent, assistente de atendimento ao cliente ou assistente de desenvolvimento, execute as quatro camadas (Context, Task, Skill, Verification) e só então discuta a criação da plataforma.
Eleve a Governança ao nível de engenharia, não a deixe apenas como questão de compliance – permissões, auditoria, explicabilidade, atribuição de erros e controle de dependências de terceiros devem ser projetados desde o início junto com o agente de negócio, e não complementados depois.

Você pode estar se perguntando

Q1: Qual a diferença entre este Stack de sete camadas e o framework de orquestração multi‑agent proposto pelo Gartner/IDC?

O Gartner/IDC foca na coordenação e governança de múltiplos agentes em nível organizacional; as sete camadas deste artigo descrevem a estrutura de engenharia interna de um único agente. Uma organização pode abordar ambas as camadas simultaneamente – um único agente percorre as sete camadas, enquanto a orquestração entre múltiplos agentes ocorre no nível de composição. O Stack é micro; a orquestração é macro.

Q2: Por que a camada de modelos não ocupa uma camada própria?

Porque os modelos funcionam como um recurso transversal no sistema de Agent, não como uma camada isolada. O Model Router distribui diferentes modelos como recursos computacionais, tratando-os como “ferramentas” no mesmo nível de importância do Shell ou do Browser no Runtime. Os modelos são fundamentais, claro, mas não justificam monopolizar a complexidade do Agent.

Q3: Times pequenos deveriam pular essa camada e usar produtos completos como ChatGPT ou Claude?

Sim. Para equipes com receita anual inferior a 100 milhões de yuans e baixa complexidade organizacional, é mais econômico utilizar produtos de Agent já prontos (como Browser Use, Manus ou Alibaba Cloud Bailian Agent). As sete camadas discutidas neste artigo partem da pergunta sobre se organizações com receita anual acima de 5 bilhões de yuans deveriam construir sua própria plataforma de Agent — criar plataforma para times pequenos seria otimização reversa.

Autoexame crítico (para você, e para mim mesmo)

Se você concordar mentalmente com qualquer uma das três frases abaixo, pode ser que esteja sendo conduzido pela narrativa, em vez de se orientar por evidências:

“Desde que o modelo seja suficientemente poderoso, o Agent funcionará por conta própria.” (O modelo é uma condição necessária, mas não suficiente. As seis camadas superiores determinam se ele pode ser colocado em produção.)
“Precisamos de uma plataforma de Agent universal.” (O custo dessa ideia provavelmente excede o valor de negócio que ela pode gerar em seis meses.)
“O Skill pode esperar até que o modelo se estabilize para ser consolidado.” (O Skill é um ativo organizacional; quanto mais tarde for consolidado, mais tarde começará a render juros compostos.)

Se você não concordou com nenhuma das três afirmações acima, continue lendo.

Referências e notas no final do artigo (fontes por item + nível de evidência + indicação de posição)

“Um ambiente de trabalho. Quatro pontos de entrada. Uma base.” ——Painéis e blogs oficiais da Qoder, demonstração no Cloud Conference 2026 + artigo Introducing Qoder 1.0 publicado na Alibaba Cloud Community em 2026-08-31. Nível de evidência: afirmação do fabricante (posição da Alibaba).
QwenWork Legal Document Fill Out: Sandbox Container + Desktop Virtual + Chamada de Ferramentas ——Demonstração ao vivo do QwenWork da Alibaba Cloud, artigo da Alibaba Cloud Community de 2026-09-25. Nível de evidência: afirmação do fabricante (posição da Alibaba).
QoderWake como produto de “funcionário digital”, lançado pela Alibaba em 2026-04-30 ——Entrada da Qoder na Baidu Encyclopedia + fontes oficiais da Alibaba. Nível de evidência: afirmação do fabricante (posição da Alibaba).
OWASP 2026: Prompt Injection lidera lista de ameaças — Síntese do State of Browser Use, maio de 2026 (Michael Livs blog). Nível de evidência: compilação de terceiros (posição da OWASP, consenso do setor).
Requesty: roteamento escalonado 70/20/10 pode reduzir custos em 60-80% — Blog oficial da Requesty, 2026. Nível de evidência: alegação do fornecedor (visão do服务商 de roteamento de modelos, números otimistas demais, apenas como indicador direcional).
Microsoft Agent Governance Toolkit (AGT), código aberto sob MIT em 2026-04-02 — Reportagem do niteagent.com. Nível de evidência: compilação de terceiros (posição da Microsoft, mas sendo projeto open source, dados verificáveis).
Protocolo Anthropic Skills: lançado em 16/10/2025, código aberto como padrão aberto em 18/12/2025 ——Blog da Anthropic Engineering + compilação do Substack + Medium LM Po. Nível de evidência: afirmação do fabricante + síntese de terceiros (posição da Anthropic).
IDC prevê que 40% dos fabricantes adotarão agendamento orientado por IA em 2026 ——Resumo Groovy Web 2026, cite relatório IDC. Nível de evidência: síntese de terceiros (posição do IDC, dados direcionais仅供参考).
Stripe “Minions”: mescla 1.300+ PRs por semana, 0 linha de código escrita, toda revisão feita por humanos ——Stripe engineering team, Steve Kaliski no programa How I AI em 25/03/2026 + reprise no ByteMonk em 14/02/2026. Nível de evidência: afirmação do fabricante (posição da Stripe, números referenciáveis, cenário interno da engenharia da Stripe, não generalizável para média do setor).
BCG 2026 Applied AI Index: agentic representa 22% (2026) → 39% (2030) do valor total da IA ——Relatório públicamente disponível do BCG. Nível de evidência: síntese de terceiros (posição da consultoria, referência direcional dos números).
Gartner prevê que 40% das aplicações empresariais incorporarão AI Agents orientados a tarefas em 2026, contra menos de 5% em 2025 ——Revisão de Paul Okhrem em 2026, com referência ao Gartner. Nível de evidência: síntese de terceiros (posição do Gartner, referência direcional).
CAC/NDRC/MIIT da China publicam conjuntamente a “Opinião sobre a Padronização de Agentes e o Desenvolvimento Inovador”, com vigência a partir de 15/07/2026 ——Boletim mensal de IA da Rimon Law, julho de 2026. Nível de evidência: síntese de terceiros (posição de escritório jurídico, documento regulatório verificável).

TinyFish: Arrecadou $47M, clientes incluem Google/DoorDash/Amazon, cold start no browser <250ms —— Relatório SwitchTools 2026. Nível de evidência: compilação de terceiros (visão de site de avaliação de produtos, dados precisam ser verificados no site oficial da TinyFish).

Se você está avaliando como construir uma plataforma de Agent dentro da sua empresa, quais capacidades devem ser desenvolvidas internamente/adquiridas/compartilhadas e quais Agent Runtime oferecem o maior potencial de reuse, entre em contato conosco. Somos especializados em consultoria de transformação de IA corporativa — da arquitetura de Agent e design de Runtime até o acúmulo de Skills, ajudá-lo a transformar “Agents pontuais” em uma “plataforma de Agent de nível organizacional”.

Serviços de Capacitação e Consultoria em IA

Capacitação Corporativa: Direcionada a gestores e líderes de negócio, curso de imersão de 3 dias por ¥90.000/sessão — desmembramos para sua equipe as sete camadas do Agent Stack, a perspectiva de engenharia de Governance e a metodologia de Skill Building.
Consultoria Especializada: Diagnóstico arquitetônico de 90 minutos a partir de ¥3.000, oferecendo avaliação independente do snapshot das sete camadas da sua organização, identificação de lacunas e recomendações de build vs. buy; acompanhamento profundo com orçamento por projeto.
Palestras e Apresentações para Gestão: Compartilhamento temático em conferências do setor, reuniões fechadas ou fóruns — agenda personalizada após contato.

E-mail de contato: [email protected]

Leitura complementar: Framework de Sete Etapas para Transformação em IA, que detalha sistematicamente o caminho completo para implementação de IA corporativa.

Pontos de Localização (referência multilíngue, convenções IAIUSE 2026-08-09)

Ao traduzir para os 19 idiomas, substituir o conteúdo abaixo por adaptações ao mercado-alvo, mantendo estrutura e visual:

(Esta seção serve como guia interno de localização — manter a mesma estrutura nos materiais traduzidos para outros mercados.)

中文稿内容	Português
Qoder / QwenWork / TinyFish / WonderClip / OpenSearch	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch

| Habilidade de Domínio / Habilidade de Codificação / Habilidade de Pesquisa SEO / Habilidade Criativa de E-commerce / Habilidade Operacional | Habilidade de Domínio (manter) / Habilidade de Codificação / Habilidade de Pesquisa SEO / Habilidade Criativa de E-commerce / Habilidade Operacional | Habilidade de Domínio / Habilidade de Codificação / Habilidade de Pesquisa SEO / Habilidade Criativa de E-commerce / Habilidade Operacional | Habilidade-de-Domínio / Habilidade-de-Codificação / Habilidade-de-Pesquisa-SEO / Habilidade-Criativa-de-E-commerce / Habilidade-Operacional | Habilidade de Domínio / Habilidade de Codificação / Habilidade de Pesquisa SEO / Habilidade Criativa de E-commerce / Habilidade Operacional |

Sobre Esta Série

«Observações da Yunqi» é uma série de análises práticas lançada pela IAIUSE, partindo da Cloud Town Congress 2026, com o olhar investigativo de um pesquisador para decifrar as mudanças reais que estão acontecendo na indústria de IA — sem perseguir manchetes, focando apenas nas direções em que se está a investir e na força das evidências.

A série cobre tópicos como a camada de sistema acima dos modelos foundation, a implementação de Agents, ativos de Context, design organizacional de IA empresarial, migração de unidades competitivas de produtos de IA, entre outros, num total de cerca de 10 artigos.

Com quase 8 anos de experiência em consultoria empresarial e análise de negócios em grandes organizações, trabajei na IBM em projetos relacionados a telecomunicações, finanças, seguros e manufatura. Depois, segui atuando na linha de frente de produtos de operadoras, produtos de internet e desenvolvimento de aplicações de IA, focando em análise de requisitos, design de produto e implementação entre equipes.

Na verdade, por trás deste blog há uma pequena equipe — eu e mais um ou dois colegas com quem colaboro há muito tempo, dividindo as responsabilidades em pesquisa de ferramentas de programação com IA, mapeamento de casos de governança organizacional e conversas de coaching. A maioria dos projetos que mencionamos como “ajudamos empresas a atravessar” foram entregueis colaborativamente por nós.