9步编排Claude Code智能体集群：如何让1个主管Agent协调10个子Agent并行工作

You give Claude one instruction. Ten agents start working at once. Twenty minutes later you come back to ten finished branches, each one already tested and reviewed.

That's not a fantasy setup or a third-party tool. It's a built-in Claude Code pattern called Dynamic Workflows, where a single lead agent can plan and fan out tens, even hundreds, of parallel subagents in one session, with a grader sending each one back to revise until its result clears the bar.

The catch: spin up ten agents wrong and you get ten conflicting diffs, a polluted context, and more time merging the mess than you saved running it. The difference between a swarm that works and a swarm that fights itself is the loop the lead runs. Here are the 9 steps.

A swarm only helps if the work splits into independent pieces.

This is the step that decides whether the swarm helps or hurts. Subagents pay off when a task naturally breaks into pieces that don't depend on each other: documentation per module, a migration across many independent files, a benchmark across dozens of combinations. If the pieces are tangled together, ten agents will just step on each other.

GOOD SWARM TASKS vs BAD ONES
Good: "Generate docs for all 12 modules" (each module is independent)
Good: "Migrate 30 files from the old API to the new one"
Bad: "Build one feature where every layer depends on the last"
Rule of thumb: if you can't name 3+ genuinely independent pieces, use one agent

✓ You only summon the swarm when the work truly splits apart

The lead breaks the job into atomic subtasks before spawning anyone.

The lead agent's first job isn't to spawn workers, it's to decompose. It splits the task into discrete subtasks, each with clear inputs, outputs, and acceptance criteria. Good subtasks are atomic: bounded files, a clear deliverable, and independently verifiable. This decomposition is what makes the parallelism safe.

ASK THE LEAD TO DECOMPOSE
"You are the lead. Decompose this task into independent
subtasks. For each: the files it owns, its exact deliverable,
and how to verify it's done. Do NOT spawn anyone yet.
Show me the decomposition first."

✓ The job is now a set of clean, independent units, not one blob

Review the decomposition. Wrong dependencies here become merge hell later.

This is your one human checkpoint, and it's the most important one. The decomposition plan determines what runs in parallel. If the lead got a dependency wrong, two agents will edit the same thing and you'll get integration conflicts. Always read the plan before approving the dispatch.

What to check in the plan:Do any two subtasks touch the same files? (They shouldn't.) Is each deliverable independently verifiable? Are the dependencies right? Fixing the plan now costs one message. Fixing a tangled merge later costs an hour.

✓ You catch bad dependencies before they turn into merge conflicts

Isolation is what stops ten agents from overwriting each other.

If your subagents write files in parallel, they need isolation or they'll clobber each other. Git worktrees give each agent its own checkout on its own branch, so they can all work at once without touching the same working directory. When each finishes, its branch is ready to merge cleanly.

ISOLATE EACH AGENT
# add to each subagent's frontmatter
isolation: worktree

# Claude Code provisions a fresh worktree per agent
# and cleans it up automatically when the agent finishes
# ten agents, ten branches, zero file collisions

✓ Ten agents work simultaneously without ever touching the same file

Now the lead dispatches the workers, in parallel.

With the plan approved and isolation set, the lead dispatches. For a handful of agents, the lead spawns subagents directly. For a job that fans out wide, Dynamic Workflows lets the lead plan and run tens to hundreds of subagents in a single session. Each runs in its own context window and reports only its result back, so the lead's context stays clean for coordination.

DISPATCH THE SWARM
"Plan approved. Dispatch one subagent per subtask, in
parallel, each in its own worktree. Each agent gets only
the context it needs and returns a single result summary.
Don't merge anything until every agent reports back."

The sweet spot:Three to five concurrent agents is the right size for most everyday work. Push to tens or hundreds only when the task genuinely fans out wide (a benchmark suite, edits across many independent files). Beyond the sweet spot, you spend more time merging summaries than you save.

✓ The whole swarm is now working at once, each in isolation

No worker's output folds back in until it clears your non-negotiables.

Ten agents means ten chances for something to slip through. A SubagentStop hook runs the moment a subagent finishes and enforces your non-negotiables before the lead is allowed to fold the result back in: tests pass, no secrets in the diff, no out-of-scope file writes. It's deterministic, so it checks every single agent, not most of them.

.claude/settings.json // GATE EACH AGENT
{
  "hooks": {
    "SubagentStop": [{
      "command": "npm run test && npm run lint"
    }]
  }
}

# every subagent's work is checked before it can merge
# one bad agent can't quietly poison the result

✓ Every worker's output is verified before it's allowed near your main branch

A separate grader scores each result and forces a revision if it misses.

This is the part that turns a swarm from "fast but sloppy" into "fast and good." A separate grader scores each subagent's result against a rubric and sends any that miss the bar back to revise, automatically, until they pass. You define what "good" looks like once, and the swarm self-corrects toward it without you reviewing all ten by hand.

SET THE BAR
"Grade each subagent's result against this rubric:
- tests for the change exist and pass
- follows the conventions in CLAUDE.md
- no TODOs or placeholder code left behind

Send any result that misses the bar back to its agent to
revise. Repeat until every result passes."

✓ Weak results get revised automatically instead of landing on you

The lead is the integration layer. Workers never integrate their own work.

Here's a mistake that wrecks swarms: asking the subagents to integrate their own work. Do that and you get duplication and conflicts. The lead is the integration layer. It collects the graded, passing results and merges them in a controlled order, exactly like a tech lead assembling work from a team rather than each engineer pushing to main on their own.

LEAD-ONLY MERGE
"Only you, the lead, merge. Collect the passing branches and
integrate them in dependency order. After each merge, run the
full test suite before taking the next one. Stop and tell me
if any two results conflict instead of guessing."

✓ One agent owns integration, so the merges stay clean and ordered

Wrap the entire loop so you trigger the swarm with a word.

Once the loop works, package it. Claude Code already ships a batch skill that splits one large change into many worktree-isolated subagents that each open a pull request, and you can wrap your own version of this 9-step loop into a reusable skill or slash command. Set it up once, and "run the swarm on this" becomes a single trigger.

.claude/skills/swarm/SKILL.md // YOUR LOOP, ONE TRIGGER
# /swarm : decompose, isolate, dispatch, grade, merge
1. Check the task genuinely fans out
2. Decompose into independent subtasks
3. Show me the plan, wait for approval
4. Give each agent its own worktree
5. Dispatch the swarm in parallel
6. Gate each result with the SubagentStop hook
7. Grade against the rubric, revise the weak ones
8. Lead merges the passing results in order

✓ The whole 9-step swarm now runs from one command

Anyone can spawn ten agents. The reason most people's swarms produce chaos is that they skip the structure: no decomposition, no isolation, no grading, no single integrator. Ten unmanaged agents is just ten ways to create a merge conflict. The loop is what turns a crowd into a team.

• Decomposition plus your approval means the work splits cleanly, not chaotically
• Worktrees mean ten agents never overwrite each other
• The hook plus the grader mean quality is enforced per agent, not hoped for
• A single lead integrator means merges stay clean instead of becoming a pileup
• The command means you set this up once and run a swarm with one word

The honest takeaway:Running 10 agents isn't impressive on its own, it's easy, and usually a mess. Running 10 agents that come back as one clean, tested, merged result is the actual skill. That skill is the loop, not the swarm.