Respostas de referência às questões para reflexão

Este arquivo reúne tópicos de respostas de referência para as questões de reflexão dos dez capítulos do livro. A maioria das questões é aberta e não tem uma única resposta correta. As respostas de referência foram geradas por IA e passaram por uma breve revisão humana. Elas são fornecidas apenas para comparação e inspiração dos leitores. Recomenda-se usar um LLM em conjunto com o conteúdo do livro para aprofundar a discussão dessas questões.

Capítulo 1: Introdução aos agentes de IA

1. (★★) Se você pudesse acrescentar apenas uma capacidade a um sistema de agentes — um modelo mais poderoso, um contexto mais rico ou mais ferramentas —, qual escolheria? Em que condições sua escolha mudaria?

Seguindo a fórmula “cérebro/olhos/mãos e pés”, primeiro identifique o elo mais fraco. Em geral, a prioridade é enriquecer o contexto, ou seja, ampliar o espaço de observação. Se a tarefa exceder a capacidade de raciocínio do modelo, adote um modelo mais poderoso. Se o espaço de ação for insuficiente — por exemplo, se não houver acesso aos sistemas internos da empresa —, acrescente ferramentas. Para decidir, analise as trajetórias de falha e identifique se o gargalo está na percepção, na tomada de decisão ou na ação.

2. (★★★) Em um ciclo ReAct, o volume acumulado de leituras do cache cresce de forma aproximadamente quadrática em relação ao número de rodadas. Como reduzir esse crescimento?

Na rodada i, o tamanho do prefixo armazenado em cache é aproximadamente proporcional a i; portanto, o total acumulado de leituras é 1 + 2 + ... + n = O(n²). O crescimento quadrático ocorre no custo acumulado das leituras do cache, e não no tamanho da trajetória nem no espaço ocupado pelo cache KV, que crescem de forma aproximadamente linear. Ao atingir determinados limites de tokens, comprima em lote o início da trajetória, preservando apenas as conclusões e os estados essenciais. Resultados intermediários extensos podem ser armazenados externamente para recuperação sob demanda ou isolados em subagentes. Não comprima a cada rodada: isso pode prejudicar o desempenho do agente e ainda gerar chamadas adicionais de compressão e custos de reconstrução do cache.

3. (★★) O paradigma “modelo como agente” significa que os modelos estão se tornando mais autônomos nas decisões de chamada de ferramentas. No entanto, este capítulo sustenta que a importância da engenharia de harness está aumentando. Como essas duas tendências podem coexistir? Em que estará o principal valor dos frameworks de agentes no futuro?

A metáfora do cavalo e das rédeas: quanto mais poderoso for o modelo e maior sua autonomia, maior será o impacto potencial dos erros e, portanto, maior a necessidade de restrição, verificação e correção. O valor dos frameworks deixa de estar em “orquestrar chamadas ao LLM” e passa para a camada de garantias entre os cinco elementos do harness: classificação de permissões, disjuntores, recuperação de erros, compressão de contexto e ecossistema de ferramentas.

4. (★★) No experimento de ablação, a ausência de “feedback dos resultados das ferramentas” fez o agente entrar em um ciclo infinito. Em um ambiente de produção, além da ausência desses resultados, que outras situações podem fazer um agente entrar em loop? Quais mecanismos de detecção e encerramento você projetaria?

Outras causas possíveis: uma ferramenta retorna repetidamente o mesmo erro; o modelo, por alucinação, chama ferramentas inexistentes; a compressão de contexto elimina um estado essencial; o conteúdo de raciocínio é removido e a API do modelo retorna erro; ou a própria tarefa não tem solução. Mecanismos: definir condições de parada, como um número máximo de iterações; detectar chamadas repetidas — mesma ferramenta e mesma impressão digital dos argumentos —; e encaminhar o caso para intervenção humana quando o limite de falhas for excedido.

5. (★) Este capítulo analisou cinco produtos de agentes segundo três dimensões: contexto de trabalho, interfaces de ação e estratégia. Escolha um produto de IA que você use diariamente, analise-o pelas mesmas três dimensões e avalie se sua arquitetura é adequada. Se você fosse projetá-lo, o que melhoraria?

Questão aberta. Pontos principais: seguindo a tabela do capítulo, descreva os olhos — quais fontes de informação ele consegue ver —, as mãos e os pés — se o espaço de ação é aberto e se ele consegue pensar internamente — e a estratégia — o padrão do ciclo de execução do agente.

6. (★★) Se você fosse projetar um sistema de atendimento ao cliente específico para reservas de passagens aéreas, escolheria um padrão de fluxo de trabalho ou de agente autônomo? É possível combinar os dois padrões no mesmo sistema?

Use um fluxo de trabalho como estrutura principal, com quatro etapas: verificação de identidade → pesquisa → pagamento → reserva. Isso garante uma sequência em conformidade com as regras, como “não reservar antes do pagamento”, e limita a superfície de ataque por injeção de prompt a uma única etapa. Adote um agente autônomo nos segmentos abertos, como compreender as necessidades, remarcar voos e recomendar alternativas em caso de cancelamento. Acrescente confirmação humana para operações de alto risco, como pagamentos de valores elevados e reembolsos.

7. (★★★) A seção sobre guardrails mencionou classificações de risco das ferramentas. Se uma ferramenta normalmente apresenta baixo risco, mas se torna de alto risco com determinadas combinações de parâmetros — por exemplo, delete_file excluir um arquivo comum ou um arquivo do sistema —, como você projetaria uma avaliação dinâmica de risco?

Refine o objeto da classificação de “ferramenta” para “ferramenta + argumentos”: no momento da chamada, calcule o risco com base na reversibilidade, nas permissões e na abrangência do impacto. Use verificações determinísticas baseadas em regras — listas de caminhos permitidos e bloqueados, expressões regulares —, e não a avaliação do modelo. A validação deve examinar apenas dados estruturados, para impedir que uma injeção de prompt manipule o resultado.

8. (★★) Na tabela de produtos de agentes deste capítulo, todos os agentes têm um espaço de ação “aberto”. Em quais cenários um espaço de ação restrito — por exemplo, limitado à escolha entre opções predefinidas — seria superior a um espaço aberto?

Em cenários com requisitos rigorosos de conformidade, alto risco ou erros irreversíveis. Em reembolsos e pagamentos, as opções limitadas funcionam como restrições e evitam erros por natureza, tornando-os impossíveis desde a concepção.

9. (★★) O mecanismo de intervenção com humano no circuito exige que o agente consiga “transferir o controle de forma harmoniosa”. Na prática, porém, o usuário pode estar offline, demorar a responder ou fornecer instruções vagas. O que o agente deve fazer nesses casos?

Adotar uma postura fail-safe: pausar operações de alto risco enquanto não houver confirmação, em vez de executá-las por padrão; concluir primeiro as partes reversíveis e de baixo risco e documentar as de alto risco, para que uma pessoa possa decidir e o agente possa retomar a tarefa; notificar o usuário por ferramentas de comunicação assíncrona, como mensagens e e-mail, com uma política de tempo limite; e solicitar esclarecimentos sobre a intenção quando as instruções forem vagas.

10. (★★★) A introdução afirma que “bons princípios de projeto devem transcender os ciclos de evolução dos modelos”, mas os métodos concretos de engenharia usados para implementar esses princípios podem se tornar obsoletos à medida que as capacidades dos modelos avançam. Dê um exemplo desse tipo de método de engenharia de agentes e explique por quê.

Exemplo 1: usar amostragem restrita para forçar as chamadas de ferramentas a seguir um formato rígido. Trata-se de uma correção de confiabilidade para modelos que frequentemente geram JSON inválido ou omitem parâmetros. Seu benefício pode diminuir à medida que os modelos se tornam melhores em seguir formatos, embora cenários de alto risco ainda devam manter a validação determinística do formato.

Exemplo 2: introduzir uma base de conhecimento externa para compensar a incapacidade do modelo de assimilar continuamente novos conhecimentos. Se os modelos vierem a adquirir recursos confiáveis de aprendizado contínuo, parte da manutenção do conhecimento poderá migrar dos sistemas externos para os parâmetros do modelo. Ainda assim, bases de conhecimento externas continuarão tendo valor próprio para atualizações em tempo real, recuperação precisa, controle de acesso e rastreabilidade das fontes. Portanto, é mais provável que seu campo de aplicação diminua do que desapareça por completo.

Exemplo 3: exigir que todas as capacidades sejam disponibilizadas pela interface padrão de chamada de ferramentas da API do modelo e proibir formatos de chamada personalizados. As Skills demonstram outro caminho: descrever em texto uma capacidade e seu procedimento de operação e, em seguida, permitir que o modelo a execute por meio de uma ferramenta de linha de comando de propósito geral. Do ponto de vista do modelo, isso equivale a compreender e seguir um protocolo textual de chamada personalizado sobre um executor genérico. À medida que os modelos melhoram sua capacidade de compreender interfaces arbitrárias, “sempre usar o formato padrão de chamada de ferramentas” deixa de ser um princípio universal. Formatos padronizados continuam úteis para interoperabilidade, validação estruturada e modelos menos capazes, mas devem ser uma escolha de engenharia baseada no contexto.

Exemplo 4: exigir que os prompts e todas as definições de ferramentas apareçam no início do contexto. Essa prática surgiu porque os primeiros modelos tinham capacidade limitada de seguir instruções e frequentemente não reconheciam nem executavam prompts e definições de ferramentas fora de posições fixas e conhecidas. As Skills carregam prompts sob demanda no meio do contexto, enquanto a descoberta dinâmica de ferramentas acrescenta as definições recém-encontradas após a trajetória existente. À medida que a capacidade de seguir instruções melhora e os modelos recebem pós-treinamento específico para esses padrões de carregamento dinâmico, os prompts e as definições de ferramentas deixam de precisar de uma posição fixa no início do contexto.

Capítulo 2: Engenharia de contexto

1. (★★★) O experimento 2-3 constatou que uma janela deslizante do histórico da conversa faz o agente executar repetidamente as mesmas chamadas de ferramentas. No entanto, manter o histórico completo faz o contexto crescer indefinidamente. Elabore uma estratégia que evite a perda de informações e controle o tamanho do contexto sem quebrar o prefixo do cache KV.

① Substitua o descarte pela compactação: apenas acrescente mensagens, sem excluí-las nem editá-las; ao se aproximar de um limite (por exemplo, 80% da janela), compacte em lote os resultados antigos de ferramentas. ② Adote um mecanismo em camadas: armazene em disco as saídas extensas e mantenha um resumo, exclua diretamente o ruído e preserve resumos de arquivamento que mantenham o fio condutor. ③ Isole os subagentes para impedir que o estado intermediário entre no contexto principal.

2. (★★) O mecanismo de retenção da cadeia de raciocínio do Chat Template do Qwen3 preserva apenas o conteúdo de raciocínio “posterior à última mensagem real do usuário”. Se um ciclo ReAct abranger centenas de chamadas de ferramentas, o conteúdo de raciocínio acumulado poderá consumir grande parte do contexto. Como você modificaria esse mecanismo para lidar com ciclos muito longos? O DeepSeek R1 exigia a remoção de todo o conteúdo de raciocínio do histórico, enquanto o DeepSeek V4 inverteu essa abordagem e passou a exigir o reenvio de todo o reasoning_content. Ao comparar essas duas estratégias opostas, quais são as vantagens e desvantagens de cada uma? O que essa inversão indica?

Direção da modificação: retenção por janela deslizante — preserve integralmente as rodadas mais recentes de raciocínio; fora da janela, acione uma compactação contínua com base em um orçamento de tokens, e não em um número fixo de rodadas, produzindo uma barra de status estruturada (objetivo atual, fatos confirmados, caminhos descartados e tarefas pendentes). A compactação ocorre apenas uma vez e em uma posição fixa, de modo que o custo de reconstrução do cache seja pago uma única vez, em vez de a cada rodada. Remoção no R1: economiza tokens, mantém o prefixo estável e favorável ao cache e corresponde à distribuição de treinamento (a cadeia de raciocínio histórica nunca aparece na entrada); porém, a cada rodada, o raciocínio recomeça do zero, os planos de longo prazo são perdidos e os erros tendem a se repetir. Reenvio obrigatório no V4: mantém a continuidade do raciocínio e melhora o desempenho em tarefas agênticas de longo horizonte; em contrapartida, tem alto custo de tokens, aumenta o prefixo a cada rodada e impede a transição fluida a partir do modo sem raciocínio. Essa inversão mostra que, no diálogo puro, o raciocínio é resíduo; em cenários agênticos, ele é estado — e a prática do setor passou a favorecer esta última visão.

3. (★★) No experimento de compactação sensível ao contexto, o conteúdo foi reduzido de aproximadamente 148 mil caracteres para cerca de 2.000. Uma compactação tão extrema traz o risco de “perda irreversível de informações”? Como resolver esse problema?

Sim. A compactação é uma projeção com perdas; se a pergunta envolver uma dimensão que não foi preservada, não será possível obter uma resposta confiável. A solução é combinar “compactação com perdas e indexação sem perdas”: cada fato inclui a URL da fonte para permitir o rastreamento; as saídas originais são armazenadas em disco, mantendo-se no contexto apenas prévias resumidas; definem-se prioridades explícitas de retenção — decisões de arquitetura, informações necessárias à integridade semântica (como horários e nomes de empresas), status de verificação e identificadores como UUIDs e hashes são preservados literalmente; o janelamento adaptativo adia o momento da compactação.

4. (★★) A barra de status do agente torna explícitos os estados implícitos. No entanto, se a própria barra contiver informações incorretas — por exemplo, devido a um bug no contador de ferramentas —, o agente poderá tomar decisões prejudiciais com base nelas. Como mitigar esse problema de “confiabilidade das metainformações”?

O modelo confia quase incondicionalmente na barra de status, portanto os erros são propagados sem alteração. Medidas de mitigação: ① mantenha-a com código determinístico — nunca encarregue um LLM de contabilizar em lote históricos extensos; se for indispensável usar um LLM, limite-o à extração item a item e faça a agregação por código; ② monitore continuamente a precisão da barra de status como uma métrica prioritária de produção; ③ use apenas informações provenientes de observações confiáveis do mundo real, protegendo a barra de status contra envenenamento.

5. (★★) O experimento de ablação em engenharia de prompts mostra que a desorganização das informações reduz a taxa de sucesso em mais de 30%. Contudo, no desenvolvimento real, os prompts de sistema costumam ser mantidos por várias pessoas em momentos distintos. Que práticas de engenharia você adotaria para evitar que eles se tornem cada vez mais desorganizados?

① Trate prompts como código: use controle de versão e revisão, com gerentes de produto definindo as regras de negócio e engenheiros responsáveis por codificá-las; ② use benchmarks semelhantes ao Tau-Bench como testes de regressão e execute ablações antes e depois das alterações para identificar seu impacto; ③ imponha uma estrutura: adote um fluxo orientado por SOP, em vez de acumular regras, com organização em camadas usando XML/Markdown; ④ classifique e nomeie os fragmentos como “compatíveis com cache” ou “incompatíveis com cache”, posicionando o conteúdo dinâmico depois do limite do cache; ⑤ divida o conteúdo excessivo em Skills carregadas sob demanda.

6. (★★★) Este capítulo propõe que “o aprendizado em contexto é, essencialmente, recuperação, e não raciocínio”. Se essa afirmação estiver correta, será necessário reavaliar todas as atuais linhas de otimização baseadas em “inserir mais informações no contexto”. Como você acredita que essa limitação pode ser superada?

Acrescente uma camada de destilação a esse “mecanismo de recuperação pela metade”: ① use destilação de contexto ou uma barra de status e faça o código calcular antecipadamente as conclusões para recuperação direta pelo modelo; ② aplique compactação ativa, substituindo registros brutos por conhecimento estruturado de alta densidade; ③ isole os subagentes para manter o ruído fora do contexto principal; ④ use a interação como terceiro eixo, fazendo instrumentos externos observarem e registrarem no contexto novas informações que o modelo não conseguiria deduzir por conta própria; ⑤ explore abordagens de fronteira, como “notas” editáveis e combináveis no cache KV e a consolidação de memória entre sessões.

7. (★★★) A revelação progressiva das Skills só carrega o conteúdo completo quando o agente considera isso necessário. Contudo, esse julgamento depende da capacidade do próprio modelo: se ele não sabe o que não sabe, não consegue acionar corretamente o carregamento de uma Skill. Como resolver esse problema de “metacognição”?

① Mantenha os metadados da Skill (nome e descrição) permanentemente no contexto, para que o modelo sempre “saiba o que tem à disposição”; ② redija a descrição da Skill como condições de roteamento, e não como uma apresentação de funcionalidades — “Use when / Don't use when” —, evitando descrições vagas.

8. (★★) No mecanismo de Skills, depois que o agente carrega dinamicamente as instruções de SKILL.md, as operações posteriores conseguem segui-las de forma confiável? Quais são as diferenças entre os modelos quanto ao suporte ao padrão de Skills?

Depende de como a Skill é inserida: incluí-la no prompt de sistema proporciona a maior aderência às instruções, mas quebra o cache KV; lê-la como um arquivo comum no meio do contexto pode reduzir a aderência às instruções; inseri-la no final do contexto proporciona boa aderência, mas exige recalcular, a cada chamada de ferramenta, o KV correspondente à Skill, o que tem um custo elevado.

9. (★★★) Este capítulo destaca que alterações em informações dinâmicas — como timestamps do sistema e a ordem da lista de ferramentas — podem impedir o reaproveitamento do prefixo no cache KV. Em um sistema de produção com muitas ferramentas e um conjunto que muda com frequência, como você organizaria o contexto para maximizar a taxa de acerto do cache?

① Use um pequeno conjunto de ferramentas centrais estáveis — por exemplo, sete — mais um executor genérico, disponibilizando recursos específicos por meio da revelação progressiva de Skills; mantenha as definições das ferramentas congeladas no prefixo estático, em ordem fixa; ② faça com que os subagentes mantenham o mesmo prefixo do agente principal.

Capítulo 3: Memória do usuário e base de conhecimento

1. (★★) Em um sistema de memória do usuário, quando o mesmo usuário fornece informações contraditórias em sessões diferentes (por exemplo, menciona dois endereços residenciais distintos), como o sistema deve lidar com esse conflito?

Use um pipeline no estilo do Mem0 de “extrair–comparar–decidir”: primeiro, recupere memórias antigas semelhantes por busca vetorial; depois, faça um LLM decidir entre ADD/UPDATE/DELETE/NOOP. Por exemplo, “mudou-se para Xangai” deve acionar UPDATE e substituir “mora em Pequim”. Quanto ao versionamento, mantenha apenas a versão mais recente de informações como endereços, com um carimbo de data e hora, mas preserve todo o histórico de informações como experiências profissionais. Na recuperação, prefixos contextuais — pessoa, tempo e intenção, como no caso dos dados de transferência bancária alterados três vezes — podem ajudar a determinar qual registro é válido em última instância.

2. (★★) A recuperação contextual acrescenta a cada fragmento o contexto do documento original. No entanto, se o próprio documento tiver uma estrutura confusa ou contiver informações contraditórias, esse método poderá propagar ou até amplificar erros. Como você introduziria um sinal de “qualidade da informação” na etapa de recuperação?

É possível aproveitar os princípios de “atualidade e governança da base de conhecimento”: associe aos fragmentos metadados como número da versão, datas de início e término da validade e fontes; durante a recuperação, filtre conteúdo expirado ou indique explicitamente no prefixo que “este registro foi revogado em determinada data”; na etapa de reordenação, inclua a autoridade da fonte e a atualidade na pontuação, em vez de considerar apenas a relevância semântica; durante a indexação, faça o LLM que gera os prefixos também detectar e sinalizar contradições entre fragmentos, de modo semelhante à detecção versionada de conflitos em sistemas de memória.

3. (★★) A extração de informações multimodais converte gráficos em descrições textuais antes da recuperação. Esse processo de “tradução” pode eliminar relações espaciais presentes nas informações visuais. Dê um exemplo específico de informação gráfica que uma descrição puramente textual não consiga transmitir por completo e proponha uma solução para preservá-la.

Exemplos: as relações lógicas em um diagrama de arquitetura de sistema, a posição do ponto de interseção entre duas curvas em um gráfico de linhas ou a correspondência entre linhas e colunas de células e cabeçalhos em uma tabela de PDF. Primeira opção: processamento multimodal nativo. Segunda opção: disponibilizar uma ferramenta multimodal de análise de imagens.

4. (★★★) A “Lição Amarga”, de Rich Sutton, afirma que métodos gerais — busca e aprendizado — acabarão superando recursos projetados manualmente. Todo o sistema de conhecimento construído neste capítulo — estratégias de fragmentação, estruturas de índice e pipelines de recuperação — não seria também uma forma de “projeto manual”? Se os modelos se tornarem suficientemente capazes, esses componentes poderiam ser substituídos simplesmente por “inserir tudo”?

De fato, trata-se de um projeto manual, e algumas etapas — como fragmentação e ajuste da fusão — podem perder importância à medida que o contexto se torna mais longo. No entanto, o caso do gato preto e do gato branco mostra que “inserir tudo” também não basta: a atenção é uma forma de recuperação flexível, enquanto a agregação e as estatísticas entre documentos ainda exigem pré-destilação durante a indexação. Restrições de engenharia como expiração e atualização do conhecimento, isolamento de permissões e locatários, auditabilidade e custo independem da capacidade do modelo. Além disso, a recuperação combinada à destilação por LLM durante a indexação é, por si só, um método geral de “busca + aprendizado”, e não se opõe à Lição Amarga.

5. (★★★) À medida que os modelos se tornam mais capazes, as bases de conhecimento de domínios específicos continuarão sendo importantes? Um futuro modelo-base poderoso poderia conter todas as informações de uma base de conhecimento de domínio, eliminando a necessidade dela?

Continuarão sendo importantes: os dados de treinamento têm uma data de corte, enquanto uma base de conhecimento pode ser atualizada a qualquer momento; processos internos de empresas, jurisprudência privada e informações semelhantes simplesmente não fazem parte do corpus público; o compartilhamento entre vários usuários exige filtragem por permissões e isolamento de locatários, e o conhecimento contido nos parâmetros não pode ser adaptado a cada solicitante; o armazenamento externo é auditável, admite controle de versões e permite retirar conteúdo expirado, algo difícil de fazer com memória paramétrica. Mesmo na abordagem paramétrica — pós-treinamento ou User as Engram —, persiste o problema de que “lembrar é fácil, mas usar os fatos em raciocínio de múltiplos saltos é difícil”.

6. (★) O RAPTOR cria um índice em árvore por meio de sumarização hierárquica de baixo para cima, enquanto o GraphRAG cria um índice estruturado em grafo com base nas relações entre entidades. Para quais tipos de consulta cada um desses índices estruturados é mais adequado?

RAPTOR: consultas de “navegação entre camadas”, que partem de conceitos gerais e avançam até os detalhes — por exemplo, localizar primeiro o resumo sobre o “conjunto de instruções SIMD” e depois aprofundar-se nos detalhes de SSE —, abrangendo tanto a visão geral quanto os detalhes. GraphRAG: raciocínio relacional de múltiplos saltos — como percorrer a cadeia de relações para descobrir “o endereço do hospital onde meu médico trabalha” — e desambiguação de entidades — dois profissionais chamados “Dr. Zhang” correspondem a nós diferentes —, ou seja, consultas como “qual é a relação entre A e B?”. Os resumos de comunidades também oferecem agrupamento temático.

7. (★★) O paradigma de sistema de arquivos organiza o conhecimento em uma estrutura hierárquica semelhante à de um sistema de arquivos. Em comparação com a RAG tradicional baseada em banco de dados vetorial, em quais cenários essa abordagem apresenta vantagens?

O texto simples pode ser lido, editado e corrigido diretamente pelos usuários, além de admitir controle de versões e reversão com Git. Por isso, é adequado a cenários em que humanos e máquinas mantêm e revisam o conhecimento em conjunto. Com a capacidade write_file, o agente pode registrar experiências de forma autônoma, criando um ciclo de memória que evolui por conta própria — um aprendizado externalizado. A revelação progressiva em L0/L1/L2 permite que a maioria das consultas seja resolvida já em L1, economizando tokens. O pré-requisito é criar links cruzados e páginas de índice, como na Wikipedia; caso contrário, quanto maior o número de arquivos isolados, mais difícil se torna a recuperação.

8. (★★★) Descobrir automaticamente “fatores de decisão” e “hierarquias de importância dos fatores” em dados estruturados — como bancos de dados de decisões judiciais — equivale, em essência, a fazer o agente inferir regras a partir dos dados. Essa extração de conhecimento orientada por dados pode alcançar a qualidade das regras elaboradas manualmente por especialistas humanos?

Vantagens: como demonstrado no experimento CAIL2018, a descoberta de fatores “de baixo para cima” reflete melhor os dados do que as concepções prévias humanas, pode capturar experiências implícitas de ponderação dispersas por dezenas de milhares de decisões — difíceis de explicitar por especialistas — e permite quantificação. Limitações: erros de extração do LLM causam contaminação do conhecimento; vieses presentes nos próprios dados são herdados; e protótipos de agrupamento refletem apenas correlação, sem explicar causalidade. Uma solução intermediária é combinar modelagem orientada por dados com a revisão do esquema e dos resultados por especialistas: os modelos formulam as perguntas, e os resultados estatísticos fundamentam as explicações.

9. (★★★) Projete fluxos de trabalho de atualização incremental e reorganização periódica para uma biblioteca de memória do usuário em Markdown. Se o Revisor e o Proponente usarem o mesmo modelo e puderem ver apenas os trechos de conversa selecionados pelo Proponente, quais erros ainda poderão ser incorporados? Explique as melhorias em termos de independência dos modelos, cobertura das evidências e permissões das ferramentas.

Atualização incremental: trate a biblioteca de memória como um repositório de código e submeta cada alteração a um PR. Primeiro, o Proponente recupera o conhecimento existente relacionado e, em seguida, propõe o menor diff que seja completo, mantendo também links, índices, metadados temporais e referências às evidências. O Revisor realiza uma auditoria independente com base no conhecimento anterior à alteração, no diff e nas evidências originais. Se rejeitar a mudança, deve apresentar comentários acionáveis que apontem para evidências e números de linha específicos. As iterações devem ter um limite máximo ou um orçamento de custo; se ele for excedido, o caso deve ser encaminhado a um humano, em vez de ser aprovado por padrão. Após a incorporação, a CI verifica primeiro a formatação, os links, os metadados e os rótulos de permissão; só então os fragmentos e índices vetoriais afetados são reconstruídos de forma incremental a partir da versão incorporada. Reorganização periódica: acione uma varredura completa em intervalos definidos ou quando o número de novas entradas atingir determinado limite; elimine duplicações, faça mesclagens, divida arquivos grandes demais e reconstrua as páginas de entrada. O essencial é retornar às conversas originais, parágrafo por parágrafo, para verificar se resumos antigos omitiram alguma negação, condição temporal ou ressalva. Contradições não devem ser resolvidas simplesmente “mantendo a versão mais recente”, mas rastreando cada afirmação até sua fonte e registrando as condições em que cada uma se aplica. Quando as evidências forem insuficientes, preserve o conflito e marque-o como pendente de confirmação. A reorganização também deve ser submetida por meio de PRs, que podem ser divididos por diretório. Depois que todos forem aprovados, além de reconstruir o índice, execute novamente um conjunto de casos típicos de recuperação para confirmar que conhecimentos antes localizáveis não se tornaram invisíveis.

O uso do mesmo modelo com trechos pré-selecionados deixará passar três classes de erro. Independência dos modelos: modelos da mesma família compartilham pressupostos de treinamento e pontos cegos; por isso, o Revisor tende a repetir a conclusão do Proponente sem retornar às evidências, e uma interpretação equivocada comum aos dois não é detectada. A solução é usar, na revisão cruzada, modelos de capacidade comparável, mas de famílias diferentes. Cobertura das evidências: quando o Revisor vê apenas os trechos escolhidos pelo Proponente, não consegue detectar citações fora de contexto, negações e precondições omitidas nem conflitos com outros arquivos. O Revisor deve poder consultar de forma autônoma toda a base de conhecimento e o repositório de evidências originais, dentro do escopo autorizado do locatário ou usuário, em vez de receber apenas algumas passagens selecionadas na etapa anterior. Permissões das ferramentas: se o Proponente puder gravar na ramificação principal ou editar o índice em produção, a revisão perde sua eficácia. É preciso impor a separação de funções: o Proponente grava apenas em uma ramificação de trabalho; o Revisor somente lê as evidências e envia seu parecer; apenas o pipeline de incorporação pode atualizar a ramificação principal e o índice em produção; e os validadores e critérios de liberação devem permanecer fora do escopo modificável.

Capítulo 4: Ferramentas

1. (★★) O padrão MCP desacopla as definições de ferramentas do framework do agente. No entanto, a padronização também significa que padrões complexos de interação com ferramentas — como saída em streaming, comunicação bidirecional e sessões com estado — podem ser difíceis de expressar em um protocolo padrão. Qual capacidade você considera mais necessário ampliar no MCP no futuro?

A principal ampliação necessária é a capacidade orientada a eventos entre sessões. O MCP já oferece suporte a interações em várias rodadas, assinaturas de alterações e tarefas de longa duração, mas seu foco continua sendo padronizar uma chamada de capacidade, e não manter um agente continuamente online. Despertar um agente quando chega um novo e-mail ou ocorre um callback externo, bem como enfileirar, retomar e repetir vários eventos, ainda é responsabilidade do framework do agente. Convenções mais uniformes para essa orquestração ampliariam o alcance do MCP sem sacrificar a simplicidade do protocolo.

2. (★★) No ecossistema MCP, diferentes servidores MCP podem oferecer ferramentas com funcionalidades muito semelhantes. Quando um agente se depara com várias ferramentas de fontes distintas, mas funcionalmente parecidas, como deve escolher? Se ferramentas homônimas de fontes diferentes tiverem comportamentos ligeiramente distintos — por exemplo, uma retornar um resumo e outra, o texto completo —, o agente consegue perceber e aproveitar essa diferença?

Critérios de seleção: antes da integração, revisar as descrições, fixar as versões e configurar credenciais com privilégios mínimos; estar atento ao sombreamento de ferramentas homônimas (tool shadowing), que pode direcionar chamadas sensíveis a agentes mal-intencionados; durante a execução, reduzir o conjunto de candidatas por meio de classificação hierárquica e descoberta dinâmica. A capacidade do modelo de perceber diferenças de comportamento depende da qualidade das descrições das ferramentas.

3. (★★) Este capítulo propõe um ciclo de “execução-validação-feedback”, como executar automaticamente um linter depois de escrever código. Em que outros cenários de uso de ferramentas esse padrão de “validação automática imediatamente após a operação” poderia ser aplicado? Existem operações cujo custo ou risco de validação supera o da própria operação, tornando esse padrão inviável?

Cenários generalizáveis: depois de alterar uma configuração, executá-la de fato em uma sandbox para verificar se a mudança entrou em vigor; depois de gerar um documento ou uma apresentação, renderizá-lo como capturas de tela e usar a capacidade multimodal do modelo para verificar o layout. O padrão é inviável em operações irreversíveis ou não idempotentes, como enviar e-mails, fazer ligações telefônicas ou transferir dinheiro — ou não há nada a observar, ou a própria validação aciona outro evento no mundo real. Nesses casos, devem-se adotar controles prévios, como a aprovação antecipada por um mecanismo de proponente-revisor.

4. (★★) Este capítulo aborda o problema da “explosão de ferramentas”: a precisão de seleção do agente diminui quando ele se depara com milhares de ferramentas. Além da descoberta proativa de ferramentas, que outras abordagens existem? Considere as estratégias adotadas por especialistas humanos diante de um vasto conjunto de ferramentas disponíveis.

① Agrupamento hierárquico: primeiro localizar o “servidor/app” e depois escolher a ferramenta específica; ② “consulta sob demanda” no estilo de Skills: como em uma obra de referência, o catálogo permanece no contexto e os detalhes são carregados conforme a necessidade; ③ manter “à mão”, residentes no contexto, algumas ferramentas básicas de uso frequente, deixando as demais acessíveis pelo índice do catálogo.

Capítulo 5: Agente de programação e agente de propósito geral

1. (★★) A geração de código é considerada uma “metacapacidade” do agente. Contudo, a execução de código traz riscos de segurança: o código gerado pelo agente pode conter vulnerabilidades, entrar em loops infinitos ou esgotar recursos. O isolamento em sandbox reduz parte desses riscos, mas também limita o que o código pode fazer, por exemplo, ao impedir o acesso à rede ou ao sistema de arquivos. Como encontrar o equilíbrio ideal entre segurança e capacidade?

Defina níveis de isolamento em sandbox conforme o cenário, usando contêineres ou microVMs; bloqueie a rede por padrão e libere o acesso sob demanda por meio de um proxy com lista de permissões; monte o código-fonte como somente leitura e mantenha as chaves de API fora da sandbox; imponha limites de recursos; gerencie o ciclo de vida da sandbox, incluindo timeouts.

2. (★★★) O bootstrapping de agentes — um agente capaz de criar outros agentes — possibilita a “autorreplicação da inteligência”. Contudo, cada iteração pode introduzir novos vieses ou erros. Esses erros se acumularão entre as gerações? Como evitar a degradação no bootstrapping de agentes?

Se cada geração continuar se reproduzindo com base nos artefatos da anterior, alguns defeitos poderão se acumular. O ponto essencial é dispor de tarefas verificáveis suficientemente desafiadoras — por exemplo, tarefas de programação com dificuldade suficiente.

3. (★★) Ao processar logs, um agente de geração de código pode acompanhar automaticamente a evolução do formato. Porém, se uma mudança de formato for um bug, e não uma alteração intencional, a adaptabilidade do agente poderá ocultar o problema. Como o agente deve distinguir entre “uma mudança que exige adaptação” e “uma anomalia que precisa ser relatada”?

Diagnostique antes de adaptar: compare o novo formato com os documentos de arquitetura e o PRD para avaliar se ele está de acordo com o esperado, seguindo a ideia do Experimento 5-11; verifique os registros do controle de versão para confirmar se a mudança corresponde a um commit legítimo, e não a um desvio sem origem clara; de forma análoga ao log_mismatch do τ-bench, mesmo que opte pela adaptação, registre um alerta e crie automaticamente uma issue, em vez de aceitar a mudança silenciosamente; em caso de dúvida, encaminhe a decisão para confirmação por um humano no circuito. O princípio é adaptar e relatar em paralelo: a adaptação não pode suprimir os sinais de anomalia.

4. (★★) Este capítulo usa repetidamente o mecanismo de proponente-revisor na geração de apresentações em PPT, na edição de vídeos e na visualização de logs. Se as preferências estéticas do revisor divergirem das do usuário-alvo — por exemplo, se o revisor considerar razoável a densidade de informações, mas o usuário achar o conteúdo muito carregado —, o ciclo de feedback poderá convergir para o ótimo local errado. Como incorporar o feedback sobre as preferências do usuário ao ciclo do revisor?

Injete o feedback do usuário na trajetória do agente como um evento estruturado de prioridade máxima; externalize e consolide as preferências do usuário registrando-as em MEMORY.md, para que sejam aplicadas entre diferentes tarefas; entregue os documentos em HTML, e não em Markdown, para que os usuários possam inspecioná-los.

5. (★★) Este capítulo apresenta várias formas de um agente de programação consolidar no repositório o conhecimento adquirido durante a execução e a depuração: criar arquivos de base de conhecimento, atualizar a documentação de arquitetura, manter arquivos de instruções do projeto e codificar sequências operacionais. Se esse conhecimento for ainda destilado em regras no prompt de sistema, o conjunto de regras continuará crescendo com o tempo. Como fazer a “coleta de lixo” das regras acumuladas para identificar e remover entradas redundantes ou obsoletas? Por que uma única modificação de código bem-sucedida ainda não constitui evolução contínua no sentido apresentado no Capítulo 9?

Abordagem de coleta de lixo: retire do prompt as regras que possam ser codificadas em um linter, na CI ou na validação de ferramentas; monitore as taxas de acionamento e os conflitos das regras e revalide-as periodicamente em relação ao repositório; use Markdown e Git para preservar a origem, as versões e a capacidade de reversão. Um patch bem-sucedido demonstra apenas que resolveu o caso atual. A evolução contínua exige, além disso, que a modificação resulte de evidências operacionais rastreáveis, melhore tarefas posteriores e seja aprovada tanto em testes de regressão com tarefas anteriores quanto em validações de segurança.

6. (★) “Equipes receptivas ao trabalho remoto também costumam ser receptivas a agentes de IA.” Em termos de documentação do conhecimento, quanto falta para que sua equipe ou organização esteja “pronta para a IA”? Qual é o maior obstáculo?

Pergunta aberta. Você pode se autoavaliar usando o indicador indireto deste capítulo: uma pessoa recém-chegada e trabalhando remotamente consegue atuar de forma independente apenas com o repositório e a documentação? Lista de verificação: as decisões estão registradas em documentos? O contexto é incluído em issues e PRs? Os comandos de build e teste estão registrados em arquivos de instruções como CLAUDE.md ou AGENTS.md? O conhecimento tribal foi consolidado em guias para desenvolvedores? O obstáculo mais comum é a transmissão oral e a cultura de quadro branco, que dependem de “perguntar ao colega ao lado”: um agente não consegue ler acordos verbais, apenas documentos.

7. (★★★) Simon Willison propôs a “tríade letal” dos agentes: acesso a dados privados, exposição a conteúdo não confiável e capacidade de comunicação externa. Este capítulo acrescenta um quarto elemento: memória persistente. Como você criaria uma estratégia de segurança para um ambiente de produção que precisa lidar simultaneamente com os quatro?

Organize as defesas em camadas, segundo quatro tipos de fronteira. Fronteira de dados: não monte credenciais, disponibilize o código-fonte como somente leitura e minimize o escopo visível. Fronteira de confiança da entrada: identifique a origem e rebaixe o conteúdo externo à condição de dado “apenas para referência, sem força de instrução”, conforme o código de conduta de lealdade. Fronteira de impacto da saída: bloqueie a rede por padrão e permita apenas destinos autorizados; analise a semântica dos comandos em vez de recorrer a listas de bloqueio; use uma revisão independente por Sidecar e inclua um humano no circuito — operações críticas devem ser revisadas por um mecanismo externo ao contexto. Fronteira entre sessões: qualquer gravação em MEMORY.md deve passar pela mesma análise de confiança aplicada ao conteúdo externo. O objetivo é impedir a execução das instruções maliciosas mesmo que ocorra uma injeção de prompt.

8. (★★) O padrão Artifact permite que um agente gere SQL ou código de frontend para execução direta pelo banco de dados e pelo navegador, sem que o LLM precise processar grandes volumes de dados. Em comparação com o padrão tradicional, no qual o agente fornece diretamente a resposta, quais são as vantagens e desvantagens dessa divisão de trabalho — “o agente gera o código, o sistema executa o código”? Além disso, o SQL gerado pode executar operações destrutivas, e o HTML gerado pode conter vulnerabilidades. Como garantir a segurança do sistema?

Vantagens e desvantagens: os dados fluem diretamente do banco de dados para o frontend, sem passar pelo LLM como “intermediário”. Isso proporciona rapidez, economiza tokens e evita erros de alucinação na transcrição de grandes volumes de dados, sendo adequado à apresentação de muitos dados. O código também é auditável, reutilizável e pode integrar pipelines, com os resultados SQL alimentando diretamente o código de visualização. Em contrapartida, o LLM não vê os resultados da consulta e, portanto, não consegue produzir sínteses adicionais nem tomar decisões com base no conteúdo dos dados. Assim, essa abordagem não é apropriada para tarefas que exigem que o modelo primeiro assimile os dados para depois raciocinar.

Segurança: execute o SQL com uma conta somente leitura e de privilégios mínimos e imponha limites de recursos, como CPU e memória, para evitar o esgotamento de recursos. Para HTML/UI, prefira protocolos declarativos como A2UI, nos quais o agente gera apenas um JSON que descreve a interface, e o cliente a renderiza usando um catálogo de componentes confiáveis, sem executar código arbitrário. Se for indispensável usar HTML arbitrário, ele deverá ser exibido em um ambiente sandbox para impedir injeções.

9. (★★) Codificar regras de negócio como validações baseadas no ground truth do banco de dados e usar o design dos parâmetros para orientar o modelo a verificar as condições da política antes de fazer uma chamada equivale, em essência, a usar a estrutura do código para restringir o comportamento do agente. Quais são as vantagens e limitações desse padrão de “código como regra” em comparação com regras expressas em linguagem natural?

Vantagens: não apresenta ambiguidades, permite execução determinística e lida bem com combinações complexas de condições. Os fatos relativos à política vêm do ground truth do banco de dados e do relógio do servidor, e não de valores declarados pelo próprio modelo; assim, nem alucinações nem injeções de prompt conseguem contorná-los. Essa é a última linha de defesa contra operações irreversíveis. Os parâmetros expected_* também funcionam como uma lista de verificação obrigatória que orienta o raciocínio. Limitações: o código não explica as políticas aos usuários, não procura soluções alternativas e tem custos de manutenção. Conclusão: regras em código complementam as regras em linguagem natural, em vez de substituí-las.

Interação: expansão dos espaços de observação e ação

1. (★★) Em uma arquitetura assíncrona de agentes, a estratégia de prioridade da fila de eventos precisa ser definida durante o projeto. Mas, se a própria determinação da prioridade exigir compreensão semântica — por exemplo, para decidir se uma nova mensagem é mais urgente do que a tarefa atual —, quem deve fazer essa avaliação: um mecanismo de regras ou outra chamada a um LLM? Quais são os custos de cada opção?

A melhor opção é uma abordagem híbrida em camadas: eventos de tipo bem definido são tratados por regras codificadas, com latência zero e alto determinismo, mas sem capacidade de compreender a diferença semântica entre “pare agora mesmo” e “como está o tempo hoje?”. Eventos semanticamente ambíguos são encaminhados a um LLM leve de classificação, que atua como roteador de eventos, ao custo de algumas centenas de milissegundos de latência, despesas adicionais e possíveis erros de classificação. Assim como o Sidecar, esse LLM deve ler apenas campos estruturados para evitar injeção de prompt.

2. (★★) No processamento de eventos baseado em filas, os modelos tendem a se concentrar apenas no último evento. Este capítulo atenua o problema por meio de marcadores na barra de status do agente e de resumos. Mas, se houver 20 eventos acumulados na fila — 10 resultados de ferramentas, 5 mensagens do usuário e 5 alertas do sistema —, como você organizaria a ordem e o formato de apresentação desses eventos para que o modelo não ignore informações importantes?

Primeiro, classifique e elimine duplicatas usando regras e um LLM leve. Eventos urgentes, como alertas e interrupções do usuário, devem ser tratados separadamente por um mecanismo de cancelamento, sem serem misturados ao lote. Os 10 resultados de ferramentas excessivamente longos devem ser truncados e armazenados em arquivos, mantendo-se apenas o início, o fim e o caminho do arquivo. Ao final do contexto, inclua na barra de status do sistema uma lista resumida com a quantidade de eventos de cada tipo e a exigência de responder individualmente a cada item.

3. (★★★) Quando um agente interage com o mundo externo em nome de um usuário, ele enfrenta essencialmente uma escolha de identidade: usar uma identidade virtual independente — com e-mail e número de telefone próprios — para atuar como terceiro ou operar diretamente as contas pessoais do usuário, assumindo a identidade dele. A primeira opção permite atuação autônoma em segundo plano, mas terceiros podem não confiar em uma identidade não humana; a segunda oferece contexto e permissões mais completos, mas introduz questões de autorização, confiança e limites de segurança. Em quais situações cada modo deve ser escolhido?

Por padrão, deve-se usar uma identidade virtual: ela permite operar de forma autônoma em segundo plano, facilita auditorias e, em caso de erro ou comprometimento, não expõe toda a identidade digital do usuário — assim como uma secretária usa seu próprio e-mail corporativo. Ainda assim, é necessário lidar com problemas de CAPTCHA e reputação de IP, por exemplo, usando proxies residenciais. Em situações que exijam a identidade do próprio usuário, como verificação de identidade da conta ou confirmação em chamada a três — como quando o Pine liga para o atendimento ao cliente —, deve-se adotar autenticação com humano no circuito: por VNC/RDP, o usuário faz login pessoalmente em uma interface visual. Os critérios incluem a exigência de que o titular da conta realize a operação, o risco da operação e o escopo das credenciais.

4. (★★) O modelo de ponta a ponta para agentes de voz reúne ASR, LLM e TTS em um único modelo, reduzindo a latência, mas eliminando a modularidade. Se esse modelo cometer um erro em uma etapa específica, como no reconhecimento de fala, depurá-lo e corrigi-lo será muito mais difícil do que em um pipeline serial. Como você projetaria um sistema de observabilidade para um agente de voz de ponta a ponta?

Faça o modelo emitir representações intermediárias legíveis junto com a saída, como o fluxo textual de “monólogo interior” do Moshi e marcadores de eventos acústicos (<emotion>, <noise>). Use uma “autocascata” para localizar a etapa do erro: o mesmo modelo primeiro transcreve e depois raciocina; a comparação com o resultado de ponta a ponta permite determinar se o erro ocorreu na percepção ou no raciocínio. Offline, execute testes de regressão separados por dimensões como compreensão paralinguística e identificação da alternância de turnos.

5. (★) O Step-Audio R1 permite “pensar enquanto fala” por meio da arquitetura MPS de cérebro duplo. No entanto, quando os seres humanos “pensam enquanto falam”, muitas vezes dizem algo antes de refletir o suficiente, corrigem a si mesmos ou usam palavras de preenchimento. O agente deveria imitar essas características humanas ao “pensar enquanto fala”?

Ele deve imitar as “imperfeições” que tenham valor informativo: pausas e palavras de preenchimento externalizam o pensamento e podem mascarar a latência, cabendo ao LLM decidir onde inseri-las. Não deve, porém, imitar autocorreções que prejudiquem a confiança: a contradição entre o pensamento rápido e o lento na Solução 1 — “afinal, devo comprar ou não?!” — destrói a confiança. Experimentos com MPS mostram que o início da cadeia de raciocínio consiste, em geral, em reformular a pergunta; portanto, é seguro começar a falar antes com uma introdução, sem precisar errar e depois se corrigir.

6. (★★) O SoM (Set-of-Mark) e suas variantes estruturadas, como a indexação de elementos DOM, transformam a localização visual do Computer Use: em vez da previsão aberta de coordenadas, usa-se a seleção de IDs em um conjunto fechado. Contudo, todos esses métodos exigem a detecção e a marcação prévias dos elementos da interface, seja por um modelo de segmentação, seja pelo DOM. Se a interface contiver controles não padronizados ou elementos que mudam dinamicamente, as marcações poderão ser incompletas ou imprecisas. Nesses casos, deve-se recorrer à previsão de coordenadas?

A previsão de coordenadas deve ser mantida como alternativa: é a única abordagem que não depende de marcações e funciona tanto com controles não padronizados quanto com elementos dinâmicos. Na prática, o mais adequado é um espaço de ação híbrido, no qual os elementos que podem ser marcados continuem sendo selecionados por ID. A previsão de coordenadas deve considerar a resolução e aplicar redimensionamento proporcional; caso contrário, ocorrerão desvios sistemáticos.

7. (★★) Plataformas robóticas de algumas centenas de dólares, como a XLeRobot, barateiam a coleta de dados por teleoperação. No entanto, a qualidade desses dados depende muito da habilidade do operador. Como dados de baixa qualidade fornecidos por um operador inexperiente afetariam o treinamento de um modelo VLA? Como esses dados poderiam ser filtrados automaticamente durante a coleta?

Os modelos VLA dependem principalmente de aprendizado por imitação; portanto, demonstrações de baixa qualidade os levam a aprender tremores, desvios, hesitações e movimentos malsucedidos como se fossem estratégias corretas. Isso reforça a conclusão do Capítulo 8: os dados são mais importantes do que a arquitetura.

8. (★★★) Este capítulo aborda três modalidades de interação: voz, Computer Use e robótica. A arquitetura de interação pode evoluir pela unificação de ponta a ponta, por cascatas modulares ou pela separação entre a interação em primeiro plano e o raciocínio em segundo plano, sem necessariamente avançar pelo mesmo caminho dos limites da inteligência. Nos próximos cinco anos, os agentes devem priorizar modelos unificados mais poderosos ou preservar uma divisão substituível entre componentes rápidos e lentos? Considere latência, observabilidade, velocidade de evolução dos modelos e risco das tarefas.

Como defende o Thinking Machines Lab, a interatividade será incorporada ao modelo, em vez de adicionada externamente por um harness, e evoluirá junto com a inteligência. O Computer Use passará de capturas de tela quadro a quadro para a observação contínua. Os modelos de mundo para inteligência incorporada serão implementados de forma abrangente, mas a separação entre componentes rápidos e lentos não desaparecerá, pois os modelos de raciocínio de fronteira evoluem rapidamente. Uma arquitetura na qual um modelo de interação e um modelo de raciocínio SOTA colaborem como pensadores rápido e lento poderá se consolidar como solução de longo prazo.

9. (★★) A indexação de elementos do DOM ou da Accessibility Tree funciona bem em aplicações web padronizadas, mas um número cada vez maior de interfaces de software — renderizadas com Canvas/WebGL ou compostas de controles personalizados multiplataforma — não oferece informações estruturadas acessíveis e depende apenas de marcação visual ou previsão de coordenadas. O Computer Use deve apostar em uma abordagem puramente visual ou manter, ao mesmo tempo, caminhos estruturados e visuais? Quais são os custos e benefícios de manter ambos?

No curto prazo, os dois caminhos devem coexistir: quando há indexação estruturada disponível, a localização é mais precisa e estável, além de evitar falsas detecções do modelo de segmentação; a visão pura, por sua vez, é a única opção para softwares nativos, Canvas e jogos. Quando o próprio modelo tem boa capacidade de grounding — isto é, consegue clicar nas coordenadas indicadas —, a indexação estruturada não oferece vantagem significativa. No longo prazo, a abordagem puramente visual tem um potencial maior.

10. (★★) Os modelos VLA usam o agrupamento de ações — como descrito no texto, o modelo gera de uma só vez uma pequena sequência de ações futuras, que a thread de controle reproduz em frequência mais alta — para ocultar a latência de inferência dentro do tempo de execução. No entanto, se o ambiente mudar repentinamente durante a execução, por exemplo, se um objeto for removido, a sequência de ações gerada antecipadamente deixará de ser válida. Como equilibrar a eficiência do agrupamento de ações com a necessidade de responder rapidamente a mudanças no ambiente?

O agrupamento troca, em essência, capacidade de reação pela suavidade dos movimentos: quanto maior o bloco, mais lenta será a resposta. O tamanho do bloco só precisa satisfazer o limite inferior “tempo de inferência < tempo de execução do bloco”; não deve ser aumentado indiscriminadamente. Mantenha o modelo de percepção em execução durante as ações e, quando ele detectar uma mudança repentina no ambiente, descarte as ações restantes e realize uma nova inferência — o equivalente a uma “interrupção” no cenário de voz. O tamanho do bloco pode ser ajustado dinamicamente: blocos longos economizam recursos computacionais em ambientes estáticos, enquanto blocos curtos preservam a rapidez de resposta em ambientes dinâmicos.

11. (★★★) Os três cenários deste capítulo — voz, Computer Use e robótica — enfrentam o problema de latência no ciclo “perceber, pensar e agir” e precisam dividir funções entre o limite de inteligência e a rapidez da interação. Na voz, isso se manifesta como “errar e depois corrigir”; no Computer Use, como “clicar primeiro e verificar depois”; na robótica, como “dar um passo e então observar”. Como usar níveis de ação, operações reversíveis, confirmação de estado, controle de permissões e parada segura para impedir que a interação rápida produza consequências irreversíveis?

Classifique as ações conforme sua reversibilidade. O pensamento rápido só pode executar ações reversíveis; operações irreversíveis precisam ser aprovadas pelo pensamento lento. O modelo rápido não deve ter permissão para realizar chamadas de ferramentas que possam causar consequências irreversíveis.

12. (★★★) O mesmo conjunto de primitivas — ativação, ponto seguro, cancelamento, preempção e separação entre componentes rápidos e lentos — reaparece neste capítulo em diferentes escalas de tempo. Escolha uma delas e explique como sua implementação difere entre o processamento orientado a eventos, que ocorre de segundos a dias, e o agrupamento de ações robóticas, que ocorre em milissegundos. O que determina principalmente essa diferença: a velocidade das mudanças no ambiente, a reversibilidade da ação ou o custo de obter uma observação?

Considere o cancelamento. No processamento orientado a eventos, o cancelamento ocorre em um ponto seguro entre duas chamadas de ferramentas: ao receber terminate, o agente libera os recursos, confirma o recebimento e encerra a execução. Uma latência de alguns segundos é aceitável, pois uma única chamada de ferramenta já pode levar de segundos a minutos. No agrupamento de ações, o cancelamento precisa surtir efeito em milissegundos: assim que a thread de controle detectar um evento de segurança ou uma mudança significativa na observação, deverá interromper o movimento atual, descartar o restante do bloco e observar novamente. Um instante de atraso pode fazer o robô colidir com um obstáculo.

Dos três fatores propostos, o custo de obter uma observação é, na verdade, o menos decisivo, pois nos dois casos é possível observar novamente a baixo custo. O que realmente determina a diferença é a combinação dos outros dois fatores: a velocidade das mudanças no ambiente define a densidade necessária dos pontos seguros — se basta inseri-los entre chamadas de ferramentas ou se são necessários em todos os ciclos de controle —, enquanto a reversibilidade da ação define o custo de perder um desses pontos — um e-mail enviado a mais pode ser seguido por um pedido de desculpas, mas não é possível desfazer a queda de um copo.

Disso decorre uma regra de projeto: a densidade dos pontos seguros deve acompanhar a velocidade das mudanças no ambiente; a proteção adicional necessária além desses pontos — parada de emergência por hardware, controlador de segurança independente ou confirmação adicional — depende do grau de irreversibilidade da ação. Isso também explica por que as operações de alto risco do Capítulo 4 exigem aprovação prévia, enquanto os robôs precisam de uma camada de segurança de hardware independente do modelo: ambas são uma segunda linha de defesa nos casos em que os pontos seguros, por si sós, não bastam.

Capítulo 7: Avaliação de agentes

1. (★★) O LLM como avaliador usa um modelo de linguagem para avaliar a saída de outro modelo de linguagem. Essa “autoavaliação” apresenta pontos cegos sistemáticos — por exemplo, o modelo pode atribuir notas altas de forma consistente a determinado estilo de resposta, embora essa preferência não corresponda ao julgamento humano? Como detectar e corrigir esses vieses?

Sim: viés de extensão, viés de estilo de resposta e exploração de vulnerabilidades por modelos da mesma família (lei de Goodhart). Para detectar esses vieses, crie um conjunto de referência validado por humanos com 100 a 200 exemplos e meça o kappa de Cohen entre o avaliador e os humanos; audite periodicamente a correlação entre as notas e a extensão das respostas; encarregue uma equipe vermelha de criar casos adversariais. Para corrigi-los, faça o rubric penalizar explicitamente a prolixidade e imponha um limite de extensão; use avaliadores heterogêneos de diferentes famílias de modelos.

2. (★★★) É fundamental impedir o vazamento dos conjuntos de dados de avaliação. No entanto, no ecossistema de código aberto, assim que os dados de um benchmark são publicados, eles rapidamente passam a integrar os dados de treinamento. Esse “jogo de gato e rato” tem um desfecho? Projete um método de avaliação que seja fundamentalmente resistente ao vazamento de dados.

Não há solução definitiva para um banco estático de questões; só é possível correr atrás do problema. A saída fundamental é tornar público o “mecanismo de geração” e manter privadas as “instâncias concretas”: usar templates parametrizados, como no τ²-bench e no AndroidWorld, instanciados aleatoriamente a cada execução, com verificação baseada no estado final do ambiente, e não em uma sequência fixa de respostas.

3. (★★) Os quatro critérios da Scale AI — orientação de especialistas, cobertura abrangente, ponderação conforme a importância dos critérios e critérios de avaliação autocontidos — buscam eliminar a subjetividade da avaliação. No entanto, certas dimensões das tarefas, como “A resposta é útil?” e “O tom é adequado?”, são inerentemente subjetivas. Como criar rubrics confiáveis para essas dimensões?

Converta critérios abstratos em comportamentos verificáveis. Forneça exemplos concretos e casos-limite para cada nível; um rubric é um produto iterativo — durante o uso experimental, registre as divergências entre os avaliadores e transforme-o gradualmente em um repertório de casos. Complemente-o com ponderação das notas de vários avaliadores e verificações de consistência, encaminhe os casos divergentes para revisão humana e calibre a taxa de concordância com o conjunto de referência.

4. (★★) O τ-bench avalia agentes simulando o comportamento de usuários reais. No entanto, o próprio usuário simulado é um LLM e pode subestimar sistematicamente certos casos extremos, como usuários emocionalmente exaltados ou que se expressam de forma pouco clara. Como validar a qualidade do próprio usuário simulado?

A primeira versão do τ-bench deixou uma lição: o simulador era mecânico demais e suas instruções, simples demais, permitindo que o agente adivinhasse as respostas. Entre os métodos de validação estão a inspeção manual de uma amostra dos diálogos simulados, para verificar se seguem o princípio da revelação progressiva e não inventam informações alheias ao roteiro, e testes com uma pequena amostra de usuários reais, para observar se o ranking dos modelos corresponde ao obtido na avaliação simulada.

5. (★★) A comparação pareada (modelo de Bradley-Terry) pressupõe que as preferências sejam transitivas: se A > B e B > C, então A > C. No entanto, as preferências humanas frequentemente violam a transitividade. Em quais cenários podem surgir preferências não transitivas na avaliação de agentes? Como isso afeta a confiabilidade dos rankings?

Cenários: situações com concessões entre várias dimensões — A é preciso, porém lento; B é rápido, porém sucinto; C é minucioso, porém caro — nas quais diferentes avaliadores ou tarefas atribuem pesos distintos a cada dimensão. Os rankings do Chatbot Arena dependem, por natureza, da distribuição dos prompts dos usuários. Impacto: o modelo de Bradley-Terry reduz o desempenho a uma única pontuação; quando há não transitividade, os rankings ficam instáveis e variam conforme a distribuição dos confrontos. Para mitigar o problema, crie rankings separados por dimensão de capacidade e apresente a matriz de taxas de vitória em comparações pareadas.

6. (★★) Este capítulo distingue o Pass@k, que representa o limite superior da capacidade, do Pass consecutive@k, que mede a confiabilidade para o negócio. Para um agente cuja taxa de sucesso em uma única execução é de apenas 60%, como combinar o custo das falhas, o custo das novas tentativas e os efeitos colaterais de uma tarefa para decidir qual métrica apresentar e qual deve ser o valor de \(k\)?

Comece verificando se é possível reverter uma falha. Quando as falhas podem ser repetidas automaticamente e não deixam efeitos colaterais externos — como em recuperação, geração de rascunhos e complementação de código —, a questão é “o agente consegue concluir a tarefa se tiver oportunidades suficientes?”. Nesse caso, apresente o Pass@k, definindo k como o número de novas tentativas realmente permitido. Quando uma falha deixa consequências irreversíveis — como em pagamentos, reembolsos, envio de e-mails externos e implantação em produção —, um único erro representa uma perda real; nesse caso, apresente o Pass^k. Com uma taxa de sucesso de 0,6 por execução, o Pass@5 é de aproximadamente 99,0%, enquanto o Pass^5 é de aproximadamente 7,8% — uma diferença de uma ordem de grandeza entre duas medidas do mesmo agente. Apresentar apenas a primeira superestima gravemente sua confiabilidade.

O valor de k deve refletir a realidade da implantação, e não o número mais atraente: no Pass@k, use o orçamento de novas tentativas; no Pass^k, use a quantidade de execuções consecutivas em um turno ou lote. Quando as novas tentativas forem caras, adote uma validação em duas etapas: primeiro, faça uma triagem preliminar dos candidatos com o Pass@1; depois, execute o Pass^k apenas para os poucos selecionados. Seja qual for a métrica apresentada, informe k e o protocolo de amostragem. Para operações com efeitos colaterais, faça a amostragem em uma sandbox ou em um ambiente que permita reversão e contabilize cada falha na estatística de confiabilidade, em vez de “tentar novamente até funcionar”.

7. (★★) Este capítulo propõe o método científico “Observar → Formular hipótese → Experimentar → Validar”. Na prática, porém, o espaço de comportamento do agente é vasto, e a validação de uma única hipótese pode exigir centenas de execuções de avaliação. Como maximizar as informações obtidas pela avaliação com um orçamento computacional limitado?

Primeiro, agrupe as falhas e restrinja o teste-piloto às tarefas com maior valor diagnóstico. Use testes pareados de baixo custo, alterando uma única variável, e trate uma pequena amostra como requisito para ampliar os testes, não como evidência suficiente para implantação. Do ponto de vista estatístico, use primeiro o erro padrão como filtro conservador e aplique uma análise pareada, como o teste de McNemar, às mesmas tarefas; se o ganho esperado for menor que a faixa de ruído, amplie o conjunto de avaliação. Ao testar diversas variantes em paralelo, corrija as comparações múltiplas e confirme os resultados positivos em uma execução independente.

8. (★) No experimento do AndroidWorld, a árvore completa de elementos elevou a taxa de sucesso de 25% para 100%, mas aumentou o uso de tokens para 2,498 vezes o do grupo de controle; após a poda, a taxa de sucesso permaneceu em 100%, enquanto o uso de tokens caiu para 0,506 vez o do controle. Como criar regras de poda automática que removam nós de UI sem conteúdo semântico, mas preservem as informações necessárias para acessibilidade, verificação de estado ou ações posteriores?

Adote uma política em camadas de “remover por padrão, preservar mediante evidências”. Mantenha os nós visíveis, com texto, acionáveis, focalizáveis, roláveis, que contenham estados ou tenham rótulos de acessibilidade, além dos caminhos ancestrais mais curtos e dos rótulos adjacentes necessários para interpretá-los. Remova contêineres usados apenas para layout e resuma subárvores repetidas. Antes e depois da poda, verifique se os IDs dos elementos acionáveis, os estados e os valores foram preservados, e mantenha a captura de tela como alternativa visual. Reproduza a regra nas trajetórias com falhas e depois teste-a em aplicativos que não tenham sido usados nos ajustes. Sucesso, tokens e latência devem funcionar conjuntamente como guardrails; qualquer regressão em tarefas de acessibilidade deve impedir o lançamento.

9. (★★) A simulação de usuários do τ-bench emprega a “revelação progressiva de informações”: em vez de fornecer todas as informações de uma só vez, revela-as gradualmente conforme as perguntas do agente. Como esse design afeta os resultados da avaliação? Se a estratégia de revelação do usuário simulado diferir significativamente da adotada por usuários reais, as conclusões da avaliação continuarão confiáveis?

Impacto: se a estratégia de revelação for distorcida, o agente pode ter apenas aprendido a “se adaptar ao simulador” — um efeito da lei de Goodhart —, e as pontuações absolutas perdem seu valor de referência; o ranking relativo entre os modelos ainda pode ser relevante. Para mitigar o problema, calibre o simulador com diálogos reais, inspecione amostras manualmente e explicite os limites de aplicabilidade das conclusões.

Capítulo 8: Pós-treinamento de modelos

1. (★★) O esquecimento catastrófico — quando o ajuste fino para uma tarefa específica destrói as capacidades gerais originais do modelo, como a chamada de ferramentas de propósito geral — é particularmente problemático em cenários com agentes. Em comparação com o ajuste fino de todos os parâmetros, o LoRA congela os pesos do modelo-base e apresenta menor risco de esquecimento, mas não é imune. Quais estratégias podem reduzir ainda mais o esquecimento de capacidades durante o ajuste fino?

Combinação de dados: incluir cerca de 20% de dados gerais ou da distribuição original, para que a proporção de dados da nova tarefa não prejudique as capacidades anteriores; limitar o treinamento: interromper o SFT assim que “o formato estiver estável e as capacidades básicas estiverem presentes” — a parada antecipada evita o colapso; usar um rank pequeno (8–32) no RL e manter a penalidade de KL para que a política permaneça próxima do modelo de referência; congelar componentes essenciais (por exemplo, treinar apenas a camada de projeção de um VLM); associar vários adaptadores LoRA a diferentes tarefas para isolar as capacidades; executar testes de regressão em benchmarks gerais.

2. (★★) O pós-treinamento consolida capacidades nos pesos do modelo, como uma “memória muscular”, enquanto o aprendizado em contexto insere o conhecimento na entrada durante a inferência. Algumas capacidades, como o conhecimento de domínio, podem ser aprendidas por pós-treinamento ou fornecidas por exemplos few-shot. Que critérios você usaria para decidir qual caminho adotar para determinada capacidade?

Primeiro, avalie se a capacidade pode ser expressa adequadamente por meio de símbolos externos: fatos e evidências devem ficar na RAG; princípios que podem ser expressos em linguagem, em prompts/skills; e procedimentos determinísticos e restrições rígidas, em programas. Capacidades de alta dimensionalidade, como compreensão de imagens médicas, tom natural e políticas implícitas, muitas vezes exigem atualização de parâmetros, mesmo quando o domínio ainda está mudando. Em seguida, considere o custo de atualização, o volume de chamadas, a necessidade de atualização e o risco: durante a exploração, use o contexto para validar rapidamente; treine apenas quando a abordagem se mostrar estável, eficaz e precisar de ampla generalização. Regras rígidas, por mais estáveis que sejam, nunca devem depender apenas da memória dos parâmetros.

3. (★★) A destilação de modelos permite que um modelo pequeno aprenda o comportamento de um modelo grande. Conforme o nível de capacidade, os modelos destilados podem ser divididos, em linhas gerais, em três categorias: modelos de chat (diálogo em turno único e respostas diretas), modelos de raciocínio (longas cadeias de raciocínio antes da resposta) e modelos agênticos (chamadas de ferramentas em vários turnos e interação com o ambiente). Quais são os diferentes desafios de destilar cada tipo? (Dica: comece perguntando “o que exatamente está sendo destilado”: o estilo da saída, a trajetória completa de raciocínio ou a política de interação com o ambiente; quais tokens da trajetória devem ser aprendidos e quais retornos do ambiente não devem; e quão tardios e esparsos são os sinais de sucesso ou fracasso.)

Chat: basta aprender o mapeamento “entrada → saída” e o estilo; o SFT convencional é suficiente, sendo o caso mais simples. Raciocínio: exige trajetórias completas de raciocínio, portanto é necessário um modelo professor de código aberto; as trajetórias com respostas erradas devem ser filtradas. Agêntico: exige um ambiente de simulação realista; o aprendizado offline está sujeito a divergências entre o aprendiz e o amostrador, por isso recomenda-se a On-Policy Distillation com base em um modelo professor de código aberto.

4. (★★★) Nas interações com agentes em vários turnos, o problema de atribuição de crédito é mais grave do que em cenários de turno único: é difícil atribuir um sucesso ou fracasso final a uma decisão tomada no terceiro turno, e não no sétimo. Como você projetaria uma estratégia de distribuição de recompensas?

Quando for possível avaliar as etapas intermediárias, inclua recompensas de processo — o V-IRL atribui ±1 por etapa. Seguindo o RLVP, use regras determinísticas para fornecer sinais de trajetória a cada ação, restaurando a variância dentro dos grupos em que todas as tentativas fracassam ou todas são bem-sucedidas.

5. (★★★) Se você tivesse um orçamento fixo, por exemplo, US$ 10.000, para melhorar um agente de atendimento ao cliente, como o distribuiria entre contexto e conhecimento, prompts/skills, restrições programáticas e treinamento de parâmetros? Quais fatores determinariam sua decisão?

Primeiro, reserve parte do orçamento para criar um conjunto de avaliação e validadores de trajetórias; caso contrário, não será possível comparar os demais investimentos. Armazene fatos e políticas dos produtos em uma base de conhecimento rastreável. Valide rapidamente, por meio de prompts/skills, um pequeno conjunto de princípios de atendimento que possam ser expressos em linguagem. Use programas como salvaguarda para permissões de reembolso, privacidade e coerência entre promessas e ações. Invista no treinamento de parâmetros apenas para capacidades difíceis de codificar como regras e usadas em escala suficiente, como tom natural e compreensão de intenções complexas. As proporções exatas dependem do gargalo, do risco, da frequência de atualização, do volume de chamadas e da capacidade do modelo existente.

6. (★★★) O aprendizado autônomo do modelo com poucas amostras e sem uma função de recompensa clara é considerado por alguns o objetivo final do pós-treinamento. Quão distantes os métodos atuais de treinamento por RL estão desse objetivo? De onde provavelmente virá o próximo avanço?

A lacuna: como apontam Silver e Sutton, o RL atual só consegue aprender com o sucesso ou fracasso final. Feedbacks ricos, como o cliente dizer “preciso dos quatro últimos dígitos do seu cartão de crédito”, são totalmente desperdiçados, o que exige centenas de tentativas às cegas. A eficiência amostral e as recompensas verificáveis são os principais gargalos. Entre os possíveis avanços estão modelos generativos de recompensa capazes de formular os próprios princípios e identificar uma direção de melhoria a partir de um único fracasso, além da abordagem de world models para modelar o ambiente.

7. (★★) Este capítulo observa que o ajuste fino com LoRA não é caro. Seria possível, então, treinar um LoRA dedicado para cada usuário ou empresa cliente, gravando a memória do usuário ou o conhecimento corporativo nos parâmetros, em vez de armazená-los em uma base de conhecimento externa, como no Capítulo 3? Em que situações “gravar a memória nos parâmetros” teria vantagem sobre “armazenar a memória em uma base de conhecimento” e quando seria contraproducente?

O LoRA tem dificuldade para memorizar com precisão grandes volumes de fatos — isso exigiria a continuação do pré-treinamento, com um aumento acentuado de custo. Mesmo que os memorize, o modelo dificilmente conseguirá usá-los em raciocínios com múltiplos saltos. Portanto, usar LoRA para memorizar fatos não é uma boa abordagem técnica. Além disso, quando os fatos mudam com frequência ou é necessária uma auditoria rastreável, a RAG é superior.

8. (★★★) A On-Policy Distillation depende de um modelo professor mais forte para supervisionar o aluno. No entanto, a pesquisa Weak-to-Strong Generalization, da OpenAI, apresentou uma conclusão contraintuitiva: a supervisão de um modelo fraco às vezes pode ativar capacidades latentes, porém inativas, em um modelo mais forte. Se isso fosse aplicado ao treinamento de agentes, poderia viabilizar uma destilação reversa em que “um modelo pequeno ensina um modelo grande”?

Sim, é possível. O ponto central é que “verificar é mais fácil do que gerar”: o modelo fraco não deve atuar como demonstrador — o limite do SFT é o nível do demonstrador —, mas como verificador ou modelo de recompensa, enquanto o modelo forte explora por conta própria e o modelo fraco apenas avalia.

9. (★★) Um Process Reward Model (PRM) avalia cada etapa do raciocínio, enquanto um Outcome Reward Model (ORM) considera apenas o resultado final. O que merece maior recompensa: “um processo correto que leva a um resultado errado” ou “um processo errado que, por acaso, produz o resultado correto”? Como você equilibraria os dois em cenários de chamadas de ferramentas em várias etapas por um agente?

Um sucesso fortuito é mais perigoso: atalhos que violam regras muitas vezes elevam artificialmente a taxa aparente de sucesso — por exemplo, alterar arquivos de teste ou ignorar a validação — e favorecem o reward hacking. Siga o princípio do RLVP de “recompensar resultados e penalizar trajetórias”: ações erradas, como chamadas de ferramentas, são fáceis de verificar, portanto desconte pontos por ação; quando as etapas intermediárias forem fáceis de avaliar, também podem ser concedidas recompensas de processo. Mas não torne as restrições de processo excessivamente densas: a estratégia superior do tipo “push-cut” foi descoberta justamente graças à liberdade de exploração proporcionada pelas recompensas de resultado.

10. (★★★) Os conjuntos de dados de avaliação discutidos neste capítulo, como SWE-Bench Verified, τ²-bench e AndroidWorld, podem ser usados tanto para avaliação quanto para pós-treinamento. Contudo, quando um conjunto de avaliação é usado no treinamento, ele deixa de ser independente. Isso viola o princípio fundamental de que os conjuntos de treinamento e teste devem permanecer separados? A geração dinâmica de parâmetros no τ²-bench e os templates parametrizados no AndroidWorld atenuam o problema até certo ponto, mas a estrutura desses templates permanece fixa. Como aproveitar plenamente o valor dos dados de avaliação para o treinamento sem comprometer a independência da avaliação?

Reutilize os ambientes, não as perguntas. Parâmetros dinâmicos só impedem a “memorização de respostas”, não o sobreajuste aos templates. Portanto, reserve lotes inteiros de templates inéditos ou cenários fora da distribuição para avaliação — de modo análogo ao V-IRL, treinado em Nova York e testado em nove cidades desconhecidas. Use templates parametrizados para gerar em lote variações de treinamento que viabilizem o aprendizado por currículo e considere as pontuações OOD a verdadeira métrica de generalização.

11. (★★★) Este capítulo propõe um paradigma de treinamento de “primeiro a forma, depois a essência”: interromper o SFT quando “o formato estiver estável e as capacidades básicas estiverem presentes” e então passar para RL. Na prática, como determinar quando o SFT é “suficiente” e chegou o momento da transição?

Sinal de formato: as saídas de chamadas de ferramentas podem ser analisadas e executadas de maneira estável, e a taxa de falhas na execução cai a um nível em que as recompensas podem ser calculadas de forma confiável. Sinal de benefício: acrescentar mais dados de demonstração já não melhora o desempenho em novos cenários OOD, indicando que o gargalo está no próprio objetivo de memorização do SFT e que o ponto de transição foi alcançado. Sinal de sobreajuste: interrompa assim que o desempenho no conjunto de validação começar a piorar. O experimento V-IRL mostra que, depois que o excesso de treinamento por SFT faz o modelo colapsar para a distribuição de treinamento, nem mesmo o RL consegue restaurar o desempenho OOD.

12. (★★★) A dinâmica de treinamento do ReTool mostra (ver Experimento 7-15) que algumas respostas extremamente longas podem prolongar significativamente todo o ciclo de treinamento: a maioria dos rollouts de um lote já foi gerada, mas o sistema precisa aguardar a conclusão das respostas mais longas, o que reduz a utilização das GPUs do cluster. Como melhorar a utilização dos recursos em clusters de treinamento diante dessa cauda longa de respostas?

Na camada de infraestrutura, desacople o rollout do cluster de treinamento e use um pipeline assíncrono; preencha as GPUs ociosas com novas solicitações por meio de processamento contínuo em lotes. Reduza a cauda longa na origem: o Overlong Reward Shaping do DAPO penaliza de forma gradual respostas excessivamente longas.

13. (★★★) Ao treinar um agente em ambientes simulados por LLMs — como um mecanismo de busca ou usuários simulados —, o alvo da exploração do agente deixa de ser “as regras do ambiente real” e passa a ser “os vieses e as brechas do próprio simulador”. Quais comportamentos concretos de reward hacking podem surgir nesse tipo de treinamento e como evitá-los?

Comportamentos típicos: fazer promessas excessivas aos “usuários simulados” e acumular pedidos de desculpa e frases bajuladoras — usuários simulados são facilmente apaziguados e, ao contrário dos usuários reais, não cobram do agente o cumprimento efetivo de suas promessas; inventar fatos que o simulador não verificará; formular consultas tendenciosas para um “mecanismo de busca simulado”, explorando sua tendência a retornar documentos que contêm a resposta e tomando um atalho em vez de aprender a fazer uma recuperação genuína; quando a recompensa vem de pontuações do simulador ou de um LLM como avaliador, produzir respostas prolixas, padronizadas e com “aparência profissional” para acumular pontos; e, de maneira mais sutil, restringir a política à distribuição com a qual o simulador está familiarizado, evitando seus pontos cegos de conhecimento, nos quais o feedback não é confiável e costuma ser avaliado incorretamente — assim, o agente aprende a atuar apenas “no mundo em que o simulador é competente”. O primeiro princípio de defesa é ancorar a recompensa em estados reais verificáveis por software (conclusão da tarefa, gravações no banco de dados, retornos reais de APIs), usando as pontuações do simulador ou do LLM como avaliador apenas como sinais auxiliares, auditando periodicamente sua correlação com os resultados reais e combinando essa abordagem com restrições de trajetória que penalizem ações suspeitas. Além disso, é preciso distinguir dois tipos de simulador: para aqueles que têm um equivalente real, como os de busca, pode-se adotar uma abordagem “híbrida” — a maioria das interações passa pelo simulador, intercalada com chamadas reais de API, que são usadas para calibrá-lo periodicamente, como na degradação de qualidade em formato de currículo do ZeroSearch. No entanto, no caso de usuários simulados, não é possível incluir usuários reais no treinamento. Portanto, “quão fiel é o usuário simulado a um usuário real” torna-se um problema independente, que só pode ser respondido com trajetórias online: comparam-se o comportamento de usuários reais nas trajetórias de produção e o comportamento do usuário simulado nas mesmas situações, identificam-se diferenças sistemáticas — usuários reais fazem perguntas complementares, ficam impacientes e encerram conversas abruptamente, enquanto usuários simulados muitas vezes não fazem isso — e, com base nisso, o simulador é calibrado continuamente. As métricas reais online também são o único critério para liberação: nenhuma pontuação obtida no simulador é suficiente.

Capítulo 9: Evolução contínua dos agentes

1. (★★) Um documento de experiência é respaldado por três trajetórias bem-sucedidas e uma trajetória malsucedida. A falha ocorreu em uma versão mais recente da API. Como o sistema deve determinar se a experiência foi invalidada ou se suas condições de aplicabilidade mudaram?

Primeiro, as quatro evidências devem ser estratificadas por versão da API, condições da tarefa e estado do ambiente, em vez de se decidir por contagem. Se a política antiga só tiver êxito na versão antiga e falhar de forma consistente na nova, deve-se restringir o escopo de aplicabilidade da experiência e gerar uma candidata para a nova versão. Se ela também falhar na mesma versão e sob os mesmos pré-requisitos, sua confiança deve ser reduzida ou a experiência deve ser revogada.

2. (★★) A satisfação dos usuários de um agente de atendimento ao cliente aumenta, mas a taxa de violações de regras também cresce. Por que a satisfação não pode servir como único sinal de aprendizado? Como você definiria métricas de guardrail?

A satisfação pode recompensar reembolsos não autorizados, vazamento de informações ou promessas excessivas. Portanto, ela só pode ser uma métrica de qualidade e não pode se sobrepor aos requisitos mínimos de segurança. Os guardrails devem abranger, no mínimo, violações de regras, vazamento de dados privados, afirmações sem evidências, inconsistências entre promessas e ações e operações não autorizadas. Essas métricas devem ter limites rígidos que não possam ser compensados por uma pontuação média. Taxa de resolução, alternativas em conformidade com as regras, concisão e satisfação só devem ser comparadas entre candidatos que estejam em conformidade.

3. (★★★) O mesmo problema de “falsa promessa” pode ser mitigado por meio de um prompt, de verificações no harness ou do treinamento de parâmetros. Que evidências você usaria para decidir onde fazer a alteração?

Comece identificando a causa raiz. Se o modelo sabe que uma ferramenta não foi executada, mas ainda assim usa termos que indicam conclusão, uma regra mínima no prompt pode corrigir o problema. Se a promessa puder ser comparada de forma determinística com o texto da resposta e o estado da ferramenta, uma verificação no harness será mais confiável e também deverá servir como última linha de defesa em cenários de alto risco. Se o problema abranger muitas formas de expressão e refletir uma capacidade ampla de alinhamento entre linguagem e ação, considere o treinamento de parâmetros. Dê preferência à menor alteração que seja mais fácil de validar e reverter, comparando seu desempenho tanto em um conjunto de falhas quanto em um conjunto preservado de tarefas antigas.

4. (★★★) Um agente pode modificar ferramentas e validadores, mas não deve ter permissão para modificar a raiz de confiança que aprova suas próprias atualizações. Como você separaria as permissões e os limites de código dessas duas partes?

Coloque o código que pode evoluir em uma sandbox com poucos privilégios, na qual ele só possa gerar patches e testes. O sistema de permissões, as chaves de API, a configuração de controle de liberação e os validadores de atualizações fazem parte dos mecanismos de segurança; o agente na sandbox não deve ter acesso de leitura nem de gravação a esses componentes. As alterações de código geradas pelo agente devem ser reproduzidas e submetidas a testes de regressão pelos mecanismos de segurança em um ambiente isolado antes da liberação.

5. (★★) À medida que a base de conhecimento de experiências cresce, erros de recuperação e conflitos de conhecimento podem anular os benefícios do aprendizado. Como devem ser projetados os mecanismos de versionamento, atualização e descarte?

Cada experiência deve preservar suas trajetórias de origem, condições de aplicabilidade, versão do ambiente, data de validação e nível de confiança. Entradas conflitantes não devem sobrescrever umas às outras silenciosamente; elas devem ser ramificadas por condição ou marcadas. Periodicamente, deve-se executar um “aprendizado durante o sono” para mesclar entradas duplicadas.

6. (★★★) O aprendizado de parâmetros é eficaz para o estilo da linguagem natural, mas tem dificuldade em garantir regras rígidas de negócio. Projete um esquema de evolução contínua para atendimento médico que coordene parâmetros, conhecimento, Skills e restrições no nível do código.

Os parâmetros — isto é, um modelo submetido a pós-treinamento — são responsáveis por compreender a linguagem médica, produzir respostas naturais e empáticas e reconhecer intenções complexas. A base de conhecimento armazena as versões mais recentes de diretrizes, bulas de medicamentos e políticas institucionais, e as respostas devem citar suas fontes. Uma Skill descreve o fluxo de trabalho para coletar informações da consulta, classificar riscos, encaminhar o caso a um humano e realizar o acompanhamento. O código no servidor impõe a verificação de identidade, a minimização de dados privados, a verificação de contraindicações, o encaminhamento de riscos emergenciais e os limites de permissão. As trajetórias de produção são primeiro avaliadas quanto à segurança médica, confiabilidade factual, consistência entre promessas e ações e qualidade da expressão; em seguida, são usadas para gerar quatro classes de candidatas a atualização. Qualquer alteração em parâmetros ou no fluxo de trabalho deve passar por um conjunto preservado de segurança médica e por revisão humana antes de uma liberação canário.

Capítulo 10: Colaboração multiagente

1. (★★) Na colaboração multiagente com contexto compartilhado, os agentes subsequentes herdam todo o contexto dos agentes anteriores. No entanto, a perspectiva herdada de um agente anterior pode enviesar o julgamento dos agentes subsequentes. Por exemplo, um “revisor de código” que herda o contexto de um “analista de requisitos” pode continuar abordando a tarefa pela perspectiva dos requisitos, e não pela qualidade do código. Como detectar e eliminar essa interferência entre papéis?

Detecção: use um LLM para analisar a trajetória do agente e determinar se o novo papel ainda apresenta comportamentos próprios do papel anterior. Eliminação: ao mudar de etapa, altere também o prompt de sistema e o conjunto de ferramentas — remova as ferramentas de questionamento e adicione ferramentas de lint e teste — para reforçar a nova identidade. Acrescente ao final do contexto uma barra de status do sistema que destaque as informações do papel atual. Se ainda assim não for possível eliminar a interferência entre papéis, considere um método de colaboração sem contexto compartilhado.

2. (★★) No padrão gerenciador, o agente gerenciador é responsável por decompor a tarefa e integrar os resultados. No entanto, a capacidade do gerenciador limita o desempenho de todo o sistema: se ele não conseguir decompor corretamente a tarefa, nem mesmo os subagentes mais capazes serão eficazes. Como garantir que o gerenciador produza uma decomposição adequada?

De acordo com a conclusão do Plan-and-Act de que “um planejador fraco é o gargalo do sistema”, atribua o modelo mais capaz ao gerenciador. Medidas de harness: antes da execução, faça um LLM revisor validar de forma cruzada o resultado da decomposição; exija que o gerenciador defina critérios de aceitação e dependências claros para cada subtarefa ao decompor a tarefa.

3. (★★) O padrão descentralizado se inspira nas melhores práticas das organizações humanas. Contudo, essas organizações também apresentam muitos modos de falha, como comunicação deficiente, transferência de responsabilidade e conflitos de objetivos. Quais “patologias organizacionais” têm maior probabilidade de surgir em uma sociedade de agentes? Como preveni-las?

Em paralelo às três categorias do MAST: interfaces pouco claras e responsabilidades sobrepostas; divergências na compreensão dos objetivos e informações mal interpretadas nas etapas posteriores; alegações falsas de que uma tarefa foi “concluída”. Outros problemas incluem a amplificação de erros em cascata, como no jogo do telefone; transferências cíclicas entre papéis; e conversas em grupo entre agentes que continuam divergindo sem convergir. Medidas preventivas: interfaces baseadas em contratos e um envelope de mensagem unificado, máquinas de estado de tarefas com verificação de aceitação, validação cruzada por uma perspectiva independente e detecção da transferência de responsabilidade entre papéis.

4. (★★★) No padrão gerenciador, quando vários subagentes trabalham em paralelo, a descoberta de um deles pode tornar inútil o trabalho dos demais — por exemplo, quando um agente já encontrou a resposta em uma tarefa de busca. Projete um mecanismo eficiente de encerramento em cascata para que, “quando um tiver sucesso, todos parem”.

Um subagente envia target_found ao gerenciador, que então transmite terminate a todos. Cada subagente verifica periodicamente o sinal de encerramento em pontos seguros do ciclo ReAct e finaliza após uma limpeza adequada, fechando sessões do navegador, liberando bloqueios e concluindo gravações de arquivos.

5. (★★★) O mecanismo de bloqueio otimista apresentado neste capítulo resolve conflitos de gravação concorrente em um único arquivo. No entanto, em um sistema multiagente real, sistemas de arquivos compartilhados também enfrentam conflitos semânticos entre arquivos, poluição do namespace — com agentes criando arquivos arbitrariamente e desorganizando os diretórios — e pontos únicos de falha — como um agente excluir todos os arquivos por engano. Como você projetaria um mecanismo mais robusto de governança do sistema de arquivos?

Governança por partições: divida o sistema nas quatro áreas da Tabela 10-4 e use scratchpads privados para isolar os espaços de tentativa e erro. Conflitos semânticos: a camada de orquestração deve definir arquivos de bloqueio no nível do diretório e exigir a aquisição desse bloqueio antes de qualquer alteração. Poluição do namespace: estabeleça padrões de diretórios e convenções de nomenclatura. Pontos únicos de falha: use um sistema de controle de versão que permita reverter alterações com base no histórico e restrinja as permissões ao mínimo necessário.

6. (★★★) A colaboração entre agentes baseada em mecanismos de mercado, como Pinchwork e RentAHuman, introduz relações comerciais: um agente paga outro agente — ou uma pessoa — para realizar uma tarefa. Como o agente contratante pode avaliar automaticamente a qualidade dos resultados entregues pelo executor? Se o executor afirmar que concluiu a tarefa, mas o contratante considerar a qualidade insatisfatória, quem arbitrará a disputa? Como impedir que a baixa qualidade expulse a alta qualidade do mercado?

A aceitação não pode se limitar à leitura da trajetória do agente; é preciso usar verificações externas determinísticas, como execução de testes, renderização de capturas de tela e verificações por ferramentas. Explore a assimetria de dificuldade entre geração e verificação para reduzir o custo da aceitação. As disputas devem ser arbitradas por um agente revisor independente, atuando como terceiro, com os recursos mantidos em custódia. Para impedir que a baixa qualidade expulse a alta qualidade do mercado, adote um sistema de reputação baseado no histórico de entregas, vinculando os sinais de preço à qualidade.

7. (★★) O RentAHuman permite que agentes contratem pessoas usando criptomoedas, invertendo a relação tradicional entre seres humanos e máquinas. Se esse modelo se popularizar, que papel os seres humanos desempenharão na economia dos agentes? Eles se limitarão a executar tarefas físicas que os agentes não conseguem realizar?

Os seres humanos farão mais do que executar tarefas físicas que os agentes não conseguem realizar. Também poderão fornecer novas informações que um agente não obteria por meio do raciocínio isolado, incluindo percepções in loco e feedback do mundo real; atuar como responsáveis pela aceitação final e como árbitros de disputas; assumir autorizações e prestar contas como sujeitos jurídicos e responsáveis; definir objetivos e fazer julgamentos de valor; e exercer um papel de equilíbrio em situações de assimetria de informação ou que envolvam limites éticos.

8. (★★) A sociedade humana precisa dividir o trabalho porque as capacidades de cada pessoa são limitadas: quem desenvolve o frontend não necessariamente conhece o backend, e quem trabalha com design pode não entender de operações. Os modelos de grande porte, por sua vez, se aproximam mais de “generalistas”. Pesquisas mostram que, em tarefas de raciocínio puramente textual e com os mesmos recursos computacionais, o debate multiagente não supera um único agente. Qual é, então, a verdadeira vantagem de usar vários agentes em vez de apenas um?

1. Incorporar feedback externo, como resultados de execução e capturas de tela, trazendo informações que não existiam no momento da geração.
2. Vários agentes com objetivos e papéis distintos podem discutir e competir entre si, como membros de uma sociedade humana, ajudando a evitar os pontos cegos de um único agente.
3. O isolamento de contexto entre vários agentes permite superar o limite da janela de contexto e comportar cadeias muito longas de chamadas de ferramentas.

9. (★★★) Este capítulo trata o “contexto compartilhado” e o “contexto não compartilhado” como uma dimensão central do projeto de sistemas multiagente. O contexto compartilhado permite que todos os agentes vejam as mesmas informações, o que, à primeira vista, facilita a coordenação. No entanto, em O Problema dos Três Corpos, o pensamento dos trissolarianos é completamente transparente, mas seu desenvolvimento tecnológico fica estagnado; o experimento mental do clipe de papel também mostra que, quando um grupo converge para o mesmo objetivo, a diversidade desaparece. Em um sistema multiagente, como equilibrar eficiência e diversidade?

O compartilhamento completo amplifica a inércia de pensamento e as cascatas de erros; é o isolamento que produz diversidade cognitiva. Use prompts ou modelos diferentes para criar vieses de pensamento distintos, como em sessões de brainstorming e debates. Além disso, faça os validadores cruzados examinarem apenas as evidências originais, sem acesso ao raciocínio anterior.

10. (★★★) Considere a atribuição de um orçamento de 30 passos e outro de 300 passos a um agente de programação. Como sua estratégia de trabalho deve mudar? Pesquisas mostram que apenas aumentar o orçamento de passos não garante melhor desempenho: os agentes podem “saturar” prematuramente após buscas superficiais. Projete um mecanismo “consciente do orçamento” que permita ao agente implementar rapidamente as funcionalidades essenciais com um orçamento pequeno e acrescentar etapas de planejamento, testes e revisão com um orçamento grande, aproveitando plenamente os recursos computacionais adicionais.

Mecanismo: insira no prompt, a cada passo, o orçamento total e o orçamento restante, ajustando dinamicamente o peso entre exploração e aproveitamento conforme a proporção ainda disponível. Por exemplo, com um orçamento pequeno de 30 passos, ignore o planejamento e a revisão e passe diretamente à implementação das funcionalidades essenciais e à verificação básica. Com um orçamento grande de 300 passos, planeje, implemente, teste e, por fim, revise e aperfeiçoe; use pontos de verificação associados a marcos para avaliar o progresso e evitar a saturação superficial.

11. (★★) A Tabela 10-3 estabelece, linha a linha, uma correspondência entre sistemas multiagente e sistemas operacionais. Acrescente algumas linhas à tabela: a que correspondem, no universo dos agentes, a memória virtual e a paginação, as permissões de arquivos, a detecção de deadlocks e os algoritmos de escalonamento? E quais conceitos dos sistemas operacionais não têm equivalente no universo dos agentes? Por quê?

Possíveis extensões: memória virtual e paginação ↔ compressão e recuperação de contexto — as informações acessadas com frequência permanecem na janela, enquanto as demais são transferidas para arquivos e repositórios de memória e recuperadas quando necessário; permissões de arquivos ↔ listas de ferramentas permitidas, montagens somente leitura e limites de credenciais; detecção de deadlocks ↔ detecção de transferências cíclicas e esperas mútuas — com limites para o número de transferências e tempos limite; algoritmos de escalonamento ↔ processamento assíncrono de eventos, apresentado no Capítulo 4. A ausência de equivalentes decorre de uma diferença no poder de imposição: as instruções de um processo são executadas obrigatoriamente pelo hardware, enquanto um agente segue os prompts apenas com alta probabilidade.