8.0
热点
AI SCORE
技术实践2026-08-16 19:40
Agent记忆系统缺的不是向量数据库，而是摄入边界
dev.to · AI#Agent#记忆系统#安全
Editor brief · 编辑速览
AI Agent的记忆系统应先定义什么信息有资格成为记忆，而非直接用向量检索。当前方案存在prompt注入、数据泄露等安全隐患。
大多数 AI Agent memory系统从检索层开始：选 embedding、加向量数据库、调 chunking、决定注入多少 context。
这是有用的工程，但起点晚了一步。
在问 Agent 应该如何检索记忆之前，我们需要先决定信息要满足什么条件才能成为记忆。
Agent 可以从网页、附件、笔记、聊天记录、导入的仓库、邮件和工具输出中捕获信息。每个来源都可能相关，但没有哪个是自动可信的。
如果捕获直接写入持久化记忆，系统会悄然合并三个不同的操作：
这个捷径很方便，但它也是一次权限升级。
恶意网页可能包含 prompt 注入。过时的文档可能与当前策略冲突。私有附件可能被放入错误的项目。生成的摘要可能把一次推理变成一个看似可信的事实。一旦其中任何一个成为持久化上下文，后续的检索就能让这个原始错误看起来合理合法。
问题不在于向量搜索不好，而在于检索质量无法弥补缺失的信任边界。
在 ChaseOS Studio 中，新捕获的材料进入 Intake 而不是可信记忆。
Intake 是候选材料的审查队列。它保留物品的来源，并让人决定它是否属于工作区知识图谱。拒绝发生在物品成为持久化 Agent 上下文之前。
操作链是：
这将知识权威与执行权威分离。一样东西可以安全地阅读但不适合记住。一样东西可以安全地记住，但不足以成为发布、发送、购买、删除或修改受保护状态的权威依据。
这些是不同的决定，应该保持可见为不同的决定。
一个有价值的 intake 决策不能只有一个"接受"按钮。审查者应该能够回答：
这使得 provenance 成为记忆对象的一部分，而不是事后添加的元数据。
这也改变了检索的形态。Agent 不再搜索一个没有区分的池，而是可以获得一个 scoped view：相关的项目、允许的来源类型、当前决定，以及任务所需的最少历史记录。
目标不是给 Agent 用户的一切知识，而是给 Agent 完成工作所需的最小可信上下文。
引入时的人工审查不能让后续每个动作都安全。
一份可信的项目简报仍可能导致用户不想自动执行的邮件、外部帖子或受保护的写入。因此 ChaseOS 将审批视为明确的运行时门禁。即使底层上下文已经可信，发布、外部发送和受保护的写入都会停止以等待人工决定。
这对无人值守工作很重要。"无人值守运行"不应该意味着"拥有无限权限"。它可以意味着 Agent 继续执行允许的步骤，在有影响的边界处暂停，并在审批后恢复。
这比无限制的自主性慢。少量的摩擦是有意的：它使得持久的后台工作更容易审查，也更容易信任。
审计跟踪应该记录的不只是最终的成功消息。
对于受治理的 Agent 工作，有用的历史包括：Agent 被允许读取什么、它产生了什么、哪个操作需要审批、什么被拒绝、以及运行为什么停止或继续。
这为操作员提供了一种诊断故障的实用方法：
没有这个证据，"Agent 做的"就不是一个解释。
这就是我在 ChaseOS Studio 中实现的模型——一个面向受治理 Agent 和持久项目上下文的本地优先 Windows 工作空间。
当前产品包括：
Community 版本是 Windows 10/11 x64 的完整免费本地产品。ChaseOS Core 及其合约采用 MIT 许可。Studio 是商业桌面层。
边界很重要：托管运行时、加密同步、Agent 集群和 GPU 计算是路线图工作，不是发布时的声明。这不是说这个产品已经解决了所有记忆问题，而是说 admission control 应该从一开始就内置于架构中。
当你的系统捕获一个页面、附件或工具结果时，在这些材料能够影响后续运行之前，到底发生了什么？
如果答案是"我们把它 embedding 了"，那么缺失的组件可能不是另一种检索技术，而可能是一个 intake 边界。
我是 ChaseOS 的构建者，我会重视对这个模型的技术批评——特别是那些自动 admission 确实更安全或更有用的场景。
探索工作空间，查看 Intake 和审批模型，并下载免费的 Community 版本：https://chaseos.ai/?utm_source=devto&utm_medium=organic_content&utm_campaign=governed_intake