到上一篇为止，这个系列的零件全部讲完了：Command、Agent、Skill 各是什么（第 3 篇），分身怎么配（第 4 篇），技能怎么写（第 5 篇），Hooks 怎么强制（第 6 篇），权限怎么放（第 7 篇）。都是零件，这篇组装。
素材仓库里有一套完整在跑的示范系统：输入一句 /weather-orchestrator，它问你用摄氏还是华氏，然后自动查迪拜实时气温，最后在项目里生成一张 SVG 天气卡片和一份摘要。整个流程没有一个环节靠 AI“自觉”，每个角色都被配置和契约按在地上。
我们把它一层层拆开，看完你就能照着改出自己的流水线。
先看输入和输出
在 Claude Code 里输入：
/weather-orchestrator发生三件事：它先弹一个选择框问你要摄氏还是华氏；你选完，它派一个分身去查迪拜实时气温；温度回来后，它调起画卡片的技能，往项目里写两个文件——orchestration-workflow/weather.svg（天气卡片）和 orchestration-workflow/output.md（本次执行的摘要）。
就这些。没有一步需要你盯着，也没有一步是“希望它记得”。下面拆开看每个零件。
全景：三层结构，一条数据流
第 3 篇给过这张系统的全家福，这次我们把数据怎么流画出来：
值得注意的不是有哪三层，而是数据的路径：你的单位偏好从选择框出发，经 Command 写进给 Agent 的指令，Agent 通过技能换成温度数值，数值回到 Command 的上下文，最后被画卡技能写进文件系统。每一跳都经过固定的接口，没有一条数据是靠“上下文里大概还有吧”传下去的。
逐文件拆解：四个文件，各管一段
这套系统一共四个配置文件，住在三个地方。
入口：.claude/commands/weather-orchestrator.md（Command 层）
它是整个流程的指挥，frontmatter 就很有讲究：
---
description: Fetch Dubai weather and create an SVG weather card
model: haiku
allowed-tools:
- AskUserQuestion
- Agent
- Skill
---model: haiku——指挥官用最便宜的模型。编排工作（问一句、派个活、收个结果）不需要聪明，需要省钱。allowed-tools 只给了三件工具：问用户、派分身、调技能。它连 Read 和 Bash 都没有——想自己动手查天气？工具架上根本没有那件工具。
正文部分写的是一份“执行契约”，关键句直接写死：
你必须通过派
weather-agent来完成本命令。禁止用 Bash、WebFetch 或任何其他工具自己抓天气；禁止跳过第一步（用户的单位偏好是必须的输入）；禁止在分身返回温度之前调用画卡技能。
分身：.claude/agents/weather-agent.md（Agent 层）
真正出门查天气的角色，配置里有三处值得抄作业：
allowedTools:
- "Read"
- "Skill"
model: sonnet
memory: project
skills:
- weather-fetcherallowedTools 里故意没有任何网络工具。配置注释里有一句话堪称点睛：“如果你发现自己需要一个网络工具，那是你在绕过技能的信号——停下来，改用 Skill(weather-fetcher)。”这比任何“请务必使用技能”的叮嘱都硬：绕路的门被物理拆掉了。
memory: project 让它每次的读数都进项目记忆——下次执行时，它能在汇报里附一句“比上次高了 2 度”。skills 预载取数手册，出厂即上岗（第 4 篇讲过的机制，这里是实战）。它甚至挂了自己的专属 Hooks——分身干活时你听得到它的动静，第 6 篇的声音系统在这里复用。
取数手册：.claude/skills/weather-fetcher/SKILL.md（Skill 层）
---
user-invocable: false
allowed-tools:
- "WebFetch(*)"
---两个细节：user-invocable: false 说明它是纯后台知识，用户永远不需要手动调它；allowed-tools 里 WebFetch 的许可写在技能这一层——网络权限跟着手册走，谁执行这本手册谁才临时获得联网能力，分身本身依然是“断网”的。
手册内容朴实到感人：两条 Open-Meteo 的 URL（免费、不要 API key）、告诉 AI 从返回 JSON 的哪个字段取温度、以及输出格式。好技能就是这种手感——没有任何炫技，每句话都在消除歧义。
画卡手册：.claude/skills/weather-svg-creator/SKILL.md（Skill 层）
收到温度后负责出活。它展示了第 5 篇说的渐进式披露怎么落地：SKILL.md 本体只有任务说明和三条规则（用调用方给的温度、不许重新抓、两个文件写到固定目录），SVG 模板放进 reference.md，输入输出示例放进 examples.md——执行时用到哪份读哪份。
跑起来时，依次发生什么
- 你输入
/weather-orchestrator，Command 展开，主 Claude 以 haiku 开始执行编排； - 它调
AskUserQuestion问你：摄氏还是华氏？（跳过这步被契约明令禁止——单位是下游的必需输入） - 它用 Agent 工具派出
weather-agent，提示词里带上一句“以用户选的单位查询”； - 分身在自己的独立上下文里启动，预载的 weather-fetcher 技能就位，它调 Skill 工具执行手册，WebFetch 打向 Open-Meteo；
- 温度数值和单位回到 Command 的上下文；
- Command 调起
weather-svg-creator，技能读模板、套数值，把weather.svg和output.md写进orchestration-workflow/。
全程你的主对话只经历了“回答一次选择”和“收到一份总结”，中间的网络请求、JSON 解析全发生在分身的上下文里——第 4 篇的上下文经济学，一次完整的实战。
值得抄的四个设计决策
一、每层一份“不可协商”的契约。 四个文件里有三个写着 Execution Contract，明令禁止本层越权的行为：Command 不许自己抓数据，Agent 不许直连 API，画卡技能不许重新抓取。这不是不信任 AI 的装饰性废话——它是和 allowed-tools 白名单配套的第二道锁：白名单管“拿什么工具”，契约管“拿工具干什么”。
二、fail-closed，不即兴。 两处契约都写了同款兜底：上游没有返回数值，就停下报告失败，不要试图自己补救。AI 的即兴发挥恰恰是流水线失控的起点——“它没查到，我拿旧数据凑一个吧”这种善意，正是你要在配置里掐死的。
三、模型分层计费。 编排的 Command 用 haiku，干活的分身用 sonnet。谁贵谁便宜不看地位看任务，这套系统是第 4 篇“让不同价位的模型各司其职”的实物示范。
四、产物落盘位置写死。 输出文件不落在“AI 觉得合适的地方”，而是技能配置里写死的固定目录。下次执行、别的脚本、你的 CI，都知道去哪找这张卡片。
改造成你自己的流水线
照着改五步，就能把“查天气”换成你的场景：
- 拆任务：哪一步需要问用户（Command + AskUserQuestion）？哪一步是独立的重活（Agent）？哪一步有固定操作知识（Skill）？
- 建四个文件：入口 Command、执行 Agent、N 个技能，目录照搬：
.claude/commands/、.claude/agents/、.claude/skills/<name>/SKILL.md； - 写契约：每层列出“禁止事项”——尤其禁止绕过下一层的捷径；
- 锁白名单：从零开始给工具，跑一遍缺什么加什么，别一上来全开；
- 定产物：输出文件写死目录，让流水线的每跑一次都留下可检查的痕迹。
举第 3 篇提过的例子：把“查天气”换成“跑测试收集报错”，把“画卡片”换成“按报错生成修复补丁”，同一条骨架就是一条质量修复流水线。
两个容易踩的坑
坑一：契约写了一层就停。 只给 Command 写“必须派分身”，分身却可以直连 API——绕过技能的路径还通着。契约要每层各写各的，白名单每层各锁各的，两道锁都要落到位。
坑二：中间产物没落盘。 温度只在上下文里传，一旦某层失败重跑，上一步的结果就悬空了。数值类中间产物学这套系统：要么进 memory（分身的历史读数），要么写进固定文件——上下文是易失的，而磁盘不是。
收工清单
- 三层分工一句话：入口用按钮，重活用分身，手册用本能
- 编排层用 haiku，干活层用 sonnet：模型按任务计费，不看头衔
- 每层两道锁：
allowed-tools白名单 + 白纸黑字的执行契约 - 关键角色的能力要做减法：分身没有网络工具，绕过技能的路才真正断了
- 失败就停（fail-closed），禁止善意的即兴补救
- 产物落盘写死目录，流水线的每次运行都留下可检查的痕迹
- 改造五步：拆任务 → 建四个文件 → 写契约 → 锁白名单 → 定产物
零件、组装、实战，到这篇全部就位。下一篇看一眼地平线：Agent Teams、定时任务、并行开发这些正在快速成型的 Hot 特性，哪些值得现在就上手。