1. 从“乱学”到“体系”为什么你需要一套AI工作流最近和不少朋友聊天发现一个挺普遍的现象很多人对AI的热情很高今天刷到一个“Prompt万能公式”就赶紧收藏明天看到“Agent是未来”又去研究框架后天听说某个新出的MCP工具很酷又一头扎进去。折腾一圈下来感觉学了很多“名词”但真到自己想做个东西比如让AI自动处理日报、分析数据或者做个智能客服原型却不知道从哪里下手各种工具和概念像一盘散沙串不起来。这其实就是典型的“乱学”。AI领域尤其是大语言模型LLM应用层新概念、新工具层出不穷如果只盯着孤立的名词和技术点很容易陷入“知识碎片化”的困境知道很多但不会用。今天我们不谈那些高深莫测的理论就从一个一线实践者的角度把这七个最常被提及、也最核心的名词——AI、LLM、Agent、Prompt、MCP以及常被关联提及的Workflow和Function Calling——给你捋清楚。它们不是七个孤立的“知识点”而是一套环环相扣、从想法到产品的完整AI应用工作流。理解了这个工作流你就能像搭积木一样清晰地知道在每个环节该用什么、为什么用、以及怎么把它们组合起来真正把AI能力“用”起来而不是“学”一堆用不上的东西。2. 基石与引擎理解AI与LLM的真实定位在我们开始搭建工作流之前必须先把两块最重要的基石摆正位置。很多人对它们的理解有偏差导致后续所有构建都摇摇欲坠。2.1 AI它不是你想象中的“万能大脑”首先说AI人工智能。在当前的语境下特别是当我们讨论“AI工作流”时它指代的往往不是那个宏大的、科幻意义上的强人工智能而是特指基于大语言模型LLM的一系列能力与应用。你可以把它理解为我们想要实现的最终智能行为或功能的目标。比如“一个能自动写周报的AI”、“一个能分析客户评论情感的AI”、“一个能回答产品问题的AI客服”。这里的“AI”是一个功能性的目标描述。一个关键的认知转变是现在的AILLM不是一个封装好的、输入问题就直接吐出完美答案的黑盒程序。它更像一个拥有庞杂知识、强大理解与生成能力但需要精确引导和约束的“超级实习生”。你不能对它说“去写份报告”然后就指望得到一份结构严谨、数据准确、文笔优美的成品。你必须告诉它报告给谁看、需要什么结构、重点是什么、甚至用什么语气。这个“告诉”的过程就是后续所有环节要解决的问题。所以AI是我们的目标而LLM是实现这个目标的核心引擎。2.2 LLM工作流的核心发动机与它的“怪癖”LLM大语言模型如GPT-4、Claude、文心一言、通义千问等是我们整个工作流的核心计算引擎。它的本质是一个基于海量文本训练出来的、能够根据上文预测下一个词token的概率模型。正是这个简单的机制赋予了它令人惊叹的对话、创作、推理和代码能力。但在工作流中我们不能只把它当做一个聊天机器人。要高效利用它必须了解它的几个关键“工作特性”无状态性StatelessLLM本身没有记忆。你每次发送请求API调用它都视为一个全新的对话。这意味着所有上下文历史对话、系统指令、用户身份等都需要你在每次请求时明确提供。这是设计工作流时最重要的前提。概率性输出同样的输入它每次产生的输出可能有细微差别。这对于创意工作是优点但对于需要稳定输出的生产环节如数据提取、格式生成则是挑战需要通过Prompt工程和后续流程来约束。上下文窗口限制每个模型都有最大的上下文长度如128K tokens。你一次能喂给它的信息系统指令对话历史本次查询不能超过这个限制。处理长文档或复杂多轮对话时必须考虑如何精简或分割上下文。纯文本接口LLM只理解和输出文本。它不知道如何操作数据库、调用天气API、执行一段代码。它需要“帮手”来与外部世界交互。理解了LLM的这些特性你就会明白直接裸用LLM API是很难构建复杂应用的。我们需要一套“控制系统”来管理它的状态、约束它的输出、扩展它的能力。这就是后面几个概念登场的原因。3. 工作流的控制中枢Prompt与System Prompt的设计艺术既然LLM需要引导那么“引导指令”就是最关键的一环。这就是Prompt提示词。但Prompt不是一句简单的“请好好回答”。在工作流中我们需要更精细地设计它通常分为两个层面System Prompt系统提示词和User Prompt用户提示词。3.1 System Prompt定义AI的“角色”与“行为准则”System Prompt是在对话开始时或每次调用LLM时首先发送的、设定AI角色和全局规则的指令。它对于构建稳定、可靠的AI应用至关重要。你可以把它理解为给那个“超级实习生”的岗位说明书和员工手册。一个设计良好的System Prompt通常包含以下几个部分角色定义明确告诉LLM“你是谁”。例如“你是一位资深的数据分析师擅长从复杂数据中提炼核心洞察并以简洁明了的语言汇报。”任务目标说明这个对话或任务的最终目标。例如“你的任务是分析用户提供的销售数据并生成一份包含关键趋势、异常点和建议的摘要报告。”输出格式约束严格要求输出的结构。例如“请始终以Markdown格式输出必须包含‘## 核心发现’、‘## 数据趋势’、‘## 行动建议’三个章节。每个章节下使用项目符号列表。”行为规范与禁忌规定什么该做什么不该做。例如“只基于提供的数据进行分析不要编造数据。如果数据不足以下结论请明确说明‘数据不足’。不要使用任何主观臆断的词汇如‘我认为’。”处理流程对于复杂任务可以给出思考步骤。例如“请按以下步骤处理1. 校验数据完整性。2. 计算关键指标同比增长率、环比增长率。3. 识别最大值、最小值及异常波动。4. 综合上述分析生成报告。”实操心得System Prompt不是越长越好。过于冗长的指令可能会占用大量宝贵的上下文窗口甚至导致模型忽略后半部分的关键指令。我的经验是优先确保核心规则角色、格式、禁忌清晰明确必要时可以将复杂的处理流程拆解通过多次对话即Workflow来逐步完成。3.2 User Prompt与Function Calling精准的用户请求与能力扩展User Prompt就是用户或系统发出的具体请求比如“分析一下附件中Q3的销售数据.csv”。在工作流自动化场景中User Prompt往往也是由程序生成的。但当用户的需求涉及“获取实时信息”或“执行具体操作”时比如“查询北京今天的天气”或“将会议纪要保存到Notion”纯文本的LLM就无能为力了。这时就需要Function Calling函数调用机制。Function Calling不是LLM自己去执行函数而是一个精巧的协作流程开发者在调用LLM API时除了发送对话消息还会附带一个“工具列表”描述可供调用的函数及其参数格式。例如{“name”: “get_weather”, “description”: “获取指定城市的天气”, “parameters”: {“type”: “object”, “properties”: {“city”: {“type”: “string”}}}}。LLM分析用户的Prompt判断是否需要以及需要调用哪个函数。如果需要它不会直接执行而是返回一个结构化的JSON对象指明它“想调用”哪个函数以及具体的参数是什么。例如{“name”: “get_weather”, “arguments”: {“city”: “北京”}}。你的应用程序收到这个JSON后在本地安全地执行对应的get_weather函数真正调用天气API。将函数执行的结果如{“city”: “北京”, “weather”: “晴”, “temperature”: “25°C”}作为新的上下文信息再次发送给LLM。LLM结合函数返回的结果组织成自然语言回复给用户“北京今天天气晴朗气温25摄氏度。”关键区别这里常常有人混淆LangChain的工具调用和LLM原生的Function Calling。LangChain是一个高层框架它封装了包括Function Calling在内的多种与LLM交互的模式。而LLM原生的Function Calling如OpenAI的tools参数是模型本身支持的一种标准化协议速度更快、精度更高。LangChain工具调用的速度主要受其抽象层复杂度、工具本身执行时间如网络请求以及是否采用并行化等因素影响。在简单、追求性能的场景下直接使用原生的Function Calling接口往往是更优选择。4. 从单次调用到复杂流程Workflow与Agent的进化当任务超越一次简单的问答需要多个步骤、多次LLM调用、并穿插条件判断和工具调用时我们就进入了Workflow工作流和Agent智能体的领域。这两者是构建复杂AI应用的核心。4.1 Workflow可预测的、线性的自动化管道Workflow或称LLM工作流是一种将多个LLM调用和工具调用按预定流程组织起来的方法。它通常是确定性的和线性的。你可以把它想象成一个流程图或者烹饪食谱第一步做什么第二步做什么如果遇到情况A则走分支B最后输出结果。一个典型的Workflow例子是Dify、LangChain Expression Language (LCEL)或微软的Semantic Kernel所构建的流程。例如一个“会议纪要分析与归档”Workflow可能包含以下节点输入节点接收音频文件。工具节点调用语音转文本STT服务将音频转为文字稿。LLM节点Prompt 1发送System Prompt“你是一个专业的会议纪要整理助手”和User Prompt“请总结以下文字稿提取关键决策、行动项和负责人”获得结构化摘要。LLM节点Prompt 2将上一步的摘要发送给另一个LLM其System Prompt是“你是一个邮件写手”生成一封发给与会者的总结邮件。工具节点调用Notion或Google Docs的API将结构化摘要保存到指定文档。工具节点调用邮件发送API将总结邮件发出。输出节点返回“处理完成”的状态和所有生成物的链接。Dify实战示例在Dify中构建上述Workflow非常直观。你可以通过拖拽节点来搭建这个流程。对于“将LLM输出的内容保存到一个Word文档”这个需求你可以在LLM节点后连接一个“代码工具”节点。在该节点中你可以编写Python代码使用像python-docx这样的库接收前序LLM节点的输出作为变量然后创建、编辑并保存Word文档。Dify负责将各个节点的输入输出串联起来并管理整个流程的状态。Workflow的优势在于稳定、可调试、易监控。每个步骤都是预设好的适合处理有固定模式的、重复性的任务。4.2 Agent具备自主决策能力的“智能代理”如果说Workflow是一个自动化的流水线那么Agent就是一个被赋予了自主决策能力的AI程序。它的核心特点是能够根据目标、当前状态和环境反馈自主决定下一步该做什么调用什么工具甚至进行多步推理ReAct模式Reason Act。一个Agent通常由几个核心部分组成规划器Planner分解目标制定计划。例如目标“为公司官网写一篇关于新产品的博客”规划器可能分解为“1. 调研竞品文案 2. 列出产品核心卖点 3. 撰写初稿 4. 优化SEO关键词”。工具集ToolsAgent可以调用的各种函数如搜索、计算、读写文件、调用API等。记忆Memory存储对话历史、工具执行结果、知识片段为后续决策提供上下文。执行器Executor核心循环负责在“思考调用LLM进行规划或推理”和“行动调用工具”之间迭代直到完成任务或达到终止条件。与Workflow的关键区别Workflow是“如果-那么”的固定路径而Agent是“为了达成目标我现在应该做什么”的动态路径。例如一个数据分析Agent你给它一个“分析这份数据并告诉我洞察”的目标它可能会自主决定先调用工具进行数据清洗发现异常值后决定先做异常排查然后再进行趋势分析最后选择用图表工具生成可视化并将结果摘要发送邮件。这个路径不是事先写死的是Agent自己“想”出来的。主流框架LangChain和LlamaIndex是构建Agent的流行框架它们提供了规划、工具调用、记忆管理等高级抽象。像“上海交大Agent教程”中可能详细讲解的以及“Hermes Agent”这类项目都是具体的Agent实现案例。5. 连接外部世界的标准接口深入理解MCP协议现在我们的Agent有了大脑LLM和自主决策能力它需要调用各种工具Tools来行动。但是如果每个工具都需要Agent开发者自己去写适配代码那将是一场噩梦。而且如何让不同的AI应用如Codex、Cursor、Claude Desktop都能方便地使用同一套工具呢这就需要一种标准化的协议——MCPModel Context Protocol。5.1 MCP是什么为什么说它是游戏规则改变者MCP由Anthropic公司推出是一个标准化协议用于定义AI应用程序客户端如何发现、调用来自不同来源服务器的工具和资源。你可以把它理解为AI世界的“USB标准”或“蓝牙协议”。在MCP之前情况是这样的你想在Codex里用Brave搜索需要找特定的插件或自己写集成想在另一个AI IDE里用Jira查任务又得再来一遍。每个AI应用和工具之间都是点对点的、紧耦合的集成效率低下生态割裂。MCP的引入彻底改变了这一点服务端MCP Server任何工具或数据源的提供者如Brave搜索、公司内部数据库、GitHub接口都可以按照MCP协议实现一个标准的“服务器”。这个服务器对外暴露一系列“工具”Tools和“资源”Resources如只读数据。客户端MCP ClientAI应用如Claude Desktop、Cursor、Codex只需要实现MCP客户端协议就能自动发现、加载并调用任何符合MCP协议的服务器提供的工具。用户无需为每个应用单独配置工具。5.2 如何将MCP服务器如Tavily/Brave搜索添加到Codex以在Codex中添加搜索类MCP服务器为例以下是基于通用MCP集成原理的详细步骤具体UI可能随Codex版本更新准备MCP服务器首先你需要目标MCP服务器的实现。例如tavily-mcp或brave-search-mcp。这些通常是开源项目你需要按照其README文档在本地或服务器上安装并运行起来。运行后它会在一个本地端口如localhost:3000上提供MCP服务。配置Codex客户端打开Codex或支持MCP的AI IDE的设置或配置界面寻找“MCP Servers”、“工具集成”或“高级设置”等相关选项。添加服务器连接在配置界面你需要添加一个新的MCP服务器连接。通常需要提供以下信息服务器名称自定义一个易识别的名字如“Tavily Web Search”。传输方式MCP支持几种传输方式最常见的是Stdio标准输入输出用于本地命令行程序和SSE服务器发送事件用于HTTP服务。对于tavily-mcp这类常作为独立进程运行的可能需要配置为Stdio并指定启动命令和参数。例如命令可能是npx modelcontextprotocol/server-tavily并设置API密钥等环境变量。如果是HTTP服务则需提供URL如http://localhost:3000/sse。认证信息如果服务器需要API密钥如Tavily、Brave搜索的API Key需要在配置中填入。验证与使用保存配置后重启Codex或重载工具列表。如果配置成功你应该能在Codex的AI聊天界面中看到新增加的工具选项。当你输入“搜索最新的LLM新闻”时Codex背后的AI模型通过MCP客户端就会自动发现并调用你配置的Tavily搜索工具获取实时结果后整合进回复。核心价值MCP实现了工具生态与AI应用的解耦。工具开发者只需写一次MCP服务器就能服务所有支持MCP的客户端。AI应用开发者只需维护一个MCP客户端就能接入整个生态的工具。对于最终用户这意味着可以在自己喜爱的AI应用里无缝使用一个不断增长的工具世界极大地提升了生产力和体验。像“Cesium MCP”、“Playwright MCP”等项目都是将特定领域能力如3D地图、浏览器自动化通过MCP标准化的例子。6. 实战串联从零构建一个智能专利信息分析Agent理论说了这么多我们用一个综合性的例子把AI、LLM、Prompt、Function Calling、Agent、MCP和Workflow全部串联起来看看如何构建一个实用的智能应用专利信息分析Agent。项目目标创建一个Agent用户只需输入一个技术关键词如“固态电池”Agent能自动搜索相关专利下载专利文档提取核心信息如申请人、发明人、摘要、权利要求并进行初步的竞争格局分析。6.1 系统架构与组件选型AI目标智能专利信息分析与报告生成。核心LLM引擎选择一款长上下文、分析能力强的模型如Claude 3.5 Sonnet或GPT-4o。它们能更好地处理和分析长篇专利文档。Agent框架使用LangChain。因为它生态成熟对工具调用、记忆、规划的支持完善社区资源丰富。工具集Tools规划专利搜索工具理想情况下可以寻找或自建一个专利数据库的MCP Server。例如一个封装了Google Patents或某商业专利数据库API的MCP服务器。这样我们的LangChain Agent就能通过MCP协议标准地调用它。如果没有现成的则需用LangChain的tool装饰器自定义一个搜索函数。文档下载与解析工具专利常以PDF形式存在。需要工具下载PDF并用PyPDF2或pdfplumber库解析文本。信息提取工具这本身可以是一个精心设计的LLM调用Function Calling。我们定义函数extract_patent_info(pdf_text)描述为“从专利文档全文文本中提取结构化信息”。在调用LLM时将此函数描述作为工具提供。LLM会分析PDF文本并返回结构化的JSON数据。数据存储工具将提取的信息保存到数据库如SQLite、PostgreSQL或Notion/Airtable中。分析报告生成工具另一个LLM调用。将多篇专利的结构化信息汇总让LLM撰写竞争格局分析报告。Workflow设计这个Agent的任务本质是一个多步骤的Workflow但由Agent自主决策。我们可以用LangChain的Plan-and-Execute或ReAct代理类型来构建。6.2 核心实现步骤与代码逻辑示意以下是基于LangChain框架的核心逻辑伪代码展示了如何将各个模块组装起来# 伪代码展示核心逻辑 from langchain.agents import AgentExecutor, create_react_agent from langchain.tools import Tool from langchain_community.utilities import GooglePatentsAPIWrapper # 假设的包装器 from langchain_core.prompts import ChatPromptTemplate import pdfplumber # 1. 定义工具函数 def search_patents(query: str) - list: 使用MCP客户端或直接API搜索专利 # 如果是MCP则通过MCP客户端调用对应工具 # mcp_client.call_tool(patent_search, {query: query}) # 此处简化假设调用一个封装好的API patents patents_api.search(queryquery, num_results10) return [{title: p.title, id: p.id, link: p.link} for p in patents] def download_and_parse_pdf(patent_id: str) - str: 下载并解析专利PDF为文本 pdf_path download_pdf_from_id(patent_id) text with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: text page.extract_text() \n return text # 注意extract_info本身是一个需要LLM参与的工具我们将其定义为一个LLM函数调用工具 from langchain.chains.openai_functions import create_extraction_chain_pydantic from pydantic import BaseModel, Field class PatentInfo(BaseModel): title: str Field(description专利标题) applicants: list[str] Field(description申请人列表) inventors: list[str] Field(description发明人列表) abstract: str Field(description摘要) claims: list[str] Field(description独立权利要求列表) # 创建信息提取链它内部会使用LLM的Function Calling能力 extraction_chain create_extraction_chain_pydantic(PatentInfo, llm, system_message你是一个专利文档分析专家...) def extract_patent_info(pdf_text: str) - dict: 调用LLM提取专利结构化信息 result extraction_chain.invoke({input: pdf_text}) return result[0].dict() # 返回第一个提取到的实体专利的字典 # 2. 将函数包装成LangChain Tool search_tool Tool(namePatentSearch, funcsearch_patents, description根据关键词搜索相关专利返回专利列表含标题、ID和链接) download_tool Tool(nameDownloadPatentPDF, funcdownload_and_parse_pdf, description根据专利ID下载并解析PDF文档为纯文本) extract_tool Tool(nameExtractPatentInfo, funcextract_patent_info, description从专利文档全文文本中提取结构化的专利信息标题、申请人、发明人、摘要、权利要求) # 3. 创建Agent tools [search_tool, download_tool, extract_tool] prompt ChatPromptTemplate.from_messages([...]) # 包含System Prompt定义Agent角色和目标 agent create_react_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) # 4. 运行Agent result agent_executor.invoke({ input: 请帮我分析一下‘全固态锂电池电解质’领域近三年的专利情况找出主要的申请人和技术焦点并生成一份分析报告。 })这个Agent会如何自主工作LLMAgent的大脑收到用户请求分析后认为第一步需要搜索专利。它决定调用PatentSearch工具并生成参数query全固态锂电池电解质 近三年。执行器调用该工具获得专利列表。LLM拿到列表后决定需要深入分析每篇专利于是对列表中的每一项依次调用DownloadPatentPDF和ExtractPatentInfo工具。收集完所有专利的结构化信息后LLM判断信息已足够开始调用其自身的文本生成能力这不再是一个外部工具而是LLM的核心能力撰写一份包含竞争格局、技术趋势和主要申请人分析的报告。最后Agent输出这份报告。你还可以增加一个工具将这份报告自动保存为Word文档利用python-docx库这就完成了从搜索、处理、分析到归档的完整自动化流程。7. 避坑指南与进阶思考让工作流真正稳健运行构建一个能跑通的Demo只是第一步要让AI工作流真正可靠地用于生产环境还有大量的细节需要考虑。以下是一些从实战中总结的避坑经验和进阶方向。7.1 常见陷阱与解决方案陷阱一Prompt设计不当导致输出格式不稳定问题你要求LLM输出JSON但它有时会输出“json ...”这样的Markdown代码块有时会在JSON外加解释文字导致后端解析失败。解决方案在System Prompt中极其严格地规定格式例如“你必须且只能输出一个合法的JSON对象不要有任何额外的解释、标记或空格。输出格式示例{“key”: “value”}。”使用LLM提供的结构化输出功能如OpenAI的response_format{“type”: “json_object”}或Anthropic的structured_output。这能极大提高输出格式的稳定性。在代码中做好防御性解析使用try...except包裹解析逻辑并在失败时提供有意义的错误信息或重试机制。陷阱二上下文管理混乱与Token超限问题在长对话或多步骤Workflow中不断累积的对话历史很快会撑爆上下文窗口导致请求被拒绝或模型“遗忘”早期指令。解决方案选择性记忆不要无脑地将所有历史消息都塞进上下文。使用ConversationSummaryMemory或ConversationBufferWindowMemoryLangChain提供来只保留最近N轮对话或对历史进行摘要。分而治之对于处理长文档的任务不要一次性塞入整个文档。采用“Map-Reduce”策略先将文档分割成块让LLM对每块进行分析Map再将各块的分析结果汇总总结Reduce。利用外部存储将重要的历史信息、知识片段存入向量数据库。当需要相关上下文时通过检索增强生成RAG的方式只检索最相关的部分注入当前上下文。陷阱三工具调用错误处理缺失问题Agent调用的外部API可能失败网络超时、权限错误、资源不存在。如果缺乏错误处理整个工作流会崩溃。解决方案在每个工具函数内部进行完善的异常捕获和日志记录。返回给Agent的结果应包含明确的状态成功/失败和错误信息。在Agent的Prompt中可以教导LLM“当工具返回错误时根据错误信息判断是重试、跳过还是向用户请求帮助。”陷阱四无限循环与成本失控问题Agent在复杂决策中可能陷入“思考-行动”的死循环或者因为规划不当而执行大量不必要的工具调用产生高昂的API费用。解决方案设置硬性限制在Agent Executor中强制设置max_iterations最大迭代次数和max_execution_time最大执行时间。精细化工具描述在工具的描述中清晰界定其用途和适用场景帮助LLM更准确地选择工具。成本监控与告警在应用层面集成成本监控对单次会话的Token消耗和工具调用次数设置阈值告警。7.2 进阶方向从能用到好用当你掌握了基础工作流后可以朝这些方向深化评估与优化如何衡量你的AI应用的效果建立评估体系包括准确性提取的信息是否正确、相关性回答是否切题、稳定性格式错误率、成本平均每次请求的Token花费和延迟响应时间。基于数据持续迭代Prompt和Workflow设计。RAG检索增强生成集成对于需要依赖特定知识库如公司内部文档、产品手册的应用将向量数据库检索与LLM生成结合。当用户提问时先从知识库中检索最相关的片段再将片段和问题一起交给LLM生成答案能极大提高答案的准确性和针对性。复杂Agent模式探索多Agent协作系统。例如一个“分析师”Agent负责分解问题和规划一个“研究员”Agent负责搜索和收集信息一个“写手”Agent负责润色报告。它们通过消息队列或共享状态进行协作可以处理更宏大的任务。可观测性与调试为你的AI工作流添加详细的日志记录记录每一次LLM调用输入/输出、工具调用、中间状态。使用像LangSmith这样的专门平台可以可视化地追踪整个链或Agent的执行过程快速定位问题节点是开发复杂应用的利器。回过头看AI、LLM、Prompt、Function Calling、Workflow、Agent、MCP这七个名词恰好勾勒出了一条从底层能力到上层应用的清晰路径LLM提供核心智能Prompt和Function Calling是控制与扩展其能力的直接手段Workflow和Agent是组织复杂任务的高级范式而MCP则是连接AI与广阔工具世界的标准化桥梁最终这一切都服务于实现具体的AI应用目标。别再孤立地学习它们了把它们看作一套组合拳理解它们在工作流中各自扮演的角色和相互间的衔接关系你就能系统地设计并实现出真正强大、实用的AI应用。