Appearance
Token 计费与降本工程
方向定位：聚焦 Token 作为大模型资源计量单位的工程实践——回答"各模态怎么计费、隐性消耗藏在哪、怎么系统性降本"。包括非对称计费公式、四类消耗场景（显性 I/O / 上下文滚雪球 / 思维链 / 系统预设与 Function Calling）、文字图片音频视频四模态计算公式、四模态降本杠杆、低成本环境完善+高成本环境执行的工作流分割、8 段式结构化提示框架。不涉及 Tokenizer 底层机制（→ Token 原理与 Tokenizer 机制）、不涉及 RAG Chunk 设计（→ RAG 文档处理与 Chunk 工程）。 当前版本：v0.1.5 首次构建：2026-05-15 最近更新：2026-05-20 文件名日期同步：2026-05-20 来源数：6 篇（笔记 24、31 + OMC 案例研究 + 商业策略 + Claude Agent SDK 配置教程 + Anthropic CU 最佳实践 2026-05-13）
相关方向：
- AI 研发效能与 SDLC 工程纪律 —— Token 成本是研发效能 ROI 公式的输入侧；工程纪律是把降本策略落地的组织前提
方向定位
本方向研究的核心问题是："大模型一次调用到底花了多少 Token，怎么花得更少？"。它的边界包括：
- 包含：非对称计费公式、四类消耗场景（显性 I/O / 上下文滚雪球 / 思维链 / 系统预设与 Function Calling）、文字/图片/音频/视频四模态 Token 计算方法、各模态降本策略、结构化提示降低 Token 成本的工作流、8 段式提示框架
- 不包含：Tokenizer 算法与底层机制（→ Token 原理与 Tokenizer 机制）、RAG Chunk 边界设计（→ RAG 文档处理与 Chunk 工程）、纯 Prompt 写作技巧（→ 待建 Prompt Engineering 方向，如有）
- 与相邻方向的区别：本方向只回答"多少钱、怎么省"，不回答"Token 是什么、怎么算出来"
理解 Token 计费逻辑是大模型工程降本的前提——不懂计费就解释不了为什么"几条对话就用掉一年额度"，不懂降本就只能在"用不起"和"砍功能"之间二选一。
叙述结构
本文沿四阶段递进展开：计费机制（怎么算钱）→ 消耗场景（钱花在哪）→ 响应时间百分位与延迟治理（快不快）→ 隐形成本（哪些是看不见的坑）→ 降本杠杆（怎么系统性地省）。每一阶段都先讲机制、再列方法、再补案例。
知识图谱
- 核心计费公式（非对称）
- 输入单价 ≠ 输出单价
- 公式 = 输入 Token × 输入单价 + 输出 Token × 输出单价 + 特殊 Token 费用
- 特殊 Token：图片/音频/视频/工具调用单独算
- 四类 Token 消耗场景
- 显性消耗：对话 I/O（用户感知）
- 隐性消耗：上下文滚雪球（每轮带历史，不感知）
- 思维链消耗：慢思考是快思考的 5~20 倍
- 系统预设与 Function Calling：开场即扣费
- 四模态计算公式
- 文字：词表收录与否决定 1 Token / 2 Token
- 图片：低清固定 85；高清按 512×512 切块 ×170+85
- 音频：时长（秒）× 每秒预设 Token
- 视频：画面帧 + 音频两部分相加
- 四模态降本杠杆
- 文字：去礼貌、开新对话、缓存 System Prompt
- 图片：裁剪局部、低清模式、预压缩到 768px
- 音频：去静音、先转文字、紧凑流
- 视频：降采样率、截关键帧、音画分离
- 结构化提示工作流
- 低成本环境（ChatGPT/Gemini）完善提示
- 高成本环境（Figma Make/v0/Lovable）执行
- 8 段式提示框架：角色/目的/输入/指令/输出/约束/备用/语气
- 触发条件→指令对（第 4 段的关键创新）
- 隐性成本的产品认知
- Token 成本从隐性变显性（Figma 2026.3 起收费）
- 设计师角色扩展：从设计界面 → 设计生成界面的提示
- 结构化提示成为核心工作流技能
一、计费机制：Token 到底怎么算钱
1.1 非对称计费公式
来自笔记 24。大模型的核心计费公式是：
费用 = 输入 Token 数 × 输入单价
+ 输出 Token 数 × 输出单价
+ 特殊 Token 费用（图片/音频/视频/工具调用等）关键认知：输入单价 ≠ 输出单价。这不是计费策略问题，而是计算成本本质不同——
- 输入：模型只需做一次前向计算把输入转成内部状态
- 输出：每生成一个 Token 都要跑一次完整前向计算（自回归机制）
所以输出 Token 通常贵 3-5 倍。估算成本时切忌混用单价，是工程中最常见的计算错误之一。
1.2 四模态 Token 计算公式
来自笔记 24。
英文文本：
- 核心词汇表：约 3 万～10 万词条（含完整单词、词根、前后缀、单字母）
- 拆分规则：先按空格/标点拆，再对长词按词根/后缀拆
- 参考值：1000 Token ≈ 750 英文单词
- 注意：大小写敏感，apple = 1 Token，APPLE 可能被拆成 3 Token
中文文本：
- 底层机制：UTF-8 编码，1 个汉字 = 3 字节（生僻字 = 4 字节）
- 流程：汉字 → UTF-8 字节 → 查词表
- 词表有收录 → 1 Token（包括高频词组如"人工智能"整体 = 1 Token）
- 词表无收录 → 3 字节组合被切成 2 个碎片 = 2 Token
- 中文标点若未收录同样占 2 Token
- 国内模型通常收录更多中文高频词，Token 效率更高
图片（低分辨率模式）：无论原图尺寸，统一缩放后固定计费 85 Token，适合粗粒度识别任务。
图片（高分辨率模式，默认）：三步计算
- 第一步：等比例缩放——约束：短边 ≤ 768px，长边 ≤ 2048px
- 第二步：切块——将缩放后图片切成 512×512 的方块；不满 512px 的边按完整块计
- 第三步：计费——总 Token = 块数 × 170 + 85（基础费）
音频：
- 原理：将连续模拟信号切成时间切片（20～50ms/片，依模型而定）
- 计费换算为秒：总 Token = 音频时长（秒）× 每秒预设 Token 数
- 示例：20ms = 1 Token → 1 秒 = 50 Token
视频：视频 = 画面帧 + 音频，公式：
总 Token = 时长(s) × 视觉采样率(帧/s) × 每帧 Token
+ 时长(s) × 每秒音频 Token- 默认采样：1 帧/秒（非 30/60 帧播放帧率）
- 每帧 Token：高清模式 ≈ 260 Token，低清模式 ≈ 65 Token
案例：图片高清模式 Token 计算实例
来自笔记 24。
| 原图尺寸 | 缩放后 | 块数 | Token |
|---|---|---|---|
| 150×150 | 150×150 | 1×1=1 | 1×170+85 = 255 |
| 1024×1024 | 768×768 | 2×2=4 | 4×170+85 = 765 |
| 1920×1080 | 1356×768 | 3×2=6 | 6×170+85 = 1105 |
关键启示：1920×1080 比 1024×1024 仅增加 41% 像素，Token 数却增加 44%（从 765 → 1105）。如果裁掉一条边让图片变成方形，可以从 6 块降到 4 块，省 30%+ Token。裁剪是图片场景最直接的降本杠杆。
Computer Use 截图模态消耗（Anthropic 官方 2026-05-13）：CU Agent 每步生成一张截图，每张消耗约 1,000-1,800 token（取决于分辨率）。200K context window 在不做任何管理的情况下，100 步之内即可填满——这使 CU 成为图片模态 token 消耗最密集的场景。API 内部分辨率限制：4.6 family 最大长边 1568px / 最大总像素 1.15MP；Opus 4.7 升级至最大长边 2576px / 最大总像素 3.75MP。超限图片会被 API 静默降采样，导致坐标空间错位、点击偏移——这是 CU 场景特有的图片计费陷阱。
二、消耗场景：Token 究竟花在了哪里
2.1 四类 Token 消耗场景
来自笔记 24。大模型成本远不止"用户输入+模型输出"这么简单。实际有四类消耗：
1. 显性消耗：对话 I/O——用户感知最强、也最容易被高估的部分。每条 Prompt 按 Token 计费，每段回复按 Token 计费，成本与内容长度正比。
2. 隐性消耗：上下文滚雪球——大模型本身没有记忆。"有记忆感"是因为每次请求都会把完整历史对话打包一起发送给模型。
- 对话轮次增加 → 每次输入 Token 数线性/指数增长
- 即使每轮只问一句话，也可能消耗上万 Token
- 这是用户感知最弱、最容易"超支"的部分
3. 思维链消耗：慢思考的代价——
| 模式 | 逻辑 | Token 消耗 |
|---|---|---|
| 快思考（快速模式） | 预测下一个 Token，直觉式回答 | 基准 |
| 慢思考（思考模式） | 引入 CoT：自我纠错 + 多路径尝试 + 逻辑验证 | 快思考的 5~20 倍 |
思维链 Token 按输出单价计费，属于"隐形输出"。原则：简单问题用快思考，复杂推理才用慢思考，避免"用大炮打蚊子"。
4. 系统预设与功能调用：
- System Prompt：对话开始前就已消耗，定义 AI 角色和回答风格——开场即扣费
- Function Calling：以"联网查资料并总结"为例的三段消耗：① AI 思考"需要联网"→ 输出 Token；② 联网搜索返回 20000 字 → 作为输入 Token 喂给模型；③ AI 生成总结 → 输出 Token
- 联网内容会滚入后续上下文，不开新对话则持续叠加
案例：Function Calling 三段计费拆解
来自笔记 24。"AI 联网查资料并总结"看似一次操作，实际计费三段：
- AI 思考"需要联网"→ 输出 Token（决策型）
- 联网搜索返回 20000 字内容 → 作为输入 Token 喂给模型（消耗最大段）
- AI 生成总结 → 输出 Token（输出型）
关键认知：搜索返回内容会滚入后续上下文，不开新对话就持续叠加。多次联网搜索后再问问题，可能比直接搜索贵 3-5 倍。
三、响应时间百分位与延迟治理
Token 成本回答"贵不贵"，响应时间百分位回答"快不快"——两条曲线共同构成 AI 系统的效能基线。前一节讨论的慢思考（§2.1）会同时推高 Token 账单与延迟尾部，二者必须放在同一张仪表盘里看。
3.1 P50 / P95 / P99 的定义与价值
百分位数（Percentile） 用于衡量系统性能，表示有多少比例的请求响应时间低于某个值。
- P50（中位数）：50% 的请求低于此值，代表典型用户体验
- P95：95% 的请求低于此值，反映大多数用户体验
- P99：99% 的请求低于此值，用于发现长尾问题
为什么不用平均值：平均值易被极端值影响，无法准确反映用户体验。例：99 个请求 10ms、1 个请求 1000ms，平均值 = 19.9ms 看似良好，实际有用户遭遇 1 秒延迟。
SLA 设定：通常使用 "P95 < 200ms" 而非平均值，更能保证用户体验。三档百分位的关键价值：P50 看中位用户体验、P95 确保大部分用户满意、P99 识别系统瓶颈与异常。
3.2 LLM 应用的两条独立延迟曲线
LLM 应用的响应时间不是单一数字，至少要拆成两条独立曲线分别监控：
- 首 Token 延迟（TTFT, Time-To-First-Token）：用户感知"系统是否在响应"的关键指标，直接决定流式输出的体感。一般用 P95 卡 SLA（如 P95 TTFT < 1.5s），P99 用于发现冷启动、上下文过长或排队拥堵导致的尾部异常。
- 整体响应时间（端到端完成时间）：受输出 Token 数量、思维链长度、Function Calling 轮次影响极大，离散度远高于传统接口。
流式输出场景的体感拆解：TTFT 决定体感、整体时长决定耐心。把两者分别画百分位曲线，能快速定位"是模型本身慢"还是"前置编排/检索/工具调用慢"。
3.3 慢思考为何推高 P99：与 §2.1 思维链消耗的耦合
慢思考模式（→ §2.1 四类 Token 消耗场景中的"思维链消耗"）会把 P99 推高一个数量级——CoT 自我纠错 + 多路径尝试 + 逻辑验证带来的 5~20 倍 Token 增长，几乎同比例反映在端到端延迟尾部上。
实践纪律：必须按"快思考 / 慢思考"分桶看 P50/P95/P99，混在一起看会失真——慢思考样本会把整体 P99 拉到一个对快思考请求毫无意义的数字上。产品分级（免费档强制快思考、高价档放开慢思考）的依据除了成本（→「关键洞察 3」），也包含延迟尾部可控这条工程理由。
四、隐形成本：那些不显眼但要命的消耗
4.1 Token 成本的"隐形成本"陷阱
来自笔记 31。对话式 AI 设计工具承诺的"提问、迭代、完善、重复"流程看似直观，但会在不知不觉中带来偏差、模糊和不断飙升的 Token 计数。
典型模式：临时随意提示——"用户点击第三步最后一个选项时，应该自动进入第四步""第四步顶部要加一个按钮和复选框""不对，还是没出来，再试一次"——每次微调看似轻松快捷，累积起来消耗惊人。
Figma Make 真实案例：作者本以为几十条提示，实际 147 条，仅完成流程 1/3，相当于 Figma Professional 6-7 个月额度。问题根源不是工具，而是提示风格。
案例：Figma Make 项目 Token 消耗失控
来自笔记 31。
背景：作者试图在 Figma Make 中重新创建一个 Figma 原型。
数据：
- 提示日志：147 条（本以为也就几十条）
- 完成进度：仅完成流程 1/3
- Token 消耗：相当于 Figma Professional 账号 6-7 个月的提示额度
- 输出效果：确实不错，但 Token 消耗速度远超预期
结论："让这项工作成本高昂的是我的提示风格，而不是工具。"——这是 AI 工具按量计费时代最具代表性的"使用方式 > 工具选择"案例。
案例：Figma 计费政策变化（2026.3 起收费）
来自笔记 31。
时间线：
- 过去：Figma 没有对超额使用收费
- 2026 年 3 月：Figma 宣布开始执行收费政策
影响：Token 成本从隐性变显性，结构化提示的价值凸显。这是行业趋势——AI 工具厂商最终都会把 Token 成本透传给用户，使用方式优化从"加分项"变成"必修课"。
五、降本杠杆：从模态到提示再到 Harness
5.1 四模态降本杠杆
来自笔记 24。降本本质 = 在完成任务前提下，给模型更少、更精准的信息。
文字降本：
| 策略 | 说明 |
|---|---|
| 去礼貌用语 | "请"、"谢谢"、情绪化表达对 AI 无意义，纯结构性指令即可 |
| 及时开新对话 | 话题切换时立即新建，避免历史上下文滚雪球 |
| 缓存技术（开发者） | 对固定 System Prompt 启用 Prompt Caching |
图片降本：
| 策略 | 说明 |
|---|---|
| 裁剪局部 | 只需分析图片某区域时先裁剪，减少切块数 |
| 低细节模式（开发者） | API 调用时强制 detail: low，约等于固定 85 Token |
| 预处理压缩 | 上传前将长边压缩至 768px 以内，避免额外切块费 |
音频降本：
| 策略 | 说明 |
|---|---|
| 去除静音 | 空白段照常计费，预处理去掉空白可直接缩短时长 |
| 先转文字再传 | 音频转文字后传 AI，文字成本约为音频的 1/10（不需要情感分析时首选） |
| 紧凑音频流 | 讲座/课程类录音采用更紧凑的音频流降低处理量 |
视频降本：
| 策略 | 说明 |
|---|---|
| 降低采样率 | 讲座/课程类每 5 秒采 1 帧，成本直降 70~80% |
| 手动截关键帧 | 不传完整视频，手动截取关键帧组图传入，成本可降 90%+ |
| 音画分离 | 仅需总结内容时，先分离音频转文字再传文字，大幅节省视频处理费 |
核心总结：文字控长度、图片压尺寸、音频去静音、视频降采样——四模态共同的降本逻辑都是"给模型更少、更精准的信息"。
Computer Use 截图降本三层策略（Anthropic 官方 2026-05-13）：CU Agent 是图片模态消耗最密集的场景（每步一张截图 ≈ 1,000-1,800 token），需要专用的三层降本架构：
| 层 | 策略 | 机制 | 效果 |
|---|---|---|---|
| L1 预降采样 | 截图发送 API 前预缩放至 1280×720（4.6 family）或 1080p（Opus 4.7） | 避免 API 静默降采样导致的坐标失配 + 控制每张 token 数 | 单张 ≈ 1,000 token，vs 4K 原图可能 1,800+ |
| L2 Cache-aware 滚动缓冲 | 保留最近 3 张截图原图，每 25 张批量替换旧截图为 [Image omitted] 占位符 | 批量修剪保持 message prefix 字节一致，prompt cache 命中率不降 | 稳态下 context 内仅 3 张原图 |
| L3 LLM-based Compaction | 输入 token 达 ~150K 时触发服务端摘要（beta compact-2026-01-12），用 8 段结构化 prompt 保留用户指令/任务模板/约束/进度/当前状态/下一步 | 回收上下文空间同时保留任务续航能力 | 长任务 context 始终 < 200K |
三层叠加的默认参数组合：1 个 cache breakpoint 在 system prompt + 3 个 breakpoint 在最近 tool_result 上，每轮前移并清理旧 breakpoint。这是 Anthropic 推荐的 CU 长任务成本控制标准配置。
5.2 服务端 task_budget：API 侧 Token 预算
2026-05-19 charrli 源码解析。客户端的四模态降本主要是"输入侧裁剪"；某顶级工业级 Agent 还在服务端引入了 task_budget 这条与客户端估算并行的硬限制通道：
| 维度 | 客户端预算估算 | 服务端 task_budget |
|---|---|---|
| 位置 | Agent 内部本地计算 | API 请求参数，由服务端强制执行 |
| 时机 | 每轮请求前估算 input + 预留 output | 整个 task 生命周期累计 token 上限 |
| 失败方式 | 触发本地压缩/截断 | 服务端直接返回 budget exhausted 错误 |
| 作用 | 防止单次请求超 context window | 防止失控 Agent 烧爆账户预算 |
关键工程细节：
task_budget是 task 级而非请求级——多轮工具调用共享同一 budget- Auto Compact 后客户端必须手动计算 remaining 并传递：服务端不知道客户端做过压缩，如果客户端不主动重置/调整 task_budget 传值，压缩后的剩余空间会被错误计算
- 客户端估算偏差是必然存在的（tokenizer 差异、工具结果不可预测）——task_budget 是兜底的"安全网"，让 Agent 在估算错误时仍然不会失控烧钱
为什么需要两条预算通道并存：
- 仅客户端估算 → 估算错误时 Agent 可以无限循环烧钱
- 仅服务端 budget → 客户端无法在请求前主动压缩，会浪费一次失败请求的成本
- 两者并行 → 客户端优先主动压缩降本，服务端兜底防失控
适用场景：
- 长程任务 Agent（DeepResearch / Coding Agent / 多 Agent 编排）
- 多租户平台（每个用户/团队不同 budget）
- 与「Harness 失效模式与反馈机制」框架 8
max_output_tokens三层恢复机制配合：output 上限是单次请求级别，task_budget 是整个任务级别，两层共同构成预算控制网
（来源：技术教科书：顶级开发团队设计的 Harness 工程项目源码什么样，作者 charrli，2026-05-19）
5.3 8 段式结构化提示框架
来自笔记 31。这是降低对话式 AI 工具 Token 浪费的核心方法论：
| 模块 | 作用 | 减少浪费的方式 |
|---|---|---|
| 1. 角色与人物设定 | 为模型提供明确的专业视角 | 消除语气偏差和不一致的建议 |
| 2. 目的与目标状态 | 说明业务成果以及"好"的标准 | 防止范围偏差和反复澄清 |
| 3. 输入 | 模型所需的所有材料、约束条件和上下文 | 避免无休止的"忘了提……"之类的后续补充 |
| 4. 指令/逻辑步骤 | 将目标转化为带有触发条件的可操作步骤 | 消除模型的猜测，并梳理思考顺序 |
| 5. 输出要求 | 指定可交付成果、保真度和格式 | 一次就得到正确的格式 |
| 6. 约束条件 | 模型不能更改的硬性边界 | 避免模型随意发挥时重新生成内容 |
| 7. 备用逻辑 | 告诉模型在某些内容缺失时应做何假设 | 防止停滞和矛盾的重写 |
| 8. 语气指导 | 定义沟通风格和重点 | 避免对布局没问题但表述不佳的情况进行重写 |
第 4 段的关键创新——触发条件→指令对：将目标拆成"当 X 发生时，就做 Y"的格式，比简单步骤列表更精确，能消除模型的猜测并梳理思考顺序。
第 7 段的容错设计——备用逻辑：告诉模型在某些内容缺失时应做何假设，防止停滞和矛盾的重写。这是提示工程中容易被忽略但非常重要的一环。
5.4 低成本完善 + 高成本执行的工作流分割
来自笔记 31。这是结构化提示降低 Token 成本的核心工作流：
核心思路：在低成本环境（ChatGPT/Gemini，按订阅或低单价计费）完善结构化提示，再放入按用量计费的高成本工具（Figma Make/v0/Lovable）执行。
为什么有效：
- 低成本环境迭代成本几乎为零，可以反复打磨
- 高成本工具一次到位避免几十次 Token 浪费
- 表述明确、减少模糊、尽早定义约束、结构化指令，让模型清晰知道该做什么、怎么做
Figma 官方建议：
- 在第一条提示里就尽可能塞足细节（任务、上下文、关键设计元素、预期行为和约束条件）
- 在将提示粘贴到 Make 之前，使用 AI 助手优化提示
- Figma Make 运行在 Anthropic Claude Sonnet 4 上，适用于 Anthropic 模型的结构化提示原则直接适用
实际效果对比：
| 维度 | 对话式提示 | 结构化提示 |
|---|---|---|
| 提示数量 | 几十到上百条 | 寥寥几次 |
| 迭代次数 | 频繁来回修正 | 少量微调 |
| Token 消耗 | 高 | 大幅降低 |
| 结果质量 | 受偏差和模糊影响 | 初稿就接近预期 |
5.5 通用提示设计器（Prompt Designer GPT）工作流程
来自笔记 31。
工具定位：定制 GPT，可在 ChatGPT、Gemini 上使用，核心是让 8 段式框架自动化。
工作方式：
- 输入粗略想法（如"重新设计加购页面提升转化率"）
- GPT 像快速访谈一样，只追问你没提供的关键信息
- 一旦有足够上下文，自动将想法扩展为完整、优化的 8 部分提示
- 格式正是 Figma Make 等工具实际需要的
适用工具：Figma Make、v0（Vercel）、Lovable 或任何其他按用量计费的 AI 设计工具。
价值：起到工作流程自动化作用，减少通常会消耗 Token 的几十次来回修正，更快摆脱"从零开始"的空白状态。
案例：8 段式提示完整示范——加购弹窗重设计
来自笔记 31。这是 8 段式框架的完整范例，覆盖一个真实业务场景：
目的：打造一个重新设计的加购弹窗（支持桌面与移动端响应式），通过优化染发测评后展示订阅套餐的方式，提升 D2C 美妆订阅流程的升级转化率。
角色 + 上下文：你是一名资深产品设计师，正在优化个性化染发测评后的关键加购环节。用户本应进入结算流程，却看到三个订阅层级（标准/增强/高级），因价值模糊、布局拥挤、层级不清、价格感知突兀导致大量流失。
输入（部分）：
- 现有设计系统、产品视觉、福利明细和定价
- 业务目标：在不使结账转化率降低超过 7% 的情况下，提高追加销售转化率
- 用户行为：用户预期进入结账流程却被不清晰的追加销售价值主张打断；与计划选项卡互动但忽略大多数辅助内容；由于之前的折扣，对价格敏感度较高
指令（触发条件 → 指令对，节选）：
- 用户完成测验 → 重新设计追加销售介绍，保持结账势头同时清晰说明展示升级原因
- 看到三个订阅选项 → 用突出价值差异而不过度堆砌细节的结构，取代选项卡式布局
- 价格在用户理解价值之前过早出现 → 重新构建价格展示方式，让用户首先理解价值驱动因素
- 桌面和移动体验必须保持一致 → 使用自动布局和一致的间距设计响应式框架
约束条件：不得重复使用或部分修改原始布局；关键升级细节无需滚动即可查看；不得重新解释福利内容或定价；不得添加或删除订阅层级；必须使用现有设计系统样式并包含产品图像。
备用逻辑：若任何图片或输入无法解析，默认原布局为杂乱、标签式、文字过多、价值层级模糊、价格突兀。
语气指导：保持中立、以用户为中心、注重转化的语气，优先考虑清晰度、信任度和决策的简洁性。
复盘：与"重新设计一下加购页面"这种一句话提示相比，这种 8 段式提示能让模型一次到位生成接近预期的初稿，省下几十次"再调一下"的 Token 浪费。
5.6 Harness 框架级降本：OMC 三组件拆解
来自 oh-my-claudecode 案例研究（28.3k Stars / 2.6k Forks 的 Claude Code 多智能体编排框架）。OMC 宣称通过 Harness 层工程化能节省 30-50% token 消耗，其降本组合可视为本方向"给模型更少、更精准的信息"元规则的 Agent 框架级范例：
| 降本组件 | 机制 | 与本方向元规则的对应 |
|---|---|---|
| 专业化分工 | 19 个专业 Agent 分入 5 条泳道，每个 Agent 只携带本职工作所需上下文 | "更少、更精准"——通过角色拆分把每个 Agent 的 context 缩到最小 |
| Context Resets 内置化 | 子 Agent 上下文逼近阈值（40%）时自动生成 JSON 交接文档，启动全新干净 Agent 加载继续 | 规避"上下文滚雪球"——把多轮叠加从隐性消耗变成结构化压缩 |
| 两层 Skill 按需注入 | 用户级 + 项目级 YAML Skill 仅在 trigger 命中时注入目标 Agent | 不预加载全部能力描述——按需调度替代默认拼接 |
重要声明：30-50% 节省是 OMC 项目方自述数据，未经第三方独立测量验证——在大模型 Token 计费场景下，任何降本声明都应注明：
- 测量基线（对比的是单 Agent 朴素运行 vs OMC 编排模式）
- 任务类型（OMC 主要场景是 macOS 上的长编码任务）
- 模型版本（基于 Anthropic Claude Sonnet）
对本方向的工程启示：
- 三类消耗场景的 Agent 级对应：OMC 把"上下文滚雪球"（→ context resets）+ "系统预设"（→ Skill 按需注入）+ "思维链消耗"（→ 专业化角色减少无关推理）这三类消耗对应到三个工程组件——这是从单次调用降本走向 Agent 框架级降本的范例
- Harness 即降本基础设施：当 Token 成本从隐性变显性（参考 Figma 2026.3 收费案例），Harness 层的工程化能力就是降本能力——这印证了"Token 成本意识是 AI 产品设计的新维度"
- 降本声明的可验证性是后续待探索问题：30-50% 是范围声明而非可复算数字——未来 Agent 框架的降本指标需要建立标准测量协议（基线模式、任务集、模型版本三件套）才能横向比较
5.7 商业层兜底：豆包"C 端免费 / B 端变现"的成本经济学
来自 [商业策略/02-doubao-free-model-bytedance-revenue-2026-04-02.md]。AI 产品的 Token 成本要不要透传给用户，决定权很大程度上不在工程能力，在母公司输血能力——豆包是典型反例。
豆包成本与字节利润对比：
| 维度 | 数据 |
|---|---|
| 豆包日运营成本 | 几百万/天（服务器/带宽/算力） |
| 豆包年研发+算力+推广 | 15-20 亿元/年 |
| 字节 2024 日均利润 | 6.6 亿元 |
| 字节 2024 全年净利润 | 2409 亿元 |
判断框架——AI 产品能否长期免费：
| 条件 | 豆包 | 大多数 AI 创业公司 |
|---|---|---|
| 母公司成熟业务输血 | ✅ 广告+电商+直播兜底 | ❌ 纯烧 VC |
| AI 成本占母公司利润比 | 极低（几百万 vs 6.6 亿） | 全部成本 |
| 数据飞轮 | ✅ 用户量大、留存高 | 用户增长慢 |
| B 端变现路径 | ✅ 火山引擎 + 硬件授权 + 生态联动 | 只有 C 端 |
对本方向的启示：当母公司有"输血+造血"能力时，C 端免费的真实成本结构能让 Token 计费变成"内部记账"——这与"Token 成本从隐性变显性"的行业趋势形成有趣对照。判断一款 AI 产品能否长期不向用户透传 Token 成本，看这四个条件就够了。
5.8 模型后端可替换：API 兼容层降本
来自 Claude Agent SDK 快速上手与 DeepSeek 配置教程（2026-05-20）。前述降本杠杆（§5.1-§5.7）聚焦于"给模型更少、更精准的信息"——输入侧裁剪、预算兜底、提示结构化、Harness 编排、商业层输血。但还有一个维度被忽略：不改代码，只改模型后端，让同一套 Agent 代码跑在更便宜的模型上。
核心机制：Claude Agent SDK 支持通过环境变量将请求路由到任意兼容 Anthropic API 协议的模型端点。代码零修改，只需切换环境变量即可在不同成本档位的模型间切换。
关键环境变量配置：
| 环境变量 | 作用 | DeepSeek 配置示例 |
|---|---|---|
ANTHROPIC_BASE_URL | 指定 API 端点地址，替换默认的 Anthropic 端点 | https://api.deepseek.com/anthropic |
ANTHROPIC_AUTH_TOKEN | 目标模型厂商的 API 密钥 | DeepSeek API Key |
ANTHROPIC_MODEL | 主 Agent 使用的模型 | deepseek-v4-pro |
ANTHROPIC_DEFAULT_HAIKU_MODEL | 轻量任务使用的模型（对应 Haiku 档位） | deepseek-v4-flash |
CLAUDE_CODE_SUBAGENT_MODEL | 子 Agent 使用的模型 | deepseek-v4-flash |
分层模型策略——成本最优的任务-模型匹配：
| 任务复杂度 | 模型档位 | 示例配置 | 成本特征 |
|---|---|---|---|
| 高复杂度（主 Agent 推理、架构决策） | 旗舰模型 | deepseek-v4-pro | 单价较高但任务成功率有保障 |
| 低复杂度（子 Agent 执行、文件读写、格式化） | 轻量模型 | deepseek-v4-flash | 单价极低，适合高频简单任务 |
这是"慢思考 vs 快思考"分级逻辑（→ 洞察 3）在 Agent 架构层的自然延伸：不同复杂度的子任务由不同成本档位的模型承接，而非所有任务统一使用最贵的旗舰模型。
国内厂商 API 兼容层成熟度：
| 厂商 | 兼容接口 | 说明 |
|---|---|---|
| DeepSeek | Anthropic API 兼容端点 | 已上线，支持 /anthropic 路径直接兼容 |
| 阿里云（通义） | Anthropic API 兼容接口 | 通过 DashScope 提供兼容层 |
| MiniMax | Anthropic API 兼容接口 | 已推出兼容模式 |
国内主流模型厂商已形成"兼容层即渠道"的竞争格局——通过提供 Anthropic/OpenAI 兼容接口，降低开发者迁移成本，争夺存量 Agent 生态的调用量。
PM 决策框架——何时适合替换模型后端：
| 场景 | 是否适合替换 | 判断依据 |
|---|---|---|
| 内部工具 / 研发辅助 Agent | ✅ 适合 | 对输出质量容忍度高，成本敏感度高 |
| 批量数据处理 / 格式转换 | ✅ 适合 | 任务简单、确定性强，不依赖模型推理能力 |
| 面向用户的核心产品功能 | ⚠️ 谨慎 | 需 A/B 测试验证替换模型的任务成功率 |
| 强依赖 Claude 原生能力的场景（Artifacts、Computer Use 等） | ❌ 不适合 | 兼容层无法覆盖 Claude 独有的能力边界 |
| 合规/安全敏感场景 | ⚠️ 谨慎 | 需评估替换模型的安全对齐水平 |
风险提示：
- 兼容层质量未经大规模验证：Anthropic API 兼容接口是各厂商自行实现的"方言翻译层"，边缘 Case（如复杂工具调用嵌套、长上下文处理）的行为一致性尚未被充分测试
- 模型能力差异影响 Agent 任务成功率：模型切换不等于能力等价——替换后端后，Agent 的推理质量、指令遵循度、工具调用准确率都可能出现退化
- 厂商锁定风险反转：从"锁定在 Claude"变成"锁定在兼容层协议"——如果 Anthropic API 协议发生不兼容变更，所有依赖兼容层的部署都需要同步适配
与本方向其他降本杠杆的关系：模型后端可替换是与输入侧优化（§5.1-§5.5）、Harness 编排优化（§5.6）、预算机制（§5.2）正交的独立降本维度——前者降的是"每次调用的 Token 数"，后者降的是"每个 Token 的单价"。两个维度可以叠加使用。
5.9 Thinking effort 对 Computer Use 成本的影响
来自 Anthropic 官方 CU 最佳实践（2026-05-13）。CU 任务与代码/数学任务有本质区别——主要是感知和机械操作而非深度逻辑推理，因此思考力度（thinking effort）对成本/质量的影响曲线与常规任务不同。
Opus 4.7 CU 场景 effort 推荐：
| 场景 | Thinking effort | 理由 |
|---|---|---|
| 默认推荐 | high | 接近 max 的任务成功率，输出 token 仅为 max 的约一半 |
| 高吞吐 / 成本敏感 | low | token 消耗远低于 medium，质量介于 Opus 4.6 high 和 max 之间 |
| 简单定义明确的工作流 | 建议用 Sonnet 4.6 | 延迟最低，短任务 UI 一致性高时足够 |
| 复杂一次性任务 | max | 必须首次成功时使用 |
4.6 family CU 场景 effort 推荐：
| 场景 | Thinking effort | 理由 |
|---|---|---|
| 默认推荐 | medium | 最佳准确率-成本比；与 high 在重试后收敛到相同成功率，token 仅为一半 |
| 高吞吐 / 成本敏感 | low | token 实际 < 关闭思考（更少错误→更少重试），准确率 ≈ 关闭思考 |
| 简单工作流 / 最快 | 关闭思考 | 延迟最低但准确率最低 |
| 复杂一次性任务 | high | 仅当不支持重试时使用；有重试则 medium 最终效果等价 |
| 不推荐 | 无精度收益，token 成本进一步上升——UI 任务不需要极深推理 |
关键 PM 决策数据：Opus 4.7 low effort 在 OSWorld 基准上得分 ≈ Sonnet 4.6 max effort，但 token 消耗仅为后者的 ~1/10。如果当前产品用 Sonnet 4.6 high/max 做 CU，切换 Opus 4.7 low/high 可能是更优成本效益选择。
模型选型矩阵（CU 场景）：Sonnet 4.6 机械点击精度最高、对重度降采样最鲁棒、成本最低——推荐默认起步；Opus 4.7 推理更强、分辨率预算更大（3.75MP）、low effort 即强——推荐高难度/高分辨率场景；Haiku 4.5——延迟优先时使用。
关键洞察
洞察 1：上下文滚雪球是最大的"沉默杀手"
来自笔记 24。Token 浪费排行榜上，上下文滚雪球几乎稳居第一。原因是它完全无感——用户感觉只是"多聊了几句"，实际每轮请求都把全部历史重发了一遍。实践建议：把"开新对话"作为产品引导的默认行为，而不是高级技巧。Claude 等工具自带的"长对话压缩"也是同样思路。
洞察 2：Token 成本意识是 AI 产品设计的新维度
来自笔记 31。在设计 AI 产品时，不仅要考虑功能和体验，还要考虑用户的 Token 消耗模式。引导用户采用结构化提示可以同时降低成本和提升满意度——这是 AI 产品独有的"降本即提质"机会。
推论：AI 产品的"用户教育"成本远高于传统 SaaS，因为用户的使用方式直接决定他们的实际付费金额。Figma 主动建议用户在第一条提示塞足细节，本质是在保护用户的钱包。
洞察 3：慢思考 5-20 倍成本是产品分级的天然依据
来自笔记 24。慢思考 Token 是快思考的 5~20 倍，这意味着同一个用户问题在两种模式下的成本差异是数量级的。产品启示：免费/低价档位强制快思考，高价档位放开慢思考——这是几乎所有 AI 产品最终走向的分级模型。慢思考也直接推高延迟尾部（→ §3.3 慢思考为何推高 P99），P99 监控可以捕捉慢思考触发引起的长尾。
洞察 4：设计师角色从"设计界面"扩展到"设计生成界面的提示"
来自笔记 31。在 AI 工具不断成熟、Token 管控越来越严的趋势下，越早适应这种转变的团队，跑得越快、成本越低。本质上，正在从设计界面 → 设计生成界面的提示。
对从业者的启示：结构化提示正成为一项核心工作流程技能，而不是一种专门技术。提示工程不是额外负担，而是新的核心能力。
洞察 5："给模型更少、更精准的信息"是所有降本策略的元规则
来自笔记 24/31 综合。文字控长度、图片压尺寸、音频去静音、视频降采样、提示用结构化——所有降本策略可以归约到同一句话："在完成任务的前提下，给模型更少、更精准的信息"。这条元规则比记住每个具体策略更重要——它能在面对新的模态、新的工具时给出方向。
洞察 6：Token 成本"从隐性变显性"是行业必然趋势
来自笔记 31。Figma 2026.3 开始收费、ChatGPT 推出按量额度、各大 IDE-Agent 把 Token 消耗暴露给用户——所有 AI 产品最终都会把 Token 成本透传到用户侧。对 PM 的提醒：在产品策略上为这一天做准备：① 提供 Token 消耗可视化；② 内置提示优化助手；③ 分级订阅与按量计费组合。Token 显性化让"降本工程"和"工程纪律"绑得更紧（→ AI 研发效能与 SDLC 工程纪律）——团队的提示风格直接决定账单。
洞察 7：8 段式框架的通用性远超设计场景
来自笔记 31 的延伸思考。8 段式框架的核心逻辑（"表述明确、减少模糊、尽早定义约束、结构化指令"）适用于任何需要结构化提示的场景：代码生成（GitHub Copilot/Cursor）、内容创作（Jasper/Copy.ai）、数据分析（Julius/Hex）。触发条件→指令对和备用逻辑这两个设计是该框架的"创新点"，值得在所有提示设计场景中复用。
洞察 8：杰文斯悖论作用于 Token 经济——单价降反而总账涨
来自 [商业策略/13-Token经济产业链全景-2026-04-14.md]。Token 降本不是终点，反而是更大支出的起点——杰文斯悖论在 Token 经济上得到验证：
- 推理成本：技术进步使推理成本下降 280 倍
- 总体支出：使用需求激增，导致总体支出反而增加 2.4 倍
- 类比：汽车油耗变低后，人们驾车次数反而增多，最终石油消耗总量不降反升
对本方向的反向启示：单次调用的"降本"工程做得越成功，越可能触发用户增加调用频次、扩展使用场景，最终公司总 Token 账单不降反升。这意味着：
- 降本不是终极目标——降本释放出的预算很可能被新场景吸收
- 总账控制需要工程之外的机制——产品策略（分级订阅、按量计费）和用户教育需要同步设计
- 行业层面的提价是结构性必然：2026 年起 AWS（+15%）、谷歌云、网宿、Ucloud 先后涨价，行业从"价格战"转向"价值战"——摩根士丹利测算阿里云每 10% 涨价能带来 4 个百分点利润率提升
与"Token 成本从隐性变显性"洞察的呼应：杰文斯悖论是因，定价权回归是果——只有当总账上涨成为客观事实，云厂商才有底气把成本透传给用户。
洞察 9：模型后端可替换性是 Agent 时代的新降本维度——不改代码只改环境变量
来自 Claude Agent SDK 配置教程。前八条洞察聚焦于"减少 Token 数"或"优化使用方式"，但 Agent SDK 的环境变量可替换机制揭示了一个正交维度：不减少 Token 数，而是降低每个 Token 的单价。通过 API 兼容层将请求路由到低成本模型后端，代码零修改，只需切换环境变量。
核心判断：当 Agent 框架普遍支持模型后端可替换时，"选择哪个模型"从一次性的架构决策变成了运行时可调的运维参数——这让 PM 可以按任务复杂度、成本敏感度、质量要求动态匹配模型档位，而不是所有场景统一用最贵的模型。
与洞察 5 的关系："给模型更少、更精准的信息"（洞察 5）降的是量，"给更便宜的模型处理"降的是价——量×价 = 总成本，两条降本路径独立且可叠加。
待探索问题
- 国内主流模型（Qwen/DeepSeek/智谱）对中文常用术语的 Token 收录差异有多大？能否量化对比同一段文本的 Token 数？
- Prompt Caching 在不同厂商的实现差异——是否真能把固定 System Prompt 的边际成本降到接近零？
- 多轮对话场景下，"压缩历史 vs 开新对话"哪种更划算？是否有定量决策模型？
- 图片低清固定 85 Token 的精度损失边界在哪？哪些任务可以放心用低清，哪些必须用高清？
- 视频"音画分离"策略在哪些任务上会损失关键信息？是否存在"自动选择策略"的判别框架？
- 8 段式框架在代码 Agent（Cursor/Claude Code）场景的适配度如何？需要哪些字段调整？
- Token 消耗可视化能否成为 AI 产品的标配 UX 组件？参考实现是什么？
- DeepSeek 等国产模型在 Claude Agent SDK 中作为后端时，Agent 任务成功率与 Claude 原生模型相比差异有多大？是否存在可量化的"质量-成本"权衡曲线？
- CU Agent 服务端 Compaction（
compact-2026-01-12beta）进入 GA 后，客户端 LLM-based Compaction 是否会被完全替代？两者长期共存还是服务端收敛？
来源索引
| 编号 | 标题 | 日期 | 类型 |
|---|---|---|---|
| S01 | Token 计费全模态拆解：文字、图片、音频、视频计算公式与降本策略 | 2026-04-13 | 笔记整理（原 24，公众号文章） |
| S02 | 对话式 AI 的 Token 隐形成本：8 段式结构化提示框架 | 2026-04-17 | 笔记整理（原 31，TCC 翻译情报局） |
| S03 | [商业策略/13] Token 经济产业链全景：五环架构、杰文斯悖论与定价权回归 | 2026-04-14 | 商业视角延伸：贡献"为什么单价 -280× 总支出 +2.4×"的总账逻辑、MaaS 层定位、Token 经济产业链五环架构 |
| S04 | [商业策略/02] AI 产品免费策略的商业逻辑：豆包与字节的"C 端免费、B 端变现"模型 | 2026-04-02 | 案例（豆包成本经济学）、AI 产品长期免费的判断框架 |
| S05 | Claude Agent SDK 快速上手与 DeepSeek 配置教程 | 2026-05-20 | 公众号文章：环境变量切换模型后端、分层模型策略、国内厂商 API 兼容层成熟度 |
| S06 | Best practices for computer and browser use with Claude | 2026-05-13 | Anthropic 官方博客：CU 截图 token 消耗实测、三层降本架构（预降采样/Cache-aware 滚动缓冲/LLM-based Compaction）、Thinking effort 对 CU 成本的影响、模型选型矩阵 |
演进记录
- 2026-05-15 v0.1 — 首次构建，由 /route-knowledge 路由分析触发。从 Token 与模型/ 目录下原始笔记 24、31 抽取，搭建 Token 计费与降本工程方向骨架，纳入 4 个核心概念、4 个框架、5 个案例、7 条洞察、7 个待探索问题。来源数：2。
- 2026-05-18 v0.1.1 — 由 /route-knowledge 路由分析触发，纳入 oh-my-claudecode 案例研究。新增案例（OMC 声称 30-50% Token 节省的三组件拆解：专业化分工 + Context Resets 内置化 + 两层 Skill 按需注入，对应"上下文滚雪球 / 系统预设 / 思维链消耗"三类消耗的 Agent 框架级降本机制；声明 30-50% 节省为框架方自述未独立验证）。来源数 2 → 3。文件名日期 2026-05-15 → 2026-05-18。
- 2026-05-19 v0.1.2 — 叙述结构整理：将原"核心概念 / 方法论与框架 / 案例库"三段式重排为"计费机制 → 消耗场景 → 隐形成本 → 降本杠杆"四阶段，使内容沿同一逻辑链推进；新增"叙述结构"说明段、与「响应时间指标」「AI 研发效能与 SDLC 工程纪律」的交叉引用。
- 2026-05-20 v0.1.3 — 整体平移合并《响应时间指标-P50-P95-P99.md》全文为新章节「三、响应时间百分位与延迟治理」（含 P50/P95/P99 定义、TTFT、流式输出双曲线监控、慢思考推高 P99 与 §2.1 思维链消耗的耦合），原"三、隐形成本"顺延为"四"、"四、降本杠杆"顺延为"五"；移除已并入的兄弟方向交叉链接，原文件随即删除。
- 2026-05-20 v0.1.4 — 由 /route-knowledge-pm 路由触发，新增 §5.8"模型后端可替换：API 兼容层降本"——Claude Agent SDK 环境变量切换模型后端、分层模型策略、国内兼容层成熟度、PM 决策框架与风险提示；新增洞察 9（模型后端可替换性是 Agent 时代的新降本维度）和 1 条待探索问题（国产模型作为 Agent 后端的质量-成本权衡曲线）。来源数 4 → 5。
- 2026-05-20 v0.1.5 — 由 /route-knowledge-pm 路由触发（Anthropic CU 最佳实践博客 2026-05-13）。§1.2 新增 CU 截图 token 消耗实测数据（1,000-1,800 token/张、100 步填满 200K window）和 API 内部分辨率限制；§5.1 新增 CU 三层降本策略表（预降采样/Cache-aware 滚动缓冲/LLM-based Compaction）；新增 §5.9 Thinking effort 对 CU 成本的影响（Opus 4.7 + 4.6 family effort 推荐矩阵 + CU 模型选型矩阵）；新增 1 条待探索问题（服务端 Compaction beta GA 后的客户端替代性）。来源数 5 → 6。