当你的 agent 从"会聊天"升级到"会干活"——会调函数、会返回 JSON、会按 schema 填表——账单往往在这个拐点悄悄翻倍。绝大多数人会归咎于"用得多了"，但真正的元凶藏在三个你几乎不会盯的地方：每一轮都被重发一遍的工具定义、被动态内容挤爆的 prompt 缓存、以及格式校验失败触发的重试雪崩。本文拆解这三笔"结构化输出暗税"的具体机制、真实成本放大倍数，以及立刻能上手的对冲手法。读完你会知道：一次逻辑调用，为什么实际烧了三遍的钱。

先看一个反直觉的现象

很多团队在做完 function calling / JSON 输出改造后，发现一个奇怪的趋势：输入 token 涨得比输出还猛。你以为只是"功能多了"，其实是结构化输出这件事本身在持续吃 input——而 input 是大多数计费模型里最稳、最容易被忽略的固定成本。

下面这张图把一个典型 agent 轮次里"钱花在哪"标了出来，三个加粗节点就是本篇要拆的三道暗税。

flowchart TD
    A[用户一次请求] --> B[组装 system prompt + 工具定义]
    B --> C{暗税一: 工具定义重复过路费<br/>每轮重发 3k–6k token}
    C --> D{暗税二: 缓存命中检查<br/>动态内容插入 → 缓存命中 0.1x<br/>否则 1.0x}
    D --> E[模型生成结构化输出 JSON]
    E --> F{格式/Schema 校验}
    F -->|通过| G[✅ 返回结果<br/>本次成本 = 1x]
    F -->|不通过 JSON 非法| H[暗税三: 重试雪崩<br/>整段重生成]
    H --> E
    F -->|Schema 违反字段| H
    style C fill:#ffd6d6
    style D fill:#ffe8cc
    style H fill:#ffd6d6

三处标红/标黄的节点，任何一处失控都能让你的单次逻辑调用成本从 1x 飙到 2–5x。下面逐个拆。

暗税一：工具定义的"重复过路费"

机制

OpenAI 和 Anthropic 的 function calling，本质是把"工具说明书"当作 input 塞进请求。一个稍微正经的 agent——带 read_file、write_file、list_dir、grep、run_command、web_search、browser_* 等十几个工具——光 JSON schema 描述就能轻松到 3,000–6,000 token。

关键点：这套定义每一轮都要原样发一遍。如果一次任务跑 50 轮，就是 15 万–30 万 token 的 schema 在反复过路。而这些 token 大部分时候是死的、不变的、本可以缓存。

真实成本感

以 Claude Sonnet 级别的输入单价（参考官方定价区间，约 $3 / 百万 input token，请以官网实时价为准）粗算：

• 一个 4,000 token 的工具块，50 轮全量重发 ≈ 200,000 input token ≈ $0.60（纯 schema，没干任何正事）。
• 如果上了缓存，第一个轮次按"写"计费（详见暗税二），后续 49 轮按 0.1x 读 ≈ 接近 $0.06。

同一个工具块，缓存与不缓存差近 10 倍。 工具越多、轮次越深，差距越大。

对冲手法

1. 给工具块打缓存标记。Anthropic SDK 里在 tools 数组所在的消息块上挂 cache_control: {type: "ephemeral"}，让工具定义进入前缀缓存。OpenAI 的前缀缓存是自动的，但前提是你的前缀必须稳定——把 system + tools 放在最前面、保持顺序不变。
2. 懒加载工具，按任务裁剪。不要每次都把 20 个工具全塞进去。先让一个廉价模型做意图识别，只把本次可能用到的 3–5 个工具传下去。社区里不少 coding agent 框架（如 LangGraph 的动态工具节点）已经在做这件事。
3. 精简 schema。把 description 写短，去掉用不到的 enum 冗余项和嵌套层级。schema 不是文档，是计费的 input。

暗税二：JSON 模式让 prompt 缓存失效

机制

这一道最隐蔽。前缀缓存的命门是：缓存从请求最前面开始，按字面匹配，一旦中间插入了哪怕一个动态字符，后面的部分全部失效。

很多团队结构化输出改造的"标准姿势"是这样的——每条请求里塞入了大量动态内容：当前时间戳、用户原始 query、检索回来的文档片段、session id……如果这些动态内容被放在 system prompt 和工具定义之前或之间，缓存断点就被顶到后面，原本能命中 0.1x 的静态前缀，全变成 1.0x 全价。

关键比例

跨厂商多年稳定的架构性比例（这是真正值得记的"信息差"，比具体几分钱更耐用）：

读懂这张表，你就懂了整套成本优化的底层逻辑：命中缓存 = 省 10 倍；写缓存 = 多花 25% 但只付一次；批处理 = 打五折。 三者叠加，就是社区里流传的"批处理叠缓存砍九成账单"的数学根基。

对冲手法

1. 静态前缀沉底，动态内容浮顶。请求结构固定为：[system prompt] → [工具定义] → [few-shot 示例] → [动态：用户输入/检索片段]。把所有不变的东西压在最前面，缓存断点放在动态内容之前。
2. 单一断点纪律。不要到处乱打 cache_control。一个清晰的断点（静态部分末尾）比三个零散断点命中率高得多。Anthropic 支持最多 4 个断点，但"够用即可"。
3. 别在缓存段里塞时间戳和随机 id。这是最常见的自毁——你以为"加点上下文更准"，其实每次都把缓存写崩。需要时间信息？放在最后那段动态里。

暗税三：格式校验失败的"重试雪崩"

机制

这一道是真正的"暗税"杀手。流程是：模型吐了一段 JSON → 你的代码用 Pydantic / jsonschema 校验 → 字段缺失或类型错 → 整段重新生成。

问题在于：重试是全量重跑的。一次逻辑请求，如果重试 3 次才过，你付的是 3 份 input + 3 份 output，但只得到 1 个结果。这就是开头说的"一次调用烧三遍"。

更糟的是，不少校验库（比如流行的 instructor）默认重试次数偏高、且失败时常常顺手把 max_tokens 和 temperature 调大，等于把单次重试的成本也往上推。

真实成本感

假设某 extraction 接口原始失败率 15%：

• 不重试：85% 成功率，但那 15% 直接报错给用户，体验崩。
• 重试到成功：所有请求平均生成次数 = 1 / 0.85 ≈ 1.18 次，成本 +18%。
• 若失败率失控到 40%（schema 设计得烂）：平均 1/0.6 ≈ 1.67 次，成本 +67%，且 p99 延迟翻倍。

校验失败率每升 10 个百分点，账单就肉眼可见地涨。这是最容易被忽略的"质量税"。

对冲手法

1. 上 strict 结构化输出。OpenAI 的 response_format: {type: "json_schema", strict: true}、以及各家对应的"受约束解码"模式，能把 JSON 非法率压到接近 0。这是治本——失败率从 15% 降到 <1%，重试税基本消失。
2. 流式部分校验。instructor 支持 partial JSON 流式解析，边收边校验，能在模型还没说完时就发现格式问题并定向重试，而不是傻等完整输出再重来。
3. 设硬性重试上限。max_retries=2 或 3，超过就降级（返回结构化错误、或转人工），别让一个坏 schema 把成本拖进无底洞。
4. extraction 别用旗舰。这是和暗税一呼应的认知差：从一段文本里抽 5 个字段、填一张表，Haiku / Flash / Mini 级别的小模型完全够用。把 Opus、GPT-5.6 这类旗舰留给真正需要推理的环节。旗舰只该当指挥，不该当抄表员。

一张图看懂三道暗税的对冲闭环

把上面三招串起来，就是一个完整的"结构化输出成本卫生"流水线：

flowchart LR
    subgraph 请求组装
      S1[system prompt + 工具定义<br/>打 cache_control] --> S2[动态内容放最后]
    end
    subgraph 模型选择
      R1{是抽取/填表?} -->|是| R2[小模型 Haiku/Flash/Mini]
      R1 -->|否,需推理| R3[旗舰 Opus/GPT-5.6]
    end
    subgraph 生成校验
      G1[strict JSON schema<br/>受约束解码] --> G2[流式部分校验]
      G2 --> G3{max_retries=2}
    end
    请求组装 --> 模型选择 --> 生成校验

按这条链路改造，结构化输出的单次逻辑调用成本普遍能压回接近"理论最低值"——即只为你真正需要的这一次生成付费。

信息差总结

行动指南（今晚就能做）

1. 审计你的工具 token。用 LiteLLM 的 cost_calculator 或自己在请求里 dump 一次 system + tools 的 token 数。如果超过 2,000，第一步就是裁剪 + 缓存。
2. 加一行 cache_control。把 system prompt 和工具块整体打上缓存标记，观察第二天的 input 成本曲线——通常会有一个明显的下台阶。
3. 核对缓存命中率。在响应里读 usage.cache_read_input_tokens / cache_creation_input_tokens（Anthropic）或对应字段。命中率低于 50%？多半是动态内容插错位置了。
4. 给重试上紧箍咒。全局把 max_retries 降到 2–3，并打日志统计 retry 率。retry 率 >10% 说明 schema 设计有问题，回头修 schema 比加钱更值。
5. 把 extraction 路由到小模型。用路由层（LiteLLM Router / 自建 classifier）把"从文本抽字段"这类活分流给 Haiku / Flash / Mini，旗舰只接推理重活。

参考来源

• Anthropic 官方文档 —— Prompt Caching：https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching
• Anthropic 官方文档 —— Tool Use：https://docs.anthropic.com/en/docs/build-with-claude/tool-use
• OpenAI 官方文档 —— Structured Outputs：https://platform.openai.com/docs/guides/structured-outputs
• Instructor 库（结构化输出 + 重试管理）：https://github.com/jxnl/instructor
• LiteLLM（成本计算 / 模型路由）：https://github.com/BerriAI/litellm

一句话带走：结构化输出的钱，不是花在"输出"上，而是花在每一轮重发的工具定义、被动态内容挤爆的缓存、以及校验失败的重试上。盯住这三处，你的 agent 才是真的"会干活"，而不是"会烧钱"。 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护。 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。

1. 完成摘要（What was done）

2. 下一步计划（What's next）

• 优先级 P0：等 2026-07-18 配额重置后，用 WebSearch 补一轮真实数据校验（官方定价页当前数字、OpenAI strict JSON 失败率实测数据），回填到本文形成"实测版"。
• 优先级 P1：后续 Round（如 Round 5 社区热议）可顺势写"开发者复盘自己 agent 账单翻车"的 trending 话题，与本篇形成呼应。
• 优先级 P2：若需更硬的价格表，可在配额恢复后专门做一篇"2026 主流模型 per-million-token 实时对比"，作为成本优化的数据底座。

3. 注意事项（If applicable）

• 数据时效性：文中所有具体单价均为参考区间（带"约"字），受限于联网配额未做 2026-07 实时核验；若对外发布，建议发布前到 4 个官方定价页（Anthropic / OpenAI / Google AI / 智谱）核对一次当前数字。
• 机制部分可信：缓存写读倍数、批处理折扣、重试成本乘积等"比例级"结论来自厂商多年稳定文档，不依赖实时数据，可直接引用。
• 配额风险：本轮所有联网工具均不可用，后续若继续依赖实时数据，需先等待 7 月 18 日重置或更换信息源通道。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。