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从“纯聊天”进化到了“能指挥外部工具”。但它的局限性也很明显：

1. 单次性：通常一次对话回合只处理一个函数调用。复杂的、需要多个步骤串联的任务（比如“查一下北京飞上海的航班，选最便宜的那个，然后帮我生成一个出行摘要文档”）很难通过一次Function Call完成。
2. 上下文管理负担重：开发者需要自己管理对话历史、函数调用结果，并决定何时、如何将这些信息重新喂给LLM。如果忘记把某个关键的执行结果放回上下文，对话逻辑可能立刻断裂，也就是网上常说的“死机”。
3. 流程控制弱：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思路：需要开发者写代码来管理状态：先调用搜索函数，把结果给LLM，LLM说需要总结，再触发总结函数……逻辑散落在代码各处。
• Workflow思路：在画布上拉出三个节点：搜索节点->LLM总结节点->文档生成节点。连线，设置好数据流转。执行引擎会按序执行，与LLM的“主观能动性”无关。

所以，Workflow的核心优势是确定性与可靠性。它适合那些步骤固定、逻辑清晰的自动化任务，比如客服自动应答流水线、内容批量生成与审核、数据ETL处理等。它的缺点是不够灵活，无法应对流程图中未定义的、突发的新情况。

4. Agent：赋予LLM“自主规划与执行”的能力

Agent（智能体）是当前最火热也最易混淆的概念。在我看来，Agent是Function Call和Workflow思想的集大成者，并引入了更关键的要素：自主性（Autonomy）。

一个真正的Agent，不仅仅是一个能调用工具的LLM，更是一个具备以下特点的系统：

1. 规划（Planning）：面对复杂目标，能将其分解为一系列子任务或步骤（Let's think step by step就是最基础的规划体现）。
2. 工具使用（Tool Use）：知道在何时、使用何种工具来完成任务。
3. 记忆（Memory）：拥有短期（对话上下文）和长期（向量数据库等）记忆，能参考历史信息。
4. 反思（Reflection）：能评估自己行动的结果，如果失败了或效果不佳，能调整策略重新尝试。

Agent与Workflow的哲学区别：Workflow是“剧本”，演员（LLM）必须严格按照剧本来。Agent是“导演”，它手里有剧本大纲（目标）、可用的演员和道具（工具），但具体每场戏怎么拍、遇到突发状况怎么处理，由导演临场决定。Agent的核心在于其基于LLM的决策循环：感知（当前状态和任务）-> 规划（下一步做什么）-> 执行（调用工具或输出）-> 观察（结果）-> 再规划……直到任务完成或无法继续。

网上很多讨论把“能调用Function的LLM”就叫Agent，这稀释了Agent的概念。按此标准，第一部分讲的Function Call例子已经是Agent了。更严格的区分，可以看系统的主导权：

• 工具调用模式：用户或预设流程主导，LLM按需提供“函数调用建议”。
• Agent模式：LLM（在一定的框架和约束下）主导整个任务解决过程。

一个经典的Agent框架（如LangChain的AgentExecutor、AutoGPT）的工作流程如下：

1. 用户输入目标：“帮我研究一下特斯拉最新的财报，总结其营收亮点和风险，写一份500字的分析。”
2. Agent框架初始化，配备工具集：网络搜索工具、财报PDF解析工具、总结写作工具。
3. LLM（Agent的大脑）开始思考：“要完成这个，我需要先搜索特斯拉最新财报，下载PDF，提取关键数据，然后进行分析写作。”
4. LLM决定第一步：调用网络搜索工具，关键词“Tesla Q4 2023 earnings report PDF”。
5. 框架执行搜索，将结果返回给LLM。
6. LLM观察结果，发现了一个PDF链接，于是决定第二步：调用财报PDF解析工具，传入链接。
7. 框架解析PDF，将文本数据返回给LLM。
8. LLM阅读文本，决定第三步：直接进行分析和写作（此时可能调用多次LLM自身进行信息提炼和草稿撰写）。
9. 最终，LLM输出完成的分析报告。

整个过程，开发者没有预先规定“必须先A后B再C”，只是提供了工具和起点，具体的路径是Agent自己“想”出来并执行的。这就是自主性。

5. Skill与MCP：模块化与标准化的“工具包”

在构建Agent或Workflow时，我们经常需要用到各种工具。如何高效地管理、复用和共享这些工具呢？这就涉及到Skill和MCP这两个概念。

Skill（技能）是一个比较上层的业务概念。它指的是一个封装好的、能完成特定业务目标的能力单元。一个Skill内部可能包含多次LLM调用、多个工具协作、甚至内嵌一个小的Workflow。例如，“订机票Skill”可能包含了查询航班、比价、选择航班、填写乘客信息、支付等一系列动作的封装。Skill强调业务功能的完整性和复用性，是面向最终用户的。Dify等平台中提到的“技能”，通常就是这个层面。

MCP（Model Context Protocol，模型上下文协议）则是更底层、更技术化的一个开放协议，由Anthropic提出并开源。它要解决的核心问题是：如何让LLM（无论是云端模型如Claude，还是本地部署的模型）能够以一种标准化、安全、可扩展的方式，访问外部工具、数据和功能？

在MCP架构下，工具和数据不再是以零散的“函数描述”列表形式硬编码到应用里，而是由独立的MCP Server（服务器）来提供。每个MCP Server就像一个专用的“服务提供商”，它通过标准协议告诉LLM：“我这里能提供哪些工具（Tools）或资源（Resources）”。你的AI应用（作为MCP Client）则可以动态地连接一个或多个MCP Server，将它们提供的工具集成了LLM的上下文中。

MCP带来的革命性好处：

1. 解耦与标准化：工具开发者和AI应用开发者分离。你可以专门写一个“数据库查询MCP Server”，另一个团队写“公司内部CRM查询MCP Server”。任何支持MCP的AI应用（如Claude Desktop、支持MCP的代码编辑器）都可以无缝集成这些工具，无需重复开发。
2. 动态性与安全性：工具可以远程运行，权限可控。比如，一个“代码执行”MCP Server可以运行在安全的沙箱环境中，与主应用隔离，避免了直接给LLM开放危险的系统调用权限。
3. 生态共享：正在形成一个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（大语言模型）：一切的核心，提供语言理解、生成和推理的基础能力。

如何理解这个架构？

1. LLM是引擎，是所有智能的源泉。
2. Function Calling是让引擎连接轮子的传动轴，是最基础的交互方式。
3. RAG是一种特殊的“加油枪”或“外挂知识库”，为引擎注入特定燃料（信息）。
4. MCP是标准化的“零部件接口规范”，确保各种工具（轮子、方向盘）能即插即用。
5. Skill是组装好的“功能模块”，比如一套完整的音响系统。
6. Workflow是“自动驾驶的固定路线图”，在已知路况下高效安全。
7. Agent是“拥有地图和应变能力的资深司机”，在未知路况下自主探索。
8. 最终，所有这些技术组合起来，构建出上层的具体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(model="gpt-4-turbo-preview", temperature=0, api_key=os.getenv("OPENAI_API_KEY")) # 2. 定义工具（工具与扩展层 / Function Calling的实践） # 使用Tavily搜索作为工具（这可以看作一个简易的“搜索MCP Server”的客户端） search_tool = TavilySearchResults(api_key=os.getenv("TAVILY_API_KEY"), max_results=2) # 我们自定义一个简单的情感分析工具 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_name="chat_history"), ("human", "{input}"), MessagesPlaceholder(variable_name="agent_scratchpad"), # 用于记录Agent的思考过程 ]) # 4. 创建Agent（编排与执行层） agent = create_openai_tools_agent(llm, tools, prompt) agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True, handle_parsing_errors=True) # 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(content=user_query), AIMessage(content=result["output"]) ]) except Exception as e: print(f"执行出错: {e}")

代码解读与概念对应：

1. LLM：我们使用ChatOpenAI作为智能的“大脑”（基础模型层）。
2. Function Call / Tool：TavilySearchResults和sentiment_analyzer就是我们定义的两个“函数”或“工具”。LangChain帮我们把这些工具的描述格式化成LLM能理解的Function Call规范。
3. Agent：create_openai_tools_agent和AgentExecutor共同构成了一个简单的Agent框架。这个框架负责：
   • 将用户输入和工具列表给LLM。
   • 解析LLM的输出，判断是直接回答还是要调用工具（规划）。
   • 如果调用工具，则执行对应函数，并将结果格式化后放回LLM的上下文（执行与观察）。
   • 循环此过程，直到LLM认为任务完成并输出最终答案。
4. Workflow的体现：虽然这个Agent是自主规划的，但其内在的“感知->规划->执行->观察”循环，本身就是一个被框架固化的微工作流。更复杂的LangGraph则允许你显式地定义这种循环和分支，走向更可控的Workflow式Agent。
5. Skill：我们构建的这个“新闻分析助手”，本身就可以看作一个初级的新闻分析Skill。它可以被集成到更大的系统中。
6. MCP的想象：如果TavilySearchResults工具不是直接集成，而是通过连接一个标准的“Tavily MCP Server”来获取，那么我们的代码就更符合MCP的哲学——工具动态发现、安全调用。

运行这段代码（需配置好API Key），你会看到Agent在控制台打印出它的思考过程（verbose=True），例如：

> 进入新的Agent执行链... 思考：我需要先搜索关于苹果Vision Pro市场反响的最新新闻。 行动：使用`tavily_search_results_json`工具。 行动输入：{"query": "Apple Vision Pro market reaction latest news 2024"} 观察：[...搜索到的新闻结果...] 思考：我获得了新闻内容。现在需要总结这些内容，并分析情感。 行动：使用`sentiment_analyzer`工具。 行动输入：{"text": "[...第一条新闻的摘要...]"} 观察：正面 ...（可能继续）... 最终输出：根据最新市场信息，苹果Vision Pro发布后，初期市场反响积极...（总结）... 整体情感倾向为正面。

这个简单的例子展示了如何将LLM、工具调用和Agent框架组合起来，创建一个能自主完成“搜索->分析->总结”多步骤任务的智能体。从这出发，你可以为其添加更多工具（如数据库查询、邮件发送），设计更复杂的提示词，或者用LangGraph将其转换为一个可视化、可精确控制的工作流，从而应对更复杂的业务场景。