AI Agent 面试
AI Agent 面试
基础概念与核心组件
【简单】什么是 AI Agent？它和直接调用大模型 API 有什么区别？⭐⭐⭐
AI Agent（智能体）是以大语言模型（LLM）为"大脑"的自主智能系统，能以"用户目标 → Agent 规划 → Agent 执行 → 结果反馈"的模式自主完成复杂任务。
与直接调用大模型 API 的核心区别：
| 维度 | AI Agent | 直接调用 LLM API |
|---|---|---|
| 交互模式 | 多步骤自主循环（规划→执行→反思） | 单次问答（指令→生成→用户执行） |
| 工具能力 | 自主调用外部工具（搜索、API 等） | 仅生成文本，无法执行操作 |
| 记忆能力 | 具备短期/长期记忆，持续学习适应 | 无状态，每次独立交互 |
| 自主性 | 主动拆解目标、动态调整计划 | 被动应答，依赖用户逐步指令 |
总结：Agent 与传统 AI 的本质差异在于——传统 AI 执行预定义规则的单点任务，Agent 能理解自然语言指令，自主将复杂目标拆解为子任务，动态调用工具并反思优化，实现从"被动应答"到"主动解决问题"的跨越。
【中等】AI Agent 的核心架构有哪些组成部分？⭐⭐⭐
AI Agent 遵循"感知-规划-行动-反思"的闭环设计，由四大核心模块构成：
- 感知模块（感官）：接收用户指令和外部环境信息，支持文本、语音、图像等多模态输入。
- 推理与决策模块（大脑）：由 LLM 驱动，通过
System Prompt定义角色和约束，使用 CoT、ReAct 等策略进行任务分解与决策。 - 执行模块（手脚）：通过
Function Calling机制调用外部工具（搜索引擎、API、代码解释器、数据库等）。 - 记忆模块（认知存储）：
- 短期记忆：当前对话上下文，由 LLM 上下文窗口直接承载。
- 长期记忆：历史经验、用户偏好，通过向量数据库/知识图谱持久化存储。
常见功能：自主任务规划与分解、多轮对话上下文管理、外部工具/API 调用、代码生成与执行、文件读写与数据处理、网页搜索与信息检索、多模态理解、自我反思与错误修正、多 Agent 协作编排等。
总结：LLM Agent = LLM 核心（推理引擎）+ 提示词工程层（角色/约束/工作流）+ 工具层（Function Calling）+ 记忆层（短期上下文 + 长期向量/图谱）+ 规划层（任务分解 + 推理策略）。
【中等】市面上有哪些主流的 LLM Agent 框架？各自的特点是什么？⭐⭐
| 框架 | 核心特点 | 适用场景 |
|---|---|---|
| LangChain / LangGraph | 生态最完善，链式调用、工具集成、图形化多 Agent 工作流 | 复杂工作流、生产级应用 |
| AutoGen（微软） | 轻量级消息列表记忆，侧重多 Agent 对话式协作 | 快速开发、多 Agent 协同 |
| CrewAI | 角色化设计，内置多种记忆类型（短期 RAG、长期 SQLite） | 分工明确的多 Agent 系统 |
| Google ADK | Google 官方 Agent 开发工具包，原生支持 A2A 协议 | Google 生态集成 |
| Spring AI | Java 生态，通过 @Tool 注解和 FunctionCallback 实现工具调用 | 企业级 Java 应用 |
总结：选型关键看生态和语言栈——Python 生态首选 LangChain/LangGraph，Java 生态选 Spring AI，多 Agent 协作场景看 CrewAI/AutoGen，Google 生态用 ADK。
【中等】什么是 RAG（检索增强生成）？它在 Agent 中扮演什么角色？⭐⭐⭐⭐
RAG（Retrieval-Augmented Generation） 是一种将外部知识检索与LLM 生成相结合的技术范式：先从知识库中检索与问题相关的文档片段，再将检索结果作为上下文注入 Prompt，引导 LLM 基于真实数据生成回答。
RAG 的核心流程：
- 索引阶段：将文档切分为 Chunk，通过 Embedding 模型转为向量，存入向量数据库。
- 检索阶段：用户提问时，将问题向量化，通过语义相似度检索 Top-K 相关片段。
- 生成阶段：将检索结果 + 用户问题一起注入 LLM，生成基于事实的回答。
RAG 在 Agent 中的角色：
- 知识增强：为 Agent 提供领域专有知识，弥补 LLM 训练数据的局限性。
- 减少幻觉：回答基于检索到的真实文档，而非 LLM 凭空生成。
- 工具集成：RAG 本身可作为 Agent 的一个工具（如"知识库查询工具"），Agent 在推理链中按需调用。
总结：RAG = 检索（给 LLM 提供真实上下文）+ 生成（基于上下文产出精准回答），是 Agent 连接私有知识库、减少幻觉的核心桥梁。
【简单】什么是 LLM 的幻觉问题？Agent 如何缓解幻觉？⭐⭐⭐⭐
幻觉（Hallucination） 是指 LLM 生成的内容看似流畅合理，但实际上与事实不符或缺乏依据的现象。主要表现为：捏造不存在的事实、引用虚假来源、逻辑推理错误等。
Agent 缓解幻觉的核心策略：
| 策略 | 原理 |
|---|---|
| RAG 知识增强 | 检索真实文档作为上下文，让 LLM 基于事实回答 |
| Tool Calling | 调用搜索/API 获取实时数据，替代 LLM 凭记忆回答 |
| 自我反思 | Agent 检查输出一致性，发现矛盾时重新推理 |
| 多源交叉验证 | 从多个数据源获取信息，交叉比对减少单一来源的错误 |
| 结构化输出约束 | 要求 Agent 输出引用来源（Citation），便于追溯和验证 |
总结：幻觉的根源是 LLM 的概率生成本质——它"预测下一个 token"而非"查证事实"。Agent 通过 RAG 引入真实知识、通过工具调用获取实时数据、通过反思机制自我纠错，构建多层防线来缓解幻觉。
记忆、工具与规划
【中等】AI Agent 的记忆机制有哪些类型？如何实现长短期记忆？⭐⭐⭐⭐
AI Agent 的记忆分为四种类型：
| 记忆类型 | 定义 | 实现方案 |
|---|---|---|
| 工作记忆 | 当前任务的即时上下文 | LLM 上下文窗口直接承载 |
| 短期记忆 | 近期对话历史和中间推理结果 | 向量数据库存储最近 N 轮对话的语义关联 |
| 长期记忆 | 用户偏好、历史经验、领域知识 | 向量数据库（语义检索）+ 知识图谱（关系推理） |
| 程序记忆 | 编码化的操作流程和技能 | 固化为 Prompt 模板或工具调用链 |
长短期记忆的分层架构：
- 工作记忆层：当前任务信息留在上下文窗口内。
- 短期记忆层：近期重要信息存入向量数据库，支持 10-20 轮对话的语义关联检索。
- 长期记忆层：经验证的长期价值沉淀为知识图谱/图数据库。
- 永久记忆层：进一步固化为可进化的用户档案。
主流实现方案：
- Mem0：专为 Agent 设计的开源记忆层，采用向量数据库 + 知识图谱 + 键值数据库的混合存储架构，支持智能提取、去重、合并和冲突解决，引入时序权重衰减模拟人类遗忘机制。
- LangGraph：支持短期（运行时上下文）与长期记忆（向量数据库），同时提供实体记忆功能。
- 混合检索策略：结合向量相似度检索和结构化查询，降低漏检风险。
关键工程步骤：① 使用 LLM 从对话中自动抽取结构化事实与偏好 → ② 存入混合存储（向量库 + 图数据库）→ ③ 检索时并行查询多种存储，通过评分层综合排序 → ④ 定期执行记忆去重、冲突解决和衰减清理。
总结：记忆系统的核心思想是分层——当前信息留窗口、近期信息存向量、长期价值沉淀图谱，通过混合检索策略在相关性和开销之间取得平衡。
【中等】什么是 AI Agent 中的工具调用（Tool Calling）？它的基本流程是怎样的？⭐⭐⭐
Tool Calling 是 AI Agent 的核心能力，允许 LLM 在需要时调用外部工具/函数来获取实时数据或执行操作。LLM 本身不执行工具，而是表达调用意图，由应用程序代为执行并返回结果。
基本流程：
- 定义工具：声明工具的名称、描述和参数 Schema（JSON Schema）。
- AI 决策：模型分析用户意图，判断是否需要调用工具，生成结构化的工具调用请求。
- 执行工具：应用程序分发并执行对应的工具方法。
- 结果返回：将工具执行结果传回模型，模型整合结果生成最终回复。
Spring AI 的三种工具定义方式：
| 方式 | 特点 | 适用场景 |
|---|---|---|
注解式 @Tool | 最常用，方法加注解即可 | 常规业务工具 |
函数式 Function/BiFunction | 基于 JDK 函数式接口，代码极简 | 轻量工具 |
编程式 ToolCallback | 手动构建工具元信息，最灵活 | 动态工具、插件化 |
总结：Tool Calling 的本质是"LLM 决策 + 应用执行"的分工——LLM 负责理解意图和生成调用参数，应用层负责实际执行和结果回传，框架层（Spring AI、LangChain）负责中间的桥接和编排。
【困难】Agent 的任务规划有哪些常见策略？Plan-and-Solve 和 ReAct 各自适合什么场景？⭐⭐⭐
任务规划是 Agent 将复杂目标拆解为可执行子任务序列的核心能力，常见策略：
| 策略 | 原理 | 优势 | 劣势 |
|---|---|---|---|
| Plan-and-Solve | 先完整制定计划，再逐步执行 | 全局视野，结构清晰 | 计划可能因信息不足而错误 |
| ReAct | 思考→行动→观察交替进行，边做边调整 | 灵活适应，实时纠错 | 缺乏全局规划 |
| Reflexion | 在 ReAct 基础上增加评估和反思，跨任务学习 | 持续优化 | 需要多次试错 |
| Tree-of-Thought | 将推理展开为树结构，搜索最优路径 | 探索空间大 | 计算开销高 |
| LATS | 结合蒙特卡洛树搜索和 LLM 反思 | 平衡探索与利用 | 实现复杂 |
Plan-and-Solve vs ReAct 的选择：
- Plan-and-Solve 适合：任务结构清晰、步骤明确的场景（如"写一份报告：先调研→再分析→最后总结"）。
- ReAct 适合：需要根据中间结果动态调整策略的场景（如"帮我查某公司的最新财务状况"——每一步搜索的结果决定下一步方向）。
- 实际工程中：通常混合使用——先用 Plan-and-Solve 制定高层计划，执行每个子任务时用 ReAct 进行即时推理和调整。
总结：没有"万能"的规划策略——结构化任务用 Plan-and-Solve 先规划后执行，探索性任务用 ReAct 边想边做，高可靠性场景叠加 Reflexion 反思机制，实践中往往混合使用。
【中等】什么是 Reflexion？它和 ReAct 有什么区别？⭐⭐⭐
Reflexion（Shinn et al., 2023）是在 ReAct 基础上增加了**评估（Evaluator）和自我反思（Self-Reflection）**机制的框架，形成"行动→评估→反思→迭代"的学习闭环。
与 ReAct 的核心区别：
| 维度 | ReAct | Reflexion |
|---|---|---|
| 关注范围 | 单次任务的即时推理-行动循环 | 跨任务的持续优化 |
| 经验保留 | 不保留跨任务经验 | 将失败经验以语言形式存入记忆 |
| 纠错能力 | 仅依赖当前轮次的观察进行调整 | Evaluator 判断失败原因，生成反思指导下次 |
自我纠错机制：当 Agent 失败时 → Evaluator 判断失败原因 → Self-Reflection 生成文本反思（如"上次用冷水无效，因为油渍需要热分解"）→ 存入滑动窗口记忆（最多保留 3 条）→ 下次执行时作为上下文指导行动。
总结：ReAct 解决"当下怎么想怎么做"，Reflexion 解决"这次失败了下次怎么改进"——Reflexion = ReAct + 评估 + 反思记忆，实现了从即时推理到跨任务学习的进化。
【简单】AutoGPT 如何实现自主决策？⭐⭐
AutoGPT 通过以下机制实现自主决策：
- 目标分解：以 LLM 为决策核心，接收高层目标后自主分解为子任务序列。
- 自主循环：循环执行"思考→规划→调用工具→观察结果→调整计划"，无需人类逐步指令。
- 工具集成：集成网络搜索、文件读写、代码执行等工具。
- 记忆维持：通过短期记忆（上下文窗口）和长期记忆（向量数据库）维持任务状态。
总结：AutoGPT 是 Agent 自主决策的典型代表，其核心模式是"目标驱动 + 工具赋能 + 记忆持续 + 循环迭代"。
【简单】LLM Agent 在多模态任务中如何执行推理？⭐⭐
LLM Agent 通过多模态感知系统接收文本、图像、音频等不同模态的输入，由 LLM 统一理解后，按照 ReAct 等推理范式进行任务分解和工具调用。
典型流程：接收图像 → OCR/视觉模型识别内容 → 调用搜索工具验证 → 整合信息生成结论。
关键挑战：将多模态信息统一编码为 LLM 可理解的表示，并在推理链中协调不同模态的处理步骤。
总结：多模态推理的核心在于"统一理解 + 分步处理"——LLM 作为统一的理解层，根据输入模态动态选择处理工具和推理路径。
上下文管理与约束
【中等】什么是 Agent 的上下文窗口？为什么它是 Agent 工程中最核心的约束？⭐⭐⭐
上下文窗口是模型在一次交互中能处理的最大 Token 数量（包含输入 Prompt + 输出 Completion）。
它是最核心约束的原因：
- 容量有限：Agent 需在窗口内同时容纳系统指令、工具定义、对话历史、工具返回结果和推理过程。
- 成本递增：窗口越长，推理延迟和计算成本越高（注意力计算为 O(n²)）。
- 信息丢失：超出窗口的内容会被截断，导致关键信息丢失。
- 注意力衰减：即使在窗口范围内，模型对中间信息的注意力也可能下降（"Lost in the Middle" 现象）。
总结：上下文窗口是 Agent 工程的"物理天花板"——所有架构设计（记忆分层、上下文压缩、工具结果处理）本质上都在与这个约束博弈。
【中等】当对话历史超出上下文窗口时，有哪些上下文压缩策略？⭐⭐⭐
| 策略 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| 截断（Truncation） | 直接丢弃早期对话 | 简单高效 | 可能丢失关键信息 |
| 摘要压缩 | 调用 LLM 将长对话压缩为摘要 | 保留核心语义 | 压缩消耗 Token，丢失细节 |
| 上下文卸载 | 完整信息保存到外部文件，窗口中仅保留摘要和路径 | 信息不丢失，Token 节省最高 61% | 需额外文件读取 |
| 分层保护 | 标记关键内容为不可裁剪，仅压缩探索过程噪音 | 关键信息有保障 | 标记策略设计复杂 |
| 滑动窗口 + 重要性评分 | 根据信息的重要性和时效性动态选择保留内容 | 动态适应 | 评分模型需调优 |
总结：上下文压缩的核心原则是"保重要、压次要、卸完整"——关键信息留在窗口内，次要信息压缩为摘要，完整数据卸载到外部存储按需读取。
【中等】AI Agent 如何处理工具调用返回超大结果的问题？⭐⭐
| 方案 | 原理 |
|---|---|
| 结果截断/分页 | 对超大返回结果截断或分页，只注入最相关的部分 |
| 摘要化 | 用 LLM 对工具返回的大结果进行摘要，注入摘要而非原始数据 |
| 上下文卸载 | 完整结果保存到外部文件，窗口中仅保留摘要和文件路径 |
| 结构化提取 | 从大结果中只提取与当前任务相关的关键字段 |
| 分层处理 | 先用轻量模型/规则筛选，再用 LLM 处理筛选后的结果 |
总结：处理超大结果的核心思路是"先筛后注"——通过截断、摘要、提取等手段将海量数据压缩到上下文可承载的密度，避免"信息洪水"淹没 Agent 的推理能力。
【中等】什么是 Agent 的 Guardrails（护栏）？如何设计安全边界？⭐⭐⭐
Guardrails（护栏） 是在 Agent 系统中设置的安全约束和防护机制，用于确保 Agent 的行为在预期范围内，防止产生有害输出或执行危险操作。
Guardrails 的设计层次：
| 层次 | 机制 | 示例 |
|---|---|---|
| 输入护栏 | 过滤和验证用户输入 | 拒绝注入攻击、敏感话题过滤 |
| 输出护栏 | 检查 Agent 生成的内容 | 有害内容检测、事实一致性校验 |
| 工具护栏 | 限制工具调用的权限和范围 | 禁止删除操作、限制文件访问路径 |
| 流程护栏 | 约束 Agent 的执行流程 | 最大迭代次数、超时机制、Token 预算 |
| 人工审核（HITL） | 关键操作需人工确认 | 高风险操作前的确认审批 |
主流框架：
- NeMo Guardrails（NVIDIA）：通过 Colang 语言定义对话流和安全规则，支持输入/输出检查、话题限制。
- Guardrails AI：提供
Guard和Validator机制，对 LLM 输出进行结构化验证和修正。
总结：Guardrails 是 Agent 系统的"安全网"——输入端防注入、输出端防有害、工具端防越权、流程端防失控，多层防护确保 Agent 在生产环境中安全可控。
协议、标准与生态 (MCP & A2A)
【中等】MCP 协议是什么？它在 AI Agent 系统中解决了什么问题？⭐⭐⭐⭐
MCP（Model Context Protocol，模型上下文协议） 是由 Anthropic 发布的开放标准，旨在为 LLM 应用与外部工具/数据源之间提供统一的连接接口。
解决的核心问题：传统集成依赖硬编码 API 连接，每接入一个新工具都需要定制开发。MCP 通过标准化协议实现"即插即用"，使 LLM 能基于任务上下文独立定位、选择并与外部服务交互，大幅降低集成复杂度。
总结：MCP 之于 AI Agent，犹如 USB 之于外设——一个标准化接口，让 Agent 连接任何工具/数据源都无需定制开发。
【中等】MCP 协议的架构包含哪些核心组件？⭐⭐⭐
MCP 采用客户端-服务器架构，三大核心组件：
| 组件 | 职责 |
|---|---|
| MCP Host | 运行 LLM 的应用（如 Claude Desktop、IDE），管理 Client 生命周期 |
| MCP Client | Host 内的通信代理，与 Server 保持一对一连接，封装/转发标准化请求 |
| MCP Server | 连接具体工具/数据源的功能适配器，接收请求、执行操作、返回结果 |
通信基于 JSON-RPC 2.0，支持 stdio（本地）和 HTTP/SSE（远程）两种传输模式。
总结：MCP 的 Host-Client-Server 三层架构实现了 LLM 与工具的解耦——Host 管 LLM 集成，Client 管通信协议，Server 管工具适配。
【简单】MCP 的工作流程是什么？⭐⭐⭐
MCP 的典型工作流分三个阶段：
- 初始化：Client 和 Server 交换并协商能力，就协议版本达成一致。
- 操作：用户发起请求 → Host 将上下文和工具清单提供给 LLM → LLM 生成结构化 JSON 调用意图 → Client 通过 JSON-RPC 发送至 Server → Server 执行操作 → 结果回传 → LLM 评估后生成最终响应或继续下一轮调用。
- 关闭：连接优雅关闭。
总结：MCP 工作流 = 初始化握手 → 请求-调用-返回循环 → 优雅关闭，核心是 LLM 决策 + JSON-RPC 通信 + Server 执行的三方协作。
【中等】MCP 协议安全性设计包含哪些层面？⭐⭐
MCP 的安全性设计涵盖五个层面：
- 访问隔离：LLM 不直接访问系统资源，所有操作经 MCP Server 中转，控制数据边界。
- 授权认证：支持 OAuth 2.1 进行授权认证。
- Root 机制：限制 Server 可访问的文件和目录范围。
- Sampling 审查：Sampling 功能要求用户审查和批准后才能传递给 LLM。
- 传输加密：支持 HTTPS/TLS 加密传输。
总结：MCP 安全设计的核心思想是"LLM 不碰底层"——通过 Server 中转、权限限制、人工审查三层隔离，确保 Agent 的工具调用安全可控。
【简单】如何将已有的应用转换成 MCP 服务？⭐⭐
将已有应用转换为 MCP Server 的步骤：
- 实现接口规范：定义工具的名称、描述和参数 Schema。
- 选择传输方式：本地 stdio 或远程 HTTP/SSE。
- 封装已有功能：使用官方 SDK（Python、TypeScript、Java 等）封装。
- 注册 Server：在 MCP Host 中注册 Server 地址。
Anthropic 提供了官方 SDK，社区也有 fastmcp 等便捷实现。
总结：已有应用接入 MCP 的关键是"包一层标准协议"——内部逻辑不变，对外暴露符合 MCP 规范的工具接口。
【中等】什么是 A2A 协议？它和 MCP 协议有什么区别？⭐⭐⭐⭐
A2A（Agent-to-Agent）协议是由 Google 发起、50+ 合作伙伴共同贡献的开源通信标准，旨在让不同厂商、不同框架构建的 AI Agent 能够协同工作。
与 MCP 的核心区别：
| 维度 | MCP | A2A |
|---|---|---|
| 连接方向 | 纵向：Agent ↔ 工具/数据源 | 横向：Agent ↔ Agent |
| 解决问题 | Agent 如何使用外部工具 | Agent 之间如何协作 |
| 比喻 | Agent 的"手"（连接工具） | Agent 之间的"语言"（协作通信） |
| 关系 | 两者互补，一个完整的 Agent 系统通常同时使用两者 |
总结：MCP 解决"Agent 怎么用工具"，A2A 解决"Agent 怎么合作"——MCP 是纵向连接，A2A 是横向协作，二者互补构成完整的 Agent 生态。
【中等】A2A 协议中的 Agent Card 是什么？⭐⭐⭐
Agent Card 是每个 A2A Agent 的"数字名片"，是发布在已知路径（如 /.well-known/agent.json）的 JSON 文件。
包含内容：Agent 的唯一身份标识、功能描述（Skills）、访问端点 URL、支持的交互模态、安全需求声明等。
作用：让客户端 Agent 能够自动发现并评估哪个远程 Agent 适合处理特定任务，是多 Agent 协作中的"服务发现"机制。
总结：Agent Card 之于 A2A，如同 DNS 之于互联网——通过标准化的"名片"让 Agent 能被自动发现和识别。
【中等】A2A 协议的核心架构及主要组件有哪些？⭐⭐⭐
A2A 采用客户端-服务器架构，四大核心数据模型：
| 组件 | 定义 |
|---|---|
| Agent Card | Agent 的机器可读名片，包含身份、能力、端点等信息 |
| Task（任务） | 最小可调度单元，生命周期：已提交→处理中→需输入→已完成/失败/已取消 |
| Message（消息） | Task 内所有交互消息的统一载体（文本、文件、数据、表单等） |
| Artifact（工件） | Task 完成后的结构化输出物，确保输出的一致性和易用性 |
总结：A2A 的四大组件构成完整的任务生命周期——Agent Card 负责发现，Task 负责调度，Message 负责通信，Artifact 负责交付。
【简单】A2A 协议有哪五大设计原则？⭐⭐
- 关注 Agent 能力（不透明代理）：Agent 之间无需共享内部记忆、逻辑或工具，只关注"对话内容"和"任务交付"。
- 采用通用 Web 标准：基于 HTTP、SSE、JSON-RPC 2.0 等成熟标准，降低集成门槛。
- 内置安全性：原生支持 API Key、OAuth2、OpenID Connect、mTLS 等认证方案。
- 支持长时间任务：能处理耗时数小时甚至数天的任务，提供实时状态更新。
- 处理多样化数据类型：原生支持文本、音频、视频和交互式表单等多模态数据。
总结：A2A 的设计哲学是"能力透明、内部黑盒"——只暴露"能做什么"和"怎么通信"，不暴露"怎么做"。
【中等】A2A 协议的工作流程是怎样的？⭐⭐⭐
A2A 遵循客户端-服务器模型，一个 Agent（客户端）请求执行任务，另一个 Agent（服务器）执行任务，角色可在对话中互换。
具体工作流：
- 服务发现：客户端 Agent 检查远程 Agent 的 Agent Card，确认能力匹配。
- 任务发起：通过
SendMessage或SendStreamingMessage发起任务请求。 - 任务执行：远程 Agent 接收任务，状态变为"处理中"，执行过程中可通过
GetTask查询进度。 - 实时推送：对于长任务，通过 SSE 实时推送状态更新。
- 结果返回：任务完成后，远程 Agent 以 Artifact 格式返回结构化结果。
- 任务终止：如需终止，可调用
CancelTask。
总结：A2A 工作流 = Agent Card 发现 → 任务创建 → 执行+状态推送 → Artifact 交付，本质上是标准化的"请求-执行-交付"异步协作模式。
【简单】A2A 协议与 MCP 协议如何协同工作？⭐⭐⭐
两者是互补关系，解决不同层面的问题：
- MCP：纵向连接——Agent ↔ 工具/数据源，解决"Agent 如何使用工具"。
- A2A：横向协作——Agent ↔ Agent，解决"Agent 之间如何协作"。
多 Agent 系统架构设计：
- Agent 内部：每个 Agent 通过 MCP 连接各自的工具集（数据库、搜索引擎、文件系统等）。
- Agent 之间：通过 A2A 进行横向协作，每个 Agent 发布 Agent Card 声明能力。
- 编排层：主 Agent（Orchestrator）通过 A2A 发现并调度专业 Agent。
示例：用户问"分析竞品并生成报告"→ 编排 Agent 通过 A2A 分发给"搜索 Agent"（MCP 连接搜索引擎）和"数据分析 Agent"（MCP 连接数据库）→ 各自完成后通过 A2A Artifact 返回结果 → 编排 Agent 汇总生成报告。
总结：MCP 让每个 Agent "手中有工具"，A2A 让多个 Agent "协同有语言"——一个完整的 Agent 生态需要同时具备纵向工具连接和横向协作通信。
系统架构、安全与工程化
【中等】什么是 Agent Loop（智能体循环）？Agent 的工作过程是怎样的？⭐⭐⭐
Agent Loop 是 OpenAI Codex 核心架构，是将用户意图、模型大脑和执行工具串联成闭环的系统。Agent 的工作过程遵循"感知→规划→执行→反思"的四阶闭环：
- 构建 Prompt（感知）：将用户输入、系统指令、工具定义、历史上下文组装为完整 Prompt。
- 模型推理（规划）：LLM 分析意图，决定下一步行动（直接回复或调用工具）。
- 工具调用（执行）：若需调用工具，执行对应的 API/函数，获取结果。
- 结果反馈（反思）：将工具返回结果注入上下文，检查是否达标。若未达标则调整计划，回到步骤 2 继续推理。
- 循环终止：当 LLM 判断任务完成，生成最终响应。
整个过程由 LLM 驱动，记忆模块持续存储相关信息，规划模块根据执行情况动态调整。
总结：Agent Loop 的本质是"Prompt → 推理 → 行动 → 反馈"的无限循环，直到 LLM 认为任务完成或被外部终止——所有 Agent 框架的核心都是这个循环的不同实现。
【中等】Agent 系统中如何设计终止条件？如何解决死循环问题？⭐⭐⭐
常见终止条件：
| 策略 | 原理 |
|---|---|
| 任务完成判定 | LLM 明确输出"任务完成"标记或 Final Answer |
| 最大迭代次数 | 设置硬性上限（如 5-10 轮），防止无限循环 |
| 重复检测 | 同一 Action 连续出现且 Observation 不变，判定为陷入僵局 |
| 平台期检测 | 连续 N 轮未发现新问题且老问题未减少，判定为收敛 |
| Token 预算 | 设置 Token 消耗上限，超出后强制终止 |
| 超时机制 | 设置时间上限 |
死循环的典型场景：Agent 在两个方案间反复横跳，或反复调用同一工具得到相同结果。
解决策略：
- 硬性上限：设置最大迭代次数（如 10 轮）。
- 重复检测：连续执行相同 Action 且 Observation 不变，强制终止。
- 反思介入：让 Agent 意识到自己在重复，主动切换策略。
- 预算兜底：Token/时间预算超出后强制退出并返回部分结果。
总结：终止条件设计的关键是"多重保险"——完成判定为主、迭代次数为底、重复检测为辅、预算超时兜底，确保 Agent 在任何情况下都能优雅退出。
【中等】多 Agent 协作有哪些常见的编排模式？⭐⭐⭐
| 编排模式 | 原理 | 适用场景 |
|---|---|---|
| 顺序编排（Sequential） | Agent A 的输出作为 Agent B 的输入 | 流水线任务（研究→写作→审校） |
| 并行编排（Parallel） | 多个 Agent 同时处理独立子任务 | 可并行的场景（同时搜索多数据源） |
| 层级编排（Hierarchical） | 主 Agent 分配任务给子 Agent，完成后汇报 | 复杂多步骤任务 |
| 辩论/投票模式 | 多个 Agent 对同一问题给出答案，投票达成共识 | 需要高准确性的决策场景 |
总结：编排模式的选择取决于任务的依赖关系——串行依赖用顺序、独立子任务用并行、层级分解用层级、需要共识用投票。
【中等】子 Agent（Subagent）模式有什么优势和挑战？⭐⭐
优势：
- 任务隔离：每个子 Agent 专注单一职责，降低复杂度。
- 上下文精简：子 Agent 只接收与其任务相关的信息，避免上下文污染。
- 可复用性：子 Agent 可被不同父 Agent 复用。
挑战与边界问题：
| 问题 | 说明 |
|---|---|
| 通信开销 | 父子 Agent 间的信息传递消耗额外 Token |
| 状态同步 | 子 Agent 的执行状态需要反馈给父 Agent |
| 错误传播 | 子 Agent 的错误可能影响父 Agent 的决策 |
| 权限边界 | 子 Agent 的工具权限应 ≤ 父 Agent（最小权限原则） |
总结：子 Agent 模式的核心价值是"分治"——隔离复杂度、精简上下文、提升复用性，但要警惕通信开销、错误传播和权限越界。
【中等】Agent 系统中的 Function Calling 和 MCP 有什么区别？⭐⭐⭐
| 维度 | Function Calling | MCP |
|---|---|---|
| 定义 | 模型原生能力，由模型提供商定义 | 标准化协议层，独立于模型 |
| 工具定义 | 直接嵌入 API 请求中 | 通过 MCP Server 独立部署 |
| 优点 | 简单直接，无需额外基础设施 | 统一接口，工具可跨模型复用，支持动态发现 |
| 缺点 | 工具与模型强耦合，不同模型格式不统一 | 需部署和维护 MCP Server，架构更复杂 |
总结：Function Calling 是"模型内置的工具接口"，MCP 是"独立的工具标准协议"——前者简单但耦合，后者复杂但解耦，生产级系统通常用 MCP 统一管理工具。
【中等】如何设计 AI Agent 的工具权限控制？⭐⭐
设计原则：
- 最小权限原则：每个 Agent 只授予完成其任务所需的最小工具集。
- 分级授权：读操作（查询）权限宽松，写操作（修改/删除）权限严格，需人工审批。
- 沙箱隔离：代码执行类工具在沙箱中运行，限制文件系统访问范围。
- 审计日志：记录所有工具调用行为，支持事后追溯和异常检测。
- 人工审核（HITL）：高风险操作（如资金转账、数据删除）需人工确认后方可执行。
总结：工具权限控制的核心是"最小权限 + 分级授权 + 关键操作人工审批"，确保 Agent 有能力完成任务但不越权。
【困难】如何评估 Agent 系统的效果？有哪些评估指标和框架？⭐⭐⭐⭐
Agent 系统评估是一个多维度问题，需要覆盖从单步推理到端到端任务完成的全链路。
核心评估维度：
| 维度 | 评估内容 | 常用指标 |
|---|---|---|
| 任务完成率 | Agent 是否成功完成用户指定的任务 | 成功率（Success Rate） |
| 推理质量 | 推理链的逻辑正确性和效率 | 步骤准确率、推理步数 |
| 工具使用准确性 | 是否选择了正确的工具并传入正确参数 | 工具选择准确率、参数准确率 |
| 幻觉率 | 输出中是否包含与事实不符的内容 | 幻觉率（Faithfulness Score） |
| 延迟与成本 | 端到端响应时间和 Token 消耗 | P50/P95 延迟、Token 成本 |
| 安全与合规 | 是否触发 Guardrails、是否有越权操作 | 违规率、护栏触发率 |
主流评估框架：
- AgentBench：涵盖操作系统、数据库、知识图谱等 8 个环境的综合评测。
- GAIA：评估通用 AI 助手解决现实世界问题的能力。
- SWE-bench：评估 Agent 在真实 GitHub Issue 上的代码修复能力。
- LangSmith（LangChain）：提供 trace 分析、评测数据集和 A/B 测试功能。
总结：Agent 评估不能只看"最终答案对不对"——需要从任务完成率、推理质量、工具准确性、幻觉率、成本效率、安全合规六个维度全面衡量，并用标准化框架（AgentBench/SWE-bench）进行可复现的评测。
【中等】Agent 系统上线后面临哪些工程化挑战？⭐⭐⭐
| 挑战 | 具体问题 | 应对策略 |
|---|---|---|
| 可观测性 | Agent 行为是黑盒，难以定位问题 | 全链路 trace 日志、推理过程可视化 |
| 成本控制 | LLM 调用成本高，多步推理 Token 消耗大 | Token 预算管理、缓存复用、轻量模型分流 |
| 延迟优化 | 多轮推理 + 工具调用导致响应慢 | 并行工具调用、结果缓存、流式输出 |
| 错误恢复 | 工具调用失败、LLM 输出异常时的容错 | 重试机制、降级策略、人工兜底 |
| 版本管理 | Prompt 变更、模型升级可能导致行为不一致 | Prompt 版本控制、A/B 测试、回归测试 |
| 安全合规 | 数据隐私、输出安全、权限管控 | Guardrails、审计日志、数据脱敏 |
总结：Agent 工程化的核心挑战是"从 Demo 到 Production"的鸿沟——Demo 只关心"能不能做"，生产系统还必须解决可观测性、成本控制、延迟优化、错误恢复和安全合规等工程问题。