1. 什么是AI应用学习资料来源好比把知识放进一家图书馆进行管理。图书馆数据库标签向量数据库模糊查询管理员Rag定标签存放规则理解标签问答LLM先理解你说的话。假如你问他 “我腰疼怎么锻炼prompt提示词”LLM会理解你的意思然后进行Rag数据检索增强去向量数据库中寻找对应的资料再去数据库中把数据还原然后LLM再把收集的数据进行整理、加工返回给你C端和B端我们一般用的网页版Ai都是C端模型它的图书馆知识是很综合的都懂但是不精通。举例我能做前台小姐姐吗可以。但是我不够专业不够细节我要经过专业的培训再上岗。B端大模型就是经过专业训练后的前端小姐姐企业需要定制自己的图书馆数据安全、专业、个性化。1.1 AI 应用大致概念图书馆查询系统相当于就是AI应用的内核但是全是数据你可以理解为一个可调用SDK。后续配合使用java前端做出用户界面。Ai SDK Java前端 运维 Ai应用Java Vue 8k2. AI 应用目前的市场分类和技术分布纯生成类 (Generation)典型应用写小说、写周报、陪聊像 ChatGPT 刚出来时那样、AI 绘画。核心靠大模型“肚子里”原本训练好的知识。RAG 的作用不大。主要靠模型的创造力。知识检索类 (Knowledge Retrieval / RAG)典型应用智能客服、垂直领域问答医疗、法律、私有数据搜索。核心大模型 外部数据。现状这确实是目前市面上最赚钱、需求最大的部分。自主行动类 (Autonomous Agents)最牛逼的代码生成 Claude典型应用帮你订机票、自动写代码并运行、操作 Excel 生成图表、代替你回邮件。核心大模型 工具 (Tools) 规划 (Planning)。3. 买机票业务流程知识检索行动3.1 传统后端 vs. Agent 工程师谁在调 API传统后端工程师的工作任务“老板让我写个按钮用户点了就买票。”代码逻辑程序员把逻辑写死在代码里。if User_Click_Buy: call_flight_api()结论是程序员控制 API 调用。AI Agent 工程师的工作你要教的任务“老板让我做一个机器人如果用户想买票或者想改签它自己看着办。”代码逻辑程序员不写调用逻辑而是写**“工具说明书”**。你告诉大模型“我有这么一个买票的 API参数是日期和航班号。”结论是大模型LLM决定何时调用但代码是你写的。3.2 Agent工程师如何做这件事情当我们在做“调用购买机票 API”这个工作时Agent 工程师实际在写这三部分代码第一步封装工具 (The Wrapper)️你要写一个 Python 函数真正去执行 HTTP 请求。这部分和传统开发一样就是 requests.post…# 这是实际干活的代码 def buy_ticket(flight_number, date): print(f正在连接航司系统预订 {date} 的 {flight_number}...) # 这里写真正的 requests 请求 return {status: success, ticket_id: 888888}第二步定义描述 (The Schema) (最关键)你要写一段 JSON 或者字典用自然语言告诉大模型这个工具怎么用。这是 Agent 开发的精髓。# 这是写给 AI 看的“说明书” tools [{ type: function, function: { name: buy_ticket, description: 当用户明确表示要购买特定航班的机票时调用此工具, # 给 AI 的提示 parameters: { type: object, properties: { flight_number: {type: string, description: 航班号例如 CA1234}, date: {type: string, description: 起飞日期} }, required: [flight_number, date] } } }]第三步回路执行 (The Loop)你要写代码处理“大模型 - 你的代码 - 大模型”的闭环。大模型返回{call: buy_ticket, args: CA1234}你的代码抓到这个信号执行第一步的buy_ticket函数。你的代码拿到结果再喂回给大模型“票买好了票号是 888888”。大模型最终回复用户“搞定您的票号是 888888。”真实业务中的处理绝大多数所谓的“AI 买票”实际上 AI 只是完成了**“填表”的工作最后的“签字支付”**环节一定是由人来完成的。而不仅仅是玩具代码我们需要引入一个核心概念Human-in-the-loop (人机协同/人工介入)。在真实的 App比如携程、Expedia 的 AI 插件里流程是这样的❌错误的想象 (全自动)用户“帮我买票” - AI 默默调用扣款接口 - 手机收到扣款短信 - 用户惊恐“我还没确定时间呢”✅真实的逻辑 (人机协同)用户“帮我买票” - AI 调用接口查询 -AI 调用生成订单接口 (但不支付)- AI 返回一个卡片 (UI Card)给用户 -用户点击“确认支付”- 前端调用支付接口。我们在开发 Agent 时会对 API 工具进行风险分级。在 LangChain 等框架中专门有这种机制。我们可以教大模型“当你想要买票时不要直接买而是先请求用户的许可。”# 1. AI 决定要买票 action buy_ticket(flightCA1234) # 2. 系统拦截 (关键步骤) if tool_risk_level(action) HIGH: # 暂停程序向前端发送确认请求 user_confirmation ask_user_confirm(fAI 想要为您购买 CA1234金额 2000元是否批准) if user_confirmation YES: execute_tool(action) # 用户点头了才真的买 else: ai_reply(好的已取消购买请问还需要看其他航班吗) else: #如果是查天气这种低风险的直接跑 execute_tool(action)目前阶段知识库问答RAG是绝对的主流占比约 80%工具操作类Action是高阶的少数占比约 20%。知识库问答现在是市场主流技术是相通的知识库问答技术层面更加纯粹工具操作类ROI偏低4. 目前AI应用的类型分布目前阶段知识库问答RAG是绝对的主流占比约 80%工具操作类Action是高阶的少数占比约 20%。4.1 第一梯队纯知识库问答 (Pure RAG) —— 占比 70%场景企业内部文档搜索、政策法规查询、产品说明书问答、合同比对。动作只读Read-Only。AI 看了文档回答问题。为什么这么多安全绝不出错因为不涉及写操作。刚需每个公司都有一堆没人看的 PDF 和 Wiki想让 AI 盘活它。容易落地技术栈成熟LangChain 向量库开发周期短一周就能上线。课程地位这是基础必修课学员学会这个能解决大部分甲方的需求。4.2 第二梯队查询型 Agent (RAG Read-Only Tools) —— 占比 20%场景智能客服查订单状态、金融助理查实时股价、销售助理查CRM里的客户资料。动作调用 API但只是去查数据不修改数据。为什么在增长单纯的文档静态数据已经不够用了用户需要知道“我现在的”情况动态数据。风险依然很低查错了顶多报错不会损失钱。4.3 第三梯队行动型 Agent (Action / Write Tools) —— 占比 10%场景帮你买票、帮你发邮件、自动提交代码、自动操作 Excel 生成报表。动作写/执行Write/Execute。会对现实世界产生“副作用”。为什么这么少风险极高就像我们刚才讨论的买错票、发错邮件都是事故。成功率问题多步操作Chain of Thought容易断链一旦一步错后面全错稳定性不如传统软件。权限复杂企业不敢轻易把核心系统的写权限开放给 AI。5. Rag是什么RAG检索增强生成是一种AI 应用的架构模式。它规定了整个应用系统的组成部分检索器、知识库、LLM和数据流向先查再喂给 LLM。将 RAG 架构理解为对LLM 模型能力的外部增强。5.1 知识增强 (Augmentation) 问题解决解决了 LLM 自身的知识截止期 (Knowledge Cut-off)问题。增强效果RAG 将 LLM 的知识边界从**“模型训练的那一天”拓展到了“实时更新的企业数据库”**。价值体现只有通过 RAG您的 Agent 才能回答“公司最新的报销政策”或“今天上午的实时股价”。5.2 可信度增强 (Grounding) ️问题解决显著降低了 LLM 的幻觉 (Hallucination)风险。增强效果RAG 迫使 LLM 的回答**“有据可查”**。它不能凭空瞎编必须基于检索到的文档片段Source: Document A, Page 3来生成答案。价值体现提高了 Agent 的可靠性和可追溯性这在金融、法律、医疗等严肃行业是必须的。6. 主流大模型6.1 目前国产大模型的情况“如果要处理复杂的中文单据、扫描件、PDF 表格”首选Qwen-VL (通义千问)。它是目前国内最强的“眼睛”。“如果要私有化部署数据不能出公司”首选InternVL (书生)。它的开源版本极其能打只需几张显卡就能跑起来。“如果只是偶尔需要看个图主业还是对话”用 DeepSeek 或 GLM-4。这叫“够用党”性价比高。“如果要搞实时视频分析比如监控安防”目前建议观望或者使用Qwen-VL做抽帧分析但要做好延迟较高的心理准备。6.2 LLM多模态图片、文本、视频等等在开发 AI 应用特别是 Agent时多模态意味着你的应用不再仅仅处理文本 (Text)而是能同时处理图片 (Image)、视频 (Video)、音频 (Audio)甚至代码、表格等多种数据形态。输入端 (Input)“能看懂”用户发一张发票照片AI Agent 能自动识别出金额、税号并填到报销系统里。OCR LLM用户发一段监控视频AI Agent 能识别出“第 3 分钟有人摔倒了”并自动报警。Video Understanding输出端 (Output)“能表达”AI Agent 分析完数据后不再是给你一段干巴巴的文字总结而是直接生成一张信息图表 (Infographic)。AI 智能客服不再是用冷冰冰的文字回复而是生成一段仿真人的语音甚至是一个数字人视频来回答你。TTS AIGC Video现在的核心突破是一个大模型同时搞定所有事。比如Google Gemini 3 Pro或GPT-4o它们是原生多模态 (Native Multimodal)。这意味着你不需要先调用一个 OCR 模型把图转成字再把字喂给大模型。你直接把图片扔给大模型它自己就能看懂图里的内容、逻辑关系、甚至梗图的笑点。这让开发的复杂度降低了 10 倍不止。7. LLM在Ai应用中充当的角色是什么读懂人话把人话变成指令调度Ai应用工作再把数据整合成人话返回给用户。RAG和Agent架构中LLM 充当的角色是唯一的决策中心 (The Decision Center) / 大脑 (The Brain)。8. LLM Api目前全球所有的主流 LLM API包括豆包、GPT、Claude、Gemini都遵循一个事实上的行业标准OpenAI API Standard。这意味着它们的核心结构是高度相似的RESTful JSON 接口。{ model: gpt-4o, // 或 doubao-pro-32k messages: [ // 核心参数 1: 对话历史/Prompt {role: system, content: 你是一位专业的销售顾问。}, {role: user, content: 请分析我司产品的最新市场趋势。} ], temperature: 0.7, // 核心参数 2: 创造力/随机性 max_tokens: 4096, // 核心参数 3: 输出长度限制 tools: [...] // 核心参数 4: Function Calling/工具定义 }9. Prompt是什么用大白话讲Prompt 就是你给大模型下达的“作战命令书”或“剧本”。它不仅仅是“问一个问题”而是一整套指令、角色、上下文、数据和约束条件的集合。Prompt 的质量决定了 LLM 输出质量的 80%。9.1 实际业务中的 Prompt 长啥样(结构化是关键)在实际的 Agent 和 RAG 应用中Prompt 必须是高度结构化的以消除模糊性。它不再是一句话而是一个包含以下关键元素的模板。9.2 不同 LLM 之间的 Prompt 相似吗底层原理相似但格式和效果天差地别结论Prompt 必须根据模型进行微调。绝对不能把给 GPT 的 Prompt 拿去直接给 Claude 或 DeepSeek 用。为什么不同应用场景不一样。大模型擅长的点也不一样你跟销售和研发沟通技巧和话术能一样嘛[ { role: system, content: ( ### [ROLE] (核心要素 1: 角色与目标) ###\n 你是一位[在此处填写角色例如顶级的商业分析师/专业的中文翻译专家]。\n 你的首要任务是基于提供的上下文以[在此处填写风格例如简洁、专业、幽默]的风格完成任务。\n\n ### [Constraint] (核心要素 4: 约束条件) ###\n 1. 除非明确要求否则不得使用第一人称‘我’或‘我们’。\n 2. 在不确定或信息缺失时必须明确指出‘数据不足’并拒绝推理。\n [在此处填写额外的安全/语言/内容限制]\n ) }, { role: user, content: ( --- [Task] (核心要素 2: 任务指令) ---\n 请执行以下任务[在此处填写具体的操作指令例如对数据进行聚合分析并找出趋势]。\n\n --- [Context_Data] (核心要素 3: 上下文/数据) ---\n [在此处粘贴所有分析所需的数据例如RAG检索结果、CSV/JSON数据、历史对话记录]。\n\n --- [Output_Format] (核心要素 5: 输出格式) ---\n 你的最终输出必须且只能是一个JSON对象结构必须严格遵守以下 Schema 定义不要包含任何额外的解释或代码块标记\n [在此处粘贴 JSON Schema 或所需的 JSON 结构定义]\n --- [End_of_Prompt] --- ) } ]10. Function Call第一层什么是 Function Calling技术基石用大白话讲Function Calling 是让大模型从“只会说话的文科生”变成“能按格式填单子的理科生”的关键技术。它的本质不是“调用”而是“结构化输出”。没有 Function Calling 时你问“北京天气怎么样”大模型瞎编“北京今天风和日丽…” 它根本没联网纯靠瞎猜。有了 Function Calling 时你开发者提前交代“嘿我有一个查天气的函数get_weather(city)。”你问“北京天气怎么样”大模型大脑判断“这题我会我不瞎编了我输出一个指令{function: get_weather, args: {city: Beijing}}。”系统你的代码拦截到这个 JSON去真的调 API 查天气拿到“25度”。系统把“25度”喂回给大模型。大模型最终回答“北京今天 25 度。”11. MCPMCP并不是api本身而是相关api可以调度的资源是否支持这个协议有点像浏览器的W3C各个厂商明里暗里在斗。MCP (Model Context Protocol) 目前的状态是“雷声大雨点在局部”。谁是亲爹Anthropic (Claude)。他们是发起者所以支持得最好。谁在跟进IDE 开发工具界非常积极Replit、Cursor、Windsurf、Zed。因为这些工具需要读取你电脑里的代码、数据库MCP 简直是救星。开源社区狂热GitHub 上各种连接 Notion、Slack、Postgres 的 MCP Server 像雨后春笋一样冒出来。谁在装死OpenAI (ChatGPT)目前完全不支持。Microsoft / Google观望中主要推自己的生态。11.1 MCP 能推行下去吗W3C 战争重演你说的“W3C 浏览器大战”比喻非常精准。现在的局面是Anthropic (Claude) 当年的 Netscape/Firefox我想搞个开放标准MCP大家都能互联互通这样即便我的模型不是第一大家也离不开我的生态。OpenAI 当年的 IE / 现在的 Apple我有最强的用户基数ChatGPT我为什么要支持一个通用的 USB 接口我就要搞我自己的GPTs Action搞我自己的Assistants API。我要把你锁在我的“围墙花园”里你想开发插件只能适配我一家短期内 (1-2年)分裂。OpenAI 只要还是老大它大概率不会轻易支持 MCP。它希望所有的应用都长在它的平台上。所以你的学员出去工作可能还得写两套代码一套给 OpenAI一套给其他模型通过 MCP。长期看MCP 有机会赢但战场在“端侧”。MCP 最大的优势是本地化 (Local-first)。OpenAI 的 GPTs 必须把数据传到云端。MCP 可以让本地运行的模型比如 Ollama 跑个 Llama 3直接读取你本地的文件。随着“端侧 AI”手机、电脑本地 AI的爆发MCP 这种不需要上传隐私数据、直接插拔的协议生命力会非常顽强。11.2 MCP 到底是什么(核心定义)全称Model Context Protocol (模型上下文协议)发布方Anthropic (2024年底开源)一句话解释它是一套标准化的规范规定了“AI 模型”应该如何跟“本地或远程数据源”进行对话。没有 MCP 时你想让 Agent 读 MySQL你得写 Python 代码用pymysql库。你想让 Agent 读 Notion你得写代码调用 Notion API。痛点每个数据源都要写一套“胶水代码”无法复用。有了 MCP 时MySQL 官方提供一个 MCP Server。Notion 官方提供一个 MCP Server。你的 Agent 只要支持 MCP 协议不需要写一行针对 MySQL 或 Notion 的代码直接插上就能读数据、写数据。Client 发送{jsonrpc:2.0,method:tools/list,id:1}Server 回复{jsonrpc:2.0,result:{...},id:1}11.3 Mcp目前的支持程度模型层 (The Brain)它是支持的 ✅事实Gemini 3 Pro 的智商非常高如果您自己写一段 Python 代码作为 Host把 MCP 的工具定义转化成 Google 的 Function Calling 格式发给它它是能完美工作的。结论Google 的“脑子”是支持的。产品/生态层 (The Product)它是排斥的 ❌这是我说“不支持”的真正含义。什么是“原生支持”Claude (Anthropic)你下载 Claude 的官方桌面客户端修改一下配置文件就能直接连上 MCP Server。官方客户端自带 MCP Host 功能。Cursor / Trae你打开编辑器配置一下就能连。官方工具自带支持。Google 的现状是什么Gemini 网页版 / App完全没有地方让你配置 MCP。你不能让 Gemini 网页版去读你电脑里的本地文件。Vertex AI (Google 的开发平台)它推崇的是 Google 自己的“Extensions”标准。它希望你用 Google Drive API用 Google Search Extension而不是通用的 MCP。IDX (Google 的 AI 编辑器)目前也没有像 Cursor 那样大张旗鼓地集成 MCP。为什么 Google 态度冷淡(商业逻辑)总监这一段非常适合作为课程的“商业洞察”部分MCP 的本质是“去中心化”和“模型商品化”。如果 MCP 普及了所有的工具数据库、日历、SaaS都变成了通用的 USB 设备。用户会发现“既然工具接口都一样我今天用 Claude明天换成 Google后天换成 OpenAI只需要改一行代码。”这对谁有利对Anthropic (Claude)有利因为他是追赶者他希望打破壁垒。对开发者有利因为不被绑定。这对谁不利对Google 和 OpenAI不利。Google 希望你深度绑定在Google Cloud生态里。OpenAI 希望你绑定在GPTs生态里。他们不希望你“想换就换”。他们希望造**“围墙花园” (Walled Garden)**。形象的比喻Type-C 接口战争我们可以这样给学员比喻MCPType-C 接口通用标准。Claude安卓手机。原生就是 Type-C 接口插上就能用。Google / OpenAI早期的苹果手机 (Lightning 接口)。问苹果手机能读 U 盘吗答技术上能就像 Gemini 能跑 MCP。但在生态上苹果不仅不给你 Type-C 接口还故意弄这一套私有标准Lightning逼你买它的转接头把你在它的生态里锁死。12. 向量数据库向量数据库Vector DB和传统数据库如 MySQL/Postgres/MongoDB的核心区别在于它们存储的内容和查询的方式是完全不同的。我们可以用一个简单的比喻来区分传统数据库是一个文件柜️。你只能通过标签关键词、ID、日期来查找文件。向量数据库是一个大脑的语义空间。你问一个概念它会给你所有“意义上相似”的文件。为什么 RAG 必须用向量数据库传统数据库无法用于 RAG因为 LLM 需要的是语义而不是关键词。用户问“我想了解人工智能的未来。”传统 DB 搜索结果可能会返回一篇标题恰好包含“人工智能”的 10 年前的旧文章。向量 DB 搜索结果检索到的是语义上与“人工智能的未来”概念相似的文档片段比如关于“通用人工智能 (AGI) 的伦理讨论”或“最新 Transformer 架构”的报告。结论向量数据库是 RAG 架构中将人类的语言转化为AI 可理解的数学空间的核心组件。13. 什么是LangChainLangChain扮演的角色是LLM 应用的“操作系统”或“总指挥部”。它是一种编排框架 (Orchestration Framework)负责将 LLM您说的“大脑”与外部世界数据、工具、记忆连接起来并管理整个工作流程。A. 统一 LLM 接口 (LLM Unification)如我们之前所说不同的 LLM API 格式略有不同。LangChain 提供了一个统一的LLM类或ChatModel类无论是哪个厂商的模型你都可以用一套标准代码进行调用。B. 流程编排与工具管理 (Chains Agents) ⚙️这是 LangChain 最核心的功能。它将一系列操作例如检索 - 总结 - 翻译 - 发邮件串联起来Chains (链)用于固定的、线性的工作流比如 RAG先检索后总结。Agents (代理)用于动态的、非线性的决策。LangChain 负责执行ReAct 循环让 LLM 自己推理出要使用哪个工具Function Calling然后执行工具并将结果反馈给 LLM。C. 数据集成与 RAG 简化 (Data Integration) LangChain 提供了一整套简化 RAG 流程的工具箱文档加载器 (Document Loaders)读取 PDF、网页、CSV 文件。文本切割器 (Text Splitters)将长文档切分成适合 LLM 读取的片段。向量存储连接器 (Vector Store Integrations)轻松连接 Milvus、Pinecone 等向量数据库。
