agent 的成本控制Cost control for agents

agent 的成本就是 token 乘以步数，再乘以每步带着的上下文。 三个因子，三个手段：砍无效 token、缩短上下文、限制步数。 本篇只讲机制与做法，不引任何价格数字—— 具体价格以各厂商官方定价页为准。

An agent's cost is tokens times steps, times the context each step carries. Three factors, three levers: cut useless tokens, shorten the context, cap the steps. This guide covers only mechanisms and practices, and cites no price numbers — for actual prices go to each vendor's official pricing page.

不知道花在哪，就谈不上省。 OpenAI 的缓存文档示范了最小记账单位： 每次响应的 usage 里分开报输入、输出、缓存写入、缓存读取四类 token。 先按这四类建账，再谈优化—— 否则你连「缓存到底命中了没有」都不知道。

典型的成本结构：

1. 输入 token：历史越长越贵，多轮对话里它常是大头。 2. 输出 token：通常比输入贵，但总量可控。 3. 步数：agent 每跑一步就是一次完整调用，循环十次付十次。 4. 工具往返：每次工具调用的定义和结果都进上下文。

If you don't know where the money goes, saving is out of the question. OpenAI's caching docs model the minimal accounting unit: each response's usage reports four token classes separately — input, output, cache write, cache read. Build the ledger on these four first, then talk optimization — otherwise you can't even tell "did the cache hit at all".

A typical cost structure:

1. Input tokens: longer history costs more; in multi-turn conversations this is often the bulk. 2. Output tokens: usually pricier per token than input, but the total is controllable. 3. Steps: every agent step is a full call; loop ten times, pay ten times. 4. Tool round-trips: every tool call's definition and result enter the context.

同一段内容反复发给模型，是最大的浪费。 主流厂商的解法都是前缀缓存：把请求开头完全相同的部分缓存下来复用。

OpenAI：缓存对符合条件的请求自动生效，无需改代码。 命中要求前缀完全一致。 OpenAI 官方原文："Cache hits are only possible for exact prefix matches within a prompt."

官方建议把静态内容（指令、示例）放提示词开头， 变化内容（用户信息）放末尾。 GPT-5.6 及之后的模型上还支持显式缓存断点， 并可用 prompt_cache_key 把共享长前缀的请求路由到一起。 缓存按用量分桶记账在 cached_tokens 里。

Anthropic：用 cache_control 标记缓存断点， 可缓存的部分包括工具定义、system、对话消息。 内容有最小长度门槛，达不到就不缓存——静默跳过，不报错。 缓存有存活期，默认短时效，命中即续期。

缓存按 tools → system → messages 的层级组织， 改动哪一层会让该层及之后的缓存失效。 响应里的 cache_creation_input_tokens 与 cache_read_input_tokens 就是缓存效果的账本。

两条通用纪律： 静态在前，变化在后； 先确认命中再庆祝——创建很多、读取很少，说明前缀根本没稳住。

Sending the same content to the model over and over is the biggest waste. Mainstream vendors' answer is prefix caching: cache and reuse the exactly-identical opening of requests.

OpenAI: caching applies automatically to eligible requests, no code changes. A hit requires the prefix to match exactly. OpenAI official text: "Cache hits are only possible for exact prefix matches within a prompt."

The official advice: put static content (instructions, examples) at the start of the prompt, changing content (user information) at the end. On GPT-5.6 and later models explicit cache breakpoints are also supported, and prompt_cache_key routes requests sharing a long prefix together. Caching is bucketed in the usage ledger as cached_tokens.

Anthropic: mark cache breakpoints with cache_control; cacheable parts include tool definitions, the system prompt, and conversation messages. There is a minimum-length threshold; below it caching is silently skipped, no error. Caches have a lifetime — short by default, renewed on hit.

The cache is organized in the hierarchy tools → system → messages; changing a layer invalidates that layer and everything after it. The cache_creation_input_tokens and cache_read_input_tokens in responses are the ledger of caching's effect.

Two universal disciplines: static first, change last; confirm the hit before celebrating — lots of creation and little reading means the prefix never stayed stable.

上下文膨胀是 agent 成本的隐形推手。几个有据可查的手段：

摘要续接：长对话压成摘要再续，而不是全量续。 这是压缩，不是记忆——详见记忆系统一篇的边界讨论。

按需召回：不把知识库整篇塞进提示词，用时才检索—— RAG server 的做法，见 context7 档案。

及时收尾：任务完成就停，别让 agent「再检查一遍」地空转。 步数上限要在 harness 层设死，不能指望模型自觉。

分级用模型：简单的步（分类、抽取）用快而小的模型，难的步才上大模型。 OpenAI 官方原文：guardrails 文档的例子是用一个快而省的模型先做检查， "saving time and money"，挡在贵模型前面。

Context bloat is the invisible driver of agent cost. Several documented measures:

Summary continuation: compress a long conversation into a summary and continue, rather than continuing in full. That is compression, not memory — see the boundary discussion in the memory systems guide.

Recall on demand: do not stuff whole knowledge-base articles into the prompt; retrieve only when needed — the RAG-server approach, see the context7 dossier.

Wrap up promptly: stop when the task is done; don't let the agent idle through "one more check". Step caps must be hard-set at the harness layer; do not count on the model's self-discipline.

Tier the models: use fast small models for simple steps (classification, extraction), big models only for hard ones. OpenAI official text: the guardrails docs' example uses a fast economical model to check first, "saving time and money", standing in front of the expensive model.

最便宜的调用是从未发生的调用。 OpenAI Agents SDK 的 guardrails 有两种执行方式，成本语义完全不同。

并行执行（默认）：护栏与 agent 同时跑，延迟最低。 但触发时 agent 可能已经烧过 token、执行过工具。

阻塞执行：护栏先跑完，agent 后启动。 触发即止，token 与工具副作用都不会发生。 OpenAI 官方原文：阻塞执行 "is ideal for cost optimization and when you want to avoid potential side effects from tool calls"。 对「恶意输入根本不该进贵模型」的场景，阻塞执行是明确更省的选择。

注意输出护栏不支持并行参数——它永远在 agent 完成后跑。

The cheapest call is the one that never happens. The OpenAI Agents SDK's guardrails have two execution modes with completely different cost semantics.

Parallel execution (default): the guardrail and the agent run together, lowest latency. But when it trips, the agent may already have burned tokens and executed tools.

Blocking execution: the guardrail finishes first, the agent starts after. Trip and halt — no tokens spent, no tool side effects. OpenAI official text: blocking execution "is ideal for cost optimization and when you want to avoid potential side effects from tool calls". For "malicious input should never reach the expensive model" scenarios, blocking execution is the clearly cheaper choice.

Note output guardrails do not support the parallel flag — they always run after the agent completes.

Anthropic 官方原文："Agentic systems often trade latency and cost for better task performance."

延迟也是成本——用户等不及会走。 以及错误复合的返工成本：一步错、步步错， 重跑十次的账单比一次大模型直接答完还贵。 先算总账，再决定省哪一段。

Anthropic official text: "Agentic systems often trade latency and cost for better task performance."

Latency is also a cost — users who cannot wait will leave. And the rework cost of compounding errors: one step wrong, every later step wrong, and the bill for ten reruns can exceed one big-model answer done directly. Do the total accounting first, then decide which segment to save.