降低 Agent 成本，先整理工作环境

Agent 的 token 账单压不住，先换小模型，还是继续改提示词？这篇文章提出第三条路：整理它每天工作的环境。把原始文件、API 返回值和数据库结构变成容易查找、按需读取的信息，可能比继续调整模型更省钱。

原文援引 EnvOpt 的实验，报告了多组超过一半的成本降幅。对前端和全栈开发者，更有用的是它指出了一类隐性开销：Agent 还没开始解决问题，就已经花了大量 token 搞清楚文件在哪、接口怎么用、数据之间有什么关系。

为什么还没开始干活，token 就花掉了

原文把常见的降本方式分成两类。一类是换模型，例如把前沿模型上的任务交给 8B 开放权重模型，或者训练路由器，为不同步骤选择模型。另一类是调整执行框架（harness）：重写系统提示词、要求结构化输出、增加逐步反思规则。

作者认为，两条路都会较快遇到收益递减。小模型可能遗漏细微上下文，处理不好多步工具调用；提示词规则则会增加每轮输入的长度。这个判断有工程上的合理性，但原文没有提供足以覆盖不同团队的对照数据，不能据此断定换模型和改提示词都不划算。

文章真正想追问的是：交给 Agent 的工作环境，是否值得先整理？

它援引的 EnvOpt 研究聚焦于「稳定环境」（stationary environments）。这里的稳定，指的是底层资料在一批任务之间相对固定：编码 Agent 反复访问同一个大型仓库，客服助手反复搜索同一个 Slack 工作区，数据 Agent 反复查询同一套数仓结构。

同一批资料会被反复使用，整理一次才有机会持续回本。

按原文描述，主要浪费来自环境反馈，也就是工具返回的大段原始文本、臃肿 JSON 和冗长错误信息。Agent 为了找一个工单 ID、函数签名或表结构发起探索，结果拿回一堆无关内容；如果后续轮次继续携带这些内容，成本还会累积。

工具调用次数少，不等于 token 成本低；每次调用返回什么，同样关键。

EnvOpt 整理的不是提示词，而是信息入口

原文引用的论文名为《EnvOpt: Automated Optimization for Agent Environments》，编号为 arXiv:2611.07372。按文中描述，EnvOpt 使用一个自动化研究 Agent，针对给定任务集合调整环境的呈现方式，再通过任务表现检验改动，不要求人工标注的参考答案。

它做的事情并不玄：重组数据、编写辅助程序、生成本地速查表、收紧工具接口。原文重复列出了几组相同段落，去重后主要是四种做法。

第一种是预解析复杂文件。辅助脚本把原始表格、多部分邮件整理成干净文本，只保留发件人、主题、消息 ID 和相关正文片段。目标 Agent 直接读取结果，省去反复尝试解析文件的过程。这里的关键是保留任务需要的信息，而不是单纯把文件变短。

第二种是生成静态 API 速查表。针对常见 Jira、Slack 和财务操作，把准确的命令结构与参数说明放在本地，减少调用 api_search、api_fetch 查找接口用法的轮次。它适合重复使用、接口相对稳定的动作；接口变化后如何更新，原文没有说清。

第三种是建立文件索引。用一个扁平文件记录路径、大小和类别，Agent 可以先用一次 grep 找候选文件，减少通过 find、ls 逐层探索目录的需要。索引负责回答「该去哪找」，正文仍然按需读取。

第四种是建立本地 SQLite 元数据缓存。把表定义、上游依赖和写入目标做成可查询的数据，让 Agent 用一条有针对性的 SQL 查询追踪关系，减少逐个读取 dbt SQL 模型的过程。

这四种做法共享一个方向：把原本需要模型临场摸索的事情，提前交给确定性的程序处理。

成本降了多少，哪些数字不能直接照搬

原文报告，在 AutomationBench 上，优化环境后，Claude Haiku 4.5 的 token 成本下降 72.7%，通过率提高 14.34%。同一优化环境迁移给 Claude Opus 5 后，运行成本下降 68.1%，准确率提高 1.34%。

环境优化与执行框架优化还能叠加。按原文说法，在 Meta-Harness 基础上进一步优化环境，Haiku 4.5 的成本再降 83.4%，准确率比单用 Meta-Harness 提高 11.17%。在考察复杂 dbt 数据工程任务的 Data-Eng-Bench 上，token 开销下降 53.44%，通过率没有损失。

这些数字支持了原文的方向：至少在它描述的实验里，环境整理可以降低成本，并保持甚至改善任务表现。但阅读时需要分清口径。

首先，文中的通过率和准确率「提高百分之多少」，没有交代是相对增幅，还是提高了多少个百分点，不能自行改写。其次，83.4% 的比较基线是 Meta-Harness，不能把它与 72.7% 直接相加。再次，原文混用了 token 成本、运行成本和 token 开销，没有展开计价方式，也没有交代环境优化本身的投入。

标题中的「70% More Cost」也缺少清楚的统一比较基线。不能把它理解成「比换模型额外节省 70%」。

这里只能把这些结果作为原文转述的实验报告。给定材料没有提供完整实验表格、任务规模和统计信息，论文及模型名称也未在此独立核验，因此不足以据此估算自己项目的收益。

我的判断

我认同先检查信息入口。原文举的两个信号很具体：Agent 要执行四条 shell 命令才能知道哪些文件相关，或者读完 400 行 JSON 才找到两个 ID。这类开销通常值得先排查。

但整理环境也可能越帮越忙。原文记录了三种失败，恰好说明「给更多资料」和「给更有用的资料」之间差别很大。

一种是超级参考文件：把数据库每列所有可能值集中列出，反而诱发更多猜测性探索。另一种是搜索助手返回范围过宽，相关文件旁边又带出一批相邻文件，Agent 随后逐个阅读，增加成本和耗时。还有一种是验证脚本死盯特定代码模式，在未见过的问题上拒绝了有效的替代补丁，迫使 Agent 进入恢复循环。

好的环境优化，应当减少无效探索，同时保留解决问题的空间。

和调整提示词相比，索引、解析器、元数据查询能把重复工作固定下来，效果更容易检查。和换小模型相比，它先减少任务中的信息噪声，但不能保证小模型因此具备复杂推理能力。原文也没有证明它在所有场景中都优于这两种替代方案。

适用前提仍然重要。仓库和接口频繁变化，就需要维护索引与速查表；任务彼此差异很大，预整理资料的命中率可能下降。一次性任务能否覆盖整理成本，更要单独计算。作者提出「先看环境」很有启发，具体收益仍应由自己的任务集验证。

能拿来做什么

• 给前端或 Node 仓库的编码 Agent 留一份精简索引，记录模块路径、用途和入口文件，让它先定位再读代码，并在目录调整后同步更新。
• 对反复出现的 API 操作整理本地速查表，保留准确的参数和命令结构；对冗长返回值，用辅助程序提取当前任务必需的字段，同时保留追查原始结果的入口。
• 如果 Agent 经常在 dbt 项目中追踪依赖，可以尝试把表定义、上游关系和写入目标存入 SQLite，让查询代替逐文件翻阅。
• 选一组有代表性的重复任务，比较整理前后的 token 用量、通过率和执行时间，并计入索引生成与维护成本。评估失败案例时，也要检查是否出现候选文件过多、资料过载或校验规则误拒有效方案的问题。