đ§Ź Anatomia de um subagent
Sub-agente Ă© uma sessĂŁo filha com context prĂłprio. Recebe prompt do pai, faz o trabalho, retorna SĂ a resposta final. O context da varredura nĂŁo polui o pai.
As 4 propriedades fundamentais
- Fresh context: começa zerado, não herda histórico do pai
- One-way: pai â filho via prompt; filho â pai via resposta final
- Output synthesis: filho sintetiza, pai sĂł vĂȘ o resumo
- Tool surface: pode ter tools restritas (read-only, p.ex.)
Use case principal: auditar 50 arquivos sem inchar o context principal. Subagent lĂȘ tudo, devolve punch list de 20 linhas.
đ Criando no Claude Code (markdown)
Arquivo .claude/agents/nome.md. Comando /agents abre wizard interativo.
---
name: dead-code-audit
description: Use quando o usuårio pedir auditoria de código morto, imports não usados, ou funçÔes órfãs
tools: [Read, Grep, Bash]
---
VocĂȘ Ă© um auditor de cĂłdigo morto.
Quando invocado, faça:
1. Liste todos os arquivos .ts/.tsx em src/
2. Para cada um, identifique imports não usados e funçÔes sem caller
3. Retorne markdown com tabela: arquivo | tipo | item | severidade
4. MĂĄximo 30 linhas total. Priorize por severidade.A description com "Use quando..." Ă© o que faz o Claude saber DISPARAR esse agent automaticamente. Especificidade aqui paga.
âïž Criando no Codex (TOML)
Arquivo .codex/agents/nome.toml (projeto) ou ~/.codex/agents/ (pessoal). Mais campos opcionais.
name = "dead-code-audit"
description = "Audita cĂłdigo morto em src/"
model = "gpt-5"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"
nickname_candidates = ["audit", "cleanup", "dead"]
developer_instructions = """
VocĂȘ Ă© um auditor de cĂłdigo morto.
Quando invocado:
1. Liste arquivos .ts/.tsx em src/
2. Identifique imports não usados, funçÔes sem caller
3. Retorne tabela: arquivo | tipo | item | severidade
4. MĂĄximo 30 linhas. Priorize por severidade.
"""Campos opcionais Ășteis
modelâ usa modelo diferente do default (gpt-5 vs gpt-5-pro)model_reasoning_effortâ "low" | "medium" | "high"sandbox_modeâ "read-only" | "workspace-write" | "danger-full-access"nickname_candidatesâ apelidos pra invocar mais rĂĄpidomcp_serversâ MCPs especĂficos pra esse agent
đŻ Auto-invocação (Claude) vs spawn (Codex)
Diferença fundamental que muda como vocĂȘ escreve a description.
Claude â automĂĄtico
Agente principal decide invocar baseado em description.
â Claude vĂȘ o trigger, invoca dead-code-audit automaticamente
â ïž Se description nĂŁo trigger â agente principal faz inline (e poluĂ context).
Codex â explĂcito
Subagent sĂł roda com comando spawn.
"spawn audit no src/" (via nickname)
â ïž Esqueceu o spawn? Codex faz inline e poluĂ context.
đą max_threads e max_depth (Codex)
Codex impĂ”e limites duros que forçam vocĂȘ a planejar fan-out:
# .codex/config.toml
[agents]
max_threads = 6 # paralelos mĂĄximos (default)
max_depth = 1 # subagent NĂO pode criar subsubagent (default)â PadrĂ”es que funcionam
- Fan-out 6 subagents auditando 6 ĂĄreas em paralelo
- Pai sintetiza 6 outputs
- Trabalho horizontal e independente
â PadrĂ”es que quebram
- Subagent criando subsubagent (recursĂŁo)
- Mais de 6 paralelos (vai fila)
- DependĂȘncias entre subagents
Claude nĂŁo documenta limites equivalentes â entĂŁo Codex Ă© mais previsĂvel pra workflows com fan-out. Lado bom de ser explĂcito.
đ Receita: subagent narrow
Os melhores subagents seguem a receita:
1 trabalho claro
"Audita dead code" â claro. "Helper" â nĂŁo claro.
Tool surface que combina
Auditor sĂł precisa Read + Grep. NĂŁo dĂȘ Bash/Write se nĂŁo for usar.
Output schema previsĂvel
"Retorne tabela markdown de atĂ© 30 linhas" â o pai sabe o que vai receber.
Anti-drift explĂcito
"NĂO refatore, apenas reporte" â limita o escopo. SenĂŁo o subagent começa a corrigir o que viu.
đ Resumo
PrĂłximo:
3.2 â Forças e limitaçÔes: qual usar pra cada task