Pacotes NuGet podem levar skills de agente junto com a biblioteca
No blog do .NET, Richard Lander mostra que um pacote NuGet pode trazer arquivos SKILL.md, o formato aberto de agent skills, com instruções para o agente usar aquela biblioteca do jeito certo. O exemplo é o pacote markout, que traz cinco skills.
Como o dotnet restore já coloca esses arquivos no disco, a documentação chega na mesma versão do pacote que o projeto usa. O post mostra como listar as skills com dotnet-inspect package markout -S Skills e como copiá-las para .agents/skills com dotnet-package-skills install.
O próprio texto lembra o cuidado de segurança: uma skill é instrução para o agente, então vale a regra de só usar pacotes de mantenedores em quem você confia. O autor promete um segundo post sobre como os agentes consomem essas skills.
Para quem usa .NET: quem mantém biblioteca ganha um jeito de entregar documentação para agentes na mesma versão do pacote; quem consome deve revisar as skills como revisa qualquer dependência.
Fonte: .NET Blog (Microsoft)
VS Code 1.145 aproxima as sessões de agente remotas da experiência local
A versão 1.145 do VS Code saiu em 4 de novembro com foco em agentes. Em preview, dá para navegar pela conexão do agent host remoto (workbench.browser.enableRemoteProxy) e misturar harnesses diferentes numa mesma sessão de chat (chat.agentHost.multipleChatProviders.enabled). As automações locais passam a aceitar agendamento com expressões cron de cinco campos.
Para empresas, a lista allowedMcpServers da política gerenciada passa a ter prioridade sobre o acesso só pelo registro de MCP. Também saem as ferramentas #installExtension, #runCommand e #newWorkspace, junto com o comando /new.
Para quem usa .NET: se o seu time usa VS Code com servidores MCP, vale conferir a política de MCP permitidos e se algum fluxo dependia dos comandos removidos.
Fonte: Visual Studio Code
Texto do Claude Mythos 5, Opus 4.7 e Sonnet 4.6 passa a carregar marca d'água
As notas de versão da plataforma do Claude registram em 3 de novembro que o texto gerado pelo Claude Mythos 5, Opus 4.7 e Sonnet 4.6 agora leva a marca d'água de texto da Anthropic. No Sonnet 4.6, respostas com temperature, top_p ou top_k fora do padrão podem sair sem a marca.
O artigo de suporte explica que a marca é imperceptível, faz parte do compromisso da Anthropic com o código de prática do artigo 50 do AI Act europeu e vale para API, Claude, Claude Code e parceiros de nuvem. A detecção está em preview privado para grupos como reguladores, imprensa, pesquisadores e empresas checando as próprias saídas. A Anthropic avisa que achar a marca não é prova definitiva, e não achar não prova que o texto é humano.
Para quem usa .NET: nada muda no código, mas se você pós-processa a saída do modelo é bom saber que a marca existe e que mexer no sampling do Sonnet 4.6 pode tirá-la.
Fonte: Claude Platform, release notes
Parallel.ForEachAsync pode virar um loop serial em container de uma CPU
Um artigo no blog do Stack Overflow, de Guilherme Appel, mostra um laboratório em que reduzir o container de duas para uma CPU quase dobrou o tempo de processar 200 registros: a mediana foi de 42,1 para 83,6 segundos. A causa é o Parallel.ForEachAsync sem MaxDegreeOfParallelism definido, que usa Environment.ProcessorCount como limite. Com limite de uma CPU, o loop processa um item por vez, mesmo que o trabalho seja quase todo espera de I/O.
A proposta do autor é definir orçamentos de concorrência por dependência (por exemplo, com SemaphoreSlim), em vez de um número único para tudo. No teste dele, essa abordagem eliminou as rejeições HTTP 503 do sistema simulado quando ele ficou degradado. Os serviços do laboratório são simulados, o que o próprio texto deixa claro.
Para quem usa .NET: procure loops com Parallel.ForEachAsync sem MaxDegreeOfParallelism explícito, principalmente em workers que rodam em Kubernetes com limite de CPU baixo.
Fonte: Stack Overflow Blog
Anthropic abre o FlashProve, protótipo para provar qual modelo gerou uma resposta
O Frontier Red Team da Anthropic publicou em 2 de novembro o FlashProve, um protótipo de pesquisa de código aberto (Apache 2.0) para inferência verificável: uma prova criptográfica (zkSNARK) de que uma saída veio de um modelo específico, sem revelar os pesos.
Os números mostram que ainda é pesquisa. Com o Llama 4 Maverick numa H100, a prova sai a cerca de 110 tokens por segundo, ocupa perto de 19 MB por requisição de 1.024 tokens e custa de 70 a 95 vezes o tempo de GPU de rodar o modelo no vLLM. A prova cobre decodificação gulosa e contexto de até 1.024 tokens, e a verificação roda em CPU.
Para quem usa .NET: nada para adotar agora; é tema para acompanhar se você depende de provedor terceiro e precisa provar a um cliente qual modelo respondeu.
Fonte: Anthropic Research
Minha leitura
Para mim, a notícia do período é a das skills no NuGet. Ela ataca um problema comum com agentes: eles escrevem código para a versão da biblioteca que lembram, não para a que está no projeto. Se a instrução vem dentro do pacote, na versão certa, o agente passa a ter a mesma fonte que o desenvolvedor. O outro lado é que pacote agora também carrega instrução para agente, e isso entra na conta de supply chain junto com o código.
A marca d'água e o FlashProve respondem à mesma pergunta, de onde veio esse texto, mas estão em estágios bem diferentes: a primeira já está ligada nos modelos, o segundo é protótipo com custo alto. O texto do Stack Overflow é o mais prático do resumo: um default que parece inofensivo e só aparece quando o container encolhe. E a .NET Conf começa no dia 10, com o lançamento do .NET 11, então o próximo resumo deve ser bem mais .NET.
Leia também
Precisa de ajuda com backend .NET e IA aplicada? Conheça o serviço.