Marico's space

最近折腾了 AI agent 的执行效率问题，踩了几个坑，这篇把问题说清楚。

当你给 AI agent 配上工具去完成一个真实的业务任务，它做的事情里有多少是真正有用的任务，又有多少只是在找方向——摸索 schema、把原始数据塞进 context、反反复复读数据、祈祷自己没漏掉某个字段？

我做了个配对基准测试来直接测量这个差距。用的工具是 Foundgine，一个开源的 .NET 语义执行层，对比的是传统的"直接把应用工具丢给 agent"的方案。相同的任务、相同的数据、相同的结果要求，唯一不同的是执行边界。

测试场景
一个银行业客户审查任务，故意设计得没那么简单：

客户
├── 4 个银行业务关系
│ └── 12 份合同
│ └── 48 笔交易
├── 计算总敞口
├── 与 $48,000 阈值比较
├── 标记客户已审查（单字段变更）
└── 验证最终状态

方案 A — 传统应用/AI 方案：agent 获得应用工具用于 schema 发现、客户查询、业务关系查询、合同查询、交易检索、变更和验证。它得自己在 context 里重建这张图，一个工具调用一个工具调用地来。

方案 B — Foundgine 语义方案：agent 获得一个语义能力。Foundgine 负责解析图结构、应用授权边界、在边界内执行。agent 只问结果，不自己去走 schema。

两种方案的评判标准只有一个：最终状态是否完全一致？如果不一致，这篇文章的其他内容都没意义。在每种方案各 10 次测量运行（3 次预热）后，结果一致——100% 吻合。

实际改变了什么
指标 传统方案 Foundgine 变化
工具调用次数 7 4 （−42.9%）
每次调用估算 token 负载（启发式） ~981 ~364 −62.9%
最终状态一致 true true pass

工具调用次数是直接从测试框架测量的，没有估算。token 数量需要多一步处理，因为这个基准测试运行在回放模式（没有真实的模型调用，所以 provider 报告的 token 数为零——这是测试框架的正常设计，不是数据缺失）。为了填补这个空白，我用标准分词器近似公式——tokens ≈ max(chars/4, words×1.3)——应用到所有记录的 tool 输入/输出 payload 加上固定的系统提示词，这与真实 BPE 分词器的误差在 ±15% 左右。这是方向性的，不是 provider 报告的数据，也不包括模型自身的推理 token（真实运行会有——两种方案都会加）。

换算成钱值多少
把 token 负载转换成成本需要再多一步推理：tool 输出的 payload 在 agent 下一轮会被计为输入 token，tool 输入的 payload（模型生成的参数）会被计为输出 token。这是真实的工具调用循环的计费方式——这里是用推理算的，不是实测，但这是标准约定。

按当前 Claude API 公开定价（2026 年 8 月）：

模型（$/MTok 输入/输出） 每次调用节省 10 万次调用/天
Haiku 4.5（$1/$5） $0.000685 约 $2,055/月 · 约 $25K/年
Sonnet 5 标准版（$3/$15） $0.002055 约 $6,165/月 · 约 $75K/年
Opus 5（$5/$25） $0.003425 约 $10,275/月 · 约 $125K/年

一个每天跑 1 万次调用的内部 agent，每月几百美元。平台级的 agent 每天 100 万次调用，每月就是六位数。把这些都当成数量级来估算，别当报价——这是按公开定价的启发式估算，可以用脚本重现（estimate_cost_savings.py，放在仓库里），你可以用自己的量和价重新跑，而不是直接信我的数字。

让我们意外的部分：Foundgine 实际更慢，按墙上时钟算
这是很多基准测试帖子会悄悄删掉的部分。我们没删。

在这个回放测试里，Foundgine 的墙上时钟时间更高，而不是更低——传统方案的 7 次小往返，每次应用时间都很便宜；Foundgine 的 4 次调用在 agent 看到结果之前，要在边界内做更多解析工作。agent 侧的更少、更小的往返，换来的是应用内部更多的工作。

Token 数、API 时间和应用负载是三个不同的指标，一个方案可能在一个上赢、在另一个上输。为每次调用的 API 成本和 context 窗口压力优化，这里语义边界赢了。为端到端延迟优化，并不能自动得到同样的结论。我们两个都报告，而不是把它们合并成一个让结果看起来更好看的数字。

放大来看：如果这是全世界的问题，不是一个基准测试呢？
这部分明确是粗略估算，不是结论。但值得做一次，开诚布公，这样别人才能反驳。

IEA（国际能源署）2026 年基准情景显示，全球数据中心电力消耗约为 485 TWh（2025 年），预计到 2030 年增长至约 950 TWh，AI 优化服务器已占 2026 年数据中心用电量的约 31%（约 175 TWh/年），增速约为传统服务器负载的 3 倍。关键的是，IEA 特别指出 agentic 和推理工作负载每个查询消耗的能量比简单文本提示多几百到几千倍——这正是这个基准测试测量的工作负载类型。

如果我们假设能耗大致与处理的 token 数量成比例（这是简化——注意成本在 context 长度上是超线性的，所以这个假设可能低估了更长 context 下的实际差距），而且这约 175 TWh/年的 AI 服务器预算中有部分是 agentic 工具调用流量，形状类似我们的"传统"方案，那么应用测量到的约 63% token 负载削减：

占 AI 服务器电力的比例（agentic 工具调用类） 约能耗 63% 削减后节省 @ 约 $0.12/kWh
1% 1.75 TWh/年 1.1 TWh/年 约 $1.32 亿/年
5% 8.75 TWh/年 5.5 TWh/年 约 $6.6 亿/年
10% 17.5 TWh/年 11 TWh/年 约 $13 亿/年

1.1 TWh/年大约相当于 10 万个美国普通家庭的年用电量。左列的百分比都不是实测的——它们是场景输入，我真的希望有人来挑战它们。三个场景下面唯一实测的数字是这个特定场景的 62.9% token 负载削减。剩下的是"如果这能推广，这是它大概值多少"——换算成美元，也同样重要的是，换算成千瓦时和二氧化碳排放吨数。

诚实的结论不是标题上的美元数或 TWh 数。而是 AI agent 的成本和能耗里，有相当一部分花在了 agent 重新学习怎么和应用对话上，而不是花在业务逻辑本身。这是一个可以解决的、枯燥的结构性问题——不是使用 AI agent 的固有成本。

效率不等于安全——不该被当成一回事来卖
这是我想说得最直接的部分，因为"我们让 agent 更便宜了"是个危险标题，不加说明就容易误导。

减少工具调用和 token 负载本身，并不会改变 agent 被授权做什么。这个必须独立设计，刻意为之，跟效率提升是两码事：

应用始终是权威，不是模型。Foundgine 的语义能力和变更边界是应用定义的；agent 请求意图，从不获得原始 SQL 或物理 schema 访问。更便宜的路不会悄悄变宽。

变更需要明确、狭窄的意图。在这个基准测试里，两种方案唯一允许变更的字段是 Customer.FullName——因为这是这个能力授予的唯一字段，不是 agent 选择保守的结果。

无论 token 数量多少，验证都要执行。两种方案在变更后都调用验证步骤。更少的 token 不应该意味着更少的检查。
"最终状态一致"是本页所有数字的实际门槛。一个便宜了 63% 但结果错误 的 agent 不是结果——是看起来快但实际上是退步。

语义执行边界的效率论据和安全论据不是竞争关系。它们是同一设计决策的两个角度。如果你在构建 agent 基础设施，只优化 token，那只完成了一半的工作。

自己复现
完整技术报告、每次运行的追踪记录、所有注意事项：Foundgine 技术文档