AI Agent技能越多反而越笨？从上下文与选择成本剖析Skill优化之道

我最近被反复问到一个问题为什么你的 AI Agent Skill 越多反而越笨第一次听到这个说法时我以为是使用姿势的问题后来在几个项目里用同一套任务反复观察才发现这不是错觉。给 Agent 装了一堆 Skill 之后它没有变得更全能反而经常选错方法、忽略该用的流程甚至在简单任务上绕远路。真正让人意外的不是“装多了会变笨”而是很多团队已经默认了这个结果还在继续加新的 Skill 去补救。问题不出在 Skill 这个概念本身而在于 Skill 数量增长后上下文管理、触发边界和冲突控制没有跟上。如果把一堆 Skill 复制进配置目录却不建立筛选、评估、清理机制数量越多Agent 的决策偏移就越严重。所以这篇文章想拆清楚几件事Skill 变多之后到底发生了什么为什么它会稀释智能怎么判断一个 Skill 该不该留以及如何把 Skill 集合做成一个真正可维护的能力系统。1. 先别急着删 Skill先看清“变笨”是怎么发生的1.1 一个让很多开发者困惑的真实场景我见过一个挺典型的场景团队为了提高 AI 编程 Agent 的能力给它配了二十多个 Skill包括代码审查、接口文档生成、日志分析、数据库调优、提交信息规范、UI 设计规范、需求拆解等等。配置完以后运行一个“给某段日志提取错误码并做汇总”的任务结果 Agent 没有直接调用日志分析相关的 Skill而是先加载了一个“代码审查”的 Skill接着又去翻“接口文档生成”的说明最后输出了一份看起来像总结、但缺少错误码分布的报告。任务本身不复杂。难的是 Agent 没能在合适的时间打开合适的 Skill。这不是某一个产品独有的问题。只要 Agent 需要从一个较大的 Skill 集合里选择当前任务该用的技能就会出现类似现象。Skill 越多描述越模糊选择错误的概率就越高。很多开发者以为“变笨”是模型能力不够其实模型可能在底层能力上没变是外挂的“工具说明”把决策过程搞乱了。1.2 Skill 是能力增强包不是越多越好先把概念对齐Skill 不是普通文档也不是聊天背景知识它更像一份“可复用的任务方法论”。一个 Skill 应该封装某一类任务的目的、触发条件、执行步骤、输入输出格式和边界限制。Agent 碰到对应任务时按 Skill 里的流程走减少重复思考提高结果稳定性。这个设计初衷是好的。问题在于Skill 一旦被启用就不是“放在硬盘里供人查阅”的文档而会成为 Agent 决策时可见的一部分。要么是全部 Skill 的索引进入提示词要么是候选列表参与工具匹配要么是在某个时刻把 Skill 内容注入上下文。无论哪种方式每个 Skill 都会占用 Agent 的注意力资源。所以一个更准确的理解是Agent 的“聪明程度”不由可用工具数量决定而由“当前上下文里的有效决策密度”决定。Skill 数量增长后如果触发边界不清晰、描述重复、内部步骤冗余有效的决策密度反而会下降。这就是“越多越笨”的直接机制。2. Skill 越多越笨背后是三个可控成本2.1 选择成本候选名单太长Agent 会先错选大模型在每一步选择工具时并不是在做精确数据库查询而是在对候选工具做概率排序。每个 Skill 的名称、描述、示例、关键词都会影响排序结果。候选越多排序的干扰就越大。当两个 Skill 的描述里都有“日志”“分析”“异常”这些词时Agent 可能把“日志监控”误当成“离线日志分析”来用。表面上看它“选了一个相关工具”实际上没有选中真正封装了目标流程的那个。这种错误不是偶发而是随着相似 Skill 增多而上升。用团队来类比如果团队成员都挂着“全能型”标签谁都能处理一点问题那么分配任务时Leader 就要反复猜谁来干。Skill 描述不清晰Agent 就是那个 Leader而它猜错的成本会直接体现在输出质量上。2.2 上下文成本Skill 的描述和步骤也在挤占注意力很多人忽略了一个事实Skill 不止是一个“可选项”在很多框架里Agent 启动任务时会预扫描整个 Skill 集合至少要把名称、描述、触发条件这些元数据纳入决策上下文。还有一些 Skill 在被选中后会把整份 Markdown 文档读入上下文。即便上下文窗口可以容纳几十万 Token真正有价值的信息密度仍然有限。用一个比喻上下文窗口像一张办公桌桌子的面积有限。桌上堆了三十本手册每一本都写着“怎么用”真正放任务图纸、日志、代码的位置就变小了。Skill 越多手册越厚Agent 需要在回答问题时兼顾的干扰信息就越多。结果就是它会在任务的细节上漏掉关键信息或者在输出里夹杂不必要的“方法论”废话。这里有人会反驳不同 Skill 并不是全部加载只是加载一个或几个。但从工程实践看即便不加载全部内容Agent 在做初始选择时通常也会扫描所有 Skill 的元数据。这个扫描动作本身就是成本而且会随着 Skill 数量线性增长。2.3 冲突成本边界不清的 Skill 会互相干扰Skill 之间如果边界不清不只是“选错”的问题还会出现“混用”的问题。比如日志分析 Skill 给出的流程是“提取错误码、统计异常堆栈、输出 Markdown 报告”而另一个日志监控 Skill 给出的流程是“接入实时日志流、持续观察、触发告警”。Agent 拿到一个离线日志文件时可能先走了离线分析的步骤中途看到监控 Skill 里有“数据流”相关描述又试图用流式方式处理最后结果既不是分析也不是监控。这种冲突不会总是报错更多表现为“行为漂移”同一个任务今天跑是这个结果明天跑是另一个结果。用户会感到 Agent 不稳定但又说不清是哪一步出了问题。真正的原因往往是 Skill 集合里存在重复覆盖或者两个 Skill 的职责边界没有写清楚。选择成本、上下文成本、冲突成本构成了“Skill 越多越笨”的三个来源。理解了这三层才能开始做减法而不是盲目地继续堆料。3. 判断一个 Skill 该不该留用“可触发”代替“可能有用”3.1 好的 Skill 应该像封装良好的函数从软件工程角度看Skill 很像一个函数有名字有入参有处理逻辑有返回值还应该有副作用说明。调用方不需要知道细节但必须知道“这个函数解决什么问题”“什么时候不该调用它”。反过来看很多不理想的 Skill名称很宽泛描述里只写着“帮助开发者提高代码质量”没有给出触发条件也没有给输入输出格式更没有边界限制。这种 Skill 对 Agent 来说就像一个没有注释、没有类型、没有异常处理的函数调用它能不能得到正确结果完全靠运气。所以判断一个 Skill 该不该留第一个标准是能不能在十秒钟内判断“这条任务该不该用它”。如果人和 Agent 都说不清它就不应该留在活跃集合里。一个合格 Skill 的入口至少应该包含触发场景、必要输入、典型输出、不适用场景。3.2 “三个一”原则一件事、一条路径、一个负责人我沉淀了一个很简单的框架叫“三个一”原则用来控制 Skill 的规模一件事一个 Skill 只解决一类任务不做大而全的“全能助手”。如果一个 Skill 里既写代码审查又写接口文档生成它看起来功能很全实际上任何一类任务都处理不深Agent 也容易在内部步骤间跳来跳去。一条路径Skill 主流程尽量线性。主步骤控制在五步以内每个步骤有明确产物。如果需要在不同分支里切换可以在“参考资料”里按需读取而不是全部写进主流程。分支越多模型执行时越容易跑偏。一个负责人同一类任务只保留一个主 Skill。如果已经有“日志分析”的 Skill就不要再来一个“日志异常日志统计”的 Skill。出现相似 Skill 时先合并再归档而不是同时启用。这三个原则的价值在于它把“Skill 管理”从“收集癖”变成了“接口设计”。一个 Skill 没有清晰接口就不应该进入生产环境。3.3 把 Skill 文档改造成“入口简洁、细节按需”很多人写 Skill 文档喜欢把一切都写得特别详细以为信息越全Agent 执行得越准。但实际效果往往相反面对一个几千字的 Skill 文档模型会在里面“迷路”尤其是在执行过程中反复跳读容易忽略最关键的步骤。更好的写法是“入口简洁细节按需”。SKILL.md 的开头只放最关键的触发信息比如叫什么、什么时候用、输入是什么、输出是什么、不适用于什么。具体步骤保持主流程短小详细示例和格式说明放到外部参考资料里让 Agent 在需要时再读取。这就像你先给读者一份目录再让他按需翻到对应章节而不是把所有内容都平铺在第一页。下面是一个常见的 Markdown Skill 结构示例不同框架的字段名可能有差异但核心思路一致--- name: log-summary-parser description: 当用户提供一份日志文件或日志文本需要提取错误码、异常类型、耗时分布并输出 Markdown 汇总报告时使用。不适用于实时日志流监控。 when_to_use: 离线日志分析需要结构化汇总 --- # 主流程 1. 读取全部输入内容 2. 提取错误码和异常堆栈 3. 统计耗时分布 4. 输出 Markdown 汇总报告 # 参考资料 - 常见日志格式说明 - 错误码分类表主流程尽量保持线性参考资料单独存放。这样一来Agent 在决策阶段不会因为文档太长而犹豫真正执行时又能按需获取细节。这个写法的前提是SKILL.md 的 description 必须写得足够精确不能是“处理日志相关问题”这种万能描述。4. 用对照实验代替感觉验证 Skill 到底有没有帮倒忙4.1 先建一组基准任务当你想判断“Skill 是不是太多了”不要只凭“感觉 Agent 变笨了”而是先建立一组固定任务。任务集不需要太复杂但要能覆盖日常使用简单任务一两步就能完成比如“把这段 Markdown 转成 JSON”。复杂任务需要多步推理比如“分析这份接口报错日志给出可能原因和修复建议”。边界任务输入包含空文件、异常格式、或明显不属于任何 Skill 范围的情况用来测试 Agent 会不会错误触发某个 Skill。每个任务最好带上“期望输出”和“可接受偏差”。比如日志分析任务期望输出至少包含错误码和出现次数如果 Agent 只给出泛泛的原因说明就算不合格。没有这套基准后面的一切优化都无从对比。4.2 做最小集合与全量集合的 A/B 对比有了基准任务后做一次严格对照同一个模型、同一套任务、同一个温度参数分别跑“全量 Skill 开启”和“只保留 3 到 5 个核心 Skill”。每轮可以连跑三次看多数结果减少偶然性。记录维度建议包含任务完成率、平均耗时、Token 消耗、人工修正次数、输出稳定性。下面是一个常见的对比表格对比维度只保留核心 Skill全量 Skill 开启任务完成率通常更高可能下降平均耗时更短可能明显变长Token 消耗更少可能更高人工修正次数更少可能增多输出一致性更好可能出现行为漂移表格里的结果不是绝对规律但在多数实践里会比“凭感觉”可靠得多。如果全量集合没有在任何一个维度上优势明显那它就没有继续留着的理由。真正的关键是控制变量不要同时换了模型、改了提示词、又动了 Skill 集合否则出了问题无法定位。建议一开始不要一次性清空所有 Skill。先只保留 3 到 5 个核心 Skill 做对照确认差异后再逐步恢复有明确价值的 Skill每恢复一个跑一轮基准任务看它到底是加分还是减分。4.3 从调用链日志看 Agent 的决策过程只看最终结果还不够还要看过程。很多 Agent 框架会输出调试日志记录每一步调用了什么工具、读取了哪个 Skill、产生了什么中间结果。排查 Skill 问题时第一步就是打开调用链日志。如果日志里出现下面这些特征基本可以判断 Skill 集合有问题任务与日志分析相关Agent 却先读取了代码审查 Skill。同一个 Skill 被反复读取了好几遍仍然没有执行关键步骤。Agent 先是选中了 Skill A接下来又读取了 Skill B 的相似内容最后生成的流程像是 A 和 B 的拼接。Skill 被正确调用了但执行的步骤和 Skill 文档里的主流程不一致。这些现象对应着选择成本、冲突成本、上下文成本。日志不会直接告诉你“该删哪个”但能告诉你“问题的入口在哪里”。先看调用链再看输入最后才谈优化策略而不是一上来就删文件。5. 多 Skill 协作时最容易踩的坑5.1 重复覆盖同一类任务的 Skill最隐蔽的坑是两个 Skill 名字不同描述里的关键词和适用场景几乎一样。比如一个叫“日志分析”另一个叫“日志异常统计”实际处理任务是同一类。Agent 面对两个高度相似的 Skill只能靠概率猜测结果可能这次选对了下次选错了。解决办法是合并同类项。把两个 Skill 里更完整、更稳定的一个作为主 Skill另一个要么删除要么移动到归档目录。保留时应明确写清“这是一个负责日志分析的主 Skill其他相关 Skill 不承担该职责”。5.2 描述里全是“万能词”“万能词”指那些放之四海而皆准的表达“处理各种问题”“帮助用户提高效率”“辅助开发工作”“通用助手”。这类描述不会让 Agent 更聪明反而会让对应 Skill 成为一个“什么都能干但什么都没封装”的候选。判断一个 Skill 描述是否合格可以做一个测试把它的描述放进另一个 Skill 里看看是不是毫无违和感。如果这段描述能同时出现在十个不同 Skill 上那它就是无效描述。正确的描述应该包含可验证的触发条件比如“当输入是 Markdown 表格时”“当需要从日志中提取错误码时”“当项目使用 pytest 编写测试时”。5.3 把 Skill 当成永远在线的人设一些人喜欢给 Agent 装“资深架构师”“前端专家”“产品经理”这种角色类 Skill。它确实能改变回答语气和风格但如果把角色设定和任务流程混在一个 Skill 里很容易干扰正常任务。比如一个“资深架构师” Skill 描述里写着“负责处理所有架构设计、代码审查、技术选型”于是 Agent 在写“给这段代码加注释”这种小任务时也激活了这个庞大 Skill开始输出一堆架构原则而不是直接动手改代码。角色约束和任务流程应该分离。如果你需要固定的人格可以用独立的系统提示词来做Skill 还是应该聚焦任务方法不要变成“人设切换器”。5.4 把简单操作也封装成 Skill不是所有事情都值得封装成 Skill。一个简单操作比如“把英文翻译成中文”“格式化 JSON”用一段提示词或函数就能完成封装成 Skill 反而增加管理成本。Skill 更适合封装那些“有多步流程、容易出现遗漏、需要固定输出格式”的任务。比如日志分析、需求拆解、代码提交信息生成、复杂报告生成。如果一个 Skill 的内容只有两三步而且没有任何容易遗漏的边界那它带来的收益就不足以覆盖维护成本。5.5 依赖环境漂移导致 Skill 悄悄失效Skill 不是纯文本它可能依赖某个 Python 脚本、某个第三方库、某个固定的目录结构甚至某条系统命令。当环境更新后依赖路径变了脚本版本换了Skill 没有被同步更新Agent 每次调用都会在中间步骤失败。这种现象给用户的体感是“Agent 变笨了”它明明找到了正确的 Skill也按照 Skill 文档执行了但内部命令报错最终输出质量很差。排查时很容易误判为模型问题其实根因在 Skill 依赖漂移。解决方法是在 Skill 文档里写明依赖和前置校验。更稳妥的是定期执行一轮“Skill 自检”让 Agent 用每个 Skill 跑一次最小冒烟任务确认还能输出预期结果。这比等到真实任务失败再排查高效很多。5.6 多 Skill 问题排查链路如果 Agent 已经出现“变笨”现象建议按下面的顺序排查看现象是答非所问、忽略 Skill、调错 Skill、重复读取还是执行中断。看输入当前任务是否真的属于某个 Skill 的触发边界还是输入格式不符合。看环境Skill 依赖的路径、权限、第三方库、版本是否仍然可用。看元数据Skill 的名称、描述、when_to_use 是否足够清晰。看内容Skill 的主流程是否线性步骤是否可执行是否包含太多分支。看集合是否存在多个 Skill 覆盖同一类任务或者描述高度相似。这个顺序能帮你把“玄学”问题变成“可定位”问题。实际经验里至少有一半的“变笨”不是模型变笨了而是 Skill 集合在某个环节悄悄失控。6. 从“堆 Skill”到“做减法”建立可维护的 Skill 体系6.1 给 Skill 建生命周期Skill 应该像代码功能一样有完整的生命周期提议、开发、试用、评估、合并、归档。不能因为某篇教程说某个 Skill 好用就直接把它部署到生产环境。具体做法是新增 Skill 时先进入“候选区”。写清楚这个 Skill 要解决什么问题、触发条件是什么、预期收益是什么。然后在小范围任务集上试用一周观察调用日志。如果一周内没有任何任务触发它或者触发后效果还不如不触发就把它从这个集里移除。归档不等于删除。归档的 Skill 可以保留在单独目录里不再参与 Agent 的日常决策。这样既能保持活跃集合精简也不会丢失已有资产。6.2 用“最小可用集合”替代全家桶很多人在配置 Agent 时会陷入一种“全家桶心理”感觉这个 Skill 以后可能用得上那个 Skill 偶尔也能用上于是全部保留。但“可能用得上”和“当前任务需要”之间差距很大而 Agent 每次决策都要为所有“可能用得上”付出成本。更实用的做法是统计过去一到两周 Agent 实际处理的任务类型只保留排在前几名的任务对应的核心 Skill。出现新任务时先试试现有 Skill 能不能覆盖。只有当现有 Skill 无法完成或者效果明显低于预期时才去新增 Skill。一个团队如果 Skill 数量已经超过二十个而且没人能说清每个 Skill 的触发场景和最近一次有效调用时间那它大概率已经是一种负担。具体上限取决于框架和任务复杂度但维护成本随着数量上升是确定的。注意做减法的目标是“减少决策干扰”不是把 Agent 变成什么都不能做的空壳。核心任务对应的 Skill 一定要保留而且要持续打磨。精简之后真正重要的是让每个保留的 Skill 都能稳定复现高质量结果。6.3 定期清理检查清单这套清理动作可以每两周或每个月做一次形成固定节奏是否还有“不知道什么时候触发”的 Skill。description 是否超过 200 字是否需要精简。是否有两个 Skill 的 description 包含高度相似的关键词。是否有 Skill 依赖的脚本、路径、第三方库已经失效。是否有 Skill 在过去一段时间内从未被调用过。是否有 Skill 在调用后被日志记录为“无效调用”或“中途失败”。是否有 Skill 的职责范围与另一个 Skill 重叠需要合并。每一项背后都对应一种成本无法触发的 Skill 只是占位符相似描述会产生选择困惑失效依赖会导致执行失败从未调用的 Skill 只会增加扫描负担。清理不是冲动删文件而是用事实决定去留。6.4 顺带把 MCP 工具连接也做一次减负很多人会把 Skill 和 MCP 混淆这里简单做一个区分Skill 是“方法”和“流程”的知识封装MCP 是“外部工具和数据源”的协议连接。Skill 告诉 Agent 怎么做MCP 让 Agent 能访问某个工具或数据源。但两者有一点是共同的它们都会进入 Agent 的候选列表都会成为上下文的一部分。当你发现 Skill 太多导致 Agent 变笨时旁边往往还有一堆 MCP 连接也在同步膨胀。每个 MCP 工具组同样会带来选择成本和上下文成本。所以做 Skill 减负时最好同步检查 MCP 配置。只保留当前任务确实需要的外部工具把“以后可能用到”的连接先移除。这样可以避免工具连接数量抵消掉 Skill 精简带来的收益。6.5 做减法的深层收获做减法的最终目的不是让数字变得好看而是把 Agent 的决策空间缩到它更可能正确的范围。人类团队也是一样。一个团队的核心战斗力不是靠堆人头堆出来的而是靠清晰的岗位边界和可复用的工作流程。Skill 就是 Agent 的“岗位说明书”。岗位说明书越多越含糊执行者就越焦虑输出就越不稳定。只有当每份说明书都知道自己负责什么、不负责什么整个系统才能高效运行。当你把 Skill 集合从“几十个模糊的备忘纸条”变成“五六个清晰可验证的任务流”时会发现 Agent 不仅没有变笨反而在那些真正重要的任务上变得更可靠、更一致。这正是 Skill 体系应该带来的价值让复杂任务可控、可复用、可迭代而不是让 Agent 像一个背着一堆工具却选择困难的实习生。如果你现在也觉得自己的 Agent 变笨了不要急着再往里加新 Skill。先打开日志找出最近一次错误选择发生在哪一步然后按“三个一”原则清理掉一批描述模糊、职责重复、长期闲置的 Skill最后用一组固定任务跑一次 A/B 对照。Skill 的价值从来不是数量而是让 Agent 在需要的时候能毫不犹豫地翻到正确那一页。这不是保守这是让复杂系统可控的常识。