Memory Is Purpose：Agent 记忆系统设计教程
LLM 把互联网压缩进权重，Agent 需要把工作压缩成状态。企业记忆系统的关键在于判断哪些过去会改变下一次行动。
LLM 已经证明了一件事：把大量文本和代码压缩进模型权重，可以产生新的智能。 Agent 面对的是另一种压缩问题：把一次次工作、承诺、修正、例外、依赖、失败尝试和交接，压缩成之后还能改变行动的状态。
企业里的记忆系统不能停在搜索、长上下文、用户画像、知识图谱或会话摘要。它要回答的问题更窄，也更难：哪些过去应该留下来，因为它会改变下一次工作。
先区分三件事
知识是曾经出现过的材料：文档、会议、客户投诉、代码 diff 、工单、邮件、录音、仪表盘、工作流痕迹、对话。
上下文是让材料变得可用的情境：谁在问、要完成什么、能看什么、错误风险有多大、后面会触发什么动作。
记忆是应该存活下来的那部分过去。它之所以留下，是因为会改变未来行为。
可以把最短定义写成这样：
memory = retained consequence
purpose = 决定哪些过去值得保留的效用函数
没有 purpose，系统可以存储、搜索、摘要、连接材料，也可以把材料递给模型，但它没有原则判断什么应该变成记忆。
石头例子：同一事实，不同用途
想象徒步小路旁边有一块石头。它有大小、形状、材质、位置、纹理、苔藓、坡度、阴影、离路多远。这些都是事实，但它们不说明这块石头“有什么用”。
疲惫的徒步者会把它当座椅；导航的人会把它当路标；维护小路的人会把它当障碍；地质学家会把它当样本；诗人会把它当意象。也有人路过后马上忘掉。
石头没有变，效用函数变了。
企业里的材料也是这样。一封客户邮件可以生成多种记忆。销售看到续约信号，产品看到缺失功能，工程看到技术约束，法务看到义务，客户成功看到升级背景，CEO 看到市场模式。
如果系统把它固定标成“投诉”，它可能帮到支持团队，却误导产品。如果固定标成“功能请求”，它可能帮到产品，却漏掉法律风险。每个标签在某个框架内都可能成立，换一个任务就可能误导。
记忆系统的目标：把过去压缩成未来状态
做得好的记忆，不能只把过去变短。摘要让过去变短，画像把用户变成偏好，图谱把公司变成一种解释。企业记忆要做的是更小、更关键的压缩：把过去变成未来相关状态。
它应该留下这些东西：
应该唤醒的事实
会改变下次执行的修正
会约束下一封邮件的承诺
不该再次尝试的失败 workaround
十次客户沟通里反复出现的异议
旧代码注释里隐藏的架构约束
周围的大量噪声应该消失。这是必要的取舍。一个保留所有东西的系统，只是推迟了判断。关键工作是判断：什么可以消失，什么必须精确保留，什么应该变成规则，什么应该衰减，什么要附着证据，方便不同角色之后重新解释。
在这个框架里，遗忘和记忆并不对立。失控的遗忘是失败，受治理的遗忘是智能的一部分。
语义检索还不够
语义检索有用，因为相关概念会靠近。但也正因为靠近，相似记忆会互相干扰。系统可能取回一个“看起来相关”的材料，只因为它接近，并不代表它适合当前行动。
所以语义记忆需要一个稳定的反向锚点：来源、时间、证据、出处、权限、矛盾、修正、结果。这些精确的 episodic grounding 用来检查“相似”能否转化为“有用”。
长上下文也不能直接替代记忆。更大的上下文只是让模型读到更多材料；更好的目标是让某些东西不必反复重读。如果一次 Agent 运行花了 120,000 tokens 才发现 auth 模块已经变过，最有价值的产物是一个状态变化：下一个 Agent 不再重复发现同一件事。
图谱应该在检索时投影
知识图谱很像记忆，因为它有节点、边、标签和关系。但图谱本质上是一种承诺：这些节点值得保留，这些边值得连接，这些标签是当前解释。
问题在于时机。任务明确后，图谱很有用；未来问题还没出现时，过早固定图谱可能把系统困在一个干净、结构化、但不适合当前工作的框架里。
更稳的原则是：
ingestion 阶段：保留丰富语义底座
retrieval 阶段：由任务决定 ontology
写入时保留尽可能丰富的底座：参与者、物件、动作、属性、时间戳、模态、来源、不确定性、证据、权限、本地上下文、随时间发生的变化。
检索时再让任务决定关系：角色是谁，问题是什么，权限边界在哪里，错误风险是什么，接下来要执行什么动作。销售 Agent 看到异议和承诺，编码 Agent 看到架构约束和历史修复，法务 Agent 看到义务和例外。
一套可落地的记忆底座
真正可用的企业记忆底座，需要至少五层。
1. 精确事件记录
保留源材料：会议、消息、文档、工单、代码变更、审批、修正、结果。没有源材料，系统无法验证，也无法在新任务里重新解释自己的记忆。
2. 共享语义状态
在源材料之上，抽出参与者、物件、动作、属性、时间、来源、证据、不确定性、关系、权限和局部上下文。它比原始文本更结构化，但不要提前变成单一业务图谱。
3. Purpose Layer
Purpose Layer 决定现在什么东西应该重要：角色、任务、风险、目标、时间跨度、权限边界、预期动作。它更像产品界面、策略、 ontology 、反馈和人工修正汇合的地方。
4. 受治理的合并与遗忘
有些记忆要保持精确，有些可以摘要，有些该变成规则或先例，有些应该衰减，有些要归档但还能取回。遗忘需要治理，不能只靠时间自动清理。
5. 行动反馈
Agent 执行动作后，人做了修正，工作流成功或失败，客户续约或流失，bug 再次出现，承诺被错过，这些结果都应该反向进入记忆底座。否则系统只是存痕迹，并没有从工作中学习。
可以把一个记忆对象设计成这种形态：
episode:
source: meeting | email | slack | ticket | code_diff | agent_trace
actor: sales | product | engineering | legal | support | executive
artifact: customer_email_2026_06_03
timestamp: 2026-06-03T10:20:00+08:00
evidence: exact_quote_or_source_pointer
permissions: account_team_only
semantic_state:
entities: [customer, export_controls, renewal, Q3]
actions: [promised, requested, blocked]
uncertainty: medium
related_work: [roadmap_item, legal_review, engineering_ticket]
purpose:
role: sales | product | legal | engineering
task: next_follow_up | roadmap_planning | obligation_review | implementation
risk: renewal_loss | contractual_exposure | delivery_delay
expected_action: remind | constrain | escalate | verify
memory_policy:
keep_exact: true
decay_after: null
attach_to_evidence: true
wake_up_before: 2026-07-01
Company Brain：三种记忆视图
企业已经有很多可搜索档案。缺的是有权限控制、会随工作更新的活记忆：发生了什么变化，谁负责，承诺过什么，哪里失败过，什么应该之后唤醒，哪些修正会改变下一次执行。
这类系统可以拆成三种视图。
事实记忆
保存存在过什么、发生过什么：文档、工单、客户、通话、代码、仪表盘、事故、负责人、产物、决策，以及它们如何连接。
交互记忆
保存人和 Agent 在沟通中表达、争论、承诺、暗示、反对和悬而未决的东西。来源可能是邮件、消息、会议、评论、电话、 review 、交接和人机协作记录。
行动记忆
保存工作实际怎么完成：触发条件、交接路径、失败 workaround 、审批习惯、历史修复、执行结果和下一次该避开的坑。
这三种对应同一个共享状态的三个视图，不该被做成三个孤立产品。过早拆开，会在记忆产品内部重新制造记忆问题。
一个客户承诺的完整例子
客户在电话、邮件或 Slack 里说：
We can renew, but only if export controls are fixed before Q3.
普通档案系统可以保存这句话。企业记忆系统要把它变成不同角色可用的状态：
销售：下一次跟进必须受这个承诺约束
产品：路线图里需要体现 export controls
法务：保留原话和证据，评估义务边界
工程：生成可追踪的修复任务和截止时间
管理层：把它作为续约风险和市场需求信号
同一句话会约束下一次跟进，影响路线图，在 Q3 前唤醒负责人，在客户负责人变更后继续存活，并且始终附着证据。这里的记忆来自整条链路里的状态变化，不来自某一条孤立消息。
实操检查清单
设计 Agent 记忆系统时，可以按下面的顺序检查：
1. 这条信息以后会改变什么行动？
2. 哪个角色会因为它做出不同决策？
3. 它需要精确证据，还是摘要足够？
4. 它应该持续多久？什么时候衰减？
5. 它是否受权限约束？
6. 它是事实、交互，还是行动模式？
7. 下次运行时，系统如何知道它应该被唤醒？
8. 如果人类纠正了它，修正如何进入控制平面？
更重要的是，不要把“能搜到”当成“已经形成记忆”。搜索解决访问，画像解决个性化，图谱解决关系，Agent runtime 解决运行状态，工作流平台解决执行。企业记忆横跨这些层，因为工作本身也横跨这些层。
模型生成答案，记忆决定答案依据什么世界运行。 Agent 越深入公司，瓶颈越会落到状态保存、正确压缩、按目的唤醒，以及下一次工作里的行动变化。