外观
如何理解常见追问与直接回答？
项目版本说明
这些问答整合历史设计与实现资料；当前 main 分支 README 以工作包描述建设状态。具体能力、实验数据与设计目标的边界见项目状态与证据。
标准回答
先口头回答，再展开。每道题的第一段直接回答问题，后面补充原因或例子。
- EachOf 到底存的是什么？
保存与工作有关的长期陈述，例如偏好、项目决定、历史事实，以及对应的来源、状态、时间与范围。原始资料、抽取出来的记忆、推导关系是不同层次的数据。
- 是不是把聊天记录全部存下来就行？
不够。聊天记录含有重复、试探、错误与过时内容，需要识别值得保留的信息，并知道它是否确认、属于哪个范围、何时有效。原始记录有追溯价值，但不能直接等同于可用事实。
- EachOf 是怎么让 AI“记住”的？
把信息持久化，查询时找出相关且有效的部分，交给 Agent 作为上下文。它不要求为每次用户信息更新都重新训练模型。
- 和知识库 RAG 有什么关系？
都能采用“检索资料再生成”的读取方式。EachOf 的产品重点还包括长期陈述的状态、来源、纠正、撤销、跨会话使用与迁移。成熟 RAG 系统也可能实现其中很多能力，所以区别应按具体功能和约束说明。
- 为什么不用一个 Markdown 文件？
少量固定项目规则可以用 Markdown。需要按范围授权、追踪来源与版本、管理多条派生关系、支持多个调用方和受控撤销时，服务化的结构与校验才更有价值，同时也增加维护成本。
- Memory 和数据库里普通一行有什么区别？
物理上可以由数据库记录承载；产品语义上，它还绑定来源、时间、状态、范围和关联关系，并经过写入与读取规则约束。价值来自这些行为及其一致性。
- 为什么处理器不能直接写数据库？
防止处理器绕过权限、来源、版本和状态约束，也减少算法实现与数据库结构的耦合。处理器只提供候选，Core 决定能否正式写入。
- Core 校验了，为什么还需要 suggested？
结构和权限校验不等于事实真实性校验。模型可能提取错，因此候选可以被正式记录为“待确认”，而不是直接标成已确认事实。
- 为何不全用 Go 或全用 Python？
单一语言可以降低运维与协作成本。当前架构把平台状态和模型处理分开，分别使用 Go 与 Python，是为了独立运行与替换处理逻辑。回答应说明这项隔离带来的收益及额外复杂度。
- 向量检索与关键词检索，选哪个？
当前架构采用混合检索，分别覆盖明确词语和语义表达。如何融合与排序、是否真的带来收益，要用具体数据验证；不是永远固定哪一路更好。
- 查不到相关记忆怎么办？
应明确返回不足或无结果，由上层决定澄清、查询其他来源或使用通用知识，并区分依据。不能为了给出答案就编造项目事实。
- Embedding 服务挂了怎么办？
真实查询向量服务失败时，语义通道不可用，关键词检索继续，返回 semantic_channel_unavailable 标记。调用方应知道结果来自降级路径。
- 修改一条记忆，如何影响旧结论？
记录派生结论使用的来源及版本，当前版本不匹配或来源不可用时，把旧推导排除出当前有效结果，并按需要重新处理。答案缓存也要重新检查依据。
- 撤销和重新算向量，哪个先做？
先让撤销对后续受控读取生效。向量重建、隔离和物理清理可以异步完成；不能等待后台计算结束才停止使用已撤销内容。
- 已经把内容给了 Agent，还能撤回吗？
EachOf 可以限制未来访问，无法单方面保证外部 Agent 删除历史、日志和文件中的副本。这需要接收方协议和实现配合。
- 租约到期时旧 Worker 恢复了怎么办？
需要校验它提交时的执行资格和候选依据，不能只因它曾领过任务就接受。任务可能重复运行，因此提交侧还必须保证幂等。具体拒绝与重试细节要追当前任务路径。
- 幂等和事务有什么区别？
事务关注一组数据库操作的原子性与隔离等属性；幂等关注同一业务操作重复执行时的结果。一次事务成功后再收到相同请求，仍需要幂等约束避免重复业务副作用。
- 为什么撤销事件放 outbox？
让业务状态变更和待处理事件一起持久化，降低“状态变了但通知丢了”的风险。后台消费者可以重试处理这些事件，也要处理重复投递。
- Space 如何避免串数据？
身份与有效授权决定可访问范围，查询和后续返回、派生提交等路径需要保持该范围。不能只靠前端隐藏，也不能让模型自己决定哪些项目数据可以看。
- MCP 会自动让模型调用记忆吗？
不会。MCP 提供标准接入能力，宿主与 Agent 决定是否、何时以及怎样调用。必须验证工具返回内容确实进入当前上下文。
- 有访问回执就能证明记忆有用吗？
不能。回执证明交付了上下文。实际使用、使用正确、提高任务表现，需要额外的行为记录或端到端评估。
- 为什么不直接说“准确率提升 3.75%”？
需要区分百分比和百分点，说明指标、模型、样本、基线及实验条件。过去的小样本 Precision@5 提升不能概括当前所有任务，也不能推出相对竞品领先。
- 当前最值得继续优化什么？
根据本次读取的仓库调查，检索排序质量和评测数据适配是明确问题；同时应持续验证撤销、纠正和跨会话实际使用。具体优先级取决于当前实验和用户需求。
- 怎么说明自己的个人贡献？
只讲自己真实完成并能追到代码或设计依据的部分。按“我负责什么、为何这样设计、遇到什么故障、如何验证”展开。本 Wiki 不替你推定每个模块都由你独立实现。
内容来源
- EachOf Wiki · 记忆与上下文 · 原条目
questions