Cloudflare 的一次“反直觉”判断：Eval++ 可能比模型本身更重要

大多数人还在争论模型参数和推理速度时，Cloudflare 的工程师却抛出一个更激进的观点：真正限制 AI Agent 的，不是模型，而是计算原语本身。Eval++，被他们称为“下一代 compute primitive”，正在悄悄改变 AI 系统该怎么构建。

最反直觉的判断：AI Agent 的瓶颈不在模型

在这场对话一开始，Sunil Pai 和 Matt Carrie 就把话题引向了一个让很多从业者不太舒服的方向：模型已经足够强了，真正拖慢 AI Agent 落地的，是计算形态。

他们的出发点并不是 LLM，而是 Cloudflare 的 Durable Objects——一种“可寻址、长期存在”的计算单元。最初它并不是为 AI 设计的，但在实践中，他们发现：这恰好是构建 AI Agent 所缺的那块积木。

一句话总结他们的核心判断：“如果计算单元本身不适合长期状态、地址化访问和动态执行，再聪明的模型也只能写 Demo。”这也是 Eval++ 被称为下一代 compute primitive 的背景。

从 Durable Objects 到 Eval++：为什么‘可寻址’这么关键

视频里反复被提到一个词：addressable（可寻址）。这不是炫技，而是痛点。

传统的无状态计算，非常适合 API 和短请求，但 AI Agent 恰恰相反：它们需要记忆、需要上下文、需要在不同时间点被“再次唤醒”。Durable Objects 的特性，让每个 Agent 都像一个有固定地址的实体，而不是一次性脚本。

在过去一年里，团队在这个基础上“堆了很多东西”，其中就包括 Eval++。它并不是一个新模型，而是一种更适合 AI Agent 的执行和评估方式——把‘运行代码’、‘评估结果’和‘状态管理’变成一等公民。

Code Mode、MCP 与 Dynamic Workers：开始像系统工程了

当讨论进入 code mode，现场的气氛明显变了。这不再是概念层面的畅想，而是工程实践。

一个关键点是：用户生成代码。无论是 Agent 写代码、改代码，还是运行代码，背后都需要一种既安全又灵活的执行环境。Dynamic Workers 正是在这里出现的——它让计算不再是提前静态定义的，而是可以根据需要动态生成。

他们甚至直言：借助这种方式，‘某种程度上修复了 MCP’。这句话本身就很耐人寻味，暗示着过去的 Agent 协议或执行模型，在真实系统中并不好用，而新的计算原语正在填坑。

真正的隐性收益：少烧 Token，少写胶水代码

有一个细节很容易被忽略，却戳中了所有做 AI 应用的人：Token。

当系统层做得不对时，最直接的后果就是‘烧 Token’——模型被迫反复思考、重复解释、模拟状态。Sunil 在对话里半开玩笑地说，如果不是这些工具，自己早就在疯狂烧 Token 了。

Eval++、Dynamic Workers 这类东西，本质上是在把原本应该由系统承担的工作，从模型身上拿走。这意味着更低的成本、更可控的行为，以及——对工程师来说——更少的胶水代码。

总结

这场对话真正值得 AI 从业者反复琢磨的，不是某个新名词，而是一种思路转变：AI Agent 不只是模型能力的延伸，而是系统工程的产物。

如果你正在做 Agent、自动化工具或复杂 AI 工作流，Eval++ 代表的计算原语值得关注。下一个阶段的竞争，可能不在于谁的模型更大，而在于谁的计算单元，更适合“长期活着”的 AI。一个值得思考的问题是：你的系统，有没有把本该由计算层解决的问题，全部甩给了模型？

关键词： Eval++， AI Agent， Compute Primitive， Dynamic Workers， Token 成本

事实核查备注： 需要核查：Eval++ 的准确定位是否被官方定义为 compute primitive；Durable Objects 与 AI Agent 的关系是否为原话表述；‘修复 MCP’是否为演讲中的原意；Token 成本相关表述是否为玩笑还是明确结论