1. 为什么我突然开始折腾 agent-skills最近在给团队搭智能体应用的时候发现一个特别尴尬的问题模型本身的推理能力再强落到具体业务里也总得有人教它“怎么做”。拿一个最简单的场景举例让 Agent 帮用户查天气看起来就是把城市名丢给天气接口可实际上你还要处理地点解析、日期理解、单位换算、接口异常重试这一堆琐碎逻辑如果全塞进提示词里第一次跑通容易后面维护起来简直是一场灾难。于是我开始认真研究 agent-skills 这套东西。说白了它就是给智能体准备的一套“可复用的技能库”把模型需要执行的每一种操作都封装成带清晰描述、标准参数、明确返回结果的技能模块。模型不需要知道技能内部怎么实现只需要根据用户意图选择合适的技能并且把参数填对就行。这个思路和微服务很像把一个大系统拆成多个小服务每个服务只管自己的事通过接口通信。折腾了一段时间之后我最大的感受是技能系统设计得好不好直接影响智能体在真实业务里的可用性。设计得好Agent 能像一个熟练员工一样按流程干活设计得不好模型就变成了一把乱挥的锤子什么钉子都想敲最后敲出一堆 bug。这篇文章我想把 agent-skills 的整套设计思路、落地方法和踩坑经验完整分享一下。里面不会有那种“万物皆可智能”的浮夸话术都是我在真实项目里验证过、跑通过的东西。适合正在做智能体应用、想给 Agent 增加工具调用能力、或者被提示词工程折磨到想换思路的开发者参考。2. agent-skills 的本质把“教模型做事”变成“给模型配工具”2.1 先搞清楚它解决的是什么问题很多人一开始接触 agent-skills 都会有个疑问这不就是 function calling 换个名字吗其实不完全一样。function calling 解决的是“模型如何调用一个函数”而 agent-skills 解决的是“模型如何组织一系列函数来完成目标”。区别看起来不大但实际设计逻辑完全不同。举一个我刚做模拟项目X时的例子。项目需求是让 Agent 自动整理客户反馈按紧急程度分类并生成处理建议。如果只做 function calling我需要定义几个函数读取反馈、情绪分析、生成标签、生成报告。模型确实能调用这些函数但每次调用什么、按什么顺序调用、结果怎么衔接全部要靠提示词写死。用户换一个提问方式提示词就崩了整个流程就得重写。引入技能系统的思路之后我把“整理客户反馈”定义成一个高层级技能这个技能内部又包含三个子技能先执行“读取反馈”再执行“情绪与主题分析”最后执行“报告生成”。模型只需要明白“整理客户反馈”这个技能适合当前场景然后触发它。至于内部怎么编排是由技能系统自己的逻辑控制的模型不用关注。这个案例特别能说明 agent-skills 的价值它把智能体的能力从“单点函数”升级成了“业务流程单元”让模型可以在更高的抽象层级上理解任务同时让开发者可以把复杂的业务逻辑收敛在技能内部。2.2 技能系统的三层结构我用过一个虽然简单但扩展性很好的三层结构这里直接贴出来给大家参考。第一层是描述层。每个技能需要一份机器可读、人也读得懂的说明文档包含技能名称、用途、适用场景、参数定义、返回值说明。这一层是给模型看的也是整个系统能不能跑起来的关键。模型要靠这份说明来决定“什么时候用这个技能”和“怎么调用这个技能”。第二层是执行层。这是技能的实际代码逻辑负责真正干活。执行层内部可以调用外部 API、读写数据库、操作文件系统、调用其他技能。这一层是给开发者写的追求的是代码清晰、逻辑健壮、方便测试。第三层是调度层。它负责管理一个技能内部的所有子步骤决定执行的先后顺序、分支条件和异常处理策略。简单技能可以没有这一层技能本身就是一步到位复杂技能一定要有否则所有逻辑都堆在一个函数里很快就变成没人敢动的大泥球。这三层结构对应到实际工程里就是一个技能通常由一个 JSON 描述文件加一个 Python 模块组成。JSON 描述文件解决“模型怎么理解这个技能”的问题Python 模块解决“这个技能怎么真正干活”的问题。职责完全分离模型侧和工程侧可以各自演进互不干扰。2.3 为什么直接交给模型或全交给代码都不对在整个设计过程中我一直在思考一个问题智能体执行任务时到底应该让模型主导还是代码主导答案是两者都要但是要画清楚边界。如果全交给模型也就是把技能逻辑全部用自然语言写在提示词里让模型自己想、自己写代码、自己执行看起来灵活性很高但实际上非常不可控。模型会漏步骤、会编造不存在的函数、会在关键时刻一本正经地做错事而且每次调用的输出还可能有随机性很难保证业务结果的稳定性。如果全交给代码就是把所有流程都硬编码用户输入什么、系统就执行什么对应的逻辑分支模型只负责在最前面做一个意图分类。这种方式确实稳定但智能体就退化成了一个传统的对话机器人失去了“自主规划”的意义遇到预设之外的情况完全没法处理。agent-skills 的价值在于提供了一条中间路线技能模块全部由代码实现保证执行的准确性和可靠性技能的选择和参数绑定由模型完成保留智能体的灵活性和适应性。用工程手段解决确定性问题用模型能力解决不确定性问题这才是这套设计最核心的哲学。3. 技能描述怎么写才能让模型不抓狂3.1 名称、描述与参数的黄金组合技能描述是整个 agent-skills 里最容易被低估的部分。很多人觉得描述写清楚了就行但实际测试下来模型对描述的敏感程度远超想象。同一个技能描述表述差异导致的选择准确率能差三成以上。我认为一份合格的技能描述必须同时包含四个核心要素。技能名称要用“动词宾语”的结构让人一眼就知道这个技能能干什么。比如用“查询库存状态”而不用“库存”用“发送审批通知”而不用“通知”。太模糊的名称会让模型在多个相似技能之间犹豫不决。技能描述要说明三个内容技能是做什么的、适合什么场景、不适合什么场景。其中“不适合什么场景”特别重要因为它能有效避免模型乱用。比如我做了一个“解析非结构化文档”的技能描述里特意加了一句“适用于 PDF、Word 等格式的正文提取不适用于图片 OCR 和手写文字识别”加了这句之后模型把图片文档误路由到文本解析技能的概率明显降低。参数定义要清晰、完整、带格式约束。类型、必填与否、取值范围、默认值都必须写明。就拿查询库存这个技能来说如果参数只定义“商品编号”模型可能会把商品名称直接传进来而参数说明里写了“商品编号系统内 8 位数字编码可在商品列表中查询”之后模型就会先去查商品列表拿编号再调用库存接口。这个差异导致的失败率是很可观的。返回格式也要写清楚。模型会根据技能返回结果决定下一步动作如果返回格式模糊模型下一轮的判断就可能出现偏差。我们会在返回值说明里写清每个字段的含义以及常见的异常返回值长什么样。3.2 描述的长度与格式控制描述不是越长越好。我在最开始写技能描述时有个坏习惯觉得信息越多模型越清楚于是把一个技能的所有细节都塞进去结果模型在选技能时经常被冗余信息干扰反而抓不住关键点。经过多轮测试我总结出一个比较稳妥的经验描述正文控制在 150 字以内参数说明每条控制在 50 字以内整体做到“看一眼就能复述”的密度。用生活里的话说写技能描述就像给新同事写交接文档重点是让对方快速知道什么情况找谁、什么情况不找谁而不是把对方的全部工作内容都写进去。格式上也要注意统一。我们用的是 YAML 格式的元数据字段名全部小写下划线避免出现大小写混用的问题。这里踩过一个坑早期技能描述里用了“APIKey”“ApiKey”“api_key”三种写法模型在生成参数值时随机挑一个结果有三分之一调用直接因为参数名不匹配失败。后来做了字段名校验规范全部统一成小写蛇形命名这个问题彻底消失。还有一个小技巧就是给技能起一个别名列表列出这个技能可能被用户提到的多种说法。比如“查询库存状态”可以起别名“库存查询”“查库存”“商品余量”模型在匹配用户意图时会先看别名匹配准确率会有肉眼可见的提升。3.3 技能的版本与兼容性声明技能是会迭代的。今天定义的参数明天可能要加字段今天返回的格式后天可能要调整结构如果这些变更没有一套管理机制线上 Agent 很容易在某个时刻突然开始报错。我在技能描述里增加了两个字段版本号与兼容性说明。版本号用来标记技能的迭代记录兼容性说明用来标注这个版本的技能能否替代旧版本。模型调用技能时系统会执行一个版本匹配逻辑优先选择与当前任务上下文兼容的技能版本避免因版本不一致导致调用失败。版本管理有一点需要注意不能频繁变动技能 ID。技能 ID 是所有描述和调用记录的锚点每次改动都用一个新 ID 会导致历史数据全部变成无用数据。正确的做法是技能 ID 唯一不变每次迭代只升级版本号同时保留旧版本入口做兼容。这样模型和系统都能稳定跟踪技能的生命周期。4. 从零写一个最小可用的 agent-skills 系统4.1 项目目录设计与初始化纸上谈兵聊了半天现在进入实战环节。我会用 Python 搭一个最小可用的技能系统演示技能的定义、注册、发现、调用这整条链路。先说明一下这套代码完全不需要依赖任何商业平台自己搭一个本地服务都能跑核心逻辑可以直接迁移到公司的业务代码里。先规划目录结构。我的习惯是按技能域组织目录每个技能一个文件夹里面放代码文件和描述文件。agent-skills-demo/ ├── skills/ │ ├── inventory/ │ │ ├── __init__.py │ │ ├── skill.py │ │ └── skill.yaml │ ├── order/ │ │ ├── __init__.py │ │ ├── skill.py │ │ └── skill.yaml │ └── report/ │ ├── __init__.py │ ├── skill.py │ └── skill.yaml ├── core/ │ ├── registry.py │ ├── executor.py │ └── model_adapter.py └── main.py为什么每个技能要单独建目录而不是把所有代码塞进一个文件原因很简单技能要能做到独立开发、独立测试、独立部署。一个技能出了问题替换掉一个目录就行不会影响其他技能。这个经验是吃了线上事故的亏总结出来的当时两个技能共用一个公共模块一个技能升级改了公共函数签名另一个技能的调用直接炸了。4.2 定义技能描述文件用一个库存查询技能来演示技能描述文件的写法。这个技能的业务逻辑很简单根据商品编码查库存数量。但把它定义成一个技能时该写的信息一点都不少。id: inventory_query name: 查询库存状态 version: 1.3 aliases: - 库存查询 - 查库存 - 商品余量 description: 根据商品编码查询指定商品在当前仓库的可用库存数量。适用于订单处理、补货决策、售后响应等场景。不适用于查询历史库存记录和库位详情。 parameters: - name: sku_code type: string required: true description: 商品编码系统内 8 位数字编码格式如 10002345 - name: warehouse_id type: string required: false description: 仓库编号默认查询全部仓库 returns: type: object description: 包含商品库存信息的结构化对象 fields: sku_code: 商品编码 total_stock: 可用库存总数 warehouse_list: 各仓库库存明细列表这份描述文件里的每一个字段都有实际用途。aliases 字段帮助模型完成用户口语化表达和标准技能名的映射parameters 里的示例格式能大幅减少模型填参时的格式错误returns 字段让模型知道调用之后能拿到什么信息这是它决定下一步动作的依据。4.3 技能执行模块的代码实现描述文件只是技能的“说明书”真正干活的是 skill.py 里的执行函数。这里有一个设计原则执行函数的入参必须和描述文件里的参数定义完全一致出参必须是一个纯 JSON 可序列化的对象。保持一致性的目的是降低模型侧的理解成本也方便做日志和监控。import json from typing import Dict, Any def execute_inventory_query(params: Dict[str, Any]) - Dict[str, Any]: sku_code params.get(sku_code) warehouse_id params.get(warehouse_id) if not sku_code: return { success: False, error_code: PARAM_MISSING, message: 缺少商品编码参数 sku_code } # 这里用模拟数据代替真实库存系统查询 mock_stock_data { 10002345: { total_stock: 120, warehouse_list: [ {warehouse_id: WH001, stock: 80}, {warehouse_id: WH002, stock: 40} ] }, 10006789: { total_stock: 15, warehouse_list: [ {warehouse_id: WH001, stock: 15} ] } } stock_info mock_stock_data.get(sku_code) if not stock_info: return { success: False, error_code: SKU_NOT_FOUND, message: f未找到商品编码 {sku_code} 对应的库存信息 } if warehouse_id and warehouse_id ! ALL: filtered_list [w for w in stock_info[warehouse_list] if w[warehouse_id] warehouse_id] if not filtered_list: return { success: False, error_code: WAREHOUSE_NOT_FOUND, message: f仓库 {warehouse_id} 不存在或未存储该商品 } stock_info { total_stock: sum(w[stock] for w in filtered_list), warehouse_list: filtered_list } result { success: True, data: { sku_code: sku_code, total_stock: stock_info[total_stock], warehouse_list: stock_info[warehouse_list] } } return json.loads(json.dumps(result, ensure_asciiFalse))执行函数里要处理几类边界情况参数缺失、数据不存在、仓库维度筛选。每个分支都返回包含 success 标志的统一结构。这么做的好处是模型拿到返回结果后只需要判断 success 是 true 还是 false不需要去解析各种各样的例外结构。4.4 技能注册中心实现技能注册中心是整个技能系统的核心枢纽所有技能都要在这里登记执行器才能找到它。我用一个轻量级的注册类来管理技能目录启动时扫描指定目录下的所有技能描述文件和代码文件自动完成加载。import importlib.util import os import yaml from typing import Dict, List class SkillRegistry: def __init__(self, skills_root: str ./skills): self.skills_root skills_root self.skills: Dict[str, Dict] {} self._load_all_skills() def _load_all_skills(self): for skill_name in os.listdir(self.skills_root): skill_dir os.path.join(self.skills_root, skill_name) if not os.path.isdir(skill_dir): continue yaml_path os.path.join(skill_dir, skill.yaml) py_path os.path.join(skill_dir, skill.py) if not (os.path.exists(yaml_path) and os.path.exists(py_path)): continue with open(yaml_path, r, encodingutf-8) as f: meta yaml.safe_load(f) spec importlib.util.spec_from_file_location( f{skill_name}.skill, py_path ) module importlib.util.module_from_spec(spec) spec.loader.exec_module(module) execute_func getattr(module, meta.get(execute_func, fexecute_{skill_name})) if not callable(execute_func): raise ValueError(f技能 {skill_name} 缺少可调用的执行函数) self.skills[skill_name] { id: meta[id], meta: meta, execute: execute_func } def list_skills(self) - List[Dict]: return [v[meta] for v in self.skills.values()] def get_skill(self, skill_id: str) - Dict: for skill in self.skills.values(): if skill[id] skill_id: return skill return None注册中心的扫描逻辑不复杂但有一个关键点值得注意技能元数据和执行模块之间的绑定关系不能靠函数名强行猜必须在 YAML 文件里显式指定。我的做法是每个技能都声明 execute_func 字段指向这个技能对应的执行函数名。这样做的好处是函数命名可以灵活调整不必为了迁就扫描逻辑而强行统一命名。4.5 模型适配器将技能描述提供给模型现在到了整个链路中与模型打交道最关键的一环。模型适配器的职责是把注册中心里的技能描述转换成模型能理解的格式同时把模型的输出解析成结构化的调用请求。以我经常使用的 JSON 输出模式为例适配器会把技能描述统一转换成如下结构再交给模型去选择。class ModelAdapter: def __init__(self, registry: SkillRegistry): self.registry registry def build_tool_schema(self) - List[Dict]: schema [] for skill in self.registry.skills.values(): skill_meta skill[meta] properties {} required [] for param in skill_meta.get(parameters, []): properties[param[name]] { type: param.get(type, string), description: param.get(description, ) } if param.get(required): required.append(param[name]) schema.append({ type: function, function: { name: skill[id], description: skill_meta.get(description, ), parameters: { type: object, properties: properties, required: required } } }) return schema def parse_model_response(self, model_output: Dict) - Dict: tool_call model_output.get(tool_calls, [])[0] function_name tool_call[function][name] arguments_str tool_call[function][arguments] import json arguments json.loads(arguments_str) return { skill_id: function_name, params: arguments }这个适配器必须注意和调用方之间的协议一致性。模型返回的 arguments 本质上是一段 JSON 字符串解析时一定要做异常捕获因为模型偶尔会生成不合法 JSON。我在解析函数里加了一层兜底如果原生 JSON 解析失败就尝试正则提取 key-value 对虽然这种方式不够优雅但在实际业务中确实能救回一部分调用。4.6 主流程串起来跑一遍主程序把注册中心、模型适配器和技能执行器串成一条完整的链路。为了让演示不依赖任何云服务我用规则匹配代替真实模型推理保证整个流程在本地可以直接跑通。from core.registry import SkillRegistry import json def main(): registry SkillRegistry() print( 已注册技能列表 ) for skill in registry.list_skills(): print(f - {skill[name]} ({skill[id]}) 版本 {skill[version]}) # 模拟用户的自然语言输入 user_input 帮我查一下商品 10002345 在 WH001 仓库还有多少库存 # 模拟模型推理选择技能并生成参数 # 实际工程中这里会调用大模型通过 ModelAdapter.build_tool_schema() 传入上下文 selected_skill registry.get_skill(inventory_query) if not selected_skill: print(无法找到匹配的技能) return simulated_model_params { sku_code: 10002345, warehouse_id: WH001 } print( 技能调用结果 ) result selected_skill[execute](simulated_model_params) print(json.dumps(result, ensure_asciiFalse, indent2)) if __name__ __main__: main()这套最小系统跑通之后你就拥有了一个完整的技能系统骨架目录里添加新技能、注册中心加载技能、模型按需选择技能、执行器执行业务逻辑。后面要做的事情无非是往上面加更多复杂技能以及把规则匹配替换成真实大模型调用。5. 复杂技能如何编排子技能、并行与异常恢复5.1 子技能调用与嵌套真实业务场景里很少有技能是单一步骤完成的。一个“生成库存预警报告”的技能至少需要完成查询库存、筛选低于阈值的商品、计算补货建议、生成报告文本这四步。如果把四步逻辑全部写在一个函数里代码会变得非常臃肿而且每一步的结果都很难单独复用。所以复杂技能需要支持子技能调用。实现方式很简单执行函数内部可以直接调用注册中心里其他技能的 execute 方法。比如报告生成技能内部会先调库存查询技能拿到数据再调商品信息技能拿到商品名称最后汇总生成报告。这里有一个重要的工程经验子技能之间的数据格式必须做转换层或者所有技能统一使用一种数据传递协议。我踩过一次坑库存查询技能返回的仓库编码是“WH001”这种格式商品信息技能要求的仓库编码是“wh_001”这种格式两者不一致导致报告生成技能在拼接数据时频繁出错。后来定了一个规矩所有技能之间的引用字段格式必须全局统一有差异就在边界处做转换。5.2 并行技能的执行策略有些技能是可以并行执行的。比如分析客户反馈时要同时调用情绪分析、主题分类、敏感词检测三个技能它们之间没有依赖关系串行执行会浪费大量时间。最简单的并行实现方式是利用 Python 的线程池。因为技能执行以 IO 操作为主线程池带来的性能提升非常明显。但并行执行一个需要注意的坑是线程安全问题。如果多个技能同时访问同一个共享状态必须加锁或者使用线程局部存储否则会出现数据错乱。拿客户反馈分析的例子来说情绪分析技能和主题分类技能都要读取原始反馈文本如果并行读取同一个数据源会有冲突风险。我的做法是在编排层先把反馈文本复制到独立的消息结构中每个并行任务持有自己的副本互不干扰。这个小小的改动让并行执行变得稳定很多。5.3 异常恢复机制让技能链路更坚韧技能执行过程中一定会遇到各种异常接口超时、数据格式不对、依赖服务不可用。一套健壮的技能系统必须具备异常恢复能力否则一个子技能失败可能导致整个任务链崩掉。我给每个技能补充了重试与降级策略。重试策略很简单针对外部接口调用增加次数限制和指数退避默认重试 3 次间隔分别是 1 秒、2 秒、4 秒。降级策略稍微复杂点当某个非关键子技能失败时可以记录失败原因后跳过它用默认值填充结果保证上层技能还能继续执行。日常场景里比较实用的是“部分成功”模式。比如生成批量商品报告10 个商品中有 2 个商品信息接口返回失败系统会把另外 8 个正常生成失败的 2 个标记在报告末尾的异常清单里而不是直接让整个报告生成失败。用户拿到的结果虽然是部分缺失的但核心价值已经交付了。5.4 技能链路的可视化跟踪技能编排还有一个常常被忽视的问题出了问题怎么排查技能调用是嵌套的、平行的如果没有完整的调用链路记录出问题之后只能靠猜。我建议在编排层增加一个简单的链路追踪机制每个任务分配一个 trace_id每层技能调用都记录自己的 trace_id、父技能、执行时间、入参、出参、异常信息。排查问题时根据 trace_id 就能还原整条调用链最快定位到具体是哪个技能、哪一步出了问题。这套机制在单机场景下用内存日志就能实现但到了分布式场景必须引入统一日志服务。关键不是工具而是意识技能系统是一个复杂的分布式计算系统没有追踪机制等于盲人摸象。6. 我踩过的坑典型问题与排查方法6.1 模型总是选错技能这是我在接入 agent-skills 之后遇到的第一个大问题。明明定义了库存查询和订单查询两个技能用户问“订单里显示的东西还有货吗”模型经常只调用订单查询不关心库存那部分。排查后发现问题的根源在技能描述我的库存查询技能描述里只写了“根据商品编码查询库存”完全没有提及“可以用于订单商品的可售状态确认”。而订单查询的描述里反而提到了“包含商品信息”模型自然认为订单查询更合适。修复方式是在库存查询技能的描述中增加一个适用场景提示“适用于查询某商品是否可售、是否有货也适用于订单履约前的库存确认”。描述改完之后模型在这类问题上的选择准确率明显提升。这也再次印证了一个观点技能系统的效果很大程度上取决于描述工程模型本身不笨是我们没把话说清楚。6.2 模型生成的参数总是格式不对第二个高频问题是参数格式。技能要求 sku_code 是一个 8 位数字编码模型经常会传一个包含商品名的字符串比如“10002345 的 iPhone 手机壳”。这种问题在早期几乎每轮对话都会出现。我做了两件事来解决。第一是在参数描述里强制增加格式示例明确写出正确的格式和错误的格式。第二是在执行器里增加参数校验层发现格式不对时主动返回“参数格式错误”的提示并回传正确格式示例让模型有机会在下一次调用时修正自己。同时要求模型侧增加内容提示用户需要提供正确的编码。参数校验层的实现是一个很有价值的取舍与其依赖大模型一次生成正确参数不如在进入执行层之前用代码硬校验一次。把确定性的事情交给代码把不确定性的事情留给模型这条原则再次得到验证。6.3 实时性要求高的技能出现超时堆积库存查询这类技能接口响应时间一般在几百毫秒但如果外部库存系统出现波动个别调用会拖到几秒钟。技能超时之后模型可能重试重试又叠加新的超时请求结果整个任务被拖垮。我的排查思路是先看锁再看连接池最后看队列。真实场景里最常出现的情况是连接池被打满大量请求等待空闲连接。优化手段有三条一是给外部调用增加明确的超时时间默认 3 秒必须返回二是连接池大小根据并发量动态调整三是技能编排层增加并发限制信号量超过阈值直接快速失败并提示用户稍后再试。加了这三道防线之后技能调用的稳定性明显好转。面对外部系统的不可控我们能做到的并不是让每次调用都成功而是让失败变得快速、可控、可预期。6.4 技能迭代导致老任务回放出错这个坑是在上线一段时间后遇到的。库存查询技能从 1.2 升级到了 1.3返回值里增加了一个字段但有一个历史任务缓存了旧版本的返回结构执行到后续处理时因为取不到新字段直接报错。解决方式是在执行器里记录每个任务实际使用的技能版本老任务继续用老版本的执行函数新任务使用新版本。不能用全量替换的思维来做技能升级而是用灰度、兼容的思路。技能升级本质上是数据协议变更必须像对待数据库迁移一样对待它把兼容性的考量放在首位。现在我的技能系统里每个版本都会保留至少一个迭代周期的兼容时长升级后观察日志确认没有异常再逐步清理旧版本。7. 我的一点实操体会整个 agent-skills 系统从搭骨架到落地稳定我最大的体会是这个方向真正的难点不在于代码逻辑而在于“能力的边界设计”。你给 Agent 配了哪些技能每个技能的边界在哪里描述写得清不清楚参数定义巩不巩固这四件事决定了智能体的表现上限。模型本身的能力反而是一块基础底板底板再强技能设计得一塌糊涂跑起来还是一团糟。我建议刚接触 agent-skills 的开发者可以先拿一个真实业务里的高频场景练手把它拆成两三个技能按本文的方法从描述文件写起跑通链路之后再慢慢叠加复杂度。不要在初期就追求技能数量而是要优先打磨技能质量。我这里定义的“质量”非常务实描述准确、参数稳定、异常可恢复、调用可追踪。最后分享一个实用的小技巧每次迭代技能描述文件之后收集一批真实用户的提问样本做回放测试看模型在相同提问下能不能稳定选中正确技能。我团队现在每次改技能描述都要过一遍回归测试一旦发现某个场景下的技能选择准确率掉了马上回滚。这个方法成本很低但能持续守护技能系统的健康度算是整个方案里性价比最高的一项投入。