Sobre o projeto

# PilotDeck · Aceitação de subtarefas e reparo local Este é um projeto de melhoria baseado no [OpenBMB/PilotDeck](https://github.com/OpenBMB/PilotDeck) (projeto participante da direção três), com o objetivo de aumentar a qualidade de entrega das subtarefas de agentes de IA. Ao introduzir o módulo `agent.acceptance`, ele adiciona verificação estrutural e revisão independente por modelo ao estado de "conclusão" das subtarefas. ## Funcionalidades principais - **Entrega verificável**: primeiro, as regras do host realizam uma pré-verificação estrutural; em seguida, um modelo independente somente leitura confere a tarefa original, a declaração de entrega e o conteúdo real dos arquivos. - **Reparo com limites**: quando a aceitação falha, o sistema executa reparo local dentro da mesma subtarefa, sessão e escopo de permissões, compartilhando o limite total de rodadas; se esgotado, recusa explicitamente, preservando as subtarefas irmãs já aprovadas. - **Experiência auditável**: grava metadados de aceitação bem-sucedida e recusada na memória white-box nativa, agrupados por modelo real e contrato, preservando o denominador de amostras, mas sem modificar automaticamente os critérios de aceitação. - **Processo verificável**: os cartões nativos de subtarefa exibem o status de aceitação e reparo, incluindo descrição do problema, número de reparos, trajetória de ferramentas e artefatos. ## Instalação e inicialização Requer Node.js **22.13–22.x** e pnpm **10.32.1**. ```bash corepack enable pnpm install --frozen-lockfile npm run build ``` A inicialização normal continua sendo `npm run dev`. Nas configurações nativas, habilitar **Agent → Revisão de entrega** ativa a segunda camada de revisão, permitindo selecionar um modelo separado e ajustar rodadas e tempo limite da revisão. ### Demonstração isolada no local Suporta qualquer modelo compatível com chamada de ferramentas da OpenAI. Configure os parâmetros da demonstração por variáveis de ambiente locais: ```bash node --import tsx scripts/verified-subtasks-native.ts ui --semantic-fault --acceptance-memory ``` Também é possível usar credenciais do Zhipu Coding Plan: ```bash node --import tsx scripts/verified-subtasks-native.ts ui # ou reutilizar credenciais locais do OpenCode node --import tsx scripts/verified-subtasks-native.ts ui --opencode-auth ``` ### Modo de aceitação direta Sem iniciar a interface, aceitar diretamente a mesma cadeia de gateway nativa: ```bash node --import tsx scripts/verified-subtasks-native.ts live --opencode-auth ``` ### Verificação determinística do mecanismo Teste de referência sem credenciais de modelo: ```bash node --import tsx scripts/verified-subtasks-benchmark.ts artifacts/verified-benchmark ``` ## Implementação técnica | Módulo | Melhoria | |---|---| | `src/agent/sub/acceptance/` | Pré-verificação de schema limitado, verificação de artefatos, normalização de problemas, registro de verificadores do host | | `SubAgentSession` / `AgentLoop` | Reparo na mesma sessão, orçamento total de rodadas, propagação de interrupções e erros, uso acumulado | | `agent` / `ToolRuntime` | Passagem de contrato, resultado de aceitação estruturado, recusa como falha real de ferramenta | | Ponte entre gateway e UI nativa | Carregamento de regras do host, configuração do modelo revisor, status de aceitação e reparo, preservação da decisão final | | `AcceptanceMemory.ts` | Ponte de metadados de estado final, deduplicação, estatísticas de denominador, entradas de feedback nativas, compatibilidade com limpeza e organização de arquivos Dream | | `modelReviewer.ts` | Sessão independente somente leitura, evidência de leitura real, herança e substituição de modelo, resultado da revisão e uso | A ativação é explícita: sem o parâmetro `acceptance`, o comportamento original é mantido. O host pode registrar verificadores de negócio; o modelo só pode referenciar nomes. A inicialização nativa carrega regras de artefatos JSON aprovadas por meio de `PILOTDECK_ACCEPTANCE_CONFIG`. ## Memória de experiência de aceitação Após habilitar a memória white-box nas configurações nativas **Agent → Memória**, o registro pode ser controlado por **Agent → Revisão de entrega → Salvar experiência de aceitação na memória do projeto**. A opção de configuração é `memory.captureAcceptance`; quando omitida, o registro é padrão em projetos com memória habilitada; definir como `false` desativa. O observador registra metadados do estado final real de aceitação, sem salvar o corpo da tarefa, o conteúdo da entrega ou comentários em texto livre; as 128 observações deduplicadas mais recentes são armazenadas no SQLite do projeto, e o Markdown de feedback nativo é um resumo derivado. O registro em si não adiciona chamadas de modelo, mas a recuperação nativa e o Dream ainda podem chamar modelos. ## Evidências e limites Este projeto fornece evidências claras de verificação por injeção de falhas, e não estatísticas de taxa de erro natural. Por exemplo, em uma execução nativa real do GLM-5.3, 4/4 entregas passaram, 1 recusa do modelo acionou reparo local, e o hash e o horário de modificação de 3 relatórios bem-sucedidos permaneceram inalterados. Em comparação com a reexecução de todo o lote, a estratégia de reparo local reduziu o volume de requisições em 40%. **Atenção**: este sistema não oferece rollback global, exatamente uma vez para efeitos colaterais externos, coordenação de conflitos em arquivos compartilhados ou recuperação entre processos. A confiabilidade de negócio depende das regras do host e da qualidade da revisão; a revisão por modelo ainda pode cometer erros de julgamento. Entregas de arquivos não serão aceitas pelo revisor se não houver leitura independente bem-sucedida. Comando de teste principal: ```bash node --import tsx --test tests/agent/sub/acceptance/*.spec.ts tests/agent/sub/VerifiedSubagent.spec.ts tests/agent/sub/AcceptanceInvariants.spec.ts tests/agent/sub/ModelReview.spec.ts tests/pilot/config/acceptanceReview.spec.ts tests/tool/VerifiedAgent.spec.ts tests/gateway/VerifiedSubtaskEvents.spec.ts ``` Para mais detalhes, consulte as [instruções da demonstração ao vivo](docs/verified-subtasks/DEMO.zh-CN.md), o [registro de validação](docs/verified-subtasks/VALIDATION.zh-CN.md) e os [detalhes técnicos](docs/verified-subtasks/README.zh-CN.md).