你给 Agent 接上几个工具，让它「自己查资料、自己调接口」，听起来是生产力飞跃。但 2026 年一堆一线团队实测下来发现：工具调用有个被所有厂商文档忽略的成本形状——你的 Agent 每转一圈，都在把之前说过的话、调过的工具结果、甚至工具本身的定义，原样重新发一遍给模型。
结果就是：你以为在为一个「新动作」付费，其实在为「反复重播的整段历史」付费。账单比预估膨胀 3–10 倍，是常态而不是例外。
本文把这块钱袋子黑洞，一层层拆开。
第一层放大：工具定义是「粘性」的，每次调用都重发
当你给模型注册工具（OpenAI / Anthropic / 方舟都如此），工具定义本身会作为 input token 计入每一次调用。一个典型生产级 Agent 有 8–15 个工具，每个工具定义（名称、描述、参数 schema）动辄 200–400 token。8 个工具 × 300 token = 每次调用凭空多出 2,400 个 input token——而这 2,400 token 里，没有一句是你或用户写的内容，模型也不会「思考」它。
更狠的是累加：如果一轮对话有 5 个回合，你就为这 2,400 个工具定义付了 5 次钱。一圈下来 12,000 input token 全是工具定义的「过路费」，用户一个字没打。
PromptUnit 2026 的实测很直白：一个客服 Agent，规划文档里写的是「平均每票 3 次 LLM 调用」，这个假设是对的；错的是每次调用的 token 数——因为没人把「工具定义每次重发」算进去。
第二层放大：工具结果被「累积」进上下文，越到后面越贵
Agent 循环里，模型每调一次工具，工具返回的结果会被追加进对话历史。下一回合发送的完整 prompt，就包含了之前每一次工具调用的入参和出参。
一个返回 500 行 JSON 的工具，意味着之后的每一回合都多了 500 行。对会抓数据、查库、调 API 的 Agent，5 个回合下来上下文能膨胀到几万 token——到第 5 回合，你发过去的 prompt 可能有 30K token，其中 28K 是历史工具结果。
OpenLegion 的量化更扎心：工具响应作为 input token 在下一轮重新计费，循环会把成本复利放大；而把工具响应截断到 2,000 token 再进上下文，就能砍掉 50%–80% 的超额成本。问题在于——绝大多数中转站给你的账单只有一个总数，你根本看不出哪一步在烧钱。
第三层放大：推理模型把「思考过程」也计费了
如果你用 o3、DeepSeek-R1 这类推理模型做 Agent 的决策步，模型内部的思维链（chain-of-thought）会被当作 output token 计费，而这些 token 用户根本看不到、也不返回给你。一个「很简单」的「调用工具 X」决策，背后可能是 2,000–4,000 token 的内部推理，全额计费。
这三层放大器会叠加：一个 5 回合、8 工具、带推理模型的 Agent 循环，可能把 input token 放大 10 倍、output token 放大 5 倍——远超用户实际对话的长度。
Real-world 数字：PromptUnit 那个客服 Agent，规划预算 $4,000/月，三个月后实际账单 $19,000/月。调用次数没错，错的是「每次调用到底发了多少 token」。AI Cost Estimator 的测算更普遍：一个有 10 个工具的中等 Agent 配置，每次请求凭空多 3,000–4,000 token；5 人开发团队每人每天 150 次调用、用 Claude Sonnet，光「工具定义 overhead」一个月就 $173——付的是「发了一堆可能根本没用到的工具描述」。
这块黑洞，上游（方舟）帮不了你
要分清边界：单位 token 的成本，靠上游方舟官方价 × 固定 1.27×，是可预期的；但「工具定义重发 / 结果累积 / 推理 token 计费」这三件事，是你的 Agent 架构对上游的调用方式决定的，属于应用层，中转站无法替你重写 Agent。
这正是很多团队「钱花得不明不白」的根因：账单只有一个总数「总 token × 倍率」，不区分哪些 token 是真实对话、哪些是工具定义的反复重发、哪个工具调用在滚雪球。你看不见，所以它发生了——和「模型偷换」「重试税」「缓存折扣被吞」是同一类钱袋子黑洞：看不见，就发生。
怎么把这块黑洞堵上：要的是「逐笔归因」
把三层放大器翻译成选型标准，就是一张清单：
- 能不能把每次调用拆到「每一步」：input/output token 构成、是不是工具调用、调了哪个工具、耗了多少，能不能逐笔看清楚？看不清，就给了「反复重发」默默膨胀的空间。
- 能不能按密钥 / 按工具 / 按智能体拆账：多 Agent、多工具并行时，哪个 key、哪个功能在烧钱，能不能归因到责任人？
- 有没有硬额度上限：单个 key、单个租户失控时，有没有一道硬顶，而不是靠事后告警？
这正是中转站该给你、却大多没给的「证据链」。
我们的做法：把工具调用做成可归因的证据
Yady API 不替你写 Agent，但默认给你一条可穿透证据链：
- 逐笔明细可溯源（request_id 级）：真实模型名/版本、每次调用的 input/output token 构成、是否工具调用、调了什么工具，你都能核对、能归因，而不是对着一个笼统总数；
- 按密钥额度上限 + 环境隔离：dev/prod 不混账，单租户失控有硬顶；
- 多智能体 / 多工具拆 key 归因：哪条 key、哪个 Agent、哪个工具在烧钱，一查就定位；
- 上游方舟官方授权链路 × 固定 1.27× 透明倍率：单位成本可预期，上游峰谷差价我们承担，调价提前公告不静默变更。
竞品（TeamoRouter / 硅基流动 / OpenRouter）只跟你比「多少折、多少模型、多好接」，从不讲「Agent 工具调用能不能逐笔归因、能不能按 key 封顶」。把「算得清、分得开、封得住」做成默认能力，是我们在钱袋子这条线上和它们最根本的分野。
给开发者的四步自查
- 先量「每次调用的真实 token」再接工具：别只算调用次数，把工具定义 + 历史结果算进每次请求的 input，你会发现比预估高几倍。
- 截断工具响应：把超长工具返回（网页全文、大 JSON）截断到 2,000 token 再进上下文，能砍掉 50%–80% 的超额成本。
- 让中转站给你逐笔明细 + 按 key 拆账：确保每次调用的 input/output 构成、是否工具调用、哪个 key 在烧钱可核对、可归因。
- 给每个 Agent / 工具单独发 key 并设硬上限：失控时一道硬顶兜底，而不是等账单爆了再事后告警。
你省的不该只是一句「Agent 真香」的口号，而是一份看得清每一步、分得开每个工具、封得住失控的账单。把工具调用这块黑洞自己堵住，再来谈「好接」和「便宜」——这才是能长期跑下去的 AI 成本账。
本站 Yady API 默认提供 request_id 级逐笔明细（可溯源真实模型名/版本/每次调用的 input-output token 构成/是否工具调用）、按密钥额度上限 + 环境隔离、多智能体/多工具拆 key 归因、固定 1.27× 透明倍率（上游方舟官方授权链路、调价提前公告不静默变更）。我们不代你写 Agent、不替你做工具调用的 token 优化、不承诺替你承担输出端责任；方舟当前仅激活 1 个模型（广度短板，不掩饰）；不承诺全网最低价。详见 -> https://yczc.top/blog/tool-call-cost-blackhole-2026.html
