Skill、Tool、Workflow 与 Subagent

一句话理解：Tool 是手，Skill 是手艺，Workflow 是流水线，Subagent 是派出去干活的同事。先问清楚“到底缺什么”，再决定用哪种形态。

导论里的「Agent、Skill、Tool 与 Workflow」建立了基本概念。这一课解决的是评审需求时真正会遇到的问题：一个能力摆在面前，到底该做成 Skill、Tool、Workflow 还是 Subagent？

选错形态的代价很具体。把权限控制写进 Skill，等于只是“请求”模型别越界，而不是强制；把一个需要判断的排查过程写成固定 Workflow，遇到新情况就会卡住；给每个小步骤都开一个 Subagent，成本翻几倍，信息还在交接中丢失。

四者对比

维度	Tool	Skill	Workflow	Subagent
本质	一个可调用的能力接口	一套按需加载的方法、知识与脚本	预先写好的执行路径	拥有独立上下文的子 Agent
解决什么	Agent “能不能”作用于外部系统	Agent “会不会”把事情做好	固定流程“每次都一样”	上下文隔离、并行、权限收窄
谁决定何时使用	模型在循环中选择	模型按描述判断，或用户手动调用	代码或触发器	主 Agent 委派，或用户指定
确定性	执行确定，是否调用不确定	指令由模型理解执行，结果会有差异	高	低，本身就是一个 Agent
对主上下文的影响	工具定义与返回结果	描述常驻，触发后加入正文	通常只返回结果	只有最终摘要返回主上下文
客服工单场景的例子	get_ticket(ticket_id)	工单排查 SOP 与工单分类表	每晚 2 点批量拉取超时未响应的工单	翻 200 条历史工单记录，只返回结论

除了这四个，还有几个经常一起出现的“邻居”：

• System Prompt / 项目说明文件（如 CLAUDE.md）：每次对话都加载，放“永远都要遵守”的规则。Claude Code 文档给的经验法则是：每个会话都要知道的放这里，只是偶尔需要的参考资料或流程做成 Skill。
• MCP：一种把 Tool 标准化接入的协议，详见「为什么需要 MCP」。它提供连接，Skill 教 Agent 怎么用好这些连接。
• Hook：在工具调用前后等生命周期节点必然执行的程序逻辑，详见「Hooks 与生命周期」。

把四者和它们的“邻居”放进同一个 Agent 系统，各自的位置和关系如下：

选择方法：五个问题

拿到一个能力需求，按顺序问：

第 5 问值得单独强调。Claude Code 文档在比较 Hook 和 Skill 时说得很清楚：在 Skill 或说明文件里写“不要编辑 .env”，只是一个请求；用 Hook 在工具调用前拦截，才是强制执行。必须每次都成立的规则，要交给程序。这与「程序校验优先」是同一个原则。

同一个客服工单场景的拆分

以一个「客服工单处理 Agent」为例，把各部分放到合适的位置：

各部分的归属一目了然：连接放在 Tool，方法放在 Skill，固定触发放在 Workflow，脏活累活交给 Subagent，红线交给程序。以后要改排查标准，业务专家只需改 Skill；要换数据源，研发只需改 MCP Server，两边互不影响。

常见的组合方式

这几种形态不是互斥的，实际系统里经常组合使用：

组合	怎么配合	例子
Skill + MCP	MCP 提供连接，Skill 说明怎么用好	MCP 连上数据仓库，Skill 写清表结构、口径和“排除测试账号”的规则
Skill + 脚本	Skill 负责判断，脚本负责确定性计算	SEO Skill 调用 check_page.py 提取标签，再由模型按规则判定
Skill 在 Subagent 中运行	把 Skill 放进隔离上下文执行	Claude Code 中设置 context: fork 的调研类 Skill
Subagent 预加载 Skill	子 Agent 启动时就带上领域知识	Claude Code 子 Agent 定义里的 skills 字段，启动时注入完整 Skill 内容
Workflow 调用 Agent	固定流程中的某一步交给 Agent 判断	见「混合架构」

Subagent 与上下文隔离的更多设计细节，在「Subagent 与上下文隔离」展开。

常见误区

• “用 Skill 来做权限控制。” Skill 里的“禁止”是给模型的指令，模型可能不遵守，也可能被注入攻击绕过。权限必须由工具层和运行系统控制。
• “流程重要，所以写成 Skill，让它每次都照做。” Skill 由模型理解执行，天然存在差异。真正需要逐字一致的步骤（比如财务对账），应该写成脚本或 Workflow，再让 Skill 去调用。
• “每个步骤都开一个 Subagent，分工更清楚。” 每个 Subagent 都是一次完整的 Agent 运行，成本和延迟成倍增加，交接时还会丢信息。只有当隔离、并行或权限收窄带来的收益明确时才用。
• “把 SOP 写进工具描述里。” 工具描述应该只说明这个工具做什么、参数是什么。排查顺序、判断标准这类跨工具的方法，属于 Skill。

产品经理检查清单

评审一份 Agent 能力设计时，逐条确认：

• 每一项能力都说明了它属于 Tool、Skill、Workflow、Subagent 还是常驻指令，并给出了理由。
• 所有“绝对不能做”的规则都有程序层面的保障，而不是只写在 Prompt 或 Skill 里。
• 业务专家可以在不改代码的情况下更新方法和标准。
• 使用 Subagent 的地方，都能说清楚隔离或并行换来了什么。
• 固定、高频、必须一致的步骤没有交给模型自由发挥。

练习

把「SEO 诊断」的完整人工流程拆解归类（约 45 分钟）：

1. 写出 10 个步骤，例如：拉取站点地图、逐页抓取、提取标签、判断标题是否合格、检查 canonical、汇总问题、按优先级排序、生成报告、创建修复任务、下周复查。
2. 为每一步填写：

步骤	归类（Tool / Skill / Workflow / Subagent / 常驻指令）	理由	是否需要程序强制
例：逐页抓取 200 个页面	Subagent + Tool	中间输出量大，主任务只需要问题汇总	否

3. 找出你最犹豫的一步，写下两种方案各自的风险。更系统的步骤归类方法见「步骤归类」。

延伸阅读

• Extend Claude Code：CLAUDE.md、Skill、Subagent、Hook、MCP 的对比与组合方式。
• Create custom subagents：Subagent 的定义方式，以及如何为子 Agent 预加载 Skill。

下一步

下一课「写好一个 Skill」会讲清楚：描述怎么写才能准确触发，正文写什么、不写什么，以及怎么用评测驱动 Skill 迭代。