用 Cursor /orchestrate 跑了一个真实项目，差点把代码库搞崩

我以为它会帮我省掉所有重复劳动。

结果第一次跑完，打开项目一看——组件引用对了，测试用例写了，语言包也生成了，但有三个文件的 import 路径全部指向一个不存在的目录。子 Agent 各自完成得很漂亮，合并在一起就是一坨 bug。

这不是在劝你别用 /orchestrate。恰恰相反，我现在每周都在用它，而且确实省了大量时间。但在你冲进去之前，我想先把那些没人愿意写的部分说清楚。

这篇文章有截图、有数据、有代码示例，不是评测软文。

---

/orchestrate 是什么：三句话讲清楚

先说背景，不啰嗦。

Cursor 的 /orchestrate 是一个任务编排指令。你给它一个复杂目标，它不是线性地一步步等你确认，而是自动把任务拆解成多个子 Agent，并行或递归地去执行。

和普通 Cursor Chat 的区别是：Chat 是你指挥 AI，一问一答；/orchestrate 是你给目标，AI 自己排兵布阵。

和 Composer 的区别是：Composer 仍然是单线程的，你在一个窗口里推进；/orchestrate 会生成一棵任务树，每个节点都是独立的子 Agent，可以同时跑。

用一个粗糙的示意图来理解：

你的指令

└── 主 Agent（拆解任务）


├── 子 Agent A（扫描硬编码文本）


├── 子 Agent B（生成语言包）


│       └── 子子 Agent B1（处理中文）


│       └── 子子 Agent B2（处理英文）


├── 子 Agent C（替换组件引用）


└── 子 Agent D（写测试用例）

关键词是并行和自动传递上下文。子 Agent 之间会共享任务状态，B 做完了，C 不需要你来告诉它"B 的结果在这里"，它自己知道。

这听起来很美好。继续往下看。

---

实验项目还原：原来要手动分 4 步的活儿

我拿来测试的项目是给一个中型 React 项目做国际化（i18n）改造。项目大概有 80 个组件，里面散落着大量硬编码的中文字符串。

过去的手动流程是这样的：

1. 扫描阶段：打开 Composer，写 prompt 让它扫描所有组件里的硬编码文本，输出一个清单

2. 生成语言包：拿着清单，重新开一个 Composer 窗口，生成 zh.json 和 en.json

3. 替换引用：再开一个窗口，让它把组件里的字符串替换成 t('key') 的形式

4. 写测试用例：最后一个窗口，针对改动写单元测试

每一步都要手动粘贴上一步的输出，每一步都要等待，每一步都要检查有没有跑偏。整个流程走下来，实际耗时大约 2.5 到 3 小时，其中至少一半时间花在切换窗口、粘贴上下文、重新校准方向上。

用 /orchestrate 之后的流程：

我写了一条 prompt，大概是这样的：

/orchestrate 请对这个 React 项目进行完整的 i18n 国际化改造，具体要求：

1. 扫描 src/components 目录下所有组件，找出所有硬编码的中文字符串


2. 生成 src/locales/zh.json 和 src/locales/en.json 两个语言包文件


3. 将组件中的硬编码字符串替换为 i18next 的 t() 函数调用


4. 为改动的组件生成对应的单元测试



约束：每个子任务完成后输出检查点报告，递归层数不超过 2 层，


遇到不确定的翻译内容标记为 [NEEDS_REVIEW] 而不是自行决定。

发送之后，任务树在 Cursor 界面里展开，子 Agent 开始并行工作。

实际耗时：约 45 分钟（其中我盯屏幕的时间大概 10 分钟，其余是等待执行）。

从 2.5 小时到 45 分钟，这个数字是真实的，不是理想状态。但我要立刻补充：那 45 分钟结束后，我花了额外 30 分钟修 bug——也就是开头说的那些 import 路径问题。

所以综合算下来，节省的时间大约是 1 到 1.5 小时。依然值得，但没有"一键完成"那么神话。

---

哪里真的省事了：诚实的优点清单

在讲坑之前，先把真实的好处说清楚。

1. 上下文传递自动化

这是最明显的收益。过去我每开一个新 Composer 窗口，都要把上一步的结果粘贴进去，还要写"基于以上内容……"的引导语。用 /orchestrate 之后，子 Agent 之间的状态传递是自动的，主 Agent 会维护一个共享的任务上下文。

2. 并行执行减少等待

扫描文本和准备语言包框架这两件事，过去是串行的，用 /orchestrate 可以同时跑。对于这个项目，并行带来的时间节省大约是 20 分钟。

3. 任务依赖关系自动识别

主 Agent 会判断哪些任务必须等前置任务完成，哪些可以并行。替换组件引用必须等语言包生成完，它自己知道，不需要你在 prompt 里手动声明顺序。

关于 token 消耗：

这里要说一个不那么好听的数字。同样的任务，手动 4 步 Composer 模式消耗的 token 大约是 /orchestrate 模式的 60%。/orchestrate 因为要维护任务树状态、在子 Agent 之间传递上下文，token 消耗更高。

这不是让你放弃用它，而是要把这个成本算进去。如果你在用 Claude Opus 4.6 或 GPT-5 系列这类贵价模型跑 /orchestrate，长任务下来账单会比你想象的高。

💡 顺手一提：用 /orchestrate 跑复杂任务，token 消耗比普通 Chat 高出不少。如果你在国内访问 Claude / GPT-4o 等模型有速率或账号限制，可以试试通过 [api.884819.xyz](https://api.884819.xyz) 调用——支持主流模型，按量付费没有月租，对跑 Agent 类长任务尤其友好。新用户注册即送体验 token，国产模型（Deepseek/千问等）完全免费。

---

必须盯着的三个坑（这部分认真看）

好，现在说真实的。

坑一：子 Agent 之间的"幻觉传染"

这是最隐蔽的问题，也是我踩得最痛的一个。

一个子 Agent 在执行过程中做了一个错误假设——比如它认为项目使用的是 react-i18next 的 useTranslation hook，但实际上项目用的是一个内部封装的 useI18n。

这个错误假设被写进了它的输出报告，然后下游的子 Agent 接收到这份报告，把这个错误假设当成事实继续执行。最终，有 12 个组件的 import 语句指向了一个不存在的 hook。

规避方法：

在 prompt 里明确声明关键约束，不要让子 Agent 自己去"猜"项目结构：

/orchestrate [任务描述]


项目约定（子任务必须遵守）：


  • i18n hook 使用 src/hooks/useI18n.ts，不是 react-i18next 的 useTranslation
    • 

  • 语言包路径固定为 src/locales/
    • 

  • 不要自行推断项目使用的库版本，遇到不确定的地方标记 [UNCERTAIN] 并停止该分支
    •

把关键事实显式写进 prompt，而不是期待 AI 从代码里推断出来。

坑二：递归深度失控

任务描述越模糊，主 Agent 就越倾向于把任务拆得越细。我有一次写了一个过于宽泛的 prompt，大意是"帮我重构这个项目的状态管理"，没有加任何约束。

结果任务树展开了 4 层，子子子 Agent 开始做一些完全不在我预期内的事情，比如开始分析 Redux 的历史版本兼容性。token 烧了一大截，产出几乎没有。

规避方法：

两个关键约束，每次写 /orchestrate prompt 都要带上：

约束：

  • 递归层数不超过 2 层
    • 

  • 单个子任务预计 token 消耗超过 [X] 时，暂停并等待我的确认
    • 

  • 任务范围严格限定在 [具体目录/文件] 内
    •

递归层数限制是最重要的。2 层通常够用，3 层以上就要非常小心。

坑三：最终整合阶段仍需人工审核

这是最容易被忽视的一个，因为它发生在你以为"完了"的时候。

子 Agent 各自完成得很好，但它们是在相对独立的上下文里工作的。合并的时候，会出现：

  • 两个子 Agent 对同一个文件做了不同方向的修改，产生冲突
  • 子 Agent A 生成的接口和子 Agent C 期望调用的接口签名不一致
  • 测试用例里 mock 的数据结构和实际生成的组件 props 不匹配
规避方法：

在 prompt 里要求每个子任务完成后输出一份接口契约声明：

每个子任务完成后，必须输出：

  • 我修改/创建了哪些文件
    • 

  • 我暴露的接口/导出的内容是什么（函数签名、类型定义）
    • 

  • 我依赖的其他子任务的输出是什么
    • 



主 Agent 在所有子任务完成后，必须做一次接口一致性检查。

然后，不管 /orchestrate 说"全部完成"多少次，你都要亲自跑一遍测试。这不是对 AI 不信任，这是工程习惯。

---

什么项目适合用，什么项目别碰

给你一个决策框架，用完可以收藏。

                    ┌─────────────────────────────────────┐

│         容错空间                     │


│    高（允许先跑再修）  低（必须一次对）│


──────────────────────────────────────────────────────


任务  高（可以   │   ✅ 最佳场景         ⚠️ 谨慎使用   │


复杂  清晰拆解） │   i18n改造、批量      代码审查、     │


度              │   重构、文档生成       安全相关修改   │


──────────┼──────────────────────────────────────


低（模糊  │   ❌ 杀鸡用牛刀       ❌ 直接用Chat │


或高创意  │   普通问答、           创意写作、     │


权重）    │   单文件修改           架构设计       │


──────────────────────────────────────────────────────
最适合的场景：
  • 批量文件处理（i18n、代码风格统一、注释生成）
  • 步骤明确的多阶段任务（测试覆盖率提升、依赖升级）
  • 有明确输入输出定义的工程类任务
不适合的场景：
  • 需要你实时反馈和调整方向的创意类任务
  • 预算敏感的场景（token 消耗比普通 Chat 高）
  • 涉及安全、权限、数据库 schema 的高风险修改
  • 任务描述本身还没想清楚的时候

最后一条是最重要的。/orchestrate 放大你的指令，也放大你指令里的模糊性。你想清楚了再用，用了会很爽；没想清楚就用，它会帮你把模糊的想法执行得很彻底，然后你要花双倍时间善后。

---

我的最终判断

/orchestrate 不是魔法，是一把有刃有柄的刀。

它真的能把复杂项目的协调成本砍掉相当一部分——我的实验里是 50% 到 60%，但这个数字高度依赖你的 prompt 质量和任务本身的可拆解性。

它不能替代你的判断。任务拆解的逻辑、关键约束的声明、最终整合的审查——这些地方你还得亲自把关。

用好它的核心心法只有一句话：你越清晰，它越有用。

你的项目里，哪个步骤最想让它接管？欢迎在评论区说说你的场景，我来帮你判断适不适合用 /orchestrate。

---

说到子 Agent 协作，/orchestrate 解决的是任务拆解问题。但还有一个更底层的问题我还没聊：

当多个 Agent 需要共享同一份代码库上下文时，Cursor 的 Memory 机制到底够不够用？还是说你需要自己搭一套持久化的 Context 管理方案？

下一篇，我们拆这个。

---

本文由8848AI原创，转载请注明出处。关注8848AI，带你从零开始学AI。

#Cursor #AI编程 #Agent开发 #orchestrate #开发效率 #AI工具 #8848AI #前端开发