共享 Agent 技能库也可能降低效果

把一套 skills/ 同时塞给主力模型、本地小模型和廉价分流模型，未必能让整个团队一起变强。作者的核心判断是：项目事实可以共享，但纠正模型行为的指令，需要按模型验证；同一句「编辑前先检查路径」，可能帮一个模型避坑，也可能让另一个模型多绕一步。

这篇值得读的地方，是它把 AGENTS.md 从「经验越多越好」拉回了工程评估：规则解决过什么失败，给谁用才有效，增加的调用成本是否值得。对同时使用多个编程模型的团队，这些问题比继续扩充提示词更实际。

项目事实可以共享，行为要求为什么不一定通用

作者先区分了两类经常混在一起的内容。

第一类是项目约定：项目使用 pnpm，某个接口返回没有响应体的 204，迁移文件放在 db/migrations，分页使用 cursor tokens 而不是 offsets。这些信息描述的是项目，换一个模型也不会改变，适合放进共享文件。

第二类是行为干预：编辑前确认路径存在，一次工具调用能完成的事不要拆成三次，测试失败两次后先读报错。这些要求通常来自某次事故，目的是纠正模型当时容易犯的错误。

作者把后一类称为「纠偏先验」（corrective prior）。可以理解成提前给模型施加一种行动倾向，让它更可能检查、更少盲目重试。

项目事实告诉模型环境是什么，行为规则则试图改变模型怎么做。

区别在于，不同模型的行为起点不同。一个经常编造路径的模型，可能需要先检查；另一个已经能正确处理路径的模型，再加同样要求，可能只会多调用一次工具。作者还提出一种风险：额外检查可能读到过期文件，反而引入混乱。不过，这段属于机制解释，原文没有提供对应案例的完整记录。

同一套技能包，为什么会出现相反结果

作者引用了一篇研究 harness 自我演化的论文。这里的 harness，可以理解为组织模型运行、工具调用和评测的外围系统；所谓自我演化，就是让 agent 在不同轮次之间修改自己的技能，而不是一直等人手工调整提示词。

原文最关键的数据来自消融实验，也就是比较「加技能包」和「不加技能包」的差别：在 103 个任务与技能配对中，同一套技能包，在研究中最强模型上约为 +31，在最弱模型上约为 −8.8。

方向相反，很有警示意义，但解释不能越界。原文没有给出论文名称、模型名称、指标单位和完整实验配置，不能直接把它写成「成功率提升 31 个百分点」。作者也明确表示，自己没有复现这套 harness。

作者自己的观察更有限：帮助主力 agent 的技能，在小模型上可能只是噪声，其中两例甚至比不加技能更差。这是个人使用经验，不能当作另一组严格复现实验。

共享文件的问题，还会被维护方式放大。有人踩坑就追加一条规则，删除却要拿出证据。久而久之，AGENTS.md 留下了不同模型、不同时期的纠错要求，却没人逐模型测量收益。文件越来越长，适用范围越来越模糊。

规则怎么进入项目，又该怎么退出

作者给出的做法分成三步。

先拆文件。conventions.md 保存跨模型成立的项目事实，统一版本管理和评审，并尽量保持简短；skills/ 则按模型配置。这里强调的是「清单」，即每个模型只加载经过验证、对它有效的技能子集。

再用真实失败做消融。作者保留了约 30 个 agent 曾经做错的任务，来自日志，每个都有通过或失败的检查条件。在同一组任务、相同 temperature 下，分别运行加载与不加载技能的版本，比较通过率。作者估计，小模型跑一次这样的对比大约需要 40 分钟计算时间。这是其环境下的估算，并非通用耗时。

最后，每条技能都要能追溯到具体事故。说不清是哪次运行促成的要求，就先别加进去。这个门槛能减少凭感觉堆叠的「你应该更谨慎」。

成本也要一起算。作者用「每轮多一次工具调用」举例：在多步骤任务中，工具往返可能占据大量延迟，即使原本正常的 90% 任务也会付出代价。原文用一条技能与十一条技能作比较，强调累积负担，但没有给出完整成本表，90% 也不应被当成普遍统计。

模型升级后，旧技能也需要重新验证。

作者用 checkpoint N 和 N+2 说明：为旧版本过度自信写下的规则，可能在模型已经修复问题后变成负担。技能并不是写好就永久有效的资产。

我的判断

作者说得最有用的一点，是要求行为规则有适用对象和验证依据。共享 AGENTS.md 容易让人误以为，只要文字合理，就能普遍改善模型表现。对多模型团队，这个假设确实需要检查。

但原文的论证还不足以证明「技能不能迁移」。更准确的结论是：迁移效果不能预设为正。作者自己也承认，项目事实可以迁移；行为规则是否有效，则需要实验回答。

约 30 个历史失败任务适合做回归检查，却主要覆盖已知问题。仅看这些任务，未必能发现规则对正常任务的拖累。相同 temperature 也是一个控制条件，原文没有交代重复运行次数，不能据此认定差异已经稳定。

相比维护一份统一的行为规则，按模型维护技能清单更精细，也增加了配置与复测成本。如果团队只用一个 provider、一个 checkpoint，没有本地回退，作者也承认问题会简单得多。此时先验证现有规则有没有帮助，比急着建立复杂的分层体系更划算。

能拿来做什么

• 检查项目的 AGENTS.md，把 pnpm、接口响应、目录位置等项目事实，与「先检查」「少重试」等行为要求分开；后者补上对应事故和适用模型。
• 从 AI 编程日志里挑选有明确验收条件的失败任务，分别比较各模型加载技能前后的通过率，并记录工具调用次数和耗时。
• 前端或 Node 项目切换主力模型、升级 checkpoint、引入廉价分流模型时，重新验证已有技能清单，不要默认整套继承。
• 对要求每轮额外检查的规则，同时观察历史失败任务和原本正常的任务，确认可靠性收益是否值得持续支付调用成本。