外观
如何理解把项目讲成自己的话？
项目版本说明
这些问答整合历史设计与实现资料；当前 main 分支 README 以工作包描述建设状态。具体能力、实验数据与设计目标的边界见项目状态与证据。
标准回答
先理解，再复述。下面讲述只覆盖当前读取到的架构与机制，不包含未经核实的个人贡献、企业生产规模或性能领先结论。
30 秒版：让不懂 AI 的人听明白
EachOf 是我做的 AI 长期记忆项目。使用 AI 做一个长期项目时，换了会话或工具，经常要重新解释背景。EachOf 把项目偏好、决定和依据保存起来，让有权限的 Agent 按需找回。用户也能查看、纠正和撤销这些记忆；来源变了以后，系统会检查旧结论和答案是否还能继续使用。
90 秒版：说明核心流程
EachOf 解决的是跨会话、跨 Agent 的项目上下文延续问题。它把长期信息组织成 Memory，放在有权限边界的 Space 中，通过 Connection 接入外部应用或 Agent。
写入时，Python 处理器提取候选记忆，Go Core 负责校验来源、权限和数据约束，再正式写入。读取时，结合关键词与向量检索，找出相关且仍有效的记忆，在预算内交给 Agent。
我关注的一个重点是记忆变化后的影响。比如日志保留规则从 30 天改成 7 天，不能只改原记录，还要检查基于旧版本产生的结论和缓存答案。架构上通过来源、推导依赖和版本校验处理这些问题；异步任务则用租约、重试与幂等提交提高可靠性。效果需要分别验证检索质量和实际使用收益。
3 分钟版：按照这五段展开
| 时间 | 讲什么 | 可以使用的句子 |
|---|---|---|
| 0:00–0:30 | 问题与定位 | “长期项目跨会话会丢背景，旧信息也可能继续误导新任务。” |
| 0:30–1:05 | 完整例子 | “先记住日志保留 30 天，换一个 Agent 设计清理任务，再把规则改成 7 天。” |
| 1:05–1:45 | 架构与数据流 | “Go 管权威状态，Python 产候选；PostgreSQL 与 pgvector 支撑数据和混合检索。” |
| 1:45–2:30 | 两个技术难点 | “变化之后如何阻止旧依据被继续使用；任务失败重试时如何避免重复提交。” |
| 2:30–3:00 | 验证与限制 | “分别检查权限、失效、检索和任务收益；外部已取得的内容不能假设自动收回。” |
卡壳时，回到这六个动词
记住 · 校验 · 找回 · 使用 · 纠正 · 撤销
每个动词解释一句，串起来就是完整项目。名词是为解释动作服务的。
技术选择怎么讲得有说服力
使用“需求 → 选择 → 获得什么 → 付出什么 → 怎么验证”这个顺序。例如：“需要计算与权威写入隔离，所以把 Python 处理器放在进程外，通过协议交结果；这样可替换和重试，但增加部署与协议维护成本；需要通过故障测试验证恢复行为。”
暂时不要这样表述
| 容易误导的说法 | 更准确的表述 |
|---|---|
| “模型已经学会了用户资料。” | “应用保存资料，在需要时提供给模型。” |
| “向量检索保证找到正确答案。” | “向量搜索返回语义相关候选，效果需要评估。” |
| “Trusted Commit 保证记忆真实。” | “它保证正式写入经过平台约束与校验。” |
| “撤销后所有 Agent 都忘了。” | “撤销限制未来的受控读取，外部副本另有边界。” |
| “已经证明全面优于竞品。” | “只有同条件、可复现的对照才支持性能比较。” |
闭卷练习：用日志保留期的例子，连续讲 90 秒。
检查是否说到了：写入不是立即确认；新 Agent 要主动接入并获取上下文；修改规则会影响派生结论和答案；撤销不能自动清除外部已获得副本。四点完整，比堆满术语更重要。
内容来源
- EachOf Wiki · 记忆与上下文 · 原条目
explain