外观
EachOf 为什么没有直接使用 Mem0 或 Hindsight？
项目版本说明
这些问答整合历史设计与实现资料；当前 main 分支 README 以工作包描述建设状态。具体能力、实验数据与设计目标的边界见项目状态与证据。
标准回答
我做 EachOf，核心是想解决多 Agent 长期协作中“旧知识继续影响新决策”的问题。普通的记忆接入，重点是把信息存下来、下次找回来；我的项目还要管理这些信息什么时候有效、依赖它的结论什么时候应该停用，以及不同 Agent 能不能使用它。
举个例子：项目原来允许自动升级，后来规则改成必须人工确认。只更新这条原始规则还不够，因为系统可能已经生成了“可以直接升级”的建议，甚至缓存了包含这条建议的答案。如果这些派生内容继续被召回，Agent 仍然会按旧规则做事。所以我把来源追溯和推导依赖分开记录，并保存来源的语义版本和内容摘要。来源纠正后，依赖旧依据的推导要退出当前召回，缓存答案也要复核来源；撤销和跨实例迁移时，同样要保持这组有效性规则。
这也解释了我为什么把权威写入收口到 Go Core。Python Processor 可以调用模型做抽取、泛化和向量化，但产出只是候选。最终能不能写入，由 Core 检查权限、来源和策略。我把这个边界称为 Trusted Commit。比如一个任务开始时依据还是 v1，执行期间来源变成了 v2，迟到的候选就不能因为“模型已经生成完了”而直接成为当前知识。
Mem0 和 Hindsight 都是应该认真考虑的现成方案。Mem0 提供长期记忆接入和自部署能力，Hindsight 提供 retain、recall、reflect 等记忆操作，和我的项目有明确重叠。因此，我不会把自研理由说成它们只是向量库，或者断言它们做不到这些事情。EachOf 的价值在于，我把自己关心的纠错、撤销、提交和迁移规则做成了项目的一等能力，并围绕这些规则验证实现。
这个选择的代价也很明确：权限、任务可靠性、数据迁移和后续维护都需要自己承担。我目前没有完成与这两个项目同条件的全面对照，所以不能证明自研是成本最低的选择，更不能声称全面领先。如果是交付一个以快速接入长期记忆为主的业务，我会先验证现成方案；如果它已经满足这些规则，我愿意直接复用，或者只在外层补充治理逻辑。对这个项目，我能说明的是自己实现了什么、为什么这些边界值得验证，以及现在的验证还覆盖不到哪里。
关键机制
- 先承认重叠：抽取、存储、检索、作用域等能力不是 EachOf 独有；开源、可自部署或使用 pgvector 也不能单独构成差异。
- 把比较落到可重复用例：来源纠正后旧结论是否返回、旧缓存是否失效、过期任务能否提交、迁移后视图是否一致。
- 自研代价包括权限、数据迁移、异步调度、维护和安全；现成引擎、二次开发与外围治理层都应该进入候选。
通俗例子
假设来源从“允许自动升级”改为“需人工确认”。要比较的是依赖旧政策的建议与缓存是否及时停用，不能只比较谁能返回一条相似文本。
追问与回答
这是不是重复造轮子？
有一部分确实重叠，比如抽取、存储、向量检索，这些都不是我的独创。自研是否有价值，要看额外控制的规则是否解决了具体问题。EachOf 重点控制的是来源变化后推导的有效性，以及异步候选成为权威记忆的条件。为了验证这组规则，自研有研究和工程实践价值；但放到业务交付中，还要比较接入、改造和维护成本。如果现成方案能满足，我不会坚持把通用部分全部自己维护。
你实际验证过 Mem0 或 Hindsight 不满足吗？
目前我没有完成固定版本、相同数据和相同故障条件下的全面对照，所以不能说我已经证明它们不满足。准确地说，我验证的是 EachOf 自己的机制，其中有小样本迁移验证和受控检索实验。若要据此作生产选型，我会再做一组共同用例：改正来源后旧结论是否退出、撤销后缓存是否仍返回、旧 Worker 是否能迟到提交、迁移后当前与历史视图是否一致，再比较质量、延迟和维护成本。
为什么不在开源项目上二次开发？
二次开发或加一层治理服务都是合理路径。关键在于扩展点能否覆盖权威写入、来源版本和失效传播：如果只需要加元数据和查询过滤，外围扩展可能更划算；如果规则涉及每一条提交、缓存和异步任务，就需要评估改动范围及跟进上游升级的成本。我目前没有证据证明二次开发一定更贵，所以不会把它排除。EachOf 让我完整实现并验证了这组契约，但生产决策仍应该重新比较复用成本。
与普通 RAG 相比，你究竟多做了什么？
普通 RAG 可以从资料中召回相关片段，当然也能加入版本和权限控制。EachOf 在此基础上明确管理“资料如何变成记忆、记忆如何形成推导、这些推导何时失效”。例如原文被纠正，受影响的不只有原文向量，还有已经生成的结论与答案缓存。我的工作是把这些关系和状态变化纳入统一读写边界，而不只是提高相似度搜索的命中率。
最有价值的成果是什么？
我更看重一套能解释、能验证的记忆有效性规则：结论有依据，来源变化能影响派生内容，模型结果需要经过受控提交，迁移后还要保持可见性语义。另外做过小样本的排序实验和迁移验证。但这些结果不能证明系统已经适合任意规模，也不能拿来代替竞品对照。我的下一步重点会是扩大样本，以及补齐并发纠错、撤销和迟到提交的验证。
易混淆点
不要说“Mem0 只是向量库”“Hindsight 没有治理”或“我的性能全面更好”。官方产品持续变化，必须区分开源版本、托管功能和测试时间。
参考资料
内容来源
- Android 技术札记 · 原条目
eachof-build-buy