有些项目就是这样标题短到只有一个词但背后藏着的工程量能把人吓一跳。拿到“agent-skills”这个题目时我第一反应是这是在做Agent的技能库。再一琢磨技能库这玩意好坏之间差距能有多大往小了说决定你的Agent能不能在复杂任务中按步骤稳定执行往大了说它直接决定整套智能体方案是能落地还是永远停在PPT演示。这篇文章我想完整拆一遍我搭Agent技能库时的设计思路、踩坑记录和最终落地的细节给正在做同类项目的朋友一个能直接参照的实操模板。先说清楚这项目到底在解决什么场景你已经跑通了大模型对话甚至接上了工具调用但每次要求Agent干一件稍微复杂的事比如“查一下这几个接口的返回把异常数据拉出来汇总成表格”它的表现就开始飘。选错工具、参数传错、步骤顺序乱问题层出不穷。root cause很典型——你的Agent确实有一堆工具但这些工具没有按照Agent的使用方式去组织。技能库就是在这里介入的把一组相关的原子能力按照任务语义组织成“技能”让Agent先选技能、再调工具、按技能内的流程走把波动压下去。下面我从设计思路、核心机制、实现细节到排查经验把这套方案完整过一遍。1. 先搞明白技能库和普通工具列表差在哪1.1 从一次翻车现场说起我之前在一个项目里给Agent挂了二十多个工具覆盖数据库查询、HTTP请求、文件读写、数据清洗这些基础能力。表面上很齐全实际跑起来惨不忍睹。用户说“帮我把最近一周的订单数据拉出来分析一下”Agent的响应路径经常变成先猜一个工具去查库查错了再换一个或者参数里把schema名塞进表名字段里再或者查完数据之后不知道怎么调用分析能力直接自己编了一段结论。那段时间我每天干的事就是翻日志看它到底哪一步选错了工具。后来我意识到问题不在大模型推理能力而在工具的组织方式。对大模型来说二十个平铺的函数签名加上一句“你可以使用以下工具”跟让一个实习生在没有SOP的情况下同时学二十台机器的操作流程差不多——它记住了每个工具大概干嘛但不知道完成一个任务应该按什么顺序、用什么组合。1.2 技能库的本质把工具路径变成可复用的流程技能库做的事情很朴素把一组工具调用编排成有输入的“能力单元”。比如上面那个场景从“查数据库”到“清洗数据”到“生成分析摘要”三步可以封装成一个技能叫analyze_orders_by_date。Agent面对用户需求时先面对的不是二十个散装工具而是几个语义清晰的技能。它只需要做一次“选哪个技能”的决策剩下的步骤由技能内部流程固定下来。我用的一个类比是工具列表等于给Agent一个工具箱里面有扳手、螺丝刀、电钻技能库等于给Agent一份设备维修手册上面写着“换滤芯时先关水阀再用扳手拧开外壳最后换上新滤芯”。前者靠临场发挥后者靠流程保障。1.3 为什么不能全塞进提示词有朋友问直接写Prompt里不行吗把工具的使用规则、调用顺序、参数说明全写进系统提示词不也是一种方案。我试过短期可行但等技能数量超过五个提示词长度迅速膨胀模型注意力会被稀释。更麻烦的是业务方每改一条规则就等于要改提示词重新调优版本管理非常痛苦。这算是技能库的第一个核心设计驱动把“如何完成某项任务”的流程性知识从提示词中抽离出来变成可版本化、可测试、可复用的代码配置。提示词只保留“大方向”具体流程交给技能定义去约束。2. 技能库的整体设计粒度、描述与注册2.1 先定技能划分的粒度技能库设计里最关键的决策就是粒度。划粗了技能的复用性差Agent每个任务都得新建专属技能划细了技能数量和原来的工具列表差不多等于白做。我摸索下来的经验是按“可以独立验收的半成品任务”来划。什么意思就是这个技能跑完之后应该产出一个用户或下游环节能直接使用的结果。拿数据场景举例子“连接数据库”不是技能它产出的结果是连接实例没人需要这个结果“把订单明细表拉到本地缓存”勉强算但太细“统计某段时间内订单的金额分布、渠道分布和异常单量”就是一个合适的技能因为它产出的是一份可直接阅读的结果。粒度定完后我给每个技能都配了三样东西描述、参数Schema、执行流程。这三样决定Agent能不能在正确的时候选中它、能不能正确调用它、能不能稳定执行完。2.2 技能描述不是给人看的是给模型看的很多人在这一步会犯一个错误技能描述写得太抽象或者太偏向“实现细节”。比如写“提供订单分析能力”或者“使用pandas进行数据聚合”这两种描述对模型都接近无效信息。我把技能描述当成一个“选型问题”来写模型需要判断的是“我现在这个用户请求和哪个技能最匹配”。所以描述里必须包含这个技能的输入假设你需要有什么数据、输出形式你会得到什么结果、典型使用场景用户说什么话容易触发这个技能、边界和限制什么情况不该用它。拿上面那个订单分析技能举例我写的描述是“当你需要分析订单数据并生成汇总统计时使用。输入为订单明细表或包含订单数据的查询结果输出为金额分布、渠道分布、异常单量的Markdown报告。如果用户只要求查询原始订单而不做统计请勿使用本技能改用query_orders工具。”这段描述里其实藏了两个信息点触发条件和不触发条件。很多技能选错的问题就是因为描述里只写了触发条件没写不触发条件。模型判断的边界会模糊就容易误选。我在所有技能描述里强制要求加一块“什么情况下不要用我”对降低误选率帮助非常明显。2.3 技能注册让Agent知道有什么可用技能库需要有一个注册机制把技能元信息暴露给Agent。我用的方案是在服务启动时扫描技能目录收集每个技能的YAML配置和Python入口然后汇总成一份JSON清单。这份清单会在每次会话构建的时候注入到系统提示词的工具定义部分保证Agent看到的技能列表永远是最新的。这里有一个性能考量点如果技能数量多清单注入提示词的开销不能忽略。我统计过一个技能平均描述大约200~400个token三十个技能就是6000到12000个token加上参数Schema还会更多。超过这个规模建议做技能路由前置——先用一个轻量模型或者嵌入式检索把候选项从三十个过滤到五个再让主Agent做最终决策。我在项目里当技能超过二十个的时候就切到了这种两段式路由效果比硬塞所有技能描述要好。3. 核心机制落地Schema、流程编排与版本管理3.1 参数Schema要偏“紧”不能偏“松”技能参数Schema的设计是我踩过最多坑的地方。给模型用的Schema和给前端表单用的不一样前端越宽松越方便模型调用技能则需要边界清晰。我拿一个技能举例fetch_page_content用来抓取网页正文并转成纯文本。最初我定义的参数只有url这一个string字段觉得够简单了。结果模型经常把带跟踪参数的、需要登录的、甚至是二进制文件链接直接传进来拿回来一堆垃圾内容。后来我改成了这样name: fetch_page_content description: 抓取指定网页并返回正文纯文本适用于文章页、文档页。什么样的链接不该用本技能需要登录、直接指向PDF/图片/视频等二进制资源。 parameters: type: object properties: url: type: string description: 完整的网页URL必须以http或https开头 timeout: type: integer description: 请求超时时间单位秒默认10最大30 required: - url additionalProperties: falseadditionalProperties: false很关键它堵死了模型往里塞额外参数的路子。timeout给了默认值但允许覆盖这算是个折中——很多场景模型确实需要调长超时但你不限制的话它能给你传个200秒。模式上我也做了调整凡是技能内部不需要的参数一律不放在Schema里凡是需要外部传入的必须写明格式和范围。宁可让模型因为参数不满足而拒绝调用也不能让它拿一个错的参数跑出一个错的结果。3.2 流程编排固定步骤与自由步骤技能内部执行流程我分成两类固定步骤和自由步骤。固定步骤是指必须按顺序执行的调用比如“先查配置再连数据源再做校验最后聚合”。这种步骤我会直接用代码来写不走模型保证不可跳过、不可乱序。自由步骤则留给模型发挥。在流程的某些节点上我会开放几个子工具让模型自行决定用哪个、怎么组合。这相当于给了一套铁路网轨道和车站是固定的固定步骤但到了中转站你可以选择换乘哪条线自由步骤。这个混编设计的出发点是我观察到的现象完全固定流程会导致Agent遇到意外情况时僵硬比如数据源变了格式就崩完全开放则又回到工具列表模式流程不可控。混编能让90%的常规操作稳定执行剩下10%的异常情况又保留了一定的灵活性。具体到实现我用的是一个很轻的STEPS配置steps: - type: fixed action: validate_input - type: fixed action: fetch_source_data - type: open tools: [clean_column, normalize_datetime, fill_missing] instruction: 根据数据质量选择合适的清洗工具处理异常值 - type: fixed action: aggregate_by_dimension - type: fixed action: render_markdownvalidate_input这种固定步骤跑在沙箱里返回结果或抛错open那一步把子工具列表给到模型让它根据前一步实际看到的数据做决策。这样流程日志里每一步都能追溯模型在哪一步做了什么决策也清晰可见。3.3 技能版本与灰度上线技能库里的技能会持续迭代版本管理从一开始就要做不然后面非常痛苦。我用的方案是每个技能目录下放一个版本号发布时保留历史版本。Agent调技能时默认走latest但可以指定某个历史版本号用于对照测试。灰度上线的方式比较朴素新版本技能先只对一部分会话开放通过请求ID哈希取模来决定是否走新版本。跑两三天对比新旧版本的技能调用成功率、平均执行时长和下游用户反馈确认新版没问题再全量切。这样做的原因很简单技能改动的影响面往往比预想的大。你以为只是调了一下数据清洗规则结果连带影响了所有依赖这个结果的后续步骤。没有灰度机制一次上线失误就是线上的事故。4. 实操过程从零搭一套可用的技能库4.1 目录结构与注册扫描我先分享一下当前项目的技能库目录规范这套结构已经跑了几个版本稳定够用skill_library/ ├── registry.yaml ├── skills/ │ ├── order_analysis/ │ │ ├── skill.yaml │ │ ├── main.py │ │ ├── steps.py │ │ └── requirements.txt │ ├── page_fetch/ │ │ ├── skill.yaml │ │ ├── main.py │ │ └── requirements.txt │ └── ... └── tests/ ├── fixtures/ └── test_skills.py每个技能目录三个核心文件skill.yaml存元信息和描述main.py存技能入口steps.py存固定步骤的具体实现。registry.yaml是可选的总索引但我越来越倾向于让它只存技能路径列表不重复存描述避免两处维护导致字段不一致。启动扫描的逻辑很简单遍历skills目录下每个子目录读取skill.yaml把技能名、描述、参数Schema汇总成一个列表做一次JSON Schema校验校验通过才把技能加载进来。任何技能只要Schema不合法就直接阻止启动而不是运行时报错。这个“fail fast”设计在前期帮了我很多很多Skema笔误被拦在了上线之前。4.2 从写一个技能到接入Agent拿写一个sentiment_stat技能的过程举例这个技能负责对一段文本列表做情感倾向统计并输出分布结果。第一步先在skill.yaml里把元信息写清楚name: sentiment_stat version: 1.2.0 description: 对文本列表做情感倾向判断并统计分布输出负面占比、正面占比和中性占比。当用户想了解舆情倾向、评论情绪、客户反馈态度分布时使用。如果用户只要求判断单条文本的情感请使用classify_text工具。 parameters: type: object properties: texts: type: array items: type: string description: 待分析的文本列表最多500条 language: type: string enum: [zh, en] default: zh required: - texts additionalProperties: false steps: - type: fixed action: validate_input - type: fixed action: batch_classify - type: fixed action: aggregate_distribution - type: fixed action: render_markdown接着在main.py里实现入口import json from .steps import validate_input, batch_classify, aggregate_distribution, render_markdown def run(context: dict) - dict: params context[params] validate_input(params) classified batch_classify(params[texts], params.get(language, zh)) distribution aggregate_distribution(classified) report render_markdown(distribution) return {result: report, meta: distribution}接入Agent这一步我用的方式是把它翻译成模型的工具调用格式注入到对话的tools字段中。这一步有个容易出问题的细节提示词里给模型看到的description字段必须和skill.yaml里的描述完全一致。不一致的话模型按提示词的描述做推理但技能服务按YAML的参数做校验两边对不上就会出莫名其妙的错误。接入完成后我会先跑到本地跑几个冒烟测试用例确认调用链路通。然后加一个关键日志技能内部每个步骤的执行耗时和返回摘要这样出问题的时候不用猜。4.3 评测技能库不能只靠肉眼观察技能库上线久了你会遇到一个很现实的问题怎么知道这次改动是变好了还是变坏了凭感觉是不行的必须有评测集。我的做法是给每个技能配一组评测用例模拟真实的用户请求。评测集分三层技能选择评测给一段用户话术让Agent选择该用哪个技能检查是否选对重点考察易混淆技能的区分度。参数抽取评测给用户话术加目标参数检查Agent抽取的参数是否符合Schema要求重点关注缺失和多传两种情况。端到端执行评测用完整话术跑通整个技能流程用结果断言来判定成功或失败。这三层评测分别对应“选没选对”“传没传对”“跑没跑通”。每一层都能定位到不同环节的问题不会一锅粥地混在一起。我给一个技能集跑完评测后会生成一个汇总表一般长这样技能名选择准确率参数合规率端到端通过率order_analysis92%95%88%page_fetch98%90%95%sentiment_stat96%100%93%哪个指标低于阈值就往对应环节查。比如选择准确率低就回去改描述参数合规率低就去看是哪个参数经常被模型乱填调整描述里的参数说明端到端通过率低就要深入看技能内部的步骤执行日志了。4.4 多Agent场景下技能库的共享与隔离最后聊一个团队协作层面的实操点多个Agent共用一套技能库时怎么处理共享和隔离。我现在的方案是技能库本身做只读共享所有Agent能读取同一份技能定义和版本但技能执行时的状态数据是隔离的比如缓存目录、临时文件、数据库连接池都按Agent维度单独分配。这个设计解决的实际问题有两个一是技能定义不做多副本改一版全链路生效不会出现不同Agent行为不一致二是执行态隔离避免了互相污染比如A任务在缓存里写入的数据不会影响B任务的正确性。如果你在一个Agent群里跑多个业务Agent这个隔离设计可以节省大量排查时间。5. 常见问题与排查技巧实录5.1 技能总是选错先看描述问题遇到技能选择准确率低我目前的排查顺序是先看是不是描述里缺少反向限制。比如fetch_page_content和download_attachment两个技能如果描述里都写了“获取文件”模型根本分不清该用哪个。给前者加上“用于渲染网页正文”、给后者加上“用于保存二进制附件到本地”区分度立刻上来了。第二个容易出问题的地方是描述里用了太多抽象形容词。一个真实例子我原来写“高效地处理数据”模型确实经常选它但用在哪都行。后来改成“将DataFrame格式的宽表做透视输出长表”选错率明显下降。模型理解具象操作远比理解抽象效果要可靠。5.2 参数老是传错收紧Schema加输出约束参数传不对是另一个高频问题。我遇到比较典型的是数组参数只有一条数据时模型可能把字符串直接传给数组字段。解决方法是让Schema描述里明确写“即使只有一条数据也请传数组格式”同时在评测集的参数抽取用例里加一条单元素测试。还有一类是单位问题。比如技能要求传入毫秒时间戳模型经常传秒级。我会在字段描述里加一个真实示例“timestamp_ms: 毫秒级Unix时间戳例如1699999999000”。给示例比给描述要有效得多模型对具体数字的感知远超抽象说明。5.3 技能执行到一半崩掉加步骤级日志技能内部步骤失败时快速定位是第几步出了问题非常关键。我的经验是每一步都记一小段结构化日志包含步骤名、入参摘要、出参摘要、耗时和错误信息。这个习惯救了我很多次。有一次技能输出结果总是少一块数据我查到最后发现是在validate_input步骤里对“空字符串”和“null值”的处理逻辑写反了导致一部分有效数据被清洗掉了。如果没有步骤级日志这种问题必须靠肉眼对数据才能看出来。所以一个值得常备的设计是技能执行框架里统一打步骤日志并在错误信息里带上步骤名和错误详情而不是只给一句“技能执行失败”。5.4 性能不够分清瓶颈在模型还是技能技能库响应变慢了需要先确认瓶颈在哪。如果是技能选择阶段慢说明模型输入里的技能描述太多了考虑加技能路由前置如果是技能内部执行慢去看固定步骤里是不是有冗余调用比如重复拉取同一份数据或没有用缓存。我做过一个优化技能内部会缓存最近10分钟的中间结果Key是“技能名主要参数哈希”。命中缓存时跳过耗时的数据拉取步骤直接把缓存结果交给下一步。在重复分析同一批数据的场景里这个优化把端到端时延从8秒降到了2秒以内。写在最后的实操心得技能库这个项目做下来我发现最反直觉的一点是难点不在让Agent用上技能而在让Agent知道什么时候不用某个技能。描述里加“不该用我”的说明、Schema里做严格限制、评测集里加入易混淆用例都是在帮模型划清边界。如果你现在正准备在自己项目里做技能库我有一条具体建议不要一口气把全部能力都封装成技能先挑三个业务价值最高、执行路径最稳定场景做试点把技能库的工程框架和评测流程跑通。等框架稳了再逐步把其他能力收编进来。技能库本身的工程能力只有在少数技能下打磨扎实了才能在规模扩大时扛住复杂度的考验。
