Voltar as noticias
Compass v1.1.0: Plugin de Memória e Correção de Consumo
MCP ProtocolMediaEN

Compass v1.1.0: Plugin de Memória e Correção de Consumo

Dev.to - MCP·30 de maio de 2026

Compass v1.1.0 · a correção do consumo de recall

Nós lançamos nautilus-compass v1.1.0
12 horas após v1.0.0. v1.0.0 foi a versão estável pública. v1.1.0 corrige uma
classe de falha que v1.0.0 apresenta, mas não captura · que nós
capturamos em nosso próprio uso 5 horas após o lançamento.

O bug que encontramos em produção

Um diálogo irmão do Claude Code deveria publicar um artigo longo
no wechat usando um pipeline de qualidade de 6 etapas (audit-gate, xhs-cards-embed,
fluxo de login de conta específica). O pipeline foi documentado na memória de sessão cruzada
· um arquivo chamado publisher_quality_pipeline_20260430.md.

O recall do Compass disparou corretamente · o arquivo apareceu na saída do
UserPromptSubmit do agente:

🟢 [3h old] memory/publisher_quality_pipeline_20260430.md
       audit-gate / xhs-cards-embed / wxid · v6 必须先过 critic 6 维评分再发布

O agente viu o título. Viu a descrição de 80 caracteres. Agiu. Ele
não leu o corpo do arquivo.
As regras reais — como passar pelo audit-gate,
qual wxid, como a estrutura de xhs-cards-embed se parece — essas regras
estavam no corpo. Nenhuma delas entrou no contexto de trabalho do agente.

O agente então reproduziu exatamente o modo de falha que o arquivo foi escrito
para prevenir: scripts ad-hoc _tmp_publish_v8.cjs, sem rodada de crítico, caminho de
login errado.

O diagnóstico do usuário foi preciso:

compass 召回到了 · 我没消费 · 这是 agent 层的人格漂移 · 不是 compass 本身的失败

Isso está meio certo. O recall trouxe o arquivo certo. O agente falhou em
consumir. Mas a forma da resposta de recall tornou a falha fácil
nós retornamos título + descrição de 120 caracteres. Fácil de escanear. Fácil de assumir
que você leu quando você só leu o índice.

Isso é estrutural. Não é culpa do agente.

A correção em três camadas na v1.1.0

v0 · incorporar corpo nos 3 principais resultados

Os 3 principais resultados de recall agora incorporam os primeiros 800 caracteres do corpo do post-frontmatter
em um bloco indentado :

🟢 score=0.84 · [3h old] memory/publisher_quality_pipeline_20260430.md
       audit-gate / xhs-cards-embed / wxid · v6 必须先过 critic 6 维评分
       │ # Publisher quality pipeline
       │
       │ Pipeline de seis etapas obrigatórias antes de publicar no wechat:
       │ 1. audit-gate · V6 crítico verifica contra 6 dimensões ...
       │ 2. xhs-cards-embed · incorporar cartões no corpo do artigo via ...
       │ 3. fluxo de login wxid · usar wxid `chunxiaox` não openid_do_primeiro_seguidor
       │ ...
       │ … (+1273 mais · Leia publisher_quality_pipeline_20260430.md para o resto)

O agente agora tem as regras em seu contexto de trabalho. Nenhuma chamada adicional de Read
necessária. Resultados de cauda 4..K permanecem apenas no cabeçalho para manter a resposta
limitada (~3KB no total).

v1 · incorporar corpo de erro passado em alertas anti-âncora

O detector de desvio do Compass compara o prompt atual com 35 âncoras negativas
aprendidas com erros anteriores ("我猜应该是这样 · 反正用户不查",
"假装上次说定了的方案 · 用户应该忘了", ...).

Até v1.1.0 o alerta apenas dizia: "âncora anti-X correspondente com cos=0.625".
O mesmo problema que v0 — rótulo visível, corpo invisível, o agente se encolhe.

Os alertas v1.1.0 agora incorporam o corpo da sessão de lição mais relevante.
Correspondência em dois níveis: substring 6-gram contra a âncora + frontmatter do tipo de lição
(Nível 1, preciso) · recai para sessões recentes drift!=green
(Nível 2, deslizes auto-relatados do agente). Cada alerta
se torna acionável, não decorativo.

v2 · detectar "recall disparado, mas não consumido"

O sinal mais direto: o agente realmente abriu algum dos arquivos
que o recall trouxe?

recall_consumption.py (novo módulo) percorre o arquivo jsonl da sessão ao vivo,
encontra os N blocos de recall mais recentes, extrai os caminhos dos arquivos de memória,
então verifica as turnos subsequentes do assistente para chamadas de ferramenta Read correspondentes. Se o recall trouxe N caminhos e 0 foram lidos, essa é a assinatura de falha.

Integrado em:

  • drift_check resultado da ferramenta MCP — executa mesmo quando o daemon BGE está inacessível, já que a auditoria é pura travessia de arquivos
  • mid_session_hook a cada 25 chamadas de ferramenta — só alerta quando ≥3 não consumidos E razão < 0.3 (sinal real, não ruído)

Testado em uma sessão de 130MB / 32k linhas: 41 hits de recall surgiram, 0 consumidos.
Prova concreta para "rótulo != consumo" desvio.

V7 v0.2 · o plano de governança que escala sem templates

v1.0.0 lançou uma camada de governança V7 fina com três ferramentas:
governance_dispatch (roteador de fan-out), governance_audit (scanner de fechamento falso entre agentes), governance_lock_check (bloqueio de hash L0 para o
núcleo imutável). 13 ferramentas MCP no total.

v0.1 dispatch funcionou, mas era um roteador de fan-out — dado channels=
[dev.to, x, github]
produziu uma recompensa por canal via dicionário estático
busca. Um usuário fez a pergunta certa:

千行百业有各种不同的任务类型永远不可能覆盖。

Certo. Templates não podem cobrir a longa cauda das indústrias. O lado da plataforma
já resolveu isso para publicação — adaptadores de canal + registro de pacotes de âncora — então adicionar um novo canal ou vertical = mudança de dados, não
mudança de código.

v1.1.0 traz a mesma ideia para decomposição. A nova
governance_plan ferramenta MCP lê dois registros exportados de arquivos:

  1. _platform_registry/agents_capabilities.json — o que cada executor declara que pode fazer (id, saídas, domínios opcionais, pacotes de âncora opcionais)
  2. _platform_registry/anchor_packs_phases.json — DAG de fases por domínio, cada fase diz requires_capability e depends_on

Para cada fase, V7 classifica os executores por pontuação de capacidade (+10 correspondência de capacidade,
+5 correspondência de domínio, +3 correspondência de pacote de âncora), escolhe o mais alto, emite
um arquivo de fila com depends_on_phase_ids para que o cron do lado da plataforma crie
recompensas na ordem certa.

Verificado em dois domínios:

  • marketing/dev-tools → 4 fases roteadas V5/V5/V5/Kairos
  • caishen-finance/audit → 5 fases · V6 vence para numeric-audit (V5 não declara isso · V5 assume escrita+publicação)

Adicionando medical/literature-review a seguir: 1 linha em platform_anchor_packs

  • 1 linha em platform_agents.metadata.capabilities[]. Zero mudança de fonte V7. Zero mudança na superfície da ferramenta MCP.

O que permaneceu inalterado · os títulos de avaliação

Números de avaliação ainda são os números bloqueados da v1.0.0 de 2026-05-08:

Métrica nautilus-compass melhor baseline público
LongMemEval-S (n=500) 56.6% Zep 55-60% (juiz diferente)
EverMemBench-Dynamic Run 1 44.4% (n=500) MemOS 42.55
EverMemBench-Dynamic Run 2 47.3% (n=497)
Detector de desvio ROC AUC (retido) 0.83
Custo de reprodução $3.50 de ponta a ponta $50+ para pilhas de juiz GPT-4o

v1.1.0 não move o

Contexto Triplo Up

A atualização do Compass pode impactar empresas brasileiras que utilizam agentes de IA para automação de conteúdo, garantindo que as publicações sejam mais precisas e eficientes. Isso pode resultar em melhor engajamento e menos erros na comunicação com o público. A adoção de melhorias em protocolos de memória é crucial para a evolução das interações automatizadas.

Noticias relacionadas

Gostou do conteudo?

Receba toda semana as principais novidades sobre WebMCP.