为什么需要编排
刚接触 OpenClaw 的人，第一反应通常是「我装一个技能，让它帮我干一件事」。比如用搜索技能查资料，或者用格式化技能整理输出。这没问题，单个技能的边界清晰、容易调试，出问题也好定位。
但真实的工作很少是一步到位的。我常遇到的一类需求是：先把网页里的内容抓下来，再做一轮摘要，接着按某个模板渲染成报告，最后发到指定渠道。如果每一步都手动触发一次技能，你得守在旁边，等上一步结束再复制结果、粘贴到下一步的输入里——这既慢，又容易在手动搬运时漏掉关键信息。
这时候就该把任务从「单个技能」升级到「多技能编排」。可以这样理解：单个技能解决的是「一件事怎么做」，编排解决的是「一串事怎么自动接着做」。它的价值不在于某个技能变强了，而在于你不用再当那个在中间传话的人。
不过也别走向另一个极端。不是越复杂越好。如果一个任务三步以内、彼此耦合很紧，强行拆成多个技能反而增加出错面。我的经验是：当任务里出现「先……再……最后……」这种明显的阶段划分，且每个阶段能用相对独立的技能承担时，才值得编排。
一个最小例子
假设你想做一个每天自动更新的「竞品动态简报」。拆解一下，它其实由四段组成：
- 抓取：去几个目标站点把最新内容取回来。
- 提炼：从抓取到的长文里摘出要点。
- 成文：把要点套进固定模板，生成一段可读的简报。
- 投递：把简报推送到你常用的看板或消息渠道。
如果用编排的思路，这四段就对应四个技能，或者更准确地说，是四个「步骤节点」。你不需要把它们写进同一个技能文件里，而是让 OpenClaw 知道：步骤 A 完成后，把它的产出交给步骤 B，B 完成再交给 C，依次类推。
示意上，一条最小流水线大概长这样：
抓取技能 ──产出──▶ 提炼技能 ──产出──▶ 成文技能 ──产出──▶ 投递技能
(节点1) (节点2) (节点3) (节点4)你只需要描述「节点 1 的输出是节点 2 的输入」这一层关系，剩下的接力由编排层去跑。触发方式可以是你一句话交代，也可以挂一个定时触发（这部分在另一篇「触发器与定时」里讲过，这里不展开）。
串行与并行
编排里最基础的两类结构是串行和并行，理解它们能少走很多弯路。
串行就是上面那个例子：一个接一个，前一个不出结果，后一个不动。适合强依赖的场景——后面要用到前面的产物，没有捷径。比如「先抓再提炼」，没抓到东西，提炼什么？
并行则是几个互不依赖的步骤同时开跑。比如你要做一份市场周报，其中「拉取销售数据」和「抓取行业新闻」这两件事彼此没关系，完全可以一起触发，等两边都好了，再进入「汇总」这一步。串行是默认的安全选择，并行是为了省时间。
需要提醒的是，并行不是免费的。它意味着同时占用更多上下文和计算，遇到需要共享同一份中间状态的情况，并行反而会把数据搅乱。我的建议：不确定的时候先用串行，等确认各步骤真没依赖了，再考虑拆成并行。
还有一种你可能用到的结构是按条件接力，也就是「if 否则」式的分支。比如：如果抓取到的内容为空，就跳过提炼直接告警；如果内容超长，就先走一个「切分」节点再提炼。这种条件编排能让流水线在异常输入下也不至于整条崩掉。
数据怎么过手
这是编排里最容易翻车的地方，值得单独拎出来说。
多个技能之间传递数据，核心要回答一个问题：上一个技能的产物，下一个技能怎么拿得到？ 通常有两种稳妥的过手方式。
第一种是「显式产物」。每个节点跑完，把结果写成一份结构化的中间产物，比如一段带字段的文本、一份 JSON 草稿，或者一个临时文件。下一个节点启动时，明确去读这份产物，而不是指望从聊天记录里「猜」。好处是数据边界清楚，调试时能直接打开中间产物看哪里断了。
第二种是「上下文摘要」。如果产物很小，比如只是一个 ID 或一条短结论，可以直接作为下一步的参数带过去。但注意，别把一大段原始内容整个塞进上下文，否则几轮下来上下文就爆了，后面的技能会「失忆」。
下面这张表是我常用的判断清单：
| 场景 | 做法 | 注意 |
|---|---|---|
| 节点产出很小（一个标题、一个 ID） | 直接作为参数传给下一个节点 | 别把大段原文一起带过去 |
| 节点产出是长文或结构化数据 | 落成一个中间文件/草稿，下个节点去读 | 给文件起稳定名字，避免被覆盖 |
| 多个下游都要同一份数据 | 上游只产一次，下游各自读取 | 别让每个下游都重新抓取一遍 |
| 数据需要跨时间保留 | 明确存到持久位置，而非临时上下文 | 临时区可能在会话结束后清空 |
| 上游可能失败/为空 | 下游先做存在性判断再处理 | 否则容易空指针式报错 |
编排的稳不稳，七成看数据过手是否干净——宁可多落一个中间文件，也别赌上下文能替你记住。
排错要点
流水线跑起来之后，麻烦才真正开始。下面几个坑是我踩过、也见过别人踩的，按出现频率排：
上下文丢失。 这是最常见的。症状是新节点「好像没看到前面的结果」。原因多半是中间产物没落盘，或者上下文窗口被前面的长输出挤掉了。排错时先看上一个节点的产物是否真的留下了，再确认新节点读的是不是同一份。
循环调用。 当两个技能互相把对方当成下一步，就会陷入死循环：A 调 B，B 又调 A……轻则跑很久不出结果，重则把上下文和配额耗光。预防办法是在编排时明确「每一步只能走向尚未执行过的下游」，必要时加一个最大步数上限。
状态不一致。 比如并行节点 A 和 B 都改了同一份共享数据，谁后写谁覆盖，最后结果对不上。这种尤其隐蔽，因为它不一定报错，只是「结果不对」。解决思路是尽量让并行节点各写各的独立产物，最后由汇总节点统一合并，而不是抢同一份文件。
错误被吞掉。 某个节点悄悄失败了，但编排层没拦住，后续节点拿空数据硬跑，最后产出一份看起来正常、其实内容缺失的报告。建议在关键节点后加一个「校验」步骤：检查产物是否符合预期格式、是否非空，不通过就中断并告警，而不是继续往下传。
调试时别整条重跑。 这是效率大忌。好的做法是让每个节点支持「从指定产物接着跑」，这样你改了第三个节点的逻辑，只需要喂给它第二个节点的产物重新验证，而不用把前两步再跑一遍。
排错的第一原则：先把每一步的产物单独看一遍，再谈修逻辑。流水线的问题，九成能从中间产物里现形。
小结
把多个 OpenClaw 技能组合成流水线，本质是把「你手动在技能之间传话」这件重复劳动，变成编排层自动完成。它不要求你重写技能，而是改变使用方式：先按「阶段」拆任务，再决定哪些串行、哪些并行、数据怎么落盘过手，最后补上校验和错误处理。
记住几个关键点：不确定依赖关系时先用串行；中间产物尽量落盘、别全压在上下文里；并行节点要避免抢同一份共享状态；每个节点都该能「从中间产物接着跑」，方便单独调试。做到这些，原本要你盯着跑半小时的多段任务，就能一键交给流水线，跑完你只管看结果。
如果你已经玩熟了单技能，编排就是下一个值得投入的方向。它不会让你的某个技能变强，但会让你整体省下大量重复操作的时间——而这，恰恰是工具该替人扛下的那部分。