计划驱动与并行波次：Agentic Coding摆脱长任务失控的执行秩序方案

如果你已经在真实项目里试过 Agentic Coding，大概率会遇到一个诡异的现象：AI 明明能写单个函数，也能解释复杂架构，但只要让它“从一个空仓库开始，独立完成一个中型功能”，它往往会在第 20 分钟之后进入重复造轮子、改坏既有模块、忘记自己写过什么的状态。问题不在大模型的代码能力，而在执行秩序。

这也是 Wb-Flow 这类方案最值得关注的原因。它把 Agentic Coding 从一个“AI 单干到底”的线性叙事，改造成“先规划、再分批并行执行”的工程流程。标题里的 Planned, Parallel Waves 三个词，翻译成实际开发语言就是：先把任务想清楚，再用有节奏的并行波次去执行，而不是让一个 Agent 蒙着头写到最后。

这篇文章不打算只做名词解读。我会从为什么 Agentic Coding 需要“计划 + 并行波次”说起，讲清楚它与传统单 Agent 模式的本质差异，然后用一个可落地的示例设计一套极简 Wave 调度流程，最后给出评估方法、常见坑和工程建议。

1. 为什么说 Agentic Coding 的瓶颈是执行秩序

先看一个真实感很强的场景。假设你给一个 coding agent 抛了这样一个需求：给现有博客系统增加一个标签聚合页，包含标签列表、按标签筛选文章、标签云展示。很多人第一次用 Agent 时会期待它一次性完成所有事。但实际运行时，Agent 经常会这样做：

• 先新建了一个功能模块，命名和项目现有目录风格不一致。
• 接着为了“快速实现”，自己定义了一套新的分页参数，没看项目原来的分页拦截器。
• 中途发现数据库查询需要关联表，又顺手改了实体类，结果破坏了另一个正在使用的查询方法。
• 最后生成了十几个文件，却没有跑一遍完整测试。

这个过程的本质问题不是“代码质量低”，而是线性执行缺少结构约束。单个 Agent 在执行长任务时，上下文窗口是有限的，记忆是易失的。它很难始终记得第 1 步的决定是否与第 50 步保持一致；更严重的是，当任务长度超过它的注意力范围后，它可能为了完成当前子任务而推翻前面的设计。

如果你把产品经理、前端、后端、测试分别交给四个独立的 Agent 去“自由协作”，效果往往更差。因为 Agent 之间的沟通成本极高，信息在传递过程中会丢失，而且没有哪个 Agent 对全局负责。

所以，从近两年 Agentic Coding 的发展脉络看，真正拉开差距的不是谁能生成更多代码，而是谁能管住执行过程。Wb-Flow 的思路恰好是针对这个痛点：在执行之前先有一个显式的计划，然后把计划拆成若干波次，每个波次内用并行 Agent 执行一批互相独立的子任务，波次之间设置检查点，逐批合并验证。

2. 从 Copilot 到 Wave-based：Agentic Coding 的三个演进阶段

为了理解 Planned, Parallel Waves 到底先进在哪里，有必要先梳理一下 Agentic Coding 的演进路径。

第一阶段：单轮补全。

以 GitHub Copilot 早期的行级/函数级补全为代表。开发者写一个函数开头，模型补全剩余部分。这个阶段的核心特征是：AI 是“输入法”，人类是唯一的设计者和集成者。好处是可控，坏处是效率提升有限，只能在局部减少打字量。

第二阶段：线性长任务 Agent。

以能够自主完成 issue 的 coding agent 为代表。你给 Agent 一个任务，它自己决定读哪些文件、改哪些代码、跑哪些测试，直到任务完成。这个阶段比补全前进了一大步，因为 Agent 开始具备计划能力。但它的计划是隐式的、写在上下文里的，并且整个执行过程是线性的：一个 Agent 从头做到尾，或者一个 Agent 调用多个工具串行执行。

线性长任务 Agent 的真实问题是：一旦任务规模超过单个上下文窗口的承载能力，执行质量会随进度衰减。很多人在长任务中会观察到，Agent 后面的改动经常与前面的设计矛盾。这就是上下文衰减和记忆遗忘在起作用。

第三阶段：计划驱动的并行波次执行。

也就是 Wb-Flow 所代表的思路。核心变化有三点：

• 计划显式化。在执行开始前，先生成一份任务计划，这份计划不是 Agent 脑中的思路，而是落在文件或数据模型里的结构化结果。
• 任务分批化。所有子任务被组织成多个 Wave，每个 Wave 内的任务尽量互相独立，可以并行执行；Wave 之间有先后依赖关系，形成一道质量闸门。
• 结果合并化。每个 Wave 执行完后，统一合并代码、解决冲突、运行测试，再进入下一个 Wave。

下表总结了三个阶段的差异：

从这张表可以看出，Wb-Flow 不是简单地“多 Agent 并行”这么浅。它把并行和计划放在一起，核心是用工程管理的确定性来对抗大模型生成的不确定性。

3. Wb-Flow 的核心概念：Plan、Wave、Task、Merge

要理解 Wb-Flow 的运作方式，需要先熟悉四个核心概念：Plan、Wave、Task 和 Merge。它们不是某个特定产品的专有名词，而是一套通用方法论。

3.1 Plan：先于代码的显式计划

Plan 是整个流程的起点，也是与普通多 Agent 协作最大的不同。在传统多 Agent 协作里，往往是你给一个主 Agent 下命令，主 Agent 临时拆解任务给其他 Agent。而 Wb-Flow 的 Plan 是一个独立的、先行的产物，它相当于工程里的“设计文档 + 任务拆解表”。

一个合格的 Plan 至少包含：

• 本次迭代的目标和边界。
• 涉及的文件、模块和接口。
• 任务清单，每个任务包含输入、输出、验收标准和依赖关系。
• 任务的 Wave 归属，即哪些任务可以在同一批并行执行。

把 Plan 显式化的价值在于：它让 Agent 不需要在漫长的执行过程中靠记忆维持全局认知。计划文件随时可以重新读取，也可以被人类审查。这相当于给 Agent 的过程加了一个“外部记忆”。

3.2 Task：最小的可执行单元

Task 是 Plan 的基本单位。一个 Task 应该具有以下特征：

• 边界清晰：只改某一个模块或某几个相关文件。
• 可验收：有明确的完成标准，比如“通过指定的单元测试”或“接口返回符合约定的 JSON 结构”。
• 上下文可控：Task 描述本身加上涉及的文件，能够放进一个不算太大的上下文窗口。

这是 Wave 并行能成立的前提。如果一个 Task 大到需要读二十个文件才能开始写代码，说明拆分粒度有问题。最好的 Task 是“给足描述后，Agent 只读 3-5 个文件就能完成”。

3.3 Wave：并行执行的批次

Wave 是 Wb-Flow 最核心的组织单位。一个 Wave 包含一组 Task，这些 Task 满足两个条件：

• 相互之间没有依赖。
• 修改的文件尽量不重叠。

一个 Wave 内的 Task 可以交给多个 Agent 并行执行。Wave 结束后，所有改动汇入主干，统一解决文件冲突和集成问题。通过后再开启下一个 Wave。

这就把“并行”和“计划”绑在了一起。并行不是让很多 Agent 乱跑，而是在计划阶段就识别出哪些任务可以安全并行。Wb-Flow 名称里的 Waves 暗示的正是这种“波次推进”：第一波处理数据模型和核心接口，第二波处理业务逻辑，第三波处理页面和联调。每个波次像潮水一样推进，一次只覆盖一片沙滩，没有交叉。

3.4 Merge：波次之间的质量闸门

每个 Wave 执行完并不等于结束，必须经过 Merge 环节。Merge 不只是 git merge，还包括：

• 检查代码风格和目录结构是否符合项目规范。
• 运行受影响模块的单元测试和集成测试。
• 审查文件冲突和重复定义。
• 必要时回退不达标的 Task，重新描述后再执行。

Merge 是质量闸门，也是 Wb-Flow 比自由多 Agent 更可靠的关键原因。因为它把不可控的“Agent 持续犯错”变成了可控的“每一波都校验一次”。

4. 一个可落地的案例：为博客系统增加标签聚合页

理论讲完，接下来用一个具体案例演示 Wb-Flow 的流程。假设你现在维护的是一个基于 Spring Boot + Thymeleaf 的博客系统，需要新增一个标签聚合页。需求描述如下：

• 标签列表页：展示所有标签，并显示每个标签下的文章数。
• 标签详情页：点击某个标签，展示该标签下的文章列表，支持分页。
• 标签云：在首页侧边栏展示热门标签。

这是一个典型的中型功能，涉及数据库表、MyBatis 映射、Service 层、Controller 层和前端页面。如果让单个 Agent 自由发挥，很容易出现表结构设计不统一、分页参数风格不一致、前端页面风格与现有页面脱节等问题。

使用 Wb-Flow 的思路，流程可以这样设计。

4.1 第一步：生成 Plan

先让规划 Agent 读取项目结构和现有代码风格，生成一份 Markdown 格式的计划文件。

# 标签聚合页实现计划 ## 目标 为博客系统增加标签列表页、标签详情页、首页侧边栏标签云。 ## 涉及模块 - 数据库：blog.tags 表（已有，结构待确认） - MyBatis：TagMapper、TagMapper.xml - Service：TagService、TagServiceImpl - Controller：TagController - 页面：tags.html、tag-detail.html、fragments/sidebar.html ## 代码风格约定 - Controller 返回视图名，使用 ModelAndView。 - 分页参数统一为 page 和 size。 - 新 SQL 使用 XML 文件，不使用注解 SQL。 ## 任务列表 ### Task-1 - 职责：确认 tags 表结构，补充 article_tag 关联表查询方法和 Tag 实体类字段。 - 涉及：Tag.java、TagMapper.java、TagMapper.xml - 验收：单元测试覆盖标签查询方法。 ### Task-2 - 职责：实现 TagService 中的标签列表、标签详情、热门标签查询。 - 涉及：TagService.java、TagServiceImpl.java - 验收：Service 层测试通过。 ### Task-3 - 职责：实现 TagController 的 /tags、/tags/{id}、/tags/hot 三个接口。 - 涉及：TagController.java、相关 VO 类 - 验收：接口返回正常视图和数据。 ### Task-4 - 职责：编写 tags.html 和 tag-detail.html 页面。 - 涉及：templates/tags.html、templates/tag-detail.html - 验收：页面可访问，样式与现有主题一致。 ### Task-5 - 职责：修改首页侧边栏，嵌入标签云。 - 涉及：templates/fragments/sidebar.html、HomeController.java - 验收：首页侧边栏显示标签云。 ## Wave 划分 - Wave 1：Task-1 - Wave 2：Task-2、Task-5 - Wave 3：Task-3、Task-4

这份 Plan 的关键是 Wave 划分。Task-1 必须先执行，因为其他任务依赖 Tag 实体和 Mapper；Task-2 和 Task-5 不依赖对方，可以并行；Task-3 依赖 Task-2，Task-4 依赖 Task-2，但它们之间互不依赖，也可以并行。

4.2 第二步：逐个 Wave 执行

每个 Wave 的执行逻辑类似：

• 读取 Plan 中当前 Wave 的 Task 列表。
• 为每个 Task 启动一个 Agent 实例。
• 每个 Agent 独立读取相关文件并执行修改。
• Wave 结束后收集所有 diff 并合并。

这里有一个容易被忽略的点：Wave 内的 Agent 最好不要共享同一个工作目录，否则容易互相覆盖文件。更稳妥的做法是各自在独立分支上完成修改，Wave 结束时再统一合入主干。

4.3 第三步：Merge 与验证

Wave 2 完成后，应该运行 Service 层测试，检查 TagService 和 sidebar fragment 是否同时正常。如果测试失败，找出是 Task-2 和 Task-5 的改动冲突，还是 Task-2 本身的实现问题。修复后再进入 Wave 3。

这种“小步快跑 + 每波验证”的节奏，比让一个 Agent 一口气完成五个 Task 更稳。原因很简单：问题被限定在一个 Wave 的范围内，排查成本直线下降。

5. 核心实现：一个极简 Wave 调度器演示代码

理解了流程之后，我们来看一眼如何用代码实现一个简单的 Wave 调度器。这里给出的是演示思路，不绑定任何特定框架，你可以根据自己的技术栈改造成 Python、Java 或 TypeScript 版本。

5.1 定义 Task 和 Wave 的数据结构

# executor/wave_model.py from enum import Enum from typing import List class TaskStatus(str, Enum): PENDING = "pending" RUNNING = "running" SUCCESS = "success" FAILED = "failed" class Task: def __init__(self, task_id: str, description: str, files: List[str], depends_on: List[str] = None, wave: int = 1): self.task_id = task_id self.description = description self.files = files self.depends_on = depends_on or [] self.wave = wave self.status = TaskStatus.PENDING self.result = "" def to_prompt(self) -> str: return f""" 你正在执行 Task {self.task_id}。 任务描述：{self.description} 涉及文件：{', '.join(self.files)} 请严格按计划完成，不要修改波及范围之外的文件。 """

这里需要注意depends_on字段。它决定了 Task 能否并行。Wave 调度器在计算可并行 Task 时，只需要检查一个 Task 的依赖是否都已处于 SUCCESS 状态。

5.2 调度器的核心循环

# executor/scheduler.py from collections import defaultdict from concurrent.futures import ThreadPoolExecutor, as_completed from typing import List from executor.wave_model import Task, TaskStatus class WaveScheduler: def __init__(self, tasks: List[Task], max_workers: int = 4): self.tasks = tasks self.max_workers = max_workers self.task_map = {t.task_id: t for t in tasks} self.wave_tasks = defaultdict(list) for t in tasks: self.wave_tasks[t.wave].append(t) def ready_tasks(self, wave_tasks: List[Task]) -> List[Task]: """ 判断哪些 Task 可以并行执行： 1. 状态为 PENDING 2. 所有前置 Task 已成功 """ ready = [] for task in wave_tasks: if task.status != TaskStatus.PENDING: continue deps_ok = all( self.task_map[d].status == TaskStatus.SUCCESS for d in task.depends_on if d in self.task_map ) if deps_ok: ready.append(task) return ready def run_one_task(self, task: Task, agent_executor) -> None: """实际执行单个 Task。agent_executor 可以是任何 coding agent 客户端。""" task.status = TaskStatus.RUNNING try: result = agent_executor.execute(task.to_prompt()) task.result = result task.status = TaskStatus.SUCCESS except Exception as e: task.result = str(e) task.status = TaskStatus.FAILED def run(self, agent_executor) -> None: """ 按 Wave 顺序执行。 每个 Wave 内部通过 ThreadPoolExecutor 并行执行互相独立的 Task。 """ wave_ids = sorted(self.wave_tasks.keys()) for wave_id in wave_ids: print(f"=== 开始执行 Wave {wave_id} ===") current_tasks = self.wave_tasks[wave_id] while True: ready = self.ready_tasks(current_tasks) if not ready: break with ThreadPoolExecutor(max_workers=self.max_workers) as pool: futures = { pool.submit(self.run_one_task, task, agent_executor): task for task in ready } for future in as_completed(futures): task = futures[future] # 这里可以在 future.result() 里捕获异常 future.result() # Wave 内的所有任务都结束后，进入 Merge/验证阶段 self.merge_and_verify(wave_id) def merge_and_verify(self, wave_id: int) -> None: """ 合并当前 Wave 的分支到主干，并运行测试。 实际项目中这里可以调用 git merge、mvn test 等命令。 """ print(f"--- Wave {wave_id} 合并验证 ---") # TODO: 按项目实际流程补充：合并分支、运行测试、回滚失败任务

这个调度器把 Wave 的执行流程还原得很直白：外层按 wave 顺序，内层通过ready_tasks识别可并行的 Task，再用线程池并发执行。agent_executor是一个抽象接口，实际使用时可换成 Claude Code、OpenHands、Cline 等任意 coding agent 的命令行客户端或 SDK。

5.3 如何对接一个真实的 Coding Agent

为了让上面的调度器真正跑起来，需要一个agent_executor。以常见的命令行 Agent 为例，可以写一个适配器，通过子进程调用 Agent 的 CLI：

# executor/agent_adapter.py import subprocess from typing import List class AgentClient: """对 coding agent 的命令行封装，演示用。""" def __init__(self, command: List[str], workspace: str): self.command = command self.workspace = workspace def execute(self, prompt: str) -> str: # 这里只是演示思路，实际需要处理工作目录和超时。 process = subprocess.run( self.command + [prompt], cwd=self.workspace, text=True, capture_output=True, timeout=600, ) return process.stdout

需要提醒的是，不同 Coding Agent 的 CLI 参数完全不同。有的支持直接传 prompt，有的需要先建 issue 再执行。上面的代码只是演示“适配器”这一层应该存在，实际接入时请以你所用工具的文档为准。

6. 效果验证：怎么判断 Wave 模式比线性模式更好

很多人问：怎么证明这种“计划 + 并行波次”真的更有效？我的建议是不要靠感觉，而是建立一组可对比的指标。

6.1 衡量维度和指标

这组指标不复杂，但能反映真实差异。尤其是“文件冲突数”，在传统单 Agent 长任务里几乎是必然上升的指标。Wb-Flow 通过任务拆分和 Wave 隔离，从结构上压低了冲突概率。

6.2 一个可复用的实验设计

如果你想在团队里验证这个思路，可以选一个中等规模 issue，用同样的需求分别跑两条流水线：一条是单 Agent 直接处理，一条是 Wb-Flow 式 Wave 调度。对比以下三个结果：

• 最终代码是否通过全部测试。
• 整个过程的耗时。
• 人工介入审查的次数。

这个实验不需要很精确，能看出趋势就可以。从实际经验看，任务越杂、涉及文件越多，Wave 模式的优势越明显；反之，如果只是一个几十行的独立小函数，单 Agent 更直接，Wb-Flow 反而显得重。

7. 常见问题与排查思路

在落地 Wb-Flow 的过程中，会遇到几个高频问题。下面按现象、原因、排查方式、解决方案整理成表格。

这里最值得警惕的是“公共文件依赖”。很多 Agentic Coding 项目失败，不是 AI 能力问题，而是多个并发任务同时改一个公共模块，造成不可调和的冲突。Wb-Flow 的解法是：在规划阶段检测 Task 间的文件重叠度，如果重叠度高于阈值，就改变 Wave 顺序或调整 Task 边界。

8. 最佳实践与工程建议

Wb-Flow 的落地不仅是一个工具使用问题，更是一套工程习惯的调整。以下是几条在项目中验证过有效的建议。

8.1 先读懂项目，再让 Agent 规划

不要让 Agent 从零开始猜架构。在生成 Plan 前，先让规划 Agent 读取项目的 README、目录结构、核心模块代码，甚至让它在主分支上跑一次现有测试。一个不了解全局的规划 Agent 产出的 Plan，会把 Wave 切分得完全不落地。

比较实用的做法是准备一份“项目概览文档”，内容包括技术栈、目录说明、编码规范、典型代码片段。这个文档既是人类新手的入职手册，也是 Agent 的规划上下文。

8.2 Task 描述要包含验收条件，而不是只有目标

弱 Task 描述：“实现标签分页查询。”这个描述太含糊，Agent 不知道该返回什么结构，也不知道分页边界在哪里。

强 Task 描述：

实现 TagService 中的 pageArticlesByTag(String tagName, int page, int size) 方法。 - 入参：page 从 1 开始，size 默认 10，最大不超过 50。 - 出参：PageResult<ArticleVO>，包含 total、page、size、records 字段。 - 数据来源：article_tag 关联表，status = 1 的文章才计数。 - 失败场景：标签不存在时返回空记录，不抛异常。 - 参考实现：可参考项目中 CategoryService 的分页写法。 验收条件：TagServiceTest 中新增三个测试用例，分别覆盖正常分页、空数据、越界分页。

这种描述虽然长，但极大降低了 Agent 的试错成本。它把“判断如何实现”变成了“按约定实现”，这正是 Wave 模式高效运转的前提。

8.3 用中间计划文件替代 Agent 的短期记忆

很多 Agent 之所以在长任务中断裂，是因为计划只存在于上下文窗口里。Wb-Flow 提倡把计划落成文件，Agent 每执行一个 Task 前都可以重新读取。这样即使上下文被其他信息冲掉，Agent 也能重新建立全局认知。

实践中，我会把 Plan 文件放在docs/plans/目录下，按日期命名。Wave 执行完后更新计划文件中的 Task 状态。这样人类可以随时查看进展，Agent 也不会“失忆”。

8.4 并行度不是越高越好

并行 Agent 的数量取决于三个因素：任务的独立性、机器的算力、上下文的成本。从实际项目看，同一时间并行 2-4 个 Agent 是比较舒适的区间。超过这个数量，合并冲突和机器资源都会变成新的瓶颈。

另外，并行度要动态调整。Wave 1 任务简单，可以开 3 个并行；Wave 3 任务互相有隐性耦合，就该降为串行执行，或者拆得更碎再做并行。

8.5 建立每个 Wave 的回滚能力

Wave 执行不可能永远一次通过。比较稳妥的做法是：

• 每个 Agent 在独立分支上工作。
• Wave 合并前先记录当前主干的基线 commit。
• 合并后如果测试失败，优先回滚到基线，再决定是修复还是重新执行。

这比“在错误代码上打补丁”更安全。对于生产仓库，还要加一层保护：Wave 合并流程只能在受保护的分支策略下进行，合并必须经过 CI 检查。

8.6 安全与权限边界不能因为 Agent 而放松

Coding Agent 本质上是一个可以读写文件、执行命令的程序，因此在团队落地时要特别强调安全底座：

• 使用最小权限的本地账号运行 Agent，避免直接用管理员账号。
• 数据库操作语句必须限定在测试库，禁止在未授权情况下连接生产库。
• 涉及删除、批量更新、表结构变更的 Task，应在计划阶段单独标注“需人工审批”。
• Agent 执行的命令应记录日志，便于审计。

这些要求看起来是老生常谈，但在 Agent 自动执行的环境里更容易被忽视。建议在 Wave 调度器的merge_and_verify阶段，显式检查本次 Wave 涉及的 SQL 和命令是否包含危险操作。

9. 总结与后续学习方向

Wb-Flow 给我最大的启发不是“用了这个就能让 AI 包办一切”，而是它重新划定了人与 AI 在编码协作中的边界。过去的 Agentic Coding 强调“AI 独立完成任务”，Wb-Flow 则更接近一种工程管理方法：人类负责定义目标和验收条件，Agent 负责在受限的 Wave 内并行执行，双方通过计划文件和 Merge 闸门协作。

如果你现在正在被 Coding Agent 的“长任务失控”困扰，我建议你按以下路径实践：

• 第一步，先选一个中等规模的独立功能，尝试把它拆成至少 5 个 Task。
• 第二步，思考哪些 Task 可以并行，哪些 Task 之间存在文件级依赖。
• 第三步，按 Wave 顺序执行，并在每个 Wave 后跑测试。
• 第四步，记录每个 Task 的首次成功率、修复轮次和 Token 消耗，建立自己的指标基线。
• 第五步，根据指标优化 Task 拆解粒度，形成适用于你自己项目的“Wave 拆分经验”。

更进一步，可以研究 Agent 工具中显式的 Planning 模块、多 Agent 通信协议、以及基于文件依赖图的任务调度算法。这些都是 Wb-Flow 理念背后的真实技术基础，比单纯追新工具更有长期价值。

需要记住的是：任何 Agentic Coding 方法都不能替代对项目架构的理解。Plan 拆得好不好，取决于你是否真正了解哪些模块可以独立演进、哪些层必须强一致。从这个角度看，Wb-Flow 提升的不仅是 AI 写代码的效率，也在倒逼开发团队把架构边界设计得更清晰。架构混乱的项目，无论用不用 Wave，Agent 都会在某个时刻把混乱放大。

如果你打算在下一个迭代里尝试 Wb-Flow，建议先从非关键业务模块做起，准备好分支回滚策略，再逐步扩大使用范围。毕竟，工具可以激进，生产环境必须保守。