最近我把自己维护了大半年的Agent工作目录翻出来准备迁移到GPT-6测试环境。第一个反应不是兴奋而是头皮发麻。目录里堆了47个Skill文件AGENTS.md早就膨胀到1200多行里面有一半规则我自己都不知道当初是为了约束什么才写进去的。跑了一次基准任务效果比在旧模型上还差模型频繁被互相冲突的指令绕晕。后来我把Skill和AGENTS.md彻底做了一次大扫除行为质量才重新回到正常线以上甚至超出预期。这篇就是我这次清扫的完整记录同时也是给所有维护Agent技能库、天天和AGENTS.md打交道的开发者的一份操作手册。如果你刚接触这些概念被五花八门的skill和规则文件搞得头大同样可以照着里面的思路从零梳理。1. 为什么GPT-6时代必须重新审视Skill和AGENTS.md1.1 模型能力变了旧约束在帮倒忙很多人没意识到Skill和AGENTS.md本质上是“给模型写的代码”。GPT-5时代你写“请每一步都先检查用户输入是否安全”它确实会照做但代价是大幅增加推理延迟。到了GPT-6这类新模型上同样的规则可能不再被需要甚至会成为模型理解任务的干扰项。我打个比方。旧模型像一个刚入职的实习生你必须在工位上贴满便签纸“发邮件之前检查收件人”、“文件名不要用中文”、“输出格式参考第3条”。但等到这个实习生干了半年已经熟练到闭眼就能干活你再让他看那堆便签纸他反而会把每条便签当成独立任务去执行凭空多出一堆无关动作。GPT-6最明显的变化是上下文理解能力更强能更准确地判断哪些指令属于“约束边界”、哪些指令属于“任务本身”。所以那些用来弥补旧模型理解力不足的“拐杖型规则”确实可以拆掉了。我实测过同一个任务在AGENTS.md里删掉17条“防止模型跑偏”的注释后输出质量没有下降生成时间却缩短了20%。但注意这里有个反向陷阱新模型可以处理更模糊的指令并不意味着你可以完全不写规则。如果AGENTS.md清空Skill也没了它就会回到“通用大模型”状态丢失你这套系统的独特业务逻辑。所以这不是“删掉一切”而是“只留下有用的”。1.2 AGENTS.md从“小抄”变成了“噪音污染源”AGENTS.md最开始的设计目的是给Agent提供项目级的行为准则相当于每次对话开始前塞给模型一张项目小抄。这在小项目里非常好用三五条规则就能显著提升任务质量。但随着项目迭代这张小抄会变得越来越大大到模型不知道该优先看哪一条。我见过最夸张的一个开源项目AGENTS.md里既有“代码风格请参考Google开源指南”又有“函数注释必须写满五行”还有“如果遇到数据库问题请查看docs/db.md”。这些规则单独拿出来都合理但放在一起模型每次都要判断优先级解释成本远超收益。更麻烦的是很多AGENTS.md里的规则已经在Skill层实现了。比如你写了一个code-review的Skill里面明确规定了代码审查的检查顺序和输出格式然后在AGENTS.md里又写了一遍“每次代码审查要按代码风格、性能、安全、可读性的顺序”。两个信息源不一致时模型就会面临冲突。在我这次大扫除里光这类重复规则就找到了9处。所以我认为GPT-6时代必须先做的不是“加更多rules”而是“减规则”。新一代模型本身带上了更多常识和工具使用能力你要做的是给它一个干净、透明、无冲突的决策框架而不是一个塞满注意事项的行李箱。2. Skill大扫除先分家再删减2.1 给Skill做一次全量体检Skill是最近很火的概念简单说就是你把一个复杂任务的操作流程、输入输出格式、判断逻辑打包成一个独立技能文件让Agent按需调用。好处是模块化坏处是无序膨胀。我建议大扫除第一步把项目里所有Skill列成一张表不要凭印象判断。我给自己的Skill做的体检表大致是这样Skill名称目录名或标识符最近调用时间从日志里统计超过30天没被调用的直接标红Skill行数超过300行的标记为“疑似过重”调用成功率基于最近20次实际任务成功率低于60%标记为“疑似失效”关联模型版本比如有些Skill是专门为某个旧模型写的里面有大量“如果模型不理解就……”之类的旁路逻辑是否与其他Skill重复比如存在review-code和code-reviewer两个同类文件这一步做完你会发现自己真正高频使用的Skill可能不到10个。我当时统计出来47个Skill里有22个在过去30天从未被调用还有6个和别的Skill功能高度重叠。这就是最典型的清理对象。体检本身不复杂但有个细节要提醒不要只看文件修改时间。很多人用“我上个月改过它”来判断Skill是否活跃这不准。必须看“Agent在执行任务时是否真正加载过这个Skill”。如果你的运行日志没记录加载情况建议先在调用入口处加一行日志跑几天再清。当时我差点删掉一个看起来很久没动的Skill结果日志显示它每天都在被一个定时任务调用只是没产生明显的独立日志。2.2 保留、合并还是删除三档分类法体检完之后我给每个Skill分了三个档位第一档保留并且整理结构。这类Skill通常是核心业务逻辑比如针对你特定领域的任务处理流程被高频调用且成功率稳定。它们不需要大改但需要统一格式。我的保留标准很简单过去30天调用次数大于10次且成功率高于80%。第二档合并消除重复。比如两个Skill都涉及“信息检索后的去重处理”只是入口不同。这种情况下把公共逻辑抽到一个共享模块里再让两个Skill分别引用。实际操作上有两种方式如果你用的是单体Skill目录可以把公共部分写成一个小工具函数如果你用的是更结构化的Agent配置可以拆出一个common-skill目录专门放公共能力。第三档封存或删除。超过30天没用、和别的Skill重复、或者只是当时为某个临时任务随手写的一个脚本这些都属于第三档。我不建议直接物理删除而是先移到archive/目录。好处是出问题时能快速回滚。封存一个月之后如果没人找过它再彻底删除。这里说一下“仓颉Skill”这个热词。它本质上就是一类特定领域的Skill因为任务场景非常垂直被很多人在社区里传播。但你要注意网上下载的Skill和自己项目的AGENTS.md之间往往存在规则冲突。比如某个仓颉方向Skill可能会定义“代码中不能出现某些写法”而你的项目规范里可能是允许的。这种冲突只靠Skill内部调试是看不出来的必须在整体大扫除时一起跑一遍。我见过有人下载了十几个热门Skill全塞进项目里结果模型每步都在Skill之间跳来跳去反而干不了正事。3. AGENTS.md重构实战3.1 先看现有文件里有多少“僵尸规则”AGENTS.md里的“僵尸规则”指的是那些已经不再被需要、但还留在文件里不断被模型读取的规则。常见来源有三种早期为补偿旧模型短板写的约束、后来已经固化进代码逻辑里的流程说明、以及无人认领的历史遗留规定。怎么识别我自己用的是“删除测试法”把某条规则暂时注释掉跑3到5个典型任务看输出是否有实质变化。没有变化的规则就是僵尸规则直接删。注意不是同时注释掉一批而是一条一条测否则根本不知道是哪个规则在起作用。另外还要留意AGENTS.md里的“自我引用”现象。比如有人会在规则里写“请遵守本文件中的所有规则”这句话没有任何操作性但会让模型把整个文件的权重都提高等于把所有僵尸规则又激活了一遍。我清理时把这类无意义元指令去掉了效果立竿见影。我还发现很多AGENTS.md存在章节排序混乱的问题。比如安全规则分散在文件各个角落编码规范夹在部署说明中间导致模型每次都要满文件找规则。重构时第一件事就是把内容按主题分区并且把“必须遵守”的硬性规则放在文件最前面。3.2 把规则分级必须遵守、尽量遵守、仅供参考一个能应对新模型的AGENTS.md不能所有规则都是同一个优先级。我按三层体系重构P0必须遵守。这类规则一旦违反会产生严重后果比如“不得删除生产环境的数据库记录”、“所有外部输入必须经过白名单校验”。数量控制在5条以内写在文件最顶部。模型的上下文窗口再大最前面的内容权重依然是最高的所以要把最重要的事放在前100行。P1尽量遵守。这类规则属于“默认情况下按此执行但用户明确要求时可以不遵守”。比如“变量命名优先使用snake_case”“接口返回值统一包裹一层data字段”。这类规则数量也不要超过15条。P2仅供参考。包括项目背景、术语解释、目录结构说明等。这些内容不是行为规则而是帮助模型理解上下文。不需要写成祈使句用描述性语言即可。这套分级最大的好处是模型在决策时能快速识别“什么是必须满足的底线什么是可以灵活处理的空间”。旧版AGENTS.md最大的问题就是所有规则都在同一水平线上模型不知道为了满足某条规则可以牺牲什么。3.3 模板化一个干净的AGENTS.md应该长什么样经过这次大扫除我整理出一个比较通用的AGENTS.md结构模板不是让你照抄而是提供一个参考支架# 项目概述 一两句话说明这个项目是干什么的目标用户是谁。 # 硬性约束P0 - 规则A - 规则B # 编码与实现规范P1 - 规范A - 规范B # 工作流程约定P1 - 流程A - 流程B # 项目结构与关键术语P2 - 目录说明 - 术语表你可以看到这个模板里每一条规则都非常具体不存在“要注重代码质量”“要有良好的设计”这种空话。写AGENTS.md和写Prompt一样抽象表达等于没写。另外我强烈建议AGENTS.md文件本身不要超过200行。如果你的项目规则确实很多拆分为多个子文件在主文件里用简短索引指向它们。这里有两点要特别注意第一主文件里要有足够的上下文让模型决定“什么情况下去读取哪个子文件”否则索引等于没有第二子文件路径应该清晰不要用./docs/related/whatever.md这种含糊描述。当时我就是把将近10个领域规则分别拆到了docs/rules/*.md里并在主文件里列出了每个文件的适用场景模型行为稳定性提升非常明显。4. 清理后的验证与回归测试4.1 用经典任务当“体检指标”大扫除不是删完就算完事必须有一套可量化的验证方案。我在清理前先设计了一组“体检任务”每个任务对应你项目里最核心的3到5类使用场景。比如我自己的项目涉及代码审查、文档生成、数据分析和单元测试生成我就准备了5个代表性任务作为基准。关键操作是在清理之前先跑一遍记录输出质量和耗时清理之后用完全相同的Prompt再跑一遍逐项对比。如果输出质量持平或提升说明删对了如果明显下降则说明删掉了关键规则需要捞回来。第一次跑的时候建议用Git打一个tag记录清理前的状态。我当时就是这样做的因为第一次删减后有个任务输出变得过于随意我对照着恢复了两条P0规则才解决问题。4.2 每次清理只改一个变量我在踩了一遍坑之后得到一个教训清理Skill和清理AGENTS.md要做成两个独立阶段不要同时进行。如果你在同一天既删了10个Skill又重写了AGENTS.md最后测试出问题你根本不可能知道是Skill删错了还是AGENTS.md改坏了。更稳妥的做法是先冻结AGENTS.md只清理Skill。跑一轮测试。确认Skill清理没有副作用后再重构AGENTS.md。又跑一轮测试。两边都稳定后做一次全量回归把高频任务全部跑一遍。这里有个现实问题有些场景跑一轮测试时间很长成本很高。我的做法是准备一套“快速回归集”每个任务只截取最关键的步骤而不是完整跑完。比如代码审查只挑一个500行的文件重点看模型有没有按规范给出结构化意见而不是真去审一整个大型仓库。这样可以快速发现问题把完整回归留到周末统一执行。4.3 建立Skill变更日志Skill和AGENTS.md本质上和代码一样应该纳入版本管理而且要有变更记录。我之前没有做这一步导致每次改动都是“改完就忘”等出问题时只能靠感觉回溯。现在我的做法是在项目根目录放一个SKILL_CHANGELOG.md记录每次增删Skill或修改规则的时间、原因和验证结果。格式很简单## [日期] 删除 abc-skill - 原因与 def-skill 重复调用成功率低 - 影响范围涉及代码审查任务最近30天未调用 - 验证跑过 code-review 基准任务输出质量持平这个文件不一定要写得多正规但一定要坚持更新。尤其是当你的项目被多个协作者维护时这个变更日志能避免很多争执。有一次同事问我为什么要删某个Skill我直接把日志链接发过去他看了一眼原因就明白了省了一通解释。5. 避坑清单与我的实操心得5.1 最容易踩的四个坑大扫除过程中我踩了不少坑这里挑四个最常见的说。第一个坑把所有Skill一视同仁。有的Skill是纯规则描述有的Skill是可执行脚本有的Skill是带输入输出示例的few-shot模板。它们的维护策略完全不同。规则描述类可以随便删但带可执行代码的Skill删之前一定要看有没有被其他模块引用。我在清理时就碰到一个Python脚本Skill被另一个数据清洗Skill当作工具调用差点误删。第二个坑过度依赖网上的“推荐Skill列表”。社区里热门的Skill往往针对特定的模型版本和项目场景。别人说好用不代表在你的项目里好用。Skill这个东西非常吃上下文你的AGENTS.md、项目结构、模型版本都会影响Skill的实际效果。我个人的建议是网上的Skill只能当参考拿回来必须重新写适配层不能直接扔进目录里。第三个坑AGENTS.md删得太狠把业务知识也删了。AGENTS.md里除了规则还有大量项目背景信息比如“这个系统是给医院用的必须遵循医疗数据规范”“这个库的底层依赖老旧不要升级大版本”。这类知识不是“规则”而是模型理解项目的基础。如果你只盯着“规则”两个字去清洗很容易把这部分当成条文误删。所以清理AGENTS.md之前我建议先把整份文件读两遍区分“约束”和“背景知识”。第四个坑只测成功路径不测失败路径。清理完Skill后不要只跑正常任务还要故意输入一些边界情况或非法请求看模型是否还能正确拒绝或降级处理。很多时候删除某些规则会导致模型在异常情况下失去兜底能力。新模型虽然理解能力更强但如果你把“禁止访问敏感文件”这类保护性规则删了它可能真的会按字面意思去执行一个危险命令。5.2 老skill不要直接删先封存大扫除时面对那些两个月没被调用的Skill最手痒的就是直接rm -rf。但我劝你忍住。因为你不知道未来会不会为了一个临时需求又要用到里面的某段逻辑。这种场景我自己遇到过不止一次某个Skill因为当时不太匹配旧模型被我扔进archive结果新模型能力变了原本不好用的实现方式突然又变得可行了。封存有两种方式。简单粗暴的是直接把文件夹移动到archive/并在文件名后面加日期。稍微正式一点的是写一个简短的存档说明把Skill的用途、被替代原因、可能重新启用的条件写清楚。我倾向于第二种因为当你一个月后翻archive时基本不会记得当初为什么要封存它。5.3 大扫除不是一次性工作最后说一个心态问题很多人的大扫除是“三年一次一次管三年”这是不对的。尤其是Skill和AGENTS.md这种和模型能力强绑定的东西几乎每一次模型重大升级都需要重新审视一遍。因为模型能力在变旧约束可能不再必要旧Skill的效果也会因模型行为变化而漂移。我现在把这个整理动作沉淀成了周期性任务每两周花半小时检查一次Skill调用日志每个季度做一次完整的AGENTS.md评审。不要觉得这是浪费时间实际上它能帮你在模型升级时快速定位问题。上次GPT-6测试环境刚出结果我之所以能在半天内定位到是旧规则拖慢了模型就是因为季度评审记录做得完整我能很快对比出“哪些规则在旧模型上有效、在新模型上不再触发”。我自己还有一个习惯每次在社区看到别人推荐的Skill不会立刻装到正式项目里而是先放到一个隔离的实验目录里跑几天。看过实际效果、验证过和现有AGENTS.md无冲突之后再决定要不要合并进来。这个习惯帮我避免了不少“加了一堆技能结果反而变傻”的尴尬情况。Skill和AGENTS.md的维护本质上是在给Agent做减法。GPT-6带来的不是“装更多东西”而是“让模型有空做更多事”。清理掉那些过时的、重复的、互相打架的文件之后你会明显感觉到模型的输出更干净、更可控也更像你真正想要的那个“虚拟员工”。
