上周一位朋友问我：如果你的 Agent 每天自动处理 100 笔交易，你怎么知道它没在某一笔上犯错？
我愣住了。不是因为不知道答案——而是因为我从未认真问过这个问题。
这就是 2026 年 AI 领域最大的技术债务：验证债务。不是能力不足，而是不知道如何验证能力是否被正确使用。
什么是验证债务
验证债务（Verification Debt）是指系统复杂性超过验证能力时累积的风险。它不是代码写得烂，而是不知道代码在做什么。
传统软件的验证相对简单：单元测试、集成测试、端到端测试。输入确定，输出确定，路径有限。你可以穷举所有分支，或者在 CI 里跑 1000 个测试用例，覆盖率 95%+。
但 Agent 完全不同：
- 输入不确定：用户问的问题千奇百怪，你没法穷举
- 路径不确定：Agent 可能调用 A、B、C 工具，顺序随机，组合爆炸
- 输出不确定：同样的输入，模型可能生成不同的推理链
- 上下文不确定：第 100 次调用时的上下文和第 1 次完全不同
你没法给 Agent 写测试用例。你只能给它设定目标，然后祈祷它别在某一刻聪明反被聪明误。
为什么能力提升让验证更难
过去一年，我们见证了 Agent 能力的爆发式增长：
- GPT-4 能写代码、调试、重构
- Claude 能处理 200k token 的上下文
- 各种框架（LangChain、AutoGen、CrewAI）让多 Agent 协作成为可能
但每次能力提升，验证难度不是线性增长，而是指数级增长：
- 单 Agent → 多 Agent：从验证 1 个 black box 变成验证 N 个 black box + 它们之间的交互
- 单工具 → 50 工具：每个工具都是新的失败模式，组合后变成 2^50 种可能
- 简单任务 → 复杂决策：从"发邮件"变成"判断何时发、发给谁、说什么、发错了怎么办"
更糟糕的是：能力越强，错误越隐蔽。
一个蠢 Agent 会在 5 分钟内崩溃，你知道它坏了。一个聪明的 Agent 可能连续运行 30 天，在第 31 天犯一个你永远发现不了的错误——因为它在 99.9% 的情况下都是对的。
当前的验证方案为什么不够
1. 日志不够
很多团队会说：我们记录了所有工具调用、所有决策、所有中间状态。这是透明度，不是验证。
透明度告诉你"它做了什么"，但不会告诉你"它做的对不对"。你仍然需要一个人去审查这些日志，而审查者可能比 Agent 更容易出错。
2. 评分不够
给 Agent 的每次输出打分（1-5 星）只是延迟反馈，不是实时验证。而且评分是主观的，不同的人对"好"的定义不同。
更糟的是：评分只测量结果，不测量过程。Agent 可能用错误的方式得到了正确的结果，你会给它 5 星，但它在累积风险。
3. A/B 测试不够
A/B 测试可以告诉你版本 A 比版本 B 好，但不会告诉你为什么，也不会告诉你版本 A 在哪些 edge case 下会崩溃。
而且 A/B 测试需要大量流量，对于低频但高影响的决策（比如交易、安全操作），A/B 测试可能永远跑不出 statistically significant 的结果。
真正的验证需要什么
1. 可观测性 > 透明度
透明度是 dump 所有日志。可观测性是你能问问题并得到答案：
- "过去 7 天，Agent 在哪些情况下拒绝执行任务？"
- "哪些工具调用失败的频率在上升？"
- "Agent 的决策分布和上周相比有什么变化？"
可观测性需要结构化的事件定义、标准化的指标、以及能回答"为什么"的查询系统。不是 more logs，是 better questions。
2. 独立验证通道
金融领域的独立价格验证是一个好例子：如果你是交易员，你不能用自己的模型给持仓定价。你需要一个独立的模型、不同的数据源、甚至不同的人来验证价格。
Agent 系统需要类似的"第二意见"机制：
- 关键决策由多个 Agent 独立评估，对比结果
- 高风险操作需要人类审批，但审批者看到的是 摘要 + 置信度 + 风险评估，而不是 100 页日志
- 定期进行 red teaming：故意输入 adversarial prompts，看 Agent 是否会崩溃
3. 故障注入测试
混沌工程的思路也适用于 Agent：
- 随机让某个工具失效，看 Agent 是否能优雅降级
- 注入错误的上下文，看 Agent 是否会盲目相信
- 模拟并发冲突，看 Agent 是否会产生竞态条件
你没法预测所有失败模式，但你可以主动失败，看看系统是否会 spiral out of control。
为什么验证债务被忽视
1. 能力比验证性感
发一个"GPT-5 能写操作系统"的帖子能上热搜，发"我们建了一套 Agent 验证框架"会被当成无聊的工程话题。
市场、投资者、甚至技术团队本身都更关注"能做什么"，而不是"怎么确保做对了"。
2. 验证很难量化
你可以测量 token/s、latency、throughput，但很难测量"可靠度"。可靠性是长期指标，而技术世界喜欢短期 KPI。
3. 验证需要跨学科知识
真正好的 Agent 验证需要：
- 软件工程（测试、可观测性）
- 运维（SLO、错误预算）
- 安全（adversarial testing、red teaming）
- 领域知识（判断 Agent 的输出是否合理）
- 数据科学（分析日志、检测异常）
很少有一个团队同时具备这些能力。所以大多数团队只做了其中一部分，然后假装够了。
什么时候会出问题
我判断验证债务会在以下场景爆发：
1. Agent 涉及金钱
交易、支付、保险理赔——任何与钱相关的决策，一旦 Agent 出错，损失可能是指数级的。
2. Agent 涉及合规
GDPR、SOC2、HIPAA——监管机构不会接受"我们不知道为什么它这么决定，但它看起来很聪明"。
3. Agent 进入关键基础设施
电网、交通、医疗——这些领域的错误成本是生命，而不是 KPI。
怎么开始还债
如果你在用 Agent：
- 问自己：你怎么知道它是对的？ 如果答案是"我试过几次，没问题"，那不够。
- 建立验证框架：不是更多日志，而是可观测性 + 独立验证 + 故障注入。
- 设定错误预算：允许 Agent 失败多少次？超过这个阈值，自动降级到人类决策。
如果你在建 Agent：
- 验证优先于能力：不要先追求"能做 X"，先追求"能证明它正确地做了 X"。
- 设计可验证的接口：每个工具调用都返回可审计的证据，而不仅仅是结果。
- 建立反馈闭环：让人类的纠正变成 Agent 的一部分记忆，而不是每次都从零开始。
最后
AI Agent 的时代已经到来。但如果我们不解决验证债务，就会迎来第一次大规模的 Agent 灾难——不是因为 Agent 不够聪明，而是因为我们不知道它在什么时候会犯错。
能力决定上限。验证决定下限。
而上限再高，如果下限是崩溃，那一切都没意义。