谁说 Agent 只是 LLM + 插件?深度剖析 Agent 核心:ReAct、MCP、Function Call 与 LangGraph我在很多技术群里都见过这样的讨论："Agent 嘛，不就是给 LLM 接几个工具、让它自己跑起来吗？"说这话的人，大概率是用 LangChain 套了个模板，跑通了一个天气查询 Demo，然后觉得自己已经理解 Agent 了。这个认知，差得很远。我不是要故意抬高门槛，而是这个误解会在你真正落地的时候带来很大的麻烦——比如你的 Agent 在简单任务上跑得很欢，一碰到多步骤的复杂问题就开始胡言乱语、死循环、或者悄悄忽略上下文。今天我想认真捋一遍 Agent 的核心概念：ReAct、MCP、Function Call 和 LangGraph。不是教程，是我自己理解这套体系的方式。先把"Agent = LLM + 插件"这个坑填上这个说法错在哪？它把 Agent 理解成了一个静态结构：一个大模型，旁边挂几个工具，模型决定用哪个。但实际上 Agent 是一个动态运行的系统，它在每一步都需要：知道自己在哪（状态）、记得之前做过什么（记忆）、判断下一步该怎么做（推理）、拿到结果后能调整方向（反馈闭环）。光靠"LLM + 插件"，你解决不了"记忆"和"闭环"这两个问题。所以 Agent 真正的四个核心是：LLM，负责推理和决策，是整个系统的"大脑"，但它本身是无状态的；记忆，分两种，短期记忆就是当前对话的上下文窗口，长期记忆需要借助向量数据库或者结构化存储来实现——后者往往是被忽视却最关键的部分；工具集，搜索、API调用、代码执行……这是 Agent 能影响"外部世界"的唯一方式；行动执行器，执行工具调用，拿到结果，把结果反馈给 LLM，形成闭环。这四个模块缺一不可，缺了任何一个，你得到的都不是一个完整的 Agent，只是一个花哨一点的 Prompt。ReAct：真正让 Agent "想清楚再动手"的机制很多人用过 Chain-of-Thought，让模型一步步推理。ReAct 是它的进化版，把推理和行动真正打通了。ReAct 的核心是一个循环，三个阶段：Thought（思考）：模型内部推理，"我现在知道什么？下一步该做什么？用哪个工具？"Action（行动）：输出结构化指令，真正调用工具。Observation（观察）：读取工具返回的结果，把它加入上下文，再次进入 Thought 阶段。循环不断推进，直到模型判断任务已经完成。举个具体的例子：你让 Agent 帮你"查一下明天上海的天气，如果下雨就把我下午的户外会议改到室内，并发一封通知邮件"。一个简单的"LLM + 插件"实现，可能在"查天气"这一步成功，但后面改日历、发邮件这两步是有依赖关系的——得先确认改没改成功，才能发通知。没有 ReAct 循环，它根本处理不好这种多步依赖。有了 ReAct，模型每一步都会"看一下现在的结果"，再决定下一步。这才是真正的智能行动，不是一口气把所有指令打出去然后祈祷不出错。Function Call、MCP、Skills：三个名字，三件事，很多人搞混了这三个概念经常被混着用，但它们其实在不同的层次上解决不同的问题。Function Call 是模型侧的能力。它解决的是：模型怎么知道"现在该调用工具了"，以及"调用哪个工具、传什么参数"。本质上，模型输出的是一段结构化的 JSON 指令，比如 {"tool": "search", "query": "上海天气"}，然后由外部系统去执行这个指令。这是 Agent 能用工具的基础能力，没有 Function Call（或类似机制），模型只能输出文字，没有能力真正"行动"。MCP（Model Context Protocol） 是协议层的标准。想象这样一个问题：你有 10 个 Agent，要接入 20 个不同的工具（搜索、数据库、日历、代码执行器……），如果每个 Agent 都要单独适配每个工具，工作量是 10×20 = 200 条对接关系。MCP 的出现，就是为了把这个问题降维——制定一个统一的工具接入协议，让工具"只需接入一次"，所有遵循 MCP 标准的 Agent 都能直接用。有人把它比作 AI 世界的 USB 接口，我觉得这个比喻很准。你买一个 U盘，不用管是插在 Mac 还是 Windows 上，接口是标准的，插上就用。MCP 要做的就是这件事。Skills 是经验层的沉淀。一个 Agent 成功完成了某个复杂任务，比如"读取 Excel 数据 → 清洗 → 生成可视化图表"这个流程，把这个执行路径记录下来，下次遇到类似问题，直接复用这段"经验"，而不是让模型从头再想一遍。Skills 本质上就是一个 Markdown 文件，描述"遇到这类问题，按这个步骤走"。它不是模型能力，是工程上对成功经验的封装。三者的关系，用一个比喻来说：Function Call 是"会说话的能力"，MCP 是"通用的语言标准"，Skills 是"积累下来的话术手册"。层次不同，缺一不可。多 Agent：什么时候需要一个"团队"？单个 Agent 有瓶颈——上下文窗口有限、单线程处理、单一视角容易出错。遇到真正复杂的任务，需要引入多 Agent 协同。有四种常见的协作模式，理解它们能帮你在架构选型的时候少走弯路：流水线（Pipeline）：A 的输出是 B 的输入，B 的输出是 C 的输入。适合步骤严格有序的场景，比如"抓取数据 → 清洗 → 分析 → 生成报告"。优点是可控，缺点是串行，任何一环出问题，整条链断掉。主从模式（Orchestrator-Workers）：一个"指挥官" Agent 负责理解任务、拆解子任务、分配给专业 Agent 去执行，最后汇总结果。这是目前最主流的多 Agent 架构，灵活性强，也便于扩展专业能力。并行模式（Parallel）：当子任务之间没有依赖关系，可以让多个 Agent 同时处理，最后合并结果。效率最高，但需要仔细设计任务拆解，避免重复和冲突。辩论模式（Debate）：多个 Agent 从不同角度分析同一个问题，互相质疑、补充，最后得出更可靠的结论。主要用来对抗 LLM 的"幻觉"问题，在对准确性要求极高的场景下很有价值。有一件事经常被忽视：防错机制。多 Agent 系统一旦出现 Bug，比单 Agent 难调试得多。所以一开始就要设计好熔断措施：设定最大步数限制，防止死循环；做状态检测，发现重复状态就报警；设置超时熔断，不让某个卡住的 Agent 拖垮整个系统。这些不是"锦上添花"，是生产环境上线的基本要求。LangGraph 和"工作流 vs 智能体"的选择题很多人在设计 Agent 系统的时候，会纠结一个问题：这个任务该用固定的工作流，还是让 Agent 自己规划？我的经验是：别把这两个当成非此即彼的选择。工作流的优势是可控、可调试、成本低。如果你的任务步骤是清晰固定的，完全没必要引入 Agent 的不确定性。Agent 的优势是灵活、能处理开放性问题。但代价是：更难预测行为、更难调试、成本更高。最好的实践往往是混合架构：外层用工作流控制主干流程（确保整体方向不跑偏），内层在需要"灵活处理"的子任务上引入 Agent。LangGraph 在这里的价值就体现出来了。它是一个基于有向图的编排框架，支持条件边（根据状态决定走哪条路）和循环（支持 ReAct 这种需要反复迭代的模式）。普通的 DAG 工作流不支持循环，而 LangGraph 支持——这是它跟传统工作流框架最大的区别。加上它内置的人机协作节点（Human-in-the-loop），在需要人工审核的关键节点暂停等待确认，非常适合生产环境。另外值得一提的是反思机制（Reflection）。在代码生成或长文写作这类任务里，Agent 第一次输出的结果往往不够好。引入一个"评估者"——可以是另一个 LLM，也可以是同一个 LLM 换个角色——对初稿打分、提出具体改进意见，Agent 根据反馈迭代，直到达到标准为止。这个模式显著提升了输出质量，也是 AlphaCode 等代码生成系统背后的核心思路之一。落地才会踩的坑：工程侧的几个实际问题理论讲完了，说几个真正落地时会遇到的问题。上下文溢出Agent 跑着跑着，上下文窗口就满了。这时候有几种处理策略：最简单的是滑动窗口，只保留最近 N 轮对话；稍复杂一点是摘要压缩，让模型把历史对话压缩成摘要再塞回上下文；更精细的方案是向量检索，把历史信息存到向量库，按需召回；最后，对于用户名、偏好这类"不能丢的关键信息"，单独维护一个"事实列表"，永远不裁剪。实际生产中，这几种方案往往需要组合使用。工具调用的可靠性Function Call 生成的 JSON 参数可能格式不对，工具调用可能超时，网络可能抖动……这些都需要有对应的处理逻辑。参数校验要严格，格式错误就让模型重试；工具失败要有重试逻辑，用指数退避（第一次等 1 秒，第二次 2 秒，第三次 4 秒……）避免打爆下游服务；设置熔断机制，连续失败多次就停下来，别让 Agent 一直在一个无效的工具调用上死磕。这些处理逻辑不写，Agent 在真实环境里分分钟崩给你看。最后说几句回到开头的问题：Agent 是什么？它是一个推理-记忆-工具-协同的完整系统，而不是一个模型加几个函数调用。ReAct 让 Agent 有了真正的迭代推理能力；Function Call、MCP、Skills 在不同层次解决了"工具如何使用"的问题；多 Agent 协同解决了单 Agent 的能力上限；LangGraph 把混乱的流程变成可控的图结构。如果你现在刚开始接触 Agent，我的建议是：先从 ReAct + Function Call 跑通一个最小可用版本，搞清楚这个循环是怎么转的；再逐步引入 MCP 做工具标准化；当单 Agent 扛不住的时候，再考虑多 Agent 架构。一步一步来，别被概念淹没。欢迎在评论区聊聊你在落地 Agent 时踩过的坑，我挺好奇大家在实际项目里遇到的具体问题是什么。
夜雨聆风
