核心概念 · 架构设计 · 多智能体 · RAG · 评估与落地 · 提示词工程一、核心概念与架构篇Q1：请简述 Agent 的基本架构组成，并解释其与传统 LLM Chain 的区别。答案：Agent 本质是"LLM 核心 + 三大辅助模块"的综合体，即LLM（基础能力底座）+规划（Planning，任务拆解与路径规划）+记忆（Memory，会话与经验存储）+工具使用（Tool Use，外部能力扩展）。四大模块协同，让 Agent 具备自主决策与执行能力。与传统 LLM Chain 的核心区别：维度LLM ChainAgent驱动方式固定流程驱动，线性硬编码目标驱动自主决策灵活性步骤不可动态调整通过 Reasoning Loop 动态调整策略异常处理按预设流程执行，无法自适应工具失败会自动重试或切换工具适用场景标准化、固定步骤任务复杂多变、非结构化任务Q2：解释 ReAct 模式的工作原理。答案：ReAct（Reasoning + Acting，推理 + 行动）是 Agent 实现自主决策的核心基石，打破了"先思考完再行动"的割裂模式，采用"边想边做"的迭代逻辑，让 Agent 的行为更可控、可追溯。具体工作流程：LLM 基于当前任务和上下文生成推理过程（Thought），明确"下一步要做什么、为什么这么做"执行对应行动（Action），调用指定工具获取观察结果（Observation）将观察结果反馈至上下文，进入下一轮"推理-行动-观察"循环，直至完成任务或达到终止条件Q3：如何实现 Agent 的长期记忆（Long-term Memory）？答案：Agent 的记忆体系分为短期与长期，二者协同保障任务连续性，长期记忆的核心是突破上下文窗口限制，留存历史经验与知识：短期记忆：依赖 Context Window，存储当前会话的 Chat History 和即时任务状态，仅在当前会话有效，窗口满后会被截断。长期记忆：主流方案是结合 RAG 技术，将 Agent 的历史经验、领域知识、任务记录等编码为 Embedding 向量，存入向量数据库（如 Milvus、Pinecone）；执行新任务时通过"经验检索"调取相关内容补充至上下文。★ 2026 新趋势：一是利用长文本模型（Long-context LLMs）直接处理数万甚至数十万 Token 的超长历史，减少检索依赖；二是通过"摘要层级结构"递归压缩记忆，既节省存储又提升检索效率。Q4：Agent 和 Prompt Chain 有什么本质区别？ChatBot 加上插件是不是就变成 Agent 了？答案：Prompt Chain：固定代码顺序执行，无基于观察结果的再决策循环。如固定三步的 RAG 流水线（Query 改写 → 向量检索 → 总结生成），没有失败分支处理，更像 Prompt Chain。Agent：闭环迭代，每步可根据工具返回结果动态调整下一步。如果加入了多轮检索策略（查不到就换词再查），并包含失败分支处理，这才接近 Agent。关于 ChatBot + 插件：如果插件调用由固定规则触发（如关键词路由），更像"带工具的 Bot"；如果由模型在多步推理中自主选择工具与参数，并形成闭环迭代，才真正接近 Agent。关键在于是否具备多步自主决策与反馈闭环。Q5：多 Agent 协作系统（Multi-Agent）和"单 Agent + 多工具"怎么选？答案：单 Agent + 多工具：实现简单、延迟低。适合任务边界清晰、模型依靠自身能力就能统筹所有工具的场景。多 Agent：适合需要角色分工、并行探索或对抗审查的场景（如：一个 Agent 写代码，另一个专门负责挑错）。缺点是协调成本高、数据一致性问题。选型核心：看任务的分解结构、组织的边界、以及对延迟和 Token 成本的敏感度。Q6：Agent 的记忆一般怎么设计？只用向量数据库够吗？答案：分层设计最常见：工作记忆：当前任务轨迹和关键结论会话记忆：摘要滚动，避免上下文过长长期记忆：向量检索 / 结构化库存储历史信息只用向量库不够。向量检索擅长模糊语义相似度，但在精确约束和关系推理上非常弱。实际工程中通常是混合架构：向量库：处理长文本和非结构化知识关系型数据库：处理精确的订单、时间状态图数据库：处理复杂的人物 / 事件关系（按需）Q7：你会如何设计 Agent 的"停止条件（Stop Condition）"？答案：在工程中绝对不能只依赖单一条件，必须组合使用：类型说明正常完成模型自主声明 finish目标达成任务清单（To-Do List）状态全部变为 Done硬性护栏达到最大步数（Max Steps）或 Token 预算上限死循环拦截检测到连续无进展的重复动作超时控制整体任务耗时超过阈值外部信号如自动化测试用例全部通过Q8：工具描述（Tool Description）为什么非常重要？答案：因为大模型完全是依靠描述来做路由和工具选择的！这相当于大模型的"API 文档"。描述不清会导致模型选错工具，或者凭空捏造参数（参数幻觉）。好的描述必须包含：这个工具是干嘛的、何时用、何时不用、参数的具体含义、错误调用的示例，以及预期的返回格式。二、多智能体协同（Multi-Agent Systems）Q9：单 Agent 遇到瓶颈时，为什么需要 Multi-Agent？常见的协作模式有哪些？答案：单 Agent 的瓶颈核心是"能力边界有限"：在处理复杂、跨领域、长周期任务时，容易出现注意力漂移、推理链断裂、技能不足等问题，而 Multi-Agent 通过分工协作突破单一个体的能力局限。常见协作模式：模式核心逻辑适用场景中心化（Boss-Worker）主 Agent 负责拆解、分配与汇总，子 Agent 无自主决策权结构化任务，如项目管理拆分需求分配给代码、测试、文档 Agent流水线（Pipeline）前一个 Agent 的输出作为后一个的输入，形成闭环流程化任务，如代码生成→审查→Bug修复→部署验证民主协作（Joint Discussion）多个 Agent 同等权限，共同讨论碰撞观点，达成一致结论开放式、多维度思考任务，如技术方案评审、复杂问题归因分析Q10：多智能体系统中如何解决"无限循环"或"通信冗余"问题？答案：需从流程控制、内容优化、条件约束三方面解决：循环检测与控制：引入状态机管理每个 Agent 的运行状态，设置最大迭代次数（如单任务交互不超过 10 轮），达到阈值时自动中断，由主 Agent 重新分配或调整策略。Token 与内容压缩：对 Agent 间的对话内容进行实时摘要，提取核心信息，剔除冗余表述；同时限制单轮对话的 Token 上限。明确终止条件：提前定义任务完成、中断、重试的标准，如"结果满足预设指标"“无新信息产出”，触发时立即终止交互。Q11：详细解释"编排者-执行者（Orchestrator-Workers）"模式。答案：该模式是中心化协作的进阶版，核心是"专业化分工 + 精细化管控"，适用于大型复杂任务的拆解与执行，是工业界落地 Multi-Agent 的主流模式之一。主 Agent（Orchestrator）具备三大核心能力：任务拆解：将复杂任务拆分为可执行的子任务，明确每个子任务的目标、范围、输出格式技能匹配：根据子任务类型，分配给具备对应 Skill 的 Worker Agents结果聚合与校验：汇总所有子任务结果，校验一致性与完整性，若存在问题则回溯调整核心难点：任务分解的粒度控制。粒度太细会导致 Agent 间通信成本剧增；粒度太粗则 Worker 难以精准执行，易产生理解偏差与幻觉。三、Agent 核心设计模式（Design Patterns）Q12：请对比"工作流（Workflows）"与"自主智能体（Autonomous Agents）"的优劣。答案：二者核心差异在于"决策主体"，适用于不同场景，无绝对优劣，按需选型：维度工作流（Workflows）自主智能体（Autonomous Agents）决策主体DAG / 状态机硬编码LLM 自主决定优点高可靠性、结果可预期、易排查极高灵活性，适配开放式任务缺点无法应对未预设异常场景结果不可控，易产生幻觉，运维成本高适用场景报销审批、固定话术客服、数据同步科研探索、个性化代码、复杂问题诊断★ 面试金句（2026 工程趋势）：当前工业界的最优实践是"用 Workflow 约束 Agent"，即在工作流定义的核心路径与边界内，给予 Agent 局部决策权，兼顾可靠性与灵活性。Q13：什么是"反思 / 自我纠正（Reflection / Self-Correction）"模式？答案：反思模式是提升 Agent 任务成功率的核心优化手段，本质是让 Agent 具备"自我审视、迭代优化"的能力，通过对过往输出的复盘，修正错误、规避重复问题，形成闭环进化。核心实现逻辑：Agent 生成初步输出后，由专门的"批评者 Agent（Critic）"或自身切换为批评者角色，对照任务目标检查输出识别错误、漏洞或优化点，生成具体反馈原 Agent 根据反馈迭代修改，直至满足要求可基于Reflexion 架构落地，核心是记录"失败轨迹"并纳入长短期记忆——将每次错误原因、修正方案编码存储，遇到同类任务时优先检索历史失败经验，避免重复踩坑。四、深度技术实现与状态管理Q14：在多轮对话 Agent 中，如何处理"状态爆炸"和"上下文溢出"？答案：状态爆炸指多轮交互中状态过多导致管理混乱；上下文溢出指信息超过 Context Window 上限。二者需结合结构化管理、语义优化、内容压缩三重方案解决：状态结构化（State Schema）：定义严格的状态数据结构（如 LangGraph 的 TypedDict、Pydantic 模型），仅保留核心变量，剔除无关冗余状态。语义修剪策略（Trim Strategy）：基于语义重要性筛选保留——优先保留 System Prompt、当前任务目标、最近 N 轮关键对话，删除重复表述、已完成步骤的细节信息。摘要缓冲机制（Summary Buffer）：对早期对话内容进行语义摘要，将摘要存入上下文头部替代原始长文本；按时间或任务阶段生成分层摘要，确保上下文窗口内始终是"核心指令 + 近期细节 + 历史摘要"的高效组合。Q15：如何保证 Agent 调用工具（Function Calling）的可靠性？答案：语法层面：强制使用 JSON Mode 或强类型约束（如通过 Schema 定义参数类型、必填项、取值范围），确保 LLM 生成的参数格式合法；格式错误时触发校验报错，返回给 LLM 重新生成。逻辑层面：对高风险操作（如数据库删除、资金转账、系统配置修改）设置人工审核节点，必须由人确认后才执行。重试与自我修复：工具调用失败时，将报错信息反馈给 LLM，让其自主分析失败原因并修正参数或切换工具，实现自我修复；同时设置重试次数上限，避免无限重试。Q16：LangGraph 中的"节点（Node）"和"边（Edge）"与传统工作流有何不同？答案：特性传统工作流（Airflow/Dagster）LangGraph节点（Node）固定任务步骤任务步骤、工具调用、决策逻辑、记忆更新等边（Edge）固定流转关系，无法动态调整支持条件边，由 LLM 输出动态决定流转方向循环支持不支持（避免死循环）原生支持循环（Cycles），允许 Agent 在多个节点间反复交互结构线性或静态 DAG动态 DAG + 循环，是 Agent 自主迭代的核心五、Agentic RAG 专项问答Q17：RAG 系统中经常遇到检索出来的片段（Chunk）互相冲突，Agent 该听谁的？答案：Chunk 冲突本质是"知识来源不一致"，需通过"权重排序、逻辑校验、溯源兜底"解决：元数据加权排序：为每个 Chunk 添加元数据标签（发布时间、权威性、来源渠道），检索时按权重排序，优先采信实时性高、权威性强的 Chunk。多智能体辩论校验：启动多 Agent 辩论机制，让不同 Agent 分别基于冲突的 Chunk 构建论证逻辑，再由汇总 Agent 根据逻辑一致性选择最合理的解释。引用溯源兜底：强制 Agent 输出时附带 Chunk 的 Source 链接，让用户可自行校验原始信息，同时标注"存在冲突，已优先采信高权威来源"。Q18：如何处理企业知识库中的"权限隔离"问题？Agent 会不会把高管工资查出来给普通员工？答案：核心解决方案是"RAG 权限对齐"，从根源上避免信息泄露，而非依赖 Prompt 拦截（Prompt 拦截易被绕过，安全性低）。具体实现方式：在向量数据库层面嵌入权限控制逻辑，每个 Chunk 的 Embedding 向量都附带 ACL（访问控制列表）元数据，标注可访问的用户角色、部门、权限等级；当 Agent 触发检索请求时，强制将当前用户的身份信息作为 Filter 注入检索语句，向量数据库仅返回该用户权限范围内的 Chunk，实现检索阶段的物理隔离。即使 Agent 尝试调用工具获取高权限信息，也因检索结果无相关内容而无法生成。Q19：当知识库内容更新很快（如每日新闻或实时股价）时，你的 RAG 系统如何应对？答案：核心思路是"动态适配 + 实时联动"，平衡检索准确性与实时性：动态路由决策：Agent 对用户问题进行实时性判断，实时性要求高的问题（如"当前股价"）优先调用实时 API 或搜索引擎，非实时问题则检索向量库。流式索引增量更新：利用数据流工具（如 Kafka、Flink）监听知识库内容变化，实时触发 Embedding 生成与向量库增量写入，避免全量重建索引。智能缓存失效策略：针对高频查询设置 TTL 缓存，如实时股价缓存 5 分钟、每日新闻缓存 1 小时；源数据更新时立即失效对应缓存。Q20：如何提升 RAG 问答准确度？答案：提升 RAG 准确度并非单一优化 Prompt，而是一套"解析-检索-生成"全链路的组合拳：1. 深度解析层：Layout-Aware Parsing（布局感知解析）使用 Layout Analysis 模型（如 DocLayout-YOLO、Unstructured、PyMuPDF），将文档按布局识别为标题、正文、表格、图片、列表等结构化元素；再按标题层级（H1-H4）进行语义分块，确保每个 Chunk 包含完整的上下文。2. 检索增强层：Multi-Stage Retrieval（多阶段检索）混合检索（Hybrid Search）：结合向量检索（语义相关性）与 BM25 检索（关键词匹配，解决专有名词、缩写查询不准），互补提升召回率。重排序（Reranking）：通过 Cross-Encoder 模型（如 BGE-Reranker、Cohere Rerank）对初筛 Top-50 Chunk 进行精排，根据与问题的语义契合度调整排序，这是提升准确度性价比最高的手段，可将相关性提升 20%-30%。3. 生成阶段：防幻觉 Prompt 约束“仅基于以下参考内容回答”“如果参考内容没有相关信息，请说明”“每个结论都要标注对应的参考片段”六、评估与工程落地Q21：你如何量化一个 Agent 的性能？答案：Agent 性能评估需结合"效果、效率、成本"多维度构建指标体系：指标说明任务成功率（Success Rate）核心指标，预设测试集中成功完成任务的比例平均推理步数（Avg Steps）完成单个任务平均所需的"推理-行动"循环次数，越少越精准工具调用准确率（Tool Call Accuracy）包括调用必要性准确率和参数准确率影子测试（Shadow Testing）生产环境并行运行新旧 Agent 逻辑，对比输出差异、成功率等指标Q22：企业内部落地 Agent，你最先关心哪三个非功能需求？答案：安全与合规：数据隔离、权限控制、操作审计日志可控性：人在回路、工具白名单机制可观测性：详细的操作轨迹（Trace）、性能指标监控、支持录像回放Q23：如何防止 Prompt 注入（Prompt Injection）？Agent 的审计日志应该记录什么？答案：防止 Prompt 注入：工具层鉴权：不能信任模型传递的用户身份，必须与系统真实登录身份绑定结构化分隔：用 XML 标签把用户不可信输入与系统指令物理隔离开输出审查（DLP）：拦截模型输出中的敏感词或机密信息审计日志至少应包含：脱敏后的用户输入、大模型原始输出（Thought + Action）、解析后的工具调用及参数、工具返回结果摘要、耗时与 Token 消耗、模型与 Prompt 版本号、能串起整个链路的 Trace ID。Q24：怎么测试一个复杂的 Agent 系统？答案：绝对不能只测最终答案，必须采用分层测试：层次说明单元测试针对 Agent 依赖的各个工具接口进行传参和返回值测试模拟环境回归在固定状态的沙箱环境里，用固定任务集测试 Agent 轨迹范围对抗测试输入恶意指令（注入）、越权尝试，测试拦截率线上监控采用金丝雀发布（灰度发布），观测线上真实错误率七、项目经验与面试技巧Q25：项目讲解技巧（来自面试复盘）答案：✗ 错误方式：报菜名式：“我们用了 RAG、用了 Tool Calling”只讲"系统有什么"，不讲"改了什么"用抽象名词：“做了状态管理”✓ 正确方式：讲决策过程：“最开始想用单 Agent，后来发现规划、检索和执行全塞在一起，链路太长出错了也不好定位，所以才拆开”讲具体改动：“一开始检索结果直接拼上下文，后来发现召回一多模型就会被带偏，所以又补了 rerank，把 topk 从 10 压到 5”用动作替代名词：“因为这个任务是多步执行的，中间结果后面还要用，所以把当前任务状态单独存出来，不然 Tool 超时以后很难从中间恢复”Q26：针对长短期记忆，讲讲你是如何设计记忆的提取、压缩与冲突更新机制的？答案：提取机制：短期记忆：最近 N 轮直接使用长期记忆：通过向量检索相关历史压缩策略：滑动窗口 + 摘要生成重要性评分：区分事实、结论、闲聊层级化摘要：会话级摘要、日级摘要、周级摘要冲突更新：新旧冲突时，带时间戳的新信息优先用户明确修正时，标记旧信息为过时保留修改历史，便于回溯八、知识点速查表类别核心关键词Agent 定义闭环决策、Planning、Memory、Tools、ObservationReActReasoning + Acting、Thought-Action-Observation 循环架构选型单Agent+多工具 vs Multi-Agent、Planner-Executor停止条件finish / Done / Max Steps / 死循环检测 / 超时 / 外部信号工具描述API文档级别、何时用/何时不用、参数含义、返回格式记忆系统向量库 + 关系型DB + 图数据库（混合架构）人在回路分级授权：低危自动 / 中危异步审批 / 高危实时阻塞安全防护工具层鉴权、XML结构化分隔、DLP输出审查评估指标Success Rate / Avg Steps / Tool Call Accuracy / Shadow Testing测试策略单元测试 → 模拟回归 → 对抗测试 → 线上灰度九、Agent 提示词设计基础篇Q1：Agent 提示词设计有哪些核心原则？如何应用这些原则？参考答案：核心原则：清晰明确（Clarity）指令清晰，避免歧义使用具体而非抽象的描述明确期望的输出格式结构化（Structure）使用结构化的格式分步骤说明使用列表和分段角色设定（Role）明确 Agent 的角色和身份设定专业领域定义行为准则上下文提供（Context）提供必要的背景信息包含相关示例说明使用场景约束条件（Constraints）明确限制和边界禁止的行为输出格式要求应用示例：# 不好的提示词bad_prompt="帮我分析数据"# 好的提示词good_prompt=""" 你是一位专业的数据分析师，擅长使用Python进行数据分析。 任务：分析销售数据并生成报告 要求： 1. 使用pandas读取CSV文件 2. 计算总销售额、平均销售额、增长率 3. 生成可视化图表 4. 输出格式：Markdown格式的报告 数据文件：sales_data.csv 输出文件：sales_report.md 请按步骤执行并展示结果。 """设计检查清单：✅ 角色是否明确？✅ 任务是否清晰？✅ 步骤是否具体？✅ 输出格式是否定义？✅ 约束条件是否说明？Q2：如何设计 Agent 的系统提示词（System Prompt）？有哪些关键要素？参考答案：关键要素：角色定义Agent 的身份和专业领域能力和特长行为风格能力说明可用的工具和功能知识范围限制说明行为准则如何与用户交互如何处理错误安全规则输出格式回答的格式要求工具调用的格式错误信息的格式示例：system_prompt=""" 你是一个智能助手Agent，具有以下特点： 【角色】 - 身份：专业的AI助手 - 领域：通用知识、工具调用、任务规划 - 风格：友好、专业、准确 【能力】 - 可以调用以下工具： 1. search_web：搜索网络信息 2. calculate：执行数学计算 3. get_weather：查询天气信息 4. send_email：发送邮件 【行为准则】 1. 始终以用户需求为中心 2. 不确定时主动询问 3. 工具调用失败时提供替代方案 4. 保护用户隐私和数据安全 【输出格式】 - 使用清晰的结构化回答 - 工具调用使用JSON格式 - 错误信息包含原因和建议 【约束】 - 不执行危险操作 - 不访问未授权的数据 - 不生成有害内容 """最佳实践：保持简洁但完整定期更新和优化根据场景调整测试和验证Q3：Agent 提示词模板如何设计？有哪些常用模式？参考答案：常用模式：任务型模板明确任务和目标步骤化说明结果验证对话型模板多轮对话支持上下文管理状态跟踪工具调用模板工具选择逻辑参数生成规则结果处理方式错误处理模板错误识别恢复策略用户通知示例：# 任务型模板task_template=""" 任务：{task_description} 目标：{goal} 步骤： {steps} 约束条件： {constraints} 输出格式：{output_format} """# 对话型模板conversation_template=""" 角色：{role} 上下文：{context} 历史对话： {conversation_history} 当前用户输入：{user_input} 请根据上下文和历史对话，生成合适的回答。 """# 工具调用模板tool_calling_template=""" 分析用户需求：{user_request} 可用工具： {tools_description} 请选择最合适的工具并生成调用参数。 输出格式： { "tool": "工具名称", "parameters": { "param1": "value1", "param2": "value2" }, "reasoning": "选择理由" } """模板管理：使用模板引擎（Jinja2等）支持变量替换版本控制复用和组合十、Agent 提示词优化技巧篇Q1：如何设计 Agent 的 Few-shot 提示词？有哪些技巧？参考答案：设计技巧：示例选择选择代表性示例覆盖不同场景包含边界情况示例格式统一的输入输出格式清晰的标注 AI Agent 面试题精选
核心概念 · 架构设计 · 多智能体 · RAG · 评估与落地 · 提示词工程一、核心概念与架构篇Q1：请简述 Agent 的基本架构组成，并解释其与传统 LLM Chain 的区别。答案：Agent 本质是"LLM 核心 + 三大辅助模块"的综合体，即LLM（基础能力底座）+规划（Planning，任务拆解与路径规划）+记忆（Memory，会话与经验存储）+工具使用（Tool Use，外部能力扩展）。四大模块协同，让 Agent 具备自主决策与执行能力。与传统 LLM Chain 的核心区别：维度LLM ChainAgent驱动方式固定流程驱动，线性硬编码目标驱动自主决策灵活性步骤不可动态调整通过 Reasoning Loop 动态调整策略异常处理按预设流程执行，无法自适应工具失败会自动重试或切换工具适用场景标准化、固定步骤任务复杂多变、非结构化任务Q2：解释 ReAct 模式的工作原理。答案：ReAct（Reasoning + Acting，推理 + 行动）是 Agent 实现自主决策的核心基石，打破了"先思考完再行动"的割裂模式，采用"边想边做"的迭代逻辑，让 Agent 的行为更可控、可追溯。具体工作流程：LLM 基于当前任务和上下文生成推理过程（Thought），明确"下一步要做什么、为什么这么做"执行对应行动（Action），调用指定工具获取观察结果（Observation）将观察结果反馈至上下文，进入下一轮"推理-行动-观察"循环，直至完成任务或达到终止条件Q3：如何实现 Agent 的长期记忆（Long-term Memory）？答案：Agent 的记忆体系分为短期与长期，二者协同保障任务连续性，长期记忆的核心是突破上下文窗口限制，留存历史经验与知识：短期记忆：依赖 Context Window，存储当前会话的 Chat History 和即时任务状态，仅在当前会话有效，窗口满后会被截断。长期记忆：主流方案是结合 RAG 技术，将 Agent 的历史经验、领域知识、任务记录等编码为 Embedding 向量，存入向量数据库（如 Milvus、Pinecone）；执行新任务时通过"经验检索"调取相关内容补充至上下文。★ 2026 新趋势：一是利用长文本模型（Long-context LLMs）直接处理数万甚至数十万 Token 的超长历史，减少检索依赖；二是通过"摘要层级结构"递归压缩记忆，既节省存储又提升检索效率。Q4：Agent 和 Prompt Chain 有什么本质区别？ChatBot 加上插件是不是就变成 Agent 了？答案：Prompt Chain：固定代码顺序执行，无基于观察结果的再决策循环。如固定三步的 RAG 流水线（Query 改写 → 向量检索 → 总结生成），没有失败分支处理，更像 Prompt Chain。Agent：闭环迭代，每步可根据工具返回结果动态调整下一步。如果加入了多轮检索策略（查不到就换词再查），并包含失败分支处理，这才接近 Agent。关于 ChatBot + 插件：如果插件调用由固定规则触发（如关键词路由），更像"带工具的 Bot"；如果由模型在多步推理中自主选择工具与参数，并形成闭环迭代，才真正接近 Agent。关键在于是否具备多步自主决策与反馈闭环。Q5：多 Agent 协作系统（Multi-Agent）和"单 Agent + 多工具"怎么选？答案：单 Agent + 多工具：实现简单、延迟低。适合任务边界清晰、模型依靠自身能力就能统筹所有工具的场景。多 Agent：适合需要角色分工、并行探索或对抗审查的场景（如：一个 Agent 写代码，另一个专门负责挑错）。缺点是协调成本高、数据一致性问题。选型核心：看任务的分解结构、组织的边界、以及对延迟和 Token 成本的敏感度。Q6：Agent 的记忆一般怎么设计？只用向量数据库够吗？答案：分层设计最常见：工作记忆：当前任务轨迹和关键结论会话记忆：摘要滚动，避免上下文过长长期记忆：向量检索 / 结构化库存储历史信息只用向量库不够。向量检索擅长模糊语义相似度，但在精确约束和关系推理上非常弱。实际工程中通常是混合架构：向量库：处理长文本和非结构化知识关系型数据库：处理精确的订单、时间状态图数据库：处理复杂的人物 / 事件关系（按需）Q7：你会如何设计 Agent 的"停止条件（Stop Condition）"？答案：在工程中绝对不能只依赖单一条件，必须组合使用：类型说明正常完成模型自主声明 finish目标达成任务清单（To-Do List）状态全部变为 Done硬性护栏达到最大步数（Max Steps）或 Token 预算上限死循环拦截检测到连续无进展的重复动作超时控制整体任务耗时超过阈值外部信号如自动化测试用例全部通过Q8：工具描述（Tool Description）为什么非常重要？答案：因为大模型完全是依靠描述来做路由和工具选择的！这相当于大模型的"API 文档"。描述不清会导致模型选错工具，或者凭空捏造参数（参数幻觉）。好的描述必须包含：这个工具是干嘛的、何时用、何时不用、参数的具体含义、错误调用的示例，以及预期的返回格式。二、多智能体协同（Multi-Agent Systems）Q9：单 Agent 遇到瓶颈时，为什么需要 Multi-Agent？常见的协作模式有哪些？答案：单 Agent 的瓶颈核心是"能力边界有限"：在处理复杂、跨领域、长周期任务时，容易出现注意力漂移、推理链断裂、技能不足等问题，而 Multi-Agent 通过分工协作突破单一个体的能力局限。常见协作模式：模式核心逻辑适用场景中心化（Boss-Worker）主 Agent 负责拆解、分配与汇总，子 Agent 无自主决策权结构化任务，如项目管理拆分需求分配给代码、测试、文档 Agent流水线（Pipeline）前一个 Agent 的输出作为后一个的输入，形成闭环流程化任务，如代码生成→审查→Bug修复→部署验证民主协作（Joint Discussion）多个 Agent 同等权限，共同讨论碰撞观点，达成一致结论开放式、多维度思考任务，如技术方案评审、复杂问题归因分析Q10：多智能体系统中如何解决"无限循环"或"通信冗余"问题？答案：需从流程控制、内容优化、条件约束三方面解决：循环检测与控制：引入状态机管理每个 Agent 的运行状态，设置最大迭代次数（如单任务交互不超过 10 轮），达到阈值时自动中断，由主 Agent 重新分配或调整策略。Token 与内容压缩：对 Agent 间的对话内容进行实时摘要，提取核心信息，剔除冗余表述；同时限制单轮对话的 Token 上限。明确终止条件：提前定义任务完成、中断、重试的标准，如"结果满足预设指标"“无新信息产出”，触发时立即终止交互。Q11：详细解释"编排者-执行者（Orchestrator-Workers）"模式。答案：该模式是中心化协作的进阶版，核心是"专业化分工 + 精细化管控"，适用于大型复杂任务的拆解与执行，是工业界落地 Multi-Agent 的主流模式之一。主 Agent（Orchestrator）具备三大核心能力：任务拆解：将复杂任务拆分为可执行的子任务，明确每个子任务的目标、范围、输出格式技能匹配：根据子任务类型，分配给具备对应 Skill 的 Worker Agents结果聚合与校验：汇总所有子任务结果，校验一致性与完整性，若存在问题则回溯调整核心难点：任务分解的粒度控制。粒度太细会导致 Agent 间通信成本剧增；粒度太粗则 Worker 难以精准执行，易产生理解偏差与幻觉。三、Agent 核心设计模式（Design Patterns）Q12：请对比"工作流（Workflows）"与"自主智能体（Autonomous Agents）"的优劣。答案：二者核心差异在于"决策主体"，适用于不同场景，无绝对优劣，按需选型：维度工作流（Workflows）自主智能体（Autonomous Agents）决策主体DAG / 状态机硬编码LLM 自主决定优点高可靠性、结果可预期、易排查极高灵活性，适配开放式任务缺点无法应对未预设异常场景结果不可控，易产生幻觉，运维成本高适用场景报销审批、固定话术客服、数据同步科研探索、个性化代码、复杂问题诊断★ 面试金句（2026 工程趋势）：当前工业界的最优实践是"用 Workflow 约束 Agent"，即在工作流定义的核心路径与边界内，给予 Agent 局部决策权，兼顾可靠性与灵活性。Q13：什么是"反思 / 自我纠正（Reflection / Self-Correction）"模式？答案：反思模式是提升 Agent 任务成功率的核心优化手段，本质是让 Agent 具备"自我审视、迭代优化"的能力，通过对过往输出的复盘，修正错误、规避重复问题，形成闭环进化。核心实现逻辑：Agent 生成初步输出后，由专门的"批评者 Agent（Critic）"或自身切换为批评者角色，对照任务目标检查输出识别错误、漏洞或优化点，生成具体反馈原 Agent 根据反馈迭代修改，直至满足要求可基于Reflexion 架构落地，核心是记录"失败轨迹"并纳入长短期记忆——将每次错误原因、修正方案编码存储，遇到同类任务时优先检索历史失败经验，避免重复踩坑。四、深度技术实现与状态管理Q14：在多轮对话 Agent 中，如何处理"状态爆炸"和"上下文溢出"？答案：状态爆炸指多轮交互中状态过多导致管理混乱；上下文溢出指信息超过 Context Window 上限。二者需结合结构化管理、语义优化、内容压缩三重方案解决：状态结构化（State Schema）：定义严格的状态数据结构（如 LangGraph 的 TypedDict、Pydantic 模型），仅保留核心变量，剔除无关冗余状态。语义修剪策略（Trim Strategy）：基于语义重要性筛选保留——优先保留 System Prompt、当前任务目标、最近 N 轮关键对话，删除重复表述、已完成步骤的细节信息。摘要缓冲机制（Summary Buffer）：对早期对话内容进行语义摘要，将摘要存入上下文头部替代原始长文本；按时间或任务阶段生成分层摘要，确保上下文窗口内始终是"核心指令 + 近期细节 + 历史摘要"的高效组合。Q15：如何保证 Agent 调用工具（Function Calling）的可靠性？答案：语法层面：强制使用 JSON Mode 或强类型约束（如通过 Schema 定义参数类型、必填项、取值范围），确保 LLM 生成的参数格式合法；格式错误时触发校验报错，返回给 LLM 重新生成。逻辑层面：对高风险操作（如数据库删除、资金转账、系统配置修改）设置人工审核节点，必须由人确认后才执行。重试与自我修复：工具调用失败时，将报错信息反馈给 LLM，让其自主分析失败原因并修正参数或切换工具，实现自我修复；同时设置重试次数上限，避免无限重试。Q16：LangGraph 中的"节点（Node）"和"边（Edge）"与传统工作流有何不同？答案：特性传统工作流（Airflow/Dagster）LangGraph节点（Node）固定任务步骤任务步骤、工具调用、决策逻辑、记忆更新等边（Edge）固定流转关系，无法动态调整支持条件边，由 LLM 输出动态决定流转方向循环支持不支持（避免死循环）原生支持循环（Cycles），允许 Agent 在多个节点间反复交互结构线性或静态 DAG动态 DAG + 循环，是 Agent 自主迭代的核心五、Agentic RAG 专项问答Q17：RAG 系统中经常遇到检索出来的片段（Chunk）互相冲突，Agent 该听谁的？答案：Chunk 冲突本质是"知识来源不一致"，需通过"权重排序、逻辑校验、溯源兜底"解决：元数据加权排序：为每个 Chunk 添加元数据标签（发布时间、权威性、来源渠道），检索时按权重排序，优先采信实时性高、权威性强的 Chunk。多智能体辩论校验：启动多 Agent 辩论机制，让不同 Agent 分别基于冲突的 Chunk 构建论证逻辑，再由汇总 Agent 根据逻辑一致性选择最合理的解释。引用溯源兜底：强制 Agent 输出时附带 Chunk 的 Source 链接，让用户可自行校验原始信息，同时标注"存在冲突，已优先采信高权威来源"。Q18：如何处理企业知识库中的"权限隔离"问题？Agent 会不会把高管工资查出来给普通员工？答案：核心解决方案是"RAG 权限对齐"，从根源上避免信息泄露，而非依赖 Prompt 拦截（Prompt 拦截易被绕过，安全性低）。具体实现方式：在向量数据库层面嵌入权限控制逻辑，每个 Chunk 的 Embedding 向量都附带 ACL（访问控制列表）元数据，标注可访问的用户角色、部门、权限等级；当 Agent 触发检索请求时，强制将当前用户的身份信息作为 Filter 注入检索语句，向量数据库仅返回该用户权限范围内的 Chunk，实现检索阶段的物理隔离。即使 Agent 尝试调用工具获取高权限信息，也因检索结果无相关内容而无法生成。Q19：当知识库内容更新很快（如每日新闻或实时股价）时，你的 RAG 系统如何应对？答案：核心思路是"动态适配 + 实时联动"，平衡检索准确性与实时性：动态路由决策：Agent 对用户问题进行实时性判断，实时性要求高的问题（如"当前股价"）优先调用实时 API 或搜索引擎，非实时问题则检索向量库。流式索引增量更新：利用数据流工具（如 Kafka、Flink）监听知识库内容变化，实时触发 Embedding 生成与向量库增量写入，避免全量重建索引。智能缓存失效策略：针对高频查询设置 TTL 缓存，如实时股价缓存 5 分钟、每日新闻缓存 1 小时；源数据更新时立即失效对应缓存。Q20：如何提升 RAG 问答准确度？答案：提升 RAG 准确度并非单一优化 Prompt，而是一套"解析-检索-生成"全链路的组合拳：1. 深度解析层：Layout-Aware Parsing（布局感知解析）使用 Layout Analysis 模型（如 DocLayout-YOLO、Unstructured、PyMuPDF），将文档按布局识别为标题、正文、表格、图片、列表等结构化元素；再按标题层级（H1-H4）进行语义分块，确保每个 Chunk 包含完整的上下文。2. 检索增强层：Multi-Stage Retrieval（多阶段检索）混合检索（Hybrid Search）：结合向量检索（语义相关性）与 BM25 检索（关键词匹配，解决专有名词、缩写查询不准），互补提升召回率。重排序（Reranking）：通过 Cross-Encoder 模型（如 BGE-Reranker、Cohere Rerank）对初筛 Top-50 Chunk 进行精排，根据与问题的语义契合度调整排序，这是提升准确度性价比最高的手段，可将相关性提升 20%-30%。3. 生成阶段：防幻觉 Prompt 约束“仅基于以下参考内容回答”“如果参考内容没有相关信息，请说明”“每个结论都要标注对应的参考片段”六、评估与工程落地Q21：你如何量化一个 Agent 的性能？答案：Agent 性能评估需结合"效果、效率、成本"多维度构建指标体系：指标说明任务成功率（Success Rate）核心指标，预设测试集中成功完成任务的比例平均推理步数（Avg Steps）完成单个任务平均所需的"推理-行动"循环次数，越少越精准工具调用准确率（Tool Call Accuracy）包括调用必要性准确率和参数准确率影子测试（Shadow Testing）生产环境并行运行新旧 Agent 逻辑，对比输出差异、成功率等指标Q22：企业内部落地 Agent，你最先关心哪三个非功能需求？答案：安全与合规：数据隔离、权限控制、操作审计日志可控性：人在回路、工具白名单机制可观测性：详细的操作轨迹（Trace）、性能指标监控、支持录像回放Q23：如何防止 Prompt 注入（Prompt Injection）？Agent 的审计日志应该记录什么？答案：防止 Prompt 注入：工具层鉴权：不能信任模型传递的用户身份，必须与系统真实登录身份绑定结构化分隔：用 XML 标签把用户不可信输入与系统指令物理隔离开输出审查（DLP）：拦截模型输出中的敏感词或机密信息审计日志至少应包含：脱敏后的用户输入、大模型原始输出（Thought + Action）、解析后的工具调用及参数、工具返回结果摘要、耗时与 Token 消耗、模型与 Prompt 版本号、能串起整个链路的 Trace ID。Q24：怎么测试一个复杂的 Agent 系统？答案：绝对不能只测最终答案，必须采用分层测试：层次说明单元测试针对 Agent 依赖的各个工具接口进行传参和返回值测试模拟环境回归在固定状态的沙箱环境里，用固定任务集测试 Agent 轨迹范围对抗测试输入恶意指令（注入）、越权尝试，测试拦截率线上监控采用金丝雀发布（灰度发布），观测线上真实错误率七、项目经验与面试技巧Q25：项目讲解技巧（来自面试复盘）答案：✗ 错误方式：报菜名式：“我们用了 RAG、用了 Tool Calling”只讲"系统有什么"，不讲"改了什么"用抽象名词：“做了状态管理”✓ 正确方式：讲决策过程：“最开始想用单 Agent，后来发现规划、检索和执行全塞在一起，链路太长出错了也不好定位，所以才拆开”讲具体改动：“一开始检索结果直接拼上下文，后来发现召回一多模型就会被带偏，所以又补了 rerank，把 topk 从 10 压到 5”用动作替代名词：“因为这个任务是多步执行的，中间结果后面还要用，所以把当前任务状态单独存出来，不然 Tool 超时以后很难从中间恢复”Q26：针对长短期记忆，讲讲你是如何设计记忆的提取、压缩与冲突更新机制的？答案：提取机制：短期记忆：最近 N 轮直接使用长期记忆：通过向量检索相关历史压缩策略：滑动窗口 + 摘要生成重要性评分：区分事实、结论、闲聊层级化摘要：会话级摘要、日级摘要、周级摘要冲突更新：新旧冲突时，带时间戳的新信息优先用户明确修正时，标记旧信息为过时保留修改历史，便于回溯八、知识点速查表类别核心关键词Agent 定义闭环决策、Planning、Memory、Tools、ObservationReActReasoning + Acting、Thought-Action-Observation 循环架构选型单Agent+多工具 vs Multi-Agent、Planner-Executor停止条件finish / Done / Max Steps / 死循环检测 / 超时 / 外部信号工具描述API文档级别、何时用/何时不用、参数含义、返回格式记忆系统向量库 + 关系型DB + 图数据库（混合架构）人在回路分级授权：低危自动 / 中危异步审批 / 高危实时阻塞安全防护工具层鉴权、XML结构化分隔、DLP输出审查评估指标Success Rate / Avg Steps / Tool Call Accuracy / Shadow Testing测试策略单元测试 → 模拟回归 → 对抗测试 → 线上灰度九、Agent 提示词设计基础篇Q1：Agent 提示词设计有哪些核心原则？如何应用这些原则？参考答案：核心原则：清晰明确（Clarity）指令清晰，避免歧义使用具体而非抽象的描述明确期望的输出格式结构化（Structure）使用结构化的格式分步骤说明使用列表和分段角色设定（Role）明确 Agent 的角色和身份设定专业领域定义行为准则上下文提供（Context）提供必要的背景信息包含相关示例说明使用场景约束条件（Constraints）明确限制和边界禁止的行为输出格式要求应用示例：# 不好的提示词bad_prompt="帮我分析数据"# 好的提示词good_prompt=""" 你是一位专业的数据分析师，擅长使用Python进行数据分析。 任务：分析销售数据并生成报告 要求： 1. 使用pandas读取CSV文件 2. 计算总销售额、平均销售额、增长率 3. 生成可视化图表 4. 输出格式：Markdown格式的报告 数据文件：sales_data.csv 输出文件：sales_report.md 请按步骤执行并展示结果。 """设计检查清单：✅ 角色是否明确？✅ 任务是否清晰？✅ 步骤是否具体？✅ 输出格式是否定义？✅ 约束条件是否说明？Q2：如何设计 Agent 的系统提示词（System Prompt）？有哪些关键要素？参考答案：关键要素：角色定义Agent 的身份和专业领域能力和特长行为风格能力说明可用的工具和功能知识范围限制说明行为准则如何与用户交互如何处理错误安全规则输出格式回答的格式要求工具调用的格式错误信息的格式示例：system_prompt=""" 你是一个智能助手Agent，具有以下特点： 【角色】 - 身份：专业的AI助手 - 领域：通用知识、工具调用、任务规划 - 风格：友好、专业、准确 【能力】 - 可以调用以下工具： 1. search_web：搜索网络信息 2. calculate：执行数学计算 3. get_weather：查询天气信息 4. send_email：发送邮件 【行为准则】 1. 始终以用户需求为中心 2. 不确定时主动询问 3. 工具调用失败时提供替代方案 4. 保护用户隐私和数据安全 【输出格式】 - 使用清晰的结构化回答 - 工具调用使用JSON格式 - 错误信息包含原因和建议 【约束】 - 不执行危险操作 - 不访问未授权的数据 - 不生成有害内容 """最佳实践：保持简洁但完整定期更新和优化根据场景调整测试和验证Q3：Agent 提示词模板如何设计？有哪些常用模式？参考答案：常用模式：任务型模板明确任务和目标步骤化说明结果验证对话型模板多轮对话支持上下文管理状态跟踪工具调用模板工具选择逻辑参数生成规则结果处理方式错误处理模板错误识别恢复策略用户通知示例：# 任务型模板task_template=""" 任务：{task_description} 目标：{goal} 步骤： {steps} 约束条件： {constraints} 输出格式：{output_format} """# 对话型模板conversation_template=""" 角色：{role} 上下文：{context} 历史对话： {conversation_history} 当前用户输入：{user_input} 请根据上下文和历史对话，生成合适的回答。 """# 工具调用模板tool_calling_template=""" 分析用户需求：{user_request} 可用工具： {tools_description} 请选择最合适的工具并生成调用参数。 输出格式： { "tool": "工具名称", "parameters": { "param1": "value1", "param2": "value2" }, "reasoning": "选择理由" } """模板管理：使用模板引擎（Jinja2等）支持变量替换版本控制复用和组合十、Agent 提示词优化技巧篇Q1：如何设计 Agent 的 Few-shot 提示词？有哪些技巧？参考答案：设计技巧：示例选择选择代表性示例覆盖不同场景包含边界情况示例格式统一的输入输出格式清晰的标注