外观
如何理解用一个故事贯穿全过程？
项目版本说明
这些问答整合历史设计与实现资料；当前 main 分支 README 以工作包描述建设状态。具体能力、实验数据与设计目标的边界见项目状态与证据。
标准回答
下面是教学示例：你在做一个“座舱资料助手”，先决定日志保留 30 天，后来调整为 7 天。所有示例记录与数值只用于解释机制。
第一天：记下一条项目决定
你说：“这个项目的诊断日志保留 30 天，方便排查偶发问题。”
- 把这段信息交给 EachOf，并指定“座舱资料助手”这个 Space。
- 处理器提取候选陈述：“诊断日志保留 30 天”。
- Core 校验候选与来源，把它写成带状态的记忆。抽取内容最初是
suggested，不能直接当作已确认事实。 - 确认后，后续有权限的 Agent 可以查询到它。
第二天：换一个 Agent 继续
你问：“帮我设计日志自动清理方案。”新 Agent 通过接入的工具查询项目记忆，EachOf 返回“保留 30 天”及相关来源信息。Agent 再结合当前任务给出方案。
这里需要同时满足：Agent 连接到了 EachOf、有该 Space 的权限、发起了查询，并实际使用返回的上下文。仅仅安装服务，不代表所有 AI 会自动共享记忆。
第三天：决定调整为 7 天
你把记忆改成“保留 7 天”。假设系统之前根据旧记忆产生过派生结论：“30 天以前的日志可以清理”。这条结论的依据已变化，需要退出当前可用结果，等待重新计算。
同样，如果曾缓存“日志保留多久？”的答案“30 天”，也不能只看缓存还在就返回。系统需要重新检查引用的记忆和版本。
第四天：撤销一份资料的使用授权
你撤销了某个来源。系统应立即阻止后续受控检索继续使用由该来源支撑的相关内容，后续再异步做索引清理、隔离和对象清除。
必须能讲清的边界
撤销能控制 EachOf 之后提供什么。已经发给外部 Agent 的文字，不能假设能从对方的历史、文件或缓存中自动收回。
用一张表记住整个故事
| 动作 | 系统关心什么 | 能讲出的价值 |
|---|---|---|
| 记住决定 | 来源、范围、状态 | 知道保存的是什么，以及依据在哪里。 |
| 换 Agent 使用 | 权限、相关性、上下文预算 | 新会话按需继续。 |
| 纠正决定 | 源版本、推导依赖、缓存引用 | 减少旧事实继续影响新回答。 |
| 撤销来源 | 授权状态、受影响链路 | 停止后续受控使用。 |
自查：只把“30 天”那一行改为“7 天”，为什么还不够？
旧事实可能已经被用于生成其他结论和缓存答案。源记忆、派生内容、答案缓存需要保持一致，否则用户看到的仍可能是“30 天”。
内容来源
- EachOf Wiki · 记忆与上下文 · 原条目
story