AI Agent · 进阶¶
AI Agent 板块的进阶题：范式切换、审核者设计、MCP 三端、LoRA vs SFT、推理引擎选型、工具调用工程化、数据飞轮。每题含参考答案与面试官追问/红旗。
Q1: ReAct 和 Plan-and-Execute 如何按场景选择？意图分类器怎么实现动态切换？¶
进阶 | AI-Agent | 📖 相关讲解
考察点：混合推理的落地，是否理解意图分类器在其中的路由作用。
参考答案
场景选择：
| 范式 | 适合场景 | 原因 |
|---|---|---|
| ReAct | 简单查询、单轮、弱依赖 | 反应快、每步可纠错、延迟低 |
| Plan-and-Execute | 复杂多步、强依赖、需全局视野 | 先拆解后执行，路径可控、可解释 |
纯 ReAct 在复杂任务里"走偏"且 Token 多；纯 Plan-and-Execute 对简单查询是过度设计。所以企业级 Agent 用 ReAct + Plan-and-Execute 混合推理（彭超案例），关键是一层意图分类器做动态路由。
意图分类器实现：根据 query 复杂度、涉及系统数、是否含多约束等特征判分——简单（如"我的订单到哪了"）走 ReAct 保延迟（P95 < 800ms），复杂（如"处理这笔退货并通知客户"）走 Plan-and-Execute 保可控。分类器可以是轻量分类模型，或"规则 + LLM"混合：先用规则初筛（含金额/多实体/多步骤关键词等判复杂），不确定时再让 LLM 判定。
面试官追问 / 红旗
- 追问：意图分错了（简单判成复杂、或反之）会有什么后果？怎么兜？（误判容错、可回退）
- 追问：分类器本身也是个模型调用，会不会反而增加延迟？（轻量模型/规则前置/缓存）
- 红旗：只会说"用 LLM 判断意图"，讲不出判别特征和兜底；或声称用了混合推理却说不清切换条件——可能是套用术语。
Q2: 详述规划者-执行者-审核者架构，审核者的规则引擎覆盖哪些维度？¶
进阶 | AI-Agent | 📖 相关讲解
考察点：三角色分工与审核者落地，是否真的做过审核闭环。
参考答案
三角色职责：
- 规划者（Planner）：拆解任务、生成执行计划、决定调哪些工具；
- 执行者（Executor）：按计划调工具/检索、生成中间结果；
- 审核者（Reviewer）：基于规则引擎校验执行者输出是否合规、可信。
审核者规则引擎覆盖维度（彭超案例）：
| 维度 | 校验内容 |
|---|---|
| 合规 | 敏感词、违规承诺、超出业务范围 |
| 金额阈值 | 涉金额超阈值需人工确认 |
| 业务约束 | 订单状态、权限范围、前置条件是否满足 |
| 事实性 | 关键事实是否在检索证据中有支撑（联动幻觉治理） |
关键设计：审核者尽量是规则引擎而非另一个 LLM——可配置、可热更、可解释、低成本。校验不通过形成闭环：带失败原因回退重规划，或高风险转人工兜底，超过重规划上限也转人工，不死循环。这套"分角色 + 规则审核 + 兜底"是金融/合规场景敢上线的前提。
面试官追问 / 红旗
- 追问：为什么审核者不用 LLM 而用规则引擎？（可控/可解释/成本/合规可审计）
- 追问：规则和 LLM 在审核上怎么配合？（规则兜底线 + LLM 做柔性判断/事实校验）
- 红旗：把审核者也做成"再调一次 LLM 让它自我检查"——既不可控又不可审计；或答不出审核失败如何闭环回退。
Q3: MCP 的 host/client/server 各自职责是什么？工具复用的优势体现在哪？¶
进阶 | AI-Agent | 📖 相关讲解
考察点：MCP 三端架构的准确理解，能否讲清复用价值。
参考答案
三端职责：
| 角色 | 职责 |
|---|---|
| Host（宿主） | 承载 LLM、决定何时用工具、管理会话与授权（如 Claude Desktop、IDE、自研 Agent 平台） |
| Client（客户端） | Host 内的协议适配器，与某个 Server 维持 1:1 连接，转发请求/结果 |
| Server（服务端） | 暴露 Tools/Resources/Prompts 的独立服务（如订单系统 MCP Server） |
Host 为每个接入的 Server 创建一个 Client（1:1），通过能力协商动态发现各 Server 提供哪些工具。
工具复用优势：
- 写一次到处用：一个 MCP Server 写好，任意支持 MCP 的 Host 都能接入；
- 接入成本骤降：Agent 接入企业系统从"N 个系统各对接"变成"接 N 个标准 Server"（蒋磊打通 10+ 接口即是此模式）；
- 可热插拔：Server 升级新增工具，Host 重新协商自动发现，不改 Host 代码；
- 解耦：Server 不关心哪个模型在调，Host 不需要为每工具重写声明。
面试官追问 / 红旗
- 追问：MCP Server 颗粒度怎么划？（按系统/领域，避免巨型 Server）
- 追问：把内部系统封装成 MCP Server 上线，安全怎么保证？（鉴权/越权/审计）
- 红旗：分不清 host 和 client 的职责（说成同一回事）；或把 MCP 当成"另一个 Function Calling"而讲不出复用/标准化价值。
Q4: LoRA 微调 vs 全参 SFT，在成本、效果、场景上如何取舍？¶
进阶 | AI-Agent | 📖 相关讲解
考察点：两种微调路径的权衡，是否根据场景做对选型。
参考答案
| 维度 | LoRA | 全参 SFT |
|---|---|---|
| 训练参数量 | 极少（<1%，只训低秩增量） | 全部 |
| 显存/算力 | 低 | 高（量级差距） |
| 效果上限 | 中高（业务定制够用） | 高 |
| 灾难性遗忘 | 少（基座冻结） | 易发生 |
| 可插拔/回滚 | 强（一个基座挂多适配器） | 弱（每模型独立） |
取舍：
- 优先 LoRA：绝大多数业务定制场景——成本低、可插拔、易回滚、少遗忘。彭超案例（rank=16 + SFT）即走此路。
- 才用全参 SFT：必须深度重塑模型行为、领域与通用分布差异极大、且数据/算力充足的少数场景。
一句话：LoRA 是性价比默认选，全参 SFT 是高投入特殊场景才上。两者也可组合——先全参奠定领域能力，再用多个 LoRA 做细分场景定制。
面试官追问 / 红旗
- 追问：rank 设多少合适？怎么选？（任务复杂度试，8/16/32 常见）
- 追问：LoRA 训练数据从哪来、多少够？（引出数据飞轮/负样本挖掘）
- 红旗：一律说"全参效果最好所以用全参"，无成本/场景意识；或讲不出 LoRA 为什么不易遗忘——暴露没真做过微调。
Q5: vLLM、Ollama、TGI 的定位差异是什么？分别用在什么场景？¶
进阶 | AI-Agent | 📖 相关讲解
考察点：私有化部署选型，能否讲清三者的定位区分。
参考答案
| 方案 | 定位 | 适用场景 |
|---|---|---|
| vLLM | 高吞吐推理引擎（PagedAttention、连续批处理），面向生产高并发 | 企业级生产、QPS 高、要榨干显存吞吐（彭超生产主力） |
| Ollama | 本地一键跑模型，面向开发者易用 | 本地开发、Demo、单机小流量快速验证 |
| TGI | HuggingFace 出品，生产级推理，支持张量并行 | 生产部署、与 HF 生态紧耦合 |
一句话：vLLM 重吞吐、Ollama 重易用、TGI 重 HF 生态兼容。
实践中常见组合：本地开发用 Ollama 快速验证 → 生产上 vLLM 高并发 + 双活热备。选型核心看"生产高并发 vs 本地易用 vs 生态兼容"哪个是首要约束。
面试官追问 / 红旗
- 追问：vLLM 为什么吞吐高？（PagedAttention/连续批处理）
- 追问：你生产环境怎么保证推理服务高可用？（引出双活热备/降级，呼应 99.99%）
- 红旗：笼统说"部署过大模型"，讲不清三个方案的区别与各自适用场景；或把 Ollama 当生产推理引擎——暴露缺乏生产经验。
Q6: 工具调用成功率从 80% 提升到 98%，你做了哪些工程化改造？¶
进阶 | AI-Agent | 📖 相关讲解
考察点：工具层工程化的具体手段，是否真做过系统性提升。
参考答案
把模型当"会犯错的决策器"，在执行链路上层层兜底：
| 手段 | 作用 |
|---|---|
| 工具元数据质量 | description 写清"做什么/何时用"，参数 schema 严格化——选对工具的根本前提（自定义注解扫描注册） |
| 参数校验 | 执行前 JSON Schema 严格校验 LLM 产出，拦截非法参数，不让脏参数打下游 |
| 异常重试 | 区分可重试（网络抖动/5xx）与不可重试（参数错/业务错）错误，按退避策略重试 |
| 超时控制 | 每工具独立超时（防慢工具）+ 链路总超时（保 P95），双层 |
| 降级链 | 重试仍失败走降级：备选工具 → 规则引擎兜底 → 转人工 |
| 全链路 Trace | 选哪个工具/参数/校验/重试/超时/降级全落 Trace，让 98% 可归因可迭代 |
核心：98% 不是模型白送的，是元数据 + 校验 + 重试 + 超时 + 降级 + 可观测这套工程化的结果。
面试官追问 / 红旗
- 追问：哪一类失败占比最高？你针对它做了什么？（归因能力，避免笼统）
- 追问：98% 这个数字怎么统计的？分母分子是什么？（口径严谨）
- 红旗：只说"调了 Prompt 让它选对工具"，无校验/重试/超时/降级体系；或答不出数字口径——典型"简历有数但讲不清来源"。
Q7: 数据飞轮如何驱动 Prompt/SFT 迭代？负样本怎么挖掘？¶
进阶 | AI-Agent | 📖 相关讲解
考察点：模型工程的闭环能力，是否理解持续迭代机制。
参考答案
数据飞轮 = 把线上真实负信号持续回收，反过来驱动模型/Prompt 迭代的闭环。彭超案例用三路信号挖负样本：
| 信号来源 | 负样本来源 |
|---|---|
| 用户反馈 | 点踩、纠错、低评分——最直接的负信号 |
| AI 审计 | 对产出做规则 + 模型自动审计，发现事实错误/合规问题 |
| CoT 归因 | 把错误沿思维链回溯，定位是哪步（检索/规划/执行/审核）引入问题 |
如何驱动迭代（关键：归因决定改哪）：
- 归因到 Prompt/工具描述层（如选错工具、格式不对）→ 改系统提示、Few-shot 示例、工具 description；
- 归因到 知识/行为层（如事实错误、话术不对）→ 把纠正后的正例加入 SFT 训练集，下一轮微调。
持续闭环后，这套机制是幻觉率 -30%、Token 成本 -45% 的真正来源。难点不在"微调一次"，而在"持续闭环"——这是模型工程的核心竞争力。
面试官追问 / 红旗
- 追问：负样本会"带毒"（用户反馈本身错/审计误判）怎么办？（清洗/置信度/人工抽检）
- 追问：多久迭代一次 SFT？成本怎么控？（迭代节奏/数据量门槛）
- 红旗：只说"收集用户反馈优化模型"，讲不清 CoT 归因如何决定改 Prompt 还是补数据；或把数据飞轮说成"定期重新训练"而无闭环机制。