一个 Agent 刚接进项目时，通常像个记性不错的新同事：你告诉它仓库在哪、规范是什么、上一步改了什么，它都能接住。
用到第三天，事情开始不对。聊天记录越来越长，工具输出像搬家纸箱一样越堆越高；它忘了最初的约束，却牢牢记住三轮失败命令。账单涨了，回答还变短了。你以为它缺“记忆”，于是又接了一个向量库。
结果只是在杂物间门口多装了一个更大的货架。
近日一篇收录在 Hugging Face Daily Papers 的论文提出了一个更有用的说法：Agent 的问题不该只被看成 storage and retrieval，而应被看成上下文的生命周期管理。这不是一个已经被独立复现的产品结论；但它把工程现场最常见的症状拆得很对。
〇、真正的敌人不是“上下文太少”
长上下文模型把窗口拉得很大后，很多人产生了一个错觉：既然能放下更多内容，那就把所有内容都塞进去。
这像给工位换了一张十米长的桌子。桌面变大并不会让你更高效，只会让过期 PRD、上周报错、半杯奶茶和一堆打印稿有了更多地方摊开。
Agent 的上下文也是这样。它需要的不是“所有曾经发生过的事”，而是“此刻完成这个任务所需、可信、权限正确的信息”。
如果每轮都把历史完整追加，成本会不断叠加，注意力也会被噪声稀释。更麻烦的是，模型并不会在上下文快满时郑重提醒你：“我从现在开始只会半信半疑地执行你的指令。”它只是开始表现得像一个很有礼貌、但没认真看需求的同事。
经验一：上下文不是聊天记录，是一段会过期、会污染、需要交接的工作内存。
一、把“记忆”改成五个动作
论文把这个问题拆成五个 primitive：architecting、ingesting、scoping、anticipating、compacting and consolidation。翻成工程语言，不是什么玄学，基本就是五个每天都会碰到的动作。
1. Architecting：先决定什么能成为事实源
很多 Agent 的 memory 从一开始就没有边界：聊天里说过的话、网页摘要、工具输出、用户上传的文件，全都长得像“知识”。
更稳的做法是先建来源等级：
| 信息类型 | 适合放哪里 | 可信规则 |
|---|---|---|
| 项目规范、接口约定 | 版本库中的文档 | 以当前提交版本为准 |
| 运行配置、密钥状态 | 受权限保护的配置层 | 不进入普通对话上下文 |
| 任务进度、决策原因 | 结构化任务记录 | 必须带时间与责任人 |
| 工具输出、网页结果 | 临时证据层 | 有有效期，不能自动升级为事实 |
第一步没有做，后面所有“智能检索”都会变成在一锅来历不明的汤里捞针。
2. Ingesting：不是存全文，是提炼可复用的事实
把一段 5000 token 的日志塞进向量库不叫完成 ingestion，最多叫把垃圾打包。
真正值得写进长期层的信息，应该能回答这些问题：它是什么、来自哪里、对哪个项目有效、什么时候失效、谁可以看。
例如一次部署失败，长期留下的不是整段终端输出，而是：
{
"kind": "deployment_constraint",
"fact": "生产环境缺少 image processor 二进制",
"scope": "project:rex-hugo / production",
"source": "deploy log #1842",
"valid_from": "2026-07-27",
"review_required": true
}
下一次 Agent 要处理图片时，它能拿到真正有用的约束，而不是在几千行 npm 输出里考古。
3. Scoping：同一句话，在不同层级含义不同
“不要改支付逻辑”是全项目规则，还是某个修复任务的临时限制？“这个客户用的是企业版”是用户级信息，还是组织级信息？
没有 scope 的 memory 很容易串台。一个客户的例外配置，变成另一个客户的默认行为；上个任务的 workaround，变成整个仓库的“规范”。
建议最少区分四层：
组织级：安全、合规、共享基础设施
项目级：代码规范、构建命令、架构约束
任务级：当前目标、验收标准、不可触碰的范围
会话级：临时推理、工具输出、待确认假设
读取顺序也要固定：先拿组织和项目的硬约束，再拿当前任务，最后才允许会话内容补细节。反过来读，临时噪声很容易盖过长期规则。
4. Anticipating：在需要之前准备，不是事后补锅
优秀的上下文管理不只问“现在要读什么”，还会问“下一步可能缺什么”。
例如 Agent 正在改登录流程，下一步大概率需要测试账号策略、session 过期规则和回归命令。与其等它改完后才发现没有测试条件，不如在任务开始时把这些信息列成一个 context checklist。
这不是让 Agent 猜未来，而是把工程师已经知道的依赖关系提前显式化。
5. Compacting：压缩前先定义什么不能丢
“总结一下历史”是最危险也最常见的指令之一。普通摘要往往删掉边界条件、失败尝试和来源链接，留下几句流畅但不可验收的话。
可用的 compact 不应只产出自然语言摘要，还要带一个验证表：
| 必保字段 | 为什么不能丢 |
|---|---|
| 当前任务目标 | 防止会话漂到另一个问题 |
| 已验证的约束 | 防止重新踩已知坑 |
| 未验证假设 | 防止猜测伪装成事实 |
| 证据链接/文件位置 | 让下一轮能回查 |
| 下一步验收命令 | 让任务能继续闭环 |
压缩不是把内容变短，而是把“下一位执行者必须知道什么”变得更清楚。
经验二：好的 context compaction 不是摘要，是带证据的交接班。
图：长期层、任务工作集和可回查证据应区分保存；压缩后的记录不能脱离来源。
二、三个最常见的反模式
反模式一：全量追加
症状：每轮 prompt 都附上完整历史、完整工具输出、完整 PRD。
代价：token 花得像自助餐，模型却要在垃圾堆里找当前任务。对短任务也许还能跑，对长任务必然变慢、变贵、变飘。
替代：只保留当前任务的 working set；其余内容通过可检索的引用按需加载。
反模式二：一段摘要覆盖一切
症状：会话太长后，让模型“总结并继续”，然后把原始记录丢掉。
代价：摘要一旦错，后续所有推理都建立在错的地基上；你甚至不知道哪一句是模型自己补出来的。
替代：摘要只做索引，原始证据保留在可回查位置。关键约束要有结构化字段，而不是只存在一段 prose 里。
反模式三：向量库没有权限和有效期
症状：所有历史资料都进同一个库，谁问都能召回。
代价：知识泄漏、过期政策回魂、不同客户的上下文互相污染。它不只是效果问题，还是安全问题。
替代：检索前先做 scope 和权限过滤；每条长期记录都给到期策略或复核标记。
三、一个小团队也能用的 Context Lifecycle
不需要先买一套“Agent Memory 平台”。从一张表、一个目录和几个固定字段就能开始。
第一步：为每个任务建立一页 Context Card
图：这张卡是任务交接的最小单位；比把整段历史塞进下一轮 prompt 更可控。
# Task: 修复登录超时
目标：session 过期后，用户应能重新登录。
硬约束：不修改 token 格式；不改支付模块。
证据：tests/auth/session.spec.ts；生产报错日志 #1842。
未知项：移动端 refresh token 是否共用同一接口。
验收：pnpm test auth；手工验证过期后重登。
Agent 每次开工先读这张卡，不必把上周全部聊天记录背一遍。
第二步：把工具输出分成“证据”和“噪声”
测试失败信息、接口响应、benchmark 结果可以保存；安装进度、重复日志、无关网页导航不值得进入长期层。
这一步看似笨，但它会直接降低后面的检索污染。不要让未来的 Agent 为今天的终端滚屏买单。
第三步：任务结束时做一次交接
交接内容不是“已完成”，而是：改了什么、验证了什么、还剩什么风险、下次从哪里继续。这样即使换模型、换人、换会话，项目也不会回到原点。
在中国使用这套方法
在国内接入通义千问、智谱 GLM-5、文心一言或本地 Ollama 模型时，Context Lifecycle 比模型供应商更值得先定下来。
- 敏感数据先分层：客户资料、源代码、公开文档必须使用不同的存储与检索策略。
- 把模型当可替换执行器：context card、权限判断、证据链接和验收命令放在模型外层，避免换一个模型就丢掉工程纪律。
- 本地模型也需要生命周期：本地部署解决的是数据出域问题，不会自动解决过期信息、错误摘要和任务串台。
真正可迁移的能力，不是“某个模型能记住多少页”，而是你是否知道哪些内容应该进场、何时退场、出了错去哪里回放。
参考资料
- Gaurav Dadhich, Agentic Context Management: Solving Agent Memory and Cost by Treating Them as Lifecycle and Architecture Problems , 2026-07-23。
- Hugging Face Daily Papers, 论文页面与社区讨论 。
- 本文的 Context Card、来源分级、scope 划分和交接流程，是基于论文观点整理出的工程实践建议；论文中报告的实验指标尚未作为本站的独立验证结论。
关注「全栈之巅-梦兽编程」公众号，每周更新 Rust、AI 编程和 Agent 工程实践。
也欢迎了解 梦兽编程 AI 编程助手服务 ，把可复查、可交接的 AI 工作流接进日常开发。