成本、延迟与生产化

一句话定义

Agent 生产化 = 把 demo 的"单次惊艳"变成"每次任务的 token 成本、p95 延迟、失败兜底、状态持久都可在预算内复现"的工程过程——其中成本与延迟是两项第一公民指标，因为 Agent 的循环结构会把模型的每一分低效放大 N 倍。

为什么重要

同一个任务，差的实现比好的实现贵 10-50 倍是常态（循环轮数 × 历史重放 × 无缓存的乘法效应），延迟同理——demo 没暴露这些是因为 demo 只跑一次。反过来，优化得当的 Agent 能用便宜模型干贵模型干不成的事。生产化的另一面是韧性：进程重启、API 超时、限流、模型版本下线——真实世界的每一天。

前置知识

kp-022（上下文策略——最大的成本杠杆）、kp-024（评测保障优化不回退）。

核心概念

成本结构拆解（一次任务的 token 账单）

成本 = Σ(每轮 输入token + 输出token) × 单价
     ≈ 轮数 × 平均历史长度 × 输入单价 + 输出总量

四个可优化乘子，按杠杆从大到小：

历史长度（上下文工程）：压缩/分层/JIT（kp-022）——头号杠杆
轮数（任务结构）：计划清晰少绕路（kp-013）、工具返回可行动（kp-010，减少瞎试）
单价（模型路由）：简单步骤用小模型（分类/抽取/摘要），复杂推理才上旗舰——级联路由是生产标配
缓存命中：prompt caching（见下）可把重复前缀的输入成本砍到原价的 10%

Prompt Caching：Agent 的免费午餐

Agent 每轮都重放"系统提示 + 工具定义 + 历史前缀"（kp-006 不变式）——这些前缀逐轮完全相同。缓存机制（各家 API 均支持）把命中前缀的输入计费降到约 1/10 且显著降低 TTFT 延迟。工程要求：前缀稳定（把动态内容挪到消息尾部、时间戳放最后一条）——一次上下文顺序调整，成本差数倍。

延迟优化的三板斧

并行化：无依赖的工具调用与子 Agent 并发（kp-019/009）；IO 等待用 asyncio
流式：先流式输出进度/中间结果，用户体感延迟大降（"正在查第 3 家…"比沉默 40 秒好）
级联降级：小模型先答 + 置信触发升级大模型；快路径（缓存的历史答案/规则命中）直接短路

生产化检查清单

持久化与恢复：状态 checkpoint，进程崩溃可续跑（框架卖点，kp-021）；幂等设计防重复副作用
重试与退避：API 429/超时的指数退避；工具调用重试上限（kp-014）
预算熔断：单任务 token/轮数上限，超限优雅终止并报告（不是烧到天荒地老）
降级路径：主模型不可用时的备选模型/排队/人工兜底
版本管理：提示、工具 schema、模型版本全部落版本戳（kp-025）
评测门禁：上述任何改动过评测再上（kp-024）
成本观测：每任务成本入 trace，异常飙升告警（有人把循环 bug 上线后一夜烧掉四位数美元）

原理与机制

为什么 Agent 成本优化要"先上下文、后模型"？算一笔账：任务平均 15 轮、初始上下文 8K、每轮新增 3K——朴素实现的输入 token 总量 ≈ 8+11+14+…+50K ≈ 435K。做两件事：① kp-022 压缩使每轮上限 20K（超出即摘要）；② 前缀稳定吃满缓存。结果可以降到 100K 量级且大半按缓存价计——不换模型，成本降约 80%。反之直接换小模型，省 50% 单价但成功率崩，还得加反思重试，净成本反升。顺序错了，优化互相抵消。

级联路由（cascade）的机制同理：任务分解后（kp-013），多数子步骤是低难度高频率（格式转换、字段抽取），小模型以 1/10 价格完成质量无损；旗舰模型只处理规划与疑难判断。评测集（kp-024）决定每级的安全边界——哪些步骤"降级不回退"。

直观类比

成本优化像给车队省油：换省油的车（换小模型）是最后的招；先把路线规划好（少绕路=少轮数）、把货装合理（上下文裁剪=不拉无用货物）、常跑线路谈通行费折扣（缓存=前缀折扣）、小件派摩托车大件才上重卡（级联路由）——前四项做好了，往往根本不用换车。

实例与案例

上线前的成本会诊（真实常见剧本）：

现状：$0.85/任务，p95 = 110s，无法接受
诊断（trace 聚合，kp-025）：
  · 62% token 花在重放历史网页全文     → 原文落盘+摘要（kp-022）
  · 平均 22 轮，其中 6 轮是重复试错    → 工具错误信息改可行动（kp-010）
  · 全程旗舰模型                      → 抽取/摘要级联到小模型
  · 前缀含时间戳导致缓存全 miss       → 动态内容挪到消息尾
结果：$0.11/任务，p95 = 41s，评测分数不降反升
     （试错轮减少本身就是质量提升）

常见误区

误区一：一上来就换小模型省钱。顺序应是上下文 → 结构 → 缓存 → 路由 → 模型；前提是评测护栏（kp-024）保证降级不翻车。
误区二："延迟靠加超时解决"。超时是兜底不是优化；并行与流式才是用户体感的主刀。
误区三：不设预算熔断。一个死循环 bug 在无人值守定时任务里能烧出一台服务器的钱。
误区四：把生产化等同于"部署上线"。状态恢复、降级、版本、成本观测这些"无聊件"才是生产化的主体——也是 kp-021 框架收费的理由。
误区五：优化后不做回归。压缩激进导致关键信息丢失、路由激进导致能力塌方——每一步优化都要过评测。

自测题

Agent 成本的四个乘子按杠杆大小怎么排？为什么上下文工程排第一？
prompt caching 生效的工程前提是什么？
预算熔断为什么是生产必选项？

（参考答案：1. 历史长度 > 轮数 > 缓存/单价路由 > 换模型——历史每轮重放，是平方级放大的乘子；2. 前缀逐字节稳定（动态内容后置）；3. 循环类故障在无人值守场景的损失无上界，熔断把尾部风险封顶。）

与其他知识点的关系

头号杠杆的细节 → kp-022；轮数优化的结构面 → kp-013/010
成本观测 → kp-025；优化护栏 → kp-024；框架提供的生产件 → kp-021
并行 → kp-019；预算与审批 → kp-023