2026年初，当团队把单轮聊天机器人升级为代理工作流时，第一个崩溃的不是代码——是预算表。
一个简单对话只需一次接口调用。但一个会规划、选工具、执行、评估结果、再综合答案的代理呢？同样的用户请求，现在触发5到20次大语言模型调用，有时更多。
上个月我做了个实验：一个生产环境的调研代理，做网页搜索、摘要、多跳推理。单个用户提示词平均在GPT-5和Claude 4.6 Opus之间往返14次。按GPT-5的输入输出定价，这个"简单问题"花了0.47美元。乘以1000日活，就是每天470美元的计划外支出。
成本到底藏在哪
我对网关日志做了两周埋点，发现了五个黑洞。
第一，规划开销。每个代理循环都以规划步骤开始：模型读取完整对话历史，决定调用什么工具，输出结构化动作。仅这一步，每次迭代就要消耗800到2000个输入词元——而且每次循环都要来一遍。
用Claude 4.6 Opus，输入定价15美元每百万词元，一个迭代5次的代理光规划就要花0.06美元。还没干正事，钱先没了。
第二，上下文窗口膨胀。代理会累积上下文。到第4次迭代，提示词已经包含原始问题、所有先前工具输出、所有先前推理痕迹，以及完整系统提示词。我测过：第1次迭代1200词元，第6次迭代超过18000词元。
最阴险的是这里：每次迭代的成本是超线性增长的，因为上下文随每一步膨胀。
第三，工具调用冗余。代理很不擅长判断什么时候该停。我们的日志显示，23%的代理运行至少有一次冗余工具调用——重新搜索已经找到的东西，或重新阅读已经摘要过的文档。每次冗余调用都是一次带着膨胀上下文的完整大语言模型往返。
第四，降级级联故障。当主模型返回429限流或503超时，代理会重试——往往换另一个模型。但重试会从头重播整个上下文。一次限流事件能让单次代理回合的成本翻三倍。
第五，多模型场景下的词元放大。当代理在GPT-5、Claude 4.6和DeepSeek V3之间路由不同子任务（2026年生产环境的常见配置），每个模型的分词器不同。同样的提示词，在不同模型间词元数差异高达15%——我实测过OpenAI和Anthropic分词器对相同文本的词元数差异。基于单一分词器的成本估算，对其他模型就是错的。
什么才是真正有效的成本控制
烧掉比愿意承认更多的预算后，我们落地了这些措施。
网关层词元计费。别再用应用层日志追踪成本了。应用代码看到请求是在发出之前；网关看到的是实际发出的词元数。我们在Envoy代理上加了自定义过滤器，实时解析响应体，提取`usage.total_tokens`，用Prometheus标签按模型、端点、用户维度打标。
关键洞察：应用层以为一次"搜索"调用花了800词元，网关显示实际发了2400词元——因为重试和重路由隐藏在上游。
上下文压缩协议。第4次迭代后，我们强制对历史记录做有损压缩。具体做法：把先前工具输出交给一个轻量模型（DeepSeek V3，输入0.14美元每百万词元），生成结构化摘要，替换原始输出。
代价：偶尔丢失细节。收益：第6次迭代的提示词从18000词元压到3400词元，该次迭代成本下降81%。
工具调用去重缓存。在网关层给工具输出加语义缓存。代理请求"搜索X"时，我们先查向量数据库看最近5分钟内有没有语义相似的查询。命中率38%，这些命中直接返回缓存结果，不走模型。
缓存失效策略很激进——5分钟——因为代理任务通常有实时性。但即使这么短，日省成本仍达12%。
模型路由的定价感知。别再按"能力"选模型了。我们建了实时成本矩阵：输入价格、输出价格、该任务类型的平均输出长度。Claude 4.6 Opus擅长长上下文推理，但规划步骤用GPT-5-turbo（输入1美元每百万词元）便宜15倍。
路由决策现在基于预估成本=（输入词元×输入单价）+（历史平均输出长度×输出单价）。这个简单公式让平均代理回合成本下降34%。
硬限流与熔断。给单个用户会话设代理迭代上限：8次。超过就返回部分结果，附"任务过于复杂"提示。残酷，但防止了那次让单日账单破4000美元的无限循环事故。
同时给模型端点加熔断：连续3次超时，30秒内降级到备用模型，而非重试同一模型。
正方：代理架构是效率革命
支持方认为，多调用模式本质是计算换质量的理性交易。单次大模型调用处理复杂任务，往往需要超长提示词工程，且输出质量不稳定。拆解为规划-执行-评估的循环，每个子任务用更短的上下文、更专注的模型，整体 token 效率反而更高。
更关键的是，代理架构让"按需调用"成为可能。传统方案里，为覆盖最坏情况，开发者往往在单次调用里塞入冗余上下文。代理模式则按实际路径动态加载信息，理论上避免了过度预加载的浪费。
成本失控不是架构问题，是工程成熟度问题。就像早期云计算，大家也曾惊呼"账单惊吓"，随后 FinOps 实践让云成本变得可预测。代理经济同样需要新的成本治理范式。
反方：这是架构原罪，补丁救不了
反对方指出，超线性成本增长是代理架构的内生缺陷，而非可优化的实现细节。上下文膨胀源于"把历史当记忆"的设计——每次迭代都要重新编码全部历史，人类大脑可不是这么工作的。
工具冗余率23%暴露了更深层问题：当前代理缺乏真正的"认知"，只是模式匹配。它不知道自己已经知道什么，因为每次调用都是无状态重启。这是 Transformer 架构的限制，不是 prompt 工程能修复的。
多模型分词器差异更是荒诞：同一文本在不同模型间15%的词元波动，说明整个行业缺乏基础标准化。在这种碎片化的基础设施上建"成本优化"，好比在流沙上盖房子。
最悲观的判断：当前代理经济建立在补贴之上。GPT-5的定价反映的是规模效应和竞争策略，而非真实计算成本。当模型厂商需要盈利时，现在的"优化"成果可能瞬间归零。
我的判断
双方都有道理，但反方低估了工程迭代的消化能力。
上下文膨胀确实是个麻烦，但"有损压缩"的实验已经证明：80%的上下文价值集中在20%的信息里。关键不是保留全部历史，而是建立有效的信息分层机制——近期细节完整保留，远期转为摘要，超期直接丢弃。这接近人类工作记忆的模式。
23%的冗余调用率听起来吓人，但对比早期检索增强生成系统40%+的检索失败率，已经是可治理的范畴。语义缓存+硬限流的组合，把最坏情况锁死在可控边界内。
真正值得警惕的是"分词器差异"这类基础设施碎片。它不会杀死代理应用，但会持续消耗工程资源——每个多模型系统都要自建换算层。这是行业需要协同解决的公共品问题，单个团队的优化有天花板。
代理成本结构正在重塑产品设计的底层逻辑。过去我们按"功能点"估算开发成本，现在必须引入"推理路径"维度：一个功能背后可能藏着5条或50条模型调用路径，用户体验的微小调整会引发成本数量级差异。
这意味着产品经理需要新的直觉训练。不是"这个能做吗"，而是"这个值得做吗"——在用户体验增益和推理成本之间找平衡点。2026年的技术栈里，成本感知能力正在成为核心 competency。
那些现在就开始建网关层计费、上下文压缩、定价感知路由的团队，不是在修修补补，是在提前适应下一个十年的基础设施范式。账单惊吓是暂时的，但成本治理能力会沉淀为组织资产。
热门跟贴