Agent 如何控制调用成本和预算？

简化版

Agent 成本控制要做成控制器，而不是事后看账单：任务开始时分配模型、Token、工具、时间和步骤预算，每次动作前估算增量成本并预授权，执行后记真实消耗。低价值步骤用小模型或规则，重复结果走缓存，搜索和重试设上限；预算不足时缩小范围、请求用户加预算或保存检查点停止，不能靠静默降低答案质量蒙混过去。

详细版

Agent 成本由模型输入输出、重复规划、工具 API、检索重排、沙箱计算和人工审核共同构成。可为任务建立预算账本：

remaining = task_budget - model_cost - tool_cost - compute_cost - review_cost

调度器在动作前检查预计成本、剩余预算和预期收益。固定分类与格式校验优先用规则；简单抽取路由小模型；困难推理再升级大模型。对相同工具参数使用有时效的缓存，对失败按错误类型限制重试，并设置每个子任务的预算封顶，防止一个分支耗尽全部额度。

预算耗尽应返回结构化状态：已完成什么、还缺什么、继续预计花费多少。评测既看单任务平均成本，也看 P95/P99、成功任务成本、浪费在失败轨迹上的比例和质量—成本曲线，避免平均值掩盖少数失控任务。

完整版教学

一、先算清 Agent 的完整成本

普通问答可能只有一次模型调用，Agent 会多轮规划、调用工具、读取结果和自我修正。账单不仅来自 token，还包括搜索 API、浏览器、代码沙箱、向量检索、GPU 和人工审批。

C_task = ΣC_model + ΣC_tool + C_compute + C_storage + C_human

如果只统计模型账单，可能错误地认为多搜十次“免费”。完整成本模型才能支持动作之间的选择，例如重新搜索、换数据源或请求人工哪一个更划算。

记忆钩子：成本控制的单位是整个任务，不是单次模型调用；每一步便宜，不代表循环一百步后仍便宜。

二、预算要分层而不是一个总上限

全局预算防止总体失控，任务预算限制单次请求，子任务预算避免某个分支吞噬全部资源，动作预算则阻止一次昂贵调用。分层额度还能区分不同业务等级。

层级	示例	作用
租户日预算	1000 元	控制整体账单与公平性
单任务预算	2 元	限制异常任务损失
搜索子任务	0.4 元	防止无休止查资料
单动作预算	0.1 元	阻止意外选用昂贵工具

子预算未用完可否回收，要由策略决定；高风险审核预算不应被生成文案的超支挤占。

三、动作前做预估和预授权

事后累计只能报告超支，无法阻止超支。执行前要估算输入长度、最大输出、工具单价和重试上界；若最坏成本超过剩余额度，就先缩小参数或请求新的预算。

假设剩余 0.12 元，一次大模型调用预计输入 6000 token、输出最多 1500 token，按输入百万 token 10 元、输出 30 元计算：

0.006 × 10 + 0.0015 × 30 = 0.105 元

调用后只剩 0.015 元，控制器应确认后续验证是否还能完成。只预算生成、不预算验证，容易得到一个无法确认的半成品。

四、模型路由按任务难度升级

并非每一步都需要最强模型。意图分类、固定字段抽取和简单摘要可以由小模型处理；当验证失败、问题复杂或置信信号不足时，再升级到更强模型。这叫级联路由。

例如 1000 个任务中 80% 用 0.002 元小模型解决，20% 升级到 0.05 元大模型，总成本约 1000×0.8×0.002 + 1000×0.2×0.05 = 11.6 元；若全部使用大模型则为 50 元。节省是否成立，还要确认路由没有让成功率跌破业务下限。

路由依据应来自任务特征和离线评测，而不是让小模型自行判断自己会不会。

五、缓存与复用要尊重新鲜度

相同检索、工具参数和稳定中间产物可以缓存，已验证的子任务产物可以在重规划时复用。缓存键要包含模型或工具版本、权限范围和关键参数；否则可能把旧结果或别人的数据返回给当前任务。

价格、库存等高时效结果需要短 TTL，静态文档摘要可以更长。写操作不能因缓存而跳过幂等和真实状态检查。

提示前缀缓存能降低重复 system prompt 与工具 Schema 的 prefill 成本，但只有精确公共前缀才容易命中；频繁改变工具顺序或动态插入时间戳会破坏缓存。

六、重试和搜索是最常见的成本黑洞

超时可有限重试，权限错误和参数错误却不能靠原样重试解决。重试策略要按错误分类、使用指数退避，并给同一动作设置总次数。搜索同样要定义停止条件：证据覆盖够了、边际新信息过低或预算到线就停。

若每轮成功概率为 70%，最多重试两次，总成功概率约为 1-0.3³=97.3%，但平均成本会上升。继续增加到五次，收益变小且可能触发限流，因此应根据错误可恢复性决定，而不是统一重试。

记录“失败轨迹花费占比”能直接发现此类浪费。如果总成本 30% 都花在最终丢弃的分支，优先优化规划和停止条件通常比压缩几百 token 更有效。

七、预算不足时要显式降级

降级可以缩小研究范围、减少候选数量、换低价模型、取消非必需润色，或保存检查点等待追加预算。降级必须告诉用户影响，例如“仅核验前三个来源”，不能交付缩水结果却仍声称完整。

高风险验证、安全过滤和权限检查不属于可裁剪项。预算不足以完成必要验证时，系统应停止，而不是拿省钱作为绕过安全步骤的理由。

检查点至少包含已完成产物、消耗账本、剩余任务和继续成本估计，使用户能做“停止、追加、缩小范围”的真实选择。

八、指标要围绕成功任务和尾部

平均单任务成本容易被大量简单任务稀释。应同时看 P50、P95、P99，按任务类型分组；还要看每个成功任务成本、每个失败任务浪费、预算耗尽率和质量—成本前沿。

一次改版把平均成本从 0.30 元降到 0.24 元，但成功率从 90% 降到 80%，每个成功任务成本从 0.30/0.90≈0.333 变成 0.24/0.80=0.30，节省只有约 10%，并非账面 20%。若失败有业务损失，方案可能更差。

成本 Trace 应能归因到任务、步骤、模型、工具、重试原因和缓存命中，才能知道钱花在哪里。

九、常见误区与追问

• 误区：限制最大 token 就控制住 Agent 成本。 工具、循环、重试、计算和人工审核同样产生费用。
• 误区：全程用小模型一定更省。 低成功率会带来更多重试和人工修复，总成本可能更高。
• 误区：缓存命中越多越好。 过期、跨权限或版本不一致的缓存会损害正确性与安全。
• 误区：超过预算后跳过验证即可。 未验证结果不能冒充成功，必要验证应预留预算。
• 误区：只看平均成本就够了。 少数循环任务会形成昂贵长尾，需要 P95/P99 和单任务封顶。
• 追问：如何给新任务定预算？ 用同类任务历史分布、成功路径和最坏必要验证估算，再通过灰度校准。
• 追问：模型路由何时升级？ 当任务特征超出小模型能力或验证失败时升级，并限制升级次数。
• 追问：预算用完如何续跑？ 保存检查点和账本，展示剩余工作与预计追加成本，由用户决定。

十、加强记忆

Agent 成本治理记住“全账、分层、预扣、路由、止损”：先统计模型、工具、计算和人工的完整账，再把额度分到租户、任务、子任务和动作；每次调用前估算并预授权，简单步骤走规则或小模型，缓存可复用产物；对搜索和重试设置停止条件。预算不足时显式缩小范围或保存检查点，最终用成功任务成本和尾部分布判断优化，而不是只看便宜了多少 token。