AI Agent 的 Skill 和行业 Workflow

在 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 是一个非常核心的扩展机制。它解决了两个问题：

1. 如何在不撑爆上下文的前提下，给模型装很多垂直能力？
2. 如何让业务团队通过“写文档”的方式，而不是“写模型”的方式扩展能力？

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 的做法是：

1. 会话启动时，只把所有 Skill 的 name + description 读一遍，放到系统级提示里。
2. 当用户输入与某个 Skill 的描述高度匹配时，Claude 再去把这个 Skill 的完整内容加载到上下文中。

这就是文档里提到的「渐进式披露（Progressive Disclosure）」机制。

2.3 渐进式披露

这个词其实有点装，但装得有点厉害，使用这种方式的原因很直接：Token 成本和性能。

• 初始加载时，每个 Skill 只占用几十个 Token（元信息）。
• 真正用到的时候，才把 SKILL.md 的主体搬进来。
• 如果 Skill 还拆成多个文件，Claude 只会读当前任务需要的那部分。

结论：我们可以放心装很多 Skill，而不用太担心上下文被占满。

2.4 Skill 里可以带代码

文档里也提到，Skill 可以带 Python 脚本等可执行文件。

用途主要有两类：

1. 做确定性计算 / 校验

• 排序、过滤、格式校验
• 比如：生成 GIF 之后检查文件大小是否符合 Slack 限制

1. 做简单的集成调用

• 调一个内部 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. 幻觉和确定性冲突

• 行业里很多流程（财务、生产、安全）对错误零容忍。
• 1% 的错误率，对于 Demo 可以接受，对生产不行。

1. 过程黑盒，难以审计

• Agent 的推理链路在模型内部
• 出现问题难以复盘和归责
• 很难满足合规和审计要求

1. 成本和延迟

• 让模型去规划每个按钮、每个 if-else，是在烧算力
• 这些确定性逻辑用传统代码 / Workflow 做更合适

所以，在企业 / 行业场景里，更现实的模式是：

Workflow + Agent Agent 做理解和决策，Workflow 做执行和兜底。

5. 「Workflow + Agent」的混合架构

把前面的点合起来，可以得到一个常见的分层结构。

5.1 顶层：意图理解与路由（Agent）

职责只有三件：

1. 理解用户在说什么（意图识别）
2. 把需要的参数补齐（参数提取 + 追问）
3. 决定触发哪个 Workflow / Skill 组合（路由）

流程可以简单画成：

用户 → 自然语言 → Agent：识别意图 + 提取参数 → 选中对应 Workflow（或再转给某个二级 Agent） → Workflow 执行 → 结果交给 Agent 格式化给用户

这一步里，Skill 可以怎么用？

• 把「意图分类规范」「参数提取规则」「话术模板」写成一个 Skill
• 在 Skill 里明确：
• 出现哪些关键词 / 条件时，对应什么意图
• 提取不到关键信息时，按怎样的模板向用户追问

5.2 中间层：RAG + 决策

有些问题不能直接映射到单个 Workflow，需要先查知识再决定走哪条路。

典型例子：

“设备报警 E03，我该怎么办？”

步骤一般是：

1. Agent 调用 RAG，在知识库中检索 E03 的说明和处理方案。
2. Skill 里定义好：

• 如何解释错误码
• 不同错误码对应的处理选项

1. 根据检索结果和规则，决定触发：

• 远程重启流程
• 提交工单流程
• 安排现场工程师流程

这里的组合关系是：

• 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

先不碰系统，先去梳理：

• 关键流程当前是怎么执行的？
• 有哪些「资深同事会说：新人容易犯错的点」？
• 有没有文档 / 模板 / 复盘材料？

然后做的事情是：

1. 挑出重复度高、流程相对固定的一批任务。
2. 每个任务建一个 Skill 文件夹，写 SKILL.md：

• 场景描述：什么时候应该用这个 Skill？
• 输入要求：有哪些字段，格式是什么？
• 处理步骤：拆成 1、2、3…
• 输出规范：JSON 字段 + 人类可读的模板
• 示例：2~3 个高频真实例子

第一轮不用追求覆盖所有流程，重点是把写 Skill 这件事本身跑顺。

6.2 把「系统做事的方式」变成 Workflow + MCP

接下来梳理现有系统资产：

• 哪些已有 API / 脚本 / RPA 可以直接复用？
• 哪些流程现在是人工填表 + 审批 + 抄数？
• 哪些操作有合规 / 风控要求，必须严格走系统？

然后做：

1. 把可复用的系统能力包装成 MCP / 内部 API。
2. 用我们熟悉的方式编排成 Workflow（BPM / 编排平台 / 自写 Orchestrator）。
3. 明确每个 Workflow 的：

• 输入结构
• 输出结构
• 错误码定义
• 审计日志

这一步的原则是：

尽量少改存量系统，尽量通过「外面包一层」的方式让它变成可调用的 Workflow 组件。

6.3 用 Skill 把「人」和「系统」连起来

最后一步，把 Skill 作为桥梁：

• 上游：Agent 与用户对话
• 中游：Skill 指导 Agent 该怎么理解、怎么提问、怎么路由
• 下游：Workflow/MCP 真正执行动作

一个典型链路会变成：

1. 用户输入需求
2. Agent 用「意图 Skill」判断任务类型
3. 分发给对应领域 Agent
4. 领域 Agent 读取对应 Skill：

• 补齐参数
• 调用 RAG 查规则
• 决定调用哪个 Workflow

1. Workflow 执行，通过 MCP / API 触达系统
2. 返回结果由领域 Agent 按「输出 Skill」转成年类可读结果
3. Agent 统一封装成对用户的话术

所有「经验」、「SOP」、「注意事项」，尽量沉淀在 Skill 里：

• 方便以后版本升级
• 方便新业务线复用
• 方便做变更审计（Skill 本身可以版本控制）

7. 实施过程中的几个注意点

7.1 先把 Skill 写“够细”，再考虑自动化程度

很多团队上来就想着「全自动」，结果 Agent 兜不住，Workflow 无法覆盖异常，最后完全不敢放生产。

相对稳妥的节奏是：

1. 用 Skill 把流程写细写透，先跑一段时间「人机协同」：

• Agent 给出建议
• 人来点确认 / 修改

1. 统计哪些环节几乎没有人工干预
2. 把这些环节下沉成 Workflow，逐步提高自动化比例

这样做有一个副作用：整个流程的「隐性知识」会被 Skill 强制写出来，对组织本身也是一种梳理。

7.2 旧系统是企业的「来时路」

很多看起来陈旧的：

• 定时脚本
• 报文接口
• Excel 宏

从「Workflow + Agent」的角度看都是资产。 Skill 负责解释「什么时候、为什么、怎么用它」，MCP / Workflow 负责「怎么安全调用它」。

相比完全重构，一个实用的策略是：

给旧系统加一个 AI 适配层，而不是要求旧系统「变成 AI 原生」。

7.3 结构化数据回流

Agent 与用户的对话里，有大量可以反哺业务的信息：

• 用户真实需求
• 高频异常
• 流程里的瓶颈点
• 新出现的边缘场景

建议在设计时就准备好：

• 把关键字段结构化写入日志 / 数据库
• 定期用这些数据更新：
• Skill 内容
• RAG 知识库
• 流程设计（Workflow）

不要只留下聊天记录，要留下可分析的行为数据。

8. 小结

把前面的内容合在一起，其实可以简化为三条：

1. Skill 把「怎么做事」固化下来

• 它是 Agent 的“操作手册”
• 它让流程可以被描述、复用、版本化

1. Workflow 把「谁来做、何时做、按什么顺序做」编排起来

• 它对接真实系统和资源
• 它保证执行的确定性和审计能力

1. Agent 把「人类模糊的需求」翻译成「可以被 Skill + Workflow 执行的指令」

• 它是交互层和调度层
• 它不是行业壁垒本身

在这个结构下，“降本增效”不再是一个抽象口号，而是一个比较直观的路径：

• 过去那些无法自动化的非结构化需求（邮件、沟通、模糊指令），
• 通过 Agent + Skill 变成可结构化的任务描述，
• 再通过 Workflow + MCP 交给稳定的代码和系统去执行。

从研发团队视角看，这套东西真正改变的是工作方式：

• 从「写提示」变成「设计并维护一套可执行流程」；
• 从「做一次性 Demo」变成「搭一套能长期演进的智能基础设施」。

如果你正在做行业 Agent，或者准备在内部推一个 AI 助手，可以先从一件事开始：

挑一个你们团队最常做、步骤最清晰、但最浪费时间的任务，把它完整写成一个 Skill，再把现有系统封装成一个 Workflow。 这两个拼起来，基本就是你们自己的第一个「行业 Workflow + Agent」原型。

以上。