降低 Agent 推理成本，核心不是简单换成更便宜的模型，而是把 Agent 从“每一步都靠大模型思考”改造成“能用规则、缓存、工具、小模型解决的，就不要交给大模型”。

Agent 的成本通常来自几部分：输入上下文 token、输出 token、多轮推理次数、工具调用次数、失败重试次数，以及高规格模型的调用比例。所以优化也要从这几条链路一起做。

首先要做模型分层和路由。不是所有任务都需要最强模型。可以用小模型或规则先做意图识别、任务分类、风险判断、参数抽取；只有遇到复杂规划、跨领域推理、低置信度场景时，才升级到大模型。这样可以形成类似：

复制
1规则 / 缓存 -> 小模型 -> 中模型 -> 大模型

的分级处理链路。很多业务 Agent 中，真正需要大模型深度推理的请求比例其实不高，关键是要有可靠的路由和置信度判断。

其次是上下文控制。Agent 最容易浪费成本的地方，是把大量历史对话、工具结果、文档原文全部塞进 prompt。更好的做法是维护结构化状态，只保留当前任务必要的信息；长历史做摘要，工具返回值做裁剪，RAG 只召回高相关片段，并限制 top-k 和单段长度。上下文不是越多越好，过多的上下文不仅贵，还会降低模型注意力质量。

第三是减少无效推理轮次。很多 Agent 使用 ReAct 循环后，会出现“想一步、调一次工具、再想一步”的高频循环。工程上需要设置最大步数、明确终止条件、失败兜底策略和预算上限。对于稳定业务流程，比如表单生成、数据查询、审批流、代码检查，更适合用状态机或固定工作流，让 LLM 只处理非确定性部分，而不是让它自由规划每一步。

工具设计也会显著影响成本。工具返回结果应该紧凑、结构化、可直接消费，而不是返回一大段无关文本。多个细碎工具可以合并成批量接口，避免 Agent 反复调用。比如查询用户信息、权限、配置、列表数据，如果每次都单独调用，模型还要多轮判断；如果提供一个面向任务的组合工具，推理轮次会明显下降。

缓存也是非常有效的手段。常见的有 prompt prefix cache、相同问题结果缓存、工具调用缓存、RAG 检索缓存、用户会话状态缓存。对于企业内部知识库、配置查询、规范问答这类低变化内容，缓存命中率通常可以做得很高。缓存不仅降低费用，也能降低延迟。

还需要减少重试成本。LLM 输出不稳定时，很多系统会整段重新请求，这很贵。更合理的方式是使用 JSON Schema、函数调用、字段级校验和局部修复。比如只修复缺失字段或格式错误，而不是让模型重新生成完整答案。输入侧也可以先做参数校验，明显缺信息时直接追问用户，避免模型盲目推理。

最后要建立成本观测和评估体系。每个 Agent 任务都应该能看到：用了哪个模型、消耗多少 token、调用了几次工具、失败重试几次、最终是否成功。没有 trace 和指标，就只能凭感觉优化。成熟做法是把质量、延迟、成本放在一起评估，通过离线评测集和线上 A/B 来决定某个优化是否值得。