GPT-6时代Agent配置大扫除：Skill与AGENTS.md清理指南

GPT-6的消息一出来我的第一反应不是去刷Benchmark榜单而是看了一眼自己攒了一年多的Codex配置目录。说实话心里有点发毛。那个塞了三十多个Skill的文件夹、每个项目根目录下越来越厚的AGENTS.md还有一堆写着v2_final_真的最终版的prompt脚本这就是一座典型的、长期疏于管理的Agent工作区。如果说GPT-5时代我们还能靠提示词堆砌和经验主义配置勉强维持秩序那到了GPT-6这种推理范式明显升级的节点这套玩法必须推倒重来。新模型对新配置的敏感度完全不同旧思路下的Skill和AGENTS.md不再是助力反而会成为拖累模型判断、消耗上下文窗口、制造错误决策的噪音源。这篇文章不聊模型参数也不做跑分分析就专心讲清楚一件事在GPT-6大规模落地之前如何对你的Skill和AGENTS.md做一次真正有效的大扫除。1. GPT-6时代为什么突然要谈清灰了从Agent工作区说起1.1 决定Agent行为的两种文件Skill与AGENTS.md的分工在OpenAI Codex这类Agent编程工具的工作体系里真正决定模型在项目里怎么干活的主要就是两样东西Skill和AGENTS.md。Skill的本质是一个带有SKILL.md说明文件的技能包目录。它告诉模型当你面对某类任务时可以调用这个目录下的脚本、参考文档和预设策略来完成工作。这像一个给Agent配好的工具箱里面放着螺丝刀、扳手、电钻还贴了一张使用说明书标明每种工具适合拧什么样的螺丝、钻什么样的孔。AGENTS.md则是项目级的协作指南一般放在仓库根目录或关键子目录下描述这个项目的技术栈、代码规范、构建命令、架构约定等背景知识。模型每次进入这个仓库工作时会先读取AGENTS.md快速建立对这个项目的基本认知。两者配合起来Agent才能像一个真正了解项目的老同事既知道该用什么工具Skill又知道项目的规矩和偏好AGENTS.md。1.2 模型推理范式升级后旧配置正在变成噪音我在实际使用中对一个趋势感受特别深模型能力越强对低质量输入的容忍度反而越低。这听起来有点反直觉但逻辑是通的——GPT-6这类新模型的推理深度和上下文利用效率大幅提升意味着它会对读到的每一行指令、每一条约束都做更深入的处理。如果配置里有一堆逻辑矛盾、语义模糊或早已过时的规则模型不会像以前那样自动忽略而是会尝试强行理解甚至在执行过程中产生冲突。打个比方以前你请一个实习生干活你把三十条注意事项全部写在纸上他能消化多少算多少很多细节他看不明白就直接跳过了。现在你请了一个经验丰富的老工程师他还是会按那张纸执行但他会逐条分析每条规则背后的意图。这时候纸上那些自相矛盾、已经失效的内容就会让他陷入两难甚至做出完全错误的取舍。GPT-6带来的正是这种变化。原本多写点总比漏写好的配置哲学在新推理范式下变成了每条多余指令都在制造理解负担。Skill目录里躺着五六个功能互相重叠的技能包AGENTS.md里累积了三年的历史决定和废弃规则这类问题如果不做一次彻底清理等到新模型真正接入工作流的那一天你会发现自己不是在用它干活而是在替它解释那些连你自己都快忘掉的旧配置。2. 先摸清家底给Skill和AGENTS.md做一次完整的资产审计大扫除的第一步永远是盘点而且是带着怀疑态度去盘点。不要看到目录顺眼就留着必须把现有的东西全部摊开重新审视一遍它们的真实价值和当前状态。2.1 审计Skill资产清单的四个维度我的做法是把所有Skill目录过一遍每个都从四个维度做一次体检实际使用频率在真实开发中用过几次哪些长期处于装了但没用过的状态维护状态最后一次更新是什么时候里面的脚本用的还是不是当前版本的API有没有已经废弃的依赖功能重叠度好几个Skill是否在做同一件事比如同时存在三个不同版本的代码审查技能包。与GPT-6的兼容性有没有针对旧模型的专用调优提示这些提示在新模型下是否会限制能力的发挥整理成表大概是这样审计维度判断标准处理建议使用频率近30天内是否被调用过低频但仍有价值的归档无价值的直接删除维护状态引用的API是否还活着失修的优先修复或淘汰功能重叠度是否存在功能相似的其他Skill合并同类项只保留最强的一个模型兼容性是否包含过时的模型定向指令去除旧版约束让新模型自由发挥不要在这步偷懒。我见过很多人清理到一半就舍不得删了觉得以后可能用得上。但现实是那些可能用得上的Skill绝大多数永远不会再被启用它们存在的唯一作用就是让模型在技能检索时多几个错误选项。2.2 AGENTS.md的信息质检清单AGENTS.md的问题和Skill不一样。Skill往往是因为太多太杂而失序AGENTS.md则是因为长期无人维护而失真。我检查项目里的AGENTS.md时会重点问这么几个问题里面提到的构建工具和版本号是不是项目当前真实使用的还是已经换了三茬工具文档却还停留在上一代那些历史决策记录是否还影响当前的开发约定比如早期为了某个特殊需求定的代码规范在功能已完成的情况下还该不该继续约束新代码有没有互相矛盾的规则比如前面说使用A框架后面又提到在B框架下的注意事项。信息密度合理吗真正重要的项目约定占多少无关紧要的操作记录占多少这里有个很容易被忽略的细节AGENTS.md不是写给人类同事看的周报它是写给模型的项目简报。写进去的每句话都应该承担指导模型行为的功能。那些某年某月某日修复了某个Bug类的流水账放在CHANGELOG里没问题塞进AGENTS.md就是在浪费模型的注意力。3. 动手拆与补清理过期Skill、瘦身AGENTS.md的执行流程盘点做完就该进入实质性的清理阶段了。这个阶段的操作核心是果断删、大胆并、重新写。每一类文件有自己的处理逻辑我分开来说。3.1 Skill三档分类法核心、备用、归档我把审计完的Skill分成三档这个分类方法可以帮你快速做出取舍第一档核心武器。这类Skill承担的是高频核心任务比如规范的代码审查、项目初始化、依赖更新它们在近期的实际操作中被反复验证有效。处理方式保留并且投入时间做一次代码级优化。第二档低频备用。比如某些特定场景下的迁移辅助工具、特殊文件格式处理器。处理方式从全局目录移到项目级目录或单独的disabled目录确保它不会在常规检索中被模型选中但保留启用能力。第三档投奔回收站。功能已被其他Skill覆盖的、引用的工具已经彻底停服的、提示词逻辑和GPT-6新推理方式存在明显冲突的。处理方式统一删除不念旧情。实际操作中最大的工作量往往不在删减而在合并。把三四个功能重叠的Skill打包成一个需要重新设计SKILL.md的目录结构、重写说明文档、梳理脚本调用关系。这个过程中你会重新理解自己当初为什么要创建这些技能包——很多其实是一步步打补丁打出来的合并之后你反而能得到一个更清晰的技能定义。3.2 AGENTS.md精简的结构化重构步骤AGENTS.md的重构核心是压缩信息突出约束。我自己的标准步骤是先拉出全文从头到尾读一遍标出每段信息的作用。是指导模型行为还是记录历史还是纯属废话把历史记录类内容直接剥离。这些内容要么转移到项目的CHANGELOG要么直接删除。保留的技术约束逐条验证。不清楚某条规则是否还生效的去问一下实际维护代码的人宁可不写也不要写错。重写时严格控制篇幅。一个中型项目的AGENTS.md如果超过100行大概率是写啰嗦了。能把核心约束压到50行以内模型的执行准确率反而更高。重塑信息结构。开篇用三五行讲清楚这是什么项目、主要技术栈、入口模块在哪之后分块列构建命令、测试命令、代码规范、部署注意点最后留一块常见任务的操作指引。很多开源项目现在开始把AGENTS.md做成多层结构根目录放全局约定关键子目录再放各自局部说明。模型工作时会按需读取这样总信息量虽然大了但单次读取的上下文开销反而小了。3.3 全局目录与项目级目录的分工重构这次大扫除里我特别想强调一个以前很少有人提到的点Skill和配置文件的放置层级本身就是一种信息过滤机制。之前的习惯是所有的Skill全部塞进全局目录结果就是模型面对任何项目都能看到所有技能不管这个项目用不用得上。这种做法在过去模型能力有限、配置检索逻辑也不完善的时候问题不大但在GPT-6阶段全局配置膨胀带来的负面效果会被放大。我现在的习惯是全局目录只保留真正跨项目通用的核心Skill比如代码审查、Git操作规范、依赖管理。其他跟特定技术栈强相关的Skill尽量下推到项目级目录你在一个Python项目里就用Python专属的Skill集合模型在那个仓库里工作时优先读取项目级配置而不是全局配置指令环境会干净非常多。同样AGENTS.md也要按域拆分。根目录只写项目级基础信息微服务子模块、前端工程、CI脚本目录各放各的说明。这样模型只需要按需加载相关目录的内容而不是每次把整个仓库的规则全部读一遍。4. 大扫除之外的底层思维转变从手写指令转向设计能力集Skill和AGENTS.md的清理如果仅仅是删几个文件、改几行说明那你只是完成了表面工作。真正的价值在于借这次大扫除刷新自己对Agent配置的底层认知。4.1 告别提示词堆砌编码习惯和项目约束的元认知重构GPT-5时代我踩过最大的坑就是习惯在Skill的SKILL.md里塞一大堆细节描述试图用文字量把模型砸醒。比如一个代码审查的Skill我会事无巨细地写明检查未处理异常检查内存泄漏检查日志格式检查命名规范...写了几十行检查清单结果模型每次审查时都在机械地逐条打钩反而忽略了真正的架构问题就像拿着一个过长的checklist反而漏掉了用户真正关心的核心逻辑。GPT-6这种新模型真正需要的不是指令列表而是能力框架。你的Skill应该在更高的抽象层级上告诉模型这个领域的核心关注点是什么、常见陷阱在哪里、什么样的产出算合格。具体到每个检查项模型自己能基于对代码的理解动态生成不需要你替它列好标准答案。这也是为什么这次大扫除中我说要敢于删。你在删掉那些冗长的检查清单时本质上是在强迫自己思考这条指令到底是在帮助模型理解任务还是在限制模型发挥如果它属于后者删掉就是最优解。4.2 善用成熟生态从全量手写到继承与改写的协作模式在重构Skill的过程中适当地参考成熟做法是完全必要的。OpenAI生态里不少团队开源的优秀Skill集合以及各类Codex实践社区里沉淀的高质量代码包都值得花时间研究。别人踩过的坑、调好的参数、理清的结构能省你不少试错成本。但直接的照搬复制意义不大。我自己的习惯是三分借鉴七分定制先参考成熟Skill的结构设计和任务划分逻辑理解它们为什么这样组织技能然后结合自己的实际工作流去改写。每个团队的技术栈、项目类型、协作习惯都不一样只有经过自己定制和验证的Skill才能真正嵌入日常开发流程。这里特别提醒一句不要看到别人分享一个效果很好的Skill就急着安装到全局。GitHub上那些Demo效果看起来很惊艳的技能包往往带着分享者特定工作流的痕迹。正确做法是先把它放在试验目录里在真实项目中试用几次确认它对你的工作流确实有帮助再决定要不要正式收录。大扫除之后如果又不管不顾地批量安装新技能那一切努力都白费了。5. 扫清之后的日常维护建立不会再次失控的运行机制大扫除最怕的是清理一时爽三个月后又回到老样子。我总结了几条维护经验说不上高深但确实管用。5.1 给项目设定配置容量预算我给每个项目定了一条硬性规矩AGENTS.md不超过100行主动维护的全局Skill不超过10个。这不是拍脑袋定的数字而是基于经验的判断——超过这个量级信息维护的边际成本就开始超过它能带来的价值增益。我会在项目里建一个简单的登记表配置项数量上限超限处理策略全局Skill10个新技能加入前必须先做合并或淘汰项目级Skill5个只保留该技术栈相关技能AGENTS.md100行超出后必须精简到核心约束这个容量预算的价值在于它逼着你每次想添加新配置的时候先思考一个问题这个东西真的必要吗如果要加我能删掉哪个旧的来腾空间别小看这种约束人类在做增量选择时天生倾向于多就是好只有主动设置上限才能对抗这种倾向。5.2 建立配置健康度的季度检查节奏日常使用中的小问题是不会自己浮出水面的需要定期主动巡视。我把Skill和AGENTS.md的审计排成了固定日程每季度做一次轻量检查每半年做一次完整大扫除。季度检查的重点是有没有新装的Skill其实是重复造轮子AGENTS.md里记录的版本号、命令是否还准确最近的讨论中是否有新的项目约定还没写进文档模型在最近的任务中是否出现过误读配置的情况检查不必很正式可能花一个下午就能过一遍但长期坚持下来你的配置库会保持在一种随时可用、随时可信的状态。这种状态在模型能力越强的时候越重要因为新模型对配置的依赖方式变了它比旧模型更认真地执行你写下的每条规则配置里的错误也会被它更认真地放大执行。还有一个小技巧善用Codex的调试日志功能。当你觉得某个任务模型的理解有偏差时回头翻一下它读取了哪些配置、哪些Skill被加载了、AGENTS.md的哪些内容被重点关注了。这些日志是调校配置的第一手依据比你自己瞎猜它为什么这样做要可靠得多。6. 大扫除期间的隔离事项Key权限、模型兼容性与回滚预案最后这部分是很多人清理配置时根本没意识到会翻车的隐藏雷区。6.1 API Key和账号权限的清理被忽略的安全死角Skill目录里藏着硬编码的API Key这绝对是清理配置时最容易被忽视、也是最危险的一个角落。我见过不少团队各种自动化脚本里直接写着OpenAI API Key的长串明文理由都是内部项目不对外。但Agent的技能包存档、分享、迁移的频率远高于普通代码库万一某个包含Key的Skill被不小心推到公开仓库或者分享给外部协作方泄露面就完全失控了。大扫除期间建议把密钥清理单独列为一个环节全局扫描所有Skill目录和脚本文件找出硬编码的Key。换成环境变量引用或密钥管理工具的读取方式。如果发现某个Key已经暴露过果断在控制台吊销并重新生成不要心存侥幸。顺手检查一下账号里的API Key列表那些很久没用的、权限设置过宽的旧Key一律删除。另外Agent的权限边界也是需要重点关注的。如果某个Skill有操作仓库、提交代码的权限要确认它的权限范围是否符合预期。大扫除中顺手收紧权限是最省心的一次安全加固。6.2 配置兼容性的灰度验证与回滚方案清理配置、重构Skill之后不要立刻全量切换GPT-6那样风险太高。稳妥的做法是给自己留一个灰度期先开一个小范围的分支项目用新配置跑几天真实任务观察模型的实际表现。对比清理前后的任务完成质量看核心操作是否稳定有没有出现过度的自由发挥。确认稳定后再逐步把主要项目迁移到新配置。迁移前用Git给配置文件打一个tag只要一个命令就能回到清理前的状态。这套流程本质上是对新模型新配置这个组合的探索。清理旧配置只是一个起点真正的目标是在GPT-6环境下重新找到Agent工作流的最佳配置。灰度验证加上回滚预案确保整个过程可控出了问题随时能退回去。我自己的体会是配置清理不是一劳永逸的工程它更像一种定期维护的习惯。GPT-6会来GPT-7也会来模型能力的每次代际升级都是重新审视我们如何与模型协作的好时机。Skill和AGENTS.md作为人机协作的接口它们的质量直接决定新模型在你手里究竟能发挥出几成实力。趁这个时间窗口把积攒了很久的配置债务一次性还清后面的日子会轻松非常多。