TL;DR：当你有 2 个以上无共享状态的任务时，在一条消息中发起多个 Agent 工具调用。这些 Agent 并发执行，各自返回独立结果，主循环随后继续。适用于并行搜索、并行测试运行或并行构建检查。
大多数"循环中的 agent"工作天然是串行的——读取文件、做出决策、写入文件、循环往复。但当你有两个或更多无共享状态且无顺序依赖的任务时，并行执行可以线性压缩总耗时。关键在于判断何时该这么做——因为共享状态意味着竞态条件，而代码中的竞态条件意味着工作成果的丢失。
LingCode 默认一次运行一个 agent 循环，这几乎始终是你想要的。一个典型任务——"重构这个模块"——的流程如下：
module.swift。module.swift。module.swift 的测试。每一步都依赖前一步。并行化此流程是不可能的——步骤 2 无法在步骤 1 返回之前运行。LingCode 的自然形态是串行的，因为推理本身就是串行的。
并行调度是例外情况，仅适用于以下场景。在不适合的任务上强行使用，会浪费上下文并产生冲突写入；而在正确的任务上使用，则能将 20 分钟的工作压缩至 5 分钟。
在让 LingCode 调度并行 Agent 之前，先回答关于任务的两个问题。两者都必须是"是"：
如果两个问题都能回答"是"，并行调度既安全又更快。如果其中一个答案是"否"，请保持串行。
在实践中真正有价值的模式：
REVIEW_<module>.md。每个 Agent 读一个文件、写一个文件——不会发生冲突。共同点：调度轮结束后有一个干净的合并步骤。并行 Agent 生成各自隔离的产物；由你（或后续的串行轮次）来整合它们。
main = 在你自己的会话中产生合并冲突。如果你确实需要这样做，请使用隔离的 worktree——参见 worktrees 教程。通过以列表形式列出任务并说明它们是独立的，来让 LingCode 并行调度。一个有效的提示词示例：
I want three independent things done in parallel — no shared
state, no ordering between them:
1. Audit Sources/Auth/ for force-unwraps and write findings to
AUDIT_AUTH.md.
2. Audit Sources/Networking/ for force-unwraps and write findings
to AUDIT_NET.md.
3. Audit Sources/Storage/ for force-unwraps and write findings to
AUDIT_STORAGE.md.
Dispatch one sub-agent per task. After all three return,
synthesize a top-level AUDIT_SUMMARY.md that aggregates the
counts and ranks modules by severity.LingCode 会调度三个子 Agent，每个拥有独立的上下文窗口，并发运行，并在完成时汇合。合成步骤是最终的串行轮次——这就是合并发生的地方。
子 Agent 不共享你的对话历史。它们只获得你分配给它们的任务和项目文件——仅此而已。这是一个特性，而非缺陷：
你需要付出的代价是：每个子 Agent 必须获得足够的指令，才能独立完成其任务。"审计 Auth"还不够——请说明目录、要查找什么、在哪里写入结果。上面的提示词对三个任务都做到了这一点。
并行调度生成 N 个隔离的产物。价值来自于对它们的综合——而综合是串行的。在合并提示词上花更多心思，而不是调度提示词：
Now that AUDIT_AUTH.md, AUDIT_NET.md, and AUDIT_STORAGE.md exist,
synthesize AUDIT_SUMMARY.md:
- Total force-unwrap count across all three modules.
- Ranked list of files by count, highest first.
- Patterns that appeared in 2+ modules (likely systemic, fix once).
- Patterns unique to one module (likely local, fix in place).
- Three concrete next-step PR titles.
Read the three audit files; do not re-scan the source code."不要重新扫描"的指令至关重要。没有它，LingCode 往往会重新执行子 Agent 已完成的工作——从而抵消并行化的收益。请信任这些产物。
并行运行结束后，检查两件事：
git status 或检查时间戳。如果两个产物最终位于同一路径，说明一个覆盖了另一个——你的"独立"任务并不是真正独立的。如果并行运行没有超过串行运行，这是下次的参考信息。并非所有"看起来能并行"的任务实际上都适合并行。
将调度启发式规则封装为一个 skill，让 LingCode 在并行化之前先执行两问测试——并在串行更合适时保持串行：
---
name: dispatching-parallel-agents
description: Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies. Triggers: 'do these in parallel', 'split this work', 'run multiple agents', 'parallelize', 'fan out', batch of independent file edits, multiple test fixtures, multiple isolated components. Actions: dispatch, parallelize, batch, fan-out, fan-in. Anti-pattern: tasks that share state, sequential dependencies, conflicting writes. Compresses wall time when the two-question test passes (no shared state + no sequential dep).
---
Before dispatching parallel agents, answer two questions about
the task set:
1. Is there shared mutable state? (Same file, same DB row, same
git branch, same in-memory variable.) If yes — stay serial.
2. Does any task's input depend on another task's output? If yes
— stay serial.
Both must be "no" to parallelize.
When parallelizing:
- Give each sub-agent a self-contained task description. They do
not share conversation history.
- Have each sub-agent write to its own artifact path. No two
agents writing the same file.
- Plan the merge step explicitly. The synthesis turn is serial
and reads the artifacts; it should not re-scan source.
Good fits: multi-target builds, per-file independent reviews,
independent research questions.
Bad fits: implementing one feature, refactor across coupled
files, two writes to the same git branch, iterative debugging.
After parallel runs, sanity-check: no file written by two agents,
wall time actually beat serial.保存至 ~/.lingcode/skills/dispatching-parallel-agents/SKILL.md——参见 安装 skill 了解确切位置以及 skill 如何被发现。