1. 项目概述：当上下文成为成本瓶颈

最近在折腾几个基于大语言模型的智能体项目，一个绕不开的痛点越来越明显：上下文（Context）的消耗速度实在太快了。尤其是那些需要维护内部状态（State）的智能体，比如一个持续对话的客服机器人，或者一个需要记住用户长期偏好的个人助手。为了让智能体“记住”之前发生了什么，我们不得不把历史对话、用户信息、系统指令等一大堆状态信息，一股脑儿塞进每次请求的上下文窗口里。结果就是，每次调用API，都在为这些重复的、冗长的状态信息支付高昂的Token费用。更头疼的是，随着对话轮次增加，状态信息像滚雪球一样膨胀，很快就触及了模型上下文长度的天花板，导致智能体“失忆”或者不得不进行昂贵且可能丢失信息的上下文截断。

这不仅仅是钱的问题，更是效率和性能的瓶颈。于是，“如何减少携带状态的智能体（State-in-Context Agents）的Token消耗”就成了一个非常实际且紧迫的工程优化课题。我最近花了不少时间研究和实践一种被称为“状态最小化”（Minification）的策略，目标就是在不损失智能体核心能力的前提下，把必须塞进上下文的状态“压缩”到极致。这听起来有点像前端代码的“压缩”（Minify），但背后的逻辑和手法要复杂得多，涉及到对智能体状态结构的深度理解、信息编码的优化，甚至是与模型特性（比如最近热议的GPT-4.1、GPT-5-mini等不同规模模型对上下文的利用效率差异）的博弈。

简单来说，这个项目的核心就是：用更少的Token，传递同样多（甚至更精准）的状态信息，从而降低每次API调用的成本，并可能提升智能体的响应速度和稳定性。无论你是正在构建复杂智能体的开发者，还是被API账单吓到的项目负责人，理解并应用这些最小化技术，都能带来立竿见影的收益。

2. 状态最小化的核心思路与设计考量

2.1 为什么状态会成为Token消耗大户？

要解决问题，先得看清问题本质。一个典型的State-in-Context Agent，其状态通常包含以下几个部分：

1. 系统指令（System Prompt）：定义智能体角色、能力和行为准则的“宪法”。这部分通常较长且固定。
2. 对话历史（Conversation History）：用户与智能体之间的一问一答。这是增长最快的部分。
3. 内部状态变量（Internal State Variables）：智能体自己维护的“记忆”，比如用户的姓名、偏好设置、当前任务进度、已收集的信息等。这些可能以JSON、键值对或自然语言摘要的形式存在。
4. 工具/函数描述（Tool/Function Descriptions）：如果智能体可以调用外部API或函数，这些工具的名称、参数、描述也必须放在上下文中供模型理解。
5. 临时指令或元数据（Temporary Instructions）：当前轮次特定的指示。

最原始的实现，就是每次请求时，把上述所有内容原封不动地拼接起来，作为输入发送给大模型。这种方式的弊端显而易见：

• 冗余性：系统指令、工具描述几乎每次相同，却在每次请求中重复传输。
• 低效编码：用自然语言描述的结构化数据（如JSON状态），其信息密度远低于纯数据格式。
• 无关信息干扰：过于冗长的上下文可能包含对当前回答无用的历史细节，反而分散模型的注意力。

2.2 最小化策略的四大方向

基于以上痛点，状态最小化可以从以下几个核心方向入手，其选择取决于你的智能体架构、状态复杂度和对性能的权衡。

2.2.1 压缩与摘要（Compression & Summarization）这是最直观的思路：把长的变短。

• 对话历史摘要：不保存完整的对话历史，而是定期（例如每5轮对话后）用模型生成一个精简的摘要，例如：“用户咨询了机票价格，偏好时间是下周五，预算在2000元以内。已为其搜索了XX航空的航班。” 后续只携带这个摘要和最近几轮原始对话。这能极大遏制历史部分的线性增长。
• 状态变量摘要：将复杂的内部状态对象，用模型提炼成几句关键描述。例如，一个包含10个字段的用户画像JSON，可以摘要为：“30岁男性，科技行业，喜欢户外运动和科幻电影。”
• 指令精简：审查系统指令，删除冗余的、过于细节的或模型已经内化的描述。用更简洁、更具约束力的语言重写。

注意：摘要是一把双刃剑。它一定会造成信息损失。摘要的粒度（多详细）、频率（多久摘要一次）需要精心设计。过于频繁的摘要会增加额外的API调用成本；过于粗糙的摘要可能导致智能体“记忆模糊”，做出错误判断。通常，对“事实性”信息（如用户提供的具体数据）摘要要谨慎，而对“意图性”信息（如讨论的主题、达成的共识）进行摘要则相对安全。

2.2.2 结构化与高效编码（Structuring & Efficient Encoding）改变信息的表示形式，使其更“机器友好”，从而在同样的语义下占用更少的Token。

• 从自然语言到结构化标记：避免用“用户的名字是张三，年龄是30岁”这样的句子。改用紧凑的、自定义的标记格式，比如[user:name=张三;age=30]。模型经过少量示例学习后，完全能理解这种格式，而Token数可能减少一半以上。
• 使用缩写与代号：为常用的长短语、工具名、状态字段定义缩写。例如，将系统指令开头冗长的“你是一个专业的、友好的、乐于助人的客户服务助手…”固定为[ROLE:CS-Agent]。
• 利用模型的上下文学习能力：在系统指令中明确告知模型一种高效的通信协议。例如：“我们将使用以下紧凑格式记录状态：U:代表用户发言，A:代表助手发言，S:代表状态更新。请严格按照此格式解析和生成。”

2.2.3 外部状态管理与动态加载（External State & Dynamic Loading）一个更根本的思路是：不把所有状态都塞进上下文，只放当前需要的。

• 向量数据库检索：将长篇文档、历史对话、知识库存储在外部向量数据库中。每次请求时，只根据当前用户问题，检索最相关的几个片段（例如top-3 chunks）插入上下文。这实现了状态的“按需加载”，是处理大量背景知识的标准做法。
• 键值存储与状态引用：将详细的内部状态（如用户的所有历史订单）保存在外部数据库（如Redis）中。在上下文中，只存放一个状态ID或关键索引。当模型需要查询详细信息时，通过函数调用（Tool Call）去外部数据库获取。这相当于把详细的“数据”移出了昂贵的“上下文内存”，只在必要时通过“函数指针”去访问。
• 分层上下文策略：区分“工作记忆”和“长期记忆”。工作记忆（最近几轮对话、当前任务状态）放在上下文里；长期记忆（用户档案、历史会话摘要）放在外部，必要时摘要或检索后注入。

2.2.4 模型选择与上下文窗口优化（Model Selection & Context Window Optimization）不同的模型，对上下文的利用效率和定价策略不同。

• 关注模型的“有效上下文”：并非所有模型都能同等有效地利用其宣称的上下文长度。一些模型在上下文很长时，对中间部分的信息记忆会衰减。需要测试你的目标模型（如GPT-4.1, GPT-5-mini）在长上下文下的实际表现。
• 成本-性能权衡：像GPT-5-mini这类更小、更便宜的模型，其单次调用的Token成本更低，但可能理解复杂指令或长上下文的能力稍弱。这时，状态最小化就显得更为关键，因为你需要用更精炼的输入来弥补模型能力的不足。反之，对于能力更强的模型，你可能可以承受稍多的Token来换取更易维护的代码逻辑。
• 位置偏见：大多数语言模型对输入开头和结尾的信息更敏感。因此，应将最重要的指令和当前状态放在开头或结尾，而不是淹没在冗长的历史中间。

3. 实操：构建一个最小化状态的智能体

下面，我将以一个“旅行规划助手”智能体为例，展示如何一步步应用上述策略，实现状态的最小化。这个助手需要记住用户的旅行偏好、预算、已讨论过的目的地，并能调用搜索航班/酒店的工具。

3.1 初始设计（高Token消耗版本）

首先，我们看一个未经优化的、典型的实现方式：

系统指令 (约150 tokens):

你是一个旅行规划助手。你的目标是帮助用户规划一次完美的旅行。你需要热情、细致。首先，你需要询问用户的出行时间、目的地偏好、旅行人数、预算范围。然后，根据用户的信息，提供目的地建议、行程安排、预算估算。你可以调用搜索航班和搜索酒店的工具。请确保你的建议符合用户的预算。在对话中，请主动总结已确认的信息，并逐步推进规划流程。

状态维护方式：每次请求，将以下全部内容拼接：

1. 完整的系统指令。
2. 完整的对话历史（用户和助手的所有消息）。
3. 一个不断增长的JSON状态对象，记录已收集的信息：

   { "user_preferences": { "travel_dates": "2023-10-01 to 2023-10-07", "destination_pref": ["beach", "cultural"], "budget": 5000, "travelers": 2 }, "discussed_destinations": ["Bali", "Kyoto"], "current_step": "comparing_accommodation" }

4. 工具描述（两个工具的JSON Schema，约100 tokens）。

假设进行了10轮对话，每次平均新增200 tokens的历史，那么这个状态在10轮后仅历史部分就高达2000 tokens，加上其他固定部分，每次请求的上下文可能超过2500 tokens。

3.2 实施最小化改造

现在，我们应用组合策略进行优化。

3.2.1 精简系统指令与定义协议重写系统指令，并植入一个高效通信协议。

优化后的系统指令 (约80 tokens):

你是一个旅行规划助手。我们使用紧凑协议： - 状态行以`[S:`开头，包含关键信息。 - 工具调用按标准格式。 - 基于已有状态和对话推进规划。 初始状态：[S: step=collect_preferences]

3.2.2 重构状态表示将JSON状态转化为紧凑的标记格式，并定期摘要对话。

• 紧凑状态标记：我们将状态编码成一行。

  • 原始JSON（约120字符）可能被编码为：[S: dates=2023-10-01_07; pref=beach,culture; budget=5k; persons=2; discussed=Bali,Kyoto; step=compare_hotel]
  • Token节省分析：JSON格式包含大量引号、括号、冒号和键名（如"user_preferences"）。我们的紧凑格式去除了这些冗余，使用下划线连接日期，用逗号分隔列表，用分号分隔不同模块。经估算，Token数可从~40降至~25，节省近40%。

• 对话历史摘要：我们设定每5轮对话进行一次摘要。摘要由模型生成，并替换掉5轮前的原始历史。

  • 摘要提示词示例：“请将以下对话历史总结成一句简短的话，聚焦于已确认的用户偏好和当前任务阶段：[历史内容]”
  • 摘要结果示例：“用户计划10月初两人出行，偏好海滩和文化，预算5000。已讨论巴厘岛和京都，正在比较酒店。”
  • 我们将这个摘要以[HistSum: ...]的格式，与最近2-3轮原始对话一起保留。

3.2.3 引入外部状态引用对于“已讨论的目的地”这种可能增长的列表，我们将其移出主上下文。

• 在外部存储（如内存字典或数据库）中维护一个详细的discussed_destinations列表，包含每个目的地的备注信息。
• 在主上下文的紧凑状态行中，只保留最新或最相关的1-2个目的地，或改为一个计数discussed_count=5。
• 当模型需要回顾所有目的地时，它可以通过调用一个get_discussed_destinations工具来获取完整列表。这样，详细的列表信息只在需要时才占用Token。

3.2.4 优化后的请求结构经过优化后，第10轮对话的请求上下文可能如下：

[系统指令]（精简版，80tokens） [S: dates=2023-10-01_07; pref=beach,culture; budget=5k; persons=2; discussed=Bali; step=compare_hotel] (25 tokens) [HistSum: 用户计划10月初两人出行，偏好海滩和文化，预算5000。已讨论巴厘岛和京都，正在比较酒店。] (30 tokens) [用户第8轮] ... (40 tokens) [助手第8轮] ... (50 tokens) [用户第9轮] ... (40 tokens) [助手第9轮] ... (50 tokens) [用户第10轮问题] “巴厘岛那家海边酒店有家庭房吗？” (15 tokens)

总Token估算：80 + 25 + 30 + 40 + 50 + 40 + 50 + 15 =~330 tokens。

与优化前的2500+ tokens相比，Token消耗降低了近一个数量级！这意味着成本的大幅下降，以及更快的模型响应速度（因为输入更短）。

3.3 关键操作的心得与陷阱

1. 摘要的时机与粒度是艺术：不要机械地每N轮摘要一次。更好的策略是在“任务阶段转换”时进行摘要。例如，当从“收集偏好”阶段进入“推荐目的地”阶段时，摘要前一阶段的所有对话。摘要的粒度要足以支撑下一阶段的任务，通常包含：核心决策、已排除的选项、待办事项。
2. 紧凑格式需要“训练”模型：模型并非天生理解你的[S: ...]格式。你需要在系统指令中清晰定义，并在最初的几轮对话中，以示例（Few-shot）的方式展示这种格式的输入和输出。可以在系统指令后附加1-2轮示例对话，其中明确展示了状态行的解析和使用。
3. 外部状态的一致性挑战：当状态部分存储在外部数据库时，必须谨慎处理并发和状态同步。如果智能体有多个实例，或者用户通过不同渠道交互，需要确保它们访问的是同一份状态。通常需要一个中心化的状态管理服务。
4. 测试，测试，再测试：任何最小化操作都可能引入错误。必须建立全面的测试用例，覆盖各种对话路径，确保智能体在状态被压缩、摘要后，依然能做出正确的决策和回应。特别要测试边界情况，比如用户引用很久以前提过的信息时，摘要是否还能提供足够线索。
5. 监控Token消耗与成本：在实施优化前后，务必对API调用进行监控，记录平均每次请求的输入Token数。这不仅能验证优化效果，还能帮助你发现意外的高消耗点。一些API提供商（如OpenAI）的返回结果中会包含使用的Token数，便于记录。

4. 不同模型下的策略微调与问题排查

4.1 针对GPT-4.1、GPT-5-mini等模型的考量

不同规模和架构的模型，对最小化策略的响应可能不同。

• GPT-4.1 / GPT-4系列：这些模型通常能力较强，对复杂指令和长上下文的处理更鲁棒。你可以采用更激进的最小化策略，比如使用高度压缩的标记格式，它们通常能很好地理解和遵循。它们也能从更长的Few-shot示例中学习你的协议。但要注意，它们的单位Token成本更高，因此最小化带来的经济效益也更显著。
• GPT-5-mini / 小型模型：这些模型成本低，但能力边界更明显。它们可能对高度非常规的格式理解力下降。策略需要调整：
  • 压缩程度要适度：可能不适合使用过于晦涩的缩写或符号。[S: ...]格式仍然可用，但键名最好更直观，如[状态: 时间=...; 偏好=...]。
  • Few-shot示例更重要：需要提供更清晰、更简单的示例来教导模型。
  • 摘要要更保守：信息损失对小模型的影响可能更大，摘要应更偏向于保留具体事实。
  • 利用其长处：一些小型模型在特定任务（如格式提取、简单摘要）上可能效率很高且便宜，可以考虑用它们作为“预处理”模型，来为主智能体生成精简后的状态或摘要。

4.2 常见问题与排查实录

在实践中，你可能会遇到以下典型问题：

一个实用的调试技巧：当你怀疑是状态最小化导致的问题时，做一个“对比实验”。临时将请求切换回包含完整、未优化状态的版本，观察问题是否消失。如果问题消失，那么问题很可能出在你的最小化逻辑上；如果问题依旧，那么可能是其他部分（如提示词设计、模型本身）的问题。这能帮你快速定位问题边界。

5. 进阶：状态最小化与智能体架构的协同

状态最小化不是一个孤立的优化技巧，它应该与你的智能体整体架构设计协同考虑。

5.1 分层状态管理设计一个清晰的状态管理层：

• 会话层状态：与当前对话线程强相关的临时状态（如当前询问的字段），必须放在上下文内，实时性强。
• 用户层状态：用户的长期偏好、档案。可以放在外部数据库，通过检索或函数调用获取。在上下文中只保留一个指向性引用或高频摘要。
• 知识层状态：产品知识、规则库。必须放在向量数据库等外部知识库中，严格按需检索。

5.2 与流式处理、函数调用深度结合现代LLM应用框架支持流式响应和复杂的函数调用链。你可以利用这些特性：

• 在流式响应中增量更新状态：模型在生成回答的过程中，可以同时输出对内部状态的更新指令（例如，输出一个特殊的标记如<update_state: step=confirmed>）。后端接收到这个标记后，再去更新外部状态存储。这样，状态更新不需要等待整个响应结束，也更自然。
• 将状态管理封装为工具：创建get_state、update_state、summarize_history等工具。让模型自己决定何时需要获取完整状态、何时需要更新状态、何时需要摘要历史。这赋予了模型更大的自主权，但也对提示词设计和工具可靠性提出了更高要求。

5.3 成本与性能的持续权衡状态最小化是一个持续的优化过程，而不是一劳永逸的设置。你需要建立监控指标：

• 平均每次请求的输入Token数
• 智能体任务完成率/成功率
• 用户满意度指标（如对话轮次、负面反馈）

当引入新的最小化策略时，要观察这些指标的变化。我们的目标是在成本（Token消耗）、性能（任务成功率）和用户体验（对话流畅度）之间找到一个最佳平衡点。有时，为了提升一点点成功率或用户体验，适当增加一些Token是值得的。关键在于，你要清楚地知道每一分Token花在了哪里，以及它带来了什么价值。

在我自己的项目中，通过系统性地应用这些最小化策略，成功将一些复杂对话智能体的平均每次调用输入Token数从3000+降低到了500-800，月度API成本下降了超过60%，而关键的任务完成率指标保持了稳定，甚至在部分场景下因为响应更快而有所提升。这个过程需要细致的分析、不断的测试和迭代，但带来的回报是实实在在的。