我最近接手了一个挺有意思的任务让智能体自动处理一部分售后工单。刚开始的想法特别天真以为把企业知识库丢给大模型再写一段详细的提示词它就能像老员工一样回复客户。结果一跑起来就发现完全不是那么回事——模型确实能说话但不知道什么时候该查订单、什么时候该看物流、什么时候该升级人工全凭“感觉”输出质量忽上忽下。后来我把这套能力彻底重构了一轮核心就做了一件事把智能体的能力拆成一个一个的“技能”也就是 agent-skills。做完之后效果提升非常明显工单处理准确率从之前的不到60%干到了85%以上而且每个步骤都能回溯、能测试、能单独迭代。这篇文章我不打算讲什么高大上的理论框架就老老实实分享我在实操中怎么设计、怎么落地、踩了哪些坑希望能给正在折腾智能体的朋友一些参考。1. agent-skills先搞清楚它在解决什么问题1.1 一个活儿怎么拆给智能体干我先用个大家都熟悉的例子说明一下。想象你去一家餐厅吃饭你跟服务员说“给我来一桌生日宴”服务员如果没有经过训练他能做的只是把这句话原样传给后厨后厨肯定懵。但如果服务员受过系统训练听到“生日宴”之后会自动拆成几个动作确认人数和忌口、安排包间、通知后厨准备特定菜单、订蛋糕、布置现场。每个动作都有明确的流程和标准串起来就是一整套服务能力。智能体干活的逻辑也是一样的。你说“帮我处理一下这个退款工单”它不能只用嘴回答“好的我来处理”。它必须能自己判断先查订单状态再看退款原因查一下是否超出售后时效必要时调取聊天记录最后生成处理意见。这一连串的“动作”每一个都应该是一个明确、可执行、有输入有输出的技能。把这些技能拆得越清楚智能体就越稳定越好调。我在最初的项目里犯的错就是把所有能力全塞进一个大提示词里让模型自己“悟”。结果就是能用的场景看着很惊艳不能用的场景莫名其妙。AI 的随机性在这个模式下被放到了最大生产环境根本不敢用。把能力拆成 agent-skills 之后至少每一条链路是我能控制的模型只需要在技能之间做选择和填参复杂度一下就降下来了。1.2 技能、工具、工作流到底是什么关系很多人第一次接触 agent-skills 的时候会把“技能”和“工具”搞混。我先给个简单的区分工具Tool是智能体可以调用的外部功能比如“查订单API”“发邮件API”“数据库查询接口”。工具本身是无状态的你给它什么参数它返回什么结果它不关心整体任务。技能Skill是把工具、提示词、判断逻辑、甚至多个工具调用包装成一个完整的“完成某个任务的能力”。技能内部可以有自己的流程比如先查订单再判断能不能退款这中间有逻辑判断不是简单一次API调用。工作流Workflow是更高层的编排把多个技能串起来完成一个端到端的业务目标。比如“处理整张退款工单”就是一个工作流它内部会调用“核对订单”“查询售后政策”“生成处理意见”“回传工单系统”四个技能。用开发的话说工具是“函数”技能是“服务”工作流是“业务流程”。我之所以强调这个区别是因为团队里沟通时如果概念不统一设计出来的东西会非常混乱。有的人说“我们做了个工具”其实他做的是一个复杂技能有人说“做个工作流”其实只是把两个API串在一起。概念统一之后我们再聊架构就顺畅得多。agent-skills 的价值就在这里它给智能体提供了一个“能力封装层”。模型不需要关心技能的底层实现是调用API、读数据库还是跑一段Python它只需要知道这个技能叫什么、什么时候该用、需要填什么参数。这样模型的选择负担小了出错的概率自然也就低了。2. 设计一套能用住的技能体系关键在“边界”2.1 技能描述先让模型看得懂再让模型用得好技能体系的第一个关键设计决策就是技能的“描述信息”怎么写。你可能觉得这不就是写一段说明文字吗实际水很深。我一开始踩过一个坑给技能写的描述又长又详细把内部实现、注意事项、边界情况全部写进去了结果模型反而变傻了。因为描述太长模型在处理复杂任务时记不住关键触发条件经常在错误的场景下调用错误的技能。后来我改成了“三层描述法”效果好了很多第一层一句话说明“这个技能是干什么的”控制在50字以内。比如“查询订单当前状态及物流轨迹”。这一层是给模型做快速筛选用的它看完就能决定要不要用。第二层写清楚“什么场景下该用这个技能”包括典型的触发条件和不适用的情况。比如“客户咨询发货时间、物流位置时使用如果客户要修改地址请使用修改地址技能”。这一层是为了防止模型误用。第三层写清楚“有哪些关键参数、各自的格式要求和默认值”。比如订单号必须是字符串、时间范围要传Unix时间戳。这一层是为了让模型能正确填参。另外我强烈建议在描述里加入“负面提示”明确说明什么情况不要调用。比如一个“查询天气”的技能你得写清楚“仅返回当天和未来三天天气不负责穿衣建议穿衣建议请调用其他技能”。别小看这几句话它能拦掉大量AI幻觉导致的错误调用。提示技能描述不是给人类看的文档是给模型看的“路由表”。每多写一句废话都在增加模型选错技能的概率。写完描述之后可以用“这个需求该调用哪个技能”的测试集跑一遍看命中率。2.2 输入输出约定把“自由发挥”变成“格式约束”技能设计的第二个重点是输入输出的格式约定。如果这一步不做严格约束后面所有的稳定性都是空谈。输入方面我的经验是参数能少就少能用基础类型就用基础类型能不嵌套就不嵌套。模型填参的能力没有你想象的那么强尤其是多层嵌套的JSON对象它经常会漏字段、填错类型。如果业务确实需要复杂结构我会在技能内部做一次“参数预处理”允许模型传一个简化的输入然后由代码补齐缺省字段。这只会在增加一层但能把填参成功率从70%拉到95%以上。输出方面一定要定义好输出结构而且要用代码来“接住”不要让模型自由输出一段文本然后让下游解析。我在项目里的做法是所有技能的输出统一为JSON结构包含三个固定字段——success表示执行是否成功、data存业务数据、error存错误信息。执行失败时error里还会带上“可读的错误原因”和“建议的替代方案”这样智能体在调用失败之后才能自己决定下一步怎么办。还有一点特别容易忽略技能内部的“超时”和“重试”策略。模型调用工具API的时候如果API响应慢它会一直等着表现就是整个工作流卡死。我给每个技能都设了硬超时时间比如5秒超时后返回一个预设的兜底结果而不是空响应。这个设计在生产环境里救了我很多次。2.3 技能编排让简单技能组合出复杂工作流单一技能能解决的问题始终有限真正能打的是“技能编排”。我理解的技能编排本质上是一种“路由决策”第一步模型先理解用户的原始需求拆解成子任务序列。第二步为每个子任务匹配合适的技能。第三步按顺序执行技能并把上一个技能的输出作为下一个技能的输入上下文。听起来简单但这里有一个关键的技术细节你在设计技能时就要考虑好“输出能不能给下一个技能用”。我见过很多团队每个技能单独都好用但一连起来就废了——因为技能A输出的是自然语言段落技能B却需要结构化的参数。解决办法就是上面说的所有技能输出统一用JSON而且为常用的“接力”组合做好字段映射。另外一个实操经验技能编排不要追求“一步到位”要允许中间步骤存在“人工确认点”。尤其是涉及资金、承诺、对外发送消息等高风险动作时我在编排里加了一个“前置审批技能”由它把待执行的内容推送给人工审核审核通过才继续执行。这个设计虽然不能算“全自动”但它在稳定性和安全性上的收益远大于损失的那点效率。3. 从零搭起 agent-skills 的实操记录3.1 先给技能分层底座技能、领域技能、流程技能动手搭建技能体系的时候我先做的一件事是给技能分层。不是我上来就规划得那么清楚是被现实教育过之后才总结出来的。一开始我把所有技能全塞平级结果技能一多模型选错的概率直线上升。后来我按“能力层级”重新分了层整个体系清晰了很多。第一层叫“底座技能”这是跟业务无关的通用能力。比如“调用HTTP接口”“读写文件”“执行一段Python代码”“做时间计算”“编解码JSON”。这一层更像“工具”但是我把它们也封装成了技能好处是模型可以通过自然语言描述直接调用而不需要知道具体API细节。第二层叫“领域技能”这是跟具体业务相关的技能比如“查询订单”“计算退款金额”“生成工单回复”。这一层是核心资产每个技能都对应一个明确的业务动作且输入输出完全标准化独立可测。第三层叫“流程技能”这是面向完整任务的高级技能内部会编排多个领域技能。比如“处理退款工单”这个流程技能内部可能涉及查询订单、核对政策、计算金额、生成回复四个子技能。流程技能对模型来说是一个“黑盒”它只需要触发一次内部逻辑由代码或工作流引擎来控制。分层设计的好处是新增一个业务需求时如果底座技能、领域技能都有现成的只需要调整流程技能的编排改动面最小。如果只有底座技能那需要新增领域技能但不用动流程层。分层之后技能库的可维护性提升了一个数量级。3.2 注册和测试技能我用的一套管法技能设计完之后就要考虑怎么注册和测试。这块我整理了一个自己的“技能上架流程”基本每加一个新技能都走这个流程第一步写“技能描述”草稿。按我说的三层描述法来写先不管措辞把内容列全。第二步建测试集。我会整理10到20条典型的用户请求这些请求覆盖正常场景、边界场景、易混淆场景。比如测试“查订单”技能时我会有“刚刚下单了怎么还没发货”正常场景、“我改了地址为什么还送到老地址去”边界场景、“我想看昨天的聊天记录”易混淆场景。测试集是技能质量最核心的保障。第三步跑描述效果测试。把用户请求发给模型看它能不能准确选中这个技能。如果选不中就去调描述措辞而不是调模型。这个环节我会反复过好几轮直到命中率100%为止。别嫌麻烦这一步省下的全是后面调试的时间。第四步跑参数提取测试。让模型从一个完整请求里提取技能需要的参数。我会特意构造一些“绕弯子”的请求比如“帮我看看那个XX牌的粉色杯子发货了没”——里面既有商品名又有颜色还有用户意图模型要能提取出正确参数。提取准确率低于90%的技能我不允许上生产。第五步跑端到端测试。把技能放进一个完整的业务场景里从用户请求到最后输出结果走一遍记录耗时、成功率、兜底触发次数。这个环节往往会暴露一些“单测过了但联调挂了”的问题比如上游传参格式不一致、下游返回结构变化等。3.3 组合技能时最容易翻车的三个地方技能组合是效率提升最快的阶段也是最容易出“玄学问题”的阶段。我翻车翻得比较多的地方有三个第一个是“上下文污染”。多个技能串行执行时每个技能的返回结果都会堆进对话上下文里。如果前面的技能返回了一段特别冗长的原始数据后面模型做决策时就会被无关信息干扰导致误判。解决办法是引入“上下文压缩节点”每次技能返回后只保留“结构化摘要”把原始数据存到外部存储不进对话上下文。第二个是“错误传播”。技能A执行失败了返回一段错误信息然后技能B在不知情的情况下继续执行基于错误的数据往下推理结果越算越离谱。这类问题的根因是没有做“执行状态检查”。后来我在工作流引擎里强制加了状态门控只要前一个技能返回的successfalse流程就必须进入“异常处理分支”跟后端开发里“error early”的思想一模一样。第三个是“循环调用”。有一次我在测试一个复杂流程时发现智能体在一个由两个技能构成的小环路上反复调用既不退出也不报错白烧了大量token。排查下来发现是技能描述里“不适用场景”写得太弱模型判断“这个技能好像能用、那个也能用”就来回试探。后来我把循环检测做进了工作流引擎同一技能连续调用超过3次就强制中断让模型重新规划路径。经验总结技能组合的核心不是“把多个API串起来”而是“让每一步都有明确的状态、明确的出口、明确的异常处理”。做不到这三点技能越多系统越不稳定而不是越强大。4. 真实场景复盘售后工单技能是怎么长出来的4.1 需求拆解从“让AI回复客户”到“五段式处理”回到我开头说的售后工单项目。最开始的需求描述是“让AI能自动回复客户的售后问题”这种需求表述非常模糊直接开做必死。我先做的第一件事是把需求拆成具体的处理流程。我把一张售后工单从进来到关闭拆成了五个阶段工单归类、信息核验、方案匹配、回复生成、结果回填。每个阶段对应一个或多个技能工单归类阶段需要“工单意图识别”技能判断客户是退换货、退款、物流咨询还是投诉。信息核验阶段需要“查订单状态”和“查售后政策”两个技能并且要做一个交叉比对判断这个工单是否符合售后条件。方案匹配阶段需要“退款试算”技能根据订单金额、商品状态、超出时限等条件计算退款金额。回复生成阶段需要“话术组装”技能把方案转成自然语言的回复文案同时控制在预设的几种语气风格之内。结果回填阶段需要“工单回写”技能把处理结果写回工单系统并记录处理日志。这五段式拆解看起来不复杂但它是整个项目最关键的决策。因为拆完之后每个环节都能独立开发、独立测试、独立优化。哪一段准确率低就单独调哪一段而不是整个系统推倒重来。从那以后我形成了一个习惯凡是做 agent 项目第一步永远是拆流程而不是先选模型、写提示词。4.2 技能落地的具体参数与中间结果拆解确认以后落地阶段有几个参数和中间结果是值得参考的。以“退款试算”技能为例输入参数只有三个订单号字符串、售后类型枚举仅退款/退货退款/换货、申请原因描述字符串。内部逻辑是先查订单金额再判断商品状态是否影响二次销售再对照退款政策表最后输出一个结构化的退款信息。输出参数包括应退金额数值、运费承担方枚举商家/平台/客户、退款时限字符串、备注字符串。这里有个细节应退金额的计算结果我会保留到两位小数而且会在技能内部做一次“金额合理性校验”——如果算出来的金额大于订单实付金额直接判为计算异常返回错误而不是硬着头皮往下走。另一个值得说的是“工单意图识别”技能的冷启动。我们一开始没有足够的标注数据来训练一个专用分类模型所以我先用了一种极端务实的方法让大模型加规则做“双重判断”。先用关键词规则快速筛分化石级场景比如包含“退款”两字优先归属退款类再用大模型处理规则覆盖不了的模糊请求。两路结果一致直接走如果不一致以规则判断为准并记录一条待人工复核的日志。跑了一段时间后我把积累下来的高质量标注样本整理出来才去微调了一个轻量级的分类模型把规则引擎给替换掉。整个过程很朴素但特别稳。我一直觉得做 agent 不是每一步都要上最先进的方案能用规则解决的先用规则能让代码控制的就少让模型发挥模型只处理真正需要理解力的部分。4.3 效果数据与局限性反思上线跑了一个多月之后我整理了一下这版本的数据。最核心的指标是“无需人工介入自动完结率”从最初版本的不到20%涨到了接近65%。也就是说大概有三分之二的售后工单整套技能流程可以在没有任何人工参与的情况下处理完并回填系统。作为对比人工客服处理一张工单的平均耗时是7分钟而技能流程的平均耗时是40秒效率提升大约10倍。但我也必须说清楚局限性。65%的自动完结率背后有将近20%的工单走了“异常处理分支”不是处理失败而是被设计逻辑主动转给了人工。比如涉及高金额退款、用户情绪激烈的投诉、或者首次出现的新问题这些场景我宁可转人工也不敢让AI直接处理。这个取舍很重要agent 追求的不是100%自动化而是“在安全边界内的最大化自动化”。还有一类局限性是长尾问题。哪怕技能划分得很细也一定会碰到“这个工单看不出属于哪个已知类型”的情况。最初我把这类全部转人工后来我多加了一个“处理建议”选项——让技能先给出一个基于经验的建议方案人工只需确认就能快速处理掉。这个改动又把处理时长压缩了不少。5. 几个压箱底的调试技巧和避坑心得5.1 日志与追踪技能出问题时先看什么agent 项目调试起来比传统后端难很多因为中间隔着大模型这层“不确定性黑盒”。我的经验是必须从第一天就做好全链路日志否则出问题的时候你连从哪查起都不知道。我在每个技能执行的时候都会记录三类信息入参模型传了什么进来、出参技能返回了什么、决策上下文模型为什么选了这个技能也就是让它看过的描述摘要。这三类信息拼在一起才能还原一个完整的执行过程。遇到问题时第一件事永远是查日志看是“选错了技能”“填错了参数”还是“技能内部报错”三个方向的处理方法完全不同。可视化追踪我也试过用开源的链路追踪工具把技能调用关系画成时序图。有一定帮助但不要指望它直接告诉你错误原因。真正有用的还是日志里的入参出参对比。我后来还养成了一个习惯每周抽几个失败案例把模型当时的决策上下文拉出来手动复盘它到底是被哪句话误导的。这类复盘比任何调试工具都有效。5.2 描述“过拟合”和“欠拟合”问题技能描述写多了以后我发现一个特别有意思的现象描述也会“过拟合”。有一段时间我在一个技能描述里把某个边界情况写得特别详细结果模型对那个边界情况的触发极其敏感稍微沾点边就调用这个技能反而把正常意图给忽略了。这就是典型的描述过拟合——你把某类场景写得越细模型就越倾向于在有歧义的时候选择它。反过来描述写得太简单又会欠拟合。比如有个技能描述只写了“查询用户信息”结果模型在用户问“我上次的收货地址是什么”时没想到调用它跑去别的技能里找答案。后来我把描述改成了“查询用户的基础信息包括姓名、电话、收货地址、会员等级”命中率一下就上来了。调整技能描述本质上是在做“路由边界校准”。我给自己的流程是每次调整完描述把测试集完整跑一遍对比调整前后的命中率变化。而且要警惕“按了葫芦起了瓢”——解决了一个误用问题可能引发另一个场景的误用。这个测试集必须长期维护积累得越多调整起来越安心。5.3 版本管理与复用技能库不是一次性工程随着技能数量增多我越来越意识到一个好的技能库是慢慢“长”出来的不是一开始规划出来的。所以版本管理非常重要。我推荐用代码仓库管理技能定义每个技能的描述、参数Schema、测试集、版本号都作为代码的一部分。改技能描述要走“修改-测试-提交”的流程别在线上环境直接改否则哪天改崩了你都不知道是哪次改动导致的。复用方面我见过两种极端团队一种是每个项目都从零开始写技能完全不看以前的积累另一种是什么都想做成通用技能结果技能之间耦合严重改一个全崩。我的建议是先按项目需求做出“能用”的技能等发现多个项目都在用同一套逻辑的时候再把它抽象成底座技能或领域技能。复用是抽象的结果不是规划的目标。最后再分享一个习惯技能库每过一段时间要做一次“技能瘦身”。那些长期没被调用的技能要么是没价值要么是描述写得太隐蔽导致模型找不到。前者直接删掉后者要重写描述。我的观察是技能库的规模不是越大越好模型在成千上万个技能里做选择本身就是一件高难度动作。精简、高可用、边界清晰的技能库比大而全的摆设要强得多。我个人的经验是agent-skills 这套思路真正考验人的不是技术而是“拆解”的功力。能把一个复杂的业务场景拆成边界清楚、描述准确、可独立测试的技能比会写多少行提示词重要得多。这需要你对业务有足够的理解对模型的行事偏好有足够的体感再配合上面这些工程方法大概率能做出生产可用的智能体。