API 成本优化首先是可核对的工程问题：一次任务到底发了多少请求，哪些重复读取可以避免，换模型后是否仍能完成工作。本文以虚构的社区活动报名系统为例：Agent 修改候补名单逻辑、生成维护说明并运行回归。我们把账单监控、代码索引和多模型分流分别设计，示例不是已经测得的收益，也不承诺统一的节省比例。
先定义成本与完成的口径
记录任务 ID、请求 ID、供应商、模型版本、时间、输入与输出用量、缓存相关用量、重试次数、状态与耗时。价格表保留币种、生效时间和计费单位，不把每千 token 与每百万 token 混算。请求级估算、平台使用量与最终账单是三种证据，应定期对账而不是直接画等号。未知价格或缺失用量单独列为待核实，不能默认零费用。
对同一组任务比较总成本、完成率、回查次数和延迟。便宜的一次请求如果导致更多重试、错误交付或人工复查，未必是便宜的任务。缓存写入、缓存读取、普通输入、输出与其他服务费用应按实际平台口径分开，不能将所有输入乘以同一个价格。本文不提供当前报价，采用前核对目标供应商官方价格与账户条款。
开始处理前检索了 GitHub 的开源方法，参考 BerriAI 的 LiteLLM 文档仓库理解缓存用量与统一计量的边界。已有网关可优先利用现成记录；新引入网关必须评估接口兼容、维护、许可证、凭据和数据去向，不能为了省一项费用增加难以审计的代理。本例先给独立于具体库的采集与验收方案，不下载运行原文列出的包。
场景一：把调用账本与预算控制接起来
在应用实际发请求的边界采集事件，明确 SDK 包装器、装饰器或 HTTP 钩子是否覆盖流式、异步与重试。若一处包装器和网关都记账，用请求关联去重，保留来源；同一任务的多次真实尝试不能误删成重复记录。流式响应中途断开时，用量可能不完整，应标记缺失并等待供应商记录补齐。
成本报告先按任务、环境与模型分组，区分开发测试和线上业务。看总量、失败尝试及异常突增，再查看某条调用；默认不保存完整提示、业务数据或密钥。为追踪候补名单修复，可以只记变更任务标识和获准的元数据，确需内容样本时另设脱敏与访问范围。日志工具获得了数据并不意味着可以把这些数据转发到所有监控服务。
预算上限需要执行层配合。调用前估算并预留本次可接受费用，限制最大输出、请求次数、持续时间和并发；完成后用实际可得用量校正。并发任务共用额度时必须协调预留，否则每个任务都看见余额充足，合计仍会超额。计费延迟和已在途请求意味着软限额不等于绝对不会超支，要明确停止的是新调用还是全部可取消工作。
给自动重试设置错误类别、最大次数、退避与总期限。持续认证失败不能靠无限重试解决，价格数据失效时也不能默默继续大量调用。达到阈值后停止后续计划，记录未完成步骤，保留恢复检查点。不要为了维持“自动完成”而自动购买额度或改用未授权账户。
验收夹具包含：正常完成、一次失败后成功、重复事件、缺失流式用量、两个并发任务争用余额。检查报告与原始请求记录的对应关系。实操请求可以写：“为候补名单任务生成逐请求成本表，报告估算与账单差异；先在虚构事件上验证超限拒绝新请求，不动生产密钥与预算。”交付账本、差异表、控制状态和测试证据。
场景二：用可失效的代码索引减少重复读取
索引不是只建一次就永久可信。先定义允许索引的仓库与路径，排除密钥、个人数据、依赖缓存和生成文件。若使用远程嵌入服务，代码片段可能离开本机，需核对具体去向和授权；“索引存本地”不代表整个构建过程离线。明确嵌入模型、索引格式、提交或文件版本、更新时间以及删除策略。
先用文件名、关键词与符号定位报名状态转换，再按需读相关函数和测试。语义检索可补充同义表达，AST 符号查找适用于被解析器支持的语言；混合搜索不是保证每次都比原生命令好。记录查询、候选文件、版本和选入理由，拿已知相关函数与易混淆文件做小型检索基准。
文件变更后增量更新，重命名与删除要同时反映到索引中；切分支时检查版本，不把另一个分支的代码当现状。检索结果提供的是定位线索，关键代码在修改前回到当前文件核验。缓存的旧设计决定也可能失效，应带来源、日期与适用范围，不能压过当前用户要求或项目规则。
以候补名单为例，先检索 promoteNext 的定义、调用者与相关测试，再读取修改所需范围。若查询只找到了说明文档，不能因此断言运行代码按说明执行。比较未索引的定向搜索和索引检索所需调用、构建成本、更新成本与任务正确性；小仓库可能没有引入向量库的必要。原文的大幅 token 降幅不直接外推到这个项目。
交付物包括排除规则、版本清单、检索样本和过期索引测试。故意修改或删除一个演示函数，再确认搜索不会继续把旧结果当最新证据。索引不可用时回退原生搜索与读文件，而不是让 Agent 根据记忆猜实现。
场景三：按验收任务分流模型，并保留可回取压缩
把工作拆成可检验的小任务，例如字段抽取、维护说明草稿、代码修改与失败诊断。为每类任务列质量标准、延迟、数据去向和允许模型，先用固定样本比较。简单任务可试较低成本模型，但“重要程度低”并不等于允许错误；遇到不确定或断言不通过时，按预设策略升级或交人工，不把未经审核的输出直接交付。
跨供应商比较要包含输入、输出、缓存、重试和服务层费用，统一币种与时间口径。还要检查工具调用、结构化输出、上下文长度与保留政策能否满足任务。故障兜底不能绕开地区、隐私或账户授权；目标模型没获准处理私有代码时，即使便宜也不能分流。
对于长日志、JSON 数组和检索结果，可用本地可回取记录加摘要。原始内容保存到任务获准位置，摘要含记录 ID、完整性标识、范围与恢复方式。若使用 SQLite，确认数据库与附件的访问、保留、备份和删除；原记录过期后，摘要中的引用也要标明不可恢复。可逆的是取回原文的流程，不代表模型的摘要本身保留了所有信息。
不要任意改写源代码或用户原始输入来凑压缩率。对 JSON 先确认下游需要结构还是自然语言摘要；若仍需机器读取，验证模式与解析，不能将摘要当等价 JSON。故障堆栈至少保留失败类型、位置和可回查原始内容，检索片段保留来源路径与版本。压缩后发现缺失证据时先回取，不为追求更短上下文继续压缩。
技能选择与实操边界
选监控能力看覆盖哪些请求边界，选代码记忆看版本失效与排除规则，选路由能力看允许目的地和质量评估。不能把原文中的 agent-lens、index1、anvx 等名称直接当作 SkillPI 已核验条目，也不能用认证 token 技能替代模型用量优化。本轮目录检索 token 的结果涉及 SDK 与凭据，任务不匹配，因此本篇暂不强行添加 Skill 链接。
以后目录增添候选时，先核对公开页、固定来源、许可与前提，明确它用于采集、检索还是压缩哪一步，再用虚构样本验证边界；没有实际运行证据只能写来源已核对。可复用的开源方法和可安装的 Skill 记录是两件事，引用仓库不等于安装或授权执行其脚本。
FAQ 与上线前验收
先监控还是先建索引？先识别账单和请求分布，再解决最大且可测的重复工作。只用一家供应商还需要路由吗？不一定，超时、重试与输入范围可能更值得先改。预算工具能保证绝不超额吗？取决于请求前控制、并发协调、在途费用和计量延迟，必须说明实际限制。
缓存命中是否等于少读代码？不是，缓存计费与检索减少输入是不同机制。索引能替代当前源码吗？不能，修改前要核对版本和真实文件。压缩工具免费是否就省钱？把构建、存储、模型请求、维护与人工复核一起计入任务成本，再比较通过验收的结果。
上线前保留基线、成本差异、预算并发测试、索引过期测试、分流质量结果与恢复步骤。用一个已知失败案例确认循环会停止，用一条旧索引确认系统会拒绝把它当现状。逐项标明实际做过的检查，不沿用未经核实的安装量、用户故事、供应商数量与节省保证。
来源
本文按中英文原文的账单监控、减少代码重读、多模型与压缩三类场景，以原创报名系统案例改写。计量边界参考 LiteLLM 文档仓库。价格、模型支持与账户规则需要采用时核对对应官方资料；本文没有实际部署监控、建立私有仓库索引或执行费用实验。