2026/8/4 12:46:54
FEATURED · 精选文章 
Agent 怎么省 Token别只换便宜模型先堵住上下文里的四个漏水点系列专栏【打造你自己的 Agent】第 3 篇摘要本文系统分析了 Agent 开发中 Token 消耗的四大“漏水点”及优化策略1源头减量- 工具与技能按需加载、稳定内容前置、示例精炼2工具减量- 文件范围读取、长输出保留关键部分、搜索结果分步返回3过程控量- 接近阈值再压缩、子 Agent 隔离噪声、保留进行中工作4调用减量- 模型分层路由、任务批处理。文章强调真正的成本优化需关注任务总 Token、真实费用、成功率和交互回合数而非局部字符减少并介绍了 RTK 与 Caveman 两个补充工具的实际效果。Agent 的 Token 账单 工具定义 文件与日志 历史轨迹 模型输出 │ │ │ │ ▼ ▼ ▼ ▼ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │源头注入│ ───→ │工具返回│ ───→ │反复累积│ ───→ │解释汇报│ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ │ │ │ │ 按需加载 范围读取 压缩/隔离 简洁输出Token 就是钱但很多 Agent 不是“思考”贵而是上下文管理得太差。几十个工具的完整定义一次性塞进去读一个函数却把几千行文件全部搬进来测试输出刷了满屏任务跑到第十轮前九轮的搜索过程还背在身上。最后大家看到费用上涨第一反应却是换一个更便宜的模型。这像水管一直漏水却把水换成便宜品牌。真正有效的省 Token 工程核心只有一句话让模型在每一步只看到完成当前任务所需的最小信息集。如果你正在做 Agent、Coding Agent 或 MCP 工具链建议先收藏。下面按四个漏水点拆开讲源头怎么少注入工具结果怎么少返回长任务怎么少累积模型调用怎么少浪费。一、源头减量不需要的内容第一轮就别塞进去最便宜的 Token不是压缩后的 Token而是从未进入上下文的 Token。1. 工具与技能只放索引正文按需加载许多 Agent 一启动就把所有工具的名称、说明、参数 Schema 和示例全部放进系统提示词。十个工具问题不大接上几个 MCP 服务后工具定义可能比用户任务还长。更合理的做法像餐厅菜单先给模型看菜名和一句简介顾客点了某道菜再去后厨拿完整配方。传统方式 [工具A完整Schema][工具B完整Schema][工具C完整Schema] ... → 全部注入 按需方式 [A搜网页][B读文件][C跑测试] → 轻量索引 │ └─ 命中 B → 再加载 B 的完整说明Skill 也一样。系统提示词只保留名称和用途确定当前任务需要时再读取完整SKILL.md。这不是“少给模型能力”而是把能力从常驻内存改成按需分页。2. 稳定内容放前面变化内容放后面多数模型供应商的前缀缓存有一个朴素条件从开头起必须保持一致。假设系统规则长期不变项目状态每轮变化。如果把项目状态放在前面它只要改一个字符后面整段稳定规则也可能无法复用缓存。正确顺序 [系统规则][工具索引][固定示例] | [当前任务][项目状态][本轮记忆] └──────── 稳定前缀 ────────┘ └────── 易变尾部 ──────┘省 Token 不只是删字也包括让同一批字不要反复按原价付费。3. 示例贵精不贵多Few-shot 示例不是越多越好。两个覆盖不同边界的稳定示例通常比十个相似示例更有用。动态检索示例虽然看起来聪明却可能让每次请求的前缀都变化。对高频、稳定的任务类型固定少量优质示例反而更容易命中缓存也更容易测试。二、工具减量模型要的是结论不是整车原材料Agent 最容易失控的地方是工具结果。搜索命中一百处、读取一个五千行文件、运行十分钟测试——这些工具可以产生海量文本。但模型完成下一步往往只需要其中几十行。4. 文件按范围读取不要整份搬家如果问题出在第 420 行附近就先读 380460 行。结果带上行号并告诉模型文件还有多少行需要时怎样续读。read(file, offset380, limit80) 380: function validateToken(...) { 381: ... ... 459: } [还有 1240 行续读 offset460]这种设计有两个好处少用 Token同时保留精确定位。模型不必为了引用一个函数把整个文件背进上下文。5. 长输出保留“首、尾、错误”全文落盘构建与测试输出通常具有固定结构开头是环境信息中间大量重复过程结尾才是结果汇总。因此可以只返回前若干行命令、环境和启动信息错误附近真正失败的上下文后若干行通过/失败统计完整输出路径信息不足时再读取。┌─ 原始输出 6000 行 ───────────────────────────┐ │ [开头 30 行] ... [错误附近 80 行] ... [结尾 30 行] │ └──────────────────┬──────────────────────────┘ ▼ 返回 140 行 完整日志文件路径关键不是粗暴截断而是“先给最可能有用的部分同时保留回溯原件的能力”。6. 搜索先返回位置再读取内容代码搜索的第一步不必返回每个匹配点的完整上下文。先给文件名、行号和一行摘要模型选中候选后再读局部。这和搜索引擎相同结果页先给标题与摘要不会第一次查询就把十个网页全文粘到你脸上。如果你只记住这一节就记住这句话工具接口返回多少往往比提示词怎么写更决定 Token 成本。如果这种从工程接口而不是“提示词玄学”解决问题的方式对你有用可以关注我。这个系列会继续拆真实 Agent 的上下文、工具和验证回路。三、过程控量上下文满了再压但不要把线索一起压没即使入口控制得很好长任务跑上十几轮上下文仍会膨胀。此时需要压缩但压缩不是越早越好。7. 接近阈值再压缩最近几轮保留原文任务刚开始时Agent 正在收集线索。过早摘要可能把一个文件名、错误码或尚未验证的假设抹掉。更稳妥的策略是监控上下文占用接近窗口上限时再触发压缩早期轨迹最近两三轮保持原样。上下文使用率 0% ───────────────────────── 80% ───────── 100% 保留原始轨迹 触发压缩 压缩后 [早期摘要][关键标识符][未完成TODO] | [最近3轮原文]摘要必须保留不能出错的“硬信息”文件路径、URL、UUID、Hash、命令、错误码、未完成 TODO 和回滚点。普通叙述可以改写标识符不能靠模型“差不多记得”。8. 让子 Agent 隔离噪声有些任务天生会制造大量中间信息例如在大型代码库里寻找认证逻辑阅读几十个文件比较实现调研多个依赖与版本差异分析一份很长的日志。与其让主 Agent 亲自翻完整个垃圾堆不如派一个子 Agent 去做。子 Agent 在自己的上下文里搜索、试错最后只返回结论、证据位置和风险。主 Agent 上下文 │ ├─ 委派“找到登录校验入口” ─────────┐ │ ▼ │ 子 Agent 上下文 │ 读 20 文件 / 搜索 / 排除 │ │ └──── 返回 300 Token 结论 ◀─────────┘主上下文只增加“任务描述 最终结论”几万 Token 的探索过程随着子任务结束被隔离。这里省下的不只是一次输入而是后续每一轮都不再背着那些中间噪声。9. 不要压缩仍在推进的工作已经完成、不会再引用的工具结果可以删除稳定结论可以摘要正在排查的错误、尚未完成的修改和最近工具结果应当保留。成熟的压缩不是“一键把历史变短”而是根据信息生命周期分层信息类型处理方式未完成 TODO、错误码、文件路径原样保留已验证结论、普通工具输出摘要已完成且无后续价值的中间过程删除四、调用减量别让最贵的模型处理最简单的事上下文优化解决“每次调用有多大”调用策略解决“为什么要这样调用”。10. 模型分层路由分类、格式转换、简单检索和参数抽取不一定需要最强模型。复杂规划、跨文件修改和关键代码审查再交给高能力模型。简单任务 ──→ 小模型 / 快模型 复杂任务 ──→ 强模型 失败或低置信度 ──→ 升级模型重试但分层路由不能只看模型价格。小模型如果理解失败、多跑五轮可能比强模型一次完成更贵。路由应同时参考任务类型、历史成功率和升级次数。11. 能批处理的任务不要实时逐条调用日志归类、批量摘要、离线索引、测试报告整理通常不要求秒级返回。把它们积攒后批量处理可以减少请求开销也可能使用供应商的批处理折扣。同样的原则也适用于工具一次读取十个明确的小片段往往比来回调用十次更省但一次读取十个完整大文件又会回到“整车原材料倒进上下文”的老问题。五、怎么判断自己真的省到了最容易制造幻觉的指标是“压缩前后字符差”。它只能证明某一步变短不能证明任务总成本下降。至少同时记录四项总 Token整个任务而不是某个命令真实费用区分缓存读取、新输入和输出价格任务成功率省钱不能以做错为代价交互回合数信息不足导致重试会吃掉全部收益。正确的评估方式是同一批任务做配对实验一组使用优化一组保持原样模型、推理强度、任务和验证标准相同。不要相信一次漂亮 Demo也不要只看优化工具给自己打的分。局部少了多少字不重要完成同一个任务最终少花多少钱才重要。六、两个可以直接尝试的补充工具RTK 与 Caveman如果暂时不想自己改 Agent Harness可以从两个现成项目理解“入口”和“出口”如何减量。RTK压缩进入模型的终端输出RTK位于命令行与 Agent 之间对git、测试、构建和日志等输出去重、截断、摘要并在失败时保留完整原文供回溯。终端原始输出 ──→ [ RTK 过滤 ] ──→ 紧凑工具结果 ──→ Agent它解决的是输入侧问题。但它只能压缩自己能拦截的命令Agent 内置的文件读取和搜索工具可能绕过它。RTK 官方宣称常见命令可减少 60%90% Token。JetBrains 在真实 Agent 配对测试中却测到低推理强度下总体成本中位数增加7.6%高推理强度下基本持平。局部过滤有效不代表整次任务一定省钱。Caveman压缩模型自己的自然语言Caveman让 Agent 使用短句、先给结论删除客套、复述和重复总结同时保持代码、命令、文件名与错误信息精确。普通“这个问题最可能是因为每次创建了新的对象引用……” Caveman“新对象导致引用变化。用 useMemo。”它解决的是输出侧问题。官方宣称节省 65% 输出 TokenJetBrains 在真实 Agent 任务中测得约8.5%且没有检测到明显质量下降。有效但属于补充优化因为 Coding Agent 的大头往往是代码和工具调用而不是解释文字。二者可以这样理解RTK Caveman 少给模型看垃圾 少让模型说废话 │ │ └──────── 都要看总账单 ──────┘它们是省 Token 工程的两块现成补丁不是整套工程本身。真正的大头仍然是前面五节按需注入、范围读取、轨迹压缩、上下文隔离和调用分层。我在开源项目 ResceneAgent 中实践的也是这条原则不让模型勉强吞下整个世界只给它完成当前一步所必需的信息。项目只在这里出现一次因为源码不是广告插页而是让上述方法接受检验的地方。如果你想继续看这些真实 Agent 工程实践关注我。下一篇会专门拆解 Agent Harness怎样用审批、隔离和验证让模型不仅少看还只做该做的事。想直接看实现再去 GitHubRescenix/ResceneAgent。引用来源RTK 官方仓库与接入说明Caveman 官方仓库与工作原理JetBrainsRTK 真实 Agent 配对测试JetBrainsCaveman 真实 Agent 配对测试
【Agent 怎么省 Token？别只换便宜模型，先堵住上下文里的四个漏水点】
Agent 怎么省 Token别只换便宜模型先堵住上下文里的四个漏水点系列专栏【打造你自己的 Agent】第 3 篇摘要本文系统分析了 Agent 开发中 Token 消耗的四大“漏水点”及优化策略1源头减量- 工具与技能按需加载、稳定内容前置、示例精炼2工具减量- 文件范围读取、长输出保留关键部分、搜索结果分步返回3过程控量- 接近阈值再压缩、子 Agent 隔离噪声、保留进行中工作4调用减量- 模型分层路由、任务批处理。文章强调真正的成本优化需关注任务总 Token、真实费用、成功率和交互回合数而非局部字符减少并介绍了 RTK 与 Caveman 两个补充工具的实际效果。Agent 的 Token 账单 工具定义 文件与日志 历史轨迹 模型输出 │ │ │ │ ▼ ▼ ▼ ▼ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │源头注入│ ───→ │工具返回│ ───→ │反复累积│ ───→ │解释汇报│ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ │ │ │ │ 按需加载 范围读取 压缩/隔离 简洁输出Token 就是钱但很多 Agent 不是“思考”贵而是上下文管理得太差。几十个工具的完整定义一次性塞进去读一个函数却把几千行文件全部搬进来测试输出刷了满屏任务跑到第十轮前九轮的搜索过程还背在身上。最后大家看到费用上涨第一反应却是换一个更便宜的模型。这像水管一直漏水却把水换成便宜品牌。真正有效的省 Token 工程核心只有一句话让模型在每一步只看到完成当前任务所需的最小信息集。如果你正在做 Agent、Coding Agent 或 MCP 工具链建议先收藏。下面按四个漏水点拆开讲源头怎么少注入工具结果怎么少返回长任务怎么少累积模型调用怎么少浪费。一、源头减量不需要的内容第一轮就别塞进去最便宜的 Token不是压缩后的 Token而是从未进入上下文的 Token。1. 工具与技能只放索引正文按需加载许多 Agent 一启动就把所有工具的名称、说明、参数 Schema 和示例全部放进系统提示词。十个工具问题不大接上几个 MCP 服务后工具定义可能比用户任务还长。更合理的做法像餐厅菜单先给模型看菜名和一句简介顾客点了某道菜再去后厨拿完整配方。传统方式 [工具A完整Schema][工具B完整Schema][工具C完整Schema] ... → 全部注入 按需方式 [A搜网页][B读文件][C跑测试] → 轻量索引 │ └─ 命中 B → 再加载 B 的完整说明Skill 也一样。系统提示词只保留名称和用途确定当前任务需要时再读取完整SKILL.md。这不是“少给模型能力”而是把能力从常驻内存改成按需分页。2. 稳定内容放前面变化内容放后面多数模型供应商的前缀缓存有一个朴素条件从开头起必须保持一致。假设系统规则长期不变项目状态每轮变化。如果把项目状态放在前面它只要改一个字符后面整段稳定规则也可能无法复用缓存。正确顺序 [系统规则][工具索引][固定示例] | [当前任务][项目状态][本轮记忆] └──────── 稳定前缀 ────────┘ └────── 易变尾部 ──────┘省 Token 不只是删字也包括让同一批字不要反复按原价付费。3. 示例贵精不贵多Few-shot 示例不是越多越好。两个覆盖不同边界的稳定示例通常比十个相似示例更有用。动态检索示例虽然看起来聪明却可能让每次请求的前缀都变化。对高频、稳定的任务类型固定少量优质示例反而更容易命中缓存也更容易测试。二、工具减量模型要的是结论不是整车原材料Agent 最容易失控的地方是工具结果。搜索命中一百处、读取一个五千行文件、运行十分钟测试——这些工具可以产生海量文本。但模型完成下一步往往只需要其中几十行。4. 文件按范围读取不要整份搬家如果问题出在第 420 行附近就先读 380460 行。结果带上行号并告诉模型文件还有多少行需要时怎样续读。read(file, offset380, limit80) 380: function validateToken(...) { 381: ... ... 459: } [还有 1240 行续读 offset460]这种设计有两个好处少用 Token同时保留精确定位。模型不必为了引用一个函数把整个文件背进上下文。5. 长输出保留“首、尾、错误”全文落盘构建与测试输出通常具有固定结构开头是环境信息中间大量重复过程结尾才是结果汇总。因此可以只返回前若干行命令、环境和启动信息错误附近真正失败的上下文后若干行通过/失败统计完整输出路径信息不足时再读取。┌─ 原始输出 6000 行 ───────────────────────────┐ │ [开头 30 行] ... [错误附近 80 行] ... [结尾 30 行] │ └──────────────────┬──────────────────────────┘ ▼ 返回 140 行 完整日志文件路径关键不是粗暴截断而是“先给最可能有用的部分同时保留回溯原件的能力”。6. 搜索先返回位置再读取内容代码搜索的第一步不必返回每个匹配点的完整上下文。先给文件名、行号和一行摘要模型选中候选后再读局部。这和搜索引擎相同结果页先给标题与摘要不会第一次查询就把十个网页全文粘到你脸上。如果你只记住这一节就记住这句话工具接口返回多少往往比提示词怎么写更决定 Token 成本。如果这种从工程接口而不是“提示词玄学”解决问题的方式对你有用可以关注我。这个系列会继续拆真实 Agent 的上下文、工具和验证回路。三、过程控量上下文满了再压但不要把线索一起压没即使入口控制得很好长任务跑上十几轮上下文仍会膨胀。此时需要压缩但压缩不是越早越好。7. 接近阈值再压缩最近几轮保留原文任务刚开始时Agent 正在收集线索。过早摘要可能把一个文件名、错误码或尚未验证的假设抹掉。更稳妥的策略是监控上下文占用接近窗口上限时再触发压缩早期轨迹最近两三轮保持原样。上下文使用率 0% ───────────────────────── 80% ───────── 100% 保留原始轨迹 触发压缩 压缩后 [早期摘要][关键标识符][未完成TODO] | [最近3轮原文]摘要必须保留不能出错的“硬信息”文件路径、URL、UUID、Hash、命令、错误码、未完成 TODO 和回滚点。普通叙述可以改写标识符不能靠模型“差不多记得”。8. 让子 Agent 隔离噪声有些任务天生会制造大量中间信息例如在大型代码库里寻找认证逻辑阅读几十个文件比较实现调研多个依赖与版本差异分析一份很长的日志。与其让主 Agent 亲自翻完整个垃圾堆不如派一个子 Agent 去做。子 Agent 在自己的上下文里搜索、试错最后只返回结论、证据位置和风险。主 Agent 上下文 │ ├─ 委派“找到登录校验入口” ─────────┐ │ ▼ │ 子 Agent 上下文 │ 读 20 文件 / 搜索 / 排除 │ │ └──── 返回 300 Token 结论 ◀─────────┘主上下文只增加“任务描述 最终结论”几万 Token 的探索过程随着子任务结束被隔离。这里省下的不只是一次输入而是后续每一轮都不再背着那些中间噪声。9. 不要压缩仍在推进的工作已经完成、不会再引用的工具结果可以删除稳定结论可以摘要正在排查的错误、尚未完成的修改和最近工具结果应当保留。成熟的压缩不是“一键把历史变短”而是根据信息生命周期分层信息类型处理方式未完成 TODO、错误码、文件路径原样保留已验证结论、普通工具输出摘要已完成且无后续价值的中间过程删除四、调用减量别让最贵的模型处理最简单的事上下文优化解决“每次调用有多大”调用策略解决“为什么要这样调用”。10. 模型分层路由分类、格式转换、简单检索和参数抽取不一定需要最强模型。复杂规划、跨文件修改和关键代码审查再交给高能力模型。简单任务 ──→ 小模型 / 快模型 复杂任务 ──→ 强模型 失败或低置信度 ──→ 升级模型重试但分层路由不能只看模型价格。小模型如果理解失败、多跑五轮可能比强模型一次完成更贵。路由应同时参考任务类型、历史成功率和升级次数。11. 能批处理的任务不要实时逐条调用日志归类、批量摘要、离线索引、测试报告整理通常不要求秒级返回。把它们积攒后批量处理可以减少请求开销也可能使用供应商的批处理折扣。同样的原则也适用于工具一次读取十个明确的小片段往往比来回调用十次更省但一次读取十个完整大文件又会回到“整车原材料倒进上下文”的老问题。五、怎么判断自己真的省到了最容易制造幻觉的指标是“压缩前后字符差”。它只能证明某一步变短不能证明任务总成本下降。至少同时记录四项总 Token整个任务而不是某个命令真实费用区分缓存读取、新输入和输出价格任务成功率省钱不能以做错为代价交互回合数信息不足导致重试会吃掉全部收益。正确的评估方式是同一批任务做配对实验一组使用优化一组保持原样模型、推理强度、任务和验证标准相同。不要相信一次漂亮 Demo也不要只看优化工具给自己打的分。局部少了多少字不重要完成同一个任务最终少花多少钱才重要。六、两个可以直接尝试的补充工具RTK 与 Caveman如果暂时不想自己改 Agent Harness可以从两个现成项目理解“入口”和“出口”如何减量。RTK压缩进入模型的终端输出RTK位于命令行与 Agent 之间对git、测试、构建和日志等输出去重、截断、摘要并在失败时保留完整原文供回溯。终端原始输出 ──→ [ RTK 过滤 ] ──→ 紧凑工具结果 ──→ Agent它解决的是输入侧问题。但它只能压缩自己能拦截的命令Agent 内置的文件读取和搜索工具可能绕过它。RTK 官方宣称常见命令可减少 60%90% Token。JetBrains 在真实 Agent 配对测试中却测到低推理强度下总体成本中位数增加7.6%高推理强度下基本持平。局部过滤有效不代表整次任务一定省钱。Caveman压缩模型自己的自然语言Caveman让 Agent 使用短句、先给结论删除客套、复述和重复总结同时保持代码、命令、文件名与错误信息精确。普通“这个问题最可能是因为每次创建了新的对象引用……” Caveman“新对象导致引用变化。用 useMemo。”它解决的是输出侧问题。官方宣称节省 65% 输出 TokenJetBrains 在真实 Agent 任务中测得约8.5%且没有检测到明显质量下降。有效但属于补充优化因为 Coding Agent 的大头往往是代码和工具调用而不是解释文字。二者可以这样理解RTK Caveman 少给模型看垃圾 少让模型说废话 │ │ └──────── 都要看总账单 ──────┘它们是省 Token 工程的两块现成补丁不是整套工程本身。真正的大头仍然是前面五节按需注入、范围读取、轨迹压缩、上下文隔离和调用分层。我在开源项目 ResceneAgent 中实践的也是这条原则不让模型勉强吞下整个世界只给它完成当前一步所必需的信息。项目只在这里出现一次因为源码不是广告插页而是让上述方法接受检验的地方。如果你想继续看这些真实 Agent 工程实践关注我。下一篇会专门拆解 Agent Harness怎样用审批、隔离和验证让模型不仅少看还只做该做的事。想直接看实现再去 GitHubRescenix/ResceneAgent。引用来源RTK 官方仓库与接入说明Caveman 官方仓库与工作原理JetBrainsRTK 真实 Agent 配对测试JetBrainsCaveman 真实 Agent 配对测试 
