我的团队同时在用 Codex 和 Lark。白天在电脑前，很多分析和代码相关的问题都在 Codex 里走；离开工位以后，大家会在 Lark 里继续问同一件事。刚开始一切都好，工具各司其职。但后来发现有点不对劲：Codex 和 Lark 之间没有统一记忆，导致同一个 defect，在 Codex 处理完，到了 Lark 里却完全没有”印象”。
就在刚才，我在Lark 里问“DEF-123 最后结论是什么”，系统给了另一条任务的摘要；我回到 Codex 继续问，得到的又是另一版上下文。显然，这不是提示词问题，也不是模型能力推理不足，而是我们没有真正做“统一记忆”。
先走错了一步
第一反应当然是同步聊天记录。实现也不复杂，看起来像捷径。
但这个方案只在 demo 阶段好看，进入真实协作就开始变形：聊天内容噪声太大、话题会跳、同义表达太多，而且 IM 渠道本来就更宽，一不小心就会把不该露的细节露出去。
后来怎么改
和团队讨论一下，我们决定建一个统一记忆服务，让 Lark 和 Codex 都能访问。这个”记忆”不是简单的聊天消息，而是任务状态——也就是一个专门管理结构化、带作用域（scoped）的任务状态的服务。Codex 和 Lark 都通过这个服务打交道。
我们的策略很简单：这个服务里只让结构化摘要跨端流动，原始聊天日志不直接暴露。这样做的原因是，我们只需要共享工作相关的结构化记忆，而不是所有的消息。
每条记录需要至少带上：
user_idproject_idjira_idchanneltimestamppermission_scope
这样做的好处不仅是为了提高检索精度。如果记录只有 user_id，检索就会”串线”，这一点我们已经在项目里验证过了。
还有一个很实操的原则：如果 project 或 jira 信息不完整，就不要自信地猜。
比如，用户在 Lark 上问一句”上次那个 defect 怎么样了？”正确的处理顺序应该是：
- 先看显式信息：DEF 编号、项目名（来自 Lark 聊天记录）
- 再看近期上下文和最近活跃任务（来自统一记忆服务）
如果还不够，就追问。宁可多问一句，也别自信地答错一句。
最小架构与落地顺序
Codex 与 Lark 统一记忆的最小架构与落地顺序
架构上我们没有搞复杂，就是两个入口（Codex、Lark）都只走同一个 Memory API，再把 workflow、artifact、索引、权限服务挂在后面。
落地顺序也很朴素：先做 Working Memory 的最小闭环，再强制写入字段，再收敛 Lark 返回格式（摘要+链接+下一步），然后补歧义追问，最后加任务收尾摘要。这里顺序挺重要，尤其前两步，少一步后面都会返工。
现在还没解决完的部分
这套方案到现在为止是有效的，但离“完成”还差得远。
首先是维护成本，Memory API 和权限策略不是一次性工作；其次是摘要质量，它会直接影响检索质量；再就是时效性，任务状态变得很快时，摘要会有短时间滞后。
接下来我主要补三件事：摘要质量评估与回放（低质量自动重写）、关键任务人工确认点。做完这些，统一记忆至少是一个可追溯、可恢复、可以慢慢变好的工程系统，而不是“看起来打通了”的演示系统。