跳到主要内容

Parallel & Async Coding Agents

2025 年 10 月起，业界顶级工程师陆续从"等 AI 写完一段"切换到"同时派活给多个 AI"。这是 Coding Agent 真正的工作流革命，比之前任何"提示词技巧"都重要。本篇是这套新范式的工程化指南。

学前说明​

5-8 Coding Agent 章节写的是"如何用一个 Coding Agent"。但 2025 年下半年，Simon Willison、Jesse Vincent、Peter Steinberger 这些一线工程师纷纷描述他们已经在用完全不同的工作流：

  • 同时打开 3-5 个终端，每个跑一个独立的 Claude Code 或 Codex CLI
  • 把任务派给 Codex Cloud / Jules，离线异步执行，回来再 review
  • 用 git worktree 让多个 Agent 在同一个 repo 上并行修改不同部分
  • "Send out a scout" —— 派一个 Agent 去探路，不要它的代码，只要它的发现

本篇与 5-8 的关系：5-8 是"单 Agent 工作流"的扎实基础。本篇假设你已经熟悉 Claude Code/Cursor 的基本用法，进入下一阶段。

学习目标​

  • 识别哪些任务适合并行/异步派给 Agent，哪些必须自己盯着
  • 掌握 4 种核心模式：Research / How-Does-It-Work / 小维护 / 受指导工作
  • 用 git worktree 让多个 Agent 并行修改同一个 repo
  • 搭建本地 Docker 沙箱降低 YOLO 模式的爆炸半径
  • 用 Codex Cloud / Jules / GitHub Copilot Coding Agent 做异步派活
  • 设计 "Architect → Implementor" 的双 Agent 工作流

与现有知识的衔接​

  • 5-8 Coding Agent：单 Agent 操作（前置）
  • 04 Lethal Trifecta：YOLO 模式的安全边界
  • 02 Skills 体系：Skills 是并行 Agent 之间共享的"工作模板"

第一章：从单 Agent 到并行 Agent 的范式跃迁​

1.1 瓶颈不是 AI，是审核​

很多工程师对并行 Agent 第一反应是怀疑：

"AI 写的代码本来就需要审核，审核才是瓶颈。同时跑 3 个 Agent 只会让我更跟不上。"

这个直觉对了一半。Simon Willison 自己一开始也这么想，但实际用了几周后发现：

我一次只能盯着 1 个重要改动。但有越来越多任务可以同时丢出去，不会给我主线工作增加太多认知负担。

关键在于区分"需要立刻盯着的任务"和"可以丢出去的任务"。后者占比比直觉中大得多。

1.2 任务的认知成本分级​

高认知负担（必须盯着）
├── 复杂业务逻辑修改
├── 需要架构决策的工作
└── 不熟悉的代码库的核心改动

中认知负担（可以并行，但要 review）
├── 已有规范下的功能添加
├── 重构（renaming、提取函数）
└── 写测试

低认知负担（适合丢出去异步执行）
├── 修 lint/typecheck 警告
├── 升级依赖、修复 deprecation
├── 探索性研究（不打算用代码）
└── "这块代码怎么工作的？"问答

并行的本质：把低认知负担任务从你的"主线"里剥离出去，让它们后台跑，你只在结果回来时花 1-2 分钟 review/合并。

1.3 并行的几种形态​

形态特点适合场景代表工具
多终端同步多个本地 CLI Agent主动派活，立刻看进度Claude Code + Codex CLI
Git worktree 并行同一 repo 多个 checkout改不同模块互不干扰任何 CLI Agent
云端异步派给云上 Agent，事后看我去做别的事Codex Cloud, GitHub Copilot Coding Agent, Jules
Architect-Implementor一个规划，一个执行复杂任务Claude Code (架构) + 多个 worker

第二章：四种核心并行模式​

这四种模式是 Simon Willison 2025 年 10 月文章的精炼，覆盖 80% 实际场景。

2.1 模式 A：研究型 Proof-of-Concept​

任务特征：你需要回答"X 库能不能这么用"、"Y 方案是否可行"，但不打算保留代码。

# 例：评估 Yjs + Python 协同编辑可行性
$ cd /tmp/poc-yjs
$ git clone https://github.com/yjs/yjs
$ git clone https://github.com/y-crdt/pycrdt
$ claude
> 请用 Yjs 和 pycrdt 写一个最小协同笔记 demo，
> Python 后端 + 简单前端，验证能不能跑通。
> 你可以读这两个 repo 的源码理解 API。

派出去后你去做别的。一小时回来看结果：

  • 跑通了 → 知道方案可行，回主线项目自己实现
  • 跑不通 → 看 Agent 在哪卡住，知道哪里有坑
  • 模型给了错误的实现 → 了解一下"模型理解的是什么"，调整自己的判断

关键洞察：研究的产出不是代码，是认知。所以即使代码全错，也已经"赚到"了。

2.2 模式 B：「这块代码怎么工作的？」​

任务特征：你需要理解既有代码，但不需要修改。

你在主线工作，突然想知道"我们的会话 cookie 在哪签名验证的？"

旧做法：暂停主线 → grep 半小时 → 切回主线（已经忘了上下文）

新做法：另开终端
> claude
> 请详细分析这个 codebase 中 session cookie 的设置和验证流程，
> 标出所有相关文件和行号，最后给一段简短总结。

Agent 用 grep 和文件遍历，几分钟后给你一份带文件:行号的报告。这份报告本身就是宝贵的上下文——下次让 Agent 改 cookie 相关代码时，直接把这份报告粘进去当上下文，比让它再 grep 一遍更准。

复利效应

这种"研究报告"建议存到 .claude/notes/ 或类似目录。日积月累，你的 codebase 就有了一份高质量的"AI 友好的注释"。

2.3 模式 C：小维护任务​

任务特征：低风险、明确目标、修了就完事。

典型场景：

  • 测试套件吐 deprecation 警告 → "跑测试，找出警告，修掉"
  • TypeScript 某个文件类型错乱 → "修复 src/foo.ts 的所有类型错误"
  • 升级 minor 版本依赖 → "把 react 从 18.2.x 升到 18.3.x，处理任何破坏"
  • 补 JSDoc 注释 → "给 src/utils/ 下所有导出函数补 JSDoc"
  • 修 i18n 漏翻译 → "扫描所有 t() 调用，找出 zh.json 里漏的 key"

这些任务的共同点：

  1. 你确切知道想要什么
  2. 完成判定机械可验证（测试通过/类型检查通过/lint 0 错）
  3. 出问题最坏只是回滚一个 commit

派出去后用 1-2 分钟扫一眼 diff 合并即可。

2.4 模式 D：受指导的实际工作​

任务特征：你已经规划好做什么、怎么做、关键约束是什么，AI 负责按规划执行。

这是 Simon 称为"权威主义"（authoritarian）的提示风格：

不要这样（开放式）：
> 帮我重构购物车状态管理

要这样（受指导）：
> 把购物车状态从 Redux 迁移到 Zustand。具体步骤：
> 1. 先创建 src/stores/cart.ts，导出 useCartStore，
>    schema 跟 src/redux/cartSlice.ts 一致
> 2. 替换 src/components/Cart/ 下所有 useDispatch/useSelector
>    为 useCartStore
> 3. 暂时不要删除 redux 文件，加 // TODO: remove 注释
> 4. 跑 pnpm typecheck 和 pnpm test 确认通过
> 
> 关键约束：
> - 不要改组件 props，只改内部 state 来源
> - 不要引入新依赖（zustand 已经在 package.json）
> - 不要碰 src/api/，那是另一个迁移

为什么这样有效：

  • 你已经做完了"想"的工作，AI 只做"执行"
  • Review 时只需检查"是否按规划做了"，不需要重新想"该不该这么做"
  • 适合在你主线工作旁边派出去——主线想完，副线交给 AI 执行

第三章：Git Worktree 模式​

3.1 痛点​

当你想让两个 Agent 在同一个 repo 上同时改不同文件时，问题来了：

# Agent 1
cd ~/projects/myapp
claude  # 改前端

# Agent 2
cd ~/projects/myapp  # 同一个 repo！
claude  # 改后端
# → 两个 Agent 互相覆盖未提交改动

直接复制目录可以，但同步主分支麻烦。git worktree 是更优雅的方案。

3.2 Worktree 实战​

# 主仓库不动
cd ~/projects/myapp

# 创建第二个 worktree（独立工作目录，但共享 git history）
git worktree add ../myapp-backend -b feature/backend-refactor

# 创建第三个
git worktree add ../myapp-types -b feature/types-cleanup

# 现在你有 3 个目录，每个都是独立的 working copy
ls ~/projects/
# myapp/         <- 主线，处理紧急 bug
# myapp-backend/ <- Agent A 改后端
# myapp-types/   <- Agent B 清类型

# 三个终端各开一个 claude

每个 worktree 共享 .git 但有独立的 working files，互不干扰。

3.3 Worktree 的工程化​

# 包装脚本：一键创建 agent worktree
#!/bin/bash
# scripts/agent-worktree.sh
TASK_NAME="$1"
WORKTREE_DIR="../myapp-agent-$TASK_NAME"
BRANCH="agent/$TASK_NAME"

git worktree add "$WORKTREE_DIR" -b "$BRANCH"
cd "$WORKTREE_DIR"

# 自动复制必要的本地文件（.env、CLAUDE.md 等）
cp ~/projects/myapp/.env.local "$WORKTREE_DIR/" 2>/dev/null || true

# 启动 agent
echo "Worktree 在: $WORKTREE_DIR"
echo "分支: $BRANCH"
echo "进入后跑 claude 开始任务"

完事后：

# 合并：用普通 git 流程
cd ~/projects/myapp
git merge agent/backend-refactor

# 删除 worktree
git worktree remove ../myapp-backend
git branch -d agent/backend-refactor

3.4 Worktree 的实战边界​

适合：

  • 改不同模块（前端 vs 后端，A 服务 vs B 服务）
  • 探索性方案（同一问题让两个 Agent 用不同思路解）
  • 一个跑测试，一个改代码

不适合：

  • 改同一个文件（合并冲突地狱）
  • 涉及全局重构（命名变更）
  • node_modules 等大依赖（每个 worktree 独立 npm install 很慢，可用 pnpm 软链）

第四章：异步云端 Agent​

4.1 为什么要异步​

本地 CLI Agent 有个隐藏成本：它在跑，你电脑就在转，你心里就有"我得关注它"的负担。即使你没盯着，潜意识也分心。

云端异步 Agent 解决这个：派活之后它在云上跑，跟你电脑无关，结束发通知。你可以：

  • 关电脑去吃饭
  • 派 5 个任务一起跑
  • 在地铁上用手机派活，回家看结果

4.2 主流云端 Agent 对比​

工具厂商特点状态（2025末）
Codex CloudOpenAIChatGPT 内置，能从手机派活GA
GitHub Copilot Coding AgentGitHub集成在 PR / issue 流程里GA
Google JulesGoogle免费 alternativeGA
Claude Code for webAnthropic异步版 Claude Code2025-10 推出
GitHub Codespaces + agent modeGitHub浏览器里完整 VS Code适合演示

4.3 异步派活模式​

手机派活流程：

1. 通勤路上想到一个改进
2. 在 ChatGPT 手机 App 进 Codex Cloud
3. 输入 "把 src/api/auth.ts 的错误处理统一成 Result<T> 模式"
4. 派出去
5. 几小时后回家，PR 已经创建
6. 在电脑 review、合并

风险隔离：异步 Agent 默认有完整网络访问。Simon 提到：

我现在用 Codex Cloud 处理风险任务，因为最坏情况只是源码泄露。我做的大多是开源项目，所以不太担心。

翻译成实践：异步云端 Agent 不要碰你的私有 repo / 商业代码 / 含密钥项目。用于开源项目或可公开内容。

4.4 异步任务的提示风格​

异步任务不能交互——派出去后你不在线，Agent 出问题不能问你。所以：

❌ 不要：开放式提示
> 帮我看看怎么优化这个查询

✅ 要：完整自包含的指令
> 优化 src/db/queries.ts 中 getUserOrders 函数。
> 当前问题：N+1 查询，每个 user 查一次 orders。
> 期望：用 join 一次查完。
> 验证方式：跑 pnpm test:db，所有测试必须通过。
> 限制：不要改函数签名，调用方代码不能改。
> 不确定时：保留原实现，输出报告说明无法优化。

每一条都是为了"你不在场也能完成或安全失败"。

第五章：YOLO 模式与沙箱​

5.1 YOLO 是什么​

Claude Code 和 Codex CLI 都支持 --no-approvals / --yolo 模式：不再每个工具调用都问用户，Agent 直接执行。

为什么需要：每次 review 工具调用打断节奏，对低风险任务不必要。

5.2 YOLO 的危险​

YOLO 意味着 Agent 可以：

  • 任意写文件
  • 跑任意 shell 命令
  • 安装任意 npm 包
  • 提交任意 git 操作

如果 Agent 处理过任何不可信内容（参考 04 Lethal Trifecta），YOLO 就是给攻击者一把钥匙。

5.3 安全 YOLO：Docker 容器隔离​

Simon 在 2025-10 反复强调：

我应该开始习惯把本地 agent 放进 Docker 容器跑，进一步限制爆炸半径。

实战配置：

# Dockerfile.agent
FROM node:22-slim

RUN apt-get update && apt-get install -y \
    git python3 build-essential curl \
    && rm -rf /var/lib/apt/lists/*

# 安装 Claude Code CLI
RUN curl -fsSL https://claude.ai/install.sh | bash

WORKDIR /workspace

# 限制网络（可选，最严）
# 默认有网络。如果要完全隔离，启动时加 --network none

CMD ["bash"]
# 启动 agent in container
docker run -it --rm \
  -v $(pwd):/workspace \
  -v ~/.claude:/root/.claude \
  -e ANTHROPIC_API_KEY \
  --memory=4g \
  --cpus=2 \
  agent:latest claude --yolo

特性：

  • 文件系统：只能写 /workspace（你挂进去的项目目录）
  • 资源：限制 CPU/内存
  • 命令：在容器里 rm -rf / 也只删容器
  • 网络：可选完全隔离（但许多 agent 任务需要网络下载）

5.4 何时不该 YOLO​

即使在 Docker 里，以下情况避免 YOLO：

  • Agent 会接触任何不可信内容（issue、邮件、网页）
  • 项目里有真正的密钥（即使是 .env.example 也别）
  • 改动会触发 deploy/payment 等不可逆操作
  • 你不熟悉 Agent 用的工具集

第六章：Architect → Implementor 工作流​

6.1 来自 Jesse Vincent 的实战模式​

Jesse Vincent 在 2025 年 10 月分享了他的并行 Agent 工作流，核心是：

Architect Agent (一个，长期运行)
  ↓ 产出详细规划文档
Implementor Agents (多个，每个 fresh 实例)
  ↓ 按规划实现
Architect Review
  ↓ 反馈
Implementor 修正

6.2 Architect 的角色​

你 → Architect：「我想加个 dark mode」

Architect 输出：
- 影响哪些文件
- 改哪些 token / variables
- 怎么测试
- 分几步实现
- 每步的 acceptance criteria
- 哪些边界情况要处理

→ 写成详细 spec.md

Architect 阶段不写代码，只设计。这一步用 Sonnet 4.5 / Opus 这种推理强的模型，慢慢想。

6.3 Implementor 的角色​

# 每个步骤一个 fresh agent（避免长上下文污染）
git worktree add ../myapp-step1
cd ../myapp-step1
claude
> 严格按 spec.md 第 1 步实现。完成后跑 pnpm typecheck && pnpm test。
> 不要做 spec 之外的事。

Implementor 用 Haiku / 便宜模型够了——它的工作是"机械执行"。

6.4 Review 与迭代​

Architect 看 Implementor 的产出：

你 → Architect：「这是 step 1 的 PR diff，按 spec 检查」

Architect 反馈：
- ✅ 实现符合 spec 1.1, 1.2
- ⚠️ spec 1.3 没实现（漏了 reduced-motion 处理）
- ❌ 1.4 实现了但破坏了 1.5 的隐含约束

→ 反馈交给 Implementor 修正，或重写 spec

这种循环把"创意"和"执行"分离，让你只在创意层面思考，执行层面成本极低。

第七章：Send Out a Scout 模式​

7.1 什么是 Scout​

Josh Bleecher Snyder 在 The 7 Prompting Habits 提出：

派一个侦察兵：把任务给 Agent 是为了发现哪里是难点，这样你就不用犯那些错。

7.2 实战例子​

任务：给 monorepo 加 turbo（构建加速工具）

不要：自己上来配 turbo.json，配半小时发现某个包有 cyclic dep

要：
> claude
> 请在我的 monorepo 加 turbo。配置 turbo.json，
> 改 package.json scripts，确保 pnpm build 能跑。
> 你可能会遇到一些坑，遇到就在 README 里记下来。

派出去。不在意 Agent 的代码。回来：

  • Agent 说"配置好了"→ 看它做了什么，自己重做一遍（更干净）
  • Agent 说"卡在 X"→ 这就是 scout 的价值，你知道接下来要解决什么
  • Agent 失败但试了 5 个方向→ 你少试 4 个错的方向

7.3 Scout 的工程价值​

Scout 模式的核心认知：Agent 的成本远低于你的时间。

  • Agent 派出去：5 美元 token + 30 分钟（你不用盯）
  • 你自己探索：3 小时 + 严重消耗你的"主线项目专注度"

即使 Agent 失败了，你也"用 5 美元买到了 30 分钟的并行探索时间"，赚了。

第八章：实战工作流模板​

8.1 我的"日常并行栈"​

参考 Simon Willison 当前的常用配置（2025-10）：

日常工具：
- Claude Code（Sonnet 4.5）：本地主力
- Codex CLI（GPT-5-Codex）：本地辅助 / 对比意见
- Codex Cloud：异步任务 / 手机派活
- Codex Cloud / Jules / Copilot Coding Agent：异步任务

物理布局：
- 主显示器：主线工作
- 副显示器：2-3 个终端，每个跑一个 Agent
- 手机：随手派异步任务

工作流：
- 主线：自己写或带 1 个 Agent 边写边帮
- 副线 1：研究/调研类任务
- 副线 2：小维护任务
- 异步：耗时长的任务，云端跑

8.2 一周节奏​

时间主要工作并行任务
周一上午规划周计划，Architect 规划 1-2 个大任务派出 3-5 个低优先级维护任务到 Codex Cloud
周二-周四主线开发主显示器主线，副线 2-3 个并行 Agent
周五上午Review 这周的异步 PR合并 / 反馈
周五下午整理 spec、写文档派文档相关任务

8.3 反模式​

反模式后果修正
同时 5+ 个 Agentreview 跟不上，质量下降限制并行 ≤ 3，多了用异步
主线高强度时还盯着副线主线效率下降主线高难度时停掉副线
异步 Agent 用在私有项目Trifecta 风险异步只用于开源 / 公开项目
把 architect 和 implementor 合并上下文污染、质量差严格分离，fresh implementor
不用 worktree，直接 cd改动互相覆盖每个 Agent 一个 worktree
YOLO 不进 Docker全机器风险至少 Docker 隔离

第九章：未来方向​

9.1 Agent 编排平台​

类似 Kubernetes 之于容器，未来会有 Coding Agent 编排平台：

  • 队列：派出去的任务排队
  • 调度：根据资源、优先级分配 Agent
  • 隔离：自动 worktree / Docker
  • 协作：Architect/Implementor 自动 hand-off

这块在 2026 年应该会有更成熟产品。

9.2 Agent 间协议​

多 Agent 协作需要标准协议——超出 MCP 的范畴：

  • Architect 怎么把 spec 给 Implementor
  • Implementor 怎么报告进度
  • 多 Agent 怎么避免冲突

业界还在试验。

9.3 持续运行的"驻场 Agent"​

不是派活 → 完成 → 关掉，而是一直运行：

  • 监控仓库变化，主动建议改进
  • 监控 issue tracker，自动尝试解决
  • 每天给你一份"昨夜我做了什么"报告

GitHub Copilot Coding Agent 已经在这个方向。

权威资料​

核对日期：2026-06-12