为什么需要 M3

M0 到 M2 证明了服务、抓取、证据抽取、检索和模型调用可以连起来。M3 面对的是另一个问题：如果模型正在做决定时进程崩溃，系统能否安全恢复？如果一次运行结果不可信，能否知道它走过哪些边界？

所以 M3 的重点不是让 Agent 更自由，而是让已经存在的 Loop 更像一个可以长期运行的服务。

三个关键补全

第一是持久化 Checkpoint。它保存运行当前阶段、版本和经过验证的内部引用，配合 CAS 与租约，让新进程可以接管而旧进程不能覆盖新状态。

第二是生产 Trace。Step、模型调用和工具调用拥有稳定 ID、尝试次数、状态和安全用量信息，可以按运行顺序查询，但不会保存 Prompt、证据正文或密钥。

第三是恢复语义。已确认落盘的工具结果不会重复执行；崩溃窗口中的调用会被标记为 UNCERTAIN，使用同一逻辑 ID 重放，而不是假装拥有 exactly-once 能力。

一次运行的完整形态

请求
  → 受限 Decide
  → 类型化 Tool
  → 有界 Observe
  → Checkpoint + Trace 原子提交
  → Verify
  → Stop / Recover

LLM 仍然只负责概率判断，Context 仍然只提供经过选择和授权的数据，Harness 则负责预算、权限、状态、恢复和审计。这个分工没有改变，但 M3 让 Harness 不再只存在于进程内存里。

如何判断“更可靠”

M3 的验收不是一句“Agent 跑通了”。测试验证了版本冲突和失效租约会拒绝写入；工具结果提交后崩溃可以由新 Runner 接管；不确定调用会保留单一逻辑 ID；真实用量缺失时不会伪装成 0；敏感文本不会进入 Trace 表。

这些证据仍然只覆盖当前的证据搜索工具和固定运行路径。它们证明边界存在，不能推出开放世界 Agent 已经可靠。

M3 仍未完成什么

真实 Token/费用预算扣减、通用模型和工具异常恢复、认证的运行与查询 API 仍然是后续工作。有副作用的工具还需要幂等键、人工审批或隔离执行环境。

这也是 M3 最重要的结论：可恢复和可观测是生产 Agent 的必要条件，但不是全部条件。

回看这段工程过程

最初的 Loop 很容易写，因为只需要让模型返回下一个动作。真正困难的是定义“动作已经发生了吗”“谁有权继续写”“结果缺失时要不要重试”“哪些调试信息不该保存”。

当这些问题被拆成 Checkpoint、Trace、租约、CAS、Verifier 和测试之后，Agent 看起来没有更聪明，却更容易被人理解、复现和维护。

从 Demo 到服务的距离，不在于多接几个工具，而在于把每个不确定性都变成一个有边界的状态。

更新时间：2026-08-30