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 = 8k

2. 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) 🔄

你要写代码处理“大模型 -> 你的代码 -> 大模型”的闭环。

1. 大模型返回：{"call": "buy_ticket", "args": "CA1234"}
2. 你的代码抓到这个信号，执行第一步的 buy_ticket 函数。
3. 你的代码拿到结果，再喂回给大模型：“票买好了，票号是 888888”。
4. 大模型最终回复用户：“搞定，您的票号是 888888。”

真实业务中的处理

绝大多数所谓的“AI 买票”，实际上 AI 只是完成了**“填表”的工作，最后的“签字支付”**环节，一定是由人来完成的。

而不仅仅是玩具代码，我们需要引入一个核心概念：Human-in-the-loop (人机协同/人工介入)。

在真实的 App（比如携程、Expedia 的 AI 插件）里，流程是这样的：

• ❌ 错误的想象 (全自动)： 用户：“帮我买票” -> AI 默默调用扣款接口 -> 手机收到扣款短信 -> 用户惊恐：“我还没确定时间呢！”
• ✅ 真实的逻辑 (人机协同)： 用户：“帮我买票” -> AI 调用接口查询 -> AI 调用生成订单接口 (但不支付) -> AI 返回一个卡片 (UI Card) 给用户 -> 用户点击“确认支付” -> 前端调用支付接口。

我们在开发 Agent 时，会对 API 工具进行风险分级。

在 LangChain 等框架中，专门有这种机制。我们可以教大模型：“当你想要买票时，不要直接买，而是先请求用户的许可。”

# 1. AI 决定要买票
action = "buy_ticket(flight='CA1234')"

# 2. 系统拦截 (关键步骤！)
if tool_risk_level(action) == "HIGH":
    # 暂停程序，向前端发送确认请求
    user_confirmation = ask_user_confirm(f"AI 想要为您购买 CA1234，金额 2000元，是否批准？")
    
    if user_confirmation == "YES":
        execute_tool(action) # 用户点头了，才真的买
    else:
        ai_reply("好的，已取消购买，请问还需要看其他航班吗？")
else:
    #如果是查天气这种低风险的，直接跑
    execute_tool(action)

目前阶段：知识库问答（RAG）是绝对的主流（占比约 80%），工具操作类（Action）是高阶的少数（占比约 20%）。

1. 知识库问答现在是市场主流
2. 技术是相通的
3. 知识库问答技术层面更加纯粹，工具操作类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. MCP

MCP并不是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. 短期内 (1-2年)：分裂。 OpenAI 只要还是老大，它大概率不会轻易支持 MCP。它希望所有的应用都长在它的平台上。所以你的学员出去工作，可能还得写两套代码：一套给 OpenAI，一套给其他模型（通过 MCP）。
2. 长期看：MCP 有机会赢，但战场在“端侧”。 MCP 最大的优势是本地化 (Local-first)。
3. OpenAI 的 GPTs 必须把数据传到云端。
4. MCP 可以让本地运行的模型（比如 Ollama 跑个 Llama 3）直接读取你本地的文件。
5. 随着“端侧 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 接口战争

我们可以这样给学员比喻：

• MCP = Type-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. 什么是LangChain

LangChain 扮演的角色是：

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 流程的工具箱：

1. 文档加载器 (Document Loaders)：读取 PDF、网页、CSV 文件。
2. 文本切割器 (Text Splitters)：将长文档切分成适合 LLM 读取的片段。
3. 向量存储连接器 (Vector Store Integrations)：轻松连接 Milvus、Pinecone 等向量数据库。