最近几个月我一直在折腾智能体Agent应用最深的感受是真正决定一个智能体上限的不是模型本身有多强而是你往它身上挂了多少“skills”。所谓 skills通俗讲就是一组可复用、可插拔、能按需调用的能力封装里面包含指令、领域知识、工具配置和示例而不是简单的一段提示词。它能解决很多团队都会遇到的问题——提示词越写越长、越改越乱、一改全崩。这篇文章我想把这套东西掰开揉碎讲清楚skills 到底怎么设计、怎么落地、会遇到哪些坑。适合正在做智能体开发的人也适合想用 AI 完成复杂任务的效率玩家哪怕你完全没搭过后端也能看懂核心思路。1. 为什么“技能化”是智能体落地的关键1.1 从“大而全的提示词”到“小而精的技能包”很多团队最开始做智能体习惯把所有规则、角色、知识、示例全部塞进一条提示词里。看起来简单实际跑起来问题一堆。首先是上下文长度越来越失控。业务知识一多提示词动辄上千行每次调用模型都要重新处理一遍这些内容费用高、响应慢。其次是注意力稀释模型要在大段文本里自己找重点经常找错。最难受的是维护今天改了一个规则明天可能把另一个功能的回复风格带偏因为所有逻辑都搅在一起根本没有边界。技能化就是把这些混在一起的逻辑拆成独立模块。每个技能只负责一件具体的事比如“查订单状态”就是查订单状态它不会关心退款政策。模型收到用户请求后先判断这个问题该用哪个技能再把对应技能加载进来执行。这就像你家里不会把所有工具焊在一把锤子上而是备一个工具箱拧螺丝用螺丝刀敲钉子用锤子各取所需。我见过一个很典型的案例某个客服智能体原本用一条大提示词同时处理订单查询、退改政策和物流信息上线后准确率一直上不去。后来把它们拆成三个独立技能每个技能只带自己的知识库和示例两周后意图识别准确率从 76% 提到了 94%。原因很直接模型不需要再纠结“这段文字到底是规则还是上下文”它只需要针对当前场景做判断。1.2 一套技能系统需要具备哪些核心能力如果只是把提示词拆开存到不同文件里那还不叫技能系统。一套真正能落地的 skills 体系至少要包含下面几个能力技能注册与清单管理系统要知道自己一共有哪些技能每个技能的版本、名称、职责是什么。输入输出定义每个技能都要说清楚自己需要哪些参数返回什么结构。这是后续做校验和稳定的基础。触发匹配机制模型或路由层要能从用户请求里判断“该不该调用某个技能”以及多个技能候选时选哪个。执行层技能内部可以是提示词模板也可以是一段代码、一个 API 调用甚至一套完整的多步骤流程。反馈与日志每次调用有没有成功、参数抽成了什么样、耗时多少都要能记下来方便排查。这里面的关键字段我用表格整理一下你在设计 manifest技能的声明文件时可以直接参考字段作用注意事项skill_id技能唯一标识建议用“业务域_动作”格式如 order_queryname技能名称用户或模型可读尽量短description功能描述必须写清楚“何时用、何时不用”parameters输入参数 Schema推荐 JSON Schema字段要收敛execution执行逻辑可以是 prompt、函数引用或工作流priority优先级多个技能相似时决定顺序version版本号升级和回滚都靠它你可能已经注意到了我把 description 和 parameters 放得很重。实际使用中绝大多数技能调不准问题都出在这两个字段上。尤其是 description它是模型判断“要不要调用这个技能”的主要依据写得模糊模型就不敢调用或者乱调用。我通常会在描述里明确写两句话第一句是“当用户提到什么的时候使用”第二句是“千万不要用于什么场景”。这两句话比你在后面堆十条规则都管用。2. 设计技能包从业务场景到可执行单元2.1 先拆场景再写指令很多新人一上来就急着写技能内容恨不得把大语言模型的提示词技巧都用上。我的建议是反过来先别碰提示词先拆场景。具体做法很简单找出你历史对话记录里高频出现的问题比如过去三个月用户反复问的那些东西。把这些问题归归类一类就是一个候选技能。然后为每个候选技能写一张“场景卡”包括触发条件、用户典型说法、必须提供的核心信息、期望的输出。这张场景卡先在真实对话里验证 2-3 天再决定要不要做成正式技能。举个例子一个内容创作助手项目最初我按“写文章”“改文案”“起标题”三个场景做了三个技能。跑了一周后发现“写文章”这个技能太贪心用户有时候只想要一个开头有时候想要完整长文有时候想要目录大纲。三个诉求混在一个技能里模型经常给错格式。后来我把“写文章”拆成了“生成大纲”“生成章节初稿”“生成完整文章”三个技能每个技能只关心一种输出立刻稳定下来。拆场景的时候有个容易忽略的细节你不仅要拆“用户说了什么”还要拆“用户没说但隐含了什么”。比如用户说“帮我看看这个订单”可能隐含了“查物流”的意思。这时候就需要技能支持从上下文推断参数而不是硬等用户把所有信息说全。2.2 输入输出的结构化设计技能参数设计得越随便模型抽参就越飘。我见过最离谱的情况是模型把用户输入的日期“明天”直接传给了接口接口收到一个中文字符串直接崩溃。要解决这个问题必须给每个技能定义严格的输入结构。我一般直接用 JSON Schema 来定义。下面是一个订单查询技能的 parameters 示例{ name: query_order, description: 查询用户的订单状态。当用户提到订单、物流、发货时使用不要用于退款和售后。, parameters: { type: object, properties: { order_id: { type: string, description: 订单编号支持模糊匹配 }, customer_id: { type: string, description: 用户唯一标识 }, query_time: { type: string, description: 查询时间范围格式为 YYYY-MM-DD, default: 最近7天 } }, required: [order_id] } }看到没我在 description 里写清了格式在 query_time 里给了默认值。这就能让模型在用户没说时间范围时自动补上“最近7天”而不是留空让下游报错。required 字段一定要用起来该要求必填的参数就要求必填别怕模型抽不出来宁可让它反问用户也比传错值强。输出结构也一样。建议每个技能都定义好返回字段比如 status、data、message。这样前端、日志和后置校验都能统一处理。我在项目里还会让技能执行结果经过一次“后处理层”把模型输出里明显不符合 schema 的内容拦截下来比如把“查询成功”这种无意义内容重新变成结构化字段而不是直接透传给用户。2.3 把领域知识塞进技能包技能不只是“告诉模型要做什么”还要给模型足够的上下文。我习惯在每个技能包里放四块内容角色设定、知识要点、执行流程、示例。角色设定不是那种“你是一个博学的助手”的废话而是“你是订单查询专家只负责返回订单状态不回答价格争议问题”。知识要点是当前技能专属的规则比如订单状态的枚举值、退款原因的分类、不同渠道的响应差异。执行流程是模型拿到请求后先做什么、再做什么比如“先解析 order_id如果缺失则追问再查询再按固定模板输出”。示例部分是我最看重的。不要只放正例一定要放反例。正例告诉模型“这种情况该调用”反例告诉模型“这种情况千万不要调用”。比如订单查询技能里可以加一个反例“用户问‘我的退款怎么还没到’不要调用 query_order应该调用 refund_status。”这样模型就不会在退款场景里误触订单接口。有人会问知识量特别大的时候怎么办比如一个技能涉及几千条产品规则。我的答案是不要全塞进技能提示词里而是把长知识库放到向量检索或倒排索引中技能本身只留检索的入口。这样技能包瘦身模型聚焦还能避免提示词超长带来的费用和延迟问题。这个思路相当于你给技能配了一个“外接大脑”用到的时候再取而不是把所有书都塞在口袋里。3. 从零搭建一套轻量级 skills 管理系统3.1 技术选型与目录结构很多人一听“技能系统”就想去上一个微服务框架项目管理、权限中心全上最后维护成本比业务代码还高。我的建议是从最小可用结构开始先用一个目录 多个 JSON 文件把技能管起来跑通了再考虑要不要加中心化存储。我自己搭建过一套轻量级方案基于 Python 后端做路由技能本体用目录和 JSON manifest 描述。目录结构大概长这样skills/ ├── manifest.json ├── order_query/ │ ├── skill.json │ └── prompt.md ├── refund_status/ │ ├── skill.json │ └── prompt.md └── common/ └── few_shot_examples.json每个技能目录里skill.json 是声明文件专门给路由层读prompt.md 是给模型看的实际内容。为什么拆成两个文件因为路由层只需要技能名、描述、参数这些元信息不需要读整份提示词。拆开后路由层加载轻模型生成时再读完整内容各司其职。manifest.json 是全局索引记录当前有哪几个技能、各版本号、是否启用。很多团队会忽略这个索引文件直接在代码里硬编码技能列表结果新增一个技能还要改路由代码。用索引文件的好处是技能上线和下线都只是改一个 JSON 字段不用重新部署。3.2 技能注册与调用的核心流程技能系统最核心的是两条流程注册流程和调用流程。注册流程在服务启动时执行扫描 skills 目录 - 解析每个 skill.json - 校验字段是否完整 - 注册到内存路由表。校验这一步非常关键如果发现 description 为空我建议直接报错而不是让这个半成品技能上线害人。调用流程可以拆成五步接收用户请求提取对话上下文和当前任务。意图匹配把请求和所有技能的 description 做匹配选出候选技能。参数抽取按照选中技能的 Schema让模型抽取出结构化参数。执行技能可能是调用一段代码、拼好 prompt 再问一次模型或者调用外部 API。结果返回把执行结果统一包装再送回对话流程。简化后的 Python 逻辑大概长这样import json from pathlib import Path SKILLS_DIR Path(./skills) def load_skills(): skills {} for skill_dir in SKILLS_DIR.iterdir(): manifest_path skill_dir / skill.json if manifest_path.exists(): with open(manifest_path, r, encodingutf-8) as f: skill json.load(f) skills[skill[skill_id]] skill return skills def find_skill(skills, user_input): # 这一步通常会调用模型做意图识别 # 简化通过关键词和描述匹配 for skill in skills.values(): for keyword in skill.get(keywords, []): if keyword in user_input: return skill return None def call_skill(skill, params): # 执行技能这里可以是代码逻辑也可以是提示词模板 prompt load_prompt(skill[skill_id]) return run_model(prompt, params)这不是完整生产代码但骨架够用了。你可以看到 find_skill 的结果完全依赖技能描述和质量所以前面我把 description 的重要性强调那么多次不是没道理的。3.3 如何处理技能依赖与版本升级技能不是写一次就完事了业务一变技能就得改。但改技能和改代码一样最怕改坏线上行为。所以我建议每个技能都要有 version 字段同时支持依赖声明。比如一个技能用到了另一个技能产出的中间结果那就不能随意调整上游技能输出格式否则下游会崩。我会在 skill.json 里加一个 depends_on 字段启动时做依赖检查确保所有引用都存在而不是等到线上调用时才报错。版本升级时我采用类似“灰度发布”的思路同一技能保留多个版本目录路由表里 version 字段控制当前默认版本。先切少量流量到新版本观察日志有没有异常再逐步放量。如果新版本出事把 version 字段回退就行整个过程不用重新部署服务只要切换配置。这里还有一个很容易踩的坑升级技能时只改了你认为需要改的那部分但模型可能在另一个没有任何改动的场景里行为变了。这不是模型玄学而是因为技能描述里某句话的措辞变化影响了整体语义匹配。所以每次升级后一定要用回归测试集跑一遍全部历史用例而不是只测当前改的这个场景。4. 实测数据与效果对比4.1 三组实验有技能 vs 无技能为了验证技能化到底有没有用我在某个智能客服项目里做了一组对比实验。测试集是 500 条真实用户问题覆盖订单查询、物流、退款、售后、常见咨询五个业务域。我对比了三组方案纯大提示词、单技能、多技能路由。结果如下指标纯大提示词单技能多技能路由意图识别准确率76.4%86.2%94.8%参数抽取完整率82.1%90.3%96.5%平均响应时间3.8s2.9s2.1s一次需求变更平均耗时2小时1小时15分钟单技能方案是只把内容做了一个大技能包没有拆业务域所以提升有限。多技能路由的提升最明显而且不只是准确率维护效率的变化更让人惊喜。之前改一个业务规则要在几百行提示词里找位置现在只需要打开对应技能目录改动几十行也不怕影响其他业务。这个结果并不意外。模型在上下文变短、目标单一的情况下判断和抽取的稳定性都会有显著提升。你给模型太多无关信息它就会“分心”你把无关信息隔离开它就只盯着眼前这一件事。4.2 真实场景中的调用记录光看指标不够我再看一条真实调用记录。用户输入是“我要查一下昨天订单到哪里了。”多技能路由收到后先匹配到 query_order 技能然后抽取参数order_id 没有直接从这句里出现但系统从会话上下文中找到了之前用户留下的订单号“ORD20240701”query_time 被解析为“最近7天”。最终技能返回结果{ status: success, data: { order_id: ORD20240701, tracking: 已到本市分拨中心预计明天送达 } }整个过程模型只做了一次意图判断和参数抽取真正返回给用户的文案由技能模板拼装完成所以稳定。我还专门测过冷启动场景一个新技能刚上线时没有配 few-shot 示例召回率只有 67%补了三条正例和两条反例后召回率直接到 93%。这印证了我前面说的示例不是可有可无它是技能数据的一部分。5. 常见问题与排查技巧实录5.1 模型总是不触发技能最典型的症状是用户明显在问订单问题模型却当普通聊天回复了。排查思路从三个方向入手。第一看技能描述是不是写得太宽泛或太窄。太宽泛会导致模型不敢确认太窄会导致漏匹配。我自己的标准是描述里必须出现至少两个用户可能会用的动词和名词比如“查询”“订单”“物流”。第二看示例里是不是只有正例没有反例。模型需要知道“什么时候不用”否则它会在边界场景犹豫。第三检查匹配阈值。有些框架默认阈值是 0.6如果用户表达比较口语化置信度可能上不去。我习惯把阈值下调到 0.35同时靠反例来兜底误触。5.2 参数抽取乱如麻参数抽取错误是另一个高频问题。比如用户说“帮我查下上个星期的订单”模型把“上个星期”抽成了字符串“上个星期”而接口要的是具体日期。解决思路是把格式要求写进参数描述比如“时间统一为 YYYY-MM-DD”同时在 Schema 里加正则约束或枚举值。如果模型还是抽错就要在技能执行前加一道二次校验发现参数不合法就要求模型重新生成而不是直接送到接口。实在不行就把这个常见表达写进示例让模型模仿示例里的抽取方式。5.3 技能包升级后行为漂移我在项目里遇到过一件特别诡异的事一个技能从 v1 升级到 v2 后原本好好的订单号提取突然全乱了。我检查 diff发现自己只是改了一下角色设定里的措辞没有动参数定义但模型就是被新措辞带偏了。这就是提示词改动的耦合效应。哪怕只是增加一句“你是一名资深客服”也可能让模型更倾向于用“更贴心”的表达方式进而影响输出格式。所以我后来给每个技能配置了一个 golden set也就是一组历史全部跑过的用例包含输入、期望输出、期望参数。每次升级后先跑一遍 golden set再决定放不放量。这比靠肉眼验证省心太多。5.4 技能冲突与优先级技能一多冲突就会出现。最典型的一个例子我有两个技能一个负责火车票退票一个负责机票退票用户说“我要退票”模型不知道该选谁。解决办法是给技能加 priority 字段同时强化 description 里的互斥条件。比如火车票退票技能里写“仅当用户提到高铁、火车、12306 时使用”机票退票技能里写“仅当用户提到航班、机票、航空公司时使用”两个描述都带上“不要用于”的边界。这样一来大多数模糊请求会被路由到优先级更高的技能或者让模型先追问而不是瞎猜。6. 一点个人体会这篇文章写到这里核心的内容都讲完了。最后聊几句我自己的真实感受。我第一次做技能系统的时候以为写几个好看的提示词模板就够了后来才发现技能库跟代码库一样需要认真维护——要有版本、要有测试、要有文档。没有测试集的技能库升级一次就像是蒙眼换零件早晚会出事。另外一个小技巧一定要重视“模型没调用技能”的日志。很多时候问题的信号就藏在这些被跳过的调用里。我会定期把这类日志拉出来看分析是描述不清晰、示例不足还是意图识别阈值太高比反复调提示词有效得多。我后续还打算把自己手上的技能库做成一个共享仓库让不同项目复用同一套 skills并结合不同的业务数据做配置化接入。这件事大概率会踩更多坑但我已经做好准备把技能系统的设计当成一个长期资产来打磨。