企业官网建设流程全解析

摘要：Agent 的 token 成本不只来自模型调用，还来自历史上下文、工具结果、RAG 召回、输出冗余与重试链路。本文从成本来源、上下文预算、模型路由、缓存、摘要压缩、工具结果裁剪、批处理、评测监控等方面，梳理一套可落地的 Agent token 降本方法。

在很多 AI 应用里，Agent 的 token 成本往往比普通聊天机器人高得多。原因很简单：Agent 不只是“问一次、答一次”，它通常要理解任务、规划步骤、调用工具、读取结果、继续推理、必要时重试，还要携带历史上下文。如果没有工程化的成本控制，一个看似简单的任务，可能在多轮推理和工具调用中消耗大量 token。

对 AI 应用开发者、产品经理和架构师来说，token 成本不是一个单纯的“模型价格问题”，而是产品设计、上下文管理、工具协议、数据检索、模型路由和监控评测共同决定的系统问题。本文不讨论某个具体产品的私有实现，而是从通用工程实践出发，梳理 Agent 降低 token 成本的关键方法。

一、先看清楚：Agent 的 token 成本来自哪里

很多团队在做成本优化时，第一反应是“换一个更便宜的模型”。这当然有用，但往往不是最优先的手段。因为 Agent 的 token 成本通常由四部分组成：

1. 输入 token
2. 输出 token
3. 工具结果 token
4. 历史上下文 token

1. 输入成本：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%

这个比例不需要固定，但必须有“预算意识”。如果没有预算，最容易失控的通常是工具结果和历史上下文。

上下文构建应遵循优先级

建议按以下优先级组装上下文：

1. 当前用户请求；
2. 必要系统规则；
3. 与当前任务直接相关的状态；
4. 最近且未解决的对话；
5. 经过筛选的工具结果；
6. 压缩后的长期记忆或历史摘要。

如果上下文超限，应该优先丢弃低优先级内容，而不是简单截断最后几千字。简单截断容易把关键约束删掉，导致质量问题。

四、模型路由：不要所有任务都用同一个模型

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 系统应该具备三种能力：

1. 知道每个 token 花在哪里；
2. 知道哪些 token 对任务有价值；
3. 能在质量和成本之间做可验证的取舍。

当团队建立起这套机制后，token 成本优化就不再是临时的“省钱动作”，而会变成 Agent 工程化能力的一部分。