从 Agent 编排到 Skill Runtime：企业 AI 工程化的下一层抽象

从 Agent 编排到 Skill Runtime：企业 AI 工程化的下一层抽象

引子：流程编排能解决一部分问题，但不该成为企业 AI 的第一层沉淀

很多企业做第一个 AI Agent 项目时，会很自然地先画流程图。

这并不是因为团队喜欢复杂，而是因为早期模型确实不够稳定。它有时不会主动拆任务，有时不会选对工具，有时查完数据也不知道怎么继续。工程团队为了让结果可控，就会把用户请求拆成一串节点：先识别意图，再拆任务，再选工具，再执行，再反思，再重试，最后总结。

这套做法在当时有价值。它能把不可控的模型行为拆成看起来可控的步骤，也能让团队更容易定位问题。比如售后退款场景里，流程可以画得很清楚：用户提问，识别退款意图，查订单，查物流，查售后政策，判断责任，生成客服回复，必要时转人工。

但这里有一个容易被低估的变化：大模型能力升级得太快。

很多流程编排，本质是在补旧模型的短板。模型不会稳定拆任务，你写一个任务拆解节点；模型不会稳定选工具，你写一个工具路由节点；模型总结不稳定，你写一个反思和重试节点。可一旦新模型原生具备更好的推理、规划、工具使用和上下文理解能力，这些手写节点就可能被模型能力覆盖，甚至新模型做得比你那套固定编排更自然。

于是问题出现了：你花很多时间沉淀下来的，不一定是企业长期需要的业务资产，而可能只是某一代模型能力不足时的补丁。模型升级后，这些补丁不但价值下降，还可能限制新模型发挥。

真正值得沉淀的，应该是模型升级也不会自动获得的东西。

还是看售后退款。用户不会总是说"请判断这个订单是否可以退款"。他可能说：

客户说用了三天就坏了，不退款就要投诉平台，帮我看看怎么处理。

这句话既像退款问题，又像投诉问题，还可能涉及商品质保、物流状态、客户等级、平台处罚、补偿券、升级工单。新模型也许能更好地理解这句话，也许能自己决定先查订单还是先查物流，但它仍然不知道你们公司内部真正认可的处理方法：

• 哪些退款可以建议放行。
• 哪些必须先看物流异常。
• 哪些客户要升级处理。
• 哪些话术不能说。
• 哪些判断必须留下证据。
• 哪些动作只能 dry-run，不能直接执行。

这些才是企业 AI 项目里真正需要沉淀的东西。它们往往散落在 SOP、Excel、飞书文档、老员工经验、系统操作习惯、Prompt 配置和工具描述里。每做一个 AI 应用，就重新写一遍 Prompt、接一遍工具、补一遍规则。项目越多，维护成本越高。

所以，对很多认知型、辅助决策型 AI 场景来说，第一层沉淀不应该是越来越复杂的流程图，而应该是一层可复用、可治理、可评估的 Skill 层。

原因很直接：流程怎么走，越来越多会被模型能力吸收；但企业自己的业务规则、工具入口、模板资产、风险边界、审计要求，不会因为模型升级而自动出现在模型里。这些才是更值得工程化沉淀的部分。

这篇文章的核心观点很简单：

Workflow 固化流程，Skill 沉淀方法。企业 AI 的早期问题，往往不是流程不够复杂，而是业务方法没有被显式表达。

这不是说 Workflow 不重要。涉及资金、发货、权限、合同、生产数据写入的强状态动作，必须由后端系统、工作流引擎、权限系统和审计系统控制。更准确的路径是：先用 Skill 把业务方法沉淀下来，再把高频、稳定、高风险的环节升级为 Workflow。

接下来我们先讲清楚 Skill 到底是什么，再讲它和 Tool、Workflow、RAG、MCP 的边界，最后再落到一个企业 Web 项目里如何实现。

第一章：Skill 不是 Prompt，而是业务能力包

很多人第一次听到 Skill，会把它理解成"更长的 Prompt 模板"。这个理解不够。

Prompt 更像一次性的指令。比如"你是一个专业客服，请根据以下规则回复用户"。它可以很有用，但它通常缺少版本、权限、审计、资源、工具和验证。

Skill 更像给 AI 系统的一份岗位作业手册。它不只是告诉模型怎么说话，而是把一类任务的做事步骤、业务规则、参考资料、工具脚本、输出模板和风险边界打包在一起。

一个企业 Skill 可以长这样：

refund-review/
  SKILL.md
  references/
    refund_policy.md
    risk_cases.md
  scripts/
    normalize_order_status.py
    check_refund_fields.py
  assets/
    refund_reply_template.md

其中 SKILL.md 是入口。它告诉模型什么时候使用这个 Skill、应该按什么步骤处理、能用哪些工具、要遵守哪些业务规则、输出格式是什么、哪些动作必须人工确认、如何检查结果是否可靠。

references/ 放更长的业务资料，比如退款政策、风险案例、指标口径、产品说明。scripts/ 放轻量、确定性、无副作用的辅助逻辑，比如字段转换、格式校验、局部计算、文档解析。assets/ 放模板，比如 PPT 模板、邮件模板、合同模板。

这里要强调一个边界：生产 API、数据库访问、凭据、审批流、订单修改、资金操作，不应该直接跟着 Skill 包发布。涉及生产数据和副作用的动作，应通过后端 Tool Executor 暴露受控 API，由权限、策略、审计和工作流系统统一控制。

所以，Skill 的价值不是"写一个更聪明的 Prompt"，而是让业务方法变成一种可管理的工程资产。它可以被版本化、被灰度、被评估、被下线，也可以和工具、知识库、模板、审批流组合起来。

以 Claude Skills 这类机制为代表的设计，已经在强调目录结构、元数据、资源文件和 progressive disclosure。背后的思路不是把所有内容塞进一个大 Prompt，而是先让模型看到少量 Skill 元数据，需要时再加载完整内容。

理解了这一点，才能继续讨论它和 Tool、Workflow、RAG、MCP 的关系。

第二章：Tool、Workflow、RAG、MCP 都重要，但它们不等于 Skill

Skill 这个概念容易和很多已有概念混在一起。最常见的问题是：Tool schema 不是也有描述吗？意图识别不是也能路由吗？Workflow 不是也能编排流程吗？RAG 不是也能提供知识吗？MCP 不是也能接工具吗？

这些都对，但它们解决的问题不同。

还是用退款申请这个任务来看：

帮我判断这个退款申请该不该通过，并生成给客户的回复。

在这个任务里，Intent 负责判断用户要办什么事。它可以把请求识别成"退款审核"或"售后处理"。但它只回答"是什么事"，不回答"这件事该怎么办"。

Tool 负责提供可调用能力。比如 query_order 查询订单，query_logistics 查询物流，refund_dry_run 模拟退款结果。Tool schema 会说明参数和返回值，但它不应该承载复杂业务判断。它像按钮，告诉模型能按什么；但什么时候按、为什么按、按完怎么判断，不是 Tool 自己解决的。

RAG 负责检索动态知识。比如退款政策、商品售后规则、历史风险案例。它能把资料找出来，但找出资料不等于会处理业务。模型仍然需要知道如何应用这些资料。

MCP 更像标准化适配协议，让模型或 Agent 以一致方式访问工具、资源和上下文。但 MCP 不替代企业鉴权、审计、事务控制和业务方法。它解决"怎么标准化暴露能力"，不解决"业务上该如何使用这些能力"。

Workflow 负责强约束状态。比如真正退款审批、打款、库存回滚、财务记录。它适合表达必须按顺序执行、状态明确、责任清晰的流程。

Skill 的位置在这些东西之间。它告诉模型：面对退款审核这类任务，应该先查哪些信息，怎样结合规则判断，哪些场景转人工，哪些动作只能 dry-run，最后如何输出给客服。

可以用一句话概括：

Tool 让模型能操作系统，Skill 让模型知道在业务上该不该操作、怎么操作、操作后如何校验；Workflow 管必须怎么走，Skill 管企业通常怎么做。

如果一个 Skill 只是写"用户要退款就调用 refund_tool"，那它没有价值。真正有价值的 Skill 应该包含任务级业务知识：什么时候用、怎么判断、用哪些工具、调用顺序、风险边界、输出格式和校验方式。

这也是为什么我不建议企业一开始就把所有东西做成复杂 Workflow。很多时候，真正需要先沉淀的是"企业通常怎么做这类判断"。

第三章：为什么不要一开始重流程编排

流程编排不是问题，过早流程编排才是问题。

企业做 AI 项目时，流程图给人的安全感很强。每个节点都有输入输出，每个分支看起来可控，每个异常都可以补一个判断。但 AI 场景和传统审批流不太一样。很多任务在早期并不是状态不清楚，而是判断方法还在变化。

更关键的是，很多流程编排其实是在补模型短板。比如模型以前不会稳定拆任务，你就写一个任务拆解节点；模型以前不会稳定选工具，你就写一个工具路由节点；模型以前总结不稳定，你就写一个反思和重试节点。这些设计在当时有价值，但它们的长期价值取决于模型能力是否继续停留在那个水平。

一旦模型升级，很多手写节点会变得尴尬：它们既没有企业业务知识，也没有确定性执行能力，只是在教模型"怎么思考"。如果新模型已经能更好地规划、调用工具、根据上下文调整步骤，那么这些编排节点就可能从"保障质量"变成"限制能力"。

售后退款就是典型例子。最开始你可能只考虑"未发货可退、已发货看物流、已签收看售后期"。很快你会遇到更多情况：客户威胁投诉、商品属于特殊品类、订单金额高、用户历史投诉多、平台活动规则特殊、物流显示异常但用户已收到货。

如果你把每个 case 都写成流程节点，系统会越来越像一棵不断膨胀的决策树。它短期可控，长期僵硬。更麻烦的是，这棵树里很多分支并不是企业稳定规则，而是对当时模型能力不足的补丁。

更合理的做法是先把判断方法沉淀为 Skill。比如：

• 先确认订单号和订单状态。
• 再查物流和支付状态。
• 已签收订单要结合商品类型和售后期。
• 客户威胁投诉时标记风险等级。
• 高金额订单只能创建审批单。
• 回复客户时不能承诺"必退"或"立即到账"。

这些内容先写成 Skill，比先写成复杂 Workflow 更轻。因为它们描述的是处理方法，不是强制状态机。业务规则变化时，你调整 Skill，比调整一整套流程编排更容易。模型能力升级时，Skill 仍然有价值，因为它沉淀的是企业业务方法；而那些只是在教旧模型如何拆解任务的流程节点，可能会被新模型自然覆盖。

等某些步骤变得高频、稳定、风险高，再升级为 Workflow。比如：

• 真实退款执行。
• 财务打款。
• 库存回滚。
• 发票作废。
• 权限开通。
• 合同签署。
• 数据删除。

这些动作必须由确定性后端系统控制。Skill 可以影响建议、解释和草稿，但不能绕过既有业务状态机。

所以，Skill 和 Workflow 不是替代关系，而是演进关系。Skill 先帮助企业把"怎么判断"讲清楚，Workflow 再把"必须怎么执行"固化下来。

第四章：真实项目里，Skill 层如何落地

现在行业里不是所有人都把这层叫 Skill，但很多系统已经在做类似的事情：把业务说明、工具使用方法、上下文管理和执行约束组织成可复用能力单元。

落地方式大概有四类。

第一类是厂商原生 Skill。比如 Claude 原生 Skill，适合文档、PPT、Excel、PDF、代码辅助、个人效率和轻量业务知识封装。这种方式上手快，适合个人和小团队。

第二类是低代码 Agent 平台。比如 Dify 这类平台，业务部门可以快速配置 Agent 指令、工具、知识库和 Workflow 节点，适合做 PoC 或内部工具。

第三类是 Agent SDK 或 Agent Harness。比如 OpenAI Agents SDK、Claude Agent SDK、LangGraph、LlamaIndex Workflows 等。它们能帮助处理模型循环、工具调用、状态、handoff、guardrail、tracing、MCP、sandbox 等问题。

第四类是企业自研 Skill 层。企业自己维护 Skill Registry、Resolver、Activator、Tool Executor、Policy、Audit、Evaluation。它适合对权限、审计、租户隔离、内部 API 调用、敏感字段脱敏、人工确认有明确要求的真实 Web 项目。

选择哪种方式，不应先看技术偏好，而应看组织成熟度。

如果只是验证 1-2 个场景，厂商原生 Skill 或低代码平台更快。如果已经出现多个部门重复建设、Prompt 难复用、工具权限难管理、审计难追溯，就需要企业级 Skill Registry 和统一治理。如果涉及金融、政企、医疗、法务等强审计场景，自研 Skill 层的价值会更早出现。

重点不是"必须自研"，而是企业是否把业务方法当成可治理资产来管理。只要开始关心复用、权限、审计、灰度和评测，Skill 就会从 Prompt 配置变成工程资产。

那么，在一个企业自研 Web 项目里，用户一句话进来后，Skill 到底怎么被触发？

第五章：一个用户 Query 进来后，Skill 是怎么被触发的

企业自建 Skill 层最重要的，不是写 SKILL.md，而是设计运行链路。

这条链路的目的不是增加架构复杂度，而是让 Skill 的选择、使用和副作用都可控、可追溯。企业要知道：谁在什么场景下用了哪个 Skill、看了哪些资料、调用了哪些系统、是否触发了人工确认。

一个更接近生产系统的链路是：

User Query
  ↓
Context Builder
  ↓
Candidate Skill Resolver
  ↓
Permission Filter
  ↓
Model Skill Selection
  ↓
Skill Activation
  ↓
Policy Check
  ↓
Tool Execution / Workflow Handoff
  ↓
Human Confirmation if needed
  ↓
Response
  ↓
Audit / Evaluation / State Update

第一步不是直接把用户问题丢给模型，而是装配上下文。同一句"帮我看看这个能不能退"，在客服工单页面、财务页面、普通用户聊天窗口里，应该触发完全不同的权限和处理方式。所以系统要知道当前用户身份、租户、业务线、入口页面、订单号、工单状态、历史会话和可用工具范围。

第二步是找候选 Skill。Resolver 可以结合关键词、入口上下文、用户角色、业务对象、embedding 检索和分类模型，把候选范围从几百个 Skill 缩到几个。

第三步是权限过滤。企业系统不应该先把不可用 Skill 给模型，再期待模型不要选。租户未启用、用户无权限、业务线不匹配、灰度范围外的 Skill，应该在进入模型上下文前就被过滤掉。

第四步才是让模型选择是否激活 Skill。这里也不应该把所有 Skill 全塞进 Prompt。更稳的做法是 progressive disclosure：先只给模型少量候选 Skill 的 name 和 description，需要时再激活完整 Skill。

第五步是受控加载。模型如果调用 activate_skill("refund-review")，后端要检查用户是否有权限、租户是否启用、会话是否允许读取相关 reference、Skill 能不能访问相关 tools、是否处于灰度版本。通过之后，再返回完整 Skill 内容。

第六步是工具调用前的 Policy Check。模型根据 Skill 决定调用工具时，后端不能直接执行。每次工具调用前都要判断：这个用户能不能调用这个工具？这个 Skill 能不能调用这个工具？这是只读动作、dry-run，还是写操作？是否需要人工确认？返回字段是否需要脱敏？

第七步是执行或移交 Workflow。只读查询、文档生成、格式校验可以由 Tool Executor 执行。涉及真实退款、合同审批、权限变更这类强状态流程，应交给 Workflow 或 BPM 系统。Skill 只负责准备上下文、生成建议、解释依据。

最后是审计和评估。系统至少要记录用户输入、候选 Skill、激活的 Skill 和版本、读取了哪些 reference、调用了哪些 tool、tool 参数和返回摘要、是否触发人工确认、最终输出、用户是否采纳或修改。

这条链路看起来比 Demo 复杂，但它解决的是企业系统必须回答的问题：AI 为什么这么做，谁允许它这么做，出了问题能不能复盘。

理解了运行链路之后，我们再看企业自建 Skill 层需要哪些工程能力。

第六章：企业自建 Skill 层需要哪些工程能力

如果把 Skill 层放进真实 Web 系统，不建议一开始就堆一堆模块名。更清楚的方式是分成四个平面。

第一是 Control Plane，也就是 Skill 资产管理。它解决"有哪些 Skill、谁负责、哪个版本在线、如何发布和回滚"。这里包括 Skill Registry、owner、适用范围、版本管理、发布审批、灰度策略、禁用和下线。没有 owner 的 Skill 最终会变成新的知识债务。

第二是 Runtime Plane，也就是一次请求的运行链路。它解决"用户这句话该用哪个 Skill、加载哪些内容、调用哪些工具"。这里包括 Context Builder、Skill Resolver、Permission Filter、Skill Activator、Tool Executor、Policy Check、Human Approval State。

第三是 Evaluation Plane，也就是判断 Skill 是否真的有效。它解决"Skill 是否减少了人工返工、错误调用和任务失败"。离线可以看历史 query 命中率、错误激活率、工具参数正确率、输出格式合规率、高风险案例拦截率；在线可以看用户采纳率、人工修改率、任务完成率、转人工率、成本延迟和误操作率。

第四是 Integration Plane，也就是接入企业已有系统。它包括 RAG / Retrieval Service、MCP Server / Adapter、内部 API、Workflow / BPM、IAM、Secret 管理、API Gateway。

这里有两个容易被忽略的工程边界。

第一，Skill 不能持有生产密钥。凭据应该由后端执行器或密钥系统管理。

第二，一次会话或一次任务应该记录使用的 Skill version。否则出了问题，无法知道当时模型看到的是哪个版本的业务方法。

这些工程能力不是为了把系统做重，而是为了让 Skill 从"几段提示词"变成真正可运行、可治理、可回滚的企业资产。

第七章：企业 Skill 主要沉淀哪几类资产

与其把 Skill 分成很多抽象类型，不如看它对应企业里已有的资产。

第一类是规程型 Skill。它把 SOP 和判断步骤显式化。比如客服处理投诉、运营审核活动、风控初筛、代码审查。它沉淀的是什么时候使用、先看什么后看什么、哪些条件触发升级、哪些动作不能自动执行、输出给谁、格式是什么。

第二类是知识型 Skill。它把制度、口径、案例组织成可用资料。比如企业制度、产品说明、指标口径、接口规范、历史风险案例。RAG 负责找资料，Skill 负责告诉模型如何使用这些资料。

第三类是工具增强型 Skill。企业系统里有很多 API：CRM、ERP、订单、支付、物流、工单、投放、数据看板。这些 API 本身都有 tool schema，但 Skill 的价值是告诉模型这些工具在业务上怎么组合，什么顺序调用，返回结果如何判断，哪些动作只能 dry-run，哪些必须转人工。

第四类是模板输出型 Skill。很多任务最终产出的是文件或文本，比如销售周报、项目汇报 PPT、投标文档、合同评审报告、客户邮件、复盘报告。模板不只是格式好看，它承载企业内部对内容结构、口径和品牌规范的要求。

多模态生成型 Skill 也可以放在这里。比如先生成结构化大纲，再生成 slide 视觉图，再转 PPT。它适合快速初稿，但在企业里仍然要考虑可编辑性、品牌一致性、事实校验和审核链路。

讲完这些类型，我们可以看一个具体 Skill 应该怎么写。

第八章：一个企业 Skill 应该怎么写

下面是一个售后退款 Skill 的简化结构。

注意这里用 Procedure，不用 Workflow。因为 Workflow 在企业架构里通常指状态机、审批流或编排系统；Skill 里的这部分只是处理步骤。

---
name: refund-review
description: 当用户需要判断订单是否可以退款、生成退款建议、解释退款规则时使用。
owner: after-sales-team
version: 1.0.0
permissions:
  - order:read
  - logistics:read
  - refund:dry_run
---

# Refund Review Skill

## When to use
当用户询问订单是否能退、客户投诉是否需要退款、是否可以补偿时使用。

## When not to use
- 用户只是查询订单状态，不需要退款判断。
- 用户要求直接执行退款。
- 缺少订单号且无法从上下文获取订单。

## Procedure
1. 先确认是否有订单号；没有则询问用户补充。
2. 调用 query_order 查询订单状态、金额、支付渠道、发货状态。
3. 调用 query_logistics 查询物流状态。
4. 读取 refund_policy 判断是否符合退款条件。
5. 如果需要真实退款，只能调用 refund_dry_run 或 create_refund_ticket，不得直接执行退款。
6. 输出判断结论、依据、风险点和建议回复。

## Available tools
- query_order(order_id)
- query_logistics(order_id)
- refund_dry_run(order_id, reason)
- create_refund_ticket(order_id, summary)

## Business rules
- 未发货订单通常可退款。
- 已签收订单需要结合售后期和商品类型判断。
- 高价值订单必须创建审批单。
- 客户威胁投诉时，需要标记风险等级。

## Output format
- 结论
- 判断依据
- 缺失信息
- 风险点
- 建议动作
- 客服回复建议

## Risk controls
- 不允许直接执行真实退款。
- 涉及金额超过阈值时必须转主管确认。
- 缺少订单状态、支付状态或物流状态时，不得给出确定结论。
- 不得向客户承诺"必退""立即到账"等未经审批的话术。

## Validation
- 确认订单号、订单状态、支付状态、物流状态均已查询。
- 如果调用工具失败，需要说明无法判断的原因。
- 输出必须包含判断依据和风险点。

## Fallback
- 关键信息缺失时，向用户索要信息。
- 高风险或规则冲突时，创建人工复核工单。

这份 Skill 的重点不是"告诉模型调用哪个工具"，而是把退款任务的处理方法讲清楚。示例重点也不是格式本身，而是说明业务方法应该被显式写出来，而不是散落在 Prompt、SOP 和工程代码里。

写 Skill 时有几个原则。

第一，description 要清楚。它决定候选检索和模型触发。如果写成"处理售后问题"，范围太泛，容易误触发。

第二，Procedure 控制在 3 到 7 步。Skill 不是流程引擎，太长说明你可能应该拆 Skill，或者把部分步骤升级为 Workflow。

第三，把确定性动作下沉到脚本或工具。不要让模型计算复杂金额、解析复杂表格、拼接危险 SQL。

第四，风险边界必须写清。哪些动作只能 dry-run，哪些必须人工确认，哪些字段需要脱敏，这些不能靠模型猜。

第五，要有输出格式、校验方式和 fallback。没有输出格式，结果无法稳定复用；没有校验方式，质量无法评估；没有 fallback，失败时系统会编答案。

下面我们用三个业务场景，把这些原则放回真实工作里看。

第九章：三个业务案例

1. 售后退款：Skill 负责判断，Workflow 负责真退款

售后退款的业务痛点是：客服每天处理大量退款和投诉，规则看似明确，但真实场景里经常夹杂物流异常、商品类型、客户等级、历史投诉、平台规则和话术风险。

没有 Skill 时，AI 可能只是查订单，然后总结订单状态。它不知道公司内部真正认可的处理方法，也不知道哪些情况必须升级。

Refund Review Skill 沉淀的是先查哪些信息、如何结合订单和物流判断、哪些场景标记高风险、哪些话术不能说、什么情况下只能创建审批单。

后端负责查询订单、支付、物流、投诉记录，控制字段脱敏，限制真实退款执行，创建审批流，记录审计日志。

这个场景里，Skill 不执行真退款。Skill 负责判断、解释和材料准备；Workflow 负责审批、打款、库存回滚和财务记录。

可衡量收益不是"AI 自动退款"，而是客服处理时间下降、回复口径更一致、人工升级更准确、审计材料更完整。

2. 销售周报：Skill 负责把数据变成业务叙事

很多销售运营每周都在重复同一件事：从 CRM、订单、回款系统导数据，做同比环比，找异常，套 PPT 模板，最后还要被管理层追问口径。

没有 Skill 时，模型即使能查数，也不一定知道哪些指标最重要，不一定知道销售额、回款额、订单额不能混用，也不一定知道异常下滑要看哪些维度。

Sales Report Skill 沉淀的是本企业销售阶段定义、客户分层口径、指标解释规则、异常波动分析顺序、周报 PPT 模板和常见管理追问。

后端负责按权限拉取 CRM、订单和回款数据，限制跨区域数据访问，记录引用来源，生成图表和 PPT。

这个 Skill 不替代销售负责人判断，而是把 2 小时的数据整理和初稿撰写压缩到 10 分钟，并减少口径争议。

3. 合同风险初筛：Skill 负责初筛，不替代法务

合同风险初筛适合 Skill，但不适合一开始就做成完整合同审批 Workflow。

早期更值得沉淀的是哪些条款高风险、哪些客户类型要关注付款周期、哪些条款偏离标准模板、输出给法务的摘要格式是什么、哪些风险必须人工复核。

Contract Review Skill 可以读取合同，识别主体、金额、期限、付款、违约、保密、管辖等条款，对照法务模板和条款库，输出风险等级和依据，标注需要法务复核的条款。

RAG 提供法务模板、条款库和历史案例。Tool 负责 OCR、文档解析和结构化提取。Audit 记录模型版本、Skill 版本和引用材料。Human 负责最终法务判断。

这个案例说明了 Skill 的边界：它提升准备材料和发现问题的效率，不承担最终法律责任。

这三个例子的共同点不是都适合自动化，而是都存在一套可复用的判断方法。Skill 化的价值，是把这些判断方法变成模型可以稳定调用、企业可以持续治理的资产。

第十章：Skill 不是越多越好

很多团队会犯一个错误：一开始就设计 100 个 Skill。

这通常没有必要。

Skill 应该从真实任务中长出来，而不是从会议室里设计出来。更可靠的路径是：

先跑真实任务
  ↓
观察模型哪里反复犯错
  ↓
把纠正动作沉淀进 Skill
  ↓
把确定性动作下沉成脚本或工具
  ↓
用真实 query 回归测试

比如你发现模型每次生成销售周报都会混淆"销售额"和"回款额"，那就把指标口径写进 Skill 或 reference。你发现它经常忘记查物流状态，就把这一步写进 Procedure。你发现它计算退款金额不稳定，就写成脚本或后端工具。

Skill 的来源应该是高频任务、真实失败案例、专家纠错、内部 SOP、工具调用经验和用户反馈，不是"让模型帮我生成一批 Skill"。

每个正式 Skill 都应该有 owner、适用范围、回归测试集、发布记录和下线条件。没有 owner 的 Skill 最终会变成新的知识债务。

既然 Skill 不是越多越好，就必须有一套判断它是否值得保留的评估方法。

可以从三个层面评估。

第一，选择是否正确。该用时有没有用，不该用时有没有乱用，不同租户、角色、业务线下是否正确过滤。

第二，执行是否可靠。工具参数是否正确，工具调用顺序是否合理，工具失败时是否 fallback，输出格式是否合规，高风险案例是否被拦截。

第三，业务是否有收益。任务完成率、用户采纳率、人工修改率、转人工率、成本和延迟、事故和误操作率是否改善。

一个 Skill 好不好，不看它写得多完整，而看它是否减少人工解释、减少错误调用、提高一次完成率，并且让失败原因可复盘。

第十一章：什么时候不要做 Skill

Skill 有价值，但不要神化。

以下场景不适合做正式 Skill。

第一，只有一个简单工具调用。比如查天气、查汇率、查订单状态。如果用户只需要一个 API 返回结果，直接 tool calling 就够了。

第二，一次性任务。没有复用价值的任务，不值得沉淀 Skill。

第三，高度不稳定、没有 owner 的临时规则。探索期可以用草稿 Skill 或实验 Skill，但要有过期时间和评测数据。不要把每天都变、没人负责、没有复用价值的临时规则沉淀成正式 Skill。

第四，强状态、强事务、强审计流程。比如真实退款、发货、转账、权限变更、数据删除。这里需要 Workflow 和后端系统。Skill 可以作为这些流程的前置判断、材料准备或解释层，但不能替代它们。

第五，Skill 写完比代码还复杂。如果你发现一个 Skill 里有几十个分支、几十条规则、复杂状态跳转，那它可能不该继续写成 Skill，而应该拆成规则引擎、后端服务或 Workflow。

一个真实反例是：某企业想把"临时市场活动审批"做成 Skill，但活动规则每周变化，审批人也不固定，历史案例参考价值低。团队花了很多时间维护 Skill 文档，结果每次使用前还要重新确认规则。这个场景更适合轻量表单、人工审批和临时说明，不适合沉淀为长期 Skill。

简单说：

Skill 适合沉淀可复用的做事方法，不适合替代所有后端逻辑。

第十二章：从 3 个 Skill 开始，而不是先造平台

如果企业要落地，我不建议第一步就做完整 Skill 平台。

更现实的路线是先选 3 个场景。判断一个场景是否值得 Skill 化，可以先问三个问题：它是否高频发生？是否依赖企业自己的做事方法？是否能通过命中率、人工修改率或处理时长衡量收益？如果三个答案都是否，先不要做正式 Skill。

第一批场景最好满足这些条件：

• 高频发生。
• 业务方法相对稳定。
• 有明确输入输出。
• 有人工复核样本。
• 能接入必要工具或资料。
• 风险可控，最好先从只读或 dry-run 开始。

比如可以先选：

• 售后退款建议。
• 销售周报生成。
• 合同风险初筛。

第一版 MVP 架构也不需要复杂：

Skill Registry：一个配置仓库或数据库表
Resolver：关键词 + embedding + 权限过滤
Activator：按版本加载 Skill 内容
Tool Executor：只接 2-3 个只读工具或 dry-run 工具
Audit Log：记录 query、候选 Skill、激活 Skill、工具调用和输出
Evaluation Set：50-100 条真实 query 回归集

第一阶段要做的不是平台，而是闭环：写最小 Skill，接入真实用户 query，记录命中率、成功率、人工修改率，把失败案例沉淀回 Skill，把确定性动作逐步沉淀为 tool 或脚本，把强约束、高频、稳定的部分升级为 Workflow。

等这 3 个 Skill 跑通之后，再考虑统一能力：Skill Registry、Tool Registry、Policy Layer、Audit Layer、Evaluation Layer、发布、灰度和回滚机制。

这样做的好处是，平台能力来自真实需求，而不是先造一个没人用的平台。

结尾：Skill 是企业 AI 的业务方法层

大模型越来越强之后，企业 AI 项目的重心会变化。

过去我们容易把重点放在"怎么控制模型一步步走"。未来更重要的是"怎么把企业自己的业务能力变成模型可调用的资产"。

这并不是说流程编排不重要。强约束、强状态、高风险的动作仍然需要 Workflow。也不是说工具调用不重要。没有工具，模型只能说，不能做。更不是说 RAG 和 MCP 不重要。没有知识检索和外部连接，模型无法进入真实业务。

但这些东西之间还缺一层：业务方法层。

Skill 的价值就在这里。它把企业经验、操作规程、工具使用方法、模板资产、风险边界和校验规则组织起来，让模型不是裸调用工具，而是按业务方法完成任务。

最后再强调一次边界：

Skill 层不替代后端系统、工作流引擎、权限系统和审计系统。它把业务方法结构化，让模型在受控系统内更好地完成任务。

所以这篇文章的最终判断是：

不是所有 AI 项目都需要复杂 Agent 编排；但只要企业希望 AI 能复用业务经验、受权限约束、可审计、可持续评估，就需要某种形式的 Skill 层。在高频、可复用、需要模型参与判断和生成的场景里，Skill 化通常是把企业经验变成模型可调用能力的一条低成本路径。

参考资料

• Anthropic Agent Skills Overview: https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
• Claude Skills API Guide: https://platform.claude.com/docs/en/build-with-claude/skills-guide
• Anthropic Engineering Blog: https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
• Agent Skills Specification: https://agentskills.io/specification
• Agent Skills Client Implementation: https://agentskills.io/client-implementation/adding-skills-support
• OpenAI Agents SDK Update: https://openai.com/index/the-next-evolution-of-the-agents-sdk/
• OpenAI Agents SDK Tools: https://openai.github.io/openai-agents-python/tools/
• Dify Agent Docs: https://docs.dify.ai/en/use-dify/nodes/agent
• LangChain Middleware Docs: https://docs.langchain.com/oss/python/langchain/middleware/overview
• LlamaIndex Workflows Docs: https://developers.llamaindex.ai/python/framework/