经典场景：数据分析 Agent 与 Copilot

• 理解 NL→SQL→图表→洞察的完整链路
• 能否设计执行安全（只读、限行、脱敏）
• 能否编排查询、执行、解读与可视化

数据分析 Agent 的编排链路：查询生成——把自然语言问题结合表结构（schema）与指标口径生成 SQL；执行安全——SQL 只允许执行只读查询、限制行数与超时、敏感列脱敏、禁止危险语句（DML）、必要时走审批；结果解读——对执行结果进行语义解读（趋势、异常、对比）；可视化——根据结果特征自动选择图表类型并生成洞察。编排上采用"生成→校验→执行→解读→可视化"逐步控制：SQL 生成后先做语法与安全校验再执行，执行结果先检查正确性（复算关键指标）再解读，避免错误结论。整个过程保留用户可审计的 SQL 与结果，支持人工复核。

面试官关注"执行安全"与"结果正确性"这两个 Agent 落地的关键。NL→SQL 生成易错，需 schema 约束 + 校验 + 复算。回答强调"生成→安全校验→执行→解读→可视化"的编排与每步的控制点。

• 理解指标口径与维度字典的语义层建模
• 能否设计数据权限前置
• 能否防止"同名不同义"的口径问题

BI 问答系统的核心是"语义层前置建模"：指标口径——把每个指标（如 GMV、DAU、退款率）的定义、计算逻辑、口径说明（如"退款率=退款金额/成交金额"）建模为语义对象，问答时映射到标准指标，避免同名不同义；维度字典——把维度（时间、渠道、商品类目）及其取值、层级关系建模成字典，支持自然语言中的别名（如"上周"→日期范围）与钻取；数据权限——把用户可访问的指标与维度前置建模，问答与 SQL 生成时强制带上权限条件，防止越权查询。口径一致性靠"问答先落到语义层，再做 SQL 生成"，而不是直接让模型解释自然语言，从而保证口径统一。

BI 问答的核心是"语义层"而非"直接 NL→SQL"。指标口径、维度字典、权限前置建模，让模型在受控语义范围内生成，避免口径混乱与越权。面试官强调"前置建模"防止口径不一致。

• 理解上下文注入（打开文件、仓库索引、语言类型）
• 能否设计补全触发与安全过滤
• 能否设计采纳度量

代码助手设计：上下文注入——注入当前打开文件、相关文件、仓库索引（代码检索）、语言/项目类型、光标位置，形成补全的上下文；补全触发——按需触发（用户暂停输入、快捷键、特定语法）而非每次击键，控制延迟与成本；安全过滤——过滤敏感信息（密钥、token）、拒绝生成恶意代码（注入、路径穿越）、对操作类补全做限制；采纳度量——记录补全被采纳比例、采纳后修改量、补全覆盖率，衡量对开发效率的提升。设计上要控制上下文大小（只注入相关片段而非全仓库）、控制延迟（缓存、流式），并对安全做模型层 + 代码规则层双重过滤。

面试官关注"上下文相关性""触发时机""安全"与"采纳度量"。上下文注入要"相关"而非"全量"，触发要"按需"，安全要"代码规则层兜底"，采纳率是核心 ROI 指标。

• 理解文档解析与字段抽取流程
• 能否设计置信度输出
• 能否设计人工复核工作台

文档处理 Agent 设计：解析——对 PDF/图片/扫描件做 OCR 与版面分析，还原文本结构（段落、表格、页眉页脚）；字段抽取——用 LLM 或抽取模型根据字段 Schema 抽取出关键字段（合同金额、日期、条款）；置信度输出——每个字段附带置信度，低置信度字段标记为"待复核"；人工复核工作台——把低置信度或高风险字段推送给人工复核，人工在界面确认或修正，复核结果回流为训练/评测数据。设计上字段 Schema 先行（定义要抽什么字段、类型、校验规则），抽取结果做格式校验（如日期格式、金额范围），置信度驱动的"人机协同"保证抽取出错可控。

面试官关注"置信度 + 人工复核"的协同。文档抽取不可能 100% 准确，设计要"高置信度自动通过、低置信度人工复核"。字段 Schema 先行 + 置信度阈值 + 复核回流是核心。

• 理解规划-执行-验证的 Agent 循环
• 能否设计工具调用与失败重试
• 能否设计人工审批节点

通用任务编排 Agent 采用"规划-执行-验证"循环：规划——把用户任务分解为步骤计划（可执行的动作序列）；执行——按计划调用工具/API，收集结果；验证——校验执行结果是否符合预期（结果正确、无副作用），不符合则重新规划或调整。工具调用设计：工具 Schema 声明、参数校验、权限校验、幂等控制。失败重试：对可重试错误（暂态失败、超时）指数退避重试，对不可重试错误（参数错误、权限不足）跳过或终止。人工审批节点：对高风险动作（写操作、对外发送、金钱操作）插入审批节点，Agent 生成待审批动作，人工批准后继续执行。整体保证"Agent 自主执行 + 高风险人工把关"。

面试官关注 Agent 循环的闭环与"人在回路"。规划-执行-验证是基本循环，失败重试要区分可重试/不可重试，人工审批节点是高风险 Agent 的必备。回答强调"高风险动作必须人工审批"的责任边界。

• 理解分层审核（规则→模型→LLM）
• 能否设计误杀率与漏放率的平衡
• 能否说明各层职责与成本

内容审核分层设计：规则引擎——用词表、正则、黑白名单快速拦截明确违规内容（色情、暴力、广告），快且便宜；分类模型——对内容做违规分类与置信度打分，覆盖语义层面违规；LLM 复核——对规则与模型判定"模糊"或"高风险"的内容用 LLM 深度复核，降低误判。误杀率与漏放率平衡：误杀率是"正常内容被错杀"，漏放率是"违规内容被放过"，两者此消彼长；通过置信度阈值与人工复核接口调节——高置信度直接处理，低置信度进人工或 LLM 复核，用"双阈值"（如置信度 > 0.9 拦截、< 0.3 放行、中间复核）平衡。审核结果回流用于优化模型与规则。

面试官关注"分层 + 双阈值平衡"。规则/模型/LLM 三层各司其职（快/中/深），双阈值策略把模糊内容交给复核，是平衡误杀与漏放的关键。成本与准确率在此权衡。

• 理解模型输出与业务规则的融合机制
• 能否设计规则过滤与排序融合
• 能否保证合规与可用性

个性化推荐/搜索增强系统要把模型输出与业务规则融合：模型负责个性化排序（按用户兴趣打分），业务规则负责约束与兜底——库存过滤（无货商品不展示）、价格过滤（价格区间、优惠）、合规过滤（限购、禁售、广告法）、业务优先级（置顶、新品）。融合机制：规则过滤在前（过滤不可展示项）、模型排序在后（在合规集合内排序），或规则作为加权因子参与排序。为避免模型输出"越权"或"违规"，规则层是硬约束（不可被模型覆盖），模型层是软优化。同时要处理冷启动（无行为数据时用规则兜底）与 A/B 验证。

面试官关注"硬规则 vs 软模型"的融合边界。规则是硬约束（库存、合规不可商量），模型是软优化（排序）。融合 = 规则过滤 + 模型排序，规则层兜底保证可用性与合规。

• 理解长文档分段与摘要层级
• 能否设计事实校验
• 能否检测摘要错误

会议纪要/文档摘要系统设计：长文档分段——把长文档按章节/语义切分，分别生成片段摘要，再合并为整体摘要（map-reduce 式），避免超长上下文；摘要层级——多级摘要（会议要点、待办、决策、逐议题），满足不同查看粒度；事实校验——生成摘要后，用"摘要断言 vs 原文"的校验（抽取式对齐或 LLM 比对），确认关键事实（数字、人名、决策）在原文中有依据，无依据的标注为"待确认"；摘要错误检测——把摘要断言与原文做一致性检测，检测出的事实错误（如数字不符）标记并提示复核，或引用原文片段。设计上区分"摘要"与"原话"，待办/决策等动作类内容要单独提取并校验。

面试官关注"事实校验"与"错误检测"，这是摘要可靠性的关键。map-reduce 分段解决长文，层级摘要解决粒度，事实校验/错误检测解决"摘要不能编造"。回答强调校验与人工复核衔接。

• 理解知识库更新管道的增量机制
• 能否设计去重与版本化
• 能否设计回滚

RAG 客服知识库更新管道设计：增量摄取——监听文档变更（新增/修改/删除）事件，只对变更文档重新解析、分块、向量化，并更新索引，避免全量重建；去重——用内容哈希或相似度检测，避免同一文档重复入库，删除重复 chunk；版本化——每个文档带版本号，索引与缓存记录版本，检索结果可追溯版本，支持"在某版本下检索"；回滚——当新版本文档质量下降或摄取错误时，回滚到上一版本（保留旧版本 chunk 与索引快照），支持按版本回切。更新管道用事件驱动（变更事件 → 摄取任务 → 索引更新 → 缓存失效），并支持失败重试与幂等（同一文档多次摄取结果一致）。

面试官关注"增量 + 版本化 + 回滚"的完整管道。增量解决效率，去重解决一致性，版本化解决可追溯，回滚解决安全。事件驱动 + 幂等保证更新可靠。

• 理解风格约束与事实核查机制
• 能否设计版权与 AIGC 标识
• 能否说明合规要求

AI 写作助手设计：风格约束——用风格指南约束（语气、术语、格式、长度），通过 Prompt 风格指令 + 输出校验（字数、风格一致性）实现，企业可配置品牌风格模板；事实核查——对生成内容中的事实断言（数字、引用、事件）做核查，标注来源或标记"待核实"，对不确定内容用"据公开信息"等表述；版权与 AIGC 标识——遵守版权合规（不生成侵权内容、识别受版权素材），并按法规要求对 AIGC 内容做标识（水印、metadata、声明"AI 生成"），内容平台可联合检测。落地上把风格、事实、合规作为生成后的校验与后处理环节，并保留人工编审入口。

面试官关注"合规与质量"的落地。风格约束靠模板与校验，事实核查靠来源标注，版权/AIGC 标识是法规刚性要求。回答强调"生成后校验 + 人工编审"保证合规。

• 理解模板 + 数据绑定 + 自然语言总结的结合
• 能否设计数值一致性校验
• 能否保证报表不出现"数字对不上"

报表生成系统设计：模板——预定义报表结构（表格、图表、布局），声明数据字段绑定；数据绑定——从数据库/数据源按模板配置取数，填充到模板对应位置；自然语言总结——对报表数据生成一段总结（趋势、异常、关键指标解读），放在报表顶部。数值一致性校验是关键：自然语言总结中的数字必须与表格/图表中的实际数据一致，通过"总结断言 vs 数据绑定值"的校验（提取总结中的数字与图表数据比对，不一致则拒绝或重写），图表数据与 SQL 结果复算校验。设计上把"数据"与"描述"解耦：数据来自确定性查询，描述由 AI 生成但必须引用真实数据，防止"结论与数据不符"。

面试官关注"报表数字不能错"。核心是"数据确定 + 描述引用数据 + 一致性校验"。总结必须与数据绑定一致，通过断言校验保证。回答强调数值一致性是报表的底线。

• 理解多数据源与权限过滤
• 能否设计 AI 摘要增强
• 能否设计点击反馈回流

企业搜索增强系统设计：多数据源——聚合文档、Wiki、工单、邮件等多个数据源，统一索引（各自建索引再合并，或统一 ingestion）；权限过滤——每个数据源文档按访问权限过滤，检索时强制带上用户权限，防止越权看到他人文档；AI 摘要——对检索结果生成摘要，帮助用户快速判断相关性，摘要需引用来源文档。点击反馈回流——记录用户点击、未点击、停留时间，作为 relevance 信号回流，用于调整重排与检索（如人工反馈训练重排模型）。整体是"多源聚合 + 权限过滤 + AI 摘要 + 反馈闭环"的组合，权限过滤与摘要都要保正确性。

面试官关注"权限过滤 + 反馈闭环"。多源聚合是基础，权限过滤是安全底线，AI 摘要提效，点击反馈是优化闭环。回答强调"权限过滤前置 + 摘要引用来源 + 点击回流重排"。

• 理解查询执行层的强制安全措施
• 能否设计只读、限行、超时、脱敏
• 能否设计 SQL 审计与审批

数据分析 Agent 执行安全必须在执行层强制：只读账号——用数据库只读账号执行，从账号层面禁止 DML/DDL；行数/超时限制——查询上限行数（防止大结果集）与超时（防止长查询拖垮），超限自动截断或报错；敏感列脱敏——对敏感列（手机号、身份证、金额）在执行层脱敏（掩码/加密），查询结果不返回明文。审计与审批：所有生成 SQL 记录审计（谁、何时、什么 SQL、结果），高风险/敏感查询（涉及敏感表、大范围查询）走人工审批后方可执行。执行层强制保证"即使模型生成恶意 SQL 也无法造成破坏"。

面试官关注"执行层强制而非依赖模型"。只读/限行/超时/脱敏是执行层硬性约束，审计与审批是治理闭环。回答强调"生成 SQL 安全不可控，执行层必须兜底"。

• 理解模糊查询的澄清机制
• 能否主动追问而非猜测
• 能否控制澄清交互成本

模糊查询澄清设计：当用户查询缺少关键参数（时间范围、指标口径、维度）时，Agent 应主动追问而非猜测。机制：先做参数完整性检测（缺哪些必需参数），再生成澄清问题（可给选项，如"查看近 7 天还是近 30 天？"），限一次追问（最多澄清 1-2 轮，避免来回拉扯）。交互成本控制：区分"必需参数"与"可选参数"——必需参数缺失必追问，可选参数缺失用默认值并提示；给默认值+选项而非开放问答，降低用户输入成本；明确告知用户可直接输入完整条件。追问后校验结果，不确定时再确认。核心是"宁追问不瞎猜，但追问要克制"。

面试官关注"澄清 vs 猜测"的平衡。猜测会给出错误结果，追问过多则体验差。回答强调"必需参数必追问、可选参数给默认 + 限轮数追问 + 选项化"。

• 理解结果正确性验证的多个环节
• 能否设计图表与 SQL 一致性校验
• 能否设计聚合复算与异常值提示

数据分析结果正确性验证设计：图表与 SQL 一致性校验——图表展示的数值必须与 SQL 执行结果一致，通过"图表数据源 = SQL 结果"的绑定校验，防止可视化层篡改或错位；聚合口径复算——对关键聚合（总数、均值、占比）用 SQL 复算一遍，确认与展示一致，防止口径错误（如去重 vs 不去重、过滤条件）；异常值提示——对结果中的异常值（极值、突变、空值、负值）做检测并提示（如"该月 GMV 较上月下降 40%，请确认口径"），防止把异常当正常。整体是"数据确定 + 校验 + 异常警示"的闭环，保证用户看到的数字可信。

面试官关注"数字可信度"。图表与 SQL 一致性、聚合复算、异常值提示三道防线，防止"结论错、口径错、异常被掩盖"。回答强调"数据链路确定性 + 校验兜底"。

• 理解慢查询的异步化机制
• 能否设计轮询与结果缓存
• 能否平衡等待体验与资源回收

长查询异步化设计：当 SQL 执行超过阈值（如 >3s）时，转为异步任务——立即返回 taskId，后台执行，前端轮询或 WebSocket 推送结果；结果缓存——相同查询结果缓存复用，避免重复执行；任务状态持久化（pending/running/success/failed），支持查看进度与结果。用户体验与资源平衡：同步/异步阈值可调，短查询走同步（快），长查询走异步（不阻塞）；对异步任务设超时与资源上限（超时终止、限制并发），并支持取消（用户放弃时释放资源）；结果缓存按查询参数与权限维度隔离，防止缓存越权。核心是"短同步、长异步、缓存复用、可取消"。

面试官关注"异步化 + 资源管理"。同步/异步阈值分流，异步任务持久化 + 轮询，缓存复用降低重复查询，超时/取消回收资源。回答强调"等待体验与资源成本的平衡"。

• 理解语音链路各环节（ASR/意图/DM/TTS/转人工）
• 能否设计对话状态机
• 能否处理语音特有交互（打断、噪音、转人工）

语音助手设计包含五环节：ASR（语音转文字，识别率与容错）、意图识别（理解用户意图）、对话管理（DM，维护多轮对话状态与槽位）、TTS（文字转语音，回复播报）、转人工（语音无法解决时转人工坐席）。状态机设计：会话状态机包含"等待输入→识别中→理解中→回复中→等待确认→转人工"等状态，处理语音特有情况——打断（用户中途打断时停止 TTS 并重新识别）、静音/超时（无输入时提示或重试）、拒识（识别不清时引导重说）、转人工（识别失败多次或情绪激动时转人工并保留上下文）。状态机保证语音交互的确定性流转，各环节异步解耦（ASR 流式、TTS 流式）。

面试官关注语音链路与状态机。语音交互有打断、静音、拒识等特有状态，需状态机管理。转人工是语音客服的兜底。回答强调"状态机驱动确定性交互 + 语音特有事件处理"。

• 理解审批助手的辅助能力
• 能否设计 AI 与人工决策的边界
• 能否设计审计留痕

智能审批助手设计：表单预填——AI 根据已有数据自动预填表单字段（申请人信息、金额、事由），人工核对后提交；审批建议——AI 根据规则与历史给出审批建议（通过/驳回/需补充），附依据与置信度；人工决策——最终审批权在人工，AI 只提供建议不直接决定，尤其金额大、风险高的审批必须人工；审计留痕——记录 AI 建议、依据、人工决策及理由、操作者，全程留痕可追溯。边界设计：AI 负责"预填与建议"，人工负责"决策与责任"，高风险项强制人工且 AI 建议仅作参考。审计是合规底线，任何 AI 介入都要留痕。

面试官关注"AI 辅助、人工决策"的边界与审计。预填与建议是提效，决策权在人工，高风险强制人工。审计留痕是合规要求，体现对责任边界的重视。

• 理解多 Agent 协作的任务分解与协调
• 能否设计消息协议与状态同步
• 能否设计成本治理

多 Agent 协作平台设计：任务分解——主 Agent 把任务分解为子任务分派给专业 Agent（检索、计算、写作等），协调子任务结果；消息协议——定义 Agent 间的消息格式（任务、结果、状态、引用），用标准协议（如 A2A/MCP）或自研结构化消息，保证互操作；状态同步——各 Agent 共享状态（任务进度、上下文）通过中心协调器或事件总线同步，避免状态不一致；成本治理——多 Agent 协作 Token 消耗大，需限制 Agent 数量、层级深度、循环次数，设定单任务成本上限，超限降级为单 Agent 或人工。架构取舍：中心化协调（可控但单点）vs 去中心化（灵活但难控），常见是"中心协调 + 子 Agent 专业化"。

面试官关注"多 Agent 的成本与可控性"。多 Agent 灵活但成本高、易失控，回答强调"任务分解 + 标准协议 + 状态同步 + 成本上限"的取舍，并指出多 Agent 未必优于单 Agent，需按需取舍。

• 理解图表类型选择的数据特征依据
• 能否设计图表生成规则
• 能否衔接图表描述与洞察

数据分析 Agent 可视化选择按数据特征自动选型：时间序列（时间 × 度量）→ 折线图；类别对比（维度 × 度量）→ 柱状图；占比（部分 vs 整体）→ 饼图/环形图；两个度量的相关性→散点图；地理→地图。选择逻辑用规则引擎（根据字段类型与语义判断）结合结果特征（行数、值域）。图表描述与洞察生成衔接：图表生成后，基于同一份数据生成图表描述（标题、坐标轴说明、关键值）与洞察（趋势、异常、对比、建议），洞察必须引用图表数据（数字一致），衔接方式是把"数据特征 → 图表选型 → 数据解读传播"作为一条管线，确保描述与洞察基于同一数据源，避免"图表与文案对不上"。

面试官关注"图表选型规则 + 描述与洞察的一致"。选型按数据特征（维度/度量/时间序列）规则化，洞察引用同一数据保证一致。回答强调"数据驱动选型与解读，杜绝图文不一致"。