引言：当 Agent 的“思考过程”成为烧钱机器

2026 年，AI Agent 已经从实验室概念走向了大规模生产部署。但随之而来的，是一个让所有开发者夜不能寐的问题——Token 爆炸。

根据 OpenRouter 的数据，在 2026 年 3 月 16 日至 22 日这一周，仅中国模型就记录了 7.36 万亿个 Token，比前一周增长了 56.9%。这还只是一个平台、一周的数据。

Agentic 编程任务消耗的 Token 量是普通 Chat 的约 1000 倍，而 Input Token 而非 Output Token 主导了绝大部分成本。换句话说，让 Agent“想太多”比让 Agent“说太多”更烧钱。

本文聚焦一个核心问题：如何在不牺牲 Agent 推理质量的前提下，对 Intermediate Steps（中间步骤输出）进行精准裁剪，实现 Token 成本的可控下降。 我们将从成本分析、技术方案、框架对比、实战代码、部署建议五个维度展开，所有数据和结论均来自 2026 年 3 月以来的真实技术资讯、论文和官方发布。

关键结论先行：通过合理的 Intermediate Steps 裁剪策略，可以在保持甚至提升任务完成质量的前提下，降低 30%-78.9% 的 Token 消耗。

一、问题剖析：Intermediate Steps 为什么是“成本黑洞”

1.1 Agent 的推理链条：看不见的 Token 消耗

一个典型的 Agent 执行流程包含多个环节：

用户输入 → 思考(CoT) → 工具选择 → 工具调用 → 观察结果 → 再次思考 → ...

每一步都会产生大量的 Intermediate Steps——也就是 Agent 的“内心独白”和工具调用的中间输出。这些内容被完整地保留在上下文中，随着轮次增加呈指数级膨胀。

根据 2026 年 4 月的一项系统研究，Agent 场景的 Token 消耗有四个核心来源：

1. 超长 System Prompt：定义工具集、约束输出格式，少则两三千 Token，多则上万
2. 多轮工具调用：每一次工具反馈都是新的 user/tool message，上下文快速膨胀
3. 重复读文件/知识：Agent 反复参考同一份资料，没有缓存时每次都重新计算
4. 思维链消耗：深度思考模型在生成最终答案前有大量内部推理

1.2 为什么 Intermediate Steps 最难优化？

难点一：结构依赖。 Agent 的推理链不是线性的——后一步依赖前一步的完整上下文。粗暴截断会导致“失忆”。

难点二：价值不均。 同样是 5000 Token，grep 输出和关键诊断信息的价值天差地别。

难点三：触发时机。 在复杂重构中间压缩上下文，会打断推理连续性。

难点四：框架差异。 不同 Agent 框架对中间步骤的处理方式不同，优化策略需要适配。

根据 2026 年 5 月发布的 AI Token Economics Report，重试浪费（Retry waste） alone 就可以占到 Agent 工作负载 Token 消耗的 10% 到 25%。这意味着，仅仅优化重试和中间步骤的重复计算，就能带来显著的成本改善。

二、方案设计：Intermediate Steps 裁剪的五大技术路线

2.1 路线一：回调拦截——LangChain 自定义 Callback 过滤

核心思路：在 Agent 执行过程中，通过自定义 Callback Handler 拦截 Intermediate Steps，只保留必要的推理轨迹。

LangChain 在 2026 年提供了成熟的中间件机制。根据 LangChain 1.0 的官方文档，中间件是围绕智能体执行流程的“可插拔钩子系统”，用于在关键节点对输入、调用、输出进行预处理、拦截、修改与验证。

实战代码：LangChain.js 中过滤思考链

// 2026年3月方案：状态机式Token过滤
class FilteredCallbackHandler extends BaseCallbackHandler {
  private shouldStream = false;
  
  async handleLLMNewToken(token: string) {
    // 只有在最终答案阶段才流式输出
    if (this.shouldStream) {
      process.stdout.write(token);
    }
  }
  
  async handleAgentAction(action: AgentAction) {
    // 记录但不输出action
    this.logAction(action);
    this.shouldStream = false;
  }
  
  async handleAgentEnd(action: AgentFinish) {
    // 最终答案开始流式输出
    this.shouldStream = true;
    return action.returnValues;
  }
}

这种方法的核心在于状态机式过滤——将 Agent 执行分为“思考阶段”（不输出）和“回答阶段”（流式输出），从而在用户体验和成本控制之间取得平衡。

适用场景：对实时性要求高、用户只关心最终答案的对话类 Agent。

成本效果：可节省 30%-50% 的输出 Token（具体取决于 Agent 推理链的长度）。

2.2 路线二：自主压缩——让 Agent 自己决定何时“清场”

2026 年最值得关注的技术趋势之一，是让 Agent 自主管理自己的上下文。

2026 年 3 月 11 日，LangChain 团队在 Deep Agents SDK 中增加了自主上下文压缩工具。这个工具允许模型在合适的时机自行压缩上下文窗口。

更进一步的突破来自 2026 年 6 月 22 日提交的 SelfCompact 论文（arXiv:2606.23525）。研究团队提出了一种让模型自己决定何时以及如何压缩上下文的框架：

SelfCompact 配对了两个推理时元素：（i）一个压缩工具，模型调用它来总结累积的上下文；（ii）一个轻量级规则，指定何时触发（子任务已解决，或轨迹正在收敛）以及何时抑制（推理中间，或卡住时）。两者缺一不可。工具单独使用时在各开源模型上的使用不均匀，常在无帮助的时机被调用或根本不调用；规则单独无法行动。两者结合，无需任何微调或外部监督即可实现有效的自适应压缩。

实验结果：在 6 个基准测试和 7 个模型上的评估显示，SelfCompact 在数学任务上比无摘要基线提升了最高 18.1 分，在 Agentic Search 上提升了 5-9 分，同时每问题成本降低 30%-70%。

关键洞察：虽然未经提示的模型无法可靠判断自己的上下文何时在“腐烂”，但一个轻量级的规则可以弥合这个元认知差距。

实现示例（使用 Deep Agents SDK）：

from langchain.agents import create_agent
from deepagents import DeepAgent

# Deep Agents SDK 支持自主压缩
agent = DeepAgent(
    model="anthropic:claude-sonnet-4-5",
    tools=tools,
    # 启用自主压缩
    enable_autonomous_compaction=True,
    # 设置在85%上下文窗口时触发压缩
    compaction_threshold=0.85
)

LangChain 团队对此持乐观态度：“我们总体上看好这样的想法——在可能的情况下，框架应该‘让开’，利用底层推理模型的改进。这是‘苦涩教训’的一个实例：我们能否给 Agent 更多对自己上下文的控制权，以避免手动调整框架？”

2.3 路线三：轨迹裁剪——删除“无用”的推理步骤

核心思路：不是压缩内容，而是直接删除那些对最终结果没有贡献的中间步骤。

2026 年 3 月 15 日提交的 AgentDiet 论文提出了一种简单而有效的轨迹缩减方法。其核心思想是：在 Agent 执行过程中自动识别并移除浪费的步骤。

与此同时，2026 年 3 月 17 日发表在 AAAI 2026 上的 DEPO（Dual-Efficiency Preference Optimization）论文提出了更系统的方法：

DEPO 定义了“双效率”：（i）步骤级效率——最小化每步的 Token 数；（ii）轨迹级效率——最小化完成任务所需的步骤数。基于这一定义，DEPO 提出了一种基于偏好的双效率优化方法，同时奖励简洁的响应和更少的行动步骤。

实验结果：在 WebShop 和 BabyAI 上的实验显示，DEPO 削减了高达 60.9% 的 Token 使用和 26.9% 的步骤数，同时任务性能提升了最高 29.3%。DEPO 还能泛化到三个域外数学基准，并且仅用 25% 的数据训练即可保持效率提升。

为什么“少即是多”？

2026 年 3 月 31 日提交的 SkillReducer 论文通过对 55,315 个公开可用的 Skill 进行大规模实证研究，发现了一个反直觉的现象：

• 26.4% 的 Skill 完全缺少路由描述
• 超过 60% 的正文内容是不可执行的
• 参考文件每次调用可能注入数万 Token

研究团队提出的 SkillReducer 框架实现了 48% 的描述压缩和 39% 的正文压缩，同时功能质量反而提升了 2.8%。论文作者称之为 “少即是多效应” ——移除非必要内容减少了上下文窗口中的干扰。

2.4 路线四：MCP 工具定义压缩——从源头削减

2026 年，MCP（Model Context Protocol）已经成为 Agent 连接外部工具的标准接口。但 MCP 带来了一个隐蔽的成本问题。

根据 MuleSoft 2026 年 6 月 3 日的博客，一个拥有 30 多个工具的 SaaS MCP 服务器，每次调用会向上下文注入 15 万到 30 万 Token 的工具定义——无论 Agent 是否调用了其中任何一个工具。更糟糕的是，在企业环境中，数十个 MCP 服务器并行加载，成本成倍增加。

解决方案 1：MCP Compressor

2026 年 4 月 1 日发布的 MCP Compressor 是一个代理服务器，它包装现有的 MCP 服务器并压缩其工具描述。通过将数十个工具替换为仅 2 个包装工具，实现了 70%-97% 的 Token 削减，同时保持完整功能。

解决方案 2：TERSE Tool Catalog

2026 年 4 月 28 日发布的 TERSE Tool Catalog 规范指出，一个典型的 MCP 工具定义消耗 100-270 Token 的 JSON Schema。一个安装了 50 个工具的系统，在没有任何用户指令、记忆或推理之前，就已经在上下文窗口中放置了 5,000-13,500 Token 的目录开销。

解决方案 3：动态工具门控

2026 年 4 月 23 日的论文提出了动态工具门控和惰性 Schema 加载方法，以消除 MCP/Tools Tax。实践者报告称，在典型的多服务器部署中，每轮开销在 1 万到 6 万 Token 之间。

2.5 路线五：多 Agent 系统压缩——精简协作结构

对于多 Agent 系统，Token 消耗问题更加严重。2026 年 5 月 9 日提交的 AgentSlimming 论文提出了一个即插即用的压缩框架：

受神经网络中剪枝和量化的启发，AgentSlimming 首先通过混合机制估计每个 Agent 的重要性分数，然后移除冗余 Agent 或用低成本 Agent 替换它们，每次操作都使用基线锚定的接受规则进行验证，以防止性能崩溃。

实验结果：AgentSlimming 平均降低 Token 成本高达 78.9%，性能下降可忽略不计，有时甚至提高了准确率。

代码已开源：https://github.com/CitrusYL/AgentSlimming

三、框架对比：谁在“吃”Token 这件事上最克制？

3.1 2026 年主流 Agent 框架 Token 效率对比

根据 2026 年 3 月 19 日发布的框架对比研究，LangChain/LangGraph、Microsoft AutoGen 和 CrewAI 各自代表了不同的设计哲学：基于图的控制流、对话式多 Agent 循环、基于角色的团队协作。

一项覆盖 5 个任务、2,000 次运行的基准测试揭示了显著差异：

框架	简单任务 Token 消耗	复杂任务表现	核心问题
LangChain	<900 Token，<5秒	最 Token 高效	状态管理简单，适合线性任务
LangGraph	<900 Token，<5秒	紧随 LangChain	状态管理开销随复杂度增长
AutoGen	略高于 LangChain	平衡表现	多 Agent 对话循环有固定开销
CrewAI	3× LangChain	最重	“管理开销”结构化，无法跳过

关键发现：

• CrewAI 在简单任务上比 LangGraph 多吃 3 倍 Token。即使只做单次工具调用，CrewAI 的 Planner 和 Analyst 角色之间的多步验证过程也会产生大量“仪式性”Token。
• 根据 LangChain 的《2026 Agent 工程状态》调查，LangChain（含 LangGraph）已部署超过 10 万个生产应用。
• 框架选择错误可能使推理成本增加 2-4 倍。

3.2 为什么 CrewAI 这么“能吃”？

深入日志分析发现，CrewAI 向系统提示中注入了多层指令，为每个 Agent 分配角色、目标和背景故事，并在每一步强制执行 ReAct 风格的 Thought → Action → Observation 循环。即使对于简单任务，LLM 也无法跳过这个“仪式”，必须生成冗长的内部独白。

这意味着：如果你的任务主要是简单的工具调用，请远离 CrewAI。

3.3 混合架构的突破

一项 2026 年的研究提出并验证了一种 LangGraph-CrewAI 混合架构，实现了 96.1% 的成功率，同时 Token 消耗降低了 76.2%，决策延迟降低了 14.5 倍。

核心思路：用 LangGraph 做编排和路由（轻量），只在复杂子任务中调用 CrewAI 的团队协作能力（重量）。

3.4 2026 年新玩家：OpenAI Agents SDK 与 Claude Agent SDK

2026 年 6 月的对比分析显示，OpenAI Agents SDK 的开销 Token 在 15% 到 25% 之间——每次调用额外消耗 200 到 600 Token。

而 Anthropic 在 2026 年 5 月 13 日宣布调整 Claude Agent SDK 的计费方式，从标准订阅调整为按 Token 用量计费。虽然这一计划在 6 月因社区反对而暂停，但释放了一个明确信号：Token 成本正在成为平台级的核心关注点。

四、实战：从零搭建一个带 Intermediate Steps 裁剪的 Agent

4.1 使用 Axor 中间件（2026 年推荐方案）

Axor 是 2026 年 5 月 26 日发布的 LangChain 治理中间件。它可以在不重写 Graph 的情况下压缩上下文增长。

安装：

pip install axor-langchain
pip install "axor-langchain[openai]"  # 或 [anthropic]

核心配置：

from langchain.agents import create_agent
from axor_langchain import AxorMiddleware

axor = AxorMiddleware(
    optimization_profile="cautious",  # 或 "aggressive"
    soft_token_limit=80_000,
    hard_token_limit=120_000,
)

agent = create_agent(
    "anthropic:claude-sonnet-4-5",
    tools=tools,
    middleware=[axor],
)

result = await agent.ainvoke({
    "messages": [("user", "Investigate the checkout latency incident.")]
})

print(f"tokens spent: {axor.total_tokens_spent}")

Axor 的核心能力：

• 减少多工具、多步骤 Agent 中的重复输入 Token
• 保留最新的工具结果，避免 Agent 不必要地重新查询
• 通过软硬 Token 限制实现显式成本控制
• 每个 Agent 限制危险或不相关的工具
• 跨 LangGraph 调用缓存只读工具输出

性能验证（在真实硬 Agent 基准上）：

配置	成本节省	质量评分（3次平均）
OpenAI 激进模式	77.0%	0.91
OpenAI 保守模式	69.9%	0.92
Anthropic 激进模式	35.3%	0.94
Anthropic 保守模式	30.0%	0.96

4.2 使用 agent-cost-guardrails 做预算熔断

2026 年 4 月 2 日发布的 agent-cost-guardrails 提供了预算限制和成本护栏：

from agent_cost_guardrails import BudgetGuard
from agent_cost_guardrails.integrations import LangGraphGuardrails

# 设置5美元硬预算
guard = BudgetGuard(max_usd=5.00)

# 在LangGraph中使用
guards = LangGraphGuardrails(max_usd=2.00)
result = graph.invoke(
    state,
    config={"callbacks": [guards.callback_handler]}
)
print(guards.cost_report())

功能特性：

• 超预算时抛出 BudgetExceededError
• 每次调用 Token 限制和每分钟 Token 限流
• 连续违规 N 次后触发的断路器
• 在 50%、80%、100% 阈值时的告警回调
• 按模型和 Agent 的成本明细

4.3 使用 agent-coherence 做多 Agent 缓存一致性

2026 年 6 月 2 日发布的 agent-coherence 是多 Agent 系统的 Token 优化层：

# 只需改一行代码
from ccs.adapters import CCSStore

# 原来
# from langgraph.store.memory import InMemoryStore
# store = InMemoryStore()

# 现在
store = CCSStore(strategy="lazy")  # 支持 LangGraph, CrewAI, AutoGen

工作原理：每个共享工件在本地按 Agent 缓存，读取时从本地缓存提供。写入提交给协调器，协调器向对等方发送轻量级失效信号（约 12 Token），而不是重新广播完整工件。

实测节省（真实 LangGraph Graph）：

工作负载	Agent数	读:写比	命中率	节省
规划（读密集）	4	12:1	75%	69%
代码审查（中等）	3	8:3	60%	47%
高变更（写密集）	4	8:4	50%	29%

4.4 Prompt Cache：云厂商的降本路径

腾讯云 TokenHub 在 2026 年 5 月提供了 Prompt Cache 能力。核心思路：当多个请求的前缀相同时，底层复用 KV Cache，缓存命中的输入 Token 享受常规输入价的 1/4 到 1/10。

{
  "model": "your-model",
  "prompt_cache_key": "conv-6900xxxx",
  "messages": [
    {"role": "system", "content": "你是一个助手..."},
    {"role": "user", "content": "你好"}
  ]
}

支持的模型包括 Hy3 preview、DeepSeek-V4-Flash/Pro、GLM-5.1 系列、Kimi-K2.6/K2.5、MiniMax-M2.7/M2.5 等。

五、部署建议与最佳实践

5.1 分阶段 rollout 策略

根据 AWS 中国博客 2026 年 4 月的建议，建议分三个阶段推进：

Phase 1：可观测性先行

• 部署 LangSmith 等监控工具，了解当前 Token 消耗分布
• LangSmith 支持按端点或用户分组显示，快速定位“大户”
• 使用 --fields 参数可减少 90%+ 的日志 Token

Phase 2：保守优化

• 使用 Axor 的 cautious 模式，保留最后 2 个工具结果
• 启用 Prompt Cache
• 设置 budget guardrails 的告警阈值（50%/80%）

Phase 3：激进优化

• 切换到 aggressive 模式
• 启用 Agent 自主压缩
• 考虑框架迁移或混合架构

5.2 关键监控指标

不要只看“平均调用成本”：

核心指标 = 总成本 / 成功任务数

其他需要跟踪的指标：

• 每任务的 Token 消耗趋势
• 按 Agent/工具/模型的成本分解
• 缓存命中率
• 重试率与重试成本占比

5.3 安全与风险考量

风险 1：质量退化

Agent Capsules 的研究表明，盲目合并 Agent 调用会静默降低质量——工具使用 Agent 失去工具访问权限，小模型将多 Agent 指令压缩为单一浅层响应。

对策：使用质量门控。Agent Capsules 的控制器在质量低于阈值时自动回退到精细模式。

风险 2：过度压缩导致“失忆”

DeepAgents 的设计哲学给出了答案：“压缩，但不删原稿；瘦身，但留得回得来”。压缩掉的消息不是删除，而是归档，可回溯。

风险 3：成本控制本身的成本

agent-cost-guardrails 的作者明确指出：“零基础设施要求——无需网关、无需代理、无需外部服务”。但在大规模部署中，缓存层、路由层本身的维护成本也需要计入总拥有成本（TCO）。

六、未来趋势：2026-2027 的 Agent 成本控制方向

6.1 从“固定阈值”到“自适应压缩”

第一代压缩的逻辑是“撑不住才动手”——不溢出时一动不动，一旦溢出就全量出手。这种“悬崖式触发”已被证明体验极差。

2026 年的趋势是分层 + 渐进。各家产品正在走向不同的哲学：

• Claude Code：五段流水线，按成本递增排列
• Codex CLI：保留近期用户消息原文，其余替换为摘要
• Cursor：自动摘要 + 提示开新对话 + 历史可搜索
• MemGPT/Letta：上下文 = RAM，历史 = 磁盘，Agent 自主换入换出

6.2 模型层面的效率优化

DEPO 和 SkillReducer 的工作表明，效率优化正在从“工程技巧”走向“模型训练” 。通过在训练阶段引入效率偏好，可以在不牺牲质量的前提下大幅降低推理成本。

6.3 端云协同与记忆工程

2026 年 5 月的 GAIR Live 讨论了两种架构级路径：

• EdgeClaw：通过“端云协同”的物理分级，从架构源头切断无效 Token 消耗
• MemTensor：通过“记忆工程”，在既有架构下通过精细化状态管理榨取极限效率

6.4 Loop Engineering 的兴起

2026 年兴起的第四代 AI 工程范式——Loop Engineering——构建“目标→执行→验证→修正→再执行”的自主闭环。它直面 Token 爆炸痛点，结合 SDD 规范实现上下文收敛与成本可控。

结语：Token 成本是架构问题，不是模型问题

回顾全文，我们可以得出一个明确的结论：Agent 的 Token 成本本质上是一个架构问题，而不是模型选择问题。

换一个更便宜的模型，可能只降低 20%-30% 的单价。但通过合理的 Intermediate Steps 裁剪、上下文压缩、缓存策略和框架选型，可以实现 50%-78% 的总成本降低——而且质量不降反升。

给读者的三条实战建议：

1. 先测量，再优化。部署 LangSmith 或类似工具，花一周时间了解你的 Agent 到底把 Token 花在了哪里。
2. 从中间件开始。Axor 或 agent-cost-guardrails 可以在不改动业务代码的情况下快速见效。
3. 不要追求“零成本” 。Token 成本是 Agent 能力的代价，目标是单位成功成本最小化，而不是 Token 消耗最小化。

2026 年 6 月 25 日，于昌吉。 当你的 Agent 还在为每一轮对话背负着昨天的日志、上个月的搜索结果、以及三个星期前的中间推理时——是时候给它减负了。