公告栏的治理不是往上贴，是往下取。
这是《Flashduty AI SRE 技术揭秘》第 22 篇。查看 SRE Agent 架构与工程实践系列，或先读生产会话失败筛选和授权信封。
Agent 产品容易遇到一个问题：prompt 膨胀。每次线上翻车，最顺手的修复就是往系统提示里加一句话。加的时候每句都有道理，积累下来却可能出现重复或矛盾的指令，也会增加上下文和缓存成本；如果没人记得每句话当年是为什么加的，清理就更困难。第 5 篇讨论了上下文压缩与缓存成本。
我们的疗法分两层：底层的版本化机制（prompt 怎么发、怎么绑、怎么回滚），和上层的治理约定（什么才有资格进 prompt）。这篇两层都讲。
核心要点
- 版本管理： Prompt 按版本保存，新会话按权重选择并冻结版本；内容指纹帮助发现同一版本号下的未版本化修改。
- 修改依据： 新增指引先说明要修复的具体失败，再判断它应该属于工具结果、工具描述、知识包还是系统提示。
- 验证与取舍： 通过评测和审计反馈验证修改；文中 31% 的删减是一次具体版本的记录，并非普遍可达到的效果。
一体一文件，文件名即版本
线上 prompt 不是散在代码里的字符串，是一个版本一个 Markdown 文件：v1.md、v2.md、v4.md。文件名就是版本号——这个设计的要义是"不存在第二处可能与之不一致的地方"：没有一个常量表、一个 manifest 能说"当前版本是 X"而文件其实是 Y。版本的全部历史就是文件的 git 历史。
围绕它有四条运行纪律：
新会话抽签，终身冻结。 会话创建时按配置的权重抽取版本；我们曾在一次 A/B 实验中对 v2、v4 分别使用一半的权重。抽定后版本冻结在会话记录里，老会话不因新版本发布而迁移。这是 A/B 可比性的前提，也意味着可以通过调整权重回滚新会话使用的版本。
未知的版本号兜底到默认版。 会话的版本冻结可能比某代二进制活得久（回滚发布、滚动部署中的旧 pod），一个会话绝不该因为"不认识自己的版本号"而丢失 prompt。
改了内容必须改版本号，有指纹守着。 每个版本带一个内容哈希指纹，随版本一起冻结进会话。审计按版本分组时顺带报告每个版本下见过的指纹集合——同一版本号下出现两个指纹，就是"有人改了内容没改版本号"，同一批实验对象混进了两种 prompt，A/B 结论直接作废。这个失败模式是被指纹兜住的，不是靠自觉。
实验结束，输家的文件和指认赢家在同一次提交里删除。 目录里不留"foo2 躺在 foo 旁边"的烂尾状态。
治理约定：先问该去哪个家
机制管"怎么发"，治理管"发什么"。我们的仓库宪法里有一条原文：
系统提示只装 agent 动手前必须知道的。绑在特定工具结果上的指引，骑在那个结果的信封上；工具的用法写在工具描述里；领域方法论写在知识包的 DUTY.md 里。一条审计驱动的 prompt 新增，必须说明它补的是哪个具体失败，并且先检查这三个家——不要默认加一段永久的 prompt 文案。
三个家在这个系列里都出现过：授权信封把 agent_instructions 放在结果上；工具描述说明 grep 的参数用法；DUTY.md提供知识域的常驻指引。系统提示里关于它们只有指针和元规则：“信封里有指引，读它”、“DUTY 索引是有约束力的，动手前读它”。
“必须说明补哪个失败"这一条，在执行层面变成了 commit message 的纪律。翻 prompt 文件的提交历史，每条都挂着具体的失败观察：“真实排查里，agent 遵循了结论模板，却把事件号写成了纯文本”——于是加一句链接要求；“聊天回答在多余的标题下重复同一个发现”——于是收紧结论长度；还有一次带着量化证据：“v2 会话里 175 次某 CLI 调用有 55 次之前先跑了 --help"——说明 prompt 里缺了调用形状。每条新增都能回答"补的是哪个失败”，这就是日后敢删它的依据。
治理能力的证明是敢删
我们曾做过一次大删减：一个版本的 prompt 体积减少 31%。删法完全按治理规则执行——删掉"已经各有主人"的段落（工具描述里有的、技能文件里有的、信封里有的，prompt 里的副本全是冗余）；合并重复表述（同一件事说了两遍的并成一遍）；消除两处自相矛盾（一处承诺标题列表可渲染、另一处禁止它们；一处说"帮助信息很便宜直接用”、另一处要求先读参考文档）。这里没有列出体积的计算单位和删减前后的评测结果；这一比例只描述当次修改，不代表 Agent 效果的提升幅度。
自相矛盾是膨胀期特有的病：不同时间、针对不同失败加进去的句子，没人检查它们彼此打架。模型夹在两条矛盾指令中间，行为取决于哪条离相关上下文更近——等于把行为交给了排版。
一条指引的归位顺序：信封、工具描述、知识包，都不合适才轮到系统提示。
闭环
把前面几篇串起来，prompt 治理其实是一条闭环流水线：评测和审计发现失败（第 19、20 篇的分类法和负样本车道）→ 定位该去的家（信封、工具描述、知识包，还是不得不进 prompt）→ 版本化发布（新臂按权重灰度，老会话不动）→ 再评测验证（A/B 账本判定胜负，赢家留下，输家的文件同提交删除）。
每个环节都有前几篇讲过的机制在兜底：失败是证据不是感觉，发布是抽签不是替换，胜负是账本不是印象。prompt 从"谁都能顺手改的文本"变成了"有版本、有冻结、有验收的发布物"——这是治理这个词的全部含义。
下一篇讲产品 sense 如何落成工程参数：告警风暴下，一次 RCA 分析最多吸收 20 个事件。
