LangSmith Agent Builder 记忆系统设计理念与工程实践

摘要

本周，LangSmith Agent Builder正式上线——这是一个无需编码即可构建智能体（Agent）的工具。它的核心亮点之一，是内置的记忆系统。这篇博客会详细聊聊我们为什么把记忆系统放在首位、背后的技术实现细节、踩过的坑、这套设计打开了哪些可能性，以及未来还打算怎么演进。

1. LangSmith Agent Builder是什么

LangSmith Agent Builder，简单说，就是一个无代码的Agent构建器。它底层跑的是Deep Agents框架，以托管的Web方案交付，目标用户是那些技术背景没那么强的平民开发者（citizen developers）。用它的人，可以创建一个Agent来自动完成某个具体的工作流或者日常重复任务——比如邮件助手、文档助手之类的。

早在项目初期，我们就做了一个有意识的选择：把“记忆”作为平台的优先事项。这其实并不是一个理所当然的决定——大多数AI产品在刚发布时，记忆功能几乎是标配之外的奢侈项，甚至有些产品加了记忆，也并没带来什么碘伏性体验。我们之所以这么重视，更多是源于对用户使用模式的观察。

和ChatGPT、Claude或Cursor这类通用型Agent不同，LangSmith Agent Builder并不是一个“什么都能干”的助手。它生来就是为了让构建者针对特定任务定制Agent。通用Agent里，你会处理各种互不相关的任务，一次会话学到的经验，大概率用不到下一次。但当一个LangSmith Agent在干活时，它是反复做同一件事——从一次会话中获得的经验，迁移到下一次会话的比率要高得多。事实上，如果没有记忆系统，用户体验会相当糟糕：你不得不在不同会话里，一遍又一遍地向Agent重复同样的要求。

在思考“记忆”对LangSmith Agents到底意味着什么时，我们参考了COALA论文的定义。它将Agent的记忆分为三类：

• 程序性记忆（Procedural）：应用于工作记忆以决定Agent行为的一组规则。
• 语义记忆（Semantic）：关于世界的事实。
• 情景记忆（Episodic）：Agent过往行为的序列。

2. 我们如何构建记忆系统

在Agent Builder里，我们把记忆表示为一组文件。这个选择是经过深思熟虑的——因为模型天然擅长使用文件系统。这样一来，让Agent读取和修改它的记忆，甚至不需要专门设计工具——给它文件系统的访问权限就行。

只要有可能，我们尽量采用行业标准：

• 用AGENTS.md来定义Agent的核心指令集。
• 用agent skills（Agent技能）为Agent提供特定任务的专门指令。
• 虽然目前没有子Agent（subagent）的标准格式，但我们参考了Claude Code的做法。

对于MCP（Model Context Protocol）访问，我们用的是自定义的tools.json文件。之所以没采用标准的mcp.json，是因为我们希望允许用户只给Agent暴露MCP服务器中的部分工具，从而避免上下文溢出（context overflow）。

我们还允许用户（以及Agent自身）向Agent的记忆文件夹写入其他文件。这些文件可以包含任意知识，Agent在运行时能随时引用。Agent在工作过程中，会“在热路径中（in the hot path）”实时编辑这些文件。

实际上，我们并没有真的用文件系统来存放这些文件，而是存在Postgres数据库里，但以文件系统的形式暴露给Agent。这样做有两个好处：LLM处理文件系统非常顺手，而从基础设施角度看，数据库存储更简单、更高效。这种“虚拟文件系统”是DeepAgents原生支持的，并且完全可插拔——你可以替换成任何存储层，比如S3、MySQL等。

之所以能在不写任何代码、不使用任何领域特定语言（DSL）的情况下构建复杂的Agent，核心原因在于底层跑的是像Deep Agents这样的通用Agent框架。Deep Agents把很多复杂的上下文工程细节（比如摘要、工具调用卸载、规划）都抽象掉了，你只需要相对简单的配置，就能驾驭Agent的表现。

这些文件与COALA论文定义的记忆类型恰好对应：

• 程序性记忆——驱动核心Agent指令的内容，对应AGENTS.md和tools.json。
• 语义记忆——对应Agent技能和其他知识文件。
• 情景记忆——目前唯一缺失的类型。对于这类专用Agent来说，我们认为它暂时没有前两者重要。

文件系统中的Agent记忆长什么样？

拿我们内部一直在用的一个真实Agent举例——一个基于LangSmith Agent Builder构建的LinkedIn招聘人员。

• AGENTS.md：定义核心Agent指令。
• subagents/：定义了一个唯一的子Agent linkedin_search_worker。主Agent完成搜索校准后，会启动它来找大约50名候选人。
• tools.json：定义了一个有权访问LinkedIn搜索工具的MCP服务器。

记忆里目前还有3个其他文件，分别代表不同候选人的职位描述（JD）。随着我们与Agent在这些搜索任务上协作，它会持续更新并维护这些JD。

记忆编辑是如何工作的：一个具体的例子

为了让记忆的工作原理更具体，我们用一个说明性的例子来演示。

开始： 你从一个简单的AGENTS.md开始：
Summarize meeting notes.（总结会议纪要）

第一周： Agent生成了段落式的总结。你纠正它：“用要点（bullet points）代替。” Agent把AGENTS.md编辑为：
Formatting Preferences
User prefers bullet points for summaries, not paragraphs.

第二周： 你让Agent总结另一个会议。它读取记忆后，自动用了要点格式。这次会话中，你又补充：“把行动项（action items）单独提取在最后。” 记忆更新为：
Formatting Preferences
User prefers bullet points for summaries, not paragraphs.
Extract action items in separate section at end.

第四周： 两种偏好都自动应用了。随着新边缘情况的出现，你继续添加改进。

三个月后： Agent的记忆里积累了大量通过使用沉淀下来的偏好、术语、区别、重复概念、会议处理方式和边缘情况修正。记忆文件可能看起来像这样：

Meeting Summary Preferences
  Format
    - Use bullet points, not paragraphs
    - Extract action items in separate section at end
    - Use past tense for decisions
    - Include timestamp at top
  Meeting Types
    - Engineering meetings: highlight technical decisions and rationale
    - Planning meetings: emphasize priorities and timelines
    - Customer meetings: redact sensitive information
    - Short meetings (<10 min): just key points
  People
    - Sarah Chen (Engineering Lead) - focus on technical details
    - Mike Rodriguez (PM) - focus on business impact
    ...

注意，AGENTS.md是通过“纠正”自我构建的，而不是预先写好的文档。用户从未手动修改过AGENTS.md，而是通过一次次的迭代，最终达到了一个细节适度的Agent规范。

3. 构建记忆系统的经验教训

这个过程中，我们学到了几个实实在在的教训。

最难的部分是提示词工程（Prompting）
构建一个能记住事情的Agent，最大的难点就是提示词。几乎在所有Agent表现不佳的场景里，解决方案都是改进提示词。比如：

• Agent在该记住的时候没记住。
• Agent在不该记住的时候却记住了。
• Agent往AGENTS.md里写了太多内容，而不是写入技能文件。
• Agent不知道技能文件该用什么格式。
• ……还有很多。

团队甚至专门安排了一个人全职负责记忆功能的提示词工作——这对团队来说，人力占比相当高了。

验证文件类型
有些文件需要遵守特定的架构（schema）。比如tools.json需要包含有效的MCP服务器，技能文件需要有正确的前置元数据（frontmatter）等。我们发现Agent Builder偶尔会忽略这一点，生成无效文件。于是我们加了一个验证步骤：显式检查这些自定义格式，如果验证失败，就把错误抛回给LLM，而不是直接提交文件。

Agent擅长添加内容，但不擅长压缩
Agent在工作时编辑记忆，它们非常擅长往文件里加具体内容。但有一个短板：不太会在适当的时候对习得的知识进行压缩。举个例子，我们一个邮件助手一度开始列出它应该忽略的所有特定冷推销供应商，而不是抽象成一条规则：忽略所有冷推销邮件。

作为终端用户，显式提示仍然很有用
即便Agent能在工作中自动更新记忆，但在某些情况下，显式提示它管理记忆依然很有效。一种常见做法是：在工作结束时，提示它反思整个对话，并更新记忆以补充可能遗漏的内容。另一种情况是，提示它压缩记忆，以解决它只记住了具体案例、没能归纳出普遍规律的问题。

人在回路（Human-in-the-loop）
我们对所有记忆编辑都设置了“人在回路”——也就是说，在更新前需要人工明确批准。这么做主要是为了尽可能减少提示词注入（prompt injection）的攻击面。当然，我们也为用户提供了关闭这个功能的选项（“yolo模式”），供那些不太担心安全问题的用户使用。

4. 这带来了什么

除了更好的产品体验，以这种方式表示记忆还解锁了很多可能性。

无代码体验
无代码构建工具的一个常见问题是：它们通常要求用户学习一种不熟悉的领域特定语言（DSL），而且随着复杂度增加，这种语言会变得难以驾驭。而我们把Agent表示为Markdown和JSON文件——这两种格式（a）大多数非技术人员都熟悉，（b）更具可扩展性。

更好的Agent构建体验
记忆系统实际上改善了Agent的构建体验。构建Agent非常依赖迭代——很大程度上是因为，你在真正尝试之前，很难预测Agent会怎么表现。记忆让迭代变得容易得多：你不需要每次都手动更新Agent配置，只需用自然语言给出反馈，Agent就能自我更新。

可移植的Agent
文件化设计让Agent非常便于移植！这意味着你可以在Agent Builder里构建一个Agent，然后轻松把它迁移到其他框架（只要它们也使用同样的文件约定）。正因如此，我们尽量采用标准约定。比如，我们希望Agent Builder里构建的Agent，能无缝在Deep Agents CLI中使用，甚至用于其他Agent框架，如Claude Code或OpenCode。

5. 未来方向

还有不少关于记忆功能的改进想法，但受限于时间或信心，没来得及在发布前全部实现。

• 情景记忆（Episodic memory）
  Agent Builder目前缺少的一种COALA记忆类型就是情景记忆：Agent过往行为的序列。我们计划通过把以前的对话也作为文件系统中的文件暴露给Agent来实现，这样Agent就能与之交互。
• 后台记忆进程
  目前所有记忆都是“在热路径中”更新的，也就是Agent运行时实时更新。我们希望添加一个后台进程（比如一些cron job定时任务，每天运行一次），负责反思所有对话并更新记忆。我们认为这能捕捉到Agent在当下没能识别的内容，尤其有助于归纳特定学习成果。

• /remember命令
  我们希望暴露一个显式的/remember命令，这样你可以主动提示Agent反思对话并更新记忆。我们自己偶尔会这样做，并且受益良多，所以希望让这个过程更容易，并鼓励用户使用。
• 语义搜索
  虽然用glob和grep搜索记忆是一个不错的起点，但在某些场景下，允许Agent对记忆进行语义搜索，会带来额外的增益。
• 不同层级的记忆
  目前所有记忆都是针对单个Agent的。我们计划引入用户级（user-level）或组织级（org-level）记忆的概念。具体做法是，向Agent暴露代表这些层级记忆的特定目录，并提示Agent相应地使用和更新它们。

6. 结论

如果构建拥有记忆的Agent让你感兴趣，不妨试试LangSmith Agent Builder。如果你想和我们一起构建这个记忆系统，我们也在招人。