1. 从“大模型”到“智能体”一个概念的演进与澄清最近和不少同行交流发现一个挺有意思的现象大家嘴里蹦出来的词越来越多LLM、Agent、Workflow、Function Call、MCP……听起来都跟AI有关但具体指什么、彼此之间又是什么关系很多人其实是一头雾水。经常有人问我“你们做的那个Agent和Workflow是一回事吗”或者“Function Call和MCP Server哪个更好用”。这种困惑太正常了。这个领域发展得太快新概念、新框架层出不穷很多名词的定义边界本身就在动态变化加上不同厂商、不同社区各有各的叫法很容易让人晕头转向。今天我就想结合我自己的实践和踩过的坑把这些高频又容易混淆的概念用最直白的方式捋清楚。我的目标很简单让你看完之后不仅能分清谁是谁更能理解它们背后的设计哲学和适用场景知道在什么情况下该用什么“工具”。文末我也会附上一个简单的配套源码帮你把抽象的概念落到具体的代码上真正“秒懂”。我们先从最核心、也是最基础的LLM说起。你可以把LLM大语言模型理解成一台拥有海量知识、但“四肢不勤”的超强大脑。它很能说能写诗、能编程、能回答问题但它有一个根本性的局限它活在“文本的世界”里。它不知道今天的天气不能帮你查航班不能操作你的数据库甚至不知道你刚刚问它的那个问题它自己上一句回答了什么如果不借助外部机制的话。LLM本质是一个基于概率生成文本的模型它的“思考”完全依赖于你喂给它的文本上下文。这就引出了我们第一个要解决的问题如何让这个“大脑”能够调用“手脚”去干实事2. Function Call让LLM学会“按按钮”Function Call函数调用就是解决上述问题的第一把钥匙也是最基础、最广泛被LLM原生支持的一种机制。它的核心思想非常直观我们提前定义好一系列工具Tools或函数Functions每个函数都有明确的名称、描述和参数格式。然后我们在把用户的问题抛给LLM时同时告诉它“嘿你现在可以调用这些函数了。” LLM在理解用户意图后会判断是否需要以及需要调用哪个函数。如果需要它不会直接执行而是输出一个结构化的调用请求。举个例子我们定义了一个get_weather(city: string)的函数。当用户问“北京天气怎么样”时支持Function Call的LLM比如GPT-4可能会在回复中附带这样一个结构{ function_call: { name: get_weather, arguments: {\city\: \北京\} } }注意到这里为止LLM的工作就完成了。它只是“说”出了要调用哪个函数、传递什么参数。真正的执行动作——去调用真实的天气API获取数据——是由我们开发者写的后端代码来完成的。执行完成后我们把得到的结果比如“北京晴25度”再塞回给LLM让它组织成最终的自然语言回复给用户。所以Function Call的本质是“意图识别” “结构化输出”。它让LLM从“纯聊天”进化到了“能指挥外部工具”。但它的局限性也很明显单次性通常一次对话回合只处理一个函数调用。复杂的、需要多个步骤串联的任务比如“查一下北京飞上海的航班选最便宜的那个然后帮我生成一个出行摘要文档”很难通过一次Function Call完成。上下文管理负担重开发者需要自己管理对话历史、函数调用结果并决定何时、如何将这些信息重新喂给LLM。如果忘记把某个关键的执行结果放回上下文对话逻辑可能立刻断裂也就是网上常说的“死机”。流程控制弱LLM负责识别“这一步做什么”但“下一步做什么”、“做错了怎么办”、“如何循环”这些流程逻辑完全需要开发者在外围用代码硬编码实现。这就引出了我们需要更强大编排工具的需求。3. Workflow用可视化蓝图编排复杂任务当任务变得复杂需要多个LLM调用、条件判断、分支合并、工具调用按特定顺序执行时Function Call这种“散装”的方式就显得力不从心了。这时Workflow工作流登场了。Workflow是一种可视化、可编排的自动化流程。你可以把它想象成音乐制作人的混音台或者工厂的流水线设计图。在AI语境下一个Workflow通常由多个“节点”Node通过“边”Edge连接而成。每个节点代表一个原子操作比如LLM调用节点向某个模型提问。工具调用节点执行一个预定义的函数如查询数据库、调用API。条件判断节点根据上一步的结果决定流程走向哪个分支。代码执行节点运行一段Python/JS代码来处理数据。输入/输出节点接收用户输入返回最终结果。这些节点通过拖拽连线的方式组合起来形成一个有向无环图DAG。平台如Dify、LangChain的LangGraph可视化界面会负责按照这个图来执行整个流程包括数据的传递、节点的触发、异常的处理等。Workflow和单纯串联多个Function Call的关键区别在于“控制权”在Function Call模式中LLM是驾驶员它决定每一步做什么但路况流程很复杂时它容易迷路。在Workflow模式中开发者是总设计师我们通过流程图预先定义了所有可能的路线和交通规则。LLM或多个LLM变成了这条流水线上的“专业工人”只在被调用时完成自己那部分特定的文本生成或决策任务。例如实现“查询并生成报告”的任务Function Call思路需要开发者写代码来管理状态先调用搜索函数把结果给LLMLLM说需要总结再触发总结函数……逻辑散落在代码各处。Workflow思路在画布上拉出三个节点搜索节点-LLM总结节点-文档生成节点。连线设置好数据流转。执行引擎会按序执行与LLM的“主观能动性”无关。所以Workflow的核心优势是确定性与可靠性。它适合那些步骤固定、逻辑清晰的自动化任务比如客服自动应答流水线、内容批量生成与审核、数据ETL处理等。它的缺点是不够灵活无法应对流程图中未定义的、突发的新情况。4. Agent赋予LLM“自主规划与执行”的能力Agent智能体是当前最火热也最易混淆的概念。在我看来Agent是Function Call和Workflow思想的集大成者并引入了更关键的要素自主性Autonomy。一个真正的Agent不仅仅是一个能调用工具的LLM更是一个具备以下特点的系统规划Planning面对复杂目标能将其分解为一系列子任务或步骤Lets think step by step就是最基础的规划体现。工具使用Tool Use知道在何时、使用何种工具来完成任务。记忆Memory拥有短期对话上下文和长期向量数据库等记忆能参考历史信息。反思Reflection能评估自己行动的结果如果失败了或效果不佳能调整策略重新尝试。Agent与Workflow的哲学区别Workflow是“剧本”演员LLM必须严格按照剧本来。Agent是“导演”它手里有剧本大纲目标、可用的演员和道具工具但具体每场戏怎么拍、遇到突发状况怎么处理由导演临场决定。Agent的核心在于其基于LLM的决策循环感知当前状态和任务- 规划下一步做什么- 执行调用工具或输出- 观察结果- 再规划……直到任务完成或无法继续。网上很多讨论把“能调用Function的LLM”就叫Agent这稀释了Agent的概念。按此标准第一部分讲的Function Call例子已经是Agent了。更严格的区分可以看系统的主导权工具调用模式用户或预设流程主导LLM按需提供“函数调用建议”。Agent模式LLM在一定的框架和约束下主导整个任务解决过程。一个经典的Agent框架如LangChain的AgentExecutor、AutoGPT的工作流程如下用户输入目标“帮我研究一下特斯拉最新的财报总结其营收亮点和风险写一份500字的分析。”Agent框架初始化配备工具集网络搜索工具、财报PDF解析工具、总结写作工具。LLMAgent的大脑开始思考“要完成这个我需要先搜索特斯拉最新财报下载PDF提取关键数据然后进行分析写作。”LLM决定第一步调用网络搜索工具关键词“Tesla Q4 2023 earnings report PDF”。框架执行搜索将结果返回给LLM。LLM观察结果发现了一个PDF链接于是决定第二步调用财报PDF解析工具传入链接。框架解析PDF将文本数据返回给LLM。LLM阅读文本决定第三步直接进行分析和写作此时可能调用多次LLM自身进行信息提炼和草稿撰写。最终LLM输出完成的分析报告。整个过程开发者没有预先规定“必须先A后B再C”只是提供了工具和起点具体的路径是Agent自己“想”出来并执行的。这就是自主性。5. Skill与MCP模块化与标准化的“工具包”在构建Agent或Workflow时我们经常需要用到各种工具。如何高效地管理、复用和共享这些工具呢这就涉及到Skill和MCP这两个概念。Skill技能是一个比较上层的业务概念。它指的是一个封装好的、能完成特定业务目标的能力单元。一个Skill内部可能包含多次LLM调用、多个工具协作、甚至内嵌一个小的Workflow。例如“订机票Skill”可能包含了查询航班、比价、选择航班、填写乘客信息、支付等一系列动作的封装。Skill强调业务功能的完整性和复用性是面向最终用户的。Dify等平台中提到的“技能”通常就是这个层面。MCPModel Context Protocol模型上下文协议则是更底层、更技术化的一个开放协议由Anthropic提出并开源。它要解决的核心问题是如何让LLM无论是云端模型如Claude还是本地部署的模型能够以一种标准化、安全、可扩展的方式访问外部工具、数据和功能在MCP架构下工具和数据不再是以零散的“函数描述”列表形式硬编码到应用里而是由独立的MCP Server服务器来提供。每个MCP Server就像一个专用的“服务提供商”它通过标准协议告诉LLM“我这里能提供哪些工具Tools或资源Resources”。你的AI应用作为MCP Client则可以动态地连接一个或多个MCP Server将它们提供的工具集成了LLM的上下文中。MCP带来的革命性好处解耦与标准化工具开发者和AI应用开发者分离。你可以专门写一个“数据库查询MCP Server”另一个团队写“公司内部CRM查询MCP Server”。任何支持MCP的AI应用如Claude Desktop、支持MCP的代码编辑器都可以无缝集成这些工具无需重复开发。动态性与安全性工具可以远程运行权限可控。比如一个“代码执行”MCP Server可以运行在安全的沙箱环境中与主应用隔离避免了直接给LLM开放危险的系统调用权限。生态共享正在形成一个MCP Server的生态。你可以找到别人写好的“GitHub搜索MCP”、“Brave搜索MCP”、“日历管理MCP”直接拿来就用极大地提升了开发效率。所以Skill和MCP的关系可以理解为你可以利用多个标准的MCP Server提供的工具像搭积木一样组合构建出一个高价值的业务Skill。MCP是“零部件标准”Skill是“组装好的产品”。6. OpenClaw一个具体的AI应用开发框架当我们谈论LLM、Agent、Workflow时最终还是要落地到具体的开发上。这就需要框架Framework。LangChain、LlamaIndex、Semantic Kernel等都是知名的框架。这里我提一下OpenClaw因为它是一个相对较新、设计理念清晰且与我们讨论的概念契合度很高的国产开源框架。OpenClaw的核心思想是“基于工作流编排的智能体开发框架”。它巧妙地将Workflow的确定性和Agent的自主性结合了起来。在OpenClaw中你通过编写YAML或Python代码来定义一个“Claw”爪寓意智能体能够抓取和操作。一个Claw本质上就是一个可编排的工作流但它里面的节点可以是强大的LLM调用并且支持复杂的控制流循环、条件分支。OpenClaw如何体现前述概念对LLM的利用它深度集成了多种LLM将其作为工作流中的核心处理节点。对Workflow的支持它提供了可视化编辑器虽然早期版本可能以代码为主允许你通过拖拽或编码来定义任务流程保证了过程的透明和可管理。对Agent能力的赋能通过其“规划节点”或“工具调用节点”你可以让LLM在工作流的某个环节自主决定下一步动作实现了局部或全局的Agent能力。你可以构建一个“Claw”去自动完成一个多步骤的、需要判断的任务比如自动化的数据巡检与报告生成。对Function Call/MCP的整合它可以方便地封装和调用外部工具函数虽然它可能尚未原生支持MCP协议但其工具调用的设计思想是相通的。使用OpenClaw这样的框架开发者无需从零开始处理LLM的API调用、上下文管理、错误重试等繁琐细节可以更专注于业务逻辑和流程的设计。它降低了AI应用特别是复杂自动化AI Agent的开发门槛。7. 概念关系与层级架构梳理现在让我们把这些概念放到一个整体的层级架构里来看就非常清晰了。网上有人问“LLM、Agent、RAG、Harness是按什么层级架构构成一个AI的” 这是一个很好的问题虽然“Harness”不是通用术语可能指某个特定框架或控制层但我们可以构建一个通用的理解模型。我们可以将其视为一个从底层能力到顶层应用的“栈”[ 应用层 / 解决方案 ] | | 体现为具体的产品或服务如智能客服、AI数据分析师、自动编程助手等。 | [ 编排与执行层 ] | |-- Agent智能体具备自主规划、工具调用、反思能力的高级系统。 | |-- 依赖于Workflow用于复杂固定流程 Function Calling用于基础工具交互。 | |-- Workflow工作流预定义的、确定性的自动化流程蓝图。 | |-- 由多个节点LLM、工具、判断等组成。 | [ 工具与扩展层 ] | |-- Skill技能封装好的业务能力单元可由Agent或Workflow调用。 | |-- MCP Server模型上下文协议服务器提供标准化工具/资源的独立服务。 | |-- Function函数具体的、可被调用的操作单元。 | [ 核心能力层 ] | |-- RAG检索增强生成一种为LLM提供外部知识源的技术可被视作一个强大的“工具”。 | |-- Function Calling函数调用让LLM与外部世界交互的基础协议。 | [ 基础模型层 ] | |-- LLM大语言模型一切的核心提供语言理解、生成和推理的基础能力。如何理解这个架构LLM是引擎是所有智能的源泉。Function Calling是让引擎连接轮子的传动轴是最基础的交互方式。RAG是一种特殊的“加油枪”或“外挂知识库”为引擎注入特定燃料信息。MCP是标准化的“零部件接口规范”确保各种工具轮子、方向盘能即插即用。Skill是组装好的“功能模块”比如一套完整的音响系统。Workflow是“自动驾驶的固定路线图”在已知路况下高效安全。Agent是“拥有地图和应变能力的资深司机”在未知路况下自主探索。最终所有这些技术组合起来构建出上层的具体AI应用比如一辆能自己接单、送客、充电的“自动驾驶出租车”一个复杂的AI Agent。8. 实战用代码串联概念——一个简易新闻分析Agent理论说了这么多不来点代码总觉得脚不沾地。下面我将用一个简化的Python示例展示如何利用LangChain框架构建一个具备新闻搜索、总结和情感分析能力的微型Agent。这个例子会涉及LLM调用、Function Calling工具使用、以及简单的多步骤规划。注意以下代码为示例需要安装langchain,langchain-openai,langchain-community等包并准备有效的OpenAI API Key。import os from langchain_openai import ChatOpenAI from langchain.agents import AgentExecutor, create_openai_tools_agent from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain_community.tools import TavilySearchResults from langchain_core.messages import HumanMessage, AIMessage # 1. 初始化核心LLM基础模型层 llm ChatOpenAI(modelgpt-4-turbo-preview, temperature0, api_keyos.getenv(OPENAI_API_KEY)) # 2. 定义工具工具与扩展层 / Function Calling的实践 # 使用Tavily搜索作为工具这可以看作一个简易的“搜索MCP Server”的客户端 search_tool TavilySearchResults(api_keyos.getenv(TAVILY_API_KEY), max_results2) # 我们自定义一个简单的情感分析工具 from langchain.tools import tool tool def sentiment_analyzer(text: str) - str: 分析一段文本的情感倾向。返回 正面、负面 或 中性。 # 这里为了简化我们让LLM自己分析。实际应用中可能调用专门的NLP模型API。 prompt f请分析以下文本的情感倾向只返回一个词正面、负面 或 中性。 文本{text} 情感 response llm.invoke(prompt) return response.content.strip() tools [search_tool, sentiment_analyzer] # 3. 构建Agent提示词赋予其规划和工具使用能力 prompt ChatPromptTemplate.from_messages([ (system, 你是一个新闻分析助手。你的任务是 1. 根据用户的问题使用搜索工具获取最新的相关新闻。 2. 对搜索到的新闻内容进行总结。 3. 使用情感分析工具判断新闻内容的情感倾向。 请一步步思考并只在必要时使用工具。你的最终输出应是一份简洁的分析报告。), MessagesPlaceholder(variable_namechat_history), (human, {input}), MessagesPlaceholder(variable_nameagent_scratchpad), # 用于记录Agent的思考过程 ]) # 4. 创建Agent编排与执行层 agent create_openai_tools_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) # 5. 运行Agent模拟应用层 chat_history [] # 简单的记忆 user_query 关于苹果公司最新发布的Vision Pro市场反响如何 print(f用户提问: {user_query}\n) try: result agent_executor.invoke({ input: user_query, chat_history: chat_history }) print(\n Agent最终输出 ) print(result[output]) # 更新聊天历史简单的短期记忆 chat_history.extend([ HumanMessage(contentuser_query), AIMessage(contentresult[output]) ]) except Exception as e: print(f执行出错: {e})代码解读与概念对应LLM我们使用ChatOpenAI作为智能的“大脑”基础模型层。Function Call / ToolTavilySearchResults和sentiment_analyzer就是我们定义的两个“函数”或“工具”。LangChain帮我们把这些工具的描述格式化成LLM能理解的Function Call规范。Agentcreate_openai_tools_agent和AgentExecutor共同构成了一个简单的Agent框架。这个框架负责将用户输入和工具列表给LLM。解析LLM的输出判断是直接回答还是要调用工具规划。如果调用工具则执行对应函数并将结果格式化后放回LLM的上下文执行与观察。循环此过程直到LLM认为任务完成并输出最终答案。Workflow的体现虽然这个Agent是自主规划的但其内在的“感知-规划-执行-观察”循环本身就是一个被框架固化的微工作流。更复杂的LangGraph则允许你显式地定义这种循环和分支走向更可控的Workflow式Agent。Skill我们构建的这个“新闻分析助手”本身就可以看作一个初级的新闻分析Skill。它可以被集成到更大的系统中。MCP的想象如果TavilySearchResults工具不是直接集成而是通过连接一个标准的“Tavily MCP Server”来获取那么我们的代码就更符合MCP的哲学——工具动态发现、安全调用。运行这段代码需配置好API Key你会看到Agent在控制台打印出它的思考过程verboseTrue例如 进入新的Agent执行链... 思考我需要先搜索关于苹果Vision Pro市场反响的最新新闻。 行动使用tavily_search_results_json工具。 行动输入{query: Apple Vision Pro market reaction latest news 2024} 观察[...搜索到的新闻结果...] 思考我获得了新闻内容。现在需要总结这些内容并分析情感。 行动使用sentiment_analyzer工具。 行动输入{text: [...第一条新闻的摘要...]} 观察正面 ...可能继续... 最终输出根据最新市场信息苹果Vision Pro发布后初期市场反响积极...总结... 整体情感倾向为正面。这个简单的例子展示了如何将LLM、工具调用和Agent框架组合起来创建一个能自主完成“搜索-分析-总结”多步骤任务的智能体。从这出发你可以为其添加更多工具如数据库查询、邮件发送设计更复杂的提示词或者用LangGraph将其转换为一个可视化、可精确控制的工作流从而应对更复杂的业务场景。