当一个金融Agent在分析年报时，先从报表中提取了"营业收入7,768亿元"，然后在记忆压缩中"亿元"被截断，变成了"7,768"。接下来它用这个数字去计算同比增长率——7,768除以上年的6,023亿元——得到了129%的增长率。
实际增长率是28.9%。但Agent仍然自信地输出了"同比增长129%"。
整个过程中，没有任何机制检测到这个跨步骤的corruption。
这不是一个假设的场景。在构建金融长文档Agent的过程中，我反复遇到这类问题：Agent有时答对，有时答错，而我无法区分"这次对了是因为推理正确"还是"碰巧中间步骤的错误相互抵消了"。
这让我开始思考一个根本性的问题：当前Agent研究的评价体系，是不是问错了问题？
所有人都在问的问题 vs 应该问的问题
2023-2024年的Agent研究——ReAct、Reflexion、AutoGPT、CrewAI——核心追问都是同一个：
"Agent能做什么？能调用更多工具吗？能处理更复杂的任务吗？能推理更长的链路吗？"
这是 Capability-first 的范式。它产出了令人兴奋的demo，但也产出了一个尴尬的现实：在production环境中，没有人敢真正信任这些Agent的输出。
因为我们问错了问题。真正的问题应该是：
"Agent给出答案的过程，是否每一步都可验证、可追溯、可恢复？"
这就是 Reliability-first 的范式。
一个类比：从"能跑"到"可靠"
这个范式转移并非凭空发明——它在计算机科学史上反复发生：
| 领域 | Capability时代 | Reliability时代 | 转折点 |
|---|---|---|---|
| 软件工程 | "代码能跑" | "代码可测试、可审计" | 结构化编程 / TDD |
| 数据库 | "能存取数据" | "ACID事务保证" | 关系数据库理论 |
| 密码学 | "能加密" | "可证明安全" | 形式化证明 |
| AI Agent | "能答对" | "过程可验证" | ← 我们在这里 |
数据库领域的转变最具启发性。早期数据库只关心"能存能取"——直到人们意识到并发写入可能导致数据不一致。ACID（原子性、一致性、隔离性、持久性）不是让数据库"更强大"，而是让数据库"可信赖"。
Agent领域需要自己的"ACID时刻"。
Agent Reliability的四个层次
我将Agent研究的可靠性问题分为四个递进层次：
Level 1: Capability — "Agent能做什么"
2023-2024，已充分研究
代表工作：ReAct、Toolformer、AutoGPT。核心突破是让LLM不只是生成文本，而是能调用工具、检索信息、分步推理。
这个层次已趋于饱和。更多的工具集成、更长的上下文窗口带来的是diminishing returns。
Level 2: Self-Correction — "Agent做的对不对"
2024-2025，正在研究
代表工作：Self-Consistency、CoVe (Chain of Verification)、Reflexion。让Agent能够发现并修正自己的错误。
但这里有一个根本性的循环问题：用同一个LLM验证自己的输出，本质上是circular reasoning。模型不会比自己更聪明。
Level 3: Verifiable Execution — "Agent做的过程可不可信"
2025-2026，正在开创
这是我站的位置。核心问题不是"答案对不对"，而是"从输入到输出的每一步，是否形成了一条不可篡改、可机械验证的执行链"。
关键区别：Self-Correction依赖模型的判断力（可能出错）；Verifiable Execution依赖类型系统和密码学绑定（mechanical guarantee）。
Level 4: Provable Reasoning — "Agent能证明自己为什么这么做"
未来方向
最终形态：Agent不仅给出答案，还生成一份machine-checkable proof——证明答案是从证据经过合法推理步骤得出的。类似于程序验证中的"proof-carrying code"。
Typed ReAct：一个Level 3的协议
在实践中，我设计了一个叫做 Typed ReAct 的协议来解决Level 3的问题。
传统ReAct是一个自由的循环：Thought → Action → Observation，模型自行决定何时停止。这很灵活，但也很脆弱——任何一步的corruption都可以无声地传播到最终输出。
Typed ReAct的核心改变：
每个Action和Observation都有typed contract。 不是自由文本，而是结构化的、有schema约束的数据。这意味着非法的状态转换在类型层面就不可能发生——类似Rust的ownership system在编译时就排除了内存错误。
状态完整性链。 从原始证据的hash，到记忆压缩后的protected signature，到决策指纹，到阶段receipt chain——每一层都绑定到前一层，形成不可篡改的执行轨迹。
Failure as first-class citizen。 不是"正常执行 + exception handling"，而是"每一步都假设会失败，每种失败都有typed分类和对应的minimal-cost recovery策略"。局部失败被隔离在失败的claim内部，不会传播到无关的claims。
六类Corruption：多步Agent执行中的真实故障
在实践中，我系统性地识别了六类corruption pattern：
- Evidence corruption — 记忆压缩丢失了关键信息（数字、单位、否定词、限定条件）
- Stale reference — 后续步骤引用了已被invalidate的早期结论
- Silent override — 验证步骤覆盖了已确认的判定，无审计痕迹
- Calculation contamination — 计算引用了provenance不明的数值
- Partial failure propagation — 一个局部失败扩散到不相关的其他判定
- Completion gate bypass — 状态未满足所有invariant时强行输出答案
这些不是假设——每一类都在360个claim验证中被真实触发和检测过。
Cost-Benefit: Reliability的代价
诚实地说：完整的Typed ReAct比简单的单次调用贵得多。在实验中，完整6阶段pipeline消耗约16M tokens/100题，而单次调用的Fast Path只需1.1M tokens。
但这不意味着Reliability没有价值——它意味着我们需要 Cost-Aware Selective Integrity：
- 低风险操作（常规查询）：跳过完整验证，信任缓存结果
- 中等风险（多步推理）：验证provenance chain
- 高风险（金融决策、法律判断）：完整integrity chain + 独立验证
- 关键决策（医疗诊断）：形式化证明 + 人工审核
这就是Reliability和Cost之间的 Pareto frontier ——不是"全都验证"或"全都不验证"，而是根据stakes动态选择验证深度。
3-5年研究展望
我认为Agent Reliability是一个至少持续5年的研究方向，以下是我看到的几条值得深入的路线：
方向一：Typed Integrity Protocol的形式化
将typed state protocol从工程实现提升为可证明的形式化性质。核心问题：在什么条件下，typed integrity chain能保证N步执行后的最终输出与原始证据保持一致性？
方向二：Selective Integrity的决策理论
何时需要full chain验证，何时可以跳过？这本质上是一个决策理论问题——在给定的风险分布和cost constraint下，什么是最优的验证策略？
方向三：跨域Reliability Benchmark
当前没有一个benchmark评估Agent的"过程可靠性"而非"答案正确性"。我们需要一个覆盖金融、法律、医疗等regulated domain的benchmark，评估维度包括corruption detection rate、recovery cost和integrity violation frequency。
方向四：Reliability-Capability Pareto分析
大规模实证研究：在什么任务、什么风险级别下，Reliability投入产生正ROI？什么时候"答对就行"已经够好？
方向五：Self-Certifying Agents
最终目标：Agent不仅生成答案，还生成一份可独立验证的"推理证书"——第三方可以无需重跑整个过程就验证输出的合法性。
不只是技术问题
Capability → Reliability的转移不只是一个技术研究方向——它反映了一个更深层的认知转变：
当我们说"信任一个Agent"，我们到底在信任什么？
如果信任的是"它大部分时候答对"——那是Capability问题，用更大的模型、更多的数据可以改善。
如果信任的是"它的推理过程每一步都可追溯、可验证、出错时可恢复"——那是Reliability问题，需要的不是更强的模型，而是更好的协议。
在金融审计、医疗诊断、法律判决这些场景中，后者才是deployment的真正门槛。
也许几年后回看，2025-2026正是Agent研究从"它能做什么"转向"我们凭什么信它"的转折点。就像数据库从文件系统走向ACID，Agent正在从demo走向production——而production需要的不是更多的Capability，是可以被验证的Reliability。