一、开篇：Agent 让模型从”会说”到”会做”

原生大模型只能输出文本，无法操作外部系统。Agent 智能体以大模型为大脑，把思考决策与工具执行结合起来，自主感知、规划、调用工具、多步执行，完成复杂任务。这一篇覆盖 Agent 概念、ReAct 范式、主流范式、Tool Call 与 MCP 协议。

二、Agent 智能体

2.1 什么是 Agent

Agent（智能体）是以大模型作为大脑，能够自主感知、思考、规划、调用工具、多步执行，完成复杂任务的系统。普通大模型：用户给 Prompt，模型直接输出答案，单轮、不会自己行动。Agent：大模型不光生成文字，还会做思考判断——分析目标 → 拆解子任务 → 判断要不要调用工具 → 执行工具拿到结果 → 把结果汇总，循环多步直到完成整体目标。

核心：大模型做思考决策，外部工具负责动手干活。常见工具包括搜索引擎、数据库查询、代码执行、API 调用、文件读写等。经典范式是 ReAct（思考 + 行动）：Think → Action → Observation → 循环。

2.2 Agent 解决什么问题

• 解决大模型只会”说”不会”做”的问题：原生大模型只能输出文本，不能操作外部系统；Agent 可以调用工具，真正去查数据、查网络、执行代码、访问接口。
• 处理复杂多步骤任务：任务无法一步完成，需要拆分多个子步骤。例：”帮我查合肥最近 3 个月房价，整理对比表格”，需要联网搜索→多份数据收集→整理计算→输出表格，多轮思考 + 工具调用。
• 突破模型自身知识与能力边界：模型知识有限，Agent 可以动态调用搜索、数据库获取实时外部数据，不用把全部信息塞到上下文。
• 自主迭代纠错：工具返回结果不对时，Agent 可以自我反思、调整策略，重新选择工具或调整查询条件，而不是直接输出错误答案。

2.3 Agent 的局限（面试加分）

• 规划能力不稳定：复杂任务容易出现规划错误，子任务拆解跑偏。
• 工具调用幻觉：模型会错误选择工具、填错参数。
• 成本高：多轮思考 + 多次工具调用，token 消耗高、耗时更长。
• 不是万能：任务越复杂失败概率越高，往往需要增加提示词约束、记忆模块来优化。

2.4 Agent 和 RAG 的区分（面试官高频对比）

RAG：主要做知识问答。拿到问题，检索已有知识库，基于文档回答，一般不主动执行多步动作，侧重”查资料回答问题”。Agent：侧重完成行动类复杂任务，可以调用各类工具、多步规划执行。RAG 可以作为 Agent 其中一个工具。

三、核心范式：ReAct 推理

3.1 ReAct 是什么

ReAct 是 Agent 最经典的实现范式，把推理思考（Reasoning）和工具行动（Acting）结合在一起。简单循环流程：Thought 思考 → Action 行动 → Observation 观察，不断循环直到任务完成。

• Thought（思考）：大模型做内部推理。分析当前目标，思考现在该做什么，判断是否需要调用工具、调用哪个工具、参数是什么。
• Action（行动）：按照思考结果执行工具调用，比如调用搜索、查询数据库、执行 RAG 检索、调用 API。
• Observation（观察）：拿到工具返回的真实结果，把结果交给大模型。

拿到 Observation 之后再次回到 Thought 继续思考下一步，循环往复；任务达成就输出最终答案结束。

3.2 ReAct 解决什么问题

普通 Prompt 只做一次输出，模型思考和工具调用割裂。ReAct 把思考和行动交织起来：模型基于真实工具返回结果做推理，不单纯靠自身内部知识，减少幻觉；把复杂任务拆成多轮小步骤，一步一步推进；工具返回错误或信息不足时，可以继续调整策略重新查询。

3.3 ReAct 的短板（面试加分）

• 循环次数不可控，多轮循环 token 消耗大、耗时久。
• Thought 环节会出现规划幻觉，模型错误判断下一步，选错工具、填错参数。
• 依赖 Prompt 约束，提示写得不好，循环容易死循环或提前终止。

面试小提示：RAG 是单次检索问答；ReAct-Agent 可以把 RAG 作为其中一个 Action 工具，多次检索、多步处理。

四、ReAct 之外常见 Agent 范式

4.1 Plan-and-Execute（规划-执行范式）

核心：规划与执行两阶段分离，先出完整计划，再分步执行。规划阶段大模型根据目标拆解出完整子任务步骤列表，生成全局计划；执行阶段执行器按照计划一步一步执行，可以内部嵌套 ReAct 做工具调用，执行中发现环境变化支持重新规划 Re-plan。

优点：任务流程清晰，适合长流程、步骤多、子任务有依赖的任务（数据分析报告、复杂调研）。缺点：初始计划错了会沿错误计划一直执行；环境动态变化时静态计划容易失效，需要重规划机制兜底。

和 ReAct 对比：ReAct 是想一步做一步；Plan-and-Execute 是先画好路线图再走路。

4.2 Reflexion（反思范式）

核心：增加反思复盘闭环，做完任务之后自我批判，把失败经验存入记忆。流程：执行任务 → 获取结果 → 反思（分析哪里出错、失败原因、总结教训）→ 把反思存入记忆，下一轮任务带上历史教训避免重复踩坑。

优点：可以从失败中学习，不用微调模型，靠记忆提升后续任务成功率，适合代码编写、复杂问题调试。缺点：多轮迭代 token 开销大；反思本身也会产生幻觉，错误反思反而误导后续执行。Self-Refine 类似，但不需要外部工具反馈，只在文本内部做生成-批评-迭代，多用于文案、代码润色。

4.3 ToT（Tree-of-Thoughts 思维树）

核心：不再只有单条线性思考路径，生成多条推理分支，评估打分、剪枝、支持回溯。CoT 是单条线性思考；ToT 在关键节点生成多个候选思路，对分支打分评估，保留高价值分支继续推演，差的分支直接剪枝，遇到死胡同可以回溯换路径。

优点：适合难题求解、博弈、头脑风暴，大幅提升复杂推理能力。缺点：token 消耗很高、成本大，工业落地不如 ReAct、Plan-and-Execute 普及，更多用于推理场景。

4.4 Multi-Agent 多智能体范式

核心：多个分工不同的 Agent 协作完成任务。拆分不同角色：规划 Agent、检索 Agent、代码 Agent、评审 Agent，各司其职、互相传递消息协作。例如一个负责拆解任务、一个负责查资料、一个负责写代码、一个负责校验结果。

优点：复杂大任务可以分工解耦，能力专业化。缺点：系统复杂度高，多 Agent 之间消息容易混乱，协调成本高。

4.5 Graph Agent（图/状态机范式，工业落地主流）

核心：用状态图、有向图管理任务流转，显式定义节点、条件分支、循环、回溯。不再完全交给大模型自由决定下一步；把思考、工具调用、判断分支封装成图节点，由状态机驱动流转，大模型只负责节点内部的推理（代表实现：LangGraph）。

优点：可控性强、可回溯、可调试，生产环境稳定性高，企业 Agent 落地大量采用。缺点：需要人工编排流程，开发工作量更大。

五、Tool Call 工具调用

5.1 什么是 Tool Call

Tool Call（工具调用）让大模型按照预定义的工具描述（函数定义），自主判断什么时候调用外部函数/API，输出结构化参数，由程序去执行真实工具逻辑，再把结果返回模型继续推理。原生大模型只能输出自然语言文本；Tool Call 给了模型”调用外部能力”的接口。工具可以是：搜索、数据库查询、RAG 检索、代码执行、文件读写、第三方 API。

区分：ReAct 用自然语言写 Thought/Action/Observation，文本格式解析工具调用；Tool Call 模型直接输出 JSON 结构化工具调用，是现在 OpenAI、各类开源模型主流的原生能力。

5.2 Tool Call 完整工作流程

1. 工具定义：提前向模型描述工具列表——工具名称、功能说明、入参 JSON Schema（参数名、类型、是否必填、描述），随 Prompt 传给大模型。
2. 模型决策：大模型分析用户问题，判断是否需要调用工具；需要则输出结构化 JSON，包含工具名、调用参数。
3. 后端解析执行：程序解析模型输出的 JSON，调用对应的真实工具，传入参数，拿到工具返回结果。
4. 结果回传给 LLM：把工具返回观测结果作为上下文交给模型。
5. 循环或输出答案：模型结合工具结果继续判断是否调用其他工具；信息足够就整理输出最终回答。

5.3 Tool Call 常见问题（面试高频坑点）

• 工具调用幻觉：模型编造不存在的工具名；参数填错、参数缺失；格式错误，输出非法 JSON，解析失败。
• 过度调用：明明不需要工具，模型仍然反复调用工具，浪费 token。
• 欠调用：明明需要查资料，模型直接靠内部知识回答，不去调用工具。
• 多轮循环不可控：不停循环调用工具，无法终止。

常见优化手段：完善工具描述 Schema，写清楚适用场景；增加校验层捕获 JSON 解析异常并给模型错误反馈；设置最大工具调用轮次上限；Prompt 约束信息足够就停止调用工具。

5.4 Tool Call 和 ReAct 的关系

ReAct：基于自然文本实现工具调用，模型输出文字描述要干什么，程序做文本解析提取动作，容易解析出错，是早期 Agent 方案。Tool Call：模型原生输出结构化 JSON，解析更可靠，现在主流。很多 Agent 底层就是 Tool Call 做执行，外层套用 ReAct/Plan-and-Execute 的逻辑。

六、MCP 协议概念

6.1 MCP 是什么

MCP 全称 Model Context Protocol，模型上下文协议，是 Anthropic 推出的开放标准化通信协议，底层基于 JSON-RPC 2.0，用来标准化 AI 应用和外部工具、数据源、提示模板之间的交互。通俗类比：AI 领域的 USB-C 接口。

架构是 Client-Server 架构：MCP Server 是工具/资源服务端，把文件、数据库、API、工具能力封装对外暴露；MCP Client 是 AI/Agent 应用侧，可同时对接多个 MCP Server，动态发现能力、调用服务端能力。

MCP 定义三类核心原语：

• Tools：可执行工具，有副作用，如文件操作、数据库查询、API 调用。
• Resources：只读资源，文件、文档、数据，只读取不修改。
• Prompts：可复用提示词模板。

6.2 解决什么问题

传统 Function Calling（Tool Call）的痛点：接入新工具要写大量适配代码；工具 Schema 硬编码在业务代码；不同大模型厂商工具调用格式不统一；工具很难跨项目复用。MCP 把 N 模型 × M 工具的对接复杂度降为 N+M。工具只需要实现一套 MCP Server，所有支持 MCP 的 AI 客户端都可以直接接入，不用重复开发适配。

6.3 基础工作流程

1. 初始化握手、能力协商：Client 与 Server 建立连接，协商协议版本，互相声明支持的能力。
2. 动态发现能力：Client 调用 list 接口，动态拉取 Server 提供的 Tools、Resources、Prompts 列表与 Schema。
3. Client 把工具 Schema 交给大模型；大模型决策需要调用哪个工具。
4. Client 通过 MCP 协议向 Server 发起工具调用请求。
5. MCP Server 执行真实逻辑，标准化返回结果。
6. 结果回传给大模型继续推理，循环执行任务。

6.4 MCP 和 Tool Call（Function Calling）的关系（面试高频）

不是替代，是互补、上下游关系。

• Tool Call / Function Calling：属于模型侧能力，解决大模型如何输出结构化调用意图（工具名和参数），工具 Schema 一般写死在业务请求里。
• MCP：属于上层通信协议规范，解决工具如何被发现、如何标准化连接、如何跨应用复用。

实际落地：MCP Server 对外暴露工具列表 → Client 拿到 Schema 喂给大模型做 Function Calling → 模型输出调用意图之后，再走 MCP 协议把调用请求转发给 MCP Server 执行。

6.5 MCP 的局限

• 增加系统分层，架构复杂度上升；简单本地工具场景直接用 Function Calling 更轻量。
• 是协议规范，不解决模型本身的工具调用幻觉问题；幻觉依旧需要在模型侧处理。