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

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

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

两条标志性工程证据（模型均未更换）：其一，某编码评测仅替换文件编辑接口（Harness 的一层），模型得分从 6.7% 升至 68.3%；其二，某框架团队仅优化文档组织、验证机制与执行追踪，同一模型在终端基准上从第 30 名升至第 5 名（52.8% → 66.5%）。这说明 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 自治循环（无人值守 + 并行 + 自修复）。

• 把 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 类范式的常态而非意外。
• 执行方差治理：同输入多次执行结果不一致是模型本性，需靠上下文工程压输入噪声 + 评估闭环压输出方差（见 A.6），而非指望模型「下次稳定」。
• 单 / 多 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 只在动态决策环节叠加。平台侧同步进化：Dify / RuoYi AI / JEECG 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，且权限隔离仍需应用层——窗口扩大不解决任何治理问题。

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

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

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

短期记忆控制三法（与上下文工程同源）：

• 上下文缩减：滑动窗口丢弃最早 N 轮，或用轻量模型压缩历史为摘要；适合闲聊型多轮，不适合需早期决策依据的任务。
• 上下文卸载：重型结果（大文件、长日志）放外部临时存储，窗口内只留 UUID / 路径引用；读取设超时与大小上限，超限返回截断或降级。
• 上下文隔离：主 Agent 只向子任务交付「任务说明 + 必要片段」，不全量广播；子 Agent 结果以摘要回传。

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

• 如何量化「腐化程度」？固定任务集在窗口利用率 20%/40%/60%/80% 分档重放，观测任务成功率与幻觉率拐点——拐点即该模型该任务的压缩阈值；不同模型、不同任务拐点不同，故无普适数字。
• 压缩与重置如何选？连续协作（上下文强相关）选压缩；阶段切换（任务已完结）选重置 + 结构化交接文档（保留目标、已决策、未解决问题）。
• 为什么「清理已完成工具结果」安全？因为工具调用记录（tool_use）保留了「做过什么」的证据链，清除的只是占空间的返回体（tool_result），需要时可凭引用重查。

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

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

从「对话历史」到「记忆系统」：早期仅滑动窗口存对话；随后向量库存语义片段；再演进到产品化分层——Mem0（ADD-only + 多信号融合检索）、Letta/MemGPT（OS 式虚拟内存分页，Main↔External 动态交换）、Zep（时间感知三层子图 + 边失效）、MemOS（记忆立方体：纯文本 ↔ 激活记忆 KV Cache ↔ 参数记忆 LoRA 动态流转）。演进主线：从「存取文本」走向「管理有生命周期的知识资产」。

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

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

生命周期六环节的工程实现：编码（LLM 抽取事实三元组 / 生成摘要）→ 存储（向量 + 图 + 关系）→ 提取（向量检索 + BM25 + 图遍历多路召回）→ 巩固（对话摘要归并实体库）→ 反思（任务后异步提取元知识 / 教训）→ 遗忘（score = relevance × importance × decay(t)，decay 为指数衰减，实际在重排阶段实时应用）。

• 写入链路：对话后异步 LLM 语义提纯（Best-Effort）；幂等 Key 用 sourceId + batchId 而非文本哈希（温度与微调会导致字面不同）；并发写用乐观锁 / MVCC。
• 检索链路：新 Session 开始向量化 Query 取回，prepend 进系统提示或平行 slot；向量库 P99 直接吃 TTFT——用 Redis 预热、浅层画像全量预载、检索与生成重叠执行来压等待感。
• 存储三层架构：VectorStore（选型看索引 HNSW / IVF / DiskANN、预过滤 / 后过滤、多租户隔离粒度、一致性、成本）+ GraphStore（实体关系图谱，支撑多跳推理）+ Reranker（交叉编码器二次精排）。
• 遗忘与冲突：新事实写入时标记旧边失效 + 时间戳，定期 Vacuum 重建索引（软删除会破坏 HNSW 连通性）。
• 轻量替代：少量明确结构化的偏好 / 规范，用 Markdown 文件（如 AGENTS.md）+ Git 版本化，零迁移成本、透明可审计；与向量库边界——少量结构化走 Markdown，大量非结构化语义召回走向量，两者可并存。

• 长期记忆 vs RAG 的职责边界？技术栈相似（向量 + 语义检索），但 RAG 服务共享知识源（规章 / 文档 / 实时库，可按租户过滤但非个性化），长期记忆管理特定用户的个性化经验。可分开召回再统一排序：长期实体可扩展 RAG 查询词，用户偏好可参与重排。
• 为什么幂等 Key 不用文本哈希？同一事实两次表述字面不同（温度采样 / 模型升级），文本哈希判重必失效；用业务侧 sourceId + batchId 才能保证「不重写、不漏写」。
• 检索链路优化次序？先修检索链路（看 Trace：query 改写 / 过滤 / 候选集 / 重排打分），再扩写入规模——写入越多检索质量越差时，扩容只会放大问题。
• 自我反思闭环？任务后异步复盘提炼教训（源于 Generative Agents 的「睡眠记忆巩固」）；高风险操作后触发细粒度核对（事实 / 验收 / 数据缺口），不通过则退回补齐。

• 短期与长期记忆混存一库：检索时任务上下文与历史偏好互相污染；必须物理 / 逻辑分离并分别设 TTL。
• 只写不清：无遗忘机制与冲突标记，记忆库膨胀后陈旧事实压过新事实——「用户换了团队」被三个月前的旧记忆覆盖。
• 多租户检索不带硬过滤：A 租户检索命中 B 租户记忆是 P0 事故；检索层必须带 UserID / 组织 / 时间 / 业务标签硬过滤，高活跃租户独立 Collection 物理隔离。
• 记忆写入走同步链路：LLM 提纯耗时且可能失败，同步写会拖垮响应；应异步 + 失败重投 + 幂等。

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

三阶段演进：Naive RAG（切块 → Embedding → TopK → 生成，Demo 级）→ Advanced RAG（Query 改写 / HyDE → 混合检索 → 重排 → 上下文压缩）→ Modular RAG（检索器 / 重排器 / 压缩器 / 路由器 / 生成器可插拔，面向生产与 Agent）。并行地，Embedding 模型从 Word2Vec → BERT → BGE-M3 → 第四代 LLM-based 嵌入（2025 年中英文 SOTA 一代）持续升级。

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，支持异步长任务）。Skills 则由 Claude Code 等实践沉淀为「声明式任务说明」形态（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；意图（模型产物）与执行（宿主程序）分离，正是权限校验的插入点。

• 把 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 版规范进一步固化安全与传输语义；2026-07-28 版做无状态化重构（远程部署可横向扩展）——SDK 版本与规范版本需配对核对（如 Spring AI 2.0 随附 MCP Java SDK 2.0 对标 2025-11-25 版）。

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

从串行链到图编排：初期多 Agent 就是「A 调 B 调 C」串行链——慢、无存档、难暂停审批、难表达复杂分工。LangGraph（2024）把「图」显式化（StateGraph + 条件边 + 持久化）；Spring AI Alibaba 对齐同一套概念（OverAllState + KeyStrategyFactory + addConditionalEdges + MemorySaver/RedisSaver 持久化 + interruptBefore 人机协同）。Claude Code 的 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 都拿到全部中间产物，上下文爆炸且互相干扰；只交「任务说明 + 必要片段 + 结论摘要 + 引用 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 的控制在模型手 unnatural，易震荡——所以工程上倾向把迭代显式建模为 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 条真实轨迹小评测集把「猜」变「看」，再逐步扩分层覆盖。

• 为什么代理指标会「说谎」？满意反馈率受用户习惯影响、转人工率受分流策略影响；代理指标只能作辅助信号，主判据必须回到任务成功率与质量指标。
• 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：回归挂了却无法定位根因层，评测沦为「红绿灯」而非「诊断仪」。

这道题考察的是 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 归一化 + 鉴权 + 幂等；ToolCallingAdvisor 控预算 / 阻断。
• AOP 审计切面：工具执行统一过注解切面，审计逻辑与业务代码解耦，防「新增工具忘埋审计」。

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

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

这道题考察的是 Spring AI 安全层组件与大模型网关的架构定位：Spring AI 的 ToolCallbackResolver / ToolCallingManager / ToolCallingAdvisor 各自承担什么安全职责？大模型网关（API 网关能力 + 模型调用控制面）为什么「Router 只选模型，Gateway 管整次调用全生命周期」？其六项核心能力与自研组件清单、演进顺序（先工程治理再智能路由）是什么。

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

Spring AI 安全层三组件：

• ToolCallbackResolver：解析工具时的准入守门——按当前身份过滤可见工具集，未授权工具名直接拒绝（工具白名单的代码化）。
• ToolCallingManager：工具执行统一入口——参数归一化 + 鉴权 + 幂等，执行逻辑不散落在业务代码。
• ToolCallingAdvisor：调用链拦截——预算控制（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 配额不释放，额度「越用越少」直至误杀正常请求；对账任务是预算流闭环的必要环节。

与 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 节点）。

四组件的工程要点：

• LLM 选型三要素：推理能力（核心决策用强模型，简单任务用小模型）、工具调用稳定性（JSON 格式老出错 → 生产大量重试与 Token 浪费）、上下文窗口（十几步任务每步工具返回都塞上下文）。
• System Prompt = 岗位说明书：定义角色、行为边界、输出格式；工程中调优常占开发时间相当大比例，是控制 Agent 行为最直接的手段。
• 工具设计四原则：职责单一（一个工具只做一件事）；描述精确（「查询公司内部销售数据库，支持按日期和产品类别筛选」远胜「查询数据」）；错误信息可操作（「参数 city 不能为空」能帮模型自纠重试，「Error code 400」不能）；参数简洁（能少传就少传，填得越多错得越多）。
• 记忆三子类型：语义（事实）/ 情节（事件经历）/ 程序（SOP）——按类型分库存，检索时精准查对应库；衰减分数 = 语义相似度 × 时间衰减因子，衰减速度按业务调整（客服快、法律合规慢）。

三层结构判据：关键不是节点是什么类型，而是控制流由谁掌握——这一条同时解释了为什么 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。
• 任务全勾但整体不对：局部通过 ≠ 整体正确；必须有真实联调与总需求回归两个收尾任务。

这道题考察的是 记忆系统三大框架的选型对比：Mem0（独立记忆服务层，add/search 两接口）、Letta/MemGPT（OS 式内存分层，Agent 自管三层记忆）、Zep/Graphiti（时间感知，时序知识图谱管生命周期）各自的核心思路与适用场景是什么？以及知识图谱增强记忆如何补向量检索的短板（多跳推理）、「记忆整合」四步（去重 / 冲突消解 / 抽象提炼）如何从碎片到知识。

三条技术路线并行成熟：Mem0（5w+ star）走「记忆即服务」——管理逻辑全包，应用只调 add / search；Letta（MemGPT 系）走「记忆即 OS」——Core（常在上下文）/ Recall（最近历史）/ Archival（长期归档）三层分页，Agent 自己用工具管理；Zep / Graphiti 走「记忆即图谱」——每条记忆标有效时间窗口，时序知识图谱自动识别过时记忆。选型分歧的本质是：记忆管理的复杂度放在平台侧、Agent 侧还是数据模型侧。

选型对照：

图增强记忆的第一性：向量检索「一条一条」存取、记忆间无关联——「用户 A 所在公司做什么业务」这类问题中「用户 A」与「云计算」文本语义不相近，向量命不中；三元组（实体 → 关系 → 实体）+ 多跳推理补足关系链。配合方式：向量库管模糊语义、图谱管精确关系；对话中由 LLM 自动提取实体关系入图。

• 长期记忆存储工程：存时「内容转向量 + 原文 + metadata 标签（时间 / 任务类型 / 重要程度 / 记忆类型）」一起存；取时查询向量（同一 embedding 模型）相似检索 + ANN 索引（HNSW / IVF）加速。
• 粒度裁决：太细 → 碎片化（完整偏好拆四条只命中两条）；太粗 → 噪音（两千 token 里相关只有一百）；合理粒度 = 一次完整交互 或 一个独立知识点。
• 「读 → 用 → 写」闭环：任务前主动检索（任务描述 → 长期记忆 → 注入 system prompt）；执行中「查记忆」封装成 Tool 按需检索；任务后写入（新偏好更新实体记忆、有价值结论摘要入向量库）。
• 记忆整合四步：去重（语义相近合并）→ 冲突消解（保留时间新的，时间戳是关键）→ 抽象提炼（情节记忆 → 语义记忆：多次「动态渲染 requests 失败」经历 → 「有动态渲染时用浏览器自动化」的通用规律）→ 分层节奏（任务后轻量去重 + 定期深度提炼）。

• 「这次答对」和「下次少犯错」为什么是两件事？纠正留在上一段对话里，模型参数没更新，新会话读不到——经验必须存到任务外（向量库 / 记忆服务）并在下次决策前检索注入，才构成学习闭环。
• 四层记忆（感知 / 短期 / 长期 / 实体；Letta 的 OS「三层」是另一套计数）与三工程问题？存什么（事实 / 偏好 / 教训分型）、怎么存（向量 + metadata + 图谱边）、何时取（任务前预载 / 执行中按需 / 冲突时裁决）——只答「长短两分」是经典不完整答案。
• 图谱记忆的成本边界？实体抽取与关系抽取每次对话都要调 LLM；低价值对话不上图，按对话重要性 / 实体密度触发抽取。

• 长期记忆「存数据库靠关键词搜索」：错。必须 Embedding + 向量库语义检索（问「代码习惯」能命中存的「Python 风格偏好」）。
• 以为粒度越细越好：碎片化导致召回失全；粒度按「完整交互 / 独立知识点」裁决。
• 无冲突消解直接追加：旧偏好压过新偏好（用户换了团队仍被按旧团队画像服务）；时间戳 + 保留最新是底线。
• 选框架只看 star 数：Mem0 省心但黑盒策略、Letta 灵活但要自己管、Zep 强在时态但引入图谱运维——按「谁管理忆复杂度」与团队运维能力选。

这道题考察的是 上下文压缩的预算公式与状态管理四层：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（反思 + 失败经验入记忆）带来多少提升（有文献报 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）。

这道题考察的是 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 与版本，文档判误时可快速定位传播范围。

• 改文档后旧答案还在：僵尸 chunk；先删后增，删除操作清所有关联 chunk。
• 尝试「局部更新 chunk」：切割边界全变无法对应；永远先删后重新入库。
• 新制度发布即覆盖地区细则：只比发布时间不看适用范围；先适用性的三段裁决顺序。
• 群聊传闻盖过正式制度：相似度最高当选；权威度排序 + 来源注册表。
• 靠用户投诉评估效果：不投诉 ≠ 好（可能直接不用了）；Hit@K + RAGAS 离线 + 线上指标闭环。

这道题考察的是 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 混用。
• 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 单端点 → 2026-07-28 无状态化的演进脉络与动机？stdio 与 Streamable HTTP 的选型判据、以及「消息格式（JSON-RPC 2.0）与传输层解耦」意味着什么。与 A04.02 的理论层互补，本卡聚焦版本与传输的工程细节。

传输演进三阶段：2024-11 初版（双端点：HTTP 请求 + SSE 推送分离）→ 2025-03（合并为单端点 Streamable HTTP，旧方案 deprecated——短请求普通响应、长请求 SSE 流）→ 2026-07-28（无状态化重构：移除握手与 HTTP 会话、请求 _meta 带版本——远程部署可横向扩展，代价是失去双向会话语义）。工程铁律：接入前核对「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 分开处理。
• 版本兼容：接入前查双方支持版本（server/discover）；批量请求 JSON-RPC 2.0 支持但 MCP 2025-06-18 规范已移除——判断功能看 MCP 规范，不只看底层消息格式。
• 安全边界：授权围绕具体操作和数据设计（不按「Tools 高危 / Resources 开放」一刀切）；Server 返回的文档 / 工具说明 / 模板也可能含不可信内容——不能因来自 MCP Server 就当高优先级指令（注入面）。

• 为什么 2026-07 版要无状态化？会话粘滞（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 → completed / failed / canceled，支持异步长任务与 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 → completed / failed / canceled，支持异步长任务；产物以 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 装很多启动就爆上下文：全量加载正文；渐进式三层。

这道题考察的是 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 知道所有代码——「能访问文件 ≠ 已拿到文件内容」；按任务选材料并确认实际获得。
• 拿上月设计文档当事实：过期材料；回当前源码（含未提交修改）核对。
• 原型直接当交付：临时实现未核；探索 → 交付转换时整理确认行为。

这道题考察的是 任务拆分（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（代码框架，精细控制）/ Claude Code 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）；Claude Code 免框架玩法——subagent 文件 = 节点、hook = 强制检查、workflow = 调度脚本；/deep-research 即投产的 graph 工作流（拆解 → 并行搜索 → 抓取 → 验证 → 综合）。
• 失败模式对照：上下文焦虑（模型误判窗口将尽就着急收尾）→ context reset + 状态外化；自评永远乐观 → 三角分工 Planner / Generator / Evaluator，验收方必须摸到真实世界；Ralph Wiggum loop（无客观 gate 的空转）→ 硬性 stop + 独立判定。

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

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

这道题考察的是 Java 平台级 AI 方案的双极对照与选型判断：RuoYi AI（企业级 AI 助手平台，一站式开箱即用）与 JEECG AI（业内 Java 版开源 AI 应用平台，企业级 Dify 替代，低代码 + AIGC 融合）的定位差异是什么？各自最适合什么场景（从 0 搭 AI 平台 vs 给既有业务系统插 AI）？核心在于把「平台路线」与「自研路线」放进同一条光谱，而非当作非此即彼。

两条路线的光谱定位：从零自研工程化（Ragent / Nexus 范式——自己写分层、检索融合、模型容错、全链路观测，适合 AI 能力是差异化竞争力的团队）⇄ 平台 / 低代码交付（RuoYi AI / JEECG AI——现成底座可视化配置，快速把 AI 嵌进既有 Java 业务，适合 AI 是「增强项」的场景）。平台把 RAG、工具 / MCP、上下文、多智能体、治理封装成产品功能，让非算法工程师也能交付 AI 应用。

双平台画像：RuoYi AI——MIT 协议、Spring Boot 3.4/3.5 + Spring AI + LangChain4j、MySQL + Redis + 向量库（Milvus / Weaviate / Qdrant 解耦可换）、Sa-Token + JWT RBAC、2 核 2G 轻量服务器可跑；独特能力是 LangChain4j Supervisor 多智能体、技能管理（docx/pdf/xlsx + Coding Harness 真实执行链路区分）、数字人 / 绘画 / PPT 多模态。JEECG AI——Apache-2.0 / 商业双轨、JeecgBoot 低代码底座、Spring Cloud Alibaba 微服务（Nacos / Gateway / Sentinel / SkyWalking）、信创六类数据库（达梦 / 人大金仓）；独特能力是高保真文档导入（含图 Markdown / PDF 格式图片还原——Dify 的短板）、AI 流程即服务（编排封装为外部 API）、iframe 一键嵌入老系统。

逐维能力对照：

对应关系的价值：两个平台不是黑盒——其内部实现正好印证工程原理（RAG 全链路、MCP 即插即用、Supervisor 编排、Sa-Token 治理与自研范式同构）。懂理论 + 看过自研实现，再看平台就能「一眼看穿按钮背后的工程」——这是平台视角的学习杠杆。

• 选平台当：AI 是业务增强项而非核心壁垒；需要周级上线快速验证；团队无专职 AI 工程；强需求是嵌入既有 Java 业务系统；有私有化 / 信创合规要求。
• 典型姿势：知识库问答 / 内部助手选 RuoYi AI（开箱 + 多模态 + 技能管理）；给 ERP / CRM / OA 智能化选 JEECG AI（低代码 + iframe 嵌入 + 流程即服务）。
• 平台测试纪律（差异化价值点）：平台普遍把评测产品化为「问答效果配置」（命中率 / 相关度阈值可视化）而非 CI 门禁——AI 质量左移不足；Java 工程背景团队应把 Golden Set 入库即回归、Testcontainers 锁关键路径、MCP 工具契约当单测、防死循环专项用例、压测验证限流排队这五条纪律带进平台项目。
• 结论口径：平台做「评测入口」，工程化做「评测纪律」；生产可用必须二者结合。

• 为什么「平台内部如何落实概念」比「会用按钮」更有价值？平台版本迭代快、功能按钮会变，但其背后的 RAG 管线 / 编排模式 / 治理结构不变——理解工程结构才能评估平台边界、做二开与迁移决策。
• JEECG 对比 Dify 的三大独有能力为何重要？高保真文档（格式 / 图片不丢）、低代码流程引擎（可调系统接口与业务逻辑）、强业务集成（Java 栈对接 ERP / CRM）——正好命中「企业既有系统智能化」这一最大存量需求；Dify 是独立 LLM 应用平台（Python + React），集成姿态不同。
• 混合策略为何最常见？平台做 MVP / 内部工具 / 知识库问答快速验证价值；验证过的核心差异化能力逐步自研迁移——平台负责「广」，自研负责「深」。

• 平台版本号当真源：平台演进快（Spring Boot 3.x vs 4、向量库选型），具体版本以官方文档实时为准，不照搬资料。
• 把平台评测配置当质量保障：命中率阈值可视化 ≠ CI 回归门禁；模型或切片策略升级后回归无人发现。
• 信创需求选错平台：达梦 / 金仓适配是硬需求时选型必须先验证（JEECG 六库 vs RuoYi MySQL 为主）。
• 平台二开低估成本：深度定制受平台抽象边界限制，「平台耦合 / 二开成本」是长期成本评估项，不只看上线速度。

这道题考察的是 平台 vs 自研的决策树与 Ragent / Nexus 模块划分：什么时候选平台（天~周上线 / 可控性中 / 0→1 验证）、什么时候自研（月~季 / 全栈可控 / 1→N 规模化）？需求形态判定（Workflow vs Agentic）的四个维度如何打分？Ragent 7 模块与 Nexus 6 模块的分层意图是什么——为什么「切换模型 / 向量库 / 对象存储时核心问答流程不重写」是架构的第一验收标准。

决策树先判形态再判路线：第一步判 Workflow 还是 Agentic——任务边界明确可枚举、可控性要求高（金融 / 合规）、路径需可审计 → Workflow（Ragent v1）；任务开放需规划、多步操作工具调用 → Agentic（Ragent v2 / Nexus）。第二步判平台还是自研——上线速度 / 可控性 / 定制深度 / 团队门槛 / 长期成本 / 适合阶段（0→1 vs 1→N）六项对照。

对照速查：

Ragent 7 模块：bootstrap（装配）/ framework（统一响应·幂等·MQ·SSE·跨节点流式取消）/ infra-ai（模型客户端·档位·路由·首包探测·降级）/ system（认证·审计）/ rag（问答·知识库·入库 Pipeline·意图树·检索·会话）/ agent（AgentScope ReAct·MCP·技能·记忆·人工确认）/ mcp-server（独立工具服务）。

Nexus 6 模块：用户入口 / 前置编排中心 / 三层执行器 / 知识底座 / 混合检索 / 工程化护栏。Java 企业级 AI 普遍采用模块化单体（非微服务拆分 AI 能力），以隔离「业务编排 / AI 供应商差异 / 通用基础设施」。

• Nexus 确定性前置经验：把「路由判定 / 问题改写 / 子问题拆分 / 知识域收缩 / 歧义检测」等确定性决策前置到编排中心，模型只做生成——显著降低不确定性，是 Java 工程化控制风险的利器。
• 框架选型：Spring AI（Spring 生态官方抽象，新项目首选）/ LangChain4j（链式编排风格）/ AgentScope Java（多智能体 + MCP 工具发现，Ragent agent 模块基于此）/ 自研编排（极致可控）。选型原则：先用 Spring AI 收口模型调用；多供应商快速接入看 LiteLLM；已有 Kong 看 Kong AI Gateway；先工程治理，再智能路由。
• 原型验证（内存起步）：Spring Boot 3.x + Spring AI + 内存 VectorStore（SimpleVectorStore）→ 一条 RAG 链路跑通（文档 → 切分 → Embedding → 检索 → 拼装 → SSE 流式返回）→ 引入一个本地 MCP 工具验证调用闭环 → 再替换生产向量库 / 模型档位 / 加 Trace 与限流。避免过早引入重量依赖。
• 分层意图的验收：切换模型（ChatClient / EmbeddingClient / RerankClient 候选路由）、向量库（VectorStore 配置切换）、对象存储时，核心问答流程不重写——靠接口 + 注册表 + 配置隔离实现。

• 为什么 Java 侧倾向模块化单体而非微服务拆 AI 能力？AI 能力的迭代在模块内（模型客户端 / 检索管线），拆微服务徒增跨服务事务与运维；Java 侧核心价值在权限 / 事务 / 中间件融合与可控可审计——模块化单体 + 清晰接口即可达成隔离目标。
• Java 栈与 Python 栈的阶段 1 差异？Python 侧多服务、算法优先、脚本即跑迭代快；Java 侧模块化单体、业务优先、需 Spring 装配略慢但更贴近生产——两条路线复用同一套理论底座（Agent 本质 / 多 Agent 编排）。
• 「混合策略」的迁移路径？平台验证 → 识别核心差异化能力（如特定领域检索融合 / 容错策略）→ 按模块自研迁移（mcp-server / rag 检索先行的拆分最适合渐进迁移）。

• 需求形态误判：金融合规场景上了全自主 Agentic（路径不可审计）；开放多步任务上了写死 Workflow（能力天花板锁死）——第一步先做形态判定。
• 过早微服务化：AI 能力还在快速迭代就拆服务，接口反复变动；模块化单体先行。
• 原型直接上重量依赖：第一天就接生产向量库 / 多档位路由，验证周期失控；内存起步、逐步替换。
• 忽视 1.x → 2.x API 变化：Spring AI 版本演进快，升级前先核对迁移清单。

这道题考察的是 平台源码包结构与自研模块的逐包映射：RuoYi AI 的 ruoyi-chat 核心包（agent / mcp / service / controller / observability / factory / mapper）与 Ragent 五模块如何一一对应？JEECG 的 jeecg-boot-module-airag 双层架构（llm 能力层 + app 应用层）如何表达「AI 供应商隔离 vs 业务编排」？核心结论：平台包结构 ≈ 自研分层表的产品化。

从功能对照到源码实证：功能层对照回答「平台能做什么」；源码层对照回答「平台的每一块能力对应自研架构的哪一环」。RuoYi AI Maven 多模块：ruoyi-admin（管理后台 / 启动入口）+ ruoyi-common（通用）+ ruoyi-extend（monitor-admin 监控、snailjob-server 任务调度重试）+ ruoyi-modules（chat 核心 / aiflow 流程 / workflow 引擎 / system 权限 / generator 代码生成）。JEECG AI 能力集中在 jeecg-boot-module-airag：llm 层（controller / service / handler【AIChatHandler 模型适配引擎 + EmbeddingHandler 向量化】/ document 高保真文档处理）+ app 层（聊天 / 知识库查询接口，REST + SSE）。

逐包对照矩阵（节选）：

结构等价性：Ragent 用 agent/rag/mcp/system/bootstrap 五个 Maven 模块表达的边界，RuoYi 用 ruoyi-chat 内的子包同样表达；JEECG 用 llm / app 双层表达同样的「供应商隔离 vs 业务编排」——同一套理论概念在不同代码组织下收敛。

• 读平台源码的三个入口：① 编排入口（RuoYi agent 包看 Supervisor 如何编排多角色）；② 供应商隔离（JEECG AIChatHandler 看模型方言适配）；③ 状态外化（RuoYi domain + mapper 看会话与记忆如何持久化）——三处看完即掌握平台骨架。
• 二开定位法：定制需求先映射到包（加新工具 → mcp 包；改检索策略 → service 包；加观测指标 → observability 包），评估改动是否跨包边界——跨得越多，二开成本与升级冲突风险越大。
• 重试与调度护栏：RuoYi 用 SnailJob 兜底重试（对应自研的 RocketMQ 事务 + 幂等 + 分布式锁状态机）——平台「有重试」与自研「有事务一致性」的深度差异在此可见。

• 为什么「平台省了什么、自研强在哪」要看包结构才能看清？功能清单看不出深度——如 RuoYi 的 workflow 引擎与 Ragent v1 Workflow 等价（路径写死），但公平排队 / 事务一致性 / 证据短路这些深度能力在包结构中明显缺位。
• factory 包的存在说明了什么？意图树 / 分块策略 / 回调对象的工厂化创建——平台也沉淀了设计模式，但隐式使用、无显式范式文档；自研的价值之一是把经验提炼为可复用规范。
• 采集实证的严谨性？目录树经 GitHub API 实拉取（非文档转述），版本演进快，具体包名 / 版本以官方仓库实时为准——源码级结论必须标采集时间。

• 用功能清单替代源码评估：选型只看官网功能矩阵，二开时才发现深度缺位；关键能力（排队 / 事务 / 观测）必须看源码实证。
• 跨包边界大改：二开改动横跨 agent / service / mapper 多包，平台升级即冲突；定制尽量收敛在扩展点。
• 忽视平台自身的护栏深度：SnailJob 重试 ≠ RocketMQ 事务消息的「恰好一次」语义；一致性要求高的入库流水线需自建。

与 A16.04 的边界：11 种模式清单以 A16.04 为登记处；本卡只保留产品化相对自研的差异（公平排队 / 事务 / 证据短路）。

这道题考察的是 产品化与自研的深度差异及 Ragent 11 种设计模式：公平排队（Redis ZSET + Lua 原子抢占 + 过期信号量 + Pub/Sub 唤醒）、分块事务一致性（RocketMQ 事务消息 + 幂等 + 状态机）、前置编排 + 证据短路、影子路由优化闭环——这四项为什么是「平台做不到或做不深」的护城河？11 种设计模式（策略 / 工厂 / 模板方法 / 注册表 / 装饰器 / 责任链 / 中间件 / 适配器 / 状态机 / 事件回调 / AOP）如何各自对应具体 AI 工程问题。核心命题：「调 API ≠ 生产级 Agent」。

四大深度能力的产品化缺口：① 模型流量保护——平台一般靠网关限流，少有「按会话公平排队」（突发流量下单会话即可打爆模型）；② 分块事务一致性——平台用调度兜底重试，自研用事务消息保障海量分块「恰好一次」；③ 前置编排 + 证据短路——平台多为单一对话链路，Nexus 三层执行器（歧义追问 → 知识问答 → 开放式 Agent）在架构层杜绝幻觉；④ 影子路由——平台少有 A/B 影子对比，Nexus 静默对比命中率 / 置信度 / 候选排名形成上线即回归的闭环。

Ragent 11 种设计模式 → Java AI 工程规范：

价值主张：每个模式对应一个具体问题（技术沟通中可展开）——设计模式不是清单背诵，而是「Java 工程经验向 AI 场景的平移」。

• 公平排队工程细节：Redis ZSET 按入队时间排序 + Lua 脚本原子抢占（防超发）+ 过期信号量回收僵尸会话 + Pub/Sub 唤醒队首——模型调用是昂贵资源，必须限并发且保公平。
• 事务一致工程细节：RocketMQ 事务消息（半消息 + 本地事务 + 回查）保障「分块任务要么全做要么不做」；幂等键防重；远程刷新 = 分布式锁 + 状态机（防并发重复刷新、防刷新中脏读）。
• 证据短路：检索无证据时直接告知用户「知识库中暂无相关内容」——架构层杜绝编造，比生成后校验便宜且可靠。
• 四大常见误区（自查清单）：① 调 API ≠ 会 RAG / Agent；② RAG ≠ 检索 + 生成（每环都有坑）；③ 接框架 / MCP ≠ 企业级（增量更新 / 多租户 / 风控 / 可观测缺一不可）；④ 只关注模型忽略工程（检索策略 / 分块 / 上下文管理决定效果）。

• 为什么「证据短路」优于「生成后校验」？生成后校验要烧一次生成成本且只能事后拦截；证据短路在编排层直接短路返回，零模型成本、零幻觉出口——把「不说错」变成「结构上不能错」。
• 影子路由为什么是 Java 特色？它复用了灰度 / 流量镜像的成熟工程范式：真实流量下新旧路由静默双跑，对比指标无感切换——AI 时代的「上线即回归」。
• 「调 API ≠ 生产级 Agent」的完整展开？生产级 = 分块策略 + 查询改写 + 混合检索 + 模型容错 + 流量保护 + 可观测 + 治理审计——工程细节才是双护城河（生产稳定性与候选人区分度）。

• 限流当流量保护：网关限流只保「不被打死」，不保「公平」——单会话可占满全部并发；公平排队是并发治理不是限流。
• 分块入库无事务：百万文档分块「做一半」无回滚；事务消息 + 幂等 + 状态机三件套。
• 设计模式当背诵清单：答不出每个模式对应的 AI 工程问题即无效；逐模式配问题记忆。
• 平台功能照抄当自研方案：平台的「重试兜底」语义与自研事务一致性不等价；按一致性需求选实现深度。

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

从直连 SDK 到抽象路由：早期业务直连各家 SDK（模型名写死、切换重写）；Spring AI 以 ChatModel / ChatClient 抽象 + 自动配置统一接入（Mistral / Ollama / OpenAI 等），多供应商路由（chat-multiple-providers 范式）按档位 / 成本 / 可用性运行时切换——与理论层 1.3 档位路由、Ragent infra-ai 首包探测 / 三态熔断同构。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 抽象解决「怎么调统一」，Ragent 式首包探测 / 三态熔断解决「调不稳怎么办」——两者叠加才是生产级供应商隔离。
• 组件全景对照：Prompts（模板）/ Tool Calling（Java 方法暴露为工具）/ Memory（四实现）/ RAG（三种流变）/ Observability（Micrometer）/ Guardrails / MCP——每个能力点都有官方参考实现可抄。

• 为什么「绑定 tier 而非模型名」是路由的关键设计？业务代码引用「tier-standard」，路由层决定 tier 内具体模型——降级 / 灰度 / 换供应商不改业务代码；引用具体模型名则每次调整都是一次发版。
• BeanOutputConverter 与手写 JSON Prompt 的差异？Converter 保证 Schema 与目标类型同步演进（改字段即改提示），手写 Prompt 与代码必然漂移；这是「契约即代码」。
• 结构化输出失败的自纠正循环怎么搭？校验失败 → 错误信息回喂模型重试（有界）→ 仍失败降级（默认值 / 转人工）；与工具调用循环共用 Advisor 机制。

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

这道题考察的是 Spring AI 记忆四实现与 Tool Calling 生产范式：Basic / JDBC / Spring Security / Vector Store 四种记忆持久化各自适用什么场景（原型 / 跨重启会话 / 多租户隔离 / 语义召回）？把 Java 方法暴露为 LLM 工具（Mistral / Ollama / OpenAI 三套实现）的生产要点是什么？记忆四实现与理论层记忆分层（短期 / 长期）、多租户体系的映射关系。

记忆实现的工程化谱系：Basic（内存会话——原型 / 单实例）→ JDBC（关系库持久化——跨重启会话、对接既有 DB）→ Spring Security（多租户隔离记忆——按认证身份分区，对齐 OAuth2 / JWT 多租户体系）→ Vector Store（语义召回记忆——记忆即检索）。四实现是「同一抽象接口 + 不同存储后端」的教科书式落地，对应理论层 1.2 的短期（会话）与长期（向量库）二分。

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

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

• 为什么「多租户记忆隔离」要用 Spring Security 实现？记忆按认证身份（principal / tenant）自动分区，与既有 OAuth2 / JWT 体系同源——隔离逻辑复用安全框架而非自造租户键，降低串租户风险。
• Vector Store 记忆与 RAG 的边界？同一套向量基建，两种数据：RAG 管共享知识（文档），记忆管用户个性化（偏好 / 历史）；检索时可分开召回再统一排序（详见 A02.03）。
• Tool Calling 与 MCP 的迁移路径？先用 Tool Calling 快速验证（进程内零部署）；能力需要跨应用复用时包装为 MCP Server——「一次实现，两类消费方」。

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

这道题考察的是 Spring AI 的 RAG 三种流变与 Guardrails 护栏：Sequential（Naive → Advanced 顺序管线）/ Branching（条件分支检索）/ Conditional（按需检索）分别解决什么问题？文档入库侧的 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 治理；组件层以 Advisor / 过滤器形态插入调用链。

• 流变选型：标准知识问答 → 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），按请求路由。

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

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

三层执行器的漏斗逻辑：第一层歧义追问——问题含糊（缺对象 / 缺参数）直接反问用户，不浪费模型推理；第二层知识问答——命中知识域走 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）？模型容错的「首包探测 + 三态熔断 + 多候选切换」如何设计？为什么「单通道失败不影响主链」是检索架构的可用性底线。

Ragent 检索融合链：向量 + 关键词 + 知识图谱 + 联网搜索四路并行 → 去重 → RRF 融合 → Rerank 精排 → 按召回数 / Rerank / TopK 分层控制；Nexus 为向量 + 关键词两路 + 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 ≠ 生产级」的最硬核证据。

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

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

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

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

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

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

与 A14.02 的边界：产品化差异见 A14.02；本卡登记模式清单与「调 API 不等于生产级」检查项，避免两处各写一套。

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

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

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

• 复用度工程化：跨业务复用的横切能力（防重复提交、审计、限流）抽象为 Spring Boot Starter（AOP + 注解 + 自动装配）——牛券防重三层（Web Token + 分布式锁 + MQ 去重表）抽象为 Starter 是范式样板；「一次实现，多业务接入」。
• 线程池治理同理：AI 链路专用线程池（Ragent 10 个 + 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）。

• 为什么「结构 + 语义 + 规则」三分而非单一相似度？三者对应三种失败模式：结构错是工程缺陷（必须零容忍硬断言）；语义偏差是效果问题（容忍带内波动）；规则违反是合规红线（一票否决）。混淆三者会导致要么测试脆断、要么红线失守。
• 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 强制上限」（如 Nexus 用 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——这是最隐蔽的成本泄漏，必须专项用例锁定。
• 故障注入污染共享环境：注入实验未隔离，殃及同环境其他服务；注入应在独立命名空间 / 环境执行并限流。

这道题考察的是 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 工程能力复用度与选型原则。

入库架构的演进：同步入库（请求内完成解析→切块→向量化→入库，长耗时阻塞且失败难恢复）→ 消息驱动的分步流水线（Nexus 用 Kafka 驱动解析→切块→向量化→入库各步任务，每步日志可追）→ 事务化可靠入库（Ragent 用 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 成本 / 会话量）。

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

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

这道题考察的是 观测数据的运营化闭环：Run/Node 级 Trace 如何支撑「答非所问」的分层定位；Nexus 的影子路由观测（用户手动选文档时后台静默跑完整路由，对比命中率 / 置信度 / 候选排名）如何用真实流量持续反哺路由质量；以及告警分级（熔断 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 工程化特有手段：它要求「同一请求双路执行 + 结果可比对」的架构支持——Java 侧强类型编排与 AOP 拦截让静默双跑的实现成本极低；本质是把「线上真实流量」转化为「免费评测集」，与灰度发布的思想同源。
• 降级「零触发」的悖论：熔断长期不触发有两种解释——系统真稳，或故障根本没被探测到；只有对探测机制本身做混沌验证（对齐 A17.02 故障注入）才能区分，观测指标（触发次数）是必要非充分信号。
• 回答溯源的合规价值：每个答案关联召回文档 ID 与工具调用记录，既支撑排障也支撑合规审计（谁问了什么、基于什么依据回答）——排障资产与合规资产同源。
• 闭环的飞轮效应：Bad Case 越多→Golden Set 越厚→回归越严→线上质量越高→用户信任越高→反馈越多——观测闭环是 AI 应用质量复利的核心机制。

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

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

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

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

认证授权三原则：

• 身份贯穿：Sa-Token / Spring Security OAuth2 对接既有 SSO，用户身份沿 AI 调用全链路透传——模型调用、工具调用、记忆读写全部携带真实身份，匿名调用链是审计黑洞。
• 数据归属校验：问答 / 文档 / 记忆按 userId / tenantId 隔离，越权访问在入口拦截（Ragent system 模块职责），而非依赖下游兜底。
• 最小权限：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 横切（切面统一记录链路追踪 / 幂等 / 审计日志——Ragent 设计模式清单中的横切方案，业务代码零侵入获得全量审计）→ 合规级审计（审计日志与回答溯源关联，支撑「谁在何时基于什么依据得到什么答案」的完整追问链）。

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

多租户隔离三手段：

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

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

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

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

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

切割策略的五级演进：固定大小 + 10–20% overlap（简单兜底）→ 递归字符切割（分隔符优先级 ["\n\n","\n","。","！","？","；","，"," "] 逐级降级，最常用）→ 文档结构切割（Markdown 标题层级 / 代码按 AST 函数边界）→ 语义切割（相邻句相似度骤降处下刀，质量最高）→ Agent 智能切割（LLM 审视，最贵）。

富化与检索增强的演进：裸 chunk 向量化 → metadata 富化（章节路径 / 关键词）→ 父子块（小块 200 token 精准检索、返回含上下文的父块 1000 token）→ Late Chunking（先编码后切分，token 向量经注意力互相感知后 mean pooling，跨块语境天然保留）→ Contextual Retrieval（向量化前 LLM 看全文为每 chunk 生成背景说明再拼接，Top-20 检索失败率降约 49%）。

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（首次 1.25 倍计费、命中 10%）后 800 chunk 文档的文档部分成本降到 10%–20%。
• 入库即验证：入库 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 毫秒级）→ 单路向量（对「M4 Pro」类精确词弱）→ 混合检索（向量语义 + BM25 精确 + 图谱实体关系三路并行，比单路好 10–30%（观察值，非普适））→ RAG 范式谱系（Naive → Advanced → GraphRAG / LightRAG → Agentic RAG）。

Rerank 的工程演进：Bi-Encoder 直出 Top-K（编码时不知查询意图，信息压缩损失）→ 两阶段：第一阶段 Bi-Encoder 粗召回 Top-50~100，第二阶段 Cross-Encoder（查询与文档拼接深度交互）精排 Top-5~10——复杂多跳 +40–50%、模糊查询 +30–40%、简单事实 +18%，幻觉率降约 35%（均为观察值，非普适）。

混合检索互补的第一性：BM25 词频 × 稀缺度（精确强同义词弱——「退货 / 申请售后」零重叠检索不到）；向量语义强精确词弱（「M4 Pro」被拉向「苹果最新处理器」反而找不到字面）。RRF 融合只用各路排名不用原始分数——不同检索器分数量纲不同不可比（像摄氏度与华氏度直接相加），被越多路命中的文档得分越高。

检索漏斗与门控（Ragent 生产实践）：漏斗三段独立——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 自我加权的陷阱：定向检索与全局检索若共用同一向量通道，同一文档会以两个「独立路」身份重复计分被自我加权——生产上必须让每路的排名来源真正独立（Ragent 用不可变 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 统计、按租户计费、模型配额、成本归因闭环。

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

档位路由的解析序（Ragent 实践）：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）——成本异常必须在速率层发现，而非月底账单。

• 只看总账单不归因：不知道钱烧在哪个场景哪类调用，优化无从下手——归因维度（业务线 / 场景 / 档位）必须在记账时埋好。
• 语义缓存不分租户：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 项目「账面省钱实际亏钱」——四项成本全口径入账。
• 无异常告警：月底账单才发现单租户异常烧钱——速率级告警前置。
• 超限静默拒绝：用户只看到「失败」不知道原因——拒绝 / 降级 / 排队都要有明确的用户侧反馈。
• 计费与审计两套账：计费系统与审计日志数据不一致，对账成本高且都不可信——同源落库。

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

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

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

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

模型档位版本注册表（Ragent 实践）：档位（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），这是版本治理与评测体系的接口纪律。
• 模型不可回滚的补偿：供应商模型被下架 / 变更无法回滚——注册表多候选设计（同档位多候选 + 熔断切换）本质是给「不可控的外部依赖」买工程保险。

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

与 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 约束 / 检索质量门控 / 引用核查 / 不确定性量化四方案按成本递进组合，Bad Case 持续回灌 Golden Set 形成飞轮。核心在于回答：上线不是终点，质量是运营出来的。

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

幻觉治理的演进（成本递进四方案）：Prompt 强约束（只用资料 / 没有就说无法回答 / 标注来源 / 不推断——零成本必做）→ 检索质量门控（Rerank 最高分低于阈值直接拒答）→ 引用核查（输出后 LLM 复核每个陈述是否有据，多一次调用）→ 不确定性量化（logprobs / 内部状态熵，高不确定输出转人工）。

漂移的两类来源：

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

幻觉四方案的运营分工：门控阈值（0.3–0.6 经验区间，金融医疗偏高）用「已知在库 + 不在库」测试集标定并定期重标；引用核查用于高风险场景（每答多一次 LLM 调用，成本换可信）；不确定性量化做转人工路由。四方案按场景风险组合，把幻觉当工程问题而非模型缺陷。

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

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

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

这道题考察的是 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 按入队时间），超限按租户策略分流（降级 / 排队 / 拒绝）。

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

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

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

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

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

TTFT 优化的演进：单模型等待（慢模型拖死首包）→ 多候选并发探测 → 首包探测 + 缓冲装饰（Ragent 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）。
• 分事件协议：思考 / 正文 / 来源 / 推荐问题分事件类型输出，前端分轨渲染——协议化让体验功能（来源展示 / 推荐）与正文解耦。

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

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

这道题考察的是 研发交付的工程化升级：IDP / 脚手架 / Starter 化标准化交付：内部开发者平台（IDP）如何统一 AI 应用的项目骨架与基建接入；Spring Boot Starter 自动装配为什么是 Java 生态标准化交付的核心机制；「防重三层」从业务代码抽象为 Starter 的抽象路径。与 A.11 的分工：A.11 讲 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 自身的集成测试必须覆盖典型装配组合。
• 脚手架与真实项目脱节：模板年久失修，生成项目仍需大改——脚手架随生产项目演进同步更新。

这道题考察的是 执行基建选型与 SDD 规约驱动：裸 JDK 线程池 / Spring TaskExecutor / Starter 化动态线程池 / 虚拟线程四形态的选型对比与判据；动态线程池的两大生产痛点（参数不可调 / 无监控）；以及 SDD（规约驱动开发）如何把「AI 理解需求」的不确定性前置消灭。核心在于回答：AI 服务是 IO 密集型负载，执行基建的选型直接影响成本与稳定性。

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

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

四形态选型对比：

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

SDD 的第一性：AI 编码的质量上限由规约质量决定——规约含需求描述 + 验收标准（可测试的完成定义），AI 的自由发挥空间被约束在验收框架内；先写规约 = 把沟通成本前置，把返工成本消灭在编码前。

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

• 虚拟线程与 AI 服务的适配性：AI 服务主流等待是 IO（模型响应 / 检索 / 队列轮询），线程在等待期零占用正是虚拟线程的设计靶点；但模型调用受全局信号量约束（对齐 A24.01），虚拟线程的「无限并发」必须仍受分布式配额约束——两者是互补不是替代。
• 从监控到自愈的闭环：告警 → 自动扩容（HPA 或动态调大 maximumPoolSize）→ 事后复盘——监控的终点是自动化响应而非人肉救火（oneThread 进阶结论）。
• 为什么 SDD 与 Coding Agent 是绝配：Agent 执行力强但理解需求有偏差——规约把偏差约束在验收标准内；同时规约是项目记忆（CLAUDE.md / AGENTS.md，对齐 A11.04）的输入，长会话上下文压缩也不丢关键决策。
• Anthropic 研究的落地映射：用好 AI 编程的关键是会问问题、会审结果、会定标准——SDD 的规约正是「会定标准」的工程化形态，把资深工程师的判断力沉淀为验收资产。

• 拒绝策略无监控：任务被静默丢弃，故障前兆无人知晓——拒绝事件必须告警。
• 告警无持续时间窗口：瞬时抖动触发告警风暴，值班疲劳后真告警被淹没。
• 参数拍脑袋不压测标定：core/max/queue 凭经验设，高峰期积压或空转——压测找到临界点再定参。
• 虚拟线程套池化思维：给虚拟线程配队列和拒绝策略，失去按需创建的意义——语义变了，监控与容量规划跟着变。
• 规约缺失直接让 AI 写：口头需求 + AI 自由发挥，产出漂移返工——哪怕 20 行规约也强于没有。
• 长会话靠压缩接力：关键决策在摘要中失真——决策写入记忆文件，压缩只省过程。

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

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

架构选择的场景化演进：一刀切 Agent（全场景上自主循环，贵且不可控）→ 按场景路由（Ragent 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 ≠ 企业级（增量更新 / 多租户 / 风控 / 可观测）；只关注模型忽略工程（检索策略 / 分块 / 上下文管理决定效果）。

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

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

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

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

学习与建设路径的演进（案例库方法论）：第一阶段基础巩固（oneThread——线程池工程化 + 可观测，直接反哺日常）→ 第二阶段高并发业务（牛券 / 12306——缓存 / 秒杀 / 分库分表）→ 第三阶段 SaaS 架构（Link——多租户 / 海量存储 / 压测标定）→ 第四阶段 AI 工程（Ragent——RAG / Agent 全链路，Java 开发者转 AI 应用的跳板）——按依赖顺序渐进，不跳步。

失败三因的机理：

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

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

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

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