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 的数据里发现的那个被低估却高频复用的技能。这些细碎的功夫才是资产最终的形状。
Agent Skills九阶段地图：把流程变成可复用的企业资产
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 的数据里发现的那个被低估却高频复用的技能。这些细碎的功夫才是资产最终的形状。
