OpenAI 官方 Agent 优化 Cookbook 解读：客服智能体的四轮降本方法论

给『智能体太贵』一个官方答案：openai-cookbook 在 2026-09-18 合入了 Agent 优化教程（Optimizing customer support agents for cost and quality，PR #3073），用一套合成电商客服工单和一个确定性模拟，把『先测基线、每轮只改一处、质量过关才接受省钱』做成了可运行的示例。本篇按本站惯例在 2026-09-22 重抓仓库原文逐项核对后转述：教程的方法论、九个优化旋钮、GPT-5.6 缓存行为的变化，以及教程自己先承认的模拟局限。所有数字凡出自模拟的，本文都保持它『示例』的身份，不当基准转述。

1. 这份教程讲什么

一句话：给『用工具的智能体』一个可复用的优化冲刺（optimization sprint）——测量基线，改变工作流的一处，质量过关后才接受省下的钱。场景是电商客服：合成工单、客户查询、订单与政策工具、退款与升级决策。教程自己的 Outline 是八步：定义成功标准与小评估集 → 搭一个故意低效的基线智能体 → 测基线成本/token/质量/延迟/工具调用 → 应用提示、输出、工具与上下文控制 → 简单步骤路由给小模型 → 为缓存重排请求结构 → 拆分实时与跟进工作 → 加监控、评估与护栏。

代码默认 dry-run 模式，不花 API 钱；可选的 live 助手需要 OPENAI_API_KEY 且 RUN_LIVE_API_CALLS=true。可选的 LLM judge 需要 RUN_LLM_JUDGE=true，judge 模型是 gpt-5.4-mini（live_api.py 中定义）。依赖只有五个：openai、pandas、matplotlib、jinja2、ipykernel。

2. 先说教程自己承认的局限：模拟数字不是基准

这是整份教程最值得学的一段写作。Simulation contract 一节开宗明义：默认路径用 mock 数据和建模指标，它的数字不是生产基准。具体地：

• harness 测的是序列化文本长度，token 计数由长度估计；
• 推理 token、延迟、缓存命中与综合质量分走示例公式；
• 成本项倒是把『已核实的价格表』套在估计用量上；
• 路由与优化动作来自夹具标签——所以这个模拟根本不测模型选对路由的能力；
• 回复检查是大小写不敏感的字面短语匹配，可能误杀合法转述，也建立不了事实正确性。

教程的结论：部署决策要换成真实用量、真实时延、真实工具结果、真实路由决策与校准过的评审或人工评估。本站把这一节放在方法论之前讲，因为它是读者最容易误用这份教程的地方。

3. 九个优化旋钮总览

教程用一张表列出全部旋钮、低效基线与优化后形态：

4. 第一轮：提示、输出与工具控制

先立规矩再换模型。教程的组合拳：把 text.verbosity 与推理力度调低，加输出上限与 allowed_tools 子集。三个容易忽略的提醒：

• 输出上限同时约束可见与推理 token——压低之后要检查不完整回复；
• helper 还限制了工具轮数、返回瘦身载荷；
• 对长会话，压缩或截断要谨慎评估：删掉早先上下文可能丢掉下一步决策需要的事实。

还有一个工程诚实的备注：demo 里用已知工单元数据限制工具，生产环境的路由器需要单独评估与低置信度回退；如果做提示优化，要针对一个具体观测到的失败，并在同一套评估上重跑。

5. 第二轮：按步骤选模型，而不是全局一个模型

教程的分层（以 GPT-5.4 为基线）：

GPT-5.6 侧的同层对照：gpt-5.6-luna 对 nano 层（分类与高吞吐任务）、gpt-5.6-terra 对 mini 层（常规支持工作流）、gpt-5.6-sol 对全量模型层（复杂或高风险场景）——每层都可以用同一批工单与质量标准对 GPT-5.4 基线做评估。两个方法论细节值得抄走：对比时先沿用现有推理力度设置，再评估低一档；新模型在任务层面反而更省是可能的——如果它重试、多余工具调用或升级更少。微调只有在选定模型明确支持时才考虑。

6. 第三轮：prompt caching——GPT-5.6 的三个变化

所有客服请求共享同样的核心指令、政策、工具定义与回复 schema，缓存让这部分跨工单复用；客户特有细节（订单 ID、账户信息、检索记录）放在共享前缀之后。

gpt-5.4-mini 的行为：API 自动识别重复前缀，客户细节变化也能复用共享上下文，写新前缀不收单独的缓存写入费。教程给出的请求形态（取自教程代码单元，行宽有压缩）：

cache_friendly_request = {
    "model": "gpt-5.4-mini",
    "instructions": CACHE_FRIENDLY_PROMPT,
    "tools": SLIM_TOOLS,
    "tool_choice": allowed_tool_choice(["lookup_order"], mode="auto"),
    "prompt_cache_key": "support_order_status_v1",
    "reasoning": {"effort": "low"},
    "text": {"verbosity": "low"},
    "max_output_tokens": 300,
    "input": [
        {"role": "user", "content": json.dumps({
            "ticket_id": "T-001", "customer_id": "C-100",
            "message": "Where is order O-1001?", "order_id": "O-1001",
        })},
    ],
}

GPT-5.6 家族（luna / terra / sol）有三点不同：

1. 缓存写入计费：写内容进缓存按正常输入 token 价的 1.25 倍收费——反复缓存每次都不同的消息，只会增加成本而不产生复用；
2. 默认断点在最新消息之后：如果那条消息在工单之间变化，最长被缓存前缀可能匹配不上；implicit 模式仍可复用更早的合格消息结尾（包括开头的 developer 消息块）；
3. 显式断点：把共享手册放进 developer 消息的 input_text 块，在块尾把 prompt_cache_breakpoint 标为 explicit 模式，订单细节放断点之后；顶层 instructions 不能含断点。

配套设置：prompt_cache_options 用显式模式、ttl 为 30m，两笔请求用同一个 prompt_cache_key（教程例：support_order_status_v1）。观测指标：cached_tokens 与 cache_write_tokens，连同延迟与每解决工单成本一起比较。

7. 第四轮：把非客户工作移出同步路径

同步路径只留四件事：分类、必要查询、解决或升级决策、客户回复。QA、标签、内部摘要、审计与报表——只要不影响当下结果——移到跟进工作。档位选择：延迟敏感走 default 或 priority；flex 用更低成本换更慢响应与偶发容量不可用（确认模型支持并处理超时）；Batch 适合有 24 小时完成窗口的离线任务；background 模式只是异步化，本身不给价格折扣。

8. 权衡与场景映射：没有万能最优解

教程明确说：不存在普适最优配置，甜点取决于流量形态、对客户的承诺、政策风险、缓存命中率、工具延迟、可观测性成熟度，以及多少工作能挪出同步路径。七组典型权衡摘三组：

教程还专门为『低重复长尾』场景画了全部架构组合的对比图，理由是：缓存本地性低的场景里，重缓存设计不划算——这一点不该被『只展示最优解』藏掉。

9. 监控：按『每次已验证解决』算成本

上线后要保持循环评估，目标不是孤立地最小化 token，而是以最低总成本正确、安全、快速地解决客户问题。教程的公式：

blended cost per verified resolution = (模型、工具、基础设施、重试、人工复核、升级与返工的总成本) / 已验证解决的客户问题数

三条配套纪律：分子必须计入失败尝试，不能只算最终通过的 traces；自主解决与人工协助解决分开统计，否则智能体降本可能只是把工作转移给了支持团队；教程自己给的示例数字是说明性的——单票 0.02 美元、解决率 50%，等于每个成功解决 0.04 美元；单票 0.03 美元、解决率 90%，约 0.033 美元。第二次每一次尝试更贵，但每个成功结果更便宜（示例不含人工支持成本）。

上线后要跟踪的清单：质量分、政策合规、动作准确率、升级准确率、工具调用次数、token 用量、缓存 token 量、p50/p95 延迟、同步成本、异步跟进成本、每工单总成本。一个配置只有在守住质量线的前提下降了成本，才算更好。

10. 九步调优顺序（官方推荐）

教程的收束是这条顺序——把它做成了本文 frontmatter 的 howTo，这里原样列出：建立基线 → 提示/输出控制 → 工具控制 → 上下文治理 → 模型路由 → prompt caching → 缓存感知的上下文调优 → 拆分工作流 → 处理档位。最强结果不是来自单一技巧，而是按安全顺序逐个上杠杆；核心工程习惯是按步骤优化，不全局优化——常规分类器、高风险退款争议、客户回复与离线 QA 标注器不该共享同一个模型、上下文、工具、延迟目标或服务档。

11. 如何运行与常见错误

运行要点：pip install -r requirements.txt（openai、pandas、matplotlib、jinja2、ipykernel），默认 dry-run 零花费；live 路径需 OPENAI_API_KEY 且 RUN_LIVE_API_CALLS=true；可选 judge 需 RUN_LLM_JUDGE=true（模型 gpt-5.4-mini，judge 失败时评分标 error 并说明原因，不阻塞其余评估）。

常见错误：

• 把模拟数字当基准写进汇报——重读第 2 节：模拟合同明示数字不是生产基准，token 是长度估计、路由来自夹具标签；
• 只算 token 不算解决率——重读第 9 节：便宜的模型若重试更多，每个已验证解决的成本反而更高；
• 把断点写进顶层 instructions——教程原文：顶层 instructions 不能含断点，断点要标在 developer 消息 input_text 块尾；
• 每张工单换一个 prompt_cache_key——同业务场景要用稳定 key（教程例：support_order_status_v1），key 碎了缓存就废了（教程在『季节性高峰』权衡里同样点名 routing key 过碎会让缓存失效）；
• 输出上限压得过低没检查不完整回复——上限含可见与推理 token。

12. 下一步

• Agents API 现身 OpenAI SDK（beta）：/agents CRUD、environments、sessions 与 vaults 全景——教程优化对象背后的 Agents API 本体；
• openai-python 3.15 / 3.16 与 openai-node 7.18 / 7.19 更新解读：缓存预热、Webhook 管理与 connector_id 弃用——prompt_cache_options 家族的另一个成员 prewarm，与本篇第 6 节同属缓存控制面；
• openai-python 3.9 / 3.10 与 openai-node 7.11 / 7.12 更新解读：prompt cache 诊断、API key 过期与 GPT Image 2.5——用 comparison_response_id 诊断缓存命中与否，配本篇的 cached_tokens 观测一起用。