你发现 agent 在写数据库迁移脚本的时候又忘了加 IF NOT EXISTS。
这是第三次了。不是同一个 session 里的三次——是三个不同的任务，三周里发生的。每次你都在对话里纠正它，每次它都当场改对了。然后下次开新会话，一切归零。
你决定去翻一下团队维护的 skill 文件。确实，里面没有这条规则。为什么没加呢？因为每次纠正都发生在完成任务的对话里——改对了，任务结束了，人就去做下一件事了。没人停下来打开 skill 文件，把刚才的纠正写成一条规则。
这事你甚至不能怪谁。你自己就是那个纠正了三次也没去更新 skill 的人。
但这不只是你一个人的问题。
现状：没人碰不是自己写的 skill
如果你去看团队仓库里的 skill 文件，大概率会发现一个规律：每个人只维护自己最初创建的那几个文件。张三写的 testing skill 只有张三改过，李四写的 deploy skill 只有李四改过。偶尔有人在别人的 skill 文件里加了一行——通常是他在那个文件所属的领域踩了坑，不得不加。
这不是某个团队特有的问题。agent 技能市场里那些社区维护的 skill 仓库，贡献也高度集中在少数维护者身上。绝大多数用户 fork 了就用，不会往回提 PR。Addy Osmani 的 agent-skills 有 24 个 skill，但贡献者 list 比 star 数短一个数量级。
一个直观的解释是懒。但如果你跟这些工程师聊，会发现他们不懒——他们写代码、修 bug、做 code review，一天到晚都在做事。只是「更新 skill 文件」这件事，被排在了所有事情的后面。
往下挖，有两个原因。
为什么没人改
一个是怕改坏。
代码改坏了，测试会挂，CI 会红，reviewer 会看出来。skill 改坏了呢？一条 skill 规则写得不好，不会立即爆炸。它会让 agent 在某些场景下做出错误决策——可能是一周后，可能是另一个人遇到的另一个任务。到那时候，没人会把那次失败跟你在 skill 文件里加的那行字联系起来。
更麻烦的是，skill 是对所有人生效的。你改代码，影响范围大体可控——改了一个函数，影响的是调用它的路径。你改 skill，影响的是所有用了这个 skill 的 agent session——你甚至不知道都有谁在用。加一条「迁移脚本必须加 IF NOT EXISTS」听起来无害，但如果有人在写需要 drop 再 create 的迁移呢？
代码有测试、有类型检查、有多层 review 来降低改坏的风险。skill 没有这些东西。你只能靠自己的判断——而大部分人对自己的判断并不自信。
所以大家的策略是防御性的：只改自己负责的 skill，至少可以本地测一下。别人的 skill，除非万不得已，不碰。
另一个原因更根本：不改 skill，任务照样能做完。
写完一段代码，跟打开 skill 文件把刚才学到的规则写进去，这两件事在结构上是分离的。前者是完成开发任务，你不做它就做不完。后者是改进开发系统，你不做它也没什么立即的后果。下一次你会再遇到这个问题，再纠正一次，花两分钟。而停下来、组织语言、找到正确的 skill 文件、写一条清晰的规则——也要两分钟。
两分钟对两分钟。但在前一种情况下，你是在完成任务。在后一种情况下，你是在做一件额外的、没有 deadline 的、受益人是「未来的自己和其他人」的事。
这就是为什么 Jira 状态永远对不齐。不填 Jira，代码照样能上线。不改 skill，任务照样能完成。任何系统里，如果记录信息的动作独立于完成工作的动作，记录就会退化。有职业素养的工程师也会忘——注意力一旦锁定在当前任务上，就基本不会剩下什么留给「顺便更新文档」。偶尔有人记得做，那是额外的意志力在撑着。系统不能建在意志力上。
质量和参与度是一对矛盾
两个原因指向同一个困境，但解决它们的手段是互相矛盾的。
你想解决「怕改坏」，就得加强质量把控——加测试、加 review、加 approval 流程。但把控越重，参与成本越高，愿意贡献的人越少。你想解决「不必须」，就得降低参与门槛——让贡献变得像呼吸一样自然。但门槛越低，质量控制越弱，进来的噪声越多。
这不是 harness 特有的问题。任何希望同时追求参与度和质量的开放系统都会撞上这堵墙。ChatGPT 的 plugin 生态是一个很好的参照：当写一个 plugin 像写一段文字一样简单时，生态在几个月内就炸开了。但如果 OpenAI 一开始就要求每个 plugin 过安全审计、性能评估、UX 审核——plugin 数量可能还停留在两位数。
同时优化两个维度几乎不可能。拉一个，另一个就掉。解法是分阶段：先解决参与度，质量先不管；等到有了一定的信号和 case 积累，不再是凭空判断的时候，再回来解决质量。
有意思的是，InnerSource、企业 wiki、开源社区这些需要协作治理的领域，在解决类似问题时都不约而同地演化成了两阶段结构——先自由贡献捕捉信号，再定期整理控制 drift。不是谁设计的，是撞出来的。这从侧面印证了分阶段不是偷懒，而是参与度和质量这对矛盾的唯一出口。
加法靠众包，减法靠系统
把这两个阶段翻译成更直觉的语言：第一阶段做加法，把散落在对话里的纠正和经验变成可复用的规则。第二阶段做减法，把不再需要的、互相矛盾的、从未被用到的规则清理掉。
加法和减法的治理逻辑完全不同，所以放在不同阶段。
加法依赖具体 case。你只有在 agent 写迁移脚本忘了加 IF NOT EXISTS 的时候，才会意识到需要这条规则。这种信号是分布式的——每个工程师在自己的对话里遇到的坑，只有他自己知道。所以加法应该众包：谁能看到信号，谁就能（或者让 agent 帮自己）把规则加上去。加错了代价不高——一条噪声规则不会让系统崩溃，最多占点位置，后续减法可以清掉。
减法不能众包。一条规则该不该删，不能只靠提出它的人来判断——当初加它的时候是有理由的，只是现在可能不适用了。判断需要跨 case 的全局视角：这条规则在过去三个月里被触发过吗？删了它会不会让某个历史 case 重新失败？这种判断一个人做不了，需要系统的 eval 能力。
所以加法和减法天然应该分给不同的阶段、不同的执行者。加法是日常的、分布式的、低门槛的。减法是定期的、集中的、依赖 eval 基础设施的。
Phase 1：把「发现问题」从人身上移走
Phase 1 的目标是做加法——最大化信号捕获。基于这个目标，「指派 owner」不太走得通：owner 审核本身就是门槛，而且 owner 跟你一样不知道怎么判断一条规则的好坏，review 时的判断本质上是猜测。指望 owner 来驱动参与，只会让 owner 变成瓶颈。
降低贡献门槛——repo-first，skill 文件就在仓库里，改起来跟改代码一样方便——对「怕改坏」有一点帮助。有 git history，改错了可以 revert，心理负担小一些。但对「不必须」基本无效：再低的门槛也是门槛，只要不改也能完成任务，就仍然不会有人主动去做。
真正有效的方向不是让人更愿意做贡献，而是把人从「发现问题 + 表述规则 + 知道放哪」这个链条里解放出来，只保留最后一步：判断。
HALO 的实验显示了一个可操作的模式：采集 agent 的执行 trace，用分析引擎识别跨 trace 的系统性失败模式，产出 findings 报告，让 coding agent 根据报告修改 harness。在 AppWorld benchmark 上，同一个模型，仅靠 harness 优化就提升了 10 到 15 个百分点。
HALO 用的是 benchmark 的标准化 trace。日常开发的 trace 要乱得多。Gloaguen 等人的研究甚至发现，LLM 自动生成的指令文件比手写的差 20% 以上——直接让 agent 自己写 skill，质量堪忧。
所以关键设计是：agent 做挖掘和提案，人做判断和确认。贡献一条 skill 规则，你需要意识到问题、判断是否系统性、用清晰的语言表述、找到正确的文件、写进去——每一步都是主动决策。Review 一条已生成的提案，你只需要看一眼，判断「对」「不对」「改一下」。
这个方案直接回应了「不必须」：agent 在对话中主动发起建议——「这次协作里，我注意到你在迁移脚本上纠正了我两次。Skill 文件里目前没有这个规则。要不要我帮你加上？」人不需要切换上下文，不需要记得去做这件事。也回应了「怕改坏」：agent 的提案附带具体的 case 作为 evidence，人判断的不是一条孤立的规则对不对，而是「这条规则能不能防止这个具体 case 再次发生」。判断有了锚点，信心自然更高。
务实的第一步现在就可行：在 AGENTS.md 里加一条自进化指令，让 agent 在每个 session 收尾时主动检查是否有值得沉淀的经验。不需要额外的基础设施，不依赖任何人的纪律性。
当然，单 session 里的 agent 只能看到自己的对话。同一个 skill 的同一个缺失，在张三五次对话里各出现一次，在李四的对话里又出现三次——单个 agent 永远不会知道这是系统性问题。更完整的做法需要基础设施：把每个人的 session 摘要上报到一个中心化的 trace 平台，定期跑跨 session 的分析。这跟 HALO 做的是同一件事，只是数据源从 benchmark trace 换成了真实对话日志。成本更高，但视野完全不同——从「一个人看到的碎片」变成「团队累积的全貌」。
两条路不互斥。AGENTS.md 自进化指令现在就能跑，中心化分析等基础设施到位了再接上。前者的提案质量会低一些，但它解决了启动问题。
Phase 2：用 eval 驱动减法
Phase 1 跑起来之后，skill 文件会开始膨胀。规则只增不减。每条规则都是对某个 case 的回应，但规则越多，agent 的指令遵循度越差。Lost in the Middle 有明确的机制——Liu 等人的研究显示 LLM 注意力呈 U 形曲线，中间位置的指令被系统性忽略。Tian Pan 的实测数据更直接：500 条指令下最好的模型也只能达到 68.9% 的准确率，主流的连 53% 都不到。
所以 Phase 2 必须定期做减法。关键不在于「知道该删什么」——老规则、重复规则、从未触发的规则，找出来不难。真正难的是「确定删了不会出问题」。
这就是为什么 eval 基础设施是 Phase 2 的前提。没有 eval，减法就是猜谜。有了 eval，每次删除都可以验证：跑一遍测试集，分数没掉，这条规则就是噪声。
EvoHarness 的做法是一个好的参照：每次提出一个 harness 修改，先在少量 case 上做 pre-screening，成本很低——几个 case 跑下来只要几美元。没效果的提案直接丢弃，不用跑全量 eval。AHE 更进一步，每次修改绑定一个 change manifest，明确声明「这个改动预期修复什么、可能破坏什么」，跑完 eval 跟预测对比，修正和回归都落在明处。
但全量 eval 基础设施不是每个团队都立刻建得起来的。在没有完整 eval 的情况下，有几件事可以先做：
模型升级后系统性地删除。 每次底层模型更新，很多旧规则的底层能力已经内置了。ETH Zurich 的研究发现，更强的模型会把冗余指令当成噪声忽略——你在 AGENTS.md 里写的框架使用规范，新版模型不用教。模型升级后直接问 agent：「你现在能直接处理哪些我之前写明的规则？」它的回答就是一张删除候选清单。
用 git history 找噪声。 git log -p -- <skill-file> 能告诉你每条规则的来龙去脉。加了又删的——确认噪声。改了三次以上的——原始表述有问题，需要重写而非修补。从未被修改过的——要么完美，要么从未被触发。交叉对照实际的 agent 失败日志，就能区分这两种情况。
两条过滤问题。 来自 ETH Zurich 研究的实践：每条规则必须通过两个问题中的一个——「这条规则解决的是代码本身无法表达的取舍吗？」或者「agent 没有这条规则需要大量探索才能推测出来吗？」两个都 pass 不了，删除。
用工尺谱替换乐谱。 一个常见的模式：200 行的 AGENTS.md，大部分是在描述 agent 自己跑一遍项目就能知道的事——缩进规范、引号风格、目录结构。与其写规则告诉它怎么做，不如写验证命令让它自己检查：npx eslint、npx tsc --noEmit、cargo clippy。原来 200 行变成 30 行规则加 5 条验证命令。规则少了，反而更可靠。
设硬上限。 约定 AGENTS.md 不超过 150 行。OpenAI 的 harness 指南建议约 100 行，HumanLayer 的研究得出 150-200 条指令的预算上限——超过之后指令遵循度系统性下降。AGENTS.md 是常驻 context 的，所以硬约束有实际意义。skill 文件不同——它是按需加载的，不会跟其他 skill 同时挤占 context。所以 skill 文件不必设绝对字数上限，更应该关注的是信号密度：加载之后，每条规则都在防止一个已知的失败 case 吗？那两条过滤问题对 skill 同样适用。不管什么文件，越界了就触发一次减法——不是建议，是必须。没有节拍，减法就永远是「下次再说」。
这些轻量手段不能替代 eval 驱动的系统性能评估——AHE 和 EvoHarness 的数据表明，有 eval 的减法比没有 eval 的减法提升高出好几个百分点。但它们可以在 eval 设施还没建好的时候，先止住膨胀的趋势。
以上是论证。下面是落地。
从哪里开始
说了这么多，对一个具体的团队来说，到底该怎么做？
本周就能做。 第一，在 AGENTS.md 里加一条自进化指令，让 agent 在每个 session 收尾时主动检查是否有值得沉淀的经验，当场问你要不要存。第二，跟团队对齐一个心态：当你在对话中纠正了 agent，而现有 skill 里没有对应的规则时，直接加上去。不需要评审，不需要犹豫。加错了 Phase 2 的减法会清掉，不加的话信号就丢了。第三，skill 文件和 AGENTS.md 全部放在仓库里，repo-first——clone 下来就能用，改起来跟改代码一样顺手。第四，约定 AGENTS.md 不超过 150 行，越界就触发修剪，制造定期做减法的节拍。
下个季度可以做。 模型升级后系统性审查已有规则——问 agent「新版模型下，哪些规则你已经内置了？」答案就是一张删除候选清单。定期跑 git log -p -- <skill-file> 审计变更模式，加了又删的、反复修改的，都是清理对象。用工尺谱替换乐谱——把规范描述改成验证命令，让 agent 自己跑 npx eslint 而不是靠人写一百行代码风格规范。
等基础设施成熟后。 如果团队有条件建中心化的 session 日志平台，把每个人的对话摘要上报上去，定期跑跨 session 的 pattern 挖掘。同一个 skill 的同一个缺失在十个人的对话里各出现一次，单个人永远不会知道，但中心化分析一眼就能看出来。更进一步，建一套 eval harness——哪怕最初只有几个关键 case——让每次减法都有数据支撑，不再是猜谜。
但最重要的建议是顺序不能反。 先让加法跑起来。信号不够多的时候，减法的收益是有限的。Skill 文件还很薄的时候就启动质量审查，只会让本来就不踊跃的贡献变得更冷清。等到文件开始膨胀、agent 的指令遵循度开始下降的时候，再启动 Phase 2。在没人贡献的时候严格把关，不如在有人贡献的时候先把信号接住。
一句话： 把「发现问题」交给 agent，把「判断要不要」留给人——加法靠这个，减法靠 eval。按这个顺序来。
我现在还没搞明白的一些事
「怕改坏」可能比「缺乏验证手段」更微妙。skill 规则一旦写进去，是不是就变成了一种承诺？代码改错了可以修，但 skill 规则代表你对 agent 行为的一种判断，改来改去会让人觉得「你怎么连这个都拿不准」。这可能让工程师在面对别人的 skill 时更不愿意出手——不是怕技术后果，而是怕社交尴尬。我不确定这个因素占多大比重。
信号识别到底能做到多准。一次性的小笔误和系统性的 skill 缺失，在单条对话记录里看起来可能一模一样。怎么让 agent 区分「这次只是碰巧」「这是模型那天状态不好」「这是 skill 真缺了东西」？也许需要积累足够的样本量才能判断，但积累多少算够？
如果团队没有中心化的 session log 基础设施（大部分团队都没有），单靠 AGENTS.md 的自进化指令能抓到多少信号？3-5 人的团队里，agent 在各自 session 里零散地提建议可能够了。但人多了以后，跨 session 的重复 pattern 会漏掉。这个规模阈值在哪，我不知道。
参考文献
- Gloaguen et al. (2026). An Empirical Study of the AGENTS.md file. 对 138 个真实仓库的研究发现，手写的 AGENTS.md 提升 agent 成功率约 4%、减少 35-55% 的 bug；LLM 自动生成的指令文件反而降低成功率超过 20%。
- Liu et al. (2023). Lost in the Middle: How Language Models Use Long Contexts. TACL. 发现 LLM 注意力呈 U 形曲线，中间位置的指令被系统性忽略。
- Tian Pan (2026). Instruction Complexity and LLM Performance. 实测多个模型在 500 条指令下的表现：Gemini 2.5 Pro 68.9%，Claude 3.7 Sonnet 52.7%，GPT-4o 15.4%。
- Shinn et al. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. NeurIPS 2023. Agent 维护反思性记忆 buffer，在 HumanEval 上达到 91% pass@1。
- HALO (2025). Hierarchical Agent Loop Optimization. 通过采集执行 trace、跨 trace 分析失败模式、迭代修改 harness，在同一模型上提升 10-15 个百分点。
- Lin et al. (2025). AHE: Agentic Harness Engineering. 每次 harness 修改绑定 change manifest，声明预期修复和潜在回归，eval 后交叉验证。
- EvoHarness (2025). 引入 pre-screening（少量 case 快速验证提案，无效则丢弃）和 fragility tracking，在 TerminalBench-2 上单次迭代翻转 9 个失败 case。
- ETH Zurich / Wortmann (2025). Failure-backed pruning heuristic: 只保留四类规则——有失败案例支撑的、工具可强制执行的、编码了刻意决策的、对应真实触发场景的。两条过滤问题作为删除标准。