可观测性三件套的生产复盘——Gate、Audit、Correction 是怎么转起来的

开篇：昨晚 21:00，审计抓到一个漏网之鱼

2026-08-24 21:00，分发任务照常跑。三方比对（本地成稿 ∩ 发布队列 ∩ 系列认知表）发现：2 篇当天刚写完的文章已经躺在公众号草稿箱，海外平台一个字都没发。不是没人记得，是发布队列里压根没有登记。

这个漏网之鱼不是人抓到的，是审计环节抓到的——三件套里的第二件，在没人盯梢的时候替我把账查了。

上一篇《Golden Dataset：让Agent回归测试成为CI门禁》讲到门禁。这篇回答门禁之后的问题：门禁拦下来的错、审计记下来的账、纠正沉淀下来的规则，在生产里到底怎么配合？ 三件套不是架构图上的三个框，是每天在跑的三个机制。这篇是它们的生产复盘，每一条都有真实记录。

---

一、三件套的定位：发现问题、记录问题、固化方案

先把三件套的职责钉死：

• Gate 门禁：发现问题——每次输出 100% 全检，不通过就不允许交付
• Audit 审计：记录问题——每次调用、每次拦截、每次发布，全部入账
• Correction 纠正：固化方案——错误入账后提炼根因，物理化到脚本和门禁，再不犯

F1 讲了测轨迹不测答案，F2 讲了校准裁判，F3 讲了 golden dataset 挂 CI 门禁。三件套是这三篇的工程底座：没有 Gate，错误没人拦；没有 Audit，错误没人记；没有 Correction，记了也白记。

---

二、Gate 在生产里：11 道门，拦下来过真东西

Gate 在我这里不是"人工审核"的电子化，是一段真实的 shell 脚本，挂在每次任务输出前：gate-check.sh。

# gate-check.sh 骨架（真实脚本的简化版）
# 门0: STANDING.md 合规检查
# 门1: 任务上下文存在性检查
# 门2: 技能文件存在性检查
# 门3: 规则执行证据 — 全量 verify 脚本
run_verify "$HARNESS_HOME/verify/quote_format.py" "规则A+规则B格式/用词" || \
  block "⛔ 门3/8: 报价格式/用词不合规 — 请按 rules/rule_A_quoting_format.md + rule_B_quoting_terms.md 修订。"
# 门4: 任务未超时（2小时）
# 门5: 报告质量 + 产物溯源标记
# 门6: Evals golden 集回归验证
# 门7: 场景结构化输出校验
# 门8: 邮件草稿质量
# 门9: audit_fail 自动改进门禁
# 门10: quote_validation_missing 自动改进门禁
# 门11: 入口收敛验证

11 道门，每道门都是一个独立脚本，只读真实文件证据，不读 LLM 自述。靠自觉的门禁不是门禁，是摆设。

门禁在生产里真拦过东西，三个真实的例子：

例 1：格式门。 报价格式不合规时，门 3 直接 block 输出，提示按规则文件修订。拦下的是"看起来能交但格式全错"的产物。

例 2：配图门。 有篇文章的配图引用路径里带了空格，markdown 解析把路径拼错，上传直接失败。这个坑被记进错误账本后，图片引用规范改成"绝对路径、括号内禁止空格"，后续文章再没犯过。

例 3：回归门。 F3 那次真实回归，v1 旧版通过率 100%，v2 改了一行逻辑后通过率掉到 50%，门禁直接打回。改动还没上线，错误就被拦住了。

门禁还有一个防死循环的机制：同一任务最多重试 3 次，3 次全失败就放行输出，让系统提示人工介入。门禁的目的是拦截错误，不是把系统卡死。

---

三、Audit 在生产里：账本上记的是什么

Gate 拦下错误只是第一步。错误如果不被记录，下次还是同一个错。Audit 做的事就是：每次拦截、每次调用、每次发布，都留一条账。

审计入账是物理的：

# 每次门禁拦截，自动写一条审计日志
python3 /root/hermes-harness/pipeline/audit_log.py "gate:block" "$task_type:$task_id" "blocked" "$msg"
# 每次门禁通过，也写一条（采样防过大）
python3 /root/hermes-harness/pipeline/audit_log.py "gate:pass" "${TASK_TYPE:-}:${TASK_ID:-}" "success" ""

账本上不只有拦截记录。生产里我每天留四种账：

账本	记什么	真实例子
审计日志	每次 gate:pass / gate:block	门9 audit_fail 连续 block 被记录
发布快照	草稿箱逐篇核验：content_len、图数、imgur 残留	08-25 实测 14 篇，B6 content_len=25658 未截断
运行留痕	每次 cron 运行的完整输出，带时间戳归档	08-24 21:00 分发报告全文可查
三方比对	本地成稿 ∩ 发布队列 ∩ 系列认知表	抓到 H5/H6 漏登记

审计最值钱的一次是 08-24 晚上：三张表一对，发现 2 篇新文章没进发布队列。如果没这张账，漏发要等到读者问"怎么没更新"才会被发现。审计的价值不在日志多全，在出事的时候你翻得出来。

---

四、Correction 在生产里：错误怎么变成规则

Gate 拦下来、Audit 记下来，还不够。Correction 才是让系统"长记性"的环节：把单次错误变成永久规则。

我的纠正闭环是五步：

① 事故或拦截发生 → ② error-ledger 入账 → ③ 修复带验证 → ④ 规则回灌 → ⑤ 门禁免疫

error-ledger 已经沉淀了 31 条错误，每条四段式：时间、场景、根因、解法。但入账只是开始，关键是第 ④ 步——规则回灌，物理化到系统里。2026-08-25 的 CHANGELOG v6.8.1 一次进了三个维护补丁，正好是三个真实的纠正闭环：

补丁	事故	修复方式	物理化到哪
①	产物绕过流水线直接交付	新增入口收敛验证：先写草稿文件→verify→通过才交付	verify/entry_convergence.py + gate 门11
②	报告无溯源标记，疑似绕过生成管线	报告头部强制带【机制链注入】标记，无标记=拒绝	verify/provenance_marker.py + gate 门5
③	门9 误报：业务 warning 被判成审计失败，持续 block 全系统输出	只认 failed/error/exception/critical/blocked 才算失败	verify/audit_fail.py 修复 + CHANGELOG 记录

第 ③ 条值得多说一句：那次门禁自己出了 bug，把 warning 误判成失败，导致系统每 30 分钟被 block 一次。修复方式不是"改改就好"，而是明确失败判定的边界——warning 是业务提示，不是审计失败。这就是纠正沉淀的本质：把模糊的"感觉不对"变成精确的"什么算失败"。

纠正还有一个纪律：上一轮的教训，直接用于本轮。 08-24 晚 Hashnode 发布报 "Draft not found"，按早前 E1 的教训没有盲目重试，等 60 秒后用标题计数独立核验 count=1，判定成功。同一个坑，第二次就不会踩。

---

进阶思考：三件套的本质，是把事故变成数据

跑了一个多月，我重新理解了"可观测性"这三个字。

可观测性的本质不是"看得见"，是改得动。日志堆得再多，如果看完不能变成一次修复、一条规则，那只是自我安慰。三件套的真正价值，是把一次事故拆成三个可操作的环节：Gate 说"这里错了"，Audit 说"这次记下了"，Correction 说"下次不会了"。

这也是为什么三件套缺一不可。Gate 不拦，Audit 没得记；Audit 不记，Correction 没有输入；Correction 不回灌，Gate 永远拦同一个错。闭环一断，系统就开始带病运行。

把视角拉高一点：这就是 Loop Engineering 在 Agent 系统上的物理形态。错误从"事故"变成"数据"，从"责任"变成"改进的输入"。F3 讲回归的本质是记忆——golden set 每加一条，系统多一条"不二过"的记忆；三件套把这条记忆变成了完整的生产流程：发生 → 记录 → 修复 → 免疫。

系统不会因为一次修复就完美，但它会因为我们把每一次错误都变成规则，而越跑越稳。

---

结尾

今天你学到的是：三件套在生产里怎么配合——Gate 的 11 道门负责拦，Audit 的账本负责记，Correction 的闭环负责把错误变成规则。拦下来的、记下来的、修出来的，全部物理化，不靠 LLM 记忆。

行动号召很简单，今晚 30 分钟就能给你的 Agent 装齐：

# ① 门禁：gate-check.sh 挂到任务输出前（门0-门11 按需裁剪）
# ② 审计：每次拦截/通过都写一条 audit_log
python3 pipeline/audit_log.py "gate:block" "$task_type:$task_id" "blocked" "$msg"
# ③ 纠正：新建 error-ledger.md，四段式入账：时间/场景/根因/解法

然后挑一个最近犯过的错，走完五步闭环，把它物理化成一条 verify 脚本。你会第一次感受到：同样的错误，第二次还没发生就被系统拦住了。

下一篇，我们把视角从"一个 Agent 怎么变稳"拉到"多个 Agent 怎么协作"——《多 Agent 不是默认选项——「Avoid multi-agent early」的生产共识与实践》：为什么顶级团队的建议是"先别上多 Agent"？单 Agent 和群体的边界到底在哪？

关于作者：魏无记，AI 和数智化实践者。专注 Agent 工程化与 Loop Engineering 研究以及数智化转型。公众号持续更新 Agent 工程化实战系列和数智化转型相关知识实践——每篇都是保姆级教程照做就行。