1. 从名词到工作流为什么你学AI总是“乱”如果你最近也在关注AI尤其是大语言模型LLM和智能体Agent那你一定和我有同感信息太杂了。今天刷到一个“Prompt工程速成”明天又看到“手把手教你搭建AI Agent”各种框架、工具、概念层出不穷学了半天感觉什么都懂一点但真到动手做个东西时却不知道从哪里开始或者做出来的东西总感觉差点意思像个玩具。这就是典型的“乱学”。问题不在于你不够努力而在于你学的是一堆孤立的“点”却没有一根清晰的“线”把它们串起来。AI应用开发尤其是基于LLM的智能应用本质上是一套完整的工程工作流。不理解这个工作流你就不知道每个技术名词比如Prompt、Agent、SubAgent在这个流程中扮演什么角色应该在什么时机使用以及它们之间如何协作。今天我们不谈那些虚头巴脑的“未来趋势”就从一个一线开发者的视角把这套工作流拆解给你看。你会发现当你把这7个核心名词LLM、Prompt、Function Calling、Agent、SubAgent或Workflow、工具Tools、评估Evaluation放到一个连贯的流程里理解时一切都会变得清晰、可操作。这不再是零散的知识点而是一张可以按图索骥的“作战地图”。2. 核心工作流全景图七步构建可用的AI应用在深入每个名词之前我们必须先建立全局观。一个典型的、从想法到落地的AI应用构建流程可以概括为以下七个环环相扣的步骤定义任务与选择模型LLM明确你要用AI做什么并据此选择合适的大模型作为“大脑”。设计并优化指令Prompt Engineering告诉“大脑”具体怎么思考和工作这是驱动模型产出的核心。赋予模型行动能力Function Calling让“大脑”不仅能说还能调用外部工具如查数据库、发邮件来做事。构建智能调度中枢Agent创建一个能自主理解目标、规划步骤、调用工具并持续执行的智能体。实现复杂任务分解SubAgent / Workflow对于复杂任务设计多个专门化的子智能体或定义明确的工作流来协同完成。集成外部能力Tools为智能体配备各种“手脚”扩展其能力边界使其能操作真实世界的数据和系统。验证与迭代优化Evaluation建立评估体系确保应用效果可靠、可控并持续改进。这个流程不是线性的而是一个螺旋上升的循环。接下来我们逐一拆解每个环节我会结合具体场景和代码示例告诉你“是什么”、“为什么”以及“怎么做”。2.1 第一步基石——理解并选择你的“大脑”LLMLLM大语言模型是整个工作流的基石是所有智能的源头。你可以把它理解为一个博览群书、经验丰富但“手无缚鸡之力”的顾问。它的核心能力是理解和生成文本。关键认知没有“最好”的模型只有“最适合”的模型。你的选择取决于三个核心因素任务类型是创意写作、代码生成、逻辑推理还是信息提取成本预算GPT-4能力强大但昂贵Claude 3在某些长文本任务上表现出色而开源的Llama 3、Qwen 2在成本可控的前提下也能达到不错的效果。数据隐私与延迟要求敏感数据可能需要本地部署的私有模型。实操建议起步阶段直接使用OpenAI的GPT-3.5-Turbo或GPT-4的API。它们稳定、易用是验证想法原型的绝佳选择。不要一开始就陷入开源模型部署的泥潭。深入阶段当你的应用场景和Prompt逐渐稳定后可以开始测试不同模型的表现。例如使用Llama 3 70B处理复杂的分析任务或用Qwen 2的128K长上下文版本处理超长文档。避坑指南不要盲目追求参数规模。一个精心设计的Prompt在70B模型上的表现可能远胜于一个粗糙的Prompt在千亿参数模型上的表现。模型是引擎Prompt才是方向盘。2.2 第二步方向盘——用Prompt Engineering驾驭模型选好了“大脑”下一步是学会如何给它下指令这就是Prompt Engineering。很多人把它等同于“写几句聪明的提示词”这太片面了。Prompt工程的核心是用结构化的上下文和信息将模糊的用户需求转化为模型可精确执行的具体任务。一个高效的Prompt通常包含以下几个部分角色Role赋予模型一个特定的身份如“资深数据分析师”、“严格的内容审核员”。任务Task清晰、无歧义地描述你要它做什么。上下文Context提供完成任务所需的背景信息、参考数据。输出格式Format明确指定输出的结构如JSON、Markdown、特定段落。示例Few-shot提供一两个输入输出的例子让模型快速掌握你的要求。示例一个糟糕的Prompt vs. 一个专业的Prompt糟糕的“总结一下这篇文章。”专业的你是一位科技专栏编辑擅长提炼核心观点。请基于以下文章内容生成一份摘要。 【要求】 1. 用中文输出。 2. 摘要需包含核心问题、作者的主要论点、文中提到的关键证据或数据、结论。 3. 以“本文探讨了...”开头总字数控制在200字以内。 【文章内容】 [这里粘贴文章正文] 【输出示例】 本文探讨了人工智能在医疗影像诊断中的应用与挑战。核心论点是...关键证据包括...最终结论认为...我的实操心得不要把Prompt当作一次性的魔法咒语来调。把它当作一个可调试、可版本化的“配置代码”。我习惯用一个YAML或JSON文件来管理复杂任务的Prompt模板将角色、指令、格式拆分成不同的字段这样迭代起来非常清晰。另外有一个小技巧在指令中明确告诉模型“逐步思考”Think step by step或“让我们先推理一下”往往能显著提升复杂推理任务的准确性。这不是玄学这相当于激活了模型的“链式思考”能力。2.3 第三步赋予双手——Function Calling让模型“动起来”LLM本身是封闭的它不知道今天的天气不能查询你的数据库也不能发送邮件。Function Calling函数调用就是这个破壁的关键。它允许你定义一套工具函数的说明书名称、描述、参数格式然后模型在对话中可以根据需求主动请求调用某个具体的工具。工作流程开发者定义一组工具例如get_weather(city: str),search_database(query: str)。在调用LLM时将这些工具的描述作为系统Prompt的一部分传给模型。用户提问“北京和上海的天气怎么样”LLM理解后不会直接生成天气而是输出一个结构化的请求如{name: get_weather, arguments: {city: 北京}}。你的程序接收到这个请求实际执行get_weather(北京)函数拿到真实数据如{city: 北京, temp: 22°C}。你将这个真实数据作为新的上下文再次发送给LLM“用户问了天气你刚才让我调用了get_weather结果是北京22°C请组织语言回答用户。”LLM生成最终回答“北京今天的天气是22摄氏度晴朗。”为什么这至关重要它让AI从“聊天机器人”变成了“能够操作数字世界的智能体”。所有的工具集成、API调用都是通过这个机制实现的。OpenAI、Anthropic Claude、Google Gemini等主流模型都支持类似的功能。2.4 第四步智能中枢——Agent自主规划与执行当你把LLM大脑、Prompt指令集和Function Calling双手结合起来一个能自主行动的Agent智能体就诞生了。Agent的核心特征是自主性和目标导向性。一个典型的Agent运行循环ReAct模式Reason Act如下观察Observe接收用户输入或当前环境状态。思考Think基于目标、历史记录和可用工具决定下一步该做什么是直接回答还是调用某个工具。行动Act执行决定如果是调用工具则通过Function Calling执行。观察结果Observe获取工具执行的结果。循环重复“思考-行动”步骤直到任务完成或达到终止条件。示例一个旅行规划Agent目标“为我规划一个为期三天的上海之旅。”Agent的思考过程思考1用户需要旅行规划。我需要知道用户的偏好预算、兴趣和出行日期。我应该先提问。行动1直接输出问题“您的旅行预算是多少对历史、美食还是现代艺术更感兴趣”用户回答后思考2用户提供了信息。现在我需要获取上海的景点信息。我有search_attractions工具。行动2调用search_attractions({city: 上海, interest: 历史})。思考3我收到了景点列表。接下来我需要把这些景点安排到三天的行程里并考虑地理位置和开放时间。我可以调用generate_itinerary工具。行动3调用generate_itinerary({...})。思考4行程已生成。我还需要查询那几天的天气以便给用户建议。调用get_weather。行动5整合所有信息生成最终建议回复给用户。框架选择你可以从头构建这个循环但更高效的是使用框架。LangChain和LangGraph是当前最流行的选择。LangChain提供了构建Agent所需的大量组件和模板而LangGraph特别擅长描述具有复杂循环和状态依赖的Agent工作流用图的方式来定义控制流非常直观。2.5 第五步处理复杂性——SubAgent与工作流分解当单个Agent的任务过于复杂时让它自己“想”所有步骤会变得低效且容易出错。这时我们需要引入SubAgent子智能体或工作流Workflow的概念。这本质上是“分而治之”的思想。SubAgent模式创建一个“主Agent”作为协调者它将大任务分解成子任务然后分派给不同的、功能专一的“子Agent”去执行。例如一个“内容创作团队”可以有“选题Agent”、“调研Agent”、“写作Agent”、“润色Agent”。工作流模式以更工程化的方式预先定义好一个任务的固定步骤和规则。每个步骤可能调用不同的工具或LLM。这更适合流程稳定、确定性高的任务。像Dify、Flowise这类低代码平台主要采用的就是可视化工作流的方式。两种模式的取舍SubAgent动态规划灵活性高能处理未知或变化的任务。适合探索性、创意性强的场景。缺点是控制流复杂调试难度大。工作流静态编排确定性高执行路径清晰易于调试和监控。适合标准化、自动化的业务流程。缺点是灵活性差任务稍有变化就可能需要修改工作流。我的经验对于企业级应用我倾向于混合模式。用确定性的工作流处理核心业务主线例如客户工单处理的标准步骤而在工作流的某个节点中嵌入一个负责“决策”或“创意”的SubAgent来处理其中不确定的部分例如根据工单内容判断应归属哪个部门。这样既保证了主干流程的稳定又保留了应对复杂情况的灵活性。2.6 第六步能力扩展——为Agent配备“工具箱”Agent的强大与否很大程度上取决于它有多少可用的工具Tools。工具就是Agent与外部世界交互的接口。常见的工具类型包括搜索工具联网搜索SerpAPI、向量数据库检索。API工具调用企业内部系统CRM、ERP、第三方服务发送邮件、短信、生成图片。计算工具执行代码Python REPL、计算器。数据工具读写数据库、处理Excel/CSV文件。工具设计的核心原则描述清晰工具的函数名和描述必须让LLM能准确理解其用途。例如“获取用户信息”就不如“根据用户ID从CRM系统查询客户姓名和最近订单”来得明确。功能单一一个工具只做一件事。这降低了LLM的理解难度也便于维护。安全可控特别是涉及写操作或敏感数据的工具必须在前端你的代码里设置严格的权限校验和参数过滤不能完全依赖LLM的判断。实操示例快速为Agent添加一个搜索工具使用LangChainfrom langchain.agents import Tool from langchain_community.utilities import SerpAPIWrapper # 1. 定义工具函数 search SerpAPIWrapper() def search_tool(query: str) - str: 一个用于回答关于当前事件或特定信息查询的搜索工具。输入应是一个具体的搜索问题。 return search.run(query) # 2. 包装成LangChain Tool对象 tools [ Tool( name网络搜索, funcsearch_tool, description当你需要回答关于近期事件或查找特定事实信息时使用此工具。输入应是一个明确的搜索查询。 ), # ... 可以添加更多工具 ] # 3. 在创建Agent时传入tools列表2.7 第七步确保可靠——系统的评估与迭代这是最容易被忽略但决定项目成败的关键一步。你怎么知道你的Agent工作得好不好不能只靠人工测试几个案例。你需要建立系统的评估Evaluation体系。评估分为几个层次单元测试针对Prompt/Function给定固定输入检查LLM输出或函数调用是否符合预期格式和内容。集成测试针对Agent流程模拟端到端的用户对话检查Agent能否正确完成多轮交互和工具调用。效果评估针对结果质量这通常是最难的。你可以结合基于规则的评估检查输出是否包含关键词、是否符合格式。基于模型的评估用另一个LLM如GPT-4作为“裁判”根据任务目标评估输出结果的相关性、准确性和完整性。人工评估在关键节点进行抽样人工审核。构建一个简单的自动化评估流水线构建测试集收集几十到上百个有代表性的用户查询输入和期望的理想输出或执行路径。运行Agent用测试集作为输入批量运行你的Agent记录下所有输出和中间步骤思考、工具调用。自动评分编写评分脚本。例如检查最终答案是否包含必要信息点规则或调用GPT-4来对比实际输出与期望输出的匹配度模型评估。分析报告生成评估报告找出常犯的错误类型例如总是错误调用某个工具、在某种输入下会陷入循环。迭代优化根据评估结果你就能有的放矢地改进是Prompt描述不清那就优化Prompt。是某个工具太难用那就重新设计工具接口。是Agent逻辑有漏洞那就调整其规划策略。评估是驱动整个工作流持续改进的飞轮。3. 实战串联构建一个智能客户支持助手让我们用一个完整的例子把上述七个步骤串联起来。目标是构建一个能处理用户产品咨询的智能助手。第一步选择LLM我们选择GPT-4因为它在理解复杂用户意图和生成友好回复方面表现更稳定。第二步设计核心Prompt我们定义系统Prompt赋予Agent角色和能力边界。你是一个智能客户支持助手“小助”。你的职责是帮助用户解答关于我们产品一款名为“智绘”的在线设计工具的问题。 【能力范围】 1. 回答关于产品功能、价格、使用方法的常见问题。 2. 如果用户问题涉及具体账户、订单或技术故障你需要引导用户提供必要信息如订单号并告知他们将转接人工客服。 3. 如果问题超出你的知识库请诚实告知“我暂时无法回答这个问题”并建议用户查阅帮助中心或联系人工。 【回答风格】专业、友善、简洁。第三步 第六步定义工具集我们为Agent配备几个关键工具search_knowledge_base(query): 在公司知识库可以是向量数据库中搜索相关文档。get_product_price(plan): 查询不同套餐如“基础版”、“专业版”的当前价格。create_support_ticket(user_id, issue_description): 当问题需要人工介入时自动创建工单。第四步构建Agent使用LangGraph来构建Agent的工作流。这个Agent的决策逻辑是用户提问。Agent首先判断问题类型普通咨询 or 需要人工。如果是普通咨询调用search_knowledge_base然后根据搜索结果生成回答。如果需要人工则调用create_support_ticket并生成回应告知用户工单已创建。如果无法判断或搜索无果则按照Prompt要求回复无法解答并给出建议。第五步处理复杂咨询引入SubAgent假设用户问“我想用‘智绘’为我的电商店铺设计一个‘双十一’主题的海报和详情页有什么建议吗” 这个问题涉及创意建议超出了知识库检索的范围。这时主Agent可以将其识别为“创意咨询”子任务并激活一个专门的**“设计顾问SubAgent”**。 这个SubAgent拥有不同的Prompt“你是一名资深电商设计师...”和工具集例如search_design_trends(keyword),generate_draft_idea(theme, industry)。它处理完这个子任务后将建议返回给主Agent由主Agent整合后回复用户。第七步评估与迭代单元测试测试get_product_price工具是否总能返回正确价格。集成测试模拟对话“专业版多少钱” - 应触发get_product_price并返回价格。效果评估收集100个真实用户问题让Agent处理同时由人工客服提供标准答案。用GPT-4作为裁判对比两者在“信息准确性”和“解决率”上的得分。根据得分低的案例分析是Prompt问题、工具问题还是Agent逻辑问题并进行针对性优化。4. 避坑指南与进阶思考走完整个流程你会发现学AI不再“乱”了。每个技术点都落在了它该在的位置上。最后分享几个我踩过坑才得来的心得不要过早优化在想法验证阶段用最简单的链Chain或最直接的Prompt快速做出原型看到效果。不要一开始就设计复杂的多Agent系统。LLM不是万能的它擅长理解和生成但在精确计算、事实核查、实时信息获取方面是短板。一定要用工具函数调用来弥补这些短板。永远不要相信LLM自己“算”出来的数学答案或“编”出来的实时信息。状态管理是难点在多轮对话中Agent需要记住历史。如何高效、准确地管理对话历史上下文避免无关信息干扰或丢失关键信息是需要精心设计的。通常需要设置合理的上下文窗口长度并学会做关键信息摘要。成本与延迟监控每一次LLM调用、每一次工具执行都有成本和耗时。在生产环境中必须密切监控这些指标优化Prompt以减少不必要的交互轮次对耗时长的工具调用考虑异步处理。可观测性至关重要你的Agent在线上是如何运行的它每一步是怎么“想”的调用了什么工具输入输出是什么你需要像监控传统软件一样为Agent系统建立完善的日志、追踪和监控体系。这不仅是调试的需要也是理解模型行为、发现偏见或错误模式的关键。AI应用开发正从“炼金术”走向“工程学”。掌握这套从LLM到评估的完整工作流就是掌握了这门新工程的蓝图。它不能让你一夜之间成为专家但能让你从此告别盲目和混乱每一步都走得清晰而坚定。剩下的就是在具体的项目中去实践、去踩坑、去积累了。这条路很长但方向对了就不怕远。