像 OpenClaw 这样的代理框架正在改变我们构建和运行 AI 模型的方式——将你的机器人放入框架中,让它们发挥更大的作用

经过近四年的研发，耗资数千亿美元打造更智能、更强大的模型之后，人们自然希望看到它们能做的不仅仅是运行聊天机器人。

在这方面，OpenClaw 犹如一股清流，证明了尽管 LLM 存在看似无穷无尽的安全漏洞，但它确实可以用于自动化复杂的任务。自那以后，你可能已经注意到“harness”这个词越来越频繁地出现在描述智能体 AI 框架时，这并非没有道理。

你不需要harness就能与聊天机器人交互——像 Ollama 这样的本地工具可以直接向 LLM 发送 API 调用——但要完成如今的高级任务，它们必不可少。

从表面上看，AI harness只是一小段代码，它封装了 LLM 的 API 端点，负责协调工具调用并管理上下文。OpenClaw、Claude Code、Codex 和 Pi Coding Agent 都是你可能已经熟悉的、以代码为中心的harness示例。

这一切听起来很简单，但模型框架（harness）正在改变我们对一切的思考方式，从训练新模型到大规模构建和运行模型。

LLM推理本身相当笨拙——倒不是模型本身的问题，而是我们与模型交互的方式。如今已成为事实标准的OpenAI兼容API调用是事务性的。在大多数早期聊天机器人中，你发出一个请求，API就会返回一个响应。

相比之下，模型框架会协调这些API调用，将一个请求分解成多个请求。

如果你让一个代码代理构建一个解析日志的应用程序，模型框架可能会发出一个请求来规划流程，另一个请求来查看日志目录，第三个请求来在解释器中生成并执行代码，第四个请求来调试和修复任何错误。这个多步骤循环会一直持续下去，直到工作完成，或者模型框架提前终止循环并请求用户输入。

至少在编码方面，这些模型框架已经足够好用了。事实上，对于代码助手而言，框架（harness）对成功的影响可能比模型本身更大。即使是像 Qwen3.6-27B 这样中小型的 LLM 模型，在搭配 Anthropic 的 Claude Code 或 Cline 等框架时，也展现出了惊人的效果，足以媲美大型付费模型。而且，如果你还不知道的话，Claude Code 可以与任何你喜欢的模型配合使用。

事实上，人们意识到，配备精心设计的框架的小型模型现在可以自动执行复杂的任务，这导致了 Mac Mini 的短缺，因为人工智能爱好者们纷纷争相在 Mac Mini 上自行托管 OpenClaw 和 LLM 模型。

改变我们构建模型的方式

在人工智能蓬勃发展的头两年，训练占据了主导地位。OpenAI、谷歌、微软和其他公司竞相利用尽可能多的数据来构建更智能的模型。

但到 2024 年底，构建更大模型的收益开始递减，因为额外的参数只能带来微小的智能提升。

DeepSeek R1 将“推理”模型和测试时可扩展性带入了主流。需要明确的是，这些模型实际上并不进行推理，而是用时间和令牌来换取更高质量的答案和更低的“胡编乱造”倾向（也就是“产生幻觉”，尽管我们 El Reg 尽量避免将人工智能拟人化）。

它并非首创。OpenAI 的 o1 抢先一步，但 R1 是第一个被广泛采用的开放权重模型，它使用强化学习 (RL) 来教授模型新技能，例如链式推理。

在过去一年中，智能代码助手稳步发展。因此，人们越来越多地使用强化学习（RL）来训练模型，使其能够使用智能体框架提供的工具和资源。

如果你查看 Hugging Face 上最近发布的许多模型，你会发现它们都非常注重智能体工具调用和长上下文推理。如果想要模型与智能体框架有效协作，它必须能够可靠地执行工具调用。而且，由于这些工具调用会返回大量信息，因此模型还需要能够追踪这些信息。

虽然这些特性使得智能体模型更加出色，但它们也需要一套截然不同的硬件。

CPU 成为焦点

运行这些智能体框架所需的计算资源需求旺盛。过去几年，CPU 一直被高端 GPU 和 AI 加速器的光芒所掩盖，如今它们重回聚光灯下。

英特尔至强处理器的销量远超其产能。Meta 公司正竭力从 Arm 和英伟达采购芯片，并在等待到货期间大量租用亚马逊的 Graviton CPU。

这种情况的出现是因为智能体框架无法在 GPU 上运行。即使拥有足够的 CPU 核心来大规模执行这些任务，请求数量的激增也正在重塑我们运行模型的方式。

如果您还没有注意到，推理成本一直在上升。OpenAI 最近提高了 GPT-5.5 的价格，微软将 GitHub Copilot 的定价模式改为完全基于使用量的模式，而 Anthropic 也可能很快会强制 Claude Code 用户升级到价格更高的“Max”订阅服务。

部分原因是需求的增长。不管你喜不喜欢，Vibe 编码正在流行，而且很可能不会消失。然而，我们怀疑部分原因在于这些模型运行在最初为训练而设计的硬件上，而现在却不得不兼顾推理任务。

直到最近一年半，我们才开始看到像英伟达 NVL72 机架这样的推理优化系统上市。AWS、AMD 和其他公司现在正竞相推出各自的机架级计算平台。

但事实证明，即使是这些系统本身也不够用。如果智能体代码框架发出数十个请求，每个请求都会生成数百行代码，那么推理性能就会成为主要瓶颈。在 ChatGPT 的早期阶段，生成令牌的速度可能比普通人阅读的速度还要快就足够了。但如果去掉人机交互，速度就成了关键。

GPU 是计算密度极高的并行处理器，但它们的内存对于这些硬件所承载的那种自回归大型模型来说并不理想。

Groq 和 Cerebras 在人工智能领域迎来了高光时刻

面对这些挑战，基础设施提供商采用了将 GPU 与专用 AI 加速器相结合的新型计算架构。

英伟达收购 Groq 就是一个典型的例子。去年年底，英伟达斥资 200 亿美元获得了这家 AI 芯片制造商的语言处理单元 (LPU) 芯片技术的授权，并挖走了其工程团队。

正如我们当时所写，如果英伟达愿意，它本可以自行构建一个占用大量 SRAM 的解码加速器，但使用别人的产品速度更快。

通过将自身强大的计算 GPU 与 Groq 的高带宽 LPU 相结合，英伟达能够更快地生成更多令牌，理论上可以改善 AI 代理的经济效益。

更高的交互性对于代理工作负载至关重要，因为它们现在可以在相同的时间内处理更多请求，或者对已提供的信息进行更长时间的“思考”。

我们之前在GTC大会上探讨过英伟达基于Groq的新型LPX处理器，以及这种多机架架构背后的市场动态。

AWS也以类似的方式使用着最近公开的Cerebras Systems晶圆级AI加速器，而英特尔目前正与SambaNova合作开发其自身的解耦式计算架构。

风向转变

鉴于这些代理工具需要大量的计算资源，我们很有可能会看到超大规模数据中心通过将部分工作卸载到客户端设备上来降低成本。

由于这些工具的工作方式，像规划这样简单的请求可以在用户本地运行的小型模型上完成。

事实上，谷歌似乎正在这样做。

正如我们本月早些时候报道的那样，谷歌悄悄地在 Chrome 浏览器中加入了一个LLM，它将占用 4 GB 的磁盘空间，并且在运行时可能也会占用同样多的内存。该模型似乎支持一些基本功能，例如“帮我编写代码”、欺诈检测以及其他最近逐渐渗透到我们浏览器中的 AI 辅助功能。

不难想象代码代理也会做类似的事情。可以使用小型本地模型来编写和测试代码片段，而使用更大的云托管模型来调试和纠正错误，从而将大部分负载从数据中心转移到客户端设备上。

要实现这一点，我们需要配备更多高速内存的系统，但鉴于DRAM和NAND闪存的短缺，这带来了一些问题。

虽然可以使用面向用户的代理工具将部分计算负载转移到用户设备上，但许多人仍然希望看到代理能够完成整个部门的工作量。如果将人从流程中移除，这些代理将不再受制于其血肉之躯的主人，并且在拥有足够的计算资源的情况下，其运行速度可以提升几个数量级。

因此，正如个人电脑的兴起并未终结大型机一样，本地人工智能也不太可能在短期内结束投资者对越来越耗电、越来越热的数据中心的痴迷。®

theregister.com