Gate 机制：如何让 AI Agent 从“看起来做了”变为“真的做了”

问题

我让 AI 分析 6 个群的聊天记录，AI 输出了漂亮的分析报告——138 条信号、团队互动表格、关键洞察。一切看起来完美。

5 天后我发现：报告是写了，但底层数据一条也没有真正存入系统。

4 个人的沟通记录在 4-23/4-24 两天完全空白。那 138 条信号只存在于那天的对话上下文和一张 Daily 表格里——一关窗口就消失了。

这不是个案。同一个月内，我在 3 个不同的 AI 技能中发现了完全相同的模式：

#	场景	AI 做了什么	AI 跳过了什么	后果
1	聊天分析	输出了信号分析表格	没写入各人的 log 文件	5 天后发现 4 人数据空白
2	待办治理	显示了 triage 看板	没回写源头 action 状态	已关闭的待办反复出现
3	日总结	叙述了"已完成/已撤回"	没更新对应字段值	逾期警告持续误报

三个不同的技能，完全独立的时间和场景——同一个 bug。

分析

为什么 AI 在三个地方犯了同一个错？

因为这不是偶然的疏忽。这是 LLM 的结构性倾向。

AI 的"可见性满足偏好"

LLM 的训练目标是产出"可读、合理、对话有逻辑"的输出。它的任务完成感来自：

• 输出看起来正确
• 用户看到了信息
• 对话上下文是连贯的

而把数据写入底层文件——对 AI 来说，这是一个额外的、不产生即时反馈的动作。做不做，对话质量不变。用户也看不出区别（直到 5 天后翻车）。

我给这个反模式取了个名字：Visible-but-not-Persisted (可见但未持久化)。

AI 让你看到了它做了——但没有真的做。

为什么"提醒 AI 注意"没用

第一反应是在 prompt 里加一条规则："做完分析后，必须写入 people/log"。

加了。然后过了两周又翻车了。

原因是：AI 概率性遵守规则。它可能 90% 的时候记得，但 10% 的时候会"忘记"。而且恰恰是在最复杂、Token 消耗最多的场景——最容易"忘"的时候，才是后果最严重的时候。

靠 AI 的"自觉"来保证数据完整性，就像靠新人"记住要部署"来保证发布流程——不是做不到，而是不能依赖。

方案：Gate 机制

解法是把"AI 应该做的事"变成"AI 必须证明做了的事"。

Gate = 强制检查点 + 机器验证 + 事件日志。

核心设计原则

1. 机器可验证，不依赖 AI 自报告

每个 Gate 背后是一个 Python 脚本，直接扫描文件系统。

 复制代码# verify_chat_analyst.py 的核心逻辑 (简化)
def check_people_log(date, signals):
    for signal in signals:
        account = signal['person']
        log_path = f"people/{account}/log.md"
        # 直接 grep 文件——不问 AI "你写了吗？"
        if f"[chat-analyst] {date}" not in open(log_path).read():
            FAIL(f"Missing: {log_path} has no entry for {date}")

重点：脚本直接读文件，不问 AI "你做了吗？"。AI 说什么不重要，文件里有什么才重要。

2. 失败即中止，没有"下次注意"

Gate 失败 = 流程中止。不是"下次注意"——而是"现在就停，修完再继续"。

这一点关键。如果失败只是个 warning，AI 会学会忽略它（就像开发者忽略 lint warning 一样）。

3. 事件日志：append-only 审计轨迹

每次 Gate 触发（无论成功或失败），都追加到一个事件日志：

 复制代码2026-05-07T19:55  PS-01  daily 2026-05-07: 会议未创建骨架就写了 daily
2026-05-07T19:55  PS-06  incremental_collect 被 AI 自行跳过

这个日志是只增不删的。它让你能回溯"AI 在什么时候、什么场景下试图跳过规则"。

6 域 Gate 体系

一个月内，我从 3 个事故推广到了 6 个领域的完整 Gate 体系：

每个域有自己的 verify 脚本，但底层共享一个 sot_lib.py 解析库——提供 5 个纯函数原语（解析 frontmatter、定位文件、检查 log block 等），不重复造轮子。

一个典型 Gate 的完整生命周期

以 CA-LOG (chat-analyst 回写 Gate) 为例：

阶段	发生的事
触发	chat-analyst 完成一个群/人的分析
检查	verify_chat_analyst.py 扫描：信号中提到的每个人 → 该人的 log.md 是否有 [chat-analyst] {date} 条目
通过	退出码=0，流程继续
失败	退出码=1，中止流程，输出缺失列表
记录	append gate-events.log

这个 Gate 让之前的"5 天后才发现缺数据"变成了"当场就报错"。

结果

引入 Gate 体系 1 个月后：

• Visible-but-not-Persisted 事故：0 次（之前平均每周 1 次）
• verify 脚本累计拦截了至少 6 次"AI 试图跳过回写"
• gate-events.log 积累了有意义的审计数据

更重要的是——AI 的行为模式变了。当它"知道"后面有脚本检查时，它在产出阶段就会更注意写入完整性。Gate 不只是拦截错误——它通过"必然被查"的预期，改变了 AI 的执行策略。

反思

适用场景

Gate 机制适用于任何"AI 应该做某事但你无法即时验证"的场景。核心判断标准：

• 操作的结果不在对话里可见（写文件、更新字段、发送消息）
• 遗漏的后果不是即时暴露的（可能几天后才发现）
• AI 有"合理借口"跳过（Token 超了、上下文切换了、觉得"不重要"）

设计要点

1. 验证逻辑必须独立于 AI — 脚本直接查文件系统，不依赖 AI 的任何自报告
2. 失败必须有硬后果 — 中止流程而不是 warning
3. Gate 越早越好 — commit 前 > 流程结束后 > 周回顾时
4. 共享基础设施 — 解析逻辑抽公共库，避免每个 verify 脚本重复造轮子

局限

• 只能验证可检查的事 — "分析质量"无法用 Gate 验证，只有"是否写入"可以
• 维护成本 — 每个新技能都需要配套 verify 脚本
• 不能替代好的设计 — 如果底层架构就是容易遗漏的，Gate 只是在堵窟窿

---