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 更隐蔽。

从材料看，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 提供底层能力。

但要注意，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 token，50 个 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 调用使用axios，Skill 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 统计对比

这个实验的价值不在于证明“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, encoding="utf-8") as f: content = f.read() m = re.search(r"trigger:\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, encoding="utf-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(f"Skill 总 token: {stats['_total']}")

如果总 token 已经接近模型上下文窗口的三分之一以上，建议立刻启用按需加载，或者删减低频 Skill。这里要特别提醒：tiktoken 只是估算，不同模型的实际编码效率不同，但用于横向对比 Skill 目录的膨胀趋势已经足够。

7.2 观察单任务 token 与步数

在 Agent 日志里记录每个任务的输入 token、输出 token、推理步数和工具调用次数。Skill 膨胀的典型信号是：步数上升但任务完成率不升，或者工具调用次数增加但有效调用比例下降。这些信号比“感觉变笨了”可靠得多，可以在日志采集阶段就加上，避免事后补数据。

7.3 观察批处理稳定性

如果你用 Agent 跑批量任务，重点关注批量任务的中断率和重试率。Skill 越多，单任务在中间步骤出错的可能性越大，批量任务队列里的重试和失败率会明显上升。这是资源占用之外最直接的稳定性信号。批量任务建议加日志和指标上报，任务失败时记录 Skill 调用序列，方便归因。

8. 常见问题与排查方法

排查顺序建议是从外到内：先看日志定位是第几步失败的，再查该步骤命中了哪些 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 到底是变强了，还是只是看起来变强了？