Session 0010

LLM API 契约与 Prompt Caching

LLM API 是应用与模型之间的契约层：请求参数定义模型行为边界，响应字段决定应用控制粒度，缓存策略直接影响成本和延迟。面试考的不是背参数表，而是能否解释每个设计选择背后的工程权衡。

1. 训练目标

本页要练会：对比 Anthropic Messages API 与 OpenAI Chat Completions API 的核心参数语义差异，设计 prompt caching 分层策略，解释 cache 命中率与上下文丰富度之间的工程权衡。

可靠依据：Anthropic Messages API 文档 / OpenAI Chat Completions API 文档 / Anthropic Prompt Caching 指南。本页把官方能力和生产工程约束转成面试题，而不是堆概念定义。

题量标准：5 个中大型深题 + 7 个知识广度题。深题用于系统设计和追问承压，广度题用于查漏补缺。

2. 五个深题

深题 01

Anthropic 和 OpenAI 的 Messages API 在 system prompt 处理上有何不同？这个差异反映了什么设计哲学？

考察点：面试官判断你是否理解 API 参数不只是字段差异，而是反映了不同的 prompt 工程理念。Anthropic 把 system 作为顶层参数，OpenAI 放在 messages 数组中 role=system。

7+ 分回答骨架：Anthropic 将 system 提升为独立顶层参数，与 messages 平级，语义上区分了"行为指令"和"对话历史"。OpenAI 把 system 当作 messages 中的一条消息，system/user/assistant/tool 四种 role 在同一数组中。这影响 prompt caching 策略：Anthropic 的 system 天然是稳定前缀，更容易缓存命中；OpenAI 的 system 如果在 messages[0] 也可以缓存，但一旦 messages 数组变化（如插入新消息），前缀稳定性下降。

继续追问会衍生：衍生知识点：instruction hierarchy、prompt structure、cache boundary、multi-system prompt。

知识展开

概念	是什么	工程落点	面试表达 / 常见坑
instruction hierarchy	指令层级是 system > user > tool 的优先级顺序，当不同来源的指令冲突时，高优先级覆盖低优先级。	Anthropic 通过顶层 system 参数 + messages 中的角色区分实现；OpenAI 通过 developer message 或 messages[0] role=system 实现。	面试中要说清"为什么系统指令不能被用户消息覆盖"，这是安全设计的基础。
prompt structure	prompt 结构决定 system、context、history、user input 的排列顺序，直接影响缓存命中率和 token 效率。	稳定内容（system prompt、用户画像）放最前作为缓存前缀；变化内容（对话历史、当前输入）放最后。	强回答要能解释 prompt 结构如何同时优化缓存命中和指令遵循。
cache boundary	缓存边界是 prompt 中稳定部分和变化部分的分界线，缓存只能命中到最后一个稳定的 token。	Anthropic cache_control 标记可以显式指定缓存断点；OpenAI 自动按前缀匹配缓存。	常见坑是把 system prompt 和动态 context 混排，导致缓存频繁 miss。

深题 02

stop_reason 和 finish_reason 有哪些可能的值？每种值对应用层意味着什么？

考察点：考模型输出的控制语义。很多人只知道 end_turn/stop，不理解 tool_use、max_tokens、stop_sequence 等值对应用流程的影响。

7+ 分回答骨架：Anthropic 的 stop_reason 有 end_turn（模型自主结束）、max_tokens（截断）、stop_sequence（命中停止词）、tool_use（需要工具调用）。OpenAI 的 finish_reason 有 stop、length、content_filter、tool_calls、function_call。应用层必须根据这些值决定下一步：end_turn/stop 表示可以返回给用户；tool_use/tool_calls 表示要执行工具再回传结果；max_tokens/length 表示输出不完整，可能需要继续请求或报错；stop_sequence 表示命中预设终止条件；content_filter 表示被安全策略拦截。忽略 stop_reason 会导致工具调用链断裂、输出截断无感知、安全拦截被忽略。

继续追问会衍生：衍生知识点：tool call lifecycle、output truncation、content filtering、continue generation。

知识展开

概念	是什么	工程落点	面试表达 / 常见坑
tool call lifecycle	工具调用是一个多步骤过程：模型发出 tool_use → 应用执行工具 → 应用回传 tool_result → 模型继续推理。stop_reason=tool_use 不是结束，而是中间状态。	agent loop 中根据 stop_reason 判断是否进入工具执行阶段，回传结果后继续请求模型。	面试中要说"tool_use 不是最终回答，应用必须执行工具并回传结果，否则 agent 链断裂"。
output truncation	max_tokens/length 表示输出被截断，内容不完整。这不是正常结束，而是预算用尽。	应用层应检测截断并采取行动：增加 max_tokens、发出 continue 请求、或提示用户内容被截断。	常见坑是不检查 stop_reason，截断输出被当作完整回答返回给用户。
content filtering	content_filter 表示输出被安全策略拦截，模型没有生成完整内容。	应用层需要记录拦截事件、通知用户、可能的降级回复策略。	强回答要区分 max_tokens（技术问题）和 content_filter（安全问题），处理策略完全不同。

深题 03

Streaming 在生产环境中有哪些工程挑战？你怎么设计一个可靠的 streaming 管道？

考察点：考 streaming 不只是"加个 stream=true"。面试官想看你是否理解 SSE 协议、断线重连、错误传播和状态管理。

7+ 分回答骨架：Streaming 基于 SSE（Server-Sent Events），挑战包括：连接中断后的恢复（无法从中间 resume，只能重新请求）；tool_use 事件的流式组装（需要收集完整 tool call JSON 后才能执行）；错误事件可能在流中间到达（需要区分 content delta 和 error event）；usage 统计只在流结束时返回（需要额外机制统计中间成本）；客户端渲染需要处理部分 token 的 Markdown 不完整。设计上：服务端做 chunk 聚合和 tool call 组装；客户端做增量渲染和断线重试；中间层做 backpressure 和超时控制。

继续追问会衍生：衍生知识点：SSE protocol、chunk aggregation、backpressure、partial rendering。

知识展开

概念	是什么	工程落点	面试表达 / 常见坑
SSE protocol	Server-Sent Events 是单向 HTTP 长连接，服务端推送事件流。不同于 WebSocket 的双向通信，SSE 更简单但有断线不能 resume 的限制。	每个 event 有 type（content_block_delta、message_delta、error 等）和 data 字段。客户端按 event type 分派处理。	面试中要说清 SSE vs WebSocket 的选型：LLM streaming 是单向推送，SSE 足够；双向交互（如中断生成）需要额外机制。
chunk aggregation	流式返回的 tool call 参数被拆成多个 chunk，应用层必须收集完整 JSON 后才能解析和执行。	按 tool_call index 分组，拼接 delta，JSON.parse 成功后才进入工具执行阶段。	常见坑是每个 chunk 都尝试解析 JSON，导致解析失败或参数不完整。
backpressure	当客户端消费速度跟不上服务端推送速度时，需要背压控制避免内存溢出或连接超时。	中间层做 chunk buffering、rate limiting、超时断开；客户端做增量渲染而不是全量累积。	强回答要说 streaming 不只是"更快看到第一个 token"，还要处理"生成速度远超渲染速度"的场景。

深题 04

Prompt Caching 的机制是什么？如何设计一个高命中率的缓存策略？

考察点：考 prompt caching 不是"加个缓存就行"。面试官想看你是否理解缓存边界、TTL、最小 token 要求和成本计算。

7+ 分回答骨架：Anthropic Prompt Caching 按 prompt 前缀匹配缓存，最小缓存单元 1024 tokens（Opus）或 2048 tokens（Sonnet/Haiku），TTL 5 分钟，cache read 成本是 input 的 10%（write 是 125%）。OpenAI 自动缓存，最小 1024 tokens，无显式 TTL 控制。高命中率策略：把稳定内容（system prompt、用户画像摘要、工具定义、few-shot examples）放最前作为缓存前缀；变化内容（对话历史、当前用户输入）放最后；控制缓存前缀的更新频率在 5 分钟内；监控 cache_read_input_tokens vs input_tokens 的比例作为核心指标。

继续追问会衍生：衍生知识点：cache TTL、minimum cache size、cost model、cache invalidation。

知识展开

概念	是什么	工程落点	面试表达 / 常见坑
cache TTL	缓存生存时间是 5 分钟（Anthropic），两次请求间隔超过 TTL 则缓存失效，需要重新写入。高频场景缓存命中率高，低频场景几乎无法命中。	对低频用户（间隔 > 5 分钟）缓存收益低；对高频场景（如客服、代码助手）缓存收益高。设计时要按用户频率评估缓存 ROI。	面试中要说"TTL 5 分钟意味着低频用户的缓存几乎永远 miss，缓存策略不能一刀切"。
minimum cache size	Anthropic 要求缓存前缀至少 1024 tokens（Opus）或 2048 tokens（Sonnet/Haiku），低于阈值则不缓存。	system prompt 太短时缓存无意义；需要确保缓存前缀超过最小阈值才有收益。	常见坑是 system prompt 只有几百 token，远低于缓存阈值，导致缓存永远不生效。
cost model	cache write 成本是正常 input 的 125%，cache read 成本是 10%。只有命中率足够高时缓存才划算。盈亏平衡点约 8%：即 cache read 占比 > 8% 时开始省钱。	监控指标：cache_read_tokens / total_input_tokens。目标 > 50% 才算缓存策略有效。	强回答要能算出盈亏平衡点，而不是只说"缓存省钱"。

深题 05

如何权衡 Prompt Caching 和长上下文？设计一个兼顾成本和推理质量的分层策略。

考察点：考架构设计能力。缓存和上下文是一对核心矛盾：缓存要求前缀稳定（少变化），上下文要求信息完整（多变化）。

7+ 分回答骨架：分三层设计。第一层：稳定前缀区（system prompt + 工具定义 + 用户画像摘要），放入缓存，几乎不变化，命中率接近 100%。第二层：半稳定区（长期记忆摘要、近期对话压缩摘要），更新频率低（每 N 轮或新话题时更新），可在 TTL 内命中。第三层：动态区（最近 3-5 轮对话原文 + 当前用户输入），每轮变化，不缓存。对话超过窗口时，旧对话压缩进第二层，最旧的记忆归档。成本优化：监控每层的 token 占比和 cache hit rate，动态调整第二层的更新频率和第三层的窗口大小。

继续追问会衍生：衍生知识点：layered context、summary injection、cost monitoring、adaptive window。

知识展开

概念	是什么	工程落点	面试表达 / 常见坑
layered context	分层上下文把 prompt 按变化频率分成稳定层、半稳定层和动态层，每层有不同的缓存策略和更新频率。	稳定层：system + tools（缓存，几乎不变）；半稳定层：memory summary（缓存，低频更新）；动态层：recent turns（不缓存）。	面试表达：不是"全缓存"或"全上下文"的二选一，而是分层让稳定部分享受缓存、变化部分保持信息完整。
summary injection	摘要注入是把压缩后的历史对话以结构化格式插入半稳定层，而不是原样保留完整历史。	摘要保留关键决策、未完成承诺、错误状态和引用 ID；丢弃闲聊、重复确认和冗余解释。	强回答要说摘要不是简单的"总结前文"，而是按任务需要选择性保留关键状态。
adaptive window	自适应窗口根据任务类型、token 预算和 cache 命中率动态调整保留多少轮原文。	简单问答保留 3 轮；复杂编码任务保留 10 轮；cache 命中率低时减少窗口、增加摘要比例。	常见坑是固定保留 N 轮，不考虑任务复杂度差异。

3. 七个广度题

编号	问题	准确回答
广度 01	temperature=0 和 temperature=1 分别适合什么场景？	0 适合需要确定性的场景（代码生成、数据提取、工具参数）；1 适合创意场景（文案、头脑风暴）。注意不同厂商范围不同：Anthropic 0-1，OpenAI 0-2。
广度 02	top_p 和 temperature 能同时调吗？	不建议同时调。两者都控制随机性，同时调整效果难以预测。实践中选一个，另一个保持默认。
广度 03	Anthropic 的 top_k 和 OpenAI 的 frequency_penalty 解决什么问题？	top_k 限制候选 token 数量（Anthropic 独有）；frequency_penalty 降低重复 token 的概率（OpenAI 独有）。两者目标类似但机制不同。
广度 04	usage 中的 token 计数包含什么？	Anthropic：input_tokens（含 cache_read + cache_creation）和 output_tokens。OpenAI：prompt_tokens、completion_tokens、total_tokens。两者都含 system prompt。
广度 05	什么时候用 stop_sequences？	当需要在特定标记处停止时使用，如代码生成的函数边界、对话中的角色切换标记。注意 stop_sequences 消耗的 token 也计入 output。
广度 06	streaming 模式下如何获取 usage？	Anthropic 在 message_delta 事件中返回 usage；OpenAI 需要设置 stream_options.include_usage=true。两者都只在流结束时返回。
广度 07	tool_choice 有哪些策略？区别是什么？	auto（模型自主决定是否调用）、any/required（必须调用至少一个工具）、tool/name（强制调用指定工具）。auto 最灵活但不可控，forced 最可控但限制了模型判断。

4. 知识索引

instruction hierarchy

指令层级是 system > user > tool 的优先级顺序，当不同来源的指令冲突时，高优先级覆盖低优先级。

prompt structure

prompt 结构决定 system、context、history、user input 的排列顺序，直接影响缓存命中率和 token 效率。

cache boundary

缓存边界是 prompt 中稳定部分和变化部分的分界线，缓存只能命中到最后一个稳定的 token。

tool call lifecycle

工具调用是多步骤过程：模型发出 tool_use → 应用执行 → 回传 tool_result → 模型继续推理。

output truncation

max_tokens/length 表示输出被截断，内容不完整，应用层必须检测并采取行动。

content filtering

content_filter 表示输出被安全策略拦截，处理策略与 max_tokens 截断完全不同。

SSE protocol

Server-Sent Events 是单向 HTTP 长连接，LLM streaming 基于此协议。

chunk aggregation

流式 tool call 参数被拆成多个 chunk，必须收集完整后才能解析执行。

backpressure

客户端消费速度跟不上推送速度时的流量控制，避免内存溢出。

cache TTL

Anthropic 缓存生存时间 5 分钟，低频场景缓存几乎永远 miss。

minimum cache size

缓存前缀至少 1024 tokens（Opus）或 2048 tokens（Sonnet/Haiku）。

cost model

cache write 125%，cache read 10%，盈亏平衡点约 8% 命中率。

layered context

分层上下文：稳定层（缓存）、半稳定层（低频更新）、动态层（每轮变化）。

summary injection

压缩后的历史对话以结构化格式注入半稳定层，按任务需要选择性保留。

adaptive window

自适应窗口根据任务类型、token 预算和 cache 命中率动态调整保留轮数。

5. 巩固训练

练习	要求	自检
参数对比表	3 分钟内写出 Anthropic 和 OpenAI 各 5 个独有或语义不同的参数。	是否覆盖 system 位置、top_k、frequency_penalty、tool_choice 语义、cache 控制。
缓存 ROI 计算	给定一个场景（QPS、平均 token 数、用户频率），计算缓存策略是否划算。	是否正确计算 cache write 额外成本 vs cache read 节省成本。
stop_reason 决策树	画出完整的 stop_reason 处理流程图：每种值对应什么应用层动作。	是否覆盖 end_turn、tool_use、max_tokens、stop_sequence、content_filter 五种情况。
分层设计	为一个具体场景（如客服 agent）设计三层 prompt 结构，标注每层内容和缓存策略。	是否说清每层的更新频率、token 占比和 cache 命中率目标。

6. 弱回答红线

只说"Anthropic 有 system 参数，OpenAI 放在 messages 里"，不解释设计哲学差异和对缓存的影响。
把 streaming 说成"加 stream=true 就行"，不提 SSE、断线恢复、chunk 聚合和 backpressure。
说"缓存省钱"但不提 TTL、最小 token 要求和盈亏平衡点。
cache vs context 只给"平衡两者"的模糊建议，不给分层方案和监控指标。
不知道 stop_reason=tool_use 是中间状态而非最终回答。

有不清楚的地方？

这节课覆盖的内容密度较高。如果你对某个概念（如 SSE 协议细节、cache 盈亏平衡计算、分层策略的具体实现）有疑问，随时向 agent 追问。agent 是你的老师，可以针对你的具体场景给出更详细的解释和代码示例。

推荐阅读：Anthropic Prompt Caching 官方文档 — 这是理解缓存机制、TTL、最小 token 要求和 cost model 的最权威来源。