跟着项目能学到什么
学会给 AI 设计一套能长期使用的项目记忆
跟着这个项目，可以系统学习 AI 怎样积累经验、整理经验，再把合适的经验用于后续任务。这里面涉及长期记忆、模型提取、分层整理、混合查找、上下文控制，以及 Claude Code、Codex、OpenCode 的跨工具接入。
这些能力放在一起，可以回答一个经常遇到的问题：一个业务项目做了几个月，怎样让不同 AI 工具继续利用这几个月里已经确认的规则和解决办法？每一部分都有对应的设计，也能继续展开到 AI 应用开发中的具体难点。
比如你在 Claude Code 中确认了“报表只统计已支付订单”，后来用 Codex 增加导出功能，再用 OpenCode 检查日期问题。前面的经验要继续发挥作用，就得先从对话里整理出来，放到正确的业务项目中，再根据下一次任务找出需要的内容。
这几步看着不太难，但做起来却有很多值得研究的地方：一句随口说的话要不要长期保存？几个说法相近的规则是否应该合并？业务要求改了以后，旧记忆怎么办？找到很多条内容时，给 AI 哪些才合适？
项目的学习价值，就在于把这些问题完整地做了一遍。 小伙伴可以沿着一份经验的产生和使用，理解 AI 应用为什么需要这些设计，而不必把各个知识点分开记。
理解对话记录、具体规则、场景经验和稳定约定各自的用途，让经验可以跨会话、跨工具继续使用。
从日常问答里提取信息，比较新旧内容，处理重复、补充和变化，并保留可以追查的依据。
把关键词查找、按意思查找和内容筛选结合起来，在有限空间里放入与当前任务有关的经验。
理解工具调用、自动提供记忆和自动保存问答的区别，把同一套记忆能力接到不同 AI 工具中。
长期记忆设计：弄清楚 AI 到底需要记住什么
一次对话里的背景，和一个项目的长期经验有不同用途
正在讨论报表时，“刚才那个字段”需要结合前几轮对话理解；过了两周再做报表，真正需要沿用的可能是“取消订单不计入收入”。前者帮助这次对话继续进行，后者属于后续工作还会用到的业务规则。
通过这个项目，小伙伴可以把几种常见的 AI 信息来源分清楚：
| 信息从哪里来 | 主要解决什么问题 | 举个例子 |
|---|---|---|
| 当前会话中的历史消息 | 理解这一轮接着在聊什么 | “刚才说的日期范围再扩大一天” |
| 已有文档和资料 | 查找业务知识或操作依据 | 产品手册里写的订单状态含义 |
| 工作中积累的项目记忆 | 沿用之前确认的要求和经验 | 某类报表要排除取消订单 |
这些内容可以配合使用。智能体认知引擎重点处理第三类：把执行任务中产生的有用信息保存、整理和维护起来，让它逐渐脱离某一个聊天窗口。
学到这里，你能理解长期记忆应该放在哪里、按什么范围管理，以及什么时候拿出来用。 这些设计可以继续用于开发助手、长期客户服务、个人工作助手等场景。
记忆保存在服务里，模型在需要时读取
本项目通过外部服务管理经验。更新一条业务规则，处理的是记忆内容和后续提供给工具的背景，不需要为这条规则重新训练模型。
这也解释了跨工具共享为什么可行：Claude Code、Codex、OpenCode 各自完成任务，同一业务项目的记忆由认知引擎统一管理。小伙伴可以从中理解模型本身的知识、一次任务的背景，以及外部长期记忆之间的关系。
对话提取与去重：让模型参与有明确要求的业务处理
一轮问答里，可能同时出现用户要求、助手建议、临时猜测和已经确认的结论。直接保存整段原话，只完成了记录；要形成后续能用的经验，还需要判断应该留下什么。
项目会让模型从原始问答中提取候选内容，再与已有记忆比较。新的规则可以新增，已经存在的内容需要考虑重复，有变化的内容需要判断怎样更新，部分变更会交给用户确认。
“导出的金额统一按元显示”是一条明确要求。
“金额展示还是按元来”可能只是把已有规则又说了一遍。
“普通报表按元，财务明细另外保留原始金额”补充了适用条件，简单合并可能丢掉这个区别。
“会不会是缓存导致的，我还没查”仍然是猜测，把它直接记成原因会影响后续判断。
这部分能学到的，是怎样安排模型要完成的任务，并检查它给出的结果。输入要包含什么，返回内容需要有哪些信息，哪些结果能继续处理，哪些情况需要停止或等待确认，都属于 AI 应用中的实际设计。
项目对模型返回内容有格式和业务检查。格式正确以后，仍然需要关注规则本身有没有提取准确、例外条件有没有保留。小伙伴能在这里理解“模型按要求返回了内容”和“业务上可以采用这份内容”之间还有哪些判断。
这种能力也能用于客户需求整理、工单分类、会议结论提取。业务不同，都会遇到把自然语言转成可处理内容的问题。
四层记忆整理：把零散规则变成对项目的整体认识
从一句具体要求，逐步整理出场景经验
如果系统里只存一条条零散规则，数量多了以后，AI 仍然很难了解一件事的全貌。项目提供了原始对话、记忆条目、场景记忆、核心记忆四层内容，让不同细致程度的信息分别保留下来。
| 内容层次 | 在订单报表里可能保存什么 | 学习时需要理解的设计 |
|---|---|---|
| 原始对话 | 用户为什么要求排除取消订单 | 整理结果要有可以核对的来源 |
| 具体记忆条目 | 收入报表只统计已支付订单 | 一条经验怎样表达完整，便于单独使用 |
| 场景记忆 | 报表的统计范围、金额展示和日期要求 | 同一个场景里的多条经验怎样组织在一起 |
| 核心记忆 | 多个相关场景中反复确认的金额处理约定 | 哪些信息适合进一步归纳成稳定规则 |
这里值得深入的地方，是从具体信息中归纳规律。比如收入报表和退款报表都涉及金额，能够共用哪些约定，又有哪些条件只适用于其中一个场景，需要在整理时分清楚。
整理得更概括，也要保留适用条件和依据
“几个报表都按元展示”不能随便扩大成“系统里所有金额都按元保存”。文字虽然变短了，业务含义却变了。
项目会保留记忆之间的来源关系，并提供版本和人工维护能力。小伙伴可以由此学习：模型怎样逐步整理信息，整理后的内容怎样继续检查，出错后怎样找到受影响的部分。
这部分能加深你对 AI 长期记忆的理解：既要能积累，也要能组织，还要能修正。 后续做长期任务助手、项目知识整理时，都可以参考这种分层思路。
混合查找：让不同表达也有机会找到同一份经验
用户这次说“导出的收入有问题”，已有记忆可能写的是“取消订单不计入营收”。只按相同文字匹配，容易错过有关内容；如果只看意思相近，具体项目名、报表名称等信息又需要格外注意。
项目支持关键词查找，配置并启用相应模型后，还可以结合按意思查找的方式。后者通常称为向量检索，可以先理解成：把文字的含义变成可比较的信息，再找意思接近的内容。
两种方式配合，能够覆盖不同的提问习惯。各自找到的结果还需要合并、去重，再检查是否属于当前项目、内容是否仍然有效。
| 可以学到的内容 | 为什么在 AI 应用里有用 |
|---|---|
| 关键词和语义两种查找方式怎样配合 | 用户不一定会使用和历史记录完全相同的词 |
| 多份结果怎样合并和去重 | 同一条经验可能被不同方式同时找到 |
| 查找范围怎样跟随业务项目 | 相似的内容可能属于不同业务，适用规则也不同 |
| 找不到与服务失败怎样区分 | 没有相关经验和本次没能正常查找，需要分别处理 |
如果小伙伴学过 RAG，也就是先查资料、再把资料交给模型辅助回答，会发现这些查找思路能够联系起来。本项目进一步让你看到：可查找的知识还可以来自日常工作，并随着新任务不断整理和变化。
上下文控制：决定这一次让 AI 看到哪些内容
查到很多经验，还需要给当前任务挑选
这里的“上下文”，可以理解成 AI 处理这次问题时能够参考的背景。模型一次能处理的内容有限，当前问题、工具信息和后续回答都需要空间，历史经验也要控制长度。
项目会组合相对稳定的记忆和根据当前问题找到的内容，并在设定的记忆预算内整理结果。比如处理报表时，可以参考项目里已经稳定下来的金额约定，再结合本次报表有关的具体经验。
这部分能学到怎样为 AI 准备背景，而不只是怎样找到几条记录。 多条规则有没有重复，内容是否过时，哪些与本次问题关系更大，能放进去多少，都会影响后续使用。
内容多少、信息完整程度和当前任务要一起考虑
把经验全部附上，会增加阅读负担；删减得太狠，又可能只留下结论、丢掉条件。比如“财务明细可以保留原始金额”里的适用范围丢了，后面的工具就可能误用。
项目中的筛选、版本检查和长度控制，给小伙伴提供了一个完整的学习场景：理解怎样选择内容、组织内容，以及为什么交给工具之前还要确认它们能否继续使用。
跨工具接入：理解记忆怎样进入 Agent 的工作过程
一套记忆服务，可以提供几种不同的使用方式
项目提供工具调用、自动召回和自动采集三类连接。它们分别处理“工具主动来找”“处理问题前提供背景”“任务结束后留下内容”这几件事。
| 接入方式 | 用大白话理解 | 可以学习什么 |
|---|---|---|
| 通过 MCP 调用记忆工具 | 用一种通用的工具接入方式，让 AI 客户端按需查找、保存等 | 怎样把服务能力提供给 Agent 调用，怎样控制可用操作 |
| 自动提供相关记忆 | 在客户端处理问题前，按当前任务取得项目经验 | 怎样把背景准备放进工具的工作过程 |
| 自动收集完整问答 | 一轮问答完成后，将符合采集条件的内容交给记忆服务 | 怎样识别合适的输入，并用于后续整理 |
三种用途可以分别配置，使用的权限也分别管理。当前提供 Claude Code、Codex、OpenCode 的接入实现，各工具继续使用自己的账号、模型和会话。
学会区分工具本身的工作和共享服务的工作
不同工具怎样提供会话事件、在什么时机接收背景，各有差异；经验提取、分层整理和按项目查找，则由共同的记忆服务处理。
小伙伴能在这里理解一个很实用的扩展方式：将可以共用的 AI 能力集中管理，把每个客户端的差异放在接入部分处理。以后给多个业务系统提供知识查询、用户偏好或其他工具能力，也能参考这种思路。
跨工具共享的前提，是把需要的连接配置到同一业务项目。共享的是整理后的可用经验，各工具自己的完整会话和文件修改仍由各自管理。
记忆纠错：让错误和过时的信息有机会被发现、被处理
长期记忆会被反复使用，一条错误规则影响的可能是后面多次任务。例如早期讨论暂时确定“所有报表都用自然月”，后来增加了客户约定周期，旧规则就需要继续维护。
项目提供了来源查看、历史版本、人工编辑、待确认建议，以及来源变化后的关联处理。当前由人工维护的版本需要更新时，自动处理会转成建议，相关合并也会保护人工内容。
这里可以学到三件对 AI 应用很有价值的事：
- 生成的内容要能解释来历。 一条规则来自哪些讨论，出了偏差才有地方核对。
- 自动整理要和人的判断配合。 用户补充的例外条件需要保护，新的自动建议也要有处理入口。
- 修改要考虑后续影响。 来源被排除或删除时，还要处理依赖它的相关自动记忆。
这些设计能帮助你理解长期使用中的 AI 内容质量问题。自动摘要、客户画像、工作经验库，都可能需要类似的维护能力。
模型管理：不同 AI 任务需要不同的使用要求
从问答里提取一条规则、比较新旧内容、整理场景经验、为查找准备语义信息，处理目标各不相同。项目可以为这些用途分别绑定模型，并检查相应能力是否可用。
小伙伴可以学到怎样按任务组织模型的使用：提取和整理需要按要求返回内容，语义查找需要相应的模型能力，配置调整后还需要知道哪些处理会受到影响。
这也给效果和成本的取舍提供了空间。哪些任务需要更好的理解能力，哪些任务更看重速度和稳定输出，可以围绕具体用途做选择，而不是把所有工作都当成一次普通聊天。
记忆服务用来整理内容的模型，与 Claude Code、Codex、OpenCode 完成任务时使用的模型分别管理。弄清楚这层关系，就更容易理解整个系统里的模型分工。
学过这些能力，可以继续做哪些 AI 应用
如果小伙伴已经学习过 Nexus Agent，可以把两类项目的学习内容联系起来：从文档里取得知识，帮助 AI 回答问题；从工作里积累经验，帮助 AI 继续处理后续任务。两者都涉及查找和上下文，信息怎样产生、怎样更新，则各有需要深入的地方。
| 后续可以尝试的方向 | 本项目能提供的设计参考 |
|---|---|
| 能长期跟进项目的开发助手 | 保存业务约定、处理经验变化、跨工具继续使用 |
| 持续服务客户的 AI 助手 | 提取偏好和确认事项，保留来源，及时修改过时信息 |
| 团队共同使用的项目经验库 | 按业务项目组织经验，控制共享和管理权限 |
| 能结合过往任务的工作助手 | 分层整理历史经验，再为当前任务挑选有关内容 |
这些能力也对应了面试中可以深入讨论的方向。下一篇项目经验怎么用在面试中，会围绕项目的 AI 亮点，展开可以和面试官聊的设计问题。