agent-skills这个词最近在AI圈子里被反复提起。我做智能体开发也有两三年了从最早的提示词堆砌到后来的函数调用再到现在围绕技能skills来构建智能体最大的感受是智能体的能力上限早就不是模型本身了而是你给它配备了多少高质量、可复用的技能。如果你正打算做AI Agent相关的项目或者在为现有的智能体产品能力发愁——感觉模型什么都能聊但一落到具体任务上就漏洞百出——那我强烈建议你认真研究一下agent-skills这个方向。这篇文章会把我在实际项目中关于技能设计、技能编排、以及如何把一套技能系统真正落地的经验全部拆开来讲包括踩过的坑和最终沉淀下来的方法论希望对你有用。1. agent-skills 到底是什么从琐碎动作到复合能力1.1 技能不是会调用工具而是会完成一件事很多人一开始会把技能skills和工具调用function calling / tool use混为一谈。工具调用是智能体调用一个外部API或函数比如查询天气打开网页发送邮件这是原子操作颗粒度非常细。而技能不一样技能是一个面向目标的能力封装它内部可能包含多个步骤、多个工具、多轮自我校验。我用一个生活化的例子解释工具是拿起锅铲技能是炒一盘番茄炒蛋。拿起锅铲只需要一个动作但炒一盘菜需要你判断番茄熟度、控制火候、决定什么时候放盐、最后还要尝味道确认咸淡。技能就是这个炒菜的完整流程而不是某一个单一动作。在实际的Agent开发中这两者的区别直接决定了智能体是像个工具人还是像个帮手。我见过太多项目把十几个API一股脑儿塞给大模型以为模型会自动把事情办好。结果模型确实会调用API但它不知道什么时候该调、调完该做什么、结果异常怎么办。这就是典型的只有工具没有技能。1.2 agent-skills 项目的核心价值能力资产化agent-skills作为一个项目主题核心要解决的事情很明确把智能体执行复杂任务的能力变成一个可以被定义、复用、共享、升级的资产。你可以把技能理解成智能体的职业能力证书。一个客服智能体可以拥有处理退款单查询物流状态安抚不满用户升级投诉工单等技能一个代码助手可以拥有理解仓库结构运行测试用例修复单元测试失败生成提交信息等技能。每个技能都不是凭空来的它是业务知识和工程实现的结晶。我把这个过程中的关键价值归纳成三点可复用一次开发多处使用。同样的语义检索技能既可以用在问答机器人里也可以用在文档助手、客服质检系统里。可组合复杂任务由简单技能编排而来。比如写周报技能 收集本周提交记录 分析代码变更 生成周报文档。可进化技能是独立模块可以单独迭代升级不影响智能体的其他部分。今天把生成SQL查询技能升级了不必改动整个Agent逻辑。1.3 这套思路适合谁来用说实话agent-skills的受众比我预想的要宽得多。我一开始以为这是开发者专属的东西后来发现产品经理、业务运营、甚至独立开发者都在用类似的思路设计他们的智能体。如果你是开发者你可以从代码层面实现一套技能框架定义好技能的结构、加载方式、调度逻辑如果你是产品经理你可以用技能的思路来规划Agent的功能边界——一个智能体该具备哪些技能每个技能的输入输出是什么优先级怎么排如果你是业务方你可以把团队的SOP标准作业流程转成技能描述让智能体严格按SOP执行。无论你在哪个位置agent-skills这套思维都能让你手头的智能体从能聊天变成能干活。2. 技能系统设计的底层逻辑为什么说技能不是简单的函数2.1 技能的三大组成意图描述、执行流、验收标准当我们把技能当作一个工程对象来看待时它绝不是一段提示词或者一个函数那么单薄。我在实际设计技能时要求每个技能必须包含三个部分意图描述Intent、执行流Flow、验收标准Acceptance Criteria。意图描述是给大模型看的说明书告诉模型什么情况下该使用这个技能、这个技能能解决什么问题、使用前需要准备什么信息。执行流是技能内部的步骤编排可以是一个固定的工作流也可以是一个让模型自主决策的策略框架。验收标准则是技能质量的底线——步骤跑完不算完必须通过验收标准才算是真正完成了任务。举个例子。我在做一个电商客服Agent时设计了一个处理退货申请技能。它的意图描述会写明当用户明确表达退货诉求并且订单处于已签收状态时启用本技能。执行流是核实订单号→核对退货原因→检查是否在退货窗口期→生成退货码→告知用户退货流程。验收标准是用户拿到了退货码且系统日志中记录了退货申请单号。这套三件套的设计让我在后期排查Agent为什么没按预期工作时省了无数时间。因为每一层都可以单独验证是模型没识别出该用技能还是执行流里某一步做错了还是技能完成质量不达标问题是发生在哪个环节一目了然。2.2 技能的颗粒度太大太小都会出事我刚做技能设计时犯的最严重的错误是技能颗粒度掌握不好。一开始我把颗粒度设计得特别细每个技能只做一件极小的事比如提取订单号判断退货窗口期结果一个退货任务要串联七八个技能模型在步骤间切换时频繁出错上下文也被拖得很长后来我又把颗粒度放大整个退货流程做成一个技能结果模型试图下雨天收衣服——什么都想管反而经常在不必要的环节上较劲。最终的平衡点在于技能应该能独立完成一个有明确产出的业务动作。判断退货窗口期没有独立产出它只是中间步骤不适合做技能处理退货申请有明确产出退货码流程指引且能独立执行适合做技能。如果流程太长可以拆成处理退货申请和监督退货退款进度两个技能前者负责发退货码后者负责追踪退款到账。这个判断标准在实际操作中非常有用你设计好一个技能后问自己一句——这个技能执行完后用户或系统能拿到一个明确的结果吗能就说明颗粒度合适不能就把技能继续外扩。2.3 技能之间如何协同编排层是灵魂单有技能还不行Agent拿到的是一个任务它得能判断该用哪个技能先做哪个后做哪个多个技能的结果怎么合并。这一层我管它叫编排层Orchestration它才是整个Agent的魂。编排思路主流有两种。一种是靠模型自主判断也就是让大模型根据用户输入从技能列表里挑一个来调用。这种方式灵活度高但可靠度一般尤其当技能数量超过20个以后模型的选择准确率明显下降。另一种是靠确定性规则我们预先定义好业务处理流程什么场景走什么技能链。这种方式稳定但灵活性差遇到规则外的场景就傻眼。我现在做项目采用的是混合编排核心业务路径用确定性规则兜底边缘场景交给模型自主决策。比如客服Agent用户明确说我要退货就直接走退货技能链用户说这个商品我不满意模型自主判断用户可能想退货或换货再引导到具体技能。这样既稳又不死板。3. 实操搭建一套可扩展的 agent-skills 技能框架3.1 技能描述文件的标准化进入工程实现环节第一步是定义技能的描述格式。用过Anthropic的Claude Skills或者OpenAI的自定义Agent的话你会发现它们都不约而同采用了一个技能一个目录的物理组织方式目录里放一个描述文件外加若干脚本和资源文件。我的标准目录结构大致长这样skills/ └── handle-refund/ ├── SKILL.md # 技能描述、使用条件、执行步骤 ├── run.py # 技能执行脚本可选 ├── refund_template.md # 给用户回复的话术模板 └── requirements.txt # 技能运行时的依赖SKILL.md是技能的核心。我会要求团队必须严格按照以下模板来写--- name: handle-refund description: 处理用户的商品退货申请生成退货码并指导用户寄回商品。 使用条件 - 用户明确表达退货诉求 - 订单状态为“已签收” - 有有效订单号 输入参数 - order_id: string订单号 执行步骤 1. 调用 check_order_status 确认订单状态 2. 核对退货原因是否在支持范围内 3. 调用 generate_return_code 生成退货码 4. 使用 refund_template.md 生成用户回复 验收标准 - 返回退货码 - 系统日志写入退货申请记录 --- # 处理退货申请技能 技能细节说明可以写一些给执行模型看的注意事项比如某些特殊情况怎么处理、有哪些坑要避开……印象中这个格式一旦标准化下来后面的迭代效率会大幅提升。以前我们用纯自然语言写的技能描述每个风格都不同模型一会儿能读懂一会儿读不懂标准化的YAML头部加自然语言主体之后模型对技能触发条件的识别稳了很多。3.2 技能加载机制别把所有技能都塞进上下文接下来是关键工程问题——技能怎么加载进大模型。如果Agent有20个技能每个SKILL.md平均800字那就是16000字全部塞进上下文会让系统提示词变得又长又贵还会降低模型对关键指令的注意力。我在项目中采用了两级加载机制。第一级是技能清单每个Agent只加载一份技能索引里面是每个技能的名字、一行描述、参数要求。这份索引控制在几百字内让模型知道有哪些技能可用。第二级是按需加载当模型决定要调用某个技能时系统再去把对应技能目录下的完整SKILL.md和脚本动态读取进来。这样做的好处非常明显上下文占用从所有技能的全文变成了清单全文 当前要用的技能全文。如果一共20个技能、每次任务最多用到3个上下文开销能减少70%以上。而且技能数量可以持续扩张不再受上下文窗口制约。这个方案可以用很简单的Python函数实现动态检索def load_skill(skill_name: str) - Optional[Skill]: 按需加载技能目录返回技能对象 skill_path SKILLS_DIR / skill_name if not skill_path.exists() or not (skill_path / SKILL.md).exists(): return None description (skill_path / SKILL.md).read_text(encodingutf-8) return Skill(nameskill_name, descriptiondescription, pathskill_path)实际用下来这种懒加载模式让整体响应延迟也降低了——因为不需要每次请求都把20多个技能文件全部读一遍I/O开销小了很多。3.3 技能注册表与运行时调度技能文件只是静态资源运行时还需要一个调度核心。我会维护一个技能注册表skill registry把所有的技能元信息集中登记起来同时负责加载、校验和执行。调度核心的核心逻辑其实不复杂接收用户的自然语言请求找出适合的技能执行技能并返回结果。但这里有几个必须在工程上处理的细节。第一个是技能参数校验。模型生成的参数经常不完整——用户没说订单号怎么办参数格式不对怎么办我的做法是在调用技能前增加一层参数校验逻辑缺什么参数先向用户补齐而不是直接把残缺参数丢给技能去执行。这里校验逻辑可以用JSON Schema来描述参数约束让模型按照Schema补全参数。第二个是执行结果反馈。技能执行完以后结果要回传给模型让模型根据结果决定下一步动作。这个闭环如果不做Agent就会出现技能执行完了但模型还在那边自顾自地说话的情况。我一般会把执行结果、状态码、耗时等结构化信息一并返回给模型。def execute_skill(skill_name: str, params: dict) - ExecutionResult: # 1. 加载技能并校验参数 skill load_skill(skill_name) if skill is None: return ExecutionResult(successFalse, error技能不存在) # 2. 补全缺失参数向模型或用户索取 fill_params complete_params(skill, params) # 3. 执行技能逻辑记录日志 result run_skill_fn(skill, fill_params) # 4. 将执行结果封装交给编排层判断下一步 return result调度层还有一个容易被忽略的点并发与超时。技能里有外部API调用时必须设置超时时间。我之前遇到过技能内部调第三方接口卡死整个Agent跟着一起卡住的情况。后来把技能的超时和重试机制做进调度层每个技能默认超时10秒超过则返回错误信息给模型模型可以选择换一个技能或者告知用户稍后再试。3.4 让技能具备自我修复能力光能把技能跑通不算完生产环境中的技能一定会因为各种原因失败上游API返回格式变了、数据库里没有对应数据、网络闪断……所以我的技能框架里一定会加一层失败处理机制。失败处理我设计了三个层次第一层技能内部重试主要应对超时和瞬时错误第二层模型介入纠偏当技能返回明确错误码时把错误信息回传给模型让模型尝试修正参数后重新调用第三层用户兜底前两层都失败了就如实告诉用户这个操作我完成不了原因是什么并提供人工处理的入口。这套三级策略让我的Agent在生产环境中的任务完成率从刚上线时的67%提升到了91%。虽然离完美还很远但至少大部分异常场景下用户得到的不是一句干巴巴的出现错误而是有信息量的反馈和后续路径。4. 技能工程中的常见问题与排查实录4.1 模型就是不调用技能怎么办这是所有做Agent开发的人都会遇到的头号问题——技能写得挺好的规则也都清楚但模型就是不用。常见的场景是模型直接根据参数算了个假结果绕过了你的技能。我先说排查路径。第一步确认技能描述里的使用条件是否写清楚了触发条件模糊模型就无法准确识别。第二步检查技能的description字段是否足够直白模型选技能主要看这个字段写得太抽象容易让模型拿不准。第三步看模型实际看到的上下文——是不是技能清单被其他指令淹没在上下文中了。在实践中我用的最有效的办法是把技能描述写成一个使用示例。与其写当用户需要退货时调用本技能不如写如果用户说我要退货商品不合适怎么退帮我申请退款调用本技能返回退货码和寄回地址。给模型看具体例子它的判断准确率会有肉眼可见的提升。另外还有一个非常实用的小技巧在系统提示词里加一句在回答之前先判断是否有技能可以执行。如果有必须先执行技能再根据技能结果回复用户。这句简单的指令能让技能调用率提高不少。4.2 技能有了但结果质量忽高忽低技能调用起来了新的问题又出现了同一个技能有时候结果完美有时候结果跑偏。这通常意味着技能内部流程里有一些步骤步骤与步骤之间的衔接给了模型太多的自由发挥空间。我排查这类质量波动问题时会先把技能执行过程里的中间步骤全部打印出来看模型在哪个环节开始发挥失常。找到环节以后把该环节里的开放式指令改成选项式指令。比如原来是核对退货原因是否在支持范围内模型可能想多了把不喜欢也判定为不支持改成退货原因是否为以下七类之一是→继续否→返回错误模型的判断就稳定多了。本质上技能质量稳定的秘诀就是减少模型的自由度——不是你让模型思考得越多就越准确而是你给模型的选项越明确越可预期。该模型发挥的地方让它发挥比如写回复话术不该发挥的地方比如业务规则判断给死选项。4.3 技能编排顺序混乱模型先做后面的事编排层的问题也很常见。模型调用了技能但顺序不对。明明是先查订单状态再申请退货模型可能先申请退货然后才发现订单还没签收。这个问题的根源在于技能清单里的技能是平铺的模型看不到技能之间的依赖关系和执行优先级。我的解决办法是在技能注册表里额外维护一张前后置依赖表handle-refund: depends_on: query-order-status blocks: none query-order-status: depends_on: none blocks: handle-refund当模型申请调用handle-refund时调度层先检查depends_on列表发现前置技能query-order-status还没执行过就自动在前台插入一次该技能的调用。这样模型即使没意识到顺序问题系统层面也能兜底把技能链给串起来。这个方案做进去以后我在多个项目里都用上了稳定性和可解释性都非常好。即使将来有人接手也只需要看这张依赖表就能理解Agent的业务处理链路。4.4 复杂任务跟进不到一半用户撤了这是业务场景里高频出现的问题用户在Agent处理过程中突然不配合了没回答关键的缺省信息直接换话题或者走人。Agent这时候容易陷入卡住——一直在等用户回答不给任何有意义的输出。我在设计技能执行策略时专门考虑了这个场景做法简单粗暴任何需要向用户追问信息的环节都必须设置最大追问次数。比如退货技能需要补全订单号最多追问两次第三次用户还没有给出有效信息就自动生成一个待处理的半成品工单交由人工客服跟进并且对用户给出友好的结束语。不会让流程僵死在那里。还有一个配套措施技能执行过程中只要检测到用户话题切换就保存当前执行状态并退出技能等用户下次再问的时候从保存的断点继续而不是从头开始。这个思想其实和程序里的断点续传是一样的在体验上能升一个档次。4.5 技能迭代如何不影响线上版本技能是持续演进的频繁改动带来的最大风险是把正在稳定运行的线上Agent搞挂了。早期我们直接改线上技能目录里的SKILL.md结果有一次描述写错了一个字导致模型连续两小时误判技能使用条件流失了好几个用户。现在我的团队上线了一套简单的技能版本管理方案技能目录下增加一个changelog.md每次修改记录变更时间和原因技能文件通过Git管理线上只加载打了version tag的版本新技能先在副本环境跑一周观察调用成功率达标后再切生产。这套流程不复杂但能避免90%以上的改挂事故。我记得有一次我们需要更新生成周报技能的模板就是按照这套流程来的。先在测试环境跑了一天发现新版模板生成的周报平均长度明显增加但要点覆盖率和格式合规率都更好才把它推到生产。切换的时候只需要改一下版本号秒级生效老用户无感。4.6 技能内部调外部API时被限流这是技能工程中很现实的一个坑。技能运行起来后会调用第三方API一旦并发量大很容易被对方的限流策略卡住。如果技能在返回结果前被API限流那么这个技能的执行就会失败。对下游的Agent来说它只知道执行失败却不知道为什么失败也无法从容应对。处理方案比较直接在技能执行层内置两个东西重试策略和退避算法。被限流后先按指数退避方式重试——间隔1秒、2秒、4秒再超过两次就放弃并返回错误码给模型。同时我在技能框架中加了一个简单的信号量限制每秒最多发出的外部调用次数从源头降低被限流的概率。这个问题的排查也比较容易日志里的状态码和耗时能直接看到如果发现某个第三方API的调用失败率偏高且多为429/5xx那基本就是限流或服务不稳定。调低并发保护阈值问题就能缓解。5. 从一个技能到一套体系agent-skills 的进阶方向前面讲的都是单一智能体的技能框架但当你真的把技能做成体系后你会发现它延伸出去的方向远比想象中多。我目前自己在测的进阶玩法有几个一是跨智能体技能共享。公司内部可能同时存在客服、导购、售后、数据分析等多个智能体以前各自开发各自的小功能现在把共性技能抽出来做成一个公共技能库不同智能体按需引用。比如理解用户情绪这个技能客服、导购、售后全都能用。统一更新统一维护省下来的重复开发时间太多了。二是技能编排的可视化。业务运营看不懂代码但能看懂技能流程图。把技能和依赖关系做成可视化的流程图后运营同学可以自己调整技能顺序加一个分支改一个话术模板。这等于让非技术角色也能参与智能体的能力建设。我见过一个运营同事自己搭出一条营销活动配置技能链极大缩短了活动上线周期。三是从单轮技能走向自动发现技能。更前沿一点的做法是——让模型去分析历史对话发现哪些用户请求经常出现但当前技能库覆盖不了自动生成新技能的草稿再由技术人员审核后加入技能库。相当于给Agent装了一个能力自生长的机制。这个方向还没有完全成熟但我觉得未来两到三年会成为Agent平台的核心竞争力。从agent-skills这个思路一路做下来我个人最深的体会是智能体的本质不是大模型而是沉淀在大模型外面的那一层能力体系。模型每个月都在变但真正产生业务价值的是那套稳定、可复用、可演化的技能集合。一个好的技能体系甚至能让一个中等参数的模型发挥出远超它原生水平的业务效果。最后分享一个小技巧技能描述里加一段前面提到过的反面示例很管用。不用太长一两句就行——注意不要将本技能用于未发货订单的退货申请或者当用户提供的订单号不存在时不要直接报错先询问用户是否提供了正确的订单号。这些反面示例能让模型避开你踩过的坑效果比单纯强调正面步骤更直接。就像教一个新员工光告诉他该怎么做不够还得告诉他什么情况下别那么做。技能描述写得越贴近真实业务模型在技能内的表现就越像一个老手。希望这篇文章对准备踏入agent-skills方向的朋友有帮助。 
长河君 · 2026/9/25 16:25:12 · 阅读 1.2k Agent Skills 实用指南：构建可复用智能体技能体系
agent-skills这个词最近在AI圈子里被反复提起。我做智能体开发也有两三年了从最早的提示词堆砌到后来的函数调用再到现在围绕技能skills来构建智能体最大的感受是智能体的能力上限早就不是模型本身了而是你给它配备了多少高质量、可复用的技能。如果你正打算做AI Agent相关的项目或者在为现有的智能体产品能力发愁——感觉模型什么都能聊但一落到具体任务上就漏洞百出——那我强烈建议你认真研究一下agent-skills这个方向。这篇文章会把我在实际项目中关于技能设计、技能编排、以及如何把一套技能系统真正落地的经验全部拆开来讲包括踩过的坑和最终沉淀下来的方法论希望对你有用。1. agent-skills 到底是什么从琐碎动作到复合能力1.1 技能不是会调用工具而是会完成一件事很多人一开始会把技能skills和工具调用function calling / tool use混为一谈。工具调用是智能体调用一个外部API或函数比如查询天气打开网页发送邮件这是原子操作颗粒度非常细。而技能不一样技能是一个面向目标的能力封装它内部可能包含多个步骤、多个工具、多轮自我校验。我用一个生活化的例子解释工具是拿起锅铲技能是炒一盘番茄炒蛋。拿起锅铲只需要一个动作但炒一盘菜需要你判断番茄熟度、控制火候、决定什么时候放盐、最后还要尝味道确认咸淡。技能就是这个炒菜的完整流程而不是某一个单一动作。在实际的Agent开发中这两者的区别直接决定了智能体是像个工具人还是像个帮手。我见过太多项目把十几个API一股脑儿塞给大模型以为模型会自动把事情办好。结果模型确实会调用API但它不知道什么时候该调、调完该做什么、结果异常怎么办。这就是典型的只有工具没有技能。1.2 agent-skills 项目的核心价值能力资产化agent-skills作为一个项目主题核心要解决的事情很明确把智能体执行复杂任务的能力变成一个可以被定义、复用、共享、升级的资产。你可以把技能理解成智能体的职业能力证书。一个客服智能体可以拥有处理退款单查询物流状态安抚不满用户升级投诉工单等技能一个代码助手可以拥有理解仓库结构运行测试用例修复单元测试失败生成提交信息等技能。每个技能都不是凭空来的它是业务知识和工程实现的结晶。我把这个过程中的关键价值归纳成三点可复用一次开发多处使用。同样的语义检索技能既可以用在问答机器人里也可以用在文档助手、客服质检系统里。可组合复杂任务由简单技能编排而来。比如写周报技能 收集本周提交记录 分析代码变更 生成周报文档。可进化技能是独立模块可以单独迭代升级不影响智能体的其他部分。今天把生成SQL查询技能升级了不必改动整个Agent逻辑。1.3 这套思路适合谁来用说实话agent-skills的受众比我预想的要宽得多。我一开始以为这是开发者专属的东西后来发现产品经理、业务运营、甚至独立开发者都在用类似的思路设计他们的智能体。如果你是开发者你可以从代码层面实现一套技能框架定义好技能的结构、加载方式、调度逻辑如果你是产品经理你可以用技能的思路来规划Agent的功能边界——一个智能体该具备哪些技能每个技能的输入输出是什么优先级怎么排如果你是业务方你可以把团队的SOP标准作业流程转成技能描述让智能体严格按SOP执行。无论你在哪个位置agent-skills这套思维都能让你手头的智能体从能聊天变成能干活。2. 技能系统设计的底层逻辑为什么说技能不是简单的函数2.1 技能的三大组成意图描述、执行流、验收标准当我们把技能当作一个工程对象来看待时它绝不是一段提示词或者一个函数那么单薄。我在实际设计技能时要求每个技能必须包含三个部分意图描述Intent、执行流Flow、验收标准Acceptance Criteria。意图描述是给大模型看的说明书告诉模型什么情况下该使用这个技能、这个技能能解决什么问题、使用前需要准备什么信息。执行流是技能内部的步骤编排可以是一个固定的工作流也可以是一个让模型自主决策的策略框架。验收标准则是技能质量的底线——步骤跑完不算完必须通过验收标准才算是真正完成了任务。举个例子。我在做一个电商客服Agent时设计了一个处理退货申请技能。它的意图描述会写明当用户明确表达退货诉求并且订单处于已签收状态时启用本技能。执行流是核实订单号→核对退货原因→检查是否在退货窗口期→生成退货码→告知用户退货流程。验收标准是用户拿到了退货码且系统日志中记录了退货申请单号。这套三件套的设计让我在后期排查Agent为什么没按预期工作时省了无数时间。因为每一层都可以单独验证是模型没识别出该用技能还是执行流里某一步做错了还是技能完成质量不达标问题是发生在哪个环节一目了然。2.2 技能的颗粒度太大太小都会出事我刚做技能设计时犯的最严重的错误是技能颗粒度掌握不好。一开始我把颗粒度设计得特别细每个技能只做一件极小的事比如提取订单号判断退货窗口期结果一个退货任务要串联七八个技能模型在步骤间切换时频繁出错上下文也被拖得很长后来我又把颗粒度放大整个退货流程做成一个技能结果模型试图下雨天收衣服——什么都想管反而经常在不必要的环节上较劲。最终的平衡点在于技能应该能独立完成一个有明确产出的业务动作。判断退货窗口期没有独立产出它只是中间步骤不适合做技能处理退货申请有明确产出退货码流程指引且能独立执行适合做技能。如果流程太长可以拆成处理退货申请和监督退货退款进度两个技能前者负责发退货码后者负责追踪退款到账。这个判断标准在实际操作中非常有用你设计好一个技能后问自己一句——这个技能执行完后用户或系统能拿到一个明确的结果吗能就说明颗粒度合适不能就把技能继续外扩。2.3 技能之间如何协同编排层是灵魂单有技能还不行Agent拿到的是一个任务它得能判断该用哪个技能先做哪个后做哪个多个技能的结果怎么合并。这一层我管它叫编排层Orchestration它才是整个Agent的魂。编排思路主流有两种。一种是靠模型自主判断也就是让大模型根据用户输入从技能列表里挑一个来调用。这种方式灵活度高但可靠度一般尤其当技能数量超过20个以后模型的选择准确率明显下降。另一种是靠确定性规则我们预先定义好业务处理流程什么场景走什么技能链。这种方式稳定但灵活性差遇到规则外的场景就傻眼。我现在做项目采用的是混合编排核心业务路径用确定性规则兜底边缘场景交给模型自主决策。比如客服Agent用户明确说我要退货就直接走退货技能链用户说这个商品我不满意模型自主判断用户可能想退货或换货再引导到具体技能。这样既稳又不死板。3. 实操搭建一套可扩展的 agent-skills 技能框架3.1 技能描述文件的标准化进入工程实现环节第一步是定义技能的描述格式。用过Anthropic的Claude Skills或者OpenAI的自定义Agent的话你会发现它们都不约而同采用了一个技能一个目录的物理组织方式目录里放一个描述文件外加若干脚本和资源文件。我的标准目录结构大致长这样skills/ └── handle-refund/ ├── SKILL.md # 技能描述、使用条件、执行步骤 ├── run.py # 技能执行脚本可选 ├── refund_template.md # 给用户回复的话术模板 └── requirements.txt # 技能运行时的依赖SKILL.md是技能的核心。我会要求团队必须严格按照以下模板来写--- name: handle-refund description: 处理用户的商品退货申请生成退货码并指导用户寄回商品。 使用条件 - 用户明确表达退货诉求 - 订单状态为“已签收” - 有有效订单号 输入参数 - order_id: string订单号 执行步骤 1. 调用 check_order_status 确认订单状态 2. 核对退货原因是否在支持范围内 3. 调用 generate_return_code 生成退货码 4. 使用 refund_template.md 生成用户回复 验收标准 - 返回退货码 - 系统日志写入退货申请记录 --- # 处理退货申请技能 技能细节说明可以写一些给执行模型看的注意事项比如某些特殊情况怎么处理、有哪些坑要避开……印象中这个格式一旦标准化下来后面的迭代效率会大幅提升。以前我们用纯自然语言写的技能描述每个风格都不同模型一会儿能读懂一会儿读不懂标准化的YAML头部加自然语言主体之后模型对技能触发条件的识别稳了很多。3.2 技能加载机制别把所有技能都塞进上下文接下来是关键工程问题——技能怎么加载进大模型。如果Agent有20个技能每个SKILL.md平均800字那就是16000字全部塞进上下文会让系统提示词变得又长又贵还会降低模型对关键指令的注意力。我在项目中采用了两级加载机制。第一级是技能清单每个Agent只加载一份技能索引里面是每个技能的名字、一行描述、参数要求。这份索引控制在几百字内让模型知道有哪些技能可用。第二级是按需加载当模型决定要调用某个技能时系统再去把对应技能目录下的完整SKILL.md和脚本动态读取进来。这样做的好处非常明显上下文占用从所有技能的全文变成了清单全文 当前要用的技能全文。如果一共20个技能、每次任务最多用到3个上下文开销能减少70%以上。而且技能数量可以持续扩张不再受上下文窗口制约。这个方案可以用很简单的Python函数实现动态检索def load_skill(skill_name: str) - Optional[Skill]: 按需加载技能目录返回技能对象 skill_path SKILLS_DIR / skill_name if not skill_path.exists() or not (skill_path / SKILL.md).exists(): return None description (skill_path / SKILL.md).read_text(encodingutf-8) return Skill(nameskill_name, descriptiondescription, pathskill_path)实际用下来这种懒加载模式让整体响应延迟也降低了——因为不需要每次请求都把20多个技能文件全部读一遍I/O开销小了很多。3.3 技能注册表与运行时调度技能文件只是静态资源运行时还需要一个调度核心。我会维护一个技能注册表skill registry把所有的技能元信息集中登记起来同时负责加载、校验和执行。调度核心的核心逻辑其实不复杂接收用户的自然语言请求找出适合的技能执行技能并返回结果。但这里有几个必须在工程上处理的细节。第一个是技能参数校验。模型生成的参数经常不完整——用户没说订单号怎么办参数格式不对怎么办我的做法是在调用技能前增加一层参数校验逻辑缺什么参数先向用户补齐而不是直接把残缺参数丢给技能去执行。这里校验逻辑可以用JSON Schema来描述参数约束让模型按照Schema补全参数。第二个是执行结果反馈。技能执行完以后结果要回传给模型让模型根据结果决定下一步动作。这个闭环如果不做Agent就会出现技能执行完了但模型还在那边自顾自地说话的情况。我一般会把执行结果、状态码、耗时等结构化信息一并返回给模型。def execute_skill(skill_name: str, params: dict) - ExecutionResult: # 1. 加载技能并校验参数 skill load_skill(skill_name) if skill is None: return ExecutionResult(successFalse, error技能不存在) # 2. 补全缺失参数向模型或用户索取 fill_params complete_params(skill, params) # 3. 执行技能逻辑记录日志 result run_skill_fn(skill, fill_params) # 4. 将执行结果封装交给编排层判断下一步 return result调度层还有一个容易被忽略的点并发与超时。技能里有外部API调用时必须设置超时时间。我之前遇到过技能内部调第三方接口卡死整个Agent跟着一起卡住的情况。后来把技能的超时和重试机制做进调度层每个技能默认超时10秒超过则返回错误信息给模型模型可以选择换一个技能或者告知用户稍后再试。3.4 让技能具备自我修复能力光能把技能跑通不算完生产环境中的技能一定会因为各种原因失败上游API返回格式变了、数据库里没有对应数据、网络闪断……所以我的技能框架里一定会加一层失败处理机制。失败处理我设计了三个层次第一层技能内部重试主要应对超时和瞬时错误第二层模型介入纠偏当技能返回明确错误码时把错误信息回传给模型让模型尝试修正参数后重新调用第三层用户兜底前两层都失败了就如实告诉用户这个操作我完成不了原因是什么并提供人工处理的入口。这套三级策略让我的Agent在生产环境中的任务完成率从刚上线时的67%提升到了91%。虽然离完美还很远但至少大部分异常场景下用户得到的不是一句干巴巴的出现错误而是有信息量的反馈和后续路径。4. 技能工程中的常见问题与排查实录4.1 模型就是不调用技能怎么办这是所有做Agent开发的人都会遇到的头号问题——技能写得挺好的规则也都清楚但模型就是不用。常见的场景是模型直接根据参数算了个假结果绕过了你的技能。我先说排查路径。第一步确认技能描述里的使用条件是否写清楚了触发条件模糊模型就无法准确识别。第二步检查技能的description字段是否足够直白模型选技能主要看这个字段写得太抽象容易让模型拿不准。第三步看模型实际看到的上下文——是不是技能清单被其他指令淹没在上下文中了。在实践中我用的最有效的办法是把技能描述写成一个使用示例。与其写当用户需要退货时调用本技能不如写如果用户说我要退货商品不合适怎么退帮我申请退款调用本技能返回退货码和寄回地址。给模型看具体例子它的判断准确率会有肉眼可见的提升。另外还有一个非常实用的小技巧在系统提示词里加一句在回答之前先判断是否有技能可以执行。如果有必须先执行技能再根据技能结果回复用户。这句简单的指令能让技能调用率提高不少。4.2 技能有了但结果质量忽高忽低技能调用起来了新的问题又出现了同一个技能有时候结果完美有时候结果跑偏。这通常意味着技能内部流程里有一些步骤步骤与步骤之间的衔接给了模型太多的自由发挥空间。我排查这类质量波动问题时会先把技能执行过程里的中间步骤全部打印出来看模型在哪个环节开始发挥失常。找到环节以后把该环节里的开放式指令改成选项式指令。比如原来是核对退货原因是否在支持范围内模型可能想多了把不喜欢也判定为不支持改成退货原因是否为以下七类之一是→继续否→返回错误模型的判断就稳定多了。本质上技能质量稳定的秘诀就是减少模型的自由度——不是你让模型思考得越多就越准确而是你给模型的选项越明确越可预期。该模型发挥的地方让它发挥比如写回复话术不该发挥的地方比如业务规则判断给死选项。4.3 技能编排顺序混乱模型先做后面的事编排层的问题也很常见。模型调用了技能但顺序不对。明明是先查订单状态再申请退货模型可能先申请退货然后才发现订单还没签收。这个问题的根源在于技能清单里的技能是平铺的模型看不到技能之间的依赖关系和执行优先级。我的解决办法是在技能注册表里额外维护一张前后置依赖表handle-refund: depends_on: query-order-status blocks: none query-order-status: depends_on: none blocks: handle-refund当模型申请调用handle-refund时调度层先检查depends_on列表发现前置技能query-order-status还没执行过就自动在前台插入一次该技能的调用。这样模型即使没意识到顺序问题系统层面也能兜底把技能链给串起来。这个方案做进去以后我在多个项目里都用上了稳定性和可解释性都非常好。即使将来有人接手也只需要看这张依赖表就能理解Agent的业务处理链路。4.4 复杂任务跟进不到一半用户撤了这是业务场景里高频出现的问题用户在Agent处理过程中突然不配合了没回答关键的缺省信息直接换话题或者走人。Agent这时候容易陷入卡住——一直在等用户回答不给任何有意义的输出。我在设计技能执行策略时专门考虑了这个场景做法简单粗暴任何需要向用户追问信息的环节都必须设置最大追问次数。比如退货技能需要补全订单号最多追问两次第三次用户还没有给出有效信息就自动生成一个待处理的半成品工单交由人工客服跟进并且对用户给出友好的结束语。不会让流程僵死在那里。还有一个配套措施技能执行过程中只要检测到用户话题切换就保存当前执行状态并退出技能等用户下次再问的时候从保存的断点继续而不是从头开始。这个思想其实和程序里的断点续传是一样的在体验上能升一个档次。4.5 技能迭代如何不影响线上版本技能是持续演进的频繁改动带来的最大风险是把正在稳定运行的线上Agent搞挂了。早期我们直接改线上技能目录里的SKILL.md结果有一次描述写错了一个字导致模型连续两小时误判技能使用条件流失了好几个用户。现在我的团队上线了一套简单的技能版本管理方案技能目录下增加一个changelog.md每次修改记录变更时间和原因技能文件通过Git管理线上只加载打了version tag的版本新技能先在副本环境跑一周观察调用成功率达标后再切生产。这套流程不复杂但能避免90%以上的改挂事故。我记得有一次我们需要更新生成周报技能的模板就是按照这套流程来的。先在测试环境跑了一天发现新版模板生成的周报平均长度明显增加但要点覆盖率和格式合规率都更好才把它推到生产。切换的时候只需要改一下版本号秒级生效老用户无感。4.6 技能内部调外部API时被限流这是技能工程中很现实的一个坑。技能运行起来后会调用第三方API一旦并发量大很容易被对方的限流策略卡住。如果技能在返回结果前被API限流那么这个技能的执行就会失败。对下游的Agent来说它只知道执行失败却不知道为什么失败也无法从容应对。处理方案比较直接在技能执行层内置两个东西重试策略和退避算法。被限流后先按指数退避方式重试——间隔1秒、2秒、4秒再超过两次就放弃并返回错误码给模型。同时我在技能框架中加了一个简单的信号量限制每秒最多发出的外部调用次数从源头降低被限流的概率。这个问题的排查也比较容易日志里的状态码和耗时能直接看到如果发现某个第三方API的调用失败率偏高且多为429/5xx那基本就是限流或服务不稳定。调低并发保护阈值问题就能缓解。5. 从一个技能到一套体系agent-skills 的进阶方向前面讲的都是单一智能体的技能框架但当你真的把技能做成体系后你会发现它延伸出去的方向远比想象中多。我目前自己在测的进阶玩法有几个一是跨智能体技能共享。公司内部可能同时存在客服、导购、售后、数据分析等多个智能体以前各自开发各自的小功能现在把共性技能抽出来做成一个公共技能库不同智能体按需引用。比如理解用户情绪这个技能客服、导购、售后全都能用。统一更新统一维护省下来的重复开发时间太多了。二是技能编排的可视化。业务运营看不懂代码但能看懂技能流程图。把技能和依赖关系做成可视化的流程图后运营同学可以自己调整技能顺序加一个分支改一个话术模板。这等于让非技术角色也能参与智能体的能力建设。我见过一个运营同事自己搭出一条营销活动配置技能链极大缩短了活动上线周期。三是从单轮技能走向自动发现技能。更前沿一点的做法是——让模型去分析历史对话发现哪些用户请求经常出现但当前技能库覆盖不了自动生成新技能的草稿再由技术人员审核后加入技能库。相当于给Agent装了一个能力自生长的机制。这个方向还没有完全成熟但我觉得未来两到三年会成为Agent平台的核心竞争力。从agent-skills这个思路一路做下来我个人最深的体会是智能体的本质不是大模型而是沉淀在大模型外面的那一层能力体系。模型每个月都在变但真正产生业务价值的是那套稳定、可复用、可演化的技能集合。一个好的技能体系甚至能让一个中等参数的模型发挥出远超它原生水平的业务效果。最后分享一个小技巧技能描述里加一段前面提到过的反面示例很管用。不用太长一两句就行——注意不要将本技能用于未发货订单的退货申请或者当用户提供的订单号不存在时不要直接报错先询问用户是否提供了正确的订单号。这些反面示例能让模型避开你踩过的坑效果比单纯强调正面步骤更直接。就像教一个新员工光告诉他该怎么做不够还得告诉他什么情况下别那么做。技能描述写得越贴近真实业务模型在技能内的表现就越像一个老手。希望这篇文章对准备踏入agent-skills方向的朋友有帮助。