我们上一篇文章的一条评论发现了我们的智能体审批机制存在一个漏洞。以下是我们的发现

摘要

## 复盘：共享 Markdown 记忆库里的 Agent 审批流程漏洞 ### 背景 我们团队维护着一个共享的 markdown 记忆库（memory repo），用于沉淀 agent 的上下文、约定和决策记录。多个 agent 通过 ingest 流程向其中写入内容。设计初衷是「先讨论、后提交」——审批在聊天里发生，达成一致之后再落到仓库里。 复盘时我才发现，这个流程实际上从一开始就是坏的。 ### 漏洞一：审批只发生在聊天中 审批环节完全活在 IM 的聊天记录里，仓库本身没有任何痕迹。聊天里的「看起来没问题」「可以合」既没有可检索的记录，也没有结构化的字段。结果就是： - 事后无法回答「这条内容当初是谁批的」 - 审批意见和最终落地的内容经常对不上 - 新成员接手时，只能靠翻聊天记录考古 ### 漏洞二：提交滞后或缺失 「讨论通过」和「实际提交」之间存在明显的时间差，有时甚至根本没有提交。滞后带来的问题是中间状态无人看守——讨论时的版本和最终提交的版本可能已经不是同一份。缺失则更糟：口头通过的内容从没进过仓库，但在聊天里大家都以为它已经是共识了。 ### 漏洞三：ingest agent 自行提交了绝大多数 commit 这条最致命。数据统计下来，绝大多数 commit 是 ingest agent 自己提交的，而不是经过人工确认的人提交的。于是产生了一个危险的等式错觉： > **「已提交」≠「已人工审阅」** 提交历史看起来很干净、很连贯，实际上只是 agent 在忠实地执行 ingest，把「写进仓库」这个动作和「被人类批准」这件事彻底解耦了。 ### 我们做的轻量修复 不需要重写整套流程，先上三件小事： 1. **未审阅文件标注** —— 未经人工审阅的文件显式打上标记，让「这份内容没人看过」在仓库里一眼可见，而不是靠猜。 2. **超期 open change 周检** —— 超过 7 天仍未处理的 open change，纳入每周例行检查，避免它们无声地烂在列表里。 3. **review flag 必须指定负责人** —— 一个 review flag 如果没有明确的 owner，就等于没有 flag。强制要求填写负责人，把「谁来审」从模糊的集体责任变成具体的人。 这些都是补丁性质的改动，不解决根本设计问题，但至少让问题从不可见变成可见。 ### 仍在征求意见：review gate 该放在读侧还是写侧 这是目前还没定下来的开放问题： - **写侧 gate**：在 ingest 提交之前就拦住，未审阅的内容根本进不了仓库。好处是仓库里永远只有可信内容；代价是 agent 的写入会被阻塞，吞吐下降，容易积累积压。 - **读侧 gate**：允许内容先落库，但在消费/检索时按审阅状态过滤，未审阅的内容默认不出现在 agent 的上下文里。好处是写入不被阻塞；代价是仓库里存在「半可信」状态的内容，过滤逻辑一旦有 bug，脏内容就会漏进上下文。 我个人倾向于读侧 + 写侧轻量标注的组合，但这取决于大家对「脏内容混入上下文」的容忍度。欢迎在这点上拍砖。