你让 Claude Code “把这 146 份 Markdown 都翻译成英文、日文、韩文、法文和西班牙文，再检查链接和代码块”。如果只开一个会话，它当然能做，只是会很慢，而且做到第 30 个文件时，前面哪些完成、哪些失败、哪些需要重试，开始变成一团账。

多数人听到 “多 Agent” 的第一反应是多开几个 Claude。这个想法不算错，但还缺了最麻烦的部分：谁来拆任务，谁能改哪些文件，结果放在哪里，前一个阶段没完成时后一个阶段能不能启动，失败的任务如何重跑，审校者拿到的是原文还是译文，以及 730 个任务为什么不该一口气启动 730 个会话。

这篇文章讲的就是这件事。它参考 AI少年关于 Claude Code Dynamic Workflow 的原始材料，但不把 “一条命令调度几百个 Agent” 当作魔法。我们会把它拆成可检查的工程问题。

先说一个版本边界。本文保留 “动态工作流” 这个说法，用它指代”把大量相互独立的工作分阶段并行执行、校验和汇总”的编排方式。Anthropic 当前公开文档明确说明了 Subagents、Agent Teams、Agent view 和 worktree 会话，却没有把名为 Dynamic Workflow 的独立产品能力写成一份可引用的通用规范。因此，参考材料中出现的特定 UI、/workflows、/effort、并发上限和开关名称，都只能视为某个版本或某个客户端的实操观察，不能当作所有 Claude Code 安装环境都具备的承诺。本文会把可迁移的方法讲清楚，产品命令请以你本机版本的帮助和官方文档为准。

读完后，你应该能自己回答这些问题：

1. SubAgent、Agent Teams 和动态工作流分别解决什么问题；
2. 为什么 “能并行” 不等于 “适合并行”；
3. 怎样把一个大任务写成可交给很多 Agent 的任务清单；
4. 怎样让翻译、测试、代码审查这类批量任务能失败重试，而不是半途变成残局；
5. 怎样估算并发数量，控制 Token、权限与文件冲突；
6. 没有某个特定的 Workflow 开关时，怎样仍然用 Claude Code 的公开能力做出同样的编排思路。

封面图来自参考材料附带的图片。文中对 Claude Code 公开功能的说明以 Anthropic 官方文档为准；示例中的目录、任务编号和提示词均为教学设计。

先把场景缩小：730 个交付物不是 730 个同时运行的会话

146 份文档翻译成 5 种语言，表面上是 146 × 5 = 730 份译文。实际工作量远不止把文字替换成另一种语言。每个译文至少要经过下面几件事：

• 读原文，判断标题、正文、代码、链接和 front matter 哪些可以翻；
• 生成目标语言文件，保持文件名、链接和 Markdown 结构可用；
• 检查代码块、URL、图片路径、表格和锚点是否被误改；
• 把结果登记为成功、待复核或失败，供下一阶段读取；
• 对失败项重试，或交给人工处理。

一个合格的工作流先定义 730 个可验证的工作单元，再决定同一时刻让多少单元运行。任务模型和并发是两件事，别把后者当成前者。

把问题写成一张最小任务表，会比一句 “批量翻译” 清楚得多：

这里有一个很实用的判断标准：如果你无法把任务写成这样一行记录，它通常还不适合交给大量 Agent。你还没有把”做什么、读什么、产出什么、成功是什么”说清楚。此时多开会话只会更快地制造混乱。

多 Agent 之前，先理解一个 Agent 到底在做什么

Claude Code 不是一个会自己无限运行的机器人。它是在一个循环里工作：读取当前上下文，决定下一步，调用允许的工具，读取工具结果，再决定下一步。读文件、搜索代码、编辑文件、运行测试，都是这个循环中的动作。

单 Agent 做任务时，所有内容都堆进同一个上下文。它既要记住用户目标，也要看文件内容、命令输出、失败日志和自己的修改历史。这对一个小改动很方便，因为信息不用来回传递；对一项会产生海量输出的工作却很吃力。比如跑完整测试、扫描几百个文件、抓取大量文档，原始输出很可能只在当下有用，之后留在主会话里反而干扰判断。

Anthropic 对 SubAgent 的定位很准确：把会淹没主会话的搜索结果、日志或文件内容放进独立上下文，最后只回传必要摘要。官方子代理文档还特别提到，子代理很适合隔离高输出操作，例如跑测试或处理日志。

因此，”多 Agent” 最先解决的是上下文边界。让许多模型同时运行，只是它可能带来的后续收益。

下面这张图把三种常见协作形态放到同一条线上：

  flowchart LR
  A["主会话\n任务小、反馈快"] --> B["SubAgent\n独立子任务，返回摘要"]
  B --> C["Agent Teams\n多人讨论、共享任务表"]
  B --> D["动态工作流\n阶段化、批量、可恢复"]
  C --> E["需要协商的复杂问题"]
  D --> F["大量可验证的重复任务"]
  

注意图里 Agent Teams 和动态工作流从不同方向长出来。它们都可以使用多个 Agent，却不是同一件事：前者增加通信，后者压缩通信。

SubAgent：把一件边缘工作交出去，再收一份摘要

SubAgent 最像一个你临时请来的专员。主会话写清任务，子代理在自己的上下文里读文件、搜索、运行允许的工具，完成后把结果交回主会话。它没有义务了解主会话所有聊天记录，主会话也不必接收它看到的每一行日志。

例如你正在修一个登录问题，主会话可以交给一个只读子代理：

1
2
3
4
5
6

请在仓库内定位所有与 redirect、session、cookie 写入有关的代码。
不要修改文件。输出不超过 20 行：
1. 涉及的文件路径；
2. 每个文件的关键函数和行号；
3. 你认为最可能的调用顺序；
4. 仍缺少的证据。

这个提示词好在四件事。

第一，它限定了范围。子代理不需要研究整个仓库。

第二，它限定了权限。它只读，不会顺手改文件。

第三，它规定了交付格式。主会话拿到的是能直接用的定位结果，不是一篇搜索日记。

第四，它允许说 “还缺少的证据”。这比让子代理硬猜一个答案更可靠。

官方文档说明，每个子代理有独立上下文窗口，且可以用工具白名单或黑名单限制能力；例如只给 Read、Grep、Glob 和 Bash，就可以让研究代理无法编辑文件。自定义 SubAgent 的配置方式也是 Markdown 加 YAML front matter，因此它很适合把反复使用的角色沉淀进项目。

一个保守的研究代理可以长这样：

1
2
3
4
5
6
7
8

---
name: repository-researcher
description: 用于定位代码、梳理调用链和收集证据。只在需要大量只读探索时使用。
tools: Read, Grep, Glob, Bash
---

先给出结论，再列出证据路径和未确认项。
不要编辑文件，不要运行会写入项目的命令。

SubAgent 的边界：它不是一个可以无限分裂的树

初学者很容易继续追问：主代理能派子代理，子代理再派两个，两个再各派十个，不就很快了吗？公开文档给出的约束是，普通子代理不能再生成子代理。原因在于要避免无限嵌套、权限扩散和难以追踪的成本。

这意味着真正的调度责任仍在主会话或外部编排器。你需要由一个明确的角色维护任务清单、限制并发、接收结果，再决定下一批。把这一层交给”任何一个工人临时发挥”，任务一大，状态就很容易失控。

什么时候别用 SubAgent

如果任务只是 “把这个函数改名，并跑一条测试”，启动一个新上下文、解释任务、等待摘要返回的时间，可能比主会话直接做更长。官方建议也很一致：任务需要频繁来回、多个阶段高度共享背景、或者只是一次小而明确的改动时，留在主会话通常更快。如何在主会话与子代理之间选择

所以 SubAgent 不是性能开关。它是一种隔离手段。只有当隔离掉的噪声、权限风险或独立工作量大于交接成本时，它才划算。

Agent Teams：当工人之间真的需要说话

假设现在要给一个老项目做支付重构。有人负责梳理旧订单模型，有人负责新的支付状态机，有人负责迁移脚本，还有人写回归测试。这里的工作会不断变化：数据模型一改，迁移方案可能要调整；测试发现边界条件，状态机也要改。

这时让四个子代理各自埋头做完再汇总，往往不够。它们需要共享进度，也需要相互发消息。Agent Teams 的设计正是为这种小规模协同准备的。

Anthropic 文档把一个团队拆成四个部件：团队负责人负责创建和协调，teammates 是各自独立的 Claude Code 实例，任务列表保存可领取的工作项，邮箱负责成员之间的消息。每个队员有自己的上下文，队员可以彼此通信，依赖任务完成后会解锁后续任务。

1
2
3
4
5

负责人：维护目标、拆任务、处理冲突、决定合并顺序
数据模型队员：提出状态字段与迁移影响
支付流程队员：实现状态机和接口适配
测试队员：根据接口变动更新回归测试
审查队员：检查并发修改和异常路径

在这里，通信本身构成任务的一部分。数据模型队员发现某个历史状态无法无损迁移，就该尽快通知支付流程和测试队员，别等到全部工作结束后才在汇总里说一句 “有风险”。

为什么团队不要开太大

每个 teammate 都是一个完整会话，有自己的上下文和工具调用。人数越多，不只是 Token 增长，消息数量也会增长。五个人互相同步时，可能产生的沟通边数是十条；十个人时是四十五条。它们不需要每次都互发消息，但协调成本确实会随着人数变大。

这就是为什么公开文档把 Agent Teams 标为实验性能力，并提醒它比单会话消耗更多 Token。并行 Agent 的选择指南建议的判断很朴素：任务是否需要直接沟通？是否需要一个主线程计划、分配和监督？如果答案是肯定的，团队才有意义。

团队适合”问题还在变化”的工作。翻译 730 个独立文件却让每个译者随时讨论术语，通常会把原本可批量处理的任务，变成昂贵的群聊。

动态工作流：用阶段和契约编排批量任务

现在回到最初的翻译任务。它需要大量 Agent 吗？需要。它们需要彼此聊天吗？大多数情况下不需要。

每一个翻译任务只要拿到四样东西就能开工：原文件路径、目标语言、术语表、输出路径。它完成后不需要告诉其他译者 “我翻完了第 37 份”，只需要把状态写进任务清单，把文件放到约定位置。审校阶段稍后读取这些结果即可。

这就是本文所谓的动态工作流：一个调度者根据任务清单不断决定下一批可运行单元，按阶段执行，收集结构化结果，通过质量闸门后再推进。它可以调度 SubAgent，也可以由外部脚本调度多个独立会话；关键不在于某个菜单名称，而在于下面这条链路是否完整：

  flowchart TD
  A["输入清单\n文件、语言、规则"] --> B["规划\n生成任务图"]
  B --> C["阶段 1：预检查\n编码、链接、front matter"]
  C --> D{全部通过?}
  D -->|否| E["记录失败\n修复输入或人工处理"]
  D -->|是| F["阶段 2：并行执行\n受控并发"]
  F --> G["写入产物与结果记录"]
  G --> H["阶段 3：独立复核\n结构、链接、术语"]
  H --> I{质量闸门通过?}
  I -->|否| J["只重试失败项\n增加 attempt"]
  J --> F
  I -->|是| K["阶段 4：汇总\n报告、提交、交付"]
  

图中的 “动态” 有两个意思。

一是任务数量不必在一开始写死。预检查发现一份文档含有 20 张图片，可能额外创建图片 alt 文本检查任务；审校发现术语冲突，可能创建一个术语修订任务，再让受影响的译文回流。

二是下一步取决于结果，而不是只按一条直线往下跑。成功任务进入审校，失败任务带着错误原因重试，依赖未满足的任务保持等待。真正有用的工作流必须认识状态，否则它只能算批量执行。

工作流的最小角色分工

不要把所有角色都叫 “Agent”。名称清楚，排错会轻松很多。

执行者与校验者最好分开。让同一个 Agent 既翻译又宣布 “我的译文完全正确”，并不是不能用，但它缺少第二个视角。分开后，校验者至少能在不同的提示词、不同的上下文和不同的检查清单下发现结构性遗漏。

任务拆分：并行化的前提是没有隐藏依赖

并行失败，常常是因为拆分时偷偷留下了共享状态，而不是模型不够聪明。

例如下面这句需求看起来可以并行：

为 50 个页面统一更新导航链接。

实际却有两种完全不同的情况。

第一种，每个页面的导航都由独立 front matter 生成，任务可以按页面拆开。每个执行者只改自己的文件，最后跑一次全局链接检查。

第二种，50 个页面都引用同一份导航模板。此时让 50 个 Agent 同时改，等于让 50 个人抢写同一个文件，结果大概率是覆盖、冲突或反复改回去。正确拆法是：一个任务改模板，另一些只读任务检查页面引用是否兼容，模板合并后再跑全量验证。

判断能否并行，先问下面四个问题：

1. 两个任务会不会写同一个文件、同一个数据库记录或同一个外部系统对象？
2. 任务 B 的输入是否依赖任务 A 尚未产生的输出？
3. 两个任务是否必须对同一份模糊规则做一致判断，例如术语翻译或 API 设计？
4. 任务完成后能否用独立检查证明结果正确？

前两个问题回答 “会”，通常要把任务串行化，或用 worktree、锁和合并步骤隔离。第三个问题回答 “会”，先产出共享规范，再并行执行。第四个问题回答 “不能”，说明你还没有设计质量闸门，先别扩大规模。

用输入和输出定义任务，而不是用一句动词定义任务

“检查认证模块” 不是一个好任务，因为谁也不知道检查到什么算结束。

下面这个版本可执行得多：

1
2
3
4
5
6

任务：审查 auth/ 下的会话固定风险
输入：auth/ 目录、当前路由表、测试目录
允许工具：只读搜索与运行测试
输出：reports/auth-session-review.json
成功条件：JSON 包含 findings、evidence、severity、unverified 四个字段
限制：不修改源代码；没有证据的结论必须写入 unverified

这份任务说明没有让 Agent “更聪明”，却让调度、重试和人工审阅都变得可操作。你可以把它放进任务表，失败后原样重发，也可以把输出交给另一个校验者检查 schema。

一个能恢复的工作流，需要状态机，不是进度条

网页上显示 “已完成 428/730” 很让人安心，但它不够。进度条只告诉你数量，无法告诉你第 429 个任务是根本没开始、模型超时、输出不合法、校验失败，还是等待某个依赖。

给每个任务设计少量明确状态：

1
2
3
4
5
6
7
8

queued      已创建，等待调度
running     某个执行者已领取
succeeded   执行成功，产物已写入
reviewing   等待或正在质量检查
retryable   可自动重试，例如超时、临时限流、输出 JSON 不合法
blocked     依赖未满足，或需要人工决定
failed      已超过重试次数，保留错误证据
skipped     人工确认不需要处理

状态之间也要有规则。比如 running 不能无限停留。调度者给任务附一个租约：10 分钟内没有心跳或结果，租约过期，任务回到 retryable。如果执行者其实还在运行，它随后提交结果时必须带任务版本号，调度者只接受仍属于它的那一版，避免两个执行者同时写入同一结果。

听起来像是做了一个小型分布式系统，确实如此。Agent 数量一旦上去，问题就不再只是提示词工程，也开始包含分布式系统最常见的麻烦：重复执行、超时、部分失败、顺序不确定和不可重复的外部副作用。

幂等性：重试前先问”再做一次会怎样”

把同一份 Markdown 翻译到固定输出路径，通常可以重试。最多是覆盖同一份候选译文，只要保留版本或 diff，风险可控。这种任务接近幂等：执行一次和执行两次，最终状态相同。

但 “给 1,000 个用户发送邮件”、”创建支付订单”、”执行数据库迁移” 就完全不同。重试可能给用户发两封邮件、扣两次款、迁移两遍数据。它们必须带去重键、预览、人工确认或事务边界，不能因为模型超时就盲目重跑。

把任务按副作用分层，是工作流里最实用的一条安全线：

Claude Code 的权限机制是另一层防线。公开文档支持通过 allow、ask、deny 等规则管理工具调用。设置与权限文档里的规则无法替代工作流设计，却能阻止一个本不该写文件的研究代理获得写权限。把”任务不需要什么能力”写进工具限制，通常比事后要求模型小心更可信。

并发数怎么定：用吞吐和失败率决定，而不是追求”几百个 Agent”

假设每个翻译任务平均花 90 秒。理想情况下，10 个并发任务用时约为 730 × 90 ÷ 10，也就是 109.5 分钟。这个数字只是一条下界，因为现实还会遇到：

• 模型请求限流和排队；
• 长文档比短文档慢得多；
• 工具调用、读写磁盘和网络请求占时间；
• 失败重试与质量复核；
• 同一台机器的 CPU、内存、文件描述符和网络带宽限制；
• 同时运行太多会话后，错误率上升。

所以并发数应该从小开始做压测，而不是从电脑能启动多少终端来决定。一个很实用的启动方式是 4 个并发，观察 20 到 30 个任务后再调到 8、16。每次只改一个变量，并记录四个指标：

如果从 8 并发升到 16 并发，完成速度只提升 10%，而限流和格式失败翻倍，就应退回 8。更高的并发不是免费午餐，它只是把等待从队列搬到了模型服务、网络或你的错误处理逻辑里。

Token 成本为什么常常被低估

一个 Agent 不只消耗最终回答那几行字。它还要读系统提示、任务说明、相关文件、工具定义、历史消息以及校验要求。团队模式中，每个 teammate 都有自己的上下文；大量独立执行者中，每个任务又会重复载入公共规则。

这也是为什么术语表、风格指南和输出 schema 要短而稳定。不要把 3 万字项目文档塞给每一个翻译代理。更好的做法是把真正通用的约束压缩为一份可引用的规则，例如：保留代码块、front matter 键不翻译、站内相对链接只改目标语言前缀、产品名保持原样。遇到某个领域才需要的背景，再按任务附加。

成本控制并不等于把提示词写得越短越好。缺失约束导致返工，同样会消耗 Token。目标是每个执行者只拿到完成当前工作所需的最小充分信息。

质量闸门：让 “完成” 有客观含义

大规模任务最容易出现一种假成功：730 个任务都返回了 “done”，但其中 40 份译文的代码块被翻译，15 份内部链接失效，几篇文档漏掉了 front matter。模型的自然语言自评不能解决这个问题。

质量闸门应该尽量使用机器能检查的条件，再把真正需要语言判断的部分留给独立审校。

对于 Markdown 翻译，我会分三层检查。

第一层：结构检查

这是完全确定的规则，不需要让语言模型猜。

1
2
3
4
5
6
7

检查项：
- 输出文件存在，且路径等于任务表中的 output
- front matter 的键集合与原文一致
- fenced code block 的数量、语言标记和内容哈希一致
- 图片数量和图片路径未丢失
- 外部 URL 集合没有被改坏
- Markdown 标题层级没有跳级

这里的 “内容哈希一致” 很有用。代码块不应被翻译，可以把每个代码块的内容提取出来哈希，源文件和译文逐个对照。这样一份看起来流畅、实际改坏了命令的译文，会在进入人工审阅之前被拦下。

第二层：规则检查

有些规则不能只靠字符数量判断，但仍可以写成明确约束。例如术语表规定 Claude Code、SubAgent、Agent Teams 不翻译，文档标题中的产品名保持英文，中文句号不应出现在 URL 内。这些规则可以让一个校验代理逐项输出：通过、不通过、证据位置、建议动作。

校验代理的交付物应当像这样，而不是一段 “整体质量良好”：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

{
  "taskId": "guide-auth__ja",
  "passed": false,
  "findings": [
    {
      "rule": "code-block-preserved",
      "severity": "high",
      "evidence": "第 42 行的 npm test 被改写为自然语言"
    },
    {
      "rule": "terminology",
      "severity": "low",
      "evidence": "第 18 行把 Agent Teams 翻成了不在术语表内的名称"
    }
  ]
}

第三层：抽样语言审校

翻译是否自然、是否误解上下文，仍然需要语言能力判断。不要把 730 份都交给同一类型的模型重复检查，然后以为独立性已经存在。更稳妥的做法是抽样覆盖不同长度、不同主题和不同失败历史的文件；对高风险文档，例如安装说明、法律文本、支付说明，提升到人工审校。

这一步是为了区分哪些结果可以放心交付，哪些结果必须停下来处理。

146 份文档翻译成 5 种语言：从一句需求到任务图

现在把上面的概念合在一起，完整设计一次工作流。这个案例不依赖某个私有命令。你可以用 Claude Code 主会话配合 SubAgent，也可以用 CI、队列系统或任何能运行任务的调度器实现同一套结构。

第 0 步：先冻结输入和规则

不要一边翻译，一边让编辑继续大改原文。至少记录一个 Git commit、输入文件清单和术语表版本。否则第 1 个任务读的是旧原文，第 700 个任务读的是新原文，最后你无法解释差异从哪里来。

目录可以约定成这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

docs/
  guide-auth.md
  guide-install.md
i18n/
  en/
  ja/
  ko/
  fr/
  es/
workflow/
  inventory.json
  glossary.yml
  tasks.jsonl
  results/
  reports/

inventory.json 只记录输入事实，例如路径、文件哈希、标题、代码块数量和是否含图片。glossary.yml 记录术语。把它们和任务表分开，是因为前两者是输入快照，任务表是运行状态。

第 1 步：生成清单并预检查

先用只读任务扫描 146 份文档，而不是立刻开始翻译。预检查要捕获两类问题：机器问题和内容问题。

机器问题包括编码异常、损坏链接、重复路径、无法解析的 front matter。内容问题包括某篇文件同时混有中英日三种语言、把秘密写进示例 .env、超长文件超出单个 Agent 的安全处理范围。

此阶段的输出应有统计，而不是一句 “扫描完成”：

1
2
3
4
5
6

输入文件：146
可直接进入翻译：139
需要拆分：3
缺少语言标记的代码块：2
含疑似密钥字符串：1
路径冲突：1

只有 可直接进入翻译 的文件才生成 5 个语言任务。其余先进入人工队列。这样做看似慢了一步，却避免了后面 15 个任务都因为同一份坏输入失败。

第 2 步：生成任务表，不让执行者自己发明文件名

一条任务记录可以使用 JSON Lines，便于逐条追加和恢复：

1

{"id":"guide-auth__ja","source":"docs/guide-auth.md","sourceHash":"8aa1...","locale":"ja","output":"i18n/ja/guide-auth.md","stage":"translate","status":"queued","attempt":0,"dependsOn":["inventory:guide-auth"]}

任务的 output 由调度者计算，不由执行 Agent 临时决定。这样同一个输入文件不会被两个任务写到同一个目录，也不会因为 Agent 自己换了命名风格而让后续检查找不到产物。

第 3 步：给执行 Agent 一份窄而完整的合同

下面的提示词比 “帮我翻译这篇文章” 多了一点约束，但它能大幅减少返工：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

你负责一个 Markdown 翻译单元。

输入文件：docs/guide-auth.md
目标语言：ja
输出文件：i18n/ja/guide-auth.md
术语表：workflow/glossary.yml

必须遵守：
1. 保留 YAML front matter 的键、代码块、URL、图片路径和锚点；
2. 不翻译术语表中标为 keep 的项目；
3. 只写入指定输出文件，不修改源文件和其他译文；
4. 完成后运行结构检查；
5. 最后仅返回 JSON：taskId、output、checks、warnings、needsHuman。

若无法满足某项约束，不要猜测。写入 needsHuman 并说明证据。

其中最重要的一句是 “只写入指定输出文件”。这是可并行的物理基础。让多个 Agent 改同一目录并不危险，危险的是它们改同一个路径或共享配置。

第 4 步：受控并发，不让所有任务同时起跑

调度逻辑可以很朴素。它不断选择状态为 queued、依赖已完成、且当前运行数低于上限的任务；提交结果后再推进下一批。

1
2
3
4
5
6
7
8

while 还有未终结任务：
  找出依赖已满足的 queued 任务
  在并发槽位允许的范围内启动它们
  收集完成、超时和失败结果
  将成功任务转入 reviewing
  将可恢复失败转入 retryable
  将不可恢复失败转入 blocked 或 failed
  启动下一批任务

从实现角度看，真正重要的是持久化。每次状态变化都写到文件、数据库或 CI artifact 中。进程崩了以后，新的调度器读任务表就知道哪些已成功，哪些可重试，而不是从 730 个任务重新开始。

第 5 步：独立校验，然后只回流失败项

翻译阶段成功，不等于交付成功。每份译文进入 reviewing 后，先跑结构检查，再跑规则检查。通过者变成 succeeded，失败者只重跑当前文件和当前语言。

这里不要犯一个常见错误：某个日文译文出错，就重新翻译同一源文件的全部五种语言。除非错误来自共享输入或术语表，否则这样会浪费成本，也增加已经正确的文件被再次改坏的机会。

如果规则检查发现术语表本身有问题，才创建一个新的全局任务：修订术语表版本，然后让受影响的任务进入新一轮。这个变化应在任务表里被记录为新的依赖，而不是悄悄在中途替换规则。

第 6 步：汇总交付，而不是只报一个百分比

最后报告应该回答交付负责人真正需要知道的事：

1
2
3
4
5
6
7
8

本次输入版本：a1b2c3d
已交付：704 / 730
已人工确认跳过：8
待人工处理：11
失败：7
总重试次数：39
结构检查失败最多的规则：代码块内容被改写
建议：把 shell 命令加入术语表和不可翻译片段规则

报告没有必要装作全绿。把 7 个失败项列出来，反而让下一次运行更容易改进。

文件冲突、worktree 与共享状态：代码任务比文档任务更难并行

文档翻译天然容易划分输出路径，代码改动就没这么幸运。两个 Agent 可能各自修改不同文件，却仍然通过同一个类型定义、接口契约或测试基线相互影响。

官方并行 Agent 指南建议，当多个任务会修改同一代码库时，使用 worktree 隔离工作区。worktree 与并行任务的说明值得认真看：隔离并不消除合并冲突，但它让每个 Agent 在自己的文件视图里工作，避免同时把未提交修改踩来踩去。

一个比较稳妥的代码工作流是：

1
2
3
4
5

主分支：只放已审查、已验证的改动
worktree A：实现 API 参数校验
worktree B：补充单元测试
worktree C：只读审查错误处理路径
集成阶段：负责人按顺序 cherry-pick 或合并，运行全量测试

这里有个看似反直觉的原则：把工作拆得越细，集成成本不一定越低。若 A、B、C 都在改同一个核心抽象，三份小 diff 最后仍要由一个人或一个主 Agent 理解、解决冲突、运行验证。此时更好的方案可能是一个 Agent 完成紧密相关的改动，另一个 Agent 做独立审查，而不是三个人同时写代码。

一张选择表：到底该用哪一种方式

也可以用一个更短的判断流程：

1
2
3
4
5
6
7

任务能否写出确定的输入、输出和验收条件？
  不能：先在主会话里澄清，不要并行。
  能：任务之间是否需要实时协商？
      需要：考虑小规模 Agent Teams。
      不需要：是否会产生大量重复、独立的单元？
          会：做阶段化工作流，受控并发运行。
          不会：使用一个或几个 SubAgent 即可。

把这张表当成决策顺序：先看依赖和通信，再看规模，最后才看你手边有哪些命令。

初学者最容易踩的八个坑

1. 先开很多 Agent，再想任务怎么拆

这和先雇 100 个人，再决定公司做什么没有区别。先写任务表和输出契约，之后再增加并发。任务定义不清时，一个 Agent 会犯的错，100 个 Agent 会批量复制。

2. 把所有上下文复制给每一个执行者

把整个仓库、完整聊天记录和全部历史日志塞给每个 Agent，既贵又容易分心。执行者只需要当前任务的输入、规则、边界和验收条件。只有调度者或集成者需要全局视图。

3. 让两个 Agent 同时修改同一个文件

这不是并行，是竞争。即使两个修改逻辑上互不相干，最后一次写入也可能覆盖前一次。拆输出路径、使用 worktree 或把共享文件改动串行化。

4. 只让执行者说”做完了”

自然语言完成声明无法当作验收。要求产物路径、检查结果、错误证据和结构化状态。必要时让独立校验者重新读取产物。

5. 失败后整批重跑

任务有 id、输入哈希和状态，就是为了精确恢复。只重跑失败或受规则变更影响的项目，保留每次 attempt 的错误信息。

6. 把并发上限当作性能目标

系统能够启动 100 个会话，不代表 100 个会话是最佳设置。限流、内存、磁盘、模型延迟和人工审阅能力都可能先成为瓶颈。用吞吐、失败率和成本做决定。

7. 自动化外部副作用

模型可以为部署生成清单，也可以运行测试，但把发布、删除、发信、付款等动作放进无人值守的重试循环，风险会迅速放大。高风险阶段应让工作流停在预览和确认处。

8. 把产品名称当成方法论

某个版本里是否有名为 Dynamic Workflow 的按钮，不决定你能否做好批量编排。任务状态、输入输出契约、并发控制、验证和恢复才是核心。产品更新会改 UI，工程约束不会消失。

一个可以从今天开始的练习

不要直接拿 146 份文档练手。先挑 6 份短 Markdown，目标语言只选一种，按下面步骤跑完一轮。

1. 建一个 workflow/inventory.json，手工列出 6 个输入和它们的输出路径。
2. 写一份十行以内的术语表，列出不能翻译的产品名和命令。
3. 为每个文件创建一条 queued 任务，只允许写自己的输出文件。
4. 一次只运行 2 个任务，观察每份任务的输入、输出、耗时和错误。
5. 写一个不依赖模型的检查：对比源文件和译文的代码块数量、链接数量、front matter 键。
6. 只把检查失败的任务重新交给 Agent，并在提示词里带上具体失败证据。
7. 最后写一份小报告：哪些规则最常失败，哪些上下文其实不需要给执行者。

这一轮练习完成后，再把并发调到 4 或 8，把语言扩到两种。你会亲眼看到，多 Agent 的难点在于怎样让它们在失败、重试和汇总之后仍然留下一个你能相信的结果。

回到”几百个 Agent 干活”这句话

它听起来很厉害。更该关心的是，每一个 Agent 的工作是否足够独立，输出能否验证，失败能否恢复，外部副作用是否被拦住。

SubAgent 用来隔离高噪声的边缘工作。Agent Teams 适合让少数角色围绕一个仍在变化的问题沟通。动态工作流把大量稳定、可验证的单元排成阶段，用调度和质量闸门代替闲聊。这三种协作结构各有边界，不能按”高级模式”来理解。

当你下一次想让 Claude Code “批量处理所有文件”，先别问能不能开到几百并发。先拿出一条任务记录，写清它读什么、只允许改什么、把结果交到哪里、怎样证明成功、失败后是否可以安全重试。答案清楚了，工具怎么选往往就不难了。

参考资料

• AI少年：什么是 Dynamic Workflow？
• Anthropic：Create custom subagents
• Anthropic：Orchestrate teams of Claude Code sessions
• Anthropic：Run agents in parallel
• Anthropic：Claude Code configuration