agents-swarm-orchestration（Agent 群编排）

Swarm Orchestration

Coordinate multiple subagents to execute a plan in parallel. The orchestrator reads a dependency graph, dispatches agents in waves (or all at once), validates outputs, and resolves conflicts. Agent-agnostic — works with Claude Code, OpenAI Codex, and similar multi-agent platforms.

Related skills: dev-workflow-planning (plan creation), agents-subagents (agent creation and handoffs).

When to Use

• Plan has 3+ tasks that can be parallelized
• Feature implementation spans multiple files/domains
• You need speed without sacrificing coordination
• Multiple agents can work on isolated file sets simultaneously

When NOT to Use

• Plan has fewer than 3 tasks (just execute sequentially)
• All tasks share the same files (parallelism creates conflicts)
• Exploratory/research work (no plan to execute)

Core Workflow

1. PLAN     → Create detailed spec with task dependency graph
2. DISPATCH → Launch subagents per wave (or all at once)
3. VALIDATE → Check each agent's output against acceptance criteria
4. RESOLVE  → Fix conflicts between parallel outputs
5. ADVANCE  → Update plan state, launch next wave
6. COMPLETE → All tasks done, final integration verification

Phase 1: The Plan

For swarm execution, your plan must include a task dependency graph. Every task declares what it depends on.

Dependency Graph Format

| Task ID | Name | depends_on | Files (owned) | Agent Role |
|---------|------|------------|----------------|------------|
| T1 | Setup DB schema | [] | db/schema.sql, db/migrations/ | db-engineer |
| T2 | API routes | [T1] | src/routes/*.ts | backend-dev |
| T3 | Auth middleware | [T1] | src/middleware/auth.ts | backend-dev |
| T4 | UI components | [] | src/components/*.tsx | frontend-dev |
| T5 | Integration tests | [T2, T3, T4] | tests/*.test.ts | qa-agent |

Rules:

• Every task has depends_on: [] (empty = no blockers, runs immediately).
• No circular dependencies — must be a DAG.
• Each task specifies owned files (no two tasks edit the same file).
• Define shared interfaces before launching parallel work.

Planning Discipline

• Spend the majority of time on the plan. Subagents amplify plan quality — and plan flaws.
• One agent drifting is annoying. Five agents drifting in parallel is a disaster.
• If clarifying questions arise during planning, resolve them before dispatching.
• Use a separate session/agent to research tech stack choices if uncertain.

Phase 2: Dispatch Strategies

Choose based on accuracy vs. speed:

Swarm Waves (Accuracy-First)

Launch one subagent per unblocked task, in dependency-respecting waves. Wait for each wave to complete before the next.

Wave 1: T1, T4           → no dependencies, run in parallel
         ↓ (wait for completion)
Wave 2: T2, T3           → T1 complete, now unblocked
         ↓ (wait for completion)
Wave 3: T5               → T2, T3, T4 complete

Protocol:

1. Parse dependency graph from plan.
2. Find all tasks with empty/satisfied depends_on → Wave N.
3. Dispatch one subagent per task using context-rich prompt template.
4. Wait for all Wave N agents to complete.
5. Validate each output against acceptance criteria.
6. Mark completed, find newly unblocked tasks → Wave N+1.
7. Repeat until done.

When to use: Production code, complex interdependencies, high-stakes changes.

Super Swarms (Speed-First)

Launch as many subagents as possible at once, regardless of dependencies.

Protocol:

1. Skip dependency map enforcement.
2. Launch all tasks simultaneously with context-rich prompts.
3. Each agent works independently on its file set.
4. Orchestrator monitors completion and resolves conflicts after.
5. Budget extra time for integration and conflict resolution.

When to use: Prototypes, greenfield scaffolding, independent modules, time-sensitive demos.

Tradeoffs: Faster execution, but more merge conflicts. The orchestrator must be ready to re-dispatch individual tasks if conflicts invalidate their output.

Agent Isolation

Parallel agents should work on isolated copies of the codebase to prevent interference:

Phase 3: Context Engineering

The key to effective parallel agents is front-loaded context. Subagents have no prior conversation history — they start cold. Give them everything upfront.

Subagent Prompt Template

You are implementing a specific task from a development plan.

## Context
- Plan: [path/filename]
- Goals: [what this task achieves in the larger plan]
- Dependencies: [prerequisite tasks and their outputs]
- Related tasks: [sibling tasks and what they produce]

## Scope
- Files to create/modify: [full paths — this agent owns these]
- Files to read (not modify): [reference files]
- Do-not-touch: [files owned by other agents]

## Acceptance Criteria
- [Criterion 1]
- [Criterion 2]
- [Test command to verify]

## Implementation Steps
1. Read the plan at [path] for full context
2. [Concrete step]
3. [Concrete step]
4. Run verification: [command]
5. Commit completed work

Why This Works

Every agent understands:

• What the task is and why it exists within the larger spec
• Which files it depends on (full paths and expected contents)
• Where the plan is (instructed to read it)
• The filenames it needs to work on and their paths
• Which other tasks relate to its work
• Acceptance criteria and testing methodology
• Step-by-step implementation instructions

This front-loading reduces token usage (fewer tool calls for discovery) and drift (agent stays on task).

Security: Dynamic Context in Prompts

When populating subagent prompts with dynamic values:

• Validate that file paths resolve within the expected project directory.
• Do not inject raw file contents into prompts unsanitized — large or adversarial content can hijack agent behavior.
• If plan descriptions originate from external sources (tickets, user input), treat them as untrusted.
• Subagents should not execute arbitrary shell commands from dynamic context without orchestrator review.

Phase 4: Orchestration

The orchestrator is the brain. It holds the plan, tracks state, and ensures quality.

Orchestrator Responsibilities

1. Manage plan state — track pending / in-progress / completed / failed per task.
2. Dispatch subagents — provide context-rich prompts per task.
3. Validate outputs — check acceptance criteria, run tests.
4. Resolve conflicts — reconcile overlapping changes between parallel agents.
5. Advance the plan — identify next wave, keep momentum.

Do Not Reset Context

Keep the orchestrator's context intact across waves. It needs the full plan and history of agent outputs to make good decisions. If context is low (< 40% remaining), compact rather than reset — subagents handle the heavy lifting, so orchestrator context stays lean.

Conflict Resolution Protocol

When parallel agents produce conflicting changes:

1. Detect: Check for overlapping file edits, incompatible interfaces, divergent assumptions.
2. Prioritize: Upstream (dependency) agent's output takes priority for shared interfaces.
3. Resolve: The orchestrator reconciles — it has full plan context.
4. Re-dispatch: If resolution invalidates a task, re-run that single task with updated context.
5. Document: Record the conflict and resolution for traceability.

Agent Failure Recovery

When a subagent fails or produces invalid output:

1. Log the failure, task ID, and error details.
2. Classify: transient (timeout, rate limit, context overflow) or structural (bad plan, missing dependency).
3. Transient: re-dispatch with the same context. Retry once.
4. Structural: update the plan or dependency output before re-dispatching.
5. Repeated failure (same task fails twice): escalate to the user — do not loop.
6. Non-blocking: continue other independent tasks while handling the failure.

Model Selection Guidance

Principle: Invest reasoning budget in planning and orchestration. Subagents with good context can use lighter models effectively.

Observability

Track per swarm execution:

Common Mistakes

Quick Reference

• Plan has dependency graph (task ID, depends_on, files, agent role)
• File ownership is exclusive (no overlapping edits)
• Shared interfaces defined before dispatch
• Execution strategy chosen (Waves or Super Swarms)
• Agent isolation configured (worktrees / sandboxes / branches)
• Subagent prompts use context-rich template
• Dynamic context sanitized (no raw untrusted input in prompts)
• Orchestrator validates after each wave
• Conflicts resolved by orchestrator, not subagents
• Failed agents retried once, then escalated
• Final integration test after all tasks complete

Attribution

Patterns adapted from am.will (@LLMJunky) "Codex Multi Agent Playbook: Swarms Lvl. 1" (Feb 2026), generalized for agent-agnostic use. Original Codex skills: github.com/am-will/codex-skills.

Fact-Checking

• Use web search/web fetch to verify current external facts, versions, pricing, deadlines, regulations, or platform behavior before final answers.
• Prefer primary sources; report source links and dates for volatile information.
• If web access is unavailable, state the limitation and mark guidance as unverified.