Agent 面试速成清单

• Agent 面试清单

下面这版是按"能扛追问"的标准整理的。你可以把它理解成一套答题框架：先讲定义，再讲运行机制，

再讲工程实现，再讲风险和边界。

---

1. 先把 Agent 说清楚

最稳的定义：

"Agent 不是单纯的大模型问答，而是一个以大模型为决策核心，能够感知上下文、规划步骤、调用工

具、执行动作、读取结果并继续迭代的任务执行系统。"

面试里最好主动区分三个层次：

1. LLM

只负责生成文本、做推理、做决策，不直接执行外部动作。

2. Workflow

流程是预先编排好的，比如固定先检索、再总结、再输出。模型参与有限，路径基本确定。

3. Agent

模型可以根据当前任务动态决定下一步做什么，比如要不要搜、搜什么、要不要调用数据库、要不要

重试、要不要继续拆解任务。

一句区分法：

"Workflow 是人提前写好流程，Agent 是模型在流程中拥有一部分决策权。"

---

2. Agent 的核心能力有哪些

面试通常会问"一个 Agent 具备什么能力"，你可以答这五个：

1. 感知

读取用户输入、系统状态、外部环境、历史上下文。

2. 推理

理解目标，拆解任务，判断当前缺什么信息。

3. 规划

决定下一步做什么，是继续思考、查资料、调工具还是结束。

4. 行动

调用外部工具，比如搜索、数据库、代码执行、发请求、操作系统命令。

5. 记忆

保存短期上下文和长期经验，用于多轮任务和个性化。

这五个一讲，基本面试官会觉得你不是只会背名词。

---

3. Agent 的典型运行闭环

这是最关键的答题点。

Agent 的本质闭环可以概括为：

Observe -> Think -> Act -> Observe -> ... -> Finish

更工程化一点可以说：

1. 读取用户目标

2. 判断是否已经足够回答

3. 如果不够，就选择工具

4. 生成结构化调用参数

5. 执行工具

6. 读取执行结果

7. 再次推理下一步

8. 达到停止条件后输出最终结果

这就是很多面试里提到的 Reason-Act-Observe Loop。

如果面试官问和普通 ChatBot 区别，你直接答：

"普通 ChatBot 一般是一轮输入一轮输出；Agent 是多轮内部闭环，直到判断任务完成才给用户最终答

复。"

---

4. ReAct 是什么

这是高频题。

ReAct = Reason + Act

它的核心思想是：

模型不是一次性直接给最终答案，而是把推理和行动交替进行。

典型格式：

• Thought: 我需要先查一下最新信息

• Action: search("...")

• Observation: 搜索结果返回...

• Thought: 我已经拿到关键事实，可以总结

• Final Answer: ...

它的价值：

1. 降低幻觉

因为模型不是凭空答，而是边查边答。

2. 提高复杂任务成功率

尤其适合搜索、调 API、数据分析、代码诊断。

3. 可解释性更强

你能看到中间决策过程和工具调用路径。

但工程上要注意：

不能把完整 chain-of-thought 暴露给用户，生产环境通常保留"结构化步骤"和"工具日志"，而不是原

始私有推理文本。

如果被追问 ReAct 的缺点：

• 调用次数多，延迟高

• token 成本高

• 容易死循环

• 工具结果不稳定时会带偏推理

• 很依赖 stop condition 和 retry policy

---

5. Function Calling / Tool Calling 是什么

这个是 Agent 基础。

最稳回答：

"Function Calling 本质是 LLM 和外部工具之间的结构化调用协议。模型不直接执行函数，只负责根据

工具 schema 输出要调用的工具名和参数，宿主程序执行后再把结果返回给模型。"

核心要点：

1. 工具由程序员注册

比如：

• search_web(query)

• get_weather(city)

• query_order(order_id)

2. 工具参数通常用 JSON Schema 描述

模型知道参数名、类型、是否必填。

3. 模型返回结构化调用意图

比如：

• tool name = get_weather

• arguments = { "city": "Shanghai" }

4. 运行时执行工具

Agent runtime 调用真实函数/API。

5. 执行结果回填模型

模型再根据结果生成最终回答。

你可以顺手补一句：

"现在很多厂商都兼容 OpenAI-style 的 tool calling 协议，底层通常是 HTTP + JSON + schema。"

面试追问"function calling 和 agent 的关系"时，答：

"Function calling 只是 Agent 的一个动作执行机制，不等于 Agent。Agent 还需要规划、记忆、错误

恢复、终止判断等能力。"

---

6. MCP 是什么

这个现在越来越常问。

MCP = Model Context Protocol

建议定义：

"MCP 是一个让模型或 Agent 以标准化方式接入外部工具、资源和上下文的协议层。它的目标不是替代

function calling，而是统一模型与工具生态之间的接口标准。"

可以把 MCP 理解成：

• Function calling 更像"一次调用格式"

• MCP 更像"工具接入协议标准"

MCP 关注的通常是：

1. 工具如何被暴露

2. 资源如何被发现

3. 上下文如何被注入

4. 调用如何标准化

5. 不同客户端/Agent 如何复用同一套工具服务

如果面试官问 MCP 和 function calling 区别：

你可以这样答：

"Function calling 解决的是模型如何描述一次工具调用；MCP 更偏生态协议，解决工具如何被标准化

提供、发现和接入。一个偏调用格式，一个偏连接标准。"

再进一步：

"Agent runtime 依然可能在内部把 MCP 暴露的工具映射为 tool calling 来给模型使用。"

---

7. Agent 和 RAG 的关系

高频误区题。

标准回答：

"RAG 不是 Agent，RAG 是给模型补充外部知识的一种检索增强机制。Agent 可以使用 RAG 作为一个工

具或一个子能力。"

RAG 流程一般是：

1. 用户提问

2. 检索相关文档

3. 把文档片段塞进 prompt

4. 模型生成回答

它的问题是流程通常固定，偏被动。

Agent 则更强：

• 它可以决定要不要检索

• 检索几次

• 换什么 query

• 检索失败后要不要改策略

• 要不要结合数据库/API/代码执行一起做

一句话总结：

"RAG 是知识增强，Agent 是任务执行；RAG 可以是 Agent 的一个组件。"

---

8. 短期记忆和长期记忆

面试常问"Agent 的记忆怎么做"。

你可以分三层回答。

1. 上下文窗口记忆

直接把历史消息放进 prompt。

优点是简单。

缺点是 token 贵、窗口有限。

2. 短期记忆

保存当前任务相关状态，比如会话摘要、当前计划、最近几轮工具结果。

常放：

• Redis

• 内存

• session store

3. 长期记忆

把长期有价值的信息持久化并支持召回。

常见两类：

• 结构化长期记忆：用户偏好、配置、历史订单、账户信息

• 语义长期记忆：把历史对话、笔记、工作记录做 embedding 存向量库

追问"为什么不能把所有历史都塞 prompt"时答：

• 上下文窗口有限

• 成本高

• 噪声大

• 会稀释当前任务重点

所以更好的工程方案是：

"短期记忆保任务态，长期记忆保稳定事实，当前轮按需召回。"

如果被问"长期记忆最大问题是什么"：

• 召回错误

• 过期信息污染

• 用户隐私风险

• 写入质量不稳定

• 容易把猜测当事实存进去

---

9. Planner-Executor 架构

这是非常经典的 Agent 架构题。

最常见模式：

1. Planner

负责理解目标、拆解步骤、确定执行计划。

2. Executor

负责按计划调用工具执行每一步。

有时还会加：

3. Verifier / Critic

检查结果是否满足要求，是否需要重试。

这种架构的好处：

• 职责清晰

• 更容易调试

• 更适合复杂任务

• 能降低一个模型同时做所有事的负担

缺点：

• 系统更复杂

• 调用轮次更多

• 延迟更高

• 计划可能和实际执行脱节

如果被问"什么时候不需要 planner"：

"任务路径很短、流程稳定时，用固定 workflow 更划算，没必要上完整 planner。"

---

10. Single-Agent 和 Multi-Agent 的区别

标准答法：

Single-Agent

一个智能体完成所有决策和执行。

优点：

• 简单

• 成本低

• 状态一致性好

缺点：

• 上下文容易过大

• 角色混杂

• 在复杂任务里容易失控

Multi-Agent

多个智能体分工合作，比如：

• Planner Agent

• Research Agent

• Coding Agent

• Reviewer Agent

优点：

• 分工明确

• 并行能力更强

• 更适合复杂场景

缺点：

• 协调成本高

• 状态同步难

• 容易重复劳动

• 错误传播链更长

面试里不要只说优点，一定补一句：

"多 Agent 不一定比单 Agent 强，很多场景是过度设计。任务边界明确、路径短时，单 Agent 或

workflow 更实用。"

---

11. Agent 的停止条件怎么设计

这是很工程化的问题，回答这个很加分。

Agent 必须有 stop condition，否则容易死循环。

常见停止条件：

1. 已得到用户要求的最终结果

2. 工具结果已经足够确定

3. 达到最大步数

4. 连续失败超过阈值

5. 发现任务不可执行

6. 用户中断

工程上常加的保护：

• max_iterations

• max_tool_calls

• timeout

• budget limit

• duplicate action detection

如果被问"为什么会死循环"：

• 模型重复选择同一工具

• 工具返回信息不足但模型没学会放弃

• 缺少完成判定

• retry 策略过于激进

---

12. Agent 的错误恢复怎么做

常考"如果工具失败怎么办"。

可分四种：

1. 重试

适合网络抖动、临时超时。

2. 降级

搜索失败就用本地知识，OCR 失败就返回原文摘要。

3. 换策略

第一次 query 不准，就改 query；API A 挂了换 API B。

4. 向用户澄清

参数不足、目标模糊时让用户补信息。

一个比较成熟的答法：

"Agent 不应该把工具失败直接等同于任务失败，而应该有 retry、fallback、replan、ask-user 这几

类恢复路径。"

---

13. Agent 的观测性和评估

这是中高级面试非常爱问的。

你要能回答"怎么知道 Agent 好不好"。

关键观测维度：

1. 成功率

任务最终完成比例。

2. 步数

平均用了多少轮工具调用。

3. 成本

token、API、外部服务调用成本。

4. 延迟

总耗时、单步耗时。

5. 质量

答案是否正确、是否满足约束。

6. 工具使用质量

是否调用了错误工具、是否参数错误、是否多余调用。

常见日志内容：

• user query

• plan

• tool chosen

• tool args

• tool output

• final answer

• error trace

• token usage

• latency

评估方式：

• 人工评测

• 规则评测

• benchmark 数据集

• 模型裁判

• A/B test

你可以补一句很工程的话：

"Agent 的评估不能只看最终答案，还要看中间轨迹，因为很多问题出在工具选择和执行路径上。"

---

14. Agent 幻觉从哪里来

很多人只会说"大模型会幻觉"，但 Agent 的幻觉更复杂。

来源主要有：

1. 模型本身编造事实

2. 错误选择工具

3. 工具返回脏数据

4. 工具参数构造错误

5. 检索召回错文档

6. 长上下文污染

7. 多轮推理错误累积

所以 Agent 的幻觉治理通常包括：

• 检索证据绑定

• 输出引用来源

• 高风险场景强制工具调用

• 参数校验

• 工具结果 schema 校验

• 最终答案验证

• 人类兜底

---

15. Agent 和 Workflow 什么时候选哪个

这是很实战的问题。

优先选 Workflow 的情况：

• 路径稳定

• 步骤固定

• 合规要求高

• 不能让模型自由发挥

• 时延和成本要求严

优先选 Agent 的情况：

• 任务开放性高

• 输入变化大

• 需要动态选工具

• 需要多步探索

• 不能提前写死所有路径

一句很好的总结：

"能用 workflow 解的，就不要硬上 agent；只有当任务路径具有明显不确定性时，agent 的价值才真正

体现出来。"

---

16. 一个完整 Agent 系统的常见模块

这是架构题。

你可以从下往上讲：

1. Model Layer

大模型服务。

2. Tool Layer

搜索、数据库、代码执行、业务 API。

3. Memory Layer

会话上下文、摘要、用户长期记忆、向量库。

4. Planning / Reasoning Layer

ReAct、planner、reflection、self-critique。

5. Execution Layer

调用工具、重试、并发、超时控制。

6. Guardrail Layer

权限、参数校验、敏感词、成本限制、风控。

7. Observability Layer

日志、trace、指标、评估。

8. Interface Layer

Chat UI、API、Webhook、业务入口。

如果你这样回答，基本已经像真正做过系统的人。

---

17. Guardrails 和权限控制

这个特别容易被追问。

Agent 最大风险不是"不会答"，而是"做错事"。

所以要强调：

1. 模型没有直接权限

只能提出调用建议。

2. 真正执行前要做校验

• 参数合法性校验

• 用户权限校验

• 资源范围校验

3. 高风险动作必须二次确认

比如：

• 转账

• 删除数据

• 发邮件

• 调生产命令

4. 工具要最小权限设计

不能把一个无边界 shell 直接暴露给 Agent。

一句标准答法：

"Agent 的安全边界应该建立在 runtime 和 tool gateway 上，而不是寄希望于 prompt 提醒模型不要

乱来。"

---

18. 面试里常问的设计题模板

如果让你设计一个"智能客服 Agent / 订票 Agent / 数据分析 Agent"，你可以按这个模板答：

1. 明确目标

是问答、执行事务，还是复杂任务协同。

2. 判断用 workflow 还是 agent

如果路径固定就 workflow，不固定就 agent。

3. 设计工具集

搜索、数据库、业务 API、用户信息服务。

4. 设计状态管理

当前计划、会话状态、短期记忆、长期记忆。

5. 设计执行闭环

reason -> tool -> observe -> replan

6. 设计安全机制

权限、参数校验、二次确认、审计。

7. 设计失败处理

retry、fallback、ask-user、handoff-human。

8. 设计观测与评估

日志、成功率、延迟、成本、错误分类。

这个模板能应对大多数系统设计题。

---

19. 高频追问和标准答案

Q: Agent 一定要多轮工具调用吗？

不一定。Agent 的关键不是调用次数，而是是否具备动态决策和环境交互能力。一次调用也可能是

Agent，但复杂场景通常表现为多轮闭环。

Q: Function calling 就等于 Agent 吗？

不等于。Function calling 只是 Agent 的动作接口之一。Agent 还需要规划、状态管理、记忆、停止

条件和错误恢复。

Q: RAG 就是 Agent 吗？

不是。RAG 是检索增强方法。Agent 可以用 RAG，但二者不等价。

Q: MCP 会不会取代 function calling？

不会。两者层级不同。Function calling 更像调用格式，MCP 更像工具生态接入协议。

Q: 为什么很多 Agent demo 很强，落地却一般？

因为真实生产环境的问题主要在工具可靠性、权限控制、状态管理、延迟成本和评估闭环，而不只是

prompt。

Q: 多 Agent 为什么不一定更好？

因为协调复杂度、上下文同步成本和错误传播会显著增加。很多业务场景单 Agent 或 workflow 更实

用。

Q: Agent 怎么减少幻觉？

通过检索增强、工具校验、结构化输出、证据引用、结果验证和人类兜底，而不是只靠 prompt。

---

20. 一段可以直接背的总答复

如果面试官让你概括 Agent，你可以直接说：

"Agent 是以大模型为决策核心的任务执行系统。它和普通问答模型的区别在于，Agent 具备感知、推

理、规划、行动和记忆能力，能够在多轮闭环中动态选择工具完成任务。工程上通常基于 ReAct 或

Planner-Executor 架构，通过 function calling 或 tool calling 连接外部工具，通过短期和长期记

忆管理上下文，通过 guardrails、权限校验和 stop condition 控制风险。RAG、workflow、function

calling 都可以是 Agent 的组成部分，但它们本身不等于 Agent。"