项目私有记忆如何变成可复用知识？

标准回答

EachOf 区分项目私有记忆和可复用知识。项目私有记忆保留具体项目的事实、决策和限制；可复用知识则希望抽象出能在其他任务中使用的经验。两者不能因为都叫“记忆”就默认互通。

读取时，Core 根据权限决定 Agent 可以得到什么上下文。模型自己说“我需要访问项目 A”不能作为授权依据。同样，把一段私有内容换一种说法，也不代表已经消除了其中的敏感信息。

比如“某项目周五轮换密钥”属于具体项目事实，“密钥需要定期轮换”可以是一般经验。但泛化结果如果仍包含系统名、时间或具体操作细节，可能仍然受原作用域限制。因此从私有记忆到可复用知识，需要结合来源和发布策略判断，而不能只看模型是否完成总结。

这组权限语义也必须贯穿缓存、迁移、反馈和撤销。查询入口检查正确，但缓存串项目，或者历史接口放宽了权限，整体隔离仍然会失效。具体数据库隔离技术应以实现为准，架构上划分了作用域，不等于自动实现了所有安全边界。

“项目 A 的密钥轮换时间”是私有事实；“密钥需要定期轮换”可以是一般知识，但具体时间、系统名和来源细节仍可能需要保留在私有范围。

不默认全部共享。Agent 是访问客户端或主体，能看到什么，取决于它代表的用户、项目和授权范围。同一个项目内可以按策略共享，多项目之间则需要明确授权。否则所谓协作很容易变成数据串用，尤其是缓存和可复用知识入口也必须保持同样的权限语义。

缓存必须把影响可见性的作用域纳入设计，不能只用查询文本作键。读取缓存时，还要考虑权限或来源版本是否已经变化。一个用户之前能访问，不代表权限撤销后还可以继续拿到旧缓存。这是缓存正确性的必要条件；具体键结构、失效传播和授权复核位置，需要与项目代码逐一对应。

材料未说明具体租户隔离、RLS 或加密方案，不能把某种常见技术直接写成已实现。