工业 Agent 实战：拆解大厂记忆机制，搭建自己的记忆系统

最近我们开发的工业研发 Agent，被客户和同事吐槽了一通：

“看报告，能不能记住我喜欢先看结果、再看依据，不用每次都重新提醒它？”

“查数据，能不能听懂我的习惯叫法，不必每次让我翻译成系统里配置的属性名称？”

“同一个检索条件可能对应不同位置的字段，第一次问清楚很有必要。但我已经选过好几次了，换个对话后，能不能别再让我解释？”

大家希望的，是下次和 AI 协作时，能少交代几句，少一些从零开始的割裂感。

但过去的习惯，也不一定适用于眼下的任务。

记住用户的默认选择，但别忘了，用户也会改变。

借着解决这些问题，我也想系统梳理一下 Agent 的记忆，同时把过程分享给大家。

看完这篇，你会弄清楚三个问题：

1. 1. 聊过的信息，怎样才能成为记忆？有哪些类型？
2. 2. ChatGPT、Codex、Claude Code 等产品，是怎样处理记忆的？
3. 3. 回到工业 Agent，怎样选择值得记住的内容，再把方案做出来、验证效果？

一、一条信息怎样成为记忆

聊天记录明明还在，为什么换个对话，AI 又要重新问？

要理解这件事，先得分清 会话记忆、长期记忆 和 当前上下文 分别起什么作用，以及它们怎样配合。

一）接住这次对话，也记得下次怎么配合

沿用前面看报告的例子。假设你把一份报告交给 AI，让它先说结果，再列依据。

聊了好几轮，你追问：“第二条依据再展开一下。”

它要接住这句话，就需要知道你在看哪份报告、刚才列了哪些依据。这些让当前任务能够继续的信息，可以理解为 会话记忆。

但到了下周，你换了一份报告、开了一个新对话，仍希望它按同样的顺序回答，这就涉及跨会话的 长期记忆。

会话记忆接住这一次的讨论，长期记忆让下一次不必从头交代。

二）保存过，不等于这次看得到

这里有个容易忽略的区别。历史聊天记录里有，不等于模型这次一定看到了。

可以把模型处理问题的场景，想象成它坐在一张工作桌前。

桌上的材料，就是当前上下文，包括这次的问题、相关的历史对话、报告内容，以及系统给它的要求。

这张桌面能放的材料有限，这就是上下文窗口的容量限制。

历史记录更像旁边的档案柜。

Agent 系统需要把相关材料取出来，放到这次的桌上，模型才能用到。

会话里的摘要、长期保存的偏好，也要经过这一步，才能成为当前上下文的一部分。

所以，当前上下文说的是“这次能看到什么”，会话记忆和长期记忆关心的是“哪些信息要留下，以及什么时候使用”。

这里的信息保存在模型之外，使用时再放进当前上下文，不涉及重新训练模型。

那把所有聊天都放上来，不就省得挑了吗？

桌面未必放得下，放得下也不代表都能用好。

即使模型支持很长的上下文，也不代表它能稳定利用其中所有信息，材料越多，关键信息的位置和额外干扰，都可能影响回答表现。

因此，处理长对话时，一种常见做法是把较早的讨论整理成摘要。

摘要可以保留这份报告中已经确认的结论和仍待核实的问题，让后面的讨论继续。

当摘要可能丢失细节，需要追查时，仍要回看原始记录。

三）这次的要求，要不要记录下来，影响下次任务？

“这份报告先说结果”，可能只是眼下的要求。

如果用户说“以后帮我看报告，都先说结果，再列依据”，就明确表达了持续的偏好。

系统可以记住这个顺序，下次看报告时继续使用。但适用范围也要记清，不能把它变成所有回答的固定格式。

记住以后，用户仍然可能提出不同要求。

“这次先逐项解释依据，最后再下结论。”

这次按新要求回答，原来的长期偏好保留。

“以后看报告，都先解释依据，最后再下结论。”

这时就需要更新原来的偏好，后续按新的顺序回答。

记忆要能延续已经说清楚的要求，也要分清临时调整和长期变化。

用户不一定每次都明确说“请记住”，系统也可能从多次交流中自动提炼偏好。但它需要分清，哪些是用户明确提出的，哪些只是根据聊天推测出来的。

接下来，我们看看不同产品怎样处理这些信息。

二、不同产品怎样处理这些信息

我去看了 Kimi Code、Codex、Claude Code 和 ChatGPT 的公开代码与文档。

它们都在处理过去留下的信息，但给我的启发不太一样。

我主要想看看，它们到底留下了什么，下次怎么用，记错了或者情况变了，又怎么处理。这些才是我做自己的 Agent 时要面对的问题。

一）摘要要留下能继续工作的线索

前面提到，长对话可以通过摘要压缩上下文。但摘要到底该留下什么，又该怎样继续使用？

Kimi CLI 的公开源码提供了一种直观的处理思路：

较早的历史 → 整理成摘要
近期的对话 → 保留原文
摘要 + 近期原文 → 交给后续任务继续使用

也就是说，它没有把全部历史都塞回上下文，也没有把所有内容都压成一份摘要，而是 同时保留“过去发生了什么”和“最近正在讨论什么”。

用于生成摘要的提示词，重点关注：当前任务、遇到的错误与解决办法、最终代码状态和待办事项。

这样下一次调用时，AI 能知道从哪开始。

地址：https://github.com/MoonshotAI/kimi-cli/blob/9ab1286b8fe4e6bcd116949a27ce5e0ac3389c82/src/kimi_cli/prompts/compact.md

这里给我的启发是：压缩不是单纯把过去说过的话变短，而是给下一步工作留下足够的线索。

OpenAI 的 Compaction（上下文压缩）提供了另一种选择。

以独立的 /responses/compact 接口为例，开发者把当前上下文交给它，得到一个可供下一次请求继续使用的上下文窗口。

其中包含不供人直接阅读的加密压缩项，也可能保留部分原消息。下一次请求完整沿用返回结果，就能在更少的上下文中继续任务。

参考地址：https://developers.openai.com/api/docs/guides/compaction

对使用者来说，价值仍然是长任务不用从头交代。

对开发者来说，区别在于由谁负责压缩：自己做文字摘要，方便检查和调整；交给接口，可以少维护一套摘要流程，但会更依赖供应商提供的能力。

这种方式并非 OpenAI 独有，不同供应商提供的形式和控制方式也不相同。

二）明确的工作要求，不必等助手慢慢猜

有些稳定的工作要求，没必要等助手从聊天里慢慢猜。

在我自己的 Codex 知识工作区里，AGENTS.md 中就有这样一条规则。

如果在其他任务中发现稳定、可复用、有长期价值的内容，在任务结束时提醒用户沉淀；不得静默保存。

这条规则让 Codex 在发现值得留下的信息时提醒我，是否保存、保存到哪里，仍然由我决定。

这不是助手从聊天中自动学来的记忆，而是我主动交给它、可以在后续任务中继续使用的约定。

在 Codex 中，这类约定大致沿着下面的路径发挥作用：

明确的工作要求 → 写进 AGENTS.md
Codex 读取用户级与当前目录路径上的指令 → 汇总适用规则
规则进入当前任务 → 告诉助手应该怎样配合

备注：Codex 的公开源码也进一步说明了这个执行过程。
地址：https://github.com/openai/codex
加载说明：https://learn.chatgpt.com/docs/agent-configuration/agents-md

Claude Code 的话，会在启动时读取当前目录及上层目录中的 CLAUDE.md。

子目录的规则，在读取该目录文件时按需加载，让具体要求跟随相关工作进入上下文。

这些指令文件都能承载明确的工作要求，但各类产品的加载方式会略有不同。

如果你平时也用 Codex 或 Claude Code，可以留意自己反复交代的要求。

相对稳定、适用范围清楚的，值得写进对应的指令文件。

例如，如果希望每次修改后都知道验证了什么、还有什么没有确认，就可以约定：

在这个项目中，修改完成后，说明验证了什么，还有什么没有验证。

总比只交代一句“认真检查”强，至少它知道要检查什么、检查完要告诉我什么。

当然，一开始，不需要写满一页。先留下最常重复的几条，观察是否减少了纠正，再根据实际做调整就可以了。

主动写下的规则，适合明确、稳定的场景。

但有些偏好散落在多次交流里，用户未必会主动整理，它们又该以怎样的形式留下来呢？

三）聊过很多次，怎样形成持续有用的记忆呢？

一种做法，是让系统回头梳理下多次交流中留下的信息，而不是等用户把每条偏好都写成规则。

ChatGPT

ChatGPT 的演进正体现了这种变化：从 2024 年的 Saved Memories（已保存的记忆），发展到 2025 年在后台整理聊天历史的 Dreaming V0，再到 2026 年的 Dreaming V3。

Dreaming V3 的信息流可以简单理解为：

多次交流 → 后台综合整理 → 更新记忆 → 在未来相关对话中使用

Dreaming V3 重点关注三个目标：延续有用的背景、遵循偏好与限制，以及让记忆跟上时间变化。

Dreaming V3 官方说明：https://openai.com/index/chatgpt-memory-dreaming/

我最关注的是其中的“记忆跟随时间变化”，官方用新加坡旅行解释了这一点。

规划行程时，记忆可以带上过去的偏好；

旅行结束后，“准备去新加坡”就应该更新为“去过新加坡”，不能继续把它当作用户当前的位置。

如果这条记忆没有更新，用户回国后再问附近餐厅或周末安排，系统仍可能按“人在新加坡”来回答。

难道还要打“飞的”去吃饭？这显然就有点过分了。

针对 ChatGPT，记忆规则和过期自动更新可以参考下，不过细节不多，目前能搜到的资料也就到此为止了。

Claude Code

自动记忆也可以只服务于一个具体项目。

Claude Code 会在工作过程中，判断用户的纠正、工作偏好和项目背景是否值得记住，并把有用的信息写入项目记忆文件。

这些文件用 Markdown 保存，MEMORY.md 作索引，详细内容放在单独的主题文件中。

新会话开始时先加载索引，需要时再读取详情。

大体流程可以理解成：

工作中的纠正与背景 → 判断是否值得保存 → 更新项目记忆 → 后续会话按需读取

为了让新会话能读到关键记忆，Claude Code 会提醒 Claude 保持索引简短，把详细内容放到主题文件中。

当然，用户也可以直接查看、修改或删除这些记忆文件。

Claude Code auto memory 文档：https://code.claude.com/docs/en/memory#auto-memory

Codex

Codex 把自动整理记忆分成了两步。

先从符合条件的历史会话中分别提炼有用信息，保留摘要和来源；

等这一批提炼完成，再结合已有记忆统一整理，合并重复内容，更新有新依据的信息，无法判断的冲突则保留不确定性。

历史会话 → 分别提炼候选 → 结合已有记忆统一整理 → 后续任务按需读取

我比较看中的是后面这一步。每段聊天单独看都有道理，放到一起，就未必还是同一回事了。

记忆 Agent：https://github.com/openai/codex/blob/41f9084b30812db321a0b592def4f500d1e79cf4/codex-rs/memories/write/templates/memories/stage_one_system.md

Codex 的公开提炼规则关注稳定偏好、用户纠正和经过验证的经验，也允许在没有有用信息时不保存。

整理规则：https://github.com/openai/codex/blob/41f9084b30812db321a0b592def4f500d1e79cf4/codex-rs/memories/write/templates/memories/consolidation.md

这也提醒我，记忆不是越多越好。

它是否有价值，要看下一次协作能不能因此少一次重复说明、少一次来回纠正。

但回到自己的工业检索 Agent，减少确认并不总是好事。

尤其当记忆会改变业务查询条件时，哪些重复解释可以省掉，哪些关键信息仍要重新确认？

三、回到工业 Agent，我怎样选择和验证

一）筛选记忆场景，明确验收标准

做记忆之前，我先想清楚，这次究竟要帮用户省掉哪些重复说明。

用户觉得反复沟通麻烦，也不代表这些问题都该用记忆解决。

Codex、Claude Code 的做法可以借鉴，但具体记什么，还得回到我们自己的业务里看。

我们这个助手要进业务系统查数据、查技术资料。一条默认选择记错了，查的字段和范围就可能跟着错，最后拿到的结果也不一样。

所以，我先分清哪些信息适合记住，分清以后，再选值得先做的记忆场景。

1. 先分清，这条信息应该由谁负责

2. 再从候选里选择先做的场景

分清边界后，我从三个方面比较候选场景：

1. 1. 使用价值：是否经常出现，用户每次为此多做了什么；
2. 2. 记忆适配度：是否因人而异、相对稳定，适用范围能否说清；
3. 3. 验证与风险：前后变化是否容易核对，用错以后会带来什么影响。

后面会用两个实际的场景展开说说。

3. 用测试用例对齐理解

场景选好以后，我会拉着用户、测试，一起对齐验收标准、整理成用例。

这次特别关注以下几点。

1. 1. 测试前有没有相关记忆，它处于什么状态；
2. 2. 当前问题是否应该触发这条记忆；
3. 3. 执行过程中实际用了哪条记忆、哪个字段和哪些查询条件；
4. 4. 用户是否真的少了一次重复说明，本次例外、范围外问题和习惯变化能否正确处理。

对 Agent 来说，结果看起来正确，不代表过程真的正确。

它是否加载了合适的记忆、重新查询了当前数据，并继续遵守原有权限，都需要核对。

验收标准明确后，我先记录没有记忆时的表现，看看用户原本要多做哪些步骤。

二）开发前建立无记忆基线

针对前面选择的两个容易理解的场景，我们先记录没有记忆时的表现，作为加入记忆功能后的对照，这就是“无记忆基线”。

基线一：查配方时，默认从哪里查

我先问。

帮我查一下生命周期为“实验”的配方有哪些？

Agent 没有直接查询。配方里的“生命周期”可能出现在不同位置，它先让我确认。

这里，“生命周期”是要查的字段，“基本属性”是这个字段所在的位置。仅凭字段名称，还不能确定查哪一处，所以需要先问清楚。

这个确认有必要，因为位置不同，查询结果也会不同。于是我回答：

是的，基本属性。

确认后，它完成了查询。

但换一个新对话，我还要再次回答“基本属性”。我希望记忆能省掉这一步重复说明。

基线二：读技术标准时，答案怎么整理

第二组我换成一份关于大肠菌群计数的标准征求意见稿，看看第一次回答能不能直接拿来核对操作。

回答里的步骤、温度和时间基本齐全，但同一步的操作和判断分散在不同段落，核对时需要来回翻找。

于是，我让它按流程卡重新整理。每一步要做什么、温度和时间是多少、什么情况下继续培养、依据哪条标准，都放在一起。

第二次回答就方便逐步核对了，也标明了这份文件是征求意见稿。

培养条件和文件状态，本来就应该查清楚、说准确，不需要靠记住用户偏好来补

。这里适合记住的，是我希望把标准整理成流程卡，方便逐步核对的阅读习惯。

两组基线的区别也就清楚了。

查配方时，我不想每次都重新确认字段位置。读标准时，我不想每次都重新交代整理格式。

后面再看，加入记忆后，这些重复的说明能不能省下来。

三）从大厂产品中借鉴生成自己的记忆方案

前面的产品做法，放到自己的业务里，哪些值得借鉴？

真正开始做，还是得把几个问题想清楚。

1、先实现用户明确指定记住的记忆，还是直接做自动学习？

这是一个最基础的场景，我决定，先完成主动保存的场景，再考虑自动整理记忆，慢慢来，找点感觉。

ChatGPT、Kimi 等大多数产品中，都可以由用户主动发起记录记忆的交互，我觉得可以无脑借鉴。

不过，用户说了“请记住”，也需要判断内容是否适合保存。

我的方案允许明确保存个人叫法与术语理解、查询默认选择、表达和阅读偏好，以及工作背景、近期项目和任务。

内容和适用范围清楚，就保存或更新；有歧义，先问清楚。

实时价格、库存、审批状态等业务事实，需要每次查询，这种肯定不能进去的；

还包括：权限声明和凭证，这类鉴权信息，也不能进入个人记忆中。

系统还得能管理记忆，让用户看清记住了什么、适用于哪些场景，也能修改和停用。

这样，针对前面设定的基线，就能做到：

• • 配方查询的条件归属位置，记住“默认看基本属性”。
• • 阅读标准时，默认用流程卡整理。

2、记住以后，每次对话都利用吗？

Claude Code 把记忆限定在项目中的做法，这个思路给了我一个参照。

我的方案也要区分作用范围：

• • 配方的查询习惯不能直接用到原材料上
• • 标准的阅读格式也不该影响普通统计
• • 项目 A 的报告输出格式，不能套用到项目 B 上
• • 存在一个全局范围，来应对更广泛的偏好

ChatGPT 对过时信息的处理，也让我注意到记忆的时效性。在自己的方案里，我给部分记忆增加了失效时间，到期后不再加载。

有些要求只在一段时间内适用，不能一直沿用。

当然，所有记忆也应该都可以更新，一旦习惯变了，就需要修改原来记录。

这样加载记忆时，先排除已停用、过期的记忆，再选择本次适用的内容。

3、用户怎么知道，助手用了哪条记忆？怎么显性出来呢？

最开始和用户聊时，他们就希望在回答旁边看清这次带上了哪些记忆，不用再去别的地方找。

过去使用ChatGPT 过程中，我观察到它也支持追溯，那可以借鉴下它的交互。

但是我没有做成一模一样的，因为我觉得 ChatGPT 埋的还是有点深，不够直接。

每次回答加载了哪些记忆，可以点开查看。

这里展示的是本轮提供给助手的记忆。它有没有真正按要求执行，还要结合查询过程和最终回答核对。

还可以回到来源对话，看看当时为什么留下这条记录。

回答不合预期时，用户就能顺着找到依据，判断是记忆需要更新，还是助手没有按要求执行。

透明、可追溯，这是工业软件这类严肃场景的最基本诉求。

4、后期做自动整理，又能从大厂产品里借鉴什么点呢？

前面看 Codex 时，它的两步处理给了我一个参照。先从符合条件的历史会话中提炼候选，再结合已有记忆统一整理。

沿着这个思路和 AI 对齐方案，才发现实际要考虑的问题不少。

1）自动整理记忆的范围是什么？

我把自动整理的范围定得比明确保存更窄。毕竟是自动写入，范围太宽容易记错。

我保留了表达、阅读和展示偏好，用户亲口说明的工作背景，以及近期关注的项目和任务。

个人叫法、术语理解和查询默认选择，则留给用户明确指定。

收缩的是那些会改变业务理解和查询结果的规则。

前面的两个基线正好可以对照，“标准用流程卡整理”可以自动学习；“生命周期默认查基本属性”会改变查询位置，需要用户明确决定。

2）哪些对话会参与自动整理呢？

后台只处理已经闲置 6 个小时的对话，正在聊的先不动。这一点也参考了 Codex 的源码逻辑。

默认只提炼最近 7 天内尚未处理的消息；更早的相邻原文可用于理解追问，已有的有效记忆也会参与综合判断。

3）自动学到的习惯，与用户明确指定的要求冲突了，听谁的？

比如，用户明确要求过“复杂方案详细解释”，最近几次聊天却又希望简洁。

这种情况下，后台能不能自动整理后，修改原来设定的记忆？

讨论后，我把记忆的维护方式分成了“明确设定”和“自动学习”。

用户明确交代过的，后台不能凭最近几次聊天就给改了。这次要简洁，就先简洁回答；以后是不是都要改，得分清楚。

4）历史会话怎样继续参与，又不必每次全部重读？

只看新聊天，很难结合过去的表达判断习惯，但是每次重读全部历史，又会增加上下文和算力消耗，很难受。

因此，我把提炼结果理解成一张张“小纸条”，保留 简短内容、适用场景、表达时间 和 来源原话，再结合已有记忆综合做判断。

处理过的消息没有变化，就不重复提炼，但纸条仍然可以在有效期内参与综合分析。

旧会话如果出现新追问，等它再次闲置后，只提炼新增消息，并带上相邻原文帮助理解。

随后，再结合仍有效的旧纸条和已有的记忆统一整理，不必每次都重读整个会话。

后来测试时，我在聊天中提到近期关注奶制品项目研发。

系统自动整理出“关注奶制品相关项目研发”这条记忆，标记为自动学习的近期背景，并保留了来源和有效期。

它记录的是我的关注方向，具体有哪些配方可供参考，仍然需要查询业务系统。

四）从方案到实现，我是怎样和 AI 协作的

开发时，我先实现用户明确要求保存记忆，以及在新会话中使用这些记忆，再加入后台自动整理。

用户明确要求记住什么，比较容易核对保存和使用是否正确。

先把这部分跑通，再加入自动提炼，出了问题也容易分清，是记错了，还是记住以后没有用好。

这次开发中，有几个做法帮我把方案聊得更清楚，也省下了一些重复的操作，大家可以参考下。

1）长文档看不动，就让 AI 逐项问我

每次 AI 生成一大篇文档，看着很累，直接让它开工，又怕返工。

我借鉴了 grill me（逐项追问） 的访谈式提问思路，让 AI 反过来问我，把不确定、影响比较大的问题逐项拿出来讨论。

这样舒服多了。

需求文档、技术方案，都可以这样过一遍。

一次只讨论一个问题，确认后再把结论写回文档，避免聊清楚了，文档里还是旧方案。

先别开工。请结合整个方案，把容易遗漏、需要我决定的问题逐个问我。一次只问一个，用大白话说明影响和你的建议。确认后更新回方案，再问下一个。

2）开工前，让方案先走一遍

方案确认了，我有时还是没想清楚它真正运行起来是什么样。

这个时候，就让 AI 做一次“方案预测”，拿具体场景讲执行过程和预期效果。

比如，同一个用户有十个会话都符合整理条件，是每提炼完一个就更新记忆，还是整批提炼完再综合？

如果最后一个会话恰好在纠正前面的说法，又会怎样？

让它拿这十个会话走一遍，我才比较容易看清，先做什么、后做什么，哪里还没想周全。

先不改代码。假设我有十个会话等待整理，最后一个会话纠正了前面的偏好。请按方案走一遍，通俗讲清处理顺序、最后会保存什么，以及哪里可能出问题。

这个方法以前介绍过很多次，尤其是遇到后台处理这类我们开发者不容易感知执行过程的功能，还是很好用的。

3）把确定要参考的源码放到本地

确认要借鉴哪些做法后，我把相关开源代码下载到了本地，比如 Codex、Kimi CLI。

后面聊到具体实现，就把路径和要看的功能交给 AI，让它对着代码分析哪些能借鉴。省得每次又去找网页、翻资料，来回折腾。

这也是准备上下文的一种方式。

参考源码已经放在这个目录。请先找到记忆提炼和综合的实现，结合我们的方案说明哪些能借鉴、哪些需要调整，并标出对应文件。先分析，不要直接照搬代码。

4）改动影响较大时，回头检查测试用例

影响比较大的调整和问题修复，我会让 AI 先扫一遍相关测试用例，看看原来哪些行为也会受影响，避免拆东墙补西墙。

必要时先用计划模式理清范围，再动手修改。

这次改动还会影响哪些已有功能？请检查相关测试用例，补上遗漏的边界场景，修复后跑必要的回归。最后说清测了什么，还有哪些没验证。

5）让 computer use（计算机操作）跑真实页面

computer use 能让 AI 操作真实页面，是这次用 Codex 很省事的地方。

新建对话、输入测试问题、打开记忆列表，再换个会话检查效果，这些重复操作可以交给它，我不用一手工守着页面操作。

腾出时间干点别的，喝喝茶、听听歌，它不香吗？

请用 computer use 在真实页面测试这几个场景。检查记忆有没有保存、内容是否准确，以及新会话是否用上。发现问题可以修复，重要风险先告诉我，保留关键截图和测试结果。

省下操作时间后，我再人工重点看核心的场景。

页面跑通了，记忆是否值得保存、回答有没有真正遵守要求，这些点仍然值得仔细核查。

五）通过前后对比和边界场景验证

开发完成后，我回到前面两组基线，检查明确保存的要求能否在新会话中生效。

1）配方查询，是否省掉了重复确认？

我明确要求记住，查询配方时，没有指定位置的“生命周期”默认使用“基本属性”字段。

保存后，新建对话，再问生命周期为“实验”的配方，它直接完成了查询，没有再次追问字段位置。

点开回答下方的个人记忆，还能查看保存的内容和来源对话。

这组测试里，重复解释“基本属性”的步骤省掉了。保存的是默认字段位置，业务数据仍要重新查询。

2）技术标准，是否沿用了阅读偏好？

我让它记住，阅读标准时，默认用流程卡整理，列出每步操作、温度、时间、判断条件和条款号。

随后新建对话，只问原来的检验问题，没有再提格式要求。

它重新检索标准资料，沿用了流程卡格式，也列出了继续培养的触发条件。

回答下方展示了本次加载的个人记忆。

3）自动整理，是否记下了有用信息并守住边界？

为了验证自动整理，我先删除前面明确保存的两条记忆，再通过几个独立对话自然表达需求，没有说“请记住”。

第一组是生命周期场景。

我在五、六个对话中都有提到，查实验状态或核对已发布配方时，会看“基本属性”里的“生命周期”。

这类信息会改变查询字段，需要用户明确决定，因此系统虽然提炼出了相关表达，最终没有写入记忆，被手动删除的旧规则也没有恢复。

这次没记下来，反倒是我想看到的结果。

第二组测试低风险的表达偏好。

我在多次标准查询的任务中要求整理成流程卡，每一步列出操作、条件和依据，没有把它明确指定为长期习惯。

对话闲置后，后台自动生成了“分析包装标准时结果按流程卡展示，每步列出操作、条件和依据”。

它被标记为“自动学习”，适用于标准类场景，还能回到原对话查看来源。

随后，我新建对话，没有再提格式要求，回答仍按流程卡整理，并展示了本轮加载的记忆。

表现与前面明确保存后的格式验证一致，这次记忆的来源是“自动学习”。

当然，这里只验证了几个基础场景，正式上线前，还得按正常研发流程完成测试、回归和用户验收。

四、最后小结

回到开头，用户真正想减少的，是那些已经说清楚、却还要反复解释的话。

这次做下来，我觉得先想清楚该记什么，比急着把记忆功能加上更重要。

哪些要求换个对话还能沿用，哪些选择必须问清楚，遇到变化又该怎么更新，都得放到具体场景里看。

Agent 要长期参与到业务中，就得记得住之前的习惯，跟着上未来的变化。

这样才配得上“助手”两个字。

我是🐼熊猫 Jay，谢谢你看我的文章。

如果觉得不错，帮忙点赞三连、转发给需要的人吧~