orchestrate
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseMulti-Agent Orchestration
多Agent编排
Meta-orchestration patterns mined from 597+ real agent dispatches across production codebases. This skill tells you WHICH strategy to use, HOW to structure prompts, and WHEN to use background vs foreground.
Core principle: Choose the right orchestration strategy for the work, partition agents by independence, inject context to enable parallelism, and adapt review overhead to trust level.
从生产代码库的597+次真实Agent调度中提炼出的元编排模式。本技能会告诉你该使用哪种策略、如何构造提示词,以及何时使用后台/前台运行模式。
核心原则: 为工作选择合适的编排策略,按独立性划分Agent,注入上下文以支持并行运行,根据信任级别调整审核开销。
Strategy Selection
策略选择
dot
digraph strategy_selection {
rankdir=TB;
"What type of work?" [shape=diamond];
"Research / knowledge gathering" [shape=box];
"Independent feature builds" [shape=box];
"Sequential dependent tasks" [shape=box];
"Same transformation across partitions" [shape=box];
"Codebase audit / assessment" [shape=box];
"Greenfield project kickoff" [shape=box];
"Research Swarm" [shape=box style=filled fillcolor=lightyellow];
"Epic Parallel Build" [shape=box style=filled fillcolor=lightyellow];
"Sequential Pipeline" [shape=box style=filled fillcolor=lightyellow];
"Parallel Sweep" [shape=box style=filled fillcolor=lightyellow];
"Multi-Dimensional Audit" [shape=box style=filled fillcolor=lightyellow];
"Full Lifecycle" [shape=box style=filled fillcolor=lightyellow];
"What type of work?" -> "Research / knowledge gathering";
"What type of work?" -> "Independent feature builds";
"What type of work?" -> "Sequential dependent tasks";
"What type of work?" -> "Same transformation across partitions";
"What type of work?" -> "Codebase audit / assessment";
"What type of work?" -> "Greenfield project kickoff";
"Research / knowledge gathering" -> "Research Swarm";
"Independent feature builds" -> "Epic Parallel Build";
"Sequential dependent tasks" -> "Sequential Pipeline";
"Same transformation across partitions" -> "Parallel Sweep";
"Codebase audit / assessment" -> "Multi-Dimensional Audit";
"Greenfield project kickoff" -> "Full Lifecycle";
}| Strategy | When | Agents | Background | Key Pattern |
|---|---|---|---|---|
| Research Swarm | Knowledge gathering, docs, SOTA research | 10-60+ | Yes (100%) | Fan-out, each writes own doc |
| Epic Parallel Build | Plan with independent epics/features | 20-60+ | Yes (90%+) | Wave dispatch by subsystem |
| Sequential Pipeline | Dependent tasks, shared files | 3-15 | No (0%) | Implement -> Review -> Fix chain |
| Parallel Sweep | Same fix/transform across modules | 4-10 | No (0%) | Partition by directory, fan-out |
| Multi-Dimensional Audit | Quality gates, deep assessment | 6-9 | No (0%) | Same code, different review lenses |
| Full Lifecycle | New project from scratch | All above | Mixed | Research -> Plan -> Build -> Review -> Harden |
dot
digraph strategy_selection {
rankdir=TB;
"What type of work?" [shape=diamond];
"Research / knowledge gathering" [shape=box];
"Independent feature builds" [shape=box];
"Sequential dependent tasks" [shape=box];
"Same transformation across partitions" [shape=box];
"Codebase audit / assessment" [shape=box];
"Greenfield project kickoff" [shape=box];
"Research Swarm" [shape=box style=filled fillcolor=lightyellow];
"Epic Parallel Build" [shape=box style=filled fillcolor=lightyellow];
"Sequential Pipeline" [shape=box style=filled fillcolor=lightyellow];
"Parallel Sweep" [shape=box style=filled fillcolor=lightyellow];
"Multi-Dimensional Audit" [shape=box style=filled fillcolor=lightyellow];
"Full Lifecycle" [shape=box style=filled fillcolor=lightyellow];
"What type of work?" -> "Research / knowledge gathering";
"What type of work?" -> "Independent feature builds";
"What type of work?" -> "Sequential dependent tasks";
"What type of work?" -> "Same transformation across partitions";
"What type of work?" -> "Codebase audit / assessment";
"What type of work?" -> "Greenfield project kickoff";
"Research / knowledge gathering" -> "Research Swarm";
"Independent feature builds" -> "Epic Parallel Build";
"Sequential dependent tasks" -> "Sequential Pipeline";
"Same transformation across partitions" -> "Parallel Sweep";
"Codebase audit / assessment" -> "Multi-Dimensional Audit";
"Greenfield project kickoff" -> "Full Lifecycle";
}| 策略 | 适用场景 | Agent数量 | 后台运行占比 | 核心模式 |
|---|---|---|---|---|
| Research Swarm | 知识收集、文档整理、前沿技术研究 | 10-60+ | 是 (100%) | 扇出,每个Agent编写独立文档 |
| Epic Parallel Build | 包含独立史诗/功能的开发计划 | 20-60+ | 是 (90%+) | 按子系统波次调度 |
| Sequential Pipeline | 依赖型任务、共享文件修改 | 3-15 | 否 (0%) | 实现 -> 审核 -> 修复链 |
| Parallel Sweep | 跨模块统一修复/转换 | 4-10 | 否 (0%) | 按目录划分,扇出调度 |
| Multi-Dimensional Audit | 质量门禁、深度评估 | 6-9 | 否 (0%) | 同一份代码,不同审核视角 |
| Full Lifecycle | 从零开始的新项目 | 以上所有 | 混合 | 研究 -> 规划 -> 构建 -> 审核 -> 加固 |
Strategy 1: Research Swarm
策略1:Research Swarm
Mass-deploy background agents to build a knowledge corpus. Each agent researches one topic and writes one markdown document. Zero dependencies between agents.
批量部署后台Agent构建知识库。每个Agent负责研究一个主题并编写一份markdown文档,Agent之间无任何依赖。
When to Use
适用场景
- Kicking off a new project (need SOTA for all technologies)
- Building a skill/plugin (need comprehensive domain knowledge)
- Technology evaluation (compare multiple options in parallel)
- 启动新项目(需要所有相关技术的前沿信息)
- 开发技能/插件(需要全面的领域知识)
- 技术选型(并行对比多个可选方案)
The Pattern
运行模式
Phase 1: Deploy research army (ALL BACKGROUND)
Wave 1 (10-20 agents): Core technology research
Wave 2 (10-20 agents): Specialized topics, integrations
Wave 3 (5-10 agents): Gap-filling based on early results
Phase 2: Monitor and supplement
- Check completed docs as they arrive
- Identify gaps, deploy targeted follow-up agents
- Read completed research to inform remaining dispatches
Phase 3: Synthesize
- Read all research docs (foreground)
- Create architecture plans, design docs
- Use Plan agent to synthesize findingsPhase 1: Deploy research army (ALL BACKGROUND)
Wave 1 (10-20 agents): Core technology research
Wave 2 (10-20 agents): Specialized topics, integrations
Wave 3 (5-10 agents): Gap-filling based on early results
Phase 2: Monitor and supplement
- Check completed docs as they arrive
- Identify gaps, deploy targeted follow-up agents
- Read completed research to inform remaining dispatches
Phase 3: Synthesize
- Read all research docs (foreground)
- Create architecture plans, design docs
- Use Plan agent to synthesize findingsPrompt Template: Research Agent
提示词模板:研究Agent
markdown
Research [TECHNOLOGY] for [PROJECT]'s [USE CASE].
Create a comprehensive research doc at [OUTPUT_PATH]/[filename].md covering:
1. Latest [TECH] version and features (search "[TECH] 2026" or "[TECH] latest")
2. [Specific feature relevant to project]
3. [Another relevant feature]
4. [Integration patterns with other stack components]
5. [Performance characteristics]
6. [Known gotchas and limitations]
7. [Best practices for production use]
8. [Code examples for key patterns]
Include code examples where possible. Use WebSearch and WebFetch to get current docs.Key rules:
- Every agent gets an explicit output file path (no ambiguity)
- Include search hints: "search [TECH] 2026" (agents need recency guidance)
- Numbered coverage list (8-12 items) scopes the research precisely
- ALL agents run in background -- no dependencies between research topics
markdown
Research [TECHNOLOGY] for [PROJECT]'s [USE CASE].
Create a comprehensive research doc at [OUTPUT_PATH]/[filename].md covering:
1. Latest [TECH] version and features (search "[TECH] 2026" or "[TECH] latest")
2. [Specific feature relevant to project]
3. [Another relevant feature]
4. [Integration patterns with other stack components]
5. [Performance characteristics]
6. [Known gotchas and limitations]
7. [Best practices for production use]
8. [Code examples for key patterns]
Include code examples where possible. Use WebSearch and WebFetch to get current docs.核心规则:
- 为每个Agent指定明确的输出文件路径(无歧义)
- 包含搜索提示:(Agent需要时效性指引)
search [TECH] 2026 - 编号的覆盖列表(8-12项)精准限定研究范围
- 所有Agent后台运行——研究主题之间无依赖
Dispatch Cadence
调度节奏
- 3-4 seconds between agent dispatches
- Group into thematic waves of 10-20 agents
- 15-25 minute gaps between waves for gap analysis
-
Agent调度间隔3-4秒
-
按主题分组为10-20个Agent的波次
-
波次之间间隔15-25分钟用于缺口分析
Strategy 2: Epic Parallel Build
策略2:Epic Parallel Build
Deploy background agents to implement independent features/epics simultaneously. Each agent builds one feature in its own directory/module. No two agents touch the same files.
部署后台Agent并行实现独立功能/史诗需求。每个Agent在独立目录/模块中开发一个功能,无两个Agent操作相同文件。
When to Use
适用场景
- Implementation plan with 10+ independent tasks
- Monorepo with isolated packages/modules
- Sprint backlog with non-overlapping features
- 包含10+独立任务的实现计划
- 带隔离包/模块的单体仓库
- 无重叠功能的冲刺待办列表
The Pattern
运行模式
Phase 1: Scout (FOREGROUND)
- Deploy one Explore agent to map the codebase
- Identify dependency chains and independent workstreams
- Group tasks by subsystem to prevent file conflicts
Phase 2: Deploy build army (ALL BACKGROUND)
Wave 1: Infrastructure/foundation (Redis, DB, auth)
Wave 2: Backend APIs (each in own module directory)
Wave 3: Frontend pages (each in own route directory)
Wave 4: Integrations (MCP servers, external services)
Wave 5: DevOps (CI, Docker, deployment)
Wave 6: Bug fixes from review findings
Phase 3: Monitor and coordinate
- Check git status for completed commits
- Handle git index.lock contention (expected with 30+ agents)
- Deploy remaining tasks as agents complete
- Track via Sibyl tasks or TodoWrite
Phase 4: Review and harden (FOREGROUND)
- Run Codex/code-reviewer on completed work
- Dispatch fix agents for critical findings
- Integration testingPhase 1: Scout (FOREGROUND)
- Deploy one Explore agent to map the codebase
- Identify dependency chains and independent workstreams
- Group tasks by subsystem to prevent file conflicts
Phase 2: Deploy build army (ALL BACKGROUND)
Wave 1: Infrastructure/foundation (Redis, DB, auth)
Wave 2: Backend APIs (each in own module directory)
Wave 3: Frontend pages (each in own route directory)
Wave 4: Integrations (MCP servers, external services)
Wave 5: DevOps (CI, Docker, deployment)
Wave 6: Bug fixes from review findings
Phase 3: Monitor and coordinate
- Check git status for completed commits
- Handle git index.lock contention (expected with 30+ agents)
- Deploy remaining tasks as agents complete
- Track via Sibyl tasks or TodoWrite
Phase 4: Review and harden (FOREGROUND)
- Run Codex/code-reviewer on completed work
- Dispatch fix agents for critical findings
- Integration testingPrompt Template: Feature Build Agent
提示词模板:功能开发Agent
markdown
**Task: [DESCRIPTIVE TITLE]** (task\_[ID])
Work in /path/to/project/[SPECIFIC_DIRECTORY]markdown
**Task: [DESCRIPTIVE TITLE]** (task\_[ID])
Work in /path/to/project/[SPECIFIC_DIRECTORY]Context
Context
[What already exists. Reference specific files, patterns, infrastructure.]
[e.g., "Redis is available at ", "Follow pattern from "]
app.state.redissrc/auth/[What already exists. Reference specific files, patterns, infrastructure.]
[e.g., "Redis is available at ", "Follow pattern from "]
app.state.redissrc/auth/Your Job
Your Job
-
Createwith:
src/path/to/module/- -- [Description]
file.py - -- [Description]
routes.py - -- [Schema definitions]
models.py
-
Implementation requirements: [Detailed spec with code snippets, Pydantic models, API contracts]
-
Tests:
- Create
tests/test_module.py - Cover: [specific test scenarios]
- Create
-
Integration:
- Wire into [main app entry point]
- Register routes at [path]
-
Createwith:
src/path/to/module/- -- [Description]
file.py - -- [Description]
routes.py - -- [Schema definitions]
models.py
-
Implementation requirements: [Detailed spec with code snippets, Pydantic models, API contracts]
-
Tests:
- Create
tests/test_module.py - Cover: [specific test scenarios]
- Create
-
Integration:
- Wire into [main app entry point]
- Register routes at [path]
Git
Git
Commit with message: "feat([module]): [description]"
Only stage files YOU created. Check before committing.
Do NOT stage files from other agents.
git status
**Key rules:**
- Every agent gets its own directory scope -- NO OVERLAP
- Provide existing patterns to follow ("Follow pattern from X")
- Include infrastructure context ("Redis available at X")
- Explicit git hygiene instructions (critical with 30+ parallel agents)
- Task IDs for traceabilityCommit with message: "feat([module]): [description]"
Only stage files YOU created. Check before committing.
Do NOT stage files from other agents.
git status
**核心规则:**
- 每个Agent有专属目录范围——无重叠
- 提供可遵循的现有模式(「遵循`X`中的模式」)
- 包含基础设施上下文(「Redis可通过`X`访问」)
- 明确的Git操作规范(30+并行Agent场景下至关重要)
- 任务ID用于可追溯性Git Coordination for Parallel Agents
并行Agent的Git协调规则
When running 10+ agents concurrently:
- Expect index.lock contention -- agents will retry automatically
- Each agent commits only its own files -- prompt must say this explicitly
- No agent should run -- only specific files
git add . - Monitor with periodically
git log --oneline -20 - No agent should push -- orchestrator handles push after integration
当同时运行10+Agent时:
- 预期会出现index.lock冲突——Agent会自动重试
- 每个Agent仅提交自己创建的文件——提示词中必须明确说明
- 禁止任何Agent运行——仅添加指定文件
git add . - 定期运行监控进度
git log --oneline -20 - 禁止Agent执行push操作——集成完成后由编排者统一推送
Strategy 3: Sequential Pipeline
策略3:Sequential Pipeline
Execute dependent tasks one at a time with review gates. Each task builds on the previous task's output. Use for the full pipeline.
superpowers:subagent-driven-development通过审核门禁逐个执行依赖型任务,每个任务基于前序任务的输出构建。可使用实现完整流水线。
superpowers:subagent-driven-developmentWhen to Use
适用场景
- Tasks that modify shared files
- Integration boundary work (JNI bridges, auth chains)
- Review-then-fix cycles where each fix depends on review findings
- Complex features where implementation order matters
- 修改共享文件的任务
- 集成边界工作(JNI桥接、认证链路)
- 修复依赖审核结果的审核-修复循环
- 实现顺序有要求的复杂功能
The Pattern
运行模式
For each task:
1. Dispatch implementer (FOREGROUND)
2. Dispatch spec reviewer (FOREGROUND)
3. Dispatch code quality reviewer (FOREGROUND)
4. Fix any issues found
5. Move to next task
Trust Gradient (adapt over time):
Early tasks: Implement -> Spec Review -> Code Review (full ceremony)
Middle tasks: Implement -> Spec Review (lighter)
Late tasks: Implement only (pattern proven, high confidence)For each task:
1. Dispatch implementer (FOREGROUND)
2. Dispatch spec reviewer (FOREGROUND)
3. Dispatch code quality reviewer (FOREGROUND)
4. Fix any issues found
5. Move to next task
Trust Gradient (adapt over time):
Early tasks: Implement -> Spec Review -> Code Review (full ceremony)
Middle tasks: Implement -> Spec Review (lighter)
Late tasks: Implement only (pattern proven, high confidence)Trust Gradient
信任梯度
As the session progresses and patterns prove reliable, progressively lighten review overhead:
| Phase | Review Overhead | When |
|---|---|---|
| Full ceremony | Implement + Spec Review + Code Review | First 3-4 tasks |
| Standard | Implement + Spec Review | Tasks 5-8, or after patterns stabilize |
| Light | Implement + quick spot-check | Late tasks with established patterns |
| Cost-optimized | Use | Formulaic review passes |
This is NOT cutting corners -- it's earned confidence. If a late task deviates from the pattern, escalate back to full ceremony.
随着会话推进和模式验证可靠,可逐步降低审核开销:
| 阶段 | 审核开销 | 触发时机 |
|---|---|---|
| 全流程 | 实现 + 需求审核 + 代码审核 | 前3-4个任务 |
| 标准 | 实现 + 需求审核 | 第5-8个任务,或模式稳定后 |
| 轻量 | 实现 + 快速抽查 | 模式已确立的后期任务 |
| 成本优化 | 用 | 公式化审核流程 |
这不是偷工减料——而是信任积累的结果。如果后期任务偏离既定模式,可回退到全流程审核。
Strategy 4: Parallel Sweep
策略4:Parallel Sweep
Apply the same transformation across partitioned areas of the codebase. Every agent does the same TYPE of work but on different FILES.
在代码库的分区范围内应用统一转换,每个Agent执行相同类型的工作但操作不同文件。
When to Use
适用场景
- Lint/format fixes across modules
- Type annotation additions across packages
- Test writing for multiple modules
- Documentation updates across components
- UI polish across pages
- 跨模块的lint/格式修复
- 跨包的类型注解添加
- 多模块的测试用例编写
- 跨组件的文档更新
- 跨页面的UI优化
The Pattern
运行模式
Phase 1: Analyze the scope
- Run the tool (ruff, ty, etc.) to get full issue list
- Auto-fix what you can
- Group remaining issues by module/directory
Phase 2: Fan-out fix agents (4-10 agents)
- One agent per module/directory
- Each gets: issue count by category, domain-specific guidance
- All foreground (need to verify each completes)
Phase 3: Verify and repeat
- Run the tool again to check remaining issues
- If issues remain, dispatch another wave
- Repeat until cleanPhase 1: Analyze the scope
- Run the tool (ruff, ty, etc.) to get full issue list
- Auto-fix what you can
- Group remaining issues by module/directory
Phase 2: Fan-out fix agents (4-10 agents)
- One agent per module/directory
- Each gets: issue count by category, domain-specific guidance
- All foreground (need to verify each completes)
Phase 3: Verify and repeat
- Run the tool again to check remaining issues
- If issues remain, dispatch another wave
- Repeat until cleanPrompt Template: Module Fix Agent
提示词模板:模块修复Agent
markdown
Fix all [TOOL] issues in the [MODULE_NAME] directory ([PATH]).
Current issues ([COUNT] total):
- [RULE_CODE]: [description] ([count]) -- [domain-specific fix guidance]
- [RULE_CODE]: [description] ([count]) -- [domain-specific fix guidance]
Run `[TOOL_COMMAND] [PATH]` to see exact issues.
IMPORTANT for [DOMAIN] code:
[Domain-specific guidance, e.g., "GTK imports need GI.require_version() before gi.repository imports"]
After fixing, run `[TOOL_COMMAND] [PATH]` to verify zero issues remain.Key rules:
- Provide issue counts by category (not just "fix everything")
- Include domain-specific guidance (agents need to know WHY patterns exist)
- Partition by directory to prevent overlap
- Run in waves: fix -> verify -> fix remaining -> verify
markdown
Fix all [TOOL] issues in the [MODULE_NAME] directory ([PATH]).
Current issues ([COUNT] total):
- [RULE_CODE]: [description] ([count]) -- [domain-specific fix guidance]
- [RULE_CODE]: [description] ([count]) -- [domain-specific fix guidance]
Run `[TOOL_COMMAND] [PATH]` to see exact issues.
IMPORTANT for [DOMAIN] code:
[Domain-specific guidance, e.g., "GTK imports need GI.require_version() before gi.repository imports"]
After fixing, run `[TOOL_COMMAND] [PATH]` to verify zero issues remain.核心规则:
- 按分类提供问题计数(而不是仅说「修复所有问题」)
- 包含领域特定指引(Agent需要知道模式存在的原因)
- 按目录划分避免重叠
- 按波次运行:修复 -> 验证 -> 修复剩余问题 -> 验证
Strategy 5: Multi-Dimensional Audit
策略5:Multi-Dimensional Audit
Deploy multiple reviewers to examine the same code from different angles simultaneously. Each reviewer has a different focus lens.
部署多个审核者同时从不同角度检查同一份代码,每个审核者有不同的关注视角。
When to Use
适用场景
- Major feature complete, need comprehensive review
- Pre-release quality gate
- Security audit
- Performance assessment
- 核心功能开发完成,需要全面审核
- 发布前质量门禁
- 安全审计
- 性能评估
The Pattern
运行模式
Dispatch 6 parallel reviewers (ALL FOREGROUND):
1. Code quality & safety reviewer
2. Integration correctness reviewer
3. Spec completeness reviewer
4. Test coverage reviewer
5. Performance analyst
6. Security auditor
Wait for all to complete, then:
- Synthesize findings into prioritized action list
- Dispatch targeted fix agents for critical issues
- Re-review only the dimensions that had findingsDispatch 6 parallel reviewers (ALL FOREGROUND):
1. Code quality & safety reviewer
2. Integration correctness reviewer
3. Spec completeness reviewer
4. Test coverage reviewer
5. Performance analyst
6. Security auditor
Wait for all to complete, then:
- Synthesize findings into prioritized action list
- Dispatch targeted fix agents for critical issues
- Re-review only the dimensions that had findingsPrompt Template: Dimension Reviewer
提示词模板:维度审核者
markdown
[DIMENSION] review of [COMPONENT] implementation.
**Files to review:**
- [file1.ext]
- [file2.ext]
- [file3.ext]
**Analyze:**
1. [Specific question for this dimension]
2. [Specific question for this dimension]
3. [Specific question for this dimension]
**Report format:**
- Findings: numbered list with severity (Critical/Important/Minor)
- Assessment: Approved / Needs Changes
- Recommendations: prioritized action itemsmarkdown
[DIMENSION] review of [COMPONENT] implementation.
**Files to review:**
- [file1.ext]
- [file2.ext]
- [file3.ext]
**Analyze:**
1. [Specific question for this dimension]
2. [Specific question for this dimension]
3. [Specific question for this dimension]
**Report format:**
- Findings: numbered list with severity (Critical/Important/Minor)
- Assessment: Approved / Needs Changes
- Recommendations: prioritized action itemsStrategy 6: Full Lifecycle
策略6:Full Lifecycle
For greenfield projects, combine all strategies in sequence:
Session 1: RESEARCH (Research Swarm)
-> 30-60 background agents build knowledge corpus
-> Architecture planning agents synthesize findings
-> Output: docs/research/*.md + docs/plans/*.md
Session 2: BUILD (Epic Parallel Build)
-> Scout agent maps what exists
-> 30-60 background agents build features by epic
-> Monitor, handle git contention, track completions
-> Output: working codebase with commits
Session 3: ITERATE (Build-Review-Fix Pipeline)
-> Code review agents assess work
-> Fix agents address findings
-> Deep audit agents (foreground) assess each subsystem
-> Output: quality-assessed codebase
Session 4: HARDEN (Sequential Pipeline)
-> Integration boundary reviews (foreground, sequential)
-> Security fixes, race condition fixes
-> Test infrastructure setup
-> Output: production-ready codebaseEach session shifts orchestration strategy to match the work's nature. Parallel when possible, sequential when required.
对于从零开始的新项目,按顺序组合所有策略:
Session 1: RESEARCH (Research Swarm)
-> 30-60 background agents build knowledge corpus
-> Architecture planning agents synthesize findings
-> Output: docs/research/*.md + docs/plans/*.md
Session 2: BUILD (Epic Parallel Build)
-> Scout agent maps what exists
-> 30-60 background agents build features by epic
-> Monitor, handle git contention, track completions
-> Output: working codebase with commits
Session 3: ITERATE (Build-Review-Fix Pipeline)
-> Code review agents assess work
-> Fix agents address findings
-> Deep audit agents (foreground) assess each subsystem
-> Output: quality-assessed codebase
Session 4: HARDEN (Sequential Pipeline)
-> Integration boundary reviews (foreground, sequential)
-> Security fixes, race condition fixes
-> Test infrastructure setup
-> Output: production-ready codebase每个会话根据工作性质调整编排策略,尽可能并行,必要时串行。
Background vs Foreground Decision
后台 vs 前台运行决策
dot
digraph bg_fg {
"What is the agent producing?" [shape=diamond];
"Information (research, docs)" [shape=box];
"Code modifications" [shape=box];
"Does orchestrator need it NOW?" [shape=diamond];
"BACKGROUND" [shape=box style=filled fillcolor=lightgreen];
"FOREGROUND" [shape=box style=filled fillcolor=lightyellow];
"Does next task depend on this task's files?" [shape=diamond];
"FOREGROUND (sequential)" [shape=box style=filled fillcolor=lightyellow];
"FOREGROUND (parallel)" [shape=box style=filled fillcolor=lightyellow];
"What is the agent producing?" -> "Information (research, docs)";
"What is the agent producing?" -> "Code modifications";
"Information (research, docs)" -> "Does orchestrator need it NOW?";
"Does orchestrator need it NOW?" -> "FOREGROUND" [label="yes"];
"Does orchestrator need it NOW?" -> "BACKGROUND" [label="no - synthesize later"];
"Code modifications" -> "Does next task depend on this task's files?";
"Does next task depend on this task's files?" -> "FOREGROUND (sequential)" [label="yes"];
"Does next task depend on this task's files?" -> "FOREGROUND (parallel)" [label="no - different modules"];
}Rules observed from 597+ dispatches:
- Research agents with no immediate dependency -> BACKGROUND (100% of the time)
- Code-writing agents -> FOREGROUND (even if parallel)
- Review/validation gates -> FOREGROUND (blocks pipeline)
- Sequential dependencies -> FOREGROUND, one at a time
dot
digraph bg_fg {
"What is the agent producing?" [shape=diamond];
"Information (research, docs)" [shape=box];
"Code modifications" [shape=box];
"Does orchestrator need it NOW?" [shape=diamond];
"BACKGROUND" [shape=box style=filled fillcolor=lightgreen];
"FOREGROUND" [shape=box style=filled fillcolor=lightyellow];
"Does next task depend on this task's files?" [shape=diamond];
"FOREGROUND (sequential)" [shape=box style=filled fillcolor=lightyellow];
"FOREGROUND (parallel)" [shape=box style=filled fillcolor=lightyellow];
"What is the agent producing?" -> "Information (research, docs)";
"What is the agent producing?" -> "Code modifications";
"Information (research, docs)" -> "Does orchestrator need it NOW?";
"Does orchestrator need it NOW?" -> "FOREGROUND" [label="yes"];
"Does orchestrator need it NOW?" -> "BACKGROUND" [label="no - synthesize later"];
"Code modifications" -> "Does next task depend on this task's files?";
"Does next task depend on this task's files?" -> "FOREGROUND (sequential)" [label="yes"];
"Does next task depend on this task's files?" -> "FOREGROUND (parallel)" [label="no - different modules"];
}从597+次调度中总结的规则:
- 无即时依赖的研究Agent -> 后台运行(100%场景)
- 代码编写Agent -> 前台运行(即使是并行模式)
- 审核/验证门禁 -> 前台运行(会阻塞流水线)
- 顺序依赖任务 -> 前台运行,逐个执行
Prompt Engineering Patterns
提示词工程模式
Pattern A: Role + Mission + Structure (Research)
模式A:角色 + 任务 + 结构(研究场景)
markdown
You are researching [DOMAIN] to create comprehensive documentation for [PROJECT].
Your mission: Create an exhaustive reference document covering ALL [TOPIC] capabilities.
Cover these areas in depth:
1. **[Category]** -- specific items
2. **[Category]** -- specific items
...
Use WebSearch and WebFetch to find blog posts, GitHub repos, and official docs.markdown
You are researching [DOMAIN] to create comprehensive documentation for [PROJECT].
Your mission: Create an exhaustive reference document covering ALL [TOPIC] capabilities.
Cover these areas in depth:
1. **[Category]** -- specific items
2. **[Category]** -- specific items
...
Use WebSearch and WebFetch to find blog posts, GitHub repos, and official docs.Pattern B: Task + Context + Files + Spec (Feature Build)
模式B:任务 + 上下文 + 文件 + 规范(功能开发场景)
markdown
**Task: [TITLE]** (task\_[ID])
Work in /absolute/path/to/[directory]markdown
**Task: [TITLE]** (task\_[ID])
Work in /absolute/path/to/[directory]Context
Context
[What exists, what to read, what infrastructure is available]
[What exists, what to read, what infrastructure is available]
Your Job
Your Job
- Create with [description]
path/to/file - [Detailed implementation spec]
- [Test requirements]
- [Integration requirements]
- Create with [description]
path/to/file - [Detailed implementation spec]
- [Test requirements]
- [Integration requirements]
Git
Git
Commit with: "feat([scope]): [message]"
Only stage YOUR files.
undefinedCommit with: "feat([scope]): [message]"
Only stage YOUR files.
undefinedPattern C: Review + Verify + Report (Audit)
模式C:审核 + 验证 + 报告(审计场景)
markdown
Comprehensive audit of [SCOPE] for [DIMENSION].
Look for:
1. [Specific thing #1]
2. [Specific thing #2]
...
3. [Specific thing #10]
[Scope boundaries -- which directories/files]
Report format:
- Findings: numbered with severity
- Assessment: Pass / Needs Work
- Action items: prioritizedmarkdown
Comprehensive audit of [SCOPE] for [DIMENSION].
Look for:
1. [Specific thing #1]
2. [Specific thing #2]
...
3. [Specific thing #10]
[Scope boundaries -- which directories/files]
Report format:
- Findings: numbered with severity
- Assessment: Pass / Needs Work
- Action items: prioritizedPattern D: Issue + Location + Fix (Bug Fix)
模式D:问题 + 位置 + 修复(Bug修复场景)
markdown
**Task:** Fix [ISSUE] -- [SEVERITY]
**Problem:** [Description with file:line references]
**Location:** [Exact file path]
**Fix Required:**
1. [Specific change]
2. [Specific change]
**Verify:**
1. Run [command] to confirm fix
2. Run tests: [test command]markdown
**Task:** Fix [ISSUE] -- [SEVERITY]
**Problem:** [Description with file:line references]
**Location:** [Exact file path]
**Fix Required:**
1. [Specific change]
2. [Specific change]
**Verify:**
1. Run [command] to confirm fix
2. Run tests: [test command]Context Injection: The Parallelism Enabler
上下文注入:并行能力的核心
Agents can work independently BECAUSE the orchestrator pre-loads them with all context they need. Without this, agents would need to explore first, serializing the work.
Always inject:
- Absolute file paths (never relative)
- Existing patterns to follow ("Follow pattern from ")
src/auth/jwt.py - Available infrastructure ("Redis at ")
app.state.redis - Design language/conventions ("SilkCircuit Neon palette")
- Tool usage hints ("Use WebSearch to find...")
- Git instructions ("Only stage YOUR files")
For parallel agents, duplicate shared context:
- Copy the same context block into each agent's prompt
- Explicit exclusion notes ("11-Sibyl is handled by another agent")
- Shared utilities described identically
Agent能够独立工作的前提是编排者预先为其注入所有需要的上下文。没有上下文的话Agent需要先自行探索,会导致工作串行化。
必须注入的内容:
- 绝对文件路径(不要用相对路径)
- 可遵循的现有模式(「遵循中的模式」)
src/auth/jwt.py - 可用的基础设施(「Redis可通过访问」)
app.state.redis - 设计语言/规范(「SilkCircuit Neon配色方案」)
- 工具使用提示(「使用WebSearch查找...」)
- Git操作指引(「仅提交你创建的文件」)
并行Agent场景下需复制共享上下文:
- 为每个Agent的提示词复制相同的上下文块
- 明确的排除说明(「11-Sibyl由其他Agent负责」)
- 共享工具的统一描述
Monitoring Parallel Agents
并行Agent监控
When running 10+ background agents:
- Check periodically -- for commits
git log --oneline -20 - Read output files -- the agent output files for progress
tail - Track completions -- Use Sibyl tasks or TodoWrite
- Deploy gap-fillers -- As early agents complete, identify missing work
- Handle contention -- git index.lock is expected, agents retry automatically
当运行10+后台Agent时:
- 定期检查 —— 运行查看提交记录
git log --oneline -20 - 读取输出文件 —— 用查看Agent输出文件了解进度
tail - 跟踪完成情况 —— 使用Sibyl任务或TodoWrite工具
- 部署补位Agent —— 早期Agent完成后识别缺失的工作
- 处理冲突 —— git index.lock冲突是正常现象,Agent会自动重试
Status Report Template
状态报告模板
undefinedundefinedAgent Swarm Status
Agent Swarm Status
[N] agents deployed | [M] completed | [P] in progress
[N] agents deployed | [M] completed | [P] in progress
Completed:
Completed:
- [Agent description] -- [Key result]
- [Agent description] -- [Key result]
- [Agent description] -- [Key result]
- [Agent description] -- [Key result]
In Progress:
In Progress:
- [Agent description] -- [Status]
- [Agent description] -- [Status]
Gaps Identified:
Gaps Identified:
- [Missing area] -- deploying follow-up agent
---- [Missing area] -- deploying follow-up agent
---Common Mistakes
常见错误
DON'T: Dispatch agents that touch the same files -> merge conflicts
DO: Partition by directory/module -- one agent per scope
DON'T: Run all agents foreground when they're independent -> sequential bottleneck
DO: Use background for research, foreground for code that needs coordination
DON'T: Send 50 agents with vague "fix everything" prompts
DO: Give each agent a specific scope, issue list, and domain guidance
DON'T: Skip the scout phase for build sprints
DO: Always Explore first to map what exists and identify dependencies
DON'T: Keep full review ceremony for every task in a long session
DO: Apply the trust gradient -- earn lighter reviews through consistency
DON'T: Let agents run or
DO: Explicit git hygiene in every build prompt
git add .git pushDON'T: Dispatch background agents for code that needs integration
DO: Background is for research only. Code agents run foreground.
禁止: 调度多个Agent操作相同文件 -> 合并冲突
正确做法: 按目录/模块划分 —— 每个Scope对应一个Agent
禁止: 独立任务也全部用前台运行Agent -> 串行瓶颈
正确做法: 研究场景用后台运行,需要协调的代码任务用前台运行
禁止: 给50个Agent发模糊的「修复所有问题」提示词
正确做法: 给每个Agent指定明确的范围、问题列表和领域指引
禁止: 开发冲刺跳过探索阶段
正确做法: 始终先运行Explore Agent梳理现有代码和依赖关系
禁止: 长会话中每个任务都保持全流程审核
正确做法: 应用信任梯度 —— 通过稳定表现换取更轻量的审核流程
禁止: 允许Agent运行或
正确做法: 每个开发提示词中都明确说明Git操作规范
git add .git push禁止: 调度后台Agent处理需要集成的代码任务
正确做法: 后台仅用于研究场景,代码Agent全部前台运行
Integration with Other Skills
与其他技能的集成
| Skill | Use With | When |
|---|---|---|
| Sequential Pipeline | Single-task implement-review cycles |
| Parallel Sweep | Independent bug fixes |
| Full Lifecycle | Create the plan before Phase 2 |
| Sequential Pipeline | Batch execution in separate session |
| Full Lifecycle | Before research phase |
| All strategies | Quality gates between phases |
| All strategies | Final validation |
| 技能 | 配合使用场景 | 触发时机 |
|---|---|---|
| Sequential Pipeline | 单任务实现-审核循环 |
| Parallel Sweep | 独立Bug修复 |
| Full Lifecycle | 第二阶段前创建开发计划 |
| Sequential Pipeline | 独立会话中的批量执行 |
| Full Lifecycle | 研究阶段前 |
| 所有策略 | 阶段间的质量门禁 |
| 所有策略 | 最终验证 |