10、典型业务场景设计题

Q10-1. 如果让你设计一个企业知识库问答系统，你会怎么做？

通常按“数据接入、检索链路、生成链路、治理能力”四层设计。

先把文档接入、解析、切块、向量化和索引更新机制搭好，再设计查询链路，包括 query 改写、混合检索、rerank、权限过滤和上下文组装。生成层要强调“基于证据回答、无依据时拒答、尽量带引用”。治理层则要补上权限、版本、监控、评测和 badcase 回灌。

如果是企业场景，通常还会预留转人工、知识修订、索引回滚和多租户隔离能力，因为这些往往比“第一次答对”更影响长期可用性。

常见追问：

• 如何支持知识更新？
• 如何避免用户问到权限外文档？
• 如果系统答非所问，优先排查哪里？

重要度：必刷（出现次数：1次） | 难度：较难

**考察点：**从需求到架构的完整表达能力。

对应章节：2-RAG 搭建企业私有&个人知识库 §5、使用 Dify 搭建知识库；19 RAG检索增强生成 §3、RAG 综合案例：智能运维助手

Q10-2. 如果让你设计一个 NL2SQL Agent，你会重点控制哪些风险？

重点应控制 schema 注入、SQL 安全、执行验证和歧义澄清四类风险。

首先不能把整个数据库 schema 全量塞进上下文，而是要按问题做裁剪和 schema linking。其次要限制只读查询、禁止危险语句、加执行沙箱和超时控制。再次要做语法检查和执行前校验，避免生成看似合理但跑不通的 SQL。最后，对时间范围、口径定义、字段歧义这类问题，要支持澄清，不要让模型自行脑补。

常见追问：

• 生成 SQL 前要不要先展示预览？
• 如何做 self-correction？
• 什么时候该放弃生成 SQL，转人工或转报表模板？

重要度：高频（出现次数：1次） | 难度：较难

**考察点：**结构化查询和安全意识。

Q10-3. 如果让你设计一个客服智能体，你会优先考虑哪些能力？

优先考虑意图识别、知识检索、流程执行、人机协同和复盘闭环。

客服场景不是简单问答，它往往同时涉及 FAQ、订单查询、退款流程、工单流转和情绪安抚。所以系统既要能回答，也要能查状态、调接口、补资料，还要在不确定时及时转人工，并把上下文完整交接过去。

上线后还要持续复盘高频未解决问题、误判意图、知识缺口和转人工原因，这样系统才会越做越稳，而不是只在演示时好看。

常见追问：

• 转人工条件怎么设计？
• 客服场景为什么更需要长期记忆或用户画像？
• 如何做满意度和闭环评估？

重要度：高频（出现次数：1次） | 难度：较难

**考察点：**业务型 Agent 设计能力。

对应章节：3 基于Coze&Dify平台的智能体开发 §7、项目：商户运营管家；21 Agent智能体 §5、实操与案例

Q10-4. 如何设计 Agent 的完成判断与终止条件，避免过早结束？

Agent 的“结束”不能只靠感觉，也不能只靠看日志或一个宽泛的完成率分数。更稳的做法是给它设计显式的完成条件。

终止逻辑通常拆成四层：

• 任务层：是否达成用户目标，是否拿到了必须的产物或字段。
• 工具层：关键工具调用是否成功，返回结果是否满足预期约束。
• 状态层：当前 state 是否进入 done / failed / need_human 这样的终态。
• 保护层：最大步数、超时、重复无进展次数、异常退出条件。

如果链路里有 Supervisor 或监督节点，更适合把它当“辅助审查”和“异常兜底”，而不是唯一的结束依据。真正稳的方案是：只有当关键任务结果、工具返回和状态机条件都满足时，才允许进入最终答复节点。否则宁可继续执行、澄清或转人工，也不要过早把未完成结果返回给用户。

常见追问：

• 只靠监督节点统计完成率和查日志，为什么会慢、还容易误判？
• 有没有更通用的判断方式，比如直接看关键工具调用结果和状态字段？
• 如何避免 Agent 任务还没做完，就提前返回给用户？

重要度：高频（出现次数：1次） | 难度：较难

**考察点：**Agent 终止条件设计、状态机思维，以及 Supervisor / 工具结果 / 状态字段的组合使用能力。

对应章节：24 LangGraphAPI：节点、边与进阶 §2、Graph API 之 Edge；21 Agent智能体 §4、Agent 工作原理（V1.0）

Q10-5. Code Agent 怎么设计？

Code Agent 的核心不是“会写几行代码”，而是能围绕一个代码任务完成 读代码库、定计划、改文件、跑验证、根据结果继续修正 的闭环。从系统结构看，它本质上仍然是一个 模型 + 工具集 + 运行循环 + 当前状态 的执行系统，只不过工具和状态都更偏代码场景。

如果按模块拆分，通常设计为以下几层：

• 任务理解层：先把需求转成明确目标，判断是读代码、改 bug、补测试、重构，还是回答架构问题。
• 代码库理解层：通过代码搜索、文件树、符号索引、依赖关系、提交历史建立最小必要上下文，而不是把整个代码库一股脑塞进模型。
• 计划与执行层：先列出修改计划，再决定读哪些文件、改哪些文件、跑哪些命令、需要哪些验证。
• 工具层：至少要有搜索、读文件、编辑文件、运行测试、执行命令、查看日志这些能力。
• 反馈闭环层：根据 lint、测试、运行报错、diff 结果继续修正，而不是生成一次补丁就结束。
• 安全治理层：限制执行权限、隔离危险命令、保留变更和执行日志，避免 Agent 在代码库里无约束乱改。

真正的难点通常不在“会不会生成代码”，而在三个地方：

• 上下文治理：代码库很大时，怎么只拿到和当前任务最相关的上下文。
• 验证闭环：怎么判断修复真的生效，而不是只让模型说“我已经改好了”。
• 失败处理：当 Agent 连续修不好 bug 时，怎么停下来、怎么暴露中间诊断、怎么交还给人。

所以一个成熟的 Code Agent，更接近“面向代码任务的执行系统”，而不是“代码自动补全工具放大版”。它的关键不只是会写代码，而是能把 代码库理解、工具调用、验证反馈、停止条件 做成稳定闭环。

常见追问：

• 千万行代码库里，Code Agent 最容易先卡在哪里？
• Agent 修不好 bug 时，你怎么设计停止条件和人工接管？
• 静态知识和动态数据在代码场景里怎么区分，哪些该靠索引，哪些该靠运行反馈？

重要度：高频（出现次数：1次） | 难度：较难

**考察点：**代码场景下的 Agent 设计能力、代码库上下文治理能力，以及“修改 - 验证 - 继续修复”的闭环意识。

Q10-6. 如果让你设计一个 Deep Research 系统，它和普通 RAG 有什么不同？

普通 RAG 更接近“先检索，再回答”，而 Deep Research 更接近“围绕一个复杂主题，先拆研究任务，再多轮检索、交叉验证、综合整理，最后输出结构化报告”。

因此，Deep Research 通常需要查询规划、子任务拆分、多源检索、冲突检测、引用管理、可信度判断和迭代补检这些能力。它更接近研究助手，而不是问答助手。输出形式也更偏报告、摘要和引用列表，而不是一句直接答案。

如果按工程实现去理解，它本质上更接近“工作流 / 图编排 + 多轮检索 + 报告生成”的组合能力，而不是把普通 RAG 的上下文塞得更长。重点不只是召回，而是有没有把研究过程拆开、证据有没有被反复求证、最后能不能形成带引用的结构化结论。

常见追问：

• 如何保证结果可靠？
• 什么叫多源交叉验证？
• 这类系统为什么更需要人工审核点？

重要度：中频（出现次数：1次） | 难度：中等

**考察点：**复杂检索与报告生成理解。

Q10-7. 如何设计一个 Deep Research 系统？

Deep Research 的核心不是“查一次资料再总结”，而是“围绕复杂问题持续研究并形成结构化结论”。

一个比较完整的设计通常包括：

• 查询规划器：把复杂问题拆成子问题。
• 检索执行器：面向搜索、数据库、知识库做多源检索。
• 信息融合层：做去重、冲突检测、证据对齐和可信度加权。
• 迭代控制器：发现证据不足时继续补检，而不是一次性结束。
• 报告生成器：输出摘要、正文、引用和时间戳。

如果采用更工程化的表达方式，可以将其理解为一个研究型工作流：

• 前面是任务拆解和检索编排。
• 中间是多轮证据收集、去重、冲突处理。
• 后面是结构化报告生成和引用整理。

它和普通 RAG 最大的差异，是从“单轮问答”升级成“多轮研究流程”。所以设计重点不只是召回率，还包括规划质量、引用质量、可信度和过程可回放性。真正落地时，通常也更倾向于用 Workflow 或 LangGraph 这类显式编排方式来做，而不是把它完全交给一个黑盒对话 Agent。

重要度：中频（出现次数：1次） | 难度：较难

**考察点：**复杂研究型系统的模块拆分能力。

Q10-8. 如何设计 Python 代码解释器？

Python 代码解释器本质上是“模型生成代码 + 安全执行 + 回传结果”的闭环系统。

核心设计通常包括：

• 代码生成层：模型把用户需求转成 Python 代码。
• 沙箱执行层：隔离环境、白名单模块、超时限制、资源限制。
• 结果回传层：收集 stdout、stderr、文件产物、图表和返回值。
• 状态管理层：支持多轮执行时保留变量或工作目录。
• 安全治理层：禁止危险系统调用、网络访问和越权读写。

这类系统真正的难点不在“会不会运行 Python”，而在“如何既让它有执行能力，又不把宿主环境暴露出去”。

常见追问：

• 如果 Agent 需要执行系统命令或访问文件，你怎么防止它越权删除数据库、读取主机敏感文件？
• 除了白名单，你在宿主环境隔离上还会做哪些限制？

重要度：中频（出现次数：1次） | 难度：较难

**考察点：**执行型智能体和安全沙箱设计。

对应章节：17 Tools工具调用 §6、从课程案例走向真实项目；21 Agent智能体 §5、实操与案例

Q10-9. 如何设计类 Manus 通用智能体？

这类系统不宜先强调“通用”，而应先回到 Agent 的最小骨架：模型 + 工具集 + 运行循环 + 当前状态。所谓类 Manus，本质上是把这四层能力扩展到更长任务链和更复杂任务空间中。

设计上通常要有：

• 任务理解与规划模块：把目标拆成可执行步骤。
• 工具调度模块：统一接搜索、浏览器、代码执行、文件系统等工具。
• 状态与记忆模块：维护任务上下文、待办和阶段成果。
• 执行与反思模块：根据中间结果继续执行、修正或重试。
• 安全与治理模块：权限控制、日志、失败恢复和人工接管。

这类系统和普通 Agent 的区别，不在于“工具更多”，而在于它需要长期推进任务、处理中间产物、管理复杂状态，并在较长链路里维持稳定性。因此，它更接近一个通用任务执行框架，而不是单轮问答机器人的放大版。

重要度：中频（出现次数：1次） | 难度：较难

**考察点：**通用任务型 Agent 的系统拆分能力。

Q10-10. 如何开发浏览器自动化 Agent？

浏览器自动化 Agent 的核心是把“看页面、理解页面、操作页面、校验结果”做成一个稳定闭环。

一个比较合理的设计通常包括：

• 页面感知层：拿到 DOM、截图、可交互元素信息。
• 决策层：根据目标决定点击、输入、滚动、等待还是回退。
• 执行层：调用浏览器自动化工具完成动作。
• 校验层：确认动作是否生效，页面是否进入预期状态。
• 治理层：超时、重试、幂等、防误操作和日志回放。

这类 Agent 最大的难点不在“会不会点按钮”，而在网页不稳定、异步加载、状态漂移和误操作成本高，所以一定要把验证和回滚意识做进去。

重要度：中频（出现次数：1次） | 难度：较难

**考察点：**浏览器工具、任务规划和可靠性设计。

Q10-11. 当 Agent 需要在真实或模拟环境中执行任务时，它和纯软件工具型 Agent 有什么本质区别？

最大的区别在于：软件型 Agent 主要在数字系统里操作，输入输出更结构化，可回放性也更强；而真实或模拟环境里的 Agent，面对的是感知噪声、状态不完备、实时反馈和物理世界副作用。

也就是说，纯软件工具型 Agent 更接近“调接口、读写数据、操作页面”，重点是权限、状态机和工具编排；真实环境 Agent 则多了感知、定位、动作执行和安全约束，很多时候不是“调用成功”就算完成，而是还要判断动作有没有真正生效、环境有没有变化、风险是否可控。

所以这类系统会更强调闭环感知、实时性、仿真验证、失败保护和人工接管。它本质上不是把工具再多接几个，而是把 Agent 从“信息处理系统”推进到了“感知-决策-行动闭环系统”。

重要度：中频（出现次数：1次） | 难度：较难

**考察点：**对“软件型 Agent”和“行动型 / 具身环境 Agent”边界的理解。