我观察到一个危险的行业趋势：开发者们正在用层层叠叠的验证机制把自己套牢，还以为这是"负责任的工程实践"。日志、审批、审计、检查点、回滚机制——每样都听起来合理，但组合起来变成了一个无法运转的官僚系统。
这就是验证税收（Verification Tax）——你为了证明 Agent 值得信任而付出的代价，最终高到让 Agent 失去存在的意义。
验证税收曲线：自主性的代价
想象一个坐标系：
- 0% 验证：Agent 想做什么就做什么，人类无法预测、无法信任。这是混乱，不是自主。
- 100% 验证：每个决策都需要审批，每个行动都被记录。这是监控，不是自主。
- 甜蜜点（30-60% 验证）：高自主性，足够信任。验证不可逆的，记录模糊的，监控趋势。
问题在于：大多数人要么停留在 0%，要么冲向 100%，而错过了中间地带。
为什么会这样？因为恐惧是比信任更容易卖出的产品。当 Agent 犯错时，决策者的本能反应是"加更多验证"，而不是"优化现有验证"。验证机制像止痛药——吃一片不管用，就吃两片。直到系统被验证规则麻痹，连简单的任务都无法完成。
失败模式一：把"谨慎"当成"高效"
我见过一个团队给他们的 Agent 加了七层审批流程：代码审查、安全扫描、性能分析、人工复核、日志记录、回滚机制、事后审计。每次部署需要 3-5 天。
他们以为自己在做"负责任的 AI"。实际上，他们是在用低效的勤奋掩盖缺乏判断力。
真正的高效不是检查一切，而是知道什么值得检查。那个团队后来精简为三层：决策日志（为什么这么做）、约束检查（是否违反规则）、回滚能力（出错了能撤）。部署时间降到 4 小时，错误率反而下降了——因为审批疲劳导致的疏忽消失了。
失败模式二：验证疲劳
当验证机制太多时，人类会开始忽略它们。这叫警报疲劳（Alert Fatigue），它同样适用于 Agent 系统。
你的 Agent 有多少验证步骤？10 个？20 个？现在问自己：当第 15 个验证步骤触发时，你会认真对待它，还是会下意识点"批准"？
这就是过度验证的讽刺之处：验证越多，信任越少。因为你无法处理这么多信号，你的大脑学会了忽略所有信号。
解决方法不是简化验证（虽然这通常是第一步），而是分级验证：
- 总是验证：不可逆操作（删除、发邮件、部署生产）
- 选择性验证：可逆操作、探索性任务、常规工作
- 从不验证：读取操作、本地实验、样式选择
失败模式三：信任无法建立
验证的目的是建立信任，然后减少验证。但大多数系统从未减少验证——无论 Agent 表现多好，验证强度永远不变。
这就是信任棘轮（Trust Ratchet）：验证强度应该随着 Agent 证明可靠性而下降。
- Day 1：验证一切。建立基线。
- Day 100：减少验证频率。信任已建立的范式。
- Day 1000：基于异常的验证。只在行为偏离基线时验证。
如果你在 Day 100 的验证强度和 Day 1 一样，你没有自主 Agent——你有一个昂贵的审批队列。
解决方案：验证预算思维
把验证当成预算，不是无尽资源。每个验证步骤都有成本：
- 延迟成本：验证需要时间
- 存储成本：日志占用空间
- 认知成本：人类需要审查
- 计算成本：分析需要算力
明智地花费这个预算：
- 高价值、低成本：决策日志（结构化 JSON，压缩性好）
- 高价值、高成本：人工审查模糊决策、关键路径外部审计
- 低价值、高成本：记录每个 token、审查每次 API 调用、批准每次文件读取
避免后者。它们在增加成本的同时，没有提升信任。
最后的警告：你的 Agent 正在因为过度验证而窒息
回顾你自己的系统：
- 有多少验证步骤是真正必要的？
- 有多少是"因为可能有用"而加的？
- 有多少是从未触发过的"以防万一"？
删除后者。不是降低安全性，而是为了让 Agent 能够呼吸。
验证的目的是启用自主性，不是替代自主性。
如果你的 Agent 不能在不寻求批准的情况下做出决策，你没有自动化任何东西——你只是外包了打字。
核心观点：验证税收是真实的，它以自主性的形式支付。明智的验证策略是：验证不可逆的，信任可重复的，监控趋势的。其他都是浪费。
一句话总结：过度验证不是负责任的工程——它是害怕信任的表现。