mcpField
B
batch-orchestration

batch-orchestration

github.com/rohitg00Agent 工作流2.9k146 次安装4 周前更新
代码仓库

关于 batch-orchestration

用于 Claude Code 的命令模式，可将大型重复性代码修改协调为多个独立任务。它先扫描并拆分工作、等待确认，再让后台 Agent 在隔离 worktree 中实施修改、运行测试并创建 PR。

主要功能

  1. 01扫描仓库以查找匹配目标
  2. 02将工作拆分为独立任务
  3. 03执行 Agent 前须获批准
  4. 04在隔离 worktree 中运行 Agent
  5. 05汇总测试结果和 PR 链接

适用场景

  1. 01在多个文件中执行 codemod 式重构
  2. 02在整个代码库升级依赖
  3. 03为 API 处理程序添加统一监测

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/rohitg00/pro-workflow --skill batch-orchestration

安装后在 Claude Code 中输入/batch-orchestration确认已加载。

详细介绍

批量编排

用于大规模并行更改的 /batch 命令模式。

工作原理

/batch <instruction>
  │
  ├── 1. Research: scan repo, understand scope
  ├── 2. Decompose: split into 5-30 independent units
  ├── 3. Present plan: show units, ask for approval
  ├── 4. Execute: one background agent per unit in isolated worktree
  └── 5. Collect: each agent runs tests and opens a PR

语法

/batch Convert all React class components to function components
/batch Add error boundaries to every page component
/batch Migrate from moment.js to dayjs across the codebase
/batch Add OpenTelemetry tracing to all API handlers

指令应描述更改模式，而不是单个文件。批处理系统会查找文件。

阶段 1：调研

编排器扫描代码仓库，查找所有符合指令的实例：

grep -r "class.*extends.*Component" --include="*.tsx" -l

它会生成完整的目标列表，并按相互独立性分组。

阶段 2：拆解

每个单元都必须：

  • 独立 — 与其他单元没有共享状态
  • 自包含 — 可以单独实现和测试
  • 可验证 — 有明确的通过/失败标准

好的单元：

Unit 1: Convert src/components/Header.tsx (class → function)
Unit 2: Convert src/components/Footer.tsx (class → function)
Unit 3: Convert src/components/Sidebar.tsx (class → function)

不好的单元：

Unit 1: Convert all components in src/components/ (too broad)
Unit 2: Fix issues from Unit 1 (dependent)

目标数量为 5-30 个单元。少于 5 个不值得承担额外开销。超过 30 个则会增加协调成本。

阶段 3：计划审批

编排器会提供：

BATCH: Convert class components to function components

Found: 18 class components across src/

Units (18):
  1. src/components/Header.tsx — class Header → function
  2. src/components/Footer.tsx — class Footer → function
  ...
  18. src/pages/Settings.tsx — class Settings → function

Per unit: convert class to function, update hooks, run component tests
Estimated: ~2 min per unit, ~5 min total (parallel)

Proceed? (y/n)

等待审批。 未经明确确认，绝不启动 Agent。

阶段 4：执行

获得批准后，对每个单元：

  1. 创建隔离的 git 工作树
  2. 在该工作树中启动后台 Agent
  3. Agent 实现更改
  4. Agent 运行相关测试
  5. Agent 创建 PR

Agent 并行运行。每个 Agent 都有自己的上下文窗口和工作树，不会产生冲突。

[Agent 1] ── worktree-1 ── Header.tsx ── tests pass ── PR #41
[Agent 2] ── worktree-2 ── Footer.tsx ── tests pass ── PR #42
[Agent 3] ── worktree-3 ── Sidebar.tsx ── tests fail ── flagged

阶段 5：收集

所有 Agent 完成后：

  • 每个单元的通过/失败摘要
  • 已创建 PR 的链接
  • 失败单元及其错误详情
  • 可以单独重试失败的单元

最适用的场景

用例批处理适用的原因
API 迁移在许多端点中应用相同模式
依赖项升级在整个代码库中查找/替换并修复
Codemod 式重构逐个文件进行机械式转换
添加监控埋点在各处应用相同的追踪/日志记录模式
测试覆盖率缺口独立为未测试的模块添加测试
采用 Lint 规则在所有文件中应用新规则并修复问题

反模式

不要批处理的情况原因
相互依赖的更改如果单元相互依赖，就无法并行运行
修改共享状态多个 Agent 同时写入同一个配置文件或状态文件
架构更改需要整体推理，而不是逐个文件处理
Schema 迁移数据库更改必须按顺序进行
需要对每个文件进行人工判断的更改这违背了自动化的初衷

与其他模式的关系

模式规模隔离方式
直接编辑1-3 个文件无需隔离
子 Agent1 个专注任务分叉的上下文
工作树1 个功能分支完整的仓库副本
Agent 团队3-5 个并行任务共享任务列表
批处理5-30 个相同模式的任务每个单元使用独立的完整工作树

批处理是开销最大的工具。仅当更改是机械且重复的，并且各个单元确实相互独立时才使用。

防护措施

  • 批准前务必检查任务拆解
  • 每个 Agent 都必须在创建 PR 前运行测试
  • 标记失败的单元，不得悄然跳过
  • 所有 Agent 完成后清理工作树
  • 分批审查 PR，不要盲目合并

评论

支持 Markdown