AI Agent 面试八股文完全指南

本文系统梳理 AI Agent 领域的核心概念与面试高频考点，涵盖定义与组件、推理框架、记忆系统、工具调用、多智能体协作等方向。

1. 如何定义一个 Agent？它通常由哪些核心组件构成？

定义

AI Agent（智能体） 是一个以大语言模型（LLM）为核心推理引擎的自主系统，能够感知环境、制定计划、调用工具并采取行动来完成用户指定的目标。与传统的"一问一答"式 LLM 调用不同，Agent 具有自主决策和多步执行的能力。

用一句话概括：

Agent = LLM + Memory + Planning + Tool Use + Action

核心组件

组件	职责	典型实现
LLM（大脑）	核心推理与决策引擎	GPT-4、Claude、LLaMA
Planning（规划）	任务分解与策略制定	CoT、ToT、ReAct
Memory（记忆）	存储历史交互与知识	对话历史、向量数据库
Tool Use（工具）	与外部系统交互	API 调用、代码执行、搜索
Action（执行）	将决策转化为实际操作	函数调用、环境交互

工作流程

用户输入 → LLM 理解意图 → 规划步骤 → 选择工具 → 执行动作
    ↑                                              ↓
    └──────────── 观察结果 / 更新记忆 ←────────────┘

Agent 的关键特征是循环执行：它不是一次性给出答案，而是在 "思考 → 行动 → 观察" 的循环中逐步逼近目标。

2. ReAct 框架、Plan-and-Solve、Reflection

ReAct（Reasoning + Acting）

ReAct 是最经典的 Agent 框架之一，由 Yao et al. (2022) 提出。其核心思想是将思维链（Reasoning）和行动（Acting）交替进行。

工作流程

Thought: 我需要查找关于 X 的信息
Action: search("X 的定义")
Observation: X 是指...
Thought: 现在我知道了 X 的定义，接下来需要...
Action: lookup("X 的应用场景")
Observation: X 常用于...
Thought: 我已经有足够的信息来回答问题了
Action: finish("最终答案...")

核心特点

Thought：LLM 的推理过程，类似 Chain-of-Thought
Action：调用外部工具（搜索、计算、API 等）
Observation：工具返回的结果，作为下一轮推理的输入
交替执行：Thought 和 Action 交替进行，形成推理链

优势

可解释性强：每步都有明确的推理过程
减少幻觉：通过外部工具获取真实数据
灵活性高：可以动态调整策略

Plan-and-Solve

Plan-and-Solve（Wang et al., 2023）是对 Zero-shot CoT 的改进，分为两个阶段：

第一阶段：Plan（规划）

让 LLM 先制定一个完整的解题计划，把复杂任务分解为子任务序列。

Prompt: "Let's first understand the problem and devise a plan to solve it.
Then, let's carry out the plan and solve the problem step by step."

第二阶段：Solve（执行）

按照计划逐步执行每个子任务。

PS+（增强版）

在 Plan-and-Solve 基础上增加了更细粒度的指令：

"extract relevant variables and their corresponding numerals"
"calculate intermediate results"
"pay attention to calculation and commonsense"

与 ReAct 的区别

维度	ReAct	Plan-and-Solve
规划方式	边想边做，动态规划	先全局规划，再执行
适用场景	需要外部工具的交互任务	复杂推理和数学问题
灵活性	高（可随时调整）	中（计划制定后较固定）

Reflection（反思）

Reflection 机制让 Agent 具备自我评估和纠错的能力。代表工作包括 Reflexion（Shinn et al., 2023）。

工作流程

执行任务 → 获得结果 → 自我评估 → 生成反思 → 存入记忆 → 重新尝试

核心思想

Self-Evaluation：Agent 评估自己的输出是否正确/完整
Verbal Reinforcement：将反思以自然语言形式存储
Memory Update：反思结果写入长期记忆，避免重复犯错

实际应用

第一次尝试：直接编写代码 → 测试失败
反思："我忽略了边界条件的处理"
第二次尝试：加入边界条件检查 → 测试通过

Reflection 的价值在于将"试错经验"转化为可复用的知识，本质上是一种基于语言的强化学习。

3. 规划能力：CoT、ToT、GoT 等

Chain-of-Thought（CoT，思维链）

CoT（Wei et al., 2022）是最基础的推理增强方法。

核心思想

通过在 Prompt 中提供逐步推理的示例，引导 LLM 展示中间推理步骤，而非直接输出答案。

类型

Few-shot CoT：在 Prompt 中给出带推理步骤的示例
Zero-shot CoT：仅添加 "Let's think step by step"

局限

CoT 是线性的思维过程，一条路走到黑，无法回溯或探索多条路径。

Tree-of-Thought（ToT，思维树）

ToT（Yao et al., 2023）将 CoT 从线性扩展为树状搜索。

核心思想

              问题
            /  |  \
         思路A 思路B 思路C
        / \     |     \
      A1  A2   B1    C1
      ↓        ↓
    评估     评估
      ↓        ↓
   继续探索  剪枝放弃

关键机制

Thought Generation：在每个节点生成多个候选思路
State Evaluation：评估每个思路的质量（自评/投票）
Search Algorithm：使用 BFS 或 DFS 遍历思维树
Pruning：剪掉低质量的分支

适用场景

需要探索和回溯的任务：创意写作、数学证明、策略规划等。

Graph-of-Thought（GoT，思维图）

GoT（Besta et al., 2023）进一步将思维结构从树扩展为有向图。

核心改进

允许合并不同分支的思路（ToT 不允许）
支持循环和反馈
思路之间可以互相参考和融合

思路A ──→ 思路B
  ↓         ↓
  └──→ 合并节点 ←──┘
         ↓
      最终方案

三者对比

方法	结构	搜索方式	复杂度	适用场景
CoT	线性链	无搜索	低	简单推理
ToT	树	BFS/DFS	中	需要探索的推理
GoT	有向图	图搜索	高	需要融合多路径的复杂推理

其他规划方法

LLM+P：将规划任务转换为 PDDL（Planning Domain Definition Language），交给经典规划器求解
DEPS：Describe, Explain, Plan, Select —— 先描述任务，再解释约束，然后规划，最后选择最优方案
Self-Ask：LLM 自问自答，递归分解问题

4. Memory 模块：短期记忆与长期记忆

短期记忆（Short-term Memory）

定义

短期记忆对应 LLM 的上下文窗口（Context Window），存储当前对话中的信息。

实现方式

完整对话历史：将所有历史消息放入 Prompt
滑动窗口：只保留最近 N 轮对话
摘要压缩：用 LLM 将长对话总结为摘要

挑战

上下文窗口有限（即使 128K tokens 也不够处理所有场景）
越早的信息越容易被"遗忘"（Lost in the Middle 问题）
Token 成本随对话长度线性增长

长期记忆（Long-term Memory）

定义

长期记忆是持久化存储的知识库，跨越单次对话，供 Agent 在后续任务中检索和使用。

实现技术

技术	适用场景	代表工具
向量数据库	语义检索	Pinecone、Milvus、Chroma
键值存储	精确查找	Redis
知识图谱	关系推理	Neo4j
关系数据库	结构化查询	PostgreSQL

记忆类型（参考人类认知）

情景记忆（Episodic）：具体事件和经历（如历史对话记录）
语义记忆（Semantic）：抽象知识和概念（如用户偏好、领域知识）
程序记忆（Procedural）：如何执行任务的经验（如成功的工具调用模式）

记忆管理策略

记忆写入：决定哪些信息值得记住（重要性评分）
记忆检索：根据当前上下文检索相关记忆（相似度 + 时效性 + 重要性）
记忆遗忘：淘汰过时或不重要的记忆（TTL、LRU）
记忆反思：定期对记忆进行总结和抽象（如 Generative Agents 中的 Reflection）

5. Tool Use 与 Function Calling

LLM 如何学会调用工具？

训练阶段

数据收集：构造 "用户问题 + 工具选择 + 参数填充 + 结果整合" 的训练数据
有监督微调（SFT）：让模型学习在合适的时机选择合适的工具
RLHF：通过人类反馈强化工具调用的准确性

Function Calling 机制

以 OpenAI 的 Function Calling 为例：

Step 1：定义工具

{
  "name": "get_weather",
  "description": "获取指定城市的天气",
  "parameters": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "城市名" }
    },
    "required": ["city"]
  }
}

Step 2：LLM 决策

LLM 收到用户消息和工具定义后，判断是否需要调用工具。如果需要，输出结构化的调用请求：

{
  "function_call": {
    "name": "get_weather",
    "arguments": "{\"city\": \"北京\"}"
  }
}

Step 3：执行与返回

应用层执行实际的 API 调用，将结果返回给 LLM，LLM 整合结果生成最终回答。

核心原理

Function Calling 本质上是让 LLM 学会了一种结构化输出能力：

理解工具的 schema（JSON Schema）
判断何时需要调用工具（intent detection）
正确填充参数（slot filling）
整合工具返回结果（result integration）

常见工具类型

类型	示例
信息检索	搜索引擎、数据库查询、知识库检索
代码执行	Python 解释器、Shell 命令
API 调用	天气 API、地图 API、支付 API
文件操作	读写文件、解析 PDF/Excel
通信工具	发送邮件、Slack 消息

6. LangChain vs LlamaIndex

LangChain

定位

通用的 LLM 应用开发框架，提供构建各类 LLM 应用的组件和工具链。

核心模块

Models：统一的 LLM 接口
Prompts：Prompt 模板管理
Chains：将多个组件串联成工作流
Agents：自主决策的智能体
Memory：对话记忆管理
Callbacks：可观察性和监控

适用场景

构建复杂的多步骤 Agent
需要灵活组合多种工具和数据源
通用 LLM 应用开发

LlamaIndex

定位

专注于数据索引和检索的框架，核心目标是让 LLM 高效地与自定义数据交互。

核心模块

Data Connectors：从各种数据源加载数据
Data Index：多种索引结构（向量索引、树索引、关键词索引）
Query Engine：检索 + 生成的查询引擎
Chat Engine：带记忆的对话引擎

适用场景

构建 RAG 系统
企业知识库问答
文档分析和检索

核心区别

维度	LangChain	LlamaIndex
核心定位	通用 LLM 应用框架	数据索引与检索框架
强项	Agent、Chain 编排、工具调用	数据连接、索引构建、检索优化
适用场景	复杂 Agent、多步工作流	RAG、知识库、文档问答
灵活性	高，组件可自由组合	中，聚焦检索场景
学习曲线	较陡（抽象层多）	较平缓

实际选型建议

纯 RAG 场景 → LlamaIndex 更专业
复杂 Agent 场景 → LangChain 更灵活
两者结合 → LangChain 做编排，LlamaIndex 做检索

7. 构建复杂 Agent 的主要挑战

可靠性问题

幻觉：LLM 可能编造不存在的工具或参数
推理失败：复杂任务链中的单点失败会导致整体崩溃
无限循环：Agent 可能在错误的推理路径上反复尝试

规划能力不足

LLM 本质上不擅长长期规划
子任务之间的依赖关系难以正确处理
面对不确定性时难以动态调整计划

上下文管理

长对话导致上下文溢出
关键信息在长文本中被淹没（Lost in the Middle）
记忆的存储和检索效率

工具调用的鲁棒性

参数填充错误
工具返回异常的处理
多工具协调调用的顺序和依赖

评估困难

缺乏统一的评估标准
复杂任务的正确性难以自动判断
不同运行可能产生不同结果（不确定性）

成本与延迟

多步推理需要多次 LLM 调用
Token 消耗大
端到端延迟高

安全性

Prompt Injection 攻击
工具调用的权限控制
敏感信息泄露

8. 短期记忆与长期记忆的设计配合

架构设计

用户输入
   ↓
┌─────────────────────────┐
│      短期记忆            │  ← 当前对话上下文
│  (Context Window)        │
│  ┌─────────────────┐    │
│  │ 系统 Prompt      │    │
│  │ 检索到的长期记忆  │ ←─── 从长期记忆中检索
│  │ 最近对话历史     │    │
│  │ 当前用户输入     │    │
│  └─────────────────┘    │
└─────────────────────────┘
   ↓
LLM 推理
   ↓
┌─────────────────────────┐
│      长期记忆            │  ← 持久化存储
│  ┌──────────┐           │
│  │ 向量数据库 │ 语义检索  │
│  │ 知识图谱  │ 关系推理  │
│  │ KV 存储   │ 精确查找  │
│  └──────────┘           │
└─────────────────────────┘

配合机制

写入：对话结束后，从短期记忆中提取有价值的信息写入长期记忆
检索：新对话开始时，根据用户输入从长期记忆中检索相关信息，注入短期记忆
更新：长期记忆中的信息可以被新信息更新或覆盖
压缩：短期记忆接近上限时，将早期对话压缩为摘要后存入长期记忆

实际案例：Generative Agents（斯坦福小镇）

短期记忆：当前的环境感知和最近行为
长期记忆：所有经历以自然语言存储在向量数据库
检索：按 相关性 × 时效性 × 重要性 加权检索
反思：定期对记忆进行高层次总结，形成抽象认知

9. 多智能体系统（Multi-Agent System）

定义

多智能体系统是由多个 LLM Agent 组成的协作系统，每个 Agent 具有特定的角色、能力和职责，通过通信和协调共同完成复杂任务。

优势

优势	说明
专业化分工	每个 Agent 专注于特定领域，提升单项能力
并行处理	多个 Agent 可同时处理不同子任务
鲁棒性	单个 Agent 失败不影响整体
涌现能力	Agent 间交互可能产生超越个体的能力
可扩展性	易于通过添加新 Agent 扩展系统能力

引入的复杂性

通信开销：Agent 间的消息传递消耗大量 Token
协调困难：需要解决冲突、达成共识
一致性问题：多个 Agent 的输出可能矛盾
调试困难：分布式系统的错误难以定位
成本倍增：每个 Agent 都需要 LLM 调用

经典架构

AutoGen（微软）：基于对话的多 Agent 框架
CrewAI：基于角色的 Agent 协作框架
MetaGPT：模拟软件公司的多 Agent 系统
ChatDev：多 Agent 模拟软件开发流程

10. 多 Agent 协作的通信与协调机制

通信模式

1. 集中式（Hub-and-Spoke）

Agent A ←→ 协调者 ←→ Agent B
              ↕
           Agent C

一个中心协调者负责任务分配和信息汇总
优点：控制简单，易于管理
缺点：协调者是单点瓶颈

2. 去中心化（Peer-to-Peer）

Agent A ←→ Agent B
  ↕           ↕
Agent C ←→ Agent D

Agent 之间直接通信
优点：无单点故障，灵活
缺点：通信复杂度高（O(n²)）

3. 层级式（Hierarchical）

        管理 Agent
       /    |    \
    组长A  组长B  组长C
    / \    |     / \
  a1  a2  b1   c1  c2

多层级的管理结构
适合大型复杂任务

4. 广播式（Blackboard）

所有 Agent 共享一个"黑板"，在上面发布和读取信息。

协调策略

策略	描述	适用场景
顺序传递	Agent 按固定顺序执行	流水线式任务
讨论投票	多个 Agent 讨论后投票决定	需要共识的决策
竞争选优	多个 Agent 各自完成，选最优	创意生成
角色分工	按角色分配不同子任务	复杂项目
辩论机制	Agent 互相质疑和改进	提升推理质量

11. 真实/模拟环境中的 Agent vs 纯软件 Agent

本质区别

维度	软件 Agent	环境 Agent（机器人/游戏）
感知	文本/API 数据	视觉、触觉、声音等多模态
行动	API 调用、文本生成	物理运动、环境交互
反馈	即时、确定性	延迟、噪声、不确定性
安全性	软错误为主	物理安全风险
实时性	通常可接受延迟	严格实时要求
状态空间	离散、有限	连续、无限

关键挑战

感知-行动闭环：需要处理连续的传感器数据
实时性：LLM 的推理延迟可能无法满足实时控制需求
安全约束：物理世界中的错误可能造成不可逆伤害
不确定性：环境状态的随机性和部分可观察性
Sim-to-Real Gap：模拟器中训练的策略在真实环境中可能失效

12. Agent 的安全性、可控性与对齐

安全挑战

Prompt Injection：恶意输入导致 Agent 执行未授权操作
工具滥用：Agent 可能调用危险工具（删除文件、发送邮件）
信息泄露：Agent 可能在回答中暴露敏感数据
目标偏离：Agent 可能为了完成任务采取不当手段

保障方法

1. 权限控制（Sandboxing）

限制 Agent 可调用的工具集
设置工具调用的参数范围
实现最小权限原则

2. 人机协作（Human-in-the-Loop）

关键操作需要人类确认
设置不同操作的风险等级
高风险操作自动暂停等待审批

3. 护栏（Guardrails）

输入过滤：检测并拦截恶意 Prompt
输出过滤：检查生成内容是否安全
行为监控：实时监控 Agent 的行为轨迹

4. Constitutional AI

制定 Agent 必须遵守的"宪法"规则
在推理过程中自我检查是否违反规则
违反规则时自动修正行为

5. 红队测试（Red Teaming）

主动尝试攻击 Agent 以发现漏洞
对抗性测试工具调用的安全性
持续迭代安全策略

13. Agent 框架选型与评价指标

主流框架

框架	特点	适用场景
LangChain/LangGraph	生态丰富，组件化	通用 Agent 开发
AutoGen	多 Agent 对话	多 Agent 协作
CrewAI	角色驱动	团队协作模拟
Semantic Kernel	微软出品，企业级	.NET/Java 生态
Dify	低代码可视化	快速原型

选型考量

任务复杂度：简单任务用轻量框架，复杂任务用全功能框架
团队技术栈：Python 生态选 LangChain，.NET 选 Semantic Kernel
可控性需求：需要精细控制选 LangGraph，快速开发选 Dify
多 Agent 需求：需要多 Agent 协作选 AutoGen 或 CrewAI
生产就绪度：评估框架的稳定性、社区活跃度、文档质量

评价指标

任务完成度

成功率：任务正确完成的比例
完整度：任务完成的程度（部分完成也有分）

效率指标

步骤数：完成任务所需的推理步骤
Token 消耗：完成任务的总 Token 数
延迟：端到端的响应时间

质量指标

准确性：输出结果的正确率
一致性：多次运行结果的稳定性
安全性：是否触发安全违规

常用 Benchmark

AgentBench：综合评测 Agent 在多种环境中的能力
ToolBench：评测工具调用能力
WebArena：评测 Web 操作能力
SWE-bench：评测软件工程能力

14. 微调 Agent 能力与数据集收集

微调目标

提升工具选择的准确率
提升参数填充的正确性
增强多步规划能力
改善特定领域的表现

数据集收集方法

1. 人工标注

标注人员模拟 Agent 的完整推理和行动过程
质量高但成本昂贵
适合高价值的垂直领域

2. LLM 自生成（Self-Instruct）

使用强大的 LLM（如 GPT-4）生成训练数据：
1. 生成多样的用户意图
2. 对每个意图，生成合理的工具调用序列
3. 模拟工具返回结果
4. 生成最终回答
5. 人工审核和过滤

3. 真实轨迹收集

记录 Agent 与用户的真实交互轨迹
筛选成功的轨迹作为正样本
分析失败轨迹以构造纠错数据

4. 工具文档转化

从 API 文档自动生成调用示例
交叉组合不同工具的使用场景
生成多工具协作的复杂案例

微调策略

策略	说明
SFT	有监督微调，学习 "问题→工具调用→回答" 的模式
DPO	直接偏好优化，让模型偏好正确的工具调用方式
RLHF	基于人类反馈强化学习，优化端到端表现
Tool-augmented Training	在预训练阶段就引入工具调用的数据

数据质量要求

多样性：覆盖不同类型的任务和工具
正确性：工具调用和参数必须正确
完整性：包含完整的推理链路
真实性：贴近实际使用场景