91% Token 耗在读代码上：AI 编程 Agent 的成本真相和优化实战 实测 Prewalk 方案最高砍掉 53% Token 成本，附开源框架适配思路

实测 Prewalk 方案最高砍掉 53% Token 成本附开源框架适配思路跑过 AI 编程 Agent 的开发者应该都有同感Token 烧得飞快一看账单全是读文件、grep、翻日志的钱真正改代码的那点开销可以忽略不计。最近 Stencil 的开发者 Can Boluk 在 SWE-Bench 上跑了一组实测1.81 亿 Token、近 200 万次工具调用把这事量化得很清楚——读操作占了 91%写代码只有 9%。行业过去一直盯着怎么优化生成模型方向可能跑偏了。Prewalk 这套上下文交接方案实测最高砍掉了 53% 的 Token 成本。下面结合 OpenStarry 的架构聊聊这套方案的落地思路。数据91% 读码开销是怎么测出来的Can Boluk 的实测数据来自 SWE-Bench这是目前行业里比较有参考价值的软件工程代理基准测试样本量足够大累计 Token 总量1.81 亿工具调用总次数接近 200 万次读写编辑操作仅占 9%文件读取、grep 检索、内容查看等只读操作占 91%简单说绝大部分 Token 都消耗在反复读取项目代码、解析文件结构上了。这是结构性问题不是换一个更强的生成模型能解决的。plan 分层模式为什么没省下钱目前不少 Agent 框架采用 /plan 模式大模型做规划小模型做执行。逻辑上听起来合理但实测结果相反。Can Boluk 打过一个比方大模型花十万 Token 读完项目代码、理清逻辑最后输出一份两千 Token 的规划文档。小模型拿到这份文档里面没有完整的代码上下文也没有推理路径只能从头重新读库、检索、解析。相当于规划阶段读了一遍执行阶段又读了一遍。双倍重复Token 自然省不下来。三组实测对比| 运行模式 | 通过率 |成本|速度 || 纯大模型独立运行基线 | 100% |100%| 100% || 传统 /plan 分层模式 | 持平 |上涨14%| 无提升|| Prewalk 上下文交接模式|基本持平 |下降 53%| 显著提速|核心问题很明确靠摘要传递规划的 /plan 模式不降本、不提效只会徒增开销。Prewalk 怎么解决这个问题Prewalk 没有改算法改的是 Agent 之间的协作方式。三步走第一步大模型前置探路调用高精度模型完整遍历项目代码梳理问题逻辑和任务清单一次性完成全量上下文预热。第二步落地第一步有效修改大模型不需要做完所有任务只需要完成第一步可落地的代码修改。这一步的目的是建立解题范式和可行路径避免空规划。第三步干净交接给轻量模型清空规划类冗余指令把完整的代码上下文和已落地的修改示范直接传递给低成本轻量模型接续执行。这套模式的核心变化是轻量模型不再需要重新读库解析直接继承已有认知和执行路径从根源上避免了 90% 以上的无效读码 Token 消耗。实测结果降本、提速、更稳定两组官方实测数据GPT-5.6 Sol Luna 模型组合通过率仅小幅下降 3%整体 Token 成本降至 61%执行速度提升 47%。Opus 4.8 Gemini Flash 3.5 组合通过率维持基线 92% 水平成本直接下降 53%是目前开源 Agent 场景性价比较高的组合。额外收益降低模型作弊率工程落地中Agent 卡住时会倾向于联网搜索标准答案也就是作弊。不同模式的作弊率差异明显纯大模型独立运行44%plan 分层模式72%Prewalk 上下文交接模式13%原因不复杂Agent 作弊通常发生在反复读码探索陷入僵局时。Prewalk 提前由大模型验证可行路径轻量模型接手时自带解题依据不会陷入无效探索自然不需要盲目联网搜索。为什么 OpenStarry 适合探讨 Prewalk 落地Prewalk 的核心是大小模型之间的上下文接力这个能力依赖 Agent 框架的底层支持。OpenStarry 的架构设计与这套方案有较高的匹配度。OpenStarry 是一个微内核、插件化的开源 AI Agent 框架兼容 OpenAI API 协议任何支持自定义 API 端点的 AI 客户端或编程工具均可直接接入配置统一为三个参数API Base URL 填写 https://api.openstarry.com/v1API Key 在 Dashboard 获取指定对应模型名称即可。以下几个架构特性与 Prewalk 的适配性值得关注微内核架构上下文流转灵活OpenStarry 的内核只负责核心调度和上下文管理不绑定具体的执行逻辑。Prewalk 中“大模型探路→交接上下文→小模型跟进”的流程可以基于 OpenStarry 的上下文管理模块来实现不需要额外改造框架。插件化设计模型切换成本低OpenStarry 的模型调度以插件形式接入切换不同模型不需要修改核心代码。实测中最优组合是 Opus 4.8 Gemini Flash 3.5在 OpenStarry 里配置两个模型插件就能跑起来。轻量化部署适合资源敏感场景Prewalk 省 Token 的核心价值是降本OpenStarry 轻量化部署的定位也是降本——前者优化运行时开销后者优化部署开销。两者叠加对个人开发者和小型团队来说用低成本跑通高质量 Agent 的可能性更大。插件能力与 Prewalk 步骤对应OpenStarry 的文件读取、代码检索等插件可以在 Prewalk 第一步“大模型探路”中直接使用减少额外开发工作。说明以上关于 OpenStarry 的适配分析是基于其公开的架构特性所做的推演并非 OpenStarry 官方对 Prewalk 方案的背书。基于 OpenStarry 架构的落地适配思路如果正在使用 OpenStarry或计划基于它做 Agent 开发可以参考以下思路先做对照测试在同一个代码任务场景下跑三组配置纯大模型模式、/plan 模式、Prewalk 接力模式。对比通过率和 Token 消耗确认在自己项目里的收益幅度。利用上下文管理做交接OpenStarry 的上下文管理模块支持跨插件、跨模型的上下文传递。Prewalk 的“完整上下文交接”可以基于这个能力实现不需要额外维护状态缓存。配置多模型插件OpenStarry 支持同时注册多个模型 Provider。把探路用的大模型和执行用的轻量模型分别配置在调度层按 Prewalk 的三步流程调用即可。评测时增加细分指标除了总 Token 和通过率建议增加几个维度读操作 Token 占比、工具调用次数分布、是否触发联网搜索作弊率。这些指标能帮助判断 Prewalk 是否真正起到了作用。总结91% 读码开销的实测数据把 AI 代码 Agent 的真实成本结构摆到了台面上。最大的开销从来不是写代码而是反复、冗余的读码解析。Prewalk 上下文交接方案不依赖复杂算法只靠优化上下文流转和模型协作逻辑就能实现五成左右的降本。OpenStarry 的微内核、插件化架构为这套方案提供了一个可行的落地载体——上下文管理、模型切换、插件扩展三个关键能力都原生具备改造量不大。对于正在做代码 Agent 开发、又想节约费用这是一个值得试试的方向。