READ · UNDERSTAND · TRANSFER
阅读理解，按需巩固
先沿着原理、问答和迁移案例阅读。需要检查理解时，再切换巩固练习或展开个人记录。
核心知识 · LLM 接口的容量、结果形态与执行边界
先理解核心原理
先备概念：HTTP 响应分类、JSON Schema、请求成本预算
模型接口交付生成结果与动作建议，应用根据结果类型决定是否执行、继续或停止。容量、形状、事实与授权分别需要检查；格式稳定不能证明业务正确，网络失败也不能证明已有动作未发生。
从普通 API 到生成接口
后端 API 常返回约定对象，模型调用还可能返回工具请求、拒绝或不完整生成。消费者不能先拼成一个字符串再猜意思，应按实际响应类型和状态分支。函数调用返回的工具名与参数是候选动作，执行端仍做校验与授权；工具回传结果关联原调用，下一轮才能使用正确事实。
Token 预算是完整输入的预算
工具定义、角色边界、历史、结果与输出都影响容量或费用，字符数只能粗估。为下一工具结果和输出留空间，调用后记录实际 usage，并区分可见回答与可能计费的推理用量。缓存能改变成本，不能默认消除上下文占用；精确限制按目标模型与接口查验。
结构化生成没有替你验证世界
Schema 能约束字段与类型，却无法凭空知道某个 ID 是否存在或属于当前用户。拒绝与输出上限导致的不完整也需要独立处理，不能把半个 JSON 补齐后当作成功。降低采样随机性至多改善某些输出差异，不能作为跨运行完全一致的保证；可复现评测要固定输入、版本和判断标准。
回到问题：怎样回答？
我重点掌握接口契约：token 决定上下文和费用预算，工具描述与历史结果也占空间；结构化输出约束形状，但不保证事实和权限；tool call 是模型提出动作，实际执行由服务端负责。采样参数会影响稳定性且支持范围因模型而异，降低温度也不等于完全确定。拒绝、截断、网络错误分别处理，重试有预算，写操作先核对结果。
实现与取舍
Token 与上下文预算
Token 是模型处理文本的单位，不等于中文字数。系统指令、工具定义、历史和工具结果都占预算，应预留输出空间，按模型支持的限制裁剪或摘要，并保存原始证据供回查。
输出与工具是不同契约
Structured Outputs约束支持的 schema，但仍需处理拒绝或不完整输出，结构正确不代表事实正确。Function calling让模型提交工具名及参数，应用负责校验、授权、执行并回传结果；不能直接执行任意模型文本。
采样、失败与验证
采样参数影响输出差异，部分模型不支持某些参数；低温度也不保证完全确定。网络超时有限退避，schema 错误修正后有限重试，拒绝不盲目重发。写操作先核对是否已成功。用正常、长输入、截断和错误参数样例验证四条路径，并记录模型版本与 token 用量。 工具结果回传时保留 call_id 关联，不能把多个结果混成一段猜测。遇到截断先检查输出上限与上下文余量，再考虑分批，不以无限扩大重试次数解决。工程重点是可解释的接口边界。
工程推演
- 场景
- 假设工程场景：工具返回长流水明细，导致下一轮回答不完整。
- 设计决策
- 工具先返回经确定程序计算的汇总和可查询明细标识，并保留输出预算。
- 验证目标
- 验收目标是完整输出且可回查，不虚构已测得的 token 节省比例。
- 适用边界
- 摘要可能遗漏细节，关键数字保留原始查询依据，不能只依赖模型摘要。
连续追问与解答
沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。
第 1 层为什么十个工具定义也会消耗上下文预算？
输入预算不能只数用户文字，工具发现也有上下文成本。
参考解答
模型需要读取工具名称、用途和参数约束才能选择调用，所以定义也进入请求输入，不是免费的服务端注释。十个很长的 Schema 可能比十条短消息更占空间。按目标模型与完整请求估算，记录实际用量；选择少量适用工具可以减少输入，但执行权限仍由网关核验。
第 1 层参数满足 schema，为什么仍可能拒绝执行？
结构输出的可靠性必须接上真实资源的授权与业务判断。
参考解答
因为 Schema 只说明参数符合局部契约，不证明账号归属、余额或审批有效。服务端从可信会话取得身份，再查资源权限与业务状态；拒绝时返回参数可修正、权限拒绝或业务条件不满足等不同类别。不能让模型换一个 tenant_id 绕过拒绝。
第 1 层模型请求超时和写入工具超时，重试策略有什么差别？
同样是超时，执行边界不同会改变重试风险。
参考解答
若模型请求只是纯生成，超时可在预算内退避重试，但可能重复费用、得到不同输出。若请求包含由供应商执行的工具或其他副作用，先检查其实际执行语义。应用写工具超时则保存结果未知，用稳定业务键或状态查询核验，不能直接发新动作。
沿着这个回答继续深入
第 2 层模型返回了工具调用，但本地还没执行就崩溃，恢复时怎么办？
从请求类型进一步定位崩溃窗口，区分候选动作与提交事实。
参考解答
持久保存待执行调用、参数摘要及关联标识，恢复核对工具账本。确认未提交才按校验流程执行；如果重新生成模型响应，调用 ID 可能变化，仍用稳定业务操作 ID 防重复。模型 call_id 用于关联结果，不自动承担业务去重。
沿着这个回答继续深入
第 3 层工具已经成功，下一轮模型输出被截断，需要再执行工具吗？
下一轮生成失败不使上一轮副作用失效，恢复应按层处理。
参考解答
不需要。成功回执是独立事实，保留对应调用结果和业务 ID；缩小上下文、合理分段或调整输出预算后重做解释。若后续工具基于新输出产生新意图，重新检查。不能因为最终文字不完整而把已经完成的写动作全部重放。
举一反三：条件变了，怎样推导？
先找出改变的条件，再判断原方案中哪些前提仍成立。下面的案例是教学推演，便于将原理迁移到新问题。
流式响应只到一半
改变的条件：完整响应变为增量传输后中断
延伸问题：已经看见大部分参数，可以先执行工具吗？
推导与参考解答
不能仅凭不完整增量执行。等对应工具调用完整并通过解析、Schema 与授权检查；流中断时保存接收状态，检查服务是否有恢复机制。用户界面可以显示生成进度，但“开始生成参数”不等于动作获准，部分文本也不能作为最终完成证据。
保持不变的原理：候选输出成为动作前必须完成约定的校验，传输速度不改变边界。
切换模型或供应商
改变的条件：输入业务相同，接口能力与输出格式变化
延伸问题：兼容 OpenAI 风格请求就能无缝替换吗？
推导与参考解答
不能只看路径和字段相似。验证工具调用格式、结构约束支持、拒绝与不完整状态、token 统计和参数支持，适配器把它们映射为内部稳定类型；用同一任务集比较业务结果。持久化记录模型及契约版本，旧任务恢复显式选择策略，不能盲传不支持的采样参数。
保持不变的原理：稳定应用行为来自明确接口契约与验证，而非品牌名称或表面格式。
易错点
- 把 token 当成汉字或英文单词的固定数量。
- 认为 strict schema 自动保证事实正确和业务授权。
- 认为降低温度就获得跨运行完全相同的结果。
参考资料
依据公开技术资料设计；参考资料支持技术机制，场景与评分标准为本站设计，不代表某公司面试原题。 新增问答与迁移案例用于原理讲解，来源核查与案例运行验证分别记录。
检查自己理解到哪一步
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评；需要进一步验证时，再完成下方小任务。
- 基础达标
- 理解上下文、Token、工具调用与结构化输出。
- 中高级信号
- 知道格式正确不代表事实或权限正确，能处理异常返回。
- 资深信号
- 能把接口限制转成预算、校验、回归与模型切换契约。
巩固练习 按需完成 · 建议 15 分钟
阅读一段同时含工具调用和文本的模型响应，指出下一步执行边界。
展开验收要求与检查点
- 工具先校验再执行
- 模型文本不是成功证明
- 上下文与输出预算分开考虑
重点检查
- 知道工具 schema、历史消息和工具结果都影响上下文预算。
- 区分 JSON 结构有效、业务参数正确与有权限执行。
- 可以给出拒绝、截断和超时的不同处理路径。