2026 年 9 月 11 日，OpenAI 发布了一篇文章《Rethinking skills and prompts for GPT-6 Astra》，讨论了一个很有意思的问题：随着模型能力不断提升，过去为了让 AI 更好地完成任务而编写的 Skills、AGENTS.md 和各种 Prompt，有些已经不再适合现在的模型，甚至可能影响它的执行效率。

文章举了一个很典型的例子。过去，为了避免 AI 修改代码时遗漏重要信息，开发者可能会在 AGENTS.md 中规定，每次修改代码前都必须阅读项目的架构文档、数据库文档和部署文档。这种做法对于早期模型有一定价值，因为当时的模型不一定能准确判断自己需要什么信息。但现在，如果任务只是修改一个按钮的文字，仍然要求模型完整阅读这三份文档，就会增加不必要的上下文和执行成本。

OpenAI 建议重新审视这些规则，让模型根据实际任务决定需要读取哪些资料，而不是机械执行过去遗留下来的流程。

这让我想到近两年使用 Claude Code、Codex 等 AI 编程工具时很常见的现象：我们不断安装新的 Skill，接入 MCP 服务，为 Agent 增加规则和工作流。每次配置都能找到理由，但几个月后，整个工作环境可能已经积累了大量功能重叠、适用范围模糊，甚至互相冲突的指令。

一个值得讨论的问题随之出现：当模型本身越来越强，我们为它增加的这些配置，是否仍然能够带来相应的收益？

一、Skill 和 MCP 太多，究竟会带来什么问题？

首先需要澄清，安装了大量 Skill，并不意味着 AI 一定会变慢。真正需要关注的是这些配置如何进入模型的工作过程。

以 Agent Skills 为例，一个 Skill 通常包含名称、描述、SKILL.md 和其他辅助文件。模型并不一定会在每次任务开始时读取所有 Skill 的完整内容，但通常需要先获取相应的名称和描述，才能判断某个 Skill 是否与当前任务有关。

这里涉及一个重要概念：Context Window（上下文窗口）。简单理解，它是模型一次处理任务时能够接收的信息范围。系统指令、历史对话、工具定义、项目文件和当前任务都会占用其中的空间。上下文足够大，只意味着信息可以被容纳，并不保证所有信息都对当前任务有帮助。

假设我们给一个编程 Agent 提供了 100 个工具，其中只有 5 个与当前任务有关。如果系统在请求开始时就将全部工具的名称、用途和参数结构提供给模型，那么即使最后没有调用另外 95 个工具，它们的定义也已经占用了上下文空间。

更麻烦的是工具之间的功能重叠。例如一个 Agent 同时拥有多个文件搜索工具，分别来自不同的 MCP 服务。模型需要根据这些工具的描述判断应该使用哪一个。如果描述不够明确，或者几个工具具有相似的触发条件，就可能出现不必要的工具调用、重复搜索，甚至选择错误。

这就是 Tool Selection（工具选择）问题。模型调用工具时，通常需要根据当前任务以及可见的工具名称、描述、参数结构等信息，生成对应的工具调用请求。工具定义本身也是模型进行决策的依据，因此它的质量会直接影响 Agent 的行为。

OpenAI 在原文中给出了一个 PostgreSQL 数据库迁移 Skill 的例子。

原本的描述大致是：当任务涉及数据库、查询、模型或数据持久化时使用这个 Skill。这个范围过于宽泛，可能导致 Agent 只是查询数据库，也会触发原本用于数据库结构迁移的工作流。

修改后的描述明确限定了适用范围：只有新增、修改数据

库迁移，或者检查迁移上线过程时才使用。

两种描述看起来区别不大，但后者为模型提供了更准确的工具选择依据。

因此，我们需要区分两个问题：一是配置本身是否有价值，二是它是否应该在当前任务中被加载。一个 Skill 完全可能很有用，只是不应该参与每一次任务。

二、这个问题其实从 2024 年就开始受到关注

如果回顾 Agent 技术的发展，会发现 OpenAI 这次提出的建议并不是突然出现的。

2024 年 12 月，Anthropic 发布了《Building effective agents》。这篇文章总结了他们与多个行业团队合作构建 Agent 的经验，其中一个重要发现是：效果较好的 Agent 系统往往采用简单、可组合的设计模式，而不是依赖大量复杂框架。

当时大家主要讨论的是如何构建 Agent。许多开发者会通过规划器、多智能体协作、反思机制和固定工作流来提高模型完成任务的能力，但这些结构也增加了系统的复杂程度。Anthropic 强调应该从简单方案开始，只在确实能改善结果时增加复杂性。

到了 2025 年，讨论开始深入到工具本身。

同年 9 月，Anthropic 在《Writing effective tools for agents》中指出，工具数量增加不一定能改善 Agent 的表现。开发者不应该简单地把每个底层 API 都包装成独立工具，而应该围绕真实任务设计具有明确用途的操作接口。

例如，完成一次会议预约可能需要查询人员、读取日程、检查空闲时间以及创建事件。传统 API 可以把这些操作拆成多个函数，但对于 Agent 来说，一个设计合理的 schedule_event 工具可能更加高效，因为它减少了中间调用和不必要的信息返回。

这并不意味着所有底层工具都应该合并。对于需要灵活组合操作的任务，细粒度工具仍然有价值。关键在于工具粒度是否符合实际使用场景，而不是工具列表是否足够丰富。

2025 年 10 月，Anthropic 正式介绍 Agent Skills 时，又将 Progressive Disclosure（渐进式披露）作为核心设计原则。它的思路很简单：先让模型知道有哪些能力可以使用，确定任务需要某项能力后，再读取具体的使用说明。

到了 2026 年 9 月，OpenAI 的讨论进一步涉及模型升级带来的变化。

过去，一些模型需要开发者通过明确规则来提醒它检查代码、运行测试和阅读相关资料。随着模型能力提高，部分原本必要的规则可能变得冗余，甚至因为约束过于严格，造成额外操作。OpenAI 特别提到，某些过去需要被反复提醒进行测试的行为，如今模型已经能够主动执行，因此原有规则也应该重新评估。

从这几篇文章可以看出，行业关注的问题正在发生变化：早期侧重于如何通过外部结构增强模型能力，后来逐渐开始研究这些外部结构本身的效率，以及它们与模型能力之间是否仍然匹配。

三、按需加载，正在成为重要的工程解决方案

目前比较明确的一条技术路线，是让 Agent 保留大量可用能力，但减少每次任务实际加载的无关内容。

以 Agent Skills 的 Progressive Disclosure 为例，它通常分为三个层次。

第一层是元数据，主要包含 Skill 的名称和描述，用于帮助模型判断是否需要这项能力。第二层是 SKILL.md，包含具体执行流程和注意事项，只有 Skill 被选中时才继续读取。第三层则是参考文档、脚本以及其他资源，根据任务需要进一步加载。

例如一个 PDF Skill，只有在用户要求处理 PDF 时，Agent 才需要读取相关说明。如果用户进一步要求填写表单，才可能需要读取专门的 forms.md。这种设计既保留了完整的功能，又避免在普通任务中加载大量与 PDF 有关的知识。

对于 MCP 和其他工具调用接口，类似思路也已经出现在 Tool Search 中。

传统的工具调用方式往往需要在请求开始时提供完整工具定义，包括函数名称、描述和参数结构。而 Tool Search 允许模型在运行过程中搜索工具目录，再将需要的工具定义加载到上下文中。这类机制通常称为 Deferred Loading（延迟加载）。

Anthropic 的 Claude Platform 文档提供了一组值得关注的数据：

这组数据来自 Anthropic 对 Claude 工具使用场景的描述，不能直接理解为所有模型在超过 50 个工具后都会出现明显退化。不过，它揭示了一个实际的工程问题：当工具数量达到一定规模时，工具目录本身也需要被管理，而不能只考虑每个工具是否能正常运行。

OpenAI 的 Tool Search 也采用了类似机制。开发者可以将部分工具设置为延迟加载，使模型在需要时再搜索其定义。这样不仅能减少初始上下文占用，也可以降低大量无关工具同时出现对模型决策造成的干扰。

当然，按需加载并非没有代价。工具搜索需要额外步骤，搜索结果也可能遗漏真正需要的工具。如果一个 Agent 只有少量常用工具，直接加载它们可能更简单、更稳定。因此，是否使用 Tool Search，仍然需要结合工具数量、任务成功率、调用延迟和 Token 成本来判断。

四、我们真正应该重新检查哪些配置？

回到普通开发者的使用场景，我认为最值得检查的不是已经安装了多少 Skill，而是长期积累的规则是否仍然合理。

例如，我们可能在 AGENTS.md 中留下这样的要求：每次修改代码之前，必须阅读全部项目文档；每次修改完成后，必须运行完整测试套件；遇到任何不确定的操作，都必须先询问用户。

这些规则在某些阶段确实可能提高稳定性，但没有必要对所有任务无差别执行。更合理的方式，是明确什么情况下需要读取架构文档，哪些修改必须执行完整测试，以及哪些操作可以在预先授权的安全范围内自主完成。

不过，精简配置不能简单等同于删除规则。

其中，安全权限、生产环境限制、硬件参数和项目特有的业务知识尤其不能随意删除。这些内容往往不是模型可以依靠自身知识准确推断出来的。

另外，我不建议仅凭主观感觉判断配置精简是否有效。可以挑选几项实际开发中经常遇到的任务，在调整前后分别测试，比较任务成功率、Token 消耗、执行时间、工具调用次数以及人工干预情况。如果精简之后成本降低了，但任务完成质量明显下降，那就说明这次优化未必成功。

这也是为什么我认为 Agent 配置需要逐步维护，而不应该一次性大规模删除。

写在最后

OpenAI 这次的文章给了我一个新的观察角度。过去我们经常把注意力放在模型本身的能力上，或者想办法通过 Skill、MCP 和复杂工作流补足模型的不足，却比较少重新检查这些外部配置是否已经过时。

模型升级之后，Agent 所需要的外部支持也会发生变化。过去有效的 Prompt 不一定适用于新模型，过去合理的工作流也可能需要重新设计。

对于开发者来说，这意味着未来除了关注模型能完成什么任务，还需要关注模型如何获取任务所需的信息、如何选择工具，以及如何在保持可靠性的前提下减少不必要的执行成本。

Skill、MCP 和 Agent 框架仍然很有价值。只是当这些能力越来越丰富时，如何组织和调用它们，本身也开始成为一个值得认真研究的技术问题。

最后，为了方便清理，我做了一套可以直接丢给 Agent 的 Prompt，请自行使用。

你现在不是来优化我的业务代码，而是对当前 AI Agent 工作环境做一次“能力与配置审计”。目标：减少无效上下文、重复能力、过时规则和不必要的常驻工具，同时保留真正重要的业务知识、安全边界、项目约束和高价值工作流。注意：第一阶段只允许分析和提出修改方案。不要删除、移动、覆盖或修改任何文件。不要卸载任何 Skill、MCP、Plugin、Agent 或依赖。完成审计以后停止，等待我的确认。请执行以下步骤：第一步：建立完整 Inventory检查当前环境中与 Agent 行为有关的配置，包括但不限于：- AGENTS.md- CLAUDE.md- Rules- System / Project Prompts- Skills / SKILL.md- MCP Servers 和 Tools- Plugins- Memory 配置- Hooks- 自定义 Agents- 长期加载的参考文档- 与 Agent 行为相关的其他配置如果某些位置无法访问，请明确标记，不要猜测。第二步：分析每一个配置项对于每一个配置项回答：1. 它解决什么问题？2. 它在什么情况下应该被触发？3. 当前模型是否已经原生具备这项能力？4. 是否存在其他 Skill / Tool / Rule 与它功能重叠？5. 它是否会在与任务无关时进入上下文？6. 它是否包含过时的模型补丁或历史规则？7. 删除它可能造成什么风险？8. 它是否可以从“全局常驻”改成“条件加载”？9. 是否可以将详细内容拆到 references / scripts 中，只保留最小入口？10. 是否有证据表明它最近仍在被真实任务使用？第三步：分类只能使用以下六种状态：KEEP必须长期保留。包括安全边界、真实业务规则、模型无法自行知道的环境约束等。SHORTEN内容有价值，但存在冗余、重复解释或模型已经具备的通用指导。MERGE与其他 Skill / Tool / Rule 功能明显重叠，应合并为更清晰的单一能力。DEFER有价值，但不是多数任务都需要。建议改成条件加载、Tool Search、Progressive Disclosure 或项目级临时加载。REMOVE已经过时、重复、没有信息增量，或只是过去为了弥补旧模型能力而存在。UNKNOWN无法证明应该保留，也无法证明可以安全删除。进入隔离观察，不执行修改。第四步：特别寻找以下问题- 多个 Skill 使用几乎相同的触发条件- “遇到任何相关任务都应该使用”的过宽描述- 每次任务都强制读取大量文档- 模型已经可以自主完成、但仍存在的旧指导- 多个 MCP / Tool 提供相同能力- 很少使用但始终 eager-load 的工具- 相互冲突的规则- 已经过时的模型名称、API、目录、工作流- 可以用一个高层工具替代多个底层 API wrapper 的情况- 可以移入 references 的大量背景资料- 已经不存在实际使用场景的配置第五步：输出报告请按照以下结构输出：# Agent Configuration Audit## 当前系统概况列出：Skill 数量Tool 数量MCP 数量Agent 数量主要规则文件可能长期进入上下文的配置## 最大的 5 个配置债问题说明具体位置、原因和影响。## 配置审计表字段：名称位置当前用途触发条件分类重叠对象潜在 Context 成本删除风险建议修改## REMOVE 候选说明为什么可以删除，但不要执行。## MERGE 候选说明应该如何合并。## DEFER 候选说明哪些能力应该从常驻变成按需加载。## SHORTEN 候选给出精简前后的建议。## KEEP说明为什么这些内容不应该删除。## 建议的新能力结构将现有能力重新组织为：核心常驻能力条件触发能力按需搜索能力项目级临时能力归档能力## 风险指出哪些修改可能导致行为退化。最后输出：“审计完成，尚未修改任何配置。等待确认后再执行第二阶段。”不要为了减少 Token 而删除安全要求、权限边界、真实业务规则、硬件限制、生产环境约束或模型无法自行获得的信息。你的目标不是让配置数量最少。你的目标是：用最少的长期上下文，保留最大的真实任务能力。

参考资料

1. OpenAI，2026.09.11：Rethinking skills and prompts for GPT-6 Astra

2. Anthropic，2024.12.19：Building effective agents

3. Anthropic，2025.09.11：Writing effective tools for agents

4. Anthropic，2025.10.16：Equipping agents for the real world with Agent Skills

5. Claude Platform：Tool Search Tool

6. OpenAI API：Tool Search