1. 1. 一、核心概念与基础
    1. 1.1. 1. 什么是 AI Agent？与传统 AI 模型的根本区别？
    2. 1.2. 2. ReAct 框架的核心思想（Reasoning + Acting）
    3. 1.3. 3. 什么是工具调用（Tool / Function Calling），为什么重要？
    4. 1.4. 4. 什么是 Agent 的规划（Planning）？常见规划方法？
  2. 2. 二、架构与设计
    1. 2.1. 1. 如果设计一个多 Agent 协作系统，需要哪些关键组件？
      1. 2.1.1. ① Orchestrator（调度器 / 控制器）
      2. 2.1.2. ② 多类 Agent
      3. 2.1.3. ③ Memory（记忆系统）
      4. 2.1.4. ④ 工具系统
      5. 2.1.5. ⑤ 监控与安全层
      6. 2.1.6. 核心交互流程：
    2. 2.2. 2. Agent 处理长上下文任务的挑战与解决方案
      1. 2.2.1. 挑战：
      2. 2.2.2. 解决方案：
    3. 2.3. 3. 如何设计 Agent 的记忆系统？
      1. 2.3.1. 短期记忆（Working Memory）
      2. 2.3.2. 长期记忆（Long-term Memory）
      3. 2.3.3. 关键能力：
    4. 2.4. 4. 如何保证工具调用安全与可靠？
      1. 2.4.1. （1）工具白名单
      2. 2.4.2. （2）强模式的 JSON schema
      3. 2.4.3. （3）沙盒化执行
      4. 2.4.4. （4）多轮验证
      5. 2.4.5. （5）限制循环
  3. 3. 三、工程实现与工具
    1. 3.1. 1. 主流 Agent 框架比较（面试常问）
    2. 3.2. 2. 提升检索器（Retriever）质量的高级技巧
      1. 3.2.1. 1. Hybrid Search（BM25 + Vector）
      2. 3.2.2. 2. Reranker（如 BGE-Reranker）
      3. 3.2.3. 3. Metadata Filtering
      4. 3.2.4. 4. Query Expansion
      5. 3.2.5. 5. Multi-step Retrieval（分阶段检索）
      6. 3.2.6. 6. Graph RAG / 结构化索引
    3. 3.3. 3. Agent 的典型工作流程与性能瓶颈
      1. 3.3.1. 典型流程：
      2. 3.3.2. 潜在瓶颈：
      3. 3.3.3. 优化策略：
    4. 3.4. 4. 如何评估一个 Agent 系统？
      1. 3.4.1. 维度 1：正确性 / 成功率
      2. 3.4.2. 维度 2：稳健性
      3. 3.4.3. 维度 3：性能
      4. 3.4.4. 维度 4：用户体验
      5. 3.4.5. 维度 5：交互性
  4. 4. 四、场景与实践
    1. 4.1. 1. 电商客服 Agent 的能力、工具、流程
      1. 4.1.1. 核心能力：
      2. 4.1.2. 工具集：
      3. 4.1.3. 工作流程（示例）：
    2. 4.2. 2. 当 Agent 在复杂任务中失败，你的调试思路
      1. 4.2.1. ① 是否走对规划？
      2. 4.2.2. ② 工具调用参数是否正确？
      3. 4.2.3. ③ 推理链是否过长？
      4. 4.2.4. ④ 是否需要增加记忆或检索？
      5. 4.2.5. ⑤ 是否需要增加 Reranker？
      6. 4.2.6. ⑥ 是否需要多 Agent？
    3. 4.3. 3. 未来 Agent 技术的最大挑战是什么？如何解决？
      1. 4.3.1. 挑战 1：长期任务的稳定性（State Management）
      2. 4.3.2. 挑战 2：多工具、多 Agent 协作的可控性
      3. 4.3.3. 挑战 3：安全与可信执行

2025年｜ai agent面试题

,

一、核心概念与基础

1. 什么是 AI Agent？与传统 AI 模型的根本区别？

一句话定义：
AI Agent = 有目标、有记忆、能推理、能调用工具、能自主执行任务的智能体。

它与传统 AI 模型的区别：

维度 传统 AI 模型 AI Agent
功能 输入→输出（单步） 连续多步推理与行动
是否有“目标” 没有，只是执行推断 有明确目标，能自主规划
是否能主动行动 不能，只能输出文本 可以调用工具、API、代码、浏览器等
是否有记忆 没有 有短期记忆 & 长期记忆
任务类型 单任务 多步骤、多工具的复杂任务
自主性 0 高（规划→执行→反馈→迭代）

一句话总结本质区别：

传统模型是“计算器”，Agent 是“可以自己决策如何完成任务的智能助手”。

2. ReAct 框架的核心思想（Reasoning + Acting）

核心思想：

Agent 在执行过程中交替进行 推理（Reason） 和 行动（Act），并用行动结果作为下一步推理的依据。

典型结构：

1
2
3
4
5
6
7
Thought: 我需要先搜索产品信息
Action: search(product_id)
Observation: 返回了产品详情...
Thought: 需要检查库存
Action: check_stock(product_id)
Observation: 有库存...
Final Answer: 可以发货。

为什么比只 Reason 或只 Act 更强？

  • 只 Reason → 容易瞎推理，缺乏真实信息

  • 只 Act → 不会规划，不知道先执行什么

  • ReAct →

    • 推理决定行动
    • 行动的结果修正推理
    • 形成“反馈回路”，大幅降低幻觉

实际效果： 搜索题、计算题、工具链任务成功率大幅提升（实验中能从 <20% 提到 >70%）。

3. 什么是工具调用（Tool / Function Calling），为什么重要？

定义：
LLM 通过结构化输出（JSON）触发外部工具执行操作，例如：

  • 搜索引擎
  • 数据库查询
  • API 调用
  • 代码执行
  • 打开浏览器
  • 本地命令

为什么对 Agent 至关重要？

因为 LLM 本身：

  • 不会实时搜索
  • 不会执行代码
  • 不会访问真实世界数据
  • 不能操作系统、业务系统

工具调用 = 给 LLM 装上手脚
使其真正能解决实际业务问题。

4. 什么是 Agent 的规划（Planning）？常见规划方法？

定义：

规划就是 Agent 把一个复杂任务拆解成可执行的步骤链。

常用方法：

方法 特点 适用场景
CoT（Chain of Thought） 串行推理步骤 普通推理、简单多步骤任务
ToT（Tree of Thoughts） 分叉探索多种推理路径 复杂决策、数学题、大型任务
GoT（Graph of Thoughts） 将多个思考节点串成图，可合并/并行 大规模复杂工程任务，多 Agent 协作
Plan-Act-Reflect 先生成计划，再执行，再复盘 长任务，如研究、写论文、编程

一句话理解：

CoT 是“一条路走到底”，
ToT 是“走多条路看看哪条最好”，
GoT 是“多条路径互相分享经验”。

二、架构与设计

1. 如果设计一个多 Agent 协作系统，需要哪些关键组件？

一个标准架构包括：

① Orchestrator（调度器 / 控制器）

  • 负责任务拆解、分发、收集结果
  • 控制各个 Agent 的顺序和依赖

② 多类 Agent

  • 专家 Agent（代码、搜索、写作、数据分析）
  • 管理 Agent（做评估与复盘）
  • 工作者 Agent（执行工具调用）

③ Memory（记忆系统）

  • 短期：保存当前 session 的思路、上下文
  • 长期：知识库、历史经验、用户偏好

④ 工具系统

  • API 集成：搜索、数据库、支付、任务执行
  • 沙盒：代码执行（Python/JS sandbox）
  • 业务系统：ERP、CRM 等

⑤ 监控与安全层

  • 防止无限循环
  • 限制危险操作
  • 工具调用的白名单 / 黑名单

核心交互流程：

  1. 用户输入 → 任务交给调度器
  2. 调度器选择合适的 Agent
  3. Agent 推理 → 工具调用
  4. 返回结果 → 合并结果 → 给用户

2. Agent 处理长上下文任务的挑战与解决方案

挑战：

  1. 遗忘内容（超过上下文窗口）
  2. 状态崩坏（长对话越来越乱）
  3. 反复处理重复信息
  4. 推理链过长导致失败
  5. 成本高（tokens 爆炸）

解决方案：

  • 压缩（Summarization）：每阶段总结
  • 记忆分层：短期 + 长期
  • 向量数据库检索（RAG）
  • 分段执行（Chunk-based Execution）
  • 中间状态持久化（State Store）
  • 规划 + 子任务拆解

3. 如何设计 Agent 的记忆系统？

短期记忆（Working Memory）

  • 保存当前任务的思路、工具调用历史
  • 以“上下文窗口”形式实时存在
  • 也可以存入 state store（如 Redis）

长期记忆（Long-term Memory）

实现方式：

  • 向量数据库（FAISS、Milvus、Qdrant）

  • 分层存储：知识、用户偏好、任务经验

  • 自动写入策略：

    • 当内容出现频率高
    • 当有未来价值
    • 当用户明确要求记住

关键能力：

  • 何时写入
  • 如何读取（RAG）
  • 如何防止垃圾记忆

4. 如何保证工具调用安全与可靠？

对策：

（1）工具白名单

LLM 只能调用特定工具，不能扩展。

（2）强模式的 JSON schema

限制参数类型、数值范围。

（3）沙盒化执行

代码执行必须在 sandbox（Node sandbox、Pyodide）中。

（4）多轮验证

使用“critic agent”检查：

  • 调用是否合理？
  • 参数安全吗？
  • 是否可能引发破坏性操作？

（5）限制循环

设置：

  • 最大工具调用次数
  • 最大递归深度
  • 超时机制

三、工程实现与工具

1. 主流 Agent 框架比较（面试常问）

框架 优点 缺点 场景
LangChain 生态最大、工具多、支持各种模型 有时过度复杂、调试难 商业应用、PoC
LlamaIndex 极强的 RAG 能力、文档结构化好 Agent 功能较弱 文档问答、企业知识库
LangGraph 状态机、循环控制好、可视化强 学习曲线稍高 复杂 Agent、多 Agent 协作
AutoGen 多 Agent 协作强 自定义工具管理略复杂 多角色协作（研究、编码）
CrewAI 任务/角色定义清晰 工具链较少 自动化生产线、多 Agent 分工

如果问我企业级项目选哪个？
→ LangGraph：最稳定，最适合复杂 Agent workflow。

2. 提升检索器（Retriever）质量的高级技巧

不仅是向量检索，还有：

1. Hybrid Search（BM25 + Vector）

解决缺词、稀疏词问题。

2. Reranker（如 BGE-Reranker）

先召回大量候选，再筛选最佳答案
→ 大幅提升精度。

3. Metadata Filtering

按标签过滤，例如时间、作者、类别。

4. Query Expansion

让 LLM 帮你改写、扩展搜索 query。

5. Multi-step Retrieval（分阶段检索）

例如先找目录，再找内容。

6. Graph RAG / 结构化索引

对文档进行：

  • 概念图
  • 章节图
  • 链接图

搜索不仅是“相似”，而是“语义关联”。

3. Agent 的典型工作流程与性能瓶颈

典型流程：

  1. 解析用户意图
  2. 规划任务（CoT / Plan）
  3. 读取记忆或检索知识
  4. 工具调用
  5. 整合结果
  6. 生成最终答案
  7. 写入记忆

潜在瓶颈：

  • 多次模型调用 → 成本高
  • 检索慢（向量数据库延迟）
  • 工具调用链太长，导致超时
  • 大模型推理速度慢
  • Reranker 过重（QPS 低）

优化策略：

  • 缓存（工具结果、Embedding）
  • 轻量模型替代（small LLM for routing）
  • 并行工具执行
  • 分段计划
  • 工具预调用（prefetching）

4. 如何评估一个 Agent 系统？

维度 1：正确性 / 成功率

  • 成功完成任务比例
  • 工具调用精准度

维度 2：稳健性

  • 是否能从错误恢复
  • 是否出现幻觉

维度 3：性能

  • 延迟（Latency）
  • Token 成本
  • 工具调用次数

维度 4：用户体验

  • 可解释性
  • 答案一致性
  • 风险和安全评估

维度 5：交互性

  • 多轮任务的完成度
  • 误解率

四、场景与实践

1. 电商客服 Agent 的能力、工具、流程

核心能力：

  • 订单查询
  • 物流查询
  • 退款/退货流程指导
  • 商品推荐
  • 投诉与工单升级
  • 多轮状态追踪
  • 个性化回答（结合用户历史）

工具集：

  • get_order(order_id)
  • get_shipping(order_id)
  • refund(order_id)
  • search_product(query)
  • recommend(user_id)
  • create_ticket(user_id, description)

工作流程（示例）：

1
2
3
4
5
6
1. 用户输入：我想查一下订单1234的物流
2. Agent 解析 → 确定工具: get_shipping
3. 调用工具
4. 得到结果（在转运中心）
5. 用自然语言返回结果
6. 根据用户后续问答继续交互

2. 当 Agent 在复杂任务中失败，你的调试思路

系统化排查：

① 是否走对规划？

  • 检查 CoT / Plan 是否合理

② 工具调用参数是否正确？

  • JSON schema 是否匹配
  • 数据接口是否返回预期格式

③ 推理链是否过长？

  • 缩短任务，拆分 Subtask

④ 是否需要增加记忆或检索？

  • 看是否因为“信息丢失/遗忘”

⑤ 是否需要增加 Reranker？

  • RAG 召回不准

⑥ 是否需要多 Agent？

  • 引入 Reviewer / Critic Agent

3. 未来 Agent 技术的最大挑战是什么？如何解决？

挑战 1：长期任务的稳定性（State Management）

长任务（写代码、写论文、跑流程）容易崩坏：

  • 状态偏离
  • 幻觉累积
  • 步骤遗忘

解决方向：

  • 引入“强状态机”（如 LangGraph）
  • 更好的中途检查（Critic Agent）
  • 更稳定的计划/反思系统

挑战 2：多工具、多 Agent 协作的可控性

复杂协作容易出现：

  • 死循环
  • 工具乱调用
  • Agent 互相误解

解决方向：

  • 静态计划（Structured Plan）
  • 工具权限控制
  • 自动纠错（Auto-correct Agents）

挑战 3：安全与可信执行

Agent 越能调用系统、越危险。

解决方向：

  • 权限系统（沙盒、白名单）
  • 强 JSON 验证
  • 调用模拟（Dry run）