最近几周我所在的几个技术社群里“agent-skills”这个关键词几乎每天都在刷屏。大家不再满足于用Agent聊天、做简单的问答而是想让Agent真正“上手干活”——查数据库、发消息、调用内部API、操作浏览器。方向没错但真把手头一个带有几十个自定义技能的Agent从Demo推到准生产环境时才发现技能定义、装载调度、冲突处理这些环节处处都是坑。这篇就围绕agent-skills展开把我踩过的、拆解过的、实测有效的东西一次性讲透。先说清楚背景我负责的项目是一个企业内部的知识助手底层接的是大语言模型外层套了一套技能注册与路由机制。所谓“技能”本质上是把模型能力与外部动作解耦的一种中间层设计——模型负责理解用户意图技能负责执行具体动作。这个东西要说新其实不算新Tool Use和Function Calling早就有了但“agent-skills”这套提法把技能从“一次性函数调用”升级成了“可持久化、可路由、可评估的能力单元”这种工程思路的变化才是值得花篇幅写透的地方。1. 为什么“Agent Skills”突然成了高频词1.1 Agent技能的爆发背景先说一个反直觉的现象很多团队在把Agent接入真实业务时最先卡住的不是模型推理能力而是“模型什么都懂但什么都碰不到”。一个裸模型能写出一段完美的SQL但它连不上你的数据库能告诉你应该给客户回什么话术但它发不出那条消息。要让Agent从“建议者”变成“执行者”必须给它接上可操作的“手和脚”。这套手脚在业界有过几个叫法Function Calling、Tool Use、Plugin现在则是Skills。“Skills”之所以被单独拎出来当一个体系是因为前几种方案在真实业务里暴露了几个共同弱点函数声明分散在各处没有统一的注册和发现机制模型对着几十个函数描述时选择准确率会明显下降但没人给这个过程买单技能的输入输出缺乏结构化管理上线后无法度量好坏。企业一旦想把Agent真正嵌入业务流程这些弱点就会被无限放大。于是agent-skills的工程化就被摆上台面把每个技能当作一等公民有描述、有入参、有验收标准、有版本记录。1.2 “技能”与“工具调用”到底差在哪我做了一次简单对比帮助团队统一认知。这张表不一定绝对严谨但对于实际选型和设计边界很有参考价值对比维度传统Function CallingAgent Skills生命周期随对话上下文一次性传递独立存储按需装配注册方式每次请求全部塞给模型先检索、再注入数量上限通常十几个就明显劣化支持几十甚至上百靠路由控制验证方式手工调用、看返回有输入schema、有评估集复用性绑定单一Agent实例跨Agent、跨场景复用迭代方式改代码、发版技能包版本化管理可单独更新这个对比的价值在于如果你的场景只需要两三个工具那用传统函数调用完全没毛病但如果你和我一样面对二三十个以上技能且技能直接对接线上业务动作那“技能独立成体系”就不是锦上添花而是刚需。2. 技能设计从“会回答”到“能做事”的关键一跃2.1 技能定义包含哪几个必备元素一个能被Agent稳定调用的技能仅仅写一个Python函数是不够的。设计阶段就要考虑模型“怎么看懂这个技能、怎么决定调用它、传什么参数”。我建议至少包含四个板块技能标识与语义描述name / description描述要写清“什么时候用、主要解决什么问题、不要和某个相邻技能混淆”。输入Schema入参定义用JSON Schema严格声明每个字段的类型、枚举值、必填项、默认值。执行逻辑execution function真正干活的代码入参校验、异常捕获、超时控制都不能少。输出与反馈格式output contract推荐统一兜底结构包括success、data、error_time_ms等便于外层观测。我在项目里把技能模板做成了这样的Python数据类from dataclasses import dataclass, field from typing import Any, Callable, Dict, List, Optional dataclass class Skill: name: str # 技能唯一标识 description: str # 给模型看的语义描述 input_schema: Dict[str, Any] # JSON Schema 格式 execute: Callable # 实际执行函数 tags: List[str] field(default_factorylist) timeout_seconds: int 10 version: str 0.1.0 enabled: bool True这套结构看起来朴素但实际跑起来会省掉大量麻烦。尤其是input_schema它直接决定了模型能不能给出正确的参数。2.2 一次完整的技能调用链路是什么样的我画不画流程图用文字给你拆一遍。假设用户问“帮我查一下华东区的销售数据按月份汇总。”这条请求在技能系统里会经过四层第一层意图识别。结合对话历史判断用户是不是“想查数”而不是“想问口径”。这层可以靠模型本身也可以叠一层分类模型做兜底。第二层技能召回。用向量相似度或规则标签从技能库中召回跟“销售数据查询”“区域筛选”相关的候选技能。这一步在多技能场景尤其重要不要让模型面对几十个技能做全量选择。第三层参数抽取。模型根据候选技能的输入Schema把“华东区”映射成regioneast把“按月份”映射成granularitymonth。这里如果Schema写得含糊模型会给出五花八门的字段名。第四层执行与反馈。调用已注册的执行函数返回结构化结果再由模型组织语言回复用户。执行失败时错误信息要回传给模型让它来决定是换参数重试还是明确告知用户失败原因。这四层里最容易被低估的是第四层的“错误回传”。很多新手会在执行层直接抛异常导致整个Agent崩掉更好的做法是把异常捕获后包装成一条可读的错误文本交给模型让它有“补救”的空间。2.3 技能描述怎么写才不会被模型“读歪”这一步是我的踩坑重灾区。最早的版本我把技能描述写得非常口语化“根据用户提供的区域信息获取相应的销售数据。”结果模型在用户没提区域时也会自作聪明地填上一个默认区域因为描述里没有强调“区域必须来自用户原话缺失时不得猜测”。后来我总结了一套写技能描述的经验核心是“负面约束必须写在正面描述之后”先说明该技能能干什么适用的业务对象、预期的输入、返回的数据形态再说清边界哪些情况不该调用本技能、哪些参数缺失时必须拒绝执行最后给一个典型示例比如“输入区域east粒度month返回该区域各月销售额明细”。这些细节看似是给模型写的其实是给整个系统的稳定性上保险。模型非常擅长“脑补”而技能描述就是你唯一能约束它不乱来的地方。3. 技能装载与调度多技能并存时的工程细节3.1 Skill Registry把“技能库”当作基础设施来设计技能数量少的时候用几个if-else就能调起来但技能一旦到了几十个的量级就必须要有一个独立的技能注册中心Skill Registry来统一管理。它至少做三件事登记与发现维护所有可用技能的名称、版本、启停状态校验与热更新新技能注册时做Schema合法性校验更新技能包时做到不影响正在运行的调用权限控制内部技能按业务线分权比如财务技能只有财务域Agent可以装配。我在实际项目里采用的是“目录式注册”加“配置驱动装载”的方式没有引入重量级中间件一个带版本管理的目录结构就够了skills/ finance/ v1/ skill_sales_summary.json execute.py v2/ skill_sales_summary.json execute.py hr/ v1/ skill_attendance_query.json execute.py每个技能目录下JSON描述文件负责“让模型看懂”execute.py负责“让机器执行”。装载时系统扫描目录统一挂载到Registry里并通过版本号控制灰度范围。这个设计最大的好处是新技能上线不需要重新发版整个Agent改一个配置项就能让某个技能生效或摘除。3.2 技能路由不是让模型“大海捞针”技能多了以后第二个问题是“模型该选谁”。我记得第一次把30个技能一次性全塞给模型时效果惨不忍睹模型在选择技能上频繁出错甚至出现该调用A技能却调用了B技能的情况。后来把“全量函数列表”改成“两阶段召回”效果立刻改善了一个档次。两阶段召回的具体做法是第一阶段离线或在线给每个技能打上标签、生成向量索引。用户请求进入时先用轻量级检索比如向量相似度加关键词规则从几十个技能里筛出5到8个候选第二阶段把这些候选技能的描述与Schema注入给模型让模型做精排和参数抽取。这样做还有一个附带收益单次请求的Token开销明显下降。技能描述动辄一两百个token全量注入和候选注入的差距在高峰期是实打实的成本。3.3 并行调用与资源管理多技能协同的体验优化真实场景里一次用户请求往往需要多个技能协作。比如“帮我查一下销售数据并生成摘要发给李总”至少涉及三个技能数据查询、文本摘要、消息发送。串行执行当然能完成但体验很慢。我建议在有序依赖不冲突的前提下把可并行步骤抽出来。对于工程实现我最常用的是Python的asyncio加asyncio.wait_for超时控制。每个技能调用都设置独立的超时时间避免某个外部API挂死拖垮整个Agent。import asyncio async def run_skill_with_timeout(skill, kwargs, timeout10): try: return await asyncio.wait_for(skill.execute(**kwargs), timeouttimeout) except asyncio.TimeoutError: return {success: False, error: skill_timeout, message: f{skill.name} 执行超时}超时控制是必须的否则线上Agent会被上游接口的偶发抖动打得毫无还手之力。4. 踩坑实录技能数量超过20个之后出现的连锁问题4.1 完整排查链路为什么Agent突然“装瞎”了有一次版本上线后运营反馈说Agent开始答非所问明明触发了“查天气”的意图却回答了一堆运营活动规则。我们当时第一反应是模型对话能力退化了换了更强的模型后问题依旧于是把怀疑对象转向了技能系统。完整排查链路大概是这样的第一步看召回结果。把单次请求的调用日志拉出来发现“查天气”这个技能压根没进入候选列表因为技能库更新后天气技能对应的向量索引没重建新版本被检索器遗忘了。这一步非常隐蔽因为Agent没有报错只是“表现笨了”。第二步看注入内容。检索结果没问题之后再看注入给模型的候选技能发现用户请求里带有“天气”二字但候选技能里有一条“气象数据分析”的技能描述里包含大量天气相关词汇模型被这个描述干扰选择了它而不是精确匹配的“城市天气查询”。第三步看模型输出。再次修改技能描述把“气象数据分析”明确加上“仅限气象平台内部数据不要用于城市天气预报”的约束后选择准确率恢复正常。4.2 根因复盘Why it happened这次故障的根因可以拆成三个层面召回层的索引失效技能包更新时没有触发向量索引自动重建路由层的描述歧义两个技能在语义上有重叠模型无法从描述上分辨边界治理层的监控缺位选择准确率没有做每日监控导致异常持续了一天才被发现。只说“加监控”太笼统我实际做了三件事给技能召回率加可视化看板、给每个技能的调用次数与成功率建立基线、在技能描述变更时强制走一次人工审核。不是多高大上的方案但足够把同类问题提前暴露。4.3 稳定性优先的工程降级方案通过踩坑我认为在技能系统设计时要有“降级意识”。所谓降级不是功能缩水而是让Agent在面对自己不擅长的场景时选择性地使用技能。置信度阈值如果模型对技能选择的置信度低于阈值宁可回复“我目前无法准确处理这个请求”也不要强行调用一个不相关的技能人工兜底通道当技能执行连续两次失败时把工单转入人工队列而不是让Agent无限重试技能熔断单个技能连续失败达到一定次数后自动摘除防止它不断干扰Agent行为。这套降级机制让我们的系统在外部依赖不稳定的情况下依然能保持可用状态。对用户来说最烦的不是Agent说“做不了”而是它反反复复做了错的事。5. 可以立刻上手的技能评估与迭代方法5.1 技能质量怎么量化五个维度写完技能不是终点技能也需要“被管理”。我给团队成员推荐了一套五维评分卡每条技能上线前和每次迭代后都打分评估维度说明参考阈值召回命中率该技能在应被召回的场景中被正确召回的比例≥90%选择准确率模型在候选技能里选它的正确比例≥95%参数抽取成功率入参能被模型按Schema正确填充的比例≥90%执行成功率技能调用返回成功不考虑业务语义的比例≥99%业务达成率用户对执行结果满意或结果符合预期的比例≥85%这个评分卡最重要的作用是让“技能好不好”从感觉变成了数据。比如上一版天气技能的选择准确率只有83%经过描述优化后升到96%这就是一次标准迭代。5.2 回归测试技能迭代不能“拍脑袋”技能迭代最怕的就是“修好一个问题拆坏三个功能”。为此我建议给每条技能准备一组迷你回归集每次更新后自动跑一遍。一个最简单的回归集可以长这样{ skill_name: sales_summary, cases: [ { id: case_001, user_utterance: 帮我汇总上季度各区域的销售额, expected_invoke: true, expected_params: {granularity: quarter, group_by: region} }, { id: case_002, user_utterance: 今天天气怎么样, expected_invoke: false, expected_params: {} } ] }维护这样的回归集确实要花时间但收益非常直接任何一次技能的Schema调整或描述修改都能立刻知道影响了哪些场景。我的看法是技能越多的团队越应该建这套东西否则版本一多回归全靠人肉试错迟早会出线上事故。5.3 技能打包与分发一套可复用的发布流程最后一个想法是关于技能怎么“分发”。好的技能设计应该是可以被复用的而不是被锁死在单个Agent里。我目前的做法是每个技能目录就是一个独立技能包包含描述文件、执行脚本、回归用例、变更记录。通过自动化脚本打包上传到内部制品库Agent启动时可以按需拉取指定版本的技能包。这样一个团队的技能可以低成本共享给另一个团队不用把一个Agent整体迁移过去。“把每个技能当作产品来运营”这是我在agent-skills实践里最想分享的一句话。技能不是写个函数就完事它需要描述、验证、评估、复盘、迭代把这一整套闭环跑起来之后Agent的能力才能从“玩具级”走到“生产力级”。这一套链路里还有太多可以优化的细节但先把基础框架搭牢后面的事情会顺很多。 Agent技能工程化实践：从函数调用到可评估、可路由的Skills体系
最近几周我所在的几个技术社群里“agent-skills”这个关键词几乎每天都在刷屏。大家不再满足于用Agent聊天、做简单的问答而是想让Agent真正“上手干活”——查数据库、发消息、调用内部API、操作浏览器。方向没错但真把手头一个带有几十个自定义技能的Agent从Demo推到准生产环境时才发现技能定义、装载调度、冲突处理这些环节处处都是坑。这篇就围绕agent-skills展开把我踩过的、拆解过的、实测有效的东西一次性讲透。先说清楚背景我负责的项目是一个企业内部的知识助手底层接的是大语言模型外层套了一套技能注册与路由机制。所谓“技能”本质上是把模型能力与外部动作解耦的一种中间层设计——模型负责理解用户意图技能负责执行具体动作。这个东西要说新其实不算新Tool Use和Function Calling早就有了但“agent-skills”这套提法把技能从“一次性函数调用”升级成了“可持久化、可路由、可评估的能力单元”这种工程思路的变化才是值得花篇幅写透的地方。1. 为什么“Agent Skills”突然成了高频词1.1 Agent技能的爆发背景先说一个反直觉的现象很多团队在把Agent接入真实业务时最先卡住的不是模型推理能力而是“模型什么都懂但什么都碰不到”。一个裸模型能写出一段完美的SQL但它连不上你的数据库能告诉你应该给客户回什么话术但它发不出那条消息。要让Agent从“建议者”变成“执行者”必须给它接上可操作的“手和脚”。这套手脚在业界有过几个叫法Function Calling、Tool Use、Plugin现在则是Skills。“Skills”之所以被单独拎出来当一个体系是因为前几种方案在真实业务里暴露了几个共同弱点函数声明分散在各处没有统一的注册和发现机制模型对着几十个函数描述时选择准确率会明显下降但没人给这个过程买单技能的输入输出缺乏结构化管理上线后无法度量好坏。企业一旦想把Agent真正嵌入业务流程这些弱点就会被无限放大。于是agent-skills的工程化就被摆上台面把每个技能当作一等公民有描述、有入参、有验收标准、有版本记录。1.2 “技能”与“工具调用”到底差在哪我做了一次简单对比帮助团队统一认知。这张表不一定绝对严谨但对于实际选型和设计边界很有参考价值对比维度传统Function CallingAgent Skills生命周期随对话上下文一次性传递独立存储按需装配注册方式每次请求全部塞给模型先检索、再注入数量上限通常十几个就明显劣化支持几十甚至上百靠路由控制验证方式手工调用、看返回有输入schema、有评估集复用性绑定单一Agent实例跨Agent、跨场景复用迭代方式改代码、发版技能包版本化管理可单独更新这个对比的价值在于如果你的场景只需要两三个工具那用传统函数调用完全没毛病但如果你和我一样面对二三十个以上技能且技能直接对接线上业务动作那“技能独立成体系”就不是锦上添花而是刚需。2. 技能设计从“会回答”到“能做事”的关键一跃2.1 技能定义包含哪几个必备元素一个能被Agent稳定调用的技能仅仅写一个Python函数是不够的。设计阶段就要考虑模型“怎么看懂这个技能、怎么决定调用它、传什么参数”。我建议至少包含四个板块技能标识与语义描述name / description描述要写清“什么时候用、主要解决什么问题、不要和某个相邻技能混淆”。输入Schema入参定义用JSON Schema严格声明每个字段的类型、枚举值、必填项、默认值。执行逻辑execution function真正干活的代码入参校验、异常捕获、超时控制都不能少。输出与反馈格式output contract推荐统一兜底结构包括success、data、error_time_ms等便于外层观测。我在项目里把技能模板做成了这样的Python数据类from dataclasses import dataclass, field from typing import Any, Callable, Dict, List, Optional dataclass class Skill: name: str # 技能唯一标识 description: str # 给模型看的语义描述 input_schema: Dict[str, Any] # JSON Schema 格式 execute: Callable # 实际执行函数 tags: List[str] field(default_factorylist) timeout_seconds: int 10 version: str 0.1.0 enabled: bool True这套结构看起来朴素但实际跑起来会省掉大量麻烦。尤其是input_schema它直接决定了模型能不能给出正确的参数。2.2 一次完整的技能调用链路是什么样的我画不画流程图用文字给你拆一遍。假设用户问“帮我查一下华东区的销售数据按月份汇总。”这条请求在技能系统里会经过四层第一层意图识别。结合对话历史判断用户是不是“想查数”而不是“想问口径”。这层可以靠模型本身也可以叠一层分类模型做兜底。第二层技能召回。用向量相似度或规则标签从技能库中召回跟“销售数据查询”“区域筛选”相关的候选技能。这一步在多技能场景尤其重要不要让模型面对几十个技能做全量选择。第三层参数抽取。模型根据候选技能的输入Schema把“华东区”映射成regioneast把“按月份”映射成granularitymonth。这里如果Schema写得含糊模型会给出五花八门的字段名。第四层执行与反馈。调用已注册的执行函数返回结构化结果再由模型组织语言回复用户。执行失败时错误信息要回传给模型让它来决定是换参数重试还是明确告知用户失败原因。这四层里最容易被低估的是第四层的“错误回传”。很多新手会在执行层直接抛异常导致整个Agent崩掉更好的做法是把异常捕获后包装成一条可读的错误文本交给模型让它有“补救”的空间。2.3 技能描述怎么写才不会被模型“读歪”这一步是我的踩坑重灾区。最早的版本我把技能描述写得非常口语化“根据用户提供的区域信息获取相应的销售数据。”结果模型在用户没提区域时也会自作聪明地填上一个默认区域因为描述里没有强调“区域必须来自用户原话缺失时不得猜测”。后来我总结了一套写技能描述的经验核心是“负面约束必须写在正面描述之后”先说明该技能能干什么适用的业务对象、预期的输入、返回的数据形态再说清边界哪些情况不该调用本技能、哪些参数缺失时必须拒绝执行最后给一个典型示例比如“输入区域east粒度month返回该区域各月销售额明细”。这些细节看似是给模型写的其实是给整个系统的稳定性上保险。模型非常擅长“脑补”而技能描述就是你唯一能约束它不乱来的地方。3. 技能装载与调度多技能并存时的工程细节3.1 Skill Registry把“技能库”当作基础设施来设计技能数量少的时候用几个if-else就能调起来但技能一旦到了几十个的量级就必须要有一个独立的技能注册中心Skill Registry来统一管理。它至少做三件事登记与发现维护所有可用技能的名称、版本、启停状态校验与热更新新技能注册时做Schema合法性校验更新技能包时做到不影响正在运行的调用权限控制内部技能按业务线分权比如财务技能只有财务域Agent可以装配。我在实际项目里采用的是“目录式注册”加“配置驱动装载”的方式没有引入重量级中间件一个带版本管理的目录结构就够了skills/ finance/ v1/ skill_sales_summary.json execute.py v2/ skill_sales_summary.json execute.py hr/ v1/ skill_attendance_query.json execute.py每个技能目录下JSON描述文件负责“让模型看懂”execute.py负责“让机器执行”。装载时系统扫描目录统一挂载到Registry里并通过版本号控制灰度范围。这个设计最大的好处是新技能上线不需要重新发版整个Agent改一个配置项就能让某个技能生效或摘除。3.2 技能路由不是让模型“大海捞针”技能多了以后第二个问题是“模型该选谁”。我记得第一次把30个技能一次性全塞给模型时效果惨不忍睹模型在选择技能上频繁出错甚至出现该调用A技能却调用了B技能的情况。后来把“全量函数列表”改成“两阶段召回”效果立刻改善了一个档次。两阶段召回的具体做法是第一阶段离线或在线给每个技能打上标签、生成向量索引。用户请求进入时先用轻量级检索比如向量相似度加关键词规则从几十个技能里筛出5到8个候选第二阶段把这些候选技能的描述与Schema注入给模型让模型做精排和参数抽取。这样做还有一个附带收益单次请求的Token开销明显下降。技能描述动辄一两百个token全量注入和候选注入的差距在高峰期是实打实的成本。3.3 并行调用与资源管理多技能协同的体验优化真实场景里一次用户请求往往需要多个技能协作。比如“帮我查一下销售数据并生成摘要发给李总”至少涉及三个技能数据查询、文本摘要、消息发送。串行执行当然能完成但体验很慢。我建议在有序依赖不冲突的前提下把可并行步骤抽出来。对于工程实现我最常用的是Python的asyncio加asyncio.wait_for超时控制。每个技能调用都设置独立的超时时间避免某个外部API挂死拖垮整个Agent。import asyncio async def run_skill_with_timeout(skill, kwargs, timeout10): try: return await asyncio.wait_for(skill.execute(**kwargs), timeouttimeout) except asyncio.TimeoutError: return {success: False, error: skill_timeout, message: f{skill.name} 执行超时}超时控制是必须的否则线上Agent会被上游接口的偶发抖动打得毫无还手之力。4. 踩坑实录技能数量超过20个之后出现的连锁问题4.1 完整排查链路为什么Agent突然“装瞎”了有一次版本上线后运营反馈说Agent开始答非所问明明触发了“查天气”的意图却回答了一堆运营活动规则。我们当时第一反应是模型对话能力退化了换了更强的模型后问题依旧于是把怀疑对象转向了技能系统。完整排查链路大概是这样的第一步看召回结果。把单次请求的调用日志拉出来发现“查天气”这个技能压根没进入候选列表因为技能库更新后天气技能对应的向量索引没重建新版本被检索器遗忘了。这一步非常隐蔽因为Agent没有报错只是“表现笨了”。第二步看注入内容。检索结果没问题之后再看注入给模型的候选技能发现用户请求里带有“天气”二字但候选技能里有一条“气象数据分析”的技能描述里包含大量天气相关词汇模型被这个描述干扰选择了它而不是精确匹配的“城市天气查询”。第三步看模型输出。再次修改技能描述把“气象数据分析”明确加上“仅限气象平台内部数据不要用于城市天气预报”的约束后选择准确率恢复正常。4.2 根因复盘Why it happened这次故障的根因可以拆成三个层面召回层的索引失效技能包更新时没有触发向量索引自动重建路由层的描述歧义两个技能在语义上有重叠模型无法从描述上分辨边界治理层的监控缺位选择准确率没有做每日监控导致异常持续了一天才被发现。只说“加监控”太笼统我实际做了三件事给技能召回率加可视化看板、给每个技能的调用次数与成功率建立基线、在技能描述变更时强制走一次人工审核。不是多高大上的方案但足够把同类问题提前暴露。4.3 稳定性优先的工程降级方案通过踩坑我认为在技能系统设计时要有“降级意识”。所谓降级不是功能缩水而是让Agent在面对自己不擅长的场景时选择性地使用技能。置信度阈值如果模型对技能选择的置信度低于阈值宁可回复“我目前无法准确处理这个请求”也不要强行调用一个不相关的技能人工兜底通道当技能执行连续两次失败时把工单转入人工队列而不是让Agent无限重试技能熔断单个技能连续失败达到一定次数后自动摘除防止它不断干扰Agent行为。这套降级机制让我们的系统在外部依赖不稳定的情况下依然能保持可用状态。对用户来说最烦的不是Agent说“做不了”而是它反反复复做了错的事。5. 可以立刻上手的技能评估与迭代方法5.1 技能质量怎么量化五个维度写完技能不是终点技能也需要“被管理”。我给团队成员推荐了一套五维评分卡每条技能上线前和每次迭代后都打分评估维度说明参考阈值召回命中率该技能在应被召回的场景中被正确召回的比例≥90%选择准确率模型在候选技能里选它的正确比例≥95%参数抽取成功率入参能被模型按Schema正确填充的比例≥90%执行成功率技能调用返回成功不考虑业务语义的比例≥99%业务达成率用户对执行结果满意或结果符合预期的比例≥85%这个评分卡最重要的作用是让“技能好不好”从感觉变成了数据。比如上一版天气技能的选择准确率只有83%经过描述优化后升到96%这就是一次标准迭代。5.2 回归测试技能迭代不能“拍脑袋”技能迭代最怕的就是“修好一个问题拆坏三个功能”。为此我建议给每条技能准备一组迷你回归集每次更新后自动跑一遍。一个最简单的回归集可以长这样{ skill_name: sales_summary, cases: [ { id: case_001, user_utterance: 帮我汇总上季度各区域的销售额, expected_invoke: true, expected_params: {granularity: quarter, group_by: region} }, { id: case_002, user_utterance: 今天天气怎么样, expected_invoke: false, expected_params: {} } ] }维护这样的回归集确实要花时间但收益非常直接任何一次技能的Schema调整或描述修改都能立刻知道影响了哪些场景。我的看法是技能越多的团队越应该建这套东西否则版本一多回归全靠人肉试错迟早会出线上事故。5.3 技能打包与分发一套可复用的发布流程最后一个想法是关于技能怎么“分发”。好的技能设计应该是可以被复用的而不是被锁死在单个Agent里。我目前的做法是每个技能目录就是一个独立技能包包含描述文件、执行脚本、回归用例、变更记录。通过自动化脚本打包上传到内部制品库Agent启动时可以按需拉取指定版本的技能包。这样一个团队的技能可以低成本共享给另一个团队不用把一个Agent整体迁移过去。“把每个技能当作产品来运营”这是我在agent-skills实践里最想分享的一句话。技能不是写个函数就完事它需要描述、验证、评估、复盘、迭代把这一整套闭环跑起来之后Agent的能力才能从“玩具级”走到“生产力级”。这一套链路里还有太多可以优化的细节但先把基础框架搭牢后面的事情会顺很多。