AI Agent技能过多反而变笨？Skill治理与上下文优化实战指南

当你在 AI Agent 里不断追加 Skill 时，很容易产生一个直觉：技能越全，Agent 应该越聪明。但实际运行中，大量团队发现现象恰好相反——Skill 从十几个涨到几十个之后，模型的工具选择开始飘忽，任务执行经常绕远路，甚至把不该调用的能力误触发，整体回答质量反而下降。这个现象背后并不是模型变笨了，而是 Skill 在每一轮推理里都在占用上下文、影响选择、改变行为偏好。下面从 Skill 的工作原理讲起，拆解 Skill 数量导致 Agent 变笨的原因，再给出一套可以落地验证的优化方案，帮助你把技能库从“越攒越多”变成“越用越稳”。如果你正在维护一个多技能 Agent，或者准备给 Agent 接入新的 Skill，先不要急着加功能，停下来看几轮日志和 token 使用情况，可能比继续堆 Skill 更有效。

1. 先搞清楚 Skill 在 Agent 中的地位：能力扩展件，也是提示词的一部分

1.1 Skill 是什么：从“工具函数”到“行为指令包”

通俗理解，Skill 是给 Agent 预设的一套“做某件事的方法说明”。它不只是给模型暴露一个函数接口，而是把“什么时候用、按什么顺序做、要避免什么、输出什么格式”这些规则统统打包。单个 Tool 往往是一段可调用的函数或 API；Skill 则处于更高的抽象层，通常包含触发条件、步骤说明、约束规则、示例输出，有时还附带脚本和资源。

技术定义上，Skill 是 Agent 运行时注入到模型上下文中的一组结构化指令和可选执行代码。它与 Function Calling 的区别在于：Function Calling 更多是把函数签名当作模型可选择的动作集合，而 Skill 在动作之外还携带完成这件事的方法论。它和 MCP 的关系也值得注意：MCP 用于统一不同外部工具和数据的访问协议，主要解决“怎么调用”的问题；Skill 解决“什么时候调用、按什么规范执行”的问题。两者可以共存，但 Skill 的指令并不一定走 MCP 通道，它首先影响的是模型在计划阶段的行为。

放在当前项目里看，当你给自己的 Agent 加一个“根据日志统计异常分布”的 Skill 时，你添加的不是一个普通函数，而是一段类似软件的操作手册：它应该说明日志来源、时间范围、聚合字段、输出格式、阈值提醒方式。模型拿到这个 Skill 后，遇到日志分析任务时会按你定义的流程执行，而不是临时猜测怎么做。

容易误解的地方是：Skill 数量代表的是“可用行为空间”，不代表“该轮任务实际用的行为”。可用的行为越多，模型在计划阶段需要评估的选项就越多。

1.2 为什么 Skill 越多并不会让 Agent 更聪明

先做一个粗略估算。假设每个 Skill 的元数据和指令平均占用 800 个 token，20 个 Skill 就是 1.6 万 token，50 个 Skill 就是 4 万 token。如果 Agent 的上下文窗口是 32K，50 个 Skill 已经超出窗口；即使窗口是 128K，这些指令也要和用户问题、历史对话、外部返回结果、模型自己的思考链一起竞争剩余空间。

更关键的是，这些 token 不是只在调用时才出现。在大多数实现里，Skill 列表会在每个请求开始时被加载，并作为系统提示或工具描述的一部分传给模型。用户输入很短、Skill 描述却很长时，模型的注意力会被大量“该做什么、不该做什么”的说明分散。模型并没有变笨，而是可用的推理余量被占用了。

从系统工程的角度理解，Agent 的“智能表现”取决于三者的比值：有效指令密度、上下文可用空间、任务信息完整度。Skill 变多时，分子不一定增加，分母却稳定增加，因此整体表现会下降。这也是为什么“Skill 越多越笨”不是玄学，而是一个上下文预算问题。

2. Agent 表现变差的四个核心机制：上下文挤占、选择偏差、指令冲突、评估失灵

2.1 上下文挤占：每轮推理都要为所有 Skill 买单

上下文挤占是最直接的机制。在常见 Agent 架构中，一次请求进入模型前，先要拼装 system prompt、Skill 集合、历史消息、工具结果等。Skill 越多，这条拼接后的输入越长。长上下文有两个代价：

第一是计算代价。模型处理每个 token 都要参与注意力计算，输入越长，首 token 延迟和成本越高。第二是效果代价。长上下文里，位置靠后的任务型指令容易被后续信息稀释，模型可能忘记某个 Skill 的关键约束。

实际项目里可以这样量化：

# 估算 Skill 描述对上下文的占用 # 以 OpenAI tiktoken 为例，用于估算 token 数量，不代表所有模型 import tiktoken enc = tiktoken.get_encoding("cl100k_base") def estimate_tokens(text: str) -> int: return len(enc.encode(text)) skills = [ "skill_log_analyzer: 分析应用日志并输出异常分布", "skill_config_checker: 校验配置文件并给出修复建议", ] for name in skills: print(f"{name} => {estimate_tokens(name)} tokens")

这里要注意：不同模型分词器不同，tiktoken 的估算只用于开发阶段；生产环境应以模型 tokenizer 为准。这个脚本可以放进 CI，新增 Skill 时自动检查描述长度。如果项目还没有 token 统计基础，可以在加入 Skill 前后分别跑同一批测试任务，对比输入的 token 总数和任务完成质量。

2.2 选择偏差：工具列表越长，选错工具的概率越高

Agent 在执行任务时会先决定调用哪个 Skill。Skill 列表越长，选项越多，模型需要区分不同 Skill 的边界就越困难。尤其是描述相似的 Skill，比如“分析日志”和“搜索日志”，“生成周报”和“汇总周报”，模型很容易把任务路由到错误的技能上。

出现这种问题时，典型日志会是这样：

{ "task": "统计今天订单接口的异常数量", "chosen_skill": "skill_log_search", "reason": "任务包含统计和异常，先搜索日志再统计", "error": "skill_log_search 只支持关键词检索，无法完成聚合统计" }

表面看模型给出了理由，但实际上它选择了能力不足的 Skill，导致任务多走了一轮。这类“看起来合理，实际选错”的情况，在 Skill 数量变多后会显著增多。处理方向不是取消选择机制，而是降低选择难度。一是把相似 Skill 合并，二是给每个 Skill 补充“适合场景”和“不适合场景”，三是引入路由层，在模型之前先按领域规则剪枝。

2.3 指令冲突：多个 Skill 的规则会在同一轮任务里相互打架

这是最容易忽略的问题。单个 Skill 单独测试时都很好，但当 Agent 一次加载多个 Skill 时，它们之间可能产生规则冲突。比如一个 Skill 要求“遇到不确定的 SQL 先解释风险”，另一个 Skill 要求“所有 SQL 必须加 LIMIT 100”，模型同时收到两条规则后，无法确定哪条优先。

冲突不一定表现为报错，更多表现为行为漂移：同一任务在两次运行中得到不同做法，一次严格加 LIMIT，一次没有加。这种不确定性会让人感觉“Agent 变笨了”，实际上是被冲突指令逼出了一种随机选择。

检测冲突比较有效的办法，是把所有 Skill 的“必须”“禁止”“优先”“除非”这类规则词抽取出来，放到同一张表里人工审查。也可以用回归测试反复跑同一批任务，观察输出是否稳定。

2.4 评估失灵：没有“边际收益”数据，Skill 只能越堆越多

最后一个机制来自团队管理层面。很多团队在评估 Agent 时只问一个问题：这个 Skill 有没有用。只要任务能跑通，就认为 Skill 有效，然后不断新增。几乎没有团队会问：新增的 Skill 让已有任务的成功率变高还是变低，让平均 token 消耗增加多少。

缺少边际收益评估是 Skill 爆炸的推手。因为负收益通常不会立刻浮现，等全量任务整体下滑时，已经很难定位是哪几个 Skill 造成的。为了判断一个 Skill 是否值得保留，至少需要记录三组数据：加载了这个 Skill 的任务成功率、同样任务在未加载该 Skill 时的成功率、加载前后 token 消耗变化。

评估失灵还会造成“Skill 冗余”。当多个 Skill 覆盖同一类需求时，模型并不知道哪个是权威版本，于是任务结果不稳定。要避免这个问题，必须把评估从“能不能用”升级为“加与不加到底差多少”。

3. 先判断你的 Agent 是不是被 Skill 拖累了：一套可操作的诊断流程

3.1 从日志里找“选择脆弱”的信号

在开始优化前，先确认问题是否由 Skill 体系导致。可以从日志里找几类典型信号：

第一类是路由漂移。同一任务在不同时间请求了不同 Skill，尤其是相似 Skill 之间反复横跳。第二类是能力误判。模型选择了某个 Skill，但执行时又说该 Skill 不适合，需要二次路由。第三类是上下文超限。请求因为输入超过限制被截断，截断部分往往包含最近几轮任务指令或工具输出。

如果日志系统还没有记录这些信息，建议先加一层请求级日志，至少包含以下字段：

{ "request_id": "req_20260812_0001", "task_type": "log_stats", "loaded_skills": ["skill_log_search", "skill_log_analyzer"], "chosen_skills": ["skill_log_search"], "used_skill": "skill_log_search", "retry_count": 1, "final_success": false, "input_tokens": 42113, "output_tokens": 1204 }

这段 JSON 是示例，实际字段可以根据框架调整。重点不是字段名，而是能回答“加载了什么、选择了什么、最终用了什么、有没有重试”这四个问题。有了这个基础，才能判断问题是出在加载层、选择层还是执行层。

3.2 用消融实验量化 Skill 的边际收益

消融实验是最直接的判断方法。选一组覆盖主要场景的任务集 Tasks，再准备 Skill 集合 S。要判断某个 Skill x 的价值，就运行两次：一次带 x，一次不带 x，只控制这个变量。

具体流程可以按下面几步走：

1. 准备固定任务集，每条任务记录输入、预期行为和成功标准。
2. 在全量 Skill 下运行任务集，记录成功率、token 消耗、平均迭代轮数。
3. 移除待评估 Skill，保持其余配置不变，再运行一遍。
4. 对比两组数据。
5. 如果移除后成功率不变或上升，同时 token 下降，这个 Skill 就应该重新设计或停用。

这个实验不一定要很复杂，但必须固定输入和评判标准。否则模型输出的随机性会让你误判 Skill 的实际效果。

注意：做消融实验时，要固定模型版本、温度参数和任务集，否则无法判断差异来自 Skill 还是随机性。

下表是一个简化示例：

在这个示例里，移除 A 后成功率反而提高，说明 A 在当前体系里是负资产；移除 B 后成功率下降，说明 B 仍有保留价值。这样就能把 Skill 管理从“感觉有用”变成“数据决定”。

3.3 建立 Skill 运行的核心指标表

诊断时不只看一两个指标，建议建立一个小组表格，记录每个 Skill 的加载频率、实际调用率、成功率、平均 token 开销和冲突次数。

这些指标需要日志或 trace 系统支撑。小团队可以先手动记录一周，再决定是否做成自动化报表。生产环境建议在 Agent 框架的中间层统一埋点，避免业务代码里到处打日志。

4. 让 Skill 系统继续扩展也不会失控：按需加载与动态路由

4.1 把“全量注入”改成“按域加载”

既然问题根源之一是全部 Skill 都进入上下文，优化思路就很明确：每一轮只加载与当前任务相关的那部分 Skill。实现上可以分两层：第一层是粗粒度路由，根据用户任务判断属于哪个领域，比如“日志分析”“代码审查”“数据可视化”；第二层是细粒度选择，从该领域内挑选具体 Skill。

粗粒度路由可以是一段简单的分类逻辑，不一定要用模型。最常见做法是维护一个关键词和领域映射规则。示例：

domain: log_analysis matches: - 日志 - log - 异常 - exception - 排错 load_skills: - skill_log_analyzer - skill_log_search_prefilter - skill_metric_alarm_check

domain: code_review matches: - 代码审查 - review - 代码质量 - pr load_skills: - skill_diff_summarizer - skill_security_checker - skill_style_linter

这样，日志任务只加载日志相关 Skill，不加代码审查类 Skill。注意，关键词映射适合场景边界清楚的任务；如果任务跨度很大，则需要在模型层做意图识别，再把识别结果用于 Skill 筛选。

4.2 用 Skill 元数据做预筛和路由

为了让路由更可靠，每个 Skill 的定义文件里应当包含结构化的元数据。示例：

name: skill_log_analyzer version: 2.1.0 domain: log_analysis summary: 对日志做异常分布统计和根因片段提取 when_to_use: - 需要按时间范围统计异常数量 - 需要找出异常集中出现的模块 - 需要生成日志分析摘要 avoid_when: - 只需要关键词检索，不需要聚合统计 - 数据源不是日志文本，而是结构化指标 priority: 5 dependencies: - skill_log_search_prefilter tags: - logs - stats - alert

这个文件的价值在于让路由模块有可计算的信息。先看 when_to_use 是否命中，再看 avoid_when 是否排除，然后检查依赖是否满足，最后按 priority 排序。模型不需要阅读完整 Skill 文本，只需要路由模块挑出少数候选。

如果项目还没有这样的结构，可以先从 YAML 字段补起。新增 Skill 时要求作者必须填写 when_to_use 和 avoid_when，否则不允许合并。这样做等于把“是否适合当前任务”的判断从模型运行时提前到了开发和评审阶段。

4.3 增加优先级、隔离和降级机制

按域加载只能解决一部分问题。同一领域内可能有多个 Skill 竞争，这时需要明确的优先级。优先级字段应该回答：当多个 Skill 都匹配任务时，默认选谁。

示例规则：

def pick_skill(candidates, task_intent): # 示例：先排除 avoid 冲突，再按 priority 升序选择 usable = [ s for s in candidates if not is_avoided(s, task_intent) ] if not usable: return None return min(usable, key=lambda s: s.priority)

注意这里的 priority 数值越小越优先，具体方向要和团队约定一致。比选哪一个更重要的是：不允许出现两个同域 Skill 的 behavior 重复。路由逻辑只负责执行选择，边界清理要靠 Skill 评审。

隔离和降级机制是在生产环境中稳定运行的关键。新增 Skill 应该先进入灰度环境，与线上 Skill 完全分离；线上只加载标记为 active 的版本。若某个 Skill 出现连续调用失败，需要能通过配置开关快速摘除，而不用重新发布整个 Agent。配置开关示例：

skills_registry: skill_log_analyzer: active: true version: 2.1.0 fallback: skill_log_analyzer_v1 max_retry: 2 skill_dashboard_builder: active: false reason: "dashboard 渲染不稳定，待修复后灰度"

生产和开发环境应该使用不同的 registry。开发环境可以加载全部 Skill 用于联调，但生产环境必须可枚举、可回滚。也可以把 registry 放配置中心，运行时调优，不需要改代码。

注意：灰度环境里停用 Skill 不能只改配置，还要确认线上流量已经被摘除，避免出现部分请求使用新策略、部分请求使用旧策略的情况。

5. 可复用的 Skill 设计规范与发布清单

5.1 写 Skill 时就要考虑“它会给每一轮带来什么成本”

Skill 描述写得越详细，模型越容易理解，但代价是每轮调用都变长。因此描述要在“机器可路由”和“模型可理解”之间取平衡。下面是一个对比。

推荐写法的核心是“一句话能说清该不该用，三句话能说清怎么做”。完整业务规范可以放外部文档，不放 System Prompt。

同时，每个 Skill 都要写 avoid_when。这看起来是多余信息，但能显著降低选择偏差。模型不是只知道什么时候该用，还要知道什么时候不该用。

5.2 发布前必须走完的检查清单

给团队用的发布检查清单，可以直接贴进 PR 模板或 CI 脚本里：

• 是否填写 name、version、domain、priority 等元数据。
• 是否写明 when_to_use 和 avoid_when。
• 是否新增了相似 Skill 或与现有 Skill 职责重叠。
• 是否记录了描述 token 消耗，增量是否可接受。
• 是否完成冲突规则扫描，比如“必须”“禁止”“除非”等规则词之间的冲突。
• 是否在测试任务集上做了带/不带该 Skill 的消融对比。
• 是否对所有依赖 Skill 进行了版本确认。
• 是否已准备回滚开关和灰度加载方式。
• 是否影响了既有高频任务的延迟和 token 成本。
• 是否通过生产环境安全审查，涉及用户数据时必须说明用途。

这份清单是通用版本，实际项目需要结合自己的框架字段调整。关键是把检查从“代码能跑”扩展到“运行不会拖累其他技能”。

6. 常见“Skill 越多越笨”的坑和对应排查路径

6.1 坑一：把“加 Skill”当成提高准确率的默认手段

现象：某个任务集准确率不达标，团队第一反应是再加一个 Skill，结果多次叠加后整体准确率继续下降。

原因：任务失败不一定是技能缺失。可能是提示词不明确、上下文不足、训练数据覆盖不够、评估标准不合理，也可能是模型在已有 Skill 中选择错误。盲目加 Skill 会让上下文更长、选择更多，反而加重失败。

排查顺序：先看失败任务发生在哪一层，是意图理解、Skill 路由、参数生成还是结果处理。用日志定位后，再决定是否需要新增 Skill。

解决方式：优先尝试修提示词、补示例、调整允许工具列表。必须新增 Skill 时，先做消融实验，确认它带来的收益大于上下文成本。

预防：把“新增 Skill 必须附消融数据”写进团队规范。

6.2 坑二：多个 Skill 职责边界模糊，模型随机选择

现象：日志分析和日志搜索两个 Skill 都能处理“看看今天日志有什么异常”这句话，模型一会调用这个，一会调用那个，输出格式不停变化。

原因：Skill 的 when_to_use 描述互相包含，且没有定义优先级。模型没有足够的判别信息，只能根据提示词里的细微偏差选择。

排查方式：把所有 Skill 的 when_to_use 和 avoid_when 抽取出来对比，看是否存在交集。也可以用一批中等难度的路由测试，检查选择稳定性。

解决方式：合并相似 Skill，或者明确一个为默认版本，另一个只处理边界场景。给每个 Skill 增加“与其他 Skill 的关系”字段，让路由层能排除互斥项。

预防：在 Skill 评审阶段，每次新增前先搜索已有 Skill 的 domain 和 tags，重复度超过阈值的直接打回。

6.3 坑三：只测单 Skill，不做全量回归

现象：新增 Skill 后，单独测试它的场景都能通过，但整个 Agent 在历史任务上的表现波动明显，有时变差，有时不稳定。

原因：Skill 之间会互相影响。新增 Skill 会改变模型选择策略、上下文长度和输出偏好，单测无法发现这些影响，只有全量任务回归才能暴露。

排查方式：准备一套固定回归集，覆盖核心业务场景和边界场景。每次 Skill 变更后，都全量运行一次，统计成功率和 token 变化。重点观察那些不涉及新增 Skill 的任务是否出现回归。

解决方式：把回归测试接入 CI，设置成功率阈值。低于阈值的提交不允许合并。

预防：把“变更 Skill 必须通过回归集”作为发布条件，而不是可选项。

7. 回到核心判断：把 Skill 当成需要治理的软件模块，而不是收藏夹

Skill 变多导致 Agent 变笨，不是模型能力到了上限，而是技能体系缺少治理。每一份 Skill 都会在每一轮推理中消耗上下文、参与选择、改变行为。它和普通代码一样，需要版本、元数据、依赖关系、冲突检测、回归测试和回滚机制。

对这些问题的处理顺序，建议先做诊断再优化。先确认是不是被 Skill 拖累，记录每轮加载和调用情况；再做消融实验，找出真正的负资产；然后将全量注入改成按域加载，补充元数据和优先级；最后把 Skill 变更纳入发布流程。

小团队可以只做两件事：第一，新增 Skill 时记录描述 token 和消融结果；第二，停止无判断地堆 Skill。先做到这两点，Agent 的稳定性就会明显改善。大团队则还需要建立统一注册中心、灰度发布机制和基于指标自动摘除能力。

下一步最值得投入的练习，是用现有项目做一次“Skill 减肥”：保留一个连续一周的日志，统计哪些 Skill 从未被调用、哪些调用后经常失败，然后把它们暂时停用，观察整体表现。这个练习成本很低，却最能帮助团队理解“多即是少”这句话在 Agent 系统里的真实含义。以后再看到一个新 Skill 时，先问的不应该是“它能不能跑通”，而是“它值不值得所占用的每一次推理”。