AI News HubLIVE
站内改写4 分钟阅读

补贴结束:使用工具的代理实际成本

GitHub Copilot于6月1日开始对所有计划实施基于使用量的计费,揭示了代理式工作流的真实成本。本文分析了令牌消耗、工具设计对成本的影响,并提出了优化提示词和输出格式的策略,强调了将成本控制纳入平台架构的重要性。

来源O'Reilly AI & ML Radar作者: Bennie Haelen

6月1日,GitHub Copilot对所有计划启用了基于使用量的计费,这一变化迅速引发了开发者的强烈反应。虽然专业版计划仍保持10美元月费,但增加了每月AI信用额度池。每个信用额度售价1美分,根据使用的模型和处理的令牌(包括输入、输出和缓存令牌)消耗。对于运行前沿模型的密集代理会话,这种计费方式与固定的订阅模式截然不同。

但这一新闻的核心并非计费本身。代理工作流的底层成本在6月1日并没有实际变化——令牌一直在消耗,循环一直在运行,工具调用一直在扩展上下文。真正变化的是,计量表变得可见了。在固定费率下被默默补贴的工作负载,现在显示为逐项账单。

令牌去向

要理解为何账单如此沉重,可以比较两种看似相似但计费方式截然不同的场景。聊天补全接近单次交易:你发送提示,模型回复答案,大致为输入和输出各付费一次。但使用工具的代理截然不同。代理并非回答问题,而是通过循环逐步逼近目标:它推理任务、调用工具、读取结果、再次推理、调用另一个工具,直到认为任务完成。

每次循环迭代都包含容易忽略的成本。在许多代理框架中,每次轮次都会携带大量累积的上下文:先前的消息、工具描述、检索的文件和工具结果。即使部分上下文被缓存、总结或剪枝,系统仍需执行计量工作来保留足够状态供下一步决策。你最终想要的答案只是所支付费用的一小部分。循环本身就是账单。

这就是代理成本不能优雅扩展的原因。它随着轮次数扩展,而轮次数又随代理需要多少发现而扩展,这进一步取决于请求的模糊性和携带的不相关上下文的量。一个清晰、范围明确的任务可能在三个轮次内完成,而同一个任务以开放式问题提出可能会漫游15个轮次,每个轮次都携带之前所有成本。在固定费率下,这种差异不可见;在基于使用量的计费下,这决定了是一次小交互还是一次昂贵交互。

工具设计成为成本模型的一部分

我最近写过关于模型上下文协议服务器的隐性税收:臃肿的工具目录如何悄悄降低模型路由到正确工具的能力。冗长的描述、重叠的职责和模糊的参数使模型工作更困难、选择更差。那个论点关乎准确性。计费变化为此类臃肿增加了第二张账单,这次以美元计。

工具目录通常部分内容会通过代理循环携带。一个用三句紧凑句子描述的工具和一个用三段冗长段落描述的工具可能都能工作,但后者每次加载代理时都要在上下文中支付租金。乘以40个工具的目录和运行十二轮次的工作流,冗长工具设计的成本就不再是舍入误差。工具设计已经是一门正确性学科,现在也成了成本纪律。同样的审计在提高路由准确性的同时,也收紧了账单。

提示纪律的局限

有个层面是个人用户可以控制的,因为节省效果真实且立竿见影。两种模式最为重要,我已将它们传授给一个大型医疗组织试点项目中的工程师。它们不是魔法,而是让代理避免不必要发现循环的方法。

第一种模式关于输入。将提示代理的方式从宽泛问题改为简短需求。例如,“查看就诊数据并告诉我发现了什么”迫使代理进入发现模式,消耗轮次弄清楚你的意图,而每个轮次都携带全部上下文。相比之下,一个提前明确指定项目、表名、过滤日期字段、所需输出形状和排除项的提示能大大压缩循环。例如:“使用精选临床项目和银区就诊表,显示2025年每个月的就诊总数,使用admission_date_time进行包含,按月返回一行,按时间排序。”第二个提示简化了循环,代理在第一个轮次就获得所需信息,直接工作而非反复询问。

实践中,这种差异不仅是润色。模糊版本迫使代理发现数据模型、推断日期语义、选择聚合方式和决定显示格式。具体版本将任务转化为有边界的查询。这种差异体现在准确性、延迟和成本上。

第二种模式关于输出,这是大多数人忽略的杠杆。在中间步骤请求纯文本或Markdown,只在最终确认的可交付成果时使用富HTML格式。格式化输出生成成本高,且需求会变化。如果一开始就要求一份精美的HTML报告,然后改变筛选条件,你将为重新生成所有布局支付完整输出令牌费用,通常不止一次。更经济的做法是先用文本验证数据,只在最后格式化。

这些模式有效,但也有上限。它们将成本控制的所有负担放在用户身上,且只在每个用户每次提示都保持纪律时才有效。一旦有人回到“告诉我发现了什么”,节省就蒸发,团队和意外账单之间只隔着一个预算上限,而它只会在超额发生后报告。

成本是治理问题,而非预算问题

这种脆弱性是真正的教训。预算上限是事后限制而非控制。它可以阻止失控,但只告诉你超支了多少而非原因,也无法让下一次运行更便宜。将成本视为预算问题让你永远对计量表做出反应,而将其视为架构问题则能一次性构建节省,无需依赖每个人的良好行为。

这意味着重要的控制属于平台,而非单个提示。这里的平台并非代理本身(开发人员日常使用的编码助手或聊天客户端),也非模型或其下的路由器。而是位于代理之上的控制平面,组织在此强制执行策略、访问、可观测性以及现在的成本控制,覆盖所有代理和模型。一个让IT能看到谁在做什么以及能安装哪些功能的管理控制台是其早期窄实例。一个将规划发送给廉价模型的路由器是其中的一个功能。平台是规则存放处,代理消费规则而非设定规则。平台应根据任务路由模型,用廉价模型进行规划,保留前沿模型用于值得其价格的工作。它应限制循环,要求代理在固定迭代次数后检查。它应限制工具结果负载,防止粗心查询将一百万行转储到上下文窗口。它应默认中间工作使用纯文本,使廉价路径成为阻力最小的路径,而非用户必须记住的事情。

这些控制中的每一个用户都可以手动近似,而平台可以简单保证。这正是我在数据访问背景下反复强调的原则:安全行为不能依赖键盘前的人记住规则。提示指导行为,而护栏让更便宜、更安全的行为成为默认。成本治理就是作为控制平面的护栏,带有美元符号,在你已经执行谁可以看哪些行的同一层强制执行。

模式,而非供应商

将本文仅视为GitHub的故事将是错误的。GitHub是当前示例,因为其变化可见且近期,但基于使用量的代理工作计费是许多AI工具的发展方向。底层的经济逻辑类似:代理工作负载将单次答案转化为模型调用、工具调用和上下文管理的循环。一旦工作负载从自动补全转向自主,固定费率补贴迟早会面临压力。

将6月1日视为定价事件的组织会优化几个提示、抱怨并继续前进,直到下一个供应商改变计量。而将其视为架构信号的组织会将成本控制下沉到平台中,无论哪个供应商在计数哪类令牌,这些控制都有效。这是更持久的立场。这个月的账单没有变大,它变得诚实了,而诚实的账单正是你可以设计应对的。