为什么代理式 AI 需要开放式推理堆栈

“目前，为企业提供服务的每个 AI 实验室都在亏钱。他们对此心知肚明，却也是有意为之。”

这是我收件箱里一篇文章的开场白。就在同一周，三个数字清晰地揭示，为什么开放式推理已不再是可选项，而是必经之路。

一位开发人员利用开源编码代理和直连 API 密钥，花了一个周末构建了一个简单的笔记应用。单页、单功能，成本 50 美元。第二天，每月 20 美元的订阅就能提供 50 倍的令牌数量。

我们推理团队的一名工程师在两天内通过开放权重模型消耗了三亿个令牌，而同样的工作通过专有 API 完成，则需要花费数千美元。

低廉的开发成本和订阅价格揭示了当前的“补贴”现象，令牌消耗量与专有 API 的成本对比则指明了出路。而我们之所以需要这条出路，原因在于代理。

定价模式正在转变

前沿模型提供商做了一件了不起的事：他们让数百万开发人员能够以两年前无法想象的低价，使用世界一流的 AI。这种可及性引爆了 AI 的采用狂潮，但也催生了一种在当前费率下可能难以为继的经济结构。

“AI 盈利了吗？”网站追踪着 AI 行业的整体财务状况。数据显示，目前 AI 公司的支出大约是其收入的 195%。一位参与讨论的贡献者算了一笔账：按 2024 年美元等值计算，十年来 AI 资本支出总额约为整个美国 州际公路系统造价的三倍。这样的投资规模最终会体现在服务定价上。

这种转变的迹象已经显现。 有报道称，一些大型企业正在重新考虑 AI 编码工具许可证，因为基于令牌的计费取代了固定费率订阅，每位工程师的成本已达到每月 500 至 2,000 美元。较新的前沿模型在基准测试方面实现了小幅提升，但每个任务消耗的令牌数增加了 10-25%。GPU 供应已经锁定到未来三至四年，多个 GPU 云提供商的产能也已售罄。

这些绝非是对提供商的批评。他们正在构建未来，并积极通过低价策略来加速普及。令牌的单位成本可能会继续下降，Gartner 预计到 2030 年将降低 90%。但正如同一份分析所指出的，代理式工作负载在每项任务上消耗的令牌量显著增多，因此尽管单位成本更低，但企业推理总支出预计将上升。 高盛预测，到 2030 年，令牌消耗量将增长 24 倍。因此，企业在做未来三到五年的规划时，应该为总成本的上升而非下降做好准备。在这一背景下，运行于自管式基础架构的开源模型就像放压阀一样，有助于在消耗量激增时保持 AI 的可及性。

图 1： 代理式推理成本悖论。每个令牌的成本下降了 90%（Gartner），但总消耗量增长了 24 倍（高盛），因此尽管单位成本更低，但企业总支出将上升。

代理颠覆了格局

订阅定价是按人类的打字速度，为人类设计的。代理生成的 API 调用量要高出几个数量级，现有的任何定价模型都无法应对这种需求。

一位 OpenClaw 贡献者在一个月内消耗了价值 130 万美元的 OpenAI API 令牌。这相当于三个人运维的约 100 个 Codex 实例发起了 760 万个请求，共消耗 6,030 亿个令牌。仅仅一天，该帐户就产生了 19,985.84 美元的支出。

黄仁勋表示，与传统模型的使用方式相比，代理令牌消耗量增长了大约 1,000 倍。Marc Andreessen 在 Latent Space 播客中透露，他身边的人每天在运行代理的 Claude 令牌上花费 1,000 美元，而每个完全部署的个人代理每天的潜在需求高达 5,000 到 10,000 美元。即使价格降低 10 倍，每天还是需要 100 美元。“这仍然远远超出人们的支付能力。”

一些提供商已经不得不限制第三方代理框架在固定费率订阅下运行，因为计算需求超出了定价模式所能承受的范围。固定费率定价与自主代理工作负载在结构上完全不匹配。

成本仅仅是问题的一部分。代理式工作负载还有一些技术需求，而专有 API 在设计之初就从未打算满足这些需求。

API 碎片化。代理式 API 领域充斥着相互竞争的标准，包括 Chat Completions（OpenAI 最初的无状态格式）、Responses API（OpenAI 较新的有状态格式，具有内置工具和模型上下文协议集成）、Messages API（Anthropic 的格式）和 Interactions API（Google 的代理式协议）等。每种 API 在工具调用、状态管理和推理机制上都有不同的处理方式，每个代理框架则会选择不同的标准。

此外，各个模型系列还会将相同的工具调用包装在完全不同的标签中。将 get_weather(city="Seattle") 发送给五个模型，会生成五种不同的格式：Llama 使用带 <|python_tag|> 的 Python 语法，Mistral 使用带 JSON 数组的 [TOOL_CALLS]，Gemma 使用 <tool_code>标签，Hermes 则使用 <tool_call>XML。推理引擎需要为每个模型系列配备单独的解析器。

工具调用。在专有 API 的背后，您只能获得提供商提供的解析器，无法对它进行自定义。如果模型输出的是 Python 语法，而不是它的训练格式，您也无法进行修复。您只能被动接受。

模型路由。单次代理运行会生成多个异构子任务，有些需要深度推理，有些需要快速分类，还有些需要代码生成。将这些任务路由到不同的模型，需要掌控服务层。而在单一供应商的 API 背后，所有任务都会发往同一个模型，并按相同价格计费。

上下文工程。在多轮交互中管理输入模型的内容，是目前最具杠杆效应的优化手段。一个精心调校的上下文管道可以将令牌使用量减少 60-80%，同时提高输出质量。但是，有效的上下文工程需要能够在推理级别访问模型的行为，因为您需要衡量模型实际关注的内容，识别哪些上下文令牌有助于提高输出质量，并根据真实的注意力模式而非猜测来调整摘要和检索策略。

熔断机制。如果无法控制推理层，就无法在模型服务器级别实现按代理分配预算、异常检测或自动关闭。作为失控循环的亲历者，我可以告诉您，提供商不会来救您。

经济学家称之为“杰文斯悖论”。威廉姆·斯坦利·杰文斯在 1865 年注意到了这一规律：随着燃煤发动机效率的提升，煤炭总消耗量反而增加了。AI 令牌正沿着同样的轨迹发展。每一次效率提升都会解锁新的用例，这些用例消耗的资源比节省下来的资源还要多。那些实现了每令牌产出优化的公司，消耗的 AI 资源只会更多，而非更少。

开源模型已准备好迎接代理式工作

我前面提到，我们的推理团队使用开放权重模型，在两天内处理了三亿个令牌。Nemotron 3 Super、Gemma 4 和 Qwen 3.6，全部运行在红帽 AI 推理堆栈上。其结果足以胜任拉取请求审查、初版功能实现和定向调查任务，减轻了原本要交由前沿模型处理的工作，并避免了令牌成本的累积。

其中的成本差距并非微不足道。 在消费级 Blackwell GPU 上的基准测试表明，一块价值 500 美元的 GPU 运行开放权重模型，每天可处理 3,000 万个令牌。以这个量级计算，相较于通过预算级 API 提供商（每百万个令牌约 0.20 美元）处理相同工作负载，硬件成本可在三个月内收回。若是与前沿 API 定价相比，投资回报期更是缩短至数天。

一位研究人员使用每个令牌仅激活 40 亿参数的模型构建了一个编码代理，在基准测试中获得了 87% 的得分。相比之下，使用 140 亿参数模型的代理得分为 75%。区别不在于模型本身，而在于复合工具和错误反馈循环。 真正扛起重任的是代理框架，而非模型规模。

要让开源模型在代理场景中发挥出色表现，需要真正的工程能力，而这正是开源所能实现的。 近期一项演示展示了 Gemma 4 与 OpenCode 和 Claude Code 搭配运行的实际效果，包括自定义聊天模板调整、对每个模型系列的工具调用解析器进行调优，以及跨多个 API 标准处理提示格式。40 亿参数模型所需的处理方式与 260 亿参数量化版不同，而 260 亿参数量化版的处理方式又与 310 亿参数模型不同。

正是这类工作，弥合了基准测试性能与实际代理性能之间的鸿沟。它涉及在聊天补全、消息和响应 API 之间进行转换，以及使用模糊逻辑来解析模型输出，因为模型有时会漏掉其工具调用的起始令牌，或者受代理框架系统提示的影响而生成出人意料的语法。

这项工作正在 vLLM 的上游、模型供应商聊天模板和代理框架错误报告中推进，并且只能在开源环境中实现。使用专有推理服务器时，您无法提交聊天模板修复、调优工具调用解析器，甚至无法观察代理输出失败的原因。而在开源环境中，每一次修复都惠及所有用户，每一次解析器升级都是永久性的。这种上游集成工作使开放权重模型能够可靠地处理整个服务堆栈中的代理式工作负载，这正是红帽 AI 的核心关注点之一。

代理式推理堆栈

要在企业级规模下实现代理式推理，需要八个层协同工作，每个层都与其他所有层进行交互。

图 2：代理式推理堆栈，从顶层的代理和代理框架开始，依次经过 API 转换、网关、护栏、解耦式服务、模型服务器配置、推理引擎，直至底层的硬件。红色边框突出显示了大多数代理兼容性工作所在的两个层。虚线沙盒边界包围了代理层，该层的代码执行和安全控制最为严格。

通过零散的开源项目把这些层拼凑组装起来，在技术上是可行的，但运维成本高昂。像红帽 AI 这样的自管式推理平台的价值在于，这些层被集成到一个经过测试且受支持的堆栈中，直接运行在您的基础架构上。这意味着您的数据永远不会离开安全边界，并且您可以控制升级周期、模型选择和路由策略。

代理式 API 层

API 多样性问题确实存在。代理框架使用 Chat Completions、Responses、Messages API 或 Interactions API，而下层的模型服务器不一定支持所有这些 API。代理式 API 层位于代理框架和基础架构之间，有助于弥合这一鸿沟。OGX（以前称为 Llama Stack）等项目本身提供代理式 API 的开放实现：Chat Completions、Responses API、Messages API 和 Interactions API，以及向量存储、文件管理和工具执行等补充功能，所有这些都运行在您使用的任何模型服务层之上。

尽管某些 API 具有先发优势，但目前还没有哪个 API 标准占据绝对领先地位。关键在于拥有所有这些标准的开源实现，这样您就可以根据需要，随时将任何代理框架与任何模型进行匹配。当转换层是开放的，它会保留完整的工具调用契约，让您准确地了解您的请求发生了什么。而当专有提供商处理转换时，您永远不知道丢失了什么内容。

llm-d：扩展代理式推理

单实例 vLLM 适用于一名工程师运行代理的情况，但如果一百名工程师同时使用相同的模型，它便难以招架。llm-d 是一个解耦式服务层，可将推理过程拆分为独立的预填充和解码阶段，使它们能够在不同的硬件上独立扩展。对于大量短请求与长推理链交错出现的代理式工作负载，这种架构变得日益关键。

护栏与沙盒

内容安全也是这个堆栈的组成部分，且必须具备代理感知能力。作为中间代理层运行的护栏框架需要保留完整的代理式 API 契约，包括工具定义、工具选择和推理参数，否则它们可能会悄无声息地削弱代理的运行表现。

有效的代理式护栏还需要访问简单的输入/输出文本过滤无法提供的推理级数据，例如：用于评估模型思维链在最终输出之前是否包含不安全步骤的推理轨迹、用于验证调用的工具和参数是否符合策略的工具调用参数、用于检测幻觉风险和低置信度输出的令牌级对数概率（logprobs），以及用于审计追踪和合规日志记录的生成元数据。这也是推理层应该开放的另一个原因。只能看到进出文本的护栏不足以满足代理式工作负载的需求。 

如果您的护栏代理是一个剥离了工具调用参数的黑箱，那么当 AI 代理出现故障时，您将无法诊断原因。而开源护栏（如 NVIDIA NeMo Guardrails 非代理 /v1/guardrails/checks 端点）能够在不违反代理式 API 契约的情况下实施内容安全策略。

沙盒是堆栈的另一个组成部分。代理会执行代码、写入文件并调用工具。 纵深防御需要分层隔离机制，包括容器级限制、网络策略、文件系统限制和运行时强制执行。仅仅将代理放到容器中是不够的。在堆栈图中，沙盒边界包裹着代理和代理框架，因为那里是可能发生任意代码执行的地方，也是安全控制必须最严密的环节。

开源为何制胜

对于一个八层的堆栈，如果看不到其中一半层在做什么，就无法对它进行测试；如果无法查看解析器，就无法调试失败的工具调用；如果护栏代理悄无声息地丢弃了 AI 代理所需的参数，就无法确保安全防护。整个堆栈的耦合度太高，任何一层都不能是黑箱。将这些层集成起来、加固到一起，让企业不必自行组装堆栈，正是红帽 AI 旨在解决的问题。

抛开技术论证，开放式推理之所以不可避免，还有更深层次的结构性原因，而不仅仅是成本原因。

图 3：适用于代理式工作负载的开放式推理与专有 API 的对比。专有 API 的优势在于设置简便性和前沿模型质量。开放式推理的优势则体现在代理式工作负载在生产环境中依赖的七项能力上：模型路由、工具调用调试、域自定义、按代理分配预算、数据驻留、供应商独立性和推理级护栏。

教育普惠加速了整个领域的发展。开源带来了两样东西：免费软件和免费知识。DeepSeek R1 便是极佳的例证。在更广泛的社区成功复现推理能力之前，专有模型已将这一能力垄断了数月之久。而当 DeepSeek 公开代码和论文后，每个主要实验室都在三个月内具备了推理能力。知识扩散效应比模型本身更有价值。应用于代理式推理时，每一次工具调用解析器修复、每一项聊天模板改进、每一个代理框架补丁，都会成为在整个生态系统中持续累积的共享基础架构。

信任离不开透明度。并非每个企业组织都愿意通过少数几个云模型提供商来路由其所有数据和工作流。对一些企业组织来说，存在严格的合规问题。医疗卫生和金融等行业在数据隐私和驻留方面需要满足严格的监管要求。对于另一些企业组织来说，这是一种战略选择，可以避免供应商锁定并保留对其知识产权的完整所有权。

利用开源，企业组织可以选择在自己的安全边界内按自己的方式运行模型，同时全面了解系统的运作方式。对于受监管的行业、政府和安全敏感型工作负载而言，这是硬性要求。监管也在朝着同样的方向发展：《欧盟 AI 法案》的透明度义务自 2026 年 8 月起强制执行，要求提供涵盖模型架构、训练流程和性能特征的技术文档。已经发布这些信息的开源模型将享受封闭模型无法获得的豁免资格。

自定义需要拥有权重。在封闭式 API 的背后，每个企业组织都运行相同的模型。而当您在自有基础架构上拥有权重时，便可以针对您的领域、内部工具和代码库约定进行微调，无需将专有数据发送到外部。医疗机构可以针对临床术语和病历格式进行微调；法律团队可以让模型适配司法管辖区特定的语言和合同结构；金融机构则可以基于其专有风险模型和合规框架进行训练。对于代理式工作负载而言，这就是通用代理与一个已经理解自有系统运作方式的代理之间的区别。

开源创造了生态系统引力。当硬件供应商投资开源推理软件时，更易获取的模型会推动更广泛的硬件采用。对 vLLM（推理运行时）优化的投资以及对开源服务堆栈的改进，使每个 GPU 都能更好地胜任代理式工作负载的处理，并实现硬件的可重用性。其结果是形成一个良性循环，使开源软件的改进在整个生态系统中不断叠加放大。

下一阶段将青睐分布式模型。正在兴起的模式是“以共享上下文为中心”，即众多模型在共享的知识图谱和上下文存储上工作。这将焦点从单一的大型模型，转移到了由智能代理框架协调、由多个专业化模型组成的生态系统上。您未必需要一个什么都能做的模型；更多时候，您需要的是许多专业化模型，每个模型各司其职，作为一个复合系统协同工作。这种架构本质上更加开放、更具分布性。

诸如 Pi 和 OpenClaw 等新兴代理架构已经采用了这种构建方式。它们的设计极为精简，通常包含一个大语言模型（LLM）、一个 bash shell、一个文件系统、markdown 状态文件和一个 cron 循环。状态存在于文件而非权重中，因此您可以替换 LLM，而不会丢失代理的记忆。这些代理适用于任何模型，无论是封闭式还是开放式。但是，如果从模型权重到服务基础架构的整个堆栈都保持开放，那么每一层结构上的优势就会整合到一起：您可以针对自己的领域进行微调，在您控制的模型之间路由，使用自有工具进行观测，并在不中断其余层的情况下替换任何层。正因为如此，开放式推理成了代理式 AI 的天然基础，而红帽 AI 正是为这一基础提供动力的平台。 

如何做好准备

在价格变革到来之前，当下需要完成三大准备工作。

图 4： 为开放代理式推理做好准备的三项措施，每项措施均使用红帽 AI 堆栈中的特定工具。这张时间表显示了从 API 可移植性过渡到完全自助管理代理式基础架构的 12 个月提升期。

构建与代理框架无关的系统。如何设计代理框架和代理，与运行哪个模型同样重要，甚至更为重要。如果您的代理被硬编码到单一提供商的 API，那么在定价变革到来之前，您就已经把自己锁死了。应该针对模型和 API 可移植性进行构建。这正是通过红帽 AI 提供的 OGX 等项目的用武之地，它们提供了跨 Chat Completions、Responses、Messages 和 Interactions API 的开放转换层，无论代理底层采用哪种模型或提供商，都可保持可移植性。

在托管式基础架构上自托管工作负载。一块运行量化版 Gemma 4 或 Qwen 模型的GPU，已经足以处理拉取请求审查、文档生成和代码摘要等任务。将 API 订阅用于那些真正需要前沿推理能力、或者前沿模型仍具有明显质量优势的工作负载，其余工作负载则自托管在您控制的基础架构上。自管式推理平台可以处理模型服务、扩展、路由和可观测性方面的运维复杂性，让团队专注于构建代理，而非维护服务堆栈。 

随着开源模型不断缩小与前沿模型的能力差距，您能够自托管的工作负载只会日益增多。现在就开始着手构建，当开源模型覆盖整个堆栈时，您就能拥有所需的运维就绪度。关于模型路由的研究表明，将大部分请求导向较小或自托管的模型，仅将复杂任务升级给前沿 API 处理，可以在质量损失极小的情况下将成本降低 60-85%。

跨代理堆栈进行端到端测试。一个通过基准测试的模型，仍可能因为代理框架提示错误、工具解析器误读输出或网关路由了错误任务而失败。测试“模型-代理框架-配置”三元组，才是正确的做法。

此外，还要将令牌预算纳入您的流程，包括每个代理的限制、每项功能的归因、异常检测等。 MLflow Tracing 已经是红帽 AI 堆栈的一部分，能够捕获提示、推理步骤、工具调用和令牌成本，并完全兼容 OpenTelemetry。您需要提前设置好预算警报，防患于未然。

为未来而构建

硬件通常会贬值，用于开放式推理的 GPU 则恰恰相反。芯片本身没有变化，但运行在其上的软件在不断改进。vLLM 中更出色的批处理和注意力内核，让同一块芯片每秒能吞吐更多令牌。量化技术的突破，让曾经需要 80GB 内存的模型，在质量相当的情况下压缩至 20GB。解耦式服务可以拆分工作负载，使同一集群能够处理更多并发代理。三年前购买的企业级 GPU，如今能产生的有用推理量比刚安装那天还要多，因为围绕它的开源堆栈在不断改进。

这种复合效应是贯穿整个论述的核心脉络。开放式工具调用解析器让每个人都受益更多；开放式聊天模板一次性修复兼容性问题，永久生效；保留代理式 API 契约的开放式护栏可保护每一次部署，而不仅仅是某一家供应商的客户；开放解耦式服务可在您已有的硬件上进行扩展。

这正是开源 AI 平台的使命所在。它不仅仅是为模型提供服务，更是在您自己的基础架构上拥有完整的代理式推理堆栈——从在代理框架和模型之间转换的 API 层，到负责路由和计量的网关，再到服务引擎及其运行的硬件，共同构成我们所说的“从底层硬件到代理”堆栈。您的数据始终留在安全边界内；模型在您选择的位置运行；成本是可预测的，因为您掌控着每一层。每一层都是开放、可调试的，每一项改进都会共享。

如今的模型已足够强大（并且日益精进），堆栈正在成形，经济效益也清晰可见。问题不在于开放代理式推理是否会发生（它已然发生），而在于当账单到来的那一天，您是否已做好准备。