在 2025 年的 10 月份，Anthropic 发布了 Claude 模型的一项重大更新的 Agent Skills，它允许用户将专业知识、脚本和资源打包成模块化的“技能文件夹”（Skill folders），让 AI 能在特定工作场景中更专业地执行任务。
如果我们在做行业 Agent、内部 Copilot、或想把 Claude Code / API 用在业务里，那就需要我们在做之前把「Skill」和「行业 Workflow」这两件事想清楚，并知道从哪里下手。
1. Skill 和行业 Workflow 的概念
1.1 Skill 是什么？
简单说：
Skill = 给模型的一份可复用「操作说明书 + 流程模板」
在 Claude 体系里，Skill 是一个带 SKILL.md 的文件夹，它告诉模型：
“在什么情况下该用我、我要完成什么任务、要按什么步骤做、输出要长什么样。”
特点有几个：
-
面向具体任务，不是一个抽象的「能力标签」
例如：生成符合公司品牌规范的 PPT，按照内部代码规范重构文件，按财务模板做对账报告。 -
本质上是文字写清楚的 SOP + 可选的脚本
主体就是 Markdown 文档，有需要时再绑上 Python 脚本去做确定性处理。 -
可以被模型自动发现和按需加载
模型不会一直把完整 Skill 塞在上下文里，只在命中时再读取详细内容。
它和我们平时说的「提示词」的区别在于：
提示词是一次性、散落的；Skill 是结构化、可版本化、可共享的。
1.2 行业 Workflow 是什么？
Workflow 可以理解为：
把行业中的业务流程，做成清晰的步骤编排和 IF-ELSE 逻辑。
过去这些东西已经存在于：
-
各种脚本、RPA、BPM 系统 -
系统之间的 API 调用编排 -
内部运维 / 运营同学脑子里和文档里的 SOP
在 Agent 语境下，我们关心的是一件事：
怎么把这些已有流程封装成「可由 Agent 触发、可观测、可审计」的工作流节点。
行业 Workflow 的关键特征：
-
强约束：
对输入 / 输出有严格格式要求，执行过程里有清晰的分支、回滚、告警。 -
强依赖业务 Know-how：
为什么要这样分支，Why 在流程里，而不是在模型参数里。 -
长期稳定运行：
一旦跑到生产，就不希望被大模型的「心情」影响。
2. Claude Code 的 Skill
在 Claude 的整体设计里，Skills 是一个非常核心的扩展机制。它解决了两个问题：
-
如何在不撑爆上下文的前提下，给模型装很多垂直能力？ -
如何让业务团队通过“写文档”的方式，而不是“写模型”的方式扩展能力？
2.1 一个 Skill = 一个带 SKILL.md 的文件夹
Claude 官方定义里，一个 Skill 的最小单元就是：
-
一个文件夹 -
里面一个 SKILL.md -
也可以再带一些脚本、资源文件
官方给出的模板是这样的：
---
name: my-first-skill
description: 这是一个关于此 Skill 能做什么以及何时使用它的清晰描述。
---
# 我的第一个 Skill
[在这里添加您的指令，Claude 在激活此 Skill 时会遵循这些指令]
## 示例
- 用法示例 1
- 用法示例 2
几个要点：
-
name：唯一标识，最好跟任务直接相关。 -
description：非常重要，模型靠这个来判断「什么时候用你」。 -
正文部分：
写清楚目标、步骤、注意事项、输出格式、示例。
只要这一个 Markdown 写好了，一个可用 Skill 就成立了，不需要额外的配置文件。
2.2 具体例子：PPT Skill
官方仓库里有一个 PPTX 相关的 Skill，SKILL.md 类似下面这种结构：
-
YAML Frontmatter：说明 Skill 名称、用途（处理 PPTX） -
正文：分章节写 -
如何解析 PPTX -
如何修改版式 -
如何保证品牌颜色与模板统一 -
输入 / 输出约定 -
示例调用方式
-
Claude 的做法是：
-
会话启动时，只把所有 Skill 的 name + description读一遍，放到系统级提示里。 -
当用户输入与某个 Skill 的描述高度匹配时，Claude 再去把这个 Skill 的完整内容加载到上下文中。
这就是文档里提到的「渐进式披露（Progressive Disclosure）」机制。
2.3 渐进式披露
这个词其实有点装，但装得有点厉害，使用这种方式的原因很直接：Token 成本和性能。
-
初始加载时，每个 Skill 只占用几十个 Token（元信息）。 -
真正用到的时候，才把 SKILL.md 的主体搬进来。 -
如果 Skill 还拆成多个文件，Claude 只会读当前任务需要的那部分。
结论：我们可以放心装很多 Skill，而不用太担心上下文被占满。
2.4 Skill 里可以带代码
文档里也提到，Skill 可以带 Python 脚本等可执行文件。
用途主要有两类：
-
做确定性计算 / 校验 -
排序、过滤、格式校验 -
比如：生成 GIF 之后检查文件大小是否符合 Slack 限制
-
-
做简单的集成调用 -
调一个内部 API -
读取一个本地文件，然后把内容返给模型
-
设计上，有一条很实用的边界：
-
流程和策略写在 SKILL.md -
需要 100% 确定性 的步骤写在脚本里
模型不负责「每次都从零写代码」，而是调用你已经写好、已经验证过的代码。
3. Skill 和 Tool / MCP 的边界
很多人会把 Skill、Tool、MCP 混在一起，这里做个简单对比方便后面聊 Workflow。
3.1 Skill：教模型「怎么做」
-
把我们的 SOP、套路、模板，变成模型可执行的说明书。 -
适合： -
结构化写作 -
格式转换 -
合规校验 -
数据清洗 / 整理
-
-
优点： -
写文档就能做定制 -
Token 成本可控 -
容易版本化和团队共享
-
3.2 MCP / Tools：帮模型「去做」
-
MCP 解决的是：如何以统一协议，让模型调用外部系统 / 数据源 / API。 -
它关注的是： -
怎么查 GitHub -
怎么调 CI/CD -
怎么查数据库 -
怎么发 Slack 消息
-
简要总结就是一句话：Skill 面向流程，MCP 面向集成。
3.3 Skill + MCP 的组合
在一个典型任务里：
-
MCP 负责：拿到需要的数据、执行动作 -
Skill 负责：拿到这些结果后怎么分析、怎么生成符合规范的输出
这其实已经非常接近我们后面要讲的「Workflow + Agent」的拆分思路。
4. 行业 Workflow：Skill 落地的载体
前面讲的是 Skill 这一颗颗能力点”，接下来要看它们怎么和行业 Workflow 结合。
4.1 Agent 是交互方式，不是业务本身
再强调一次我们之前文章中的观点：Agent 是交互方式，不是业务本身
在行业里，Agent 更适合作为：
-
自然语言入口 -
意图理解与参数提取 -
初步判断和分发
真正的行业壁垒在于：
-
我们内部沉淀的 SOP -
历史案例和边缘场景处理方式 -
审批链路和风控规则
这些东西，应该放在：
-
Workflow 编排系统 -
规则引擎 -
Skill + MCP 的组合
而不是「指望一个通用 Agent 自己学出来」。
4.2 为什么不能纯 Agent？
-
幻觉和确定性冲突 -
行业里很多流程（财务、生产、安全）对错误零容忍。 -
1% 的错误率，对于 Demo 可以接受，对生产不行。
-
-
过程黑盒，难以审计 -
Agent 的推理链路在模型内部 -
出现问题难以复盘和归责 -
很难满足合规和审计要求
-
-
成本和延迟 -
让模型去规划每个按钮、每个 if-else，是在烧算力 -
这些确定性逻辑用传统代码 / Workflow 做更合适
-
所以，在企业 / 行业场景里，更现实的模式是：
Workflow + Agent
Agent 做理解和决策，Workflow 做执行和兜底。
5. 「Workflow + Agent」的混合架构
把前面的点合起来，可以得到一个常见的分层结构。
5.1 顶层：意图理解与路由（Agent）
职责只有三件：
-
理解用户在说什么（意图识别） -
把需要的参数补齐（参数提取 + 追问） -
决定触发哪个 Workflow / Skill 组合（路由）
流程可以简单画成：
用户 → 自然语言
→ Agent：识别意图 + 提取参数
→ 选中对应 Workflow（或再转给某个二级 Agent）
→ Workflow 执行
→ 结果交给 Agent 格式化给用户
这一步里，Skill 可以怎么用？
-
把「意图分类规范」「参数提取规则」「话术模板」写成一个 Skill -
在 Skill 里明确： -
出现哪些关键词 / 条件时，对应什么意图 -
提取不到关键信息时，按怎样的模板向用户追问
-
5.2 中间层：RAG + 决策
有些问题不能直接映射到单个 Workflow，需要先查知识再决定走哪条路。
典型例子：
“设备报警 E03，我该怎么办？”
步骤一般是：
-
Agent 调用 RAG，在知识库中检索 E03 的说明和处理方案。 -
Skill 里定义好： -
如何解释错误码 -
不同错误码对应的处理选项
-
-
根据检索结果和规则，决定触发： -
远程重启流程 -
提交工单流程 -
安排现场工程师流程
-
这里的组合关系是：
-
RAG：提供上下文知识 -
Skill：约束「如何做决策、如何提问、如何输出」 -
Workflow：完成最终执行动作
5.3 底层：确定性执行（Workflow / RPA / 脚本）
这一层的唯一要求：
不要信模型，要信代码和流程编排。
包括：
-
API 调用链 -
BPM 流程 -
RPA 机器人 -
定时任务 -
数据库操作事务
这里非常适合做成「Skill + MCP + Workflow」的组合：
-
Workflow 把一串 API / RPC / 脚本串起来 -
MCP 把外部系统包装成标准工具 -
Skill 负责： -
输入规范 -
输出规范 -
错误处理策略 -
不同状态码的解释
-
最后返回给 Agent 的应该是：
-
清晰的状态（成功 / 失败 / 部分成功） -
明确的字段（JSON 等结构化结果） -
标准错误码和错误信息
5.4 最后一层：结果转述（Agent）
Agent 的工作只是：
-
把结构化结果翻译成人能看懂的话 -
必要时附上详细解释和后续建议 -
避免「编故事」，严格按返回字段说话
在这一步也可以挂一个简单 Skill：
-
统一输出口吻 -
统一敏感信息处理方式 -
统一错误提示文案
6. Skill 在行业 Workflow 里的落地方式
回到文章标题里的核心问题：行业 Workflow 如何通过 Skill 落地？
可以拆成三步。
6.1 把「人做事的方式」变成 Skill
先不碰系统，先去梳理：
-
关键流程当前是怎么执行的？ -
有哪些「资深同事会说：新人容易犯错的点」？ -
有没有文档 / 模板 / 复盘材料？
然后做的事情是：
-
挑出重复度高、流程相对固定的一批任务。 -
每个任务建一个 Skill 文件夹，写 SKILL.md：-
场景描述：什么时候应该用这个 Skill？ -
输入要求：有哪些字段，格式是什么？ -
处理步骤：拆成 1、2、3… -
输出规范：JSON 字段 + 人类可读的模板 -
示例：2~3 个高频真实例子
-
第一轮不用追求覆盖所有流程，重点是把写 Skill 这件事本身跑顺。
6.2 把「系统做事的方式」变成 Workflow + MCP
接下来梳理现有系统资产：
-
哪些已有 API / 脚本 / RPA 可以直接复用？ -
哪些流程现在是人工填表 + 审批 + 抄数？ -
哪些操作有合规 / 风控要求，必须严格走系统？
然后做：
-
把可复用的系统能力包装成 MCP / 内部 API。 -
用我们熟悉的方式编排成 Workflow（BPM / 编排平台 / 自写 Orchestrator）。 -
明确每个 Workflow 的： -
输入结构 -
输出结构 -
错误码定义 -
审计日志
-
这一步的原则是：
尽量少改存量系统，尽量通过「外面包一层」的方式让它变成可调用的 Workflow 组件。
6.3 用 Skill 把「人」和「系统」连起来
最后一步，把 Skill 作为桥梁：
-
上游：Agent 与用户对话 -
中游：Skill 指导 Agent 该怎么理解、怎么提问、怎么路由 -
下游：Workflow/MCP 真正执行动作
一个典型链路会变成：
-
用户输入需求 -
Agent 用「意图 Skill」判断任务类型 -
分发给对应领域 Agent -
领域 Agent 读取对应 Skill： -
补齐参数 -
调用 RAG 查规则 -
决定调用哪个 Workflow
-
-
Workflow 执行，通过 MCP / API 触达系统 -
返回结果由领域 Agent 按「输出 Skill」转成年类可读结果 -
Agent 统一封装成对用户的话术
所有「经验」、「SOP」、「注意事项」，尽量沉淀在 Skill 里：
-
方便以后版本升级 -
方便新业务线复用 -
方便做变更审计（Skill 本身可以版本控制）
7. 实施过程中的几个注意点
7.1 先把 Skill 写“够细”，再考虑自动化程度
很多团队上来就想着「全自动」，结果 Agent 兜不住，Workflow 无法覆盖异常，最后完全不敢放生产。
相对稳妥的节奏是：
-
用 Skill 把流程写细写透，先跑一段时间「人机协同」： -
Agent 给出建议 -
人来点确认 / 修改
-
-
统计哪些环节几乎没有人工干预 -
把这些环节下沉成 Workflow，逐步提高自动化比例
这样做有一个副作用：整个流程的「隐性知识」会被 Skill 强制写出来，对组织本身也是一种梳理。
7.2 旧系统是企业的「来时路」
很多看起来陈旧的：
-
定时脚本 -
报文接口 -
Excel 宏
从「Workflow + Agent」的角度看都是资产。
Skill 负责解释「什么时候、为什么、怎么用它」，MCP / Workflow 负责「怎么安全调用它」。
相比完全重构，一个实用的策略是：
给旧系统加一个 AI 适配层，而不是要求旧系统「变成 AI 原生」。
7.3 结构化数据回流
Agent 与用户的对话里，有大量可以反哺业务的信息：
-
用户真实需求 -
高频异常 -
流程里的瓶颈点 -
新出现的边缘场景
建议在设计时就准备好：
-
把关键字段结构化写入日志 / 数据库 -
定期用这些数据更新： -
Skill 内容 -
RAG 知识库 -
流程设计（Workflow）
-
不要只留下聊天记录，要留下可分析的行为数据。
8. 小结
把前面的内容合在一起，其实可以简化为三条：
-
Skill 把「怎么做事」固化下来 -
它是 Agent 的“操作手册” -
它让流程可以被描述、复用、版本化
-
-
Workflow 把「谁来做、何时做、按什么顺序做」编排起来 -
它对接真实系统和资源 -
它保证执行的确定性和审计能力
-
-
Agent 把「人类模糊的需求」翻译成「可以被 Skill + Workflow 执行的指令」 -
它是交互层和调度层 -
它不是行业壁垒本身
-
在这个结构下，“降本增效”不再是一个抽象口号，而是一个比较直观的路径：
-
过去那些无法自动化的非结构化需求（邮件、沟通、模糊指令）， -
通过 Agent + Skill 变成可结构化的任务描述， -
再通过 Workflow + MCP 交给稳定的代码和系统去执行。
从研发团队视角看，这套东西真正改变的是工作方式：
-
从「写提示」变成「设计并维护一套可执行流程」； -
从「做一次性 Demo」变成「搭一套能长期演进的智能基础设施」。
如果你正在做行业 Agent，或者准备在内部推一个 AI 助手，可以先从一件事开始：
挑一个你们团队最常做、步骤最清晰、但最浪费时间的任务，把它完整写成一个 Skill，再把现有系统封装成一个 Workflow。
这两个拼起来，基本就是你们自己的第一个「行业 Workflow + Agent」原型。
以上。