# FDE W7D6 评测题 · 单一调用链设计与部署交付基础 > 配套手册：《FDE-W7D6-单一调用链设计与部署交付基础-学习手册.html》 > 候选人背景：36 岁，Java + 大数据 + 医疗保险，偏企业 AI 平台与部署交付。 > 题型：L1 基础 / L2 进阶 / L3 深度 / L4 场景，共 13 题。 > 评分：每题满分 5 分（4 档：0 / 2 / 3.5 / 5），折叠区为参考答案，先自答再展开。 --- ## L1 基础（概念清晰、能准确表述） ### Q1. 企业模式的 AI 调用链是什么？各层负责什么？ - **考察点**：调用链结构（业务→Spring AI→LiteLLM→模型）与分层职责。 - **评分维度**：① 四层链路正确；② 治理归网关、编排归应用；③ 换厂商业务零改动。
参考答案（点击展开） 调用链：业务应用(Java) → Spring AI → LiteLLM Proxy → 厂商/私有模型。职责：Spring AI 做业务编排、Prompt、工具调用、应用超时；LiteLLM 做路由、虚拟 Key、预算、配额、成本统计；模型做推理。治理集中网关，多业务共用，换模型厂商业务零改动。
### Q2. 学习/自研模式的调用链与企业模式的核心区别是什么？ - **考察点**：自研 Model Adapter 路线与"单一职责层"原则的保持。 - **评分维度**：① 业务→自研 Adapter→模型；② 区别在于网关是自研还是 LiteLLM；③ 仍要单一职责，业务代码勿再加一层重试/路由。
参考答案（点击展开） 自研模式：业务经自研 Model Adapter 调模型，治理（路由/重试/可能成本）在 Adapter 内实现。与企业模式的区别只在"网关是自研还是 LiteLLM"。但无论哪种，**路由/重试/成本仍只在一层做**——自研模式下就在 Adapter 这一层，别在业务代码里又写一遍，否则同样有重试风暴。
### Q3. 为什么强调"每类职责只允许在一层做"？ - **考察点**：单一职责层的工程价值（排障、账目）。 - **评分维度**：① 排障路径清晰；② 避免重复/冲突；③ 联系成本不双计、重试不风暴。
参考答案（点击展开） 每类职责（路由/重试/成本/超时）只在一层做，排障路径才清晰——请求失败能立刻定位是哪层。多层重复做会导致：两层路由冲突走错模型、两层重试放大成风暴、两层成本 double count。这是交付的工程纪律，不是可选优化。
### Q4. Docker 对 AI 服务镜像有什么特殊要求？ - **考察点**：AI 镜像与常规镜像的差异（权重、非 root、锁版本）。 - **评分维度**：① 模型权重不进镜像（走挂载）；② 非 root 运行；③ 依赖锁版本、体积可控、GPU 用 CUDA 基础镜像。
参考答案（点击展开） AI 镜像特殊点：模型权重几 GB~几十 GB，**绝不打进镜像**（否则膨胀、拉取慢、更新难），走 Volume/对象存储挂载；容器跑非 root 降攻击面（金融合规）；依赖锁版本；GPU 推理用带 CUDA 的基础镜像；Java 用多阶段构建减体积。
--- ## L2 进阶（能结合企业/Java 平台场景分析） ### Q5. 为什么只用一层路由？请描述两层路由会导致什么具体问题。 - **考察点**：路由冲突、最终决策权单一。 - **评分维度**：① 两层路由决策冲突/叠加；② 走错模型、行为不可预测、难排查；③ 正确做法：业务只选虚拟 Key，网关做最终路由。
参考答案（点击展开） 两层路由（业务选模型 + 网关又选模型）会冲突：业务选 A、网关因预算/白名单改到 B，业务不知情，结果不符预期；且两层策略不同，行为不可预测、极难调试（常表现为偶发走错模型）。正确：路由最终决策权只在网关一层；业务层最多决定用哪个虚拟 Key，进网关后不再二次路由。
### Q6. 两层重试为什么是灾难？重试应该放在哪层、如何处理 429？ - **考察点**：重试风暴、重试分层、429 处理。 - **评分维度**：① N×M 放大、压垮模型、成本翻倍、延迟叠加；② 网络重试只在一层；③ 429 不盲目重试，应降级/退避。
参考答案（点击展开） Spring AI 重试 3 次 + 网关重试 3 次 = 最多 9 次实际请求（重试风暴）：压垮模型/触发厂商限速、成本翻倍、延迟叠加。网络级重试只在一层做（Spring AI 或网关二选一）。429（预算/限速）不该盲目重试，应降级或退避排队，重试只会更快撞墙。业务级带反馈重试（结构化校验失败）是另一类，在应用层单做。
### Q7. 成本统计为什么只在网关一层做？重复统计的后果是什么？ - **考察点**：成本唯一可信来源、double count。 - **评分维度**：① 网关掌握真实 token 与单价，是唯一权威；② 应用再记会 double count、结算混乱；③ 应用只记调试 Trace，不作为结算依据。
参考答案（点击展开） 成本唯一可信来源是网关（LiteLLM 落库，掌握真实 token 用量与厂商单价）。若 Spring AI 也记一笔，同一请求被记两次 → 报表翻倍、Chargeback 算错、业务线甩锅。应用层只记"用了哪个模型/多少 token 估计"用于自身 Trace，不作为结算依据，结算一律以网关 Spend 报表为准。
### Q8. 环境隔离（dev/staging/prod）应隔离哪些维度？为什么保险客户特别敏感？ - **考察点**：隔离维度与金融合规。 - **评分维度**：① 网络/配置/数据/密钥四维度；② 测试连生产库是严重事故；③ staging 尽量像生产。
参考答案（点击展开） 隔离维度：网络/namespace（互不可达）、配置（模型地址/预算按环境不同）、数据（测试用脱敏/假数据）、密钥（各环境独立）。保险客户极敏感：测试连生产库、实验性 Prompt 影响真实用户、密钥混用越权都是严重事故，属硬合规项。staging 要尽可能"像生产"才能暴露真实问题。
--- ## L3 深度（能设计、能辨析细节） ### Q9. Liveness 与 Readiness 探针有什么区别？AI 服务为什么必须分开配？ - **考察点**：双探针语义差异与 AI 场景特殊性（模型加载慢）。 - **评分维度**：① Liveness=进程活否（失败重启）；Readiness=能否接流量（失败摘流不重启）；② 模型加载慢，进程活但没就绪；③ 误配会导致被杀循环或接流量失败。
参考答案（点击展开） Liveness 回答"进程还活着吗"，失败则重启容器；Readiness 回答"能接流量吗"，失败则从负载均衡摘掉、不重启。AI 服务模型加载权重要几十秒~几分钟，**进程活了但模型没就绪**——此时 Readiness=false 别接流量，但 Liveness=true 别重启。若把两者混用或阈值过短：Readiness 失败当 Liveness → 容器被杀、模型永远加载不完（被杀循环）；或模型没就绪就被打流量。必须分开配且阈值适配加载耗时。
### Q10. K8s Secret 默认安全吗？企业级 Secret 管理应该怎么做？ - **考察点**：Secret 风险认知与正确方案。 - **评分维度**：① 默认仅 base64 编码非加密；② 需 etcd 加密 + RBAC；③ 更优：Vault/云 Secret Manager，有动态密钥、审计、轮换。
参考答案（点击展开） K8s Secret 默认只是 base64 编码，**不是加密**，有 get 权限者即可解码，必须开 etcd 加密 + RBAC 限制。企业级：走 Vault / 云 Secret Manager，提供动态秘钥、访问审计、自动轮换；厂商 Master Key、DB 密码绝不进代码/镜像/Compose 明文；每个服务最小权限拿所需 Secret；有轮换流程（呼应 D5 虚拟 Key 可吊销）。
### Q11. Docker Compose 适合做生产架构吗？它的 depends_on 有什么坑？ - **考察点**：Compose 边界认知、就绪语义。 - **评分维度**：① 无扩缩容/自愈/多节点，仅单机演示；② depends_on 只管启动顺序不管就绪；③ 生产交 K8s。
参考答案（点击展开） 不适合。Compose 适合单机演示/PoC/小团队，一把起多容器定依赖，但**无自动扩缩容、自愈、多节点**。它的 `depends_on` 只管容器启动顺序，**不管"就绪"**——DB 起了但还没接受连接，网关可能连不上，需配合健康检查/重试。生产上这些交给 K8s。交付节奏：先 Compose 演示，再 K8s 生产。
--- ## L4 场景（企业 Agent 平台 / 保险实例综合应用） ### Q12. 某保险企业 Agent 平台要上线，业务→Spring AI→LiteLLM→模型。请指出交付前必须排查的"调用链重复"风险，并给出落地方案。 - **考察点**：把"单层路由/重试/成本"落到保险平台交付，含降级与可观测。 - **评分维度**：① 识别三层重复风险（路由/重试/成本）；② 每层只在一处做，给具体归属；③ 补充降级兜底 + Trace 串联 + 资源限。
参考答案（点击展开） 风险与方案：① 路由——业务代码若也按模型路由，会跟网关冲突；落地：业务只选虚拟 Key，网关做最终路由。② 重试——Spring AI 与网关都重试会成风暴；落地：网络重试只在一层（如 Spring AI maxAttempts=2，网关不重试），业务级带反馈重试在应用层另做，429 降级不重试。③ 成本——应用再记会 double count；落地：成本唯一来源是网关落库，应用只记调试 Trace。补充：网关挂了应用要有降级（换模型/人工）不卡死；调用链 id 贯穿各层做 Trace 串联；GPU/内存/超时按模型设限防 OOM 拖垮节点。
### Q13. 场景：你要为保险客户交付一个 Spring AI + LiteLLM 的 AI 服务，用 Docker/K8s 部署。请写出"部署交付 Checklist"并说明其中哪几条是金融合规的硬项。 - **考察点**：交付清单整合 + 合规硬项识别（Secret/隔离/探针/降级）。 - **评分维度**：① 列出镜像/配置/Secret/探针/调用链/降级/可观测/资源八条；② 指出合规硬项：Secret 不落代码+etcd加密+轮换、环境隔离、双探针、降级兜底；③ 体现"可运维交付"成熟度。
参考答案（点击展开） 交付 Checklist：① 镜像（权重外挂/非 root/锁版本）；② 配置各环境分离；③ Secret 走 Vault/云、不落代码、etcd 加密+RBAC、有轮换；④ Liveness/Readiness 分开、阈值适配模型加载；⑤ 调用链单一职责（路由/重试/成本各一层）；⑥ 降级兜底（网关挂有 fallback）；⑦ 可观测（日志/链路/Trace 串联）；⑧ 资源限（GPU/内存/超时）。 金融合规硬项：③ Secret 管理（明文进 Git 是 P0）、②/⑧ 环境隔离（防测试连生产库）、④ 双探针（防模型没就绪接流量/误杀）、⑥ 降级兜底（保障业务连续性）。这四条是"交付成熟度"的体检项，缺任一条金融客户验收不过。
--- ## 评分汇总表 | 题号 | 层级 | 主题 | 满分 | 自评 | 考官评 | |------|------|------|------|------|--------| | Q1 | L1 | 企业调用链 | 5 | | | | Q2 | L1 | 自研模式区别 | 5 | | | | Q3 | L1 | 单一职责层 | 5 | | | | Q4 | L1 | AI 镜像要求 | 5 | | | | Q5 | L2 | 单层路由 | 5 | | | | Q6 | L2 | 单层重试/429 | 5 | | | | Q7 | L2 | 成本单点 | 5 | | | | Q8 | L2 | 环境隔离 | 5 | | | | Q9 | L3 | 双探针区别 | 5 | | | | Q10 | L3 | Secret 管理 | 5 | | | | Q11 | L3 | Compose 边界 | 5 | | | | Q12 | L4 | 保险调用链落地 | 5 | | | | Q13 | L4 | 交付 Checklist | 5 | | | **计分**：每题 0 / 2 / 3.5 / 5 四档。总分 65。 - **达标线①（单层路由/重试/成本）**：Q3、Q5、Q6、Q7 合计应 ≥ 17/20，能口头讲清"为什么只在一层"。 - **达标线②（Docker 部署要点）**：Q4、Q8、Q9、Q10、Q11 合计应 ≥ 21/25，能讲清镜像/隔离/Secret/探针/Compose 边界。 - **整体达标**：总分 ≥ 50/65，且两条达标线同时达标，方可进入 W7D7（K8s 与平台整合）。