1. 先说结论：Agent Skills 是不是一场资产化幻觉
最近圈子里聊得最热的词就是Agent Skills。不管是搞大模型应用层的、做企业服务中台的、还是以前做 RPA 和低代码的团队，几乎都在往这个概念上靠。原因也很好理解：过去两年我们把大模型接进了业务系统，做了大量对话机器人、知识库问答、流程助手，但做完了发现一个问题——项目是交付了，能力却留在原地。换一个客户、换一条业务线、换一套系统环境，又得从头来一遍。于是大家开始追问：有没有什么办法，把已经跑通的、被验证过的流程，沉淀成一种可以反复使用、跨场景复用的“资产”？
Agent Skills 就是冲着这个问题来的。它本质上想把“让大模型能干某件事”的最小能力单元给标准化、封装化，让一个技能可以被不同的 Agent 反复调用，像搭乐高一样组装进新的流程里。这个想法听起来很顺：流程不再是散落在文档里、人脑里、某条聊天记录里的经验碎片，而是一等公民——可以被检索、被评估、被版本化、被复用的企业资产。
我自己的结论是：这个方向成立，但它不是天然成立的。它需要一条非常清晰的路径，把流程从“隐性经验”变成“显性资产”，中间还埋伏着不少暗礁。这篇文章我想把这条路径展开成一张九阶段地图，再把落地过程中最容易翻车的三道暗礁摊开讲清楚。适合谁看？正在做 Agent 相关平台建设的技术负责人、企业架构师、AI 应用开发者，以及所有在思考“怎么把大模型能力沉淀下来”的人。
2. 先把“流程变资产”这件事拆到骨子里
2.1 “技能”和“工作流、插件、工具”到底有什么区别
很多人对 Agent Skills 的第一反应是：这不就是插件吗？不就是工作流吗？我可以负责任地说，形式上它们会有重叠，但出发点完全不同。
插件（Plugin/Tool）解决的是“Agent 能接什么外部能力”，核心是对 API 的包装。比如一个查天气的插件、一个访问数据库的工具，它们的功能是确定性的，输入输出边界清晰，但本身不包含“怎么用”的策略。
工作流（Workflow）解决的是“任务怎么按顺序执行”，核心是编排。比如先取数、再清洗、再建模、再推送，它把步骤逻辑固化了，但往往和具体场景强耦合，换个业务领域很难直接搬。
技能（Skill）站在两者中间，它更靠近“某一类任务的可复用执行方式”。它不应该绑定具体的数据源，而应该绑定“这类任务该怎么做才对”。举一个最简单的例子：一个“客户投诉分级处理”的技能，它不需要关心投诉是从哪个渠道进来的、也不关心客户是谁，它关心的是你怎么判断投诉的紧急度、怎么分配处理优先级、哪些情况必须升级——这是一套专业人士大脑里的方法论，而不是某张表或某个接口。
这个区分决定了后面的资产化路径完全不同。工具资产化，沉淀的是接口清单。流程资产化，沉淀的是决策逻辑和执行策略。Agent Skills 真正要承接的，是后者。
2.2 为什么说传统流程文档化不是资产化
过去很多企业做 SOP（标准作业程序）沉淀，把流程写成几十页的 Word 文档，甚至做成精美的流程图。但这些文档有一个通病：它们描述的是“应该怎么做”，而不是“如何被自动执行”。大模型也好，Agent 也罢，拿到一份 SOP 文档并不等于会干活——它需要的是可解析、可触发、可验证的最小执行单元。
我打个比方：一本菜谱是文档，一个会做这道菜的厨师是技能。菜谱能传递给人类厨师，因为人类有常识、有手、有锅、有火候概念。但 Agent 没有这些，它只有上下文窗口和工具调用能力。你必须把“菜谱”翻译成一连串带条件的动作、判断、兜底策略，并且确认它在真实环境里能跑通。这一步翻译，才是资产化真正开始的地方。
另外，传统文档还有一个要命的毛病：不会自证有效。你说这个流程能提升效率 30%，文档里看不出真假。但一个 Skill 必须能挂上评估集——拿历史案例去跑，用结果说话。一份不能验证的流程记录，只能叫存档，不能叫资产。
2.3 九阶段地图的全景预览
我花了很长时间拆解那些成功把流程资产化的团队到底做对了什么，也复盘了自己经手过的几个从零起步的项目。我把整个路径拆成九个阶段，分三段：
- 抽取段（阶段 1-3）：把流程从专家脑子里、旧系统里、工单记录里挖出来，形成初步的任务分解和知识采集。
- 建模段（阶段 4-6）：把挖出来的流程结构化，加入决策逻辑、评估机制、版本管理，让它可以被执行。
- 复用段（阶段 7-9）：把跑通的技能投入到真实业务中，打造发现渠道，建立复用度量，最终形成跨场景的流程资产网络。
九个阶段对应的核心产出分别是：任务拆解书、知识采集包、流程结构化模型、技能描述文件、执行引擎适配、评估集与基准分、技能仓库、复用记录与度量体系、跨场景迁移方案。
这个顺序不能乱。很多团队死在半路，不是因为某个技术环节没搞定，而是因为跳过了抽取段直接做建模，或者跳过了评估直接上复用，最后资产还没成形就开始要求 ROI，翻车是必然的。
3. 九阶段地图：每一步到底在做什么
3.1 抽取段：资产化的地基层
阶段 1——任务拆解：把“一个流程”拆成“一系列决策点”。
这是最容易被低估的一步。我去过很多业务团队，他们描述流程时的颗粒度是“我们这边有一套售后处理流程”，等你追问细节，就会发现每个人嘴里的“这套流程”根本不是一个版本。所以要做的第一件事，是拉着核心业务专家做结构化访谈，用“如果—那么—否则”的句式把流程显性化。
举个例子。一个售后处理流程，拆出来可能是这样的：
- 判断投诉类型属于质量问题、物流问题还是服务态度问题
- 如果属于质量问题，进一步判断严重等级：影响安全 / 影响核心功能 / 影响体验
- 如果影响安全，立刻触发召回和上报；影响核心功能则进入加急维修通道；体验问题分配给常规组
- 如果无法判断类型，进入人工复核，不自动分发
这一步得到的不是流程图，而是决策表。它是后续所有工作的原材料。
阶段 2——知识采集：把隐性经验从专家脑子里挖出来。
任务拆解只是骨架，知识采集是往里填肉。这个阶段要收集三类东西：一是判断规则，比如“什么情况算严重”“什么情况可以赔偿”，往往藏在老师的工单备注里；二是反例和边界案例，比如“看着像质量问题的其实是个误会”，这些才是模型最容易翻车的地方；三是外部约束，包括合规要求、SLA 承诺、成本边界。
实操中我建议用“问题清单轰炸法”：准备好十几二十个尖锐问题，比如“如果客户同时投诉两个问题怎么办”“如果在非工作时间收到投诉怎么处理”“如果客户要求超出政策范围怎么应对”，把专家问到词穷为止。词穷的地方就是知识真空，也是将来 Agent 最可能出错的雷区。
阶段 3——结构化建模：把零散知识变成可处理的数据。
到了这个阶段，你会得到大量文字记录、访谈纪要、工单分类。需要把它们整理成结构化格式。我惯用的方法是把每个决策点写成一条带条件的规则，附上置信度和来源。比如：
- 规则“投诉类型 = 物流问题 AND 派送超时 > 48h ⇒ 优先级 P1”，置信度 0.9，来源：售后组长访谈
- 规则“投诉类型 = 物流问题 AND 派送超时 ≤ 48h ⇒ 优先级 P2”，置信度 0.8，来源：工单 2024-Q3 统计
结构化建模的目的不是为了给写代码的人看，而是为了让后续阶段可以自动化地生成、验证、迭代。
3.2 建模段：资产化的核心引擎
阶段 4——编写技能描述文件。
这是 Agent Skills 与传统工作流拉开差距的地方。一个 Skill 不能只是一段提示词模板，它应该有完整的描述文件，包括：技能名称与标签、触发条件、输入参数与输出格式、步骤说明、前置条件和约束条件、已知边界案例。
拿“客户投诉分级处理”举例，技能描述文件里的“步骤说明”会写成这样：
- 接收投诉内容，提取客户诉求、问题对象、发生时间等关键字段
- 根据投诉类型规则集进行初判
- 如果初判置信度低于 0.7，进入追问澄清流程
- 根据严重程度规则集进行分级
- 输出分级结果和建议处理通道
描述文件是给 Agent 的 meta 信息，也是给人看的说明书，更是后续检索和匹配的依据。我的经验是，描述文件写得好不好，直接决定这个技能在仓库里“被想起来”的概率。很多技能做完了吃灰，就是因为描述文件写得太宽泛，别人根本不知道它能干什么。
阶段 5——执行策略与工具适配。
流程的骨架有了，决策规则也有了，接下来的问题是：Agent 怎么真的把它跑起来？这里要看这个流程依赖哪些外部动作。如果只是文本分析和判断，一个能调用大模型推理的 Agent 就够了；如果涉及操作业务系统，就得接 API 或通过浏览器工具自动化完成。
在这个阶段，要把流程中的每个步骤映射到具体的执行方式上：某一步用模型推理，某一步调用 SQL 查询，某一步触发工单系统接口，某一步需要人工确认。这一层映射关系，其实就是传统 RPA 领域多年的积累。Agent Skills 和 RPA 不冲突，反而互补——RPA 提供确定性的操作执行力，Skill 提供不确定性的决策判断力。
阶段 6——评估集与基准分：给技能装上“及格线”。
这是我最想强调的阶段，也是大部分人最容易偷懒的阶段。技能做出来之后，你不能凭感觉说“好像还可以”，你得有一套固定的评估集，让每个版本的技能都能在同一批问题上跑出可比分数。
评估集怎么造？我一般建议从历史工单里抽 20-50 个典型或刁钻案例，人工标注出标准答案，然后把它们变成自动化测试用例。每次迭代先跑评估集，分数下降就说明迭代引入了回归，坚决不能上线。
基准分也很重要。第一个版本上线时记录下当时的分值，比如正确率 80%，处理时延 15 秒，需要人工介入的概率 30%。后面每次优化都要与这个基线对比。没有基线的优化，最后都会变成自说自话。
3.3 复用段：资产化的价值兑现
阶段 7——把技能发布进技能仓库：让资产可以被找到。
单个 Skill 跑通其实不难，难的是让团队里其他人、甚至其他团队愿意用。这时候你需要一个技能仓库，它不只是存储，还要解决发现和信任问题。每个技能要有清晰的用途说明、试用入口、数据表现、维护负责人。我在实际项目中看到，很多技能仓库上线后没人访问，问原因，反馈是“不知道里面东西靠不靠谱”。
解决信任问题的方法只有一个：让每个技能像开源项目一样，有明确的版本号、更新时间、测试覆盖率和已知问题列表。都是大模型平台的老熟人了，公开、透明、量化数据才是信任的来源。
阶段 8——建立复用记录与度量体系：让资产能被算账。
一个技能发布之后，不能放任不管。需要度量四个指标：被调用次数、被哪些 Agent 或场景调用、调用后的成功率、相比不用此技能的效率提升。这些数据意义重大——只有数据，才能回答老板“这个技能创造了什么价值”的追问，也只有数据，才能知道哪些技能值得加大投入、哪些技能该下架。
我这里说的调用次数不是埋点统计那种大数，而是带上下文的记录。你得知道这个技能是处理了什么类型的输入、输出了什么结果、最后有没有被人改掉。这些记录攒多了，还能反过来优化技能本身的提示词和规则。
阶段 9——跨场景迁移与资产放大。
最后一个阶段，是从“一个流程跑通”走向“一类流程都能跑通”。一个售后投诉分级技能跑顺了，你会发现物流异常处理、客诉升级判定、甚至对公业务的分级流转，都有类似的决策结构。这时候可以做两件事：一是从原技能里抽象出公共模块，比如“工单分类器”“严重度评估器”；二是把技能推广到相邻场景做迁移适配，迁移后照例跑评估集，不达标就不算迁移成功。
这就是“资产”的终极形态：不是一堆一次性交付物，而是一套带自检机制、能跨场景复用的能力网络。做到第九阶段，你才算真的把流程变成了资产。
4. 三道暗礁：资产化路上最容易翻车的地方
九阶段地图是理想路径，但是实际走起来，你八成会遇到三道暗礁。我在自己的项目和同行的项目中都见过它们，每一道都足以让资产化努力付之东流。
4.1 暗礁一：流程还没标准化，就开始抽象化
这是目前行业里最普遍的现象。很多团队在流程本身还很混乱的时候，就急着让 Agent 去“学会”它。结果是：Agent 固化了一套本身就残缺的流程，甚至在残缺的基础上增加了一层幻觉，最后产出的不是资产，而是灾难。
判断标准其实很朴素：如果你的流程可以用一张二维表讲清楚，有明确的判定条件、责任人、处理时限，那再去谈资产化。如果连业务方自己都说不清每个分支怎么走，那建议先回到流程治理本身。流程梳理清楚，是资产化的前提；跳过这一步，九阶段的第一阶段就没走完，后面全白搭。
我在一个项目里见过特别典型的失败案例：某团队希望把“客户续费提醒”做成 Skill 自动化执行，但他们的续费策略本身有五种口径，不同客户经理各自有一套判断标准。结果 Skill 不过是把其中一套口径固化了，其他四类客户的续费判断全错了。最后资产业务双双返工。
4.2 暗礁二：技能边界失控，Agent 幻觉被“合法化”
Agent Skills 的一个隐藏风险在于：它把一个流程的执行权交给了 Agent，而 Agent 天生有“自由发挥”的倾向。当你把一个 Skill 封装好、挂到 Agent 上之后，你天然会降低对每一步执行的审查力度——毕竟我们都相信“这是跑通过的东西”。可问题是：流程是标准化的，输入不一定标准化。一旦输入落在技能的盲区，Agent 就极有可能作出“看似合理、实则错误”的延伸判断。
每一个技能在设计时都要明确它的适用范围和禁区，描述文件里不只是写“能做什么”，还要写清楚“不能做什么”和“不确定怎么办”。不确定性一定要有一个兜底动作，比如转人工、输出“无法判断”、上报队列。没有护栏的技能，上线越久隐患越大。
我还建议每一个技能里都要有“必答校验”机制——在某些关键输出节点上，强制 Agent 重新核对原始输入与输出的一致性。这个机制在大量阈值判断型流程里特别管用，能很大程度上压住幻觉。
4.3 暗礁三：资产化变成了存档化，没人用、不维护
第三种翻车最隐蔽，因为它不是技术问题，而是组织问题。团队热火朝天做了几十个技能，然后呢？然后没有然后了。技能们安静地躺在仓库里，版本永远停在 V1.0，没人评估、没人优化、更没人复用。资产化最后变成了“数字化存档”，自嗨一场。
要破这个局，必须在项目启动的第一天就预设复用目标。我见过比较有效的做法是“先找场景再建技能”：在开始做之前，先明确这个技能将被至少两个以上场景复用；如果一个技能只为一个特定场景服务，它还不配叫资产。具体激励上，可以把技能复用次数纳入研发团队的关键指标，把“别人调用过你的技能多少次”变成一种数字荣誉，效果往往比行政命令好。
再补一点：技能的维护成本要前置考虑。一个技能上线运行半年后，如果不更新规则，面对新的业务变化必然慢慢失真。每个技能必须有一个明确的负责人和生命周期管理方案，到期不维护的技能直接下线归档。资产的价值在于流动和更新，没有维护计划的技能，本质上还是债务。
5. 常见问题速查与避坑经验
5.1 高频问题对照表
| 问题 | 典型表现 | 根源 | 解决建议 |
|---|---|---|---|
| 流程不靠谱 | 技能上线后在真实场景经常走不通 | 阶段 1-3 的抽取和建模偷工减料 | 先做流程梳理，画决策表，没有规则先不建技能 |
| Agent 自由发挥 | 输出超出技能边界且无人察觉 | 技能缺少适用范围和禁区说明 | 在描述文件里明确不能做的事，加入兜底转向人工机制 |
| 技能没人用 | 仓库里有技能但调用量长期为零 | 缺少信任机制和复用激励 | 给技能做数据透明展示，公开基准分和负责人；将复用纳入考核 |
| 迭代倒退 | 版本升级后反而变差 | 没有固定评估集，凭感觉改进 | 第一个版本就建评估集，每次迭代必测，回归即回滚 |
| 资产不可比 | 不同团队造的同类技能效果差异大 | 缺少统一的标准模板和评价口径 | 发布阶段先统一描述文件模板和测试集标准 |
| 维护者失联 | 技能出问题找不到人改 | 没有明确的负责人机制 | 每个技能必须有 owner，有生命周期管理规则 |
5.2 我从实际项目中踩坑踩出来的心得
先说一个反复出现的教训：技能描述文件要用业务语言和开发语言各写一遍。只写业务语言，开发调起来一头雾水；只写技术参数，业务方根本看不懂也没兴趣维护。两份内容对不上，不如不写。
另外，评估集不要一次性建完。我建议先建一个 10 个案例的 mini 集，在技能开发到 80% 左右就让它跑起来，随后边开发边补充评估案例。等到了阶段 6 再做 30-50 条的完整评估集。一次性憋大招的结果，往往是现在做一个看起来全面但颗粒度极粗的测试集，又苦又累又不能真正暴露问题。
还有一点关于提示词。很多人觉得 Skill 的核心就是提示词，只要提示词写得好就万事大吉。我的经验是：提示词的重要性只占三成，剩下七成都取决于数据、规则、评估和流程结构。不要在提示词里堆砌“你要成为一位专业的……”之类的废话，把这些精力省下来去打磨规则集和边界案例，收益要大得多。
6. 回到最初的那个问题
Agent Skills 能不能把流程变成资产？我的答案是：它能，但前提是你要明白“资产”不是一个技术名词，而是一个管理名词。流程变成代码只是手段，流程变成“可持续变现的能力”才是目的。九阶段地图不是什么高深的算法，它只是一个提醒：资产化这条路很长，每个阶段都有它必须交付的产物，没有捷径可走。
我自己这几年最大的体会是：技术圈从来不缺新概念，缺的是把这些概念放回真实土壤里检验的耐心。Agent Skills 给了我们一个很好的框架，但框架只是起点，真正值钱的是你在阶段 1 的一场访谈里挖出的那条边界规则，在阶段 6 反复打磨的那个评估集，在阶段 8 的数据里发现的那个被低估却高频复用的技能。这些细碎的功夫，才是资产最终的形状。
