AI 智能体（Agent）应用开发工程师面试题（二）-程序员充电站

AI 智能体（Agent）应用开发工程师 · 进阶面试题

1. 目前主流的 Agent 开发框架有哪些？各自的适用场景是什么？

参考答案：

LangChain：最早流行的 Agent 框架，提供了丰富的工具、记忆、链式调用封装。适合快速原型构建和学习，拥有庞大的生态，但在处理复杂的状态分支和循环时，代码会变得臃肿。
LangGraph：专注于将 Agent 工作流建模为有向图，天然支持条件分支、循环、并行和状态持久化。适合构建复杂的、需要高度定制控制流的 Agent 应用。
AutoGen：微软推出的多智能体对话框架，核心是让多个智能体通过对话协作完成任务。内置 GroupChat 等高级机制，适合需要角色扮演、辩论、分工的多 Agent 场景。
CrewAI：基于角色的多智能体编排框架，高度抽象，开发者只需定义 Agent 的 Role、Goal 和 Backstory，即可快速搭建协作系统。适合业务端开发者快速落地多 Agent 工作流。
Semantic Kernel：微软的轻量级 SDK，侧重于将 AI 能力无缝融入传统业务应用，支持 C#、Python 等，与企业级开发栈集成度高。
Dify / Coze：低代码 Agent 编排平台，通过可视化画布配置工作流、知识库和插件，极大降低了非开发者的使用门槛。

补充思考
选择框架的核心依据是复杂度、团队技术栈和控制粒度。如果流程是简单的线性 Chain，LangChain 足够；一旦出现复杂的 if-else 和循环，优先考虑 LangGraph；如果是典型的多智能体角色协作，CrewAI 或 AutoGen 更合适。

2. 什么是 Plan-and-Execute 模式？它与 ReAct 相比有何优缺点？

参考答案：

Plan-and-Execute 是一种先规划、后执行的智能体范式。智能体在拿到任务后，首先生成一个完整的行动步骤清单（Plan），然后在执行阶段逐条执行，中间可能穿插对进度的检查，但总体按照既定计划推进。

与 ReAct 的对比：

ReAct是“走一步看一步”，每一轮都根据最新观察动态决策。优点是灵活、适应性强，面对突发状况能及时纠偏；缺点是可能陷入短视，在多步任务中容易迷路，且没有全局视图。
Plan-and-Execute是“谋定而后动”，优点是全局目标感强，步效率高，可以提前预估资源和耗时；缺点是对动态环境的适应能力差，一旦原计划的前提条件发生变化，可能需要重新规划，且初始规划本身可能不完美。

适用场景：Plan-and-Execute 更适合流程相对固定、环境变化小、任务结构清晰的场景，如自动化数据报表生成、固定 CI/CD 流程。ReAct 适合探索性、不确定性强的任务，如开放式客服、复杂问题搜索。

补充思考
工程中常采用混合模式：使用一个顶层规划器生成粗略计划，每个子任务再交由一个 ReAct 执行器动态完成，兼顾全局和局部的灵活性。LangGraph 中很容易实现这种双层结构。

3. 在 Agent 中如何实现动态工具选择与路由？

参考答案：

当工具数量膨胀到几十甚至上百个时，将所有工具描述都塞进 System Prompt 会让模型选择困难、成本激增。动态选择和路由是必然策略。

常见的实现方式有：

基于描述的分类索引：先用一个轻量级模型（或规则）根据用户意图将请求分类到“天气类”“航班类”“文档类”等，然后只向主 Agent 暴露对应类别的工具子集。这可以显著减小候选工具空间。
语义路由：对用户请求和每个工具的描述进行向量化，通过相似度检索出 Top-K 个最相关的工具，再交给模型做最终选择。
递归工具选择：让 Agent 先选择工具分类，再在分类内选择具体工具。例如，{ "category": "weather" }解析后再加载该类别下的所有工具签名。
自动生成工具选择提示：每次调用根据当前对话状态，动态生成仅包含相关工具的 System Prompt 段落，而非静态列出全部。

补充思考
实际应用中，常会将工具注册到“工具商店”或“技能库”，并为每个工具打上标签。再结合 RAG 的思路来检索工具，这样即便工具集持续增长，也不会冲击模型性能。

4. 如何处理 Agent 中工具的异步调用与并发执行？

参考答案：

许多任务天然可并行，比如同时查询“北京天气”和“上海天气”，或同时读取多个文件。如果 Agent 只能顺序调用工具，延迟将线性累积。

实现并发执行的关键是让 Agent 的思考过程能够一次性识别可并行的独立操作，并输出多个工具调用请求。在代码层收到这一组调用后，通过asyncio.gather或线程池并发执行，等所有结果返回后统一传回模型。这种做法要求在 System Prompt 中明确告知模型：“如果多个工具调用互不依赖，请在同一轮中一起输出。”

工程要点：

使用异步 HTTP 客户端或消息队列来并行调用外部 API。
必须设置并发超时和单点失败策略：是全部失败回滚，还是部分成功继续？
对于有依赖关系的工具，模型应分两轮依次调用，开发中的执行引擎则需要支持基于依赖图的自动调度。

补充思考
LangGraph 天然支持在图中定义并行节点，多个出边指向不同的工具节点，执行时会同时触发。这比手动管理并发调用要优雅得多。

5. 如何解决 Agent 在长对话中上下文超长的问题？请介绍几种上下文管理策略。

参考答案：

Agent 的多轮推理和工具调用极容易撑爆模型的上下文窗口。常用策略包括：

滑动窗口截断：只保留最近 N 条消息，丢弃历史。简单但会丢失重要早期信息。
摘要压缩：当一个主题结束或上下文字数达到阈值时，用模型对历史对话进行摘要，用摘要代替原始长对话放入后续上下文。可在 System Prompt 中设定摘要条件。
分层记忆：将对话分为“当前活跃窗口”和“长期记忆库”。长期记忆库存储完整历史，仅在需要时通过向量检索召回相关片段注入当前窗口。
关键消息标记：对重要消息（如用户确认、关键决定）进行标记，使其在摘要或截断时免于丢失。
上下文窗口预留：为 System Prompt、工具定义和输出预留固定 token 空间，剩余部分分配为动态历史区域，通过编程严格控制其大小。

补充思考
最新的 MemGPT 等系统借鉴了操作系统虚拟内存的思想，让模型自主管理记忆的交换，自动在“核心上下文”和“外部存储”之间搬移信息，是上下文管理的前沿方向。

6. Agent 记忆系统中的“摘要记忆”和“向量检索记忆”如何配合使用？

参考答案：

这是混合记忆的典型模式。摘要记忆负责维护对话的宏观语境，保证 Agent 对当前任务的整体把握；向量检索记忆负责提供细节和事实的精准回忆。

配合方式：

在每一轮对话中，Agent 首先从向量数据库中检索与当前问题最相关的历史片段（如“上次用户提到的过敏原”），将它们插入上下文。
同时，系统会保持一份由模型定期生成的对话摘要，它概括了当前会话的总体进展和目标。摘要始终保留在上下文中，不被截断。
当检索到的具体信息与摘要出现矛盾时，以具体检索结果为准，或触发 Agent 进行自我澄清。

这样，Agent 既能“记得现在在干什么”（摘要），又能“回忆过去某件事的具体情况”（检索），兼顾全局和局部。

补充思考
实现上的一个难点是摘要的更新时机。可以是每 N 轮主动触发，也可以由 Agent 自行判断“当前对话阶段即将结束，我该总结一下了”，后者更智能但实现难度更大。

7. 什么是 RAG（检索增强生成），Agent 与 RAG 结合时会产生哪些新的设计和挑战？

参考答案：

RAG 通过在生成回答前从外部知识库检索相关信息，来减少幻觉、引入实时知识。当与 Agent 结合时，RAG 不再是简单的“检索→回答”线性管道，而变成了 Agent 可在推理循环中主动调用的一个工具。

新设计维度：

检索即工具：Agent 可以决定何时需要检索、检索什么内容、从哪个知识库检索，甚至可以在一次任务中进行多次不同粒度的检索。
检索与行动的融合：Agent 可以先检索政策条款，再根据条款调用执行工具，最后再检索合规检查清单，形成闭环。
多知识源协同：Agent 可同时连接公司内部 Wiki、CRM 数据库和公共搜索引擎，根据不同子任务动态选择。

主要挑战：

检索噪音：如果检索结果质量差，会严重误导 Agent 的后续推理。
上下文膨胀：多次检索会把大量文本塞入上下文，加剧管理难度。
权限隔离：不同用户可检索的知识库范围不同，Agent 必须携带用户身份进行检索。

补充思考
实践中常将 RAG 管道本身也视为一个 Agent，专门负责理解查询、改写查询、检索和重排序，然后主 Agent 使用这个“知识检索 Agent”的输出，形成分层架构。

8. 在 Agent 中如何实现 Human-in-the-loop（人机协同）？请举例说明。

参考答案：

Human-in-the-loop（HITL）是指在 Agent 工作的关键节点引入人工确认、干预或输入，以保障安全、提升质量。实现方式通常是在 Agent 的执行图中设置中断点或确认节点。

常见模式：

关键操作确认：在发送邮件、扣款、删除数据等不可逆操作前，Agent 暂停执行，生成一份“待确认摘要”，等待人类回复“确认”或“取消”后才继续。这是最常用的安全阀。
模糊决策征询：当 Agent 对下一步行动的自信心低于设定阈值时，主动向用户提问，而不是强行猜测。例如：“我找到了两个匹配的地址，请问是 A 还是 B？”
人工审核循环：Agent 完成任务草案，交给人类审核，人类可以修改、补充或驳回，Agent 根据反馈进行迭代修改，直到人类满意。
中断接管：人类可以随时暂停 Agent 的执行，查看当前状态和推理链，手动注入新的指令或纠正错误思路。

工程实现：在 LangGraph 中，可以通过interruptAPI 在指定节点暂停图执行，并将状态持久化，等待外部触发恢复。

补充思考
设计 HITL 时，必须保证中断等待不会超时导致整个流程挂死，需要设置超时回退策略，如在规定时间未收到人类反馈则走默认安全路径。

9. 如何使用 LangGraph 构建具有条件分支和循环的 Agent 工作流？

参考答案：

LangGraph 将 Agent 的工作流抽象为节点（Nodes）和边（Edges）组成的有向图，用原生方式支持条件分支和循环。

条件分支：通过add_conditional_edges函数，根据当前状态决定下一个节点。例如，一个路由器节点分析用户意图后，可以路由到“天气工具”“计算器”或“直接回复”三个不同节点。
循环：在添加边时，将后续节点指回之前的节点就形成循环。最典型的 ReAct 循环就是 Agent 节点与工具节点之间的回环：Agent 思考后决定调用工具，工具执行后返回 Agent 继续思考，直到 Agent 决定结束并输出最终回复。
状态管理：LangGraph 使用统一的状态对象（TypedDict）在图节点间传递数据，每次节点执行都返回状态的更新部分，框架负责合并和持久化。这保证了在多步循环中不会丢失信息。
并行：从一个节点出发的多条边可以指向不同节点，框架会并发执行这些节点，然后在汇聚点等待全部完成。

补充思考
与 LangChain 的AgentExecutor相比，LangGraph 让你能精细控制图中每个环节的实现，包括错误处理路径、超时控制等，非常适合追求生产级可靠性的场景。