一次 Agent 任务为什么能烧掉几十次 LLM 调用？
很多团队第一次算 Agent 成本，会算错。
他们按一次聊天请求算：
用户发一条消息
↓
模型回答一次
↓
成本 = input token + output token
这个算法适合普通 Chatbot，不适合 Agent。
Agent 的成本通常长这样：
第 1 步：模型判断要读哪些文件
第 2 步：模型根据文件内容决定搜索
第 3 步：模型根据搜索结果读另一个文件
第 4 步：模型决定执行测试
第 5 步：模型分析测试日志
第 6 步：模型修改代码
第 7 步：模型再次执行测试
第 8 步：模型总结结果
每一步都可能重新构造上下文。每一步都要把消息历史、工具结果、文件片段、系统指令、工具 schema、运行状态发给模型。看上去是一个任务，账单上可能是十几次甚至几十次模型调用。
这就是 Agent 成本最容易被低估的地方。
成本不是只发生在模型回答那一刻
一个 Agent run 里，成本至少有五类。
第一类是模型 input token。系统指令、工具 schema、用户目标、历史消息、文件片段、工具结果，全都算。
第二类是模型 output token。它可能是最终回答，也可能是中间推理后的 tool call 参数、计划、摘要。
第三类是工具成本。外部 API 查询、浏览器任务、数据库请求、容器运行、代码执行，都可能有资源账单。
第四类是重试成本。模型调用重试、工具调用重试、失败后重新规划，都会放大账单。
第五类是恢复和评测成本。checkpoint 之后继续执行、trace replay、真实模型 smoke eval，也要花钱。
所以我更愿意把 Agent 成本写成：
Run Cost =
Σ(step input token + step output token)
+ Σ(tool cost)
+ retry cost
+ recovery cost
+ eval cost
这不是会计洁癖。你不这么算，线上成本一定会'突然'冒出来。
Agent 为什么比 Chatbot 更容易爆 token
普通 Chatbot 至少有一个优点：用户问一句，模型答一句。历史会变长，但每次通常只有一个回答。
Agent 有三个额外放大器。
第一个放大器是 step。
maxSteps=20 不代表最多调用 20 次模型这么简单。每一步都可能带上工具列表、上下文摘要、最近 observation 和运行状态。前面几步留下的结果，还会变成后面几步的输入。
第二个放大器是工具输出。
一次 npm test 失败可能吐几万字符。一次 rg 搜索可能返回几百行。一次读取日志可能直接把上下文塞满。如果 runtime 不做降级，模型每一轮都会拖着这些日志跑。
第三个放大器是工具 schema。
工具多了以后，schema 本身也很贵。一个 MCP 环境里可能有几十个 server、几百个 tools。你把所有工具都塞给模型，不只是浪费 token，还会增加误调用概率。
这三个放大器叠在一起，成本就不再线性。
长上下文不是免费午餐
现在模型上下文窗口越来越大，很多人第一反应是：那就全塞进去。
我理解这个冲动。早期上下文太小，大家被截断折磨过。可长上下文不是免费的。
OpenAI 的产品页面在解释上下文窗口时也提到，可用空间会被系统指令、工具、记忆、内部处理等占用。Anthropic 和 OpenAI 都提供 prompt caching，说明长前缀、重复上下文确实值得被缓存和优化。换句话说，厂商也知道重复发送大段上下文是成本问题。
更大的窗口解决的是'放得下'，不是'放得对'。
Agent 真正需要的是当前目标、关键约束、最近行动、相关事实、失败证据和下一步可用工具。把半小时前的旧日志、已经废弃的计划、全量搜索结果和无关文件都塞进去，模型不会变成资深工程师。它只会更慢、更贵，还可能被旧信息带偏。
上下文工程不是'尽量多给'，而是'知道什么不能丢，什么必须降级'。
Context Builder 要有预算报告
我建议把 Context Builder 当成一个正式模块，而不是 controller 里的字符串拼接。
它的输入大概是这样：