成本 - 如何持续降低 Agent 的单位结果成本？ ​

生产级 AI Agent（人工智能智能体）的 Cost Engineering（成本工程），绝不是“少用一些 Token（模型处理单元）”，也不是把所有任务都切换到更便宜的 Model（模型）。

真正的问题是：

完成一个真实业务结果到底消耗了什么资源？这些资源为什么被消耗？哪些属于 Necessary Cost（必要成本），哪些属于可以在不破坏业务护栏的情况下减少的 Avoidable Cost（可避免成本）？剩余必要工作应该走哪条最经济的执行路径？当成本开始失控时，Runtime（运行时）又如何主动限制，而不是月底才从账单里发现问题？

整章可以先建立三个核心模型：

Accounting Model（成本核算模型）：钱花在哪里？

Consumption Model（资源消耗模型）：为什么花这么多？

Economic Decision Model（经济决策模型）：这些钱值不值得？

最终主链：

Business Outcome（业务结果）
→ Resource Metering（资源计量）
→ Pricing Function（计价函数）
→ Cost Attribution（成本归因）
→ Waste Detection（浪费识别）
→ Economic Routing（经济路由）
→ Budget Enforcement（预算执行）
→ Outcome Validation（结果验证）

一、Cost Fundamentals（成本基础） ​

1.1 Agent Cost 是什么？ ​

最常见的错误认知是：

Agent Cost = LLM Token Cost（大语言模型 Token 成本）。

这是明显不完整的。

一个 Data Agent（数据智能体）任务可能经历：

User Request（用户请求）
→ Model Planning（模型规划）
→ Metadata Retrieval（元数据检索）
→ SQL Generation（SQL 生成）
→ Warehouse Query（数据仓库查询）
→ Model Analysis（模型分析）
→ Chart Generation（图表生成）
→ Evaluation（评测）

一个 Coding Agent（研发智能体）可能经历：

Repository Retrieval（代码仓库检索）
→ Model Reasoning（模型推理）
→ File Read / Write（文件读写）
→ Sandbox Execution（沙箱执行）
→ Test Execution（测试执行）
→ Replanning（重新规划）
→ Code Review（代码审查）

企业级 Action Agent（操作智能体）还可能调用：

CRM（客户关系管理系统）
Payment API（支付接口）
Search（搜索）
Database（数据库）
Browser（浏览器）
Audit System（审计系统）

因此最底层的 Accounting Model（成本核算模型）应该是：

Total Cost（总成本） = 各类 Resource Usage（资源使用量）经过对应 Pricing Function（计价函数）计算后的成本之和。

对于线性计价资源，可以近似理解为：

Total Cost（总成本）
≈
Σ Usageᵢ（第 i 类资源使用量）
×
Effective Unit Priceᵢ（有效单位价格）

但必须强调：

这是核算抽象，不代表所有资源都是“使用量 × 固定单价”。

生产环境还可能存在：

• Cached Pricing（缓存计价）
• Tiered Pricing（阶梯计价）
• Long-context Pricing（长上下文计价）
• Batch Pricing（批处理计价）
• Service Tier Pricing（服务层级计价）
• Per-call Pricing（按调用计价）
• Compute-time Pricing（按计算时长计价）
• Storage Pricing（按存储量计价）

因此成熟的 Cost Platform（成本平台）应该支持：

Pricing Catalog（价格目录） + Pricing Function（计价函数）

而不是在业务代码里散落：

price = 0.002

从企业 Agent Platform（智能体平台）视角，可以把成本分成三类。

Serving Cost（线上服务成本） ​

直接服务用户任务：

• Model（模型）
• Tool（工具）
• Search（搜索）
• Database（数据库）
• Browser（浏览器）
• Sandbox（沙箱）
• External API（外部接口）
• Memory Retrieval（记忆读取）

Platform Cost（平台成本） ​

多个 Agent 共用：

• Worker（工作节点）
• Cache（缓存）
• Storage（存储）
• Vector Database（向量数据库）
• Memory Infrastructure（记忆基础设施）
• Observability Platform（可观测平台）

Improvement Cost（持续优化成本） ​

用于持续改进 Agent：

• Evaluation（评测）
• Judge Model（评测模型）
• Regression Test（回归测试）
• Prompt Optimization（提示词优化）
• Offline Experiment（离线实验）

所以：

Model Cost（模型成本）只是 Agent Cost 的一个子集。

对于一次具体 Run（执行），还要区分：

Direct Cost（直接成本） ​

可以直接 Attribution（归因）到某次执行：

• Model Call（模型调用）
• Search
• Tool API
• Warehouse Query
• Sandbox Runtime（沙箱运行时间）

Allocated Shared Cost（分摊共享成本） ​

例如：

• Worker Cluster（工作节点集群）
• Vector Database
• Cache Cluster
• Observability Platform

这些资源无法天然属于某一条 Run，可以根据：

• Request Count（请求数）
• CPU Time（CPU 时间）
• Storage Usage（存储使用量）
• Tenant Usage Share（租户使用占比）

做 Allocation（成本分摊）。

因此企业里可能同时维护：

Direct Unit Cost（直接单位成本）

更适合 Runtime Optimization（运行时优化）。

以及：

Fully Loaded Unit Cost（完全单位成本）

在 Direct Cost 基础上按照企业口径增加部分 Shared Cost Allocation（共享成本分摊），更适合经营和 FinOps（云成本运营）视角。

但 Improvement Cost（持续优化成本）不应该机械地全部摊进每次线上 Task。它通常应该独立观测；只有做更完整的 Unit Economics（单位经济性）分析时，才根据业务口径决定是否摊销。

从优化角度，还可以进一步拆成：

Total Cost（总成本）
├─ Necessary Cost（必要成本）
└─ Avoidable Cost（可避免成本）

这里的 Avoidable Cost 不是：

“理论上应该全部消灭的成本”。

更准确的定义是：

在不破坏 Quality（质量）、Reliability（稳定性）、Safety（安全）、Policy（策略）等业务 Guardrail（护栏）的情况下，可以通过架构、策略或执行优化减少的成本。

例如：

• 无关 Context
• 不必要 Retry
• Duplicate Work（重复工作）
• 无收益 Fan-out
• Abandoned Work（废弃工作）
• Zombie Work（僵尸工作）
• 不必要的高质量执行路径

因此 Cost Optimization 的第一优先级通常不是：

买更便宜的模型。

而是：

先停止购买本来就不需要的资源。

1.2 什么是 Cost per Outcome（单位结果成本）？ ​

如果只知道：

“这个月 Agent 花了 100 万。”

工程决策价值很有限。

必须先明确：

Cost Unit（成本单位）是什么？

常见层级：

Cost per Request（单请求成本）
→ Cost per Task（单任务成本）
→ Cost per Successful Task（单成功任务成本）
→ Cost per Business Outcome（单位业务结果成本）

生产 Agent 最值得关注的是：

Cost per Successful Outcome（单位成功结果成本）

严格定义：

Cost per Successful Outcome（单位成功结果成本）
=
Total Cost（总成本）
/
Successful Outcomes（成功结果数量）

为什么不应该只看 Cost per Task？

因为失败任务经常反而更贵。

例如 Data Agent：

成功路径：

Plan（规划）
→ SQL
→ Query（查询）
→ Answer（回答）

Cost ≈ $0.05

失败路径：

Wrong SQL（错误 SQL）
→ Query
→ Fail（失败）
→ Replan（重新规划）
→ Strong Model Escalation（强模型升级）
→ Re-query（重新查询）
→ Verify（验证）
→ Answer

Cost ≈ $0.18

所以：

提高成功率本身，也可能是一种成本优化。

企业客服 Agent 更明显。

方案 A：

AI Cost / Task（单任务人工智能成本） = $0.02
Automation Success（自动处理成功率） = 60%

方案 B：

AI Cost / Task = $0.05
Automation Success = 95%

如果失败后需要 Human Review（人工审核），方案 B 虽然 AI 成本更高，却可能拥有更低的 Total Business Cost（业务综合成本）。

因此 Cost per Business Outcome 可以根据业务需要进一步纳入：

Human Escalation Cost（人工升级成本）

但不需要把这一章扩展成完整人力成本会计。

这里还有一个很重要的统计边界：

Successful Outcome（成功结果）的定义必须稳定。

例如 Data Agent v1：

SQL 能执行就算成功。

Data Agent v2：

SQL 正确 + 指标正确 + 真正回答用户问题才算成功。

那么两个版本的：

Cost per Successful Outcome

不能直接比较。

因为分母已经发生变化。

可以把这种问题理解成：

Denominator Drift（分母漂移，本文工程表达）。

所以版本比较时应该固定或版本化：

• Task Definition（任务定义）
• Success Criteria（成功标准）
• Evaluation Version（评测版本）
• Dataset Version（数据集版本）
• Workload Mix（工作负载结构）

否则所谓：

Cost / Success 下降

可能只是成功标准被放宽。

1.3 成本优化的目标是什么？ ​

Cost Optimization（成本优化）不是：

Minimize Cost at All Costs（不惜一切代价降低成本）。

真正的问题是：

Constrained Optimization（约束优化）。

可以理解为：

Minimize Cost per Successful Outcome
（最小化单位成功结果成本）

Subject to（满足约束）：

Quality ≥ Target（质量达标）
Reliability ≥ Target（稳定性达标）
Latency ≤ Target（延迟达标）
Safety Must Hold（安全约束必须成立）
Policy / Compliance Must Hold
（策略 / 合规要求必须成立）

因此经常存在 Pareto Trade-off（帕累托权衡）。

例如 Coding Agent：

从 B 到 C：

Incremental Cost（增量成本）
= +$0.06

Incremental Outcome Gain（增量结果收益）
= +3 个百分点

是否值得，要看一个额外成功修复的业务价值。

这就是：

Marginal Cost（边际成本）

真正需要问的是：

多花下一块钱，可以换来多少额外业务结果？

Multi-Agent（多智能体）、Verification Agent（验证智能体）、Strong Model（强模型）、Deep Reasoning（深度推理）都应该用这种方式判断。

阶段总结 ​

便宜不是一次调用便宜，而是在业务约束成立以后，一个成功业务结果的综合成本更低。

二、Measurement & Attribution（测量与归因） ​

2.1 怎么测量 Agent 的真实成本？ ​

生产成本系统首先应该是：

Resource Metering System（资源计量系统）。

不同资源需要使用真正能够解释成本的 Meter（计量单位）。

因此：

Tool Call Count（工具调用次数） ≠ Tool Cost（工具成本）。

例如两个 SQL Tool Call：

Query A：
扫描 1MB

Query B：
扫描 10TB

虽然都是：

tool_calls = 1

真实成本可能相差几个数量级。

所以 Data Agent 的 Tool Telemetry（工具遥测）最好进一步记录：

bytes_scanned（扫描字节数）
compute_time（计算时间）
warehouse_tier（数据仓库层级）
cache_hit（缓存是否命中）
result_size（结果大小）

Tool Cost 还可以从三个分析维度理解：

Definition Cost（工具定义成本）

Invocation Cost（工具执行成本）

Result / Reprocessing Cost（工具结果及后续重复处理成本）

例如：

100 Tool Definitions（100 个工具定义）
→ Tool Name（工具名称）
→ Description（工具描述）
→ Parameter Schema（参数结构）

即使最终只调用两个 Tool：

其余 Tool Definition 仍可能长期占据 Model Context（模型上下文），持续产生 Input Token 成本。

真正执行 Tool 后，又可能产生：

Invocation Charge（工具执行费用）
+
Result Payload（结果载荷）
+
Future Context Reprocessing
（后续上下文重复处理）

但需要注意：

这三类是成本分析维度，不一定是互斥的账本科目。

如果 Provider（供应商）已经把 Tool Definition 的 Token 计入 Input Tokens，那么 Cost Ledger（成本账本）不能再次把 Definition Cost 加一遍。

否则就会发生：

Double Counting（重复计算）。

另一个必须严谨处理的是：

Provider-specific Usage Semantics（供应商特定使用量语义）。

某个 Provider 可能返回：

input_tokens
cached_input_tokens
output_tokens
reasoning_tokens

不能看到四个字段就机械相加。

因为：

Cached Tokens（缓存 Token）可能已经是 Input Tokens（输入 Token）的子集。

Reasoning Tokens（推理 Token）可能已经属于 Output Usage（输出使用量）的子集。

所以 Cost Calculator（成本计算器）应该是：

Provider-aware（理解供应商计量语义的）

而不是字段求和器。

成熟平台还需要：

Versioned Pricing Catalog（版本化价格目录）

至少应该支持：

Provider（供应商）
Resource Type（资源类型）
Model / Tool（模型 / 工具）
Usage Type（使用量类型）
Region（区域）
Service Tier（服务层级）
Currency（币种）
Pricing Rule（计价规则）
Effective From（生效时间）
Effective To（失效时间）

一个非常重要的原则是：

Pricing Is Temporal Data（价格是具有时间版本的数据），不是代码常量。

否则供应商调价后：

历史成本就很难公平比较。

2.2 模型是怎么计费的？ ​

这一题不能写成：

“模型 A 多少钱，模型 B 多少钱。”

具体价格会持续变化。

真正稳定的知识是：

什么因素共同决定 Effective Model Cost（模型有效成本）。

最终可以压缩成六类。

Usage Type（使用量类型） ​

常见包括：

• Input Tokens（输入 Token）
• Cached Input Tokens（缓存输入 Token）
• Output Tokens（输出 Token）
• Reasoning / Thinking Usage（推理 / 思考使用量）
• Multimodal Usage（多模态使用量）

因此：

100K Total Tokens（10 万总 Token）

并不代表两个任务成本相同。

例如：

Task A：

90K Input（输入）
10K Output（输出）

Task B：

30K Input
70K Output

如果 Output Price（输出价格）明显高于 Input Price（输入价格）：

Task B 会明显更贵。

所以：

Total Tokens 只是 Usage Summary（使用量摘要），不是完整成本指标。

Model Tier（模型能力层级） ​

不同模型拥有不同的：

Capability / Cost Profile（能力 / 成本特征）

但不能简单认为：

贵模型一定更强，便宜模型一定更弱。

真正 Agent Model Selection（智能体模型选择）需要同时比较：

• Task Success（任务成功率）
• Average Turns（平均轮次）
• Tool Usage（工具使用量）
• Escalation Rate（升级率）
• Latency
• Cost per Successful Outcome

例如：

最后一行才是真正值得比较的。

Context Tier（上下文档位） ​

Pricing Function（计价函数）不一定线性。

某些模型在超过特定 Context Size（上下文大小）以后：

会进入不同 Pricing Tier（计价档位）。

因此：

Context：
270K → 275K

虽然 Token 只增加一点点：

实际金额可能发生 Step Change（阶跃变化）。

所以 Context Optimization（上下文优化）不仅可以：

减少 Token。

还可能：

避免跨入更昂贵的计价档位。

Cache Strategy（缓存策略） ​

缓存可能存在不同：

• Cache Write（缓存写入）
• Cache Read（缓存读取）
• Cached Input（缓存输入）
• Cache Storage（缓存存储）

价格。

因此 Prompt Cache（提示词缓存）不是：

“支持就打开”。

它必须通过后续真实复用：

收回 Cache Creation / Write（缓存创建 / 写入）成本。

Processing Tier（处理层级） ​

同一个 Model 可能存在：

• Standard（标准处理）
• Fast / Priority（快速 / 优先处理）
• Flex（弹性处理）
• Batch（批处理）

等模式。

本质上又是：

Cost ↔ Latency（成本与延迟）

之间的 Trade-off（权衡）。

所以：

不要为 Workload（工作负载）不需要的 SLA（Service Level Agreement，服务水平协议）付费。

Interactive Agent（交互型智能体）可能愿意为低延迟付费。

Offline Eval（离线评测）则通常没有必要购买同等级实时 SLA。

Capacity Model（容量模式） ​

还要区分：

• Pay-as-you-go（按量付费）
• Provisioned Capacity（预配置容量）
• Self-hosted（自托管）

按量付费主要表现为 Variable Cost（可变成本）。

Provisioned / Self-hosted 则更接近 Capacity Cost（容量成本）。

这时：

Utilization（利用率）

变得非常重要。

例如：

Purchased Capacity（购买容量） = 100
Average Used Capacity（平均使用容量） = 20

理论 Unit Price（单位价格）可能很低。

但 80% 长期闲置以后：

单位业务结果成本仍可能很高。

所以：

Capacity Is Cheap Only When It Is Used（容量只有真正被利用时才便宜，本文记忆性表达）。

API vs Self-hosted（托管接口 vs 自托管）也不能只比较 Model Price。

应该看：

TCO（Total Cost of Ownership，总拥有成本）

包括：

• GPU
• Serving Cluster（推理集群）
• Idle Capacity（空闲容量）
• Reliability Overhead（稳定性额外成本）
• SRE / Operations（可靠性工程 / 运维）
• Model Upgrade（模型升级）
• Engineering Cost（工程成本）

不存在一个通用规律：

“超过 X QPS（每秒查询数）以后就一定应该自托管。”

Break-even Volume（规模盈亏平衡点）取决于：

• Utilization
• Peak / Average Ratio（峰均比）
• Model Size（模型规模）
• Batchability（可批处理性）
• Availability Requirement（可用性要求）
• GPU 成本
• 运维能力

Multimodal Pricing（多模态计费） ​

生产 Agent 可能处理：

• Text（文本）
• Image（图片）
• Audio（音频）
• Video（视频）
• PDF

不同 Modality（模态）可能使用不同 Meter 和 Pricing Function。

所以：

Cost Platform 不能假定所有 Usage 都是文本 Token。

最终应记住：

Effective Model Cost（模型有效成本） = Task Usage Shape（任务使用形态）经过 Provider-specific Pricing Function（供应商特定计价函数）计算后的结果。

具体价格会变。

计费结构与比较方法才是长期知识。

2.3 怎么做 Cost Attribution（成本归因）？ ​

生产平台应该形成完整链路：

Usage Telemetry（使用量遥测）
→ Resource Metering（资源计量）
→ Pricing Catalog（价格目录）
→ Cost Calculation（成本计算）
→ Cost Attribution（成本归因）
→ Cost Ledger（成本账本）
→ Reconciliation（成本对账）
→ Regression / Optimization
（成本回归 / 优化）

每一笔 Usage 最好能关联：

Organization（组织）
Product（产品）
Tenant（租户）
Agent（智能体）
Task Type（任务类型）
Trace（追踪）
Run（执行）
Step（步骤）
Model（模型）
Tool（工具）
Agent Version（智能体版本）
Prompt Version（提示词版本）
Release（发布版本）

这就是：

Trace-level Cost Attribution（追踪级成本归因）。

Provider Dashboard（供应商仪表盘）可以告诉你：

花了多少钱。

Trace-level Attribution 才能告诉你：

是哪一条 Agent 执行路径把钱花掉的。

成本分析最好同时维护三个视角。

Usage View（资源使用视角） ​

回答：

Agent 架构本身是否更加高效？

例如：

• Input Tokens / Task
• Model Calls / Task
• Tool Usage / Task
• Sandbox Seconds / Task

Actual-price View（实际价格视角） ​

回答：

实际 Spend（支出）有没有下降？

Constant-price View（恒定价格视角） ​

将不同版本 Usage 套用同一份价格：

剥离 Provider 调价以后，Agent 自身到底有没有优化。

例如：

五月：
100M Tokens
Spend = $1M

六月：
100M Tokens
Spend = $700K

如果 Usage 完全没变：

账单下降不一定来自 Agent Optimization（智能体优化）。

可能只是：

Provider Price Drop（供应商降价）。

总成本变化可以统一拆成：

Volume（业务量） / Mix（任务结构） / Usage（资源效率） / Price（价格）

例如：

Volume Effect（业务量变化）       +25%
Mix Effect（任务结构变化）        +10%
Usage Regression（资源效率回归） +12%
Price Effect（价格变化）           -7%

所以：

Spend 告诉你贵了多少；Volume、Mix、Usage、Price 才告诉你为什么变贵。

还要区分：

Estimated Cost（估算成本）

和：

Billed Cost（实际账单成本）。

Runtime 通过：

Usage
×
Pricing Catalog

得到的通常只是 Estimated Cost。

真实 Billed Cost 还可能受到：

• Region（区域）
• Contract（合同）
• Discount（折扣）
• Deployment Type（部署类型）
• 未采集 Tool Charge（工具费用）

影响。

因此成熟平台还需要：

Cost Reconciliation（成本对账）。

这里实际上存在两个层次。

第一层：

Run-level Settlement（单任务结算）

用于内部 Runtime Budget（运行时预算）和 Cost Ledger。

第二层：

Provider Billing Reconciliation（供应商账单对账）

用于把平台内部估算与供应商最终账单对齐。

两者概念相关，但不是同一次动作。

可以抽象理解成：

Operational Estimate（运行时估算）
        ↓
Internal Settlement（内部结算）
        ↓
Provider Billing（供应商账单）
        ↓
Reconciliation（最终对账）

一个重要原则是：

Estimate Is for Planning; Budget Is for Enforcement（估算用于规划，预算用于执行约束）。

平台还可以生成：

Cost Receipt（成本收据，本文工程概念）

例如：

Run #A1298

Model Cost（模型成本）           $0.031
Warehouse Cost（数仓成本）      $0.018
Search Cost（搜索成本）         $0.004
Retry Waste（重试浪费）         $0.007
------------------------------------
Total Cost（总成本）            $0.060

Model Calls（模型调用）         5
Tool Calls（工具调用）          7
Input Tokens（输入 Token）      62K
Cached Tokens（缓存 Token）     31K
Retries（重试次数）             2

它比：

cost = $0.06

更适合 Debug（调试）、Cost Regression（成本回归）和优化归因。

阶段总结 ​

Spend 告诉你花了多少；Usage、Pricing 和 Attribution 才告诉你为什么花。

三、Resource Efficiency（资源效率） ​

3.1 Context 为什么这么贵？ ​

Context（上下文）最大的成本问题不是：

Prompt 很长。

而是：

相同信息会被反复购买。

例如 Data Agent：

System Prompt（系统提示词）       10K
Tool Definitions（工具定义）      20K
Conversation History（会话历史）  20K
Data Schema（数据定义）           10K
--------------------------------------
Standing Context（固定上下文）    60K

任务执行：

Turn 1
Turn 2
...
Turn 10

大量固定内容可能每个 Model Turn（模型轮次）重新进入输入。

这就是：

Context Reprocessing（上下文重复处理）。

Performance（性能）章节关心：

它如何增加 Prefill Latency（预填充延迟）。

Cost 章节关心：

为什么同一批信息被多次付费。

Tool Definition（工具定义）尤其容易成为隐形成本。

例如：

100 Tool Definitions（100 个工具定义）
→ Tool Name（工具名称）
→ Description（工具描述）
→ Parameter Schema（参数结构）

即使当前任务最终只调用 2 个 Tool：

其他 Tool Definition 仍可能长期存在于 Context 中。

所以：

• Dynamic Tool Loading（动态工具加载）
• Tool Search（工具搜索）
• Tool Scoping（工具范围收敛）

不仅是 Performance Optimization（性能优化），也是 Cost Optimization。

一个非常典型的 Agent Cost Pitfall（智能体成本踩坑）不是：

“Agent 调了 100 个工具。”

而是：

“Agent 每一轮都重新携带 100 个工具的定义。”

Context 优化可以统一成三个动作：

Remove（删除） → Compress（压缩） → Retrieve on Demand（按需检索）

Remove（删除） ​

当前 Step 不需要：

就不发送。

Compress（压缩） ​

信息必须保留，但不需要原始全文。

例如 Coding Agent：

5000 行 Test Log（测试日志）

可以压缩成：

Failed Tests（失败测试）
Key Stack（关键调用栈）
Relevant Files（相关文件）

Retrieve on Demand（按需检索） ​

低频信息：

使用时再获取。

例如企业 Compliance Policy（合规策略）不一定需要每轮全部进入 Context。

三种策略都有 Trade-off（权衡）。

Remove：

可能删掉必要信息。

Compress：

可能损失细节。

Retrieve：

会增加 Retrieval Cost（检索成本）和 Latency。

所以：

Context Optimization 本质上是 Cost × Quality × Latency 的联合权衡。

Tool Result（工具结果）也需要 Budget（预算）。

例如：

cat huge.log
→ 返回 20MB Log（20MB 日志）
→ 进入 Context
→ 后续多个 Model Turn 继续携带

Tool Call 本身可能很便宜。

真正昂贵的是：

Tool Result 被后续不断重新处理。

所以除了：

Tool Call Budget（工具调用预算）

还应该考虑：

• Max Result Bytes（最大结果字节数）
• Max Result Tokens（最大结果 Token）
• Top-K Limit（Top-K 数量限制）
• Field Projection（字段裁剪）
• Pagination（分页）
• Result Summarization（结果摘要）

核心原则：

Control Tool Output, Not Just Tool Calls（不仅控制工具调用，也要控制工具输出，本文记忆性表达）。

Memory（记忆）也是经济性问题。

不用 Memory：

History 持续增长。

使用 Memory：

Summarize（摘要）
→ Store（存储）
→ Retrieve（读取）

又会产生：

• Memory Extraction Cost（记忆提取成本）
• Storage Cost（存储成本）
• Retrieval Cost（读取成本）

所以真正判断应该是：

Memory Cost 是否低于减少的 Context Reprocessing Cost，同时 Quality Guardrail（质量护栏）是否成立？

3.2 执行为什么会产生成本浪费？ ​

Agent Resource Efficiency（智能体资源效率）可以统一理解为：

Useful Work（有效工作） vs Waste（浪费工作）。

常见 Avoidable Cost 包括：

• Over-execution（过度执行）
• Over-retry（过度重试）
• Duplicate Work（重复工作）
• Abandoned Work（废弃工作）
• Zombie Work（僵尸工作）
• Over-quality Work（过度质量工作）
• Cost Leak（成本泄漏，本文工程表达）

例如 Enterprise Agent：

Tool API（工具接口）
→ Timeout（超时）
→ Retry（重试）
→ Timeout
→ Replan（重新规划）
→ Tool API
→ Timeout

Performance 看：

延迟越来越高。

Reliability（稳定性）看：

恢复策略有问题。

Cost 看：

为了同一个业务目标，重复购买了多遍相似资源。

因此 Runtime 至少应该考虑：

• Max Steps（最大步骤数）
• Model Turn Budget（模型轮次预算）
• Retry Budget（重试预算）
• Tool Budget（工具预算）
• Cost Budget（成本预算）

Retry 还必须考虑 Idempotency（幂等性） ​

例如 Refund Agent（退款智能体）：

refund_order（执行退款）
→ Network Timeout（网络超时）

Agent 不知道：

后端到底成功了还是失败了。

如果直接 Retry：

refund_order again（再次退款）

而 Tool 又不支持 Idempotency Key（幂等键）：

就可能产生重复退款。

之后还可能引发：

• Compensation Transaction（补偿事务）
• Human Intervention（人工介入）
• 更多 Tool / Model 调用

因此 Enterprise Agent 的 Retry 设计至少应该考虑：

• Idempotency Key（幂等键）
• Duplicate Request Detection（重复请求检测）
• Retry Classification（重试分类）
• Safe Retry（安全重试）

从 Cost 角度：

最便宜的 Retry，是不要重复执行已经成功的工作。

No-progress Execution（无进展执行） ​

完全重复的 Infinite Loop（无限循环）通常比较容易检测。

更难的是：

Search（搜索）
→ Replan（重新规划）
→ Similar Search（相似搜索）
→ Replan
→ Similar Search

每个 Step 都不完全相同。

但：

New Evidence（新增证据）≈ 0
Uncertainty Reduction（不确定性下降）≈ 0
Completion Progress（完成进展）≈ 0

Cost ↑

因此可以考虑：

No-progress Detection（无进展检测）。

具体 Progress（进展）信号要根据 Agent 类型定义，例如：

• Evidence Gain（证据增益）
• State Change（状态变化）
• 新 Tool Result
• Completion Criteria（完成条件）推进

但这不是一个可以通用于所有 Agent 的精确算法。

复杂任务可能确实需要一段时间探索。

因此 No-progress Detection 应该作为：

Replan / Stop / Escalate（重新规划 / 停止 / 升级）的辅助信号

而不是简单：

“连续三步没有结果就 Kill”。

Cancellation Propagation（取消传播） ​

如果 Parent Agent（主智能体）已经完成：

Final Result（最终结果）
✅

但：

Sub-Agent C
Sub-Agent D
Browser
Sandbox

仍然运行：

就形成 Zombie Work。

对于支持 Cancellation（取消）的下游：

应传播 Cancel Signal（取消信号）。

无法真正取消的下游：

• 不再创建新工作；
• 停止消费无价值结果；
• 使用 Timeout；
• 使用剩余 Budget 限制资源消耗。

Performance 关注：

减少等待。

Cost 关注：

不要继续为已经没有业务价值的工作付费。

3.3 Prompt Cache 什么时候省钱？ ​

Prompt Cache（提示词缓存）是典型的 Break-even Problem（盈亏平衡问题）。

不用 Cache：

Without Cache（无缓存）
=
N × Normal Input Cost
（N 次普通输入成本）

使用 Cache：

With Cache（使用缓存）
=
Cache Creation / Write Cost
（缓存创建 / 写入成本）
+
Cache Storage Cost
（缓存存储成本，如果存在）
+
N × Cache Read Cost
（N 次缓存读取成本）

还必须考虑：

• Stable Prefix（稳定前缀）
• Hit Rate（命中率）
• Reuse Frequency（复用频率）
• Reuse Interval（复用间隔）
• TTL（Time To Live，缓存存活时间）
• Cache Invalidation（缓存失效）

因此：

Cache Hit（缓存命中） ≠ Cache Saving（缓存省钱）。

真正要看：

Net Saved Cost（净节省成本）。

典型负优化：

System Prompt + Tool Definitions
= 50K Tokens

但每个 Request Prefix（请求前缀）变化很大

Hit Rate（命中率）
≈ 5%

即使 Cache Infrastructure（缓存基础设施）建设得很完整：

真实账单可能几乎没降。

根因不是：

Cache 技术没有价值。

而是：

这个 Workload 的 Cacheability（可缓存性）不足。

3.4 Multi-Agent 为什么容易变贵？ ​

Multi-Agent（多智能体）的成本不能理解成：

Agent 数 × 模型单价

完整成本至少可能包含：

Parent Planning Cost（主智能体规划成本）
+
Sub-Agent Execution Cost（子智能体执行成本）
+
Context Replication Cost（上下文复制成本）
+
Tool Cost（工具成本）
+
Coordination Cost（协调成本）
+
Fan-in / Synthesis Cost（汇聚 / 综合成本）
+
Verification Cost（验证成本）

最隐蔽的一项通常是：

Context Replication（上下文复制）。

如果每个 Sub-Agent 都重新携带：

• System Prompt
• Policy（策略）
• Tool Definitions
• History（历史）

共享 Context 会随 Agent 数量快速复制。

因此：

Multi-Agent Cost Amplification（多智能体成本放大）不仅来自更多模型调用，也来自共享上下文和工具活动的重复消费。

不要简单问：

Multi-Agent 会不会更贵？

正确问题是：

Incremental Cost（增量成本）换来了多少 Incremental Outcome Gain（增量结果收益）？

例如：

Single-Agent（单智能体）
Cost = $0.05
Success = 85%

Multi-Agent + Verification
Cost = $0.08
Success = 96%

普通 FAQ（常见问题）：

可能不值得。

高价值 Coding Review（代码审查）：

可能完全值得。

所以 Multi-Agent 的经济合理性最终取决于：

Marginal Cost vs Marginal Outcome Gain（边际成本 vs 边际结果收益）。

阶段总结 ​

成本优化的第一优先级，是停止为没有业务价值的工作付钱。

四、Economic Routing（经济路由） ​

4.1 Economic Routing 怎么做？ ​

Model Routing（模型路由）只是 Economic Routing（经济路由）的一部分。

生产 Runtime 真正需要选择的是：

Execution Plan（执行计划）。

可能同时决定：

• Model（模型）
• Tool（工具）
• Processing Tier（处理层级）
• Cache Strategy（缓存策略）
• Verification Level（验证级别）
• Agent Topology（智能体拓扑）

可以把 Economic Routing 定义为：

在 Quality（质量）、Risk（风险）、Latency（延迟）、Reliability（稳定性）和 Budget（预算）约束下，选择 Expected Cost per Successful Outcome（预期单位成功结果成本，本文用于经济决策的工程指标）最低的可接受执行路径。

这里必须严格区分两个指标。

Expected Spend per Task（单任务预期支出） ​

把所有可能路径：

Probability（概率） × Path Cost（路径成本）

求和。

Expected Cost per Successful Outcome（预期单位成功结果成本） ​

还需要结合：

整个策略最终 Success Probability（成功概率）。

例如：

Cheap Model（低成本模型）

Cost = $0.02
First-pass Success（首次成功率） = 60%

失败后：
Strong Model（强模型）
额外 Cost = $0.08

Strong Model Success
= 95%

单任务 Expected Spend：

0.60 × $0.02
+
0.40 × ($0.02 + $0.08)

=
$0.052

策略最终 Success Probability：

0.60
+
0.40 × 0.95

=
0.98

于是近似：

Expected Cost per Successful Outcome
（预期单位成功结果成本）

≈
$0.052 / 0.98

≈
$0.053

这才应该和其他策略比较。

所以：

Route by Expected Outcome Cost, Not Unit Invocation Price（按预期结果成本路由，而不是按单次调用价格路由，本文记忆性表达）。

实际 Router（路由器）可以考虑：

• Task Complexity（任务复杂度）
• Risk（风险）
• Confidence（置信度）
• Quality Requirement（质量要求）
• Latency Requirement（延迟要求）
• Tenant Tier（租户层级）
• Remaining Budget（剩余预算）

例如 Data Agent：

Intent Classification（意图分类）
→ Low-cost Model（低成本模型）

SQL Planning（SQL 规划）
→ Strong Model（强模型）

Formatting（格式化）
→ Code / Low-cost Model
（代码 / 低成本模型）

Coding Agent：

File Listing（文件列表）
→ Deterministic Code（确定性代码）

Simple Classification（简单分类）
→ Low-cost Model

Complex Debug / Architecture
（复杂调试 / 架构推理）
→ Strong Model

核心原则：

Intelligence Only Where Needed（只在真正需要智能的地方购买强能力，本文记忆性表达）。

Processing Tier（处理层级）也属于 Routing。

Interactive Agent：

可能值得为低 Latency 支付更多。

Background Eval（后台评测）：

通常没有必要购买同等级实时 SLA。

因此：

不要为 Workload 不需要的速度付费。

API vs Self-hosted（托管接口 vs 自托管）属于高价值 P1（重要进阶）。

不能说：

Open-weight Model（开放权重模型）权重免费，所以自托管一定更便宜。

真正应该比较：

TCO（Total Cost of Ownership，总拥有成本）

包括：

• GPU
• Serving Cluster（推理集群）
• Idle Capacity（空闲容量）
• Reliability Overhead（稳定性额外开销）
• SRE / Operations（可靠性工程 / 运维）
• Model Upgrade（模型升级）
• Engineering Cost（工程成本）

不存在一个通用：

“超过 X QPS 就应该自托管。”

Break-even Volume（规模盈亏平衡点）取决于：

• Utilization
• Peak / Average Ratio（峰均比）
• Model Size（模型规模）
• Batchability（可批处理性）
• Availability Requirement（可用性要求）
• GPU Cost
• 运维能力

4.2 Tool Cost 怎么优化？ ​

企业 Agent 真正最大的成本源不一定是 Model。

Data Agent：

LLM Cost（模型成本） = $0.01
Warehouse Query（数仓查询） = $0.08

Research Agent：

Model
+ Search
+ Browser
+ Document Parsing（文档解析）

Coding Agent：

Model
+ Sandbox
+ Build（构建）
+ Test Execution（测试执行）

因此：

Tool Call Count ≠ Tool Cost。

首先要识别真正 Tool Meter（工具计量单位）。

Warehouse（数据仓库） ​

关注：

• Bytes Scanned（扫描数据量）
• Compute Time（计算时间）
• Query Complexity（查询复杂度）
• Cache Hit（缓存命中）
• Result Reuse（结果复用）

Sandbox（沙箱） ​

关注：

• CPU Seconds
• Memory GB-Seconds
• Duration（持续时间）

Search（搜索） ​

关注：

• Actual Search Uses（实际搜索次数）
• Search Result Size（搜索结果大小）

还要区分：

Agent-level Tool Call（智能体层工具调用）

和：

Provider-level Tool Usage（供应商层实际工具使用量）。

例如：

Agent：

web_search() × 1

Provider：

Search Query × 3

真实成本不能只统计上层的一次 Tool Call。

因此 Budget 最好绑定真正 Resource Meter：

max_search_uses（最大搜索使用次数）
max_scanned_bytes（最大扫描字节数）
max_sandbox_seconds（最大沙箱运行秒数）
max_browser_actions（最大浏览器操作数）

而不是只有：

max_tool_calls

Tool Result（工具结果）也会形成后续成本。

例如：

Search（搜索）
→ 500KB Results（500KB 搜索结果）
→ Context
→ Replan
→ 下一轮继续携带

工具本身可能只收费一次。

结果却可能反复形成 Input Cost。

因此：

Control Tool Output, Not Just Tool Calls（不仅控制工具调用，也要控制工具输出，本文记忆性表达）。

Data Agent 的一个典型 Economic Decision（经济决策）：

Realtime Warehouse Query（实时数仓查询）
Cost = $0.20
Freshness（数据新鲜度） = 实时

Cached Dataset（缓存数据集）
Cost = $0.01
Freshness = T-1

用户问：

“昨天销售额怎么样？”

Cached Dataset 可能足够。

用户问：

“现在支付成功率是多少？”

T-1 数据不可接受。

因此：

最低成本 Tool 路径仍然受到 Freshness（数据新鲜度）、Quality、Risk 和业务要求约束。

阶段总结 ​

无法消除的 Necessary Cost（必要成本），才应该通过 Economic Routing 选择满足业务目标的最低成本执行路径。

五、Budget & Governance（预算与治理） ​

5.1 为什么 Budget 必须进入 Runtime？ ​

月底 Dashboard（仪表盘）只能：

解释事故。

它不能：

阻止 Agent 今天烧掉整月预算。

所以 Cost Budget（成本预算）必须进入 Runtime Decision（运行时决策）。

平台可以形成 Budget Hierarchy（预算层级）：

Organization Budget（组织预算）
↓
Product / Agent Budget（产品 / 智能体预算）
↓
Tenant Budget（租户预算）
↓
Run Budget（单任务预算）
↓
Model / Tool / Eval Budget
（模型 / 工具 / 评测预算）

同时必须区分：

Budget（预算）：总共允许花多少。

Quota（配额）：一个主体最多被分配多少资源。

Rate Limit（速率限制）：单位时间最多消耗多快。

三者解决不同问题。

一个成熟 Runtime 的 Budget Lifecycle（预算生命周期）可以抽象成：

Forecast（预测）
→ Reserve（预留）
→ Execute / Enforce（执行 / 约束）
→ Settle（结算）
→ Reconcile（对账）

Forecast（预测） ​

任务启动前估算：

大概还需要花多少。

Reserve（预留） ​

Fan-out（任务扇出）等并发工作启动之前：

提前占用预算空间。

Execute / Enforce（执行 / 约束） ​

Runtime 持续控制。

Settle（结算） ​

根据实际 Resource Usage 对当前 Run 做内部结算。

Reconcile（对账） ​

之后再和 Provider Billing（供应商账单）做最终对齐。

Runtime 不能只判断：

spent_cost < budget

例如：

Budget = $1.00
Spent = $0.90
Remaining = $0.10

下一步准备：

Sub-Agent A expected $0.08
Sub-Agent B expected $0.08
Sub-Agent C expected $0.08

如果只看：

$0.90 < $1.00

三个都可能启动。

真正应该考虑：

Spent
+
Reserved
+
Expected New Work
≤
Budget

这就是：

Budget-aware Planning（预算感知规划）。

并发情况下尤其需要：

Cost Reservation（成本预留）。

Reserve（预留）
→ Execute（执行）
→ Settle（结算）
→ Release Unused Reservation
（释放未使用预留）

否则多个 Branch（分支）同时读取同一个 Remaining Budget：

都认为自己有足够预算。

这种情况可以理解成：

Concurrent Budget Race（并发预算竞争，本文工程描述）。

Budget 还应该区分：

Soft Budget（软预算） ​

接近以后：

开始调整执行策略。

Hard Budget（硬预算） ​

达到以后：

不再允许启动新的非必要高成本工作。

但 Hard Budget 不意味着：

立即强制 Kill 所有运行中的任务。

因为可能还必须完成：

• Safety Check（安全检查）
• Audit（审计）
• Mandatory Verification（强制验证）
• 必要事务收尾

企业平台还需要：

Cost Forecasting（成本预测）

例如：

Expected Task Volume（预计任务量）
×
Task Mix（任务结构）
×
Expected Usage（预计资源使用）
×
Pricing Function（计价函数）
→
Monthly Cost Forecast（月度成本预测）

还可以做 Scenario Analysis（情景分析）：

Base Case（基准情景）
1M Tasks / month

Growth Case（增长情景）
2M Tasks / month

New Feature Case（新功能情景）
Fan-out 3 → 8

Provider Price Change Case（供应商调价情景）
Price ±30%

这样 Deep Research Agent（深度研究智能体）新功能上线之前：

就能提前知道潜在月成本。

运行以后再看：

Budget Variance（预算偏差）

并通过：

Volume / Mix / Usage / Price

解释为什么偏离 Forecast。

5.2 接近预算时怎么办？ ​

Runtime 不应该只有：

if cost > budget:
    kill()

更成熟的是：

Runtime Control Loop（运行时控制闭环）

Observe（观察）
→ Warn（预警）
→ Optimize（优化路径）
→ Degrade（降级）
→ Stop / Escalate（停止 / 升级）

例如：

Budget Usage（预算使用率） < 70%
→ Normal Path（正常路径）

80%
→ Reduce Fan-out（减少扇出）

90%
→ Stop Optional Exploration
（停止可选探索）

95%
→ Use Cheaper Acceptable Model
（使用满足要求的低成本模型）

Near Hard Limit（接近硬上限）
→ Best-effort Finish / Human Escalation
（尽力完成 / 人工升级）

但必须遵守硬边界：

Cost Optimization 不能绕过 Safety（安全）、Permission（权限）、Compliance（合规）和 Mandatory Verification（强制验证）。

Enterprise Agent 存在 Side Effect（副作用）时，还不能在业务事务执行中途粗暴停止。

例如：

Create Refund（创建退款）
✅

Budget Exhausted（预算耗尽）

Write Audit Record（写审计记录）
❌

如果直接 Kill：

可能留下半完成业务状态。

因此可以设计：

Safe Budget Boundary（安全预算边界，本文工程概念）。

在进入昂贵且不可安全中断的 Transaction Boundary（事务边界）之前：

先确认剩余 Budget 足以完成必要动作和安全收尾。

Cost Tail（成本长尾） ​

Cost Governance 不能只优化 Average Cost。

例如：

P50 Cost = $0.02
P95 Cost = $0.10
P99 Cost = $2.50

P99 是 P50 的 125 倍。

典型原因：

• Retry Storm（重试风暴）
• Infinite / No-progress Loop（无限 / 无进展循环）
• Context Explosion（上下文爆炸）
• Multi-Agent Fan-out
• Long-running Sandbox
• Cost Leak

所以：

Cost Tail（成本长尾，本文工程表达）是 Runtime Hard Budget 必须存在的重要理论依据之一。

Dashboard / Unit Cost Target（单位成本目标）主要优化：

正常任务的平均经济性。

Runtime Hard Budget 主要限制：

极端任务最多允许烧多少钱。

Cost Dashboard 至少应该包含：

• Mean / Average（平均值）
• P50
• P95
• P99
• Max Cost per Run（单任务最大成本）
• Outlier Count（异常任务数量）

Cost Regression（成本回归） ​

建议固定诊断链：

Cost Regression（成本回归）
→ Segment（分群）
→ Normalize Workload（归一工作负载）
→ Volume / Mix / Usage / Price
→ Resource Breakdown（资源拆解）
→ Trace Breakdown（追踪拆解）
→ Root Cause（根因）

不能看到：

v1 Average Cost = $0.06
v2 Average Cost = $0.09

就直接说：

v2 回归。

可能只是：

v2 的 Complex Task（复杂任务）占比更高。

所以：

先分群，再比较。

Cost Observability（成本可观测能力）自身也有成本。

如果为了 Attribution：

100% Trace
+
Full Prompt Payload（完整提示词载荷）
+
Full Tool Result（完整工具结果）
+
Long Retention（长期保留）

Observability Storage（可观测存储）自己也可能成为明显成本源。

因此可以通过：

• Metadata vs Payload（元数据 vs 完整载荷）
• Sampling（采样）
• Retention Policy（保留策略）
• Hot / Cold Storage（热 / 冷存储）

控制。

详细方法仍然属于 Observability（可观测性）章节。

阶段总结 ​

优化解决正常路径怎样更省；Budget & Governance（预算治理）解决异常路径最多允许烧多少。

六、Validation（验证闭环） ​

6.1 怎么证明 Cost Optimization 真有效？ ​

看到：

Tokens ↓ 30%

不能宣布：

Cost Optimization 成功。

完整生产验证应该是：

Baseline（基线）
→ Controlled Change（受控改动）
→ Representative Workload（代表性工作负载）
→ Usage Breakdown（资源使用拆解）
→ Cost Breakdown（成本拆解）
→ Quality Validation（质量验证）
→ Performance Validation（性能验证）
→ Reliability Validation（稳定性验证）
→ Canary Validation（灰度验证）
→ Production Validation（线上验证）

Representative Workload（代表性工作负载） ​

假设真实线上：

60% Simple Task（简单任务）
25% Multi-tool Task（多工具任务）
10% Long Context Task（长上下文任务）
5% Complex / Multi-Agent Task（复杂 / 多智能体任务）

Benchmark（基准测试）如果只有：

100% Simple Task

得到的 Cost Saving（成本节省）没有足够代表性。

至少同时检查：

典型负优化 ​

优化前：

Strong Model（强模型）

Cost / Task = $0.08
Task Success = 95%
Escalation = 5%

优化后：

Cheap Model（低成本模型）

Cost / Task = $0.04 ✅
Task Success = 75% ❌
Escalation = 35% ❌

大量任务最终变成：

Cheap Model
→ Fail（失败）
→ Strong Model
→ Retry Tool（重试工具）

于是：

Cost per Successful Outcome 可能反而上涨。

这种方案不能上线。

验证时还需要防：

Outcome Definition Drift（结果定义漂移）。

如果优化前后 Success Criteria（成功标准）变化：

Cost / Success 失去可比性。

因此：

• Evaluation Version（评测版本）
• Dataset Version（数据集版本）
• Success Criteria
• Workload Mix

应该保持稳定或显式版本化。

还应该做：

Savings Attribution（节省归因）。

例如团队宣布：

Cost ↓ 30%

应该继续拆成：

Context Reduction（上下文缩减）   -12%
Prompt Cache（提示词缓存）        -8%
Economic Routing（经济路由）      -6%
Provider Price Drop（供应商降价） -7%
Task Mix Shift（任务结构变化）     +3%

真正 Engineering Saving（工程节省）应该尽量剥离：

• Price Effect（价格效应）
• Mix Effect（任务结构效应）

因此：

Constant-price Comparison（恒定价格比较）

非常重要。

否则供应商降价：

很容易被误认为团队优化成果。

Improvement Cost（持续优化成本）自身也要验证。

例如：

10,000 Eval Samples（1 万评测样本）
×
5 Candidate Agents（5 个候选智能体）
×
3 Evaluators（3 个评测器）

很容易产生巨量 Agent + Judge 调用。

所以 Evaluation Pipeline（评测流水线）本身也需要：

• Sampling（采样）
• Candidate Pruning（候选淘汰）
• Early Stopping（提前停止）
• Cascaded Evaluation（级联评测）
• Eval Result Reuse（评测结果复用）

阶段总结 ​

Cost / Task 下降只是局部数字；只有 Cost per Successful Outcome 在 Quality、Performance、Reliability、Safety 等 Guardrail（护栏）没有不可接受退化时下降，才是真正的 Cost Optimization。

七、三个生产级 Case（案例） ​

Case A：Data Agent Context Regression（数据智能体上下文成本回归） ​

现象：

Agent v31
Cost / Task = $0.05

Agent v32
Cost / Task = $0.11

分群后发现：

Task Mix ≈ unchanged
Provider Price ≈ unchanged
Model Calls ≈ unchanged
Tool Calls ≈ unchanged

Input Tokens / Task：
20K → 70K

Trace（追踪）最终发现：

v32 把完整 Tool Registry（工具注册表）和大量 Schema（数据定义结构）永久加入 Standing Context（固定上下文）。

优化：

• Tool Scoping（工具范围收敛）
• Dynamic Tool Loading（动态工具加载）
• Retrieve on Demand（按需检索）
• Result Compression（结果压缩）

这套案例串联：

Measurement → Attribution → Context → Regression → Validation

Case B：Coding Agent Cheap Routing Negative Optimization（研发智能体低成本路由负优化） ​

为了省钱，把：

Architecture Reasoning（架构推理）
Debug（调试）
Patch Planning（补丁规划）

全部切到 Cheap Model。

结果：

Single-call Cost ↓
First-pass Success ↓
Replan ↑
Test Retry ↑
Strong-model Escalation ↑

最终：

Cost per Successful Bug Fix（单成功缺陷修复成本）反而上涨。

更合理：

Classification / Formatting（分类 / 格式化）
→ Low-cost Model（低成本模型）

Deterministic Work（确定性工作）
→ Code（代码）

Complex Reasoning / Debug（复杂推理 / 调试）
→ Strong Model（强模型）

这套案例串联：

Pricing → Expected Cost to Success → Economic Routing → Validation

Case C：Enterprise Agent Runaway Cost（企业智能体成本失控） ​

Tool Backend Failure（工具后端失败）
→ Retry（重试）
→ No Progress（无进展）
→ Context Growth（上下文增长）
→ Strong Model Escalation（强模型升级）
→ Multi-Agent Fan-out（多智能体扇出）
→ Cost Tail Explosion（成本长尾爆炸）
→ Budget Exhausted（预算耗尽）

正确多层防线：

Failure Classification（失败分类）
→ Idempotency / Safe Retry（幂等 / 安全重试）
→ Retry Budget（重试预算）
→ Backoff / Circuit Breaker（退避 / 熔断）
→ No-progress Detection（无进展检测）
→ Run Budget（单任务预算）
→ Fan-out Budget（扇出预算）
→ Cost Reservation（成本预留）

这套案例串联：

Waste → Runtime Control → Budget Governance

八、六类 Cost Anti-pattern（成本反模式） ​

Over-context（过度上下文） ​

不断重复购买旧信息。

Over-execution（过度执行） ​

Step（步骤）、Replan（重新规划）、Verification（验证）超出业务需要。

Over-retry（过度重试） ​

同一个失败不断重新购买资源。

Over-fanout（过度扇出） ​

Sub-Agent、Search、Tool 无约束扩散。

Over-quality（过度质量） ​

简单任务默认购买最昂贵的能力和 SLA。

Blind Optimization（盲目优化） ​

只看 Token、Model Price 或 Cost / Task，不看 Cost / Outcome 和 Guardrail。

九、五条最高级原则 ​

原则一：Optimize Cost per Outcome（优化单位结果成本） ​

不要只优化一次模型调用多少钱。

原则二：Measure Usage Before Money（先理解资源使用，再理解金额） ​

Provider 价格会变化。

Usage 更能说明架构本身是否真正变高效。

原则三：Eliminate Waste Before Buying Cheaper Compute（先消除浪费，再购买更便宜的计算，本文记忆性表达） ​

先处理：

• Context
• Retry
• Loop
• Duplicate Work
• Fan-out
• Zombie Work

再讨论换更便宜模型。

原则四：Budget Must Be Enforced at Runtime（预算必须在运行时执行） ​

Dashboard 能解释事故。

Runtime Budget 才能限制事故。

原则五：Cost Optimization Is Constrained Optimization（成本优化是约束优化） ​

只有：

• Quality
• Performance
• Reliability
• Safety
• Policy / Compliance

没有不可接受退化：

成本下降才有意义。

十、最终主知识链 ​

Business Outcome（业务结果）
↓
Workload（工作负载）
↓
Execution Shape（执行形态）
↓
Resource Usage（资源使用量）
↓
Pricing Function（计价函数）
↓
Cost Attribution（成本归因）
↓
Resource Efficiency（资源效率）
↓
Economic Routing（经济路由）
↓
Budget Enforcement（预算执行）
↓
Outcome Validation（结果验证）

压缩记忆：

定义结果 → 计量资源 → 理解计费 → 归因成本 → 消除浪费 → 选择经济路径 → 控制预算 → 验证结果

十一、P0 / P1 / P2 面试优先级 ​

P0：必须掌握 ​

1. Agent Cost 是什么？
2. 什么是 Cost per Outcome？
3. 成本优化的目标是什么？
4. 怎么测量 Agent 的真实成本？
5. 模型是怎么计费的？
6. 怎么做 Cost Attribution（成本归因）？
7. Context 为什么这么贵？
8. 执行为什么会产生成本浪费？
9. Prompt Cache 什么时候省钱？
10. Multi-Agent 为什么容易变贵？
11. Economic Routing 怎么做？
12. Tool Cost 怎么优化？
13. 为什么 Budget 必须进入 Runtime？
14. 接近预算时怎么办？
15. 怎么证明 Cost Optimization 真有效？

P1：重要进阶 ​

• Pricing Catalog（价格目录）
• Pricing Version（价格版本）
• Estimated vs Billed Cost（估算成本 vs 实际账单成本）
• Cost Reconciliation（成本对账）
• Constant-price Comparison（恒定价格比较）
• Cost Ledger（成本账本）
• Cost Receipt（成本收据，本文工程概念）
• Volume / Mix / Usage / Price 分解
• Long-context Pricing（长上下文计价）
• Multimodal Pricing（多模态计价）
• Cache Break-even（缓存盈亏平衡）
• No-progress Detection（无进展检测）
• Marginal Cost（边际成本）
• Processing Tier（处理层级）
• Expected Cost per Successful Outcome（预期单位成功结果成本，本文工程指标）
• API vs Self-hosted（托管接口 vs 自托管）
• Utilization（利用率）
• Cost Forecasting（成本预测）
• Budget Variance（预算偏差）
• Cost Reservation（成本预留）
• Cost Tail（成本长尾，本文工程表达）
• Shared Cost Allocation（共享成本分摊）
• Eval Cost（评测成本）
• Human Escalation Cost（人工升级成本）

P2：高级边界 ​

• Quantization（量化）
• KV Cache（注意力键值缓存）
• Speculative Decoding（推测解码）
• Continuous Batching（连续批处理）
• GPU Utilization（GPU 利用率）
• Spot / Reserved GPU Economics（竞价 / 预留 GPU 经济性）
• Complex FinOps Chargeback（复杂内部成本计费）

这些更属于：

LLM Infra（大语言模型基础设施） / Cloud FinOps（云成本运营）

除非岗位明确要求，否则不展开。

十二、2～3 分钟标准面试回答 ​

如果面试官问：

“你会怎么优化一个生产 Agent 的成本？”

可以这样回答：

我不会一开始就把 Agent Cost 等同于 Token Cost，也不会直接把强模型全部换成小模型。第一步是定义 Cost Unit。对生产 Agent，我通常更关注 Cost per Successful Outcome，也就是完成一个真正成功业务结果需要多少钱。因为一个单次调用很便宜但经常失败、Retry、升级或者转人工的 Agent，最终单位业务结果成本可能反而更高。

然后我会建立完整的 Resource Metering 和 Cost Attribution。Model 要区分 Input、Cached Input、Output 等 Usage；不同 Tool 应使用真实 Resource Meter，比如 Data Warehouse 看 Bytes Scanned，Sandbox 看 CPU Seconds 和 Memory Time，而不是只统计 Tool Call Count。Tool 成本还要考虑 Definition、Invocation 和 Result Reprocessing，但 Cost Ledger 要避免重复核算。每笔 Usage 应尽量关联 Tenant、Agent、Task Type、Trace、Step、Model、Tool、Agent Version 和 Prompt Version，再通过 Versioned Pricing Catalog 计算成本，并通过 Cost Reconciliation 与最终账单对齐。

模型计费本身也不是一个固定 Token 单价。真实成本受到 Usage Type、Model Capability / Cost Profile、Context Tier、Cache Strategy、Processing Tier 和 Capacity Model 等共同影响。因此模型选型不能只比较每百万 Token 单价，而应该比较整个策略的 Expected Cost per Successful Outcome。

开始优化时，我首先减少 Avoidable Cost。Agent 最典型的是 Standing Context 反复处理、Tool Definition 长期占 Context、无效 Step、Retry Loop、重复 Tool Call、过大的 Tool Result、Multi-Agent Fan-out 和已经没有业务价值却还在运行的 Zombie Work。Context 可以做 Remove、Compress 和 Retrieve on Demand；Prompt Cache 则要计算 Write、Storage、Read、Hit Rate 和 Reuse Frequency 的 Break-even。

剩余 Necessary Cost 再进入 Economic Routing，根据 Task Complexity、Risk、Quality、Latency 和 Budget 选择 Model、Tool、Processing Tier、Verification Level 和 Agent Topology。不能只提高 Cheap Model Usage Ratio，因为低成本模型失败以后再升级 Strong Model，整个成功路径反而可能更贵。

最后 Budget 必须进入 Runtime。我会同时看 Spent、Reserved 和 Expected Remaining Cost，在 Multi-Agent Fan-out 前做必要的 Cost Reservation。接近预算以后逐步减少 Fan-out、停止可选探索或选择更经济路径，但不能为了省钱跳过 Safety、Permission、Compliance 或 Mandatory Verification，也不能在有 Side Effect 的事务执行到一半时粗暴 Kill。

验证时不能只看 Token 少了多少。我会使用 Representative Workload 做 Controlled Comparison，同时看 Cost / Task、Cost / Successful Outcome、P95 / P99 Cost、Task Success、Latency、Retry 和 Reliability，并通过 Constant-price Comparison 剥离 Provider 调价影响。只有单位成功结果成本真正下降，而且其他 Guardrail 没有不可接受退化，我才会认为这次 Cost Optimization 成立。

十三、最终记忆模型 ​

三层模型 ​

Accounting（核算）：钱花在哪里？

Consumption（消耗）：为什么用了这么多？

Economics（经济性）：这些钱花得值不值？

六个阶段 ​

Cost Fundamentals（成本基础） → Measurement & Attribution（测量与归因） → Resource Efficiency（资源效率） → Economic Routing（经济路由） → Budget & Governance（预算治理） → Validation（验证闭环）

六句话 ​

便宜不是调用便宜，而是结果便宜。

Spend 说明花了多少，Usage、Pricing 和 Attribution 解释为什么花。

先减少 Avoidable Cost（可避免成本），再优化 Necessary Cost（必要成本）。

Routing 看 Expected Cost per Successful Outcome，而不是单次调用价格。

Dashboard 解释成本，Runtime Budget 限制成本。

Guardrail 内 Cost per Successful Outcome 下降，才是真优化。

十四、一句话本质 ​

Agent Cost Engineering（智能体成本工程）的本质，是从 Business Outcome（业务结果）出发，准确计量一次 Agent 执行消耗的 Model、Tool、Compute、Storage、Memory、Evaluation 等资源，通过版本化 Pricing Function（计价函数）完成 Cost Attribution（成本归因），优先减少在业务护栏内可以避免的资源消费，再通过 Economic Routing（经济路由）优化 Necessary Cost（必要成本），并利用 Runtime Budget（运行时预算）限制极端 Cost Tail（成本长尾），最终在 Quality（质量）、Performance（性能）、Reliability（稳定性）、Safety（安全）等 Guardrail（护栏）成立的前提下，持续降低 Cost per Successful Outcome（单位成功结果成本）。

十五、封版检查 ​

Theory Coverage（理论覆盖） ​

已覆盖：

• Accounting Model（成本核算模型）
• Consumption Model（资源消耗模型）
• Pricing Function（计价函数）
• Cost Amplification（成本放大）
• Unit Economics（单位经济性）
• Marginal Cost（边际成本）
• Constrained Optimization（约束优化）
• Cost Distribution（成本分布）

通过。

Production Coverage（生产覆盖） ​

已覆盖：

• Model / Tool / Sandbox / Memory / Eval Cost
• Tool Definition / Invocation / Result Cost
• Context Reprocessing
• Tool Result Budget
• Prompt Cache Break-even
• Retry / Idempotency
• No-progress Detection
• Cancellation Propagation
• Multi-Agent Context Replication
• Economic Routing
• API vs Self-hosted
• Resource Metering
• Pricing Catalog
• Cost Ledger
• Cost Attribution
• Cost Reconciliation
• Constant-price Comparison
• Runtime Budget
• Soft / Hard Budget
• Cost Reservation
• Safe Budget Boundary
• Cost Forecasting
• Cost Tail
• Cost Regression
• Savings Attribution
• Production Validation

通过。

Terminology Hard Gate（术语硬检查） ​

重要技术英文使用：

English（中文解释）

非标准工程表达已明确标注。

通过。

Redundancy Hard Gate（重复硬检查） ​

正文负责讲机制。

Case 负责串联。

Anti-pattern 与最终原则只做知识压缩。

通过。

Module Boundary（模块边界） ​

继续向下深入将主要进入：

• LLM Serving（大语言模型服务）
• AI Infra（人工智能基础设施）
• Distributed Systems（分布式系统）
• Cloud FinOps（云成本运营）

而不是补 Agent Cost 的一级知识缺口。

通过。

因此正式标记为：

《第六章：Cost（成本）》V3 Final / SEALED（最终封版）