LLM agent 的成本会随步数、搜索源和重试次数一起膨胀。论文把「成功一次要花多少钱」写成 cost-of-pass，在 GAIA 上每次只改一个组件，给 backbone、BoN、planning、tool、memory 逐项标价；最后以 1.81 pp 的准确率为代价，换掉 0.20 的 cost-of-pass。
LLM agent 的成本不是线性的：前沿产品一次任务要几百次 API 调用，成本随步数、搜索次数、重试次数一起膨胀。论文把这个问题压成一个指标——成功一次要花多少钱。
cost-of-pass = 单次尝试成本 ÷ 成功率。它同时惩罚贵和不准：便宜但成功率低的模型不会自动赢，强但贵的模型也要付溢价。低 CoP 只代表「期望花费低」，不代表模型可用。
论文在 GAIA 上把 agent 拆成五个组件，每次只动一个：backbone、Best-of-N、planning、tool using、memory。结论不是「越简单越好」，而是每个组件都要按它对成本和准确率的实际贡献来选。
最终配置是 GPT-4.1 + 8 步 + Multi 搜索源 + Simple Memory：准确率 51.52%，CoP 0.55；OWL 是 53.33% / 0.75。准确率少 1.81 pp，CoP 低 0.20（相对 26.7%）。摘要里的 28.4% 与 CoP 的 26.7% 对不上；它恰好等于成本降幅——第 06 节对账。
这一节只建立一件事：为什么「更复杂的 agent」在真实部署里越来越难成立。
论文开篇把矛盾说得很直接：DeepResearch、Manus 这类产品展示了很强的多步任务能力，但 suffer from exorbitant operating costs due to explosive LLM call overhead；有的系统一个任务要几百次 API 调用。
GAIA 把任务分成 L1–L3 三档。难度上去，成本不是缓慢上升，而是成倍地跳。下表只取 Table 1 里两个推理模型的 L1 / L3 列：
| 模型 | CoP · L1 ↓ | CoP · L3 ↓ | L3 / L1 |
|---|---|---|---|
| Claude 3.7 Sonnet | 1.69 | 9.04 | 5.35× |
| o1 | 1.96 | 12.66 | 6.46× |
同一模型在 L3 的 CoP 是 L1 的 5–6 倍；与此同时，Claude 3.7 的准确率从 L1 的 73.58% 掉到 L3 的 42.31%。难任务既更贵、又更不准，两个方向一起把成本推高。
这时候只看准确率会误判。Table 1 里 Qwen3-30B-A3B 的 CoP 只有 0.13，是全表最低；但它的准确率只有 17.58%。按定义，CoP 0.13 只说明「在这套任务分布下，得到一次正确答案的期望花费是 $0.13」——它不是一个能直接拿去跑 GAIA 的通用 agent。推断（依据：Table 1 的 CoP 0.13 与 Acc 17.58% 同行；C = 0.023 美元时 0.023 / 0.1758 ≈ 0.131）。
单次调用便宜，可能只是模型在乱答；单次调用贵，也可能一次就答对。把两者压成一个比值，才能比较「花多少钱办成一件事」。这就是下一节两条现成路线都没有回答的问题。
一条堆能力，一条压单价；两者都能拿出漂亮的单项数字，但都没回答「哪个模块值这个钱」。
OWL 在 GAIA 上 53.33%、CoP 0.75；Smolagents 同样 53.33%，CoP 却高达 5.82。两者准确率一样，CoP 差 7.76 倍——框架设计本身就能把成本拉开一个数量级。
盲区：它告诉你「谁更强」，不告诉你多出来的每一步、每一次工具调用值不值。
Qwen3-30B-A3B 的 CoP 0.13、Qwen3-235B-A22B 0.22；Claude 3.7 Sonnet 准确率 61.82%，但 CoP 3.54，是 GPT-4.1 0.98 的 3.61 倍。
盲区：便宜和强之间没有免费的选择；只压单价会把任务成功率一起压下去。
论文的做法不是选边，而是先把每个组件单独放到同一张价目表上。下面把 Table 1 的 backbone 全列转录出来（all 列）：
| Backbone | CoP ↓ | Acc / % ↑ | Cost / $ ↓ | #Tokens ↓ |
|---|---|---|---|---|
| GPT-4.1 | 0.98 | 53.33 | 0.705 | 243K |
| Claude 3.7 Sonnet | 3.54 | 61.82 | 2.190 | 680K |
| Qwen3-235B-A22B | 0.22 | 27.27 | 0.040 | 72K |
| Qwen3-30B-A3B | 0.13 | 17.58 | 0.023 | 65K |
| QwQ-32B | 0.23 | 22.42 | 0.120 | 142K |
| o1 | 3.66 | 52.12 | 1.908 | 69K |
读表提示：GPT-4.1 这一行的 Cost/$ 0.705 ÷ Acc 53.33% = 1.32，与同表 CoP 列的 0.98 不能直接互推。Table 4 的同一默认配置行写 1.32；Table 2 / Table 5 的同一默认配置用 Cost 0.521，0.521 / 0.5333 = 0.98。原文并列了这些值，没有说明聚合口径；本页引用时保留原表数字，不做换算。
这张表已经说明 backbone 是最大的单一杠杆：CoP 从 0.13 到 3.66，跨 28.15 倍；准确率从 17.58% 到 61.82%。但它没有回答另外四个组件该怎么选——那需要控制变量。
cost-of-pass 是标尺；固定其余组件、每次只动一个，是方法。切换标签，看每组选项的价目表。
论文固定一套默认配置（Table 8：GPT-4.1、12 步、plan interval 1、Simple 搜索源、10 次查询、BoN 1、Simple Memory），然后每次只改一个组件。这样每个组件的成本变化可以单独归因，而不是混在整体账单里。
下面这张价目表把 Table 1–5 的测量结果放在同一个视图里。条形图只做展示：CoP 条按组内最大值归一（越短越好），Acc 条按 0–100 归一（越长越好）。数值逐字来自原表。
覆盖：Table 1 的 6 个 backbone；Table 2 的 N=1/2/4；Table 3 的 5 个非重复 planning 配置（4/1、8/1、12/1、12/2、12/4）；Table 4 的 6 个 tool 配置；Table 5 的 6 个 memory 配置。
没覆盖：组件之间的交互。每组只改一个组件，其余保持默认；Table 6 最终选的 Multi + 5 没有在 Table 4 里单独出现（Table 4 只测了 Multi + 10 和 Simple + 5）。BoN 只测到 N=4；memory 的对照基线是 w/o extra（0.98），而 Table 8 把默认 memory 写成 Simple——本页在涉及 memory 时直接用 Table 5 的基线与 Simple 对照。
归一化：CoP 条长度 = 该组 CoP ÷ 该组最大 CoP；Acc 条长度 = Acc / 100。归一化只影响条形长度，不改变读数；所有读数都带原表表号。
论文的账本口径，以及一个可以自己拨的 C / R 计算器。
成本不是简单地「token 数 × 一个单价」。论文按官方定价把输入和输出分开算：C = nin · cin + nout · cout。很多闭源模型输出 token 的单价明显高于输入，因而输出长度对账单的影响更大；价格锚定在 2025 年 5 月的官方文档。
把 C 再除以成功率 R，就得到 cost-of-pass。注意 C 是「一次尝试」的成本，R 是「一次尝试答对」的概率；两者相除才是「成功一次」的期望成本。R=0 时 CoP 无定义，论文记为 ∞。
口径：本页不涉及标准差；成功率按百分比输入，JS 中除以 100 后作为分母。计算器只演示 v = C / R 这一层，不复现原表把逐题结果聚合成 all / L1 / L2 / L3 的过程。
计算器在同样参数下输出上述四个值，与手算逐位一致。原表的 CoP 是逐题计算后再汇总，和「总成本 ÷ 总准确率」不要求逐位相等；上面几组恰好落在原表舍入范围内。
成本口径只覆盖 API 调用：论文没有把自托管算力、向量数据库、工具 API 费用和工程重试成本计入。这些会在第 07 节作为边界展开。
Table 6 的配置逐项对应前面的测量；图里是一条 GAIA 任务的执行路径。
| 组件 | 最终设置 | 依据（本页对 Table 1–5 的读数） |
|---|---|---|
| Backbone | GPT-4.1 | Table 1 中准确率 53.33%、CoP 0.98；Claude 3.7 准确率高 8.49 pp，但 CoP 是 3.61 倍 |
| Max Step | 8 | Table 3：12 步比 8 步只高 0.60 pp，CoP 高 0.28 |
| Plan Interval | 1 | Table 3：12 步下 interval 2 准确率 57.58%，但 CoP 1.04；最终 8 步 / interval 1 的 CoP 0.70 |
| Search Source | Multi | Table 4：准确率 +6.06 pp，CoP 1.32→0.81（相对 -38.6%） |
| Search Num | 5 | Table 4：5 次的 CoP 1.17，低于 10 次的 1.32，准确率同为 53.33% |
| BoN | 1 | Table 2：N=4 比 N=1 只高 0.61 pp，CoP 高 0.30，token 多 82K |
| Memory | Simple | Table 5：56.36%、CoP 0.74；比 w/o extra 基线高 3.03 pp，CoP 低 0.24（相对 -24.5%） |
一处未单测的组合：Table 6 选 Multi + 5，但 Table 4 没有这一行——它测的是 Multi + 10（0.81 / 59.39%）和 Simple + 5（1.17 / 53.33%）。最终组合的效果只在 Table 7 以整体结果出现，论文没有对组合做消融。
把五个选择放在一起看，逻辑是一致的：每个旋钮都停在「再加一档，收益抵不上成本」的位置。Claude 的 8.49 pp 准确率要用 3.61 倍 CoP 换；12 步的 0.60 pp 要用 0.28 CoP 换；BoN 的 0.61 pp 要用 0.30 CoP 加 82K token 换。这些交换在 GAIA 的预算约束下不划算，但在别的任务分布里未必。
Table 7 的三个 agent 对照；收益主要集中在 L3，L1 上并没有赢。
| Agent | CoP all ↓ | CoP L1 ↓ | CoP L2 ↓ | CoP L3 ↓ | Acc all ↑ | Acc L1 ↑ | Acc L2 ↑ | Acc L3 ↑ | Cost all / $ ↓ | Tokens all ↓ |
|---|---|---|---|---|---|---|---|---|---|---|
| OWL | 0.75 | 0.35 | 0.80 | 2.10 | 53.33 | 71.70 | 50.00 | 26.92 | 0.398 | 189K |
| Smolagents | 5.82 | 3.21 | 6.46 | 13.37 | 53.33 | 62.26 | 54.65 | 30.77 | 3.104 | 146K |
| Efficient Agents | 0.55 | 0.37 | 0.54 | 1.71 | 51.52 | 62.26 | 52.33 | 26.92 | 0.285 | 127K |
Efficient Agents 的准确率比 OWL 低 1.81 pp（53.33 − 51.52），CoP 低 0.20（0.75 − 0.55），相对降幅 26.7%（0.20 / 0.75）。成本从 $0.398 降到 $0.285，绝对少 $0.113，相对降幅 28.4%（0.113 / 0.398）。准确率保留 96.6%（51.52 / 53.33）；论文取整写作 96.7%。
收益不是均匀分布的。L1 上 Efficient Agents 的 CoP 是 0.37，比 OWL 的 0.35 还高 0.02；L2 上是 0.54 对 0.80，低 0.26；L3 上是 1.71 对 2.10，低 0.39，相对降幅 18.6%。优势出现在 L2 和 L3——这正是简单配置最容易被复杂框架拖垮的地方。推断（依据：Table 7 的 L1 / L2 / L3 三列；L2 差 0.26、L3 差 0.39，L1 差 +0.02）。
Simple Memory 只保留观察与动作：56.36%、CoP 0.74。Summarized Memory 反而 51.52%、CoP 1.52；extra hybrid 是 54.55%、CoP 1.29。
比 w/o extra 基线高 3.03 pp，CoP 低 0.24（相对 -24.5%）。复杂摘要会引入额外 LLM 调用，还可能把关键历史压掉。
N 从 1 到 4：准确率 53.33%→53.94%（+0.61 pp），CoP 0.98→1.28（+0.30），token 243K→325K（+82K）。
PRM 是 GPT-4o，候选越多，评审本身也越贵；边际收益被采样成本吃掉。
4→8 步：准确率 41.82%→52.73%（+10.91 pp），CoP 0.48→0.70（+0.22）。8→12 步：准确率只 +0.60 pp，CoP 却 +0.28。
超过 8 步后，更多步数没有带来新的有效信息，只是在重复搜索和重规划。
Simple → Multi：准确率 53.33%→59.39%（+6.06 pp），CoP 1.32→0.81（-0.51，相对 -38.6%）。更多来源既提高了命中率，也减少了无效重试，所以成本和准确率同向改善。
浏览器复杂度则不是：Browser-Complex 的 CoP 0.88 低于 Browser-Simple 的 1.59 和 Crawler 的 1.32，但准确率 49.09% 也最低。正文对「简化浏览器在效率上也更好」的说法，与 Table 4 的这组数字对不上——详见下面的对账。
这些位置都保留原文数值与出处，不在本页做换算或修正。读者若要复现，直接对照 Table 1–7 的对应行。
论文的结论有明确的 benchmark、价格和时间边界；越过这些边界，配置要重新测。
GAIA 主要是基于网络的问答、检索和多步推理。论文没有测代码生成、科学发现、长程软件工程。Simple Memory 在几百步的超长任务里是否仍然够用，论文没有数据；8 步上限也是按 GAIA 的难度分布选的。换任务分布，这些「甜点」都要重新扫。
论文按官方文档的 per-token 价格计算，只覆盖 API 调用。自托管算力、向量数据库运维、工具 API、失败重试和工程人力都没有计入。价格变动或改用自托管，Table 1 的排序可能直接翻转。
Table 1–5 每次只改一个组件，其余保持默认。最终 Table 6 的 Multi + 5 在 Table 4 里没有单独一行；Table 7 只报告组合后的整体结果。组件之间的交互（例如多搜索源是否放大了 Simple Memory 的优势）没有拆开测。
backbone 只测了 6 个（GPT-4.1、Claude 3.7、o1、Qwen3-235B/30B、QwQ-32B）；Table 1 未列出针对 agent 任务微调过的开源小模型。BoN 只测到 N=4，PRM 固定为 GPT-4o。memory 和 tool 的结论是在 GPT-4.1 上得到的；换 backbone 后，最优记忆和工具配置未必不变。
还有一个范围问题：论文称其在 GAIA 的 cost-of-pass 上达到新的最优；但同一篇的 Table 1 里，Qwen3-30B-A3B 的 0.13 比 Efficient Agents 的 0.55 更低，代价是准确率只有 17.58%。这个「最优」是在高准确率 agent 框架的语境里说的，论文没有把它写成跨所有模型的绝对最优。
一句话总结：这套方法最值得带走的不是「GPT-4.1 + 8 步 + Simple Memory」这串固定配置，而是「固定其余变量，给每个组件单独算 cost-of-pass」的实验设计。换 benchmark、换价格、换模型，配置要重扫，方法可以复用。