2026年6月，Peter Steinberger公布了一组数据：他的系统在30天内消耗了1305088.81美元，处理了超过6030亿个token，在大约100个Codex实例上运转，而负责运营的团队只有三个人。

这不是一次性实验的炫技，而是一个暴露出AI代理所有弱点的真实生产环境。消息一出，绝大多数人的第一反应直奔核心问题——用的是哪个模型？

打开网易新闻 查看精彩图片

这个提问角度没错：更强的模型写代码更利索、指令遵循更可靠、跑偏之后恢复的概率也更高。做AI代理开发，选最顶尖的模型看似是唯一值得关心的决策。但一个月烧掉130万美元、横跨100个Codex实例的体量，让一个更刁钻的问题浮了出来：这套系统的“脚手架”到底是什么？

可惜几乎没人问。而这个被集体忽略的问题，恰恰解释了模型周围的系统如何让长时间任务不至于跑崩、如何支撑数以百计的代理并行工作、如何在经历数千次工具调用和决策之后还能持续产出有效结果。这些能力没有一项是模型自带的，它们全部来自生产级脚手架的设计——这个方向如今有了一份专属命名：代理框架工程。

前沿模型不断推高自主解决问题的边界，进步是实打实的。但生产系统崩溃的原因，往往藏在跑分永远测不出的角落里。一旦一个代理进入长时间运转，执行工具调用，跟其他代理协同，模型本身就不再是决策的全部。它只是更大系统里的一个组件，而从这一刻起，所有假设的前提都变了——你面向的是构建一套生产级代理系统，而不再是跑一次单任务演示。

一言以蔽之：决定AI代理能不能真正上线的，不是模型选型，而是它周围的那套框架。今年发表的两项研究测量的是不同维度的约束，彼此并不矛盾，放在一起揭示了一个规律：框架的质量在脱离模型本身的情况下，依然能独立推动产出。

能把AI代理交付上线的团队，最终都收敛到了同一种设计模式：状态留在模型外部，验证独立于生成，上下文在第一次提示发出之前就已经装载完毕。所以真正该问的问题不是选哪个模型，而是这套框架到底承担了多少本该由它来完成的工作。

模型负责推理，但生产级AI代理框架承担的是完全不同的职责。它是模型外部的运行时，负责协调将推理转化为可靠执行所必需的全部工作。具体包括组装指令和上下文、管理工具的访问和执行、维持持久状态，以及对接模型路由、验证、可观测性等能力。这些职责天然不归模型管，因为它们属于系统工程问题，跟推理本身已经不在一个层面上了。