避免Agent技能过多，别将Prompt塞成能力清单

摘要

首先分享一个许多团队常见的误区——不少人一开始就想当然地认为，Agent 的 Skill 装得越多，其能力就越强。于是，工具说明、操作流程、检查清单、模板规则……全部一股脑地塞进系统 Prompt。结果呢？Agent 非但没有变得更聪明，反而在工具选择上更加飘忽不定，关键 Skill 经常无法触发，上下文越发臃肿，整体行为也变得极不稳定。

问题的根源并非在于 Skill 数量多，而在于：同时暴露给模型选择的 Skill 入口太多、太长、太相似。当大量 Skill 的 metadata、工具说明和流程规则一起涌入上下文后，就会触发三类能力退化：Listing 截断、Context Rot（注意力稀释），以及相似 Skill 之间的冲突。

本文将从这三层退化机制入手，深入剖析为何“堆砌 Skill”反而会让 Agent 表现变差，并提供一套切实可行的治理方案：先盘点 Skill 资产，再缩小自动触发面，利用 Fork 隔离长流程，按场景打包能力，最后通过日志监控、僵尸 Skill 清理和安全审计形成持续的运维闭环。

开场：Skill 越多，Agent 为什么反而更笨？

“我的 Agent 安装了很多 Skill，为什么反而越来越笨？”——这是很多团队在落地 Agent 时都会遇到的棘手问题。

起初，大家的思路很直接：把 Skill 视为能力增强包。会写代码就添加 Code Review Skill，会查日志就加入 Debug Skill，会写文档就配置 Doc Skill，会部署就集成 Deploy Skill。

听起来功能很强大，对吧？

然而，在实际运行之后，问题便接踵而至：该触发的 Skill 未能触发，不该触发的 Skill 却被误调用，相似的 Skill 之间相互干扰，系统 Prompt 越写越长，上下文变得混乱不堪，Agent 的输出也极不稳定。

于是，许多团队可能会得出结论：是不是 Skill 不能设置太多？

其实更准确的解读是：一个成熟的 Agent 能力系统，并非简单地把所有工具、流程和规则堆砌进 Prompt，而是应当把 Skill 构建成一个可检索、可隔离、可治理的能力索引库。

一、问题本质：不是能力太多，而是暴露太多

一个 Skill 通常不仅仅是一个名字。它至少包含三层内容：第一层是入口信息，例如 name、description、when_to_use；第二层是执行说明，包括具体流程、检查清单、操作步骤；第三层才是资源文件，如脚本、模板、示例和参考文档。

真正应当常驻在模型“眼前”的，通常只有第一层。后两层应当在相关任务出现时再按需加载。

这正是 Agent Skills 的核心设计理念——Anthropic 的文档将其称为“渐进式披露”（progressive disclosure）。Skill 的 metadata 作为轻量级入口存在，当任务匹配时再读取 SKILL.md，如果需要更多细节，再按需访问额外文件或资源。Claude API 的官方文档也明确指出，Skill 内容应分为 metadata、instructions、resources/code 三层加载，而不是从一开始就将所有内容塞进上下文。

但许多团队在落地时却刚好相反。系统 Prompt 变成了什么样子？

“你是一个工程 Agent。当用户需要代码审查时，遵循以下 500 行规则……当用户需要部署时，遵循以下 300 行流程……当用户需要分析日志时，遵循以下 400 行步骤……当用户需要撰写文档时，遵循以下 200 行模板……”

这根本不是 Skill 系统。这是把系统 Prompt 写成了一份无人能稳定读完的公司操作手册。

系统 Prompt 应当管理长期稳定的原则——角色边界、安全准则、输出风格、基础约束。而 Skill 应管理特定的任务流程。Resources 则应用于存放长模板、脚本、示例和参考资料。

二、三层退化机理

1. Listing 截断：入口描述被压缩，关键触发词丢失

Skill 能否被正确调用，第一步就取决于模型能否看到一个清晰的入口描述。

以 Claude Code 为例，官方文档明确建议将关键的 use case 置于描述的最前端，因为 description 和 when_to_use 在 Skill listing 中有字符长度限制。文档还说明，可以使用 /doctor 检查 budget 是否溢出，必要时将低优先级 Skill 设为 name-only，或者调整 listing 预算。

这意味着一个很现实的问题：比如你撰写了一个很长的描述：“这是一个用于复杂企业级项目代码审查的 Skill，它可以检查安全问题、性能问题、架构问题、数据库迁移问题、权限控制问题、日志规范问题、错误处理问题……”如果真正关键的触发词藏在后面，模型未必能够稳定地看到。对模型来说，这个 Skill 就如同“虽然装了，但入口没写清楚”。

更好的写法是：description: Review Django code for ORM misuse, migrations, auth, security, and performance.

你看，入口描述不是撰写论文。它只负责一件事：让模型知道何时应该打开这扇门。

2. Context Rot：上下文不是免费仓库

很多人对上下文窗口存在一个误解：以为它像一个仓库，能塞多少就塞多少。但长上下文并非免费仓库，它更像一个会逐渐变脏的工作台。

Chroma 在 Context Rot 报告中指出，模型并不会均匀地处理长上下文。随着输入长度增长，模型表现会变得更不可靠，即使在一些简单任务上也可能出现波动。

这一点在 Agent 上表现得尤为明显。Agent 运行一段时间后，上下文里可能堆满了已经失败的尝试、过时的中间结论、未被使用的工具输出、相似但冲突的规则、冗长的 Skill 说明，以及大量日志、检索片段和历史对话。你以为是在增强 Agent，实际上是在稀释其判断力。

Claude Code 文档也提醒：一旦 Skill 被调用，渲染后的 SKILL.md 内容会进入对话并在后续 session 中持续存在。因此 Skill body 应保持简洁，因为每一行都会转化为持续的 token 成本。

因此，Skill 的设计原则应当是：只放置最必要的执行指令，其余一切按需加载。

3. 相似 Skill 冲突：边界模糊，模型更容易选错

比 Skill 数量多更危险的，是 Skill 之间的相似性。

举个例子，如果你有以下这些 Skill：pdf-reader、pdf-summary、pdf-extract、document-parser、file-analyzer。如果它们的描述都写成“处理 PDF 文件”或“分析文档内容”，模型就会开始犹豫不决。

用户说：“帮我总结这个 PDF。”到底应该用 pdf-reader，还是 pdf-summary？如果要提取表格，是 pdf-extract，还是 document-parser？如果 PDF 是扫描件，又该调用哪个？

如果人类工程师看完都说不清边界，那么就不要期待模型每次都能稳定地做出正确选择。

好的 Skill 描述，必须回答三个问题：什么时候用它？什么时候不要用它？它与相邻 Skill 的边界是什么？

不要这样写：description: Use this skill to process PDF files.

应该这样写：description: Extract tables from PDF files into CSV. Do not use for summarization or OCR-heavy scanned documents.

边界越清晰，模型表现越稳定。

三、正确做法：让大部分 Skill 不进候选集

Skill 管理并非“装得更多”，而是“暴露得更少”。可以按照四步来执行。

Phase 0：先盘点 Skill 资产

在优化之前，先进行一次 Skill 审计。每个 Skill 至少记录这些字段：名称、描述、所属场景、是否高危、是否有副作用、最近一次调用时间、最近 30 天调用次数、是否与其他 Skill 重叠、是否依赖外部脚本或资源。

然后将其分为四类。第一类：高频核心 Skill，例如代码审查、测试、文档润色。这类可以保留自动触发，但描述必须简短、准确、清晰。第二类：低频但关键 Skill，例如生产故障排查、数据库迁移、事故复盘。这类不能因为低频而删除，但需要限制触发条件。第三类：高危 Skill，例如部署、回滚、删除数据、发送消息、修改权限。这类不应让模型自主决定何时使用。第四类：僵尸 Skill，长期未被调用，且没有明确的业务价值。这类先降级，再归档，最后删除。

不要一上来就“30 天没用直接删”。更稳妥的策略是：30 天零调用 -> 降级观察，60 天零调用 -> 移出自动候选，90 天零调用 -> 归档或删除。Skill 治理不是大扫除，而是资产管理。

Phase 1：缩小自动触发面

以 Claude Code 为例，Skill frontmatter 中有几个非常关键的字段。

第一个是 paths。它可以使用 glob pattern 限定 Skill 仅在匹配文件范围内自动触发。例如 Django Review Skill：

name: django-review description: Review Django code for ORM misuse, migrations, auth, security, and performance. paths: - "**/*.py" - "**/migrations/*.py"

这样它便不会在所有任务中都出现，只在相关的代码场景中进入候选。

第二个是 disable-model-invocation。将其设为 true 可以阻止模型自动加载这个 Skill，适合需要用户手动通过 /name 触发的工作流，尤其是部署、提交、发送消息等带有副作用的操作。例如生产回滚：

name: prod-rollback description: Roll back a production deployment. Manual use only. disable-model-invocation: true

这一点至关重要。Agent 可以建议你进行部署，但不应自主决定执行部署操作。

Phase 2：长流程用 Fork 隔离

有些 Skill 天生会产生大量中间过程，例如全仓库扫描、多文件代码审查、大型日志分析、安全检查、批量文档处理、竞品调研。这些任务如果全部在主上下文里运行，主 Agent 很快就会被日志、扫描结果和中间尝试所污染。

更好的方式是让它在隔离的上下文中执行，只将总结结果带回主会话。Claude Code 支持在 frontmatter 中添加 context: fork，让 Skill 在 subagent 中隔离运行——Skill 内容会变成驱动 subagent 的提示，并且此 subagent 不会访问当前的对话历史。

示例：

name: repo-audit description: Scan repository structure and summarize architecture risks. context: fork agent: Explore

但要注意：Fork 并不保证每次都更节省 token。它真正解决的是主 Agent 不被长流程的中间噪音所干扰。主 Agent 负责判断和收敛，子 Agent 负责探索和消耗资源。

Phase 3：按场景打包能力

当 Skill 数量多到几十个以后，就不应继续扁平化展开了。应该按场景进行组织：

engineering/

code-review

test-runner

migration-check

architecture-audit

writing/

blog-outline

title-generator

polish-draft

social-post

ops/

log-debug

incident-summary

rollback-guide

deploy-checklist

用户当前在编写代码，就只启用 engineering；当前在撰写文章，就只启用 writing；当前在排查故障，就只启用 ops。这和人类团队协作一样——你不会让研发、法务、财务、运营、销售同时围着一个需求发言。

四、不是所有 Skill 都该自动触发

1. 自动调用

适用于高频、低风险、边界清晰的 Skill。例如 Code Review、Test、Doc Polish。这类 Skill 出现频率高，副作用小，模型也容易判断何时使用。

2. 手动调用

适用于高风险、有副作用、需要用户确认的 Skill。例如 Deploy、Rollback、Send Message、Delete Data。这类 Skill 不应自动触发，应由用户明确调用，或者至少经过确认。

判断标准很简单：如果这个操作出错后恢复成本很高，就不要让模型自主决定。

3. Fork 调用

适用于长流程、重扫描、容易污染主上下文的 Skill。例如 Repo Audit、Log Analysis、Security Scan。这类 Skill 不一定危险，但很“重”。直接在主上下文里运行，会让主 Agent 吸入大量中间信息，因此应 Fork 出去，主 Agent 只获取结果摘要。

总结成一个判断公式：风险高 + 不可回滚 => 手动调用；过程长 + 噪音大 => Fork 调用；频率高 + 边界清 + 副作用小 => 自动调用。

五、安全：Skill 是能力，也是供应链风险

Skill 不仅仅是 Prompt。它可能包含脚本、命令、模板、外部资源，甚至可能继承宿主 Agent 的权限。

OWASP Agentic Skills Top 10 已将 Malicious Skills、Supply Chain Compromise、Over-Privileged Skills 等列为关键风险，并给出了恶意 Skill、供应链妥协、过度授权、弱隔离等风险类别。

因此，不要这样做：看到一个 Skill 市场 -> 觉得描述不错 -> 直接安装 -> 让 Agent 自动调用。

那么，更稳妥的流程应该是什么？查看来源，审查脚本，确认权限，检查是否会执行 shell，是否会联网，是否会读取敏感目录。高危 Skill 默认手动调用，不可信的 Skill 禁止自动触发。

Claude Code 文档也提供了 disableSkillShellExecution 设置，用于禁用来自用户、项目、插件或额外目录源的 Skill / command 动态 shell 执行。被禁用后，命令会被替换为固定文本，而不会被实际运行。

一句话总结：只要是插件，就存在供应链风险。

六、持续治理：Skill 不是写好就完事

Skill 不是一次性配置，而是需要持续运转的能力系统。可以建立一个简单的治理闭环。

每天：查看关键 Skill 是否命中

无需查看所有日志，只需关注关键链路：Code Review 是否触发正确？Test Skill 是否误触发？Deploy Skill 是否保持手动调用？高危 Skill 有无异常调用？每天花费 5 分钟即可。

每周：查看 Top / Bottom

每周查看一次：调用次数最多的 5 个 Skill，完全未被调用的 5 个 Skill，误触发次数最多的 Skill，以及用户经常手动点名的 Skill。如果一个 Skill 经常被手动调用，说明其 description 可能写得不够好；如果一个 Skill 经常误触发，说明其边界可能定义得过于宽泛。

每月：进行一次重组

每月检查：是否有相似的 Skill 可以合并？是否有 Skill 需要拆分？是否有高危 Skill 需要改为手动调用？是否有长流程 Skill 应该使用 Fork？是否有第三方 Skill 需要复审？Skill 不应越堆越多，而应越来越清晰。

每季度：进行一次安全和资产清理

按季度进行以下处理：90 天零调用的 Skill 进行归档，重复的 Skill 进行合并，第三方 Skill 重新审计，检查是否存在过宽的权限，检查是否有不必要的 shell 执行，检查是否有敏感目录的读取操作。这不是洁癖，而是为了避免 Agent 的能力系统演变成垃圾场。

结尾：高手不是装更多 Skill，而是让大部分 Skill 不出现

很多人认为 Agent 能力建设是在做加法：多安装 Skill，多撰写规则，多塞入 Prompt，多添加工具。但真正落地之后你会发现，关键不是做加法，而是构建一个选择系统。

哪些能力常驻？哪些能力按需出现？哪些能力只能手动调用？哪些能力必须隔离执行？哪些能力应该归档删除？

Skill 的本质不是“更多的说明”，而是“更好的能力组织方式”。

下一次你试图往系统 Prompt 里塞入一大段流程时，可以先问自己一句：如果是全局原则，放入系统 Prompt；如果是操作流程，做成 Skill；如果内容很长，拆解为 Resources；如果操作高危，禁止模型自动调用；如果容易污染上下文，使用 Fork 隔离；如果长期无人使用，进行归档。

最后记住一句话：真正成熟的 Agent，不是 Skill 越堆越多，而是能力系统越来越清晰。