如何为 AI Agent 构建记忆：从 Trace 到可复用上下文

让 Agent 能从过去的行动中学习，是构建更自然、更贴近用户的 agentic experience 的关键。这样的学习循环通常被称为 memory。

没有记忆时，用户可能需要反复纠正同一个问题。Agent 每次都像第一次见到用户，无法保留偏好、规则、成功经验或工具使用模式。有了记忆后，Agent 才能在第一次被纠正后，把相关经验变成未来可用的上下文。

记忆的实现仍在演化，但抽象并不复杂：系统需要在后台运行一个过程，观察 Agent 过去的运行轨迹，找出它犯错、学到新信息或暴露出可改进模式的地方，再把这些信息抽取并泛化成某种数据结构。

一个具体实现可以拆成三部分：

使用 LangSmith Observability 作为 trace store。
使用 LangSmith Engine 分析 traces。
使用 LangSmith Context Hub 作为 memory store。

什么是 Memory

Memory 是 Agent 可以跨运行检索的持久上下文，用来指导后续行为。它可以包含事实、偏好、历史交互、指令、技能、示例，以及从过去运行中学到的模式。

这里需要区分 trace 和 memory。Trace、transcript 或 log 记录的是发生过什么，它们是证据；但只有当其中相关经验被转成未来可检索、可改变行为的上下文时，它才真正变成 memory。

换句话说，日志不是记忆。能被 Agent 在后续运行中读到并改变行为的上下文，才是记忆。

短期记忆与长期记忆

为了判断不同信息应该放在哪里，可以先把 memory 分成两个范围：短期记忆和长期记忆。

类型	含义	典型内容
Short-term / working memory	Agent 执行当前任务时可用的上下文	当前 thread、近期消息、工具结果、检索文档、中间推理产物、临时文件或运行时状态
Long-term memory	跨当前运行持久存在、未来仍可使用的上下文	事实、偏好、示例、工作流、策略、指令、技能

两者之间是一个读写循环。

在一次运行中，Agent 可以从长期记忆中读取相关上下文。读取方式可能是 prompt assembly、从存储中检索、通过工具访问、加载文件、注入 runtime state，或其他上下文加载机制。

运行过程中，working memory 会不断变化。运行结束后，trace 记录了发生过什么。大部分 trace 只应该保留为历史证据，但其中一小部分可能包含有用信号：用户偏好、需要澄清的指令、应该固化的工具使用模式，或需要更新的 skill。

Agent memory diagram

长期记忆的三种类型

理解长期记忆时，可以借用认知科学里的分类：semantic memory、episodic memory、procedural memory。这套分类也经常被映射到语言 Agent 系统中。

长期记忆类型	Agent 视角	内容
Semantic memory	Agent 知道什么	事实、偏好、通用知识
Episodic memory	Agent 经历过什么	过去的交互、示例、动作和结果
Procedural memory	Agent 应该如何行动	指令、工作流、策略、技能、工具使用规则

很多可见的 Agent 行为改进，来自 procedural memory。

例如，Agent 反复用错回答格式、按错误顺序调用工具、委派给错误的 subagent，或者忽略语气规则。解决方法通常不是单纯记住一条事实，而是修改“应该怎么做”：让规则更清楚、调整执行步骤，或者把行为封装进更具体的 skill，让这个 skill 负责对应任务。

高层记忆流程

一个运行良好的 Agent memory loop 通常包含三步：capture traces、analyze traces、update memory。

1. Capture traces

Traces 是证据层。一个被充分 instrumented 的 trace 应该记录 Agent 在任务中的路径，包括用户输入、模型调用、工具输入和输出、检索文档、路由决策、延迟、错误，以及可能存在的用户反馈。

这很重要，因为 Agent 和传统确定性软件不同。你经常无法只从最终输出判断它为什么这样做，必须检查它的 trajectory。

一次异常行为可能来自很多原因：

prompt 太弱。
缺少必要工具。
工具 schema 让模型困惑。
retrieval 质量差。
context 过期。
指令过宽。
routing decision 把任务悄悄送到了错误位置。

Trace 的价值，就是帮助定位这些原因。

2. Analyze traces

捕获 traces 后，下一步是找出有用信号。

有些信号来自明确反馈或 eval failures；有些来自反复出现的模式，例如同样的坏输出、同样的无效工具调用、同样的路由错误，或同一条被忽略的指令。

难点在 diagnosis。同一个症状可能对应不同修复方式。比如 Agent 忽略一条语气规则，可能是规则太模糊，也可能是规则放错位置、没有写进相关 skill，或者被另一条指令抵消。

3. Update memory

理解信号后，系统需要决定未来上下文是否应该改变。

改变可以是修复问题，例如澄清指令或修改路由规则；也可以是记住有用信息，例如用户偏好、成功示例，或 Agent 之后应该复用的模式。

Agent feedback loop

用 LangSmith 实现这个记忆循环

整个 Agent memory loop 可以用 LangSmith 串起来：

步骤	LangSmith 组件	作用
Capture traces	LangSmith Observability	记录 Agent 的运行轨迹
Analyze traces	LangSmith Engine	分析 traces，提取改进信号
Update Memory	LangSmith Context Hub	存储可复用的持久上下文

在 LangSmith 中，tracing 负责 capture。Tracing projects 提供了丰富的 trajectory store，让你能检查 Agent 走过的路径，并理解它为什么表现成那样。

LangSmith Engine 是后台分析过程。它不要求你手动检查每一次运行，而是分析 traces 中反复出现的问题，诊断可能的 root cause，并提出能改善未来行为的具体修改。它可能添加一条规则，把某条指令移到更接近相关 workflow 的位置，创建一个新示例，更新一个 skill，或者修改 routing policy。

Context Hub 则是这些变化成为 durable agent context 的地方。它提供了一个有版本管理的位置，用来管理 Agent 使用的 instructions、tools 和 skills。这样，memory 不再只是散落在应用代码里的临时 prompt edit。

当 context 被更新后，未来运行会重新加载它。闭环也就完成了：trace 被捕获，Engine 提取改进信号，Context Hub 存储记忆，下一次运行从更新后的上下文开始。

Update memory loop

设计可用 Memory 的三个原则

1. 不是所有内容都应该变成 memory update

大多数 trace data 应该继续作为历史保留。有些内容更适合变成 dataset examples，有些应该进入 evals，有些需要改代码或修工具 schema。

只有一小部分信息应该成为 durable context。否则，memory store 会变成杂乱、冲突且难以维护的上下文堆。

2. 确保未来运行真的会读到更新

如果 runtime 会缓存 prompts、tools 或 skills，memory commit 就必须有刷新路径。

否则系统可能已经存储了正确更新，却仍然用 stale context 运行。这样一来，记忆看似写入成功，Agent 行为却不会改变。

3. 用 evals 保护重要行为

如果某个 memory update 重要到足以影响未来行为，那通常也值得建立检测机制，判断这个行为以后是否发生退化。

记忆不是一次性的 prompt patch。它会进入 Agent 的长期行为系统，因此也需要有评估和回归检测来保护。

小结

Agent memory 的核心不是“保存更多历史”，而是把历史中的有效信号转成未来可读取、可执行、可评估的上下文。

Trace 提供证据，Engine 提取模式和改进建议，Context Hub 负责把这些改动变成可版本化的持久上下文。下一次 Agent 运行时，这些上下文重新进入 harness，改变 Agent 的行为。

这才是 memory loop 的本质：让 Agent 不只是完成一次任务，而是能从运行经验中逐步形成更好的行为。