Agent 面试题解析

本章按模块整理 AI Agent 岗位的高频面试题，每道题给出考点分析、参考回答框架和加分要点。题目覆盖 Agent 架构设计、开发框架、RAG 检索、向量数据库、工程实践与应用开发等核心领域，建议结合自身项目经验灵活组织回答。

一、Agent 基础与架构设计

面试题 1：如何设计一个多 Agent 系统？

考点：多 Agent 协作模式理解、架构拆分能力、通信机制设计

参考回答框架：

多 Agent 系统的设计首先要明确协作模式。常见模式有三种：层级式（一个中央调度 Agent 分配任务给子 Agent）、协作式（多个 Agent 平等协作，通过共享记忆或消息传递协调）、竞争式（多个 Agent 各自独立尝试解决问题，择优选用）。

以代码生成场景为例，层级式架构中调度 Agent 接收用户需求，拆解为"需求分析 → 代码编写 → 代码审查"三个子任务，分别交给分析 Agent、编码 Agent、审查 Agent 执行。协作式架构中各 Agent 共享一个工作记忆区，编码 Agent 写完代码后自动通知审查 Agent，审查 Agent 的反馈写入共享记忆供编码 Agent 参考。

关键设计决策包括：Agent 间通信方式（共享记忆 vs 消息队列）、任务分配策略（静态分工 vs 动态路由）、冲突解决机制（当两个 Agent 给出矛盾建议时如何裁决）。还要考虑系统复杂度与效果的平衡——2-3 个 Agent 的简单协作往往比 7-8 个 Agent 的复杂编排更实用。

加分要点：提到实际工程中的踩坑经验，如"多 Agent 系统的调试成本远高于单 Agent，建议先用单 Agent 验证可行性再考虑多 Agent 拆分"。

面试题 2：Agent 的记忆机制如何设计？

考点：对 Agent 长期/短期记忆的理解、状态管理能力

参考回答框架：

工程上通常将记忆划分为四个层级，以匹配信息的生命周期与用途：

感知记忆：处理单次请求的原始输入数据，生命周期极短，通常随当前请求结束即释放。

短期记忆：依赖上下文窗口维护当前会话的完整交互记录。由于窗口容量有限且存在"Lost in the Middle"现象，工程上常用策略包括：

• 滑动窗口截断（保留最近 N 轮对话）
• 对话摘要压缩（用 LLM 把较早历史压缩成摘要，如 ConversationSummaryBufferMemory）
• 基于重要度的选择性保留

长期记忆：跨任务持久化存储，可进一步拆分为：

• 情节记忆：记录具体执行过程
• 语义记忆：沉淀通用规律和知识
• 程序记忆：固化标准操作流程（SOP）

常见实现方式：向量数据库（Milvus、Chroma）存储 Embedding 向量实现语义检索；关系型/KV 存储保存用户画像、任务记录等结构化数据；知识图谱（Neo4j）存储复杂实体关系网络辅助多跳推理。

实体记忆：主动从对话中抽取关键事实（如用户技术栈偏好、项目预算、常用工具等），以高信息密度的结构化字段保存，供后续任务快速加载。

设计核心问题：

• 筛选标准：仅存入能显著提升后续任务表现的数据，过滤中间推理步骤、冗余日志与闲聊内容
• 调用策略：结合"主动预加载"（任务初始化时加载用户画像）与"被动按需检索"（将记忆查询封装为工具，由模型根据上下文调用）
• 更新/遗忘：设置时间衰减权重，定期由 LLM 整理去重、冲突消解，将零散情节提炼为高复用性的语义规则

加分要点：提到开源框架参考——Mem0 提供按用户隔离的向量化与图谱混合服务；Letta 采用操作系统级分层设计，允许模型自主调度核心、缓存与归档存储；Zep 引入时间窗口机制，通过时序图谱自动处理记忆过期。

面试题 3：为什么选择 ReAct 而非纯规划式 Agent？

考点：对不同 Agent 范式的理解、架构选择判断力

参考回答框架：

ReAct（思考-行动-观察循环）的核心优势是动态适应——Agent 可以根据工具返回的实际结果调整下一步行动，而非执行一个可能基于错误假设的固定计划。纯规划式 Agent 先生成完整计划再逐步执行，在信息不完整或环境变化的场景中容易偏离实际。

选择依据：当任务需要与外部环境频繁交互、信息逐步获取时，选 ReAct；当任务步骤确定性强、执行过程不可中断时，纯规划式效率更高。实际中两者常混合使用——先做粗粒度规划，再在每个步骤内用 ReAct 细化执行。

加分要点：提到 ReAct 的推理过程本身就是可观测的调试线索，而纯规划式 Agent 一旦偏离计划，排查根因更困难。

面试题 4：Agent 的安全边界如何设计？

考点：对 Agent 安全风险的理解、防护机制设计

参考回答框架：

Agent 安全的核心风险包括：Prompt 注入（恶意输入操纵 Agent 行为）、工具滥用（Agent 被诱导调用危险工具）、信息泄露（Agent 输出敏感数据）、权限越界（Agent 执行超出预期范围的操作）。

防护机制应多层叠加：输入层做意图检测和恶意 prompt 识别，工具层做权限分级和操作审计，输出层做敏感信息过滤，整体层面设置行动预算（最大步数、最大 token 消耗）防止失控循环。

加分要点：提到"最小权限原则"——每个工具只暴露必要的操作，Agent 的默认状态应该是"能做的不多"而非"限制的不多"。

面试题 5：多 Agent 系统的任务分配与通信机制如何设计？

考点：多 Agent 协作的工程实现细节、通信模式选型

参考回答框架：

架构模式选择：

• 中心化编排：由监督 Agent 负责意图解析、任务拆解与结果汇总。控制流清晰易排查，但监督节点易成性能瓶颈且决策质量决定系统上限
• 去中心化协作：各 Agent 在共享会话中平等交互，适合多角度碰撞场景。需严格设置终止条件以防对话发散或死循环
• 分层架构：采用多级管理（经理 → 组长 → 执行 Agent），通过限制单层管理幅度提升系统横向扩展能力

任务分配策略：

• 静态路由：设计期固定职责边界，运行时按规则分发。行为可预测，适用于标准化业务流程
• 动态路由：监督 Agent 基于语义理解与能力描述进行实时匹配。要求提示词定义精确
• 竞标机制：Agent 根据负载与能力报价竞争任务。因额外增加推理开销与延迟，实际落地较少

通信机制：

• 共享消息列表：全局广播历史记录，实现简单但快速消耗上下文窗口
• 定向状态传递：通过结构化共享状态读写特定字段，减少冗余传输
• 黑板模式：维护预定义结构的全局工作区，Agent 按规则存取中间产物
• 工具化调用：将 Agent 封装为具明确输入输出契约的可调用接口，耦合度最低

加分要点：提到错误隔离——在 Agent 间设置输出校验关卡，阻断上游异常向下游级联放大；规模控制建议维持 3-5 个节点，超过 7 个需引入分层设计。

二、Agent 开发框架与协议

面试题 6：MCP 协议的价值是什么？

考点：对 Agent 工具调用标准化的理解、协议设计的工程思维

参考回答框架：

MCP（Model Context Protocol）的核心价值是标准化 Agent 与外部工具的交互接口。类比 HTTP 协议标准化了 Web 应用间的通信，MCP 标准化了 LLM Agent 与工具/数据源的通信。

没有 MCP 时，每个工具都需要针对每个 LLM 写专门的适配层——LangChain 的工具定义格式、OpenAI 的 Function Calling 格式、各 Agent 框架的自有格式各不相同，工具开发者需要适配多个平台。有了 MCP，工具端只需实现一个标准协议的 MCP Server，任何支持 MCP 的 Agent 框架都能直接调用，大幅降低了工具集成的开发和维护成本。

MCP 协议的设计包含几个关键组件：Tools（可调用的函数接口）、Resources（可读取的数据源）、Prompts（预定义的提示模板）。这种分类让 Agent 能清晰地理解每个 MCP Server 提供什么能力。

加分要点：提到 MCP 当前仍处于早期阶段，实际采用中的挑战包括协议稳定性、工具质量参差、安全沙箱机制不成熟等，展现你对新技术的理性判断。

面试题 7：OpenAI Function Calling 和 Claude Tool Use 有什么区别？

考点：对主流工具调用协议的深入理解、工程适配能力

参考回答框架：

两者核心差异有三点：

1. 工具结果的角色不同：OpenAI 用 role: "tool"，Claude 用 role: "user"。这意味着在 Claude 中，工具结果是"用户消息"的一部分，对话历史管理逻辑需要适配
2. 参数是对象还是字符串：OpenAI 的 arguments 是字符串需要 JSON.parse()，Claude 的 input 是对象可以直接使用。Claude 的设计更安全——避免了模型生成非法 JSON 字符串的问题
3. 混合输出能力：Claude 可以在同一条消息中既输出文本解释又发起工具调用，这让 Agent 的可观测性更好。OpenAI 在调用工具时 content 为 null，丢失了推理解释

从工程角度看，如果需要同时兼容两者，建议在工具执行层之上封装一个统一的抽象层，将不同协议的差异隔离在适配器内部，上层业务代码不感知底层是 OpenAI 还是 Claude。

加分要点：提到多工具场景的分层路由策略——当工具超过 20 个时，先用一个"路由工具"选择类别，再暴露具体工具，提升模型选择准确率。

面试题 8：Skill 系统与 MCP 是什么关系？

考点：对新兴 Agent 能力抽象层的理解、架构分层思维

参考回答框架：

Skill 和 MCP 是互补而非竞争的关系：

• MCP 解决"连接"问题：标准化 Agent 与外部工具/数据源的通信协议
• Skill 解决"能力"问题：封装完整的业务流程和决策逻辑

类比：MCP 是 USB 接口标准，Skill 是插在上面的外设驱动程序——接口让设备能连上电脑，驱动程序让设备能真正工作。

在工程实践中，一个 Skill 通常内部使用 MCP 来连接底层工具。例如"旅行规划 Skill"内部通过 MCP 连接航班查询、酒店预订、天气查询等 Server，但对外暴露的是一个完整的"规划旅行"能力——它知道何时调用哪些工具、如何处理中间结果、如何在失败时降级。

加分要点：提到 Skill 生态的治理挑战——社区贡献的 Skill 中有相当比例存在安全漏洞（Prompt 注入、权限越界等），生产环境使用需经过沙箱测试和代码审计。

面试题 9：Function Calling、Agent 和 MCP 三者的关系是什么？

考点：对工具调用技术栈的分层理解、架构抽象能力

参考回答框架：

三者是不同抽象层次的能力，解决不同范围的问题：

Function Calling（函数调用）

• 大模型通过标准化 JSON 结构向外部系统发送调用指令的交互机制
• 以单次执行为主，依赖开发者提前定义的函数签名与参数模板
• 执行逻辑：模型直接输出调用命令，由上层应用接管实际运行
• 适合轻量级、单步骤或对响应延迟要求极高的应用
• 与特定大模型深度耦合

Agent（智能体）

• 能够自主拆解目标、进行决策并调度工具完成任务的智能化系统
• 融合 RAG 与 ReAct 等架构，支持多轮任务规划、自我反思、状态记忆及多工具协同
• 面向复杂工作流自动化（如代码编写、数据挖掘）或拟人化服务场景
• 资源消耗大，多步推理链易出现偏差且受外部工具稳定性影响

MCP（Model Context Protocol）

• 由 Anthropic 主导的开放通信标准，用于统一大模型与外部数据源或工具的对接方式
• 采用 Host/Client/Server 三层架构，支持动态上下文调度与跨平台集成
• 实现会话级动态工具发现（摒弃硬编码）与权限隔离机制
• 企业级多源数据整合、跨平台协作或需长期维护的底座开发首选

关系总结：Function Calling 是"单次工具调用能力"，Agent 是"自主调度多个工具的决策系统"，MCP 是"让工具可以被任何模型统一调用的协议层"。

加分要点：提到选型建议——低延迟单任务选 Function Calling；复杂决策链选 Agent；多系统整合与标准化对接选 MCP。三者可以组合：Agent 内部用 Function Calling 调工具，工具通过 MCP 协议标准化暴露。

三、RAG 与向量检索

面试题 10：RAG 和微调，什么时候选哪个？

考点：对两种 LLM 增强方式的本质理解、工程决策判断力

参考回答框架：

RAG 和微调解决的是不同问题。RAG解决的是"知识注入"问题——让模型访问它训练数据中没有的外部信息。微调解决的是"行为塑造"问题——让模型在特定任务上表现得更专业、更稳定。

选择决策的核心依据是：如果问题主要是"模型不知道某些信息"（如公司内部文档、最新新闻），选 RAG；如果问题主要是"模型在该任务上表现不够好"（如遵循特定输出格式、采用特定推理风格），选微调。

实际项目中两者常常组合使用。例如客服 Agent 场景：先用微调让模型学会客服对话风格和标准回复格式，再用 RAG 让模型能查询产品手册和用户订单信息。单独只用一种往往不够——纯 RAG 的模型可能检索到信息但无法以正确风格呈现，纯微调的模型可能风格对了但缺少最新信息。

成本维度也要考虑：RAG 的运维成本主要是向量数据库和检索管道，微调的成本主要是数据标注和 GPU 训练资源。对于快速迭代的产品，RAG 的灵活性更高。

加分要点：提到"渐进策略"——先用 RAG 快速验证效果，确认方向正确后再考虑微调做行为优化，避免过早投入微调成本。

面试题 11：RAG 系统中如何提升检索质量？

考点：RAG 工程化能力、检索优化方法论

参考回答框架：

提升 RAG 检索质量是一个系统工程，核心环节包括：

分块策略：块大小直接影响检索质量。经验值 512-1024 tokens 为通用起点，法律/合同等长文本场景可用 1500-2000，问答对等短文本场景用 200-400。更关键的是分块边界——不要在段落中间硬切，应按语义边界分割，可用 semantic-chunking 策略计算相邻句子的 Embedding 相似度，低于阈值处切分。

混合检索：结合向量检索与关键词检索（BM25），取各自优势。向量检索擅长语义匹配，BM25 擅长精确匹配。实际做法是分别检索后做 RRF（Reciprocal Rank Fusion）融合排序，公式为 score = sum(1 / (k + rank_i))，k 通常取 60。

重排序（Reranking）：向量检索的 Top-K 结果往往包含"看起来相关但实际无关"的段落。用交叉编码器（Cross-Encoder）对 query 与每个候选段落做精细相关性打分。推荐先用向量检索召回 20-50 条候选，再用 Reranker 精选 5-10 条送入 LLM。

元数据过滤：纯向量检索不考虑文档的时效性、权限、类别等元数据。在向量数据库中存储元数据字段，检索时附加过滤条件（如 date > 2024-01-01 AND permission = "public"），避免召回过时或无权访问的文档。

加分要点：提到评估指标——不要凭感觉优化，要建立 Recall@K、Precision@K、NDCG@K 等量化指标，用 100-500 条真实查询构成评估基准集，每次优化后跑自动化评测对比。

面试题 12：Embedding 模型如何选型？

考点：对 Embedding 技术的理解、模型选型能力

参考回答框架：

Embedding 模型的选择直接影响检索质量，需从三个维度评估：

常见选项：

• OpenAI text-embedding-3-large：3072 维，语义理解强，适合中英文混合场景，但成本较高
• text-embedding-3-small：1536 维，性价比好，大多数场景够用
• BGE-M3（BAAI）：开源模型，支持多语言和多粒度检索，适合私有化部署
• GTE-Qwen2：阿里开源，中文表现优异，适合中文为主的知识库

选型建议：先在业务数据集上做小规模召回率测试（50-200 条查询），不要仅看模型排行榜——排行榜数据集与你的业务数据分布很可能不同。

加分要点：提到 Embedding 微调——如果业务领域非常垂直（如医疗、法律），通用 Embedding 可能无法捕捉领域术语的细微差别，此时在领域语料上微调 Embedding 模型往往比换更大的通用模型更有效。

面试题 13：什么是 Self-RAG、CRAG 和 Graph RAG？它们解决了什么问题？

考点：对 RAG 高级变体的理解、技术演进敏感度

参考回答框架：

Self-RAG（自反思检索增强） 模型在生成过程中自主评估检索资料的质量，输出评估标记决定是否需要补充检索。解决了传统 RAG"单次召回不足就硬答"的问题——当检索结果置信度低时，Self-RAG 会主动触发额外检索而非直接基于低质资料生成。

CRAG（纠正性检索增强） 当系统判定检索结果置信度过低时，自动触发网络搜索或知识图谱推理等降级纠错流程。与 Self-RAG 的区别在于：CRAG 更强调"纠错动作"——不仅判断资料好坏，还会主动寻找替代信息源。

Graph RAG（图检索增强） 将文档中的实体与关系构建成知识图谱，检索时通过图遍历获取子图再转为文本上下文。与传统 RAG 的核心差异：传统模式依赖纯向量相似度，多跳推理弱且仅返回片段；Graph RAG 支持关系链推导，可解释性强，返回完整推理路径，极适合复杂关联查询（如"某药物的所有副作用及相互作用"）。

应用定位：三者均为金融、医疗、法律等高可靠性场景的核心优化方案。Self-RAG 和 CRAG 解决"检索质量不稳定"问题，Graph RAG 解决"多跳关联推理"问题。

加分要点：提到 Graph RAG 的代价——构建和维护知识图谱的成本远高于纯向量检索，仅在确有复杂关联查询需求的场景才值得投入。

面试题 14：RAG 中的文档分块策略如何设计？

考点：RAG 工程细节、文档预处理能力

参考回答框架：

主流分块策略：

• 固定长度切分：按固定 token 数切割，实现简单但容易在段落中间切断语义
• 递归分割：先按大段落切分，过长段落再按句子递归切分，兼顾完整性与粒度
• 语义分割（semantic-chunking）：计算相邻句子的 Embedding 相似度，低于阈值处切分，保证每个块内部语义连贯
• 结构分割：按标题、表格、章节等文档结构切分，适合 PDF/Word 等格式化文档
• 父子块模式：小块用于精确检索，大块用于生成上下文（"小检索大生成"），兼顾召回率与上下文完整性

参数建议：

• 通用技术文档：512-1024 tokens，重叠区 100-200 tokens
• 法律/合同等长文本：1500-2000 tokens
• 问答对/FAQ：200-400 tokens
• 重叠比例建议控制在 10%-20%，维持语义连贯

调优方法：通过对照实验测试不同尺寸与重叠率的组合，结合业务反馈锁定最优配置。不要凭直觉定参数。

加分要点：提到"分块边界比分块大小更重要"——在段落中间硬切会导致检索结果丢失关键上下文，按语义边界分割即使块大小略有波动，检索质量也更好。

四、向量数据库与工程基础

面试题 15：向量数据库选型时需要考虑哪些因素？

考点：对向量数据库生态的理解、基础设施选型能力

参考回答框架：

向量数据库选型需考虑以下因素：

数据规模与性能：百万级文档可用开源方案（Milvus、Weaviate、Qdrant），亿级以上或高并发场景考虑托管服务（Pinecone、Zilliz Cloud）。要实测写入吞吐和查询延迟，不要只看官方 benchmark。

混合检索支持：生产环境几乎都需要"向量相似度 + 关键词过滤"的组合查询，确保选型支持 metadata filtering 和 hybrid search。Milvus、Pinecone、Weaviate 都支持，但语法和性能差异较大。

部署与运维：私有化部署选 Milvus（K8s 生态成熟）或 Qdrant（轻量易部署）；无运维团队选托管服务。要考虑数据备份、索引重建、版本升级等运维成本。

成本模型：开源方案主要成本是服务器资源，托管服务按数据量+查询量计费。小规模场景托管服务更省心，大规模场景自托管成本更低。

加分要点：提到"不要过度设计"——很多项目早期用 pgvector（PostgreSQL 插件）就能满足需求，等数据量到百万级再迁移到专用向量数据库，避免过早引入运维复杂度。

面试题 16：如何处理 Agent 的工具调用失败？

考点：鲁棒性设计思维、异常处理能力

参考回答框架：

工具调用失败是 Agent 运行中的常态而非例外。处理策略包括：

• 重试机制：同一工具短暂失败后重试，设置最大重试次数（通常 3 次），对可恢复错误（网络超时、429 限流）做指数退避重试
• 降级策略：主工具失败后切换到备用工具或简化方案（如实时查询失败时返回缓存数据并标注"数据可能非最新"）
• 反馈学习：将失败信息反馈给 LLM，让它重新规划和选择替代行动
• 优雅降级：所有工具都失败时，Agent 应坦诚告知用户当前能力受限而非胡编答案

关键设计原则是不要把工具失败当作异常情况，而是当作 Agent 正常运行中需要处理的常规事件。在 Agent 的提示词中明确告知"工具可能返回错误结果或失败，你应该根据错误信息调整下一步行动"。

加分要点：提到错误分级体系——Level 0（可忽略，部分数据缺失）→ Level 1（可重试，暂时性错误）→ Level 2（需要替代，工具不可用）→ Level 3（需要人工介入，权限/冲突问题），不同级别对应不同的 Agent 处理策略。

五、Agent 工程实践

面试题 17：如何评估 Agent 的效果？

考点：评估方法论理解、指标设计能力、对 Agent 评估特殊性的认知

参考回答框架：

Agent 评估比传统 LLM 评估复杂得多，因为 Agent 的输出不只是一段文本，而是包含推理过程、工具调用、多步决策的完整行为轨迹。

核心评估维度有四个：任务完成率（Agent 是否最终解决了用户的问题）、步骤效率（Agent 用了多少步才完成任务，过多的步骤说明规划能力不足）、工具使用准确率（Agent 选择和调用工具是否正确）、成本效率（完成任务消耗的 token 量和 API 调用次数）。

具体评估方法：对于确定性任务（如信息查询），可以用自动化测试集对比 Agent 输出与标准答案。对于开放性任务（如创意写作辅助），需要人工评估或用 LLM-as-judge 方法。重要的是评估 Agent 的鲁棒性——在模糊输入、工具失败、信息不足等边界情况下 Agent 是否还能合理应对。

一个实用建议是建立"阶梯测试集"：从简单单工具调用 → 中等多工具组合 → 复杂多步推理，逐级测试 Agent 能力边界，找到它的能力上限和退化点。

加分要点：提到评估不应只看单次结果，还要看 Agent 在多次运行中的稳定性（同一个问题跑 5 次，几次能得到正确答案），以及多轮对话中的上下文一致性。

面试题 18：Agent 在生产环境中的主要挑战是什么？

考点：工程落地经验、对生产级要求的认知

参考回答框架：

核心挑战包括：

• 延迟管理：多步 Agent 推理的响应时间远超单次 LLM 调用，用户可接受的响应时间通常在 1-3 秒，而复杂 Agent 任务可能需要 10-30 秒。解决方案包括流式输出（让用户看到中间进展）、异步执行（对复杂任务走后台处理+通知机制）、步骤并行化（能并行的工具调用同时发起）
• 稳定性保障：LLM 输出的不确定性导致 Agent 行为不可预测，同一问题多次运行可能得到不同结果。解决方案包括温度参数调低、输出格式强制约束（JSON Schema）、关键节点增加人工确认
• 可观测性：Agent 的决策链路复杂，排查问题困难。需要记录完整的 Thought-Action-Observation 轨迹，每个工具调用的输入输出，以及每次 LLM 调用的上下文
• 成本控制：多步推理的 token 消耗是乘法级增长。需要模型分层（简单判断用小模型）、缓存策略、提前终止机制
• 安全合规：Agent 自主调用外部工具带来权限和数据安全风险，需要审计日志、权限分级、敏感数据脱敏

加分要点：提到这些挑战"不是单纯靠更好的 LLM 来解决"——再强的模型也需要工程层面的延迟优化、稳定性保障和可观测性建设。

面试题 19：如何降低 Agent 的推理成本？

考点：工程优化思维、成本意识

参考回答框架：

主要优化方向：

• 模型选择分层：简单判断（如意图分类、工具选择）用小模型（GPT-3.5 级别），复杂推理（如代码生成、多步规划）用大模型。通过路由层根据任务复杂度动态选择模型
• 缓存策略：相似查询复用历史结果（用向量相似度判断"这个问题是否问过"）、工具返回结果缓存（如天气查询结果 10 分钟内有效）
• 提示压缩：精简系统提示（去掉冗余描述）、用摘要替代完整历史（只保留关键决策点和当前上下文）
• 工具结果精炼：工具返回的大量数据先做提取和压缩再送入 LLM，避免上下文窗口被无关内容浪费
• 提前终止：设置置信度阈值，Agent 确信已获得答案时提前结束循环，而非继续执行剩余计划步骤

加分要点：提到成本监控——为每个 Agent 任务记录 token 消耗和 API 调用次数，建立成本基线，当某个任务类型成本异常增长时自动告警。

六、Agent 应用开发

面试题 20：如何设计一个智能客服 Agent？

考点：垂直场景应用设计能力、端到端系统思维

参考回答框架：

智能客服 Agent 的设计可分为五个层次：

意图理解层：识别用户问题的真实意图，区分"咨询类"（产品信息、价格）和"操作类"（退款、修改订单）。对模糊输入做澄清追问，避免误解意图导致错误操作。

知识检索层：用 RAG 接入产品手册、FAQ、订单数据。关键优化点：对用户 query 做扩展改写（如"怎么退"→"退款政策/退货流程"）、用元数据过滤确保只检索用户有权查看的内容、对检索结果做相关性阈值过滤避免送噪声进 LLM。

工具执行层：封装订单查询、退款申请、物流跟踪等工具。每个工具要有严格的权限校验和操作审计，涉及资金/敏感信息的操作需要二次确认。

对话管理层：维护多轮对话状态，处理上下文切换（用户突然换话题）、意图澄清（"您是指 A 还是 B？"）、会话恢复（断线后重新连接）。

兜底策略层：当置信度低于阈值或遇到未训练场景时，优雅转人工，并携带完整的对话上下文和已尝试的解决方案。

加分要点：提到客服场景的评估特殊性——不仅要答对，还要考虑"是否让用户满意"（语气、响应速度、是否一次性解决问题），这些往往比准确率更重要。

面试题 21：Agent 在代码生成场景中的关键技术点是什么？

考点：代码类 Agent 的专项设计能力

参考回答框架：

代码生成 Agent 的关键技术点：

上下文管理：代码生成极度依赖上下文——文件结构、已有代码、依赖关系。需要将相关代码片段（而非整个仓库）精准送入 LLM，避免上下文窗口浪费。常用策略：先用代码结构摘要定位相关文件，再提取具体函数的上下文（定义+调用链）。

执行验证：生成的代码必须能运行且通过测试。建议为 Agent 配备沙箱执行环境（Docker 容器），让 Agent 能自行运行代码、查看报错、迭代修复。这是代码 Agent 区别于通用文本 Agent 的核心能力。

工具链集成：Agent 需要调用编译器、测试框架、代码分析工具（linter、类型检查）。这些工具的输出要结构化解析后反馈给 LLM，而非直接塞入原始终端输出。

增量修改：大多数场景不是从零写代码，而是修改现有代码。Agent 需要学会生成 diff 或 patch，而非完整文件重写，减少不必要的变更。

加分要点：提到 SWE-Agent 类系统的核心洞察——"让 Agent 像程序员一样工作"（读代码 → 理解 → 修改 → 测试 → 提交），而非"让 Agent 直接输出答案"。

面试题 22：Agent 的流式输出与用户体验如何设计？

考点：前端交互设计思维、用户体验意识

参考回答框架：

Agent 的 UX 设计核心是让用户感知到进展，而非面对空白等待。

流式输出设计：LLM 的生成结果应实时展示，用户看到文字逐字出现会比等待完整答案感觉更快。对于多步 Agent，应展示当前步骤的状态（"正在搜索相关知识..."、"正在调用计算工具..."），让用户理解系统在做什么。

中间状态可视化：Agent 的思考过程（Thought）、工具调用（Action）、观察结果（Observation）可以选择性展示。对于技术型用户，展示完整推理链增强可信度；对于普通用户，简化为进度条+关键节点提示。

错误与重试的透明化：当工具调用失败时，不要只显示"出错了"，而应说明"数据库查询超时，正在重试..."或"未找到相关信息，尝试用其他关键词搜索...」。这种透明化让用户感知到 Agent 在积极应对，而非僵死。

人工介入点设计：在关键决策节点（如执行资金操作、删除数据前）设置确认弹窗，让用户有掌控感。同时提供"停止"按钮，用户可随时中断 Agent 的自动执行。

加分要点：提到" perceived performance "（感知性能）比实际性能更重要——同样的延迟，有进度提示的体验远优于空白等待。

本章小结

面试回答原则：

1. 结构化表达——用"首先...其次...最后"或分层框架组织回答
2. 结合项目经验——理论+实际踩坑经历最有说服力
3. 展现权衡思维——没有银弹，每个选择都有 trade-off
4. 关注前沿——适当提及 MCP、A2A、Skill 系统等新兴方向，展现持续学习

📖 延伸阅读

1. Machine Learning Interviews —— ML 面试题汇总
2. LLM Interview Questions —— LLM 专项面试题
3. System Design for ML —— ML 系统设计
4. MLOps Interview Questions —— MLOps 面试题