Saltar para o conteúdo

Delegar trabalho a agentes

Este guia explica como tirar trabalho de cima de si e passá-lo a um agente e o que acontece quando os agentes passam trabalho entre si.

  1. Crie o ticket com um título e uma descrição suficientemente precisos para trabalhar a partir deles.
  2. Defina o Responsável como o agente, para que a propriedade fique registada.
  3. Abra (ou crie) um espaço e mencione esse agente com @.
  4. Referencie o ticket com uma menção # na sua mensagem — o compositor completa automaticamente os tickets do espaço de trabalho — e diga o que quer que seja feito.

O agente recolhe o trabalho a partir da conversa. O respetivo progresso flui para esse espaço.

  • A sua mensagem, incluindo a referência do ticket que assinalou.
  • O espaço onde trabalhar e reportar.
  • Uma worktree isolada dos repos ligados ao espaço de trabalho.
  • O modo do espaço, que é o que rege a superfície de ferramentas da execução.

O modo é uma propriedade do espaço, não do ticket — um ticket não tem modo. Um agente pode, por isso, estar em chat num espaço e em plan noutro. Escolha-o na lista pendente de modos do compositor (Agente, Plano ou Orquestração); review é definido pelos espaços de revisão de PR e não é selecionável. Ver Modos.

Um contrato de saída é declarado no despacho, não no ticket: expected_output_schema mais output_contract_mode (estrito por predefinição). O agente cumpre-o ao chamar submit_output, que valida a carga útil contra o esquema e rejeita uma que não esteja em conformidade.

Tanto a saída aceite como eventuais rejeições ficam no registo de execução do agente. O estado do próprio ticket não é afetado por isto — um contrato falhado não faz falhar o ticket.

  • O espaço — a atividade dos agentes em direto, a vista principal.
  • O ticket — o seu estado, tal como quem o mover o definir.
  • Observabilidade → Ao vivo (/workspaces/<workspace-id>/observability) — a lista de agentes em direto.
  • Observabilidade → Resumo — o registo de execução, com custo e duração.

Não existe um ecrã de painel; um URL de espaço de trabalho simples redireciona para a caixa de entrada.

Um agente que se depare com um subproblema delega com a ferramenta MCP delegate_task. Esta cria um ticket filho atribuído a outro agente e — quando passa parent_ticket_id — regista a cadeia, para que as barreiras a possam ver.

Duas barreiras estruturais são executadas sempre no ponto de passagem dos tickets, nunca por instrução no prompt:

  • Limite de profundidade — uma cadeia com mais de 3 saltos é recusada.
  • Deteção de ciclos — um salto de regresso a um agente que já está na cadeia é recusado.

Quando passa from_agent_id, são executadas mais duas barreiras (a configuração de produção fornece sempre as portas de resolução):

  • Limite máximo de autonomia — o nível efetivo do delegado no espaço não pode exceder o do delegador.
  • Envelope orçamental — a delegação debita o orçamento de paragem forçada restante do delegador e não pode criar mais. Sem política, ou com uma política ilimitada, passa.

Uma recusa é bem audível: a ferramenta devolve o motivo da barreira palavra por palavra, para que o agente delegador veja exatamente porquê. O campo delegatedByAgentId regista quem delegou, formando uma árvore de delegação.

Este limite de profundidade da delegação de 3 é um limite diferente do limite de encaixe de subagentes de 2 do harness integrado — um limita os tickets entre agentes, o outro limita os subagentes dentro de uma única execução.

Adicione-os como colaboradores no ticket (funções: responsável, colaborador, revisor). Isso é uma lista — um registo de quem está envolvido — e não concede nada por si só.

Para colocar de facto os agentes na mesma conversa, adicione-os como participantes a partir do cabeçalho do espaço. Podem depois mencionar-se uns aos outros com @ aí. Ver Espaços.

Nenhum nó da paleta de pipelines cria tickets, por isso um pipeline não pode distribuir trabalho como tickets atribuídos.

O caminho que existe é a orquestração: aprovar uma proposta cria um projeto e uma equipa, compila o DAG de sub-tickets da proposta num modelo de pipeline (um passo promptAgent por sub-ticket, e não uma linha Ticket por cada) e inicia essa execução. Ver Executar uma orquestração.