系统提示词膨胀至20万字符：记忆系统设计与工程反思

近期，某头部 AI 实验室新一代旗舰大模型的系统提示词被社区完整整理并公开，总长度已逼近 20 万字符；而一个月前，其上一代模型还停留在 12 万字符左右。一个月内近七成的增量里，塞进了一整套持久化记忆文件系统规范、多端产品界面说明、工具调用细则、更细化的安全条款，甚至包括服务因出口管制下架又恢复的完整事件时间线。本文先拆解这次膨胀中最值得研究的技术设计，再讨论“补丁式增长”背后的工程风险与治理思路。

一、膨胀从哪里来：逐条拆解增量内容

对比前后两版，新增内容大致可归为六类：

1. 持久化记忆文件系统规范（本次膨胀的绝对主力）：约 200 多行，覆盖读写时机、文件格式、目录结构、隐私边界、多端并发写入与冲突处理，详细程度不亚于一份内部产品规格书。
2. 模型回退机制：轻量模型遇到高风险请求时回退到旗舰模型处理的路由说明。
3. 多界面产品说明：聊天助手、智能编程工具、办公协作界面、浏览器助手、电子表格、演示文稿等多个产品形态各自的行为约定。
4. 工具与能力规范：搜索、文件操作、富内容生成、写作与引用格式、工具调用约束。
5. 安全策略细化：儿童安全、心理健康、武器制造、网络安全攻防、超长对话等场景的专项提醒。
6. 语言风格与交互规则：细化到标点、格式、语气，以及“何时追问澄清、何时直接执行”的边界。

这六类增量共同指向一个朴素但危险的工程直觉：凡是模型“曾经做错的事”，就补一条显式规则堵住；每上线一个需求，就多一段说明或分类器解释。规则只增不减，系统提示词便从“行为宪法”逐渐膨胀成“操作手册 + 产品百科 + 合规手册”的复合巨型文档。

二、最值得研究的模块：跨会话记忆文件系统

抛开膨胀本身，这次泄漏中设计密度最高的部分是记忆系统规范，其思路对任何构建长期记忆型 AI 应用的团队都有参考价值。

2.1 设计理念：为“未来的自己”写记忆

规范开篇的表述颇具代表性：这是模型跨会话的工作记忆，写入它不是因为用户要求，而是因为未来的会话需要这些上下文。这句话背后有三层设计判断：

• 记忆是主动行为而非被动存储：模型应当在判断“此信息跨会话仍然有效”时主动落盘，而不是等用户明确说“记住这个”；
• 记忆是多端共享的：聊天界面、智能编程工具、办公协作界面共用同一套记忆文件，甚至可能同时修改——这直接把并发写入与冲突处理推上了必答题；
• 记忆有写入门槛：并非所有对话都值得持久化，需要明确判据决定“什么进、什么不进”。

2.2 注入策略：目录先行、正文懒加载

系统提示词明确规定了每轮注入的记忆内容——不是全部记忆，而是三样东西：

• <profile>：身份档案（如 /profile.md）的正文；
• <preferences>：用户对回答方式的偏好；
• <memory_listing>：所有记忆文件的路径、简介、别名与来源。

其余记忆文件只出现在目录列表中，正文并不注入。当模型判断某文件与当前问题相关时，再通过类似 read_file() 的读取接口拉取全文（接口名仅为示意）。目录的典型形态如下：

<memory_listing>
  /profile.md           用户身份与职业背景（来源：用户陈述）
  /areas/app-project    应用项目：架构决策与进度记录
  /people/partner       长期协作伙伴的关键信息
  /topics/food          饮食偏好相关话题
</memory_listing>

这是典型的两阶段检索：先以目录做粗筛，再对疑似相关的文件做精读。本质上是在上下文窗口这个“寸土寸金”的资源上实现了分层缓存——热数据（身份、偏好）常驻，冷数据（具体项目细节）按需加载。这种做法直接控制了每轮的固定 token 开销，也让记忆总量可以远超单轮上下文容量。

2.3 “先查再答”原则：对抗模型的不检索倾向

整套规范中最容易被忽视、却最能体现实战经验的一条约束是：在回答“没有这项信息”之前，必须先检查目录并读取可能相关的文件。

举一个具体场景：目录中存在 /areas/app-project、/people/partner、/topics/food 三项，用户问“我的应用项目之前决定用什么架构”。架构决策大概率写在 /areas/app-project 里，但它的正文并未注入当前上下文。规范要求模型必须先读取该文件再作答，不能因为“当前上下文里没有”就脱口而出“不知道”。用伪代码表达这条约束：

应答流程（示意）：
1. 解析用户问题，扫描 memory_listing 中的路径与简介
2. 命中疑似相关文件 → 调用读取接口获取正文
3. 结合读取内容与当前对话作答
4. 仅当步骤 1~2 一无所获时，才允许回答"我不知道"

这条规则针对的是大模型应用的一个经典缺陷：模型天然倾向于只依赖当前上下文作答，缺乏“主动检索后再回答”的自觉。把它写成硬性流程，能显著减少“伪不知道”——明明知识库里有，模型却说没有的情况。

2.4 组织方式：按稳定性与主题分域

记忆文件按维度划分为若干类别，从泄漏内容中可以明确识别的包括：稳定身份档案（profile）、活跃领域（areas）、联系人（people）、兴趣话题（topics）等。其中身份档案的写入判据被明确表述为一个时间检验问题——“三个月以后这个信息是否仍然成立”。

姓名、职位、长期职责这类信息能通过检验，进入 profile；而“这周在改某个缺陷”这类短周期信息则不应沉淀为长期记忆。用时间稳定性做写入门槛，本质上是在对抗记忆系统最常见的失败模式：噪声越积越多，检索信噪比持续下降，最终把记忆库变成垃圾场。

2.5 一份可复用的记忆架构清单

把具体实现抽象掉，这套方案沉淀出一张可直接复用的设计清单：

设计问题	采用的方案	直接收益
上下文预算有限	目录注入 + 按需读取	常驻上下文规模可控
模型不主动检索	强制“先查再答”流程	减少“伪不知道”
记忆噪声膨胀	时间稳定性写入门槛	维持检索信噪比
多端并发写入	显式冲突处理规范	避免记忆互相覆盖
隐私敏感信息	隐私边界与来源标记	敏感数据可审计

三、膨胀的代价：四类系统性风险

即便单个模块设计精良，20 万字符的系统提示词本身正在成为风险源，主要体现在四个方面。

第一，注意力稀释。 研究普遍发现，长上下文中模型对中部信息的利用率显著低于首尾。20 万字符的提示词里，大量规则实际处于“写了但很少被遵守”的状态；安全条款越多，单条条款的约束力反而可能越弱。

第二，规则冲突的组合爆炸。 规则数量线性增长时，两两之间潜在冲突的组合数是平方级增长。“保持简洁”与“长对话中应主动总结回顾”、“直接执行指令”与“高风险操作先确认”这类规则，在边界场景会互相打架，最终行为取决于模型对上下文的隐式仲裁，回归测试的难度陡增。

第三，维护成本失控。 没有版本管理、没有变更评审、没有规则级测试的提示词，与没有持续集成流水线的“祖传代码”没有区别。这次泄漏之所以有分析价值，恰恰因为外界第一次能看到“一个月的完整 diff”——而如果团队内部缺乏同样的 diff 视角，膨胀过程是不可感知的。

第四，攻击面扩大。 系统提示词是产品逻辑、路由策略与安全红线的完整地图。20 万字符意味着潜在的提示词提取攻击者获得了空前详细的“规则手册”，可以针对性寻找未被覆盖的缝隙——规则越长，没有堵上的洞反而越显眼。

四、治理建议：像管理代码一样管理提示词

结合上述分析，给出一组可落地的实践建议。

1. 分层与懒加载应是第一原则。 凡是“可能相关而非每轮必需”的内容，都应移出常驻提示词，改为索引 + 按需注入。记忆系统的目录设计就是正确方向；问题在于其他模块（产品说明、风格细则、专项安全条款）并未同等地做分层处理。

2. 能用机制解决的，不要用自然语言解决。 判断请求是否高风险，前置一个分类器或路由器远比在提示词里写几百字判断标准可靠；判断该读哪个记忆文件，结构化检索与相关性打分也优于纯文本目录。自然语言规则适合表达意图与边界，不适合承担精确分类职能。

3. 规则要有退出机制。 每条规则上线时记录触发场景与预期效果，配合日志与监控（在企业级环境中，可借助日志服务、监控告警等通用云上能力做规则命中统计），定期审计低命中规则并删除。提示词需要定期“减脂”，而非只增不减。

4. 版本化与回归评测。 每次提示词变更都应跑固定的评测集，覆盖行为一致性、安全合规、风格合规三组基线，并保留“为什么加这条规则”的决策上下文。在基于百度智能云等企业级平台构建大模型应用时，提示词变更同样应纳入与代码等同的版本管理与评测流程，避免其成为不可追溯的黑盒。

5. 提示词、检索、微调各司其职。 通用行为准则与安全底线放系统提示词；事实性、易变的知识（如产品手册、事件时间线）放检索层；稳定且高频的风格模式可考虑参数化手段固化。把事实性内容写进提示词，是三种手段中性价比最低的一种——它们本可以只是一条按需召回的检索结果。

五、结语

从 12 万到 20 万字符，一个月的增量里既有值得借鉴的精巧设计——目录式记忆加载、先查再答、时间稳定性门槛，也有值得警惕的工程惯性——逐 case 打补丁、只增不减。系统提示词正在从“模型的行为宪法”演变为“巨型配置文件”，而配置文件的经典顽疾——冗余、冲突、无人敢删——正在原样复现。

对开发者而言，这类泄漏事件的最大价值不是围观，而是一面镜子：你自己的系统提示词，上一次“删掉一条规则”是什么时候？