跳转至

Claude Code 编排原语——决策指南

概述

Claude Code 提供五种编排原语（Skills、子智能体、Agent View、Agent Teams、动态工作流）以及一种能力暴露协议（MCP）。如何选择正确的组合，是 Claude Code 集成中最关键的决策：它直接影响上下文成本、智能体协调方式、可重复性，以及计划的可观测性与复用性。

本指南为每种原语提供决策框架，并说明 MCP 与所有原语之间的关系。

原语速览

原语 定义 协调者 工作者之间是否通信 计划存储位置
MCP 向智能体暴露工具/资源的标准协议 不适用——属于能力层，而非编排层 不适用 不适用
Skills 可复用的 /command 指令，由 Claude 执行 Claude，遵循技能正文 不适用——单一智能体 技能文件（SKILL.md）
子智能体 在独立上下文中运行的委派工作者，由会话内部生成 Claude，逐轮协调 否——仅向主智能体汇报 Claude 的上下文窗口
Agent View 由用户管理的后台会话调度界面 用户，直接管理 否——各会话相互独立 用户的决策
Agent Teams 由主导智能体协调、共享任务列表并支持消息传递的工作者会话 主导智能体，自主协调 是——支持智能体间直接通信 主导智能体的任务列表
动态工作流 由运行时跨数百个子智能体执行的 JS 脚本 脚本本身 否——结果存储于脚本变量中 脚本

MCP：能力层（而非编排选项）

MCP 与上述编排原语正交。它的职责是将外部系统——数据库、API、文件系统、服务——暴露为任何 Claude 智能体均可调用的工具。

External System → MCP Server → Agent (subagent, skill runner, teammate, workflow agent)

适合使用 MCP 的场景： 需要让智能体访问 Claude 内置工具以外的能力时，例如查询数据库、调用私有 REST API、读取云存储桶，或触发外部工作流。

MCP 无法替代编排原语。确定好智能体协调方式（Skills、子智能体、Agent Teams 或工作流）后，MCP 决定这些智能体能调用什么。所有编排原语均可同时使用 MCP 工具。

MCP 问题 解答
应该用 MCP 替代子智能体吗？ 否——两者配合使用。MCP 提供能力；子智能体负责协调工作者。
工作流智能体可以调用 MCP 工具吗？ 可以——工作流子智能体继承会话的工具许可列表，包括 MCP 服务器。
技能可以调用 MCP 工具吗？ 可以——技能可以调用当前会话中任何可用的 MCP 工具。
什么情况下 MCP 不适合？ 当 Claude 的内置工具（文件读写、bash、网络搜索）已能满足需求时。为 Claude 已具备的能力额外添加 MCP 服务器只会带来不必要的间接层。

决策流程图

flowchart TD START(["开始"]) --> MCP_Q{"把外部系统暴露<br/>为可调用工具？<br/>如数据库、API、服务"} MCP_Q -->|是| MCP["🔌 添加 MCP 服务器<br/>然后继续 ↓"] MCP_Q -->|否| SKILL_Q MCP --> SKILL_Q SKILL_Q{"会再次调用的<br/>可重复流程？<br/>如部署清单、<br/>代码审查、运行手册"} SKILL_Q -->|是| SKILL["📋 技能 SKILL<br/>存为 /command<br/>按需加载 · 便宜<br/>通过仓库共享<br/>由 Claude 自动调用"] SKILL_Q -->|否| COORD_Q COORD_Q{"由谁来协调<br/>这些工作者？"} COORD_Q -->|"你来——派发后<br/>再回来查看"| AGENTVIEW["🖥️ AGENT VIEW<br/>派发并监控<br/>独立会话<br/>需要时介入<br/>研究预览版"] COORD_Q -->|"Claude——<br/>自动协调"| COMMS_Q COMMS_Q{"工作者之间需要<br/>互相沟通吗？<br/>辩论 · 共享发现<br/>相互竞争的假设"} COMMS_Q -->|是| TEAMS["👥 AGENT TEAMS<br/>实验性<br/>共享任务清单<br/>智能体间直接通信<br/>3–10 个伙伴"] COMMS_Q -->|"否——<br/>只要结果"| SCALE_Q SCALE_Q{"规模？"} SCALE_Q -->|"少量任务<br/>1–5 个工作者"| SUBAGENTS["🤖 子智能体 SUBAGENTS<br/>专注的工作者<br/>保留上下文<br/>路由到更便宜的模型<br/>结果汇总返回"] SCALE_Q -->|"数十–数百<br/>或需交叉验证<br/>或可重放的计划"| WORKFLOWS["⚙️ 动态工作流<br/>脚本承载计划<br/>最多 1000 个智能体<br/>后台执行<br/>存为 /command"] style MCP fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f style SKILL fill:#dcfce7,stroke:#16a34a,color:#14532d style AGENTVIEW fill:#fef9c3,stroke:#ca8a04,color:#713f12 style TEAMS fill:#fce7f3,stroke:#db2777,color:#831843 style SUBAGENTS fill:#ede9fe,stroke:#7c3aed,color:#3b0764 style WORKFLOWS fill:#ffedd5,stroke:#ea580c,color:#7c2d12 style START fill:#f1f5f9,stroke:#64748b

各原语的适用场景

Skills——"我有一个需要反复执行的流程"

适合使用的场景： - 你经常将相同的指令、清单或多步骤流程粘贴到对话中 - CLAUDE.md 中某个章节已演变为一套完整流程（技能按需加载；CLAUDE.md 始终加载） - 你希望将工程工作流打包并通过仓库（.claude/skills/）共享 - 你希望 Claude 在识别到特定上下文时自动调用某个流程（frontmatter 中设置 invoke: auto）

不适合使用的场景： - 任务是一次性的——直接向 Claude 提示即可 - 需要并行执行——可将技能与子智能体结合（技能可在子智能体中运行）

Token 成本：低。技能正文仅在被调用时加载，不会永久占用上下文窗口。

子智能体——"我有专项子任务，直接处理会撑爆上下文"

适合使用的场景： - 研究任务、日志分析或文件扫描会向主对话输出大量内容 - 你需要为工作者设置不同的工具访问权限（例如只读研究员、禁止执行 shell 的审计员） - 你希望将低复杂度任务路由到更小、更便宜的模型（Haiku），同时主智能体继续使用 Opus/Sonnet - 你只需要少量（1–5 个）并行工作者，其职责仅为返回摘要

不适合使用的场景： - 工作者之间需要互相通信——使用 Agent Teams - 任务需要数十个工作者或交叉验证——使用动态工作流 - 你希望编排逻辑可复用为脚本——使用动态工作流

Token 成本：中等。每个子智能体有独立的上下文窗口；结果以摘要形式返回给主智能体，而非原文回传。

Agent View——"我想自己分配任务并随时检查进度"

适合使用的场景： - 你有多个独立任务，希望将它们交给后台会话处理 - 你想随时介入、调整方向，或接管某个具体会话 - 你需要一个界面同时展示所有正在运行的会话，以及哪些需要你的输入

不适合使用的场景： - 你希望 Claude 自动协调工作者——使用 Agent Teams 或工作流 - 研究预览阶段的限制对你的场景有实质影响

Token 成本：高（每个会话有独立的上下文），但会话由用户管理，因此范围完全由你控制。

Agent Teams——"我希望工作者能相互讨论并互相质疑"

适合使用的场景： - 工作者需要共享发现、质疑彼此的假设，或在对方输出的基础上继续推进 - 并行探索是核心价值所在：不同审阅者从不同角度评审、针对一个 bug 提出竞争性假设、前后端与测试由不同团队成员各自负责 - 你希望 Claude 自主将项目拆解为任务、分配任务并管理依赖关系

不适合使用的场景： - 工作者需要向同一批文件写入——请对工作进行分区，确保每位团队成员拥有独立文件，或使用 worktrees - 顺序执行的工作——单会话或子智能体更高效，协调开销大于收益 - 需要恢复会话——当前进行中的团队成员会话暂不支持此功能 - 需要超过约 10 个工作者——协调开销随规模上升，建议改用动态工作流

Token 成本：高且线性增长——每位团队成员都是一个完整的 Claude 会话。大多数工作流建议控制在 3–5 名成员。

状态：实验性功能，默认关闭。通过 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 启用。

动态工作流——"我需要规模化、交叉验证，或可重放的编排脚本"

适合使用的场景： - 任务所需的智能体数量超出单次对话的协调能力（代码库审计、500 个文件的迁移） - 你希望让独立智能体对彼此的发现进行对抗性交叉验证，再统一汇报 - 你希望将编排逻辑固化为脚本，以便保存、重跑，并在两次运行之间对比差异 - 计划应存储在代码（脚本）中，而非 Claude 的上下文窗口里

不适合使用的场景： - 少量子智能体或一个技能已经够用——工作流消耗的 Token 明显更多 - 工作者需要在运行途中接受用户输入——工作流不支持运行中交互（应将每个阶段设计为独立工作流）

Token 成本：高且取决于任务规模。建议先在小范围内试跑（单个目录、单个窄问题）以评估开销。/workflows 视图会在运行过程中实时显示每个智能体的 Token 用量。

能力与编排的组合模式

各原语可以相互组合。常见模式如下：

模式 工作方式 适用场景
MCP + Skills 通过 MCP 暴露工具；通过调用该工具的技能执行多步骤流程 以固定流程反复调用私有 API（例如：对预发布环境执行部署检查清单）
MCP + 子智能体 子智能体在隔离的上下文中调用 MCP 工具 查询数据库的研究智能体，避免原始结果污染主上下文
MCP + 工作流 工作流生成数百个子智能体，每个子智能体调用 MCP 工具（例如：查询搜索 API） 大规模研究任务，向外部 API 进行扇出检索——类似检索层的 Perplexity Search as Code
Skills + 子智能体 技能正文在子智能体内运行（frontmatter 设置 subagent: true） 可复用但上下文占用较大的流程（例如：扫描大文件的代码审查技能）
子智能体 + Worktrees 每个子智能体获得独立的 git checkout 涉及相同文件的并行实现任务；防止写入冲突
工作流 + 已保存命令 工作流运行成功后，将其保存为 /command 将一次性编排脚本转化为可复用的工程工具（例如：/audit-endpoints、/migrate-module）

决策速查表

如果你想…… 使用
将外部系统暴露为可调用工具 MCP
将可复用流程打包为斜杠命令 Skill
将专项子任务卸载出去以保护主上下文 子智能体
将低复杂度任务路由到更便宜的模型 子智能体（在定义中设置 model: haiku）
自行调度任务并监控进度 Agent View
让智能体直接辩论并共享发现 Agent Teams
用可重放脚本协调数十至数百个智能体 动态工作流
跨独立智能体进行交叉验证 动态工作流
执行大规模迁移或全代码库审计 动态工作流
以上任意场景，加上外部工具或 API 在适合的方案上叠加 MCP

最佳实践

挑战 建议
选择了过于强大的原语 从最简单的选项开始：技能 → 子智能体 → Agent Teams → 工作流。只有当更简单的原语真的无法满足需求时，再升级。
Token 超支 子智能体以摘要形式回传结果（成本适中）；Agent Teams 和工作流的成本呈线性倍增。在确定规模前，先在小范围内进行基准测试。
MCP 蔓延 仅为 Claude 原生不具备的能力添加 MCP 服务器。许可列表中的每个 MCP 服务器在工作流运行期间对所有智能体可见，应尽量缩小暴露面。
缺乏可重复性 运行超过两次的编排逻辑都应保存为技能或工作流命令。随着复杂度增长的临时提示词会带来维护风险。
并行工作中的文件冲突 使用 worktrees 隔离文件访问。Agent Teams 不会自动隔离；需为每位团队成员明确划分文件所有权。
运行中断 动态工作流不支持在运行过程中接受用户输入。对于需要在阶段间进行人工审批的任务，应将其拆分为按顺序运行的独立工作流。

参见

参考资料