AI 工程纵深：理论 · 前沿 · 规模化生产

这道题考察的是对 「Agent = Model + Harness」二分模型的第一性认知。核心不在复述「Agent 是能自主干活的 AI」，而在回答：模型（Model）与驾驭环境（Harness）的职责边界在哪？为什么「模型决定能力天花板，Harness 决定能否落地生产」？能否用工程证据（模型不变、Harness 换血带来得分跃迁）支撑这一判断。这是 Agent 工程化的认知地基题。

瓶颈外移的演进线：提示词工程（说清指令）→ Function Calling（接上工具）→ ReAct 单体 Agent（边想边做）→ Context Engineering（喂对信息）→ Harness Engineering（系统级驾驭环境）。模型每强一截，工程瓶颈就向模型外迁移一层——最终矛盾落在「包裹模型的整套运行环境」上。

两条标志性工程证据（模型均未更换）：其一，仅替换文件编辑接口（Harness 的一层），同一模型在编码类评测上的得分出现数倍级跃升；其二，仅优化文档组织、验证机制与执行追踪，同一模型在终端类基准上的排名大幅前移。均为社区转述的个案，具体基准与数值需核实。这说明 Harness 与模型是强耦合的：模型在自带的 Harness 中表现更强，换 Harness 可能反而下降，选型必须以「任务工具 / 约束 / 验证方式」为准，而非默认模型自带环境。

从 LLM 四大弊端推导 Agent 全部组件——这是理解 Agent 架构的第一性路径：

• 只会说不会做 → 工具调用（Function Call / MCP 接入外部能力）；
• 没有记忆 → 记忆系统（短期上下文 + 长期外部存储）；
• 不会规划 → 规划模块（任务拆解 / ReAct / Plan-and-Execute）；
• 不可控不可观测 → Harness 约束层（边界、校验、恢复、审计）。

由此得到四组件结构：大脑（LLM 推理决策）+ 规划模块 + 记忆模块 + 工具模块，外加统一驾驭它们的 Harness。最小定义可记为：Agent = LLM 在循环中自主使用工具的系统——LLM 负责「想」，Harness 负责「做完、做对、做稳」。

Harness 六层框架（分析框架而非协议）：

建设优先级：先补 L1 + L6（明确信息边界 + 越权 / 失败的拦截恢复），再随多步骤、中间产物、验证需求补 L2–L5。落地抓手：维护 AGENTS.md（每行对应一个历史失败案例，约 100 行当目录、细节子文档按需加载）；自定义 Linter + 修复指令把架构约束机械化执行（无法机械化执行的约束，Agent 必然偏离）；团队知识进仓库而非散落聊天工具。

• 为什么瓶颈常在模型外？因为模型只是输入输出函数——不会存历史、跑命令、知道测试是否通过、区分该留该丢；这些全是 Harness 的职责。能力上限由模型决定，但生产可用性由 Harness 决定。
• 「上下文越多越蠢」怎么理解？某 168K 窗口模型在用量约 40% 后质量开始下降（Smart/Dumb Zone）——这是特定模型任务的观察值，并非普适阈值；正确做法是监控上下文利用率并自建评测确定压缩 / 交接阈值，而非背一个数字。
• 成熟度怎么分级？Level 0 无 Harness → L1 基础约束（规约文件 + Linter + 手动测试）→ L2 反馈回路（CI/CD + 自动化测试 + 进度追踪）→ L3 专业化 Agent（分工 + 分层上下文 + 持久记忆）→ L4 自治循环（无人值守 + 并行 + 自修复）。
• Harness 为什么是控制面而非框架？模型是执行单元，Harness 是资源与权限的仲裁者：它决定谁能读什么、哪一步可以写、失败后能否重试、哪条路径需要人工终审。把这些横切关注点散落在各业务服务里，等于让每个服务各自实现一遍概率性组件的安全外壳，版本必然漂移；收敛到统一控制面后，权限、知识、人机、观测、组织五类约束才有单一判定点与单一可审计记录。

• 把 Agent 等同于「提示词 + while 循环」：缺 L1 边界与 L6 恢复层，长链路一遇异常即失控；正确顺序是先边界与恢复、再编排与验证。
• 只堆模型不建 Harness：换更强的模型掩盖不了环境缺陷，且 model-harness 耦合意味着盲换环境可能让效果下降。
• 约束停留在文档里：无法机械化执行的规约对 Agent 无效，必须下沉为 Linter / 结构测试 / Hook。
• 把观察值当定律：上下文利用率阈值、少样本数量等均为经验值，需用自有评测集验证，禁止直接照搬。

这道题考察的是 Agent 核心范式谱系的体系化理解：ReAct、Plan-and-Execute、Reflection、Multi-Agent（再加自主 Agent 范式）各自的机制、适用场景与代价是什么？能否给出「从最简单方案起步、明确需要才加复杂度」的选型纪律，并说明生产中为何多为混合架构。范式不清会导致选型时「杀鸡用牛刀」或「拿锤子找钉子」。

谱系从受控到自主依次展开：ReAct（2022，推理与行动交错的「边想边做」）→ Plan-and-Execute（先出完整计划再逐步执行，把「想」与「做」解耦）→ Reflection（产出后自查或双 Agent 互审，形成质量闭环）→ Multi-Agent（多角色分工协作）→ 自主 Agent 范式（以 AutoGPT 为参照：用户只给目标，Agent 递归自建计划、自调工具、自修订，长链自驱直到完成）。前四者本质都是「Harness 约束下的受控执行」，自主范式则把「目标」直接交给模型——自主性、不确定性、成本与安全风险同时到达最高点。

四种范式的分野在「谁在何时做决策、决策范围多大」：

自主范式的工程特征需特别记忆：目标驱动而非流程驱动；长链路自循环必须设最大步数 / 预算上限 / 人工介入节点；工具自调度必须配沙箱与权限收窄；长任务需状态持久化与中断续跑。

选型纪律（生产口径）：

• 从最简单方案起步：先 Workflow / 单 Agent，验证确实不够再升级范式；自主性每升一级，不确定性、成本、安全风险同步上升。
• 多数生产系统是混合架构：如客服场景，Workflow 控制主流程（身份核验 → 工单分类 → 路由），只在「复杂诉求理解」等少数环节起 Agent；自主 Agent 仅用于目标明确、结果可校验的开放任务（如调研报告）。
• 稳定性治理三板斧：最大步数、回退、人工确认——路径震荡与死循环是 ReAct 类范式的常态而非意外。
• 执行方差治理：同输入多次执行结果不一致是模型本性，需靠上下文工程压输入噪声 + 评估闭环压输出方差（见 A06.02），而非指望模型「下次稳定」。
• 单 / 多 Agent 判定：任务边界清晰、子任务可并行 → 多 Agent；否则单 Agent + 强 Harness 更稳。

• 为什么 Plan-and-Execute 难应对突发？计划在执行前冻结，突发信息（工具失败、需求变更）需要重规划；改进方向是「重规划节点」（执行若干步后重新评估剩余计划），本质是把部分决策权还给模型。
• Reflection 与 Evaluator-Optimizer 的关系？前者是单 Agent 自查（省一次上下文交接），后者是生成者与评审者分离的双角色循环（评审上下文更干净、更挑剔）；质量敏感任务优先双角色，代价是延迟翻倍。
• 自主 Agent 与 Workflow 的控制权对比？Workflow 代码预定义路径（确定性高、可复现、成本约 Agent 的 1/4）；自主 Agent 模型全权自驱（人类仅设边界 / 预算 / 审批）。两者不是替代关系，而是控制权连续谱的两端。

• 一上来就 Multi-Agent：单 Agent 能在可接受成本 / 延迟内完成的任务，拆多 Agent 只会平添调度、上下文交付、结果归并与故障恢复的工作量。
• 自主 Agent 不设预算护栏：无最大步数 / Token 预算 / 人工介入节点的自循环极易失控烧钱，必须作为上线前置条件。
• 混淆「范式能力」与「任务需要」：范式越强不等于效果越好；先确保单点稳定（模型 + 工具 + 校验），再谈编排升级。
• 把 ReAct 的不确定当缺陷去「修」：动态决策类任务的不确定性是特性，治理手段是护栏与评测，而非强行固定路径（那会退化回 Workflow）。

这道题考察的是 Workflow 与自主 Agent 的边界判定与成本核算：两者的本质区别（谁控制流程）是什么？「Token 成本约 1:4」从何而来？生产落地为什么是「Workflow 为主、Agent 择优叠加」而非全量 Agent 化？能否给出可执行的判定清单（什么场景必须 Agent、什么场景坚持 Workflow）。这是 AI 应用架构选型的最高频决策点。

从「全 Agent 化」幻梦到「混合架构」共识：早期实践（AutoGPT 一类）追求全自主，随即暴露成本失控、路径震荡、不可复现三大问题；Anthropic 等一线实践随后确立「从最简单方案起步」原则——Workflow 覆盖多数确定性场景，Agent 只在动态决策环节叠加。平台侧同步进化：主流低代码 AI 平台普遍提供「Workflow 编排为主体 + Agent 节点」的形态，自主 Agent 退守开放型长任务（各平台具体能力边界需按版本核实）。

核心区别：控制权归属。Workflow 的流程由代码预定义（确定性高、可复现、易调试）；Agent 的流程由模型动态主导（灵活但不确定）。由控制权差异派生全表：

1:4 成本比的机理：Agent 每一步决策都要携带完整上下文调用模型（系统提示 + 历史 + 工具结果），且存在重试与反思开销；Workflow 仅在固定节点调用模型、其余环节为纯代码，调用次数与单次上下文体量均显著更小。该比值是同类任务实测的量级参考，随任务长度与工具轮次变化，不可当固定常数。

1:4 判定清单（逐条过，命中越多越倾向 Workflow）：

• 流程能否画成有限状态图且分支条件可代码表达？→ 能则 Workflow。
• 每次执行是否要求结果可复现、可审计（支付、退款、合规操作）？→ 是则 Workflow + 确定性节点。
• 是否存在「必须理解非结构化输入才能决定下一步」的语义分支？→ 该分支交给模型（Agent / 模型决策边），其余仍 Workflow。
• Token 预算 / 延迟 SLA 是否紧张？→ 紧张则压缩 Agent 使用面，用缓存与裁剪上下文兜底。
• 失败后的补偿是否复杂（外部副作用）？→ 复杂则倾向 Workflow（便于挂补偿与人工节点）。

落地形态：客服系统 = Workflow 主干 + 意图理解 Agent 节点；数据研发 = 固定 ETL 流 + 故障诊断 Agent；研发工具链 = CI 流水线（确定性）+ 修复 Agent（受限循环，最大轮次 + 超时 + 预算强制退出）。

• 混合架构的接缝在哪？在「节点粒度」：Workflow 的一个节点可以是 Agent（受控循环），Agent 的一个工具调用可以触发 Workflow（确定性子流程）；关键是把决策点与执行点分离，决策交给模型、执行交给代码。
• 1:4 是恒定比例吗？不是。它是「同类任务、相同质量目标」下的量级参考；若 Workflow 需要为每个分支写大量兜底代码，其研发成本可能超过 Agent 化——所以成本核算要同时算 Token 成本与研发维护成本。
• 什么场景必须自主 Agent？目标清晰但路径无法枚举的开放任务（深度调研、跨系统排障）；且必须配「预算 + 沙箱 + 审计 + 人工确认」四件套。

• 把「智能」等同于「自主」：为演示效果把支付审批做成自主 Agent，结果不可复现、无法审计；生产第一原则是确定性优先。
• 只比 Token 成本不比总成本：忽略研发、调试、回归评测的隐性成本；Workflow 的代码分支膨胀同样是成本黑洞。
• Agent 环节没有护栏就上线：最大步数、超时、Token 预算、人工确认节点缺一不可，否则单次故障即可烧穿预算。
• 用「能否做」替代「该不该做」：模型能力上确实能自主完成多数流程，但工程选型问的是「是否值得承担不确定性代价」。

这道题考察的是 上下文工程（Context Engineering）的定义层级与 Context Assembler 组装范式：它比提示词工程管得更大——决定「这轮调用前窗口里放什么、怎么放、何时进出」。核心是能否讲清统一组装顺序（约束 → 目标 → 证据 → 记忆 → 工具 → 历史）、rank 与 Token 预算两步走，以及为什么「窗口越大 ≠ Agent 越聪明」。这是从「调 Prompt」升级到「设计信息供给系统」的分水岭题。

定义演进：Prompt Engineering（怎么说清一句话）→ Context Engineering（为任务提供恰好可解的全部上下文的艺术）→ Harness Engineering（系统持续执行与纠偏）。类比操作系统：Prompt 是用户命令，Context 是内存管理——页面置换、LRU、优先级淘汰，管理的是「有限窗口内的信息供给」。模型窗口从 8K → 128K → 1M+ 的扩张并未消灭该领域，反而因「长上下文贵、慢、易噪声」使精准供给的价值更高。

Context Assembler：每次调用前统一组装。组装顺序固定：约束 → 目标 → 证据（RAG）→ 记忆 → 工具 → 历史摘要；随后两步走：rank（决定信息排列顺序）+ fit_token_budget（决定每条信息保留原文、压缩摘要还是仅留引用）。跳过这两步，窗口一半是噪声——而噪声不是「浪费」，是主动干扰（Context Rot：噪声增多后关键证据利用率不稳定）。

Token 预算四级优先：低优先（早期历史 → 压摘要）/ 中优先（背景资料、旧工具结果 → 裁剪，留核心段 + 可回查引用）/ 高优先（系统约束、当前目标、安全边界 → 固定区不动）/ 阶段性内容（当前阶段工具描述与示例 → 用完卸载，可再发现）。角色与格式要求放输入两端，规避 Lost in the Middle（首尾敏感、中间易漏）。

• 运行时加载三策略：预检索（调用前按相似度取回一次性放入，适合 FAQ、稳定文档审阅）；按需加载 JIT / 渐进披露（先留轻量引用——路径 / 查询 / 链接，需要时再读，适合代码库分析、故障排查）；混合策略为生产主流（确定性高的静态知识预检索，运行中动态发现的信息按需拉取）。
• 长任务三法：Compaction（接近窗口上限时压缩历史为摘要，保留架构决策 / 未解决 Bug / 关键实现，清除冗余工具结果）；Structured Note-taking（进展写外部文件如 NOTES.md，上下文重置后读取续做）；Sub-agent（独立上下文执行检索 / 阅读，主 Agent 只收约 1–2K Token 摘要）。
• 工具上下文：工具描述必须回答「何时该调 / 何时不该调」，单一操作拆出并给格式示例。
• 排障信息必留原始引用：traceId、时间、错误码、日志位置、参数与结果摘要链接——压缩后仍可回查。
• 评估指标：任务成功率、工具质量（错选 / 漏调 / 参数错）、上下文成本（输入输出 Token、缓存命中、压缩保留比）、延迟（TTFT / p95 / p99）、结果质量（幻觉率 / 引用准确率）。先建 20–50 条真实轨迹小评测集，每次只改一个变量。

• 黄金法则：do the simplest thing that works——先固定高优指令与工具边界，验证 RAG 有效，再加摘要与预算控制，最后才上记忆层 / Sub-agent；顺序颠倒会让组件互相掩盖故障源。
• 静态规则的 Goldilocks zone：系统提示拆角色 / 目标 / 约束 / 执行流 / 输出格式，按作用域落文件（如 AGENTS.md）；过度设计（长而脆）与过度抽象（无决策依据）都要避开，落在「具体能引导、抽象能覆盖」区间。
• 与记忆系统的边界：Context 管本轮窗口内的供给与淘汰，Memory 管跨会话的沉淀与取回；两者在组装顺序里是相邻两级（证据 → 记忆），工程上常共享同一套 rank / budget 机制。

• 把 RAG 结果一股脑塞进窗口：无 rank 无预算，噪声淹没证据，效果反而低于精排 Top-5；正确姿势是「先检索 50–100 候选，重排后取 Top-5/10 再入窗口」。
• 压缩时丢掉安全边界：摘要只留「结论」丢掉「约束与引用」，导致后续轮次越权或幻觉；系统约束与安全边界必须固定区保留。
• 工具结果原文常驻窗口：旧工具结果应裁剪为引用 + 摘要，否则多轮后窗口被历史占满。
• 迷信大窗口：长上下文贵、慢、Lost in the Middle，且权限隔离仍需应用层——窗口扩大不解决任何治理问题。

术语对齐：本卡的上下文拼装、裁剪与预算管理，在 2026 年岗位描述里通常写作 Context Engineering；检索片段排序优化对应 Re-rank（另见 A09.02）。两者是同一套工程能力的两种叫法，检索时可用英文原词定位。

这道题考察的是 Context Rot（上下文腐化）的机理与治理：为什么窗口里塞得越多、模型对关键证据的利用越不稳定？退化信号有哪些（任务成功率下滑、工具错选率上升）？压缩策略（滑动窗口 / 摘要 / 卸载 / 隔离）各自适用边界是什么？能否给出「压缩阈值如何用自有评测确定」的可执行答案，而非背诵一个普适百分比。

问题随窗口扩张而显形：早期 4K/8K 窗口时代，历史管理靠「截断」；窗口进入 128K+ 后，团队倾向「能塞就塞」，随即观察到「塞得越多、效果越差」的悖论——Smart/Dumb Zone（某 168K 窗口模型用量约 40% 后质量下降，特定模型任务的观察值）。一线实践随之收敛出两条路线：压缩保留（Compaction）与 上下文重置（context resets：清空窗口 + 结构化交接文档保留关键状态，治理「上下文焦虑」）。

Context Rot 的三重机理：① 注意力稀释——窗口内 token 越多，单条关键证据分到的注意力越少；② 位置敏感——Lost in the Middle 使中间信息易被忽略；③ 语义干扰——过期工具结果、重复内容与当前任务争夺「解释权」，模型可能引用错误版本的信息。对策的统一原理：删重复、把约束放明确位置、长文档先切分 / 检索 / 摘要并保留可回查引用——即「少而准 + 可追溯」，而非「多而全」。

短期记忆控制：缩减 / 卸载 / 隔离三法与通用压缩策略同源，机制与适用条件见 A02.01，本卡不再重复展开。

压缩执行要点：保留架构决策、未解决 Bug、关键实现；清理已完成工具结果（保留 tool_use、清除 tool_result）；压缩触发阈值不照搬他人数字——监控上下文利用率，用自有评测集实测「压缩点前后质量曲线」确定。大规模并发下配套 Prompt / Context Caching 降首 Token 延迟。

• 如何量化「腐化程度」？固定任务集在窗口利用率 20%/40%/60%/80% 分档重放，观测任务成功率与幻觉率拐点——拐点即该模型该任务的压缩阈值；不同模型、不同任务拐点不同，故无普适数字。
• 压缩与重置如何选？连续协作（上下文强相关）选压缩；阶段切换（任务已完结）选重置 + 结构化交接文档（保留目标、已决策、未解决问题）。
• 为什么「清理已完成工具结果」安全？因为工具调用记录（tool_use）保留了「做过什么」的证据链，清除的只是占空间的返回体（tool_result），需要时可凭引用重查。
• 系统硬约束为什么必须排除在摘要压缩之外？压缩是对历史信息的损耗型重写，而权限边界、拒答规则、允许的工具集合属于不可协商的前置条件；一旦被压成自然语言摘要，就从结构化约束退化为可被后续上下文争夺解释权的普通文本。工程做法是把硬约束放在消息组装的固定槽位，由代码注入而非由模型生成；压缩器只处理会话历史与工具结果，且压缩前后都要断言硬约束槽位逐字未变。

• 把「某模型 40% 阈值」当通用定律：观察值非普适阈值，换模型 / 换任务必须重测。
• 压缩把「未解决问题」一起压没：摘要必须显式保留未解决项与下一步，否则 Agent「忘事」后原地打转。
• 卸载引用无超时无上限：外部存储读取不设限，长任务后期变成 IO 灾难；引用必须带 TTL 与大小上限。
• 只压不评：压缩策略变更后不跑回归集，等于盲改生产配置——每次只改一个变量并重放评测。

这道题考察的是 记忆工程的分层模型、生命周期与存储三态：短期 / 长期如何二分？事实 / 经验 / 工作（再分情景 / 语义 / 程序）记忆如何归类？「编码 → 存储 → 提取 → 巩固 → 反思 → 遗忘」生命周期各环节的工程实现是什么？主流方案（Mem0 / Letta-MemGPT / Zep-Graphiti）的选型判据与边界是什么？以及长期记忆与 RAG 的边界——技术相似（都是向量检索），职责为何必须分开。这是 Agent 系统「越用越懂你」的架构题。

从「对话历史」到「记忆系统」：早期仅滑动窗口存对话；随后向量库存语义片段；再演进到产品化分层——Mem0（以 ADD 为主，支持 ADD / UPDATE / DELETE / NOOP 的抽取式写入 + 多信号融合检索）、Letta/MemGPT（OS 式虚拟内存分页，Main↔External 动态交换）、Zep（时间感知三层子图 + 边失效）、MemOS（记忆立方体：纯文本 ↔ 激活记忆 KV Cache ↔ 参数记忆 LoRA 动态流转）。三条产品化路线的分歧本质是记忆管理复杂度放在哪里：平台侧（Mem0 全包）、Agent 侧（Letta 自管）、数据模型侧（Zep 时序图谱）。演进主线：从「存取文本」走向「管理有生命周期的知识资产」。

三个坐标轴定位任意记忆方案：

• 时间轴：短期记忆（Session 级，服务当前任务）vs 长期记忆（跨 Session，沉淀偏好与决策）——物理与逻辑都应分开。
• 功能轴：事实记忆（知道什么：偏好 / 环境 / 显式事实）、经验记忆（如何改进：成败教训 / 策略）、工作记忆（当前思考：推理上下文 / 任务进展）；细分还有情景（发生了什么）、语义（意味着什么）、程序（习得技能，如「该用户代码审查优先查 OOM」）。
• 存储形态轴（三态）：Token 级（向量库文本块 / 结构化 JSON）、参数化（预训练 / LoRA / SFT）、潜在态（KV Cache / 激活值）。

主流方案选型对照：Mem0——记忆即服务，embedding / 去重 / 冲突消解全包，按 user_id 隔离，接入成本最低，适合个性化偏好记忆；Letta / MemGPT——记忆即 OS，Core（常在上下文）/ Recall（最近历史）/ Archival（长期归档）三层分页，Agent 自主管理，适合长会话自编辑；Zep / Graphiti——记忆即图谱，有效时间窗口 + 时序知识图谱管生命周期，适合事实会过时、需要失效追踪的长期 Agent。判据不是 star 数，而是团队愿意把复杂度放在平台侧、Agent 侧还是数据模型侧，以及是否具备对应的运维能力。

图增强记忆的第一性：向量检索按「一条一条」存取，记忆之间没有显式关联——「用户 A 所在公司做什么业务」这类问题里，「用户 A」与「云计算」文本语义不相近，向量召不回；三元组（实体 → 关系 → 实体）+ 多跳推理补足关系链。分工是向量库管模糊语义、图谱管精确关系，对话中由 LLM 抽取实体关系入图。成本边界：实体 / 关系抽取每次都要调 LLM，低价值对话不上图，按对话重要性或实体密度触发。

生命周期六环节的工程实现：编码（LLM 抽取事实三元组 / 生成摘要）→ 存储（向量 + 图 + 关系）→ 提取（向量检索 + BM25 + 图遍历多路召回）→ 巩固（对话摘要归并实体库）→ 反思（任务后异步提取元知识 / 教训）→ 遗忘（score = relevance × importance × decay(t)，decay 为指数衰减，实际在重排阶段实时应用；该式源自 Generative Agents，属一种常见实现，不同方案的权重与衰减曲线不同，此处仅作示意）。

• 写入链路：对话后异步 LLM 语义提纯（Best-Effort）；幂等 Key 用 sourceId + batchId 而非文本哈希（温度与微调会导致字面不同）；并发写用乐观锁 / MVCC。
• 存储字段与索引：内容转向量与原文、metadata（时间 / 任务类型 / 重要程度 / 记忆类型）一起存；查询必须用同一 embedding 模型，ANN 索引（HNSW / IVF）加速——写入与检索的向量空间不一致，等于自毁召回。
• 检索链路：新 Session 开始向量化 Query 取回，prepend 进系统提示或平行 slot；向量库 P99 直接吃 TTFT——用 Redis 预热、浅层画像全量预载、检索与生成重叠执行来压等待感。
• 读 → 用 → 写闭环：任务前按任务描述检索长期记忆并注入 system prompt；执行中把「查记忆」封装成 Tool 按需检索；任务后把新偏好更新到实体记忆、有价值结论摘要写入向量库——只在任务前预载会漏掉中途出现的新线索，只在任务后写则下次会话接不上。
• 存储三层架构：VectorStore（选型看索引 HNSW / IVF / DiskANN、预过滤 / 后过滤、多租户隔离粒度、一致性、成本）+ GraphStore（实体关系图谱，支撑多跳推理）+ Reranker（交叉编码器二次精排）。
• 粒度与整合：粒度太细 → 碎片化（一条完整偏好拆四条只命中两条）；太粗 → 噪音（两千 token 里相关的只有一百）；合理粒度 = 一次完整交互或一个独立知识点。整合四步：去重（语义相近合并）→ 冲突消解（保留时间新的，时间戳是关键）→ 抽象提炼（情节记忆 → 语义记忆，如多次「动态渲染 requests 失败」沉淀为「有动态渲染时用浏览器自动化」）→ 分层节奏（任务后轻量去重 + 定期深度提炼）。
• 遗忘与冲突：新事实写入时标记旧边失效 + 时间戳，定期 Vacuum 重建索引（软删除会破坏 HNSW 连通性）。
• 轻量替代：少量明确结构化的偏好 / 规范，用 Markdown 文件（如 AGENTS.md）+ Git 版本化，零迁移成本、透明可审计；与向量库边界——少量结构化走 Markdown，大量非结构化语义召回走向量，两者可并存。

• 长期记忆 vs RAG 的职责边界？技术栈相似（向量 + 语义检索），但 RAG 服务共享知识源（规章 / 文档 / 实时库，可按租户过滤但非个性化），长期记忆管理特定用户的个性化经验。可分开召回再统一排序：长期实体可扩展 RAG 查询词，用户偏好可参与重排。
• 为什么幂等 Key 不用文本哈希？同一事实两次表述字面不同（温度采样 / 模型升级），文本哈希判重必失效；用业务侧 sourceId + batchId 才能保证「不重写、不漏写」。
• 检索链路优化次序？先修检索链路（看 Trace：query 改写 / 过滤 / 候选集 / 重排打分），再扩写入规模——写入越多检索质量越差时，扩容只会放大问题。
• 自我反思闭环？任务后异步复盘提炼教训（源于 Generative Agents 的「睡眠记忆巩固」）；高风险操作后触发细粒度核对（事实 / 验收 / 数据缺口），不通过则退回补齐。
• 「这次答对」与「下次少犯错」为何是两件事？纠正留在上一段对话里，模型参数没有更新，新会话读不到——经验必须存到任务外（向量库 / 记忆服务）并在下次决策前检索注入，才构成学习闭环。
• 四层记忆（感知 / 短期 / 长期 / 实体）与三个工程问题？存什么（事实 / 偏好 / 教训分型）、怎么存（向量 + metadata + 图谱边）、何时取（任务前预载 / 执行中按需 / 冲突时裁决）——只答「长短两分」是经典的不完整答案（Letta 的 OS 三层是另一套计数口径，不要混用）。

• 短期与长期记忆混存一库：检索时任务上下文与历史偏好互相污染；必须物理 / 逻辑分离并分别设 TTL。
• 只写不清：无遗忘机制与冲突标记，记忆库膨胀后陈旧事实压过新事实——「用户换了团队」被三个月前的旧记忆覆盖。
• 多租户检索不带硬过滤：A 租户检索命中 B 租户记忆是 P0 事故；检索层必须带 UserID / 组织 / 时间 / 业务标签硬过滤，高活跃租户独立 Collection 物理隔离。
• 记忆写入走同步链路：LLM 提纯耗时且可能失败，同步写会拖垮响应；应异步 + 失败重投 + 幂等。
• 用关键词搜索代替语义检索：问「代码习惯」命不中已存的「Python 风格偏好」——长期记忆必须 Embedding + 向量库语义检索；少量结构化偏好走 Markdown 文件是另一条边界，不是关键词库。
• 粒度越细越好：碎片化导致召回失全；按「一次完整交互 / 一个独立知识点」裁决，而不是按句子切。
• 选框架只看 star 数：Mem0 省心但策略黑盒、Letta 灵活但要自己管、Zep 强在时态但引入图谱运维——按「谁管理记忆复杂度」与团队运维能力选。

持久化状态会累积偏差，局部合理的记忆更新可能漂移到从未授权的行为轨迹。本题考察为何记忆写入必须按「生产变更」准入，以及谱系、拒绝策略与遗忘权如何支撑回滚。

从自由写入到准入闸门：早期对话结束即把摘要追加进向量库；随后引入抽取式写入与冲突消解；再往后发现「局部有效」的更新会在长周期里改变 Agent 行为；当前把写入视为变更，配变更单、盲集比对与准入判定。

记忆不是日志，而是会被后续推理反复引用的状态。单次更新的合理性无法推出全局安全性，因此准入标准应从「这条记忆是否正确」改为「这次写入有没有在别处制造退化」。写入方与判定方必须分离，且系统硬约束不能参与摘要压缩。

写入前产出变更单：来源会话、抽取主体、时间与模型版本、目标记忆类型、影响的检索分区；谱系记录父子关系与覆盖链；准入跑盲集比对，观察其他任务是否退化，异常即拒绝；删除按遗忘权联动向量库、图谱、缓存与索引快照，并保留可审计的墓碑记录。

为什么摘要压缩不能覆盖硬约束？压缩的目标是省 Token，而约束的价值在于不可被省略，两者优化方向相反。为什么遗忘是安全能力而非清理任务？未联动删除的过期记忆仍会被召回，形成「已撤回但仍生效」的幽灵状态。

自动写入无审批；系统约束被摘要吞掉；写入无谱系导致无法回滚；删除不联动缓存与索引；把「用户说过」直接当永久事实；用同一模型既生成记忆又判定准入。

这道题考察的是 RAG 的存在理由与两阶段范式：它补齐 LLM 哪三个短板（知识时效性 / 私有数据 / 幻觉控制）？离线索引与在线检索各环节职责是什么？「RAG vs 微调」的决策依据是什么（解决「不知」还是「不会」）？以及为何长上下文不能取代 RAG。这是 RAG 体系的开山题，答不好后续进阶题全部失守。

三阶段演进：Naive RAG（切块 → Embedding → TopK → 生成，Demo 级）→ Advanced RAG（Query 改写 / HyDE → 混合检索 → 重排 → 上下文压缩）→ Modular RAG（检索器 / 重排器 / 压缩器 / 路由器 / 生成器可插拔，面向生产与 Agent）。并行地，Embedding 模型从 Word2Vec → BERT → BGE-M3 → LLM 直出嵌入（如 Qwen3-Embedding、gemini-embedding 一类；具体型号与榜单表现以官方发布为准，需核实）持续升级。

RAG 补齐的三个短板与边界：① 知识时效性——训练截止后的新事件靠动态检索注入；② 私有数据——只把相关片段给模型，不暴露全量企业数据；③ 幻觉控制——提供明确参考文本降低编造概率，但非彻底消除，需配引用校验 / 拒答 / 反馈闭环。

两阶段工作流：离线索引（输入 → 清理 → 元数据增强 → Chunking → Embedding → 入库）+ 在线检索（Query 改写 → 向量化 → 相似检索 → 上下文增强 R → 生成 G）。

RAG vs 微调的判据：RAG 解决「不知道新知识 / 私有知识」，微调解决「不会按你的方式说 / 做」；知识更新成本 RAG 低（更新库）微调高（重训）；可追溯性 RAG 强（引用片段）微调弱。结合策略：微调注入领域术语与格式习惯，RAG 供给实时可追溯证据；资源有限先稳 RAG。

• 答非所问排查顺序（比换贵模型有用）：Chunk 切太粗 → Query 未改写 → 关键词与向量未结合 → 重排缺失，逐项排查。
• 向量库选型：Milvus（大规模）/ pgvector（已有 PG）/ ES（全文 + 向量一体）/ Faiss（轻量内嵌）；关注权限隔离与增量更新能力。
• 相似度度量：余弦最常用（对长度不敏感）；内积在 L2 归一化后近似余弦；欧氏对幅度敏感。
• 长上下文为何不能取代 RAG：贵且慢、百万级文档塞不下、Lost in the Middle、权限隔离仍需应用层、可追溯性 RAG 更优。企业常「传统搜索（找材料）+ RAG（读材料给结论）」两套入口并存。
• 效果评估：RAGAS 用强模型当裁判自动计算 Faithfulness / Answer Relevance / Context Recall；DeepEval 融入单元测试；评估纳入 CI 回归。

• 「幻觉控制非彻底消除」如何工程化？三件套：生成时强制引用标注；后置引用校验（答案中的每个论断能否回溯到检索片段）；无证据时拒答短路（宁说不知道不给编造）。
• Embedding 维度越高越好吗？不是。768/1024/1536/3072 各有存储与延迟代价；MTEB 榜单仅参考，必须用业务评测集实测（领域术语、真实脏输入）。
• 微调与 RAG 同时上的顺序？先 RAG 后微调：RAG 建立可追溯底线与评测基线，微调在其上优化表达；反过来做，微调的错误无法定位是知识缺失还是表达问题。

• 把 RAG 当幻觉消除器：检索到错误 / 过期资料时 RAG 会「自信地引用错误证据」；必须有引用校验与时效性治理（见 A21.03）。
• 切分只看固定长度：一句话被切断、表格被拆散；应递归字符 / 语义切分起步，保护语义完整。
• 上线后不建评测集：每次改切分 / 换模型都靠「感觉」；Faithfulness < 0.75 这类门禁无法建立，回归无从谈起。
• 微调替代知识更新：用微调「教」新知识，成本高且不可追溯；知识注入是 RAG 的本职。

与 A09.02 的边界：本卡是决策入口（要不要上切分 / 精排 / 多路）；RRF 与分档收益的机制展开见 A09.02。下文百分比都是观察值。

这道题考察的是 RAG 检索质量的三板斧：切分、精排、多路召回：Chunking 如何兼顾语义完整与检索粒度？Cross-Encoder 精排为何能提升 30–50% 准确率（特定评测观察，非普适）、其性价比拐点（50–100 候选重排到 Top-5/10）如何算？向量 + BM25 混合召回为何比单路好 10–30%（观察值，非普适）？核心是建立「答非所问多在召回阶段」的排查直觉。

从单路 TopK 到多级流水线：初代只做「向量 TopK → 直接生成」；Advanced RAG 引入「多路召回 → 融合 → 精排 → 压缩」四级；工业实践进一步细化出父子块（小块检索、大块生成）与「简单事实查询阈值短路」（初排 Top-1 得分高于阈值则跳过重排省延迟）。

切分（Chunking）的第一性矛盾：检索粒度要小（向量表征聚焦、匹配准），生成上下文要大（语义完整、信息足）。解法不是找「完美块大小」，而是检索与生成分离——父子块：子块（句 / 段）用于向量召回，命中后回挂父块（章节 / 文档）进窗口。

精排（Re-rank）的第一性原理：双塔（Bi-Encoder）向量检索把 query 与文档独立编码后算相似度，快但粗；Cross-Encoder 把 query 与文档拼接送入模型逐 token 交互，准但慢（每对都要过一遍模型）。所以只能「双塔粗筛大候选集 → Cross-Encoder 精排小候选集」，准确率提升 30–50%（特定评测观察，非普适）。

多路召回的第一性原理：向量召回抓语义近似（同义改写），BM25 抓关键词精确匹配（型号、错误码、专有名词）；两路失败模式互补，融合后覆盖面提升 10–30%。

• 切分策略选型：递归字符切分起步（保段落 / 句子边界）→ 语义切分（按 embedding 相似度断点）→ 结构感知切分（按 Markdown 标题 / 代码块 / 表格边界）；避免一句话被切断、段落被拆开。
• 精排参数：先检索 50–100 候选，重排取 Top-5/10 性价比最高；简单事实查询可设阈值短路（初排 Top-1 低于阈值才触发重排，省延迟）。
• 混合融合：RRF（倒数排名融合，免调参适合冷启动）/ 线性加权（需标注数据校准权重）；RRF 是工程默认起点。
• Query 侧优化：改写（口语 → 检索友好）、扩展（一问多变体）、HyDE（先让模型生成假设答案再用其向量检索）、拆解（复合问题拆子问题分别召回）。
• 上下文压缩：重排后对入选片段做句子级筛选 / 摘要，压掉与问题无关的段落再进窗口。

• 为什么「切太细」同样致命？子块语义断裂后，向量表征失去上下文语境，召回的片段「对但不可用」；父子块正是为同时保住「检索粒度」与「生成完整性」。
• RRF 与线性加权怎么选？冷启动无标注 → RRF（免调参、对单路异常鲁棒）；有标注数据且追求极限 → 线性加权 / 学习型融合；两者可 A/B 实测定。
• 重排模型的延迟预算怎么算？Cross-Encoder 对 k 个候选的延迟 ≈ k × 单对推理耗时；k=50、单对 10ms 即 500ms——生产上要么缩 k、要么用轻量重排器、要么异步预取。
• 答非所问为什么先查召回？生成阶段只能「用给定的料答题」；料本身错 / 缺，换再强的生成模型也无济于事——排查顺序：切分 → Query 改写 → 混合召回 → 重排。

• 只调块大小不调召回：把「切 256 还是 512」当主要优化点，忽视 Query 改写与混合召回——后者收益更大。
• 精排候选集过大：1000 条全量重排，延迟爆炸；精排永远只处理粗筛后的头部候选。
• BM25 分词未按领域定制：中文未分词、专有名词被切碎，关键词路形同虚设；需按领域维护词典与同义词表。
• 父子块映射关系丢失：重建索引后未同步更新父子映射，召回命中「孤儿子块」无法回挂父块。

这道题考察的是 图增强检索的边界与选型：传统向量 RAG 的三大失效场景（跨文档多跳推理、全局归纳、切块语义断裂）是什么？GraphRAG（社区摘要 + 图遍历）与 LightRAG（去社区层 + 双层检索）的机制与成本差异为何高达两个数量级（论文报告口径的 Token 成本约 $20–50 vs $0.15，具体数值与语料规模需核实）？能否给出「传统 RAG → LightRAG → GraphRAG」的务实升级路径。

GraphRAG（微软，2024-04）：用 LLM 抽取实体与关系构建知识图谱，检索时 Local Search（图遍历邻居）+ Global Search（Leiden 社区检测 + 社区摘要 Map-Reduce）。代价显著：索引昂贵（被称「Token 焚烧炉」）、增量更新引发级联失效、端到端延迟 10s–1min。LightRAG（港大，2024-10）：去掉社区层（省 80%+ LLM 调用）、双层检索（低层实体 + 高层主题并行）、追加式增量更新；论文报告 Token 成本降幅约 99%（基线口径需核实），延迟 1–3s，且保留 Naive 模式兼容传统向量 RAG。

向量 RAG 的失效根源：它只做「相似文本块召回」，没有实体间关系的显式表示——「A 供应商供应 B 零件、B 零件用于 C 产品」这类跨文档多跳链路被切碎在三个互不相似的块里，TopK 检索永远凑不齐；「这本书的核心论点」类全局问题更是无块可召回。

图增强的解法：把知识组织为实体 - 关系图，检索变为图遍历（多跳）与社区摘要（全局）；Local Search 管「点对点关系链」，Global Search 管「主题级归纳」。

LightRAG 的取舍：社区检测 + 社区摘要是 GraphRAG 成本与延迟的大头；LightRAG 以「双层并行检索」近似全局能力，用「高层主题关键词」替代「社区摘要」，故成本骤降而全局归纳能力略有折损。

• 选型对照：GraphRAG = 重型武器（深度全局洞察、跨文档高价值推理、知识静态少更新、强可解释 / 审计要求）；LightRAG = 轻巧刀具（频繁更新、成本敏感、C 端实时交互、语料 10 万–500 万 token 甜蜜区）。
• 务实升级路径：传统向量 RAG 起步 → 遇到跨文档 / 全局问题且传统召回确实无效 → 升 LightRAG → 精度仍不足且预算充足 → 再上 GraphRAG。禁止一上来就建图。
• 增量更新纪律：GraphRAG 的图更新会级联失效（新实体改变社区划分），需预算重算窗口；LightRAG 追加式更新适合高频知识库。
• 与混合检索共存：图检索不替代 BM25 / 向量路，而是作为第三路参与融合；实体别名表（缩写 / 旧称）须维护，否则图召回漏召回。

• 图构建质量由谁保证？实体抽取与关系抽取均由 LLM 完成，抽取幻觉会污染图谱；需抽样人工校验 + 实体消歧（同名实体合并规则）+ 抽取 Prompt 版本化管理。
• 为什么 LightRAG 敢去掉社区层？因为「高层主题」可通过「实体共现统计 + 关键词提升」在线计算，无需离线社区摘要；代价是全局问题的回答结构化程度略低。
• 图增强与 Agentic RAG 的关系？图是数据结构，Agentic 是调用方式（由 Agent 决定何时查图、查几跳）；两者正交，可组合为「Agent 调度下的多跳图检索」。

• 为「看起来高级」上图：语料仅几万 token、问题全是单跳事实，图增强纯属成本浪费；先确认传统 RAG 真实失效再升级。
• 忽视图索引维护成本：知识频繁更新的库用 GraphRAG，每次更新触发社区重算，运维成本失控。
• 实体消歧缺位：「BAT」「百度阿里腾讯」未被合并，图遍历断裂；别名与消歧规则必须进 ETL。
• 把图检索延迟带入在线主链：Global Search 秒级延迟不适合同步接口；应异步预计算常用主题摘要或降级到 Local Search。

这道题考察的是 Agent 工具体系的四层概念分层：Function Call（原子调用能力）、MCP（统一连接标准）、Skills（做事方法知识层）、A2A（Agent 间协作协议）各自的角色与边界是什么？为什么「一个任务可能触发十几次 FC，而 Agent 是 FC 的高级编排」？能否用「打电话 / 通讯录 / 岗位手册 / 横向协作」的比喻体系讲清四者关系。分层不清是工具架构混乱的总根源。

从私有 Function Call 到协议标准化：早期各家模型私有 FC 格式互不兼容，工具接入随模型切换重写；2024-11 Anthropic 开源 MCP（Model Context Protocol）统一「模型 ↔ 工具」连接标准，被称「AI 界 USB-C」；2025-04 Google 发布 A2A 补齐「Agent ↔ Agent」横向协作（Agent Card / Task 生命周期 / Message & Artifact，基于 HTTP+JSON+SSE，支持异步长任务），2025-06 起移交 Linux Foundation 托管（治理细节与时间以官方公告为准，需核实）。Skills 则由 AI 编程工具实践沉淀为「声明式任务说明」形态（SKILL.md）。四层概念至此齐备。

四层各自的「存在理由」：

链路关系：FC 产生命令（结构化调用意图）→ MCP 传递命令并连接工具 → Agent 决定链路何时继续 / 结束；Skills 在其上规定「该按什么流程调、调完怎么校验」。一句话锚点：MCP = 厨房（能做什么），Skills = 菜谱（该怎么做）。

工具三分类：感知类（读文件 / 查库 / 爬网页）、执行类（写文件 / 发消息 / 调业务系统）、协作类（调用其他 Agent，对应 A2A）。

• 接入优先级：单模型单工具场景直接 FC 即可；工具需跨多个 Host / 应用复用时才引入 MCP（避免为用而用）；团队级流程规范沉淀为 Skills；跨团队 / 跨进程 Agent 委派才需要 A2A。
• MCP 生产难点在接入之后：谁能调、能操作哪些数据、调用审计、失败回滚——「怎么接」是协议题，「接得稳」是治理题。
• 代码执行必须沙箱：限制文件系统 / 网络 / 资源配额（如专用 execution sandbox），高危操作加人工确认。
• 网关层兜底：统一鉴权、限流、审计、降级，工具调用全部过网关而非直连（详见 A07.03）。

• MCP 与 A2A 为何不互相替代？MCP 竖向（模型 ↔ 工具/资源），A2A 横向（Agent ↔ Agent）；一个 Agent 既是 MCP Client（用工具）又可以是 A2A Server（接活）——两个协议在典型架构里同时存在。
• Skills 与系统提示词的区别？系统提示全局常驻（吃窗口）；Skills 三层渐进披露——广告层（仅元数据常驻）→ 指令层（命中才读正文）→ 资源层（按需读 references），按需加载不占常驻预算。
• FC 与 MCP 的调用时序？模型经 FC 输出「调用意图」，执行由 Host 侧的 MCP Client 转发给对应 Server；意图（模型产物）与执行（宿主程序）分离，正是权限校验的插入点。
• 为什么工具网关必须是唯一可信边界？模型输出的是意图而非事实，若允许它直连下游服务，身份、参数、幂等键、限额这些确定性校验就散落在各处，任何一处遗漏都会变成可直接触达生产的旁路。统一网关把意图翻译成带校验的调用：先做 schema 与白名单校验，再注入身份与幂等键，最后落审计与限流；模型永远拿不到网关注入的字段，也永远无法绕过该链路。

• 把 MCP 当万能中间件：单应用内部调用硬套 MCP，徒增进程与序列化开销；协议解决的是复用与解耦，不是性能。
• Skills 写成「百科全书」：单个 SKILL.md 塞数千行，命中后一次性灌满窗口；应主文档精简（建议五百行内），细节拆 references 按需读。
• 混淆「工具能力」与「使用方法」：把操作手册写进工具 description 或把接口文档写进 Skill，职责错位导致维护地狱。
• 协作类工具不做幂等：Agent 间调用失败重试导致重复执行副作用，必须有幂等键（详见 A05.03）。

这道题考察的是 MCP 的协议本质：它究竟定义了什么（Client 与 Server 之间的通信协议，而非「框架」）？三角色（Host / Client / Server）如何分工？「N×M → N+M」的数学含义是什么？三类能力（Tools / Resources / Prompts）与三项进阶能力（Roots / Sampling / Elicitation）各自解决什么问题。能否从「同一工具交付多个 Host 重复集成」的痛点推导出协议的必然性。

痛点模型：M 个 AI 应用（Host）× N 个工具（数据源 / 系统）= M×N 份定制集成代码，任一方升级都牵动全部。MCP（Anthropic，2024-11 开源）把集成收口为 M+N：应用实现一次 MCP Client，工具实现一次 MCP Server，中间走统一协议。生态演进：2025-03 规范修订引入 Streamable HTTP 传输（替代纯 HTTP+SSE）；2025-11-25 版规范进一步固化安全与传输语义——SDK 版本与规范版本需配对核对（双方绑定关系以官方发布说明为准，需核实）。

三角色分工：Host（宿主应用）承载用户交互与模型调用；Client（每个 Host 内可持多个）负责与单个 Server 的协议通信；Server 暴露工具与资源。MCP 本质 = Client 与 Server 之间的 JSON-RPC 2.0 通信协议——Host 负责交互与模型调用，协议只管「怎么发现、怎么调、怎么回」。

三类能力：Tools（执行动作，有副作用）/ Resources（只读上下文：文件 / 日志 / Schema）/ Prompts（可复用提示模板）。三项进阶能力（Client → Server 方向）：Roots（声明目录范围——注意它是约定不是沙箱，路径校验仍需 Server 自做）、Sampling（Server 反向请求 Host 的 LLM 生成）、Elicitation（Server 向用户补充询问）。

• 传输选型：stdio（本地子进程，注意 stdout 不能打日志——会污染协议流）适合本地开发；Streamable HTTP（远程、可过网关做鉴权 / 限流 / 审计）适合生产远程；无状态变体可横向扩展但失去双向通信。
• Schema 即契约：字段单位、时间格式、枚举值写清；工具带版本号支持灰度回滚；Schema 同时用作运行时校验与模型提示。
• Server 设计纪律：避免 execute_sql / file_operation 式万能工具，按业务动作拆分（动词 + 名词，description 写清适用与禁用场景）；大文件按 chunk（约 100KB）读取。
• 安全不靠模型：目录校验、沙箱、限流熔断全部在代码层实现；三方 Server 需源码 / 依赖 / 权限三重审核，禁用 Token Passthrough（原样透传令牌）。
• 可观测：Trace ID 贯穿 + 结构化日志 + 成本归因（关联用户 / 业务线 / 工具）。

• 为什么 JSON-RPC 2.0 而非 REST？工具调用本质是「方法名 + 参数 + 结果」的方法调用语义，与 JSON-RPC 天然贴合；REST 的资源模型反而要为「动作类工具」强行建模。
• Roots 与沙箱的区别？Roots 只是 Client 告诉 Server「我关心这些目录」的声明，恶意 / 有 bug 的 Server 可无视；真正的隔离必须靠操作系统级沙箱与权限体系。
• Sampling 与 Elicitation 的安全边界？两者都是「Server 反向驱动力」：Sampling 让 Server 触发模型生成（成本与内容可控性归 Host），Elicitation 让 Server 请求用户输入（需 Host 明示并向用户呈现来源）；Host 必须对两者设白名单与审计。
• N+M 之后的新瓶颈是什么？工具数量爆炸后的「选择准确率」——几百个工具全量注册进上下文会推高 token 成本并降低选择准确率，解法是渐进式工具披露（先索引后按需暴露，见 A15.01 关联实践）。

• 把 MCP 当安全边界：协议本身不含权限模型；鉴权、脱敏、防路径遍历 / SQL / 命令注入全部要在 Server 实现与网关层补齐。
• stdio 模式在 stdout 打日志：日志混入协议流直接破坏通信，日志必须走 stderr。
• SDK 版本与规范版本错配：升级前不核对「SDK 对标哪一版规范」，无状态化重构等破坏性变更直接踩坑。
• 万能工具一把梭：execute_sql 一步到位，代价是权限粒度无法细分、审计无业务语义、注入面全开。

这道题考察的是 生产级工具接入的完整 Checklist 与 Skills 渐进披露机制：从 Schema 版本化、权限安全、可观测到成本归因的接入清单有哪些必查项？SKILL.md 的结构规范（YAML 元数据 + 正文指令）是什么？三层渐进披露（广告层 → 指令层 → 资源层）如何解决「跨会话规则复用 + 上下文腐化」两大问题。这是把「能调通」升级为「敢上生产」的工程题。

Skills 从隐性实践到显性标准：早期团队把操作经验写进 wiki / 聊天记录，Agent 不可见也不稳定；随后沉淀为仓库内规约文件（如 AGENTS.md），但全局常驻吃窗口；最终收敛为 Skills 形态——SKILL.md 声明式定义（YAML 元数据 + 自然语言指令），按需加载，Git 版本化，团队经验资产化。

生产接入 Checklist（四象限）：

• Schema / 版本：字段单位、时间格式、枚举写清；工具带版本号 + 灰度回滚；Schema 双重身份——运行时校验器 + 模型提示词。
• 权限安全：目录 / 库 / API 边界明确；读写分离；高危操作人工确认；返回值脱敏；防路径遍历 / SQL 注入 / 命令注入；三方 Server 审核三件套（源码 / 依赖 / 权限）。
• 可观测：Trace ID + 结构化日志 + 完整调用链。
• 成本归因：调用关联到用户 / 业务线 / 工具三个维度，支撑计费与异常告警。

SKILL.md 结构规范：YAML 元数据（name ≤ 64 字符小写连字符；description 必须写清「做什么 + 何时用 + 触发词」）+ 正文指令（默认方案 / 项目约束 / IO 格式 / 失败处理，建议 ≤ 500 行，长内容拆 references/ 目录）。工作流：宿主把各 Skill 简介放进上下文 → 模型路由命中 → 延迟加载完整正文 → 按流程调工具。

三层渐进式披露：

企业价值落点：评审规则 / 慢 SQL 排查 / 报表口径等经验固化为 Skill，新人 Agent 直接继承；Checklist + 验证节点写进正文防跳步；按任务风险分配自由度——迁移 / 部署类低自由度（强约束 + 回滚预案），评审类高自由度（开放建议）。

• 为什么 description 决定 Skill 成败？路由完全依赖模型对广告层的判断；description 不含触发词 / 场景边界，Skill 等于不存在。写法公式：「做什么 + 何时用（含触发词）+ 何时不该用」。
• Skill 与测试的关系？Skill 正文中的验证节点应可执行（关联脚本 / 校验命令）；只有文字检查清单而无机械校验，Agent 会跳步。
• 披露层数会增长吗？会。Skill 数量上百后，广告层本身成为窗口负担——需按项目 / 场景域分组启用（宿主按配置只挂相关 Skill 集），对应工具披露的同一治理逻辑。

• Schema 不带版本直接改字段：调用方与 Server 不同步上线即崩；字段变更必须走版本号 + 双写过渡。
• 正文里写敏感信息：Skill 进 Git 仓库，密钥 / 内网地址一旦写入即泄露；敏感值走环境注入。
• 描述含糊导致误路由：「处理数据相关问题」这类 description 会让模型在无关任务上误触发；必须写明触发词与排除场景。
• 只发 Skill 不发验证：没有机械校验节点的 Skill 在执行中被「创造性跳步」，产出的东西看似完整实则漏检。

工具调用是 Agent 链路里最大的单点故障源。本题考察零信任 Schema 校验、幂等加沙箱、错误分类加重试预算这三层契约为何缺一不可，以及为何同一请求只能由一层负责重试。

从裸调用到分层契约：起初模型直接拼参数调下游；随后补上 JSON Schema 校验；再往后发现校验通过仍会产生重复副作用与错误放大；当前把三层拆开，分别由网关注入、执行层与预算层承担。

模型输出的是意图而非事实，任何由模型填写的参数都须视为不可信输入。重试只对瞬时故障有效，对语义错、权限拒绝与参数不合法只会放大成本与副作用；若各层各自重试，实际调用次数按乘积增长，且幂等键可能不一致。

第一层：ToolContract 声明参数白名单与只读注入字段，Schema 强校验剔除模型提供的同名参数；第二层：幂等键由执行上下文生成，写操作配去重表，沙箱按会话动态注册工具并限制作用域；第三层：错误 taxonomy 仅让超时、限流、依赖不可用进入带抖动退避，总预算由入口下发并逐跳递减。

为什么模型不能决定重试次数？它无法区分瞬时故障与永久拒绝，且自报成功不构成证据。为什么「工具返回成功」不等于副作用正确？返回码只描述调用完成，业务状态须由独立的后置校验确认。

多层重复重试；幂等键含时间戳等易变字段；工具一次性永久挂载；所有错误一律重试；用「请谨慎」替代硬拦截；只记录成功路径导致故障无法复盘。

这道题考察的是 多 Agent 协作的四要素与 Graph Engineering 三要素：任务拆分 / 状态共享 / 冲突处理 / 失败恢复如何构成协作的完整性约束？Graph 的 Node / Edge / State 三要素各自的设计原则是什么（好节点：只干一件事、可单测、可替换；边：能写死尽量写死；状态：字段固定的 JSON 存档）？以及「先确保每个节点稳定，再谈编排」的先后纪律。

从串行链到图编排：初期多 Agent 就是「A 调 B 调 C」串行链——慢、无存档、难暂停审批、难表达复杂分工。LangGraph（2024）把「图」显式化（StateGraph + 条件边 + 持久化）；Spring AI Alibaba 对齐同一套概念（OverAllState + KeyStrategyFactory + addConditionalEdges + MemorySaver/RedisSaver 持久化 + interruptBefore 人机协同；类名与模块随版本演进，以所用版本官方文档为准，需核实）。AI 编程工具的 subagent / hook / workflow 也是同一思想的实现变体。

协作四要素（缺一即事故）：

• 任务拆分：可独立、可并行、可校验的子任务分配给不同角色；避免单步过重。
• 状态共享：共享上下文 / 全局状态避免信息孤岛，但只保存跨角色必要信息，各 Agent 的 ReAct 进度留在自己会话态。
• 冲突处理：明确 ownership，分歧经评审 / 仲裁节点解决，而非简单投票。
• 失败恢复：重试 / 降级 / 人工接管三档预案前置设计。

Graph 三要素：Node（干活的单元：agent / 固定代码 / DB 查询 / 人——审批节点也是节点）；Edge（确定性边代码写死、模型决策边留给语义分支、条件边两者皆可——原则是能写死尽量写死）；State（字段固定的 JSON 对象，节点完成后存档，中断 = 读档重试单节点而非从头跑）。核心关系：loop ⊂ graph——loop 是单节点自环的最小 graph，graph 管「节点之间」，loop 管「节点内部」。

• 拆分判定信号：① 不同环节需要明显不同的工具 / 权限 / 上下文；② 任务可划为独立子方向（多路并行检索）；③ 各角色能产出结构化交付物（结论 / 引用 / Diff / 测试报告）而非自由文本。三条全不命中就别拆。
• State 设计：按业务含义分块（工单快照 / 评分 / 重试次数 / 错误码），忌过粗（丢信息）过细（同步地狱）；finalOutput 仅允许归并节点写。
• Java 落地映射：Spring AI Alibaba 的 OverAllState + KeyStrategyFactory（Replace / Append 策略）对应 LangGraph 的 TypedDict + Annotated reducer；MemorySaver / RedisSaver 持久化；interruptBefore + updateState 实现人工审批。
• 适用与不适用：适用——可拆独立子任务需并行、不同环节不同模型 / 权限、需人工确认环节、长时多分支需追踪；不适用——小任务顺序执行（「一个人一下午能干完的活，别开项目启动会」）。

• 为什么「先节点稳定再谈编排」？图编排放大一切单点问题：一个节点抖动，并行分支全部受灾；编排层的设计前提是每个节点的输入输出契约与失败模式已明确。
• 人作为节点的工程含义？审批节点 = 状态机中断点（interruptBefore）+ 存档 + 恢复时重校验权限 / 版本 / 业务状态；人的响应延迟要求 Checkpoint 必须落盘且可校验。
• 静态拆分 vs 动态委派？业务稳定用静态拆分（易测试、控成本）；子任务不确定用动态委派（主管 Agent 现场派活）；可混用——外层固定阶段、内层动态派 Subagent。
• 多 Agent 的唯一取舍标尺是什么？分工收益必须大于协作成本，否则应退回单 Agent。协作成本包含规格传递损耗、上下文重复开销、结果归并的验证开销，以及多角色带来的额外故障面，这些成本随角色数增长而非线性收敛。因此设计顺序是能单不双：先证明单 Agent 在步数预算内无法达成目标，再引入角色划分，并为每个交接点定义可机械校验的交付物。

• 状态共享变成全量广播：每个 Agent 都拿到全部中间产物，上下文爆炸且互相干扰；只交「任务说明 + 必要片段 + 结论摘要 + 引用 URI」。
• 模型决策边滥用：把可以代码判定的分支交给模型判断，路径不可复现、测试无从下手；模型判断力留给少数真正语义化的分支。
• 无存档的长图：跑到第 9 个节点失败即全部重来；没有 State 存档的长图在生产等于不可用。
• 业务上下文用 ThreadLocal 隐式串任务：并发下串数据事故；必须显式传 TaskContext。

这道题考察的是 Workflow / Graph / Loop 三种编排范式的对比与选型：三者的控制方（代码 / 混合 / 模型）、灵活度、可调试性如何排序？Loop 的五大件 + 磁盘记忆构成是什么？Agent Loop 与 Graph Loop（回边迭代）如何区分？核心是能按任务形态（固定流程 / 多节点复杂分工 / 单点反复迭代）对号入座。

四代 engineering 演进的终点是 Loop：Prompt（怎么说）→ Context（喂什么）→ Harness（驾驶舱 / 运行环境）→ Loop（把「亲自写 prompt 的你」替换为「设计代替你做这件事的系统」）。杠杆支点从「说一句话」移到「设计一套制度」——投入从消耗品变为可复利资产。loop = 递归式目标，系统持续迭代直到完成。

三范式对比：

Loop 五大件 + 一份磁盘记忆：① 自动化（心跳：定时 / 事件触发）；② worktree（并行隔离，防多 Agent 改同一文件打架）；③ skill（固化项目知识，治「金鱼记忆」）；④ connector（基于 MCP 接 issue / 监控 / PR 等外部系统）；⑤ sub-agent（写代码与检查代码分离，干净上下文挑刺）；⑥ 记忆（磁盘状态文件——「Agent 会忘，但 repo 不会」）。

Agent Loop vs Graph Loop：前者是 Agent 顶层运行引擎（while 循环反复「推理 → 行动 → 观察」直到完成）；后者是 Graph 内部特定节点经回边形成的迭代修正环（审核不通过 → 回到修改），可嵌套在 Agent Loop 某节点内。外层与内层，不是二选一。

• Loop 防死循环三要素：继续条件（为什么再来一轮）+ 退出条件（何时足够好）+ 安全边界（最大轮次 + 超时 + Token 预算强制退出）；支持嵌套（外层质量迭代 / 内层工具重试，各自独立退出条件）。
• 选型口诀：单点迭代用 Loop、固定流程用 Workflow、复杂分工用 Graph；生产多为混合——Workflow 控主干，复杂环节起 Graph / Agent。
• Loop 的成本纪律：Loop 会放大 Token 与延迟——先粗筛再精修、够好即停；每轮迭代必须有增量价值判定，否则立即退出。
• 落地检查：sub-agent 的审查者上下文必须干净（未见过生成过程），否则「自己查自己」流于形式。

• 为什么说 Loop 的本质是「制度设计」？退出条件、质量门槛、安全边界都是制度；制度一旦建立可反复复用（资产），而每次手写 prompt 是一次性消耗——这是投入产出结构的根本变化。
• Graph 里的回边与 Agent Loop 的 while 有何本质差异？回边的继续 / 退出由 Edge 条件（可代码可模型）决定且 State 显式记录轮次；while 的控制权在模型手中，天然易震荡——所以工程上倾向把迭代显式建模为 Graph 回边 + 轮次上限。
• Loop 与自进化？进阶形态是 Loop 修改自身规约（如把失败教训写回 AGENTS.md）；必须人工审核入口，否则规约被污染将系统性放大错误。

• 只设继续条件不设退出条件：「不够好就再来一轮」没有上限，Token 失控；轮次 / 超时 / 预算三保险必须硬编码。
• Loop 内外层共用一个退出计数：外层质量迭代与内层重试互相干扰；嵌套循环各自独立计数与退避。
• 把 Workflow 硬写成 Graph：无分支无并行无审批的纯顺序流程上 Graph，徒增状态管理复杂度；Graph 的价值在「关系复杂」，不在「图好看」。
• sub-agent 审查者共享主 Agent 上下文：偏见随上下文传染，审查形同虚设；审查者必须从零上下文开始。

这道题考察的是 九种编排模式与 AgentTask 执行契约 / Checkpoint 机制：Sequential / Parallel / Router / Supervisor / Handoff / Evaluator-Optimizer / Group Chat / Debate / Event-driven 各自的机制与主要代价是什么？AgentTask 契约（子目标 / 依赖 / allowedTools / outputSchema / maxIters / deadline）如何把「约定俗成」变为「运行时强制」？失败状态机与 Checkpoint 落盘如何设计。

模式库的沉淀路径：单链 Sequential（最直观）→ 并行 Parallel + 归并（提效）→ Router（专家路由）→ Supervisor / Handoff（控制权管理）→ Evaluator-Optimizer（质量循环）→ Group Chat / Debate（观点碰撞）→ Event-driven / Peer（松耦合）。成熟系统多为混合——如投研类系统采用 Sequential + Parallel + Aggregator 组合，而非单一模式。

九模式与代价对照：

AgentTask 契约字段：子目标、依赖关系、allowedTools（工具白名单）、outputSchema、maxIters、modelTimeout、deadline、maxAttempts——由运行时强制执行而非口头约定。状态机：PENDING → READY → RUNNING → (SUCCEEDED / FINAL_FAILED / WAITING_INPUT / RETRYABLE_FAILED / CANCELED)。

• 并行判定：输入就绪且互不读取对方中间结论 → 可并行；需要对比结论 → 必须等待；外部副作用（通知 / 改代码）交单一执行者或加幂等保护。
• 冲突处理分层：状态写冲突按角色分槽 / 追加集合 / CAS / 版本号；观点冲突保留来源结构化 claim（带 scope / observedAt / sourceTool）交归并器裁决；所有权冲突用 Lease + Fencing Token；副作用冲突用幂等键 + 业务唯一约束。
• 失败恢复分类：输入 / 契约错 → 修正或终失败；权限拒 → 终止或等授权；瞬时故障 → 指数退避重试；超时 → 取消未完但保留成功部分；质量差 → 降级 / 跳过；代码错 → 快速失败。
• Checkpoint 设计：存「可校验位置」——材料清单、Artifact、审批参数；区分单 Agent 会话态与 Workflow 运行态；超阈值转人工（WAITING_INPUT）时存 Checkpoint 并释放资源，恢复时重校验权限 / 版本 / 业务状态。
• 通信选型：进程内固定 Workflow 直接方法调用最简；跨进程 / 团队 / 安全域用 A2A（读 Agent Card → 建 Task → Artifact 交付）；外层代码控 DAG，限制最大并发、设阶段 Deadline。

• Supervisor 与 Handoff 的控制权差异？Supervisor 保留控制权（结果回归主 Agent 归并，主 Agent 是瓶颈但边界清晰）；Handoff 整体移交（下一步由接手者主导，灵活但会话与权限边界维护成本高）。频繁往返的协作用 Supervisor，单向接力用 Handoff。
• 为什么辩论不保证更正确？Debate 的收敛取决于裁判与停止条件；无停止条件时双方重复争论、立场极化；需要明确「以证据分裁决 + 轮次上限」。
• Fencing Token 解决什么？Lease 过期后旧持有者「僵尸写」—— fencing token 单调递增，存储端拒绝旧 token 写入，这是分布式系统经典方案在多 Agent 域的直接复用。
• EvalRecord 式可追溯在编排层的对应物？每个 AgentTask 的执行留痕（attempt / 模型 / 耗时 / 失败原因 / Checkpoint URI），支撑事后归因与回放。

• Group Chat 无停止条件：轮转发言直到上下文爆炸；必须设轮次上限 + 主持人裁决节点。
• 归并节点不做冲突裁决只做拼接：观点冲突被「缝合」进答案，结论自相矛盾；归并器必须持有 claim 元数据做显式裁决。
• 重试不看错误类型：对契约错误重试三次纯属烧钱；恢复策略必须按错误分类路由。
• Checkpoint 只存状态不存校验物：恢复时无法验证「存档时的世界还是现在的世界吗」（材料版本 / 权限 / 业务状态），重放即错。
• Handoff 移交全部历史：接手者上下文爆炸且带入前序偏见；移交应带「结论 + 引用 + 未决问题」，原始过程留 Artifact 库。

这道题考察的是 评测与监控的职责分界及四类评测设计：评测（开发期主动发现问题、发布前阻断回归）与监控（上线后观察分布漂移）为何互为延伸而非替代？公开 benchmark 为什么无法替代自建业务评测集？离线评测 / Trace 回放 / 线上灰度 / 回归 CI 四类评测各自解决什么盲区。这是 AI 质量保障体系的总纲题。

从「跑榜单」到「建体系」：初期依赖公开 benchmark 选型（粗筛明显不合适模型：中文弱 / 窗口小）；实践暴露其三大盲区——覆盖不了业务分布（电商退换货 / 促销规则）、覆盖不了真实脏输入（错别字 / 截图 / 多语言）、覆盖不了低频致命失败（客服答错退款、代码 Agent 执行危险命令）。体系化评估随之形成「离线 → 回放 → 灰度 → 监控」四层闭环。

评测 vs 监控：评测是开发期主动——固定评测集、重放、灰度，发布前阻断回归；监控是上线后被动——持续观察指标分布波动，发现漂移（供应商静默升级模型、知识库更新改变召回分布）。监控是评测的延伸而非替代：它发现「世界变了」，评测验证「我们还能打」。

四类评测的互补结构：离线评测（冻结 Golden Set 版本，新旧结果同表对比，绑定 Prompt / 模型 / 检索策略变更）→ Trace 回放（生产采样真实请求带完整上下文，新版本重跑，补 Golden Set 盲区）→ 线上灰度（新版本接少量真实流量，灰度组 vs 对照组）→ 回归 CI（能力集追踪改善 + 回归集守门）。

• 核心指标分层：检索质量（Recall@k / Hit Rate@k / MRR / Context Precision）；生成质量（Faithfulness / Answer Relevance / Completeness / Noise Sensitivity）；Agent 工具（任务完成率、工具选择精确率 / 参数准确率、错误恢复率、pass@k 能力上限 / pass^k 生产稳定性）；结构化输出（JSON 合法率 / Schema 通过率）；安全与成本（越权率 / 幻觉率 / TTFT / Token 数）；代理指标（追问率 / 转人工率——需结合场景解读，不能孤立看）。
• 监控双轨：固定快照回归（查改动回归）+ 实时能力探针（查真实世界适应）；告警基于历史基线 / 控制图，而非拍脑袋阈值。
• 启动路径：先建 20–50 条真实轨迹小评测集把「猜」变「看」，再逐步扩分层覆盖。

Python：离线评测 + 灰度 + 漂移监控四类评测的最小可执行骨架

# eval/offline.py —— 离线评测：自建 Golden Set 而非公开 benchmark
import json, statistics
from pathlib import Path

def load_golden(path="eval/golden.jsonl"):
    return [json.loads(l) for l in Path(path).read_text().splitlines() if l.strip()]

def evaluate(predict_fn, golden=None):
    rows = []
    for case in golden or load_golden():
        out = predict_fn(case["question"])
        rows.append({
            "id": case["id"],
            "exact": out.strip() == case["expected"].strip(),
            "faithful": contains_evidence(out, case["references"]),
            "latency_ms": out.meta.get("latency_ms", 0),
        })
    return {
        "n": len(rows),
        "exact_rate": sum(r["exact"] for r in rows) / len(rows),
        "faithfulness": sum(r["faithful"] for r in rows) / len(rows),
        "p95_ms": statistics.quantiles([r["latency_ms"] for r in rows], n=20)[18],
    }

# 线上漂移监控：只观察分布，不做阻断；与离线门禁职责分离
def drift(baseline, window):
    return {k: abs(window[k] - baseline[k]) / max(baseline[k], 1e-9)
            for k in ("exact_rate", "faithfulness", "p95_ms")}

if __name__ == "__main__":
    print(json.dumps(evaluate(predict), ensure_ascii=False, indent=2))

Java：CI 回归门禁，把评测结果变成可机器判定的发布闸口

// Java / JUnit 5：读取 Python 评测产物，非劣效判定后决定是否放行
@Test
void evalGateIsNonInferior() throws Exception {
  EvalReport cur = mapper.readValue(Path.of("target/eval/current.json").toFile(),
                                    EvalReport.class);
  EvalReport base = mapper.readValue(Path.of("eval/baseline.json").toFile(),
                                     EvalReport.class);

  double delta = 0.02;   // 允许的回归幅度
  assert cur.n() >= 100 : "样本量不足，门禁不生效";
  assert cur.faithfulness() >= base.faithfulness() - delta
      : "忠实度回归超过阈值";
  assert cur.p95Ms() <= base.p95Ms() * 1.10
      : "p95 时延劣化超过 10%";
}

record EvalReport(int n, double exactRate, double faithfulness, double p95Ms) {}
// CI：python eval/offline.py > target/eval/current.json && mvn -q test

• 为什么代理指标会「说谎」？满意反馈率受用户习惯影响、转人工率受分流策略影响；代理指标只能作辅助信号，主判据必须回到任务成功率与质量指标。
• Trace 回放的「快照陷阱」？只存 URL 不存正文快照，页面更新后无法复现当时检索内容，回放失效——证据快照（网页正文 / 哈希）必须落库。
• 供应商静默升级如何发现？固定探针集每日重放，指标基线偏移即告警；这是监控层独有职责——离线评测集发现不了「模型在夜里被换了」。

• 拿公开榜单当业务门禁：榜单分高 ≠ 业务场景能打；业务分布必须自建评测集覆盖。
• Golden Set 只收高频样本：低频致命失败（退款错误 / 危险命令）不进集，门禁形同虚设；分层采样优先「不满意 / 追问 / 转人工 / 边缘案例」。
• 评测集与被测系统同源腐化：评测集长期不更新，系统「过拟合」评测集；季度复查 + 失败样本回流 + 保留集防过拟合。
• 灰度通过即停止观测：新版本的问题常在长尾场景延迟暴露；灰度通过后仍需双轨监控接续。

这道题考察的是 Golden Set 的建设方法论与 LLM-as-Judge 的防偏差设计：评测集的四个来源（日志分层采样 / 人工构造 / 失败回填 / 冷启动合成）与「分层比总量关键」的原则是什么？Judge 的打分体系（规则拦硬错误 + LLM 评开放语义 + 人工复核高风险）如何设计？位置 / 冗长 / 自我强化 / 有限推理四类偏差的对策是什么。能否说清「所有 Judge 必须先过人工校准集」这条铁律。

从人工全检到分层自动评测：初期纯人工评审（不可扩展、口径漂移）；随后规则断言（只能校验格式 / 枚举等硬错误）；LLM-as-Judge 出现后开放语义可自动评，但随即暴露四类系统性偏差——工程实践最终收敛为「规则 + Judge + 人工」三明治架构，且 Judge 本身要被校准。

Golden Set 四来源与使用原则：① 生产日志分层采样（优先不满意 / 补充追问 / 转人工 / 边缘案例，非仅高频）；② 人工构造（正常路径 + 缺失信息追问 + 对抗样本如越权退款 / Prompt 注入）；③ 失败案例回填（线上投诉确认后转用例）；④ 冷启动合成（知识库种子 + RAGAS 生成 + 人工审核——只补初始覆盖，不作门禁）。扩展手段：蜕变测试做输入 / 上下文 / 工具 / 状态扰动；保留集防过拟合调参。分层比总量关键：正常 / 边缘 / 对抗 / 高权重失败分层，高权重失败单独设门禁（一票否决）。

LLM-as-Judge 打分设计：Reference-based（有参考答案，事实型业务尽量补）/ Reference-free（依问题与约束评判）；规则评测拦硬错误 → LLM-Judge 评开放语义 → 人工复核高风险；Judge Prompt 含评测员角色 + 维度锚点（Faithfulness / Relevance / Completeness 分档）+ 结构化 JSON 输出（pass / fail、score、reason、category、confidence，低置信转人工，允许 Unknown）。

四类偏差与对策：

CI 集成：区分能力集（追踪改善，初始通过率不必高）与回归集（迁入 CI 作门禁）；阈值组合 = 绝对（如 Faithfulness < 0.75 不通过）+ 相对（任务完成率下降不超过 5%）；PR 阶段只跑核心回归集（规则 / 校准器），完整集放主分支 / 定时任务；Trial 间环境版本化隔离。

• 为什么 Judge 必须过人工校准集？Judge 也是模型，其判定本身有偏差；用人工标注的校准集测 Judge 与人的一致率，一致率不达标就不能上岗——「用模型评模型」的信任链必须落到人工锚点。
• G-Eval 什么时候用？复杂任务（多维度综合评判）借其 CoT + 表单式打分；简单格式校验不必上长推理链，规则直判更快更稳。
• 评测集如何防泄漏？评测样本若混入 RAG 知识库 / Few-shot，等于开卷考试；评测集与知识源物理隔离 + 定期查重。
• 为什么评估器可信度优先于其余机制？闭合验证环、步数预算、状态准入、路径级安全都依赖「测得出退化」这一信号；若评估集被生产流量污染，或评分由同一概率组件自评，信号本身失真，其余机制会朝错误方向优化。落地顺序上先冻结盲集快照、隔离评估器归属、给每次评测留版本号与回放入口，再谈护栏强度；评测集与调优样本必须严格隔离。

• 单一 Judge 打天下：不做偏差防护，同源互评自我强化；关键场景必须交叉 Judge + 人工抽核。
• Golden Set 只增不减不复查：过期用例（旧政策 / 下线功能）持续产生误报；季度复查清理。
• 冷启动合成集直接当门禁：合成样本分布偏离真实流量，门禁形同虚设甚至误杀。
• 阈值拍脑袋：「下降 3% 就停」的死板百分比不看方差——非劣效界值应按历史方差与样本量计算（详见 A06.03）。

这道题考察的是 灰度发布的非劣效界值设计与 Java 侧 EvalRecord 落地：为什么「下降 3% 就停」是错误的门禁方法（不看方差与样本量）？非劣效界值如何依据历史方差计算？EvalRecord 单条记录的字段集（promptVersion / datasetVersion / evidenceSnapshotUri / rootCauseLayer 等）为何这样设计？评测 Harness 的职责边界与环境隔离要求是什么。

从「感觉没问题」到「统计门禁」：早期灰度靠人工看几条 Case 决定放量；随后固定百分比阈值（简单但误判率高——小样本下 3% 波动纯属噪声）；成熟实践引入 A/B 实验规范：实验前写入发布规则、依历史方差定非劣效界值与样本量、看效应量 + 置信区间决策。Java 侧配套沉淀 EvalRecord / EvalRunSummary 结构与 CI 门禁集成。

非劣效设计的要义：目标不是证明「新版更好」，而是「新版不比旧版差（在可接受界值内）」。界值 δ 与样本量的确定：依据历史运行方差（同版本重放的分数波动范围），要求「新版 - 旧版」差值的置信区间下界 > -δ；方差大 → δ 放宽或样本量加大，方差小 → 可收紧。这解释了为什么固定百分比错误：同一 3% 在高方差场景是噪声、在低方差场景是灾难。

灰度判定组合：结构化输出规则自动评（格式 / 枚举全量判）+ 开放题 LLM-Judge 采样评 + 用户反馈辅助（满意 / 转人工）；门槛实验前写入发布规则，防止「看到结果再定标准」的确认偏误。

• 评测 Harness 职责：读评测集 → 调被测系统 → 跑 Grader → 存结果（分数 / Trace / 版本）；Agent 场景必须环境隔离（防缓存 / 文件残留污染 Trial 间独立性）。
• EvalRecord 单条字段：taskId、trialId、promptVersion、modelId、datasetVersion、taskAsOf（动态任务时间点）、timezone、environmentVersion、evidenceSnapshotUri、inputHash、outcomeStatus、scores、judgeModel、errorCategory、rootCauseLayer、confidence、gitCommit——设计意图：任一条结果可追溯到「哪个版本组合 + 哪份证据 + 哪层出错」。
• EvalRunSummary 汇总：avgScores、passRates、baselineScores、passedRegression、regressionDetails——直接供 CI 门禁消费。
• 门禁落地：PR 阶段跑核心回归集（规则 / 校准器，分钟级）；完整 Golden Set 放主分支 / 定时；能力集指标只追踪不拦截。
• 早期提效：可用 Coding Agent 搭轻量 Harness 与脚本，但业务口径与最终决策必须人确认。

• 为什么 EvalRecord 要存 evidenceSnapshotUri？评测结论的可复现性依赖证据快照——只存「检索到了什么文档」的引用 URL，文档更新后无法复核；快照（正文 / 哈希）落对象存储，结论才可审计。
• rootCauseLayer 为什么是关键字段？失败归因到层（检索 / 生成 / 工具 / 编排）才能定位改哪里；没有归因维度的评测只能报「挂了」，不能指导修复。
• taskAsOf 解决什么？动态任务（时效性问题）的「正确答案」随时间变化；记录任务时间点，才能正确判定「当时答错」还是「现在变错」。
• 环境版本化为什么必要？工具版本 / 知识库版本 / 系统提示版本任一变化都会影响结果；环境不变异，分数波动才可归因于被测变更。

• 实验后定标准：先看结果再挑阈值，必然选出对自己有利的口径；门槛必须在实验前写入发布规则。
• 小样本下结论：灰度 1% 流量跑 1 天就全量，样本量不足置信区间宽到没有意义；样本量按历史方差预估。
• 环境不隔离：Trial 间共享缓存 / 临时文件，前一个 Trial 污染后一个，评测结果不可信。
• 只存分数不存 Trace：回归挂了却无法定位根因层，评测沦为「红绿灯」而非「诊断仪」。

评估器是其余治理机制的信号来源：门禁、路由、回滚都依赖它。本题考察基准为何可被刷分、评测集为何会被自身输出污染，以及如何让评估器保持独立与可信。

从人工抽查到评估器治理：早期靠人工看样例；随后建固定指标与 Golden Set；再引入 LLM-as-Judge 扩覆盖；当指标成为发布目标后，出现刷分、过拟合与 judge 被操纵；当前把评估器独立性列为最高优先级。

指标一旦成为优化目标，就不再可靠地度量原目标。评测集若直接吸收生产流量，会被系统自身输出污染，形成自证循环；judge 与被测模型同源时，共同偏见会被放大成「一致通过」。因此评估可信度优先于验证环、复合收缩、状态准入与路径级安全。

评估集与调优样本严格隔离；盲集快照冻结并按期轮换；judge 与被测模型分属不同供应方或不同版本族，判定须带可核对的硬证据；对输入做注入检测，防止「忽略评分规则」类指令影响判定；记录评测集版本、judge 版本与通过率漂移，异常升高即复核是否刷分。

为什么「让第二个模型打分」不等于独立验证？同源模型可能共享训练偏见与失败模式，一致通过只说明同源。为什么发现刷分后必须轮换盲集？泄漏的盲集已失去判别力，继续沿用会让门禁变成假绿。

训练集与评测集共用；线上流量直接回灌基线；judge 与被测同模型；只看平均分不看分布与长尾；盲集泄漏后不轮换；把评估器输出当不可质疑的结论。

这道题考察的是 AI 系统四大风险面与分层防护体系：Prompt 注入 / 越权访问 / 数据泄露 / 内容违规的典型表现与防护方向分别是什么？为什么「输入层 → 执行层 → 输出层 → 数据层」四层防护缺一不可？核心认知是：模型输出不可信、一切外部输入不可信，安全是「执行侧」问题——靠 Harness 硬边界与后端强控制，而非靠提示词礼貌请求。

攻击面随能力扩张而扩张：纯对话时代风险集中在内容违规；工具调用（FC）时代出现越权执行；RAG / Memory 普及后出现间接注入（网页 / 邮件 / 工具结果夹带指令）与跨租户泄露；MCP / 多 Agent 生态带来供应链风险（恶意 Server / Skill / 知识库投毒）。防护体系从「内容审核」单点演进为「四层纵深 + 供应链审查」。

四大风险面：

四层防护：输入层（注入检测 / 输入隔离 / 工具白名单）→ 执行层（权限校验 / 审计 / 失败回滚）→ 输出层（内容审核 / 引用校验 / 敏感信息过滤）→ 数据层（向量数据脱敏 / 用户隔离 / 加密）。设计六原则：模型输出不可信（视为待校验的操作建议）；后端兜底限制损害；全面不可信输入（用户 / 网页 / RAG / Memory / MCP / Skill）；最小权限精细拆分；分层防御（提示词降概率 + 后端强控制 + 隔离 + 审计）；安全 Badcase 随版本化回归。

• 间接注入是 Agent 时代主攻击面：模型读到的网页 / 邮件 / RAG 片段都可能是攻击载体；对策 = 把「读到指令」与「执行指令」隔离——执行一律走权限校验，不因「内容里这么说」而放行。
• 检索安全顺序：先按 tenant_id + ACL 过滤再取 TopK，而非取完再滤（后滤时越权文档已进上下文）。
• 网络出口管控：HTTP 工具出口白名单，拒绝私网与云元数据地址（SSRF 防护）。
• 供应链审查：三方 MCP Server / Skill 的源码、依赖、权限三审；知识库写入走审核管道防投毒。
• 安全 Badcase 回归：注入样本 / 越权样本随模型 / Prompt / Schema / MCP / Skill / 权限版本化回归，防「改一处破一线」。

• 为什么「分隔符防护」不等于安全？System / User 分隔符只帮助模型区分来源，不阻止危险执行；带副作用的工具必须在代码层鉴权 + 沙箱 + 人工审批——分隔符是提示词工程，不是访问控制。
• 多 Agent 级联的风险放大？目标劫持（某 Agent 被注入后劫持协作目标）、故障级联、责任难定位；对策 = 每个 Agent 独立权限域 + 级联调用审计链 + 跨 Agent 传递内容按不可信输入处理。
• 安全与体验的平衡点？按操作风险分级：只读操作自动放行（留审计）、低危写操作自动 + 事后审计、高危操作（退款 / 删除 / 外发）人工确认——一刀切全人工会杀死可用性，一刀切全自动是事故温床。
• 为什么逐工具授权拦不住组合越权？单工具权限检查只看这一步能不能做，而真实风险来自多步组合后的可达状态：读库、拼装、写外部接口，每一步都合规，合起来却完成了从未被授权的数据外传。因此权限预算必须随值在工具链上流动，组合只能收紧不能放宽；每次调用携带当前剩余预算，网关在链路上做累计算，而不是在入口做一次静态判定。

• 靠提示词「请求」模型别越权：提示词是概率性约束，不是访问控制；硬边界必须落在代码与权限系统。
• RAG 先取后滤：越权文档先入上下文再过滤，泄露已发生；过滤必须前置到检索阶段。
• Trace / 缓存无租户隔离：调试日志与语义缓存跨租户复用即泄露；缓存键 / Trace 索引必须带租户边界。
• Token Passthrough：把用户令牌原样透传给三方 Server，等于交出身份；网关代持并按最小范围签发。

这道题考察的是 合规要求在 Java/Spring 侧的工程落地：身份如何与模型解耦（ExecutionContext 不进模型可改参数）？四层校验（结构 → 语义 → 资源 → 风险）与幂等键 / 审批 Token 绑定如何设计？工具状态机（超时进 UNKNOWN 对账不重放）与 ToolAuditEvent 审计字段如何支撑问责与被遗忘权。核心是「合规不是文档，是可执行的代码结构」。

合规压力的三波演进：个人信息保护 / 数据出境 / 训练数据版权的静态合规 → 生成内容审核与违规拦截的动态合规 → Agent 时代「自主操作」的可解释与问责（AI 决策可解释、责任边界、算法公平性）。工程响应从「制度文件」演进为「代码级结构」：身份上下文、状态机、审计事件、幂等键成为标准件。

身份与决策分离：ExecutionContext(tenantId, userId, authorities) 来自登录态，不进模型可改参数；执行前服务端用 tenantId + orderId 重算权限，绝不信任模型输出的租户字段——模型参数只是「建议」，鉴权事实只认服务端会话。

四层校验链：validateProposal（结构合法）→ refundPolicy.check（业务语义）→ authorizationService（资源权限）→ 风险策略（限频 / 人工审批）；IdempotencyKey 由服务端生成并绑定 commandHash，审批 Token 绑定参数——参数变更即重批。

工具执行状态机：PENDING → EXECUTING → SUCCEEDED / FAILED / UNKNOWN；超时进 UNKNOWN，走对账而非盲目重放（重放可能重复副作用）。

• 审计事件设计：ToolAuditEvent 记录请求 / 租户 / 用户 / 工具 / 参数 Hash / 风险级 / 决策 / 幂等键 / 状态；PII 不全文入库、加密受控存储——审计要能问责，也要能「被遗忘」（删除请求可定位并清除该用户全部 PII，同时保留脱敏后的审计骨架）。
• 多租户隔离清单：RAG 检索 / Memory namespace / 缓存键 / Trace 索引全部带租户与权限边界；被遗忘权落地 = 数据地图（该用户数据分布在哪些库 / 索引 / 缓存）+ 删除编排 + 审计留存。
• Spring AI 安全层：仅传当前身份允许的 ToolCallback；自定义 ToolCallbackResolver 拒绝未授权工具名；ToolCallingManager 归一化 + 鉴权 + 幂等；Advisor 链上的安全拦截控预算 / 阻断（上述类名与职责划分以所用版本官方文档为准，需核实）。
• AOP 审计切面：工具执行统一过注解切面，审计逻辑与业务代码解耦，防「新增工具忘埋审计」。

• 为什么审批 Token 要绑定参数？用户审批的是「退款 100 元」，模型后续把参数改成 10000 元再执行——Token 不绑参数则审批被偷换；绑定后参数任何变化都使 Token 失效、需重新审批。
• UNKNOWN 状态为什么不能重放？超时可能意味着「已执行但响应丢失」；重放 = 可能双倍退款。正确动作是查对账系统确认最终态，对账失败转人工。
• 审计与被遗忘权的张力如何解？审计记录去标识化（存 Hash 不存原文），PII 单独加密存储并带索引；删除请求清除 PII 与关联明文，保留去标识审计骨架满足问责要求——两全的关键是「存储分层 + 可重构造」。

• 信任模型输出的身份字段：模型被注入后改 tenantId 即越权；身份永远来自服务端会话，模型参数只是建议。
• 幂等键由客户端 / 模型生成：可被伪造或碰撞；幂等键必须服务端生成并绑定业务命令哈希。
• 审计记录明文存 PII：泄露面扩大且无法响应删除请求；去标识 + 加密分层是前提。
• 数据地图缺位：被遗忘权请求来了不知道该用户数据散落何处，删除不彻底即违规；先建数据地图再做删除编排。

这道题考察的是 Spring AI 安全层组件与大模型网关的架构定位：Spring AI 的 ToolCallbackResolver / ToolCallingManager 与 Advisor 链上的自定义安全拦截各自承担什么安全职责（具体类名以所用版本官方文档为准，需核实）？大模型网关（API 网关能力 + 模型调用控制面）为什么「Router 只选模型，Gateway 管整次调用全生命周期」？其六项核心能力与自研组件清单、演进顺序（先工程治理再智能路由）是什么。

网关从「代理转发」到「治理控制面」：初期应用直连模型供应商——模型名写死、Key 分散、限流靠供应商、成本不可见、日志缺失、SDK 各家一套；网关化第一版解决「统一 API + Adapter + 日志」，随后补路由 / Fallback / 预算五维限流，最终成为模型调用的统一治理入口。选型参考：起步轻量自研；多供应商快速接入看 LiteLLM；已有 Kong / Cloudflare 体系可评估其 AI Gateway 能力。

Spring AI 安全层三组件：

• ToolCallbackResolver：解析工具时的准入守门——按当前身份过滤可见工具集，未授权工具名直接拒绝（工具白名单的代码化）。
• ToolCallingManager：工具执行统一入口——参数归一化 + 鉴权 + 幂等，执行逻辑不散落在业务代码。
• Advisor 链安全拦截（如自定义安全 Advisor；ToolCallingAdvisor 是否为当前版本公开 API 需核实）：预算控制（Token / 次数）与危险调用阻断，Advisor 链机制天然适合横切安全策略。

网关六项核心能力：多模型统一接入（OpenAI 兼容入口 + Provider Adapter 转各家协议）；模型路由（按 scene / Token / 套餐 / 风险 / 模型状态，绑定 tier 而非具体模型名）；限流配额（用户 / 租户 / 模型 / 供应商 / Token 五维，estimate → reserve → usage → reconcile 预算流）；故障处理（重试 / Fallback / 熔断）；观测审计（request_id + route_reason + usage 脱敏留存）；成本归因。

• 自研组件清单：API Adapter / Auth-Tenant / Prompt Renderer / Token Budget Estimator / Model Registry / Router / Provider Adapter / Retry-Fallback / RateLimiter / Cost Tracker / Observability / Audit Log；第一版先统一 API + Adapter + 日志，再补路由 / Fallback / 预算。
• 演进纪律：先工程治理（统一接入、可观测、可审计），再智能路由（按成本 / 质量 / 负载调度）——反过来做，路由策略没有数据支撑。
• 安全设计落位：安全校验沉到环境（规约文件 / Hook / 测试）形成复利；网关层统一鉴权 + 五维限流 + 审计是执行侧安全的最后防线。
• 配额预算流：调用前 estimate 预估 → reserve 预占 → 完成后 usage 上报 → 定时 reconcile 对账，防「预占泄漏」与「超发」。

• 为什么「绑定 tier 而非模型名」？业务代码引用「tier-standard」，网关决定 tier 内具体模型——供应商切换 / 降级 / 灰度对业务透明；引用具体模型名则每次换模型都要改业务代码。
• 网关必须是独立服务吗？不必。可以应用内轻量模块（共享进程省一跳）起步；当多应用需要统一治理时再独立部署——定位是「控制面」而非「部署形态」。
• Spring AI 安全层与网关的职责边界？Spring AI 层管「进程内工具执行安全」（谁能调哪个工具），网关管「模型调用面安全」（谁能调哪个模型 / 花多少钱）；前者是应用内访问控制，后者是跨应用治理面，两层叠加而非互替。

• 网关只做转发不做审计：request_id、route_reason、usage 缺失，成本与故障无法归因；观测三件套是网关第一版底线。
• 业务直连供应商 Key：绕过网关的调用成为治理盲区（成本黑箱、无审计）；密钥统一由网关持有并轮换。
• 限流只按用户一维：供应商侧配额被打爆、单模型过载都无法防护；五维限流缺一不可。
• reconcile 缺位：预占的 Token 配额不释放，额度「越用越少」直至误杀正常请求；对账任务是预算流闭环的必要环节。

逐个工具都鉴权，仍可能通过工具组合越权。本题考察攻击面为何是路径级的、权限预算如何随值流动，以及发布前红队门禁与权限蠕变检测怎么落地。

从单点越权到组合攻击面：早期只检查单个工具的角色；随后发现「读文档 + 发消息 + 写文件」的串联可绕过逐点限制；再往后引入路径级权限预算与攻击面矩阵；当前把红队门禁做成发布卡点并持续检测权限蠕变。

安全属性不是各节点属性的并集，而是路径属性。权限预算应随值在工具链上流动且组合只能收紧不能放宽；逐工具鉴权原理上拦不住组合越权，因为它看不到前序步骤带来的能力与数据敏感度。

建立工具 × 数据敏感度 × 身份 × 副作用的攻击面矩阵；网关在每一跳重新计算剩余预算，高危组合强制业务终审；发布前跑红蓝对抗，覆盖间接提示注入、检索内容夹带指令、跨租户数据串联；用影子流量验证策略；审计权限变更并定期回收长期凭证。

为什么「每个工具都鉴权」仍会越权？鉴权看的是「谁能调」，组合攻击利用的是「调完之后能拿什么去调下一步」。为什么提示注入要按数据流向建模？注入内容往往来自检索或工具返回，而非用户输入。

只测单工具；忽略间接注入与工具返回里的指令；Agent 持有可写生产、删备份、绕终审的集中凭证；红队只在上线前做一次；权限变更无审计与回收。

与 A01 的边界：四组件与控制流的定义以 A01.01 / A01.03 为准；本卡只保留落地结构（层间接口与装配顺序）。

这道题考察的是 Agent 四组件的工程细节与三层结构的决策维度：LLM / 工具 / 记忆 / 规划各自的生产级设计要点是什么（工具设计四原则、记忆三子类型、System Prompt 岗位说明书）？Tools / Agent / Workflow 三层的本质区别为什么是「控制流由谁掌握」而非节点类型？能否说清三者是粒度不同可嵌套的三层，而非三选一。

从「组件清单」到「控制流谱系」：早期论述把 Agent 拆为四组件（LLM 大脑 / 规划 / 记忆 / 工具——类比老板 / 项目经理 / 档案室 / 外包团队）；工程实践随后发现更关键的判据是决策权归属：Tools 无决策只执行、Agent 由 LLM 运行时动态决策、Workflow 由开发者提前写死——三者可嵌套（Workflow 的节点可以是任意 LLM 调用、Tools 或 Agent），生产主流形态是 Agentic Workflow（Workflow 骨架 + Agent 节点）。

四组件的工程要点：

• System Prompt = 岗位说明书：定义角色、行为边界、输出格式；工程中是控制 Agent 行为最直接的手段。
• 工具设计四原则：职责单一（一个工具只做一件事）；描述精确（「查询公司内部销售数据库，支持按日期和产品类别筛选」远胜「查询数据」）；错误信息可操作（「参数 city 不能为空」能帮模型自纠重试，「Error code 400」不能）；参数简洁（能少传就少传，填得越多错得越多）。
• 记忆三子类型：语义（事实）/ 情节（事件经历）/ 程序（SOP）——完整分层与存储见 A02.03，本卡不重复。

三层结构判据：关键不是节点是什么类型，而是控制流由谁掌握——这一条同时解释了为什么 Workflow 的节点可以是 Agent（控制流仍是代码）。

• 自研 ReAct 循环骨架（Java 生产思路）：while (!taskDone && steps < maxSteps) 内完成「生成 → 解析工具调用（失败重试 / 模型自纠）→ 执行（带超时 + 权限校验 + 审计）→ 记忆追加（超限压缩）→ 完成判定（防任务幻觉）」；框架解决通用问题，生产需要在记忆策略、上下文装配、容错上深度定制——复杂场景手搓关键路径反而更可控。
• 工具接入选型：内部系统优先 MCP Server（标准化可复用）；遗留无源码系统用 CLI 封装（模型对 CLI 文本交互天然友好）；一次性任务直接 FC 内联定义。
• 执行结果校验：任务幻觉（声称完成但没执行工具）的对策是以工具真实返回为准，不信模型自述——「完成」必须是系统验证过的状态。
• 防死循环：max_steps 硬闸 + 相同工具连续 N 次调用触发换策略 + 人工确认。

• 为什么「执行方差」需要记录 seed 与版本？同输入不同结果来自 temperature > 0、工具返回时序、模型版本差异；核心链路 temperature=0 + 结果缓存 + 记录 seed / 版本，才能归因与复现。
• 「手搓 vs 框架」的判断信号？能说清「框架在某处替我做了什么、方法内部发生了什么」→ 理解它；只会调方法不知道里面 → 不透明黑盒。框架不是问题，「不理解就依赖」才是。
• Multi-Agent 容错三件套？子 Agent 超时（熔断 + 降级为单 Agent）、失联（心跳 + 任务重派）、并发修改冲突（乐观锁 / 单写者原则）——通信问题与一致性问题手段不通用，须分层治理。

• 把 Agent 等同于插件 / 工具调用：漏掉「自主性」（自己决定用不用、何时用、用哪个）与执行闭环；模型只是大脑，执行是你的代码。
• 「记忆就是上下文」：记忆分两层（短期 context / 长期向量库），机制与用途不同；漏记规划与记忆组件是常见盲区。
• 把 Workflow 说成「多个 Agent 串联」：节点可以是任意类型，关键是谁掌握控制流。
• 延迟升高就换模型：先 Trace 定位（RAG 段 / 工具段 / 生成段），常见根因是串行工具调用与长上下文——并行工具 + 上下文瘦身往往更有效。

这道题考察的是 任务拆分方法论与 DAG 并行执行：为什么拆（context 有限、每步可验证、出错只重试那步）？静态拆分与动态拆分如何混合？依赖分析画 DAG 后「并行降低的是关键路径总时间而非每步时间」如何理解（端到端延迟降 40%–60% 的前提是什么）？以及可验证性三标准（完备 / 独立 / 拆分时同步写好验收标准）。

从「拍脑袋拆」到「契约化拆」：初期凭感觉拆步骤，执行中发现接口对不上、验证无从下手；成熟方法收敛为「静态主流程 + 关键节点动态 + 执行中自适应再拆」，并以 tasks.md / AgentTask 契约把目标、前置、范围、完成依据显式化——计划即状态，可接续、可审计。

为什么拆的根因：context window 有限，任务大则中间状态多（「桌面太乱」），模型难以持续追踪子目标；拆开后每步可独立验证、出错只重试那步。

拆分两思路：静态（写死 Workflow，可预测、难应对意外）vs 动态（Plan-and-Execute，灵活但规划质量不稳定）——混合策略：主流程静态 + 关键节点动态 + 执行中自适应再拆（先试，超步数 / 质量不达标才交规划器再拆，计算开销与任务难度成正比）。

验证三标准：完备性（步骤拼起来覆盖原始任务全部要求）；独立性（职责边界清晰无重叠）；可验证性（拆分每步时同时写好验收标准——步骤定义与断言成对出现）。原子操作判定：能写出清晰函数签名的大概率是原子的。

• 依赖分析与并行：画 DAG（节点 = 步骤、边 = 依赖），无依赖节点并发执行；并行降低的是关键路径总时间而非每步时间——实际项目端到端延迟降 40%–60% 的前提是依赖稀疏且 I/O 占主要耗时。
• Replan 触发条件：不是每步都触发（每步多一次调用），设「输出与预期差异大 / 执行失败」才触发；重规划时把已证明无效的路径写进新计划约束，否则是用更多 Token 重生成旧计划。
• tasks.md 落地：每任务记录目标 / 前置 / 范围 / 完成依据；执行中随实际信息更新剩余计划；完成勾选只标记「有证据的工作」。
• 行为导向拆分：从行为要求拆起再定代码范围——按技术层拆会让每层自行决定接口（前端 status / 后端 state / 数据库 order_status 没人让它们互相认识）；先确认共享接口、优先打通可验证链路。

• 为什么「并行前提」常被忽略？并行不仅要求依赖满足，还要求修改范围不冲突（两任务改同一文件会互相覆盖）；worktree / 分支隔离是并行的工程前提。
• 拆多细算合适？以「能理解、能检查」为准，一个任务可跨文件；按文件数拆或拆到每个函数会徒增交接成本。
• 自适应拆分为何开销可控？像递归展开的任务树——只有做不好（超步数 / 质量不达标）才展开，计算开销与任务实际难度成正比，简单任务不付复杂度税。

• 把「准确率高一些」当拆分收益：太模糊；正确表述是「根因是 context 有限 + 中间状态过多」，收益要落到「每步可验证、失败只重试单步、关键路径缩短」。
• 按技术层拆任务：接口约定无人守护，联调灾难；从行为拆起、先锁共享接口。
• DAG 并行不控并发度：无最大并发限制的扇出会打爆下游（模型限流 / 工具限流）；限并发 + 阶段 Deadline。
• 任务全勾但整体不对：局部通过 ≠ 整体正确；必须有真实联调与总需求回归两个收尾任务。

与 A08.02 的边界：A08.02 讨论任务级 DAG 与依赖分析，本卡只讨论一次模型决策内同时发起的多次工具调用。考察并行带来的三个新问题——返回乱序、部分失败、写操作冲突——以及结果归并契约为何必须先于并发代码定义。

从串行循环到带契约的扇出：早期 ReAct 循环一次只调一个工具，延迟随步数线性累加；随后把无依赖的工具批量发出，发现模型会把先返回的结果当作先发生的事实；再往后引入 toolCallId 归位与部分失败的显式表示；当前把「哪些工具可并行、结果如何合并」写进工具元数据，由执行层而非模型决定调度。

并行的收益来自 I/O 重叠，代价是顺序语义的丢失，具体有三个后果：① 返回乱序——完成次序不再等于逻辑次序，任何依赖返回顺序的推理都只是偶发正确；② 部分失败——超时与查无结果必须区分，否则模型会把「没查到」当事实写进结论；③ 写冲突——两个工具改同一资源时，并行度越高丢失更新的概率越大。因此可并行性不是运行期猜测，而是工具声明里的静态属性：只读且无共享状态的工具才可扇出，写操作按冲突域串行化。

CompletableFuture 扇出 + 有界线程池 + 单工具超时；结果按 toolCallId 写入有序容器，交付模型前按声明顺序排列而非按完成顺序。为每个工具声明 mergePolicy（并集 / 优先级覆盖 / 冲突报错 / 投票），归并阶段显式执行；部分失败统一表示为带 status 与 reason 的结果对象，禁止用空结果代替。写工具按 resourceId 哈希进单线程队列，状态合并用版本号加 CAS，冲突时返回 CONFLICT 交还规划层重决策。扇出前先算并发上限，避免打爆下游限流。

为什么不能让模型自己判断哪些调用可并行？它没有工具副作用的全局视图，判断本身还会随上下文长度波动，调度决策必须留在确定性代码里。为什么空结果不能代表失败？模型会把缺失解释成否定事实，进而输出「确认不存在」这类高强度错误结论。

把返回顺序当因果顺序；用 null 或空串表示超时；对写操作无冲突域约束直接扇出；无限并发打爆模型或工具限流；归并时静默丢弃冲突结果；把并行度当成可调参数而不写进工具元数据。

这道题考察的是 上下文压缩的预算公式与状态管理四层：70%–80% 只是「给输出与工具返回留余量」的一种拆法，不是定律，须用自有评测标定（机理见 A02.02）。滑动窗口 / 摘要压缩 / 重要性过滤 / 结构化抽取四类对策如何选？对话历史 / 业务状态 / 任务状态 / 长期记忆四层为何不能混放（「这次报告用英文」是业务约束不是用户永久偏好）？以及 Prompt Caching 为何是互补而非替代。

窗口爆满的四大后果：撞上限、成本飙升、延迟变长、注意力分散。四类对策成熟度递进：滑动窗口（硬截断，「金鱼记忆」）→ 摘要压缩（层级式防单次丢细节）→ 重要性过滤（保指令 / 决策 / 报错，丢寒暄；工程形态 = 观察遮蔽 + 主动压缩）→ 结构化抽取（抽成 JSON 状态骨架 + 近期原文拼接）。阈值的本质也从「拍比例」演进为「从任务预算算边界」。

阈值公式的推导：输入预算 = 总窗口 − 输出预留 − 工具增长预估 − 安全余量。以 32k 窗口为例：32,000 − 4,000 输出 − 2,000 余量 = 26,000 输入预算；若下一步预计 +6,000 工具结果，则 26,000+6,000 超限——当前输入只占 2/3 窗口也该提前处理。70%–80% 软阈值触发摘要、窗口硬截断兜底，是「容量口径」；「阶段完成提前整理」是「质量口径」，两者叠加。三类内容都要计入预算：聊天历史之外还有指令、任务状态、工具定义（几十个工具的描述即使没调用也进上下文）、工具结果。

状态管理四层：对话历史（证据）/ 业务状态（可信参数）/ 任务状态（流程控制）/ 长期记忆（跨任务）——同一句话放错位置后果完全不同。核心字段：core_intent（模型不能自行覆盖，用户明确修改才版本化）、current_subtask、pending_tools（先登记再执行）、completed_steps（只记可复用结论）、context_snapshot（带来源与版本）；session_id + task_id 分层（一会话多任务不搅）、state_version 乐观锁。

• 压缩组合策略：结构化抽取保任务骨架 + 滑动窗口保近期细节 + 摘要压缩过渡中间段；触发边界与压缩目标分开（26,000 触发 → 降到 20,000，防反复总结同一历史）。
• 压缩后检查三件事：大小回到预算内；目标 / 硬约束 / 关键参数 / 进度保留；消息结构完整（工具请求与返回按调用编号关联，不能删请求留孤立结果）。
• 增长估计：参考同类工具历史返回量分布（日志波动大，均值低估异常），工具返回后重新计数；工具可返回无限长内容时，完整日志存外部只回摘要 / 命中位置。
• 中断恢复：checkpoint 三问（哪个用户的哪个任务 / 哪一版一致状态 / 哪步可安全执行）；pending_tools 分流（succeeded 跳过 / failed 重试 / unknown 先去外部核对）；跨系统不存在「恰好执行一次」——副作用可幂等才是答案。
• 缓存定位：Prompt Caching 命中费用约重算 1/10，但命中内容仍占窗口——缓存省计算费、压缩省 Token 总量，两者叠加不互替。

• 为什么「压缩后 Agent 失忆跑偏」高发？把任务进度也压进了上下文——上下文（可压缩重建的 prompt 材料）与任务状态（系统权威数据）必须分开存储；压缩只动前者。
• 「运行停止 ≠ 任务完成」如何工程化？完成判定独立成模块，以可验证外部结果为准（订单状态 / 测试通过）；循环停了可能只是没 Token / 被限流 / 在等用户。
• 软硬双阈值为何必要？只有软阈值（按预算公式反推、常见落在 70%–80%）极端时仍可能漏；只有硬阈值（截断）信息损失大；软阈值保质量、硬阈值保不崩。

• 80% 阈值还是超限：没给输出与工具增长留空间；用预算公式而非拍比例。
• Token 降了任务失败多了：摘要压掉了硬约束 / 进度；压缩后必查「目标 / 约束 / 进度 / 消息结构」四项。
• 「这次报告用英文」被存成用户永久偏好：业务状态误入长期记忆；四层各司其职，写入前先判层。
• 把 Prompt Caching 当压缩替代：费用降了窗口还是爆；缓存与压缩定位不同。

这道题考察的是 反思机制、Multi-Agent Handoff 与容错三件核心设计：Self-Refine 闭环的两个关键 Prompt 设计（明确检查维度 + PASS 出口）是什么？Reflexion（Shinn 等，2023）带来多少提升（该文献报告 HumanEval pass@1 约 80%→91%，具体口径须核对原文，不当定律）？Handoff 移交什么、为什么必须设移交上限？Multi-Agent 容错为何必须分层（通信层：心跳 / 租约 / fencing token；一致性层：所有权 / worktree / 唯一 Integrator）。

反思从「调试手段」到「质量增强层」：Self-Refine（2023）确立「生成 → 评估 → 改进」闭环；Reflexion 加入「失败经验存记忆」实现跨尝试学习；工程上明确其定位——叠加在 ReAct / Plan-and-Execute 上的质量增强 buff，代价是 Token 与延迟（反思两轮该步消耗可达三倍，一般设上限 2–3 轮）。步骤级（错误早发现、开销大）vs 任务级（开销小、看整体一致性）按任务形态选。

反思闭环两个关键设计：① 评估 Prompt 必须有明确检查维度（否则流于表面「看起来不错」）；② 必须有 PASS 出口（否则无限挑毛病把对的改错）；改进 Prompt 必须同时传原始任务 + 原始输出 + 评估意见（缺一改进就盲目）。同模型自评有「自洽」偏见——独立 Critic Agent 互评视角更客观。

Handoff 移交内容：任务描述 + 已完成上下文 + 工具清单，控制权整体移交；必须设移交上限（已访问集合 + 次数上限）防 A→B→A 死循环。

容错两层：通信层（丢 / 重 / 乱 / 心跳停）——心跳 + 租约判失联、generation fencing token 拒绝旧代际写入（防「僵尸 Agent」复活覆盖新主数据）、checkpoint + 幂等键接管；一致性层（改同一文件 / 任务干两遍 / 语义冲突）——所有权认领从根上防重叠、worktree 隔离 + 乐观并发 + 热点短锁、唯一 Integrator 最终提交权（文本可合 ≠ 语义对，合并前跑编译 + 测试）。

• 反思工程参数：强依赖链任务用步骤级（10 步任务约 20 次调用）；独立步骤的报告类用任务级（只多一次调用）；上限 2–3 轮硬编码。
• 接管时序：租约到期判失联 → 新主拉起 → 先核对未决操作（幂等键查哪些做了一半）→ checkpoint 恢复进度 → 接管执行；僵尸防护靠 fencing token 而非「相信旧 Agent 会自己退出」。
• Handoff 治理：交接目标与接收条件写进路由规则（Orchestrator 介入 A→B→A 空转）；移交次数上限 + 已访问集合。
• 无进展循环治理：结构化错误分流（临时错误有界退避 + 随机抖动；参数 / 权限错误换参数或询问）；换路要求新动作与旧动作有实质差异（看状态差分：有无新证据、待办是否缩小——分页拉数据 / 限流重试也是同动作，不能按「动作重复」误杀）。

• 为什么「反思」不是独立流程？它是叠加在既有范式上的增强层；把 Reflection 当独立第三步会导致「先生成完再想是否要反思」的时序混乱——正确形态是评估者嵌在生成循环内。
• fencing token 的直觉？租约到期不代表旧 Agent 停止（可能只是 GC 慢）；给每代主节点的写入配单调递增代数号，存储端拒旧——分布式系统经典方案在多 Agent 域的平移。
• 为什么唯一 Integrator 必须「跑测试后提交」？Git 合并无冲突只说明文本可合，语义（接口契约 / 行为）可能已破坏；编译 + 测试是语义一致性的最低门槛。

• 反思无 PASS 出口：无限挑毛病把对的改错；评估维度明确 + PASS 机制 + 2–3 轮硬上限。
• Handoff 无防循环：A→B→A 无限转接；移交上限 + 已访问集合。
• 失联 Agent 恢复后覆盖新数据：旧会话写入没被拒；fencing token 拒旧代际。
• 动作重复一律按死循环杀：分页 / 重试也是同动作；看状态差分（新证据 / 待办缩小）再判。
• 通信层手段治理一致性问题：心跳重试解决不了「两个 Agent 改同一文件」；两层手段不可互替。

这道题考察的是 文档切割五级策略与父子块设计：固定大小 / 递归字符 / 结构感知 / 语义切割 / Agent 智能切割的适用与成本排序是什么？「语义截断」的本质为什么是「信息被拆散后每一半都不够强，检索全军覆没」而非「信息丢失」？父子块（小块 200 token 检索 + 大块 1000 token 返回）如何同时保住检索粒度与阅读完整性。这是 RAG 工程的第一块地基。

五级策略按质量与成本递进：① 固定大小 + 10–20% overlap（简单粗暴）；② 递归字符切割（分隔符优先级 ["\n\n","\n","。","！","？","；","，"," "] 逐级降级——最常用默认）；③ 文档结构切割（Markdown 标题 / 代码 AST 按函数边界 / 表格整块）；④ 语义切割（相邻句相似度骤降处下刀，质量最高）；⑤ Agent 智能切割（LLM 审视，最贵）。配套高级形态：句子窗口（单句向量化细检索，命中返回前后 N 句）、父子块、Late Chunking（先编码后切分，token 向量经注意力互感知后 mean pooling，跨块语境天然保留）、Contextual Retrieval（向量化前 LLM 看全文为每 chunk 生成背景说明）。

语义截断的本质：信息不是丢了，是被拆散后每一半的语义都不完整，向量表征强度不足以命中——overlap 只兜底（跨边界文字不丢失），解决不了完整语义被拆散。因此方案谱系从「兜底」（overlap）到「保质量」（语义边界 / 结构切分）再到「补背景」（父子 / 句子窗口 / Contextual Retrieval）。

存储三件套：每条 chunk = 向量（索引卡，负责「找到」）+ 原文（书页，LLM 真正阅读）+ metadata（书签，过滤 + 溯源）。整篇不能存：向量模型有输入长度限制 + 整篇压成一个向量细节被「平均掉」。

• 按文档类型选策略：纯文本固定 + 重叠；结构化文档语义边界 / 标题层级切且 metadata 带章节路径；代码 AST 按函数 / 类边界切（函数是最小语义完整单元）；表格整块转 Markdown（按行截断后「2 小时」脱离列名无意义）；高质量场景叠加父子或 Contextual Retrieval。
• 参数基线：chunk 500–1000 token 起步；overlap = chunk_size 的 10%–20%；父子块子 150–200 / 父 500–1000（子块检索、父块返回，ID 关联）。
• Contextual Retrieval 成本控制：完整文档是所有 chunk 请求的相同前缀——Prompt Caching 首次写入 1.25 倍计费、后续命中 10%；8k token 文档百万级成本约 1 美元出头；结合 BM25 混合检索 Top-20 检索失败率降约 49%。
• 工程组合拳：重叠切割兜底（必开）+ 语义边界保质量（结构化文档）+ 高质量场景叠加父子 / Late Chunking。

• 句子窗口与父子块怎么选？前者命中后动态扩展（实现简单，父块大小不可控）；后者提前存父子关系（父块大小精确可控，多一层存储管理）。
• Late Chunking 的适用边界？需要长上下文 Embedding 模型支持；对超长文档仍有窗口限制，超长时退化回分段 + Contextual Retrieval。
• 为什么「检索回来整篇笼统文档」是切分事故？整篇压一个向量细节被平均掉；chunk 化 + 粒度控制是检索信噪比的第一决定因素。

• 表格按行切：行脱离表头无意义；整块转 Markdown。
• 代码从函数中间截断：通用策略不适配代码；AST 边界切。
• 只调 overlap 不查切分质量：overlap 是兜底不是解药；语义拆散要靠边界策略。
• 为省 Token 删块边界：函数截半导致误判；保留完整函数 / 分支 / 类型。

与 A03.02 的边界：要不要上精排见 A03.02；本卡只展开 Bi-Encoder / Cross-Encoder / RRF。百分比是观察值。

这道题考察的是 两阶段检索（Bi-Encoder 召回 + Cross-Encoder 精排）与混合检索 BM25 + RRF 融合：为什么 Bi-Encoder 必须快而粗、Cross-Encoder 必须准而慢（拼接 [CLS] query [SEP] doc [SEP] 深度交互）？精排的量化收益（多跳 +40–50%、模糊 +30–40%、简单事实 +18%、幻觉率降约 35%）与候选集控制（Top-50~100 → Top-5~10）如何设定？RRF 为什么「只看排名不看绝对分数」。这是 RAG 检索质量的核心机制题。

从单路 TopK 到标准生产架构：Naive（向量 TopK 直塞）→ Advanced（多路召回 + RRF + Rerank）成为大多数生产形态。典型生产组合：Parent-Child 索引 + 向量 / BM25 / 多 Query 三路召回 + RRF 融合（k=60）+ Cross-Encoder 精排 + 带溯源 Prompt；提问质量差再加 Query 改写。

两阶段的第一性：Bi-Encoder 文档编码时不知道用户会问什么——信息压缩损失 + 无查询意图感知，所以快而粗；Cross-Encoder 把查询与文档拼接送入模型逐 token 深度交互，准而慢（每对都要过一遍模型）。架构结论：Bi-Encoder 负责百万级粗筛，Cross-Encoder 只对 Top-20~30 候选精排（对百万数据用 Cross-Encoder 不可行）。

RRF 的第一性：向量分数与 BM25 分数量纲不同不可比（像摄氏度和华氏度）；排名是通用语言——RRF 只用各路排名，被越多路命中的文档得分越高，免调参且对单路异常鲁棒。

BM25 与向量的互补机理：BM25 = 词频 × 稀缺度（TF-IDF 改进 + 饱和度限制），精确词强（型号 / 缩写 / 错误码）、同义词弱；向量语义强（「退货」≈「申请售后」）、精确词弱（「M4 Pro」被拉近到「苹果最新处理器」反而找不到字面）。

• 精排收益与参数：复杂多跳 +40–50%、模糊查询 +30–40%、简单事实 +18%，幻觉率降约 35%（均为观察值，非普适）；候选集 Top-50~100 粗筛、精排取 Top-3~10；不 Rerank 的双重代价——Token 暴涨 + Lost in the Middle。
• 多路并行：向量 + BM25 同时发起（延迟取 max 不加 sum）；图谱作为第三路（实体关系）按需叠加。
• 分层优化落位：索引层 Small-to-Big（父子 / 摘要索引 / 多粒度）；查询层四法；召回层三路 RRF；重排序层 Cross-Encoder——按症状选层（提问质量差上查询层、单路漏召上召回层、粗排精度不足上 Rerank）。
• 原始问题必须保留：改写可能丢细节，原始 Query 始终在检索列表中（它往往最精准）。

• 为什么调大 top-K 不是解法？相似度排序尾部很平，Top-20 与 Top-200 只是多塞无关 chunk 稀释 LLM 注意力，正确答案照样进不来；正确动作是多路召回 + 精排，不是调大 K。
• RRF 的 k=60 起什么作用？平滑常数，抑制单路极端排名的影响；工程上不敏感，默认即可，不必调参。
• 精排模型的延迟预算怎么算？Cross-Encoder 延迟 ≈ 候选数 × 单对推理耗时；控制候选数（20–30）是延迟的第一杠杆，其次轻量化精排器。
• 混合检索一定更好吗？绝大多数场景是（失败模式互补）；纯精确词场景 BM25 为主、纯语义场景向量为主——混合是默认，权重按业务分布微调。

• 精排候选集过大：1000 条全量重排延迟爆炸；永远只精排粗筛头部。
• RRF 之外还做分数归一化：把两路分数强行 min-max 到同一尺度再线性合并——量纲问题已由排名解决，多此一举且引入超参。
• 只上向量一路：精确型号 / 错误码类查询命中率惨淡；BM25 路是标配。
• 精排后不做阈值门控：最高分仍很低时照样生成，幻觉风险高；低分直接拒答（详见 A09.05）。

术语对齐：本卡的混合检索与重排在英文岗位描述里通常写作 hybrid retrieval / Re-rank；与上下文预算（Context Engineering，A02.01）共同决定送入模型的片段质量。

这道题考察的是 Query Rewrite 四法与 RAG 范式分层：直接改写 / HyDE / Step-back / 多 Query 各针对什么问题（口语指代 / 文体差异 / 问题太具体 / 角度单一）——为什么 HyDE 的机理是「答案到答案比问题到答案近得多」？Naive → Advanced → Modular 三代范式与 Self-RAG / CRAG / GraphRAG / Agentic RAG 四个高级范式的适用判据是什么。核心是「Query 质量决定后续所有环节的天花板」。

三代范式：Naive（线性三段）→ Advanced（固定流程打补丁：查询改写 / 混合检索 / Re-rank / 切割优化——大多数生产形态）→ Modular（模块乐高组合）。四个高级范式：Self-RAG（LLM 自主决策是否检索，需四类 reflection token 专门 SFT 训练，不能拿通用模型直接套）；CRAG（检索质量差时降级网络搜索 / 合并，三级路由阈值按业务调）；GraphRAG（社区摘要 + Map-Reduce 全局理解）；Agentic RAG（检索作为工具，路径由模型自定，多轮动态检索，最大迭代防死循环）。

四法各有针对性：直接改写治口语 / 指代（多轮对话补全「它」指什么）；HyDE 治文体差异——问句与陈述句在向量空间坐标有距离，先让模型生成假设答案再检索，「答案到答案比问题到答案近得多」（假设答案只需风格像文档，不需准确）；Step-back 治问题太具体（抽象一层先检索背景原理）；多 Query 治角度单一（一问多变体覆盖）。共同前提：原始问题必须保留在检索列表。

• 组合策略：多轮对话用直接改写（补指代）；专业库文体差异大用 HyDE；技术文档需原理支撑叠加 Step-back；复杂多维度问题用多 Query。每次改写多一次 LLM 调用——按场景选，不必全上。
• 范式选型判据：问题类型多样部分不需检索 → Self-RAG；知识库覆盖不全需兜底 → CRAG；实体关系复杂需全局理解 → GraphRAG；复杂多步骤需多轮检索 → Agentic RAG；四者可叠在 Modular 框架上组合。
• Self-RAG 落地警告：reflection token（Retrieval / Relevance / Support / Utility）需专门数据集 SFT 训进去；用开源微调版或自造数据，通用模型直接套无效。
• Agentic RAG 护栏：最大迭代次数 + 证据完整性核查（范围缺继续补查，防「搜几轮就认为查全了」）。

• 为什么说「Query 质量决定天花板」？LLM 只能根据送进的 context 回答，检索召回内容就是系统上限；生成层优化是锦上添花，检索层优化是从根本提上限，投入产出比最高。
• HyDE 什么时候会帮倒忙？知识库领域与模型常识偏差大时，假设答案方向错了把检索带偏；知识库领域明确场景用，配 Rerank 兜底。
• 「RAG vs 文件搜索」争论的本质？混淆了两个维度——搜索方式（关键词 / 语义，怎么匹配）与取资料流程（什么时候搜、读到什么是否继续）；前者是匹配算法，后者是「预建索引 vs 运行时自主探索」——索引定位 + Agent 读原文补查是生产最佳组合。

• 只用改写版本检索：改写丢细节；原始问题必须保留。
• 拿普通模型套 Self-RAG：reflection token 需 SFT；直接套不生效。
• Agentic RAG 无迭代上限：多轮检索失控烧钱；最大迭代 + 停止条件硬编码。
• 所有问题都改写：每次改写多一次调用；简单清晰的问题直接检索最快。

与 A03.03 / A09.03 的边界：图增强成本见 A03.03，Query Rewrite 见 A09.03；本卡只保留「何时从检索升级到图或 Agentic」的判据。

这道题考察的是 图增强检索与 Agentic RAG 的组合机理：向量检索单跳、无「关系」概念——为什么「多检索几次」替代不了图遍历（前提是知道下一步搜什么，但向量连边在哪都不知道）？「答案在多个节点之间的关系上而非某一文档里」的判据如何使用？组合工作流（向量入口定位实体 → 图接力遍历 → 合并上下文）怎么搭。

从「上图数据库热」到「判据先行」：GraphRAG 火热期一度「所有 RAG 都上图」；实践收敛出判据——多实体关系推理才上图，并沉淀出轻量组合模式：向量定位入口（在哪）+ 图一站站走（能到哪），替代昂贵的全量建图 + 社区摘要（详见 A03.03 的 GraphRAG / LightRAG 成本对比）。

向量检索的结构性缺陷：单跳语义匹配，没有「关系」表示——「A 供应商供应的产品的认证情况」需要跨「A→供应商→产品→认证」的关系链，这些内容分散在互不相似的文档块中，向量 TopK 凑不齐；而多跳检索的前提是「知道下一步搜什么」，向量连边在哪都不知道。图检索补的正是「关系结构」：实体为节点、关系为边，遍历即推理。

判据：当答案的核心在「多个节点之间的关系」而非「某一文档内的描述」时上图；纯描述性内容（「X 的定义」）向量足够。

• 组合工作流：向量入口定位起点实体 → 图遍历接力（小米 → 竞争 → 对手 → CEO）→ 合并多跳上下文给 LLM——「导航定位（在哪）+ 一站站走（能到哪）」。
• 图谱问答分工：向量检索答「像不像」（语义相似），图谱答「关不关联」（关系链）；实体消歧（别名 / 旧称合并）是图谱召回率的前提。
• Agentic RAG × 图：Agent 决定何时查图、查几跳、何时停止；图工具返回「路径 + 命中位置 + 片段」，证据不够 Agent 继续补查。
• 成本纪律：图构建（实体 / 关系抽取）按语料密度抽样触发，不做全量；关系少更新的库用追加式增量。

• 为什么「A 的投资方和 B 有什么交集」向量必败？答案在两组关系链的交集上，不存在单一文档包含它；向量单跳结构天然无解，图遍历是唯一路径。
• 图增强与长上下文的分工？关系推理上图、全文通读用长上下文窗口；两者可组合（图定位关系链后把相关文档全文拉入窗口）。
• 图谱维护的真相？实体抽取质量决定图谱质量——抽取幻觉污染图谱、实体不消歧图遍历断裂；抽取 Prompt 版本化 + 抽样人工校验是运维底线。

• 所有 RAG 都上图数据库：过度设计；判据是「多实体关系推理」。
• 实体不消歧直接建图：同名实体 / 别名分裂，遍历断裂。
• 图查询进同步主链不设预算：多跳遍历延迟不可控；限制跳数 + 超时降级向量。
• 以为「多检索几次」能替代图：多跳的前提是知道下一步搜什么；向量没有边信息，盲目多查只是噪声。

这道题考察的是 幻觉四层防线与检索门控：检索层幻觉与生成层幻觉为何要分开治理（门控拒答 vs Prompt 约束）。更新原子性与冲突裁决见 A21.03 的运维面，本卡不再复述证明。

幻觉治理从「Prompt 祈祷」到「分层设防」：① Prompt 约束（限知识范围 / 标来源 / 鼓励说「不确定」）——零成本必做；② RAG 检索增强（事实性幻觉可有明显下降（社区观察值 20–40%，随场景波动），不能完全消除）；③ 输出验证（LLM-as-Judge 交叉验证 / 规则校验关键数据 / 多次采样一致性）；④ 领域微调 + 不确定性量化（logprobs / 内部状态熵）。核心原则：把幻觉当工程问题而非模型缺陷。

幻觉两来源与对应防线：检索层幻觉（没召回，LLM 靠自身知识编造）——治法是检索质量门控（Rerank 最高分低于阈值直接拒答，阈值按业务调，经验 0.3–0.6，金融医疗偏高）；生成层幻觉（召回了但超发挥，加推断补细节——更隐蔽更常见）——治法是 Prompt 四规则（只用资料 / 没有就说无法回答 / 标注来源 / 不推断）+ 结构化溯源输出（claim + source_ids + confidence，系统可程序化验证编号真实且相关）。

更新与冲突不在本卡展开：先删后增与裁决次序的证明、以及刷新 / 灰度 / 脏读防护 / 对账，统一见 A21.03。本卡只守幻觉：检索没召回要拒答，召回了还超发挥要溯源。

• 门控阈值调法：用「已知在库 + 已知不在库」两组测试集跑 Rerank 分数分布找切点；低于切点直接拒答（「知识库中暂无相关内容」），把「自信答错」变「诚实说不知道」。
• 更新、元数据与冲突样本：入库字段、灰度切换、裁决评测样本都记在 A21.03，本卡不另写一套。

• 为什么「没召回时模型仍自信答错」？LLM 天然倾向持续生成，没有「不确定就停」的开关——幻觉是知识缺失的副产品；门控拒答是把「停止权」从模型手里拿回系统手里。
• 引用核查为什么不能全量做？多一次 LLM 调用成本高，只用于容错极低场景；常规场景用结构化溯源（编号可程序化验证）替代。
• 僵尸 chunk 从哪来？只增不删或局部更新会留下旧答案；对账与清理步骤见 A21.03，不在本卡重复。
• 来源权威度谁来定？来源注册表由业务负责人定义各领域来源等级（不拍脑袋全公司常量）；线上答案引用 source_id 与版本，文档判误时可快速定位传播范围。
• 为什么 RAG 结论必须绑定可回查证据？检索结果只是候选文本，模型可能引用错误版本、错拼片段，或把多个来源混合成从未存在的论断。证据绑定要求每个论断携带文档标识与片段定位，后置校验据此核对引用是否真实存在、是否被支持；无法绑定的结论按拒答处理，而不是降级为仅供参考。缓存命中后同样要做后置校验，避免命中被投毒的历史结果。

• 只靠 Prompt 约束「不要说谎」：低成本层不替代硬防线；必须叠加检索门控与结构化溯源。
• 门控阈值拍脑袋定：过松等于不设防、过紧把可答问题也拒掉；用「在库 / 不在库」两组测试集校准并定期复核。
• 引用了但不校验：编号可伪造或与论断无关；必须程序化校验 source_id 存在且相关，否则等于没做。
• 把领域微调当幻觉万能药：特定领域可降幻觉，但新知识仍需 RAG，微调模型同样会编造。
• 靠用户投诉评估效果：不投诉 ≠ 好（可能直接不用了）；Hit@K + RAGAS 离线 + 线上指标闭环。

结论必须与证据绑定，缓存命中的历史结果同样要校验。本题考察全维度哈希的构成、投毒检测与拒绝策略，以及「有引用」为何不等于「引用支持结论」。

从相似即返回到带校验的复用：最初按输入文本精确缓存；随后用向量相似度做语义缓存，出现跨租户串答与错误固化；再往后 key 纳入租户与版本维度；当前把证据绑定、后置校验与投毒检测纳入缓存契约。

缓存把一次概率性生成固化为多次复用的确定结果，因此任何影响输出的维度缺位都会把单点错误放大为系统性偏差。租户、模型与 Prompt 版本、索引版本、工具契约版本、检索片段共同决定答案，key 必须是这些维度的联合哈希。

key 由网关注入的租户标识、各方版本与归一化输入联合哈希；生成时把结论绑定到具体文档标识与片段偏移，校验引用是否真的支持结论；命中后仍跑证据绑定与业务规则后置校验；记录命中率与校验拒绝率，版本变更按前缀主动清理；疑似投毒样本隔离且不得回灌评测基线。

为什么相似度阈值不能兜底？阈值只判断能否复用，不判断复用内容是否正确。为什么投毒样本不能进基线？基线一旦吸收攻击样本，后续回归会把攻击结果当成预期行为。

key 缺租户或版本维度；命中即返回不做后置校验；只检查引用存在不检查支持关系；版本变更不清缓存；把命中率当唯一健康指标；阈值本身长期不按业务基线校准。

这道题考察的是 Function Calling 的本质与训练机制：FC 为什么本质是「两轮对话 + 中间执行」闭环（模型只输出结构化 tool_calls JSON，执行一律由宿主代码完成）？finish_reason == "tool_calls" 与 description 的协议地位是什么？为什么预训练学不会 FC、必须 SFT 教「怎么调」+ RLHF 教「什么时候调」，SFT 数据必须覆盖哪五个场景。这是理解一切工具体系的底层题。

从文本解析到原生 FC：早期 Agent 靠正则 / 约定格式解析模型文本中的调用指令（脆弱、易幻觉）；现代 LLM 原生支持 FC——输出结构化 JSON、可一次响应多个 tool_calls 并行执行（前提工具间无依赖），宿主解析执行、结果回填、模型续写终答。tool_choice="auto" 模型自判、required 强制调用。

FC 本质：模型不输出自然语言而输出结构化 tool_calls JSON（「调哪个函数、参数是什么」），宿主代码解析执行，结果塞回对话，模型再生成最终答案——两轮对话 + 中间执行。核心设计：模型只做决策，执行一律由宿主代码完成（模型无直接执行代码和访问网络的权限）；finish_reason == "tool_calls" 是「还没准备好给答案」的明确信号；description 是模型判断是否调用和参数填写的唯一依据。

训练两阶段：预训练语料没有「schema → JSON」成对样本所以学不会；SFT 教会怎么调（完整样本五段式：system 工具定义 + user 提问 + assistant JSON 调用 + tool 返回 + assistant 终答，反向传播惩罚偏离）；RLHF 教会什么时候调（人类排序训练奖励模型 RM，PPO 调整主模型建立「能直接答就不调」的边界感——只有 SFT 没 RLHF 的模型极端时会把「1+1」也交给计算器（教学例，不是评测结论））。PPO 的两个务实理由：训练稳定不崩 + KL 散度约束防止「为讨好 RM 退化成套话复读机」。

• SFT 数据五场景全覆盖：单工具 / 多工具并行 / 失败后处理 / 不需要工具直接回答 / 多轮中的调用——缺哪个场景就在哪个场景翻车。
• 数据来源：人工标注（种子）+ 强模型蒸馏（主流——防幻觉传递必须人工抽查）；RLAIF 用 AI 评委降本（社区观察值约 10–100 倍，随任务与数据规模波动，需核实）但存在偏见传递，关键数据人工 + 量大 AI 混用；偏好优化一侧已扩展到 DPO / GRPO 等免奖励模型路线。
• schema 工程：description 写清用途 / 范围 / 格式 / 示例 / 限制（「获取天气」→「查询指定城市实时天气，含气温 / 天气状况 / 风向风速，仅支持中国大陆城市」）；参数 description 同理。
• 模型侧兜底：推理模型（思维链式）早期不支持中途工具调用——生成范式冲突（思维链连续生成不能打断 vs 工具调用需暂停等待）；解法是工具调用发生在思考阶段结束后（extended thinking）或 interleaved thinking 穿插。

• FC 与 MCP 是什么关系？不同抽象层次——FC 是「调用语言」（单次调用消息格式），MCP 是「工具生态协议」（标准化打包 / 注册 / 发现 / 复用），类比 HTTP vs REST + 服务发现；MCP 底层依然靠 FC 驱动，模型感知不到 MCP 存在——魔法全在宿主程序层（list_tools → 转 FC 格式 → 路由 → 喂回）。
• 为什么「错误信息可操作」如此重要？「参数 city 不能为空」能让模型自纠重试，「Error code 400」只能让模型盲试——错误信息质量直接决定自愈能力。
• 并行调用的前提与收益？工具间无依赖时一次响应多个 tool_calls 并行执行；I/O 密集任务端到端延迟显著下降，但要求宿主执行器支持并发与结果按序回填。

• 以为模型能自己访问网络执行代码：混淆决策与执行；模型只输出 JSON，宿主代码执行。
• description 写得含糊模型瞎猜：描述是唯一依据；用途 / 范围 / 格式 / 示例 / 限制五要素写全。
• 「1+1」也去调计算器：只有 SFT 没 RLHF，无「该不该调」的边界感。
• 蒸馏数据不抽查：上游幻觉传递，模型学进错误调用模式；人工抽查是底线。

与 A04.02 的边界：N×M→N+M 与 Roots 不是沙箱，以 A04.02 为准；本卡只保留版本、传输和三角色的运维字段。

这道题考察的是 MCP 的三角色 / 版本演进 / 传输选型：Host / Client / Server 三角色与「一 Client 对一 Server」的约束是什么？协议从 2024-11 双端点 HTTP+SSE → 2025-03 单端点 Streamable HTTP → 2025-06-18 / 2025-11-25 后续修订的演进脉络（各版本具体变更以官方 changelog 为准，需核实）？stdio 与 Streamable HTTP 的选型判据、以及「消息格式（JSON-RPC 2.0）与传输层解耦」意味着什么。与 A04.02 的理论层互补，本卡聚焦版本与传输的工程细节。

传输演进路径：2024-11 初版（双端点：HTTP 请求 + SSE 推送分离）→ 2025-03（合并为单端点 Streamable HTTP，旧方案 deprecated——短请求普通响应、长请求 SSE 流）→ 2025-06-18（移除 JSON-RPC 批量请求）→ 2025-11-25 后续修订（传输与会话语义的具体变更以官方 changelog 为准，需核实）。工程铁律：接入前核对「SDK 版本 ↔ 目标规范版本」配对，勿把两者当成同一代。

三角色与约束：Host（宿主应用，管交互 / 上下文 / 权限）、Client（Host 内部通信组件，一个 Client 对应一个 Server——多 Server 即多 Client 实例）、Server（独立进程提供能力）。

解耦的意义：消息格式（JSON-RPC 2.0）与传输层（stdio / Streamable HTTP）独立——同一套 JSON-RPC 消息可跑任意传输；「JSON 是数据格式不是协议」（普通 CLI 输出 JSON ≠ MCP 消息）。

三类能力再强调：Tools（改变世界，模型触发，需授权——不能按「副作用有无」分类，只读工具也是 Tools）、Resources（观察世界，应用决定加入上下文，URI 标识）、Prompts（结构化表达，用户主动选择）。

• 传输选型：stdio（Host 拉起子进程走管道，零网络低延迟，本地个人工具；stdout 只走协议消息、日志必须写 stderr）；Streamable HTTP（Server 独立 HTTP 服务，多 Client 共享，适配微服务部署，可过网关统一鉴权 / 限流 / 审计）。同一份 Server 代码通常两种传输都支持，配置层切换。
• 自写 Server 最小路径：声明 tools/list → 实现 tools/call → 启动传输（约 30 行起步）；失败分层——协议层 error 与业务层 isError: true 分开处理。
• 版本兼容：接入前查双方支持的规范版本（通过 initialize 握手协商，具体能力发现方法名以目标规范版本为准，需核实）；批量请求 JSON-RPC 2.0 支持但 MCP 2025-06-18 规范已移除——判断功能看 MCP 规范，不只看底层消息格式。
• 安全边界：授权围绕具体操作和数据设计（不按「Tools 高危 / Resources 开放」一刀切）；Server 返回的文档 / 工具说明 / 模板也可能含不可信内容——不能因来自 MCP Server 就当高优先级指令（注入面）。

• 为什么远程传输要关注无状态化与横向扩展？会话粘滞（HTTP 会话绑定实例）阻碍负载均衡自由分发；若目标规范版本不再保留 HTTP 会话语义，双向通信与会话级状态需应用层重建——因此「规范 ↔ SDK」版本配对必须先核对（具体版本行为以官方文档为准，需核实）。
• 「一 Client 对一 Server」为何这样设计？隔离故障域与生命周期（一个 Server 崩溃不牵连其他连接）、权限按 Server 粒度授予；多工具复用一个连接会把故障与权限搅在一起。
• MCP 选型五步？① 社区有现成 Server 直接用；② 跨项目 / 多人复用选 MCP；③ 数量 / 复杂度 / 团队 / 变更频率综合看拐点；④ 正式 Agent 系统选 MCP；⑤ 部署环境不允许子进程只能 FC/HTTP。

• stdio Server 日志写 stdout：污染协议流直接断连；日志必须 stderr。
• 远程接入失败不查版本：部署环境只支持某传输或双方版本不匹配；接入前三查（传输支持 / 规范版本 / SDK 配对）。
• 把 MCP 返回内容当可信指令：Server 来源 ≠ 可信；外部内容一律按不可信输入处理。
• 本地 / 远程与 CLI / MCP 混为一谈：本地 / 远程是部署维度，CLI / MCP 是接入维度，四个象限都存在；「本地用 CLI 远程用 MCP」没有依据。

这道题考察的是 A2A 协议的两大机制与「Agent 微服务化」本质：Agent Card（/.well-known/agent-card.json 名片：技能列表 / 端点 / 认证）为什么本质是服务发现？Task 状态机（submitted → working → input-required → completed / failed / canceled / rejected，支持异步长任务、多轮补充与 Artifact 回传）如何治理超时 / 取消 / 重试？以及「Agent Card ≈ 服务注册发现、Skill 声明 ≈ API 契约、Task ≈ 异步任务队列」的微服务类比。

从提案到基金会：A2A（Agent2Agent）由 Google 2025-04 提出，随后捐赠 Linux 基金会成为开放标准；与 MCP 构成「一纵一横」——MCP = Agent 连工具（纵向，微服务里的 API 网关位），A2A = Agent 连 Agent（横向，微服务间调用位），两者互补构成「Agent 互联网」协议栈。

两大机制：

• Agent Card：Agent 在约定路径暴露 JSON 名片（技能列表 / 端点 / 认证方式）——本质是服务发现：调用方拉取名片即可知道「你能干什么、在哪调、怎么鉴权」，跨组织协作靠能力声明达成契约。
• Task 状态机：submitted → working → input-required（需补充信息，可多轮往返）→ completed / failed / canceled / rejected（明确不接受该任务）；支持异步长任务；产物以 Artifact 回传——本质是异步任务队列语义。

微服务类比：Agent Card ≈ 服务注册发现；Skill 声明 ≈ API 契约（能力边界）；Task ≈ 异步任务队列（提交 / 轮询 / 回调）。这一类比把 A2A 从「新概念」落回后端工程师的既有知识体系。

• 协作落地流程：主 Agent 拉取协作者 Agent Card → 按技能列表路由子任务 → 提交 Task（轮询 / 回调状态）→ 收 Artifact 汇总；长任务异步化，不阻塞主流程。
• Task 状态机即治理抓手：超时检测（submitted 后长期不 working 报警）；取消传播（级联取消子任务）；重试幂等（Task ID 作幂等键）。
• 防「任务幻觉」传染：下游 Agent 的 completed 不代表任务真完成——上游按证据链原则验收 Artifact（六要素：任务 / 输入 / 调用序列 / 原始返回 / 产物 / 验证结果），不信状态声明。
• 与自研消息总线的选择：跨组织 / 跨框架标准 → A2A；内部可控优先 → 自研总线；任务状态同步用事件而非轮询（减少无效查询）。

• A2A 与 MCP 为什么不合并？关注点不同：MCP 管「能力接入」（一个 Agent 如何用工具），A2A 管「能力协作」（Agent 之间如何委派与验收）；一个 Agent 同时是 MCP Client（用工具）与 A2A Server（接活），协议栈各司其职。
• Agent Card 与 OpenAPI 的关系？同构——OpenAPI 描述 REST 服务能力，Agent Card 描述 Agent 能力（技能语义 + 端点 + 认证）；区别是消费者从「人写客户端」变为「Agent 运行时自动发现与路由」。
• Task 与 AgentTask 契约（A05.03）的关系？A2A Task 是协议层任务（跨进程 / 跨组织），AgentTask 是运行时执行契约（依赖 / allowedTools / maxIters）；跨域用 A2A Task 传递，域内用 AgentTask 约束执行。

• 同步等待长任务：A2A 派活后阻塞等待直到超时；必须用 Task 状态机异步轮询 / 回调。
• 信下游 completed 不验 Artifact：任务幻觉沿调用链传染；上游验收产物。
• 取消不传播：主 Task 取消后子任务继续跑完烧钱；级联取消。
• 重试无幂等键：Task 重试导致下游重复执行副作用；Task ID 即幂等键。

这道题考察的是 工具容错五阶段、沙箱隔离设计与 Skill 三层加载机制：决策 → 校验 → 执行 → 确认 → 恢复五阶段各自的关键动作是什么（错误分类先行、幂等键查 unknown、重试收敛到一层）？沙箱为什么必须「代码按不可信处理」——访问边界（三区）/ 资源预算（cgroup 归组）/ 运行器管理三层如何设防？Skill 渐进式三层加载（元数据目录 → 正文 → 资源）如何把「能力数量」与「上下文占用」解耦。这是工具规模化治理的收官题。

从「重试三次」到「五阶段 + 分类治理」：早期容错就是统一重试三次（放大故障）；成熟设计先按错误类型分流（格式错 / 参数错 / 鉴权失败 / 瞬时故障 / 副作用 unknown），每类对应不同恢复动作；沙箱从「子进程跑跑」演进为「访问边界 × 资源预算 × 运行器管理」纵深防御；Skill 加载从全量注入演进为三层渐进披露。

五阶段容错：决策（模型发起）→ 校验（Schema 拦截 + 模型有界重生成；参数错误修正或问用户）→ 执行（鉴权失败拒绝并审计——Prompt 不代替服务端鉴权；瞬时故障三条件重试：可安全重放 + 时间预算有余 + 次数未超）→ 确认（副作用结果三态：成功 / 失败 / unknown——写请求超时必须幂等键查状态，HTTP 状态码只提供线索：连接前失败通常没到服务端、读响应超时可能已执行完）→ 恢复（重试收敛到一层、同一预算；Checkpoint 副作用前写 pending、确定结果后更新）。

沙箱三层：① 访问边界——任务空间三区（只读 input / 可写 tmp / 输出 output）、低权限身份、网络默认断、凭据不继承（文件只读 + 任意网络 = 数据外泄通道）；② 资源预算——对象是整项任务进程集合（cgroup 归组），CPU 配额 ≠ 总时长，内存 / 进程数 / 输出大小单独限；③ 沙箱外运行器——管全生命周期（准备 → 受限启动 → 终止整个执行单元 → 核对实际对象导出产物——防符号链接攻击的路径文字检查 → 清理；任务间不继承数据 / 进程 / 凭据）。

Skill 三层加载：元数据目录（frontmatter name + description，约 30–50 token / 个，成百技能只占几千 token）→ 选中后正文进上下文 → 资源按需（references / scripts）。四个状态要分清：安装 ≠ 可见 ≠ 正文已读 ≠ 动作已执行；加载改变上下文、不等于执行脚本（脚本经工具调用由宿主查权限）。

• 统一错误信封：category / code / retryable / outcome / safe_message——模型只收脱敏消息；outcome=unknown 数量是核心告警指标（提示幂等 / 对账缺口）。
• 幂等键工程：run_id + step_id 调用前生成，服务端持久化「键 + 参数摘要 + 状态 + 结果」，同键不同参拒绝；推理节点与副作用执行节点分开（防恢复时重新生成付款动作）。
• 容器 vs 虚拟机：容器轻量快启但共享内核（配置错误即交还能力），适合受控代码；VM 独立内核隔离强，适合任意用户代码；敏感场景低权限身份 + 去特权 + 系统调用过滤收紧。
• Skill 运维：目录扫描 + frontmatter 解析建轻量目录（缓存全文但只交需要的部分）；第三方 Skill 来源白名单 + 操作影响分级；「以前加载过」≠「当前仍能使用」——长任务丢正文要按来源重读并核对版本。

• 为什么「先鉴权再召回」？Tool Routing 中向量搜到第一就执行会出事——相关 ≠ 可调用 ≠ 授权；过滤链第一层就是确定性权限过滤，执行端还要重新鉴权（双重校验）。
• 为什么重试必须收敛到一层？多层各重试三次 = 请求翻倍放大故障；全链路重试收敛到单一层、共享同一预算。
• 「Prompt 写不要越权」为什么不是安全边界？OS 看进程权限不读 Prompt；权限控制 = 服务端鉴权 + 沙箱隔离 + 高风险审批，提示词只是降低概率。
• Tool Routing 与 Skill 加载的思想同源？都是「上下文是稀缺资源，一切按需」——工具动态绑定候选集、Skill 渐进披露、MCP 工具按需暴露、RAG 检索注入同属一个思想族。

• 副作用 unknown 当失败重试：重发邮件 / 重复扣款；幂等键查状态，查不清转人工。
• 子进程当沙箱用：继承宿主全部权限；必须受限身份 + 隔离环境。
• 宿主目录可写挂进容器：挂载即交还能力；三区独立 + 按权限挂载。
• 只杀主进程：后台子任务继续跑；cgroup 归组终止整个执行单元。
• 路径以 output 开头就导出：符号链接可指向外部；核对实际对象 + 限类型大小数量。
• Skill 装很多启动就爆上下文：全量加载正文；渐进式三层。

术语对齐：本卡的执行隔离在英文资料里称 sandbox，常见实现含 E2B / Modal / gVisor / Firecracker；平台级最小权限与执行轨迹治理见 A33.07。

这道题考察的是 AI 编程三种参与模式的判别与需求描述规范：补全 / 对话生成 / Agent 编程按「AI 能采取哪些行动 + 谁根据执行结果推进下一步」如何区分（为什么代码长度、界面、单次工具调用都不是判据）？需求五段式（目标 / 现状 / 输入输出边界 / 约束 / 验收）为什么比角色扮演和「写得健壮一点」有效？Vibe Coding 与 Spec 驱动的本质差异（效果反馈循环 vs 规格持续指导）及各自适用阶段。

三模式的能力边界：补全（编辑位置候选，开发者全程主导）；对话生成（表达规则讨论实现，执行反馈由开发者组织搬运）；Agent 编程（授权范围内读写 / 检查 / 接入执行，模型据反馈持续决策）。判错维度澄清：同一段代码三种方式都能生成，Agent 也能放聊天窗口，单次工具调用只说明取得某种能力——判据只有「行动范围 + 谁推进下一步」。开发者角色从「写代码」转为「定义任务 + 审查 + 验收」。

需求五段式：目标（改变什么行为）+ 现状（理解任务的背景）+ 输入输出边界 + 约束（硬要求与偏好分开）+ 验收（什么条件观察到什么结果——编码前从需求推导）。关键区分：「实现空间」与「未决规则」——「支持空值」这类歧义 AI 只能猜（返回默认 vs 明确错误）；项目事实让 AI 查源码，影响用户可见行为的规则由开发者确认。角色扮演和「写得健壮一点」不改变信息量——找出改变结果的歧义写清楚才是正道。

Vibe vs Spec：Vibe Coding（严格义）= 效果反馈为主、少审查代码的生成-运行-调整循环；Spec 驱动 = 已确认的行为 / 约束 / 验收写成规格，持续指导实现与验证。三件独立的事：AI 是否生成代码 / 开发者怎么审查 / 有没有规格组织——探索期用原型，交付期用规格；不因原型能跑就继承全部实现，不因文档厚就当质量保证。

• 五段式模板落地：目标 / 背景 / 规则 / 约束 / 验收 + 「事实自查与冲突上报」；验收前缀「其他字段有效、依赖正常」防测试被无关条件拦截；数值 2 与字符串 '2' 明确「只接受数值不做转换」。
• 上下文供给：不可读仓库 → 粘贴组织式输入（任务 / 环境 / 相关代码 / 参考验证 + 「未提供的接口不要按名称猜」）；可读仓库 → 路径 + 获取要求式（「从 listOrders 入手补读入口 / 类型 / 接口 / 测试；检索不完整要补读，不要当成不存在」）；关键结论附文件与符号位置。
• 复杂任务流程：先探索（读代码出方案）→ 复述核对 → 写成 Spec → 拆到每步可 diff 审查、可独立验证。
• 关键认知：AI 产出 = 高置信度的「看起来对」；「实现和测试都是 AI 写的，它们一起理解错了需求」是最大风险——验证标准必须独立于实现来源。

• 为什么「支持空值」是需求歧义的代表？它同时可能是「空值报错」「空值用默认值」「空值跳过」三种行为；不写清，AI 的选择就是掷骰子——歧义的代价不在长度而在行为分叉。
• Vibe Coding 什么时候合理？原型探索（快、可丢弃、实现理解弱）；一旦转交付，必须做「探索 → 交付」转换：整理确认行为、补验收标准，否则临时实现直接上生产。
• Spec 即资产？spec.md 是行为契约——换实现不换验收条件；constitution.md 沉淀项目原则跨功能复用；需求变更时「更新受影响规格 → 实现 → 测试」的传播链是 Spec 驱动区别于「文档剪彩」的本质。

• 给 AI 安排资深角色还强调三遍：角色 / 语气不补信息；写清行为条件和边界。
• 需求越长越模糊：加油词代替规则；找出改变结果的歧义写清楚。
• 全仓库塞入仍答非所问：打开仓库 ≠ AI 知道所有代码——「能访问文件 ≠ 已拿到文件内容」；按任务选材料并确认实际获得。
• 拿上月设计文档当事实：过期材料；回当前源码（含未提交修改）核对。
• 原型直接当交付：临时实现未核；探索 → 交付转换时整理确认行为。

术语对齐：本卡的个人使用规约对应岗位要求里的 Vibe Coding 与 Copilot / Cursor / 通义灵码 等 AI 编程工具；团队级治理与效能度量的组织视角见 A33.03。

这道题考察的是 任务拆分（tasks.md）与代码质量保障的双保险：Oracle 独立 + 独立审 Diff：为什么「从行为要求拆起再定代码范围」而按技术层拆是灾难？测试预期为什么必须有独立于实现的需求依据（Oracle）——「照实现反推预期」为何意味着实现和测试一起错？验收 Checklist 五步（逐 hunk 看 diff / 先红后绿 / 回归 / 边界异常 / 安全规范）如何防「删断言让结果变绿」。

从「AI 写完测过就行」到「验收契约」：早期信任「测试全绿 = 正确」；实践暴露同源错误（实现与测试一起理解错需求）与标准削弱（删断言 / 放宽预期 / 跳过用例）；成熟方法确立两条铁律——Oracle 独立于实现来源、审查对象是实际 Diff 而非完成说明；tasks.md 成为跨会话的状态接口。

拆分的行为导向：按技术层拆会让每层自行决定接口（前端 status / 后端 state / 数据库 order_status 没人让它们互相认识）；按文件数拆或拆到每个函数徒增交接成本。正确粒度：以能理解能检查为准，一个任务可跨文件；相关实现与必要验证放同一行为目标下；先确认共享接口、优先打通可验证链路。

Oracle 第一性：能运行只是基础（>= 100 和 > 100 都合法，区别在边界）；测试预期必须有独立需求依据——照实现反推预期 = 实现和测试一起错；用测试代码调待测函数算预期更隐蔽。分层检查：构建 / 类型 / 静态 → 单元（局部边界）→ 集成（真实传递路径）→ 回归（区分原有失败与本次引入）。

• tasks.md 五任务样例（订单筛选）：T1 链路确认 → T2 接口筛选 + 验证 → T3 页面筛选 + 验证 → T4 真实联调 → T5 总需求回归；T1 的接口约定作 T2 / T3 共同输入支持并行；T3 记录是否用替身、T4 查真实连接；提示词限定本轮范围（「本轮完成 T2，不提前改页面」）+ 完成记录只勾有证据的项。
• 验收 Checklist 五步：① 逐 hunk 看 diff（不只跑测试——确认改的是「你想改的」，删除的代码尤其核对）；② 测试是否先红后绿（新测试对旧实现失败才有效）；③ 原有功能回归；④ 边界与异常路径（AI 偏爱正常路径）；⑤ 安全与规范（无硬编码密钥 / 越权 / 注入）。
• 审 Diff 流程：实际 Diff（含测试配置）→ 转行为问题（输入 / 判断 / 操作 / 结果）→ 疑点核验（触发条件 + 反例 + 读外围确认没被别处处理）→ 测试本身也要审（真触发目标路径？断言独立依据？）→ AI 审查意见逐条核实（意见数量多 ≠ 审查质量高）→ 修复后重审最终差异。
• 防「改断言」：diff 审查限定范围（测试文件变更需额外审批）、验收条件由系统持有不可被模型篡改。

• 「先红后绿」为什么是测试有效性的试金石？新测试对旧实现不失败，说明它没触达目标行为（可能根本没测到）；先红后绿证明测试有区分能力。
• tasks.md 为什么是「计划即状态」？勾选只标记「有证据的工作」；执行中更新剩余计划（保留有效步骤、补新依赖、更新完成依据）让 AI 可接续、开发者可判断真实进度——与 Agent 压缩、Checkpoint 同一思想：显式记录状态才能恢复和继续。
• 验收契约与实现分离的价值？换内部结构仍用原验收条件——重构不被「测试跟着实现改」绑架；契约是外部可观察行为。

• 前端后端各自定接口：按技术层拆的必然结果；先锁共享接口约定。
• 任务全勾但按钮一点就报错：局部过 ≠ 整体对；真实联调 + 总需求回归两个收尾任务不可省。
• 测试全绿交付仍错：预期照实现反推；Oracle 独立需求依据。
• 删除断言让检查变绿：标准被削弱；审 Diff 含测试配置，改标准要独立说明。
• 听完成说明验收：摘要漏删除；审实际 Diff，删除代码重点核对。

这道题考察的是 AI 排障方法论与测试覆盖的核验手段：为什么「报错位置 ≠ 根因位置」（产生错误状态的位置可能在更早的调用中，如 findById 返回 Promise 未 await）？固定复现 → 沿数据流追源 → 候选假设 → 修复 → 回归的排障流程如何走？测试覆盖为什么「业务覆盖 ≠ 测试数量 ≠ 代码覆盖率」（实现漏权限检查则无代码可覆盖）？错误注入与变异测试如何核验测试的发现能力。

排障从「报错处修」到「数据流溯源」：AI 常见错误模式是「补默认值让报错消失」（在错误表现处修而非根因处修）；正确流程固定为：固定复现（预期 / 实际 / 触发步骤 / 版本 / 环境 / 命令）→ 沿报错追输入和数据来源 → 提出有依据的候选假设（说明什么观察能区分它们）→ 每轮做一个缩小范围的检查 → 按业务约定修复 → 原复现条件 + 旧实现会失败的回归用例验证。

排障第一性：报错位置接近问题表现，产生错误状态的位置可能在更早的调用中——沿数据流找「最早可观察分歧」；AI 解释是判断，实际执行结果才是验证依据。测试覆盖第一性：测试的价值在于区分正确与错误实现的能力，不在于存在或变绿——业务覆盖 ≠ 测试数量 ≠ 代码覆盖率（实现漏权限检查则无代码可覆盖，行覆盖率 100% 也不保障）。

场景推导：从规则出发——等价类 + 边界（0 / 1 / 100 / 101）、业务状态、权限条件（登录 ≠ 有权访问）、流程失败点、重复与并发顺序；Oracle 必须独立；触发有效性：前置隔离、替身故障落在目标步骤、替身保留关键语义（异步契约——替身同步返回导致漏 await 测不出）。

• 排查提示词六要素：约定 / 输入数据 / 预期与实际 / 环境版本 / 复现命令 / 读取范围 + 「先排查不改约定」；日志按同一次请求筛关键过程（全发 AI 分析隔壁任务是噪声灾难）。
• debug.md 四段：已确认事实 / 已排除候选 / 修复验证 / 尚未验证——状态显式化防「 AI 修一轮忘一轮」。
• 覆盖核验四手段：规则-条件-用例-断言对应表（人工核对）/ 覆盖报告（未执行区域）/ 错误注入（小成本核验发现能力）/ 变异测试（系统化——等价变异仍通过不代表缺口，需分析）。
• 并发测试：同步屏障 / 测试钩子控制时序，不靠「睡一会儿」碰运气。

• 为什么「测试再调待测函数算预期」更隐蔽？它看似独立（测试代码 ≠ 实现代码），实际预期来源仍是被测实现——实现错则预期跟着错；Oracle 必须来自需求规则 / 人工确认样例 / 接口规范。
• AI 排障与测试覆盖的思想同源点？「旧实现会失败的回归用例」与「错误注入 / 变异测试」是同一思想——验证手段的价值在于区分正确与错误实现的能力。
• 分支不同后怎么比？先比共同前缀再分析分叉点，不机械比两边「第七步」——执行方差排查（分层回放：事件回放 / 固定观察重跑模型 / 环境恢复整体重跑）同理。

• 补默认值让报错消失：在错误表现处修；追数据来源修根因。
• 改测试迁就实现：「应返回用户名」改成「空字符串也行」；预期独立 + 回归用例旧实现失败。
• 替身掩盖真实差异：替身没模拟真实契约（同步返回 / 缺异常路径）；替身保留关键语义 + 真实路径补充验证。
• 每函数几条用例当覆盖：业务动作跨函数；从规则推导场景 + 对应表验收。
• 睡一会儿查并发：时序靠运气；同步屏障 / 测试钩子。

这道题考察的是 Coding Agent 六件工程化设施与 SDD 规约驱动开发：CLAUDE.md / AGENTS.md（项目记忆）、Skills（领域知识包）、Subagents（子 Agent 隔离上下文）、MCP（外部工具协议）、Hooks（生命周期钩子）、Plugins（能力分发单元）各自解决什么问题、落地顺序为什么是「记忆 → 自动检查 → 团队知识 → 工具扩展 → 大规模并行」？SDD（Spec 驱动开发）的 constitution / spec / plan / tasks 三件套如何组织。以及源码级认知（grep 而非 RAG 检索、文件而非向量库记忆）背后的设计取舍。

六件设施的能力矩阵：

落地顺序（不能反）：CLAUDE.md（记忆）→ Hooks（自动检查）→ Skills（团队知识）→ MCP（工具扩展）→ Subagents（大规模并行）——先地基后扩张。

SDD 规约驱动：把「已确认的行为 / 约束 / 验收」写成规格持续指导实现与验证。典型目录组织：constitution.md（项目原则，跨功能复用）+ specs/<功能>/ 的 spec / plan / tasks 三件套 + checklists（需求质量核对）；工作流链：constitution → specify → clarify → plan → tasks → implement → analyze → converge。OpenSpec 变体围绕变更组织（propose → apply → archive 同步主规格）。小功能几段文字写清行为即可，不为用 Skill 把功能扩成复杂文档。

源码级设计取舍：代码检索用 grep 而非 RAG（精确匹配 + 上下文可控 vs RAG 的召回不确定性）；记忆用文件而非向量库（可审查、可版本化）；Skill 两级加载（元数据 → 全文）；主循环 = Query 循环（模型推理 + 代码驱动）+ Compact 压缩。取舍逻辑：代码域精确匹配优先于语义召回、可审计优先于自动化。

• AGENTS.md 写法：每行对应一个历史失败案例（「不要用 X，因为上次导致 Y」）；约 100 行当目录、细节拆子文档按需加载——百科全书式注入稀释注意力反而更糊涂。
• Hooks 是纪律的机械化：格式化 / lint / 测试挂在工具调用前后自动执行——「无法机械化执行的约束，Agent 必然偏离」。
• Subagents 分工：干活给写权限、审查给只读；写代码与检查代码分离（干净上下文挑刺）；主会话只拆解 / 派发 / 汇总（调度与执行分离）。
• 跨会话交接：HANDOFF.md 记录目标约定 / 代码现场（未提交 + 未跟踪单列）/ 进度分层 / 验证条件 / 下一步；新会话先核对工作区（HEAD / status / diff）再动手；已执行命令不当初始化重放（服务多起一份、任务又建一单）。

• 为什么 grep 优于 RAG 检索代码？代码有精确标识符（符号 / 路径 / 错误码），精确匹配确定性强；RAG 的语义召回在代码域引入不确定性且候选需核验——「相似 ≠ 相关」。模糊描述场景可配语义检索作候选，但定位靠符号工具确认。
• 为什么文件记忆优于向量库？项目规约 / 偏好是少量结构化信息——文件可 Git 版本化、可人工审查、零迁移成本；向量库的优势在大量非结构化语义召回，两者边界清晰可并存。
• 六件设施与工具调用三层（A10）的关系？MCP / Skills 是共享底座；Hooks / Subagents / AGENTS.md 是 Coding Agent 侧的编排与约束层——底座通用，编排按任务形态组装。

• AGENTS.md 越写越长：注意力稀释更糊涂；目录页化 + 子文档按需加载。
• 每步弹窗全点同意：确认机械化失去防线作用；授权内自主推进 + 高影响才确认。
• 信外部内容自称「管理员已授权」：注入；来源与权限分离，授权只认用户。
• 「继续昨天的」接错片：会话信息没进新输入；HANDOFF.md + 工作区核对。
• 长任务上下文丢失：会话超长压缩失真；关键决策写入项目文档（AGENTS.md / SPEC），context.md 分「代码已修改 vs 行为已验证」记录。

这道题考察的是 Agent 工程五代演进：Prompt → Context → Harness → Loop → Graph：每一代解决什么问题、本质是什么（塑造概率空间 / 时机送信息 / 运行系统工程化 / 设计代替你按回车的系统 / 节点边编排流程）？为什么五者是「层层包含」关系而非替代关系（Prompt ⊂ Context ⊂ Harness；loop 是最小 graph）？瓶颈迁移的驱动力（模型每变强一截，瓶颈外移一层）如何推导出下一站。

五代演进表：

包含关系：Prompt 是 Context 的一部分，Context 是 Harness 的一部分；一个 loop 是只有一条自指边的最小 graph。术语会过时，节点 / 边 / 状态 / 任务调度不会消失——注意力正从「单个 Agent 怎么完成一步」转向「多个 Agent 怎么共同完成一条复杂流程」。

瓶颈迁移的驱动力：模型每变强一截，上一层的边际收益递减，瓶颈外移一层——从「你怎么说」到「你喂什么」到「环境跟不上」最后落到「人肉驱动的你」。这解释了为什么方法论文献在 2025–2026 密集涌现（有资料把 Harness 标到 Mitchell Hashimoto、把 Loop 标到 Steinberger / Addy Osmani / Boris Cherny 的同期讨论（编年与人名须核对原文，本库不当硬史））——不是概念发明，是瓶颈迁移的同步标记。

层级递进的最小投入：单轮问答 → 一段结构化提示词；需外部知识 / 多轮 → 召回压缩组装三步 + 渐进披露；长链路低容错 → 六层 Harness 从「下一次犯错的修复落点」开始建；重复性工作想脱手 → 自动化 + skill + 状态文件 + 闸门四件套；多角色协作 → 节点 + 边 + 状态三要素（先确认单节点稳定）。

• 按任务形态选层：五层不是替代是包含——先判断任务处于哪一档，从该档最小投入起步；「杀鸡用牛刀」与「拿螺丝刀挖地基」都是选层错误。
• 修复落点法建 Harness：每次 Agent 犯错，修复落到对应层（漏上下文 → 上下文层、用错工具 → 工具层、步骤乱 → 编排层、跨天失忆 → 状态层、无法判断好坏 → 评估层、一失败就崩 → 约束恢复层）——六层随时间一寸寸长大。
• Loop 值不值得建？值得——每周重复的活、有自动裁判（测试 / 类型检查 / 构建）、Token 预算扛得住、Agent 能跑自己写的代码、你打算 review 产出；不值得——一锤子买卖、没有裁判、预算紧张、高风险活（架构 / 鉴权 / 支付 / 生产部署）。
• 编排工具选型：LangGraph（代码框架，精细控制）/ 工具内置 workflow（低门槛）/ 自写调度（深度定制）——都是节点 + 边 + 状态的实现，做 graph engineering 不限于任何框架。

• 为什么说「设计让 Agent 高质量产出的环境是未来程序员的主战场」？认真做 Harness 几个月后，「亲手写代码」时间越来越少、「写规则 / 流程 / 设计环境」时间越来越多——工程师的价值锚点从产出代码迁移到设计产出系统。
• 五代演进与「认知投降」的对策关系？Loop 让产出顺滑，但理解债（Comprehension Debt：代码不烂但你不知道它为什么对）与认知投降（不再有观点、给什么收什么）是副作用；解药是坚持读 diff、抽查闸门、别让 loop 碰架构。
• 一句话总结三层方法论关系？Harness 管节点内部怎么转（运行系统），Loop 管「替你按回车」的心跳（最小 graph），Graph 管节点之间怎么连（依赖编排）——层层包含，按需取用。

• 跳层建设：Harness 未稳就上 Loop 自动化（垃圾进垃圾出加速器）；单节点不稳定就上 Graph 编排（编排放大一切单点问题）。
• 把四代当替代关系：Prompt 功夫没用就不练——它是 Context 的组成部分；层级是包含不是迭代淘汰。
• loop 无停止条件：Token 烧光还在兜圈子；硬性 stop + 客观 gate 判完成，别让 Agent 自己喊「干完了」。
• 追新术语追丢本质：名字会过时（框架方自己都调侃）；节点 / 边 / 状态 / 调度这些不变量才是积累对象。

本卡不重讲定义：Harness 六层见 A01.01，Loop 五大件见 A05.02，Graph 节点 / 边 / 状态见 A05.01。要回答的是生产怎么装：先手动跑稳，再沉淀 skill，再包 loop，最后才接自动调度；闸门必须独立于生成者。装配顺序反了，得到的是空转，不是自治。

装配顺序（不能反）：手动跑通一条真实任务 → 把反复用到的约束写成 skill / AGENTS.md → 加上状态文件与客观闸门 → 最后才接定时或事件调度。缺闸门就自动化，等于把「跑完了」当成「干完了」。

生产装配对照（定义在他卡，本卡只锁增量字段）：

• Loop 最小四件套：automation（心跳）+ skill（项目背景）+ 状态文件（STATE.md 或接 issue 系统）+ 闸门（测试 / 类型检查 / 构建——loop 唯一挡住烂活的关卡）；另配常驻目标文件（VISION.md / AGENTS.md）管方向。顺序不能反：先手动跑稳 → 沉淀成 skill → 包成 loop → 才接自动调度。
• 晨间 triage loop 实战：定时触发 → 分诊 skill 读 CI 失败 / issue → worktree 隔离派 sub-agent 修复 → 第二个 sub-agent 审查 → connector 开 PR → 搞不定进收件箱 → 写回状态文件；内层 loop 干活 + 外层 loop 吸收 review 反馈（复利吃满）。
• Graph 落地两路：LangGraph（StateGraph + 条件边 + compile）；免框架玩法——subagent 文件 = 节点、hook = 强制检查、workflow = 调度脚本；深度研究类 workflow 即投产的 graph 工作流（拆解 → 并行搜索 → 抓取 → 验证 → 综合）。
• 失败模式对照：上下文焦虑（模型误判窗口将尽就着急收尾）→ context reset + 状态外化；自评永远乐观 → 三角分工 Planner / Generator / Evaluator，验收方必须摸到真实世界；Ralph Wiggum loop（无客观 gate 的空转）→ 硬性 stop + 独立判定。

• 为什么「闸门」是 loop 的灵魂？没有客观裁判（测试 / 类型检查 / 构建）的 loop 无法区分「干完了」和「跑完了」——产物质量完全靠运气；先确认有裁判，再谈自动化。
• 理解债如何量化管理？盯「每个被接受的改动的成本」——接受率 < 50% 即亏本（十改九废）；坚持读 diff + 抽查闸门，产出越顺滑越要抽查。
• AGENTS.md 为什么要「每行对应一个失败案例」？经验只有挂接在具体失败上才可验证、可维护；泛泛的最佳实践（「代码要优雅」）对模型无约束力。
• 工具无关化的价值？Cursor 与 Codex 部件几乎一一对应——值得积累的是 loop 设计图纸（五大件组合方式），不是对某家工具的肌肉记忆。

• loop 每周期从零重推项目规范：会话冷启动 + 金鱼记忆；skill 文件化，知识复利。
• 检查 Agent 说 done 就撒手：done 是声明不是证明；验证归你，gate 独立判定。
• 三路并行改同一份 API 契约：合并时对不上；规划节点先定统一契约写进状态对象。
• 测试失败三路全部重跑：无差别返工；条件边只标记失败模块返工，已存盘分支保留结果。
• 自动装来路不明的 skill：skill 是注入入口（抽样中数百个泄露凭证，多数经 debug 日志、无需权限）；装前读源码、生产关 verbose、权限定期复审。
• 串行长对话执行到第 40 步中断：全部家当只剩聊天记录；状态对象结构化存档，中断读档重试单节点。

这道题考察的是 能力归属的边界划分，而不是「能不能做」：引入成熟底座可以压缩交付周期，但把差异化能力一并交出去，就会失去迭代主动权。核心命题是——决策对象不是「整体自建或整体引入」，而是「哪一部分能力必须自己持有、哪一部分可以外包给底座」。

三段演进：早期团队倾向全自研（可控但重复造轮子）→ 平台成熟后倾向全引入（快但能力天花板受制于抽象边界）→ 稳态是分层混合：通用编排、鉴权、存储交给底座，检索策略、评测资产、领域编排自持。底座能力会持续上移，因此边界不是一次性决策，需要按版本周期重估。

二维判据：横轴是「差异化价值」，纵轴是「失效代价」。两项都高的能力必须自持；两项都低的应直接引入；一高一低的用隔离层做可替换封装。可逆性优先：容易撤回的决策可以快速拍板，难撤回的必须留出证据与回滚方案。真正的锁定往往不发生在代码里，而发生在数据格式、提示词资产、评测集与标注规范中——代码可以重写，资产迁移不动。

• 四步评估：能力映射（列出链路全部环节）→ 失效代价（逐环节问「它错了业务会怎样」）→ 替换成本（导出格式、接口契约、迁移工时）→ 退出演练（真的导一次数据 / 评测集 / 提示词，验证能跑起来）。
• 隔离层：底座只通过自建接口进入业务链路，供应商差异收敛在适配器内；业务层不出现厂商类型、不出现厂商枚举。
• 验收口径：切换底座供应商时，业务用例与评测集零改动即可通过——这是「边界划对了」的工程证据。
• 重估触发器：底座大版本升级、定价模型变化、团队新增专职工程能力时，重新跑四步评估。

• 为什么退出路径比功能对比表更关键？功能表描述的是当下状态，退出路径描述的是未来选择权。没有退出演练的引入决策，本质是把路线押注在供应商的迭代节奏上。
• 为什么「底座做广、自研做深」是稳态？通用能力的边际收益递减，差异化能力的边际收益递增；把工程预算放在后者，是投入产出比最优的分工。
• 锁定的三种形态：数据锁定（私有格式）、资产锁定（评测集与提示词绑死平台语义）、组织锁定（团队只会配置不会改内核）——第三种最难逆转。

• 把演示当能力上限：演示走的是标准路径，生产走的是异常路径；评估必须落在超时、脏数据、并发与降级上。
• 只比功能清单不看迁移成本：清单相同不代表接口语义相同，语义差异才是迁移工时的主体。
• 忽略评测资产可迁移性：评测集若绑死平台打分口径，换底座等于质量体系从零重建。
• 二开深度受抽象边界限制：底座未暴露的扩展点，只能靠旁路补丁，长期演变为最难维护的一层。

这道题考察的是 平台化到底沉淀了什么：不是把脚本封装成界面，而是把不确定性收敛到三类可治理构件——编排内核决定行为、注册表决定边界、观测基座决定可验证性。三者缺一，平台就只是「一堆能跑的链路」。

三段演进：脚本拼装（能力散落在各业务仓库，行为不可控）→ 框架封装（统一调用骨架，但能力边界与权限仍靠约定）→ 平台化（多租户、配额、审计、灰度与发布门禁成为一等公民）。演进的驱动力不是功能变多，而是「同一个能力要被很多团队反复使用且都要能追责」。

三条第一性约束：① 注册表是唯一真源——工具、模型、知识库只有登记过才允许被执行，避免影子能力绕开治理；② 执行与治理分离——编排内核只做决策，权限预算、配额、审计由独立切面注入；③ 每个能力必须可观测、可灰度、可回滚，否则无法进入生产分级。

• 三类契约：编排内核暴露「一次决策的输入 / 输出 / 终止条件」；工具注册表登记 schema、权限预算、超时、版本与负责人；观测基座统一 Run / Node Trace 与指标口径。
• 准入流程：登记 → 契约校验 → 小流量灰度 → 指标达标 → 全量放行；未登记能力在执行层被拒绝，而不是靠文档约定。
• 分级与配额：按租户 / 场景声明可用能力集合，执行层在调用前校验权限预算，网关层配额与执行层配额必须同源。
• 发布门禁：能力版本变更触发回归集重跑，未达标不允许放量（与评测体系共用同一套判定问句）。

• 为什么注册表必须是「准入」而不是「清单」？清单只描述现状，准入才产生约束；清单可以漏登，漏登的能力一旦绕过执行层校验，治理就形同虚设。
• 能力发现与权限预算为何要联动？模型只应看到「当前会话被允许调用」的工具集合；全量暴露会同时放大提示词注入面与误调用面。
• 观测为什么必须建在编排内核里？旁路埋点只能看到外部结果，看不到「为什么选了这条路」；内核埋点才能把决策依据与结果对齐。

• 只做编排不做治理：链路能跑但没有权限边界、没有配额、没有审计，第一次越权就是事故。
• 观测事后补：Trace 后加会导致节点语义与决策依据对不上，Bad Case 无法定位。
• 工具无版本契约：schema 变更未通知调用方，线上静默失败且难以回溯到变更点。
• 网关配额与执行层配额两套口径：网关放行但执行层超额，或反之，都会出现「限流看起来生效但模型仍被打爆」。

这道题考察的是 登记之后如何产生约束：注册表回答「有哪些能力」，分级回答「这一次调用能不能被放行」。把等级当成标签贴在能力上，治理就停在台账层；真正的分级是给每次调用绑定一组可判定的放行条件，以及一个预先设好的摘除动作。能力地图与构件契约见 A13.02，本卡只处理放行与摘除的判定口径。

三段演进：静态白名单（谁能调用写死在配置里，调整靠发版）→ 比例灰度（按流量百分比逐步放开，但没有质量判定，劣化只能靠人发现）→ 分级准入（能力等级、场景等级与证据集三者共同决定放行，失效时自动摘除）。推动演进的不是规则变复杂，而是同一个能力被很多团队复用之后，人工审批既慢又挡不住跨租户扩散。

三条原理：① 定级对象是「能力 × 场景」组合——同一检索工具在离线分析与对外应答里，失效代价差一个量级，全局定级必然要么过松要么过紧；② 放行条件必须可判定——回归集分数、SLO 达标、负责人签字都能被程序判定，「看起来稳定」不能；③ 摘除要比放行快——等级越高越要预置回滚路径，否则分级只是一扇单向阀门，越放行越收不回来。

• 四级定义：L0 实验（仅影子流量、不产生业务副作用）→ L1 小流量（绑定回归集与熔断）→ L2 常规（绑定 SLO 与配额上限）→ L3 关键（变更双签、保留演练记录）。
• 每级四要素：允许的场景集合、必备证据清单、配额上限、摘除触发器；四者缺一，该等级不允许被声明。
• 执行层校验：调用前取「能力等级 ∩ 场景等级」求交，不满足直接拒绝并带拒绝原因，而不是先放行再告警。
• 等级变更：升级触发回归集重跑与发布门禁复核，降级立即生效并记录触发指标；与发布流程共用同一组判定问句，避免两套口径。

• 为什么等级要绑定场景而不是全局？离线批处理里一次错误检索最多重跑，在线应答里同样一次错误会直接面对用户；把两者定成同一级，只能按最严的那一端兜底，成本全压在低风险场景上。
• 为什么摘除必须自动化且预置？人工摘除的响应延迟就是故障持续时间；只升不降的等级表会慢慢退化成没人看的台账，反而把真实风险遮住。
• 为什么影子流量也算准入的一环？那是唯一能在不产生副作用的前提下取得真实分布证据的窗口；跳过它直接小流量，等于拿生产流量做实验。

• 只升不降：等级成了荣誉记录，已经劣化的能力长期停在 L3，门禁名存实亡。
• 等级与配额两套口径：高等级能力配低配额，或反过来，越权面与容量风险同时放大。
• 证据集绑死打分口径：换底座后历史分数无法复算，所有等级一次性失去依据。
• 校验只写在文档里：执行层不做求交，绕过配置即可调用，分级退化为口头约定。

这道题考察的是 边界的时间维度：A13.01 给出的是一次决策，但底座能力持续上移、定价模型与接口语义持续变化，今天该自持的能力明天可能已是通用件，今天外包的明天可能成为差异化瓶颈。把选型结论封存在文档里，等于默认边界永不变；正确做法是把边界当作有版本、有证据、有回滚路径的长期资产来治理。

三段演进：一次性选型（结论写进决策记录后不再回看）→ 事件驱动重估（出事故、涨价或供应商停服才被动复盘）→ 周期性重估 + 兼容矩阵（底座大版本、能力清单变化、团队工程能力变化三类触发器自动启动评估，由回归矩阵决定变更能否平移）。驱动力是变更窗口在出问题时最窄、议价能力也最弱。

三条原理：① 边界漂移来自外部——底座把某项能力上移为通用件、或悄悄改变接口语义，自家代码并没有变，边界却已经失效；② 兼容是语义等价而非签名相同——默认值、排序稳定性、流式事件顺序、错误分类的任何变化都属于破坏性变更；③ 重估结论必须能撤回——隔离层保留旧实现一段时间并双跑对比，验证不过就退回原边界，否则重估就是不可逆的单向下注。

• 三类触发器：底座大版本发布、定价或配额模型变化、团队新增专职工程能力；任一命中即启动评估，不依赖事故驱动。
• 兼容矩阵五列：接口契约 / 参数语义 / 输出格式 / 资产格式 / 评测口径，每格标注兼容等级与迁移工时；签名相同但语义变化的格子单独标红。
• 双跑窗口：新旧实现接同一份流量做结果对比，差异超阈值不放行；窗口结束才允许摘除隔离层里的旧实现。
• 硬门槛：沿用 A13.01 的退出演练，但追加一条——导出的评测集与提示词资产必须能在新实现上跑通回归集，跑不通即判边界不可迁移。接口层的版本与兼容测试见 A14.02，本卡处理的是平台层的重估流程。

• 为什么功能清单相同仍可能不兼容？默认值与不确定性处理方式只在异常路径、并发路径上暴露，演示与单测都走标准路径，差异会被一直掩盖到线上。
• 为什么重估要有固定周期？被动重估永远发生在最坏的时点：故障正在扩散、切换窗口被压缩、替代方案没验证过，此时做的决策几乎必然偏向维持现状。
• 为什么资产格式要排在代码前面进矩阵？代码可以重写，评测集与提示词一旦绑定平台打分口径，迁移的就是整套质量体系，这部分成本主导总工时。

• 把大版本升级当依赖升级：只跑单测不跑回归集，语义变化全靠线上发现。
• 兼容矩阵只记接口不记语义：格子全是「兼容」，真正出问题的默认值与事件顺序无人登记。
• 双跑没有差异阈值：靠人眼抽样看结果，等于没有判定标准。
• 重估结论只写文档不改隔离层：边界在纸面上变了，实际调用链一分未动。

这道题考察的是 横切关注点如何不侵入业务链路：Advisor 把请求改写、记忆注入、审计、日志做成一条有序责任链，链上每个节点包住一次模型调用。顺序即语义——同一个 Advisor 放在链首和链尾，行为可能完全相反。

三段演进：手写拦截（在业务方法里前后各贴一段，重复且易漏）→ 框架 Advisor（统一的 around 抽象，顺序由注册顺序决定）→ 可编排链（按场景条件启用、支持观测与降级，顺序成为可测试的契约）。推动演进的是「横切能力越来越多，隐式依赖再也无法靠人脑维护」。

三条原理：① around 语义——每个 Advisor 同时掌握调用前与返回后，因此必须成对处理成功与异常路径；② 顺序敏感——改写在记忆注入之前，否则历史被写进改写目标；审计要包住请求与响应两端；③ 上下文只读传递——节点之间通过不可变的请求上下文交换数据，避免后写覆盖前写。

• 典型链序：输入净化 → 查询改写 / 检索增强 → 记忆注入 → 模型调用 → 结构化输出校验 → 审计与指标记录。
• 节点纪律：每个 Advisor 声明自身依赖的前置节点；启动期校验链序，顺序不对直接失败而不是带病上线。
• 远程调用：节点内若访问外部服务，必须自带超时、熔断与降级返回值，禁止把不确定性带进同步链。
• 可测性：用固定链序的集成测试断言「改写后的提示词」「注入的记忆片段」「审计记录的字段」三处快照。

• 为什么改写必须在记忆注入之前？改写针对的是本轮问题；若先注入历史，改写器会把历史一并重写，既污染上下文又放大 Token 成本。
• 为什么审计要同时包住请求与响应？只记请求无法回答「基于什么依据得到这个答案」，只记响应无法回放输入上下文；缺一端就形不成追溯链。
• 顺序错位的隐性故障长什么样？链仍能跑、指标仍正常，但记忆命中率缓慢下降、审计字段偶发缺失——这类缺陷只能靠链序快照测试发现。

• Advisor 内远程调用无超时：一个慢节点拖死整条链，且超时发生在框架之外难以定位。
• 隐式依赖注册顺序：换一个依赖版本就可能改变顺序，行为随之漂移且无报错。
• 吞异常：节点捕获异常后返回兜底值却不记录，链路表面成功、审计无痕。
• 在节点里写业务状态：横切面变成业务耦合点，复用与测试同时失效。

这道题考察的是 可替换性来自哪里：不是适配器写得多，而是接口边界足够稳定、方言差异被完整收敛在适配层内。业务层只依赖统一的模型接口与工具回调接口，供应商切换才可能退化为一次配置变更。

三段演进：硬编码 SDK（业务代码直接引用厂商类型，换模型等于全量改造）→ 统一抽象（ChatModel / ToolCallback 屏蔽调用方式，但能力差异仍靠 if-else 兜）→ SPI 可插拔 + 能力协商（实现按声明的能力注册，调用方按能力选择而非按厂商分支）。

三条原理：① 依赖倒置——业务层定义接口，适配层实现接口；② 方言收敛——参数命名、流式事件格式、工具描述差异只在适配器内翻译；③ 能力协商优于能力抹平——不要把所有模型压到最小公共能力集，而是声明「支持工具调用 / 流式 / 结构化输出」并由路由按能力选择。

• 接口边界：ChatModel 收敛请求 / 响应 / 流式事件；ToolCallback 收敛工具 schema、执行与结果序列化；结构化输出交给转换器生成可校验对象。
• 能力探测：启动时登记每个实现的能力矩阵与必填参数（超时、档位、思考支持），配置缺项直接启动失败。
• 降级链：主模型超时 → 同档位备选 → 降档模型；每级切换都带事件记录，避免静默降级。
• 兼容测试：同一组用例跑遍所有已注册实现，断言工具调用、流式中断、结构化输出三类契约一致。

• 为什么「最小公共能力集」会拖累效果上限？为了兼容弱实现而禁用工具调用或结构化输出，等于让强模型按弱模型的能力工作，成本没降、质量先降。
• 为什么结构化输出属于契约而非提示词？提示词只能「请求」模型守格式，转换器才能真正把自由文本收敛成可校验对象并驱动重试。
• SPI 为什么要有版本？接口不变但语义会变（如工具结果默认值）；没有版本与兼容矩阵，新增实现会悄悄改变既有链路行为。

• 厂商特性泄漏到业务层：业务代码里出现供应商枚举或私有参数名，抽象层即刻失效。
• SPI 无版本 / 无兼容测试：实现各自解释接口语义，切换时行为漂移且难归因。
• 降级路径从未验证：备选模型没跑过回归集，真正切换时才暴露工具调用不兼容。
• 把结构化输出当字符串解析：正则截取自由文本，格式一变就静默产出脏对象。

这道题考察的是 钩子在哪一层：框架级观测不是多埋几个点，而是提供一处稳定的扩展点，让模型调用、工具执行与 Advisor 节点的前后状态被同一套上下文串起来。旁路埋点只能看到外部结果与耗时，看不到「为什么选了这条路」；可观测性的上限，在框架决定把钩子放在哪里时就已经被确定。观测什么指标属于 A19.03 的契约范围，指标如何落地见 C12.40，本卡只处理框架扩展点机制。

三段演进：散点日志（各节点各写各的，没有关联标识，Bad Case 无法还原）→ 统一 Tracing（有了 traceId，但节点语义靠口头约定，换一个人写就换一套字段名）→ 框架一等 Observation 抽象（生命周期、上下文传播、标签约定与错误状态由框架统一定义，自定义实现只补业务语义）。

三条原理：① 生命周期成对——open 与 close 必须覆盖成功、异常、取消三条路径，取消最容易被当成正常返回，漏一次就留下悬挂节点与失真耗时；② 上下文只读传递——节点之间用不可变上下文交换数据，后写不能覆盖前写，这与 A14.01 的链序纪律同源但作用在不同层；③ 标签基数有界——提示词全文、用户标识、工具参数原文放进属性会直接打爆时序库，只登记枚举、分档与摘要哈希。

• 注册约定：通过 ObservationRegistry 登记自定义 ObservationConvention，声明节点名、允许的低基数键集合以及错误到状态的映射规则。
• 节点五字段：输入摘要哈希、选中的能力版本、决策依据类别、耗时、结果状态；任何字段都不落原文，需要原文回放时走独立的脱敏存储。
• 桥接与采样：与链路追踪对接时显式对齐传播格式与采样率，网关层与框架层若各设一套，Trace 会在中途断裂。
• 快照测试：固定链序的集成测试断言节点树形结构与五字段快照；取消与超时路径用故障注入单独验证节点一定 close。

• 为什么钩子要建在框架内部而不是切面旁路？切面拿得到入参出参，拿不到编排内核里的候选集、选中理由与放弃分支，而这些恰恰是定位 Bad Case 的凭据。
• 为什么标签基数比字段数量更关键？高基数字段会让聚合查询失去意义并按写入量放大成本，宁可少记几个字段，也要保证每个字段都能被稳定分组。
• 为什么取消路径最容易漏 close？异常有显式捕获，取消常被实现为「提前返回」，既没有错误也没有结束事件，节点就永远停在打开状态。

• 把提示词原文写进节点属性：既造成高基数，又把敏感输入带进遥测系统。
• close 只放在成功分支：异常与取消遗留悬挂节点，耗时分布被长尾污染。
• 自定义约定与默认约定叠加：同一次调用产生双份节点，指标口径随之翻倍。
• 采样率两层不一致：网关采样放过的请求在框架侧被丢弃，链路只剩半截。

这道题考察的是 装配期而非调用期：A14.02 让调用方按能力挑选实现，但没有回答「哪些实现在当前部署里根本不该被注册」。可替换性不只来自接口稳定，还来自把缺能力、缺配置在启动阶段就暴露成一次发布被拒，而不是等到首次流量到来才静默降级。自动配置的底层机制与交付标准化另有专章，本卡只处理 AI 能力差异下的注册判定。

三段演进：全量注册（所有实现都进容器，运行时用分支挑一个）→ 条件装配（按类路径与配置项决定注册，但条件只回答「依赖在不在」）→ 能力协商式装配（实现声明能力矩阵，装配期与场景所需能力求交，缺项直接启动失败并点名缺失维度）。

三条原理：① 声明与需求分离——能力声明属于实现，能力需求属于场景，二者只在装配期求交，任何一方都不能替对方兜底；② 缺失必须前移——运行期才发现不支持工具调用，代价是一次线上失败，启动期发现，代价只是一次发布被拒；③ 按档位选实现而非按公共集裁剪——为了兼容弱实现而关掉强实现的结构化输出，成本没降质量先降，这与 A14.02 的结论同源，但落点从选路换成了注册。

• 能力矩阵：每个实现注册时提交工具调用、流式输出、结构化输出、上下文上限、思考支持五维声明，以及必填参数清单；场景侧声明最低能力集合。
• 装配期求交：缺项给出「场景 × 缺失维度 × 候选实现」三元组报错，启动即失败，不做告警降级。
• 降级链约束：备选只允许在同一能力档位内选择，跨档切换必须显式配置并留事件记录，杜绝静默降质。
• 单一声明源：能力矩阵与 A14.02 的运行期能力探测共用同一份声明对象，禁止配置与代码各写一套；兼容测试保证同档实现跑同一组用例结论一致。

• 为什么「依赖在不在」不足以作为装配条件？类可用只说明能构造对象，不说明该实现支持结构化输出或工具调用；把这两件事混为一谈，缺能力就会推迟到运行期才暴露。
• 为什么缺项要启动失败而不是告警？告警在发布噪声里会被忽略，而首次流量到来时已经没有可回滚窗口，只剩线上兜底。
• 为什么声明必须与运行期探测同源？两份声明一旦漂移，就会出现「装配期放行、运行期拒绝」，这类故障的日志里两边都显示正常，归因成本最高。

• 把能力当成布尔开关：忽略上下文上限这类连续量，档位判定失真。
• 降级链跨档无记录：用户侧看到答案质量下降，链路侧找不到切换事件。
• 声明散落两处：配置写一份、代码注解写一份，改一处忘一处。
• 只校验主实现：备选实现从未跑过兼容测试，真正切换当天才暴露工具调用不兼容。

这道题考察的是 Spring AI 的 ChatClient 多模型路由与结构化输出生产范式：ChatClient 抽象如何屏蔽供应商差异、支持运行时按档位 / 成本 / 可用性切换？BeanOutputConverter 如何把自由文本收敛为「可校验的 I/O 契约」？与基础设施层首包探测 / 熔断、理论层模型档位路由的关系是什么。组件级代码范式是自研架构的最小构件。

从直连 SDK 到抽象路由：早期业务直连各家 SDK（模型名写死、切换重写）；Spring AI 以 ChatModel / ChatClient 抽象 + 自动配置统一接入（Mistral / Ollama / OpenAI 等），多供应商路由（官方示例仓库提供多供应商示例，示例名与位置以仓库为准，需核实）按档位 / 成本 / 可用性运行时切换——与理论层 1.3 档位路由、基础设施层首包探测 / 三态熔断同构。Embedding 侧同样抽象（含 ONNX 本地推理），Image / Audio（STT·TTS）多模态接口齐备。

结构化输出的第一性：Agent 工具调用、数据抽取都要求「非结构化生成收敛为可校验 I/O 契约」——BeanOutputConverter 将目标 Java 类型映射为结构化提示（含 JSON Schema），模型输出经转换器反序列化为强类型 Bean；配合校验（格式 / 枚举 / 必填）失败重试，把「碰运气解析」变为「契约化 I/O」。这是工具调用与下游系统集成的工程基础。

• 路由落地：按 scene（场景）/ Token 预算 / 套餐 / 风险绑定 tier（档位）而非具体模型名；ChatClient 按档位构造，底层实现可配置切换——供应商切换对业务透明。
• 结构化输出落地：定义输出 Bean（字段 + 校验注解）→ Converter 生成结构化提示 → 解析失败触发重试（结构化输出自纠正）；复杂抽取再配 few-shot 示例。
• 与熔断的关系：Spring AI 抽象解决「怎么调统一」，首包探测 / 三态熔断解决「调不稳怎么办」——两者叠加才是生产级供应商隔离。
• 组件全景对照：Prompts（模板）/ Tool Calling（Java 方法暴露为工具）/ Memory（四实现）/ RAG（三种流变）/ Observability（Micrometer）/ 护栏（SafeGuardAdvisor + 自定义 Advisor）/ MCP——每个能力点都有官方参考实现可抄。

• 为什么「绑定 tier 而非模型名」是路由的关键设计？业务代码引用「tier-standard」，路由层决定 tier 内具体模型——降级 / 灰度 / 换供应商不改业务代码；引用具体模型名则每次调整都是一次发版。
• BeanOutputConverter 与手写 JSON Prompt 的差异？Converter 保证 Schema 与目标类型同步演进（改字段即改提示），手写 Prompt 与代码必然漂移；这是「契约即代码」。
• 结构化输出失败的自纠正循环怎么搭？校验失败 → 错误信息回喂模型重试（有界）→ 仍失败降级（默认值 / 转人工）；与工具调用循环共用 Advisor 机制。
• Prompt 为什么要按一等资产管理？它同时决定行为边界、输出契约与安全策略，变更影响面等同于代码发布，却常被放在配置字符串里随改随上。最低要求：版本化、评审、变更单关联评测报告、与模型版本和检索版本绑定成四方快照，并保留一键回滚点；禁止在线热改而不触发回归，也禁止把系统硬约束写进可被用户上下文覆盖的位置。

• 路由绑定具体模型名：换模型即改业务代码；统一走档位抽象。
• 结构化输出不校验直接用：非法 JSON / 字段缺失直捣业务层；Schema 校验 + 有界重试是底线。
• 把 Spring AI 抽象当容错：抽象统一的是调用方式，不是稳定性；探测 / 熔断 / 降级需另建。
• 版本升级不看迁移清单：Spring AI 1.x → 2.x API 变化大（工具循环上移 Advisor 链等）；升级前核对。

这道题考察的是 Spring AI 记忆四实现与 Tool Calling 生产范式：内存（InMemory）/ JDBC / Neo4j / Vector Store 四种记忆持久化各自适用什么场景（原型 / 跨重启会话 / 图结构长期记忆 / 语义召回）？把 Java 方法暴露为 LLM 工具（Mistral / Ollama / OpenAI 三套实现）的生产要点是什么？记忆四实现与理论层记忆分层（短期 / 长期）、多租户体系的映射关系——以及多租户隔离为何不能依赖框架、必须由应用层显式实现。

记忆实现的工程化谱系：内存（InMemoryChatMemory——原型 / 单实例）→ JDBC（JdbcChatMemoryRepository——跨重启会话、对接既有 DB）→ Neo4j（Neo4jChatMemoryRepository——图结构长期记忆）→ Vector Store（VectorStoreChatMemoryAdvisor——记忆即检索）。四种实现是「同一 ChatMemory 抽象 + 不同存储后端」的落地，对应理论层 1.2 的短期（会话）与长期（向量库）二分；多租户隔离不在框架内，需应用层在读写键上显式加 tenant 维度。

Tool Calling 范式：Spring AI 把 Java 方法（注解声明）暴露为 LLM 可调用工具，框架负责意图解析 / 参数转换 / 执行 / 结果回填；与理论 1.4 工具协议、MCP 形成「函数调用 → 标准化协议」的递进——进程内方法用 Tool Calling，跨进程能力用 MCP。生产要点：方法 description 写清用途与边界；参数用强类型（自动校验）；写操作套人工确认与审计（见 A20）。

• 选型映射：内部工具 / 原型 → 内存实现；面向用户的助手（会话可恢复）→ JDBC；需要图结构长期关联 → Neo4j；个性化助手 → Vector Store（语义召回历史偏好）。SaaS 多租户不是「换一种实现」，而是任一持久化实现 + 应用层显式租户键。
• 组合使用：JDBC（会话连续性）+ Vector Store（长期偏好）+ 应用层租户键（隔离边界）三件套叠加是常见生产形态——各管一层，接口统一。
• 工具暴露纪律：工具粒度按业务动作拆（不做万能工具）；description 回答「何时该调 / 何时不该调」；错误信息可操作（帮模型自纠）。
• 与 Agent 模块的关系：Agent 运行时（AgentScope ReAct + 技能 + 记忆 + 人工确认）建立在 Spring AI Tool Calling 之上——组件范式（怎么调）与 Agent 架构（怎么编排）分层。

• 为什么「多租户记忆隔离」不能依赖框架自带实现？记忆抽象只负责存取，不携带租户语义——必须由应用层在会话 / 查询键上显式加 tenant 维度，并在入口校验数据归属；把隔离当框架能力，是串租户事故的根源。
• Vector Store 记忆与 RAG 的边界？同一套向量基建，两种数据：RAG 管共享知识（文档），记忆管用户个性化（偏好 / 历史）；检索时可分开召回再统一排序（详见 A02.03）。
• Tool Calling 与 MCP 的迁移路径？先用 Tool Calling 快速验证（进程内零部署）；能力需要跨应用复用时包装为 MCP Server——「一次实现，两类消费方」。

• 生产用 Basic 内存记忆：重启即失忆、多实例不共享；跨重启场景必须 JDBC 以上。
• 多租户产品用无隔离记忆：会话串租户 P0 事故；应用层显式租户键 + 入口归属校验。
• 工具方法写万能入口：execute(String sql) 式设计权限粒度全失；按业务动作拆分。
• 记忆无限增长：无 TTL / 无压缩的会话记忆撑爆存储；会话 TTL + 摘要压缩。

这道题考察的是 Spring AI 的 RAG 三种流变与 Guardrails 护栏：Sequential（Naive → Advanced 顺序管线）/ Branching（条件分支检索）/ Conditional（按需检索）分别解决什么问题？这三种划分属社区归纳的教学口径，Spring AI 官方对应 Modular RAG 的 Pre-Retrieval / Retrieval / Post-Retrieval / Generation 模块（具体 API 与命名以所用版本为准，需核实）。文档入库侧的 splitters（分块）与 metadata 富化（摘要 / 关键词）如何共同决定召回质量？输入 / 输出 Guardrails 在组件层怎么落。本卡把理论层 RAG 演进落到 Spring AI 组件代码。

三种流变的适用递进：Sequential——标准管线（检索 → 增强 → 生成），Naive 升级 Advanced（加重排 / 压缩）覆盖大多数问答；Branching——按问题类型分支到不同检索策略（如事实类走向量、关系类走图谱）；Conditional——按需才检索（简单寒暄 / 闲聊不检索，省成本降延迟），是 Agentic RAG 的组件级雏形。

入库质量决定召回上限：Document Readers（JSON / Markdown / PDF / Text / Tika 多格式解析）→ Transformers 两类——Metadata 富化（LLM 生成摘要 / 关键词 / 假设性问题入 metadata，扩展召回面）与 Splitters 分块（Token 粒度 / 段落边界）。理论结论在此组件化：切块与富化共同决定召回质量，检索层优化比换更强生成模型投入产出比更高。

Guardrails 双向护栏：输入护栏（敏感词 / 注入模式 / 长度与格式校验，不合规直接拦截不进模型）+ 输出护栏（敏感内容 / 格式校验 / 引用完整性）——对齐理论 1.7 分层防护与阶段 6 治理；Spring AI 官方提供 SafeGuardAdvisor（敏感词级），更完整的护栏以自定义 Advisor / 过滤器插入调用链（是否存在独立 Guardrails 组件需核实）。

• 流变选型：标准知识问答 → Sequential Advanced；多知识域 / 多模态混合 → Branching（意图路由到检索策略）；高 QPS 成本敏感 → Conditional（前置分类器决定是否检索）。
• 入库管线：Reader 选型按格式（Tika 兜底复杂格式）→ Splitter 保语义边界 → Metadata 富化（摘要 + 关键词 + 章节路径）→ 向量化入库；每步可独立测试（Testcontainers 锁链路）。
• Guardrails 落点：输入护栏在 ChatClient 调用前（Advisor 链前置）；输出护栏在响应后（正则 / 分类器 / 引用校验）；高危场景叠加第三方审核 API。
• 可观测配套：LLM 调用与 Vector Store 的 Micrometer 指标 / 追踪——组件级观测埋点对齐阶段 5 三支柱。

• Conditional 与 Agentic RAG 的关系？Conditional 是「检索不检索」的二分支；Agentic RAG 是「检索什么、检索几轮、何时停」的动态规划——前者是后者的最低成本形态，可先上 Conditional 验证价值再演进。
• Metadata 富化为什么能提升召回？原文措辞与用户问法存在语义鸿沟（文档写「退订规则」用户问「怎么取消」）；LLM 生成的摘要 / 假设问题以「用户语言」入索引，桥接鸿沟——代价是入库成本上升，按价值文档选择性富化。
• Guardrails 与业务校验的边界？组件护栏管通用安全（敏感词 / 格式 / 注入模式），业务规则（退款额度 / 权限语义）必须落在服务端业务层——护栏不是权限系统。

• 所有请求都检索：闲聊也走全量管线，成本延迟双输；Conditional 按需检索。
• 入库不做富化：语义鸿沟导致「明明有却召不回」；摘要 / 关键词富化是高 ROI 优化。
• 护栏挡住业务规则：把权限判断写进输入护栏；护栏管通用安全，业务规则归服务端。
• 三种流变硬选一种：同一系统可并存（问答走 Sequential、复杂任务走 Branching、闲聊走 Conditional），按请求路由。

这道题考察的是 双链路 v1/v2 与三层执行器的架构决策：v1 Workflow（路径写死：问题重写 → 意图识别 → 多路召回 → 组装生成）与 v2 Agentic（ReAct 循环，知识检索 / MCP 工具 / Skills 皆为工具）为何并存且按场景路由？MCP 边界为什么「客户端仅在 agent 模块装配、Workflow 不连 MCP」？三层执行器（歧义追问 → 知识问答 → 开放式 Agent）的优先级链如何降低模型不确定性。

双链路并存是「可控性与智能性权衡」的教科书实践：v1 Workflow 更快、更可控、成本低——适合知识助手类标准问答；v2 Agentic 可规划、可调用工具——适合复杂任务场景。按场景路由，二者并存而非二选一。前置编排则从另一端收敛不确定性：模型回答前，前置编排中心做完所有确定性决策（路由判定 / 改写 / 拆分 / 域收缩 / 歧义检测）。

三层执行器的漏斗逻辑：第一层歧义追问——问题含糊（缺对象 / 缺参数）直接反问用户，不浪费模型推理；第二层知识问答——命中知识域走 RAG 管线（确定性路径）；第三层开放式 Agent——前两层接不住才放行 ReAct 循环。漏斗的经济学：越往下越贵（Token / 延迟 / 风险），让 80% 的请求止步于前两层。

MCP 边界的架构含义：Workflow 是确定性路径，引入动态工具等于把不确定性重新注入——所以 MCP 客户端只在 agent 模块装配；这是「能力放行与风险边界对齐」的架构表达。

• 路由实现：意图分类（注册表模式 + 树形意图识别）→ 路由到 v1 管线 / v2 Agent / 澄清反问；分类置信度不足转追问而非硬猜。
• v1 管线组件化：问题重写 → 意图识别 → 多路召回 → 组装生成，各环节策略化可替换（策略模式）；单通道失败不影响主链。
• v2 Agent 组件：AgentScope ReAct 引擎 + MCP 工具 + 技能 + 记忆 + 人工确认；maxSteps / 超时 / Token 预算三闸门。
• 判定清单：新需求先问「任务边界可枚举吗？可控性要求多高？路径要可审计吗？」——三问定链路，再写代码。

• 为什么「歧义追问」排在第一层？歧义输入下任何生成都是猜——追问一次的成本远低于一次错误执行（可能触发副作用）；把「问清楚」前置是最便宜的纠错。
• v1/v2 并存的运维含义？两套链路共享基础设施（模型客户端 / 观测 / 治理）但独立演进——v1 改检索策略不影响 v2 的 Agent 循环；隔离降低了回归半径。
• 「Workflow 不连 MCP」会不会太严格？确定性节点需要外部数据时走固定数据源接口（内部服务调用）而非 LLM 动态选工具——数据获取的确定性由代码保证，工具选择的智能性留给 Agent 层。

• 全场景一把梭 Agentic：标准问答也走 ReAct，成本翻数倍且不可复现；按场景路由。
• Workflow 偷连 MCP：确定性路径被动态工具污染，审计失效；边界固化在模块装配层。
• 三层执行器漏斗失衡：第一层判定过松（什么都放行到 Agent）或过紧（合法问题被反复追问）；用评测集调漏斗阈值。
• 意图注册表不维护：新业务意图漏注册，请求落到兜底链路质量骤降；意图上线流程化。

与 A09.02 的边界：RRF 机制见 A09.02；本卡只保留检索融合接到熔断三态之后的可用性设计。

这道题考察的是 检索融合 RRF 与模型容错三态熔断：多路召回（向量 + 关键词 + 知识图谱 + 联网）并行后如何融合（去重 → RRF → Rerank，分层控制召回数 / Rerank / TopK）？模型容错的「首包探测 + 三态熔断 + 多候选切换」如何设计？为什么「单通道失败不影响主链」是检索架构的可用性底线。

检索融合链：向量 + 关键词 + 知识图谱 + 联网搜索四路并行 → 去重 → RRF 融合 → Rerank 精排 → 按召回数 / Rerank / TopK 分层控制；轻量链路为向量 + 关键词两路 + RRF + 可选 Rerank + Parent-Child 聚合。问题理解层配套：查询词映射（同义词 / 领域词典）→ 问题重写与拆分 → 树形意图识别 → 多知识库路由。

并行召回的可用性设计：四路并行且单通道失败不影响主链——每路独立超时与降级，失败通道返回空集而非拖垮整体；图谱 / 联网路是增强路（失败降级为向量 + 关键词双路），向量路是保底路。

模型容错三态：多候选模型自动切换；首包探测（首包超时 / 空响应 / 异常三级触发降级——首包慢直接切候选，不等整包）；三态熔断（关闭 → 打开 → 半开，失败率阈值断链，恢复探测放行）。

• 融合参数基线：每路召回 Top-30~50 → RRF 融合去重 → Rerank 取 Top-5~10 → 生成；分层控制防止「全量塞给 LLM」。
• 首包探测实现：模型客户端设首包超时（如 3s），超时即取消当前请求切下一候选——用户感知的 TTFT 是体验第一指标。
• 三态熔断参数：失败率阈值（如 50% / 窗口 20 次）打开熔断 → 静默期 → 半开放行探测 → 成功恢复；熔断事件全量上报观测。
• 排查顺序（JavaGuide 经验）：答非所问先查 Chunk 切粗 → Query 未改写 → 关键词与向量未结合 → 重排缺失，逐项排查比换贵模型有用。

• 为什么「首包超时」比「总超时」更重要？用户流失发生在等待期——首包 3 秒外的响应即使完整也体验失败；首包探测把降级时机从「失败后」提前到「慢了就切」。
• 四路并行的成本账？图谱 / 联网路每次调用都有成本——按意图路由启用（关系类问题才走图谱、时效类才联网），非全量常开；「并行」是能力不是常开义务。
• RRF 在 Java 侧的实现要点？只依赖各路排名（不依赖分数归一化）；实现为纯函数便于单测；k=60 默认即可。

• 串行调用多路：延迟取 sum 而非 max；并行化（无依赖路并发）。
• 一路失败全链重试：增强路失败拖垮保底路；路间隔离降级。
• 熔断无半开探测：打开后永不恢复或瞬间全量放行；半开 + 探测流量。
• 换模型当优化：没定位就动手；Trace 先圈定异常切片（RAG 段 / 工具段 / 生成段）再下钻。

这道题考察的是 Redis ZSET 公平排队与 RocketMQ 事务一致性两大基础设施设计：为什么模型调用是「必须限并发且保公平」的昂贵资源——ZSET 公平排队 + Lua 原子抢占 + 过期信号量 + Pub/Sub 唤醒四件套如何协作？海量文档分块入库为什么必须 RocketMQ 事务消息（半消息 + 本地事务 + 回查）+ 幂等 + 分布式锁状态机。这是「调 API ≠ 生产级」的最硬核证据。

从网关限流到公平排队：网关限流只保「系统不被打死」，不保「公平」——突发流量下单会话可占满全部模型并发，其他用户全部排队无响应。工程方案：Redis ZSET 按入队时间给会话排序（FIFO 公平）+ Lua 脚本原子抢占并发额度（防竞态超发）+ 过期信号量回收僵尸会话（客户端断开不占坑）+ Pub/Sub 唤醒队首会话（免轮询）。

公平排队四件套的协作：请求到达 → Lua 原子检查「当前运行数 < 上限」则直接执行，否则 ZSET 入队（score = 时间戳）→ 任一请求完成 → Pub/Sub 广播 → 队首会话被唤醒抢占 → 客户端断开 / 超时 → 过期信号量回收。公平性语义：先来先得 + 单会话不霸占 + 无轮询开销。

事务一致三件套：RocketMQ 事务消息——半消息先落 MQ → 执行本地事务（分块任务落库）→ 提交 / 回滚消息 → 失败靠回查补偿，保障「分块任务与业务状态要么一致成功要么一致失败」；幂等键防重试重复；远程刷新 = 分布式锁 + 状态机（刷新中 / 完成 / 失败——防并发重复刷新与刷新中脏读）。

• 参数基线：并发上限按模型供应商配额压测定（非拍脑袋）；排队深度上限 + 排队超时（超时快速失败并提示，不无限排）。
• Lua 抢占脚本要点：检查 + 占用 + 写 ZSET 必须一个脚本内完成（拆开即竞态）；释放与唤醒同样原子化。
• 入库流水线：解析 → 切块 → 向量化 → 入库各步经 MQ 串联，每步幂等（任务 ID + 步骤号）；失败进重试队列，超限进死信人工处理。
• 压测验证：JMeter / Gatling 模拟并发问答，验证排队公平性（会话间延迟方差）与抢占正确性（不超发）。

• 为什么不用「简单信号量」限并发？信号量只限总量不保公平（后到者可能抢到先到者的坑）；且客户端断开后许可泄漏需额外回收机制——ZSET + 信号量组合同时解决公平与回收。
• 为什么「恰好一次」要靠事务消息而非本地事务？分块入库横跨「业务库状态 + 向量库写入 + MQ 通知」多资源，本地事务管不到；事务消息把「消息发送」与「本地事务」绑成原子，再以幂等覆盖消费端——跨资源一致性的标准解。
• 僵尸会话的危害？客户端断开后仍占并发坑，模型额度被空耗；过期信号量（TTL）自动回收是公平性的兜底。

• 抢占逻辑非原子：检查与占用分离，并发下超发打爆模型；Lua 单脚本原子完成。
• 排队无超时：高峰期请求无限排队，用户体验与资源双输；排队上限 + 快速失败。
• MQ 消费不幂等：重试导致重复向量化 / 重复入库；幂等键 + 唯一约束。
• 刷新无状态机：并发重复刷新引发脏读与资源浪费；分布式锁 + 刷新中 / 完成 / 失败三态。

本卡定位：本卡是模式清单与「调 API 不等于生产级」检查项的唯一登记处。

这道题考察的是 「调 API ≠ 生产级 Agent」的完整工程差距：从 Demo 到生产，模型调用之外还缺哪些工程件（分块策略、查询改写、混合检索、模型容错、流量保护、可观测、治理审计）？工程细节清单如何映射为「生产 Checklist」？以及中间件 / 基础组件的 Starter 化交付范式（防重 Starter：AOP + 注解复用）如何提升工程复用度。

四大常见误区的工程展开：① 调 API ≠ 会 RAG / Agent——分块、改写、混合检索、容错、可观测才是效果与稳定的决定因素；② RAG ≠ 检索 + 生成——每环都有坑（切粗 / 未改写 / 未融合 / 未重排）；③ 接框架 / MCP ≠ 企业级——增量更新、多租户、风控、可观测缺一不可；④ 只关注模型忽略工程——检索策略 / 分块 / 上下文管理决定效果上限。

生产 Checklist（Demo → 生产差距清单）：

• 复用度工程化：跨业务复用的横切能力（防重复提交、审计、限流）抽象为 Spring Boot Starter（AOP + 注解 + 自动装配）——防重三层（Web Token + 分布式锁 + MQ 去重表）抽象为 Starter 是范式样板；「一次实现，多业务接入」。
• 线程池治理同理：AI 链路专用线程池（按链路隔离 + TTL 上下文透传）参数经压测标定，动态调参与监控告警用动态线程池框架（详见 A25.02）。
• 叙事纪律：项目按「问题 → 方案权衡 → 数据验证」组织，不按技术清单罗列；每个能力配可量化成果（QPS / P99 / 命中率 / 成本降幅）。
• 二刷策略：第一遍跟做功能，第二遍专攻生产级改造（加监控 / 压测 / 容错 / 文档）——工程化是项目完整度的分水岭。

• 为什么「证据短路」优于「生成后校验」？生成后校验要烧一次生成成本且只能事后拦截；在编排层检索无证据时直接短路返回，零模型成本、零幻觉出口——把「不说错」变成「结构上不能错」。
• 为什么 Starter 化是 Java 团队的复用杠杆？AI 工程的横切能力（审计 / 幂等 / 防重 / Trace）在各业务线重复出现；Starter 自动装配 + 注解声明把「接入成本」压到一个依赖，同时统一实现质量。
• 「问题 → 权衡 → 数据」叙事的本质？AI 工程没有标准答案只有权衡（Workflow vs Agentic、ES vs Redis 组装、轮询 vs 延时消息）——能讲清权衡与验证数据才是架构能力，技术清单只是词汇量。
• Demo 玩具化的自检？追问三连能否回答：数据一致性怎么保证？异常路径测过吗？压测数据是多少？——答不出即为 Demo。

• 把 Demo 直接上生产：无容错无观测无治理，首次突发即故障；对照 Checklist 逐项补齐。
• 横切能力各写一套：每个业务线自己实现防重 / 审计，质量参差；Starter 化统一。
• 技术堆砌无主线：架构文档按技术罗列，讲不清为什么；按问题组织。
• 压测数据缺失：容量规划拍脑袋；关键链路压测标定 + 告警阈值设临界点 70–80%。

这道题考察的是 LLM 应用测试与传统 Java 单测的本质分野：模型输出非确定，逐字 assertEquals 必然脆断——断言策略必须从「值相等」迁移到「结构合法 + 语义达标 + 规则约束」，并用 Golden Set + RAGAS/DeepEval 指标 + CI 回归门禁把「效果质量」变成可机器判定的工程闸口。核心在于回答：哪些测试仍用传统手段、哪些必须换范式、回归门禁卡在哪一层。

测试栈的四层演进：传统单测（JUnit 5 + Mockito，覆盖工具函数、分块、改写、融合等非 LLM 纯逻辑）→ 集成测试（Spring Boot Test + Testcontainers，起 PGVector / ES / Redis 容器验证真实检索链路）→ Mock 模型层（本地 stub ChatClient，固定返回跑通编排逻辑，不烧 Token）→ 效果评估层（Golden Set + 离线指标 + LLM-as-Judge，判定「答得好不好」）。

关键路径测试思想的引入：散点单测兜不住端到端质量，应对「分块→改写→混合检索→Rerank→生成」主链路做端到端断言——这与传统后端「核心交易链路集成测试优先」是同一工程直觉的迁移。评测框架从 Python 生态的 RAGAS/DeepEval 原生，演进为 Java 侧的绑定调用或自研打分，指标体系不变（忠实度、答案相关度、上下文召回率、噪声敏感度）。

非确定性断言的四条第一性策略：

Golden Set 的定位：业务沉淀的「问题→标准答案 / 标准召回文档」对，是效果回归的真值锚点；离线指标（忠实度 Faithfulness / 答案相关度 Answer Relevance / 上下文召回率 Context Recall）在锚点上计算。回归门禁把评估搬进 CI：Golden Set 指标低于阈值则阻断合并——效果质量从「上线后感知」左移到「合并前拦截」，这是 AI 应用 CI/CD 与传统 CI 最大的结构差异。

• 分层铺测试：非 LLM 纯逻辑（分块 / 改写 / 融合 / 重排器接口）用传统单测高覆盖；检索链路用 Testcontainers 起真库集成验证；编排逻辑用 stub 模型跑通且零 Token 成本；效果质量用 Golden Set + 指标评估——四层各司其职，不要用 LLM 调用做本该 stub 的测试。
• CI 门禁设计：Golden Set 规模从 50–100 条起步，随 Bad Case 持续回灌；忠实度 / 召回率阈值按业务容忍度设定（如忠实度 >=0.9、Context Recall >=0.85），低于阈值阻断合并。
• 快照基线纪律：模型或 Prompt 升级必须先跑 Golden Set 全量回归，diff 报告人工确认后才允许更新基线快照——防止「顺手更新基线」掩盖真实回退。
• Java 侧实现：RAGAS/DeepEval 的 Java 绑定，或用 ChatClient 自研 LLM-as-Judge 打分（注意 Judge 自身的偏差校准，见 A06.02）。

Python：非确定性输出改用「结构 + 语义 + 规则」三层断言

# test_llm_assertions.py
import json, re
from ragas.metrics import faithfulness, answer_relevancy

def test_structure_and_rules():
    out = predict("订单 12345 能退吗？")
    # ① 结构合法：必须能被业务层解析
    payload = json.loads(out)
    assert {"answer", "citations", "need_human"} <= payload.keys()
    # ② 规则约束：高风险场景必须转人工
    assert payload["need_human"] is True
    # ③ 禁止逐字断言：assertEquals(out, "……") 会因采样温度脆断
    assert not re.search(r"保证|一定可以", payload["answer"])

def test_semantic_metrics():
    score = faithfulness.score(
        answer=predict("订单 12345 能退吗？"),
        contexts=["退款规则：签收 7 日内可申请"],
    )
    assert score >= 0.85, "忠实度低于门禁阈值"

Java：JUnit 5 动态测试把 Golden Set 每一行变成独立用例

// Java：评测集驱动的动态测试，失败可定位到具体 case
@TestFactory
Stream<DynamicTest> goldenSetCases() throws Exception {
  List<GoldenCase> cases = mapper.readValue(
      Path.of("eval/golden.jsonl").toFile(), new TypeReference<>() {});
  return cases.stream().map(c -> DynamicTest.dynamicTest(c.id(), () -> {
    Answer a = agent.answer(c.question());
    assertTrue(a.structured(), "输出不可被业务层解析: " + c.id());
    assertTrue(a.citations().size() > 0, "缺少引用: " + c.id());
    assertFalse(a.text().contains("保证"), "绝对化措辞: " + c.id());
  }));
}
record GoldenCase(String id, String question, String expected) {}

• 为什么「结构 + 语义 + 规则」三分而非单一相似度？三者对应三种失败模式：结构错是工程缺陷（必须零容忍硬断言）；语义偏差是效果问题（容忍带内波动）；规则违反是合规红线（一票否决）。混淆三者会导致要么测试脆断、要么红线失守。
• Golden Set 的两重身份：既是回归测试集（防回退），又是效果基线（衡量优化收益）——同一份数据服务两个目的，因此构建标准必须严：问题覆盖真实分布、标准答案经业务确认、标准召回文档随知识库版本同步维护。
• 与监控的分工（对齐 A06.01）：CI 离线评估回答「这次改动是否变差」，线上监控回答「真实流量下质量是否漂移」——Golden Set 回灌是二者之间的数据闭环接口。
• 成本视角：LLM-as-Judge 每次回归都有 Token 成本，工程上按层裁剪——结构 / 规则断言零成本先行，仅对通过者跑语义评估，失败短路。

• 把 LLM 输出当确定性输出测：逐字符断言导致用例随机红绿，团队对测试信号脱敏——这是 AI 测试最常见的「假测试」形态。
• 阈值拍脑袋且永不校准：相似度阈值不随模型升级重新标定，可能锁死旧模型口吻、误杀新模型合理输出；阈值应随基线重建而重标。
• Golden Set 只增不洗：过期问题（知识已更新、文档已下线）留在集里持续制造假阳性回退信号；应随知识库版本同步清理。
• Judge 即真理：LLM-as-Judge 有立场偏差（偏长答案 / 偏自我一致），必须用人工标注子集定期校验 Judge 与人的一致率。
• 门禁形同虚设：CI 跑了指标但失败可手动跳过——门禁必须硬性阻断合并，例外走变更审批留痕。

这道题考察的是 Agent / 工具调用层与稳定性层的专项测试设计：工具契约（Schema 非法入参拦截）、防死循环（调用上限与失败截断）、ReAct 链路收敛、人工确认分支如何用测试锁死；以及并发压测（公平排队 + 限流）与故障注入（模型超时 / 空响应触发三态熔断）如何验证生产容错真实生效。核心在于：AI 系统的「异常路径」比「正常路径」更需要测试资产。

从「测正确」到「测收敛与容错」的演进：传统测试断言「给定输入产出正确输出」；Agent 测试的核心命题变为「给定不可靠的工具与不确定的模型，流程是否收敛、失控是否被截断」。

三段演进线：其一，工具调用从「直接函数调用」演进为「Schema 契约 + 校验拦截」，测试随之引入契约测试（非法入参必须被拒）；其二，循环控制从「模型自觉」演进为「Hook 强制上限」（如运行时用 Hook 限制调用次数），测试随之制造「工具持续失败」场景断言循环被截断；其三，稳定性从「单点超时重试」演进为「首包探测 + 三态熔断 + 公平排队」组合，测试随之引入故障注入与并发压测验证降级链路。

Agent 测试四原则：

• 契约先行：每个 MCP 工具定义 Schema，测试用非法入参验证校验拦截——契约是模型与工具之间的「接口协议」，协议测试优先于功能测试。
• 有界性优先：一切循环必须有工程上限（次数 / 预算 / 时间），测试断言「持续失败场景下循环被截断」而非「最终成功」。
• 确定性锚点：ReAct 链路用 Mock 模型返回固定 Thought/Action 序列，断言最终 Observation 收敛、Checkpoint 持久化正确——把不确定的推理过程变成可断言的状态转移。
• 危险分支显式覆盖：写操作工具「未确认不执行」的分支必须有用例锁定——这是权限模型的一部分，不是边缘 case。

稳定性测试双手段：并发压测（JMeter / Gatling 模拟并发问答）验证 Redis ZSET + Lua 原子抢占的公平排队与限流在高压下真实生效、不超卖不饿死；故障注入（随机让候选模型超时 / 空响应）验证三态熔断降级与首包探测切换按预期触发。二者合起来回答一个问题：容错代码在生产故障中会不会真的工作。

• 契约测试落地：为每类工具建「合法入参样本集 + 非法入参攻击集」，CI 中对 Schema 校验层做参数化断言；模型方言适配器同样覆盖异常分支。
• 防死循环用例：构造「工具恒返错误」的 stub，断言 Hook 在第 N 次调用后终止循环并产出可观测的失败原因；同时断言「成功后停止调用」防止无意义空转。
• 压测场景设计：三档——正常并发（验证吞吐）、突刺并发（单用户刷爆，验证公平排队隔离）、持续高压（验证排队深度上限与过载丢弃策略）；每档都要断言排队指标（ZSET 深度、Lua 抢占成功率）。
• 故障注入矩阵：超时 / 空响应 / 慢响应 / 交错失败四类，逐类断言熔断状态转移与降级输出（降级答案 / 明确报错，而非静默失败）。
• 长链路专项：SSE 全局超时 + 客户端断开取消需专项验证——断开连接后任务应被取消、资源应被释放，而非后台空烧 Token。

• 为什么故障注入比单元级 Mock 更有价值：熔断 / 排队 / 探测是组合行为——单组件测试各自通过不代表组合正确（如熔断打开瞬间排队中的请求如何处理是典型缝隙）。注入测试在近真实拓扑下暴露组合缺陷。
• Checkpoint 断言的状态机本质：ReAct 链路测试真正断言的是「状态机转移的正确性」——每步 Observation 后状态可恢复、中断后可续跑，这把 Agent 测试拉回工程可控域。
• 公平排队的测试视角：ZSET + Lua 的原子性在低并发下难以区分对错，压测的意义正是把「理论原子」逼成「实证原子」——排队深度、抢占成功率是公平性的可测代理指标。
• 与 A06 评测的关系：本卡测「工程行为」（收敛、熔断、排队），A06 测「效果质量」（忠实度、召回率）——二者互补，缺一不可。
• 为什么评测断言不能只看字符串相似度？流畅的错误答案在文本相似度上往往得分不低，而正确的结构化输出可能因字段名顺序被判低分。断言应落在语义指标上：要点覆盖、依据命中、拒答正确率、工具副作用是否符合预期，并用固定盲集做指标级回归；持续集成门禁以不低于基线为阻断条件，而不是以生成成功为通过条件，且评估集须与线上流量隔离。

• 只测 happy path：工具全部正常时链路通，就认为可上线——生产事故 90% 发生在工具失败、模型超时、并发突刺这些没测过的分支上。
• 上限设置形同虚设：Hook 限制存在但从未被测试触发，真出事才发现上限配置错误或根本没生效。
• 压测只压单接口：只压问答主链路、不压「排队 + 熔断 + 降级」的联动路径，突刺场景下降级链路可能死锁或雪崩。
• 断开不取消：SSE 客户端断开后后台任务继续烧 Token——这是最隐蔽的成本泄漏，必须专项用例锁定。
• 故障注入污染共享环境：注入实验未隔离，殃及同环境其他服务；注入应在独立命名空间 / 环境执行并限流。

静默失效不会抛异常，只有受控的主动注入才能暴露「监控全绿但语义已错」。本题考察注入点清单、影子流量隔离、故障传播观测与 kill switch 回归门禁。

从功能测试到韧性演练：早期只测正常路径；随后补异常分支单测；再往后引入故障注入验证降级；当前把注入结果接入持续集成回归门禁，并要求演练绑定行为基线。

概率性系统的失败常以「返回成功」的形式出现，被动监控无法观测未触发的退化路径。注入的意义不是制造故障，而是验证控制面是否按预期收缩：预算耗尽是否降级、终审是否生效、告警是否按语义偏离触发。

注入点覆盖工具超时、返回脏数据、检索空结果、模型输出漂移、记忆写入冲突；用影子流量在隔离环境执行，禁止触达生产写路径；观测故障在工具链的传播与放大；每次演练验证降级路径与紧急停用入口，并把结果作为回归门禁卡点。

为什么注入必须隔离生产写路径？验证可靠性不能以产生真实副作用为代价。为什么演练要绑定行为基线？没有基线就无法判断「降级后是否仍在可接受范围」，演练会退化成只看有没有崩。

只在测试环境演练而不覆盖真实编排；注入触发真实写操作；无回滚与停用预案；演练结果不进回归门禁；kill switch 从未被实际触发验证。

这道题考察的是 Java AI 服务的打包运行与「Java×Python」混合部署架构：Spring Boot fat jar 与 GraalVM native-image 的取舍、JVM 调优在 AI 场景的特殊关注点（堆外内存 / GC 停顿 / 线程池隔离）、K8s + HPA 编排中有状态依赖的分离；以及为什么企业主流形态是 Java 管业务编排 / 权限 / 事务、Python（vLLM / TensorRT-LLM）管 GPU 推理、大模型网关居中治理。核心在于回答：每种部署决策背后的约束是什么。

打包形态的演进与取舍：Spring Boot fat jar（生态兼容性最稳，AI 依赖链复杂时的安全选择）→ Spring Boot 3 native-image GraalVM 编译（启动毫秒级、内存更省，但 AI 生态的反射 / 动态代理兼容性需逐项验证）。

部署架构的演进：单体同进程（早期 demo，Python 推理与 Java 业务耦合）→ 混合部署（Java 微服务 + Python 推理 Sidecar / 独立服务，HTTP/gRPC 通信，各自按资源特征伸缩）→ 网关治理层（大模型网关统一鉴权 / 限流 / 路由 / 审计 / 降级 / 多模型管理，插在 Java 服务与模型之间）→ MCP Server 独立部署（工具能力远程化，Java Agent 网络发现调用而非硬编码）。关键演进纪律：先工程治理，再智能路由——没有统一网关的多模型路由只是散乱的 if-else。

混合部署的分工第一性：Java 与 Python 各自留在自己的最强域——Java 承担业务编排 / 权限 / 事务 / 既有系统集成（企业级治理能力的主场），Python 承担 GPU 推理（vLLM / TensorRT-LLM 生态）。边界是 HTTP/gRPC 接口，接口即契约。

• 镜像构建：多阶段 Dockerfile——build 阶段 Maven/Gradle，runtime 用 eclipse-temurin 精简 JRE；镜像瘦身与依赖分层缓存并重。
• HPA 谨慎设定：JVM 应用扩缩要考虑预热（连接池、JIT），副本突增可能短时恶化延迟；QPS 指标配合预热期配置。
• 与既有网关体系融合：大模型网关与既有 Kong / Spring Cloud Gateway 的关系要明确——模型治理能力（多模型路由 / Token 计费 / 档位降级）独立成层，通用流量治理复用既有网关。
• MCP Server 独立化：工具服务从 Agent 进程拆出独立部署，版本演进与 Agent 解耦；Agent 侧通过注册发现而非硬编码引用。
• 压测驱动线程池参数：检索 / 模型调用 / 入库各线程池的 core/max/queue 在压测下标定，禁止拍默认值上线。

• 为什么有状态 / 无状态分离是硬纪律：应用 Deployment 随时扩缩、漂移、重建，数据层（向量库 / 图谱 / Redis）需要稳定存储与序号——混部会导致扩缩误伤数据节点，这是 K8s 编排的第一原则迁移。
• Sidecar vs 独立推理服务的判据：推理负载与业务负载的资源画像完全异构（GPU vs CPU/堆），且扩缩周期不同——独立服务 + 网关路由优于同 Pod Sidecar，除非延迟要求极端苛刻且资源比恒定。
• 「先治理后路由」的深层原因：智能路由（按成本 / 质量选模型）依赖可观测的成本与质量数据——没有网关层的统一审计与统计，路由策略就是无数据支撑的拍脑袋。
• GraalVM 的真实评估维度：收益是启动与内存，代价是反射配置维护与 AI 生态兼容验证成本——对常驻微服务（启动一次长跑）收益有限，对高频扩缩场景收益显著。

• 线程池共享导致相互拖垮：检索慢把模型调用线程池占满，全部请求连锁阻塞——专用线程池隔离 + TTL 上下文透传是底线。
• native-image 盲目上：AI 依赖反射多，未做兼容矩阵验证就切换，生产运行期才炸出序列化 / 代理异常。
• 有状态依赖塞进应用 Deployment：向量库与应用混部，扩缩应用时数据节点漂移导致索引损坏或连接风暴。
• HPA 只看 CPU：AI 服务瓶颈常在外部（模型延迟 / 排队）而非 CPU，纯 CPU 指标扩缩与实际负载脱节；应结合 QPS 与排队深度。
• 网关后置：先接多模型后建网关，鉴权 / 审计 / 限流散落各处，再回头治理的成本远高于起步即建。
• SSE 未配超时放大：网关 / Ingress 默认超时截断流式长连接，用户看到回答中途消失——流式链路的代理超时必须专项配置。

这道题考察的是 文档入库的异步流水线设计与 Agent 的六种部署形态：为什么入库必须异步化（Kafka 分步任务 / RocketMQ 事务消息）、每步如何保证可追踪与幂等；以及企业级 Agent 的完整交付形态为什么是「Web 服务为核心 + 多端嵌入 + 离线调度」的组合而非只有 Web。核心在于回答：不同形态各自的技术载体、Java 工程能力复用度与选型原则。

入库架构的演进：同步入库（请求内完成解析→切块→向量化→入库，长耗时阻塞且失败难恢复）→ 消息驱动的分步流水线（消息驱动方案用 Kafka 驱动解析→切块→向量化→入库各步任务，每步日志可追）→ 事务化可靠入库（事务化方案用 RocketMQ 事务消息保障分块可靠执行，半消息机制对齐「业务写 + 消息发」原子性）。

部署形态的认知演进：从「AI 应用 = 一个 Web API」演进为六形态组合认知——企业级 AI 的核心服务层绝大多数是 Web 形态，但完整交付是「Web 为核心 + 多端嵌入 + 离线调度 + 边缘私有化」的矩阵。

六种部署形态对照：

异步流水线三原则：分步解耦（每步独立消费、独立重试、独立日志）；可靠投递（事务消息保证「业务落库」与「消息发出」原子，消费端幂等去重）；全程可追（每步任务状态与失败原因可查，支持断点重放）。

• 入库流水线选型：已有 Kafka 生态选 Kafka 分步任务（日志丰富、生态成熟）；强一致诉求选 RocketMQ 事务消息（半消息回查机制对齐业务与消息的原子性）。
• 幂等设计：每步消费以「文档 ID + 版本号 + 步骤」为幂等键，重复消费直接跳过；失败进死信队列并告警。
• 形态组合落地：核心管控（权限 / 审计 / 多租户 / 计费 / 监控）收敛到 Web 中心服务；重计算 / 私有数据走边缘或云端；批量与定时走 Worker——治理保中心，算力按需放。
• ②③④ 形态的有状态管理：会话快照、中断续跑、状态机持久化是共性需求（区别于无状态 Web），Checkpoint 机制（对齐 A08.05）在此形态是必需品。
• ⑤⑥ 形态复用：把 Agent 能力封装为流程节点或调度任务，直接复用既有 BPM（Camunda）与分布式调度（XXL-JOB / 云调度）经验，执行节点是独立 Worker 不处理 Web 请求。

• 为什么 Web 是「核心」而非「全部」：标准化对接（HTTP/SSE）、交互天然适配、中心化管控（治理抓手）、框架默认形态（Spring AI / LangChain 服务化最终都是 Web API）——四个因素使 Web 成为治理收敛点；但批处理 / 嵌入 / 边缘场景天然非 Web，强塞 Web 形态反而破坏治理。
• 事务消息 vs 分步日志的本质差异：Kafka 方案用「可追溯」换「最终一致的事务性」；RocketMQ 事务消息用半消息回查直接对齐原子性——按业务对入库原子性的容忍度选型，而非按技术偏好。
• Java 降维优势的落点：六形态中复用度「极高」的三项（①③④）恰好是 Java 企业级工程的成熟腹地——线程池 / 调度 / 容灾 / 事务经验直接平移，这是 Java 团队做 AI 基础设施的杠杆。
• 消息中间件是 Java 栈的独有变量：对照 Python 栈，Java 侧多了 Kafka / RocketMQ 这层基建——它既是入库可靠性的来源，也是背压与削峰的天然手段。

• 同步入库塞请求链路：大文档解析 + 向量化在 HTTP 请求内完成，超时 / 重试导致重复入库或用户侧长时间白屏——入库必须异步化。
• 流水线无幂等：消息重投导致同一文档切块入库两份，检索出现重复段落、上下文窗口被垃圾占满。
• 失败静默进死信：死信队列无人消费、无告警，文档「悄悄消失」，用户以为知识库有实则检索不到。
• 形态一刀切：把离线批处理硬做成 Web 接口循环调用，失去削峰与重试能力；把嵌入式 Agent 做成重量级 Web 依赖，失去本地轻量优势。
• 边缘形态丢治理：私有化部署只搬功能不搬治理（审计 / 配额 / 监控），合规环境反而成为治理盲区。

这道题考察的是 可观测三支柱在 Java AI 场景的落地差异：Metrics（Micrometer + Prometheus + Grafana，多采集模型首包 / 限流排队 / 熔断次数等 AI 专属指标）、Logging（结构化日志记录改写结果 / 召回文档 ID / 工具出入参）、Tracing（OpenTelemetry + SkyWalking / LangFuse，Run/Node 级链路）。核心在于回答：AI 应用可观测的重点为什么是链路质量——模型答得好不好、工具调没调对、检索是否召回——而非仅系统健康。

从系统观测到链路质量观测的演进：传统可观测回答「服务是否活着、延迟多少」（JVM GC / 线程池 / QPS）；AI 应用的故障模式新增了「系统全绿但回答是错的」——检索没召回、工具调错、Prompt 失效都表现为「健康指标正常 + 业务质量崩坏」。观测重心随之从资源指标扩展到链路质量指标。

Java 侧工具栈的演进融合：Metrics 从裸 Micrometer 到 Actuator 暴露 /health / /metrics / /prometheus 与 K8s 探针、Prometheus scrape 集成；Tracing 从纯 APM（SkyWalking）到 AI 链路平台（LangFuse）的双栈并用——前者看服务拓扑，后者看「改写→召回→Rerank→生成」的 AI 节点级拆解。

三支柱的 AI 专属采集内容：

结构化日志的第一性：AI 链路的排障查询模式是「按 trace_id 串联一次问答的全节点」——日志必须结构化（JSON 字段而非自由文本），召回文档 ID、工具出入参、Token 数都是一等字段，才能支撑「答非所问」的定位。

• 指标分层埋点：资源层（JVM / 线程池 / 连接池）、服务层（QPS / 延迟分位）、AI 链路层（首包 / 总耗时 / Token / 排队深度 / 熔断计数）三层指标分开命名与告警。
• Actuator 集成：/prometheus 端点接入 scrape；/health 按依赖分组（向量库 / 模型网关 / Redis）支持就绪探针细粒度。
• LangFuse 双栈：SkyWalking 看微服务拓扑与 JVM，LangFuse 看 AI 节点级输入输出与 Token 成本——管理端看趋势与配置 Diff 用后者。
• 日志字段规范：强制 trace_id 贯穿 + 节点名 + 输入摘要 + 输出摘要 + 耗时 + Token，敏感字段脱敏后记录。
• Grafana 看板分角色：值班看稳定性（错误率 / 熔断 / 排队），算法看质量（召回率 / 忠实度趋势），业务看用量（Token 成本 / 会话量）。

Java：Micrometer + Actuator 暴露 AI 专属指标

// Java / Spring Boot 3：AI 指标与 JVM 指标分开命名、分开告警
@Configuration
public class AiMetricsConfig {
  @Bean
  MeterBinder aiMetrics() {
    return registry -> {
      Counter.builder("ai.model.requests")
          .tag("model", "qwen-max").description("模型调用次数")
          .register(registry);
      Timer.builder("ai.model.first.token")
          .description("首 token 时延")
          .publishPercentiles(0.5, 0.95, 0.99)
          .register(registry);
      Gauge.builder("ai.queue.depth", queue, Queue::size)
          .description("限流排队深度").register(registry);
    };
  }
}

// application.yml
// management.endpoints.web.exposure.include: health,metrics,prometheus
// management.endpoint.health.group.readiness.include: vectorStore,modelGateway,redis

Python：LangFuse 作为 AI 链路平台，与 SkyWalking 双栈并用（器维横切组件）

# Python：系统拓扑看 SkyWalking，AI 节点级输入输出看 LangFuse
import os
from langfuse import Langfuse
from langfuse.decorators import observe, langfuse_context

lf = Langfuse(public_key=os.environ["LANGFUSE_PK"],
              secret_key=os.environ["LANGFUSE_SK"])

@observe(name="rag.answer")
def answer(question: str) -> str:
    # ① 改写节点
    with lf.trace(name="rag.answer", input={"q": question}) as t:
        rewritten = t.span(name="rewrite").end(output=question)
        # ② 召回节点：记录文档 ID 与相似度，供「答非所问」定位
        docs = retrieve(rewritten)
        t.span(name="retrieve").end(output=[d.id for d in docs])
        # ③ 生成节点：Token 与成本归到该 generation
        gen = t.generation(name="chat", model="qwen-max",
                           input={"docs": [d.id for d in docs]})
        text = do_generate(question, docs)
        gen.end(output=text, usage={"input": 820, "output": 156})
        langfuse_context.score_current_trace(name="faithfulness", value=0.91)
        return text
    # 结构化日志仍须带 trace_id；LangFuse 管质量，ELK 管排障原始字段

• 为什么「首包时间」是 AI 服务的一等指标：流式交互下用户感知的是首包延迟而非总耗时——首包由路由决策 + 模型排队 + 探测共同决定，是链路质量与用户体验的交叉点，也是模型档位切换是否生效的直接信号。
• Trace 粒度的选择逻辑：Run/Node 级（每次问答内的每个节点）是 AI 链路的最小诊断单元——只到服务级无法区分「召回差」还是「生成差」，只到 Token 级成本过高。
• 工具调用追踪的定位价值：记录来源 / 参数 / 结果 / 耗时，能把「答非所问」精确定位在召回层（没检到）还是生成层（检到了没用好）还是工具层（参数错 / 返回空）。
• 多线程池的可观测映射：隔离的 10 个专用线程池（检索 / 模型 / 入库等）各自暴露活跃度与队列积压——线程池指标从「一个池」变成「池矩阵」，是 Java AI 服务 Grafana 看板的特色区域。

• 只看系统指标不看链路质量：GC 正常、QPS 正常，但召回率已连续三天下滑无人知晓——链路质量指标必须进看板与告警。
• 日志自由文本：答案与召回内容整段打进日志，无法按字段检索聚合，排障退化为肉翻日志。
• Trace 不贯通：跨服务（网关→编排→工具）trace_id 断裂，一次问答的链路拼不完整，定位失效。
• Token 成本无观测：只在账单日发现成本暴涨，中间无速率指标与阈值告警——成本异常是可观测问题（对齐 A22）。
• 观测数据本身泄露敏感内容：日志与 Trace 记录了完整用户输入与文档内容，未脱敏即入 ELK——观测基建成为数据泄露面。

这道题考察的是 观测数据的运营化闭环：Run/Node 级 Trace 如何支撑「答非所问」的分层定位；影子路由观测（用户手动选文档时后台静默跑完整路由，对比命中率 / 置信度 / 候选排名）如何用真实流量持续反哺路由质量；以及告警分级（熔断 P0 / 排队溢出 P1 / 召回率下滑 P2）与 Bad Case 闭环（Trace + 用户反馈 + 回答溯源沉淀 Golden Set）如何把观测从「看」变成「改进机制」。

观测的三级演进：被动看板（指标上了 Grafana，人来看）→ 主动告警（阈值触发分级通知）→ 闭环反哺（观测数据自动沉淀为优化资产：Bad Case 进 Golden Set、影子路由数据反哺路由模型）。第三级是 AI 应用运维区别于传统运维的标志性成熟度。

影子路由的机制设计：用户手动指定文档检索时，系统在后台静默执行完整自动路由（意图识别→文档选择），记录自动路由的候选排名与置信度，与用户真实选择对比——人工选择的「真值」源源不断产生，路由策略获得免费标注数据。

告警分级的第一性：按「业务影响 × 恢复紧急度」定级——

Bad Case 闭环的数据流：线上发现坏例（用户负反馈 / 质检抽样 / Trace 异常节点）→ 溯源定位（Trace 还原该次问答的改写→召回→生成全链路）→ 归因分层（数据问题 / 检索问题 / 生成问题 / 工具问题）→ 修复动作 → 沉淀 Golden Set 回灌 CI 评测（对齐 A17.01）→ 回归验证。观测、评测、修复三者由此串成环。

• 分层定位 SOP：收到「答非所问」先看 Trace 节点耗时与输入输出——改写层（问题被改坏）、召回层（该召回没召回）、Rerank 层（召回被排挤）、生成层（证据在但没用）逐层排除。
• 影子路由落地：手动选择场景埋点采集（用户选择 + 后台路由结果 + 置信度 + 候选排名），定期统计路由命中率与排名偏差，作为路由策略迭代的依据。
• 容错观测：档位切换次数、首包超时率、三态熔断触发数上板——验证降级策略「真实生效」而非「代码存在」；触发数长期为零可能是探测失灵的假安全。
• 流量保护观测：ZSET 排队深度、Lua 抢占成功率、分布式信号量占用持续监控，防突发流量压垮模型。
• Bad Case 周会制：每周固定评审新增 Bad Case，归因分类统计，Top 类别驱动当周优化优先级。

Java：Observation API 定义 Run/Node 级嵌套 Span

// Java / Micrometer Observation：Run -> Node 两级，字段与 LangFuse 对齐
@Service
public class RagObservation {
  private final ObservationRegistry registry;
  RagObservation(ObservationRegistry r) { this.registry = r; }

  public String answer(String q) {
    return Observation.createNotStarted("rag.run", registry)
        .lowCardinalityKeyValue("scene", "faq")
        .observe(() -> {
          var docs = Observation.createNotStarted("rag.node", registry)
              .lowCardinalityKeyValue("node", "retrieve")
              .observe(() -> vectorStore.similaritySearch(q));
          return Observation.createNotStarted("rag.node", registry)
              .lowCardinalityKeyValue("node", "generate")
              .observe(() -> chatClient.prompt()
                  .user(q + "
" + docs).call().content());
        });
  }
}
// 导出：OTel Bridge 把 observation 转 span，traceparent 透传给 Python 侧

Python：影子路由与 Bad Case 闭环，观测数据反哺 Golden Set（器维组件）

# Python：影子路由 + 失败 case 自动沉淀为评测集
from langfuse import Langfuse
import json
from pathlib import Path

lf = Langfuse()

def shadow_route(question: str, chosen_docs: list, trace_id: str):
    """用户手动选文档时，后台静默跑完整路由并对比命中率。"""
    silent = retrieve(question, top_k=5)
    hit = len({d.id for d in silent} & {d.id for d in chosen_docs}) / max(len(chosen_docs), 1)
    lf.score(trace_id=trace_id, name="shadow_route_hit_rate", value=hit)

def collect_bad_case(trace_id: str, reason: str):
    """Trace + 用户反馈 + 回答溯源沉淀 Golden Set，形成闭环。"""
    t = lf.fetch_trace(trace_id)
    row = {"id": trace_id, "question": t.input["q"],
           "references": t.output.get("doc_ids", []),
           "expected": None, "reason": reason,
           "status": "pending_label"}     # 待标注，不自动当标准答案
    with Path("eval/bad_cases.jsonl").open("a") as f:
        f.write(json.dumps(row, ensure_ascii=False) + "
")

# bad_cases.jsonl 经人工标注后合入 golden.jsonl，参与下次 CI 回归

• 影子路由为什么是 Java 工程化特有手段：它要求「同一请求双路执行 + 结果可比对」的架构支持——Java 侧强类型编排与 AOP 拦截让静默双跑的实现成本极低；本质是把「线上真实流量」转化为「免费评测集」，与灰度发布的思想同源。
• 降级「零触发」的悖论：熔断长期不触发有两种解释——系统真稳，或故障根本没被探测到；只有对探测机制本身做混沌验证（对齐 A17.02 故障注入）才能区分，观测指标（触发次数）是必要非充分信号。
• 回答溯源的合规价值：每个答案关联召回文档 ID 与工具调用记录，既支撑排障也支撑合规审计（谁问了什么、基于什么依据回答）——排障资产与合规资产同源。
• 闭环的飞轮效应：Bad Case 越多→Golden Set 越厚→回归越严→线上质量越高→用户信任越高→反馈越多——观测闭环是 AI 应用质量复利的核心机制。
• 为什么监控要看行为基线而非只看成功率？语义错误常表现为全部返回成功，传统成功率与延迟曲线全绿恰是最危险的信号。应先建立分场景行为基线：工具调用分布、拒答比例、引用命中率、平均步数，再用统计偏离触发告警；同时抑制同源告警风暴，避免一次模型抖动把值班淹没。告警要绑定可回放的故障快照，否则只能知道不对而不知道哪里开始不对。

• 告警全是一个级别：熔断和召回率波动用同一通知渠道同一紧急度，值班疲劳后 P0 被淹没——分级必须映射到不同响应 SLA。
• Bad Case 只记录不闭环：问题收集了一堆，没有归因、没有修复动作、没有回灌 Golden Set——收集沦为形式。
• 影子路由数据脏用：用户手动选择不等于最优选择（用户可能选错），直接当真值训练会引入偏差；应过滤明显误操作样本。
• 溯源链路断裂：Trace 有但召回文档 ID 没记全、工具调用参数没落日志，Bad Case 到了评审会无法归因。
• 指标只增不清理：旧版路由策略的观测指标与新版混在一起统计，趋势失真；策略版本变更必须打标隔离。

传统成功率与延迟对语义错误全盲。本题考察语义正确性指标、行为基线与统计偏离告警、告警雪崩抑制以及故障快照回放如何组成语义 SRE 的观测契约。

观测对象从可用性转向正确性：起初只看 HTTP 成功率与 P99；随后加入 Token 与成本指标；再往后引入语义正确率、引用命中率与拒答比例；当前把行为基线偏离、快照回放与分层告警收敛为常规实践。

语义错误常以「返回成功」的形式出现，故监控对象必须从「调用是否成功」转为「行为是否偏离基线」。基线按场景建立：工具调用分布、平均步数、拒答比例、引用命中率；用统计偏离而非单点阈值触发告警——监控全绿恰恰可能是风险信号。

四维埋点：正确性（语义错计数与返回成功但语义错分开统计）、行为（步数与工具分布）、成本（每完成任务成本）、链路（TraceId 贯穿检索与工具）；指标带租户与版本标签；告警按同源聚合与抑制窗口收敛；每条告警绑定可回放的故障快照，并给出降级与紧急停用入口。

为什么告警雪崩比故障本身更危险？一次模型抖动会同时点亮多个指标，未收敛的告警让值班在噪声里错过主因。为什么「用户静默放弃」必须入指标？它是语义错最诚实的外显信号，且不体现在任何服务端错误码里。

只埋成功率与延迟；指标不带版本标签导致无法归因；用固定阈值而非行为基线；告警无聚合；只记录成功路径；把 fail-plausible（错误被转化为流畅叙述）当成正常回答。

这道题考察的是 Java 业务侧把 AI 能力纳入既有企业安全体系的方法：认证授权复用（Sa-Token / Spring Security 对接既有 SSO，身份贯穿 AI 调用全链路）、Prompt 注入防护（输入净化 + 工具白名单 + Schema 强校验）、写操作人工确认、「无证据短路」架构层防编造。核心在于回答：AI 服务的安全不是另起炉灶，而是把权限 / 校验 / 最小权限原则延伸到模型与工具这一新增攻击面。

安全边界的演进：传统 Web 安全（认证→授权→审计，边界在 HTTP 入口）→ AI 服务安全（新增两个边界：用户输入到模型的「提示注入」面、模型到工具的「越权执行」面）。

防护手段的演进线：裸暴露（模型直接见用户全量输入与全量工具）→ 输入净化（问题经改写 / 校验剥离可疑指令）→ 工具白名单（按场景声明可用集合，如意图树节点指定工具，非全量暴露）→ Schema 强校验（MCP 工具入参强校验拒绝畸形参数）→ 写操作确认（高危动作人工确认后执行）→ 架构级防编造（架构级：检索无证据时直接告知用户，从架构上杜绝编造输出）。

认证授权三原则：

• 身份贯穿：Sa-Token / Spring Security OAuth2 对接既有 SSO，用户身份沿 AI 调用全链路透传——模型调用、工具调用、记忆读写全部携带真实身份，匿名调用链是审计黑洞。
• 数据归属校验：问答 / 文档 / 记忆按 userId / tenantId 隔离，越权访问在入口拦截（身份模块职责），而非依赖下游兜底。
• 最小权限：AI 服务仅持必需权限；调用下游走服务账号 + 作用域限制——Agent 不是超级用户。

注入防护四道闸：输入净化（剥离可疑指令）→ 工具白名单（场景化能力收缩）→ Schema 强校验（畸形参数拒绝）→ 写操作人工确认（不可逆动作出环）。四道闸按「成本递增、信任递减」排列，前道拦截越早，后道成本越低。

• SSO 对接：复用企业既有 Sa-Token / Spring Security OAuth2 体系，AI 服务作为资源服务器接入；Token 校验失败与普通 API 同等处置。
• 工具白名单配置化：意图树 / 场景节点声明可用工具集合，新增工具默认不可见——「默认拒绝」而非「默认开放」。
• 写操作确认规则：MCP 写操作（增删改）强制人工确认，确认动作本身留痕（谁、何时、确认了什么）。
• 无证据短路：检索结果为空或置信度低于阈值时，直接回复「未找到依据」，禁止模型自由发挥——把「不知道」做成架构行为而非模型自觉。
• 模型方言适配器测试：异常分支（畸形响应 / 超长输出）纳入契约测试覆盖，防止适配层成为注入绕过点。

• 为什么「无证据短路」是架构级防幻觉：Prompt 层约束（「请勿编造」）是概率性的，模型可以违反；架构层短路（无证据直接走固定回复）是确定性的，模型无机会违反——治理手段从「求模型」升级为「限模型」，这是工程对概率系统的根本策略。
• 白名单 vs 黑名单的第一性：注入向量不可枚举（黑名单永远滞后），能力可以枚举（白名单完备）——安全边界必须定义在「允许什么」上。
• 身份透传的技术难点：异步链路（线程池切换 / 消息队列）中上下文丢失是身份断链主因——TTL 上下文透传（对齐 A18.01 线程池设计）与消息头携带身份是必备配套。
• 与企业安全体系的融合红利：Java 侧复用既有 SSO / 审计 / 租户体系，AI 安全的边际成本远低于独立建设——这是「把 AI 纳入企业安全体系」而非「为 AI 单独建安全体系」的核心论据。

• 工具全量暴露：所有工具对所有会话可见，一次成功的注入即可触达高危工具——白名单必须按场景收缩。
• 写操作只挡模型不挡绕过：确认规则只在 Prompt 层声明，直接 API 调用工具可绕过——确认必须在工具执行层强制，非模型自觉。
• 身份在异步处断链：线程池 / MQ 环节身份丢失，下游以系统身份执行，审计无法归因到人。
• 输入净化误伤：过滤规则过激把正常业务问题（含「删除」「更新」等词）误拦，可用性受损——净化规则需测试标定。
• 越权校验放下游：入口不校验数据归属，依赖向量库查询时过滤——一处遗漏即数据越权泄露，入口拦截是唯一可靠位置。

这道题考察的是 治理的运营层：审计、租户隔离与成本限速治理：AOP 横切实现全链路审计（谁、何时、问了什么、调了什么工具、得到什么答案）；多租户数据隔离（PGVector 用 tenant_id 过滤、ES 用索引隔离）与「被遗忘权」落地；以及成本与限速治理（模型档位路由、Redis ZSET 公平排队四件套、大模型网关统一限流配额）。核心在于回答：治理如何从「有功能」变成「可追溯、可隔离、可计量」。

审计的演进：散点埋点（各处自行打日志，格式不一、覆盖不全）→ AOP 横切（切面统一记录链路追踪 / 幂等 / 审计日志——横切方案，业务代码零侵入获得全量审计）→ 合规级审计（审计日志与回答溯源关联，支撑「谁在何时基于什么依据得到什么答案」的完整追问链）。

限速治理的演进：简单限流（网关 QPS 限制，先到先得、单用户可占满）→ 公平排队（Redis ZSET + Lua 原子抢占 + 过期信号量 + Pub/Sub 唤醒四件套，保障公平配额防单用户突发压垮模型）→ 网关层治理（统一限流 / 配额 / 成本统计，模型档位按复杂度路由）。

多租户隔离三手段：

审计四问完整性：审计记录必须能回答「谁（身份）、何时（时间线）、问了什么（输入）、基于什么调了什么工具得到什么答案（链路）」——四问缺一即审计不合规。被遗忘权：用户可查询 / 删除自己的对话与记忆，删除必须覆盖向量库、ES、Redis、备份的全副本。

• AOP 审计落地：定义审计注解 + 切面，覆盖模型调用 / 工具调用 / 记忆读写三类边界动作；审计日志独立存储、只追加、独立权限。
• 公平排队四件套实施：ZSET 记录排队（分数 = 入队时间保公平）、Lua 脚本原子抢占（判 + 占一步不可分割）、过期信号量（持锁者崩溃自动释放）、Pub/Sub 唤醒（排队者被通知而非轮询）。
• 模型档位路由：按问题复杂度路由不同成本模型（档位 + 首包探测），简单问题不烧贵模型——成本治理的第一杠杆在路由而非压缩。
• 网关层治理：大模型网关统一限流 / 配额 / 成本统计（对齐 A18.01 网关位置），租户级配额在网关强制而非应用自觉。
• 配置一致性校验：启动期校验模型档位、向量库、限流参数，防误配导致安全或成本事故（早失败原则，对齐 A18.01）。
• 被遗忘权实现：删除 API 按用户级联清理全存储副本并记录删除审计，支持合规查验。

• 为什么公平排队比简单限流更本质：限流回答「允许多少」，排队回答「谁先谁后」——AI 服务成本高、容量刚性，公平性（单用户突发不能挤占他人配额）直接决定多租户体验；ZSET 按入队时间排序正是公平性的数据结构表达。
• Lua 原子性的必要条件：「检查配额 + 占用配额」若分两步，并发下必然超卖——Redis 单线程执行 Lua 脚本提供了判断与占用的原子性，这是分布式信号量正确性的根基。
• 审计与溯源的同源设计：审计日志与 A19.02 的回答溯源共用 Trace 数据——一份链路数据同时服务排障、审计、合规三个消费者，避免三套日志。
• 成本治理的层级观：档位路由（事前省钱）→ 排队保护（事中防冲）→ 网关统计（事后计量）→ 异常告警（反哺前两者，对齐 A22.02）——成本治理是贯穿事前 / 事中 / 事后的闭环而非单点。
• 隔离与合规的耦合：租户隔离既是安全需求也是合规需求（数据不出租户边界），PGVector 的 tenant_id 过滤必须做进索引设计与查询模板，靠开发自觉必然遗漏。

• 审计日志与业务日志混存：审计记录随业务日志滚动删除，合规检查时追溯链断裂——审计日志必须独立存储与保留周期。
• 租户过滤靠 WHERE 手写：某处查询漏加 tenant_id 即跨租户泄露——过滤必须模板化 / 中间件化强制。
• 信号量无过期：持锁者崩溃后配额永久占用，排队者全部超时——过期信号量与续约机制是四件套中不可省的一件。
• 被遗忘权删不干净：只删了业务库，向量库 / 备份 / 审计明细中副本仍在——删除范围必须覆盖全存储拓扑并验证。
• 配额在应用层硬编码：租户配额散落代码，调整需发版——配额必须配置化 + 网关强制。
• 审计记录敏感内容未脱敏：审计明细含完整对话与文档内容，审计库本身成为高价值泄露面——按最小必要原则脱敏存储。

这道题考察的是 知识库入库 ETL 管线的生产化设计与 Embedding 版本治理：解析→清洗→切分→富化→Embedding→入索引的每一步在生产环境要做什么工程决策？切分如何按文档类型选型（五级策略的完整机理见 A09.01）？Embedding 选型为什么必须用业务数据自测而非信通用榜单？以及 Embedding 模型换版为什么是「全库重建级」事件。核心在于回答：进去的是垃圾，出来的就是垃圾——数据工程决定 RAG 效果天花板。

切分与富化的完整方法论见 A09.01：固定大小 → 递归字符 → 结构感知 → 语义 → Agent 智能的五级策略，以及 metadata 富化 / 父子块 / Late Chunking / Contextual Retrieval 的机理与收益数据均在那里展开；本卡只保留「按文档类型选型」结论与 ETL 版本治理。

Embedding 四代演进：Word2Vec（静态，无法多义词）→ BERT（双向上下文，512 窗口）→ BGE-M3（多粒度 8192 + 稠密/稀疏/多向量三合一）/ text-embedding-3-large（3072 维）→ Qwen3-Embedding 等 LLM 直出模型（需专门训练）。

切割策略按文档类型选型矩阵：

Embedding 选型三判断点：中英文比例（中文选 BGE / Qwen3-Embedding，混合选 bge-m3，纯英文选 text-embedding-3-small）；数据合规（不能出境必须开源本地部署）；维度与成本（百万量级 1024 维是平衡点，Matryoshka 表示可降维）。评估铁律：MTEB 通用排行榜不代表你的场景——准备几百条「问题 + 正确答案 chunk」对，用业务数据自测 Hit@K，Hit@5 < 0.7 就该换模型或改进切分。

• ETL 管线分层：解析（PDF 表格 / 双栏 / 扫描件是重灾区，Tika 自检扩展名启动期 fail-fast）→ 清洗（去页眉页脚 / 噪声符号）→ 切分（按类型选策略）→ 富化（metadata 章节路径 + 关键词）→ Embedding（与在线查询必须同模型）→ 入索引。
• 预处理代码量的心理预期：生产级预处理代码量常超过 RAG 核心逻辑本身——这是地基型投入，不可压缩。
• Embedding 版本治理：模型版本入库 metadata 打标；换版即触发全库重建（旧向量与新查询向量不同空间，混用即静默降质）；灰度重建期新旧索引并存 + 双读对比。
• Contextual Retrieval 成本控制：完整文档是所有 chunk 请求的相同前缀，配合 Prompt Caching 可显著降低文档部分的重复计费（计费口径见 A22.01）。
• 入库即验证：入库 Pipeline 每节点落任务日志（对齐 A18.02），入库完成抽检 Hit@K 抽样指标，防止坏数据静默入索引。

• 为什么切分质量是 RAG 效果天花板：LLM 再强也无法从被切碎的语义中还原真相——「跨边界语义两半都召不回」「答案张冠李戴」的根因都在切分层；换更强 LLM 效果没提升时，瓶颈大概率在检索层不在生成层。
• 父子块的第一性：检索需要小块（语义聚焦、向量判别力强），阅读需要大块（上下文完整）——两者矛盾由「小块检索 + 父块返回」的结构化解耦解决，而非折中取中间值。
• 「同模型」约束的数学本质：查询向量与文档向量必须落在同一表示空间才有可比性——建库与查询跨模型版本等于把两套坐标系里的距离当相似度，是静默性最强的 RAG 事故之一。
• Overlap 的扫描仪类比：重叠区是「扫两遍的边缘」——保证任一语义单元至少在一个 chunk 内完整出现，是所有高级切分策略之下的兜底层。

• 整篇文档压成一个向量：细节被平均掉，检索回来全是笼统结果——必须切 chunk（500–1000 token 起点）。
• 表格按行切：行脱离表头后 LLM 无法解读——表格整块保留转 Markdown。
• 英文模型处理中文库：语义空间不适配，效果差却查不出原因——选型必须业务数据 Hit@K 验证。
• Embedding 静默换版：升级模型不重建库，新旧向量混存，检索质量无声劣化且极难归因。
• 先 ANN 后 Metadata 过滤：Top-K 名额先被无关向量占满再被过滤掉——必须先过滤再 ANN。
• 调大 top-K 提效果：尾部相似度平坦，塞入无关 chunk 稀释注意力反而更差——优化方向是多路召回 + Rerank，不是调大 K。

这道题考察的是 向量索引生命周期与混合检索的运维化治理：索引选型（HNSW / IVF 与向量库产品谱系）、增量更新与全量重建的触发时机；三路召回（向量 + BM25 + 图谱）并行、RRF 融合只看排名不看绝对分数的第一性、Cross-Encoder Rerank 两阶段的量化收益、检索漏斗三段独立与证据门控。核心在于回答：检索质量不是调出来的，是治理出来的——靠归因数据持续校准。

检索架构的演进：暴力遍历 → ANN 索引（HNSW / IVF 毫秒级）→ 单路向量 → 混合检索（向量 + BM25 + 图谱）→ RAG 范式谱系。三路召回、RRF 融合与 Rerank 两阶段的完整机理及收益数据见 A09.02，本卡只保留索引侧与运维侧的取舍。

混合检索互补与 RRF 的第一性见 A09.02（BM25 精确强、向量语义强；RRF 只取排名不取原始分数，因分数量纲不可比）。本卡只强调运维结论：每路排名来源必须真正独立，否则同一文档会以多个「独立路」身份被自我加权。

检索漏斗与门控（生产实践）：漏斗三段独立——recall 20 → candidate 40 → contextTopK 10，启动期校验单调性，任何一段调参不动其他段；后处理责任链去重（保留首次命中，多路命中不丢）→ RRF 融合（vector / keyword 权重 1.0，graph / web 0.5）→ Rerank 精排 → 证据门控（整批最高精排分低于阈值整批丢弃，宁可拒答不硬撑）。

• 向量库选型：Milvus（十亿级企业首选，需 K8s）/ Pinecone（全托管 SaaS）/ Weaviate（原生混合检索）/ Qdrant（Rust 高性能自建）；已有 PG / ES 的团队用 pgvector / ES 向量扩展，运维成本近零。
• 索引生命周期管理：增量更新（在线 upsert）为主；全量重建仅三种触发——换 Embedding 模型、改切分策略、切分重大架构调整；重建期新旧索引并存双读对比后切换。
• 归因日志校准权重：记录融合池 / 送排 / 精排存活按通道分布、精排分高低端、图谱存活率——RRF 权重（如 graph / web 0.5）就是这样从数据里调出来的，不是拍的。
• 单通道故障隔离：三路并行 orTimeout 超时按空结果降级，单通道失败不影响主链；Rerank 只对粗排 Top-20（Cross-Encoder 每候选拼接过模型，计算量不能大）。
• 门控阈值标定：用「已知在库 + 已知不在库」测试集跑 Rerank 分数分布找切点，经验区间 0.3–0.6，金融医疗等高风险场景偏高。

• RRF 自我加权的陷阱：定向检索与全局检索若共用同一向量通道，同一文档会以两个「独立路」身份重复计分被自我加权——生产上必须让每路的排名来源真正独立（用不可变 results 取名次）。
• 为什么索引重建是「架构级事件」而非运维操作：换模型 / 改切分意味着全库表示空间或语义单元变更，所有下游（Rerank 阈值 / 权重 / Golden Set）都可能需要重标定——必须走灰度 + 双读验证流程。
• 四层优化的分工记忆法：索引层保证「存进去可被找到」→ 查询层保证「搜索姿势对」→ 召回层保证「不漏」→ Rerank 层保证「送进 LLM 的真有用」；按症状定位层：提问质量差上查询层，单路漏召上召回层，粗排精度不足上 Rerank。
• Hit@5 高但答案差的诊断：内容找到了但排名靠后——看 MRR，加强 Rerank；这体现「检索指标要成对看」的运维纪律。

• 不 Rerank 直接全塞：Token 暴涨 + 注意力稀释，中间信息被忽略——Cross-Encoder 精排 Top-3~5 必配。
• 无证据门控：Rerank 最高分极低仍硬生成，检索层幻觉（没召回靠模型编）直接穿透——门控拒答是最后一道闸。
• 索引只建不运维：HNSW 参数（ef / M）从不按召回率 / 延迟实测调优，删除文档成僵尸向量永不清理。
• 多路召回延迟按 sum 估：三路并行延迟取 max 不加 sum——容量规划按错误模型估会严重过度 provisioning。
• RRF 权重拍脑袋永不校准：无归因日志，权重失真无从发现；融合分数分布漂移是需要监控的指标。

先删后增和裁决次序只在第一性原理里用一段话钉死，不再展开成第二套教程（幻觉门控见 A09.05）。本卡要回答的是索引生命周期与对账：刷新中用户会不会看到空库、向量 / 关键词 / 图谱会不会删不齐、灰度版本能不能按标签回滚、孤儿 chunk 靠什么巡检发现。

运维形态的演进：停机全量重建（小库可承受）→ 在线刷新但无快照（删除与写入之间出现空窗）→ 锁 + 状态机 + 查询打旧快照 → 按 version 灰度、可回滚 → 文档清单与各索引定期对账。幻觉门控见 A09.05，本卡跟踪这些运维状态。

文档和 chunk 是一对多：改一句可能让切分边界整体挪动，新旧 chunk 对不上号，逐条 UPDATE 会留下孤儿或漏更新。所以替换以文档为单位，先删掉该文档的旧集合再写入新集合。冲突时先看适用范围，再看来源权威和版本，最后才用相似度——相似度只说明像不像。下面只写这些动作怎么进生命周期和对账。

索引生命周期：

• 生产推荐组合：事件驱动触发（文档变更事件）+ hash 检测（精确识别需更新文档）+ 先删后增（集合级一致性）——全量重建仅用于换模型 / 改切分的重大调整。
• 灰度更新：新版本知识先小范围生效，验证后放量；回滚后保留变更记录，可定位受影响的历史答案并主动修正。
• 变更期间防脏读：知识库远程刷新用分布式锁 + 状态机（刷新中 / 完成 / 失败），刷新期间查询路由到旧快照——更新原子性对用户可见。
• metadata 支撑裁决：入库时必须把适用范围（产品线 / 生效日期 / 部门）写进 metadata，否则裁决次序的第一段无从执行——裁决能力是入库时预埋的，不是检索时凭空的。
• 僵尸 chunk 巡检：定期对账「文档清单 ↔ chunk 归属」，发现孤儿 chunk 告警清理。

• 空窗怎么测？刷新过程中持续打查询，断言命中数不为 0，且命中的 version 要么全旧要么全新，不允许混杂。
• 多索引删不齐怎么发现？对账作业按 doc_id 求各索引差集，差集非空即告警，而不是等用户搜到旧答案。
• 回滚之后历史答案怎么追？每次刷新留下 version、操作者与受影响 doc 列表，才能定位「哪批回答引用了已回滚的知识」。
• 与 A09.05 的分工：A09.05 守幻觉门控；先删后增和裁决次序的短证明在本卡第一性原理，刷新、灰度、脏读防护和巡检也在本卡。

• 改文档后旧答案还在：僵尸 chunk 没删干净——先删后增 + 多索引联动删除 + 巡检对账。
• 单条 UPDATE 思维：试图做「精确替换」，边界位移场景必然漏更新——放弃逐条映射，用集合级先删后增。
• 时间戳一刀切：一律取最新忽略适用范围——老版本对老产品仍有效，范围裁决在时间裁决之前。
• 矛盾知识随机引用：无裁决层，检索排序隐式裁决——输出时对时错，用户信任崩塌。
• 更新期间不防脏读：删除完成、新增未完成时查询命中空窗，用户看到「知识消失」——刷新须加锁 + 状态机。

这道题考察的是 AI 特有的成本工程三杠杆：Token 消耗统计与预算（每次调用记录 input/output token、模型档位、归属租户）、语义缓存与命中率（相似问题直接命中缓存不调模型）、按成本模型路由（按问题复杂度路由不同档位模型）。核心在于回答：降本的第一杠杆是「少用贵模型」，第二杠杆才是「少传 Token」——排序错则事倍功半。

成本意识的演进：无成本观测（只看月账单）→ 调用级统计（每次调用记 token / 档位 / 租户）→ 预算与配额（租户级限额）→ 主动降本三件套（档位路由 / 语义缓存 / 上下文压缩）→ 资源级优化（闲时降配 / 批量合并推理 / Prompt Caching / KV Cache）。

成本构成四项：模型调用（Token，通常占比最大）、推理算力（GPU）、存储（向量库 / 对象存储）、工程人力。传统业务没有、AI 场景必须补的工程能力：Token 统计、按租户计费、模型配额、成本归因闭环。

三大杠杆的优先级第一性：

档位路由的解析序：thinking=true → DEEP → 显式 override → 默认档位；启动期校验档位必填 timeout、候选 id 在注册表、DEEP 档必须有支持思考的候选——fail-fast 防止错误配置静默烧钱。

• 调用级记账：拦截层统一记录 input / output token、模型档位、归属租户（OAuth2 / JWT 租户标识贯穿）、耗时——记账是后续一切优化与计费的数据底座。
• 成本归因闭环：按业务线 / 场景聚合成本，定位高成本链路（长上下文 / 冗余召回 / 未命中缓存），迭代 Prompt / 切片 / 缓存策略——归因把账单变成优化路线图。
• 语义缓存落地：缓存键 = 问题向量相似度匹配（非精确匹配），相似度阈值按业务标定；缓存必须带租户隔离，跨租户命中即数据串权。
• 闲时降配：低峰期切换小模型或降配实例；批量请求合并推理提升 GPU 利用率。
• Prompt Caching 计费数学：首次写入 1.25 倍计费、后续命中 10%——重复前缀（系统提示 / 文档前缀）越长越值，Contextual Retrieval 场景文档部分成本可降到 10%–20%。

• 为什么路由排在压缩之前：压缩（上下文裁剪）有语义损失风险且只能省输入侧；路由让简单请求直接走低价模型，无质量感知损失地砍掉「贵模型溢价」——先降「适用档位」再压「单次用量」，损失面最小。
• 语义缓存的命中率经济学：命中率提升的价值是「免去一次完整推理」，成本是相似度误判风险——高重复率场景（客服 / 政策问答）ROI 极高，创意生成场景几乎为零且有害。
• KV Cache / Prompt Caching 与上下文压缩的互补：前者是「同样的前缀少算钱」（供应商侧机制），后者是「少传前缀」（应用侧机制）——先压缩到必要内容，再让必要内容吃缓存折扣，两层叠加。
• 成本指标是可观测的一部分：Token 消耗速率、缓存命中率、档位分布都是一等 Metrics（对齐 A19.01）——成本异常必须在速率层发现，而非月底账单。
• 为什么单位成本要按完成的任务核算？Token 单价只覆盖显式调用，真实开销还包括精炼循环、重试、监督与人工终审、协议与序列化开销，以及失败任务已消耗却未产出的部分。以每完成一个合规任务为分母建立成本指标，才能暴露便宜模型但反复重试这类反直觉亏损；预算硬顶要落到会话与租户两级，触发后走降级或拒答，而不是继续透支。

• 只看总账单不归因：不知道钱烧在哪个场景哪类调用，优化无从下手——归因维度（业务线 / 场景 / 档位）必须在记账时埋好。
• 语义缓存不分租户：A 租户的问题命中 B 租户的缓存答案——数据泄露级事故，缓存键必须含租户隔离。
• 压缩阈值激进破坏语义：上下文压过头，关键约束丢失，回答质量下降省了小钱赔了效果——压缩需配效果回归验证（对齐 A17.01）。
• 档位路由错误配置静默烧钱：DEEP 档候选配错或超时缺失，异常时全量 fallback 到最贵模型——启动期 fail-fast 校验必须做。
• 统计不含失败调用：重试与熔断切换产生的隐性 Token 消耗不入账，成本模型失真。

这道题考察的是 成本治理的计量与闭环层：按租户计费与配额（QPS / 日调用量 / 并发上限，超限降级或排队）、出账维度与多租户体系打通、ROI 度量模型（业务效果提升 vs 成本的量化）、成本异常告警。核心在于回答：配额是「防失控」的闸，ROI 是「证明值」的尺——二者共同让 AI 项目从「烧钱实验」变成「可经营的业务」。

计费治理的演进：无计量（内部免费敞开用）→ 简单限额（全局限流，无租户维度）→ 租户级配额（QPS / 日调用量 / 并发三维配额，超限分流处置）→ 计费化（Token 计费写入审计，出账对齐多租户体系）→ ROI 闭环（成本与业务效果联动度量，反哺投入决策）。

超限处置的演进：硬拒绝（体验粗暴）→ 降级（超限切低价模型）→ 排队（Redis 公平排队保配额公平，对齐 A20.02）→ 分场景策略（付费租户排队 + 免费租户降级）。

配额表设计四要素：主体（租户 / 用户 / 场景）、维度（QPS、日调用量、并发上限、月 Token 预算）、动作（超限降级 / 排队 / 拒绝）、周期（配额重置策略）。配额在网关层强制而非应用自觉——应用层配额在多副本下天然失真且易被绕过。

ROI 度量模型：ROI =（业务效果增益折算价值 − 总成本）/ 总成本；分子取「可量化业务指标改善」（人工替代工时 / 转化提升 / 响应时长缩短），分母含四项成本（Token / 算力 / 存储 / 人力）。ROI 的粒度必须落到场景级——全局 ROI 会用高价值场景掩盖低效场景。

• 计费落审计：Token 计费随审计日志落库（对齐 A20.02 AOP 审计），谁、何时、用了多少、哪个档位——计费数据与审计数据同源不分裂。
• 成本看板：按业务线 / 租户 / 档位三维度聚合，趋势与预算对比；高成本链路（长上下文 / 冗余召回 / 缓存未命中）定位到可操作的优化动作。
• 异常告警：Token 消耗速率阈值 + 持续时间窗口（防抖动风暴，对齐 A19 告警纪律）；单租户用量突增、档位分布异常偏移、缓存命中率骤降三类信号分级告警。
• 闲时调度：低峰降配 + 批量合并推理 + GPU 池化弹性伸缩——算力成本与 Token 成本是两条独立的优化线。
• 北极星衔接：每个场景的 ROI 分子绑定该场景的北极星指标（对齐 A26.01），成本投入与业务价值在同一条度量链上。

• 为什么配额必须在网关层：多副本部署下应用层计数器各自为政（本地 Semaphore 配额分裂，对齐 A24.01），且绕过应用即绕过配额；网关是所有模型调用的必经点，天然是计量与强制的收敛层。
• 排队优于拒绝的经济学：模型调用是高价值操作，硬拒绝浪费了排队等待可消化的需求——公平排队让「等一会儿」替代「办不了」，配额刚性下总吞吐不变但满足率提升。
• ROI 分子的折算纪律：人工工时折算要用真实人力成本而非标价，效果增益要有对照（灰度组 vs 对照组，对齐 A23.02）——无对照的 ROI 是讲故事。
• 成本异常的三类根因：流量异常（攻击 / Bug 循环调用）、配置异常（档位错配 / 缓存失效）、质量异常（重试风暴）——告警设计要能区分三者，处置动作完全不同。

• 配额应用层硬编码：调整需发版，多副本失真——配额配置化 + 网关强制。
• ROI 只算直接成本：漏算人力与机会成本，AI 项目「账面省钱实际亏钱」——四项成本全口径入账。
• 无异常告警：月底账单才发现单租户异常烧钱——速率级告警前置。
• 超限静默拒绝：用户只看到「失败」不知道原因——拒绝 / 降级 / 排队都要有明确的用户侧反馈。
• 计费与审计两套账：计费系统与审计日志数据不一致，对账成本高且都不可信——同源落库。

第一成本指标应是「每完成任务成本」而非 Token 单价。本题考察 CPS 的口径与埋点、预算硬顶，以及监督税、协议税、精炼循环等二阶成本为何必须计入。

从单价核算到任务级核算：早期按千 Token 报价估算；随后发现重试、校验与人工复核占比很高；再往后按成功完成的任务分摊成本；当前把能耗、协议开销与失败重跑纳入单位经济模型。

用户购买的是「任务被正确完成」，不是「模型被调用」。任何为收敛不确定性而付出的代价——重试、强校验、沙箱、评测、人工终审、多轮精炼——都是完成任务的组成部分；单价下降若伴随步数上升，总成本反而增加。

定义 CPS 为成功任务的全部直接与间接成本除以成功任务数；埋点把重试次数、验证调用、人工工时、失败重跑与工具开销归到同一 TraceId；按租户与场景分摊并设预算硬顶；路由与语义缓存的收益须扣除命中后校验成本；CPS 退化超阈值触发告警与降级。

为什么「更便宜的模型」可能更贵？若单步正确率下降导致步数与重试上升，端到端成本按复合效应放大。为什么人工监督税要计入？不计入会让全自动方案在账面上永远显得更划算。

只报 Token 单价；忽略重试与复核开销；无预算硬顶；缓存收益不校验命中质量；按调用次数而非成功任务分摊；把失败任务排除在成本之外。

这道题考察的是 模型与 Prompt 的版本资产管理与回滚机制：模型档位版本注册表（候选 id 校验、版本元数据）、Prompt 的版本化—变更评审—效果回归三位一体、回滚预案与演练。与 A06.02 评测体系的分工：A06.02 讲「怎么评」，本卡讲「评完之后怎么管版本、怎么上线、怎么退回来」。核心在于回答：Prompt 与模型配置是一等资产，必须获得与代码同级的工程待遇。

Prompt 管理的演进：硬编码在业务代码里（改 Prompt = 改代码发版，且无历史）→ 配置化（配置中心下发，热更但无版本语义）→ 版本库化（版本号 + 变更记录 + 关联回归结果）→ 平台化（Prompt 管理平台：版本 / 灰度 / 效果回归一体化，对齐平台建设四大能力域）。

模型管理的演进：单模型硬编码 → 多候选配置 → 档位注册表（Tier 档位 + 候选模型 + 超时 + 探测策略，启动期校验一致性）→ 模型管理平台（注册 / 版本 / 档位路由 / A-B 灰度）。

Prompt 治理三体一位：版本（每次变更唯一版本号，旧版永久可取）、变更（变更原因 / 责任人 / 预期效果记录在案）、回归（变更必须跑 Golden Set，结果挂版本号存档——对齐 A17.01 快照纪律）。没有回归记录的版本不允许发布。

模型档位版本注册表：档位（FAST / STANDARD / DEEP）+ 候选模型 id 必须在注册表中、必填 timeout-ms、DEEP 档必须有支持思考的候选——启动期一致性校验 fail-fast。配置漂移防线：多环境配置一致性校验，启动期即暴露环境间差异。

回滚的第一性：回滚是「能力」不是「文档」——回滚路径必须演练过（切回旧版本 + 生效验证 + 用户侧无感），未演练的回滚预案等于没有。

• Prompt 发布流水线：修改 → 变更评审（diff + 动机）→ Golden Set 回归（指标不劣化）→ 灰度发布（对齐 A23.02）→ 全量；每个回答的 Trace 记录 Prompt 版本号，可溯源。
• 模型升级流程：新模型入注册表（不动现行档位）→ Golden Set + 业务评测集回归 → 基线快照更新经人工确认 → 灰度切流 → 观察期 → 全量或回滚。
• 版本与观测联动：效果指标按版本维度打标（A19.02），版本间对比可看可查——「效果变化」总能归因到「某版本变更」。
• 配置启动校验：档位 / 候选 / 漏斗参数启动期 fail-fast（对齐 A22.01），禁止运行期才发现配置错误静默降质。

• 为什么 Prompt 要按代码治理：Prompt 是系统行为的最大变量之一——一句措辞改动可让效果大幅波动；它有版本、有影响面、有回归需求，与代码的工程属性完全同构，却常因「只是段文字」被排除在治理之外。
• 版本—Trace 关联的归因价值：线上效果变化时，「哪个版本开始变的」是第一问——Prompt 版本进 Trace 使每一次回答可归因到精确版本，Bad Case 定位从「猜」变成「查」。
• 基线更新纪律的深层原因：模型升级后输出分布变化，「顺手更新 Golden Set 基线」会把真实回退洗白成「新基线」——基线更新必须人工确认 diff（对齐 A17.01），这是版本治理与评测体系的接口纪律。
• 模型不可回滚的补偿：供应商模型被下架 / 变更无法回滚——注册表多候选设计（同档位多候选 + 熔断切换）本质是给「不可控的外部依赖」买工程保险。
• 为什么 AI 制品需要配置谱系与退役清单？一次回答的可复现性取决于 Prompt、模型、索引、工具、检索版本与参数快照的共同取值，缺任一维度就无法回放事故，也无法证明某次变更没有引入退化。谱系记录要进变更单与 Trace；退役时除下架服务外，还须处理缓存中的历史结果、向量索引副本、评测集里的旧基线、以及日志中可还原个人信息的片段，并保留可核对的销毁记录。

• Prompt 改了没记录：效果变化无法归因，团队进入「玄学调参」状态——变更记录是归因的前提。
• 模型升级直接切流：不跑回归不灰度，效果回退全量暴露——升级必须走「回归 → 灰度 → 观察」流水线。
• 回滚无演练：真要回滚时发现旧版本配置不全 / 依赖已变——回滚路径定期演练。
• 多环境版本漂移：测试环境 Prompt v3 生产环境 v2，测试结论失效——配置一致性启动期校验。
• 版本号只存在于文件名：Trace 与观测数据无版本维度，版本治理与运营脱节。

术语对齐：本卡的版本与回滚机制属于 LLMOps 体系的一部分；模型 / Prompt / 数据集 / 评测集四类版本绑定发布单的完整链路见 A33.02。

与 A06.03 的边界：非劣效界值与 EvalRecord 的定义见 A06.03；本卡只保留发布门禁和灰度切流。

这道题考察的是 AI 应用发布门禁的设计：A-B 测试与灰度发布的机制、非劣效界值（新版本效果不低于旧版本的可接受边际——「不比现在差」而非「必须更好」）、发布门禁的组成（离线回归 + 线上观察）、灰度切流与 abort 条件。核心在于回答：AI 发布的风险不是「崩溃」而是「悄悄变差」——发布机制必须能感知渐变劣化并自动刹车。

发布方式的演进：全量直接上（效果回退全量暴露）→ 金丝雀（小流量试错但无效果判定标准）→ A-B + 非劣效判定（新旧版本并行对比，界值内算过）→ 门禁自动化（离线 Golden Set 回归 + 线上灰度指标双闸，指标越界自动 abort）。

流量形态的演进：真实施流量灰度 → 影子流量先行（新版本静默跑不返回用户，对齐 A19.02 影子路由——零风险预演）→ 影子 + 灰度组合（影子看效果，灰度看体验）。

非劣效界值的第一性：AI 版本更替的目标多数是降本 / 提速 / 换供应商，而非提效果——判定标准是非劣效（效果损失 ≤ 界值即通过）而非优效。界值按指标性质设定：忠实度等质量指标界值紧（如降幅 ≤2%），成本 / 延迟指标按优化目标定。界值记录进 EvalRecord（对齐 A06.03），判定可复现可审计。

发布门禁双闸：

• 灰度切流四步：影子（零用户可见）→ 1–5%（内部 / 白名单）→ 25–50% → 全量；每步设最短观察期（如 24h 覆盖流量波谷峰），未满期不推进。
• abort 条件前置声明：切流前写明哪些指标越界即回滚（错误率 / 忠实度 / 负反馈率 / 成本速率），达标才推进——abort 标准事后补等于没有。
• 切分维度设计：按用户 / 租户 / 场景维度切流（保证同一用户体验一致），避免按请求随机切导致同用户版本跳跃。
• 样本量纪律：非劣效判定需要足够样本量，低流量场景延长灰度期或用统计方法估算最短观察时长——样本不足的「持平」结论不可信。
• 回滚联动：abort 自动触发版本回滚（对齐 A23.01 回滚演练），回滚后保留灰度组数据供复盘。

• 为什么 AI 发布不能只看「没报错」：传统发布风险是突变（崩溃 / 5xx），监控告警天然覆盖；AI 发布风险是渐变（忠实度从 0.92 滑到 0.88，无任何报错）——效果指标必须进入发布判定，且界值必须事先声明。
• 影子流量的独特价值：新版本对新流量无影响即可获得真实分布下的效果数据——把「上线后才发现问题」变成「上线前用影子发现」，代价是双倍推理成本（限时限流跑）。
• 非劣效 vs 优效的工程含义：优效判定要回答「提升是否显著」，对样本量要求高；非劣效只回答「损失是否在界内」，判定更稳更快——版本更替场景用非劣效是务实选择。
• 灰度环境保真：灰度环境与生产的配置 / 数据 / 依赖不一致会让灰度结论失真——灰度流量应打到生产集群由版本路由区分，而非独立环境。

• 灰度只按比例不看效果：灰度形同「小范围全量」，劣化照样全量暴露——灰度的本质是「带判定的小步走」。
• 无 abort 条件越灰越多：排期驱动推进而非指标驱动，出问题才想起回滚——abort 标准与推进标准切流前锁定。
• 样本不足下判定：灰度 2 小时「数据差不多」就全量——观察期按流量与统计要求定，不按日历定。
• 界值拍脑袋：非劣效界值不随业务风险分级（医疗场景与内部工具同界值）——界值按场景风险设定并记录依据。
• 回滚不删数据：灰度期写入的记忆 / 知识不清理，回滚后新数据污染旧版本——灰度数据隔离与清理纳入预案。

这道题考察的是 生产期质量运营的两条主线：漂移监测——知识库内容漂移与用户问题分布漂移会让「上线时合格」的系统随时间渐变失效，必须靠趋势指标发现；幻觉缓解运营闭环——Prompt 约束 / 检索质量门控 / 引用核查 / 不确定性量化四方案按成本递进组合（机制与阈值标定见 A09.05），Bad Case 持续回灌 Golden Set 形成飞轮（SOP 见 A19.02）。核心在于回答：上线不是终点，质量是运营出来的。

质量保障的演进：上线即结束（无生产期评估）→ 被动响应（用户投诉才发现）→ 监控告警（召回率 / 忠实度趋势监控，对齐 A19.02）→ 漂移检测（分布级变化识别，指标恶化前预警）→ 闭环运营（Bad Case 回灌 → 修复 → 回归 → 灰度，全链路成环）。

幻觉治理的演进：从「只靠 Prompt 要求不要编造」逐步加装确定性防线——检索门控、引用核查、不确定性量化，按成本递进组合（四方案机理与阈值标定见 A09.05，本卡不复述）。

漂移的两类来源：

• 知识库内容漂移：文档增删改、切分 / Embedding 版本变化导致召回分布改变——检索命中率、Rerank 分数分布、融合权重存活率都是漂移信号。
• 用户问题分布漂移：新业务 / 新事件 / 用户群变化使问题偏离评测集分布——Golden Set 覆盖外的真实问题比例上升，效果指标「在评测集上不变差但线上变差」。

幻觉治理的运营分工：门控阈值用「已知在库 + 不在库」测试集标定并随模型 / 知识库版本定期重标（具体区间与标定方法见 A09.05）；引用核查用于高风险场景（每答多一次 LLM 调用，成本换可信）；不确定性量化负责转人工路由。核心是把幻觉当工程问题而非模型缺陷。

• 漂移监控指标组：召回率 / 忠实度 / Rerank 分数分布 / 拒答率 / 档位分布的趋势监控（对齐 A19.01 链路质量指标）；分布类指标（问题聚类新增簇占比）用于早期预警。
• Bad Case 闭环：发现（用户反馈 / 质检 / Trace 异常）→ 分层溯源（见 A19.02）→ 修复（改切分 / 换检索 / 调门控 / 补知识）→ 回灌 Golden Set 接入回归门禁（见 A06.02）→ 灰度发布——闭环速率是运营成熟度的核心度量。
• 阈值定期重标定：门控阈值 / 相似度阈值随模型与知识库版本变更重标（用标定测试集重跑分数分布）。
• 风险分级配置：医疗法律金融 = RAG + 人工审核 + 免责声明；客服内容代码 = Prompt + RAG + 输出验证 + 置信度阈值；头脑风暴 = 基础 Prompt。

• 为什么漂移是 AI 应用特有风险：传统系统行为由代码决定（代码不变行为不变）；AI 系统行为 = 模型（冻结）+ 知识库（动态）+ 用户分布（漂移）——后两者持续变化使「验收合格」不等于「持续合格」，生产期评估不可省略。
• 幻觉四方案的层位逻辑：Prompt 约束治生成层（模型自觉，概率性）、门控治检索层（无据不答，架构性）、引用核查治输出层（事后验证）、不确定性量化治决策层（何时转人工）——四层各挡一类泄漏，组合使用非单选。
• 闭环飞轮的复利机制：Bad Case → Golden Set → 回归门禁 → 更少 Bad Case 逃逸——评测资产随运营增厚，系统质量上限随之抬升（与 A19.02 闭环数据流同构，本卡强调「幻觉缓解」专项）。
• 与 A06.02 的分工边界：A06.02 讲评测方法论（指标 / Golden Set / Judge 校准），本卡讲生产运营（漂移 / 门控 / 闭环）——方法论在先，运营在后，资产互通。

• 上线后不再评估：离线评测通过即「完工」，线上漂移无人观测——生产期评估是常设职能。
• 阈值永不重标定：模型或知识库变更后门控阈值失真（过松放行幻觉 / 过紧大面积拒答）。
• Bad Case 只修不灌：修复完成但问题未进 Golden Set，同类回退无门禁拦截——回灌是闭环的必要环节。
• 幻觉治理只靠 Prompt：「请勿编造」是概率约束，架构级门控（无证据短路 / 拒答）才是确定性防线（对齐 A20.01）。
• 评测集与线上分布脱节：Golden Set 长期不更新，评测结论与真实效果渐行渐远——定期用线上真实问题抽样刷新。

一次回答由 Prompt、模型、索引、工具、参数与随机性共同决定，缺任一维度都无法复现与回滚。本题考察配置谱系、ModelSBOM、取证存证与 AI 特殊 RTO/RPO。

从版本备注到供应链治理：早期只在配置里写模型名；随后补版本号与模型卡；再往后要求索引快照与评测基线同步冻结；当前把 SBOM / ModelSBOM、取证存证与退役销毁清单纳入变更与灾备流程。

供应链不可追溯，故障就无法归因；灾备对象不只是服务进程，还包括权重、索引、Prompt、评测基线与记忆状态。供应方静默升级等价于未走门禁的生产变更。

谱系字段含模型与权重版本、Prompt 版本、索引快照标识、工具契约版本、参数与随机种子；维护 ModelSBOM 记录来源、许可证与依赖；关键决策留取证存证；灾备按 AI 特殊 RTO/RPO 演练，覆盖索引重建与基线恢复；退役走销毁清单，联动缓存、记忆与备份。

为什么模型供应方切换要重新过门禁？同一提示在不同模型上的行为分布不同，评测基线与拒绝策略都需重新校准。为什么退役必须销毁而非停服？残留索引与记忆仍可能被其他链路召回。

只记模型名不记版本；无索引快照；供应方静默升级未纳入变更；退役留缓存与长期记忆；灾备只测服务可用性不测数据一致性。

术语对齐：本卡的漂移监测在 LLMOps 语境下常写作 drift monitoring，需与数据侧血缘（data lineage，G09.02）联动才能定位到具体上游版本。

这道题考察的是 AI 服务规模化承载的四件套：无状态水平扩展（会话 / 记忆外置后的 K8s HPA 弹性）、分布式限流排队（Redis 公平排队替代本地 Semaphore 的必然性）、多租户配额 QoS（大客户不挤占小客户）、线程池隔离的规模化纪律。核心在于回答：模型容量是刚性瓶颈——规模化的本质是「在刚性供给下做公平与保护」，而非堆机器。

规模化路径的演进：单机（本地 Semaphore 限流）→ 无状态水平扩展（会话 / 记忆外置 Redis / DB，K8s HPA 弹性）→ 分布式限流排队（多副本下本地配额分裂，Redis 集中式计数 + 公平排队）→ 多租户 QoS（租户级配额分级 + 网关强制）。

线程池的演进：共享池（检索慢拖垮全部）→ 多池隔离（8–10 个专用池：检索 / 意图 / 记忆 / 流式 / 分块，TTL 上下文透传）→ 动态线程池（配置中心热更，对齐 A25.02）。

本地限流失效的第一性：N 个副本各自持有配额 M，实际总配额是 N×M 且单请求可任选副本——「每副本限 M」不等于「全局限 M」；且模型侧容量是全局刚性资源，必须由集中式分布式信号量统一守护（Redisson 信号量 + ZSET 队列 + Lua 原子 claim + Pub/Sub 唤醒，对齐 A20.02 四件套）。

QoS 分级第一性：多租户下「先到先得」会被大客户突发挤占——配额按租户分级（付费 / 免费），排队按公平原则（ZSET 按入队时间），超限按租户策略分流（降级 / 排队 / 拒绝）。

• 公平排队规模化细节：Lua 原子 claim（ZRANGE 取窗 + entry TTL 判活 + 僵尸 ZREM 清理）；Ticket 状态机 PENDING→GRANTED/TIMED_OUT/CANCELLED CAS 终态互斥；GRANTED 态 cleanup 不释放 permit（防让出使用中 slot）；队头无 permit 按原 score 重入队保公平。
• SSE 跨节点取消：客户端断开经 Pub/Sub 广播取消信号到实际执行节点——流式任务生命周期必须框架层统一管理（框架层统一能力）。
• 多租户配额：网关层强制（对齐 A22.02），租户 QPS / 并发 / 日配额三维限制，大客户突发不影响他人公平配额。
• 容量标定：压测找到「排队深度 × 处理时长 × 消费速率」临界点，告警阈值设在临界点 70–80%；模型侧并发上限按供应商配额 + 实测标定。

• 为什么排队优于无脑重试：模型容量刚性，超量请求重试只会加剧拥塞（重试风暴）——排队把「过载」转化为「有序等待」，吞吐不变而完成率提升；排队 + 超时退出是刚性瓶颈下的标准解。
• 会话亲和 vs 状态外置：会话亲和（粘性路由）让无状态化倒退且扩缩困难——正确解是状态外置 + 任意副本可服务，亲和仅作缓存优化而非正确性依赖。
• 连接与堆的副本线性增长：JVM 堆 / 连接池随副本数线性叠加，对下游（PGVector / Redis / 模型网关）的连接压力要按「副本数 × 池大小」全局估算——副本扩容前先算下游连接账。
• AbortPolicy 与 CallerRuns 的语义分工：入口 / 模型类池用 Abort（快速失败进排队或拒绝，保护下游），检索类池用 CallerRuns（调用线程自己执行形成天然背压）——拒绝策略是流量拓扑设计的一部分，不是随手配置。

• 本地限流多副本超卖：每副本各自限流，总并发超模型容量触发供应商限流连锁超时——分布式信号量是唯一正确形态。
• 会话状态内存化：多轮上下文存本地缓存，副本重启 / 扩缩即丢会话——状态外置是水平扩展的前提。
• SSE 断开不取消：客户端走了，跨节点的流式任务继续烧模型 Token——Pub/Sub 取消广播必须验证。
• 无租户 QoS：单一大客户突发把公共配额占满，所有租户一起排队——配额分级 + 公平排队缺一不可。
• 线程池参数拍默认值：未压测标定即上线，高峰期队列积压 / 拒绝风暴——参数压测标定 + 动态热更。

这道题考察的是 流式链路的生产化四难题：保活（反向代理默认超时截断长流）、续传（断线重连后不重头再来）、中断恢复（客户端断开后台任务取消与恢复语义）、TTFT 优化（首包时间——用户感知延迟的决定项）。核心在于回答：流式体验的工程难点不在「能流」，而在「流得稳、断得起、等得不焦虑」。

流式工程化的演进：单发长连接（能流就行）→ 保活心跳（防代理 / 负载均衡空闲超时截断）→ 事件化输出（SSE 分事件：思考 / 正文 / 来源 / 推荐问题，客户端可分轨渲染）→ 断点续传（服务端缓存已发事件 + offset，重连续传）→ TTFT 工程（首包探测 + 缓冲切换，把模型切换对用户透明化）。

TTFT 优化的演进：单模型等待（慢模型拖死首包）→ 多候选并发探测 → 首包探测 + 缓冲装饰（ProbeStreamBridge 缓冲装饰：未提交前缓存全部事件，非空白内容才判探测成功，失败缓冲永不 flush）。

TTFT 为什么是一等指标：流式交互下用户心理从「点击」就开始计时——首包（第一个可见 token）前的等待是纯焦虑期，正文流出后焦虑消散；总耗时反而次要（流式过程中用户已在阅读）。TTFT 由「路由决策 + 模型排队 + 探测」共同决定，是模型档位切换是否生效的直接信号（对齐 A19.01 / A19.02）。

零脏数据切换的缓冲原理：探测期间所有事件进缓冲区不提交；探测成功（收到非空白内容）→ 锁内按序 flush（含首包前空白 / thinking 事件）；探测失败（超时 / 空响应 / 异常）→ 缓冲永不 flush 随桥丢弃 + 切换下一候选——用户要么看到完整换模型的输出，要么什么都看不到，永远看不到半截脏数据。

• 保活三层配置：SSE 全局超时（应用层）+ 网关 / Ingress 超时放大（代理层专项配置）+ 心跳注释帧（空闲期定期发 keep-alive 防中间设备掐断）。
• 续传设计：SSE 事件带序号 + 服务端缓存最近事件（Redis 短 TTL）；客户端重连带 Last-Event-ID，服务端从 offset 续发；缓存过期则明确告知重开会话而非静默重头。
• 断开取消：客户端断开 → 网关感知 → Pub/Sub 广播取消 → 执行节点终止模型调用 + 释放排队名额 + 归还信号量——断开必须省钱，这是成本与容量的双重纪律。
• TTFT 优化组合：首包探测多候选并发（探测超时按分位数标定）、简单问题路由 FAST 档（对齐 A22.01 路由）、Prompt 前缀吃缓存（对齐 A22.01 Prompt Caching）。
• 分事件协议：思考 / 正文 / 来源 / 推荐问题分事件类型输出，前端分轨渲染——协议化让体验功能（来源展示 / 推荐）与正文解耦。

• 零脏数据切换的本质是「事务性输出」：模型切换 = 一次可能失败的写操作；缓冲装饰把「边写边暴露」改为「成功才提交」——这是数据库事务语义在流式输出上的移植，源码级答案（buffer 永不 flush）值得精读。
• 取消语义的三层完整性：上游断（OkHttp call.cancel 立即断模型连接）、中游清（排队名额 / 信号量归还）、下游净（半截回答不落库或标记中断）——只做第一层是常见的「伪取消」。
• 续传的边界判断：不是所有断点都值得续传——正文已流大半可续传，刚开始断开重发成本更低；续传窗口与缓存 TTL 按「重发成本 vs 续传复杂度」标定。
• 空白首包陷阱：部分模型先吐空白 / 纯 thinking 无正文——按「收到首包」判定成功会把用户挂在空白流上；必须以「非空白内容」为成功判据（探测判定）。

• 代理默认超时截断：Nginx / Ingress 默认 60s 掐断长流，用户看到回答中途消失——代理超时必须专项配置 + 全链路实测。
• 断开不取消后台空烧：用户关页面，任务跑完——Token 白烧还占模型并发，是最隐蔽的成本泄漏（对齐 A17.02）。
• 重连重头再来：无 offset 续传，长回答断线全丢，体验崩塌且重复计费。
• 空白首包误判：探测按「有响应」判定，用户盯着空白流等到超时。
• 切换时脏数据泄露：模型切换直接断流重开，用户看到半截旧答案 + 新答案拼接——缓冲事务性提交是标准解。

这道题考察的是 研发交付的工程化升级：IDP / 脚手架 / Starter 化标准化交付：内部开发者平台（IDP）如何统一 AI 应用的项目骨架与基建接入；Spring Boot Starter 自动装配为什么是 Java 生态标准化交付的核心机制；「防重三层」从业务代码抽象为 Starter 的抽象路径。与 A11.01 的分工：A11.01 讲 Coding Agent 方法论（怎么用 AI 写代码），本卡讲交付工程化（写出来的能力怎么标准化复用）。核心在于回答：对使用者隐藏复杂度，对运维者暴露可控性。

交付形态的演进：手工配置（每个项目复制粘贴基建代码，质量随人漂移）→ 脚手架（模板生成项目骨架，起步统一）→ Starter 化（通用能力封装为依赖，一个依赖接入零配置可用）→ IDP 平台化（自服务门户：脚手架 + 基建目录 + 交付流水线统一入口）。

抽象路径的演进（工程范式）：防重逻辑写在业务代码里 → 抽象为通用 AOP + 注解 → 封装为 Spring Boot Starter 全项目复用——「多场景通用代码，写到业务里只是第一步，掌握抽象的能力才是关键」。

中间件交付范式（oneThread 分层）：core（领域内核，纯逻辑）+ starter（接入层，按配置中心可插拔）+ spring-base（框架集成）+ dashboard（展示层）——分层目的：内核与接入解耦，能力演进不破坏接入方。

Starter 自动装配机制：AutoConfiguration.imports 注册 + @ConditionalOnClass / @ConditionalOnProperty 条件装配——使用方引入依赖 + 少量配置即生效；条件装配让「有则启用、无则跳过」，同一 Starter 适配不同项目形态。AI 中间件（限流排队 / 幂等 / 防重 / 审计 / Token 计费）Starter 化后，新 AI 应用接入这些企业级能力的成本从「人天」降到「小时」。

• AI 中间件 Starter 清单：分布式限流排队（公平排队四件套封装）、幂等（@IdempotentSubmit / @IdempotentConsume + Lua 三态机）、审计（AOP + 注解）、Trace（TTL 透传封装）、动态线程池（配置中心热更）——AI 应用的高频基建全部可 Starter 化。
• IDP 脚手架统一骨架：AI 应用模板（Spring AI 依赖 / 向量库接入 / 记忆 / 评测框架预置）一键生成，项目结构 / 命名 / 基建接入全站统一。
• 配置中心驱动：Starter 参数挂 Nacos / Apollo 监听，参数即运维界面——「改配置不发版」从框架能力变成平台默认体验。
• 可观测三件套随 Starter 附赠：Prometheus 指标（队列深度 / 活跃线程 / 拒绝次数）+ Grafana 看板模板 + 告警（阈值 + 持续时间窗口防风暴）——接入即有观测。
• 版本与兼容纪律：Starter 语义化版本 + 变更日志 + 兼容性矩阵，升级成本对使用方透明可控。

• 为什么 Starter 是 Java 生态的标准化交付单元：Maven 依赖是 Java 世界最低阻力的分发形式——能力一旦 Starter 化，就自动获得了「版本管理 / 传递依赖 / 条件装配」这一整套生态机制；对比 SDK / 文档分发，Starter 把「接入成本」压缩到极限。
• 抽象层次的判断：过早抽象（业务模式未稳定就封装）会锁死错误抽象；抽象太晚则复制粘贴蔓延——判据是同一逻辑第三次出现且需求稳定时启动 Starter 化（防重逻辑的演进即此节奏）。
• IDP 的价值本质：把「最佳实践」从口口相传变成平台默认值——新人建的 AI 应用自动带上 Trace / 评测 / 限流，质量的下限由平台决定而非个人水平。
• AI 场景的特殊杠杆：AI 应用迭代极快，基建重复建设尤其浪费——限流 / 幂等 / 记忆 / 评测这些跨项目共性能力 Starter 化的复利比传统后端更高。

• 通用逻辑散落业务代码：限流 / 幂等各项目各写一份，质量参差且修一处漏三处。
• Starter 过度封装：内部逻辑全部私有化，使用方无法扩展 / 绕过——暴露扩展点（接口 + 条件装配），封装默认实现而非唯一实现。
• 文档与代码漂移：Starter 能力演进文档不跟，使用方按旧文档接入踩坑——文档同步纳入发布 Checklist（对齐 A11 踩坑表）。
• 条件装配失效：@ConditionalOnClass 判断的类被使用方以不同方式引入，装配行为与预期不符——Starter 自身的集成测试必须覆盖典型装配组合。
• 脚手架与真实项目脱节：模板年久失修，生成项目仍需大改——脚手架随生产项目演进同步更新。

这道题考察的是 AI 服务执行基建的选型：裸 JDK 线程池 / Spring TaskExecutor / Starter 化动态线程池 / 虚拟线程四形态的能力边界与选型判据；动态线程池要解决的两大生产痛点（参数不可调 / 无监控）；以及 AI 这类 IO 密集型负载下，为什么默认答案不是「裸线程池」。核心在于回答：执行基建直接吃成本与稳定性，参数必须可观测、可调整。

线程池形态的演进：裸 JDK ThreadPoolExecutor（参数运行期不可调，改参要重启；无监控）→ Spring ThreadPoolTaskExecutor（Bean 重建可换参但能力弱）→ 动态线程池框架（oneThread / Hippo4j：配置中心热更 + Prometheus 监控 + 告警 + 拒绝策略增强）→ 虚拟线程（JDK 21，按需创建无需池化，IO 密集新范式）。

四形态选型对比：

两大生产痛点（美团经典问题）：核心数偏小 → 大量拒绝异常触发降级；队列过长 → 最大线程数失效任务堆积下游超时——根因都是「参数不可调 + 无监控，问题暴露时已成故障」。

默认选型判据：生产业务池默认 Starter 化动态线程池（可热更 + 可监控）；纯 IO 高并发且任务轻量再评估虚拟线程；裸池只用于参数稳定、无监控诉求的内部任务。选型不是「越新越好」，而是「出问题时能不能看见、能不能调」。

• AI 服务线程池隔离实践：检索 / 意图 / 记忆 / 流式 / 分块各自专用池（TTL 上下文透传），入口池大小与全局限流联动，拒绝策略按流量拓扑选（对齐 A24.01）。
• 动态线程池落地：Starter 接入配置中心（Nacos / Apollo 监听热更）+ 告警阈值设在压测临界点 70–80% + 持续时间窗口防抖动风暴；拒绝事件动态代理拦截告警（拒绝 = 故障前兆必须可见）。
• JDK 边界注意：动态改 corePoolSize 有并发边界问题（先减后加或加锁）；队列容量动态改要保证 remainingCapacity 一致性。
• 虚拟线程适用判据：高并发 IO 型（AI 服务的模型调用 / 检索正是此类）+ 任务轻量；需配套新监控工具，池化类经验（队列 / 拒绝策略）不适用。

• 虚拟线程与 AI 服务的适配性：AI 服务主流等待是 IO（模型响应 / 检索 / 队列轮询），线程在等待期零占用正是虚拟线程的设计靶点；但模型调用受全局信号量约束（对齐 A24.01），虚拟线程的「无限并发」必须仍受分布式配额约束——两者是互补不是替代。
• 从监控到自愈的闭环：告警 → 自动扩容（HPA 或动态调大 maximumPoolSize）→ 事后复盘——监控的终点是自动化响应而非人肉救火（oneThread 进阶结论）。

• 拒绝策略无监控：任务被静默丢弃，故障前兆无人知晓——拒绝事件必须告警。
• 告警无持续时间窗口：瞬时抖动触发告警风暴，值班疲劳后真告警被淹没。
• 参数拍脑袋不压测标定：core/max/queue 凭经验设，高峰期积压或空转——压测找到临界点再定参。
• 虚拟线程套池化思维：给虚拟线程配队列和拒绝策略，失去按需创建的意义——语义变了，监控与容量规划跟着变。

这道题考察的是 SDD（Spec-Driven Development，规约驱动开发）与 AI 原生研发流：为什么「先写规约再让 AI 编码」能把理解偏差前置消灭？规约必须包含哪些要素（背景 / 需求 / 边界 / 验收标准 / 禁区）？验收标准如何直接转成测试用例？AI 原生研发流六阶段（需求 → 规约 → 编码 → 验证 → 评审 → 上线）的准入准出如何设置？与 A11.04 的分工：A11.04 讲 Coding Agent 六件设施与规约三件套的目录组织，本卡讲规约驱动的研发流程与组织落地。核心在于回答：AI 编码的质量上限由规约质量决定，流程要把返工成本消灭在编码前。

研发范式的演进：Prompt 式驱动（口头描述让 AI 写，产出随理解漂移）→ SDD 规约驱动（先写规约：需求 + 边界 + 验收标准，再让 AI 编码——把理解偏差前置消灭）→ AI 原生研发流六阶段（需求澄清 → 规约 → 编码 → 验证 → 评审 → 上线，Agent 参与全程、人类把关准入准出）。

SDD 的第一性：AI 编码的质量上限由规约质量决定——规约含需求描述 + 可测试的验收标准，AI 的自由发挥空间被约束在验收框架内；先写规约 = 把沟通成本前置，把返工成本消灭在编码前。规约的最小要素：背景（为什么做）、需求（做什么）、边界（不做什么）、验收标准（可测试的完成定义）、禁区（不可触碰的约束）。

六阶段的准入准出：需求澄清（目标与不做的范围确认）→ 规约（验收标准可写成用例）→ 编码（按规约产出，不夹带未定义需求）→ 验证（验收用例全绿）→ 评审（人类审 diff 与规约一致性）→ 上线（观测指标与回滚条件就绪）。每阶段的准出物是下一阶段的输入，缺一项就把不确定性带到更贵的环节。

• 规约模板：背景 / 需求 / 边界 / 验收标准 / 禁区五段式，长度按功能复杂度裁剪；小功能几段文字写清行为即可，不为「用模板」把功能扩成复杂文档。
• 验收标准即测试：每条验收标准写成可执行的 Given / When / Then 或断言，直接转成测试用例——规约即测试的前置物，测试通过就是验收通过。
• 规约作为项目记忆：关键决策写入 CLAUDE.md / AGENTS.md，长会话压缩只省过程、不丢决策；新会话先读规约再动手。
• 变更纪律：需求变更先改规约再改代码，评审同时看规约 diff 与代码 diff——只改代码不改规约，下一次 AI 生成又会回到旧行为。

• 为什么 SDD 与 Coding Agent 是绝配？Agent 执行力强但理解需求有偏差——规约把偏差约束在验收标准内；同时规约是项目记忆的输入，长会话上下文压缩也不丢关键决策。
• 规约「够用」的判据？不是篇幅，而是能否写出可执行的验收用例、边界能否被测试表达；若验收标准只能写成「体验好 / 性能高」，说明需求还没澄清，继续写文档只是把模糊放大。
• 业界研究的落地映射：用好 AI 编程的关键是会问问题、会审结果、会定标准——SDD 的规约正是「会定标准」的工程化形态，把资深工程师的判断力沉淀为验收资产。

• 规约缺失直接让 AI 写：口头需求 + AI 自由发挥，产出漂移返工——哪怕 20 行规约也强于没有。
• 验收标准不可测试：写成「体验好」「性能高」，无法转成用例，等于没有验收——改成可观测的数值或行为断言。
• 规约写成大而全文档：小功能被扩成复杂文档，维护成本超过收益——按复杂度裁剪，几段文字能写清就不上三件套。
• 长会话靠压缩接力：关键决策在摘要中失真——决策写入记忆文件，压缩只省过程。

这道题考察的是 AI 项目立项的两问：做什么与怎么证明值：场景选型决策树（知识密集？重复高频？容错边界？数据可得？）筛选值得做的场景；价值度量（北极星指标）让项目价值可量化可追踪；Workflow vs Agent、v1/v2 双引擎按场景路由的落地对应。核心在于回答：先选对场景再谈技术——「AI 是增强项还是核心壁垒」决定一切后续投入结构。

立项思维的演进：追风口（先有 AI 再找场景，本末倒置）→ 场景筛选（决策树过滤）→ 价值度量（北极星指标上线前定义）→ 规模化复制（单点验证后按组织路径推广，对齐 A26.02）。

架构选择的场景化演进：一刀切 Agent（全场景上自主循环，贵且不可控）→ 按场景路由（v1 Workflow 处理问答类——快、可控、成本低；v2 Agentic 处理复杂任务——可规划可调用工具；两套并存按场景分发）——「可控性与智能性权衡」的教科书实践。

场景选型决策树四问：

北极星指标第一性：每个场景上线前定义唯一主导指标（客服场景 = 一次解决率，知识问答 = 采纳率 / 免检索率，文档处理 = 单件处理时长）——没有北极星的 AI 项目无法回答「值不值」，也无法发现「Demo 漂亮但不产价值」。

• 立项动作清单：决策树四问打分 → 竞品 / 平台路线初判（平台 vs 自研，对齐 A13.02）→ 北极星指标 + 对照基线（现状人工耗时 / 错误率）→ 最小验证场景（灰度试点）→ ROI 模型挂账（对齐 A22.02）。
• 场景—引擎路由表：标准问答 / 检索类走 Workflow（v1，路径确定成本低）；规划 / 多步任务走 Agent（v2，路径自主能力上限高）；网关按意图路由两引擎。
• 价值叙事纪律：项目汇报按「问题 → 方案权衡 → 数据验证」组织，每项目提炼 3 个可量化成果（QPS / P99 / 成本降幅 / 解决率）+ 2 个深度技术决策——数据是价值叙事的唯一硬通货。
• 四大误区自查：调 API ≠ 会 RAG / Agent、RAG ≠ 检索 + 生成、接框架 / MCP ≠ 企业级、只关注模型忽略工程——完整清单与判据见 A16.04，本卡只做选型视角的取舍。

• 「增强项 vs 核心壁垒」的投入分野：AI 是增强项 → 平台 / 低代码快速交付（对齐 A13.01 决策边界），工程投入保全底线；AI 是核心壁垒 → 自研纵深（自研纵深范式），评测 / 检索 / 编排自主可控——路线错了，执行越努力偏差越大。
• 北极星防「指标幻觉」：会话量 / 调用量是虚荣指标（可被刷高），一次解决率 / 采纳率 / 处理时长缩短才是价值指标——北极星必须绑定业务成果而非系统活动。
• 容错边界的分层设计：多数场景不是「能用 / 不能用」二元——用风险分级（对齐 A23.03：高风险场景人工审核兜底 / 中风险置信度阈值 / 低风险直出）把不可靠技术放进可靠的产品结构里。
• 决策树与需求形态判定的衔接：A13.02 的需求形态判定（平台 / 自研 / 场景）解决「用什么路线做」，本卡决策树解决「该不该做」——立项先过本卡，路线再走 A13.02。

• 场景选错：低频 / 零容错 / 无数据场景硬上 AI，技术再好也不产价值——决策树四问前置。
• 无北极星上线：上线后说不清价值，预算被砍时无数据自辩——指标与对照基线在立项期锁定。
• 技术堆砌无主线：方案汇报罗列技术清单而非问题—权衡—验证叙事，评审无法判断合理性。
• 一步到位大而全：首版追求全功能，验证周期拉长错过窗口——最小验证场景先行，灰度复制。
• 全场景 Agent 化：标准问答也走自主循环，成本与延迟量级明显高于 Workflow（经验估计，随轮次放大）且不可控——按场景路由引擎。

这道题考察的是 失败模式归纳与组织级 adoption 路径：AI 项目三大失败根源（技术幻觉——把 Demo 当能力、工程缺位——数据一致性 / 异常路径 / 压测缺失、组织未跟上——职责边界不清能力不在平台在人）；以及从「单点试点」到「组织能力」的 adoption 路径（试点 → 规约沉淀 → 平台化 → 规模化复制）。核心在于回答：决定 AI 项目存活的不是单点技术亮度，而是工程完整度与组织可复制性。

组织能力的演进：个人英雄式 Demo（能力在人不在组织，人走能力走）→ 工程化单点（完整工程实现，单项目可复制）→ 组织能力沉淀（平台 + 规约 + 评测资产：IDP 脚手架 / Starter 化基建 / Golden Set 沉淀 / SDD 规约——能力在平台在资产，对齐 A25）→ 规模化 adoption（多业务线按标准路径复制）。

失败三因的机理：

adoption 路径四步：① 单点试点（高价值场景小范围验证，产出北极星数据）→ ② 规约沉淀（试点经验固化为 SDD 规约 / 评测纪律 / 上线 Checklist）→ ③ 平台化（共性能力 Starter 化 / IDP 脚手架，对齐 A25.01）→ ④ 规模化复制（新场景按平台路径低成本启动，评测资产复用）。

• 职责边界三层：平台团队（模型管理 / Prompt 管理 / Agent 编排 / 数据服务四大能力域，对齐平台建设框架）+ 算法团队（效果 / 评测 / 模型选型）+ 业务团队（场景 / 数据 / 验收）——接口是「平台提供能力域，业务按需消费」。
• 试点选址标准：决策树四问全过（对齐 A26.01）+ 容错边界清晰（出错可拦截）+ 数据可得——先赢一场建立组织信心。
• 资产化纪律：每个试点的 Golden Set / 规约 / 踩坑记录强制归档进平台——试点结束的标准不是「上线了」而是「资产入库了」。
• 压测数据文化：第三方压测（如阿里云 PTS）数据是项目可信度的核心证据——创建 / 跳转 QPS、P99、成本降幅必须有实测数字。
• 人员能力建设：按「问题 → 方案权衡 → 数据验证」训练叙事能力；基础工程（线程池 / 可观测 / 高并发）按依赖顺序补，其功底直接决定 AI 工程的落地质量。

• 为什么工程完整度决定存活：Demo 与生产的差距全在「没发生过的路径」——异常 / 并发 / 数据一致性 / 故障恢复；这些路径的完备度是「技术演示」与「业务系统」的分界线，也是组织对 AI 项目信任的来源。
• 知识资产的组织复利：Golden Set（评测资产）、规约（SDD / Checklist）、Starter（代码资产）、踩坑库（经验资产）——四类资产随项目累积，新项目的边际成本持续下降；这四类资产的厚度就是组织 AI 工程能力的厚度。
• 判断力的组织级映射：用好 AI 的关键是会问问题、会审结果、会定标准——组织层面把「判断力」沉淀为 Hooks / Skills / 规约（对齐 A25.03），让 Agent 在循环中自动执行资深标准，个人的判断力变成组织的生产力。
• 失败案例的正面价值：把精确查询场景套用全文检索方案（业务形态与检索方案不匹配的典型反面案例，具体归属需核实）、缓存穿透单方案漏洞（Null 缓存脏数据窗口 / 布隆误判）——失败案例是最便宜的学费，避坑库的组织价值不亚于成功范式。

• 只调 API 当做过：追问一致性 / 异常路径 / 压测即穿帮——生产级完整度是唯一及格线。
• 试点成功即终点：经验留在个人脑中，下个项目从零开始——资产入库是试点的验收标准。
• 职责无边界：平台 / 算法 / 业务互相等待，决策悬空——能力域归属先行声明。
• 组织 adoption 无路径：指望「全面推广」一步到位，业务线各自野蛮生长——四步路径有序推进。
• 忽视压测数据：性能结论靠「感觉挺快」，评审与容量规划无据可依。
• 能力建设跳步：基础工程（线程池 / 可观测 / 高并发）未扎实直接上 AI 工程——按依赖顺序渐进，AI 工程的难点恰好是传统工程功力。

规模化之后组织本身成为独立失效来源：技能梯子断裂、监督能力空心化、审计态与运行态行为差异、影子 AI。本题考察责任分工与治理闭环如何与技术控制面对齐。

从试点成功到规模化失配：初期由少数专家手工把关；推广后一线缺少判断模型失效的能力；随后出现未登记的自建 Agent 与私有凭证；当前把能力阶梯、影子发现与审计态对账纳入常态化治理。

自动化程度提高不会减少监督需求，只会改变监督位置。若监督能力未随系统同步建设，人就会退化为橡皮图章；而审计采样与真实运行路径不一致时，合规结论与实际行为会系统性偏离。

用 RACI 明确模型、工具、数据与审批的责任主体；建能力阶梯与值班手册，让一线能识别静默失效；审计态与运行态定期按 TraceId 对账；发现影子 AI 先纳管再评估，避免只禁不管；立项准入交付风险矩阵，全自动闭环在多数业务场景不予批准；变更评审覆盖 Prompt、模型与评测基线。

为什么「全自动闭环」多数场景不应被批准？物理不可逆操作与高风险副作用无法靠事后回滚恢复，必须保留人类终审。为什么审计采样要覆盖长尾？失效恰恰集中在低频但高危的组合路径上。

只采购平台不建能力；监督全靠人工且无判定标准；影子 AI 只禁不管；审计只查成功路径；组织无明确责任主体；把试点指标当作规模化结论。

AI 工程的治理机制不是并列的经验清单，而是从三条事实推导出来、有依赖顺序的必然结论。本题考察概率性、复合性、累积性如何共同决定控制面的形状。

从清单到第一性框架：早期把生产事故逐条沉淀为注意事项；随后归拢成评测、验证、编排、记忆、权限几类机制；再往后发现这些机制之间存在先后依赖；当前把它们还原为对三条基底事实的响应，避免「照抄清单但漏了前提」。

事实一：推理是概率性的，单步正确率恒小于一。事实二：概率在复合中相乘，端到端成功率是各步乘积。事实三：持久化状态会累积偏差，局部合理的更新会漂移到从未授权的行为轨迹。由这三条可以推出：评估器必须先可信、验证必须来自硬证据、复合指数必须收缩、状态写入必须准入、权限必须按路径而非逐点校验。

按依赖顺序落地：评估可信度（评估集隔离与盲集冻结，它是其余机制的信号来源）→ 闭合验证环（schema、文件存在、返回码、校验和构成硬证据）→ 收缩复合指数（确定性步骤移出模型、窄接口拆短链、每步交接校验）→ 持久化状态准入（变更单、谱系、盲集比对）→ 路径级安全（权限预算随值流动且只收紧）。本质是「在概率性基底上构建确定性的承诺边界」。

为什么评估可信度排第一？门禁、路由与回滚都读它的输出，评估器被污染时其余机制会一起给出「通过」的假信号。为什么 Harness 应理解为控制面而非框架？模型是执行单元，控制面负责权限、知识、人机、观测与组织五类横切关注点；散落在业务代码里的横切逻辑会积累成概率性债。

把五条机制当可任选的并列清单；指望「模型更聪明」替代工程约束；把治理要求写进 Prompt 当作已实现；先做编排再做评测，导致优化没有可信信号；只谈框架选型不谈承诺边界。

长任务的失败由步数驱动，而非上下文长度。本题考察端到端成功率的乘积关系、为什么扩上下文窗口是被否定的捷径，以及如何收缩复合指数。

从「让它记住更多」到「让它少走几步」：起初用更长上下文承载完整历史；随后做摘要压缩防止溢出；再往后发现步数一多，即便每步都很稳，端到端仍会快速退化；当前把设计重心放到链路长度与交接校验上。

若每步正确率为 p，一条 N 步链路的端到端成功率近似 p 的 N 次方。这意味着退化是几何的，且由步数主导：单步再高也扛不住长链，而压缩窗口既不减少步数，还可能丢失硬约束。可行的方向只有两个——减少由概率组件承担的步骤，以及让每一步的交接都有确定性校验。

把参数拼装、权限判定、重试、状态落库等确定性步骤移出模型；用窄接口把长链拆成可独立验证的短段；每段交接强制 schema 与业务规则校验，失败即中断而非带着错误继续；在入口设定最大步数与每步耗时预算，预算耗尽转降级或人工；用平均步数与步数分布作为可靠性回归指标。

为什么「更长的上下文」反而更差？它增加了无关信息与硬约束被摘要吞掉的概率，却没有改变任何一步的正确率。为什么重试不能替代收缩？重试是对同一步的再采样，不改变链路长度，只会抬高成本并放大副作用。

靠扩窗口提升可靠性；链路无步数上限；每步之间不校验直接透传；把系统硬约束交给摘要压缩；把重试次数当成可靠性指标；只统计最终成功率不看中途偏离。

验证环的意义是让「正确」由模型之外的证据判定。本题考察硬证据的范围、验证器归属为何必须独立，以及拒绝策略与可回放性怎么构成闭合。

从自证到他证：起初让模型自查输出；随后用第二个模型打分；再往后发现同源模型会共享偏见，一致通过并不构成证据；当前把 schema、文件存在性、接口返回码、校验和等硬证据串成独立验证链，并把拒绝路径纳入契约。

被验证的概率组件不能同时充当验证者：它既没有判定业务正确性的权威，也可能把错误转化为流畅叙述。验证必须来自确定性系统可核对的证据，且验证器归属独立于生成方；「Schema 通过」只说明形状合规，不等于值、引用关系与业务状态正确。

四层链路：类型转换取约束 → JSON Schema 校验必填与范围 → 业务规则校验外键存在性、权限、金额与状态机 → 拒绝策略分补全复验、一次性重生成、拒答与降级模板。每层记录通过或失败原因并绑定 TraceId；保留原始输出、校验器版本与规则版本以支持回放；命中缓存或降级模板的结果同样走完整后置校验；禁止业务代码裸解析模型原始文本。

为什么同源打分不是独立证据？两个模型可能共享训练偏见与失败模式，「一致」只说明同源。为什么拒绝原因必须落库？否则无法区分模型变差、Schema 变更与规则收紧，回归门禁也就失去判别力。

让模型自审作为唯一防线；把「请输出合法 JSON」当校验；Schema 通过即放行；失败后无限重生成；校验逻辑写进 Prompt 使用户上下文可覆盖硬约束；缓存命中不做后置校验。

累积性是三条第一性事实之一：任何持久化写入都不能只按「这一次是否正确」判定，而必须评估它会沿后续链路累积成何种行为。本题从控制面推导视角，考察为什么状态写入必须被视为有向变更而非追加日志，以及谱系、盲集比对与拒绝策略为何是累积性下的必然结构。

从单点校验到全局状态图：早期只在写入时校验内容正确性；随后发现退化跨会话累积、单点校验对组合效应失明；再引入跨会话谱系与回滚点；控制面由此承接「持有全局状态视图」的职责，业务链路只上报写入意图，判定留在控制面。

单步偏差可逆，跨会话累积不可逆——这是累积性的数学事实。局部更新的合理性推不出全局安全，因此准入标准须从「这条记忆是否正确」改为「这次写入有没有在别处制造退化」。写入方与判定方分离是控制面职责而非业务链路职责；系统硬约束不参与摘要压缩，防止累积噪声逐步吞掉边界。

控制面侧落点：变更单与谱系图记录父子关系与覆盖链；盲集比对作为跨会话回归基线，异常即拒绝；墓碑与回滚链路联动向量库、图谱、缓存与索引快照；稳态腐化按行为基线偏离触发熔断。业务链路只负责产生写入意图并上报，判定与回滚能力统一由控制面持有。

为什么累积偏差无法用单步校验兜住？单步校验只看这次写入本身，而累积偏差发生在「这次写入 × 历史状态」的组合上，单步视角看不到组合效应。为什么控制面必须持有跨会话状态视图而不是各业务链路各自记账？各自记账时，跨链路的记忆复用会把偏差悄悄传播，没有统一视图就无法定位是哪次写入把行为带偏，回滚也会漏掉旁路的复用点。

把状态写入当无副作用的缓存更新，跳过变更单；谱系只记录不查询，回滚点形同虚设；盲集比对只在发布跑、不在运行时，线上漂移无感知；墓碑不进回滚链路，删除后仍能从备份或快照复活；业务链路私自写记忆绕过控制面判定；用同一模型既生成记忆又判定准入。

逐个工具都鉴权，仍可能通过工具组合越权。本题考察安全属性为何是路径属性、权限预算如何随值流动，以及身份注入与终审为何不可绕过。

从逐点到逐路径：早期按角色控制每个工具能否调用；随后发现「读文档 → 取凭据 → 发消息 → 写文件」的串联可绕过逐点限制；再往后引入随值流动的预算；当前把身份注入、参数白名单、路径级预算与业务终审串成不可绕过的链路。

安全属性不是各节点属性的并集：鉴权回答「谁能调」，组合攻击利用的是「调完之后能拿什么去调下一步」。权限预算应随值在工具链上流动且组合只能收紧不能放宽；逐工具检查看不到前序步骤带来的能力与数据敏感度，原理上拦不住组合越权。

身份由网关从已认证会话注入执行上下文，模型既看不到也改不了；工具契约声明参数白名单，网关注入字段标记只读并在 schema 校验时剔除同名参数；每一跳按前序数据敏感度重算剩余预算，高危组合强制业务终审；高风险调用绑定不可变参数快照与审批主体；Agent 凭证不得同时具备写生产、删备份与绕过终审的能力。

为什么前端一句「是否确认」不构成终审？确认必须绑定不可变参数快照与审批主体，否则用户确认的是摘要、执行的却是另一个请求。为什么每一跳要重校验？长任务中的上下文重组与状态恢复可能把旧身份带进新阶段。

让模型声明身份；把租户标识放进 Prompt；工具参数不设白名单；网关注入字段可被同名参数覆盖；审批流于前端一次点击；Agent 持有过度集中的长期凭证。

显式失败会抛异常、触发错误码、进入告警；静默失效四型都不走这些通道。本题考察四型的分类判据、各自可观测的代理信号，以及 fail-plausible 为何连人工复核都容易放行。

从「错误即异常」到「正确需举证」：早期把可靠性等同于可用性与延迟；随后发现大量工单对应「接口 200、答案不对」；再往后把行为漂移与用户放弃纳入故障定义；当前把「监控全绿」写进复核清单，作为需要主动验证的风险面而非健康证明。

四型的分界在于失真位置：① 返回成功但语义错——结论层失真，服务端无任何异常；② 行为静默漂移——过程层失真，单步都合规但整体路径变了；③ fail-plausible——表达层失真，错误被改写为流畅自信的叙述；④ 用户静默放弃——反馈层失真，用户不报错、不重试、直接离开。四者共同的根因是正确性缺少独立证据源，因此故障分级不能沿用错误码体系，必须按语义影响面重新划分。

分类落地为四张判定卡，每型写明「可观测代理量」与「确认动作」：语义错靠盲集抽检、行为漂移靠路径分布对照、fail-plausible 靠结论与证据逐条核对、静默放弃靠会话终止率。故障分级把「影响用户决策但无人报错」单列一级；复盘模板要求回答「该型是否曾出现外显信号、当时为何未采信」。

为什么 fail-plausible 最危险？流畅性会触发复核者的启发式判断，自动化偏见又让人倾向接受结构完整的输出；错误越像正确答案，越不会进入异常通道。为什么静默放弃是最诚实的外显信号？它是用户用行为投票，不经过任何可能被模型润色过的文本通道。

把「没有异常」当成「没有故障」；用回答流畅度做质量代理；只统计显式差评与重试；四型共用一套处置流程；把静默放弃归为正常流失而不进复盘。

术语对齐：本卡讨论的四型失效在英文文献与岗位描述里称 silent failure / fail-plausible；其检测依赖步级轨迹（trajectory eval，见 A33.01）而非结果级打分。

反模式的价值不在于背下清单，而在于每条都能回答「怎么发现、怎么拦住」。本题考察按不可逆性与检出难度分级，并把条目转成可执行的判定问句。

从踩坑笔记到门禁条目：早期靠复盘口述；随后整理成经验列表；再往后发现列表记不住也测不出来；当前把高频且不可逆的条目转成判定问句，接入评审清单与持续集成门禁。

一条反模式若没有可观察的判定信号，就无法进入检查表。分级看两个维度：后果是否可回滚（写生产、删备份、绕过终审属不可逆），以及失败是否静默（语义错比抛异常更难发现）。分级结果决定它进设计评审、进 CI 门禁，还是仅作提示。

把 Agent 当同步 API——判定问句：链路是否有步数与耗时上限？状态放 worker 内存——重启后能否恢复？让模型声明身份——身份是否由网关注入？语义缓存不带租户维度——key 是否含租户与各方版本？用「请谨慎」替代硬拦截——约束是否由确定性代码执行？让第二个模型给自己的作业打分——验证器是否独立？工具一次性永久挂载——注册是否按会话收敛？把「是否确认」做成聊天框一句——是否绑定参数快照？

为什么「请谨慎」不是护栏？Prompt 是输入不是约束，用户上下文可以覆盖它，且它没有可观测的失败信号。为什么只记录成功路径最致命？静默失效恰好藏在成功路径里，不记录中途状态就无法定位从哪一步开始偏离。

只记结论不问判定；反模式不分优先级全部塞进评审；条目不进 CI 门禁；把「注意」「谨慎」当落地方案；清单长期不随事故复盘更新。

三阶段不是时间顺序，而是风险性质的顺序：能不能跑通、错了会不会出事、长期会不会悄悄变坏。本题考察每阶段的准入条件与退出物，以及五条 Harness 基线如何写成可回答的判定问句。

从一次性上线到分阶段验收：初期以 Demo 跑通为完成标准；随后生产事故暴露出强校验与审批缺位；再往后把评测回流、成本与告警闭环列为放量前置；当前用阶段门禁把「演示可用」与「生产可托管」明确切开。

每阶段的放行判据对应不同性质的证据。能跑阶段要证明链路完整（统一入口、版本可追溯、Trace 贯通）；敢用阶段要证明失效可控（强校验、幂等沙箱、最小权限、高风险终审、回归门禁）；可持续阶段要证明系统能被长期观察与修正（评测回流、成本看板、分层告警、紧急停用闭环）。跳过任一阶段，等于把该阶段的控制面欠账挪到生产偿还，且欠账会在规模放大后以静默失效的形式出现。

每阶段设一页验收表，写清「进入条件 / 必须交付 / deny 条件」；阶段之间不允许以「后续补」放行。五条基线各配一个可证伪的判定问句与证据形式：权限（模型能否通过任意工具链拿到身份字段？证据=注入链走查报告）、知识（结论能否落到具体片段？证据=引用支持关系抽检）、人机（高风险动作是否绑定不可变参数快照与审批主体？证据=审批单样本）、观测（语义错能否在无人报错时被发现？证据=盲集注入演练）、组织（失效时谁有停用权与回滚权？证据=RACI 与值班演练记录）。人机基线背后的不可逆性论证见 A26.03，本卡只负责门禁判定。

为什么评测回流不能提前到第一阶段？它需要足够的线上样本与标注能力，提前建设往往把生产流量直接回灌成基线，把当下的模型偏差固化成验收标准。为什么阶段门禁必须写成 deny 条件而非建议清单？建议项在排期压力下会被逐项协商掉，只有 deny 条件可机械判定。

试点跑通即宣布上线；用「二期补」跨过强校验与幂等；无紧急停用入口；用调优样本直接充当盲集；把三阶段压缩进一次发布；验收表只写交付物不写 deny 条件。

数据从采集、版本化、训练/索引、服务、监控到退役构成完整生命周期，是 AI 系统可靠性的隐藏主轴；治理缺失直接导致不可复现与静默劣化。

手工脚本读最新文件 → 数据湖版本化（tag/分支）→ Embedding/模型版本绑定 → 血缘+漂移监控 → 生命周期闸门。

数据集即代码；版本三元组（数据×Embedding×模型）可追溯；漂移是静默失效；训练集/评测集/生产样本三集隔离。

数据版本注册表、Embedding 版本随模型绑定、生产数据分布监控（PSI/KL）、血缘回放定位根因。

训练-服务偏斜（training-serving skew）用 PSI/KL 等统计检验量化；协变量/先验/概念三类漂移中，Embedding 质心漂移比原始特征更易早发现；可复现要求实验 run 绑定数据+代码+超参+模型版本。

只版本化代码不版本化数据；Embedding 升级不重算旧向量；评测集被生产数据污染；血缘只到文档不到切分方式。

量化模型：漂移用 PSI / KL 散度做分布级度量（PSI >0.2 触发冻结）、用字段级断言做质量度量（主键唯一 100%、非空率 ≥99.9%、分区行数相对 7 日中位数波动 ≤±30%）。两类信号分开告警：分布漂移指向「数据变了」，质量异常指向「管道坏了」。

Java / Spring 落点：写入路径前置 Advisor 计算内容哈希与采集规则版本，血缘记录 source → transform → dataset_ver → index_ver → eval_run；重建索引走蓝绿切换并原子替换别名，避免查询混合两版。

反例：某次只监控了总量没监控意图分布，训练数据被新渠道流量逐渐稀释，模型整体准确率持平但核心意图下降 12 个百分点。修复后按意图分桶监测（与 C14.15 指标口径一致）。

漂移的量化推导：把「数据变了」拆成可测的三类，才知道该看哪条曲线。协变量漂移看输入分布，用 PSI 按意图分桶计算：以 7 日中位数为参考，单桶 PSI 0.12 时回答准确率尚无明显变化，0.21 时核心意图准确率下降 4.6pt，故把 0.2 设为冻结线；先验漂移看标签或意图占比，某渠道导流让「退款」意图占比从 18% 涨到 34%，整体准确率因简单意图变多反而上升 1.2pt，只有分桶曲线能暴露这种「整体变好、核心变差」；概念漂移看输入到答案的映射关系，需靠标注样本回放测，PSI 完全无感。Embedding 质心漂移常早于原始特征：把每日抽样 1 万条向量算质心余弦距离，在人工发现质量退化前 6 天就开始偏离，距离 0.08 为预警、0.15 为冻结。三者要分别设告警，混成一条「数据健康分」会把因果信号抹平。

可复现的机理边界：可复现不是「同输入同输出」，而是「同输入同分布、且差异可被解释」。实验 run 要绑定五元组：数据版本、特征变换代码、超参、模型权重、随机种子；缺任一环，复现实验时只能得到相关系数 0.83 左右的结果波动。更隐蔽的是训练—服务偏斜：离线用批处理算好的特征、在线用流式近实时特征，两者窗口定义不一致时，离线指标会明显高于线上；排查应先对齐窗口语义再怀疑模型退化。因此偏斜检测要在同一份原始事件上双跑两条管道并逐字段比对，而不是比 AUC。另一处边界是「版本化到什么粒度」：只 tag 数据集文件不够，切分方式、分词器、Embedding 模型、去重规则都要进版本键，否则同 tag 下两次重建会产生不同 chunk 集合，评测集与线上索引悄悄错位。

回放反例：一次季度复盘里，团队发现某类问答准确率连续三周缓降 6pt，监控大盘的 PSI 与质量断言全部正常。按时间线回放：先排除模型别名（未变）、再排除 Prompt（未变）、查数据集日增量发现新增渠道的文档占比逐周从 3% 升到 19%，但总量与字段质量都合规，所以告警没响；按意图分桶重算，核心业务意图的训练样本占比被稀释了近一半，而该渠道的问答更简单，把整体准确率抬了上去。修复动作不是「加数据」，而是给数据集加意图配额与来源权重，并把分桶 PSI 定为一级告警。第二个反例是血缘只到文档层：索引重建后召回异常，血缘查到「文档 A 来自库 X」就断了，查不到是哪次切分参数变更导致片段边界改变，最终靠逐版本重放才定位。两次事故共同说明：治理粒度低于失效发生的层级时，血缘形同虚设。

交叉与验收：与 C12.44 的分工是「本卡定为什么、C12.44 定怎么落」：漂移类型与阈值属本卡，Spring AI 的 LineageAdvisor、蓝绿重建、别名切换属 C12.44；A29.02 负责实验绑定的可复现判据，本卡负责生命周期的分段与闸门；A33.02 把四类版本绑进发布单，本卡的五元组是它的上游定义；C14.15 统一「一次召回」「一个 chunk」的指标口径，避免分桶 PSI 用两套分母；G09.02 的血缘台账是跨团队协作时的共同模板。验收口径：分桶 PSI / 质心距离 / 字段断言三类告警分别可注入并各自触发；同一事件双管道逐字段比对差异为 0；季度抽查任一回答能在十分钟内追到 dataset_ver、transform_ver 与 index_ver；三集隔离有静态检查，生产表不得直写评测表。

不适用与代价：分布监控对低频高价值意图几乎无效——某类合同解释每天只有 20 次请求，PSI 分母太小、波动全靠噪声，应改用标注样本回放与人工抽检而非统计检验。第二处代价是分桶维度无限膨胀：按意图 × 渠道 × 租户 × 时段全组合会产生上万条曲线，告警疲劳比没有告警更危险，实践中只保留业务等级最高的 8～12 个桶并季度评审。第三类是「冻结」的副作用：PSI 触线自动冻结写入会让正当的业务上新被卡住，需有明确的人工解冻审批与时效，否则团队会想办法绕过监控。最后，血缘与版本元数据本身也是数据，注册表停服或元数据写错时，整个可追溯链会给出错误答案且无人察觉，因此注册表要像主数据一样做备份、校验与变更评审。

演进脉络：数据治理的重心是随失效形态迁移的。最早只管「数据有没有到」，靠行数、非空率与主键唯一这类字段断言，对应的是 ETL 跑挂了；索引与 Embedding 进入链路后，字段全合规但召回悄悄变差，于是补上按意图分桶的 PSI 与向量质心距离，关注点从「有没有」变成「分布还是不是原来那个」；再往后出现「整体变好、核心变差」这类先验漂移与概念漂移，单看分布曲线已经无感，只能靠标注样本回放与人工抽检，治理对象从数据扩展到「数据 × 意图 × 版本」的组合。这条演进线里有个容易被跳过的结论：监控粒度必须细于失效发生的层级，否则血缘形同虚设；只 tag 到文档层，切分参数变了就查不到片段边界为何改变。也正因为如此，把三类漂移压成一个「数据健康分」是倒退而不是简化——分数把因果信号抹平后，值班只能看到「健康度下降」，却分不出该去查上游渠道、切分作业还是标注分布。按这个脉络，冻结线的取值应由「哪类漂移先造成业务损失」反推，而不是先定一个通用阈值再到处套用。

可复现是科学底线，也是监管底线；数据集管理让一次实验结果可被他人精确重跑、被监管精确核验。

共享盘文件 → 数据集仓库（tag/分支）→ 特征库（Feature Store）→ 评测集独立不可变快照。

数据集快照不可变；特征定义单一来源；评测集与生产集物理隔离；实验记录（run）绑定全要素。

Feature Store 统一线上线下特征；评测集在 CI 锁定快照版本；实验追踪元数据覆盖数据/代码/模型。

特征穿越（feature leakage）常因训练-服务特征定义不一致或时间点切片错误；point-in-time correctness 防止未来信息泄漏；评测集污染导致指标虚高需用盲集与定期重测发现。

特征线上线下定义不一致；评测集直连生产库；run 不绑定数据版本导致无法复现；快照可改破坏不可变假设。

可复现三要素：固定随机种子与采样参数、固定四类版本（prompt / dataset / eval / alias）、固定检索索引快照。所谓「同输入同输出」在工程上应表述为「同输入 + 同版本组合 → 输出分布稳定」，用 K≥5 次运行的通过率与步骤数分位数核验。

故障回放：评测记录保留每步 action / observation / 片段 ID / 分数，失败用例可直接转成回放夹具；评测集本身要有一份不对外暴露的 holdout，防止反复调参把公开集过拟合。

反例：把「温度设为 0」当成可复现保证，但供应商侧模型权重已静默更新，两次运行结果仍不同。修复后把供应商版本与别名映射版本纳入固定项，并要求网关记录 provider_model_ver（C12.48）。

可复现的量化定义：把「同输入同输出」变成可判定的指标，需要区分三层。确定性层：固定随机种子、关闭采样（temperature=0）、锁定 alias_ver，同一用例连跑 20 次应得到逐 token 一致或 ≤1 处差异；示例里即使固定种子，供应商侧的批量调度与浮点累加顺序仍会带来约 3% 的输出差异，因此判据应定为「关键字段一致率 100%、全文一致率 ≥97%」，而不是要求字节相同。可比层：同一 eval_run 在点查与批量两种执行路径下，要点覆盖率差异 ≤1pt，否则说明批处理引入了上下文拼接差异。可追溯层：任一条历史结果能在十分钟内反查到五元组版本与所用评测集 scorer_ver。三层分别对应「能不能重跑」「能不能比较」「能不能解释」，把它们混成一句「可复现」是多数争议的源头。

污染与泄漏的机理：评估污染最常见不是有人作弊，而是管道天然把答案带进了输入。三类路径要分开防：训练集与评测集共用同一去重键导致样本重叠，示例中 4% 重叠就能把准确率虚抬 7pt；线上 Bad Case 不经标注直接回灌为基线，让评测集逐步拟合自身历史错误；用生产查询日志做「难例挖掘」时把带标准答案的运营数据一并纳入。防法是物理分库 + 单向闸门：候选池 → 人工标注 → 盲集，盲集对调优流程只读，且每条用例带 provenance 与哈希指纹，构建时做集合差集断言。另一处隐蔽泄漏是「时间穿越」：用全时段文档构建索引再评测历史时点的问题，答案里含当时尚未发布的信息，指标虚高；评测集要按业务时间切片，索引快照按切片冻结。

回放反例：季度模型升级时离线核心集通过率上升，并不代表线上体验同步改善；若放量后差评反向抬升，应先查评测集是否被业务刷题、评分器版本是否随报告冻结。回放示例里有两处问题：其一，新评测集在构建时把上一季度线上差评样本直接并入了「核心集」，而这些样本恰好是模型调优时反复用过的，等于拿练习题当考卷；其二，评分器版本从 v2 升到 v3 放宽了同义表述判定，报告里没有记录 scorer_ver，前后两次通过率根本不可比。修复动作是把污染样本整体移入独立盲集、给 EvalReport 增加 scorer_ver 与集合指纹，并规定「评分器变更不得与模型变更同批评审」。第二个反例是索引未冻结：评测跑的是 latest 别名，而重建任务恰在评测窗口内完成，前半段用例命中旧索引、后半段命中新索引，报告平均值掩盖了两段的分布差异。此后评测一律绑定 index_ver 显式快照。

交叉与验收：A29.01 给出生命周期与漂移类型，本卡给出实验绑定与污染防护的判据；C12.33 的评测集字段与卡门阈值是这些判据的落地形态，index_ver / prompt_ver / alias_ver 三元组就是本卡五元组的工程子集；C12.41 负责把线上故障转成用例，本卡规定它必须走候选池 → 标注 → 盲集三道闸；A33.02 的四类版本绑定发布单包含 scorer_ver，K09.01 的回放验收口径可直接复用。验收清单：确定性 20 次重跑关键字段一致率 100%；点查与批量覆盖率差异 ≤1pt；集合差集断言重叠为 0；评分器与模型变更不同批评审；历史结果十分钟内可反查五元组。另需静态扫描：评测表不得接受来自生产表的直写，盲集对调优流程只读。

不适用与代价：确定性重跑只适用于可锁定版本的自托管或可回放推理服务；对第三方托管模型，浮点与调度不可控，强行要求字节一致会得出「永远不可复现」的无用结论，正确做法是冻结请求录制值并只验证决策逻辑。第二处取舍是盲集规模：盲集越大越抗污染，但每条用例都要人工标注与季度复核，超过约 800 条后维护成本陡增，实践中按风险分层保留 200～300 条高价值盲例、其余走规则抽检。第三类边界是生成式任务的天然非确定性，开放式写作、多方案设计没有唯一标准答案，可复现判据应改为「rubric 分布稳定」而非字段一致。最后，五元组绑定会让每次实验多出元数据登记与制品存储成本，小团队可先做「三元组 + gitSHA」的最小版，但必须在报告里显式声明省略了哪些绑定，不能默认宣称完全可复现。

端侧把推理下沉到设备，受算力/内存/能耗/离线四约束，量化是主要杠杆，但量化误差需评测兜底。

纯云端 → FP16 → INT8 → INT4/二值 → 混合精度；ONNX/TFLite 统一中间表示跨端部署。

四约束优先于效果；量化是 Pareto 权衡不可拍脑袋；端侧失败模式不同于云端（OOM/发热降频/精度塌）。

量化前后评测对比、端侧运行时（ONNX Runtime）封装、模型下发带版本+签名+灰度。

量化误差层敏感（部分层对量化更敏感）；校准集选择显著影响其 INT8 精度；端侧 FP16 累加误差会放大长尾退化；需在真机低内存下验证而非仅实验室。

量化过度精度崩塌；端云模型版本不一致预测偏差；无离线降级断网即瘫；真机低内存未验证上线 OOM。

四大约束的量化：算力（端侧 NPU TOPS 与可用线程）、内存（权重 + KV Cache + 运行时峰值 ≤ 设备预算的 70%）、能耗（连续推理的温升与降频阈值）、离线（断网时长与本地队列上限）。任一越界即降级到更小模型或回传云端，不允许硬扛到 OOM。

量化损失补偿：INT4 在数字、长上下文与结构化输出上损失更明显，上线前按任务类型分别对比 FP16 基线；对工具调用类任务保留 FP16 或用约束解码，避免格式错误触发重试把省下的算力又还回去。

反例：只按模型权重大小估内存，忽略 KV Cache 随上下文长度线性增长，长会话场景直接崩溃。修复后按「最大并发会话 × 最大上下文」反推显存/内存预算（A33.04）。

四大约束的量化拆解：端侧不是「把小模型塞进手机」，而是四个约束同时求解。算力：1.5B 模型 INT4 在中端 NPU 上解码约 21 token/s，换 INT8 降到 13 token/s 而精度收益仅 1.2pt；内存：参数 900MB 加上 KV cache（2K 上下文约 160MB）与运行时开销，常驻需按 1.2GB 规划，低于 4GB RAM 机型要先查可用内存而非总量；能耗：连续推理 5 分钟可致机身升温 7.2℃、电量下降 3.8%，温控降频后解码速度掉 35%，所以长会话要主动切云端；精度：INT4 相对 FP16 在分类/抽取类任务上准确率损失约 1.8pt，在数值推理与长链生成上损失可达 6pt，因此量化不是全局开关，应按任务类型决定是否允许端侧执行。四者的 Pareto 前沿要按机型档位分别测，用旗舰机数据下发给全量设备是典型误用。

量化损失的机理：INT4 的误差主要来自激活值离群点而非权重均值，逐通道（per-channel）与分组（group-wise）量化的差异在离群通道上最明显：同一模型 group size 32 比 128 的要点覆盖率高 2.4pt，而模型体积只增加 4%。校准集的选择比位宽更关键：用通用语料校准、业务语料推理时，长尾专业术语的召回损失达 5.1pt；换成 2000 条业务抽样校准后降到 1.3pt。另一处机理是「量化后仍走浮点算子」：部分 NPU 驱动不支持 INT4 的某些算子，会静默回退 CPU 浮点，精度看似正常但首 token 从 310ms 变成 2.4 秒——性能回退是量化失效的先行信号，必须在回执里采集解码速度而非只看 checksum。混合精度策略（注意力层保 INT8、FFN 走 INT4）在示例中能以 +6% 体积换回 1.6pt 精度，是比全量降位更划算的取舍。

回放反例：一次端侧升级把默认量化从 INT8 换成 INT4，离线用 500 条通用问答评测，准确率只降 0.9pt，评审通过。上线两周后，涉及金额与条款的长链推理差评集中爆发，回放发现这类任务在 INT4 下的关键数值错误率是通用问答的 3.4 倍，而通用评测集里一条都没有。根因是评测集与真实任务分布不匹配，量化损失高度依赖任务类型。修复动作是建立「按意图的量化准入表」：分类、抽取、短改写允许 INT4；数值计算、多跳、合规解释强制云端或 INT8，并把这条规则写进 EdgeModelRegistry 的兼容矩阵。第二个反例是校准集过期：业务新增一批专业词表后未重校准，长尾召回在三个月内缓降 4pt，没有任何报错，直到季度抽检才发现；此后把「校准集版本 + 业务词表版本」绑定，并把质心漂移监测（A29.01）复用到端侧输入分布上。

交叉与验收：C12.45 负责下发、回执、灰度与端云切换的工程实现，本卡只负责为什么这样约束、以及量化损失的判定；A30.02 的端云闭环消费本卡的置信度与失败类型定义，C12.34 的分桶灰度规则在端侧复用但要换成 device_tier 键。A33.08 的单位完成成本模型需把端侧省下的云端开销与量化导致的返工率一并计入，否则「切小模型」永远看起来更省；C12.46 的脱敏要求决定哪些意图根本不允许端侧处理。验收：四约束在三档机型各有标定记录；按意图的量化准入表有静态校验，高风险意图不会落到 INT4；校准集版本绑定且季度重标；回执含解码速度以识别算子回退；量化前后在同盲集上按意图分桶对比，任一桶跌幅 >3pt 即否决。

不适用与代价：端侧量化不适用于需要完整知识库或长上下文的任务，模型体积下降换不来检索侧的内存与更新成本，此时应做端云分工而非硬塞。第二类代价是碎片化：不同芯片对 INT4 算子支持不一，兼容矩阵要随驱动版本维护，机型超过一定数量后维护成本会超过云端推理费用，实践上只覆盖近三年主流档位。第三类是精度判据的局限：准确率看不出「 confidently wrong 」——量化后模型可能更流畅地给出错误数值，需引入语义校验与人在环（A33.09）而非只靠打分。最后，能耗与温控属于设备状态而非模型属性，同一模型在低温与降频状态下表现会有明显差异，把实验室指标当 SLA 会导致线上体验不稳定，SLA 应按设备状态分档声明并保留随时切云端的通道。

端云协同 = 端侧轻推理/缓存 + 云端重训/编排 + 反馈闭环，是边缘 AI 的骨架而非单点优化。

端全量上云 → 端缓存 → 端轻推理 → 端云分工 → 端侧 Agent + 云端全局编排。

端做低延迟与隐私本地决策，云做重训练与全局视图；反馈数据回传是模型持续改进燃料。

边缘网关路由、端侧结果回传云端、云端增量重训触发、模型下发灰度与回滚。

联邦/协同学习的通信-计算权衡决定批策略；反馈闭环的标签延迟会放大概念漂移；端云对同一输入结论应一致，需一致性校验防止用户困惑。

反馈断流模型僵化；端云决策不一致；边缘节点无回退；模型下发无签名被植入脏模型。

闭环协议：端侧上行的是「失败样本摘要 + 置信度 + model_ver + dataset_ver + 设备分组」，不是原始隐私数据；云端按失败簇重训或更新 Prompt，新版本先在影子设备组验证再灰度下发，下发结果回写闭环台账。

边界条件：离线队列需设上限（如 5000 条 / 7 天）与去重键，恢复网络后按批次限速回传，避免千万台设备同时上线把采集管道打满；端侧版本与云端评测集版本要能对齐，否则无法判断某个失败是否已被修复。

反例：设备恢复联网后集中回传三天缓存，采集队列积压 6 小时，期间所有在线评测被延迟。修复后加入指数退避与按设备哈希分片回传（C12.47 背压思路）。

闭环的量化模型：端云协同的收益要看「净节省」而非直出率。定义端侧直出率 R、端侧错误率 e、云端兜底成本 C、返工与投诉成本 F，净收益 ≈ R×C − (R×e×F + 回传与重训成本)。示例取 R=0.68、e=1.2% 时净节省 41% 云端开销；把置信度阈值从 0.85 降到 0.70 后 R=0.84，但 e 升到 4.6%，净收益反而回落到 23%，因为一次错误答复的人工补偿成本约为一次云端推理的 60 倍。闭环的另一侧是反馈质量：端侧只回传「失败类型 + 意图标签 + 脱敏片段哈希」时，可用于重训的有效样本率 31%；补上云端重推理的 diff 标签后升到 68%，但回传带宽增加 2.4 倍。因此反馈字段要按价值密度筛选，不能全量上报，更不能把用户原文直接回流。

反馈延迟与分布偏移：端侧样本到达云端存在天然延迟与选择偏差，这是闭环最容易被忽略的机理。延迟：4G 与闲时 Wi-Fi 策略下，回执延迟可能长达小时级且长尾远大于中位，若按小时级触发重校准，模型会追着一个滞后的分布跑；实践上按 24 小时窗口聚合、周级触发校准。选择偏差：只有「端侧低置信度」样本会被回传，云端看到的是被筛过的难例分布，直接用它做全量再训练会让模型在简单意图上退化，核心意图准确率可下降 2.8pt。正确做法是保留一部分随机采样（约 5%）作为无偏参照，并用重要性加权修正。还有一类偏移来自设备档位：低端机失败样本占比天然更高，若不按 device_tier 分层，重训会过度拟合低端机噪声，把中高端机体验拖下去。

回放反例：某次闭环上线后两周，云端模型在标准评测集上指标稳定，但端侧用户投诉上升。回放链路发现三个问题叠加：其一，回传样本只含低置信度难例，重训数据分布偏离真实流量；其二，回执延迟 P95 19 小时，校准任务按小时触发，实际在拟合昨天的分布；其三，影子比对阶段只比对了最终答案，没有比对「端侧与云端选择的工具是否一致」，导致端侧少调一次校验工具却因答案碰巧相同而被判一致。修复是把影子比对扩展到工具调用序列与关键字段、反馈按 device_tier 分层加权、校准改按 24 小时窗口，并把「一致率」拆成答案一致率与轨迹一致率两个指标，任一低于 95% 都不允许端侧直出。第二个反例是回传带宽：一度把完整上下文回传用于分析，触发隐私评审叫停，此后字段清单由 C12.46 的脱敏规则裁定并固化到协议里。

交叉与验收：A30.01 定义置信度与失败类型，本卡定义它们如何形成可训练的反馈；C12.45 的 edge_quality 表与回执聚合是物理载体，C12.44 的数据集版本与三集隔离规则同样适用于端侧回传样本，避免回流数据污染评测盲集（A29.02）。A33.08 的成本模型提供净收益公式中 C 与 F 的口径，C12.40 的行为基线在端侧只能本地聚合后回传。验收：净收益按意图分桶计算并留回放记录；反馈含 5% 无偏随机采样且按机型分层；影子比对同时验答案与工具轨迹一致率 ≥95%；校准窗口 ≥24 小时并验证不追滞后分布；回传字段经脱敏评审，不含用户原文。

不适用与代价：闭环成立的前提是端侧与云端能对齐同一套意图与置信度定义；若两端用不同模型、不同分词、不同阈值，diff 标签本身就没有可比性，反馈越多偏差越大。第二类边界是低频意图：某类意图每天不足 10 次，回传样本量撑不起校准，应按季度人工评审而非自动重训。第三类是合规：受监管决策要求完整留痕，端侧直出会缺失云端审计链，这类意图必须强制云端（C12.46），闭环里要为它们设 no_edge 标记。最后，闭环有运维成本：回执聚合、分层加权、影子比对、校准调度四套组件都要监控，若团队规模不足以维护，宁可退化为「端侧只读缓存 + 云端决策」的单向模式，也不要上一个无人看管的自动重训环路。

算力是 AI 应用最大可变成本，FinOps 把成本从不可控账单变成可归因、可优化的单位经济。

不计成本 → 资源监控 → 成本归因 → 调度优化（spot/排队）→ 预算池化与单位经济。

成本必须归因到场景/租户/模型；利用率与单价双优化；单位经济（每千次调用成本）优于绝对值。

GPU 利用率监控、成本归因看板、spot/抢占调度、预算池与配额、模型路由降本。

GPU 利用率低根因常为碎片化/长尾批/冷启动；显存与算力可解耦（推理与 KV cache 分离）；批大小与延迟呈 Pareto；多租户隔离需把成本内化到租户。

只砍单价不提利用率；成本无归因找不到大头；预算碎片化无法调配；忽略长尾批碎片浪费。

二阶成本模型：单位完成成本 = (推理成本 + 重试成本 + 沙箱/工具成本 + 人工介入成本) ÷ 成功完成任务数。只看 GPU 单价会把重试风暴与人工返工漏掉；实测中「切便宜模型」常因返工率上升使分母下降而更贵。

控制杠杆：按任务难度分级路由、前缀/语义缓存、批量与连续批处理（注意 TTFT 权衡）、按租户配额与预算门禁、用户取消即 abort 推理。缓存键必须含 tenant / 上下文版本 / 数据时间窗口，避免串租户复用。

反例：为降本把默认别名全局切到小模型，工具调用格式错误率上升导致重试翻倍，单位完成成本反升 18%。修复后按任务类型做 A/B 并以「单位成功任务成本」为判据（A33.08）。

单位经济的推导：单位完成成本的分母必须是「成功任务」而非「调用次数」，这是整个模型的支点。设推理单价 c、平均调用次数 n、重试放大倍数 r、人工介入率 h、单次人工成本 w，则 U = (n×c×r + 工具与沙箱成本 + h×w) ÷ (1 − 失败率)。示例里把默认别名从大模型切到小模型后 c 降 42%，但工具格式错误率上升让 r 从 1.15 升到 2.3、h 从 2% 升到 7%，代入后 U 反升 18%——这正是「只看单价会亏」的量化解释。第二个支点是利用率：GPU 利用率低往往不是算力不够，而是碎片化与长尾批，把连续批处理的等待窗口从 20ms 调到 60ms，吞吐提升 2.1 倍而 TTFT 只增加 34ms，在交互类 SLA 内是划算的；但离线批任务可把窗口放到 300ms，收益再增 40%。把 U 按场景、租户、模型别名三维归因，才能定位真正的大头。

成本归因的机理：归因失败通常不是没埋点，而是维度缺失或分摊规则不一致。推理成本要拆到 prompt token、completion token、缓存命中、重试四段，各自按 alias_ver 定价；工具与沙箱成本按调用次数与时长单列，不能摊进「模型成本」；人工介入成本最容易被漏掉，需由工单系统按任务 ID 回写。多租户场景下还要区分「共享池空闲成本」与「按租户边际成本」，把空闲全部分摊给活跃租户会得出错误定价，会高估头部租户 23%。另一处机理是预算池化：按团队切死配额时，A 团队月末预算结余、B 团队被迫降级，整体利用率只有 51%；改为「团队软配额 + 全局池调剂」后升到 74%，但要配跨团队的结算规则与审计，否则会出现搭便车。

回放反例：一次降本专项把月度账单压了 27%，季度复盘却发现业务侧人力成本上升。回放三类数据：模型账单、任务成功率、人工工单，发现为省 token 把上下文裁剪阈值收紧后，长文档任务的要点覆盖率从 91% 掉到 79%，用户反复追问使单任务调用次数从 1.4 升到 3.1，且 11% 的任务最终转人工；账单降了，单位成功任务成本反升。修复动作是把降本判据从「账单总额」改成 U，并给每类优化加「成功率不下降」的约束。第二个反例是 spot 抢占调度：为省单价把离线评测全放抢占实例，结果季度有 6 次被中断重跑，节省的单价被重跑与延期发布抵消，且评测报告出现版本窗口不一致；此后按任务可中断性分级，带发布卡门的评测不放抢占实例。

交叉与验收：C12.26 讲语义缓存、分级路由与上下文裁剪的具体手段，本卡只定义「省得值不值」的判据；C12.09 的成本优化工程实践是手段集合，A33.08 的 Token 成本与延迟治理提供 c 与 r 的采集口径，二者共用同一套四维标签。C12.20 的多模型路由决定别名切换，本卡规定切换必须以 U 而非单价做 A/B 判据；C12.37 的重试预算与 C12.35 的降级备用池配额都进入 U 的分子，漏一项就会低估真实成本。验收：U 按场景/租户/别名三维可下钻；任何降本变更同时报账单变化与 U 变化，且成功率不下降；归因分摊规则版本化并留评审；预算池调剂有结算与审计记录。

不适用与代价：单位完成成本不适用于无法定义「成功」的探索型任务，研究、创意、开放式分析没有稳定分母，强行算 U 会把成本压力错误导向缩短探索时间。第二类是新业务冷启动：样本量不足时 r、h、失败率估计方差极大，按 U 做路由会在噪声上过拟合，应先用固定档位跑满一个月再启用动态判据。第三类代价是归因系统本身：三维下钻需要账单、指标、工单三套数据按任务 ID 对齐，ETL 与对账成本不小，小团队可先做「按别名 + 场景」两维周报，但必须显式标注未纳入的人工与沙箱成本，不能把不完整的 U 当成完整结论。最后，成本优化不能突破可靠性与合规底线，把审计、评测、人在环当成「可省项」是典型的假降本，这类开销应由 SLA 与监管要求直接锁定。

多模态（文/图/音/视频）扩展能力边界，但对齐与评测更难、失效更隐蔽，不能复用纯文本指标。

独立单模 → 晚期融合 → 跨模态对齐（CLIP 类）→ 统一表征 → Agent 多模态工具。

模态对齐是能力前提；跨模态评测不可复用文本指标；失效常源于模态间不一致。

多模态评测集、模态缺失降级、跨模态一致性校验、引用可追溯（图/视频出处）。

模态鸿沟（不同模态表征空间不一致）通过对齐损失缩小；视觉问答幻觉常表现为物体存在性/计数/空间关系错误；跨模态评测需细粒度指标而非单一 accuracy。

用文本指标评多模态；模态缺失不降级崩；视觉引用不可追溯；对齐只在训练不在服务校验。

细粒度评测指标：把跨模态能力拆成物体存在性、计数、空间关系、文字识别（OCR 字错率）、语音转写（ASR 字错率，按口音/噪声分桶）与引用可点开率六项，逐项设基线；单一 accuracy 会把这些错误平均掉。

生产链路补充：转换层输出 confidence 与时间戳/帧号，低置信度走澄清或人工；生成层引用原始片段 ID；响应里标注模态缺失与降级原因。延迟按 VAD 判停 → ASR → 推理 → TTS 首包四段分解，只优化模型推理不足以改善体感。

反例：把 ASR 结果当事实直传，噪声环境下一个误识别字改变用户意图，下游生成流畅但完全跑偏且无留痕。修复后转换层置信度进入轨迹与审计（A33.05）。

对齐与评测的量化：多模态的难点不在「能不能识别」，而在跨模态一致性能否被判定。定义三类可测指标：时间对齐（语音/视频片段与文本时间戳偏差 ≤200ms，示例里偏差 >500ms 时引用溯源正确率从 94% 掉到 71%）、跨模态一致性（同一实体在 OCR、转录、画面标注三路的字段一致率 ≥97%）、证据可点开率（回答中每个数值都能定位到原始帧号或片段 ID，目标 100%）。评测集构造比纯文本难在「参考答案不唯一」：同一张票据的金额在 OCR 与版面模型中可能给出两种切分，需用 rubric 而非字符串匹配，并让标注者给出可接受的等价集合。示例中引入 rubric 后，评测者间一致率从 0.68 升到 0.89；反之用固定答案会系统性低估带表格的页面。

失效机理：多模态的静默失效有独特形态。一是模态缺失降级：音频转录为空时系统仍会用文本侧信息生成流畅回答，用户看不出少了哪一路输入，这类「有响应无依据」不会自己报错，必须在响应里显式标注各模态的可用性，并在评测里按模态缺失分桶统计。二是分辨率与压缩：票据照片压缩到 720p 后小字号数字识别错误率升到 8.4%，但 OCR 置信度仍报 0.9，说明置信度与真实正确性脱钩，需引入跨路一致性断言而非信任单路分数。三是时间轴错位：视频按固定 30 秒切片会把一句话切成两半，转录丢掉谓语，回答语义反转；切片应按语义边界（静音检测 + 镜头切换）而非固定时长。四是对齐偏差会向下游传播：检索片段带错帧号后，引用溯源、评测打分、审计留痕会一起错，且没有任何一层抛异常。

回放反例：某次合同扫描问答上线后，回答语气自然、引用格式完整，但金额偶发错误。回放发现两条独立问题叠加：其一，OCR 把「万元」识别成「元」而版面模型给出正确单位，融合层按置信度取了 OCR 结果，没有做单位一致性校验；其二，引用片段的帧号来自压缩后的预览图而非原图，抽查时点开的画面与回答依据不是同一处。修复动作是给数值字段加量纲与跨路一致性断言（与 C12.36 的语义校验同构）、引用统一指向不可变原图快照、并在低置信度样本上强制澄清分支。第二个反例来自评测：早期用纯文本 rubric 评多模态回答，只判「答案对不对」，不判「证据能不能点开」，导致一批「答案碰巧对、证据全错」的用例长期通过；此后把证据可点开率设为一级卡门，与答案准确率并列。

交叉与验收：C12.10 讲多模态能力与趋势，本卡只定义评测与失效判据；A28.01 的静默失效四型分类在本卡表现为「模态缺失仍返回流畅回答」，应与行为基线（C12.40）联动告警。A33.05 的多模态/语音生产链路是本卡判据的工程落地，C12.45 的端侧推理决定哪一路在设备侧执行，两者的时间戳口径必须统一，否则对齐指标无法跨端比较。C12.36 的语义校验网关复用为数值量纲断言，C12.41 的故障快照需额外冻结原图/原音频哈希与帧号。验收：时间对齐偏差 ≤200ms、三路字段一致率 ≥97%、证据可点开率 100%；模态缺失注入时响应必须显式标注而非静默降级；rubric 评测者间一致率 ≥0.85；低置信度样本走澄清分支且阻断生成。

不适用与代价：严格跨模态一致性断言适用于票据、合同、医疗影像等强证据场景；开放式图像描述、创意视频理解没有唯一正确答案，强行要求三路字段一致会把合理多样性判为错误。第二处代价是存储与计算：保留不可变原图与逐帧时间戳，会使单任务存储成本增加约 4 倍，需按数据等级设留存分层，不能全量永久保存。第三类是标注成本：多模态 rubric 需要标注者同时看画面、转录与 OCR，单条用例标注耗时约为纯文本的 5 倍，盲集规模应相应收缩并优先覆盖高风险意图。最后，跨模态对齐不是一次性的：切片策略、OCR 版本、转录模型任一升级都会改变帧号与字段值，评测集需绑定这三者的版本，否则前后报告不可比——这一点与 C12.33 的索引版本绑定是同一条原则在不同模态上的投影。

站点现有评测体系覆盖 Golden Set、RAGAS / DeepEval、CI 卡门与故障快照回放，但都是结果级（outcome-level）：比对最终答案与参考答案。Agent 的生产事故常发生在过程里——工具选错、多绕三步、越权读数据、在错误分支上「碰巧答对」。本题补的是 trajectory / step-level eval：把一次运行建模为可打分的步骤序列。

结果打分（答案相似度）→ 组件级指标（检索命中率、工具成功率）→ 轨迹级（步骤序列、路径偏差、恢复行为）→ 在线轨迹采样与回归门禁 → 轨迹驱动的自动归因与修复建议。

轨迹 = 有序步骤 + 每步的上下文、动作、观察、耗时与成本。评测对象不只是「选了哪个工具」，还包括是否必要、参数是否正确、遇到失败是否正确恢复、是否遵守权限边界。

非确定性下要评分布而非单次：同一输入跑 K 次（K≥5），报告通过率、步骤数分位数与路径熵；用单次结果判通过会把随机波动误当成能力。

过程指标与结果指标要同时看：结果正确但轨迹含越权调用，仍判失败；结果错误但轨迹完全合规，归因到模型能力而非工程缺陷。两类指标分开记录，避免互相掩盖。

轨迹 schema：run_id / step_idx / state_snapshot / action(tool,args) / observation / latency_ms / token_cost / guardrail_hits / error，由 Agent Harness 在每步 emit，落到可回放的事件日志（与 C11.31 事件契约同构）。

打分器分三层：①规则断言（禁止工具集合、必调工具、参数域、步数上限）；②路径比对（与专家标注的标准轨迹做编辑距离 / 前缀匹配）；③模型裁判（对「这一步是否必要」做带 rubric 的评分，裁判本身要用 Golden Set 校准）。

门禁示例：轨迹合规率 ≥ 98%、平均步数相对基线 ≤ +15%、越权调用 = 0、失败后恢复成功率 ≥ 90%；任一越界阻断发布（C12.29 评测集 CI 卡门的步级扩展）。

失败归因：把失败轨迹按首个偏离步骤聚类，输出「工具选择 / 参数生成 / 上下文缺失 / 恢复策略 / 权限配置」五类分布，直接指向该改 Prompt、工具描述还是 Harness 状态机。

为什么 trajectory eval 被工程界视为最开放的评测问题？因为「正确路径」往往不唯一，标注成本高且随工具集演进而失效；实践上用「不变量断言 + 关键里程碑」代替完整路径标注，比强制单条标准轨迹更可维护。

与静默失效（silent failure / A28.01）的关系：结果级指标看不出的 fail-plausible，常在轨迹里表现为「跳过了必须的核验步骤却给出流畅答案」，步级断言是少数能提前捕获它的手段。

只评最终答案：越权调用与多余工具调用被判为通过，直到审计才暴露。

用单次运行做回归门禁：随机性造成假红/假绿，团队很快绕过卡点。

把完整标准轨迹写死：工具集一升级全部用例失效，维护成本压垮评测体系。

轨迹日志不含成本与耗时：无法解释「结果一样但这次贵了 3 倍」。

向下回指：A06.01 / A17.01 / C12.29 / C12.41 / A28.01 / C12.47。本卡只定「过程是否可信」的判据与信号口径；结果级评分、快照如何存、故障如何重放由所引卡各自负责，验收时两类通过率必须分开出图，不能拿最终答案正确率替代步级通过率。

站点已有版本回滚、漂移监测、数据生命周期、评测门禁与灰度回滚的分散能力，缺的是把它们串成一条端到端链路并给每个资产定义 owner。LLMOps 不是又一套工具，而是回答「线上这次回答由哪几个版本共同决定、出问题先回滚哪一个、谁有权改」。

Prompt 写在代码里 → 独立配置 → 版本化资产 → 与数据集 / 评测集 / 模型别名绑定发布单 → 血缘贯通、漂移监测与责任归属制度化。

一次线上行为由四类版本共同决定：prompt_ver / dataset_ver / eval_ver / alias_ver（外加代码版本与检索索引版本）。只记录其中一两类，事故就无法复现。

资产平等：数据集与评测集和代码同等级别，变更需评审、版本、回归与回滚；悄悄替换评测集让通过率「上升」是最隐蔽的失真。

血缘要能双向查询：从线上 run_id 反查当时全部版本；从某个 Prompt 版本正查影响哪些业务与哪些评测结果。

责任归属显式：每类资产有 owner 与变更审批人，自动漂移监测告警必须落到人，否则「监测」只是看板。

发布单字段：release_id / prompt_ver / dataset_ver / eval_ver / alias_ver / index_ver / code_ver / owner / approver / canary_plan / rollback_target。模型网关（C12.48）按发布单解析别名映射，禁止手工热改。

四类门禁：①Prompt 变更 → 离线评测集回归 + 关键用例人工抽检；②数据集变更 → 数据质量断言与分布漂移检查（C12.44）；③评测集变更 → 评审 + 基线重算；④别名/模型变更 → 灰度 + 成本与 TTFT 双指标观测（C12.30）。

漂移监测三层：输入分布（意图/长度/语言）、检索分布（命中率、片段来源）、输出分布（拒答率、长度、工具调用率、成本）。相对 7 日基线偏移超阈值即告警到 owner，并自动冻结相关发布。

Java / 平台落点：资产注册表 + 制品仓库 + CI 卡点 + 网关控制面（C10.33 / C10.34）；业务侧只声明版本组合，不直接编辑线上 Prompt 文本。

为什么「把 Prompt 放数据库方便热更」是反模式？热更绕过了评审、回归与回滚链，且没有版本就无法回答「昨天和今天为什么不一样」；正确做法是热更的对象为「已发布版本的权重/开关」，文本本身仍须走发布流程。

评测集被污染如何检测？维护一份不对外暴露的 holdout 集，定期比对公开评测集与 holdout 的通过率差；差值异常扩大通常意味着过拟合或数据泄漏。

只版本化 Prompt：模型别名换了、索引重建了，复盘时无法还原当时行为。

评测集随业务迭代静默替换：通过率上升但线上投诉同步上升。

漂移告警无 owner：看板红了三天无人处理，监测形同虚设。

回滚只回 Prompt 不回别名：回退后行为仍未恢复，误判为回滚无效。

向下回指：A23.01 / A23.04 / C12.44 / A29.01 / G07.01 / C12.30 / C12.48。本卡只定资产版本与责任人的绑定关系；漂移怎么测、回滚怎么切、评测怎么卡门归所引卡。判据是任挑一次线上回答能反查出模型、Prompt、索引与评分器各自的版本号，缺一项即血缘断裂。

站点 A11 组覆盖个人使用规约、G07.09 给出治理红线、A26 组讨论组织 adoption，缺的是团队级治理与度量闭环：工具准入、上下文与任务拆解规范、AI 生成代码的审查与安全管控、效能指标与反作弊。个人提效无法线性外推为组织提效，因为评审、返工与合规成本会随 adoption 上升。

个人试用（Vibe Coding / Copilot / Cursor / 通义灵码）→ 团队约定上下文与任务拆解 → 生成代码强制审查与安全扫描 → 效能指标与质量基线并行观测 → 平台化默认路径（IDP）与治理例外国审计。

度量必须成对：交付前置时间、变更失败率、回滚率、缺陷逃逸率要与「采纳率 / 生成代码占比」同时看。只报生成占比会激励灌水，只报速度会忽视质量债。

上下文是治理对象：让工具看到什么（仓库范围、密钥、客户数据、内部文档）要有分级与默认拒绝；上下文供给质量比模型能力更决定生成质量，规范应落在「任务拆解 + 上下文包」上。

AI 生成代码不降低审查标准：生成代码同样过 Code Review、单测覆盖率、依赖漏洞扫描、许可证检查与架构约束（分层依赖、禁用 API）；差异只在于要额外标注生成来源便于事后归因。

反作弊是指标设计的一部分：任何单一「行数 / 提交数 / 采纳率」指标都会被优化；采用多指标 + 抽样人工复核 + 长周期趋势，禁止把指标直接挂到个人绩效。

工具准入清单：数据出境与驻留、代码是否用于训练、私有化/网关接入方式、审计日志粒度、权限最小化、可停用开关。准入由平台与安全共同评审，未过清单的工具不得接入公司仓库（C12.48 统一入口思路）。

上下文规范：任务卡必须写明目标、约束、验收与相关模块；上下文包由平台按仓库权限自动生成并附带来源，禁止把整库或生产数据贴进对话；敏感仓库默认禁用外部工具。

效能看板四项：交付前置时间中位数、变更失败率、AI 生成代码的返工率、评审平均耗时；按团队而非个人聚合，观察 8～12 周趋势再下结论。

与组织治理衔接：把上述规则做成平台默认模板与门禁（C10.34 / G11.03），团队只需声明例外；每季度评审例外与返工率，反向修正上下文规范与准入清单。

为什么「生成代码占比」容易失真？因为它把重构、样板代码、测试桩与核心逻辑等价计数，且无法反映返工。更稳的代理指标是「首次评审通过率」与「合并后 7 日内被修改比例」。

Vibe Coding 在团队场景的主要风险不是代码错，而是决策留痕缺失：为什么这样设计、参考了哪份规约、谁批准了偏离，若不落进 PR 描述与 ADR，技术债会以「没人记得为什么」的形式积累（呼应 G11.02）。

用生成行数做 KPI：代码量与返工量同步上升，评审成为瓶颈。

跳过 Code Review 与依赖扫描：许可证与漏洞风险在合并后才被发现。

把生产数据贴进外部工具：合规事故往往发生在「临时试一下」的场景。

只做工具采购不做上下文规范：同一个工具在不同团队效果差异数倍，被误判为工具不行。

向下回指：A11.01 / A11.04 / G07.09 / A25.03 / A26.02 / G11.03 / C10.34。本卡定组织级准入与度量的边界；工具规约、审查红线、采纳曲线归所引卡。判据是同一指标在个人与团队口径下分别出数：只看生成量不看返工与评审耗时，提效结论必然虚高。

内网与受监管场景要求模型不出域，问题从「调 API」变成自建一条推理生产线：服务引擎、显存与并发的取舍、量化损失、GPU 调度、镜像与权重分发、以及 Java 业务系统与 Python 推理栈的边界。站点 A18.01 讨论选型，本题补端到端工程。

单机裸跑模型 → 专用推理引擎（vLLM / TensorRT-LLM / SGLang，PagedAttention 与连续批处理）→ 量化与蒸馏降本 → K8s GPU 调度与多租户配额 → 与模型网关 / LLMOps 打通的统一生产链路。

显存与吞吐的约束是 KV Cache：并发会话数 × 上下文长度 × 每层 KV 维度决定显存占用；连续批处理提高吞吐但会拉长单请求 TTFT，容量模型必须按「显存预算 ÷ 单会话 KV」反推可承诺并发（C10.32）。

量化是有损优化，必须评测补偿：INT8 / INT4 / AWQ / GPTQ 降低显存与延迟，但在长上下文、数学与工具调用上损失更明显；上线前用同一评测集做 FP16 基线对比，并把通过率下降纳入发布门禁。

Java 与 Python 解耦在进程边界：业务侧 Java 只通过模型网关（C12.48）调用，不直接依赖 Python 库；推理侧独立伸缩、独立发版，避免把 CUDA / Python 依赖拖进业务镜像。

权重也是制品：权重文件带版本、校验和与许可证，分发走制品仓库并灰度到节点；禁止在节点上手工替换权重文件导致「同版本不同行为」。

部署形态：K8s 用 device plugin / MIG 做 GPU 分配，推理副本按模型维度分池，避免多模型互相抢显存； readiness 检查要覆盖「引擎已加载权重且能完成一次 warmup 推理」，而非只查端口。

关键参数基线：max_model_len / gpu_memory_utilization / max_num_seqs / tensor_parallel_size 与量化方案一起进压测报告；观测 TTFT、TPOT（每输出 token 时间）、吞吐 tok/s、显存水位、preempt 次数。

Java×Python 混合部署：业务服务（Spring Boot）→ 模型网关（鉴权/配额/别名）→ 推理池（Python 引擎），中间用 gRPC / HTTP + SSE 流式；网关负责超时、取消与成本归因，Java 侧不感知 GPU 拓扑。

内网运维：离线镜像与权重预热、无外网时的许可证与依赖审计、GPU 节点故障时的容量接管余量、以及日志脱敏与决策留痕（C12.46 合规口径）。

为什么连续批处理会让 SLO 难以承诺？因为一批内长输出请求会拖住短请求的完成时间，需要按输出长度分池或设最大批次等待窗口；把 TTFT 与总生成时长分开承诺更贴近实际（C12.47）。

私有化与公有云的成本对比不能只看单次 token 价：要计入 GPU 闲置、运维人力、权重更新、电力与故障接管余量；低且不稳定流量下，混合路由（敏感走私有、通用走公有）通常更优。

只按模型参数量估显存：KV Cache 随并发与上下文线性增长，长会话场景直接 OOM。

量化后不做评测回归：工具调用参数格式悄悄劣化，线上表现为随机失败。

业务镜像里塞 CUDA 依赖：镜像体积与构建时间暴涨，JDK 升级被 GPU 栈卡住。

节点手工换权重：灰度期间不同节点行为不一致，问题无法复现。

向下回指：A18.01 / D05.05 / S10.03 / S11.06 / C12.48 / C10.32。本卡定推理生产线的分层边界；资源隔离、镜像分发、跨语言调用归所引卡。判据是替换权重后能否在不重启业务 JVM 的前提下完成灰度，若必须整栈重启，则两侧边界没有真正切开。

多模态把文本链路扩展到图 / 音 / 视频，但失效更隐蔽、评测更贵、成本与延迟方差更大：语音识别错一个字可能改变意图，图片里的物体计数与空间关系错误无法用文本指标发现，一段 30 秒音频的 token 成本可能是纯文本的数十倍。本题补生产链路而非模型原理（A32.01 已覆盖原理）。

单模态独立服务 → 拼接式流水线（ASR/OCR → LLM → TTS）→ 端到端多模态模型 → 流式双工语音 Agent → 统一评测、溯源与成本治理的多模态生产链路。

模态转换处是错误放大器：ASR / OCR 的错误会作为「事实」传给后续模型，且无法靠下游纠正；必须在转换层输出置信度与候选，低置信度走澄清或人工，而不是硬传。

跨模态一致性要单独评测：图片中物体存在性、计数、空间关系与文字描述是否一致，语音转写与最终回复是否语义一致；这些都要细粒度指标，不能复用 accuracy / BLEU。

引用必须可溯源到原始片段：回答里引用图/音内容时，要保留时间戳、帧号或裁剪区域，让审阅者能点开核对；无溯源的引用在合规场景等于不可上线（C12.46）。

延迟按双工体验拆解：语音场景用户感知的是「说完到开口」的端到端延迟，需拆成 VAD 判停、ASR、推理、TTS 首包四段分别设预算；只优化模型推理不足以达标。

链路设计：输入层做格式校验、时长/分辨率限制与敏感内容检测；转换层输出带 confidence 的结构化结果（含时间戳）；编排层按置信度决定是否澄清；生成层引用原始片段 ID；输出层做 TTS/字幕一致性与引用渲染。

评测集分层：①转换层（ASR 字错率、OCR 准确率，按口音/噪声/分辨率分桶）；②理解层（VQA 存在性/计数/空间关系）；③链路层（端到端意图正确率、引用可点开率、低置信度澄清率）；④成本层（每秒音频 token、每图 token、P95 端到端延迟）。

降级阶梯：模态缺失 → 转文本路径；低置信度 → 澄清或转人工；模型不可用 → 只返回可溯源片段而不生成结论；成本超预算 → 降采样 / 截帧 / 缩短上下文。每一步都要在响应里标注降级原因与数据新鲜度。

与长响应架构衔接：语音双工是典型的「长连接 + 流式 + 可取消」链路，复用 C12.47 的租约、心跳、seq 续传与取消语义，避免为语音另写一套状态机。

为什么多模态静默失效更难发现？因为输出通常流畅且看似合理，错误藏在「图里其实没有这个物体」这类事实层；需要把原始片段与生成断言做自动一致性校验，而不是只做人工抽检。

双工语音的打断（barge-in）如何建模？客户端检测到用户开口即发取消帧，服务端按当前 seq 截断生成并保留已说内容；取消必须传播到 TTS 与推理两侧，否则会出现「模型还在说、用户已插话」的错乱。

把 ASR 结果当事实直传：噪声环境下一个误识别字改变用户意图，且下游无从纠正。

用文本指标评多模态：物体计数与空间关系错误被平均分数掩盖。

引用不带时间戳/帧号：审阅无法核对，合规审查直接否决。

只压测文本请求：音频/图片请求把带宽与 token 成本打爆，P95 延迟成倍恶化。

向下回指：C12.10 / A32.01 / L03.13 / G10.02 / K09.03 / C12.47。本卡定对齐、溯源与成本延迟的联合口径；单模态编码、沙箱、回放归所引卡。判据是引用能否带时间戳或帧号定位到原始片段，只给文本摘要的引用在合规审查里无法核对。

Spring AI、LangChain4j 等框架提供了 Prompt / ChatClient / Tool / VectorStore / Advisors 的统一抽象，但框架抽象一旦覆盖到业务编排与状态机，就会成为换模型、换供应商与自定义 Harness 时的最大阻力。本题要划清「框架负责什么、平台负责什么、业务自己负责什么」。

裸调 SDK → 框架封装 Prompt/向量/工具 → 引入 Advisors 做横切（日志、审计、重试）→ 平台层统一网关与资产版本 → 业务自建 Harness 状态机，框架退化为可替换的适配层。

可替换性优先于便利性：业务代码应依赖自建的窄接口（如 ModelInvoker / ToolRegistry），框架实现放在 adapter 层；直接把 ChatClient 注入上百个业务类，等于把框架版本绑定到全站。

横切能力放平台而非框架：鉴权、配额、审计、成本归因、别名路由、kill switch 属于组织级一致性边界（C12.48），应由网关/平台统一实现；框架内 Advisors 只做进程内的日志、脱敏与上下文拼装。

状态机是业务资产：Agent 循环、重试、恢复、人在环审批、任务持久化属于业务语义，交给框架黑盒会让步级评测与故障回放无从下手（A33.01）。

版本与 API 稳定性是选型指标：预览 API、注解式魔法、隐式自动配置在快速演进期收益高、长期维护成本高；评估时要看升级频率、 breaking change 记录与可测试性。

分层建议：业务编排（自建状态机） → 窄接口（ModelInvoker / ToolSpec / TraceSink） → 框架适配层（Spring AI / LangChain4j 实现） → 模型网关（平台）。任一层替换不影响上层。

Java 落点：用 Spring Boot 自动配置注入 adapter，但把关键参数（超时、重试预算、max_tokens、alias）统一从控制面读取；虚拟线程适合承载大量阻塞 I/O，但推理超时与取消由任务层负责（C12.47）。

可测试性：窄接口提供确定性 fake 实现，让轨迹评测与故障注入不依赖真实模型；框架相关测试限定在 adapter 模块，业务测试不启动框架上下文，CI 时间可控。

与平台工程衔接：把这套分层做成服务模板默认实现（C10.34），避免每个团队各自决定「框架抽象到哪一层」，否则半年后全站出现 N 种不可互换的封装。

为什么「框架自带的 Memory / Agent 循环」在规模化生产里要慎用？它们通常把状态放在进程内存或用简单序列化，跨实例漂移、取消恢复、审计留痕与步级回放都缺；生产状态应落在可持久化的任务状态机里。

MCP 等协议如何定位？它是工具/上下文的互操作协议，属于接口契约层；把协议细节直接写进业务逻辑同样会形成锁定，宜通过 ToolRegistry 适配。

业务代码到处注入框架类型：一次框架 breaking change 引发全站改造。

把配额与审计写进框架 Advisor：多语言/多框架服务无法共享治理口径，出现漏记。

依赖框架内置 Memory 做生产会话：实例重启即丢，且无法回放与审计。

没有 fake 实现：评测与故障注入必须调真实模型，CI 慢且不稳定。

向下回指：C12.01 / A01.01 / L03.11 / A12.01 / C12.48 / C10.34。本卡定抽象应该停在哪一层；Advisor、Memory、MCP 的具体实现归所引卡。判据是换掉框架后业务状态机能否原样保留，若编排写在框架基类里，选型问题就退化成迁移成本问题。

Agent 一旦能执行代码、访问文件系统或调用外部 API，风险模型就从「输出不当」升级为真实副作用：任意代码执行、横向移动、数据外泄、资源耗尽。沙箱（sandbox / E2B / Modal / gVisor / Firecracker）不是加一个容器就完事，而是要定义执行主体的权限、生命周期与可观测边界。

无隔离进程内执行 → 同机容器 → 强隔离（microVM / gVisor / seccomp）→ 按任务临时沙箱 + 网络白名单 + 资源配额 → 与策略引擎、审计和轨迹评测联动的执行治理平面。

默认拒绝 + 显式白名单：网络出口、可访问路径、可调用工具、可写目录默认全关，按任务粒度临时授予；「先跑起来再收口」在 Agent 场景等于把提示注入直接变成远程执行。

隔离强度按副作用等级分层：只读检索可在进程内；生成图表/文件用容器；执行任意代码或访问客户数据用 microVM/gVisor 级隔离，并配合临时凭证与短 TTL。

沙箱是一次性的：一个任务一个沙箱，结束后销毁镜像层与临时卷；复用沙箱会积累状态，导致跨任务数据泄漏与行为不可复现。

可观测与可回放：每次执行记录 tool、args、退出码、资源用量、网络目标与文件变更摘要，进入轨迹（A33.01）与审计（C12.46）；无法回放的执行不允许进入生产。

策略四要素：identity（临时凭证）+ capability（工具白名单）+ resource（CPU/内存/时长/进程数）+ egress（域名/IP 白名单），由策略引擎按任务签发，沙箱启动时注入，超时自动回收。

Java 侧落点：业务服务不直接 spawn 进程，通过 ToolGateway 提交执行请求到隔离池；返回结构化结果（stdout 截断、产制品引用、退出码），不返回原始 shell 句柄；大文件与产制品走对象存储并带扫描。

提示注入防护联动：工具描述与检索内容视为不可信输入，执行前做参数域校验与二次确认；高风险动作（写库、转账、外发）强制人在环（A33.09），并在轨迹里留审批凭证。

量化基线：单任务 CPU ≤ 2 核、内存 ≤ 2GB、墙钟 ≤ 60s、出口域名白名单 ≤ 20 条、产制品大小 ≤ 50MB；超限即终止并记为策略命中，进入周度评审。

容器为什么不够？共享内核下面，内核漏洞或挂载配置错误可导致逃逸；microVM 用独立内核把攻击面收敛到 hypervisor，代价是冷启动与内存开销。按「任务副作用等级」选择隔离级别，比全站一刀切更经济。

沙箱与成本的关系：一次 Agent 任务可能拉起多个沙箱，冷启动与空闲占用会进入单位成本；按任务复用「预热池」时要保证池内实例在两次任务间完全重置，否则就是隐性状态泄漏。

复用长驻沙箱：上一任务写入的文件被下一任务读到，跨租户数据泄漏。

出口不设白名单：提示注入诱导工具把环境变量或客户数据发到外部地址。

只记 stdout 不记参数与网络目标：事后无法判断这次执行是否越界。

把隔离做成单点：某个工具绕过 ToolGateway 直连宿主机，整体边界立即失效。

向下回指：A10.04 / C12.28 / A08.04 / L03.08 / C12.46 / A33.01。本卡定执行边界与逃逸面；工具网关、审计、挂载与网络策略归所引卡。判据是所有工具调用是否强制经同一入口，只要存在一条直连宿主的路径，其余隔离在事故时都不构成边界。

站点已有成本与延迟的分散卡（C12.26、A22 组、A31.01），缺一张把它们与质量约束、缓存、路由、重试放在同一目标函数里的整合卡。生产里最贵的往往不是单价高的模型，而是重复上下文、无缓存、静默重试与不必要的大模型调用。

按 token 单价核算 → 上下文压缩与 prompt 缓存 → 语义缓存与结果复用 → 按任务难度路由多模型 → 成本 / 延迟 / 质量三目标联合优化与预算门禁。

单位业务成本才是目标函数：cost_per_resolved_task = 总 token 成本 ÷ 成功完成的任务数。为省钱切小模型导致重试与人工介入增加，分母下降会让单位成本反而上升。

延迟与成本常同源但不同向：更长的上下文同时推高成本与 TTFT；而批处理/缓存降本却可能拉长单请求延迟。优化前先声明要保哪一个 SLO（TTFT 还是总时长）。

重复是可优化的最大项：系统提示、检索片段、工具描述在每个请求里重复发送；prompt caching / 前缀缓存、语义缓存、去重检索通常比换供应商见效更快。

重试与 failover 必须计入同一账本：一次用户请求可能产生多次模型调用，成本按 taskId 聚合而非按 HTTP 请求聚合（C12.48），否则容量与成本都失真。

成本模型：input_tokens × p_in + cached_tokens × p_cache + output_tokens × p_out + 工具/沙箱成本，按 tenant / biz_tag / taskId 记账，单价带版本；缓存命中率、重试次数、降级次数进同一条记录。

路由分层：简单分类/抽取走小模型或规则；常规问答走默认别名；复杂推理与高风险决策走强模型并强制评测；按置信度或任务标签动态升级，升级必须在轨迹里留原因（A33.01）。

延迟预算：TTFT ≤ 2s 时优先控排队与上下文长度（C12.47 四段分解），TPOT 与总时长通过 max_tokens、流式输出与提前终止控制；把「用户已离开仍在生成」的取消语义做成默认行为，直接砍掉无效成本。

预算门禁：租户日预算、单任务成本上限、缓存命中率下限、重试率上限四项进告警；超限自动降级到低 max_tokens / 小模型，并通知 owner 而不是静默继续烧钱。

为什么「切到便宜模型」经常失败？因为便宜模型在工具调用格式、长上下文遵循上更易出错，一次格式错误触发的重试与回退会抹平差价；正确做法是按任务类型做 A/B + 单位完成成本对比，而不是全局替换别名。

语义缓存的风险：缓存键若只按文本相似度，会把不同租户/不同上下文的请求错误复用；缓存键必须包含 tenant、上下文版本、数据时间与安全等级，并设置 TTL 与 staleness 标注。

按 HTTP 请求记账：重试与 failover 成本被漏记，月底对不上账。

只看单价不看完成率：小模型返工率上升，单位完成成本反而更高。

缓存键不含上下文版本：用户拿到过期或串租户的答案。

用户取消后不 abort 推理：连接断了但 GPU 继续生成，产生纯浪费。

向下回指：C12.26 / A22.01 / A22.03 / A31.01 / K07.09 / C12.48 / C12.47。本卡定质量约束下的联合目标函数；单价、缓存、路由与重试的实现归所引卡。判据是按「完成一次有效任务」核算成本，若仍按单次调用报价排序，返工率高的小模型会被误判为更省。

站点 L03.20 已给人在环的目录式长卡，本题补组织与架构决策视角：哪些动作必须人工批准、审批点如何按风险分级、审批本身如何被观测与回放，以及怎样避免「所有步骤都要点确认」导致审批疲劳后被一键绕过。

全人工 → 全自动 → 高风险动作人工兜底 → 按风险分级 + 抽样复核 + 自动升级 → 审批决策本身进轨迹与评测，成为可治理的控制面。

审批点是风险函数不是流程习惯：判据应为「动作可逆性 × 影响面 × 信息不确定度」。写库/转账/外发/删除/权限变更属不可逆高影响，必须审批；只读检索、格式转换通常不需要。

审批要带上下文包：审批人必须看到任务目标、拟执行动作、参数、依据片段、成本估算与可撤销性；只弹一个「是否继续」等于让人盲签，责任无法真正落地。

审批本身是可观测事件：谁、何时、看了什么、改了什么、超时如何处理都要进轨迹与审计（A33.01 / C12.46）；超时默认拒绝而非默认放行。

抽样复核防止疲劳：低风险路径用事后抽样复审 + 异常自动升级，而不是全量前置审批；高风险路径保持强制前置，两类比例随事故率动态调整。

风险分级表：R0 只读（自动）；R1 可逆写入（自动 + 抽样 5% 复核）；R2 对外可见或产生费用（前置审批 + 成本上限）；R3 不可逆/合规相关（双人审批 + 决策留痕 + 可回放）。分级由平台策略引擎按动作类型判定，业务不得自行降级。

Java 落点：ToolGateway 在执行前查策略，命中 R2/R3 时把任务置为 WAITING_APPROVAL 并持久化（复用 C12.47 状态机），审批通过后凭审批凭证恢复；超时按 SLA 自动拒绝并记录原因。

度量四项：审批平均等待时长、超时拒绝率、审批后动作失败率、抽样复审发现的违规率。若等待时长持续上升而违规率不变，说明审批点设得过多，应下调分级而非加人。

与组织治理衔接：审批权限与值班表绑定、定期轮岗与复核；审计可按人/按动作反查全部决策，满足受监管行业的「决策可解释」（C12.46）。

为什么「默认放行」的超时策略危险？它把时间压力转化为隐性授权，攻击者可以故意在审批人离线窗口触发高风险动作；正确做法是超时拒绝 + 自动升级到备份审批人 + 全程留痕。

人在环与自动化的边界会随能力演进移动：应把「过去 N 次人工审批中被改动的比例」作为下调风险等级的证据，用数据驱动分级调整，而不是一次性设定后永不复审。

所有工具调用都要点确认：审批疲劳后团队用共享账号一键通过，控制彻底失效。

审批弹窗不带参数与依据：审批人无法判断风险，签字变成形式。

超时默认放行：形成可被利用的固定时间窗口。

审批记录不进轨迹：事后无法解释「当时为什么批准」，合规审查不通过。

向下回指：L03.20 / A26.02 / G10.03 / C12.46 / A33.07 / A33.01。本卡定审批点分级与失效判据；审批界面、轨迹记录、组织流程归所引卡。判据是超时分支默认拒绝且写进轨迹，若默认放行，审批会退化成一个可被定时利用的固定窗口。