写在前面最近半年AI Agent 圈子里人人都在囤 skillGitHub 上 star 涨得最快的项目是 “XX 个精选 skill 合集”社群分享的是 “我整理了 100 条 prompt 模板”工具链也在推波助澜 —— 一键导入、批量安装仿佛 skill 装得越多Agent 就越强。但真正把 Agent 跑在生产环境里的人会发现一个尴尬事实装了一堆 skill 之后Agent 反而没那么好用了。本文想说的不是 “skill 没用”而是skill 是好东西但迷信 skill 会让 Agent 变差。我们要做的是用好 skill而不是被 skill 绑架。一、Skill 对 Agent 到底有什么好处不能一上来就否定 skill。它之所以流行是因为确实解决了真问题。把 “隐性知识” 变成 “显性规则”很多业务场景有专属规则退款走什么流程、周报包含哪些字段、代码 review 检查哪些点。这些规则模型不知道你不告诉它它就瞎猜。skill 的价值就是把这类隐性知识显性化。保证输出稳定性同一个问题问十次模型可能给十种格式。加上一条格式 skill——“输出必须是 JSON字段为 title、summary、tags”—— 输出立刻稳定。这对 Agent 协作、结果入库等需要程序化处理的场景至关重要。降低重复沟通成本高频任务不用每次重新解释一次写好、反复调用。这是 skill 最朴素的收益。让能力可以复用和传递一个好 skill 可以从一个项目复制到另一个项目、从一个人传递给另一个人把 “经验” 变成 “资产”。所以 skill 本身没错错的是 “越多越好” 这个假设。二、迷信 Skill会让 Agent 变得不好用“迷信” 的意思是把 skill 当成万能药遇到问题第一反应就是 “再加一条 skill”。这条路走下去Agent 会越来越差具体表现在四个方面。注意力被稀释规则越多每条越弱模型的注意力是有限资源。塞进去 50 条 skill每条分到的注意力权重就低了该遵守的规则没遵守该触发的 skill 没触发输出 “每条都沾一点”但哪条都没做到位。这不是模型变笨了是你让它同时背太多东西。规则打架模型陷入 “精神分裂”“回答要简洁” 和 “要详细解释每一步” 并存“用正式语气” 和 “要口语化、接地气” 并存。模型没有仲裁能力只能在冲突中摇摆最后输出一个四不像既不够简洁也不够详细既不够正式也不够亲切。触发条件模糊该用的没用不该用的乱用很多 skill 写的是 “在合适的时候使用” 当需要时调用 “。什么叫合适什么叫需要模型判断不准于是出现两种极端该触发时没触发 —— 用户明明在问退款Agent 却没走退款流程不该触发时乱触发 —— 用户只是随口提了一句” 钱 Agent 就启动了整套退款话术。模糊的触发条件比没有 skill 更糟糕。维护成本转嫁给模型人类加规则时想的是 “多一条没坏处”但模型每次推理都要重新解析全部规则解析负担越重、出错概率越高、响应越慢、token 越贵。你省下的思考成本全转嫁给了模型。三、怎么让 Skill 真正帮 Agent 发挥更大作用核心原则一句话Skill 不是越多越好而是越 “准” 越好。Agent 不是 skill 的仓库而是 skill 的调度器。场景一客服 Agent迷信的做法装 30 条 skill—— 退款、换货、物流、发票、投诉、催单…… 全部默认生效。结果用户问 “我的快递怎么还没到”Agent 同时触发物流、催单、投诉三条 skill输出又长又乱还莫名其妙提一句 “如需退款请告知”。正确的做法分层 按需加载。第一层永远生效1 条你是客服只处理订单相关问题不确定时转人工。 第二层工作流1 条识别意图 → 判断问题类型 → 加载对应 skill → 输出前自检 第三层按需加载 - 退款 skill触发词退款、退钱、不要了 - 物流 skill触发词快递、物流、到哪了 - 发票 skill触发词发票、开票关键点第三层不默认注入上下文Agent 判断意图后再调取。用户问物流只加载物流 skill输出精准、简洁、不跑偏。场景二编程 Agent迷信的做法代码风格、命名规范、注释规范、测试规范、提交信息规范、review 规范…… 全部默认生效。结果写一个简单函数既想守命名规范又想加注释又想写测试又想考虑性能最后写出来一个过度设计的累赘。正确的做法按任务阶段加载。阶段一理解需求 → 只加载需求澄清 skill 阶段二写代码 → 只加载代码风格 命名规范 阶段三自测 → 只加载测试规范 阶段四提交 → 只加载提交信息规范关键点不同阶段用不同 skill而不是同时全开。每个阶段专注一件事输出质量明显提升。场景三写作 Agent迷信的做法正式风格、口语风格、幽默风格、专业风格、简洁风格…… 全部默认生效。模型在风格冲突中摇摆写出来的东西既不正式也不口语读起来很 “AI 味”。正确的做法风格 skill 只留一条且必须由用户显式指定。默认风格1 条用简短、直接的中文回答不堆术语。 可选风格按需切换不叠加 - 正式报告 → 切换到正式风格 - 科普文章 → 切换到科普风格关键点风格类 skill 天然互斥永远只激活一条。输出风格统一不再 “精神分裂”。场景四数据分析 Agent迷信的做法SQL 规范、可视化规范、统计方法、异常检测、报告格式…… 全部默认生效。用户只是想看一眼 “上个月销售额”Agent 却启动了完整分析流程最后给出一篇用户根本不需要的长篇大论。正确的做法按问题复杂度分级加载。简单查询1 条 skill直接查数、直接回答不做额外分析。 中等分析2-3 条 skill查数 简单可视化 一句话结论。 深度分析按需加载全套查数 可视化 统计检验 异常检测 完整报告。关键点用 “问题复杂度” 作为 skill 加载的开关而不是无脑全开。简单问题快速回答复杂问题深度处理用户体验反而更好。四、四条通用原则不管什么场景用好 skill 都遵循这四条一条 skill 只干一件事“查订单 判断政策 生成话术 发邮件” 应该拆成四条而不是塞进一条。触发条件必须硬不要写 “在合适的时候使用”要写成 “当用户提到 ’ 退款 ’ 且订单状态为 ’ 已发货 ’ 时触发”。优先级必须显式冲突时谁赢必须写清楚安全规则 合规规则 风格规则 效率规则。能删就删每加一条 skill问自己删掉它输出会变差吗如果不会就删。Skill 的价值在于它改变了行为而不是它存在。五、总结Skill 是好东西它把隐性知识显性化、保证输出稳定、降低沟通成本、让经验可复用。但迷信 skill—— 遇到问题就加一条 —— 会让 Agent 注意力被稀释、规则打架、触发混乱、成本飙升。真正用好 skill 的关键是分层、按需、硬触发、显式优先级、能删就删。一句话收尾好的 Agent 不是 skill 的仓库而是 skill 的调度器。它知道什么时候用哪条而不是把所有规则同时背在身上。