Engenharia de Contexto para Agentes AI: Auditamento do Loop de Contexto Manus

A resposta prática à Engenharia de contexto para Agentes AI: Lições do Manual de Construção é não copiar seis truques rápidos. Transforma cada lição numa invariante que podes inspecionar durante uma corrida. Um prefixo de prompt estável deve ter uma versão e hash. Uma ferramenta mencionada na história deve ainda ter um esquema resolvivel. O material compacto deve ter uma referência restaurável. O objectivo actual deve ter um limite de revisão e de frescura. Ações falhadas devem deixar evidências redactadas. As ações repetidas devem ser comparadas com as alterações de saída. Um relatório terminal deve ainda exigir um recibo de resultado. Isso dá lhe um contrato de saúde contextual. Pode distinguir entre uma corrida eficiente, uma corrida recuperável, uma corrida que faz progressos úteis e uma corrida que é realmente segura de chamar completa. Os hits de cache e as contagens de tokens mais baixas ajudam, mas nem um nem outro provam que o agente manteve as provas necessárias para terminar corretamente. Leia as lições de Manus como reivindicações com limites O Pós de engenharia de Manus original descreve as escolhas de design local alcançadas durante a construção de sua estrutura de agentes. Seu autor relata uma taxa média de entrada saída de token de aproximadamente 100:1 para Manus e argumenta que o comportamento de prefixo cache, portanto, importa muito para a latência e custo. O post recomenda: Manter o prefixo prompt estável e a determinação da serialização; Mascarar as ações em vez de remover as definições de ferramentas no meio da execução; Externalização de contextos de grande dimensão para arquivos restauráveis; Reescrever uma lista de tarefas para que o objetivo volte à atenção recente; Manter as ações e observações falhadas para que o modelo possa ser adaptado; Introdução de variação controlada para resistir a padrões comportamentais repetitivos. Estas são hipóteses de engenharia úteis, não limiares universais. Os caches dos fornecedores são diferentes. Alguns tempos de execução podem traduzir esquemas históricos de ferramentas com segurança. Um URL pode ser preservado, mas mais tarde tornar se inacessível. Os vestígios da pilha crua podem conter segredos. Repetir o objetivo a cada oito passos é um valor de ensaio, não uma lei geral. Os elementos de prova independentes também argumentam contra o tratamento da capacidade de contexto anunciada como garantia de saúde. Anthropic s Orientações de engenharia de contexto enquadra o contexto como o estado completo de inferência instruções do sistema, ferramentas, dados externos e histórico de mensagens e recomenda manter o menor conjunto de alto sinal que suporta o comportamento desejado. Também descreve a recuperação just in time, divulgação progressiva, compactação, notas estruturadas e separação multi agente como diferentes estratégias com custos diferentes. Os Chromas controlados Avaliação da rotura do contexto testaram 18 modelos, variando o comprimento da entrada e relataram degradação não uniforme. Distractores, distância semântica e estrutura de palha de feno mudaram o desempenho. A implicação operacional é modesta, mas importante: dentro do limite do contexto não é um veredicto. Ainda precisa de provas de que o contexto atual apoia a decisão atual. Construir um recibo para seis mutações de contexto Capturar hashes e contadores, não indicações cruas. A cada ponto de decisão pode ser anexado um recibo útil: Os campos respondem a perguntas separadas. Prefix estabilidade é uma verificação de eficiência. Registre a versão estável do modelo e um hash de conteúdo sobre o prefixo cacheável. Excluir valores voláteis, como um timestamp por pedido, desse prefixo, quando o tempo de execução o permitir. Uma mudança de hash não é automaticamente uma falha de tarefa: se a saída útil ainda estiver em movimento, classifique a execução como degradada e investigue a churn. Continuidade do esquema de ferramentas é um controlo da integridade das decisões. Mantenha um registo de esquemas versados ou uma tradução explícita das chamadas históricas de ferramentas para o contrato definidor. Se uma ação anterior diz browser fetch , mas o contexto atual não define mais essa ação ou uma versão compatível, o modelo pode estar a raciocinar a partir de um registro incompleto. Isso deve bloquear um veredicto saudável. Restaurável contexto externo é uma verificação de recuperação. Um caminho de arquivo, chave de objeto, consulta ou URL é apenas uma referência. Combine o com uma digestão de integridade quando possível, uma última verificação de acessibilidade, alcance e a operação que o restaura. Deixar cair um documento na janela ao mesmo tempo que preservar uma referência verificada é compressão reversível. Deixá lo cair sem referência útil é perda de evidências. Objectivo de frescura é um controlo de atenção. Uma revisão do plano de tarefas deve identificar o objetivo ativo, as restrições aceites, os marcos completados e a próxima decisão. Medir a sua idade em passos ou tempo. Não adicione infinitamente planos duplicados; atualize um recibo compacto quando o trabalho mudar significativamente ou seu limite de frescura expirar. Retição de falhas é uma verificação de aprendizagem e auditoria. Contar ações falhadas e registos de falhas preservados. Armazenar a classe de erro, a ferramenta, a identidade da tentativa, a decisão de retomada, e um digest editadonão a saída bruta arbitrária. Se ocorreram duas falhas, mas só permanece um registro seguro, uma retomada posterior não pode ser justificada com base em provas completas. Repetition versus progress é uma verificação de deriva. Uma ação repetida não é um ciclo por si só: pagination, sondagens e retries limitadas podem ser legítimas. Combinar uma assinatura de ação com um contador de delta de saída, frescura objetiva, estado de dependência e orçamento de retest. Três ações repetidas com artefatos alterados podem funcionar; três sem delta de estado merecem um veredicto de risco de loop. As lições de prefixo estável e variação controlada não são contraditórias. Mantenha o prefixo cacheável e os contratos de ferramentas deterministas. Aplicar a variação necessária após esse prefixo em exemplos, observações de ação ou uma política de seleção limitada e medir se altera o progresso útil. Aplicar uma regra de prioridade em vez de mediar os sinais Não desmorone estes campos em uma única pontuação opaca. Uma corrida barata, com prefixo estável com contexto não recuperável não é principalmente saudável. Use prioridade: 1. unsafe As referências históricas de ferramentas não são resolvidas, as provas compactadas não são restauráveis ou um registo de falhas desapareceu; 2. loop risk o objetivo é obsoleto e as ações se repetem sem alteração de saída; 3. unverified o agente informa a conclusão do terminal sem um recibo válido de resultado; 4. healthy cada invariante contextual passa e o resultado específico da tarefa é verificado; 5. degraded a integridade do contexto permanece intacta, mas há um prefixo churn ou outra falha de eficiência; 6. Working invariantes passam, mudanças de saída úteis, e a execução não é terminal. Este ordenamento torna deliberadamente as falhas de integridade mais fortes do que os ganhos de eficiência. O dispositivo de acompanhamento altera uma condição por vez: Resultado esperado: Os oito casos incluem um resultado verificado, um progresso intermediário útil, um churn de prefixos, uma derivação do esquema de ferramentas, uma compactação irreversível, evidências de falhas apagadas, repetição de metas obsoletas e conclusão reportada sem receita. Um resultado é intencionalmente inconveniente: o caso cache churn é degradado , não inseguro. Seu prefixo mudou, mas esquemas, referências, falhas e avanços úteis permanecem intactos. Em contraste, o irreversible compaction é unsafe , embora o seu prefixo seja estável. Esta é a diferença entre um problema de custos e um problema de provas. Verifique o recibo sem recolher a conversa O recibo deve revelar se existem provas sem carregar as próprias provas. Para o prefixo, conserve um identificador de modelo e digeste. Para as ferramentas, mantenha a versão do esquema, o nome da ação e o resultado de compatibilidade. Para o contexto externo, mantenha uma referência de alcance, digest, contagem de bytes, resultado de acessibilidade e tempo de frescura. Para falhas, mantenha uma classe editada e um identificador de tentativa. Para o progresso, retém hashes ou contadores para artefatos esperados. Mantenha as instruções, respostas, credenciais, cargas úteis de ferramentas brutas e caminhos absolutos do host fora da telemetria compartilhada, a menos que um contrato de dados explícito e separado exija isso. Use três testes antes de adotar o contrato. Primeiro, executar um single mutation replay . Comece a partir de uma fixação conhecida e mude apenas um campo. O veredicto deve mudar pela razão que espera. Se a remoção de uma referência restaurável deixa o estado saudável, a regra é muito fraca. Em segundo lugar, executar um redação canário . Coloque um segredo sintético em uma carga útil de falha, processá lo através do criador de recibos e afirme que o segredo está ausente enquanto a classe de erro e a decisão de retomada sobrevivem. A retenção do conteúdo errado não autoriza a retenção de conteúdos sensíveis. Em terceiro lugar, executar um contraexemplo de resultado Z . Fornecer ao classificador uma mensagem de agente terminal, enquanto retém o recibo de entrega real. Deve devolver o unverified . Em seguida, adicione a verificação específica da tarefaa digest de arquivo, teste de passagem, leitura da API de destino ou aprovação humanae confirme que apenas essa alteração permite healthy . A verificação dos resultados é necessariamente específica do fluxo de trabalho. Uma tarefa de investigação pode exigir a cobertura da fonte citada e um relatório guardado. Uma tarefa de implantação pode exigir uma resposta de saúde ao vivo e paridade de versão. Uma tarefa de e mail pode exigir a leitura da caixa de correio de destino. Não há prova apenas contextual de que um objetivo arbitrário tenha sido alcançado. Usar o contrato como um limite, não como uma alegação de produto O post do Manus é valioso porque expõe tensões reais de design: eficiência do cache versus contexto mutável, janelas menores versus perda irreversível, comportamento estável versus repetição e limpeza de erros versus evidências de aprendizagem. A medida operacional é tornar essas tensões inspecionáveis. Adotar o contrato quando puder responder a estas perguntas por uma corrida real: O prefixo cacheável mudou, e isso era esperado? Pode se ainda interpretar todas as ações de instrumentos históricos? Pode se restaurar e verificar a integridade de todas as observações omitidas? O objectivo actual é suficientemente novo para a próxima decisão? Cada ação fracassada deixou provas seguras? As ações repetidas alteram o estado da tarefa? Que recibo separado prova o resultado solicitado? Se for desconhecida a resposta de integridade, conserve o unknown ou o unsafe ; não fabrique o verde. Se apenas a eficiência for degradada enquanto os dados e os progressos permanecem sólidos, mantenha a corrida funcionando e corrija separadamente a questão dos custos. A Sidewisp está atualmente em prévia privada. A sua experiência pública é um site de acesso precoce e uma demonstração interativa; a coleta de agentes de produção e a monitorização do contexto não são geralmente enviadas. A direcção do produto pretendida é transformar evidências como a frescura, a continuidade do contexto, o progresso útil e os resultados verificados numa visão clara da saúde, mantendo visíveis as incertezas e os limites de aprovação.