每天精通一个 claude code skill -- orchestrating-parallel-research

每天精通一个 Claude Code Skill —— Orchestrating Parallel Research

坏了孩子们 调cc跑实验又浪费GPU了 不好孩子们cc又钻进牛角尖里面了

无数个通宵、踩烂的坑、推倒重来的流程，尽数熔铸于这一柄利器——Orchestrating Parallel Research。剑成之日，效果出奇：昔日一个创新点熬一整天，如今一声令下、二十路 agent 同时开工，一天并行跑穿 20 个创新点。自此，一人不再是一人，而是一支舰队的大脑。

平时用 Claude Code，大多是“一个会话、一个人埋头干”：你提需求，它读代码、改代码、跑测试。小任务够用。但任务一变大——同时验证十几个想法、把一个大项目拆成很多块并行改、或者上远程 GPU 跑一批实验——这种“单会话串行”就顶不住了：上下文越滚越满，速度全靠排队，你还得盯着它一步一步来。

很多人会想到“多开几个会话、多派几个 agent 并行干”。方向没错，但真动手就全是坑：两个 agent 改到同一个文件、产物互相覆盖、你在第一个点上定了套目录规范、第二个点又临时改一版，跑到一半彻底失控。前端有 Playwright 给 Claude 当“眼睛”，后端有测试用例兜底，但“怎么把一堆 agent 并行调度得又快又不打架”这件事，一直没人给一套章法，全靠临场拍脑袋。

这时候，今天的主角就来了：Orchestrating Parallel Research——并行科研总协调。它做的不是“让 Claude 更会写代码”，而是换一个更狠的角色：让 Claude 从“干活的人”变成“指挥一支并行舰队的军师”，就这么说吧，你只需要把论文仓库，GPU ssh key，不知从哪来的几十个创新点丢给他,一个下午跑20个创新点加消融不是问题！！！

name: orchestrating-parallel-research
description: Use when running many independent tasks in parallel across
  isolated agent workspaces — fanning out research experiments (remote GPU,
  ablations, innovation points) or feature work — and you act as the
  coordinator deciding how to split, isolate, dispatch, and report.

入门级玩法

最基础的用法，是把“你自己埋头做”改成“你当军师、把重活并行派出去”。这个 Skill 把总协调者的动作拆成清清楚楚的四招：

1. 拆分（Split）：沿“隔离边界”切活——切在包 / 模块 / 创新点的边界上，让任意两个 agent 都不会碰同一个文件。切得对，后面就不用收拾冲突。
2. 隔离（Isolate）：每个 agent 一份自己的完整工作区（从主分支 checkout 一份）+ 自己的分支 + 自己的产物目录，本地和远端各一份。代码和产物天然不串味。
3. 派活（Dispatch）：给方向，不给牢笼。每个 agent 只拿到“输入 / 输出 / 目标 + 一份大纲或伪代码”，剩下让它自己实现。不逐步教、不堆一堆“不许做 X”。
4. 观测（Observe）：读每个 agent 的汇报，对着目标评估，再决定下一波怎么派。它照没照做、有没有跑出不一样的东西，都是你调度的依据。

举个具体场景：你手上有 10 个想验证的创新点。以前是一个一个来，做完一个再做下一个。现在你只做“军师”该做的事——把每个点解析成“大纲 + 一两处关键伪代码”，然后一条命令并行拉起 10 个 Codex/GPT agent，各自在自己的目录里实现、自测、回报。你从“执行者”，变成了“设计流程 + 分发 + 汇总判断”的那个人。

进阶玩法

四招之外，真正难的工程细节这个 Skill 也替你规范好了，拆在几个 references 里按需加载：

• 完全隔离（最关键）：每个 agent 一份独立完整目录，本地一份、远端 GPU 一份，不合并回主干——主分支只当只读模板。这条最反直觉：很多人默认“最后要合并回去”，但对并行实验来说，不合并才是真隔离，代码和产物都不会互相污染。
• 派单契约：一份派单只要六件事——角色+任务、输入、输出（严格 schema）、几条硬规则、一条能自检的命令、这一步在全局流程里的位置（附伪代码），最后一句“只输出结果、别多话”。核心心法就一句：给方向不给牢笼——你越想用一堆“不许”把它框死，它越发挥不出来。
• 远程 GPU / SSH 纪律：单卡单 SSH 串行通道、薄件回传（只回 csv/json/md，重产物留服务器）、部署六步 + 每次跑都过“验收门”（无损 / 触发计数 / 单变量）。其中触发计数这条特别值：任何“开了某开关、结果说等价”的结论，必须证明那段新代码真跑过（计数 > 0），否则就是“根本没跑、自己跟自己比当然一样”的假等价。
• 报告规范：可读性第一——给效果和分析，别堆函数名和英文标识符；数据用表 + 一句结论；论文级对比就上三线表。

一些小坑

它当然也不是没成本。

第一，token 消耗会明显上去。 并行 N 个 agent，就是 N 份上下文和命令在同时烧；流程一长、中途报错反复重跑，整体消耗比“改一段代码”高不少。并行的粒度和数量要有规划，不是越多越好。

第二，隔离目录和产物要提前约定。 一堆 agent 各跑各的，产物、日志很容易“东一份西一份”。不提前定好目录结构和命名规则，回头汇总能让你崩溃。主干先定死、一点一文件夹，是省后账的关键。

第三，派太死等于自废武功。 “给方向不给牢笼”知易行难。你越忍不住去规定每一步、去堆防错约束，agent 就越只会机械照抄，产出反而更差。风险点到为止，细节放手让它想。

第四，单卡单 SSH 是硬瓶颈。 并行的是“写代码 / 离线分析”，真正上 GPU 那一下是串行的。参数网格、阈值扫描这类别上卡，归到离线 CPU；GPU 只留给首验、采集、终审。

第五，也是最反直觉的一条：先规范，后开跑。 并行实验是一项工程，不是“边跑边改”。你得在第一个 agent 出发前，就把目录、隔离、派单契约全定好，而不是第 1 个点改这里、第 2 个点改那里。失控几乎都是从“中途改规范”开始的。

一点直观感受

我的直观感受是：如果说 Playwright CLI 给 Claude Code 装了“眼睛”，Technical Writer 给了它“笔杆子”，那这个 Skill 给的是“军师的大脑”——它不再是一个埋头干活的人，而是一个会拆目标、设计并行流程、指挥一支隔离舰队、最后汇总判断的总协调者。

对小任务，它是杀鸡用牛刀；但对大型改造、论文实验、几十个想法要并行验证的场景，价值非常直接：把你从“逐个盯”里解放出来，只做最该你做的事——拆解和判断。

它已经开源在我的 agent-pilot-skills 仓库里，一行装上（会顺带把仓库里的 skill 一起装好）：

npx skills add babyGao/agent-pilot-skills -g -y

不用配 MCP，装好 Codex CLI（npm i -g @openai/codex && codex login）就能用。