摘要Agent 的 token 成本不只来自模型调用还来自历史上下文、工具结果、RAG 召回、输出冗余与重试链路。本文从成本来源、上下文预算、模型路由、缓存、摘要压缩、工具结果裁剪、批处理、评测监控等方面梳理一套可落地的 Agent token 降本方法。在很多 AI 应用里Agent 的 token 成本往往比普通聊天机器人高得多。原因很简单Agent 不只是“问一次、答一次”它通常要理解任务、规划步骤、调用工具、读取结果、继续推理、必要时重试还要携带历史上下文。如果没有工程化的成本控制一个看似简单的任务可能在多轮推理和工具调用中消耗大量 token。对 AI 应用开发者、产品经理和架构师来说token 成本不是一个单纯的“模型价格问题”而是产品设计、上下文管理、工具协议、数据检索、模型路由和监控评测共同决定的系统问题。本文不讨论某个具体产品的私有实现而是从通用工程实践出发梳理 Agent 降低 token 成本的关键方法。文章目录一、先看清楚Agent 的 token 成本来自哪里1. 输入成本Prompt 不是越长越安全2. 输出成本回答越长成本越高3. 工具结果成本最容易被忽略的大头4. 历史上下文成本多轮对话会自然膨胀二、Prompt 精简不是少写而是分层写实践建议三、上下文预算给每类信息设定 token 上限上下文构建应遵循优先级四、模型路由不要所有任务都用同一个模型路由要配合评测五、缓存把重复问题变成一次成本1. Prompt 前缀缓存2. 工具结果缓存3. 语义缓存六、RAG 精准召回少召回比多召回更难也更重要优化方向七、摘要压缩把历史变成状态而不是聊天记录摘要也要可更新八、工具结果结构化与裁剪让工具为模型服务工具层应提供裁剪能力九、批处理与并发控制别让重试和风暴吃掉预算工程建议十、评测和成本监控没有数据就没有优化成本看板要按链路拆分十一、质量与成本的平衡不要为了省 token 牺牲可靠性用评测决定降本边界十二、工程实践清单Prompt 层上下文层模型层RAG 层工具层运行层监控层总结一、先看清楚Agent 的 token 成本来自哪里很多团队在做成本优化时第一反应是“换一个更便宜的模型”。这当然有用但往往不是最优先的手段。因为 Agent 的 token 成本通常由四部分组成输入 token输出 token工具结果 token历史上下文 token1. 输入成本Prompt 不是越长越安全输入 token 包括系统提示词、开发者提示词、用户问题、上下文材料、任务约束、工具定义等。Agent 项目早期常见做法是把所有规则都塞进 prompt角色设定、业务规则、异常处理、输出格式、工具说明、安全边界、示例案例全部放进去。这样做短期能提升稳定性但长期会带来两个问题每次调用都重复支付相同的 token 成本Prompt 越长模型越容易被无关信息干扰。因此输入成本优化的第一步不是压缩几个词而是判断哪些内容真的需要每次都进入上下文。2. 输出成本回答越长成本越高输出 token 是模型生成内容的成本。很多 Agent 在规划、工具调用解释、任务总结时会输出大量中间过程例如“我将先分析问题再调用工具……”“根据工具返回结果我发现……”“下面是详细解释……”如果这些内容面向最终用户可能有价值但如果只是 Agent 内部链路的一部分就应该尽量结构化、短格式、可裁剪。尤其在多步 Agent 中中间输出越啰嗦后续轮次还会把这些内容重新带入上下文形成二次成本。3. 工具结果成本最容易被忽略的大头Agent 经常调用搜索、数据库、文档、代码仓库、工单系统、日历、CRM 等工具。工具返回的数据如果不加控制可能一次返回几千甚至几万字。例如用户只是问“这个客户最近有没有投诉”工具却返回了客户过去一年的全部沟通记录。模型不仅要处理大量无关信息后续还可能把这些信息作为历史上下文继续携带。工具结果成本的核心问题是工具返回的是“原始数据”但模型需要的是“与当前任务相关的最小事实集”。4. 历史上下文成本多轮对话会自然膨胀Agent 为了保持连续性通常会携带历史消息。但并不是所有历史都同等重要。用户寒暄、已解决的问题、过期工具结果、重复解释都可能继续占用上下文窗口。如果没有上下文预算机制多轮对话会逐渐变成“把过去所有内容都带上”。这会直接提高成本也会降低回答质量因为模型需要在更大的噪声中寻找关键信息。二、Prompt 精简不是少写而是分层写Prompt 优化不是简单删字而是把规则分层。建议把提示词拆成三类常驻规则每次都必须存在例如安全边界、输出语言、核心角色场景规则只有特定任务才加载例如代码审查、合同分析、数据报表临时规则只对当前请求有效例如“用表格输出”“控制在 500 字内”。这样可以避免所有任务都携带完整规则包。实践建议第一删除装饰性表达。比如“你是一个非常专业、非常耐心、非常优秀的……”这类描述对稳定性帮助有限却会长期消耗 token。第二减少重复规则。如果系统提示词已经规定“输出中文”后续任务提示里就不必反复强调。第三用明确约束替代长篇解释。例如输出要求 - 语言中文 - 结构结论 原因 建议 - 长度800 字以内 - 不确定时说明不确定这通常比一大段自然语言说明更省 token也更稳定。第四使用模板而不是示例堆叠。示例有价值但不要把十几个样例全部放进 prompt。可以保留 1-2 个代表性样例其余通过检索或配置按需加载。三、上下文预算给每类信息设定 token 上限Agent 降本最重要的工程手段之一是建立上下文预算。也就是说在一次模型调用前明确不同信息最多能占多少 token。一个常见分配方式如下系统规则10%-15%用户当前问题5%-10%关键历史摘要15%-25%检索材料或工具结果30%-50%输出预留空间20%-30%这个比例不需要固定但必须有“预算意识”。如果没有预算最容易失控的通常是工具结果和历史上下文。上下文构建应遵循优先级建议按以下优先级组装上下文当前用户请求必要系统规则与当前任务直接相关的状态最近且未解决的对话经过筛选的工具结果压缩后的长期记忆或历史摘要。如果上下文超限应该优先丢弃低优先级内容而不是简单截断最后几千字。简单截断容易把关键约束删掉导致质量问题。四、模型路由不要所有任务都用同一个模型Agent 系统中不同步骤对模型能力的要求不同。规划、复杂推理、代码生成可能需要更强模型分类、改写、摘要、格式转换则未必需要。典型的模型路由策略包括简单意图识别使用小模型工具参数抽取使用小模型或规则复杂任务规划使用强模型长文总结根据质量要求选择中等或强模型最终用户可见回答根据场景选择合适模型。模型路由的关键不是“永远用便宜模型”而是“让每个步骤使用刚好够用的模型”。如果一个任务 80% 的步骤都可以由低成本模型完成只在关键节点使用高能力模型整体成本会明显下降。路由要配合评测不要凭感觉决定模型。可以准备一批真实样本比较不同模型在准确率、格式遵循、工具调用成功率、用户满意度和 token 成本上的表现。最后选择性价比最高的组合。五、缓存把重复问题变成一次成本缓存是 token 降本中投入产出比很高的手段。Agent 场景下可以做多层缓存1. Prompt 前缀缓存系统规则、工具说明、固定模板经常重复出现。如果模型服务支持类似前缀缓存的能力可以让固定部分复用降低重复输入成本。即使没有底层缓存也可以在应用层减少不必要的规则拼接。2. 工具结果缓存例如查询某个文档元信息、用户配置、产品列表、常见知识库内容这些结果在短时间内可能不会变化可以设置 TTL 缓存。需要注意的是缓存必须考虑权限和数据隔离。不同用户、不同租户、不同权限范围下的工具结果不能随意复用。3. 语义缓存对于常见问法可以把问题向量化后进行相似匹配。如果用户问的是高度相似的问题可以复用已有答案或复用中间检索结果。语义缓存适合 FAQ、政策解释、产品说明等稳定场景不适合强实时、强个性化、强权限隔离的任务。六、RAG 精准召回少召回比多召回更难也更重要很多团队做 RAG 时为了避免漏信息会一次召回很多 chunk。结果是模型拿到大量相似、重复、低相关内容token 成本上升答案质量也未必更好。RAG 降本的目标不是“召回越少越好”而是“召回足够回答问题的最小证据集”。优化方向第一提升切分质量。文档 chunk 不宜过大也不宜割裂语义。过大的 chunk 会浪费 token过小的 chunk 会丢失上下文。第二使用元数据过滤。比如按产品线、时间、地区、文档类型、权限范围先过滤再做向量召回。第三增加重排序。初次召回可以多一些再通过 rerank 选出最相关的少量片段。第四去重和合并相邻片段。如果多个 chunk 来自同一段内容应该合并或只保留最有信息量的部分。第五按问题类型设定召回数量。事实型问题可能 3-5 个片段足够复杂分析型问题才需要更多材料。七、摘要压缩把历史变成状态而不是聊天记录Agent 不应该永久携带完整历史。更好的做法是把历史对话压缩成状态。例如把一段长对话压缩为用户目标搭建一个面向客服场景的 Agent。 已确认约束必须接入企业知识库回答需要引用来源不能展示内部工单备注。 当前进展已完成需求澄清下一步需要设计工具调用流程。 未解决问题是否需要人工审核环节。这种摘要比原始聊天记录更短也更适合后续推理。摘要也要可更新摘要不是越写越长而应该持续合并。每轮对话结束后只把新的关键信息写入状态并移除过期内容。例如用户已经修改了需求旧需求就不应继续保留。对于复杂任务可以维护多种记忆短期状态当前任务进度长期偏好用户稳定偏好事实记忆项目背景、业务规则待办列表未完成事项。不同记忆按需进入上下文而不是全部加载。八、工具结果结构化与裁剪让工具为模型服务工具返回结果应尽量结构化而不是把原始文本全部交给模型。例如查询订单时不要返回完整数据库行和所有字段而是返回{order_id:xxx,status:已发货,paid_at:2026-06-01,risk_flags:[],summary:订单已付款并发货暂无异常}结构化结果有几个好处模型更容易理解可裁剪无关字段更容易做权限控制更容易统计 token 成本后续链路更稳定。工具层应提供裁剪能力工具接口最好支持这些参数fields只返回指定字段limit限制返回条数date_range限制时间范围query_type区分摘要、详情、统计max_chars限制文本长度include_raw是否返回原文。不要让模型在一大堆原始数据里“自己找重点”。越靠近数据源做过滤越省 token也越安全。九、批处理与并发控制别让重试和风暴吃掉预算Agent 系统中成本失控不一定来自单次调用也可能来自并发和重试。例如一个批量任务包含 1000 条数据每条都启动一个 Agent每个 Agent 又做 5 次工具调用和 3 次模型调用。如果没有并发限制和失败退避成本会快速放大。工程建议第一批量任务优先合并处理。能一次分类 50 条就不要 50 次单独分类。第二对失败重试设置上限。不要让 Agent 在工具异常、权限失败、格式错误时无限尝试。第三区分可重试和不可重试错误。网络超时可以重试权限不足不应反复重试。第四设置任务级预算。例如单个用户请求最多消耗多少 token单个批处理任务最多消耗多少模型调用。第五对低价值任务降级处理。如果预算快用完可以返回部分结果、摘要结果或请求用户确认是否继续。十、评测和成本监控没有数据就没有优化Token 降本不能只靠经验。必须建立监控指标。建议至少记录以下数据每次调用的输入 token、输出 token使用的模型调用场景和链路节点工具调用次数和返回大小RAG 召回 chunk 数量历史上下文长度重试次数最终任务是否成功用户是否满意或是否追问。有了这些数据才能回答几个关键问题哪个 Agent 成本最高哪类任务最容易超预算是输入太长还是输出太长是工具结果过大还是历史上下文过长降低成本后质量有没有明显下降成本看板要按链路拆分不要只看总成本。应该按“意图识别、规划、工具调用、RAG、总结、最终回答”等节点拆分。这样才能定位优化点。例如总成本高不一定是最终回答太长可能是 RAG 每次召回了过多文档也可能是某个工具返回了无用日志。十一、质量与成本的平衡不要为了省 token 牺牲可靠性降本不是越省越好。Agent 最终服务的是业务目标不能为了少花 token 导致错误决策、遗漏风险、用户体验下降。建议把任务按风险分层低风险任务闲聊、格式转换、简单分类可以激进降本中风险任务客服回复、内容生成、数据分析需要平衡质量高风险任务金融、医疗、法律、生产变更、权限操作需要优先可靠性。对于高风险任务不要过度压缩上下文也不要盲目使用低能力模型。更合理的方式是减少无关内容、提升检索精度、加强验证而不是简单缩短输入。用评测决定降本边界每次优化都应该做 A/B 或离线评测。观察成本下降的同时准确率、召回率、格式遵循率、人工修正率是否变化。只有质量可接受的降本才是真正的降本。十二、工程实践清单最后给一份可直接落地的检查清单。Prompt 层是否删除了装饰性角色描述是否把规则拆成常驻、场景、临时三层是否避免重复说明同一约束是否用结构化要求替代长篇自然语言是否只保留必要示例上下文层是否为系统规则、历史、工具结果、检索材料设置 token 预算是否按优先级组装上下文是否有超限裁剪策略是否把历史对话压缩成状态是否移除了过期信息模型层是否区分简单任务和复杂任务是否为分类、抽取、摘要使用更轻量的模型是否只在关键推理节点使用强模型是否基于评测选择模型而不是凭感觉RAG 层是否使用元数据过滤是否控制 chunk 大小是否做 rerank是否去重相似片段是否按问题类型调整召回数量工具层工具是否支持字段选择是否限制返回条数和文本长度是否返回结构化摘要而不是完整原文是否避免把无关日志、调试信息、重复字段交给模型是否考虑权限隔离和缓存安全运行层是否设置任务级 token 预算是否限制重试次数是否有并发控制是否支持批量合并处理是否在预算不足时优雅降级监控层是否记录每次调用的输入和输出 token是否按链路节点统计成本是否记录工具结果大小是否监控重试和失败率是否把成本指标和质量指标一起看总结Agent 节省 token 成本不能只靠“换便宜模型”或“把 prompt 写短一点”。真正有效的方法是把 token 当成一种工程资源来管理输入要分层历史要压缩工具结果要裁剪RAG 要精准模型要路由缓存要安全批处理要受控监控要可追踪。从架构视角看一个成熟的 Agent 系统应该具备三种能力知道每个 token 花在哪里知道哪些 token 对任务有价值能在质量和成本之间做可验证的取舍。当团队建立起这套机制后token 成本优化就不再是临时的“省钱动作”而会变成 Agent 工程化能力的一部分。
Agent 如何节省 Token 成本：从 Prompt 到工程监控的系统化优化指南
摘要Agent 的 token 成本不只来自模型调用还来自历史上下文、工具结果、RAG 召回、输出冗余与重试链路。本文从成本来源、上下文预算、模型路由、缓存、摘要压缩、工具结果裁剪、批处理、评测监控等方面梳理一套可落地的 Agent token 降本方法。在很多 AI 应用里Agent 的 token 成本往往比普通聊天机器人高得多。原因很简单Agent 不只是“问一次、答一次”它通常要理解任务、规划步骤、调用工具、读取结果、继续推理、必要时重试还要携带历史上下文。如果没有工程化的成本控制一个看似简单的任务可能在多轮推理和工具调用中消耗大量 token。对 AI 应用开发者、产品经理和架构师来说token 成本不是一个单纯的“模型价格问题”而是产品设计、上下文管理、工具协议、数据检索、模型路由和监控评测共同决定的系统问题。本文不讨论某个具体产品的私有实现而是从通用工程实践出发梳理 Agent 降低 token 成本的关键方法。文章目录一、先看清楚Agent 的 token 成本来自哪里1. 输入成本Prompt 不是越长越安全2. 输出成本回答越长成本越高3. 工具结果成本最容易被忽略的大头4. 历史上下文成本多轮对话会自然膨胀二、Prompt 精简不是少写而是分层写实践建议三、上下文预算给每类信息设定 token 上限上下文构建应遵循优先级四、模型路由不要所有任务都用同一个模型路由要配合评测五、缓存把重复问题变成一次成本1. Prompt 前缀缓存2. 工具结果缓存3. 语义缓存六、RAG 精准召回少召回比多召回更难也更重要优化方向七、摘要压缩把历史变成状态而不是聊天记录摘要也要可更新八、工具结果结构化与裁剪让工具为模型服务工具层应提供裁剪能力九、批处理与并发控制别让重试和风暴吃掉预算工程建议十、评测和成本监控没有数据就没有优化成本看板要按链路拆分十一、质量与成本的平衡不要为了省 token 牺牲可靠性用评测决定降本边界十二、工程实践清单Prompt 层上下文层模型层RAG 层工具层运行层监控层总结一、先看清楚Agent 的 token 成本来自哪里很多团队在做成本优化时第一反应是“换一个更便宜的模型”。这当然有用但往往不是最优先的手段。因为 Agent 的 token 成本通常由四部分组成输入 token输出 token工具结果 token历史上下文 token1. 输入成本Prompt 不是越长越安全输入 token 包括系统提示词、开发者提示词、用户问题、上下文材料、任务约束、工具定义等。Agent 项目早期常见做法是把所有规则都塞进 prompt角色设定、业务规则、异常处理、输出格式、工具说明、安全边界、示例案例全部放进去。这样做短期能提升稳定性但长期会带来两个问题每次调用都重复支付相同的 token 成本Prompt 越长模型越容易被无关信息干扰。因此输入成本优化的第一步不是压缩几个词而是判断哪些内容真的需要每次都进入上下文。2. 输出成本回答越长成本越高输出 token 是模型生成内容的成本。很多 Agent 在规划、工具调用解释、任务总结时会输出大量中间过程例如“我将先分析问题再调用工具……”“根据工具返回结果我发现……”“下面是详细解释……”如果这些内容面向最终用户可能有价值但如果只是 Agent 内部链路的一部分就应该尽量结构化、短格式、可裁剪。尤其在多步 Agent 中中间输出越啰嗦后续轮次还会把这些内容重新带入上下文形成二次成本。3. 工具结果成本最容易被忽略的大头Agent 经常调用搜索、数据库、文档、代码仓库、工单系统、日历、CRM 等工具。工具返回的数据如果不加控制可能一次返回几千甚至几万字。例如用户只是问“这个客户最近有没有投诉”工具却返回了客户过去一年的全部沟通记录。模型不仅要处理大量无关信息后续还可能把这些信息作为历史上下文继续携带。工具结果成本的核心问题是工具返回的是“原始数据”但模型需要的是“与当前任务相关的最小事实集”。4. 历史上下文成本多轮对话会自然膨胀Agent 为了保持连续性通常会携带历史消息。但并不是所有历史都同等重要。用户寒暄、已解决的问题、过期工具结果、重复解释都可能继续占用上下文窗口。如果没有上下文预算机制多轮对话会逐渐变成“把过去所有内容都带上”。这会直接提高成本也会降低回答质量因为模型需要在更大的噪声中寻找关键信息。二、Prompt 精简不是少写而是分层写Prompt 优化不是简单删字而是把规则分层。建议把提示词拆成三类常驻规则每次都必须存在例如安全边界、输出语言、核心角色场景规则只有特定任务才加载例如代码审查、合同分析、数据报表临时规则只对当前请求有效例如“用表格输出”“控制在 500 字内”。这样可以避免所有任务都携带完整规则包。实践建议第一删除装饰性表达。比如“你是一个非常专业、非常耐心、非常优秀的……”这类描述对稳定性帮助有限却会长期消耗 token。第二减少重复规则。如果系统提示词已经规定“输出中文”后续任务提示里就不必反复强调。第三用明确约束替代长篇解释。例如输出要求 - 语言中文 - 结构结论 原因 建议 - 长度800 字以内 - 不确定时说明不确定这通常比一大段自然语言说明更省 token也更稳定。第四使用模板而不是示例堆叠。示例有价值但不要把十几个样例全部放进 prompt。可以保留 1-2 个代表性样例其余通过检索或配置按需加载。三、上下文预算给每类信息设定 token 上限Agent 降本最重要的工程手段之一是建立上下文预算。也就是说在一次模型调用前明确不同信息最多能占多少 token。一个常见分配方式如下系统规则10%-15%用户当前问题5%-10%关键历史摘要15%-25%检索材料或工具结果30%-50%输出预留空间20%-30%这个比例不需要固定但必须有“预算意识”。如果没有预算最容易失控的通常是工具结果和历史上下文。上下文构建应遵循优先级建议按以下优先级组装上下文当前用户请求必要系统规则与当前任务直接相关的状态最近且未解决的对话经过筛选的工具结果压缩后的长期记忆或历史摘要。如果上下文超限应该优先丢弃低优先级内容而不是简单截断最后几千字。简单截断容易把关键约束删掉导致质量问题。四、模型路由不要所有任务都用同一个模型Agent 系统中不同步骤对模型能力的要求不同。规划、复杂推理、代码生成可能需要更强模型分类、改写、摘要、格式转换则未必需要。典型的模型路由策略包括简单意图识别使用小模型工具参数抽取使用小模型或规则复杂任务规划使用强模型长文总结根据质量要求选择中等或强模型最终用户可见回答根据场景选择合适模型。模型路由的关键不是“永远用便宜模型”而是“让每个步骤使用刚好够用的模型”。如果一个任务 80% 的步骤都可以由低成本模型完成只在关键节点使用高能力模型整体成本会明显下降。路由要配合评测不要凭感觉决定模型。可以准备一批真实样本比较不同模型在准确率、格式遵循、工具调用成功率、用户满意度和 token 成本上的表现。最后选择性价比最高的组合。五、缓存把重复问题变成一次成本缓存是 token 降本中投入产出比很高的手段。Agent 场景下可以做多层缓存1. Prompt 前缀缓存系统规则、工具说明、固定模板经常重复出现。如果模型服务支持类似前缀缓存的能力可以让固定部分复用降低重复输入成本。即使没有底层缓存也可以在应用层减少不必要的规则拼接。2. 工具结果缓存例如查询某个文档元信息、用户配置、产品列表、常见知识库内容这些结果在短时间内可能不会变化可以设置 TTL 缓存。需要注意的是缓存必须考虑权限和数据隔离。不同用户、不同租户、不同权限范围下的工具结果不能随意复用。3. 语义缓存对于常见问法可以把问题向量化后进行相似匹配。如果用户问的是高度相似的问题可以复用已有答案或复用中间检索结果。语义缓存适合 FAQ、政策解释、产品说明等稳定场景不适合强实时、强个性化、强权限隔离的任务。六、RAG 精准召回少召回比多召回更难也更重要很多团队做 RAG 时为了避免漏信息会一次召回很多 chunk。结果是模型拿到大量相似、重复、低相关内容token 成本上升答案质量也未必更好。RAG 降本的目标不是“召回越少越好”而是“召回足够回答问题的最小证据集”。优化方向第一提升切分质量。文档 chunk 不宜过大也不宜割裂语义。过大的 chunk 会浪费 token过小的 chunk 会丢失上下文。第二使用元数据过滤。比如按产品线、时间、地区、文档类型、权限范围先过滤再做向量召回。第三增加重排序。初次召回可以多一些再通过 rerank 选出最相关的少量片段。第四去重和合并相邻片段。如果多个 chunk 来自同一段内容应该合并或只保留最有信息量的部分。第五按问题类型设定召回数量。事实型问题可能 3-5 个片段足够复杂分析型问题才需要更多材料。七、摘要压缩把历史变成状态而不是聊天记录Agent 不应该永久携带完整历史。更好的做法是把历史对话压缩成状态。例如把一段长对话压缩为用户目标搭建一个面向客服场景的 Agent。 已确认约束必须接入企业知识库回答需要引用来源不能展示内部工单备注。 当前进展已完成需求澄清下一步需要设计工具调用流程。 未解决问题是否需要人工审核环节。这种摘要比原始聊天记录更短也更适合后续推理。摘要也要可更新摘要不是越写越长而应该持续合并。每轮对话结束后只把新的关键信息写入状态并移除过期内容。例如用户已经修改了需求旧需求就不应继续保留。对于复杂任务可以维护多种记忆短期状态当前任务进度长期偏好用户稳定偏好事实记忆项目背景、业务规则待办列表未完成事项。不同记忆按需进入上下文而不是全部加载。八、工具结果结构化与裁剪让工具为模型服务工具返回结果应尽量结构化而不是把原始文本全部交给模型。例如查询订单时不要返回完整数据库行和所有字段而是返回{order_id:xxx,status:已发货,paid_at:2026-06-01,risk_flags:[],summary:订单已付款并发货暂无异常}结构化结果有几个好处模型更容易理解可裁剪无关字段更容易做权限控制更容易统计 token 成本后续链路更稳定。工具层应提供裁剪能力工具接口最好支持这些参数fields只返回指定字段limit限制返回条数date_range限制时间范围query_type区分摘要、详情、统计max_chars限制文本长度include_raw是否返回原文。不要让模型在一大堆原始数据里“自己找重点”。越靠近数据源做过滤越省 token也越安全。九、批处理与并发控制别让重试和风暴吃掉预算Agent 系统中成本失控不一定来自单次调用也可能来自并发和重试。例如一个批量任务包含 1000 条数据每条都启动一个 Agent每个 Agent 又做 5 次工具调用和 3 次模型调用。如果没有并发限制和失败退避成本会快速放大。工程建议第一批量任务优先合并处理。能一次分类 50 条就不要 50 次单独分类。第二对失败重试设置上限。不要让 Agent 在工具异常、权限失败、格式错误时无限尝试。第三区分可重试和不可重试错误。网络超时可以重试权限不足不应反复重试。第四设置任务级预算。例如单个用户请求最多消耗多少 token单个批处理任务最多消耗多少模型调用。第五对低价值任务降级处理。如果预算快用完可以返回部分结果、摘要结果或请求用户确认是否继续。十、评测和成本监控没有数据就没有优化Token 降本不能只靠经验。必须建立监控指标。建议至少记录以下数据每次调用的输入 token、输出 token使用的模型调用场景和链路节点工具调用次数和返回大小RAG 召回 chunk 数量历史上下文长度重试次数最终任务是否成功用户是否满意或是否追问。有了这些数据才能回答几个关键问题哪个 Agent 成本最高哪类任务最容易超预算是输入太长还是输出太长是工具结果过大还是历史上下文过长降低成本后质量有没有明显下降成本看板要按链路拆分不要只看总成本。应该按“意图识别、规划、工具调用、RAG、总结、最终回答”等节点拆分。这样才能定位优化点。例如总成本高不一定是最终回答太长可能是 RAG 每次召回了过多文档也可能是某个工具返回了无用日志。十一、质量与成本的平衡不要为了省 token 牺牲可靠性降本不是越省越好。Agent 最终服务的是业务目标不能为了少花 token 导致错误决策、遗漏风险、用户体验下降。建议把任务按风险分层低风险任务闲聊、格式转换、简单分类可以激进降本中风险任务客服回复、内容生成、数据分析需要平衡质量高风险任务金融、医疗、法律、生产变更、权限操作需要优先可靠性。对于高风险任务不要过度压缩上下文也不要盲目使用低能力模型。更合理的方式是减少无关内容、提升检索精度、加强验证而不是简单缩短输入。用评测决定降本边界每次优化都应该做 A/B 或离线评测。观察成本下降的同时准确率、召回率、格式遵循率、人工修正率是否变化。只有质量可接受的降本才是真正的降本。十二、工程实践清单最后给一份可直接落地的检查清单。Prompt 层是否删除了装饰性角色描述是否把规则拆成常驻、场景、临时三层是否避免重复说明同一约束是否用结构化要求替代长篇自然语言是否只保留必要示例上下文层是否为系统规则、历史、工具结果、检索材料设置 token 预算是否按优先级组装上下文是否有超限裁剪策略是否把历史对话压缩成状态是否移除了过期信息模型层是否区分简单任务和复杂任务是否为分类、抽取、摘要使用更轻量的模型是否只在关键推理节点使用强模型是否基于评测选择模型而不是凭感觉RAG 层是否使用元数据过滤是否控制 chunk 大小是否做 rerank是否去重相似片段是否按问题类型调整召回数量工具层工具是否支持字段选择是否限制返回条数和文本长度是否返回结构化摘要而不是完整原文是否避免把无关日志、调试信息、重复字段交给模型是否考虑权限隔离和缓存安全运行层是否设置任务级 token 预算是否限制重试次数是否有并发控制是否支持批量合并处理是否在预算不足时优雅降级监控层是否记录每次调用的输入和输出 token是否按链路节点统计成本是否记录工具结果大小是否监控重试和失败率是否把成本指标和质量指标一起看总结Agent 节省 token 成本不能只靠“换便宜模型”或“把 prompt 写短一点”。真正有效的方法是把 token 当成一种工程资源来管理输入要分层历史要压缩工具结果要裁剪RAG 要精准模型要路由缓存要安全批处理要受控监控要可追踪。从架构视角看一个成熟的 Agent 系统应该具备三种能力知道每个 token 花在哪里知道哪些 token 对任务有价值能在质量和成本之间做可验证的取舍。当团队建立起这套机制后token 成本优化就不再是临时的“省钱动作”而会变成 Agent 工程化能力的一部分。
