Appearance
Claude Code 的编排模式将复杂工作流分解为三层：Command 作为用户入口处理交互，Agent 在独立上下文中自主执行数据获取，Skill 负责可复用的输出生成。三者的核心区别在于上下文隔离和触发方式，weather 系统是理解这三层分工的最好示例。
Claude Code Orchestration 编排模式：Command → Agent → Skill 完整实战
三层架构概览
Claude Code 编排模式由三个组件层构成：
用户触发 /command
↓
Command — 入口，处理用户交互，调度工作流
↓
Agent — 独立上下文，自主执行多步任务
├── Preloaded Skill — Agent 的领域知识（启动时注入）
↓
Skill — 可复用的输出生成过程（inline 或 context: fork）每层职责清晰，互不越界：
- Command 不执行业务逻辑，只负责调度
- Agent 不直接生成最终输出，只负责数据获取
- Skill 不做决策，只负责按格式生成输出
Weather 系统完整案例
组件总览
| 组件 | 类型 | 角色 |
|---|---|---|
/weather-orchestrator | Command | 入口：询问单位偏好 → 调用 Agent → 调用 Skill |
weather-agent | Agent | 执行器：调用 Open-Meteo API 获取温度 |
weather-fetcher | Skill（Agent 预加载） | 领域知识：告诉 Agent 如何调用 API |
weather-svg-creator | Skill（独立调用） | 输出：生成 SVG 天气卡片 |
流程图
╔══════════════════════════════════════════════════════════╗
║ ORCHESTRATION WORKFLOW ║
║ Command → Agent → Skill ║
╚══════════════════════════════════════════════════════════╝
┌─────────────────┐
│ User: /weather-orchestrator │
└────────┬────────┘
│
▼
┌──────────────────────────────────────────┐
│ Command: weather-orchestrator │
│ Step 1: AskUserQuestion — C° 还是 F°? │
└──────────────────┬───────────────────────┘
│ User: Celsius
│
Step 2: Agent tool
│
▼
┌──────────────────────────────────────────┐
│ Agent: weather-agent │
│ ● Preloaded skill: weather-fetcher │
│ ● Tools: WebFetch, Read │
│ → 调用 Open-Meteo API → 返回 26°C │
└──────────────────┬───────────────────────┘
│ Returns: temp=26, unit=Celsius
│
Step 3: Skill tool
│
▼
┌──────────────────────────────────────────┐
│ Skill: weather-svg-creator │
│ → 生成 weather.svg │
│ → 写入 output.md │
└──────────────────────────────────────────┘执行步骤
- 用户运行
/weather-orchestrator - Command 用
AskUserQuestion询问摄氏度还是华氏度 - Command 通过 Agent 工具调用
weather-agent weather-agent启动时加载weather-fetcherskill 的完整内容作为领域知识- Agent 按照 weather-fetcher 的指令调用 Open-Meteo API，获取迪拜当前温度
- Agent 返回温度值和单位给 Command
- Command 通过 Skill 工具调用
weather-svg-creator - Skill 生成 SVG 天气卡片和 output.md，完成输出
两种 Skill 模式的关键区别
本案例展示了 Skill 的两种完全不同的用法：
模式 1：Agent Skill（预加载）
yaml
# .claude/agents/weather-agent.md
---
name: weather-agent
skills:
- weather-fetcher # 启动时完整注入 agent 上下文
---yaml
# .claude/skills/weather-fetcher/SKILL.md
---
name: weather-fetcher
user-invocable: false # 不对用户暴露 /weather-fetcher
---- 启动时注入：Agent 启动即拥有 weather-fetcher 的完整知识
- 内部使用：Agent 自主决定何时、如何运用这个知识
user-invocable: false：隐藏/菜单入口，不允许用户直接调用
模式 2：独立 Skill（Command 直接调用）
yaml
# .claude/skills/weather-svg-creator/SKILL.md
---
name: weather-svg-creator
description: 创建迪拜天气 SVG 卡片
---- 按需调用：Command 通过 Skill 工具显式调用
- 接收上下文数据：从调用时的对话上下文中获取温度数据
- 用户也可以调用：
/weather-svg-creator命令可用
核心区别：Agent Skill 是给 Agent 的领域知识；独立 Skill 是给 Command 或用户调用的工具接口。
Command 层实现
yaml
# .claude/commands/weather-orchestrator.md
---
description: 获取迪拜天气并生成 SVG 天气卡片
model: haiku
---
# Weather Orchestrator
## 工作流
### 第一步：询问单位
使用 AskUserQuestion 工具：摄氏度还是华氏度？
### 第二步：获取天气
使用 Agent 工具调用 weather-agent：
- subagent_type: weather-agent
- prompt: 获取迪拜当前温度（[用户选择的单位]）
### 第三步：生成卡片
使用 Skill 工具调用 weather-svg-creator skill关键设计决策：
model: haiku— 编排层只负责调度，不需要高推理能力- 所有业务逻辑委托给 Agent 和 Skill，Command 保持轻量
设计原则
1. 单一职责：每个组件只做一件事
- Command = 调度 + 用户交互
- Agent = 自主数据获取
- Skill = 格式化输出
2. 最小权限：weather-agent 只有 4 个工具（WebFetch, Read, Write, Edit），而不是默认全部工具
3. 上下文隔离：Agent 在独立上下文中运行，大量 API 调用和中间步骤不污染主会话
4. 复用性：weather-svg-creator 既可以被 Command 调用，也可以被用户直接运行 /weather-svg-creator
FAQ
Q: 为什么不直接在 Command 里调用 API，而要用一个 Agent？ A: Agent 在独立上下文中运行，API 调用的中间步骤（网络请求、错误重试、数据解析）不会出现在主会话里。另外 Agent 可以持久记忆（memory: project），能积累历史天气数据。
Q: weather-fetcher 不对用户暴露，那它有什么意义？ A: weather-fetcher 是 weather-agent 的"内置知识"，告诉 Agent 如何调用 Open-Meteo API、参数格式、返回值处理方式。这些细节适合封装在 Skill 里版本控制，而不是写进 Agent 的系统提示中。
Q: Command 也可以不经过 Agent 直接调用 Skill 吗？ A: 可以。本案例的 weather-svg-creator 就是由 Command 直接调用的 Skill。只有当任务需要多步自主执行或上下文隔离时才引入 Agent 层。
Q: 编排模式适合什么场景？ A: 适合复杂的多步工作流，尤其是：数据获取 + 数据处理 + 输出生成的三段式流程；需要与用户交互的节点（AskUserQuestion）；不同步骤需要不同权限或工具集的场景。