给智能体记忆加上“私有”标签，并不意味着检索链路就自动实现了隔离。CrewAI于10月23日发布的1.15.29版本修正了一个具体边界：私有记录没有填写来源、查询也没有填写来源时，旧逻辑可能因为两个空值相等而把记录放进默认结果。修复落在检索过滤条件中，提醒企业检查的不是模型会不会保密，而是调用代码究竟允许哪些记录进入上下文。

快速看点：一，修复同时覆盖浅层检索与深层召回；二，空来源不再被视为私有记录的有效归属匹配；三，同来源访问与显式包含私有记录的选项仍存在，不能把这次更新理解为完整的多租户身份认证系统。

问题藏在“空值等于空值”的默认分支

统一记忆组件既保存内容，也保存类别、范围、来源和私有标记。来源参数可用于标识记录来自谁；查询时也能提供相应标识。对公共记录，检索主要围绕相关性工作；对私有记录，还需要判断请求是否符合可见条件。这个判断一旦过宽，后面的回答即使完全遵守提示词，也可能已经读到了不应出现的上下文。

在1.15.28的相关过滤中，非私有记录可以通过，私有记录在来源相等时也可以通过。但来源允许为空，而默认查询同样可以不提供来源。这样，两边都为空就满足相等关系。问题不是私有标签没有保存，而是判断没有区分“明确属于同一个来源”和“双方都没有说明来源”。

1.15.29增加了非空前提：在没有显式包含私有记录的情况下，私有结果必须先具备查询侧的非空来源，再与记录来源匹配。无归属不再被当作共享身份。它改变的是默认可见性规则，不是删除已有数据，也不是把历史内容自动分配给新的所有者。

浅层和深层都要守住同一条规则

浅层路径把查询转为向量后执行检索，再过滤候选；深层路径则会进行查询分析、范围选择和进一步探索。两条路径都可能读到同一类私有记录，因此只修其中一条并不足够。标签版本中的统一记忆实现与召回流程均加入了非空检查，使这条可见性规则在两种路径中保持一致。

与改动配套的回归测试把公共记录和来源为空的私有记录放在同一个测试存储中，分别检查浅层、深层默认查询：公共记录应保留，私有记录不应返回。另一组测试检查具名来源能够读取相应私有记录，以及显式开启包含私有记录时仍可返回它。

这些测试说明了维护者希望保留和改变的行为，但不等于现实部署已经完成安全审计。测试使用受控数据和模拟组件，不能证明所有自定义存储、插件、缓存和外围服务都不存在旁路。这里核对的是公开代码和测试约定，并不是对某个企业生产环境的复现报告。

来源字符串不是登录身份，开关也不是授权

最容易被忽略的限制是：来源仍是调用参数。若业务接口允许不可信请求随意填写他人的来源字符串，字符串相等并不能证明请求者真的属于那个人。企业必须在模型之外完成身份验证，把可信身份映射到查询条件，并阻止客户端自行扩大范围。

显式包含私有记录的选项也仍然有效。因此，普通用户能否触发这个选项、代理工具是否能修改它、后台任务是否沿用过宽的默认配置，都应进入权限检查。升级组件可以收紧这次暴露的默认分支，却不能代替应用层审查谁有权选择更宽的读取方式。

部署团队还可以检查记忆写入：哪些路径会遗漏来源，公共与私有记录如何分类，迁移数据是否丢失标记。修复后，以前依赖空来源也能读回的业务可能发现结果减少；这时应确认归属和合法使用方式，而不是为了恢复召回数量直接打开全量私有读取。

小编判断：把“不该召回”写进升级验收

这次更新没有提供已发生攻击的证据，也不能据此推断所有CrewAI应用都泄露过数据。影响取决于是否使用相应记忆实现、是否存在无来源私有记录，以及查询和存储如何配置。版本评估应围绕具体使用路径展开，不能把一个条件修正渲染成整个框架已经具备或彻底失去安全性。

可复用的教训很明确：记忆系统的回归测试不仅要问“能否找到正确内容”，还要问“是否混入不该返回的内容”。将空来源、相同来源、不同来源和显式管理读取分别列成用例，再覆盖不同召回路径。让负向权限测试与相关性评测并行，才不会在追求更多上下文时，把缺失身份误当成访问许可。