场景设计题没有标准答案，评分逻辑也就和手撕题完全不同。面试官手里通常只有一张 checklist：边界条件想没想（步数上限、超时、失败兜底）、数字给不给得出来（工具几个、重试几次、预算多少）、取舍讲不讲得清（为什么单 Agent 不上多 Agent）。答得玄的候选人满地都是，能落出具体数字和分层架构的少，所以这类题的胜负手是「像不像真的上线过」，而不是「背没背过架构图」。本篇围绕 Agent 从 0 到 1 的十个高频场景，每题给一套能直接在白板上展开的答法。题目结构说明：每题四部分。考点定位讲面试官在筛什么；答题框架是开口后的叙述顺序，先说什么后说什么；参考架构与关键决策给一套带数字的方案，数字是记忆锚点，面试时可以微调但要敢说；追问链是讲完后大概率跟上的问题，附一句话答法。标记：⭐ 高频（出现率过半）、🔥 近两年新增。Q1 开放题：设计一个数据分析 Agent，用户上传 CSV 后用自然语言问数 ⭐考点定位：Agent 岗最常见的开场题。它把意图理解、工具设计、SQL 生成、安全、兜底全塞进一个场景，面试官看你能不能在三分钟内给出有层次的方案，而不是一上来就「用 LangChain 搭一个」。筛的是结构化表达和边界意识。答题框架：按「入口 - 理解 - 执行 - 呈现 - 兜底」五段讲。先说数据侧准备（schema 和术语表），再说问答循环，最后讲失败处理。入口和兜底讲得越细，越像做过的人。参考架构与关键决策：用户 CSV └─ 入口层：文件校验（大小上限 100MB、行数上限 100 万）+ 编码探测 └─ 数据准备层（只跑一次，不在对话循环里）： schema 抽取 - 逐列画像（类型/缺失率/基数/样例值） 术语表生成 - 存向量库（"GMV"对应哪几列，靠它对齐黑话） └─ 问答层（每问一轮）： 意图判断：闲聊 / 元数据问题 / 取数分析 / 画图 取数走 Text2SQL，SQL 只在 DuckDB 副本上执行 └─ 呈现层：数字带口径说明，图表默认前 20 行 └─ 兜底层：SQL 报错回灌重试、行数为 0 时反问澄清关键决策带数字：Text2SQL 执行前先过 SQL 解析器校验，只放行 SELECT，拦截一切写操作；单轮对话工具调用上限 8 步；SQL 超时 10 秒熔断；生成结果附「依据哪张表哪些列」的口径，用户能核对。追问链：「CSV 列名是中文乱码或 a、b、c 怎么办？」- 数据准备阶段让模型基于列内容重命名并生成别名映射，查询时用别名，展示时映射回原名。「用户问的问题超出这份数据能答的范围怎么办？」- 检索 schema 后置信度低就明说答不了并建议相近可答问题，不要硬编 SQL。「怎么降低 Text2SQL 的错误率？」- few-shot 给 3 到 5 个「问题到 SQL」示例，加上列画像和术语表，准确率通常能从六成提到八成以上。Q2 工具集怎么设计？粒度、数量、描述怎么定？ ⭐考点定位：工具是 Agent 的手脚，这道题考的是有没有意识到「工具设计比 prompt 调优更影响成功率」。堆 50 个工具上去的方案直接暴露没上过线。答题框架：分三小问答。粒度讲「一个工具等于业务上一个完整动作」；数量讲上限和超了怎么办；描述讲结构化写法。参考架构与关键决策：粒度：一个工具做完一件用户视角完整的事。反例是把「查订单」拆成「调接口」「解析 JSON」「格式化」三个工具，模型平白多两次决策，每一步都是出错机会。数量：单 Agent 工具 5 到 15 个。超过 15 个先怀疑该拆 Agent 或该加工具检索：用向量检索按当前意图选出 Top 3 到 5 个工具再进 prompt，等于把工具选择变成两阶段排序。描述：每个工具写四件事，干什么、什么时候用、什么时候不要用、参数含义和单位。正反边界比正面描述更重要，模型分不清两个相近工具时靠「不适用场景」区分。描述控制在 100 词以内，太长本身也消耗注意力。
场景设计题没有标准答案，评分逻辑也就和手撕题完全不同。面试官手里通常只有一张 checklist：边界条件想没想（步数上限、超时、失败兜底）、数字给不给得出来（工具几个、重试几次、预算多少）、取舍讲不讲得清（为什么单 Agent 不上多 Agent）。答得玄的候选人满地都是，能落出具体数字和分层架构的少，所以这类题的胜负手是「像不像真的上线过」，而不是「背没背过架构图」。本篇围绕 Agent 从 0 到 1 的十个高频场景，每题给一套能直接在白板上展开的答法。题目结构说明：每题四部分。考点定位讲面试官在筛什么；答题框架是开口后的叙述顺序，先说什么后说什么；参考架构与关键决策给一套带数字的方案，数字是记忆锚点，面试时可以微调但要敢说；追问链是讲完后大概率跟上的问题，附一句话答法。标记：⭐ 高频（出现率过半）、🔥 近两年新增。Q1 开放题：设计一个数据分析 Agent，用户上传 CSV 后用自然语言问数 ⭐考点定位：Agent 岗最常见的开场题。它把意图理解、工具设计、SQL 生成、安全、兜底全塞进一个场景，面试官看你能不能在三分钟内给出有层次的方案，而不是一上来就「用 LangChain 搭一个」。筛的是结构化表达和边界意识。答题框架：按「入口 - 理解 - 执行 - 呈现 - 兜底」五段讲。先说数据侧准备（schema 和术语表），再说问答循环，最后讲失败处理。入口和兜底讲得越细，越像做过的人。参考架构与关键决策：用户 CSV └─ 入口层：文件校验（大小上限 100MB、行数上限 100 万）+ 编码探测 └─ 数据准备层（只跑一次，不在对话循环里）： schema 抽取 - 逐列画像（类型/缺失率/基数/样例值） 术语表生成 - 存向量库（"GMV"对应哪几列，靠它对齐黑话） └─ 问答层（每问一轮）： 意图判断：闲聊 / 元数据问题 / 取数分析 / 画图 取数走 Text2SQL，SQL 只在 DuckDB 副本上执行 └─ 呈现层：数字带口径说明，图表默认前 20 行 └─ 兜底层：SQL 报错回灌重试、行数为 0 时反问澄清关键决策带数字：Text2SQL 执行前先过 SQL 解析器校验，只放行 SELECT，拦截一切写操作；单轮对话工具调用上限 8 步；SQL 超时 10 秒熔断；生成结果附「依据哪张表哪些列」的口径，用户能核对。追问链：「CSV 列名是中文乱码或 a、b、c 怎么办？」- 数据准备阶段让模型基于列内容重命名并生成别名映射，查询时用别名，展示时映射回原名。「用户问的问题超出这份数据能答的范围怎么办？」- 检索 schema 后置信度低就明说答不了并建议相近可答问题，不要硬编 SQL。「怎么降低 Text2SQL 的错误率？」- few-shot 给 3 到 5 个「问题到 SQL」示例，加上列画像和术语表，准确率通常能从六成提到八成以上。Q2 工具集怎么设计？粒度、数量、描述怎么定？ ⭐考点定位：工具是 Agent 的手脚，这道题考的是有没有意识到「工具设计比 prompt 调优更影响成功率」。堆 50 个工具上去的方案直接暴露没上过线。答题框架：分三小问答。粒度讲「一个工具等于业务上一个完整动作」；数量讲上限和超了怎么办；描述讲结构化写法。参考架构与关键决策：粒度：一个工具做完一件用户视角完整的事。反例是把「查订单」拆成「调接口」「解析 JSON」「格式化」三个工具，模型平白多两次决策，每一步都是出错机会。数量：单 Agent 工具 5 到 15 个。超过 15 个先怀疑该拆 Agent 或该加工具检索：用向量检索按当前意图选出 Top 3 到 5 个工具再进 prompt，等于把工具选择变成两阶段排序。描述：每个工具写四件事，干什么、什么时候用、什么时候不要用、参数含义和单位。正反边界比正面描述更重要，模型分不清两个相近工具时靠「不适用场景」区分。描述控制在 100 词以内，太长本身也消耗注意力。
