输入主导：62:1 的 I/O Ratio
Agent 每一轮都要重读全部历史。逐轮点开一个 Excel 任务，看 Input 怎么滚到 31,460 Token
本页解决的问题
先给结论「输入主导：62:1 的 I/O Ratio」要解决的关键问题是什么？
Agent 每一轮都要重读全部历史。逐轮点开一个 Excel 任务，看 Input 怎么滚到 31,460 Token
把成本看成形状，不是一个数字。 把一次请求拆成输入、输出、重试、工具和等待时间。使用量的形状，通常能告诉你是哪项设计选择最贵、哪里值得先改。
优化想象中的平均值之前，先测一次真实请求。
调用便宜了，却悄悄增加了重试、延迟或人工复核。
普通 Chatbot 问「讲个笑话」（10 Token），答 150 Token——I/O Ratio ≈ 1:15，输出主导。而 Agent 做一个代码修复任务：System Prompt、工具返回、历史输出，全都要在每一轮里重新读一遍。三轮下来，总 Input 16,790、总 Output 270——I/O Ratio 62:1，输入主导。
任务：「帮我分析这个 Excel 表格，找出销售额最高的产品，然后生成一个图表。」点「下一轮」，看每一轮的累计 Input 怎么滚起来。
假设任务要 N 轮完成，System Prompt 长度 S，每轮新增（输出 + 工具返回）约 Δ。第 N 轮的 Input ≈ S + Q + Δ×(N-1)，而总 Input 是所有轮次的累加——里面藏着一个 1+2+3+…+(N-1) 的等差数列。每轮新增 500 Token 的话，5 轮循环的总 Input 就有 15,000+；轮次翻倍，成本接近翻两番。
| Agent 框架（SWE-bench 实测） | 平均 I/O Ratio | 说明 |
|---|---|---|
| 简单 RAG Agent | 10:1 ~ 20:1 | 检索 + 回答 |
| OpenHands | 20:1 ~ 50:1 | 代码修复任务 |
| AutoGPT 类 | 30:1 ~ 100:1 | 开放式任务，循环多 |
这解释了为什么 KV Cache（第 11 节）对 Agent 是决定性的：既然每轮都要重读同样的前缀，能不能命中缓存，就是 5 倍的价差。也解释了为什么要监控 I/O Ratio——比率超过 50:1，往往说明 Agent 在「空转」，该优化流程或降级任务了。
Agent 是输入主导的：每轮 Input 都带全部历史，总量按轮次的平方级膨胀。
单次执行看着便宜，规模化才见真章：0.02 元的任务 × 失败重试 × 百万调用，就是账单窒息现场。
把 I/O Ratio 当健康指标监控：>50:1 说明 Agent 在空转，先查流程再谈省钱。
内容来源：整理自作者团队内部分享《AI Token 降本增效策略分享》「Agentic 应用的计费机制」。行业数据参考 SWE-bench 上的 Agent Token 消耗实证研究（见收官节阅读材料）。Agent 循环的原理详见动手实战篇。
「Chatbot vs Agent：计费结构完全不同」的完整成本怎么算
「普通 Chatbot 问「讲个笑话」（10 Token），答 150 Token—— I/O Ratio ≈ 1:15，输出主导 。而 Agent 做一个代码修复任务：System Prompt、工具返回、历史输出，全都要在每一轮里重新读一遍。三轮下来，总 Input 16,790、总 Output 270—— I/O Ratio 62:1，输入主导」提醒我们，AI 成本不是单价乘一次调用这么简单。输入、输出、重试、工具调用、等待时间和人工收尾，会共同决定一次任务到底贵不贵。
先找出账单里不断重复的部分
「任务：「帮我分析这个 Excel 表格，找出销售额最高的产品，然后生成一个图表。」点「下一轮」，看每一轮的累计 Input 怎么滚起来」对应的关键变量通常是上下文是否每轮重复发送、输出是否过长、失败是否触发重试，以及每次调用是否真的带来有用结果。减少无效 Token 往往同时降低费用、延迟和并发压力。
便宜的单次调用可能换来更贵的全流程
以「把 I/O Ratio 当健康指标监控： >50:1 说明 Agent 在空转，先查流程再谈省钱」为起点做一张小表：输入、输出、重试、工具和人工复核分别花了什么，再比较优化前后的质量，避免只看某一项价格。
从「Chatbot vs Agent：计费结构完全不同」走到「交互演示 · 一个「简单」任务的真实账单」
「Chatbot vs Agent：计费结构完全不同」先把问题落在「普通 Chatbot 问「讲个笑话」（10 Token），答 150 Token—— I/O Ratio ≈ 1:15，输出主导 。而 Agent 做一个代码修复任务：System Prompt、工具返回、历史输出，全都要在每一轮里重新读一遍。三轮下来，总 Input 16,790、总 Output 270—— I/O Ratio 62:1，输入主导」上；到了「交互演示 · 一个「简单」任务的真实账单」，讨论继续推进到「任务：「帮我分析这个 Excel 表格，找出销售额最高的产品，然后生成一个图表。」点「下一轮」，看每一轮的累计 Input 怎么滚起来」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
分析成本时，先画出完整交互，再找每轮重复的输入、无效输出和失败重试；单次调用便宜，并不代表整个任务便宜。
- 「Chatbot vs Agent：计费结构完全不同」：普通 Chatbot 问「讲个笑话」（10 Token），答 150 Token—— I/O Ratio ≈ 1:15，输出主导 。而 Agent 做一个代码修复任务：System Prompt、工具返回、历史输出，全都要在每一轮里重新读一遍。三轮下来，总 Input 16,790、总 Output 270—— I/O Ratio 62:1，输入主导
- 「交互演示 · 一个「简单」任务的真实账单」：任务：「帮我分析这个 Excel 表格，找出销售额最高的产品，然后生成一个图表。」点「下一轮」，看每一轮的累计 Input 怎么滚起来
- 「最后的要点」：把 I/O Ratio 当健康指标监控： >50:1 说明 Agent 在空转，先查流程再谈省钱
最后的「最后的要点」把讨论落到「把 I/O Ratio 当健康指标监控： >50:1 说明 Agent 在空转，先查流程再谈省钱」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。