别从“用哪个大模型”开始：先证明用户任务值得被解决
AI 产品题真正考的是把开放生成变成工程契约：谁在什么场景完成什么任务，哪些失败不可接受，怎样用离线证据筛候选，再用灰度、成本与回滚决定是否放量。模型只是发布单元中的一个变量。
先看整套知识的坐标，再逐题理解
这不是背答案清单。先用地图确认概念之间的依赖，再沿“白话直觉 → 核心结论 → 原理与取舍 → 常见误区”阅读每个知识点。
先看关键链路，单个知识点才不会变成碎片
面试官追问的方向，往往就是这张图里的下一根箭头：输入怎样变化、状态存在哪里、哪一步最贵、失败怎样被验证。
换一个关键词，或切回“全部章节”。
先确定 AI 是否是合适手段，再定义它必须守住什么
好的需求不是“加一个聊天框”。它描述用户任务、现有基线、信息与动作边界，以及失败发生时谁承担什么。
什么场景适合用生成式 AI？什么时候规则、搜索或人工流程更合适？#
先用大白话把它讲明白
当输入表达开放、输出允许多种有效答案，或任务需要理解与生成非结构化内容时，生成式 AI 才是候选，例如归纳长文、草拟回复、把自然语言转成查询；这不等于它对每个长尾都可靠。
若输入输出稳定、规则可枚举且结果必须确定，普通代码或模板通常更便宜可控；只需找已有事实时先考虑检索；高风险决策可让模型提案，但真实权限和最终决定留给确定性系统或人。
先建立同口径的非 AI 基线：合格任务量、人工时长、规则/搜索成功率与失败代价。只有完整方案在约定周期内带来足够增量，且风险与回退可接受，才值得引入。
我从任务而非模型出发：开放表达、非结构化理解与多种有效输出可把生成式 AI 列为候选；确定性强的任务优先普通软件，事实查找优先检索，高风险动作保留服务端授权与人工边界。先固定非 AI 基线和评估周期，再验证任务成功增量、完整成本、失败代价与回退路径。
展开原理与工程取舍FORMULA · TRADE-OFF · FOLLOW-UP
原理拆解
把功能拆成感知、检索、判断、生成和执行，只在确需概率泛化的环节用模型，其余交给确定性代码；这能缩小评测面和错误半径。
NIST AI RMF（AI Risk Management Framework，人工智能风险管理框架）的 Map、Measure、Manage 要落到具体使用上下文、受影响方和不确定性；不能先拿通用榜单分数倒推产品需求。
estimated_net_value_horizon = eligible_tasks·Δsuccess_vs_baseline·value_per_success − inference − review − operations − expected_failure_loss工程取舍
让 AI 覆盖更多步骤可能提高自动化率，却扩大不可预测面；混合工作流增加组件，但能把高风险动作留在规则、权限和人工边界。公式是决策估算，价值、成本、合格任务分母和时间窗口必须同口径。
常见误区
“只要模型足够强，所有软件都应改成对话”错误。用户目标可能更适合按钮、搜索、表单或批处理；自然语言界面本身不等于任务体验改善。
面试官可能继续问
追问：如何判断 Copilot 还是 Autopilot？没有历史标注怎样做基线？若人工流程很慢但错误代价高怎么办？
怎样把“做一个好用的 AI 助手”拆成成功指标、Guardrail 与风险预算？#
先用大白话把它讲明白
“好用”必须落到具体任务：谁在何时提供什么输入，系统允许产出或执行什么，怎样用外部结果确认完成。成功/失败样例是起点，不存在对所有产品通用的固定 20 条门槛。
指标分三层：业务结果如任务完成与返工；过程指标如正确性、引用、延迟和单成功成本；Guardrail（护栏指标）如泄露、越权、严重误导和投诉。各指标要声明合格分母、窗口、切片与数据来源。
平均质量不能抵消严重事故。高影响风险可设独立硬门或风险预算，但“测试中零事故”只说明在该样本量和分布下未观察到，不证明真实概率为零；还要看不确定性、红队覆盖和恢复能力。
我把需求写成 task contract：用户与场景、输入、允许输出/动作、证据、成功判定、拒答和人工接管。指标树由业务结果连接质量、延迟和成本；安全、隐私与越权做不可由均值抵消的独立门禁，并用样本量、切片和不确定性解释风险证据。
展开原理与工程取舍FORMULA · TRADE-OFF · FOLLOW-UP
原理拆解
领先代理指标帮助快速迭代，最终决策仍要回到真实任务结果。例如“回答被复制”可能是采纳，也可能是用户拿去修正，需和完成、返工、投诉及随机抽样对照。
风险分类要记录来源、影响、可检测性和可恢复性。高影响低频事件需要定向场景和红队测试；若要声称风险率低于预算，应预先选定统计方法和置信水平。
gate_pass = primary_target_met ∧ UCB(severe_failure_rate; n, α) ≤ risk_budget工程取舍
强 Guardrail 降低严重风险，也可能提高拒答和人工转接；指标越多越全面，但没有主指标、估计量和决策规则时，团队容易事后挑数。UCB 是风险率上置信界的占位写法，不指定唯一分布模型。
常见误区
“用户点赞率就是产品价值”错误。点赞有选择偏差、易受语气影响，也覆盖不到未反馈用户和隐藏风险；同样，零次严重失败也不等于零风险。
面试官可能继续问
追问：拒答算成功还是失败？如何把客服节省时长换成业务价值？严重风险零样本能把概率上界压到多低？
模型选型与 Build vs Buy 怎么做？为什么不能先看公开榜单第一名？#
先用大白话把它讲明白
公开榜单使用特定题集、提示、评分器和采样设置，与你的语言、文档、工具、延迟和风险未必同分布。它适合缩小候选，不替代自有任务 Eval。
候选不是孤立模型，而是一份完整 release manifest：模型版本、Prompt、检索资料、工具、策略、结构化输出和 Guardrail。小模型加可靠检索可能胜过大模型裸答，反之也需实测。
Buy 通常减少前期训练和基础设施工作、上线快，但受价格、限额、数据条款和版本变更影响；自托管可增强部署控制，却要承担容量、Serving、评测、安全和 on-call。不存在只按请求量就能回答的通用盈亏平衡点。
先用自有场景、关键切片和风险门禁建 Eval，再在同一 workload 上比较完整 manifest 的质量、P95、容量、单验证成功成本、隐私和迁移性。Build vs Buy 看总拥有成本、交付速度、差异化、数据边界、团队能力和退出成本；榜单只负责发现候选。
展开原理与工程取舍FORMULA · TRADE-OFF · FOLLOW-UP
原理拆解
先做规则、Prompt 或较小模型基线；只有失败切片证明瓶颈确在模型能力时再升级，否则更大模型可能只是掩盖检索、数据或交互问题。
供应商评估还要覆盖地域、限流、版本生命周期、数据保留、SLA、审计和 fallback。切换 provider 后输出、工具调用与拒答语义可能改变，不能沿用旧 Eval 结论。
cost_per_verified_success_horizon = (usage + retrieval + allocated_infra + review + operations + failure_rework) / verified_successful_eligible_tasks工程取舍
多供应商路由降低单点与锁定风险，却增加行为差异、评测矩阵和合规面；单一平台开发快，但要钉住版本并准备退出。分子、成功分母和摊销周期必须同口径。
常见误区
“开源权重免费，所以自托管成本接近零”错误。硬件、峰值余量、工程、监控、安全、升级与事故成本不会因权重许可免费而消失。
面试官可能继续问
追问：什么 workload 和团队条件下自托管可能划算？怎样做 provider fallback 又不破坏体验？最好模型即将下线怎么办？
评测集是产品需求的可执行版本，不是随手攒的一百个问题
让每个分数可追溯到场景、Rubric、数据版本和评审证据；均值之外必须看切片与失败类型。
怎样构造一个可信的评测集？Golden、生产样本、难例和切片怎么配？#
先用大白话把它讲明白
Golden case 是专家确认过输入、可接受结果和评分规则的参考样本；开放任务可能有多个有效答案，不应硬造唯一字符串。生产样本贴近曝光分布，却含隐私、旧系统选择偏差和不完整反馈；难例补高风险与长尾。
从 task contract 建用户、任务、语言、长度、数据质量和风险场景矩阵，再分层抽样。每条 case 记录来源、许可、时间、版本、Rubric、参考证据和潜在训练污染。
固定回归集保证跨版本可比，滚动挑战集吸收新失败；开发集与最终盲测隔离。Agent case 还要固定初始环境、可用工具和权威完成状态，并验证任务确实可解。
从任务契约建立场景矩阵，组合专家参考 case、脱敏生产样本和边界/对抗难例，再按关键切片分层抽样。每条 case 版本化来源、有效结果、Rubric 和风险；保留固定回归集与滚动挑战集，开发和盲测隔离，报告均值、切片和不确定性。
展开原理与工程取舍FORMULA · TRADE-OFF · FOLLOW-UP
原理拆解
样本单位要与用户任务一致：多轮客服不能只拆成独立单轮；Agent 要保存初始环境并从权威最终状态判成功，不能只信轨迹末尾“已完成”的文字。
生成有随机性，同一 case 应按风险和方差设计多次 trial；比较候选宜用配对 case。多次采样估计的是给定配置下的表现分布，不会自动修复坏任务或坏 grader。
overall_score = Σ_s w_s·score_s；另报 critical_slice、severe_failure 与 trial uncertainty工程取舍
按生产频率加权贴近总体价值，却会稀释稀有高风险；均匀覆盖切片便于诊断，却不代表线上分布。固定集保证可比，滚动集提高时效，两套成绩单都要保留。
常见误区
“随机抽 100 条线上日志就足够客观”错误。低频事故可能缺席，历史日志还会继承旧产品曝光、用户选择和标签缺失偏差。
面试官可能继续问
追问：Eval 被 Prompt 工程师看过后还算盲测吗？开放任务怎样定义多个有效结果？Agent case 如何验证可解？
Exact Match、规则评分、LLM Judge 与人工评审怎样组合？#
先用大白话把它讲明白
可确定的先用代码评分：JSON Schema、数值范围、工具参数、引用 ID、单元测试和 Exact Match。它便宜稳定，但只覆盖写入规则的性质，不能把“格式通过”当语义正确。
开放写作或复杂语义可用维度化 Rubric 的 LLM Judge 扩大覆盖，但它会受措辞、顺序、长度、知识和候选分布影响；Agent 的“完成”优先由数据库、文件、测试或环境状态判定。
人工用于建立和复核参考标签、校准 Judge、处理高风险和分歧。人工也会不一致，需领域资格、盲评、分档示例、重叠标注和仲裁，不存在天然无误的“最高质量”标签。
评分按可验证性分层：结构、业务规则与最终环境结果用代码/执行测试；开放语义用清晰 Rubric 的 Judge；合格人工建立校准集并仲裁高风险或分歧。保留每维判断、可核验依据和 grader 版本，不把目标压成一个不可解释总分。
展开原理与工程取舍FORMULA · TRADE-OFF · FOLLOW-UP
原理拆解
Rubric 要描述可观察标准与分档锚点，例如“哪条证据支持哪项主张”，而不是“回答是否优秀”。可要求 Judge 输出简短判定依据供审计，但不要把隐藏思维过程当作可验证证据。
多轮或 Agent 要区分 outcome（最终结果）与 trajectory（过程）：权限、工具参数、状态变化、恢复路径都可评分，但步骤更少不必然更好，除非它是明确约束。
release_gate = hard_constraints_pass ∧ quality_score≥τ_q ∧ safety_score≥τ_s工程取舍
代码 grader 稳定但覆盖窄；Judge 可扩展却有系统偏差与成本；人工灵活但慢且受标注规范影响。组合能互补，也要求每个 grader、Rubric 和阈值版本化。
常见误区
“LLM Judge 给出 8.7 分就显著优于 8.6”错误。没有量表校准、重复试验与误差区间，小数位只是伪精确。
面试官可能继续问
追问：为什么 pairwise 可能比 absolute 容易？如何从权威状态评 Tool 调用？Judge 依据与分数冲突怎么办？
怎样校准 LLM-as-a-Judge，并控制位置、风格、长度与自偏好？#
先用大白话把它讲明白
Judge 也是模型。交换 A/B 顺序、改成更自信或更长的文风，都可能改变偏好；MT-Bench 论文观察到与自增强相容的信号，但因数据有限和混杂未能确认 self-enhancement bias，更不能把它当普遍定律。
让多名合格人工按同一 Rubric 标注校准集，测原始一致率、严重漏判和关键切片。Pairwise 要交换顺序：先把两次结果映射回候选身份，再比较 A 胜、B 胜或 Tie；两次都 Tie 也属于一致，解析失败另报。
隐藏模型身份，只提供 Rubric 所需证据，并控制或分层报告长度。Judge 模型、Prompt、采样参数、Rubric 和候选分布都要版本化；升级后重校准，而不是把新旧分数直接串成趋势。
用专家校准集测 Judge 与人工一致和错误切片；Pairwise 交换 A/B 顺序，预先定义 Tie，映射回候选身份后计算位置一致性，并另报 decisive coverage 与解析失败。隐藏身份并检查长度、风格和潜在自增强信号；高风险或分歧人工仲裁。
展开原理与工程取舍FORMULA · TRADE-OFF · FOLLOW-UP
原理拆解
总体一致率会被易样本和标签不平衡抬高，应看高风险切片、质量接近区与混淆矩阵。Cohen’s κ 只在标签与独立性设定适合时提供机会校正，仍不替代逐类误差分析。
若同一模型既参与生成又评答案，评测误差可能相关。异源 Judge、确定性证据和随机人工复核能降低单一偏差，但多 Judge 投票也不是事实真值。
position_consistency = consistent_identity_mapped_outcomes / valid_swapped_pairs（A胜 / B胜 / Tie）工程取舍
多 Judge、多次采样或双顺序更稳但更贵；单 Judge 便宜可回归，却不能把模型偏好等同真实用户偏好。Position Consistency 可把“双 Tie”计为一致，所以还要并列报告 decisive coverage、Tie 率和解析失败，防止靠全判 Tie 得高分。
常见误区
“Judge 比被测模型更大，所以判断一定正确”错误。能力规模不保证理解你的领域、Rubric，也不消除位置、冗长或潜在自增强偏差。
面试官可能继续问
追问：Judge 与人工只有 70% 一致能否用于筛选？双 Tie 为什么算位置一致却不代表有判别力？怎样诊断只奖励长回答？
离线更好只是候选，线上价值和可逆性才决定放量
比较完整 pipeline 的 Pareto 前沿；灰度前写清主指标、Guardrail、最小效果与停止规则，异常时能按版本快速回退。
质量、延迟与成本冲突时怎样选模型？什么是 Pareto Frontier？#
先用大白话把它讲明白
一个方案可能更准但慢且贵，另一个足够好且快。只有在同一 workload、统计口径和发布配置下，若 A 的质量不低、延迟不高、成本不高，且至少一项严格更优，才可说 B 被 A 支配。
Pareto Frontier（帕累托前沿）是未被其他候选全面压过的一组方案。先过安全、质量和 SLO 硬门，再按业务价值与预算从前沿选择；不确定性重叠时不要把微小点估计差当确定支配。
成本除以经验证的成功任务，不只算 token 单价：重试、RAG、工具、审核、返工、峰值容量和固定工程成本都进入同一周期总账。分层路由还要计误路由。
先以关键质量、安全和 P95 SLO 淘汰不合格 manifest；对同 workload 的剩余方案画质量、延迟、单验证成功成本及其不确定性。业务价值和风险预算决定前沿上的选择，并单独评 Router 的漏升与误升成本，榜单或 token 单价不能代替这套比较。
展开原理与工程取舍FORMULA · TRADE-OFF · FOLLOW-UP
原理拆解
固定输入/输出分布、输出上限、缓存冷热、并发、区域和评测器；模型输出更长会同时影响主观质量、延迟与成本，应控制或分层报告。
Router 的 false negative（漏升）会把难题留给弱路径，false positive（误升）会浪费成本。路由后还要按实际选择概率重算整体成功率、尾延迟与成本。
cost_per_verified_success = total_variable_and_allocated_fixed_cost / verified_successful_eligible_tasks工程取舍
硬门清晰但阈值附近对噪声敏感；加权总分易排序，却会隐藏不可补偿的安全失败。分层路由可能降成本，也增加一致性、校准和观测负担。
常见误区
“每百万 token 更便宜，所以总成本一定更低”错误。较便宜模型可能输出更长、重试更多、需要更多人工，或让成功分母更小。
面试官可能继续问
追问：置信区间重叠时怎样比较？缓存命中如何进入成本？Router 阈值怎样离线校准再在线验证？
离线评测通过后，怎样设计 Shadow、Canary、A/B 与 Guardrail？#
先用大白话把它讲明白
Shadow（影子流量）复制真实请求但不展示新输出，可测执行、延迟、成本和离线 grader，不能直接估用户行为；工具和外部写操作必须禁用或隔离，不能让“不可见答案”真的下单。Canary（小流量发布）限制新版本影响面，主要用于发现坏发布；Google SRE 也把它视作一种 A/B 比较，但它未必有足够样本证明产品价值。
用于估计业务因果效应的在线对照实验要随机分流。随机化与分析单位应匹配干扰范围，例如按用户或会话而非逐消息；还要先查 SRM（Sample Ratio Mismatch，样本比例失配）、曝光/日志完整性和聚类方差。
实验前声明主指标、Guardrail、实际值得上线的效果阈值 δ_ship、MDE（Minimum Detectable Effect，最小可检测效应）、样本量、周期和停止规则。MDE 用于功效与样本设计，不是观察结果的上线门槛。
按隔离副作用的 Shadow、内部白名单、小比例 Canary、随机对照实验和逐步放量推进。预注册随机化单位、估计量、δ_ship、Guardrail、MDE/样本量和停止规则；先过 SRM 等完整性检查，再用与随机化匹配的方差和置信区间判断。硬风险或 SLO 破坏立即 kill/rollback。
展开原理与工程取舍FORMULA · TRADE-OFF · FOLLOW-UP
原理拆解
Canary 与产品 A/B 可共享分流技术，但目标不同：前者先限制坏发布爆炸半径并看绝对 SLO，后者在可识别假设下估计因果效应；可串联，不能把小样本无事故当价值证明。
同一用户多次交互通常相关，逐消息当独立样本会低估不确定性。若存在用户间干扰、网络效应或跨端曝光，还要调整随机化设计与分析，不能只在报表末尾“聚类一下”。
ship ⇐ LCB(Δprimary) ≥ δ_ship ∧ guardrails_pass ∧ experiment_integrity_pass工程取舍
更慢放量降低风险但延迟价值；Shadow 不影响用户却测不到交互适应；自动 kill switch 保护系统，也可能被短窗噪声误触发，需明确窗口、最低信息量和紧急硬门。LCB 是预声明置信水平下的下界；非劣实验需另写方向。
常见误区
“Δprimary 超过 MDE 就该上线”错误。MDE 是实验在给定功效下计划检测的效应，实际决策还要看效应区间、实际业务阈值、Guardrail 和实验完整性。
面试官可能继续问
追问：为什么 Shadow 必须隔离写操作？SRM 通过后还可能有哪些偏差？Canary 与产品 A/B 的流量能否复用？
模型、Prompt、知识库和工具都在变，怎样做版本管理与一键回滚？#
先用大白话把它讲明白
一次结果由模型/Adapter、Tokenizer、System Prompt、检索资料与索引、工具 Schema、策略、代码、采样和外部观察共同决定。只记录模型名不足以诊断事故。
发布创建不可变 manifest，把可控制版本与 Eval report 绑定；流量指针按 manifest 灰度，异常原子切回已验证版本。输入内容和外部观察要保存受治理的快照引用或事件版本；哈希只能校验身份/完整性，不能还原未保存内容。
模型路由回滚不会撤销已发邮件、订单或数据库变更。外部副作用需要幂等账本、审批、状态对账和补偿；数据迁移还要向后兼容。闭源供应商和并行数值可能让精确逐字重放本来就不可达。
把发布单元做成不可变 manifest：模型、Tokenizer、Prompt、corpus/index、tool schema、policy、code、grader 与 Eval report。日志引用输入和外部状态快照并记录采样/运行时元数据；故障时切回已验证 manifest。目标是可审计和行为诊断，外部副作用另靠幂等、对账与补偿。
展开原理与工程取舍FORMULA · TRADE-OFF · FOLLOW-UP
原理拆解
评测只对实际测试的 manifest 与数据/grader 版本有效。知识库、Judge 或托管模型静默变化后，旧分数不能自动代表新系统。
滚动发布中，新旧 worker 会共存，请求状态、工具参数和 cache key 要有版本边界。对不可控外部依赖，记录供应商公开版本、请求 ID、时间和可观察响应，并诚实标注无法逐字复现。
replay_record = {input_snapshot_ref, release_manifest_id, external_snapshot_refs, sampling_and_runtime_metadata}工程取舍
保留快照与事件能提升审计和复现能力，却增加存储、隐私、版权和治理成本；只留哈希暴露更少，但仅能验证已有内容是否相同，不能重建内容。应按风险分级留存。
常见误区
“temperature=0 加一个 hash 就能完全重放”错误。哈希不是快照，底层实现、并行数值、检索排序、外部工具和供应商版本变化仍可能改变结果。
面试官可能继续问
追问：知识库太大怎样做内容寻址快照？供应商不暴露权重版本怎么办？Prompt 热修复是否可以跳过 Eval？
用客服与 Agent 两个案例，把证据、权限和线上反馈落到细节
案例题要给出输入、状态、门禁和失败恢复，不要只说“接 RAG”“加人工审核”。
案例：设计一个企业客服 RAG，怎样同时评检索、回答、引用与转人工？#
先用大白话把它讲明白
先按产品、地区、版本、有效期和访问控制治理文档。授权必须在任何候选证据进入模型上下文前生效，并对最终引用再校验；不能先把越权片段喂给模型再隐藏链接。
评测拆层：检索看关键证据是否进入 top-k；MRR 只强调首个相关结果，多个分级相关结果可用 nDCG。生成另看事实/任务正确性、是否忠于给定证据，以及 citation correctness（每条引用是否支持所附主张）与 completeness（回答中需要引用的关键主张是否都有支持）。
证据不足、高风险承诺、连续失败或情绪升级时转人工。转接包只携带用户有权查看的已核验事实、引用和尝试步骤；最终 resolution 要用工单重开、权威业务状态或人工确认，而非模型自报。
客服 RAG 先做有权限、版本和时效的知识治理，再分评证据召回/排序、答案任务正确性、对证据的 faithfulness、引用正确性与完整性。低证据、高风险或多轮失败转人工；线上监控重开后的解决率、过期引用、越权、P95 和单验证解决成本。
展开原理与工程取舍FORMULA · TRADE-OFF · FOLLOW-UP
原理拆解
用 2×2 归因：检索证据充分/不足 × 回答忠于/不忠于证据。证据充分却答错归生成或策略，证据不足却强答归拒答门禁；“忠于错误或过期资料”仍可能事实错误，faithfulness 不等于外部正确性。
引用存在不等于支持，支持一条次要句也不等于关键主张完整覆盖。保留 claim、citation、文档 ID/版本/chunk，并用 entailment grader 与人工样本校准。
citation_correctness = supported_citations / evaluated_citations；citation_completeness = claims_with_supporting_citation / claims_requiring_citation工程取舍
提高 top-k 可能改善召回，也会增加噪声、延迟与泄露面；强制关键事实引用提高审计性，但闲聊不必伪造引用。转人工保安全却增加运营成本，需单独看最终解决和重开。
常见误区
“RAGAS faithfulness 高就说明回答事实正确”错误。它关注回答是否由给定上下文支持；上下文若错误、过期或越权，忠实回答仍不一定正确或安全。
面试官可能继续问
追问：旧会话引用遇到文档更新怎么办？多轮问题怎样定义 case？ACL 应在检索前、重排前还是生成前强制？
案例：设计一个能发邮件/下单的 Agent，怎样做审批、权限、幂等和最终状态验证？#
先用大白话把它讲明白
模型先生成类型化提案，不直接拥有权限。服务端独立做身份认证、对象级授权、Schema 和业务策略校验；高风险预览绑定规范化后的收件人/商品、金额、内容摘要、调用者、版本与过期时间。审批只确认这次参数，不会替代授权。
写操作先以 idempotency key 和 request fingerprint 原子创建 pending 账本，只有成功创建者可以 dispatch。同 key、同 fingerprint 返回原结果或进行中状态；同 key、不同参数必须冲突，不能把旧批准挪给新请求。
网络超时代表结果未知，不等于失败。先用业务 ID 查询供应商或权威数据库并对账，再决定等待、返回原收据或重试；模型文字和工具自然语言都不是完成证明。Saga 只能补偿明确定义的可逆步骤，不能撤回已读邮件或已消费商品。
写操作走“模型提案→服务端认证/授权/策略→参数绑定审批→原子 pending 账本→唯一 owner dispatch→权威状态对账”。同 key 同 fingerprint 复用状态，同 key 异参数冲突；超时先查真实结果再决定重试。审计记录 manifest、规范化参数、批准者、执行 owner、收据和最终状态。
展开原理与工程取舍FORMULA · TRADE-OFF · FOLLOW-UP
原理拆解
Prompt 或结构化 tool call 都只是提案。即使用户点过确认，服务端仍需验证当前身份、对象权限、额度和政策；审批 token 必须短期、单次并绑定 exact fingerprint。
幂等去重不能创造“恰好一次”网络语义：第一次可能已执行但响应丢失。账本状态至少区分 pending、dispatched、succeeded、failed 与 unknown，unknown 必须对账而非盲重放。
dispatch = authn ∧ authz ∧ schema_valid ∧ policy_pass ∧ approval_matches_fingerprint ∧ created_pending_atomically工程取舍
逐次确认最安全但打断体验，可按金额、域、可逆性和信任分级；更强自治提高完成率，也扩大错误半径。账本与对账增加延迟和状态复杂度，却是副作用安全的必要成本。
常见误区
“用户一开始授权 Agent 办事，加上 idempotency key，就可以安全重试任何动作”错误。授权有对象和时效边界；key 需绑定参数，超时还要从权威系统判断第一次是否已生效。
面试官可能继续问
追问：工具超时但订单其实已创建怎么办？哪个事务决定唯一 dispatch owner？多个工具部分成功时哪些步骤真的可补偿？
上线后怎样监控质量漂移、成本异常和新失败，并把它们回流下一轮 Eval？#
先用大白话把它讲明白
线上通常没有即时真值，所以同时看任务完成/采纳、重问、转人工、返工、投诉、拒答、工具失败和引用点击等代理信号，并用延迟到达的权威结果或随机人工抽样校准。代理变化不等于质量变化。
漂移要拆开：输入/用户组合变了是 data drift，模型/Prompt/索引/策略变了是 release/config drift，任务结果变差才是 outcome/quality drift。按 manifest、场景、语言和风险切片，避免全局均值遮住局部事故。
异常样本经最小化、脱敏、去重和归因后进入滚动 challenge set；同时保留冻结回归集，才能区分“新难例越来越多”与“同一基准真实退化”。修复要同时通过旧回归、新切片和灰度。
线上把业务结果与代理信号、严重风险、P95/错误和单验证成功成本按 manifest 与场景切片；分开诊断输入、配置和结果漂移。用随机抽样人工或已校准 grader 做质量哨兵，失败经治理后进入滚动挑战集，但固定回归集保持可比，再按门禁灰度。
展开原理与工程取舍FORMULA · TRADE-OFF · FOLLOW-UP
原理拆解
基础运行监控覆盖 latency、traffic、errors、saturation 四个黄金信号，再加 token、finish reason、拒答、引用、工具和任务 outcome。OpenTelemetry GenAI semantic conventions 截至核查日仍标 Development，字段变化需钉版本。
用户反馈有选择和曝光偏差：极满意或极不满者更愿评价，重问也可能是正常探索。训练、告警和产品决策都不能把每条点击或差评直接当独立真值。
unit_economics = total_online_cost / verified_successes；alert by manifest × slice, not only global mean工程取舍
提高人工抽检可更早发现语义失败，却增加成本与隐私接触；自动 Judge 可扩规模但会漂移。日志越完整越利于诊断，也越需要最小留存、访问控制和删除策略。
常见误区
“挑战集持续加新失败后总分下降，说明线上模型退化”错误。题集难度本身在变；趋势比较要看固定 cohort，滚动集负责暴露新风险而不是直接画连续分数线。
面试官可能继续问
追问：没有即时标签怎样校准代理信号？供应商静默更新如何发现？固定集多久刷新又不破坏可比性？