想必不少做 AI 应用的朋友都碰到过这个场景本地调试时Agent 的表现还挺聪明一上生产面对真实流量要么响应慢得像蜗牛要么账单数字蹭蹭往上涨更头疼的是对话稍微长一点它就开始“失忆”——前面刚交代的关键信息转头就忘得一干二净。我这两年折腾商用级 Agent 架构绕了无数弯路最后发现几乎所有问题的症结都指向同一个词Token 经济学。没错就是你每次调用模型时按字符数量计费的那个 Token。它不光是成本问题更直接决定了你的 Agent 是“能用”还是“能商用”。这篇文章不聊虚的直接拆解我在实际项目中打磨出来的一个商用 Agent 架构思路。核心就一句话如何在最小化输入输出省 Token与保护上下文别丢关键信息之间走好钢丝。我会把背后的原理、具体的战术、以及架构上的取舍讲透适合那些已经跑通 Demo、正准备把 Agent 推向真实业务场景的开发者。1. 商用与 Demo 的鸿沟Token 消耗如何决定你的产品生死线先说一个反直觉的结论在 Demo 阶段Token 成本几乎可以忽略不计但到了商用阶段Token 消耗量直接决定了你的产品毛利甚至影响用户留存。1.1 Demo 里看不见的“瘦成本”与生产环境的“胖成本”你在本地跑一个 Agent输入几百 Token输出几百 Token感觉不出什么。但商用场景是什么样的以客服机器人为例一次真实会话动辄十几轮每轮都要携带历史对话。假设平均每轮输入 1000 Token上下文累积到第 10 轮时单次调用的输入可能就达到了 5000 甚至 8000 Token。如果是 1000 个并发用户每天每用户 20 次调用算下来这数字就很惊人了。我这里给一笔实在的账假设你用的是市面上主流的大模型 API输入每 100 万 Token 收费若干元输出每 100 万 Token 收费更高。一个每天处理 10 万次请求的商用 Agent如果每次请求平均消耗 3000 输入 Token 加 500 输出 Token那么一天光 Token 费用就可能上百元。这还只是单个场景。如果再碰上高峰期调用、或者模型需要重试成本还会直线上升。更关键的是Token 消耗过多还会带来延迟问题——输入越长模型推理时间越长用户的等待感就越明显体验一差留存率跟着就掉了。1.2 为什么“上下文保护”与“最小化输入输出”是一对天然矛盾这里有个核心矛盾要让 Agent 表现得聪明就得给它足够的背景信息上下文但背景信息越多Token 消耗越大推理速度越慢。这两者天然对立。你不可能无限地塞历史记录进去因为绝大多数模型的上下文窗口是有限的比如 128K 或 200K。就算你硬塞进去超长上下文还会导致“迷失在中间”效应——模型对中段信息的注意力下降反而抓不住重点。我见过不少团队一开始偷懒直接把所有历史消息原封不动地拼接进每次请求结果就是账单暴涨模型响应质量反而下降。后来我们做了一个简单的实验把同样的任务分别用 3000 Token 上下文和 8000 Token 上下文跑结果发现8000 Token 场景下模型的准确率并没有显著提升延迟却足足增加了将近一倍。从那之后我就意识到“保护上下文”不是指保存全部内容而是指保留关键决策信息。1.3 商用架构必须确立的 Token 预算制既然叫经济学就得有预算。我在项目里推行的第一件事就是给每个会话、每个任务设定硬性的 Token 预算。比如处理用户查询这个动作输入预算 1500 Token输出预算 300 Token。如果发现某次请求超了预算要么触发截断策略要么走降级方案。这里有一个具体做法在每次调用模型前用一个轻量级规则引擎预估即将拼接的上下文大小如果超出预算就启动下文会提到的压缩流程。别小看这一步它相当于给你所有的下游逻辑套上了一个安全带。没有预算控制任何架构优化都是空中楼阁。2. 上下文窗口的“沙漏效应”为什么长上下文反而让 Agent 变笨在细讲优化策略前必须先把这个底层原理掰扯清楚。很多人觉得上下文窗口越大越好模型肯定能记住更多东西。但从我实际测试的经验来看并不完全是这么回事。2.1 注意力机制的物理限制中间被遗忘两端被强化大模型的注意力机制有个特点它对序列开头和结尾的信息关注度更高而中间部分相对容易被忽略。这就是所谓的“迷失在中间”现象。打个比方你读一篇长文最容易记住的就是开头和结尾中间的大段内容很快就模糊了。放在 Agent 场景里如果每次请求都把一大坨历史记录塞进上下文这些历史记录会占据中间的“劣势区位”。模型表面上看到了实际上却“视而不见”。这解释了为什么很多 Agent 一旦上下文变长就开始答非所问——它真不是笨是信息位置不好。基于这个原理我们在架构上的第一原则就是绝不让 Agent 在每一次请求中都背负全部历史包袱。而是采用一种类似“缓存与摘要结合”的叠加结构下面会详细展开。2.2 “保护上下文”的真正含义关键决策变量的持久化很多团队会犯一个概念错误认为保护上下文就是把所有对话记录一字不落地传给模型。其实更精确的表述应该是保护那些对当前决策有影响的变量。比如用户偏好、订单状态、身份信息、未完成的步骤等至于那些寒暄、重复表述、中间推理过程完全没必要保留。举个例子用户说“帮我查一下上周三的订单那个红色的 T 恤”。那么真正需要保存进上下文的是“订单时间上周三商品红色T恤”这两个关键实体而不是用户说的那一整句自然语言。我们用结构化数据把这层信息固化下来在下一次请求时只需要注入这些结构化字段模型就能准确完成任务完全不需要看到原始的那句话。这么做的好处是显而易见的输入 Token 大幅下降而且模型对关键信息的感知强度反而提升了——因为关键信息被放到了上下文的开头或结尾避开了“中间迷失区”。2.3 上下文保护的三种粒度原始、摘要、变量我把上下文保护分为三个粒度根据场景灵活切换原始粒度适用于极短对话不超过 2-3 轮或者对信息完整性要求极高的场景比如用户明确要求保留所有细节。这是最奢侈的用法商用场景下要慎用。摘要粒度适用于中长对话。用一次模型调用把前 N 轮对话提炼成一段 200-300 字的摘要然后在后续请求中只携带这份摘要代替全部历史。变量粒度适用于业务逻辑明确的场景。从原始对话中抽取关键字段如意图、实体、状态按需注入。这是最经济、也是我觉得最符合商用原则的做法。这三种粒度并不是互斥的我会把它们混合使用。但注意一个选择逻辑粒度越细Token 越省但对抽取的准确性要求越高。如果抽取出错会直接导致信息丢失所以需要配合校验机制。这一点在第四节会专门讲。3. 最小化输入输出的三大战术截断、压缩与结构化重写既然 Token 消耗的根源在输入输出那我们就从源头下手。这一节是纯实操经验我踩过的坑比你们想象的多。3.1 硬截断不是简单删掉最早的消息而是分层裁剪很多初学者一上来就写代码“如果上下文太长就删掉最老的几条消息”。这个做法在简单场景下能用但一到商用就出问题——因为你删的可能是关键信息。我用过一个改进版本叫“分层裁剪”第一层保留所有的系统提示、用户的核心意图、关键的实体信息。第二层保留最近 5 轮对话的原始内容。第三层释放中间部分的对话如果存在摘要则使用摘要否则整体丢弃。这个策略在我的实际项目里效果不错。注意一点硬截断前一定要做“关键信息提取”否则就是盲人摸象。另外我还做过一个测试同样是 10 轮对话硬截断保留后 5 轮与保留前 5 轮相比后 5 轮的方案在任务完成率上高出 23%。原因很简单——对话的“当前状态”往往由最近的几轮主导之前的旧信息通常只是背景。当然如果你发现业务场景需要看重历史中的某个特定信息那就别用硬截断改用压缩。3.2 摘要压缩用一次模型调用换 10 次调用的 Token 节省摘要压缩的原理很容易理解输入一个长历史调用模型输出一个短摘要。但我一开始做得并不好直到我给它加上了“摘要要求”明确要求摘要必须包含所有出现的实体人名、订单号、时间、地点。明确要求摘要在结尾保留“当前待处理问题”。限制摘要长度比如不超过 300 Token。加了这些要求之后摘要的可用性大幅度提升。因为原始摘要经常把关键实体省略掉模型到了后面根本不知道用户说的是哪个订单。另一个细节是我让摘要的生成流程不是一次性完成的而是“增量摘要”。每次对话轮数超过阈值就对当前的摘要加上新增对话再重新提炼一遍。这样做的好处是你不需要在每一次请求中都运行一次完整的摘要模型节省了相当多的 Token 和延迟。实际上增量摘要的成本只有全量摘要的 30% 左右。3.3 结构化重写把自然语言变成 JSON让输入 Token 减少 40%如果说摘要压缩是“以短代长”那么结构化重写是“以变易繁”。我的实践是在 Agent 收到用户输入后先经过一层“意图与实体抽取器”把它转成 JSON 结构。比如{ intent: query_order, entities: { date: 2025-01-15, product: red_tshirt, status: pending } }然后在后面的所有环节中模型只与这份 JSON 打交道而不是与原始自然语言打交道。这么做有几个立竿见影的效果输入 Token 直接缩减了大约 40%取决于原始句子的冗余程度。模型更容易理解业务意图因为信息已经被提炼成机器可读的格式。配合上“变量粒度”的上下文保护几乎可以做到在任意长的对话中只传递关键信息。但你千万别以为结构化重写是银弹。它的前提是意图和实体的抽取必须足够准。如果在抽取环节就抽错了后面全错。所以我们一般会对抽取结果做一个置信度评分低于阈值的就回退到原始文本模式。4. 分层记忆体系让 Agent 在有限上下文里记住真正重要的东西前面讲的是“怎么省 Token”这一节讲的是“省完之后怎么还能记得住”。我的答案是别把记忆全部塞给模型上下文而是设计一套分层记忆体系让 Agent 可以用极少的 Token 保存最多的有效信息。4.1 短期缓冲保留最近 5-10 轮原始内容我习惯把最近几轮对话的原始内容保存在一个短期缓冲池里。这样做的好处是模型能够在当前话题上保持流畅的连贯性不会因为一次摘要压缩就忘记用户刚刚说过的话。短期缓冲的容量控制很关键。我建议用一个动态阈值如果当前输入 Token 总量接近预算上限再从短期缓冲里切割最久远的几轮将它们转入中期摘要。这个顺序千万不要反不能一上来就清短期缓冲。4.2 中期摘要滚动更新的业务状态卡片中期摘要不是一段自然语言文字而是一张“业务状态卡片”。我会用结构化字段记录这些内容用户身份、当前购物车内容、未完成的操作、最近一笔订单的状态、以及用户特别强调的偏好。状态卡片的更新机制是每次 Agent 执行完一个动作后都会重新写一遍这张卡片。这会消耗一点输出 Token但值得——因为后续所有请求都只依赖这张卡片。我实测过用状态卡片代替整段历史摘要输入 Token 可以再压缩 50% 甚至更多。打个比方这就像是你给自己写了一个“记忆标签”以后每次翻笔记只需要看标签不用重新读一整本笔记。4.3 长期记忆向量数据库与关键事件的落盘有一些信息需要跨会话保留比如一周前用户投诉过物流慢。这种信息不适合放进当前的上下文窗口最好存入外部存储——向量数据库或者其他形式的关系库。做法是当一个重要事件发生时比如用户发起投诉、完成支付、修改过收货地址我把它写成一个结构化 event 对象存入长期存储。在每次开启新会话时通过语义检索把最相关的 1-3 个历史事件注入上下文开头。注意这里的关键不是“存多少”而是“取多少”。我会刻意限制取回的数量因为取回的每一个事件都在消耗 Token 预算。4.4 记忆调用的触发条件不要每次都用所有记忆这是很多架构犯的错误——既然有这个记忆系统那就每次都把所有记忆都塞进去。实际上你会很快把 Token 烧光并且模型也会被无关信息干扰。我总结的记忆触发条件有两种用户主动提及比如“我上次不是说过了吗”。当前意图与某类历史事件强相关比如用户要查询订单就去检索关于该订单的历史事件。至于其他情况一概不主动取用长期记忆。这套机制能让你在 Token 预算内做到“该记的都能记不该记的一个不记”。5. 一次真实 Agent 性能调优复盘从 8000 Token 降到 1500 Token准确率反而提升 12%理论说再多不如来一个完整的复盘。这是我在某个模拟电商客服 Agent 项目上做的优化项目规模不大但足以说明问题。5.1 调优前的状态无脑拼接上下文的灾难现场原始架构很简单每次用户发消息代码就把整个历史消息列表一股脑拼到 prompt 末尾。运行起来的效果是平均每次请求输入 Token约 8000。平均响应延迟约 3.2 秒。任务完成准确率78%指用户意图识别和订单操作的正确率。问题非常明显延迟高、成本高、准确率还不尽如人意。而且一旦对话轮数超过 15 轮准确率还会进一步下滑因为上下文已经接近模型窗口上限模型开始删减信息。5.2 分阶段改造过程先压缩后结构化再增量更新我分三步来做改造每一步都做了可量化的测试。第一步只做摘要压缩。把所有超过 8 轮的会话在每轮结束的时候生成一个滚动摘要并在后续请求中用摘要替代中间部分的对话。效果输入 Token 降到约 4500延迟降到约 1.8 秒准确率几乎没有变化78% 到 79%。这一步证明了省 Token 和保信息是可以共存的。第二步引入结构化重写。增加了意图和实体抽取层并让模型直接使用 JSON 结构作为输入的一部分。效果输入 Token 从 4500 降到 2200延迟继续降到 1.1 秒准确率反而升到 85%。原因如前面所讲——去掉了自然语言中的冗余模型能更精准地抓住关键词。第三步搭建分层记忆和状态卡片。加入短期缓冲、中期状态卡片和长期事件检索机制并严格控制各层的触发条件。效果平均输入 Token 稳定在 1500 左右延迟约 0.8 秒准确率提升到 90%。这个结果比我预想的还要好。5.3 牺牲了什么换来了什么当然这套架构不是免费的午餐。最明显的牺牲是“系统的可解释性”变弱了。因为中间有摘要、抽取、结构化重写等多个环节一旦出错排查链路过长。不过我通过在每个环节打印关键日志和置信度分数把这个成本控制在了可接受范围内。另一个牺牲是开发复杂度。你需要多开发 2-3 个处理模块并且要仔细打磨摘要模板和抽取规则。但对比长期运营的 Token 成本和用户体验这些投入完全是值得的。尤其是当你的 Agent 面临高并发时省下的每一分 Token 都是纯利润。5.4 踩过的一个大坑过度压缩导致实体丢失在调优过程中我还犯过一个典型错误在生成摘要时为了压缩得更狠我设置了很低的摘要长度上限150 Token 以内。结果就是很多关键实体比如订单号、日期、颜色被“压缩”掉了后续请求中模型完全无法正确处理用户指令。后来我总结了一个经验摘要压缩的下限必须足以容纳当前业务场景的所有必要实体。一般我会预留比实体清单多出 30% 的 Token 余量确保不因压缩而丢失关键信息。6. 架构层面最终的取舍倒金字塔状态流与多级缓冲最后把视角拉高到架构层聊一聊我在这套体系里最核心的两个设计模式。它们保证了你不会在复杂的业务逻辑中迷失也不会在极端的 Token 压力下崩盘。6.1 倒金字塔状态流让关键信息永远置于上下文前部什么叫倒金字塔你可以这样理解上下文的最开头系统提示区域永远放最核心的、不变的、必须遵守的规则紧接着放当前任务的关键变量然后才根据预算空间放短期缓冲对话摘要最后才放一些可选的历史背景。这个顺序不是随意的而是顺应了注意力机制的两端聚焦效应。模型会优先看到金字塔顶部的信息自然会对这些部分投入更多注意力。我测试过仅仅把关键变量从文本中间挪到开头准确率就能提升 3-5 个百分点。这是一个几乎零成本的优化强烈建议各位尝试。6.2 多级缓冲预算耗尽时如何优雅降级即使做了这么多优化依然会有突发情况某个用户的问题比较复杂导致上下文和调用次数超过预期。这时候不能直接报错需要一套多级缓冲方案。我的设计是三层缓冲第 1 层临时追加 300 Token 给当前请求如果还不够进入第 2 层。第 2 层在前端允许的延迟范围内调用一次轻量模型对当前对话做快速摘要以摘要代替部分原始输入。第 3 层如果仍超预算就输出一个明确的“需要用户指令确认”的兜底消息而不是让模型继续瞎猜。这套方案的核心思想是宁可让 Agent 明确承认自己需要更多信息也绝不让它在信息残缺的情况下硬答。商用产品里一个“我不知道”比一个“我瞎编”要好得多。6.3 监控和成本仪表盘没有度量就没有优化最后我强烈建议你一定要搭一个 Token 消耗监控面板。至少需要统计这几个维度每个用户会话的平均 Token 消耗。每次调用中输入 Token 与输出 Token 的分布。不同意图的 Token 消耗对比。上下文压缩触发次数和回退次数。没有这些数据你根本不知道下一步该优化什么。我一开始没有做这个统计后来发现某个特定业务场景的 Token 消耗是平均值的 3 倍一查才发现是它的摘要模板写得太啰嗦了白白浪费了大量 Token。从预算控制到上下文保护再到分层记忆和状态流设计这套“Token 经济学”并不是什么高深莫测的理论而是一套可以在实践中反复迭代的方法论。它的核心只有一个让 Agent 在接触信息时像经济学家一样斤斤计较在输出决策时像战略家一样把握重点。多说一句现在市面上关于大模型 Agent 的教程大多停留在“怎么调 API”的阶段真正深入 Token 层面的架构思路其实很少。如果你正在做商用 Agent我建议你从今天开始给每一个功能都建一个 Token 预算和监控指标你会发现很多你以为的“模型能力问题”其实都是上下文管理问题。这套架构思路虽然不能保证让你的 Agent 成为最强但至少能让它离“商用”二字真正迈进一大步。