AIREITERTrocar de modelo não deveria obrigar ninguém a refazer toda a orquestração do agente. Na prática, porém, esse tipo de retrabalho costuma comprometer cronogramas. O Microsoft Copilot harness no Microsoft Foundry é a resposta gerenciada da Microsoft: a mesma camada de execução usada no Copilot Code, Copilot Studio, app do GitHub Copilot, CLI e Visual Studio Code agora está em prévia pública, com runtime gratuito até 1º de dezembro de 2026 (blogs.microsoft.com). Vale criar experimentos desde já, mas a recomendação é manter a produção na stack atual enquanto os limites de prévia descritos abaixo não forem resolvidos.
O que o Microsoft Copilot harness faz na prática
O Microsoft Copilot harness é a camada gerenciada de orquestração que fica em torno do modelo e transforma raciocínio em trabalho concluído. A Microsoft fornece o loop do agente, sandbox, governança e otimização; o desenvolvedor entra com instruções, skills, ferramentas e a escolha do modelo.
A definição da Microsoft é direta: "Se o modelo fornece a inteligência, o harness é tudo o que está ao redor dele" (blogs.microsoft.com). Na prática, ele administra o contexto de trabalho conforme a tarefa evolui, coordena chamadas ao modelo e às ferramentas, executa arquivos e código em sandbox, delega subtarefas delimitadas a subagentes integrados e aplica os limites e as políticas configurados (devblogs.microsoft.com).
| Responsabilidade | Gerenciada pelo Microsoft Foundry | Fornecida por você |
|---|---|---|
| Loop do agente e execução em sandbox | Sim | Não |
| Governança, aprovações e otimização | Sim | Configuração |
| Instruções e skills | Não | Sim |
| Ferramentas, servidores MCP e conhecimento | Não | Sim, com a autenticação que você configurar |
| Seleção de modelo | Lista compatível | Escolha do seu deployment |
Roteamento multimodelo para mais de 20 modelos frontier e BYOK
O Microsoft Copilot harness oferece suporte a mais de 20 modelos frontier de diferentes famílias, incluindo configurações bring-your-own-key (BYOK), e direciona o trabalho ao modelo ou aos modelos mais adequados para cada tarefa (blogs.microsoft.com). A Microsoft não publicou no anúncio a relação completa dos 20 modelos. Antes de planejar uma arquitetura multimodelo, confirme a disponibilidade exata para sua região do Foundry. A proposta é eliminar a necessidade de manter um roteador próprio: "Você fornece as instruções, skills, ferramentas e a escolha do modelo."
Um dos primeiros desenvolvedores resumiu o apelo como não precisar reescrever a camada de orquestração a cada troca de modelo — @ai_fengshou.
Runtime em Rust e os produtos que já o utilizam
O runtime do Microsoft Copilot harness foi recentemente portado para Rust. Segundo a Microsoft, isso reduziu o overhead de sessão e o tempo até o primeiro token (blogs.microsoft.com). A empresa não publicou percentuais de melhoria nem uma tabela de latência, portanto a afirmação deve ser tratada como indicativa.
A Microsoft informa que esse mesmo harness já sustenta o Copilot Code, Copilot Studio, app do GitHub Copilot, GitHub Copilot CLI, Visual Studio Code e outras superfícies do Microsoft e GitHub Copilot (blogs.microsoft.com). De acordo com a empresa, essa base compartilhada foi testada por milhões de usuários em centenas de casos de uso reais (blogs.microsoft.com).
O harness tem extensibilidade aberta por meio de Model Context Protocol (MCP), agent skills e agent plugins (blogs.microsoft.com).
O que mudou em 28 de outubro de 2026
Em 28 de outubro de 2026, a Microsoft fez dois movimentos relacionados: colocou o Microsoft Copilot harness em prévia pública no Foundry Agent Service e disponibilizou de forma geral a resiliência de longa duração para agentes hospedados (devblogs.microsoft.com).
A nomenclatura está mudando. O que a documentação do Copilot Studio ainda chama de GitHub Copilot harness passa a ser chamado de Microsoft Copilot harness nos produtos, embora a atualização das páginas ocorra em ritmos diferentes (microsoft.com).
O Foundry Agent Service passa a oferecer três níveis de abstração: prompt agents sem harness, prompt agents com o Microsoft Copilot harness em prévia e hosted agents, nos quais o desenvolvedor controla o framework (devblogs.microsoft.com). A resiliência de longa duração — capacidade de agentes hospedados se recuperarem de interrupções em fluxos que duram horas ou dias — é a parte que já está em disponibilidade geral.
Como criar um agente com harness no Foundry
Um agente com harness no Foundry é definido de forma declarativa e armazenado junto ao código da aplicação (devblogs.microsoft.com). O fluxo consiste em criar e testar o agente no Foundry, manter as definições sob controle de versão e fazer o deploy com Azure Developer CLI (azd) ou pelo portal do Foundry (devblogs.microsoft.com).
Skills reutilizáveis encapsulam o método
Skills reutilizáveis reúnem instruções, scripts, recursos de apoio e procedimentos que os agentes aplicam em diferentes tarefas. O exemplo documentado usa uma skill research-brief em skills/research-brief/SKILL.md. Ela obriga o agente a confirmar pergunta, público, escopo e período, reunir evidências com ferramentas aprovadas, citar fontes e datas, separar fatos de interpretação e sinalizar evidências conflitantes.
Ferramentas conectadas continuam sob governança
As ferramentas conectadas permitem que agentes usem ferramentas do Microsoft Foundry e ferramentas MCP com autenticação e aprovações configuradas explicitamente. Essa etapa de aprovação é um controle de governança, mas, como mostram os relatos do Reddit abaixo, também pode gerar atrito em produção quando usuários finais encontram repetidos diálogos de consentimento.
Execução, arquivos e delegação de tarefas
Os agentes trabalham com arquivos, executam código e delegam tarefas delimitadas a subagentes integrados, enquanto o agente principal coordena os resultados. A comparação de harnesses do Copilot Studio acrescenta que o harness de origem GitHub cria e edita nativamente arquivos Word, Excel, PowerPoint e PDF, além de oferecer suporte a skills e memória (learn.microsoft.com).
Definições versionadas e uma linha para ativar o harness
As definições do agente ficam ao lado do código. No exemplo do Foundry, o harness é declarado em azure.yaml (devblogs.microsoft.com):
harness:
type: microsoft_copilot_previewO exemplo conecta um prompt agent research-brief à skill research-brief-skill, com busca na web (public-research) e Code Interpreter (research-analysis), usando FOUNDRY_PROJECT_ENDPOINT e MODEL_DEPLOYMENT_NAME como entradas de ambiente (devblogs.microsoft.com). O deploy e a invocação seguem a CLI de prévia:
azd deploy --all
azd ai agent invoke research-brief \
"Compare publicly announced approaches to agent interoperability. Produce a concise brief with sources, tradeoffs, and open questions."Outras opções de criação incluem o portal do Foundry, o Foundry Toolkit para Visual Studio Code e o plugin do Foundry para o app do GitHub Copilot (devblogs.microsoft.com).
Qual caminho de agente do Foundry escolher
Não há um único nível de abstração correto. A orientação da própria Microsoft é adotar o menor nível de responsabilidade sobre infraestrutura que atenda à aplicação (devblogs.microsoft.com). Durante a prévia, a escolha fica definida na criação do agente; por isso, decida antes de clicar em criar.
| Abordagem | Quando usar | O que você ganha | Do que abre mão |
|---|---|---|---|
| Prompt agent sem harness | Quando instruções e ferramentas compatíveis bastam | Opção mais simples, com menor responsabilidade | Sem skills, arquivos gerenciados, subagentes ou orquestração avançada |
| Prompt agent com Microsoft Copilot harness (prévia) | Quando são necessárias skills, execução gerenciada, arquivos, subagentes e coordenação complexa de ferramentas | Loop e sandbox gerenciados, skills reutilizáveis e execução mais rica | Aplicam-se os limites de prévia; a Microsoft controla mais do runtime; há restrições de modelos, ferramentas e regiões compatíveis |
| Hosted agent | Quando é preciso trazer ou modificar framework, loop, middleware ou dependências | Máximo controle com hospedagem gerenciada pelo Foundry | Você assume checkpoints, lógica de retomada e prevenção de ações duplicadas |
Entre os primeiros sinais de clientes citados pela Microsoft estão a Confluence Technologies, que entregou uma solução em menos de uma semana ao se concentrar no design em vez da infraestrutura, e a Fashable, que usa o harness em fluxos de sourcing governados enquanto mantém decisões comercialmente vinculantes sob controle humano (devblogs.microsoft.com).
Quanto custa a partir de 1º de dezembro de 2026
A cobrança do runtime do Microsoft Copilot harness começa em 1º de dezembro de 2026, no modelo de consumo. O uso do runtime antes dessa data é gratuito, mas a inferência de modelos, as ferramentas cobradas separadamente e os serviços conectados continuam sendo faturados à parte durante todo o período.
| Recurso de sandbox | Preço a partir de 1º de dezembro de 2026 |
|---|---|
| Computação de sandbox | $0.0994 por vCPU-hora |
| Memória de sandbox | $0.0118 por GiB-hora |
Os preços podem variar conforme a região e o contrato do cliente (devblogs.microsoft.com). Durante a prévia, o Foundry gerencia as configurações de CPU, memória e inatividade do ambiente de execução (devblogs.microsoft.com) e direciona para documentação separada sobre regiões, modelos, ferramentas e limites de prévia compatíveis.
No Copilot Studio, agentes que usam o harness de origem GitHub são cobrados por Copilot Credits em um modelo baseado em uso, uma superfície de cobrança separada da medição de sandbox do Foundry (learn.microsoft.com). Para estimar um piloto, multiplique as vCPU-horas e GiB-horas de sandbox observadas pelas tarifas acima e, depois, some os custos de tokens de modelo e ferramentas.
Limites de prévia para validar antes de desenvolver
São os detalhes que definem se um piloto de prévia resiste ao contato com produção. As restrições a seguir vêm da publicação da Microsoft sobre o Foundry, exceto onde indicado como relato de usuários.
- A escolha do harness ainda não tem volta. Escolha o harness ao criar o agente; os agentes existentes permanecem inalterados, e não há suporte atual para trocar de harness após a criação. Um leitor inicial destacou exatamente esse ponto: "você escolhe o Copilot harness ao criar o agente. Os agentes existentes permanecem inalterados, e ainda não há suporte para trocar o harness após a criação" — @navaneethan_es.
- Regiões e modelos têm limites. O Foundry remete a lista completa para a documentação sobre regiões, modelos, ferramentas e limites de prévia compatíveis. Um resumo de usuário menciona cerca de nove regiões, sem cobertura no Oriente Médio e sem bring-your-own-model completo por enquanto — @HeshamSaadZaki. Trate isso como uma leitura de usuário a ser confirmada na documentação, não como uma tabela oficial de regiões.
- A recuperação de tarefas longas é responsabilidade do seu código. O Foundry reinicia trabalhos hospedados interrompidos e reenvia a entrada original, mas a aplicação precisa salvar o progresso, retomar a partir de checkpoints e impedir ações duplicadas, como criar duas vezes o mesmo relatório externo. Apenas o histórico da conversa não restaura um trabalho em andamento.
- O lançamento não traz benchmarks nem números de SLA. Espere alegações qualitativas, como "desempenho líder do setor", sem tabelas de latência, throughput ou precisão.
O que usuários iniciais encontraram em produção
Usuários do Copilot Studio que trabalham com o harness de origem GitHub relatam preocupações recorrentes sobre a distância entre prévia e produção. Os relatos descrevem a experiência do GitHub harness no Copilot Studio antes da prévia do Foundry e são incluídos aqui como uma inferência sobre a linhagem compartilhada descrita pela Microsoft (blogs.microsoft.com), não como medições do Foundry.
Esses malditos conectores não conseguem permanecer conectados por sequer um dia em produção. — u/roberts2727 em r/copilotstudio
Às vezes os flows funcionam; em outras, o agente não passa absolutamente nada para eles. — u/donstazz em r/copilotstudio
Usuários de negócio não conseguem fazer esses app regs etc.; são os administradores de TI que precisam fazer isso. Para cada agente separadamente. — u/Teemu_St em r/copilotstudio
Problemas relatados nessas discussões:
- Respostas mais lentas em agentes apoiados por SharePoint, descritas como significativamente mais lentas do que as alternativas em r/copilotstudio.
- Agentes que funcionam no painel de teste do Studio, mas falham depois do deployment no Teams ou M365 Copilot com erros genéricos em r/copilotstudio.
- Instabilidade em conectores e flows, além de atrito recorrente com autenticação e consentimento MCP, em r/copilotstudio.
- Dúvidas de cobrança sobre uma licença M365 Copilot cobrir o runtime do harness ou se Copilot Credits ainda se aplicam, em r/microsoft_365_copilot.
Nada disso invalida a prévia do Foundry, mas define a checklist do piloto: teste com sua fonte de conhecimento real, seu canal real e seu fluxo real de consentimento do usuário final antes de prometer prazos.
Perguntas frequentes
O Microsoft Copilot harness é o mesmo que o GitHub Copilot harness?
Sim. É a mesma linhagem criada pela GitHub, agora sob o nome Microsoft; durante a transição, parte da documentação do Copilot Studio ainda usa o nome anterior.
Quais modelos o harness do Foundry suporta?
Mais de 20 modelos frontier, além de BYOK com roteamento baseado na tarefa. A Microsoft não publica a lista completa, portanto consulte a documentação do Foundry para sua região, conforme indicado na seção sobre multimodelo.
Posso migrar um agente existente do Foundry para o harness?
Não há troca in-place durante a prévia. Faça uma avaliação em paralelo: levante prompts, ferramentas, autenticação e necessidades de estado; recrie o agente com microsoft_copilot_preview em um projeto de prévia; depois compare qualidade, latência, uso de sandbox e recuperação antes da migração.
Uma licença M365 Copilot cobre o uso do harness?
Não automaticamente. O Foundry mede computação e memória de sandbox separadamente da inferência de modelos, enquanto o Copilot Studio cobra essa família de harness via Copilot Credits. Confirme qual medidor se aplica à sua superfície.
Devo usar o harness ou um hosted agent?
Use o harness para ter loop gerenciado, sandbox, skills e subagentes sem assumir a orquestração. Use um hosted agent quando precisar controlar o framework ou runtime e puder assumir checkpointing e idempotência.
Comece na prévia com o padrão de skill research-brief, compare o custo de sandbox e tokens com um prompt agent sem harness na mesma tarefa e mantenha a produção no caminho já comprovado até que migração, regiões e comportamento de consentimento estejam documentados para seu tenant.