Aula 12 · cooperação

Agentes diferentes não devem pegar a mesma árvore.

"Isolar por diretório, coordenar por ID de tarefa." Dois aviões não interferem um no outro.

⏱ ~10 min · 📝 3 componentes interativos · 🧑‍💻 Baseado em shareAI-lab · s12_worktree_task_isolation.py

Um problema difícil com agentes paralelos

s09-s11 permite que você inicie vários companheiros de equipe ao mesmo tempo, mas há uma armadilha: Eles estão todos no mesmo diretório de trabalho. Alice está alterando auth.py e Bob também está alterando auth.py ao mesmo tempo - conflitos de git, confusão de arquivos e contaminação mútua de testes.

A solução para s12 é git worktree: no mesmo warehouse, você pode fazer check-out de diferentes ramificações em diretórios diferentes por meio de git worktree add. Cada agente obtém sua própria árvore de trabalho e trabalha em seu próprio diretório, invisíveis entre si.

my-repo/ # Espaço de trabalho principal (para lead)
.worktrees/
  alice-auth/ #diretório de isolamento de alice
    (ramo: wt/alice-auth)
  bob-api/ #diretório de isolamento do bob
    (ramo: wt/bob-api)
  index.json # registro da árvore de trabalho
  events.jsonl #Registro de eventos do ciclo de vida

Divisão do trabalho em dois planos

s12 Divida explicitamente o sistema em dois planos:

  • Plano de controle: arquivo JSON em .tasks/. Tarefa é uma unidade abstrata de "o que fazer", incluindo dependências, proprietário e status.
  • Plano de execução: diretório em .worktrees/. Worktree é o contêiner físico de "onde fazer", um diretório + uma ramificação.

Os dois são vinculados bidirecionalmente por meio de task.worktree e worktree.task_id.

Esse tipo de desacoplamento permite: Reutilizar o mecanismo de gerenciamento de tarefas, mas alterar o ambiente de execução (por exemplo, não git worktree, mas docker container). Ou altere o mecanismo de tarefa, mas reutilize a árvore de trabalho (por exemplo, não um arquivo JSON, mas um banco de dados).

demonstração do ciclo de vida

Veja tudo abaixo: criar tarefa → criar árvore de trabalho → executar comandos → manter ou remover. Cada etapa possui um registro de log de eventos (events.jsonl), que é usado para observabilidade na produção.

keep vs remove

Existem dois finais quando o worktree completa sua missão:

  • remove: git worktree remove --force, exclua o diretório. Os galhos também são geralmente limpos. É equivalente a “Não quero mais essa exploração”.
  • keep: marque apenas status: mantido em .worktrees/index.json e o diretório físico será mantido. É equivalente a "Vou conseguir esse resultado, espere até mesclá-lo".

Modo comum: o subagente executa um refator experimental → executa com bons resultados → manter → revisão humana → mescla no branch principal → remove manualmente. Efeito ruim? Basta remover e jogar fora.

Interativo

Widget 1 · Ciclo de vida · Desde criar tarefa até manter/remover

Acione 5 eventos em etapas. Observe o status do disco à esquerda (.tasks/ + .worktrees/) e o log de eventos (events.jsonl) à direita.

磁盘状态
events.jsonl(append-only)
Interativo

Widget 2 · Pistas Paralelas · 3 agentes em 3 árvores de trabalho simultaneamente

alice/bob/charlie modifica o mesmo arquivo em diferentes árvores de trabalho ao mesmo tempo. Eles são visíveis um para o outro? Haverá um conflito?

📂 .worktrees/alice/
📂 .worktrees/bob/
📂 .worktrees/charlie/
Interativo

Widget 3 · Fluxo de decisão · Escolha o próximo passo certo para cada etapa

Quando um agente em Produção conclui o trabalho na árvore de trabalho, ele deve ser mantido ou removido? 5 cenas.

答对 0 / 5