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

问题

先来看看一个真实的案例。

让AI去分析6个群的聊天记录，几秒钟后，它输出了一份漂亮的分析报告——138条信号、团队互动表格、关键洞察，看起来天衣无缝。

结果呢？5天后才发现：

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

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

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

分析

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

原因很简单，这不是偶然的疏忽，而是LLM的

。

AI的"可见性满足偏好"

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

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

至于

——对AI来说，这是一个额外的、不产生即时反馈的动作。做不做，对话质量看起来没区别，用户也看不出差异（直到5天后翻车）。

我给这个反模式取了个名字：

。

AI让你

它做了——但。

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

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

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

原因是：

。它可能90%的时候记得，但10%的时候会"忘记"。而且恰恰是在最复杂、Token消耗最多的场景——最容易"忘"的时候，后果最严重。

换句话说，靠AI的"自觉"来保证数据完整性，就像写代码时依赖新人"记住要部署"来保证发布流程——理论可行，但实战中根本

。

方案：Gate 机制

解法很简单：把"AI应该做的事"变成"AI必须证明做了的事"。

核心设计原则

每个Gate背后是一个Python脚本，直接扫描文件系统——不问AI"你写了吗？"，只问文件系统"有记录吗？"。

 复制代码# 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说什么不重要，文件里有什么才重要。

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

这一点至关重要。如果失败只是warning，AI会学会忽略它，就像开发者忽略lint warning一样。

每次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 积累了有意义的审计数据

更重要的是——

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

反思

适用场景

Gate机制适用于

。核心判断标准：

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

设计要点

1. 验证逻辑必须独立于 AI
   — 脚本直接查文件系统，不依赖AI的任何自报告

2. 失败必须有硬后果
   — 中止流程而不是warning

3. Gate 越早越好
   — commit 前 > 流程结束后 > 周回顾时

4. 共享基础设施
   — 解析逻辑抽公共库，避免每个verify脚本重复造轮子

局限

• 只能验证可检查的事
  — "分析质量"无法用Gate验证，只有"是否写入"可以

• 维护成本
  — 每个新技能都需要配套verify脚本

• 不能替代好的设计
  — 如果底层架构就是容易遗漏的，Gate只是在堵窟窿

---