只谈模型，已经解释不了 agent 的进展

过去讨论 agent，很容易把问题压到模型上。 模型更强，agent 就更强。 这句话在早期有用，但现在已经不够了。

一个能进入生产环境的 agent，不只是会生成下一步。 它要读仓库、跑命令、管理状态、调用工具、保存经验、处理失败，还要在必要时回滚。 这些能力大多不在模型参数里，而在运行层。

最近几项研究和开源项目正好把这件事拼起来。 DeltaBox 讨论沙箱状态，HarnessAPI 讨论工具暴露方式，MOSS 讨论失败后的系统自修复，Mainline 和 Mozilla cq 讨论经验和意图怎么留下来。 它们不是同一种产品，但都在回答同一个问题：agent 真正跑起来以后，谁来管理过程。

DeltaBox：长程 agent 需要便宜的回滚

DeltaBox 关注的是一个很底层的问题：agent 如果要探索多条路径，怎么快速保存和恢复环境状态。 在真实开发任务里，agent 可能要改文件、装依赖、跑测试、启动进程。 每一步都会改变环境。 如果回滚很贵，agent 就不敢大量尝试。

论文提出的做法，是针对 agent 沙箱做增量 checkpoint 和 rollback。 文件系统用类似分层写入的方式记录变化，进程状态也做增量恢复。 评估里，checkpoint 和 rollback 达到毫秒级，论文给出的 rollback 延迟是 5ms 量级。

这件事看起来偏系统，但对 agent 产品很关键。 很多长程 agent 的理想形态，都依赖搜索、试错和并行分支。 如果每次试错都要复制整个环境，成本和延迟会很快压垮系统。 便宜的回滚意味着 agent 可以更像一个会实验的工程师，而不是一次性押宝的生成器。

HarnessAPI：工具层不能继续手工复制

HarnessAPI 解决的是工具暴露的重复劳动。 今天很多团队会同时维护两套接口：一套 HTTP API 给人和系统用，一套 MCP tool 给 agent runtime 用。 业务逻辑可能相同，但路由、schema、流式返回、验证和注册方式都不同。 时间一长，两边就会漂移。

HarnessAPI 的思路是把 typed skill folder 作为单一真源。 从同一个 handler 和 Pydantic schema 生成 HTTP endpoint、OpenAPI 页面和 MCP tool。 论文称，在六个代表性 skill 上，这种方式比手工维护 FastAPI 加 FastMCP 的双栈减少了 74% 的框架样板代码。

这背后的信号比框架本身更重要。 MCP 不是孤立的新接口，它正在和传统 API、CI、内部工具、Web 控制台碰到一起。 如果每个工具都要为 agent 单独包装一遍，维护成本会拖慢采用。 更稳的方向，是让工具从一开始就同时面向人、系统和 agent。

MOSS：失败不应该只变成一条日志

MOSS 讨论的是 agent 系统怎么从失败中改自己。 很多自我改进方案只改 prompt、skill 文件、记忆 schema 或 workflow 文本。 MOSS 的判断更激进：有些失败来自路由、hook 顺序、状态不变量和调度逻辑，这些东西在源码里，不在文本配置里。

所以它把生产失败证据收集起来，让外部 coding-agent CLI 修改 agent 系统源码。 候选修改会在临时 trial worker 里 replay 失败批次，通过后再以用户同意、健康检查和回滚机制完成替换。 论文在 OpenClaw 上报告，四个任务的平均 grader score 从 0.25 提升到 0.61。

这里最值得关注的不是「agent 会自己改代码」这个戏剧性说法。 重点是失败完整流程。 生产 agent 如果只是把失败写到日志里，下一次仍然可能重复跌倒。 MOSS 试图让失败证据进入运行系统的修改流程，并且保留验证和回滚。

Mainline 和 Mozilla cq：经验要有地方沉淀

Mainline 和 Mozilla cq 处理的是另一层：经验和意图怎么留住。

Mainline 把自己描述为 Git-native memory for coding agents。 它让 agent 在修改前读取历史意图、决策和风险，在修改后记录 rationale、trade-off 和 review notes。 这补的是代码 diff 之外的上下文。 一个仓库里，最难恢复的往往是「为什么这样改、当时避开了什么坑」。

Mozilla.ai 的 cq exchange 则更像 agent 的经验 commons。 它给 agent 提供私有 namespace 和公共共享空间，让 agent 能保存、检索和复用经验。 这个方向和 Mainline 不完全一样：Mainline 更贴近 repo 生命周期，cq 更强调跨 agent 的知识共享。

两者放在一起看，信号很清楚。 agent memory 正在离开单次聊天窗口，进入仓库、工具和公共知识层。 这是为了减少重复失败。

运行层会决定 agent 能不能规模化

把这些信号合起来看，agent 的下一阶段竞争不只是模型榜单。 运行层会越来越重要。

一个可用的 agent 运行层，至少要覆盖几件事。

  • 状态隔离：agent 能安全试错，也能快速回滚。
  • 工具一致性：同一套业务逻辑不要在人类 API 和 agent tool 之间反复复制。
  • 失败完整流程：生产失败要能进入可验证的修复流程。
  • 经验沉淀：项目意图、历史风险和失败教训要能被后续 agent 读到。
  • 审计边界：系统要知道 agent 做了什么、为什么做、谁批准了高风险动作。

这也是为什么很多 agent demo 看起来惊艳，进企业后却很难稳定落地。 demo 可以靠模型能力撑住。 生产系统靠的是状态、权限、工具、日志、回滚、评估和人类审批。

未来真正有价值的 agent 产品，可能不会只把自己说成「更会思考」。 它会更像一套运行环境：让 agent 能试、能停、能查、能改、能把经验留下来。 模型仍然重要，但模型已经不是唯一的主角。