Code Mode砍掉99.2%成本

AI Agent 的下一轮降本，可能不再依赖更便宜的模型，而是直接重写工具调用链。

近日，Agent Swarm 在一篇题为《Code mode yields a 99.2% cost reduction in our systems》的文章中称，引入 Code Mode 后，其系统成本降低了 99.2%。换算一下，新方案只保留原成本的 0.8%；如果统计口径一致，相当于完成同类任务所需成本缩小至原来的 1/125。

这个数字足够夸张，也需要谨慎理解。文章标题特意使用了“in our systems”，意味着它是特定工作负载、模型、工具数量和计费方式下的系统结果，而不是所有 Agent 都能复现的行业基准。

但方向比数字更值得关注：Agent 正从“模型逐步遥控工具”，转向“模型生成一段程序，由运行时集中执行工具”。

Code Mode 不是代码生成，而是执行架构

Code Mode 是一种让模型编写受约束程序，并由隔离运行时执行多步工具操作的 Agent 编排方式。

普通代码生成的终点通常是“把代码交给用户”，Code Mode 的终点则是“让这段代码代表 Agent 完成任务”。工具不再只是聊天模型每一轮都要单独触发的按钮，而会变成运行环境中的函数、模块或类型化接口。

AI Agent 是能够根据目标自主规划步骤、调用外部工具并根据结果继续行动的软件系统。 过去两年，多数 Agent 的基本工作方式可以概括为：模型思考一次、调用一次工具、读取一次结果，再思考下一步。

一个市场研究 Agent 可能需要完成以下流程：

1. 搜索目标公司；
2. 获取每家公司的公开资料；
3. 提取产品、融资和团队信息；
4. 过滤不符合条件的公司；
5. 补充缺失字段；
6. 汇总并生成报告。

传统工具调用会让模型成为每一步的数据搬运工。 每调用一次工具，编排器通常都要把工具定义、参数格式、历史消息和上一步结果重新送入模型，然后等待模型输出结构化参数。

它的逻辑大致是：

模型决定调用搜索工具 → 搜索结果返回模型 → 模型选择公司 → 模型决定调用资料工具 → 资料返回模型 → 模型逐条筛选 → 再调用下一个工具。

Code Mode 会把相同任务压缩为一次较完整的程序生成。 模型可以写出循环、条件判断、并发请求、字段过滤和聚合逻辑，运行时再负责执行；除非遇到异常或需要重新规划，中间结果不必全部回灌给模型。

它的逻辑更接近：

模型生成任务程序 → 沙箱批量调用搜索与资料工具 → 程序在本地筛选、去重和聚合 → 只把摘要或最终结果返回模型。

这不是简单地把 JSON 换成 Python 或 JavaScript，而是改变了模型参与计算的粒度。

99.2%究竟省在了哪里

Code Mode 最主要的节省来自模型上下文和推理轮次，而不是某个工具突然便宜了。

在传统 Agent 中，成本通常来自四个部分：

• 每轮都要发送的系统提示词和任务历史；
• 一组甚至数十组工具的名称、描述和参数模式；
• 工具返回的大段原始数据；
• 为下一步操作再次调用模型产生的输入、输出与延迟。

假设一个任务需要调用 20 次工具，传统架构可能触发 20 次模型决策。即使每一轮只增加几千 Token，完整历史、工具定义和结果也会随着轮次不断累积。更糟糕的是，网页正文、日志和表格等工具输出很容易达到数万 Token。

Code Mode 把循环和数据处理从高价的模型 Token 转移到了低价的 CPU 计算。 “遍历100条记录并过滤其中12条”对语言模型而言意味着大量输入和多轮推理，对普通运行时而言只是一次毫秒级循环。

| 成本来源 | 传统工具调用 | Code Mode | 可能产生的变化 | |---|---|---|---| | 工具描述 | 多轮重复进入上下文 | 按需加载或通过运行时引用 | 输入 Token 减少 | | 工具决策 | 每一步由模型重新决定 | 模型一次生成多步控制逻辑 | 模型调用次数减少 | | 中间数据 | 原始结果持续回灌模型 | 在沙箱内筛选、聚合 | 上下文长度下降 | | 循环与分支 | 依赖模型逐轮推进 | 由程序原生执行 | 稳定性和速度提升 | | 错误处理 | 模型读取错误后再重试 | 运行时捕获、退避和重试 | 无效推理减少 | | 计算成本 | 主要消耗模型推理 | 部分转移至 CPU、内存和网络 | 总成本取决于任务结构 |

99.2%的降幅意味着被优化的系统原本很可能存在大量重复编排开销。 如果旧方案成本记为100元，新方案就是0.8元；这并不意味着所有 Agent 都能从100元降到0.8元，而是说明多工具、长链路、数据密集型任务存在极大的结构性浪费。

这个结论也提示开发者，不要把 Token 单价当成 Agent 成本的唯一决定因素。一个单价便宜但需要往返30轮的模型，未必比一个能一次写出可靠执行程序、只调用两轮的高价模型便宜。

Tool Calling 正从协议问题变成编译问题

工具调用是模型以结构化参数请求外部函数、服务或数据源的机制。 它解决的是模型如何表达“我要调用什么”，却没有自动解决几十个工具如何高效组合。

过去的优化重点是让模型严格输出 JSON、减少参数错误，以及为工具补充更清楚的描述。Code Mode 则进一步把问题改写为：如何让模型生成一份可验证、可执行、可观察的任务计划。

这种变化很像从逐条发送数据库查询，转向编写一段存储过程。前者容易观察和干预，但网络往返多；后者能在数据附近完成循环和聚合，效率高得多，却需要权限控制、资源限制和调试能力。

Code Mode 的本质更接近 Agent 编译层。 模型把自然语言目标“编译”为程序，运行时再将程序中的函数映射为真实工具，并处理鉴权、超时、并发、重试和日志。

因此，真正成熟的 Code Mode 至少需要四层能力：

1. 工具发现层：告诉模型有哪些能力可用，但不把所有完整定义永久塞入上下文；
2. 程序生成层：将自然语言目标转换为带有循环、条件和异常处理的受约束程序；
3. 安全执行层：限制文件、网络、进程、时间、内存和工具权限；
4. 可观测层：记录每次工具调用、参数、返回值、费用和失败原因。

只增加一个“执行代码”按钮，并不能自动得到可靠的 Code Mode。

MCP 与 Code Mode 不是替代关系

MCP，即 Model Context Protocol，是一种连接 AI 应用与外部工具、资源和提示模板的开放协议。 MCP 主要统一“工具如何被发现和调用”，Code Mode 主要优化“多个工具如何被组织和执行”。

两者解决的是不同层级的问题。MCP 类似 USB 接口标准，Code Mode 更像插上设备后运行的软件和自动化脚本。

| 维度 | 传统 Function Calling | MCP | Code Mode | |---|---|---|---| | 核心目标 | 让模型输出一次结构化调用 | 标准化工具与资源连接 | 用程序编排多步工具操作 | | 控制逻辑 | 主要位于模型对话轮次 | 由客户端或 Agent 决定 | 大量逻辑进入执行运行时 | | 中间结果 | 通常返回模型 | 取决于客户端实现 | 可在沙箱内处理 | | 工具规模 | 少量工具较合适 | 适合跨服务扩展工具生态 | 适合复杂、多步、数据密集任务 | | 主要风险 | 参数错误、调用失败 | 权限边界和服务可信度 | 任意代码、越权访问和副作用 |

MCP 工具越多，Code Mode 的价值反而可能越明显。 当 Agent 接入几十个 MCP Server 时，如果每轮都向模型展示全部工具定义，上下文会迅速膨胀；更合理的方式是先检索相关工具，再让模型基于精简后的能力集合编写执行程序。

但 Code Mode 不能掩盖工具设计本身的问题。命名混乱、参数不稳定、错误格式不统一的工具，即使包装成函数，也只会让模型生成一段更难排查的程序。

省下的 Token 会变成新的基础设施成本

Code Mode 并没有消灭成本，而是把成本从模型推理转移到了执行基础设施。

一个可用的代码运行环境需要冷启动、CPU、内存、临时存储、网络带宽和日志系统。如果每个任务都要启动独立容器，短任务的沙箱成本可能超过节省的 Token；如果工具会返回视频、压缩包或大型数据集，网络费用也不能忽略。

因此，系统总成本至少应按下面的口径计算：

总成本 = 模型输入费用 + 模型输出费用 + 沙箱计算费用 + 工具费用 + 网络与存储费用 + 重试成本。

只比较模型账单，很容易得到一个漂亮但不完整的降幅。Agent Swarm 的99.2%值得关注，但开发团队复现时必须确认统计范围：是否包含执行环境，是否包含失败任务，是否使用缓存，以及新旧方案是否达到相同成功率。

成功率比单次调用价格更重要。 如果传统方案每次成本1元、成功率90%，Code Mode 每次成本0.05元、成功率只有30%，后者虽然单次便宜95%，完成一个有效任务所需的实际成本却没有表面上那么低。

建议至少同时记录以下指标：

• 单个成功任务的平均总成本；
• 完成任务所需的模型调用次数；
• 输入与输出 Token 数量；
• 工具调用次数及失败率；
• 端到端 P50、P95 延迟；
• 沙箱启动与运行费用；
• 人工接管率和结果正确率。

没有这些数据，99.2%只能被视为一个案例数字，而不是工程承诺。

最大风险不是模型写错代码，而是代码真的执行了

沙箱是限制程序可访问资源和权限范围的隔离执行环境。 对 Code Mode 来说，沙箱不是附加功能，而是进入生产环境的前提。

传统工具调用通常只有预定义接口可用，模型很难绕开参数结构。Code Mode 一旦允许程序访问文件系统、网络或密钥，攻击面就会明显扩大。提示注入可能不再只是诱导模型说错话，而是诱导程序向外发送数据、批量删除资源或重复创建付费任务。

生产系统至少需要以下边界：

• 默认拒绝网络访问，只允许访问明确列入白名单的域名和工具；
• 密钥按调用注入，不要让程序直接读取长期凭据；
• 限制时间和资源，防止死循环、递归爆炸及无限并发；
• 区分读写权限，搜索和查询可以自动执行，付款、删除、发布等操作需要审批；
• 设置费用预算，限制单任务、单工具和单用户的最大支出；
• 保留完整审计日志，确保每个外部副作用都能追溯；
• 支持幂等与回滚，避免重试造成重复付款、重复发信或重复下单。

“模型生成代码”听起来比“模型调用工具”更像传统软件工程，但它并不会天然更可靠。模型可能调用不存在的函数、误解字段含义、遗漏分页，也可能在处理异常时产生新的副作用。

并非所有 Agent 都应该切换 Code Mode

Code Mode 最适合多步骤、高重复、强数据处理的任务。 例如批量研究、网页信息抽取、财务数据整理、日志分析、测试执行和跨系统报表生成，都能从循环、并发和本地聚合中获益。

简单任务通常没有必要承担代码执行的复杂性。如果 Agent 只需查询一次天气、创建一条日历事件或发送一封确认邮件，传统 Function Calling 更直接，也更容易审计。

| 任务类型 | 更合适的方式 | 原因 | |---|---|---| | 单次查询、参数固定 | 传统工具调用 | 链路短，额外沙箱得不偿失 | | 2至3步确定性流程 | 工作流引擎 | 流程可预先定义，无需模型写程序 | | 批量抓取、筛选和聚合 | Code Mode | 可在运行时完成循环和数据压缩 | | 高风险写操作 | 工具调用加人工审批 | 权限边界更清楚 | | 动态探索、工具数量多 | MCP加Code Mode | 先发现工具，再生成执行计划 | | 强合规、强可解释任务 | 确定性工作流优先 | 更容易验证、回放和审计 |

一个实用判断标准是看中间数据是否真的需要模型阅读。 如果中间结果只是用于排序、去重、计算、格式转换或条件判断，就应该尽量留在普通程序中；如果它需要语义理解、价值判断或重新规划，再交给模型。

Agent 团队接下来要做的是“少让模型工作”

最好的 Agent 架构不是让模型参与每个步骤，而是只在不确定性最高的地方使用模型。

模型擅长理解目标、处理模糊语义、制定计划和解释结果，却不擅长廉价地执行上千次重复循环。CPU 擅长后者，而且成本和结果都更可预测。

Code Mode 所代表的趋势，是把 Agent 从“一个会不断聊天的机器人”改造成“一个由模型驱动的程序运行系统”。模型负责生成和修正策略，普通软件负责执行确定性逻辑，工具协议负责连接外部世界，安全层负责控制副作用。

99.2%未必能被普遍复制，但工具调用链的重构几乎已经不可逆。 随着 Agent 接入的工具从个位数增长到几十甚至几百个，继续把所有定义、数据和控制逻辑塞进对话上下文，既昂贵又脆弱。

截至2026年7月23日，Code Mode 最值得开发者关注的并不是“可以执行代码”这个表面功能，而是它揭示了一条更现实的 Agent 降本路线：少发上下文、少做模型往返、少让大模型处理普通程序几毫秒就能解决的问题。

对正在做 Agent 的团队来说，现在该问的已经不是“要不要换一个更便宜的模型”，而是：这一步真的需要模型再思考一次吗？

参考来源

• Model Context Protocol Specification：MCP 官方规范仓库，用于核对工具、资源与客户端连接的协议定位。
• JSON Schema Specification：JSON Schema 规范仓库，提供结构化工具参数与数据校验的基础背景。
• E2B GitHub 仓库：面向 AI 应用的隔离代码执行项目，可用于理解 Agent 沙箱的工程实现方向。
• HTTP 状态码与 AI Agent 经济：讨论 Agent 调用商业服务时的支付、身份和协议摩擦，补充工具经济层面的观察。