做了这么久的 Agent 相关项目我收到最多的反馈其实是同一句话“它聊得头头是道我让它干活怎么就这么费劲” 这不是模型不行而是我们一直在用“聊天”的思路去要求“干活”。这个系列写到第八篇前面聊过 Agent 的框架、上下文管理、工具调用这篇终于轮到 Skill 技能系统——目前把 Agent 从“能说”推向“能干”最关键的一层封装。这篇适合谁看你正在用 Claude Code、Cursor、Codex 这类工具做自动化任务或者自己在搭 Agent 应用但发现 Agent 处理复杂任务时行为飘忽、结果不稳定、换一天跑同一个任务就变样。看完这篇文章你会理解 Skill 和普通 Prompt、Function Calling 的本质区别能独立设计一个可复用、可验证的 Skill并且学会在实际开发中避开我踩过的那些坑。1. Skill 技能系统入门Agent 为什么需要“技能库”1.1 聊天和干活差的是一层“确定性”先摆一个很常见的现象。你让 Agent 分析一份表格第一次跑出来结果挺好第二天同样的输入再跑一遍它可能给出完全不同的结论。这不是偶然的 bug而是 LLM 本身的概率属性导致的——同样的 Prompt、同样的模型参数每次采样都可能落在不同的分布区域。聊天场景下这种发散是优点同一个话题可以聊出千百种角度但干活场景下发散就是灾难因为任何一个重复性任务都要求行为可复现、结果可校验。Skill 系统解决的就是这个“确定性缺口”。它把一段能力从“临时写在 Prompt 里的建议”升级成“工程上可加载、可触发、可验证的模块”。一个 Skill 不是一段更长的提示词而是一个包含描述、步骤、脚本、参数定义和测试用例的完整单元。Agent 在任务中通过描述做检索匹配一旦命中就走固定流程该用代码的地方用代码该用模型判断的地方才把控制权交回给 LLM。这样一来核心逻辑被钉死在代码里模型只需要在少数开放节点上做决策。我早期做过一个很蠢的尝试把一系列操作步骤全写在一个大 Prompt 里让 Agent“按部就班”执行。结果它前五分钟还很听话聊天窗口一长它就自己开始自由发挥跳过步骤直接总结。后来我才意识到这不是用户提示写得不够好而是因为所有行为都挂在“模型的自觉”上而模型没有自觉。Skill 的意义在于把“自觉”换成“强制”——步骤里明确哪些动作是脚本执行哪些输出需要结构化校验。确定性来自工程约束不来自口头叮嘱。1.2 Skill、Function Calling、Prompt、MCP四者怎么分工很多刚开始做 Agent 的同学喜欢把 Skill 和工具函数混为一谈。我在团队内部经常用一句话概括Prompt 是“告诉模型要做什么”Function Calling 是“让模型能做什么”Skill 是“让模型知道什么时候做什么、怎么做对”MCP 则更像“把工具变成标准化服务”的传输协议。四者不是替代关系而是不同层级的分工。用生活化类比来说Prompt 像是你给一个新来的实习生口头交代“把这个报表整理一下”说得再详细也只是口头指令Function Calling 是给他一台计算器他得自己想清楚什么时候按哪个按钮Skill 是给他一份完整的工作手册里面有流程图、检查清单、异常处理办法他照着走就能稳定产出MCP 是把公司各个业务系统统一封装成标准接口任何实习生进来都能按统一方式接入。这个区分很关键因为 Agent 的工程化难点从来不是“能不能调用工具”而是“在什么条件下、用哪套流程、以什么标准交付”。Function Calling 只解决调用能力调度逻辑还是模型临场发挥。Skill 则把调度依据前置用描述和元数据给 Agent 提供决策支持匹配决策是确定性的描述配置得好触发就精准步骤配置得好执行就稳定。我还经常看到有人把 Skill 和 MCP 对立起来讨论。实际项目中它们常常配合使用MCP 解决的是工具连接问题让 Agent 能拿到外部系统数据Skill 解决的是工作方法问题定义处理这些数据的流程和产出标准。一个 MCP Server 可以提供搜索、数据库操作等原子能力但“用这些能力凑成一份周报”的完整手艺还是得靠 Skill 来编排。两者不是同一层的东西放在一起比谁替代谁意义不大。1.3 工程化的分水岭Skill 化程度观察过不少 Agent 项目之后我发现一个规律早期项目都在堆 Prompt把模型能力当万能牌遇到问题就加一段描述中期开始接入 Function Calling模型终于能调外部工具到了后期真正能稳定落地的项目基本都会沉淀出一套技能库。这个从“堆 Prompt”到“建技能库”的过程就是工程化的分水岭。这不是什么高深理论。做 Agent 项目本质是在做一件事把不确定性尽量压缩到模型最擅长的区域把确定性的部分交给传统代码。Skill 系统就是这个压缩过程的载体。一个团队如果能把自己的核心能力写成几个高质量的 Skill那么不同项目之间复用能力就变得非常便宜反之每次新项目都从头写 Prompt 调对话相当于每次都重新发明一次轮子。我也注意到社区里很多 Agent 教程都在讲“Agent 循环”思考、调用工具、观察结果、再思考。这个框架没错但它描述的是模型内部的运行过程。Skill 系统补的是产能侧的封装问题——如何把一次成功的实践固定下来让 Agent 下次遇到同类任务时不需要重新摸索。换句话说吴恩达那套 Agent 教程解决的是“Agent 怎么动起来”Skill 解决的是“动完之后怎么沉淀下来”。两者结合才是完整的 Agent 工程闭环。2. 设计一个 Skill目录、描述、入参与验证闭环2.1 一个 Skill 的最小目录结构长什么样我在实际项目中用过的 Skill 目录结构经过好几轮迭代目前最顺手的是这样的skills/ meeting-minutes/ SKILL.md scripts/ parse.py format_output.py references/ template.md tests/ case_normal.json case_edge.json case_adversarial.json这个结构里SKILL.md是 Agent 读到的说明书scripts/放确定性执行脚本references/放模板和参考材料tests/放验证用例。每个目录都有明确职责不混放。你可能会问为什么需要references/因为有些 Skill 需要引用固定格式模板或行业规范与其把这些内容全部塞进 SKILL.md 里撑爆上下文不如放在单独文件里让 Agent 用到时再读取。这个设计能有效控制上下文窗口占用尤其是 Skill 描述比较长的时候。一个 Skill 的核心只有一个让 Agent 在正确时机、用正确流程、产出正确结果。目录结构只是载体真正的灵魂在SKILL.md和脚本的设计上。很多新手容易犯的毛病是把目录建得特别宏大plan、analysis、report 建了一堆文件夹结果内容都是空的。我建议从最小可用开始一个 SKILL.md、一个脚本文件夹、一份测试用例够用就行。后面扩展结构一定是功能真的需要了才加。2.2 SKILL.md 是写给 Agent 看的说明书SKILL.md的定位很容易误解。它不是写给人类阅读的文档而是给 Agent 的“操作规范”。这意味着它的写法要贴近模型的理解方式结构清晰、语义明确、指令性强。我见过有人把 SKILL.md 写成大段散文描述这个技能“旨在提升工作效率”结果 Agent 看完根本不知道什么时候该用它。一个有效的 SKILL.md至少包含这些字段name / version技能名字和版本用于检索和追溯description一句话说明这个技能解决什么问题when_to_use哪些场景应该触发、哪些场景绝对不能触发parameters入参定义字段名、类型、必填项、默认值steps执行步骤按顺序编号标注哪些步骤跑脚本、哪些步骤用 LLMoutput_format输出结构最好有模板或示例其中最容易写坏的是 description 和 when_to_use。description 写得好不好直接决定 Agent 会不会在恰当的场景调用它。我举个对比差的描述是“处理会议相关内容”好的描述是“将会议录音转写后的纯文本整理为结构化会议纪要提取决策、待办事项、负责人和截止时间适用于会议时长小于三小时且包含明确议题的文本”。后者给了模型足够的匹配信号触发准确率会高很多。when_to_use 同样重要而且要写“负面清单”。明确写“不要在文本缺少发言主体时强行推测归属”“不要对情绪化的聊天记录做结构化处理”这能显著降低 Agent 在边缘场景的错误调用概率。模型对禁止项的理解往往比含糊的边界描述更可靠。2.3 脚本层与“人机结合”哪些部分交给代码Skill 开发中最容易被忽视的问题是没有正确划分“代码该做的事”和“模型该做的事”。我的原则是凡是规则明确的、需要精确计算的、格式固定的一律交给脚本凡是语义开放、需要理解语境和判断取舍的才交给 LLM。拿会议纪要 Skill 举例。提取会议时间、统计参会人数、去重、格式化日期这些都是规则性操作应该用正则或日期解析库在脚本里做掉。它们不需要模型发挥用 LLM 反而容易出幺蛾子——比如模型编造一个不存在的日期。而“这段对话里真正做出了什么决定”“这句话是结论还是疑问”这类语义判断才值得调用 LLM。脚本负责确定性LLM 负责歧义性这是一个 Skill 稳定性的根本保证。还有一点脚本对 LLM 的输出要设立护栏。比如脚本里可以加一层断言检查 LLM 返回的 JSON 是否包含必需字段、字段类型是否正确不合规就直接重试或者报错而不是把脏数据传给下游。这个习惯我是在吃了好几次“脏数据进入下一环”的亏之后养成的。Skill 不是把流程写好就完事它必须有自我保护机制保证任何一个环节失败时能尽早暴露而不是带病运行。2.4 验证闭环Skill 必须自带“考试题”做 Agent 工程和做普通脚本工程最大的不同在于我们验证的不只是代码对不对还包括“Agent 加 Skill 这个组合”能不能稳定完成任务。同一个脚本面对不同的上下文扰动Agent 的调用路径可能完全不同。所以 Skill 必须自带测试用例形成验证闭环。我的测试思路是设计三层用例第一层是标准用例覆盖技能的主要场景第二层是边界用例比如空输入、超长文本、缺字段第三层是对抗用例故意给一些不该触发技能的内容看 Agent 会不会被误导。每一层都有不同价值标准用例验证功能正常边界用例验证鲁棒性对抗用例验证触发阈值的准确性。测试方式也很直接把用例喂给 Agent让它以该 Skill 的方式处理然后核对输出是否满足断言。这个过程应该做成可重复的自动化回归否则每改一次 SKILL.md 或者脚本就要手动试一遍成本太高也容易遗漏。一个 Skill 是否成熟衡量标准就是它能不能通过自己的测试集——而不是“我今天试了一把感觉还行”。3. 完整实操从零开发一个“会议纪要与任务提取”Skill3.1 定义边界先想清楚这个 Skill 不做什么很多 Skill 设计失败的起点是功能边界没定清楚。一个技能又想整理会议纪要又想处理翻译又想分析情感结果 Agent 遇到稍微偏一点的输入就把 Skill 调出来流程一跑全是错的。我在设计任何 Skill 之前第一件事是列“不做什么”清单。以“会议纪要与任务提取”这个 Skill 为例我定的边界是只处理会议录音转写后的纯文本且文本里存在明确的多方发言和议题讨论不处理单句闲聊、不处理没有任何动作要项的文本、不对缺失的发言主体做猜测、不负责翻译或摘要改写。为什么要这么严格因为触发精度要远比覆盖面重要。一个 Skill 偶尔漏触发一次最多让 Agent 走回通用流程但如果频繁误触发下游就会持续收到错误结构的输出这种污染比不触发更麻烦。写完“不做什么”之后我会把边界同步写进 SKILL.md 的 when_to_use 字段里用负面清单的措辞明确禁止。实测下来这种写法的效果立竿见影Skill 的误触发率明显下降因为模型在处理模糊任务时会优先排除边界外的场景而不会硬着头皮套用。3.2 把流程拆成五个可执行节点边界定好之后就开始拆流程。我设计的会议纪要 Skill 拆成五个节点输入校验、文本清洗、结构化抽取、任务优先级判断、输出格式化。每个节点只做一件事节点之间有明确的输入输出约定。输入校验节点在脚本里实现检查文本非空、长度在合理范围、包含至少两个不同发言主体不满足直接返回错误码。文本清洗节点做去重、去无效行、修正标点和换行这个也放在脚本里。结构化抽取是把清洗后的文本交给 LLM让它按字段抽出议题、决策、待办、负责人、截止时间。任务优先级判断可以做成两个版本简单版用规则关键字匹配、时间紧迫度在脚本里算复杂版可以让 LLM 根据上下文判断紧急度但我会要求它的输出必须是枚举值而不是自由文本方便后续排序。最后输出格式化节点统一组装 JSON 或 Markdown。这个拆分思路的核心是每个节点要么是“纯代码”要么是“LLM 做选择题”。越到后期我越倾向于把 LLM 的输出收敛成选择题而不是简答题。比如“这个待办的优先级是 A/B/C 哪一档”模型答对的概率远高于“请用一句话描述这个待办的紧迫程度”。不确定性在传输过程中会被逐级放大收敛得越早最终输出越稳定。3.3 写描述和参数让 Agent 看得懂、调得对流程拆完就要给 Skill 写“门面”——描述和参数定义。这是决定 Agent 会不会在正确时机调用你的 Skill 的关键环节。我在生产环境里反复调整过的经验是描述要包含触发场景的具体信号词比如“会议”“转写稿”“多人对话”“纪要”“待办”同时明确输出形态。参数设计上我倾向精简。这个 Skill 只保留了三个入参source_text必填待处理的会议转写文本output_format选填支持json或markdown默认jsoninclude_summary选填布尔值是否在纪要末尾生成一段简短总结。参数越少Agent 在调用时越不容易拼错参数越多模型犯错的空间越大。不要把一个 Skill 设计成万能接口什么都能传最终就是什么都传不对。参数类型也要尽量用明确的枚举或布尔值替代自由字符串。比如output_format写成枚举比让模型自己填一个“我觉得好看的格式”靠谱得多。我在 SKILL.md 里会给每个参数附带一个示例值模型在生成调用时会模仿示例这比冷冰冰的类型描述效果好很多。3.4 测试用例三层从正常到对抗测试用例是 Skill 质量的第一道防线。我开发这个 Skill 时测试用例设计遵循三层结构。第一层标准用例给一段包含明确议题、决策和三项待办的会议记录验证输出是否完整提取了全部字段且格式符合 Schema。第二层边界用例给空文本、只有一个人的独白、超过一万字的超长会议记录看系统是优雅降级还是直接崩溃。第三层对抗用例给一段朋友闲聊的微信对话里面没有任何会议议题验证 Agent 不会强行套用这个 Skill而是返回“不适用”或者转交通用流程。每层用例的价值不同但第三层往往最容易被跳过。新手写测试都喜欢盯着“正常场景能不能跑通”忽略了“不该跑的能不能拦住”。实际上在生产环境里一个误触发造成的数据污染远比十次漏触发的损失大。因为在编排链路中错误的结构化输出会直接进入下游数据表排查成本很高。对抗用例是给 Skill 上保险这笔投入非常划算。测试用例写完之后我还会做一件事用不同模型跑同一套用例观察结果差异。同一份 SKILL.mdGPT 系和 Claude 系行为可能差别巨大。如果这个 Skill 要在多个模型间复用就得在测试里记录各模型的通过率针对偏差大的模型调整描述措辞。Skill 不是一次写死终生不变的它需要跟着模型能力的变化做校准。3.5 让 Agent 在实际环境中找到并触发 SkillSkill 开发完成后最后一步是把它挂到 Agent 的运行环境里。不同工具的做法有差异但思路都是把skills/目录配置到 Agent 的可见路径下让模型在任务开始时能检索到技能列表。我习惯在系统提示词里加一句“遇到与会议纪要、待办提取相关的任务优先使用 meeting-minutes 技能”同时在用户请求里也会自然触发描述匹配。整个过程等同于给 Agent 一个工作手册索引而不是要求它靠记忆硬背。挂载完之后务必跑一个端到端验证给出一段真实的会议记录观察 Agent 是否主动选择这个 Skill、是否按流程执行、输出是否符合预期。很多 Skill 单独测试时样样都好一挂到完整 Agent 环境里就出问题通常是因为描述里缺少环境上下文或者参数命名和 Agent 既有体系冲突。这一步验证不能省它和单元测试是两码事。我在 Cursor、Claude Code 和 Codex 里都试过类似的技能挂载逻辑整体模式大同小异目录要放在配置指定的技能根目录下SKILL.md 的格式要严格对齐脚本执行权限要给对。有个常见问题是沙盒环境默认不允许脚本执行导致 Skill 里的 Python 脚本跑不起来。遇到这种情况优先检查权限配置再排查依赖是否安装最后才是代码逻辑问题。4. 实测中的坑与速查表4.1 坑一Agent 就是不调用 Skill开发 Skill 初期我遇到最崩溃的问题是Skill 写好了测试也过了但真实使用时 Agent 完全不理它宁愿自己靠记忆硬答也不用技能。一开始我以为是描述写得太含蓄后来排查发现是 Skill 列表压根没有进入模型上下文——Agent 根本不知道有这个技能存在。很多 Agent 工具默认只会把技能目录里的文件名加进索引如果你的 SKILL.md 里没有足够强的检索信号模型就“看不见”它。解决办法分两步第一步把核心触发场景的关键词写进 SKILL.md 的开头段落不要只放在某个偏僻字段里第二步在系统提示或者在关键任务节点显式告诉 Agent“这类任务有专用技能可用”。实测下来显式提示的效果立竿见影但要注意不能让所有任务都靠提示硬指定否则 Skill 系统就退化成了固定路由失去了灵活性。还有一种情况是模型压根不读 SKILL.md只是看到目录文件名就自行发挥。这种问题一般出在 SKILL.md 格式不规范、结构不清晰、或者文件被放在脚本目录而不是技能根目录。我建议严格检查目录和文件命名确保 SKILL.md 位于技能文件夹的根路径而不是藏在scripts/子目录里。4.2 坑二Skill 能跑但输出结果飘忽不定另一个高频问题是Skill 被触发了流程也正常执行但输出结果每次都不一样而且不稳定。我把这类问题归结为“节点内自由度太大”。如果你的步骤里有一行写着“分析这段文本并提取相关信息”这行指令就是自由度的源头——怎么分析、提取哪些信息、以什么格式输出全部交给模型临时决定结果自然飘。修正方向是把开放性描述改成封闭性约束。比如“从文本中找出所有包含明确动词和负责人的句子按 JSON 数组输出每条记录包含 action、owner、deadline 三个字段字段缺失填 null”。模型在封闭任务上的表现一致性会远高于开放任务。我在团队内部有个原则Skill 里的每一步要么是代码要么是枚举选择题原则上不出现“请总结”“请分析”这种开放式要求。每次出现这类要求就是一次不可控因素注入。此外如果 Skill 输出会经过后处理脚本务必在脚本里加 Schema 校验所有非法输入统一拦截。很多不稳定问题不是模型造成的而是模型输出的格式稍微变化后处理脚本没有兼容于是表现在结果上就是“时好时坏”。用 Pydantic 或者 JSON Schema 做一层强制性校验能过滤掉绝大多数偶发问题。4.3 坑三参数冲突和上下文污染第三个坑比较隐蔽发生在 Skill 与其他系统组件协作时。我遇到过一个问题Skill 的输出是一段很长的 Markdown 纪要直接拼回主对话结果后续几轮对话全被这段长文本带偏模型开始“纪要口吻”说话。这就是上下文污染——Skill 的输出不应该无差别地流回主链路应该做截断或结构化处理。我现在的做法是输出模块返回一个简短的执行摘要完整结果写入文件或变量只有摘要回填对话上下文。这样既保留了结果的可追溯性又不污染模型对后续任务的判断。另外Skill 之间的参数传递也要特别小心。多个 Skill 串联时一个技能的输出字段和另一个技能的入参字段可能重名但含义不同模型很容易把字段张冠李戴。解决思路是在参数命名上尽量加前缀区分比如meeting_minutes_action_items降低混淆概率。还有一类问题是 Skill 内部使用的脚本依赖全局变量或环境变量两个 Skill 同时运行时冲突。这种问题排查难度高定位到之后也很沮丧。我的建议是 Skill 的脚本尽量做成无状态输入全部从参数进、输出全部从标准输出或指定返回结构出不要读写临时目录或环境变量。无状态是 Agent 技能库能够大规模并行的前提。4.4 常见问题速查表事故症状可能原因处理办法Agent 完全不调用 SkillSkill 描述缺少触发信号、技能列表未加载重写描述中的关键词和场景显式提示可用技能调用了但结果不稳定步骤中开放式指令过多、模型自由度太大把“请分析”改成封闭式选择题或枚举输出输出偶尔断 JSON模型输出格式漂移、后处理校验缺失脚本入口做 Schema 强制校验非法输入拦截重试后续对话被带偏Skill 长输出污染主上下文只回填执行摘要完整结果写文件或变量脚本跑不起来沙盒权限受限、依赖缺失检查执行权限、安装依赖先跑单测定位多 Skill 串联时字段错乱参数名冲突、字段语义混淆加前缀区分命名严格定义各自 Schema改了一版描述后效果倒退触发关键词和真实场景失配用测试集回归对比新旧版本通过率4.5 进阶心得Skill 不是越多越好我在项目维护后期踩过一个大坑技能库越建越多维护成本爆炸而且 Agent 的选择准确率反而下降。原因很简单技能描述之间越来越相似模型在召回阶段容易混淆。比如我建了“会议纪要”和“访谈纪要”两个 Skill功能高度重叠实际使用中 Agent 经常选错。最后我把它俩合并了用参数区分适用场景效果一下子稳定了许多。这个教训让我意识到Skill 系统的质量不在于数量而在于每个技能之间的辨识度。技能库维护者应该定期检查现有技能标记出功能重叠的部分能合并就合并能删除就删除。一个精而少、边界清晰的技能库远比一个什么都往里塞的大杂烩可靠。另外每个 Skill 最好指定一名负责人技能更新要记录变更日志避免多人同改一个文件导致版本混乱这些管理细节看似和“技能开发”无关但在长期项目中决定生死。5. 从单个 Skill 到 Agent 工作流编排与管理5.1 编排思路链式和路由式的平衡单个 Skill 解决的是单个任务闭环但真实 Agent 场景往往是多个 Skill 协作。我常用的编排模式有两种链式编排和路由式编排。链式编排是指上一个 Skill 的输出是下一个 Skill 的输入在数据处理管线里很常见路由式编排是 Agent 根据任务意图选择一条技能路径分流执行更像企业里的工单分配系统。两种模式各有代价。链式编排的缺点是错误会逐级累积放大前一个环节的脏数据会污染后面所有环节所以每个环节的校验特别重要路由式编排的优点是模块独立性强但要求路由决策足够精准否则一个任务走错分支后面全是白做。我目前的经验是能并联就不要串联能路由就不要链式链条越短出问题的概率越低。在编排时还要考虑 Skill 之间的资源竞争。多个技能同时跑脚本时注意依赖和超时设置。我之前踩过一个坑一个 Skill 的 Python 脚本因为等待外部 API 响应挂起了整个流程后续任务全部阻塞。后来我统一给所有脚本加超时和重试机制才解决这个问题。Agent 工作流本质上是一个分布式系统任何一环没有超时保护整体可用性都上不去。5.2 技能库的版本与质量治理技能库壮大之后版本管理就变成一个严肃问题。我见过不少团队的技能库处于“代码人都能改、改了没人测、加了没人删”的状态。解决这个问题的核心是给技能库建立简单的治理规则每个 Skill 带 version 字段更新要过测试集回归变更记录写进 CHANGELOG长期不用的技能标记为 deprecated 并定期清理。这套规则不需要很复杂但要坚持执行。质量治理的落地工具最好是自动化回归。我把所有技能的测试用例集中到一个脚本里每次技能变更后跑一遍全量回归任何一个技能通过率下降都能立刻暴露。这个机制让团队敢放心更新技能不用每次改完都靠人工回归试。没有自动化验证的技能库等于没有刹车系统的车跑得越快越危险。另外一个治理重点是技能的可观测性。每个 Skill 的调用记录应该被记录下来包括何时触发、用了哪些入参、输出结果是否通过校验、耗时多久。有了这些数据你才能回答“这个技能到底有没有人用、用得对不对、和同类技能谁更好”这类关键问题。技能优化如果没有数据支撑最终只会变成靠感觉拍脑袋。5.3 我给新手的一句话先跑通再完善最后说点我个人的实操体会。很多新手拿到 Skill 系统之后容易陷入“设计完美框架”的陷阱花大量时间在搭建目录结构、写规范文档上迟迟不进入真实任务。我自己用过的最有效开发流程是先用一段小脚本验证核心逻辑能跑通再花半小时补一份能用的 SKILL.md最后写几个测试用例把边界拦住。整个过程不追求一步到位核心逻辑稳定之后再回头优化描述、补充边界、完善测试。Skill 是要在真实任务里“喂”出来的不是一次性设计出来的。还有一个很务实的小技巧新写的 Skill 先在单一 Agent 环境里试用一周记录触发率、通过率、误触发次数再决定要不要纳入正式技能库。这比在测试用例里自我感觉良好可靠得多。毕竟技能库的价值最终体现在真实任务的成功率上而不是文档写得有多漂亮。