别再把所有东西塞进 Context：Agent 真正需要的是可装配的记忆
编辑标准与来源政策: 编辑标准, 团队. 内容均链至原始来源，见 方法论.
当 Agent 忘记项目背景时，最直接的反应通常是：把更多内容放进 Prompt。
先放团队规范，再放产品文档，然后加入历史对话、代码摘要、用户偏好和最近的决定。上下文很快变成一个不断膨胀的行李箱。每轮推理都要把整箱东西重新搬一遍，其中真正与当前任务有关的可能只有几条。
这不是记忆，只是重复携带。
Context 与 Memory 不是一回事
Context 是模型这一次推理时能看到的工作区；Memory 是跨会话保存、组织、更新并按需取回信息的系统。
更大的上下文窗口当然有价值，但它不会自动回答：
- 什么值得长期保存？
- 新事实出现后，旧结论怎样更新？
- 当前任务真正需要哪一部分？
- 没有相关证据时是否应该拒绝召回？
- 谁可以读取，哪个 Agent 应该使用？
- 结果来自哪段对话、哪份文档或哪处代码？
一个团队不会把档案室、代码仓库、全部会议纪要和每个人的私人笔记永久堆在所有人的桌上。团队会分类、设权限、建立索引，并在工作需要时取出相关材料。
Agent 也需要同样的机制。
为什么 Always-on Context 会越来越难用
把全部资料常驻上下文，会逐渐产生四种代价。
噪音。 更多 token 并不意味着模型会更准确地注意到关键约束。过期决定、无关项目和重复描述会与真正重要的信息竞争注意力。
成本。 相同材料在每轮重新传输，会持续增加 token、延迟和上下文管理负担。
冲突。 如果新旧结论同时出现，系统还需要判断哪个版本有效。单纯把两者都塞进去，不等于完成了记忆更新。
越界。 一个成员的私人偏好或一个项目的内部信息，不应自动进入所有 Agent 的上下文。
因此，更合理的问题不是“还能放进去多少”，而是“这次应该取出什么”。
分层记忆：先恢复语境，再核对事实
TencentDB Agent Memory 将对话信息逐层组织：
- L0 Conversation 保存原始对话；
- L1 Atom 保存从对话中提取的事实、偏好、约束和事件；
- L2 Scenario 组织与项目或场景有关的知识块；
- L3 Core / Persona 保存较稳定的长期认识。
这些层级面向不同问题。
当 Agent 刚进入任务时，L2/L3 可以帮助它快速知道“这是一个怎样的项目”“用户通常怎样做决定”。当任务涉及具体约束时，系统再通过 BM25、向量检索与 RRF 回到 L1/L0，找到相关事实与原始记录。
高层信息减少冷启动，底层信息保留证据。两者缺一不可。
不同知识不应该被压成同一种文本块
长期记忆系统经常把所有内容都转换成相似的向量片段。但用户偏好、发布流程、架构文档和代码调用关系，本来就是不同的信息结构。
TencentDB Agent Memory 将它们区分成四类资产：
- Chat Memory 面向事实、偏好、决定与场景；
- Skill 面向已经验证的可执行经验；
- Wiki 保留文档页面和链接关系；
- CodeGraph 保留文件、符号、调用关系与影响路径。
它们也有不同的使用方式：Chat Memory 可以召回，Skill 可以按触发边界装载，Wiki 与 CodeGraph 可以由 Agent 通过工具按需探索。
这比把全部知识压成一个无差别的文本仓库，更接近真实团队使用知识的方式。
Loadout：不是所有 Agent 都需要同一份记忆
假设一个小团队里有三个 Agent：
- Scout 负责研究，需要用户访谈记忆、市场 Wiki 和竞品分析 Skill；
- Builder 负责实现，需要产品 Wiki、项目 CodeGraph 和交付 Skill；
- Reviewer 负责检查，需要历史事故、CodeGraph 和发布 Checklist。
它们属于同一个团队，但不应该携带完全相同的上下文。
TencentDB Agent Memory 把记忆资产作为 Agent 的 Loadout。系统先按照 Team、User、Agent 和可见性确定可用范围，再结合当前任务召回。少给噪音，多给完成工作真正需要的信息。
文档和代码应该随用随取
即使某个 Agent 有权访问整个项目 Wiki，也不代表每轮都要注入全部页面。即使它能使用完整 CodeGraph，也不代表每次都要把所有符号与调用边展开。
在当前设计中，Agent 可以先发现 Wiki 与 CodeGraph 工具，再读取相关页面、源码、调用方、被调用方或影响路径。知识一直可用，但只有在需要时才占用上下文。
这将 Context 从“仓库”重新变回“工作台”。
好的记忆不是记得最多
一个真正可用的 Agent Memory，需要能够选择、分层、更新、拒绝、追溯、授权和修正。
Context 依然重要，但它不应该同时承担数据库、档案库、流程库、代码图谱和权限系统的全部职责。
可持续的 Agent Memory，不是无限扩大上下文，而是让正确的 Agent 在正确的时刻，拿到正确版本的少量信息。
记忆的目标不是拿得更多，而是少拿、拿对。