如果你把“能用上的能力”全部做成 Skill 塞给 AI Agent结果大概率不是全能而是全不能。Skill 从 5 个加到 50 个代码审查没有更仔细反而连“该不该调用 Skill”这种最简单的判断都开始出错。这个现象在 2026 年的 AI Coding Agent 生态里越来越普遍尤其是围绕 Claude Code Skill、Codex Skill、Cursor Skill 和各类开源 Skill 库的讨论中几乎每个技术群里都能看到类似的吐槽。先给结论Skill 数量与 Agent 能力不是单调递增关系而是典型的“先升后降”。初期加几个高质量的 Skill任务完成率和输出规范性会明显改善超过一定数量后上下文膨胀、路由误判、指令冲突、规划开销这几个因素会同时恶化最终表现为 Agent 变笨。这篇文章不打算劝你“不要用 Skill”而是把背后的机制拆开给你一套可以自己验证、自己管理的 Skill 工程化方案。本文会覆盖五件事Skill 与 MCP、插件、Prompt 的区别Skill 过多导致性能下降的核心原因如何用一套可控的实验流程测量“Skill 多 vs Skill 少”的差异Skill 库的目录、命名、评估和治理规范以及常见问题排查清单。适合正在搭建 Agent Skill 库的开发者、给团队设计 AI 编码规范的工程负责人以及被“装了一堆 Skill 反而更慢”困扰的人。1. 核心问题速览先看清这个“越装越笨”问题长什么样。它不是某一个环节出错而是多个机制叠加后的综合表现所以排查起来往往比普通 Bug 更隐蔽。现象具体表现根因方向上下文拥挤对话轮次稍长就丢信息命令执行到一半忘了前提Skill 文件注入 token 过多路由误判任务该用 A Skill模型却调了 B Skill或不触发任何 Skill描述重叠、命名模糊指令冲突两个 Skill 对同一类输出给出不同格式模型反复横跳规则互相矛盾决策变慢每次任务前枚举候选 Skill 的时间明显变长候选空间膨胀自查失效Agent 完成输出后无法判断是否符合预期验收标准被多个 Skill 稀释回归难定位加一个新 Skill 后旧任务开始失败缺乏评估集和回归机制从材料看2026 年 AI Coding Agent 的 Skill 生态已经非常丰富OpenCode、Cursor、Claude Code、Codex 都支持类似 Skill 的机制第三方 Skill 库和 Skill 推荐内容也大量出现。但生态越繁荣越容易出现“看到什么 Skill 都想要”的囤积行为。结果就是 Agent 的工具列表和系统提示越来越长核心能力反而被淹没。这个问题的本质不是 Skill 机制的缺陷而是缺少工程化治理。很多人把 Skill 当成插件来安装装完就以为能力自动叠加实际上每个 Skill 都会改变模型的决策空间和上下文环境。接下来我们先明确 Skill 的定义再拆解性能衰减的因果链。2. Skill 到底是什么先看清它和 MCP、Prompt 的关系2.1 Skill 的定义Skill 在 AI Agent 语境里通常指一段结构化的“过程性知识”。它告诉模型面对某类任务时应该按什么步骤做、遵循什么规则、输出什么格式。一个 Skill 一般包含名称、描述、触发条件、操作步骤、示例和边界。与一次性 Prompt 不同Skill 是可复用、可版本化、可跨任务复用的行为资产。典型的 Skill 文件长这样--- name: code-review description: 对代码变更进行审查重点检查安全问题、性能风险和可读性。 trigger: 当用户请求 review 代码、提交 PR、或要求检查代码质量时触发。 priority: high --- ## 执行步骤 1. 读取 diff标注修改涉及的文件和函数。 2. 按优先级检查安全问题 性能风险 可读性。 3. 对每个问题输出文件路径、行号、问题描述、修改建议。 4. 如果没有问题明确输出 PASS。 ## 输出格式 { ok: true, issues: [] } ## 边界 不修改代码只输出审查结论。不要在无 diff 的情况下列出假设性问题。这段内容看似简单但“把它放在哪、什么时候被加载、如何被筛选”直接决定了 Agent 的聪明程度。不同实现里Skill 可能被静态追加到系统提示可能按关键词或向量检索后动态注入也可能作为一个工具由模型主动调用或者由外层 Router 模型预筛后再注入。加载机制不同Skill 数量对性能的影响幅度也不同。2.2 Skill 与 MCP 的区别很多人会把 Skill 和 MCP 混在一起但从功能边界上它们完全不同。Skill 回答的是“模型应该怎么做”MCP 回答的是“模型能碰到什么”。MCP 提供外部工具和数据源连接Skill 负责教模型如何编排和使用这些能力。两者常常配合使用Skill 里可以编排对 MCP 工具的调用顺序MCP 提供底层能力。维度SkillMCP回答的问题模型“怎么做”模型“能碰什么”内容形态步骤、规则、示例、边界工具定义、数据源连接消耗方式占用推理上下文和决策空间占用工具列表和调用通道典型来源编码规范、工作流、领域知识数据库、浏览器、文件系统、第三方 API变更影响影响输出质量和行为风格影响能力半径和副作用风险但要注意MCP 连接多了同样会增加模型选择工具的难度。Tools 列表膨胀会拉长模型在“选哪个工具”上的判断时间甚至漏选正确工具。这个问题和 Skill 过多是同一类“决策空间膨胀”问题只是表现路径不同。所以治理 Skill 的同时也要顺手清理低价值的 MCP 连接。2.3 Skill 与 Prompt 的关系Prompt 是一次性、面向单个任务的指令Skill 是可复用、可版本化、跨任务复用的行为包。好的 Skill 本质上是把反复编写的 Prompt 沉淀成了资产但如果只做沉淀不做治理Skill 就会退化成一堆互相打架的 Prompt。很多团队的 Skill 库没有评审、没有冲突检测、没有废弃机制最后膨胀到连管理员自己都不知道哪些还能用、哪些已经过时。判断一个能力到底该写成 Prompt 还是 Skill可以看两点它是否会被反复触发它的规则是否需要跨多个任务保持一致两个答案都是“是”才值得沉淀成 Skill。低频、一次性、强任务耦合的指令留在 Prompt 里反而更灵活。3. 为什么 Skill 越多Agent 反而越笨这是本文的核心章节。Skill 数量上升时至少五条因果链同时恶化而且它们之间还会互相放大。3.1 上下文膨胀稀释注意力模型每一步推理都要把当前可见的 Skill 内容计入上下文。假设一个 Skill 平均 1500 token50 个 Skill 就是 75000 token这还没算对话历史、代码 diff 和工具返回结果。上下文窗口是有限的Skill 占得越多留给任务本身的注意力分配就越少。尤其是“Lost in the Middle”问题窗口中间的 Skill 描述往往被模型忽略真正被记住的只有开头和结尾。这不是玄学而是 Transformer 注意力机制的实际表现。你在系统提示里放了 50 条规则模型在长对话后真正遵守的可能只有最靠前和最靠后的几条。所以你会看到Skill 多的 Agent反而在“按规则做事”上表现更差。很多用户反馈“规则写了等于没写”排查到最后发现是 Skill 总量把注意力稀释掉了。3.2 路由误判Skill 选择本身成了一个困难任务Agent 在执行任务前要先判断“该用哪个 Skill”。候选越少这个判断越简单候选越多判断越难。尤其是当多个 Skill 的描述高度相似时模型很容易选错。路由一旦出错后面的步骤全部建立在错误前提上Agent 的表现自然越来越差而且这种失败往往要到任务执行中段才能被发现浪费的 token 和步骤已经不可回收。常见的路由失败模式有四种描述泛化一个 Skill 写“处理各种开发任务”另一个写“处理通用编程问题”模型分不清边界随机挑一个命名混淆api-test和api-tester并存模型选了旧的过时版本触发条件缺失Skill 正文很详细但 description 没写“什么时候用”模型在需要时根本不触发长尾淹没高频低频 Skill 和核心 Skill 放在同一层核心 Skill 的触发率被稀释。3.3 指令冲突导致行为摇摆Skill 不是孤立存在的。当你从不同作者、不同仓库、不同版本里收集 Skill 时冲突几乎是必然的。最简单的例子Skill A 要求所有 API 调用使用axiosSkill B 要求所有 HTTP 请求统一走fetch封装层Skill C 又规定“第三方 SDK 优先不要自己写 HTTP”。三条规则单独看都没问题同时出现在上下文里时模型面对一个网络请求任务会陷入自我矛盾。更隐蔽的是输出格式冲突。一个 Skill 要求 JSON 输出带code字段另一个要求带status字段模型在两个标准之间横跳下游脚本跟着崩。这种冲突不会在单个 Skill 的测试里暴露只会在全量集成后出现所以特别难排查。排查时往往要逐个比对 SKILL.md 里的格式定义效率极低。3.4 规划开销与决策延迟Agent 的推理过程可以理解为在“可用操作集合”上做搜索。Skill 越多操作集合越大搜索分支越多模型需要更多步骤才能收敛到正确的执行路径。表现就是任务开始前的“思考”变长中间走到错误分支的概率变大失败后重试的次数也变多。在批量任务场景中这个问题会被放大如果一个 Agent 每天要处理几百个任务每个任务因为 Skill 路由多消耗 20% 的 token累计成本几乎等同于平白多跑了一轮任务。从性能观察的角度看“平均步数上升但任务完成率不升”是一个典型信号。如果你在 Agent 日志里看到推理步数持续上涨而任务成功率没有对应提升首先应该怀疑的可不只是模型能力而是候选 Skill 空间过于庞大。3.5 验收标准稀释Agent 不知道什么叫“做好了”Skill 里通常包含输出格式和验收标准。当多个 Skill 同时存在时模型手头可能有五套不同的“成功标准”。它执行完任务后无法判断当前结果到底符合哪一套。这会导致两种行为要么随意选一个标准自我满足要么反复自查、迟迟不输出。前者降低质量后者拖慢效率都是“变笨”的典型表现。这个问题在自动化流水线里最常见。Agent 生成的代码要通过下游脚本的格式校验一旦格式标准被 Skill 之间的冲突污染下游脚本就会频繁报错看起来像是 Agent 生成的代码质量变差了实际上问题出在 Skill 层。4. 怎么验证“Skill 越多越笨”一套可控的测量流程想证明“Skill 多了会变笨”不能靠感觉要有一组能重复运行的评估任务。下面的流程不需要复杂基建适合个人开发者直接照做也适合团队接入 CI。4.1 准备评估集从你实际的工作流里挑出 20 到 30 个有代表性的任务。不要只挑简单任务要覆盖三类核心高频任务、中等复杂任务、边缘长尾任务。每个任务要有明确的“通过标准”。建议用 JSONL 存储每一行是一个任务{id: 001, task: 审查这段代码的 SQL 注入风险, prompt_file: case001.py, pass_criteria: [报告包含 risk 等级, 指出危险行号]} {id: 002, task: 根据需求生成 REST API 的 OpenAPI 描述文件, prompt_file: case002.md, pass_criteria: [输出为 YAML, 包含 3 个以上 endpoint]}评估集的质量直接决定测量的可信度。通过标准越客观越好最好能由脚本自动校验而不是人工主观判断。如果必须人工判断至少要统一标准避免不同人打分的尺度不一致。4.2 设置对照组分别准备三套 Skill 配置空配置不启用任何 Skill核心配置只保留 5 个精心编写的高频 Skill全量配置把你收藏的全部 Skill 放入。用同一个 Agent 框架、同一个模型版本、同一份评估集跑三遍重点记录四个指标任务完成率、单任务平均 token 消耗、单任务平均步数、工具调用准确率。这里有个容易忽略的细节跑测试时模型版本必须固定温度参数也要固定否则你无法区分性能变化来自 Skill 数量还是模型随机性。建议每个配置至少跑两轮取平均值降低偶发因素干扰。4.3 统计对比指标空配置核心 5 个 Skill全量 50 个 Skill任务完成率基准值基准值 增量大概率回落平均 token最低适中明显上升平均步数低稳定上升工具调用准确率可能偏低最高下降这个实验的价值不在于证明“Skill 一定有害”而在于给你一个基线知道什么样的 Skill 数量对该模型、该任务集是拐点。不同模型对 Skill 数量的容忍度差别很大上下文窗口大、指令遵循能力强的模型可以扛住更多 Skill但拐点一定存在。数据出来之后你就能非常清楚地回答“我该留几个 Skill”这个问题了。4.4 用回归测试守护 Skill 变更把评估集变成日常 CI每次新增、修改、删除 Skill 后跑一遍如果核心任务完成率下降超过阈值就打回变更。这一步是把 Skill 管理从“凭感觉”升级成“看数据”的关键。具体实现上可以在 CI 里加一个任务检查 Skill 目录变更后自动触发评估集输出对比报告。evaluation: dataset: ./benchmark/tasks.jsonl variants: - name: skills_core skill_dir: ./skills/core - name: skills_all skill_dir: ./skills metrics: - task_completion_rate - avg_tokens_per_task - avg_steps_per_task - tool_accuracy threshold: completion_rate_delta: -0.05上面这段是 YAML 示例实际字段名要根据你使用的 Agent 框架调整但核心思想不变给 Skill 变更设置一个量化门槛越过门槛就禁止合并。5. Skill 多久算多数量阈值与质量权重很多人会问一个直接的问题到底多少个 Skill 合适诚实地说没有统一的魔法数字它取决于模型上下文窗口、Skill 文件长度、路由机制和任务复杂度。但可以从工程经验里总结几个判断标准。如果 Skill 全部静态注入系统提示总量建议控制在上下文窗口的 20% 以内留出足够空间给对话历史和工具返回。如果框架支持按需检索注入总量可以放宽但前提是每个 Skill 的描述质量过关并且检索 Top-K 限制合理。判断阈值的核心指标是“工具调用准确率”一旦发现在正确场景下不触发正确 Skill 的失败率上升说明 Skill 数量已经超过该模型的合理负载。这里要强调一个关键认知Skill 的质量权重远大于数量。一个 500 token、写清楚触发条件和步骤的 Skill效果可能好过五个各 2000 token、描述含糊的 Skill。与其囤积不如先保证每个 Skill 都有明确的价值、明确的触发条件和可验收的输出格式。一个 Skill 如果面临以下情况之一就应该被合并或删除过去两周没有任何实际触发触发条件下与另一个 Skill 重叠超过 50%正文里有自相矛盾的规则描述超过 200 字还说不清适用场景。6. Skill 工程化管理从“囤积”到“治理”6.1 目录结构建议按层级组织 Skill而不是平铺一层塞进去。层级的好处是核心链路只加载必要部分低频能力保留但降低优先级实验性能力隔离观察废弃能力不再注入上下文。skills/ ├── core/ # 高频、稳定的核心 Skill │ ├── code-review/ │ ├── commit-message/ │ └── test-generation/ ├── domain/ # 按领域拆分的中频 Skill │ ├── docker-debug/ │ ├── api-design/ │ └── sql-optimization/ ├── experimental/ # 验证期的 Skill │ └── legacy-migration/ └── deprecated/ # 不再启用的 Skill保留但不注入 └── old-format/把 Skill 分成 core、domain、experimental、deprecated 四层在配置里只启用对应层级。experimental 目录里的 Skill 默认不注入主链路你想验证时手动启用deprecated 目录里的 Skill 只是存档防止有人误用。这样既不影响增量探索也不污染主链路。6.2 SKILL.md 的描述规范一个 Skill 能不能被正确路由description 是第一决定因素。建议遵循下面这套规范用动词开头比如“审查”“生成”“修复”不要用名词短语明确触发条件写清楚“当……时触发”并给出不触发的反例控制描述长度description 控制在 100 到 200 字正文放详细步骤写明输出格式让模型知道做完后应该交付什么标注依赖和边界依赖哪些 MCP 工具、禁止做什么。--- name: docker-debug description: 诊断 Docker 容器启动失败和网络不通问题。当用户报告 docker logs 有报错、容器一直 Exited、或需要排查 compose 配置时触发。不用于容器镜像构建优化。 ---上面这个描述只有几十字但包含触发条件和反例边界比“通用 Docker 帮助”这种描述可路由得多。写 description 时可以把自己当成搜索引擎的召回工程师如果模型不知道你的词表它就无法在正确的场景里召回这个 Skill。6.3 冲突检测写一个小的检查脚本扫描所有 Skill 的描述和关键词找出明显重叠的部分。两个方面的冲突要重点查触发条件重叠、输出格式矛盾。下面给一个基础版脚本import os import re def extract_trigger(path): with open(path, encodingutf-8) as f: content f.read() m re.search(rtrigger:\s*(.), content) return m.group(1) if m else def detect_overlap(skill_dir): skills {} for root, _, files in os.walk(skill_dir): for name in files: if name SKILL.md: path os.path.join(root, name) skills[os.path.basename(root)] extract_trigger(path) for a in skills: for b in skills: if a b: aw set(skills[a].split()) bw set(skills[b].split()) inter aw bw if len(inter) 3: print(f疑似冲突: {a} - {b}, 共同词: {inter}) detect_overlap(./skills)这个脚本只是个起点生产环境可以接入向量相似度计算或 LLM 评审但原理一样尽量在合并前发现冲突而不是把冲突留给运行时去暴露。输出格式冲突更隐蔽建议在脚本里正则扫描各个 SKILL.md 中的code、status等字段定义人为比对一遍。6.4 版本控制与变更记录Skill 是代码资产必须走版本控制。每次修改 Skill 都要写清变更原因并且把“该变更解决了什么问题”关联到具体任务。不要在 Agent 目录里改完就上线至少保留一个可回滚的 Release 标记。团队协作时Skill 变更要像代码评审一样走 review提交后由另一个熟悉该领域的人确认确认重点包括描述是否准确、触发条件是否清晰、是否与其他 Skill 冲突。7. Skill 数量膨胀时的性能观察方法如果你已经有一堆 Skill先别急着删先量化一下当前的状态。三个观察维度值得做统计注入 token、观察单任务 token 与步数、观察批处理稳定性。7.1 统计注入 token写一个小脚本统计 Skill 目录总 token 数。不同模型编码不同实际以模型 tokenizer 为准下面给一个估算脚本import os import tiktoken def count_skill_tokens(skill_dir: str) - dict: enc tiktoken.get_encoding(cl100k_base) result {} total 0 for root, _, files in os.walk(skill_dir): for name in files: if name.endswith((.md, .mdx)): fp os.path.join(root, name) with open(fp, encodingutf-8) as f: content f.read() tokens len(enc.encode(content)) result[fp] tokens total tokens result[_total] total return result stats count_skill_tokens(./skills) print(fSkill 总 token: {stats[_total]})如果总 token 已经接近模型上下文窗口的三分之一以上建议立刻启用按需加载或者删减低频 Skill。这里要特别提醒tiktoken 只是估算不同模型的实际编码效率不同但用于横向对比 Skill 目录的膨胀趋势已经足够。7.2 观察单任务 token 与步数在 Agent 日志里记录每个任务的输入 token、输出 token、推理步数和工具调用次数。Skill 膨胀的典型信号是步数上升但任务完成率不升或者工具调用次数增加但有效调用比例下降。这些信号比“感觉变笨了”可靠得多可以在日志采集阶段就加上避免事后补数据。7.3 观察批处理稳定性如果你用 Agent 跑批量任务重点关注批量任务的中断率和重试率。Skill 越多单任务在中间步骤出错的可能性越大批量任务队列里的重试和失败率会明显上升。这是资源占用之外最直接的稳定性信号。批量任务建议加日志和指标上报任务失败时记录 Skill 调用序列方便归因。8. 常见问题与排查方法问题现象可能原因排查方式解决方案该触发 Skill 时不触发description 缺少触发条件或关键词不匹配检查 SKILL.md 的 trigger 字段按 6.2 规范重写 description调用错误的 Skill多个 Skill 描述重叠或命名相似运行冲突检测脚本合并重叠 Skill重命名输出格式与预期不符多个 Skill 定义了不同输出格式搜索所有 SKILL.md 中的输出格式部分统一为一份全局格式规范对话稍长就开始忘事Skill 静态注入占用上下文过多统计 Skill token 总量启用按需加载或删减任务变慢、步数暴增Skill 候选空间过大对比单任务平均步数按层级裁剪加了一个 Skill 后旧任务失败新 Skill 与旧规则冲突跑回归评估集定位冲突并调整批量任务失败率上升路由误判累积查失败任务日志里的 Skill 调用序列降低全量 Skill 层级只保留 core排查顺序建议是从外到内先看日志定位是第几步失败的再查该步骤命中了哪些 Skill再看 Skill 的加载位置和描述是否匹配。如果日志里完全没有 Skill 调用记录优先怀疑触发条件写错了如果调用了但输出格式不对优先怀疑格式冲突。9. 团队协作中的 Skill 治理个人开发者的 Skill 泛滥问题在团队里会变成更大的灾难。一个团队通常有后端、前端、算法、运维多个角色每个角色都有一套“好用”的 Skill如果全部合入公共库Agent 的上下文会立刻爆炸。团队级 Skill 治理至少要定三件事。第一Skill 分级评审。新增 Skill 不是想加就加要回答三个问题它解决的问题是否已经被现有 Skill 覆盖它的触发条件是否与现有 Skill 冲突它能用 100 字以内说明白吗答不上来就进 experimental 目录先观察观察期结束再决定是否转正。这里的核心是让“加 Skill”这个动作变得有成本有成本才会克制。第二定期裁剪。每个迭代末跑一次评估集统计哪些 Skill 在真实任务中被调用。连续两个迭代零调用的 Skill要么重写触发条件要么移入 deprecated。保留它们没有意义只会不断稀释核心 Skill 的注意力。裁剪不是删除而是降级真的需要时还能找回。第三共享基准。团队的 Skill 库要绑定一个公共评估集至少覆盖每个角色的典型任务。任何 Skill 变更都要过回归防止“修好一个角色的任务、弄坏另一个角色任务”的连锁反应。共享基准的意义不仅是质量保障更是团队对“什么算好”达成共识的载体。10. 总结与下一步建议先回到最初的问题Skill 越多Agent 越笨根因不是 Skill 机制本身而是上下文膨胀、路由误判、指令冲突和规划开销四条链路同时恶化。Skill 更像是一种需要做减法管理的能力资产而不是越多越好的收藏品。如果你现在正被这个问题困扰按下面这个顺序做第一步先量化统计当前 Skill 总 token 数记录最近一批任务的完成率、步数和失败原因没有数据之前不要删任何 Skill第二步砍到核心集把高频、高质量、无冲突的 Skill 放到 core 层其余全部降级跑一周真实任务对比完成率第三步建立回归集沉淀 20 到 30 个有明确通过标准的任务以后每次 Skill 变更都跑一遍第四步再谈扩展当核心集稳定后通过 experimental 层级小步引入新 Skill用数据决定是否转正。下一步可以继续深入的方向有两个一是给 Skill 库接入向量检索实现真正的按需加载而不是全部塞进上下文二是用 LLM 做 Skill 路由的预筛层把“选哪个 Skill”从模型主推理中分离出去。这两条路都能有效拉高 Skill 数量的容忍上限但前提都是先把基础治理做好。建议收藏备用。等你下次看到一份“最强 100 Skill 合集”时先问自己一句这 100 个 Skill 放进上下文我的 Agent 到底是变强了还是只是看起来变强了 AI Agent的Skill越多越笨？真相与工程化解法
如果你把“能用上的能力”全部做成 Skill 塞给 AI Agent结果大概率不是全能而是全不能。Skill 从 5 个加到 50 个代码审查没有更仔细反而连“该不该调用 Skill”这种最简单的判断都开始出错。这个现象在 2026 年的 AI Coding Agent 生态里越来越普遍尤其是围绕 Claude Code Skill、Codex Skill、Cursor Skill 和各类开源 Skill 库的讨论中几乎每个技术群里都能看到类似的吐槽。先给结论Skill 数量与 Agent 能力不是单调递增关系而是典型的“先升后降”。初期加几个高质量的 Skill任务完成率和输出规范性会明显改善超过一定数量后上下文膨胀、路由误判、指令冲突、规划开销这几个因素会同时恶化最终表现为 Agent 变笨。这篇文章不打算劝你“不要用 Skill”而是把背后的机制拆开给你一套可以自己验证、自己管理的 Skill 工程化方案。本文会覆盖五件事Skill 与 MCP、插件、Prompt 的区别Skill 过多导致性能下降的核心原因如何用一套可控的实验流程测量“Skill 多 vs Skill 少”的差异Skill 库的目录、命名、评估和治理规范以及常见问题排查清单。适合正在搭建 Agent Skill 库的开发者、给团队设计 AI 编码规范的工程负责人以及被“装了一堆 Skill 反而更慢”困扰的人。1. 核心问题速览先看清这个“越装越笨”问题长什么样。它不是某一个环节出错而是多个机制叠加后的综合表现所以排查起来往往比普通 Bug 更隐蔽。现象具体表现根因方向上下文拥挤对话轮次稍长就丢信息命令执行到一半忘了前提Skill 文件注入 token 过多路由误判任务该用 A Skill模型却调了 B Skill或不触发任何 Skill描述重叠、命名模糊指令冲突两个 Skill 对同一类输出给出不同格式模型反复横跳规则互相矛盾决策变慢每次任务前枚举候选 Skill 的时间明显变长候选空间膨胀自查失效Agent 完成输出后无法判断是否符合预期验收标准被多个 Skill 稀释回归难定位加一个新 Skill 后旧任务开始失败缺乏评估集和回归机制从材料看2026 年 AI Coding Agent 的 Skill 生态已经非常丰富OpenCode、Cursor、Claude Code、Codex 都支持类似 Skill 的机制第三方 Skill 库和 Skill 推荐内容也大量出现。但生态越繁荣越容易出现“看到什么 Skill 都想要”的囤积行为。结果就是 Agent 的工具列表和系统提示越来越长核心能力反而被淹没。这个问题的本质不是 Skill 机制的缺陷而是缺少工程化治理。很多人把 Skill 当成插件来安装装完就以为能力自动叠加实际上每个 Skill 都会改变模型的决策空间和上下文环境。接下来我们先明确 Skill 的定义再拆解性能衰减的因果链。2. Skill 到底是什么先看清它和 MCP、Prompt 的关系2.1 Skill 的定义Skill 在 AI Agent 语境里通常指一段结构化的“过程性知识”。它告诉模型面对某类任务时应该按什么步骤做、遵循什么规则、输出什么格式。一个 Skill 一般包含名称、描述、触发条件、操作步骤、示例和边界。与一次性 Prompt 不同Skill 是可复用、可版本化、可跨任务复用的行为资产。典型的 Skill 文件长这样--- name: code-review description: 对代码变更进行审查重点检查安全问题、性能风险和可读性。 trigger: 当用户请求 review 代码、提交 PR、或要求检查代码质量时触发。 priority: high --- ## 执行步骤 1. 读取 diff标注修改涉及的文件和函数。 2. 按优先级检查安全问题 性能风险 可读性。 3. 对每个问题输出文件路径、行号、问题描述、修改建议。 4. 如果没有问题明确输出 PASS。 ## 输出格式 { ok: true, issues: [] } ## 边界 不修改代码只输出审查结论。不要在无 diff 的情况下列出假设性问题。这段内容看似简单但“把它放在哪、什么时候被加载、如何被筛选”直接决定了 Agent 的聪明程度。不同实现里Skill 可能被静态追加到系统提示可能按关键词或向量检索后动态注入也可能作为一个工具由模型主动调用或者由外层 Router 模型预筛后再注入。加载机制不同Skill 数量对性能的影响幅度也不同。2.2 Skill 与 MCP 的区别很多人会把 Skill 和 MCP 混在一起但从功能边界上它们完全不同。Skill 回答的是“模型应该怎么做”MCP 回答的是“模型能碰到什么”。MCP 提供外部工具和数据源连接Skill 负责教模型如何编排和使用这些能力。两者常常配合使用Skill 里可以编排对 MCP 工具的调用顺序MCP 提供底层能力。维度SkillMCP回答的问题模型“怎么做”模型“能碰什么”内容形态步骤、规则、示例、边界工具定义、数据源连接消耗方式占用推理上下文和决策空间占用工具列表和调用通道典型来源编码规范、工作流、领域知识数据库、浏览器、文件系统、第三方 API变更影响影响输出质量和行为风格影响能力半径和副作用风险但要注意MCP 连接多了同样会增加模型选择工具的难度。Tools 列表膨胀会拉长模型在“选哪个工具”上的判断时间甚至漏选正确工具。这个问题和 Skill 过多是同一类“决策空间膨胀”问题只是表现路径不同。所以治理 Skill 的同时也要顺手清理低价值的 MCP 连接。2.3 Skill 与 Prompt 的关系Prompt 是一次性、面向单个任务的指令Skill 是可复用、可版本化、跨任务复用的行为包。好的 Skill 本质上是把反复编写的 Prompt 沉淀成了资产但如果只做沉淀不做治理Skill 就会退化成一堆互相打架的 Prompt。很多团队的 Skill 库没有评审、没有冲突检测、没有废弃机制最后膨胀到连管理员自己都不知道哪些还能用、哪些已经过时。判断一个能力到底该写成 Prompt 还是 Skill可以看两点它是否会被反复触发它的规则是否需要跨多个任务保持一致两个答案都是“是”才值得沉淀成 Skill。低频、一次性、强任务耦合的指令留在 Prompt 里反而更灵活。3. 为什么 Skill 越多Agent 反而越笨这是本文的核心章节。Skill 数量上升时至少五条因果链同时恶化而且它们之间还会互相放大。3.1 上下文膨胀稀释注意力模型每一步推理都要把当前可见的 Skill 内容计入上下文。假设一个 Skill 平均 1500 token50 个 Skill 就是 75000 token这还没算对话历史、代码 diff 和工具返回结果。上下文窗口是有限的Skill 占得越多留给任务本身的注意力分配就越少。尤其是“Lost in the Middle”问题窗口中间的 Skill 描述往往被模型忽略真正被记住的只有开头和结尾。这不是玄学而是 Transformer 注意力机制的实际表现。你在系统提示里放了 50 条规则模型在长对话后真正遵守的可能只有最靠前和最靠后的几条。所以你会看到Skill 多的 Agent反而在“按规则做事”上表现更差。很多用户反馈“规则写了等于没写”排查到最后发现是 Skill 总量把注意力稀释掉了。3.2 路由误判Skill 选择本身成了一个困难任务Agent 在执行任务前要先判断“该用哪个 Skill”。候选越少这个判断越简单候选越多判断越难。尤其是当多个 Skill 的描述高度相似时模型很容易选错。路由一旦出错后面的步骤全部建立在错误前提上Agent 的表现自然越来越差而且这种失败往往要到任务执行中段才能被发现浪费的 token 和步骤已经不可回收。常见的路由失败模式有四种描述泛化一个 Skill 写“处理各种开发任务”另一个写“处理通用编程问题”模型分不清边界随机挑一个命名混淆api-test和api-tester并存模型选了旧的过时版本触发条件缺失Skill 正文很详细但 description 没写“什么时候用”模型在需要时根本不触发长尾淹没高频低频 Skill 和核心 Skill 放在同一层核心 Skill 的触发率被稀释。3.3 指令冲突导致行为摇摆Skill 不是孤立存在的。当你从不同作者、不同仓库、不同版本里收集 Skill 时冲突几乎是必然的。最简单的例子Skill A 要求所有 API 调用使用axiosSkill B 要求所有 HTTP 请求统一走fetch封装层Skill C 又规定“第三方 SDK 优先不要自己写 HTTP”。三条规则单独看都没问题同时出现在上下文里时模型面对一个网络请求任务会陷入自我矛盾。更隐蔽的是输出格式冲突。一个 Skill 要求 JSON 输出带code字段另一个要求带status字段模型在两个标准之间横跳下游脚本跟着崩。这种冲突不会在单个 Skill 的测试里暴露只会在全量集成后出现所以特别难排查。排查时往往要逐个比对 SKILL.md 里的格式定义效率极低。3.4 规划开销与决策延迟Agent 的推理过程可以理解为在“可用操作集合”上做搜索。Skill 越多操作集合越大搜索分支越多模型需要更多步骤才能收敛到正确的执行路径。表现就是任务开始前的“思考”变长中间走到错误分支的概率变大失败后重试的次数也变多。在批量任务场景中这个问题会被放大如果一个 Agent 每天要处理几百个任务每个任务因为 Skill 路由多消耗 20% 的 token累计成本几乎等同于平白多跑了一轮任务。从性能观察的角度看“平均步数上升但任务完成率不升”是一个典型信号。如果你在 Agent 日志里看到推理步数持续上涨而任务成功率没有对应提升首先应该怀疑的可不只是模型能力而是候选 Skill 空间过于庞大。3.5 验收标准稀释Agent 不知道什么叫“做好了”Skill 里通常包含输出格式和验收标准。当多个 Skill 同时存在时模型手头可能有五套不同的“成功标准”。它执行完任务后无法判断当前结果到底符合哪一套。这会导致两种行为要么随意选一个标准自我满足要么反复自查、迟迟不输出。前者降低质量后者拖慢效率都是“变笨”的典型表现。这个问题在自动化流水线里最常见。Agent 生成的代码要通过下游脚本的格式校验一旦格式标准被 Skill 之间的冲突污染下游脚本就会频繁报错看起来像是 Agent 生成的代码质量变差了实际上问题出在 Skill 层。4. 怎么验证“Skill 越多越笨”一套可控的测量流程想证明“Skill 多了会变笨”不能靠感觉要有一组能重复运行的评估任务。下面的流程不需要复杂基建适合个人开发者直接照做也适合团队接入 CI。4.1 准备评估集从你实际的工作流里挑出 20 到 30 个有代表性的任务。不要只挑简单任务要覆盖三类核心高频任务、中等复杂任务、边缘长尾任务。每个任务要有明确的“通过标准”。建议用 JSONL 存储每一行是一个任务{id: 001, task: 审查这段代码的 SQL 注入风险, prompt_file: case001.py, pass_criteria: [报告包含 risk 等级, 指出危险行号]} {id: 002, task: 根据需求生成 REST API 的 OpenAPI 描述文件, prompt_file: case002.md, pass_criteria: [输出为 YAML, 包含 3 个以上 endpoint]}评估集的质量直接决定测量的可信度。通过标准越客观越好最好能由脚本自动校验而不是人工主观判断。如果必须人工判断至少要统一标准避免不同人打分的尺度不一致。4.2 设置对照组分别准备三套 Skill 配置空配置不启用任何 Skill核心配置只保留 5 个精心编写的高频 Skill全量配置把你收藏的全部 Skill 放入。用同一个 Agent 框架、同一个模型版本、同一份评估集跑三遍重点记录四个指标任务完成率、单任务平均 token 消耗、单任务平均步数、工具调用准确率。这里有个容易忽略的细节跑测试时模型版本必须固定温度参数也要固定否则你无法区分性能变化来自 Skill 数量还是模型随机性。建议每个配置至少跑两轮取平均值降低偶发因素干扰。4.3 统计对比指标空配置核心 5 个 Skill全量 50 个 Skill任务完成率基准值基准值 增量大概率回落平均 token最低适中明显上升平均步数低稳定上升工具调用准确率可能偏低最高下降这个实验的价值不在于证明“Skill 一定有害”而在于给你一个基线知道什么样的 Skill 数量对该模型、该任务集是拐点。不同模型对 Skill 数量的容忍度差别很大上下文窗口大、指令遵循能力强的模型可以扛住更多 Skill但拐点一定存在。数据出来之后你就能非常清楚地回答“我该留几个 Skill”这个问题了。4.4 用回归测试守护 Skill 变更把评估集变成日常 CI每次新增、修改、删除 Skill 后跑一遍如果核心任务完成率下降超过阈值就打回变更。这一步是把 Skill 管理从“凭感觉”升级成“看数据”的关键。具体实现上可以在 CI 里加一个任务检查 Skill 目录变更后自动触发评估集输出对比报告。evaluation: dataset: ./benchmark/tasks.jsonl variants: - name: skills_core skill_dir: ./skills/core - name: skills_all skill_dir: ./skills metrics: - task_completion_rate - avg_tokens_per_task - avg_steps_per_task - tool_accuracy threshold: completion_rate_delta: -0.05上面这段是 YAML 示例实际字段名要根据你使用的 Agent 框架调整但核心思想不变给 Skill 变更设置一个量化门槛越过门槛就禁止合并。5. Skill 多久算多数量阈值与质量权重很多人会问一个直接的问题到底多少个 Skill 合适诚实地说没有统一的魔法数字它取决于模型上下文窗口、Skill 文件长度、路由机制和任务复杂度。但可以从工程经验里总结几个判断标准。如果 Skill 全部静态注入系统提示总量建议控制在上下文窗口的 20% 以内留出足够空间给对话历史和工具返回。如果框架支持按需检索注入总量可以放宽但前提是每个 Skill 的描述质量过关并且检索 Top-K 限制合理。判断阈值的核心指标是“工具调用准确率”一旦发现在正确场景下不触发正确 Skill 的失败率上升说明 Skill 数量已经超过该模型的合理负载。这里要强调一个关键认知Skill 的质量权重远大于数量。一个 500 token、写清楚触发条件和步骤的 Skill效果可能好过五个各 2000 token、描述含糊的 Skill。与其囤积不如先保证每个 Skill 都有明确的价值、明确的触发条件和可验收的输出格式。一个 Skill 如果面临以下情况之一就应该被合并或删除过去两周没有任何实际触发触发条件下与另一个 Skill 重叠超过 50%正文里有自相矛盾的规则描述超过 200 字还说不清适用场景。6. Skill 工程化管理从“囤积”到“治理”6.1 目录结构建议按层级组织 Skill而不是平铺一层塞进去。层级的好处是核心链路只加载必要部分低频能力保留但降低优先级实验性能力隔离观察废弃能力不再注入上下文。skills/ ├── core/ # 高频、稳定的核心 Skill │ ├── code-review/ │ ├── commit-message/ │ └── test-generation/ ├── domain/ # 按领域拆分的中频 Skill │ ├── docker-debug/ │ ├── api-design/ │ └── sql-optimization/ ├── experimental/ # 验证期的 Skill │ └── legacy-migration/ └── deprecated/ # 不再启用的 Skill保留但不注入 └── old-format/把 Skill 分成 core、domain、experimental、deprecated 四层在配置里只启用对应层级。experimental 目录里的 Skill 默认不注入主链路你想验证时手动启用deprecated 目录里的 Skill 只是存档防止有人误用。这样既不影响增量探索也不污染主链路。6.2 SKILL.md 的描述规范一个 Skill 能不能被正确路由description 是第一决定因素。建议遵循下面这套规范用动词开头比如“审查”“生成”“修复”不要用名词短语明确触发条件写清楚“当……时触发”并给出不触发的反例控制描述长度description 控制在 100 到 200 字正文放详细步骤写明输出格式让模型知道做完后应该交付什么标注依赖和边界依赖哪些 MCP 工具、禁止做什么。--- name: docker-debug description: 诊断 Docker 容器启动失败和网络不通问题。当用户报告 docker logs 有报错、容器一直 Exited、或需要排查 compose 配置时触发。不用于容器镜像构建优化。 ---上面这个描述只有几十字但包含触发条件和反例边界比“通用 Docker 帮助”这种描述可路由得多。写 description 时可以把自己当成搜索引擎的召回工程师如果模型不知道你的词表它就无法在正确的场景里召回这个 Skill。6.3 冲突检测写一个小的检查脚本扫描所有 Skill 的描述和关键词找出明显重叠的部分。两个方面的冲突要重点查触发条件重叠、输出格式矛盾。下面给一个基础版脚本import os import re def extract_trigger(path): with open(path, encodingutf-8) as f: content f.read() m re.search(rtrigger:\s*(.), content) return m.group(1) if m else def detect_overlap(skill_dir): skills {} for root, _, files in os.walk(skill_dir): for name in files: if name SKILL.md: path os.path.join(root, name) skills[os.path.basename(root)] extract_trigger(path) for a in skills: for b in skills: if a b: aw set(skills[a].split()) bw set(skills[b].split()) inter aw bw if len(inter) 3: print(f疑似冲突: {a} - {b}, 共同词: {inter}) detect_overlap(./skills)这个脚本只是个起点生产环境可以接入向量相似度计算或 LLM 评审但原理一样尽量在合并前发现冲突而不是把冲突留给运行时去暴露。输出格式冲突更隐蔽建议在脚本里正则扫描各个 SKILL.md 中的code、status等字段定义人为比对一遍。6.4 版本控制与变更记录Skill 是代码资产必须走版本控制。每次修改 Skill 都要写清变更原因并且把“该变更解决了什么问题”关联到具体任务。不要在 Agent 目录里改完就上线至少保留一个可回滚的 Release 标记。团队协作时Skill 变更要像代码评审一样走 review提交后由另一个熟悉该领域的人确认确认重点包括描述是否准确、触发条件是否清晰、是否与其他 Skill 冲突。7. Skill 数量膨胀时的性能观察方法如果你已经有一堆 Skill先别急着删先量化一下当前的状态。三个观察维度值得做统计注入 token、观察单任务 token 与步数、观察批处理稳定性。7.1 统计注入 token写一个小脚本统计 Skill 目录总 token 数。不同模型编码不同实际以模型 tokenizer 为准下面给一个估算脚本import os import tiktoken def count_skill_tokens(skill_dir: str) - dict: enc tiktoken.get_encoding(cl100k_base) result {} total 0 for root, _, files in os.walk(skill_dir): for name in files: if name.endswith((.md, .mdx)): fp os.path.join(root, name) with open(fp, encodingutf-8) as f: content f.read() tokens len(enc.encode(content)) result[fp] tokens total tokens result[_total] total return result stats count_skill_tokens(./skills) print(fSkill 总 token: {stats[_total]})如果总 token 已经接近模型上下文窗口的三分之一以上建议立刻启用按需加载或者删减低频 Skill。这里要特别提醒tiktoken 只是估算不同模型的实际编码效率不同但用于横向对比 Skill 目录的膨胀趋势已经足够。7.2 观察单任务 token 与步数在 Agent 日志里记录每个任务的输入 token、输出 token、推理步数和工具调用次数。Skill 膨胀的典型信号是步数上升但任务完成率不升或者工具调用次数增加但有效调用比例下降。这些信号比“感觉变笨了”可靠得多可以在日志采集阶段就加上避免事后补数据。7.3 观察批处理稳定性如果你用 Agent 跑批量任务重点关注批量任务的中断率和重试率。Skill 越多单任务在中间步骤出错的可能性越大批量任务队列里的重试和失败率会明显上升。这是资源占用之外最直接的稳定性信号。批量任务建议加日志和指标上报任务失败时记录 Skill 调用序列方便归因。8. 常见问题与排查方法问题现象可能原因排查方式解决方案该触发 Skill 时不触发description 缺少触发条件或关键词不匹配检查 SKILL.md 的 trigger 字段按 6.2 规范重写 description调用错误的 Skill多个 Skill 描述重叠或命名相似运行冲突检测脚本合并重叠 Skill重命名输出格式与预期不符多个 Skill 定义了不同输出格式搜索所有 SKILL.md 中的输出格式部分统一为一份全局格式规范对话稍长就开始忘事Skill 静态注入占用上下文过多统计 Skill token 总量启用按需加载或删减任务变慢、步数暴增Skill 候选空间过大对比单任务平均步数按层级裁剪加了一个 Skill 后旧任务失败新 Skill 与旧规则冲突跑回归评估集定位冲突并调整批量任务失败率上升路由误判累积查失败任务日志里的 Skill 调用序列降低全量 Skill 层级只保留 core排查顺序建议是从外到内先看日志定位是第几步失败的再查该步骤命中了哪些 Skill再看 Skill 的加载位置和描述是否匹配。如果日志里完全没有 Skill 调用记录优先怀疑触发条件写错了如果调用了但输出格式不对优先怀疑格式冲突。9. 团队协作中的 Skill 治理个人开发者的 Skill 泛滥问题在团队里会变成更大的灾难。一个团队通常有后端、前端、算法、运维多个角色每个角色都有一套“好用”的 Skill如果全部合入公共库Agent 的上下文会立刻爆炸。团队级 Skill 治理至少要定三件事。第一Skill 分级评审。新增 Skill 不是想加就加要回答三个问题它解决的问题是否已经被现有 Skill 覆盖它的触发条件是否与现有 Skill 冲突它能用 100 字以内说明白吗答不上来就进 experimental 目录先观察观察期结束再决定是否转正。这里的核心是让“加 Skill”这个动作变得有成本有成本才会克制。第二定期裁剪。每个迭代末跑一次评估集统计哪些 Skill 在真实任务中被调用。连续两个迭代零调用的 Skill要么重写触发条件要么移入 deprecated。保留它们没有意义只会不断稀释核心 Skill 的注意力。裁剪不是删除而是降级真的需要时还能找回。第三共享基准。团队的 Skill 库要绑定一个公共评估集至少覆盖每个角色的典型任务。任何 Skill 变更都要过回归防止“修好一个角色的任务、弄坏另一个角色任务”的连锁反应。共享基准的意义不仅是质量保障更是团队对“什么算好”达成共识的载体。10. 总结与下一步建议先回到最初的问题Skill 越多Agent 越笨根因不是 Skill 机制本身而是上下文膨胀、路由误判、指令冲突和规划开销四条链路同时恶化。Skill 更像是一种需要做减法管理的能力资产而不是越多越好的收藏品。如果你现在正被这个问题困扰按下面这个顺序做第一步先量化统计当前 Skill 总 token 数记录最近一批任务的完成率、步数和失败原因没有数据之前不要删任何 Skill第二步砍到核心集把高频、高质量、无冲突的 Skill 放到 core 层其余全部降级跑一周真实任务对比完成率第三步建立回归集沉淀 20 到 30 个有明确通过标准的任务以后每次 Skill 变更都跑一遍第四步再谈扩展当核心集稳定后通过 experimental 层级小步引入新 Skill用数据决定是否转正。下一步可以继续深入的方向有两个一是给 Skill 库接入向量检索实现真正的按需加载而不是全部塞进上下文二是用 LLM 做 Skill 路由的预筛层把“选哪个 Skill”从模型主推理中分离出去。这两条路都能有效拉高 Skill 数量的容忍上限但前提都是先把基础治理做好。建议收藏备用。等你下次看到一份“最强 100 Skill 合集”时先问自己一句这 100 个 Skill 放进上下文我的 Agent 到底是变强了还是只是看起来变强了