OpenWiki 可写记忆：LangChain Agent 从 RAG 只读到运行时写入的架构跃迁

大多数团队在构建 AI Agent 时，把记忆当作一个"存聊天记录的地方"。这个假设在前 RAG 时代勉强成立——上下文窗口够大，把所有对话塞回去就行。但 2026 年的 Agent 已经需要跨会话、跨任务、跨用户地管理知识，记忆系统的架构决策直接决定了 Agent 能否从"一次性工具"进化为"持续学习的协作者"。

记忆架构的核心挑战不是"存多少"，而是"谁能写、写什么、何时过期、冲突怎么办"。 这四个问题定义了 Agent 记忆的三代演进。工程上，这四个维度会映射到不同的系统组件：写入权限控制、记忆 schema 设计、TTL 调度器、冲突仲裁策略。如果上线前没有明确答案，后期每次改需求都可能牵动整条数据链路。

第一代：上下文窗口（In-Context Memory）。 模型原生支持的短期记忆，受限于 context window 大小。优点是零延迟、零工程成本；缺点是会话结束即丢失，无法跨会话持久化。适合单轮对话助手，不适合需要长期协作的 Agent。典型实现是把最近 N 轮对话拼进 prompt，或用摘要压缩历史——但摘要本身会丢细节，且无法被其他 Agent 复用。

第二代：RAG 只读外部记忆（Read-Only External Memory）。 通过向量数据库存储知识，Agent 按需检索注入 prompt。优点是突破了上下文窗口限制，可访问海量知识；缺点是只能读不能写——知识必须由人类预先灌入，Agent 自身无法从交互中学习新知识。运维侧常见痛点是：embedding 版本升级需要全量重建索引，而 Agent 在对话里学到的新事实无法自动回流知识库。

第三代：可写外部记忆（Writable External Memory）。 Agent 不仅能读取外部知识，还能在运行时主动写入、更新、删除外部记忆。这代表从"知识检索工具"到"持续学习系统"的范式转变。LangChain 于 2026 年 7 月发布的 OpenWiki 0.1.0 是这一范式的标志性实现。选型时建议先画一张数据流图：哪些记忆走 RAG、哪些走可写库、哪些只留上下文——三类边界一旦模糊，就会出现"同一事实三处存储、三处不一致"的维护噩梦。

OpenWiki 是 LangChain 于 2026 年 7 月发布的可写外部记忆库（0.1.0 版本），其核心设计理念是让 Agent 像人类使用 Wiki 一样管理知识——可以创建新页面、编辑已有页面、标记过时内容、解决编辑冲突。与 Mem0 侧重"自动抽取用户画像"不同，OpenWiki 更强调可审计的结构化页面：每条记忆有标题、正文、版本历史与 ACL，适合需要合规留痕的企业 Agent。

写入链路（Write Path）： 当 Agent 在交互中发现新知识（用户偏好、任务经验、事实更新），它通过结构化的写入 API 将知识存入 OpenWiki。典型流程分四步：（1）意图识别——模型判断当前 utterance 是否包含可持久化事实，而非闲聊噪声；（2）去重与合并——写入前对已有页面做语义相似度检索，决定 create 还是 update；（3）元数据填充——每条记忆必须包含来源标注（session_id、agent_id、utterance_hash）、置信度评分（0-1，基于证据强度与用户明示程度）、过期策略（TTL 或事件触发）、关联索引（指向相关页面的 wiki link）；（4）异步索引——正文写入后触发 embedding 重建，保证读路径可检索。生产环境建议在写入层加人工审核队列：置信度低于阈值或涉及 PII 的记忆先进入 pending，避免 Agent 误写污染长期库。

读取链路（Read Path）： Agent 在执行任务前，根据当前上下文从 OpenWiki 检索相关记忆。检索通常混合关键词 + 向量 + 元数据过滤：先按 namespace 与 ACL 缩小范围，再按 task embedding 召回 Top-K，最后用 recency、confidence、是否 expired 做 rerank。与 RAG 的关键区别是：检索结果包含完整元数据，Agent 的 system prompt 可以写规则——"置信度低于 0.5 的记忆仅作参考，不得覆盖用户当轮明示"。例如，一条置信度 0.3 的旧记忆可能不如 Agent 自身的推理可靠；而用户刚说"我现在改用 TypeScript"时，同主题高置信度新记忆应优先注入。

冲突解决（Conflict Resolution）： 当多个 Agent 或多次交互产生矛盾记忆时，OpenWiki 采用版本化存储 + 置信度竞争机制。新版本不会直接覆盖旧版本，而是并存并标记 conflict_group_id；Agent 在检索时根据置信度、时间戳和来源可信度选择采纳哪条。语义冲突检测可结合 embedding 距离与结构化字段比对——同一 key（如 preferred_language）出现互斥 value 即触发冲突标记。运维侧应定期跑冲突报表：未解决冲突超过 N 条时告警，由 Wrapper Agent 或人工介入合并。这与 Git 的分支合并逻辑类似，但增加了语义层面的冲突检测与自动降级策略。

并非所有 Agent 都需要直接操作可写记忆。2026 年出现的 Wrapper Agent 提醒模式提供了一种轻量级替代方案：一个"包装层" Agent 监控主 Agent 的行为，在关键时刻注入记忆提醒，而不需要主 Agent 具备直接的记忆读写能力。这种模式特别适合已有单体 Agent 无法大改的场景——你在主 Agent 外包一层 event bus 订阅者即可，而不必重写 tool calling 或 ReAct 循环。

工作原理： Wrapper Agent 订阅主 Agent 的交互流（通常通过 message broker 或 hook middleware），当检测到特定模式时触发检索与注入。常见触发器包括：用户重复提问同一主题（可能主 Agent 未加载历史偏好）、任务上下文切换（从 coding 切到 scheduling，需加载另一 namespace）、长时间未提及某偏好（超过 7 天未验证的 memory 需 reconfirm）、主 Agent 输出与用户已知偏好明显矛盾（confidence 冲突告警）。注入方式有两种：prefill（在 user message 前插入 system 级 memory block）和 nudge（在主 Agent 回复后追加一句"根据记忆，用户偏好 X"供下一轮参考）。主 Agent 本身不需要知道记忆系统的存在——它只是"被提醒"了。

优势： （1）对主 Agent 零侵入，不需要修改其 prompt 或工具链；（2）记忆策略可以独立迭代——改 TTL、改 rerank 权重、改触发规则都不动主 Agent；（3）适合已有 Agent 系统的渐进式记忆增强，灰度时可只对 10% 流量开 Wrapper；（4）便于 A/B：同一主 Agent，对比"有提醒"与"无提醒"的任务完成率。

局限： （1）Wrapper Agent 只能提醒，不能代替主 Agent 做记忆决策——若主 Agent 忽略注入块，记忆等于无效；（2）提醒的时机和内容依赖规则设计，容易过度提醒（噪声导致 context 膨胀）或提醒不足（遗漏关键偏好）；（3）不适合需要深度记忆集成的复杂任务，如多步规划 Agent 需在每步 tool call 前读写 state；（4）延迟叠加：多一次检索 + 一次 LLM 判断，P99 需单独监控。

与 OpenWiki 的关系： Wrapper Agent 提醒模式可以作为 OpenWiki 的消费层——Wrapper Agent 从 OpenWiki 读取记忆，注入主 Agent；而主 Agent 的交互结果通过另一个异步写入 worker回写 OpenWiki（与读路径解耦，避免阻塞用户响应）。写入 worker 可复用 OpenWiki Write Path 的四步流程，但由独立服务消费 transcript 队列。这种读写分离的架构在工程上更容易实现和调试：读失败只影响体验，写失败可重试进 dead-letter queue。

人类大脑有主动遗忘机制——不重要的记忆会自然衰退，重要记忆会被反复强化。Agent 记忆系统同样需要遗忘能力，否则记忆库会迅速被过时、矛盾和噪声信息淹没。OpenWiki 0.1.0 文档中把 forgetting 列为一等能力：没有 TTL 与归档策略的生产部署，往往在 3-6 个月内出现检索噪声陡增、用户投诉"Agent 记错旧偏好"。

过期的三种策略：

TTL（Time-To-Live）： 每条记忆设置固定生存时间，到期自动标记为 expired。实现上可用 cron job 扫描 expires_at 字段，或写入时注册 delayed task。简单但粗糙——用户核心偏好（timezone、language）应设 permanent 或 365 天续期；临时任务状态（"正在等 PR review"）可设 24-72 小时。建议按 memory_type 分档配置，而非全局单一 TTL。

事件触发过期： 当特定事件发生时，相关记忆批量过期。例如，用户明确说"我换工作了"，则 employer、office_location 等 tag 下的旧记忆触发 invalidate；或 project_id 归档时，该项目下所有 task_state 记忆一并过期。这更接近人类的遗忘逻辑，但需要维护事件-记忆关联表（event_type → memory_tags）。可用轻量规则引擎或 LLM 分类器识别"人生/项目状态变更"类 utterance。

置信度衰减： 每条记忆的 confidence 随时间或未命中次数衰减：每 30 天未被 retrieve 则乘以 0.9，用户否定一次则直接置 0 并标记 disputed。低于阈值（如 0.2）后移入 archive tier，不再进入默认 Top-K。MemGPT 的"记忆压缩"机制就采用了类似思路——热记忆留 context，温记忆进外部库，冷记忆压缩为摘要或删除。

遗忘的工程实现： 过期不等于删除。推荐三层存储：active（参与检索）、archived（仅审计/人工恢复）、purged（合规要求下的物理删除）。检索 API 默认 filter status=active；管理后台可查看 archived。定期跑记忆健康度报告：过期未清理比例、冲突 unresolved 数量、单用户 memory 条目数 P99——超阈值则触发治理 sprint。

Multi-Agent 系统中，记忆管理面临额外维度——隔离与共享的平衡。不同 Agent 可能需要访问不同的记忆子集，同时某些记忆需要跨 Agent 共享。Orchestrator 调度子 Agent 时，若未传递 namespace context，极易出现子 Agent 用错用户偏好或读到其他 tenant 的数据。

隔离需求： （1）用户 A 的私人记忆不应被用户 B 的 Agent 访问——tenant_id 必须是检索的 hard filter；（2）不同职能 Agent（销售 vs 技术支持）的记忆空间应隔离，避免报价策略泄漏给外部用户；（3）临时 Agent（一次性 code runner）的记忆不应写入长期库，或仅写入 sandbox namespace 并在任务结束后 TTL 清空；（4）工具调用结果与用户画像应分 namespace，防止 debug log 污染偏好层。

共享需求： （1）用户核心偏好（locale、accessibility）应在所有 Agent 间只读共享；（2）组织级知识（产品文档、SOP）对所有 Agent 可读、仅 admin Agent 可写；（3）Multi-Agent 协作经验（A 与 B 联调任务 X 的成功 tool 序列）可写入 shared_playbook namespace，供后续编排复用。

OpenWiki 的解决方案： 采用 命名空间（Namespace）+ 访问控制列表（ACL） 机制。每个记忆条目属于一个命名空间（user:{id}、org:{id}、agent:{role}、task:{id}），通过 ACL 控制哪些 principal 可 read/write/admin。还可加语义 scope：检索时除 ACL 外，再 filter task_tags 与当前 intent 的交集。这种设计类似于文件系统权限，但增加了 Agent 场景的动态 principal（子 Agent 继承 orchestrator 的 delegated token，有效期与会话绑定）。

工程实践建议： 在多 Agent 系统中，记忆隔离应在架构设计阶段就确定，而不是后期补丁。一旦记忆泄漏发生（用户 A 的信息出现在用户 B 的对话中），修复成本极高，且可能已经造成信任损害。建议从第一天就实现严格的命名空间隔离，再逐步开放受控共享。上线前做红队测试：用恶意 prompt 诱导 Agent 读取其他 namespace；通过后再开可写记忆。OpenWiki ACL 变更应走 audit log，与 IAM 变更同级审批。

不是所有 Agent 都需要可写外部记忆。过度设计的记忆架构会增加系统复杂度、延迟和成本，而不会带来相应的价值。以下是基于场景的选型建议，并附架构决策清单供评审会用。

使用上下文窗口（第一代）的场景： 单轮对话助手、简单 FAQ、一次性任务执行。记忆持久化价值有限，工程投入应放在 prompt 与 tool calling。若用户从不跨会话返回，可写记忆 ROI 为负。

使用 RAG 只读（第二代）的场景： 知识库问答、文档检索、客服机器人。知识由人类维护，Agent 只检索回答。RAG 成熟链（LangChain + Pinecone/Milvus）足够；重点是 chunk 质量与 citation，而非 Agent 自写库。

使用可写外部记忆（第三代）的场景： 长期协作助手、个性化推荐 Agent、持续学习研究助手。Agent 需从交互中学习偏好、积累领域知识、更新任务状态。OpenWiki、Mem0、MemGPT 等工具正在定义最佳实践；选型时对比：OpenWiki 偏 Wiki/ACL/版本，Mem0 偏自动抽取，MemGPT 偏 context 压缩。

混合架构（推荐）： 大多数生产系统应采用混合——核心知识 RAG 只读（质量可控），用户偏好与交互经验可写（个性化），当前任务状态留上下文（低延迟）。关键是明确边界与流转：RAG 文档永不由 Agent 直接改；可写库条目需带来源；上下文只放本轮 plan 与 tool I/O 摘要。

迁移路径建议： 如果你的系统当前使用 RAG 只读，不要一步跳到全量可写记忆。推荐的渐进路径是：第一阶段，在 RAG 基础上增加一个轻量级的"用户偏好层"（仅存 locale、timezone、沟通风格等低风险偏好，TTL 30 天）；第二阶段，引入 Wrapper Agent 模式，在不改主 Agent 的前提下验证记忆注入的效果；第三阶段，才考虑全面接入 OpenWiki 类系统，开放 Agent 的结构化写入能力。每一步都应该有明确的评估指标（任务完成率、用户满意度、检索噪声率），达标后再进入下一阶段。

架构决策清单（评审前逐项打勾）： （1）是否跨会话？否 → 第一代可能够用。（2）知识是否由运营维护？是 → RAG 为主。（3）Agent 是否必须从对话学习新事实？是 → 需要第三代或混合。（4）是否 Multi-Agent / 多租户？是 → 命名空间与 ACL 是否已设计？（5）是否有合规审计要求？是 → 可写记忆是否版本化、可导出？（6）遗忘策略是否定义？未定义 → 禁止全量上线。（7）读写的 P99 延迟预算？可写+向量检索通常 +100-300ms，是否可接受？（8）是否与 Wrapper 模式兼容以便渐进迁移？

成本与运维考量： 可写记忆的运维成本显著高于 RAG 只读。向量数据库的存储成本随记忆条目线性增长；检索延迟随记忆库膨胀而增加（除非定期做 archive 压缩）；冲突解决和遗忘策略需要持续调优。建议在架构评审时明确记忆预算：单用户最大记忆条目数、单条记忆最大体积、每月新增记忆量预估。超过预算时，要么升级 archive 策略，要么缩小写入范围。OpenWiki 的 dashboard 提供了记忆健康度视图：active vs archived 比例、冲突 unresolved 数量、P99 检索延迟，建议接入告警系统。