上下文管理：给智能体喂什么信息

同一个模型、同一个任务，给的信息不同，产出质量可以差出一个量级。上下文不是越多越好——无关的历史会稀释判断质量，缺关键约束又会让它自己发挥。这篇讲我这半年形成的分层供给方式。

先说结论

• 信息按四层供给：系统规则 → 项目规则 → 任务输入 → 会话历史，越靠上越稳定；
• 规则文件写"环境约束"，记忆文件写"已有结论"，两者都不写在提示词里；
• 子任务只带它需要的输入，不要把"可能用到"的全部材料塞过去。

一、四层结构

层次	内容	更新频率	载体
系统规则	角色、输出风格、禁止事项	极少变	框架配置 / 全局规则文件
项目规则	这个环境与仓库的特殊约束	随项目演进	项目根目录规则文件
任务输入	这次要做什么、验收标准、边界	每次任务	派发时的任务描述
会话历史	过程中的试错与中间结论	持续增长	会话本身

分层的价值在于：越靠上的层次越稳定，越靠下的层次越临时。把稳定信息写进规则文件，就不必每次重新交代；把临时信息留在会话里，就不必污染长期规则。

二、什么该写进规则文件

我写进项目规则文件的是环境约束，而不是项目介绍：

• 哪些命令在这台机器上不能用、要换成什么；
• 哪些路径需要转义、哪些工具的版本有坑；
• 交付前必须跑哪几条检查；
• 代码风格与命名约定中"非默认"的部分。

判断标准很简单：这条信息如果不写，下次还会踩吗？ 会踩的就写进去。写完之后的收益是长期的——每次会话开始都自动加载一份环境说明书。

性价比最高的一步

把"这次踩的坑"在会话结束时追加到规则文件。写一行的时间，远小于下次重新排查的时间。

三、什么该写进记忆文件

规则文件记录环境，记忆文件记录结论：

• 某个方案被验证不可行（以及为什么）；
• 某个参数范围确定不适用；
• 某个决定是在什么背景下做的（避免后来者反复推翻）。

这两类信息如果只留在会话里，换个会话或换台设备就丢失了。我把它们以文件形式放在项目目录，并通过私有仓库在多台设备之间同步——这样换框架时，真正要迁移的东西很少。

四、子任务的上下文要干净

派发子任务时我遵守两条：

一、只给需要的输入。 把主流程的全部历史带过去，会显著降低子任务的判断质量——它会开始"体谅"上下文里的其他约束，做出与任务无关的取舍。

二、不共享可变状态。 多个并行的子任务不该改同一份文件；如果必须，就先串行或先隔离。这一点比上下文本身更容易造成事故。

五、长会话怎么处理

长会话的上下文会被压缩或截断，这是必然的。应对方式是把重要结论及时外置：

• 阶段性结论写进记忆文件；
• 任务状态写进任务表或进度文件；
• 关键决定写进规则文件或项目文档。

原则是：不要让"只有会话里才知道"的信息成为项目的关键依赖。会话是可以随时丢掉的，文件不行。

稍加注意

上下文被压缩时，被丢掉的通常是"过程"而不是"结论"——但如果结论只存在于过程描述里，它也会一起丢掉。所以结论要在得出结论的当次就写下来。

六、一个反面例子

我早期有过一次很难受的排查：一个任务的结论写在某次会话的中间，之后换了工具、换了设备，再回看时只能看到"当时讨论过"的痕迹，具体结论需要重新推一遍。

从那之后我固定了一个动作：每次得出可复用的结论，立刻写进项目里的记忆文件或笔记，并在需要时同步到跨设备仓库。这个动作几乎没有成本，但它把"一次性对话"变成了"可积累的资产"。