AI Agent 记忆写入需设人工审查门

如果你在构建任何给 AI Agent 提供持久化存储写权限的系统——知识库、记忆层、Agent 可以自行更新的向量库——在发布之前都值得读一下 CVE-2026-59726。这不是某个框架的推介文，而是我为自己的个人知识系统实际运行的审核逻辑，解释我为什么这样设计，以及它旨在捕获的确切故障模式。包括我强制执行的 entry schema 和审核 gate 本身的伪代码。

几个月来，我的"知识库"是 1,140 篇 Obsidian 笔记，背后没有任何过滤机制——我把一些摘录和半成型的想法说服自己当作了第二大脑。我可以搜索所有内容，却无法使用任何内容，因为没有任何内容经过核查、连接，或被过滤以判断它是否能加速下一次研究会话。我一口气删除了整个文件夹，感受到的不是失落，而是解脱。

取代它的是刻意朴素的方案：纯 Markdown 文件，按框架和主题组织，外加一条在写入时强制执行的硬规则。

每条 entry 需要恰好三个字段，第三个字段才是真正的 gate：

entry = {
    "claim": str,           # the assertion, stated plainly
    "source": str,          # named source
    "source_date": date,    # dated — undated sources don't qualify
    "why_it_mattered": str, # one sentence, written by a human, honestly
}

如果 why_it_mattered 无法诚实书写，那这条 entry 就不会被提交。这不是格式规则——这是综合步骤。根据 2026 年 6 月一个名为 NatureBench 的基准测试（arXiv 2606.24530），这也是 AI Agent 在可衡量层面表现最差的阶段。NatureBench 让编码 Agent 对抗 90 个从同行评审的 Nature 系列论文中抽取的任务。Agent 理解了任务分配，它们的主要故障模式是选错了方法——默认使用训练数据中最接近的模式，而不是真正适合任务的方法。这就是检索偏差，这是任何系统（人类或 Agent）在没有强制核查步骤的无过滤档案上工作时都会出现的问题。

Gate 的伪代码实现

def write_entry(candidate, reviewer_signoff):
    if not candidate.claim:
        return reject("no claim")
    if not candidate.source or not candidate.source_date:
        return reject("no dated source")
    if not candidate.why_it_mattered:
        return reject("no justification — most common rejection reason")
    if not reviewer_signoff.human_reviewed:
        return hold_for_review(candidate)  # never auto-commits
    return commit_to_knowledge_base(candidate)

这个函数中没有任何分支允许 Agent 在无人监督的情况下提交 entry。这就是整个设计。每天大约花费我十分钟。

为什么 gate 不是可选项——CVE-2026-59726

2026 年 6 月 30 日，一名研究人员披露了 CVE-2026-59726（"RufRoot"），该漏洞存在于 Ruflo 中——一个拥有 67,000+ GitHub stars 的开源 AI Agent 编排平台。Ruflo 的默认 Docker 配置将其 MCP Bridge（路由每个工具调用的服务器）暴露给 233 个工具，通过 HTTP 访问且零认证。只需一个未认证的 POST 请求就能在容器内获得 shell 访问权限，以及对 Agent 持久化记忆的写入访问权限。维护者在 24 小时内发布了修复方案；该修复添加了认证机制，而不是在工具执行路径本身中添加人工检查点。

我并非在运行一个生产级编排平台。但这个结构性教训完全可以缩小适用：当一个 Agent 拥有一个可以写入你视为永久记录的工具时，那个工具就是一条写入路径。如果没有任何 gate 保护它，所有下游——包括个人知识文件——都会继承这个风险。

关于"不要信任 Agent 自我报告"的数据

如果你在决定多大程度上实现自动化，有两个数据集值得关注：

AgentHallu（arXiv 2601.06818）：横跨 7 个框架的 693 条真实 Agent 轨迹。表现最好的模型在总体上只有 41.1% 的情况能正确定位导致幻觉的步骤——对于工具使用幻觉这一与 Agent 写入文件最相关的类别，更是低至 11.6%。

一项针对 1,639 个代码库中 20,574 个真实编码 Agent 会话的研究（arXiv 2605.29442）发现，总体不对齐率随时间下降，但约束违反和不准确自我报告的比例却在增长。Agent 平均表现越来越好，但在诚实告知自己出错时却越来越差。

一个无法可靠诊断自身故障的自动化系统，不应该成为某内容成为你永久记录前的唯一检查点。

我仍然实现自动化的部分

这一切都不是反对 Agent 的论点。微软关于其内部 Claude Code 和 GitHub Copilot CLI 推广的一项研究（arXiv 2607.01418）发现，采用者在四个月窗口内合并的 pull request 增加了约 24%——这是一个真实的、可衡量的收益。我自己的研究阶段大量依赖 Agent 辅助。不会被自动化的是写入行为本身。机制可以，是的。判断不行——至少现在还不行——而 RufRoot 就是本月关于一个团队做出相反假设后会发生什么的证明。

完整六阶段框架（Knowledge Flywheel™）、30 天构建计划和完整架构：Building A Personal Knowledge Engine With AI。