面试官："Agent 不就是 LLM 加点工具？"，我："ReAct、MCP、Skills、Function Call 你到底懂不懂？"

大家好，我是二哥。

今年的求职变化很大，相信面试过的小伙伴都会认同这个观点。AI的浓度高到爆表，别说AI应用开发岗，就算是前端、测试这些岗位。

面试官也会张嘴闭嘴 AI Agent。

我根据球友们的反馈整理了一份大模型 Agent 的高频面试题，从架构原理到多智能体协同，把面试官最喜欢问的点全覆盖了，全文7000+字。

结合我开源的 PaiAgent 项目，争取让大家背完这篇，面试的时候有底气。

GitHub地址：https://github.com/itwanger/PaiAgent

01、核心概念与架构篇

Q1：说说 Agent 的基本架构？

一个完整的 Agent 通常由四个核心模块构成。

第一个是LLM，负责推理和决策，相当于 Agent 的 CPU。接收输入、理解意图、输出下一步计划。

第二个是记忆（Memory），分短期记忆和长期记忆。短期记忆就是对话上下文，存在内存里；长期记忆需要外部存储，比如向量数据库、关系型数据库，跨会话持久化。

第三个是工具集（Tools），Agent 能调用的外部能力，比如搜索、代码执行、数据库查询、API 调用。工具是 Agent 和现实世界交互的抓手。

第四个是行动执行器（Action Executor），负责真正执行 LLM 决定的操作，并把结果反馈回去。

和传统 LLM Chain 的区别？

LLM Chain 是固定流程，你预先定义好每一步：先调模型 A，再调模型 B，最后输出。

流程是静态的，不会根据中间结果调整。就像一条流水线，装配顺序写死了，哪怕中途出了问题，它也不会停下来想一想。

Agent 是动态决策。每一步都是 LLM 根据当前状态重新决定的，「下一步该干什么」不是提前写好的，而是实时推理出来的。它会根据工具返回的结果、当前对话历史，动态调整行动路径。

用一句话概括：LLM Chain 是剧本，Agent 是即兴表演。

Q2：ReAct 模式是怎么工作的？

ReAct 的工作流程是一个不断循环的「思考-行动-观察」：

Thought（思考）：LLM 分析当前情况，决定下一步要做什么。这一步不对外输出，只是内部推理。比如「用户问今天天气，我需要调用天气查询工具，参数是当前城市」。

Action（行动）：LLM 决定调用哪个工具、传什么参数，以结构化的 JSON 格式输出。

Observation（观察）：系统执行 Action，把结果返回给 LLM。比如「北京今天晴，26°C」。

LLM 拿到结果后，更新自己的上下文，进入下一轮思考，判断任务是否完成。如果没完成，继续循环；如果完成了，输出最终答案。

这个设计解决了什么问题？

它让 LLM 不再是「一次性问答」，而是能够和外部环境交互、根据反馈调整策略的推理引擎。

举个具体例子，你让 Agent「帮我查一下最近发表了哪些关于 RAG 优化的论文」：

第一轮：Thought → 「我需要搜索最新的 RAG 论文」；Action → 调用 search 工具，关键词「RAG optimization 2026」；Observation → 返回 10 篇论文摘要。

第二轮：Thought → 「摘要太长，需要筛选最相关的三篇」；Action → 调用 filter 工具；Observation → 三篇精选。

第三轮：Thought → 「信息足够了，可以输出答案」；Final Answer → 整理成易读格式返回给用户。

有一点很关键：ReAct 里的 LLM 每次只生成「下一步指令」，循环控制是外部程序负责的。这也是为什么实现一个 Agent 框架，循环逻辑和上下文拼接非常重要的原因。

Q3：Agent 的长期记忆怎么实现？

按存储时效，记忆分两层：

短期记忆（Working Memory）：就是当前对话的上下文窗口，放在内存里。缺点很明显，会话结束就消失了，而且受上下文窗口大小限制，不能无限叠加。

长期记忆（Long-term Memory）：需要持久化到外部存储，跨会话保留。常见的实现方案有三类。

第一类是向量数据库。把历史对话或知识库文本向量化存储，每次查询时做相似度检索，把最相关的片段召回塞进 Prompt。这是 RAG 的标准做法，也是目前最主流的长期记忆方案。

第二类是结构化存储。用 SQLite、PostgreSQL 这类关系型数据库存储结构化信息，比如用户偏好、任务历史、已知的事实。查询走 SQL，精确但不灵活。

第三类是摘要压缩。对话长了之后，让 LLM 把历史对话压缩成一段摘要，摘要替代原始对话注入下次上下文。这样能在有限的上下文窗口里保留更多历史信息。

02、多智能体协同

Q4：为什么需要 Multi-Agent？

第一个是上下文窗口限制。复杂任务的信息量可能远超单个 LLM 的上下文窗口，塞不进去就会丢失信息。

第二个是专业能力瓶颈。让一个 Agent 同时精通代码审查、数据分析和文案撰写，效果远不如三个专门训练的专业 Agent 各司其职。

第三个是并行效率。串行任务慢，但很多子任务之间没有依赖关系，完全可以并行跑。单 Agent 做不到真正的并发。

常见的协作模式有哪些？

流水线模式（Pipeline）：Agent A 的输出是 Agent B 的输入，一环扣一环。适合有明确先后顺序的任务，比如「爬虫 Agent → 解析 Agent → 总结 Agent → 推送 Agent」这条链路。

主从模式（Orchestrator-Workers）：一个指挥官 Agent 负责任务分解和调度，多个执行 Agent 负责执行。这是目前最主流的多 Agent 架构，LangGraph 里用得很多。

平行模式（Parallel）：多个 Agent 同时处理不同的子任务，最后汇总结果。适合没有依赖关系的并发任务，比如同时监控三个数据源。

辩论模式（Debate）：多个 Agent 对同一个问题给出不同角度的回答，最后综合或让裁判 Agent 做决策。适合需要多视角验证的场景，能有效降低单 Agent 的幻觉风险。

Q5：多智能体系统怎么避免无限循环和通信冗余？

无限循环的根源通常是：Agent 之间互相依赖，A 等 B，B 等 A，或者某个 Agent 在循环处理一个它永远解决不了的子任务。

常见的防护手段有三个：一是最大步数限制，给每个 Agent 设定最大执行步数，超过就强制中止并报错；二是状态哈希检测，记录每次执行的状态哈希，如果发现重复状态就判定为循环并中断；三是超时熔断，任务执行超过预设时间就强制结束，返回当前最优解。

通信冗余的问题更隐蔽。多个 Agent 同时汇报类似的结果，或者中间过程产生大量无意义的消息，会让指挥官 Agent 淹没在噪音里。

解决思路是设计清晰的消息协议：每条消息带上 Agent ID、任务 ID、消息类型（中间状态 vs 最终结果），指挥官只处理「最终结果」类型的消息，忽略中间过程；另外用消息去重队列过滤掉内容相同的重复消息。

03、Agent 核心设计模式

Q6：工作流和智能体怎么选？

工作流模式：流程由开发者提前定义好，LLM 只负责在固定节点做决策或生成内容，整体流程是可预测的。

优点是可控、稳定、便于调试。出了问题知道在哪一步，改起来也方便。

缺点是灵活性差。遇到不在预设流程里的情况，工作流会直接卡住或给出错误结果。而且每加一种新场景，都要改流程代码。

智能体模式：给 Agent 一个目标，让它自己规划路径、调用工具、动态调整策略，全程不干预。

优点是灵活，能处理开放式任务，对需求变化的适应性强。

缺点是不可控。LLM 的推理路径不透明，出了问题难以追溯。而且每一步都在消耗 Token，成本高，延迟也不稳定。

一个简单原则：任务边界清晰、步骤可枚举，选工作流；任务开放、需要大量判断，选智能体。

更常见的做法是混合架构：外层用工作流控制主流程，内层的某些节点换成智能体处理开放性子任务。

比如一个客服系统，整体流程是固定的（接收问题 → 分类 → 查知识库 → 回复），但「查知识库」这一步可以用智能体，让它自己决定检索策略。

Q7：编排者-执行者模式了解吗？

编排者负责三件事：接收原始任务、拆解成子任务、把子任务分发给合适的执行者，最后汇总结果。可以把它理解成一个项目经理，自己不直接写代码，但负责整体规划和进度跟踪。

执行者是一批专业化的 Agent，每个只干自己最擅长的那类任务。比如「代码审查专员」「文档生成专员」「接口调用专员」，分工明确，互不干扰。

这个模式的关键点在于编排者的任务拆解质量。拆解粒度太粗，执行者拿到的任务依然很复杂，失败率高；拆解粒度太细，子任务太多，通信开销大，最后汇总也麻烦。

一个好的编排提示词应该包含：任务目标、可用的执行者列表及其能力描述、任务拆解的格式要求（通常是 JSON 格式的任务列表）、汇总输出的格式要求。

在 LangGraph 里，编排者是一个中心节点，各执行者是叶子节点，通过带条件的边来控制任务路由。

编排者节点的返回结果里带上「下一步应该调用哪个执行者」的决策，LangGraph 根据这个决策动态路由。

Q8：Reflection / Self-Correction 模式是什么？

反思模式是让 Agent 具备「自我纠错」能力的设计模式，在代码生成、长文写作等高精度场景里特别有用。

基本流程是这样的：Agent 生成一个初始结果，然后启动一个「评估步骤」，让同一个或另一个 LLM 对结果打分、找问题，输出改进建议，再把建议反馈给 Agent 重新生成，如此循环直到满足质量标准或达到最大迭代次数。

举个代码生成的例子：

第一轮，Agent 生成一段 Python 爬虫代码。

反思步骤，Critic Agent 检查代码：「没有异常处理，缺少请求头设置，可能被反爬」。

第二轮，Agent 根据反馈改进代码，加上 try/except、设置 User-Agent。

反思步骤，Critic Agent 再检查：「看起来可以了」。

最终输出第二轮的代码。

这个模式有两个变体。一种是自我反思（Self-Reflection），用同一个 LLM 来评估自己的输出，成本低，但因为是同一个模型，盲点也相同，评估质量有限。

另一种是对等评审（Peer Review），用专门训练的 Critic 模型来评估，质量更高，但成本也更高。

生产里一般用自我反思做快速迭代，对精度要求很高的场景（比如合同审核、医疗建议）才会上专门的 Critic 模型。

04、深度技术实现与状态管理

Q9：多轮对话 Agent 怎么处理状态爆炸和上下文溢出？

状态爆炸指的是多轮对话中，状态空间随着轮次指数级增长，系统越来越难以管理。比如对话到第 50 轮，历史状态依赖关系复杂，任何一步出错都很难追溯。

解决思路是状态精简：不要把所有历史步骤的完整状态都存下来，只保留「当前任务完成所需要的最小信息集合」。已经完成且结果已知的子任务，把结果压缩成摘要，原始状态可以归档。

上下文溢出是 LLM 上下文窗口容量有限，对话轮次一多就超限的问题。

常见的处理方案有四种：

第一种是滑动窗口，只保留最近 N 轮对话，超过的直接截断。简单粗暴，但会丢失早期的重要信息。

第二种是摘要压缩，用 LLM 把旧对话压缩成摘要，摘要替代原始对话留在上下文里。保留了信息大意，但细节会丢失。

第三种是向量检索增强，把历史对话存向量库，每轮对话开始前检索最相关的历史片段注入上下文，而不是全量载入。

第四种是关键事实提取，专门维护一个「重要事实列表」，对话里提到的关键信息（用户名字、偏好、已确认的决策）单独提取出来永久保存，每轮注入。

Q10：如何保证 Agent 工具调用（Function Calling）的可靠性？

工具调用的不可靠通常来自三个层面。

模型层：LLM 生成的调用参数可能格式错误、字段缺失，或者把错误的工具名传进来。应对方式是在 Prompt 里明确每个工具的 JSON schema，要求模型严格输出，调用前做一次参数校验，格式不对就打回去让模型重新生成，最多重试 3 次。

执行层：工具本身可能超时、返回异常、或者返回了不符合预期的结果。标准做法是给每个工具调用设超时上限，加 retry 逻辑（指数退避），同时对返回结果做基本的合法性检查，异常情况记日志并向 Agent 上报「调用失败，原因：xxx」，让 Agent 自己决定下一步。

系统层：高并发下多个 Agent 同时调同一个外部服务，可能把下游打挂。引入限流和熔断机制，单个工具的并发调用数设上限，触发熔断后返回降级结果。

有一个经常被忽视的细节：工具描述的质量直接影响调用准确率。

工具的 name、description 写得越清晰，模型选错工具的概率就越低。

Q11：LangGraph 的 Node 和 Edge 与传统工作流有何不同？

传统工作流的边是静态的，流程图一旦画好，数据就沿着固定路径流动，没有运行时判断。

LangGraph 的创新是条件边（Conditional Edge）。普通边是固定的 A → B，条件边是 A → f(state) → B 或 C 或 D，下一步走哪里取决于当前状态的计算结果。这让有向图具备了动态路由的能力。

节点（Node）在 LangGraph 里接收当前状态、做一些处理、返回状态更新。状态是整个图共享的，每个节点只负责更新自己关心的那部分状态字段。

这个设计带来了两个传统工作流没有的能力：

一是循环支持。LangGraph 明确支持图里有循环，这是实现 ReAct 循环的基础。传统 DAG（有向无环图）不允许循环，但 Agent 的推理循环天然就是需要循环的。

二是状态持久化。LangGraph 可以把每一步的状态快照存下来，支持「人在回路（Human-in-the-Loop）」——在关键节点暂停、等待人工确认，确认后继续执行。这在需要人工审批的业务流程里非常有用。

Q12：Function Call、MCP 和 Skills，到底有什么本质区别？

Function Calling 是模型侧的原生能力。厂商通过微调，让 LLM 能够输出符合特定 JSON schema 的结构化调用指令。

比如你问「今天北京天气怎么样」，模型会输出 {"tool": "weather_query", "params": {"city": "北京"}}，而不是直接回答。它解决的问题是：如何让模型准确地触发工具调用，而不是在自然语言里猜工具。

MCP（Model Context Protocol） 是工具接入的标准化协议，相当于 AI 世界的「USB 接口」。

它解决的问题不是「模型怎么调工具」，而是「不同的工具怎么用统一的协议暴露给不同的模型」。MCP 采用 Host-Client-Server 架构，基于 JSON-RPC 2.0 通信，让你写一次工具实现，就能被所有支持 MCP 的模型调用，不用为每个模型单独适配。

Skills 是 Agent 在执行任务过程中沉淀下来的「经验文件」，本质上是一段描述成功路径的 Markdown 文档。它不是调用机制，也不是通信协议，而是 Agent 的「肌肉记忆」。

Hermes Agent 把复杂任务的解决过程自动沉淀成 Skill，下次遇到类似任务直接复用，效率大幅提升。

三者的关系是：Function Call 是基础能力层，解决「模型和函数之间如何沟通」；MCP 是协议层，解决「工具怎么标准化接入」；Skills 是经验层，解决「如何复用过去的成功经验」。

一个完整的 Agent 系统通常三层都有：用 Function Call 触发工具、通过 MCP 管理工具注册、用 Skills 积累执行经验。

Q13：知识库内容更新很快，RAG 系统怎么应对？

常见的应对方案有三层。

第一层是增量更新机制。不要每次全量重建索引，而是监听数据源的变更事件，只对新增或修改的内容重新向量化并写入。

第二层是时效性过滤。在检索时加上时间维度的过滤条件，只召回最近 N 天的内容，过期的文档直接排除在外。同时给每条文档打上创建时间和有效期字段，让检索结果自带时效判断。

第三层是实时工具兜底。对于更新极快的内容，向量库本来就追不上，干脆不存，直接在 Agent 里挂一个实时查询工具，让模型在需要时实时拉取，不走向量检索这条路。

Q14：如何提升 RAG 问答的准确度？

准确度通常出在两个环节：召回质量差和生成质量差，要分开诊断。

召回侧最常见的问题是语义匹配不准。解决方法是混合检索：向量检索（语义）加关键词检索（BM25）双路并行，结果用倒数排名融合算法合并，比单路检索的召回率高 15%~30%。

另一个常见问题是文档切片太粗或太细。切太粗，一个片段里信息太杂，相似度被稀释；切太细，上下文断裂，模型拿到片段看不懂。一般建议 512~1024 个 token 一个片段，前后各留 50~100 个 token 的重叠，避免关键信息被切断。

生成侧的问题通常出在提示词设计上。要明确告诉模型「只根据以下文档回答，如果文档中没有相关信息，直接说不知道，不要编造」。加上这条约束，幻觉率能下降很多。

另外，重排序是提升准确度性价比最高的手段之一。先用向量检索粗召回 20 条，再用重排序模型按相关性精排，取前 5 条进入生成阶段。重排序模型理解问题和文档的语义关系比纯向量相似度更准，效果提升明显。

ending

Agent 这个领域现在特别热，大家都在卷，但真正能在面试里讲清楚原理的人，比想象中少很多。

建议配合 PaiAgent 项目一起学——教程地址在这里：https://paicoding.com/column/14/1，从零搭一个 Agent 系统，把这些概念全部落地一遍，面试的时候才能讲出自己的理解，而不是复述别人的定义。

【真正的理解，从踩坑开始。】

做过项目、踩过坑，这两点是最有说服力的背景。如果简历上有 PaiAgent 这样完整的 Agent 项目经验，面试官问「你们是怎么处理上下文溢出的」，你能直接说「我们用了三层叠加方案，滑动窗口保留近十轮，摘要压缩中期历史，关键事实单独提取……」，那种感觉和背答案完全不一样。

共勉。