从"省着用"到"循环用"：Agent Token成本优化的逻辑重构与工程全景
摘要
大语言模型 Agent 正从实验室走向生产环境，Token 成本已成为制约其规模化的核心瓶颈。现有优化方案多聚焦于压缩、缓存与规划分离，但常出现"重输入轻输出""重缓存轻冷启动""将互补策略误作递进关系"等认知偏差。本文基于因果成本模型与任务分布理论，系统梳理 Agent Token 优化的真实杠杆、学术进展与工程落地路径，建立统一的成本归因框架。文章进一步提出"规划即文档"的架构范式，明确长上下文操作与文档化解析的决策临界点，并阐明"省着用"与"循环用"作为正交策略的互补关系------前者兜底一次性任务，后者收割高频场景，二者共同构成 Agent 系统经济性设计的完整拼图。
关键词：Agent、Token 成本优化、规划-执行分离、上下文压缩、计划缓存、成本归因
一、问题重定义：成本归因的第一性原理
1.1 Token 成本的结构性困境
大语言模型 Agent 正被广泛部署于软件工程、运营自动化、数据分析等复杂多步任务中。然而，当 Agent 从单轮问答走向多轮交互与长时程任务时，上下文长度的指数级膨胀迅速成为根本性瓶颈。
Agent 的"状态"并非由模型参数表征，而是由提示上下文构成：系统指令、演化中的计划、历史推理轨迹、工具调用结果、用户指令、长期记忆与检索知识。随着任务深度与广度的增加，这一状态日益庞大、冗余且昂贵。更为严峻的是，即便拥有 200k--1M token 窗口的模型，在处理结构不良或信息过载的上下文时，其推理质量亦会显著退化------业界称之为"上下文腐烂"（Context Rot）。现代 Agent 的失败，压倒性地是上下文失败，而非模型能力不足。
Token 成本优化由此成为 Agent 系统从实验室走向大规模生产的必答题。
1.2 成本公式与优先级倒置的纠正
Agent 系统的 Token 成本（C）可分解为三个核心变量：
C = Σ (i=1..N) [ p_in · l_in(i) + p_out · l_out(i) ]其中：
- N 为调用轮次
- l_in 、l_out 分别为输入/输出 Token 长度
- p_in 、p_out 为对应单价
真实 API 定价中，p_out ≈ 3 × p_in（如 GPT-4o：输入 5/1M tokens，输出 15/1M tokens）。由此可得成本优化的优先级排序：
- 减少调用轮次 ：同时节省
l_in + 3 × l_out的成本； - 控制输出长度：边际收益为等量输入的 3 倍；
- 压缩输入长度：虽可降低单次成本，但若引发轮次增加，则得不偿失。
因此，成本优化的第一杠杆永远是"减少调用轮次"，其次为"控制输出"，最后才是"压缩输入"。将"输入控制"置于首位，是对成本结构的根本误判。成本优化的本质是成本归因------先算清每一笔账，再决定使用何种工具。
二、学术视角：效率理论的真实贡献与边界
2.1 上下文压缩：信息密度的"不可能三角"
学术界聚焦于固定 Token 预算下的信息有效密度最大化。
- ACON：提出统一压缩框架，可将环境观测与交互历史压缩为信息凝缩，峰值 Token 减少 26%--54%，性能保持率达 95% 以上。
- PAACE：引入规划感知压缩，在 AppWorld 基准上取得最高准确率，蒸馏版本保留教师模型 97% 的性能。
- SimpleMem：基于语义无损压缩，实现 26.4% 的平均 F1 提升，推理 Token 消耗减少高达 30 倍。
- AgentDiet：通过移除冗余轨迹信息，将输入 Token 减少 39.9%--59.7%。
边界与局限：上述框架报告的 95%--97% 性能保持率为平均表现。在长尾异常日志、非标准系统报错等边缘案例中，压缩导致的信息熵损失往往引发性能断崖。压缩率与泛化能力的"不可能三角"依然存在------99% 的压缩率必然伴随不可逆信息损失。此外，PAACE 的规划感知压缩依赖"下一任务相关性建模"，需额外 LLM 调用；SimpleMem 的记忆构建依赖离线预计算，难以应对冷启动场景。
2.2 规划-执行分离：解耦的真实收益
ReAct（Reasoning + Acting）范式虽能提升任务性能，但以过量的工具调用、更长的轨迹和更高的 Token 消耗为代价。
Plan-then-Execute（P-t-E） 模式将战略规划与战术执行显式解耦：Planner 由推理能力强的模型承担，Executor 按计划逐步执行。P-t-E 的成本优势不仅在于"少调用"，更在于调用结构的优化------将 N 次复杂推理压缩为 1 次规划 + M 次轻量执行（M << N）。研究表明，角色分解的 Agent 团队持续占据成本-准确率的帕累托前沿，异构团队相比同构团队准确率可提升高达 44%，或以低至 1/12 的每任务成本达到同等性能。
Agentic Plan Caching（APC） 进一步将计划缓存引入测试时记忆，实现成本与延迟的显著降低------但收益高度依赖缓存命中率，未命中时还需支付检索与比对开销。
2.3 代码化执行：从"对话"到"编译"
CodeMem 提出将 LLM 重新定位为可执行工作流的架构师。Agent 在沙箱中编写、验证并将成功逻辑持久化为代码，将复杂逻辑从易失性上下文窗口转移到确定性代码中，解决了概率模型固有的可复现性危机。CodeAct（以 Python 代码作为 Action 空间）可将复杂操作压缩为单步执行，有助于保持上下文精简。
需澄清的是：代码化执行并非"零 Token 消耗"------处理 GB 级数据仍需在上下文中读取文件元数据或样本以编写代码。其真正价值在于：将多轮试错压缩为单轮生成，将消耗从执行时转移到规划时，并使代码可反复复用摊销成本。
三、工程视角：三大控制维度的落地实践
3.1 成本权重修正：轮次 ＞ 输出 ＞ 输入
工程落地应以成本权重为指导，而非 Token 体积：
| 维度 | 控制策略 | 单位成本系数 | 杠杆排序 |
|---|---|---|---|
| 调用轮次 | 规划-执行分离、并行工具调用、计划缓存 | l_in + 3 × l_out |
🥇 第一 |
| 输出量 | 结构化输出、截断、终止序列 | 3 × |
🥈 第二 |
| 输入量 | 摘要、截断、缓存读取 | 1 ×（缓存仅 0.1 ×） |
🥉 第三 |
特别注意：前缀缓存虽能将输入成本降至 0.1 倍，但仅对 System Prompt 及固定前缀生效，动态上下文不命中缓存。"缓存读取 Token 按 0.1 倍计算"不可泛化为"所有输入成本降低 90%"。
3.2 调用轮次：被低估的最大杠杆
减少轮次的具体工程手段包括：
- Orchestrator 模式 ：1 次规划 + 1 次总结 = 2 次调用，对比 ReAct 的 7 次调用，成本差距为
(7−2) × (l_in + 3 × l_out)。 - 并行工具调用：单次 Prompt 生成多个工具调用，一次 API 完成多个动作。
- 计划缓存：命中时直接将 3--5 轮试错压缩为 1 轮调用，但收益须乘以命中率。
- 最大重试阈值：约定最多自动重试 2 次，第 3 次失败后直接报告错误，避免无限循环。
3.3 控制输入：什么该进，什么不该进
System Prompt 固化与缓存：确保静态前缀稳定命中 API 的自动缓存，删除未使用的工具定义（每调用减少 8KB--12KB）。
数据与逻辑分离：
| 类型 | 处理方式 | 缩减率 | 重复出现概率 | 缓存策略 |
|---|---|---|---|---|
| 数据文件（日志、CSV） | 头尾截断/结构化提取/统计摘要 | 70%--90% | 低 | 绝不缓存 |
| 程序逻辑（脚本、命令） | AST 哈希去重/参数化泛化/工具缓存复用 | 95%+ | 高 | 值得投入缓存体系建设 |
分层隔离：执行工具只接收原子指令（动作 + 参数，≤200 Token），不携带对话历史、任务背景等上下文，单次调用降幅达 99%+。
3.4 控制输出：堵住终端的"废话管"
输出 Token 单价为输入的 3 倍，必须强力管控：
- 脚本层 ：要求输出结构化数据（JSON/CSV），强制添加输出截断（如
Select-Object -First 50），丢弃无用输出。 - API 层 ：设置
max_tokens为预期值的 1.5 倍，设置stop终止序列（如["\n\n", "```"]）强制刹车。 - Prompt 层：System Prompt 末尾加死命令："禁止开场白、禁止结束语、禁止解释过程，只输出最终结果。"
四、核心决策：长上下文工具操作 vs. 文档化解析
4.1 问题定义
一个频繁出现却鲜有定量回答的问题是：带着长上下文进行工具操作划算，还是先将其输出为文档、再让工具解析文档划算？
4.2 成本数学模型
设原始长上下文长度为 L （如 100k Tokens），每次工具调用输出为 O（固定 1k），输入单价为 1，输出单价为 3（相对值）。
方案 A（直接携带）：
Cost_A = N × (L × 1 + O × 3) = N × (L + 3O)方案 B（先输出文档，再解析）：
第一步生成摘要/结构化文档 D（D ≈ 5%~10% L），消耗一次输出；后续调用上下文变为极短的 D。
Cost_B = (L × 1 + D × 3) + N × (D × 1 + O × 3)代入 L = 100k, D = 5k, O = 1k：
| 调用次数 (N) | 方案 A | 方案 B | 结论 |
|---|---|---|---|
| 1 次 | 103k 单位 | 115k 单位 | A 更便宜（B 贵约 12%） |
| 2 次 | 206k 单位 | 128k 单位 | B 更便宜（B 节省约 38%） |
| 5 次 | 515k 单位 | 140k 单位 | B 碾压（B 节省约 73%） |
数学阈值 ：当 N ≥ 2 时，文档化策略开始展现优势；N ≥ 3 时优势极其显著。
4.3 被忽略的"缓存陷阱"与工程范式转移
有人会反驳："方案 A 可以利用前缀缓存，长上下文前 90% 固定，成本只算 10%。"------致命缺陷在于：前缀缓存要求前缀完全一致。多轮工具调用中，每次返回的观察结果不同，会破坏缓存连续性，命中率随轮次增加急剧下降。
文档化的优势在于将长上下文物理剥离出对话窗口，后续工具调用时 System Prompt 极短（可命中缓存），工具仅读取本地文件指针，彻底将数据从 Token 计费体系中移除。更进一步，方案 B 中生成的结构化文档（JSON/CSV）可由确定性算法零 Token 消耗解析------这正是 CodeMem 理念的落地：将"模糊的推理负担"转化为"确定的计算负担"。
4.4 实操黄金法则
- 一次性任务（≤2 次操作） → 直接带长上下文，成本最低，省去解析逻辑的维护成本。
- 长期运行任务（≥3 次迭代） → 采用文档化策略，从第二次起节约 70% Token 费，并将延迟从 15 秒降至 2 秒。
五、范式升级：规划即文档
5.1 从"额外生成"到"本职工作"
文档化策略引出一个更深层的洞察：在成熟的"规划-执行分离"架构中，AI 的标准规划输出本身就是"文档"，根本不需要"额外生成"一步。
Planner 的职责正是读取长上下文、输出一份结构化的执行清单（Plan），这份清单自然就是文本（JSON 或 Markdown）。Planner 输出 Plan 是本职工作，无论是否需要工具操作都必须完成。将这份现成的 Plan 复用为文档，边际成本为 0------这比"多调一次 API 专门写摘要"要高明一个维度。
5.2 从"传递文本"到"传递指针"
- 旧思维（拷贝）：将长文本压缩为摘要，再塞入下一次 Prompt------摘要依然消耗 Input Token。
- 新思维（指针） ：Planner 输出 Plan 后，通过函数返回 Plan ID 或文件路径传给 Executor------上下文仅为"请根据
/tmp/plan.json执行" ≈ 20 Token，从 L 降至 O(1)。
5.3 格式决定成败
| Plan 格式 | Executor 解析方式 | 成本 |
|---|---|---|
| 散文式 Plan | 仍需消耗大量 Token 理解 | 极高 |
| 结构化 JSON Plan | 只解析键值对 | 极低 |
| 可执行代码（CodeMem 模式） | 工具直接运行代码，不再调用 LLM 解析 | 归零 |
5.4 唯一需要"额外生成"的反例
当长上下文是"待操作的原始数据池"（如 10 万行日志），而非"待执行的任务说明"时，Planner 无法将全部数据写入 Plan，只能输出"数据切片指针"（如 grep "Error" | head -50）。若工具返回的结果仍需格式化为精简的"中间证据文档"供下一轮推理使用，这才需要"额外生成"------但这属于状态管理范畴，与规划文档化是两回事。
六、"省着用"与"循环用"：正交策略而非线性演进
6.1 错误二分法的纠正
"省着用"（压缩/截断）与"循环用"（缓存/复用）并非递进关系，而是面向不同任务分布的正交工具箱：
| 策略 | 适用场景 | 核心机制 | 冷启动成本 | 边际收益 |
|---|---|---|---|---|
| 省着用 | 一次性任务、长尾探索 | 降低单次调用的输入/输出 Token | 无 | 线性递减 |
| 循环用 | 高频重复任务、标准化流程 | 将成功经验固化为可复用资产 | 高（首次编写/泛化） | 指数摊销 |
6.2 二者不可相互替代
- 若 Agent 面对的全是一次性任务，缓存命中率趋近于 0，"循环用"的构建成本无法回收。
- 若面对的是标准化运维操作（如"查昨日错误日志 Top10"），"循环用"可将每次数千 Token 的调用压缩为哈希查找 + 确定性执行。
合理的架构应为混合策略：对任务请求进行路由分类------高频任务走缓存执行路径，长尾任务走动态生成路径，二者共享底层的压缩与截断能力作为兜底。
6.3 能力飞轮：从"动态生成"到"条件固化"
将一次性成功经验转化为可复用资产，需经过四个前置判断：
- 重复性检测：计算任务指纹（AST 哈希/意图向量），查询缓存库------命中则直接复用。
- 参数化泛化：将硬编码路径、IP 等替换为变量，使脚本从"针对某实例"升维为"针对某类问题"。
- 入库阈值判定：若该任务类型在过去 30 天内出现 ≥3 次，才封装为工具入库------避免"一次性逻辑"污染缓存库。
- 动态检索：调用时通过向量检索召回 Top-3 最相关工具注入上下文，避免全量工具列表撑爆 System Prompt。
核心原则：不是所有成功经验都值得固化，只有高频且稳定的模式才应进入复用池。
七、结语：成本优化的本质是成本归因
Agent 的 Token 成本优化，正在从"提示词工程"走向"系统工程"。系统工程的起点不是"用什么技术"，而是"算清每一笔账"：
- 成本权重决定了优化优先级：轮次 ＞ 输出 ＞ 输入；
- 任务分布决定了策略选择：高频走缓存，长尾走压缩，二者并行不悖；
- 性能报告必须附带边缘案例表现与冷启动开销，否则"95% 性能保持"只是平均数的胜利；
- 架构设计应将规划输出本身视为可复用文档，避免"额外生成"的无谓消耗；
- 缓存策略必须挂钩命中率，未命中的缓存只是纯粹的系统开销。
最终，Agent 成本优化的本质不是让模型"少说话"，也不是让系统"变聪明"，而是让每一笔 Token 支出都经得起成本-收益核算------把高频成功经验转化为确定性资产，对一次性任务务实压缩，既不盲目崇拜缓存，也不否定压缩的价值。让 Agent 从"事必躬亲的执行者"进化为"运筹帷幄的调度者"，让每一次 Token 支出都用在刀刃上。这才是工程落地应有的理性姿态。
关键决策速查表
| 场景 | 推荐策略 | 核心动作 |
|---|---|---|
| 一次性任务（≤2 次操作） | 直接携带长上下文 | 省去解析逻辑维护成本 |
| 多轮迭代（≥3 次操作） | 文档化解析 | 生成结构化文档供后续零 Token 解析 |
| 高频标准化任务 | 循环用（缓存/复用） | 哈希去重 + 参数化泛化 + 工具入库 |
| 长尾探索任务 | 省着用（压缩/截断） | 头尾截断、结构化提取、统计摘要 |
| 规划-执行架构 | 规划即文档 | Planner 输出 JSON Plan，Executor 只读指针 |
| 代码化执行 | CodeMem / CodeAct | 将试错循环压缩为单轮代码生成 |