AI Agent令牌成本优化：三招降低大模型Token开销

你的AI Agent账单里，绝大部分是输入token——而且花在“重读”上。每一轮对话，编码Agent都会把完整的对话记录重新发给模型；加上仓库探索和工具输出，一次会话就可能携带十万token的上下文，被反复以全价阅读。原文作者在单台机器上运行一整队过夜编码Agent，直接感受到这种成本压力。他们总结了三个已在生产环境运行的杠杆：用便宜模型先做摘要、把昂贵推理性放在V模型两端、以及用代理按价格路由请求。

需要提前说明的是，作者坦承这些机制经过了测量，但端到端节省并未核算——文中的算术基于公开价格和自有日志，只能作为示意，而非真实账单。

杠杆一：先检索，让便宜模型做摘要

给前沿模型提供上下文最贵的方式，是直接塞入原始搜索结果；最便宜的方式，是让小模型先读一遍。

这个模式的流程是：本地搜索工具从代码库或知识库中检索候选片段；在这些片段进入GPT-6或Fable级会话之前，一个低成本模型先将其合成为紧凑答案，并附上可回溯到源头的确定性引用。昂贵模型收到的是摘要和少量可能需要重开的引用，而不是十段近乎重复的摘录。

作者使用开源工具terraphim-grep，它通过精选的知识图谱同义词库解析查询词，再对本地匹配排序。--answer参数在充分性检查要求时请求生成答案，--force-rlm强制走合成路径；只有选中的片段会离开本机，经OpenRouter发往DeepSeek^广告-flash级模型。还有--search-only模式，彻底禁用合成并跳过构建LLM客户端，这样即使环境里残留API key，也不会产生一次网络调用。

在他们的验证运行中，原始片段内容为505字符，带来源位置的证据为1108字符，合成答案文本为440字符——前沿模型收到的上下文约为原本的40%，且附带可按需重开的引用。

这里有两个诚实的注意点。第一，测的是字符而非token，CLI不暴露token用量，所以这个比例只能看作方向性参考。第二，收益取决于交接形态：完整答案对象连同全部十个引用测量为1918字符，若原样转发，节省就蒸发了。只传合成结果加上验证所需的引用，别的不传。

杠杆二：把昂贵推理放在V模型两端

第二个杠杆不是工具，而是生命周期决策：让模型价格匹配工作阶段。

作者把Agent工作组织成V模型。左侧问“该建什么”（研究、设计、规格）；右侧问“建对了吗”（评审、验证、评判小组）。中间漫长的部分（实现、写测试、机械验证循环）是token燃烧最多的地方，恰恰也是最不需要深度推理的部分。

于是模型被分置：

• 两端使用昂贵模型。 研究合成、架构决策和最终评审留在高推理通道，因为糟糕的计划或走过场的评审，代价高于省下的token。
• 中间使用快速交付模型。 实现和测试循环跑在grok、MiniMax或Kimi highspeed通道上，走固定费率订阅。过夜Agent在opencode-go订阅模型上执行；评判小组跑在Kimi K2.5上，约每9秒完成一次评审，与人类评审员的判定一致率达到90%。

算术值得做一次。按公开API价格，一个示意性工作负载（1亿输入token、2000万输出token）全部跑在前沿模型上花费800美元；将其中80%路由到中端模型，同样的token量成本为480美元，省40%，模型数量不变。这是按公开价格的反事实推算，不是实测账单，但节省的形态是真实的：你并非少付token，而是为不需要前沿推理的阶段支付更低的单价。

问题在于纪律。放任自流的话，Agent会从头到尾用同一个模型。阶段必须显式定义，所以这个杠杆只在结构化生命周期内有效，自由运行的会话不行。

V模型（V-Model）源自系统工程与软件工程，是一种将开发阶段与验证阶段一一对应的生命周期模型。左侧下行分支依次为需求分析、系统设计、架构设计、详细设计，右侧上行分支依次为单元测试、集成测试、系统测试、验收测试，整体呈V字形。其核心思想是：每一个开发阶段都应有对应的验证阶段，且验证标准应在开发阶段就定义好。在本文语境中，作者借用V模型强调：左侧的“该建什么”和右侧的“建对了吗”都需要深度推理，而V字底部的实现与测试循环虽然token消耗最大，却对推理深度要求最低，因此适合用便宜快速的模型执行。

杠杆三：在供应商前面放一个代理

第三个杠杆让便宜路线成为默认：在Agent和每个供应商之间放一个LLM代理，按请求内容或各通道当前速度进行路由。

作者的代理运行在localhost，暴露OpenAI和Anthropic兼容端点，决定每个请求的去向：

• 关键词路由。 代理用Aho-Corasick字符串匹配（微秒级开销，与知识图谱使用同一个crate）将提示词内容与markdown分类法匹配。一个写着“think step by step about this architecture”的提示词会被路由到think链，不管客户端请求的是什么模型ID。在他们的日志中，三个连续请求在三种场景下落到三个不同供应商，对客户端完全透明。
• 速度与价格路由。 候选通道可按首token时间排序，或按成本等级排序：免费优先，然后订阅，最后按量计费。每个场景可以自行选择延迟优先还是价格优先。Agent因限流空等的闲置时间是真实成本，只是以小时而非token计价。
• 回退链让便宜通道变得安全。 便宜供应商确实存在可靠性缺口：无声的API格式变更、未文档化的容量错误、从欧洲访问时更高的延迟。管道分隔的回退链意味着一个供应商挂掉，请求就转到下一个目标。作者通过故意的故障注入（在/etc/hosts中把主供应商域名指向localhost）来验证，而不是信任配置。

有一个让他们意外的注意点：提示缓存是按模型而非按会话的。在真实编码会话中测量，会话中途切换模型时，82%的情况缓存读取量跌至此前值的10%以下：一个温热的107000 token前缀变成110000 token的未缓存输入，同样文本的价格约为缓存价的十倍。因此节省的模式是按会话或按场景路由，而不是每轮随机切。为任务选定一条通道并留在上面。

Aho-Corasick算法是一种多模式字符串匹配算法，由Alfred Aho和Margaret Corasick于1975年提出。它通过构建有限状态自动机（类似字典树加失败指针），能在一次扫描中同时匹配多个关键词，时间复杂度为O(n + m + k)，其中n为文本长度、m为模式总长度、k为匹配数，与模式数量无关。这使得它非常适合在请求路由场景中做低开销的关键词识别：代理只需微秒级时间就能判断提示词中是否包含“think step by step”等触发词，从而决定路由目标。相比逐个正则匹配，Aho-Corasick在模式较多时优势明显，且实现简单、无需外部依赖。

提示缓存（Prompt Caching）是多家LLM供应商提供的一项优化机制：当请求的前缀（如系统提示、长对话历史）与之前某次请求完全一致时，供应商可以复用已计算的键值缓存（KV Cache），避免重复计算，从而降低延迟和输入token费用。通常缓存命中的token价格仅为未缓存token的十分之一左右，但缓存有有效期（如几分钟到几小时）且按模型隔离。这意味着同一段对话历史在不同模型之间无法共享缓存。本文中82%的缓存读取量崩塌，正是因为会话中途切换模型导致新模型需要从头计算整个前缀，使原本廉价的缓存token变成全价输入token。

作者不声称什么

token节省没有端到端测量。合成示例测的是字符不是token；模型组合示例是按公开价格的算术，不是发票；82%的缓存崩塌数字来自一个运维者的会话日志，不是集群基准。诚实的指标是“每个被接受任务的质量调整成本”，而他们仍在构建上报所需的测量设施。

他们能声称的是机制：在昂贵模型阅读前先过滤的检索、把推理预算花在判断所在之处的生命周期、以及在转发请求前先为通道定价的代理。这些都不需要信任某个基准，而且三者今天都在运行。

相关组件有完整文章：terraphim-grep与角色感知搜索、AI Agent的V模型。grep工具位于terraphim-clients仓库。