AI技术发展与企业落地探析

AI应用开发入门：从Prompt、RAG到MCP，再到落地应用全景

一、技术组件：AI应用开发的核心积木

这一部分按数据流顺序展开：用户提问，文档被处理，检索相关内容，模型理解并生成，最后通过工具与外部系统对接。每个组件都回答三个问题：它是什么，为什么需要，在哪个环节起作用。

1.1 Prompt提示词工程

Prompt 位于模型生成环节，是你发给模型的指令，包括任务、背景、约束和输出格式。同一个模型，提示词不同，效果可能差很远。原因是模型在根据上下文预测下一个词，你给的信息越清楚，它越不容易跑偏。

坏例子是只写一句“帮我写代码”。模型不知道语言、框架、输入输出和异常处理要求，只能自由发挥。好例子会写成：“你是后端工程师，用 Python 写一个订单查询接口，要求支持分页、参数校验、超时重试，返回 JSON，并给出单元测试。”角色、上下文、格式、验收标准都有了。

常用技巧有三个。Few-shot 是给两三个输入输出示例，让模型照着学；输出格式约束是要求“只返回 JSON，字段为 id、name、score”，方便程序解析；思维链是让模型先列步骤再给结论，适合复杂推理，推理模型则可以简化这一步。业务里，用这套方法让模型把客服对话整理成工单字段，比一句“总结一下”稳定得多。

1.2 文档切片（Chunk文本分块）

文档切片位于数据准备阶段。长文档不能直接塞给模型。上下文窗口有上限，硬塞会截断；即使放得下，太多无关内容也会分散注意力，增加成本和延迟。切片就是把文档拆成一段段适合检索和放入 Prompt 的小块。

切片大小没有绝对标准。中文场景可以从 300 到 800 字开始，按标题、段落、条款等自然边界切，重叠 10% 到 20%，避免一句话被切断。重叠部分是相邻块之间的“缓冲带”，让跨块的语义不至于丢失。

业务例子：一份 200 页的员工制度手册，按章节切成“考勤”“年假”“报销”等块，每块带上部门、版本、生效日期等元数据。员工问年假时，系统只召回相关章节，而不是把整本手册发给模型。

1.3 Embedding文本向量化

Embedding 位于检索链路的入口，负责把文字变成一串数字向量。可以把它想成一张语义地图：意思相近的句子，坐标靠得近；意思差得远，坐标离得远。模型通过大量文本训练，学会了这种“意思上的距离”。

它解决的是关键字检索的局限。用户搜“年假能休几天”，文档里写的是“带薪休假”，字面没有“年假”两个字，传统关键字匹配可能找不到；向量检索比较的是语义，能把这两句话关联起来。

业务例子：HR 知识库里有“员工连续工作满一年可享受带薪年休假”的条款，用户问“入职多久有年假”，Embedding 能把问题和条款映射到相近位置，召回正确内容。常见模型有 bge、text-embedding 系列，选型时要关注中文效果、维度、成本和是否需要本地部署。

1.4 向量知识库与向量检索

向量知识库位于检索环节，用来存向量和元数据，并支持“找最相似的几条”。传统 MySQL 用 LIKE '%年假%' 查的是字面包含，向量库比较的是向量距离，底层通常用 HNSW、IVF 等近似最近邻索引来加速。

常见工具一句话带过：Milvus、Qdrant 是向量数据库，FAISS 更像向量检索库，适合自己搭建检索层。选型时看数据量、过滤条件、权限、运维成本和是否需要混合检索。

检索流程很直接：用户问题变成向量，在向量库里找距离最近的 Top-K 个文档块，再按元数据过滤，比如只查当前部门和有效版本。业务例子：把 10 万条客服 FAQ 存进向量库，用户问“退款多久到账”，先召回 20 条相关问答，再交给下一步处理。

1.5 Rerank重排

Rerank 位于向量检索之后、拼 Prompt 之前。向量检索追求快，通常是“问题一个向量、文档一个向量，各算各的”，所以叫粗排。它可能召回 100 条结果，但真正最相关的未必排在第一。Rerank 就是把问题和候选文档放在一起，逐条打一个更精细的相关性分数，再重新排序。

粗排负责“别漏”，精排负责“排准”。Rerank 慢一些，但只处理少量候选，整体成本可控。业务例子：用户问“试用期有没有年假”，向量检索同时召回“年假规定”和“试用期规定”，Rerank 能把同时包含两个条件的条款顶到最前面，减少模型答非所问。

1.6 RAG检索增强生成

RAG 位于知识型问答的生成前环节，把前面的组件串成一条链路：用户提问 → 问题向量化 → 向量检索 → Rerank 重排 → 取最相关的几个文档块拼进 Prompt → 大模型基于这些材料生成回答。

它主要解决三个问题：模型不知道企业私有数据，训练数据有截止日期，以及容易一本正经地编造。RAG 把“知识”放在外部，模型负责理解和组织语言，答案还可以附上来源，从而降低幻觉。

业务例子：员工问“出差住宿标准是多少”，系统从财务制度里召回对应条款，模型回答“一线城市每晚 600 元，需提前审批”，并给出文档链接。要注意，RAG 的效果上限由检索质量决定，检索不到、切得乱、文档过期，模型再强也答不好。

1.7 对话记忆管理

对话记忆位于每次模型调用之前。模型本身不会记住上一轮对话。每次调用 API，它都是无状态的，所谓“记忆”，是你把历史对话重新塞回 Prompt 里。

实现方式很朴素：维护一个消息列表，把用户和助手的历史消息按顺序带上。窗口快满时，常见做法是截断最早的消息、保留最近几轮，或者把早期对话压缩成一段摘要，再继续对话。

业务例子：用户先说“帮我查订单 12345”，几轮后问“那它什么时候到”，系统需要把订单号从历史里带出来。如果直接截断，模型就不知道“它”指什么。记忆管理就是在成本、连贯性和信息完整度之间做取舍。

1.8 对话状态管理

对话状态位于业务流程控制层。它回答的是“现在进行到哪一步”，而不是“之前说过什么”。记忆是对话内容，状态是业务进度。状态通常存在 Redis 或数据库里，用状态机或槽位填充来维护。

业务例子：智能工单系统里，用户说“我要报修”，状态机知道下一步该问地点；用户回答“三楼会议室”，状态变成“待填故障描述”；再问“空调不制冷”，状态变成“待确认联系方式”；信息齐了才创建工单。

把状态和记忆分开，好处是可控。模型可以负责理解用户说了什么，但是否进入下一步、能不能提交，由业务状态机决定。这样即使模型偶尔理解错，也不会把流程带乱。

1.9 Function Calling函数调用

Function Calling 位于模型与外部系统之间，是让模型在需要时输出一个结构化的调用指令，而不是直接编答案。模型不执行函数，它只告诉你“该调哪个函数、参数是什么”，真正执行的是你的代码。

完整流程是：用户问“杭州今天天气怎么样” → 模型判断需要查天气 → 返回函数名 get_weather 和参数 {"city":"杭州"} → 你的后端调用天气接口 → 把结果喂回模型 → 模型组织成自然语言回答。

这里有两个工程重点。第一，参数要校验，不能模型给什么就信什么；第二，权限要控制，查天气可以自动执行，退款、改地址这类操作必须加确认。业务例子：客服机器人查物流，模型只负责发起查询，真正的订单权限和数据过滤仍在后端完成。

1.10 Tool Calling工具调用

Tool Calling 位于工具接入与执行层。Function Calling 和 Tool Calling 经常被混用。简单说，Function Calling 是模型输出“调用哪个函数、传什么参数”的能力；Tool Calling 是更完整的工具接入框架，除了调用，还包括工具注册、鉴权、重试、超时、权限和审计。

维度	Function Calling	Tool Calling
本质	模型输出结构化的函数名和参数	一整套工具接入、执行和治理机制
范围	单次函数调用动作	注册、鉴权、重试、权限、日志
关系	底层能力	上层工程体系，可以包含 Function Calling

业务例子：查订单是一个 Function Calling，但企业级客服系统还要判断这个坐席有没有权限查该订单、接口超时怎么重试、失败怎么转人工，这些属于 Tool Calling 的范畴。

1.11 MCP（Model Context Protocol）

MCP 位于工具与模型之间的协议层。它是模型上下文协议，用一套标准方式让模型连接外部工具和数据源。它把“工具提供方”和“模型使用方”解耦：工具方实现一个 MCP Server，模型侧通过 MCP Client 连接，按约定发现和调用工具。

为什么需要它？以前每接一个系统，就要为它写一套 Function Calling 适配；有 N 个模型、M 个工具，可能要维护 N×M 套对接。MCP 像 USB 接口，工具按标准暴露能力，模型侧按标准接入，复杂度变成 N+M。

它和 Function Calling 的关系是：MCP 是上层协议，底层仍然可以靠 Function Calling 让模型选择工具。业务例子：公司把数据库、日历、内部工单系统各封装成 MCP Server，助手接入一次，就能查数据、约会议、建工单，不用为每个模型重写适配器。要注意，MCP Server 的权限就是调用者的权限，必须做最小授权和审计。

1.12 Agent智能体

Agent 位于应用编排层。普通问答是“你问一句，我答一句”；Agent 是“给我一个目标，我自己拆步骤、调工具、看结果、继续做，直到完成”。它的核心是一个循环：规划 → 执行 → 观察 → 反思 → 再规划。

业务例子：让 Agent 自动生成周报。它先查数据库拿到本周订单和故障数，再调用统计工具算环比，然后按模板写文案，最后调用邮件接口发给主管。中间某一步失败，它要能重试或向人求助。

Agent 的核心组成是规划、工具调用、记忆和执行。工程上最难的不是“让它会调工具”，而是“让它知道什么时候停、什么时候该问人”。长任务误差会累积，发邮件、下单、改数据这类动作必须加人工确认和回滚机制。

1.13 模型API封装服务

模型 API 封装服务位于业务代码与模型供应商之间。直接在大模型 API 外面再包一层，几乎是所有生产系统的标配。原因很简单：你需要统一入口，而不是让每个业务代码都直接持有密钥、各自处理超时。

封装层通常做这些事：多模型路由，简单问题走小模型，复杂问题走大模型；密钥管理，密钥只存在服务端；限流和配额，防止某个业务把额度打满；日志和追踪，记录请求、响应、耗时和成本；缓存，相同问题直接复用；降级，主模型超时就切备用模型。

业务例子：主模型接口超时，网关自动切到备用模型，同时记录一次降级事件，用户几乎无感知。没有这层封装，故障时只能改代码、重新发版。

1.14 SFT有监督微调

SFT 位于模型定制环节，是用自己的输入输出数据继续训练模型，更新模型权重，让它学会特定任务、风格或输出格式。它和 RAG 解决的不是同一类问题：RAG 补知识，SFT 调行为。

需求	优先 RAG	优先 SFT
知识经常更新	是	否
私有文档问答	是	可作为辅助
固定输出格式、语气、流程	先试 Prompt	是
标注数据少	是	否
成本	较低	较高

业务例子：律所希望模型固定输出“结论、依据、风险提示”三段式，且语气严谨。如果只是格式问题，Prompt 加 few-shot 可能就够了；如果大量样本都要求这种风格，且 Prompt 稳定性不够，才考虑 SFT。微调贵在数据标注、GPU 和迭代周期，RAG 便宜但受检索质量影响，别把两者当替代关系。

1.15 多模态解析模块

多模态解析位于数据进入系统的入口。多模态是指模型不只能读文字，还能“看”图片、PDF、表格和扫描件。多模态解析模块负责把这些非结构化内容转成可处理的文字或结构化字段，再交给 RAG 或模型直接回答。

常见链路是：PDF 或图片 → OCR 识别文字 → 版面分析还原表格和段落 → 抽取关键字段 → 进入知识库或业务系统。扫描件先用 OCR，复杂图表和版式可以再用视觉语言模型理解。

业务例子：员工拍一张发票上传，系统 OCR 识别发票号、金额、税额，抽取模块把字段填进报销单，规则引擎校验抬头和税号，最后自动提交审批。这里 OCR 负责“看见字”，多模态理解负责“看懂这张票是什么”。

二、应用产品：用上面的积木能搭出什么

同样的组件，换个组合方式，就是不同的产品。下面拆解八类常见应用，重点看它们用了哪些积木、解决什么问题、典型用户是谁。

2.1 智能问答系统（通用对话助手）

核心组件是 Prompt 工程、对话记忆管理和对话状态管理。它解决通用知识问答、闲聊和信息检索，不依赖企业私有知识库。

典型用户是普通消费者、开发者，以及需要日常信息处理的办公人群。业务例子：用户先问“帮我解释一下什么是幂等”，再问“那在订单接口里怎么实现”，系统靠对话记忆理解“那”指的是幂等，靠状态管理判断当前处于技术问答模式。它的能力边界也很清楚：通用知识强，但问公司内部制度就答不了。

2.2 知识库问答系统（RAG知识库）

核心组件是文档切片、Embedding、向量检索、Rerank 和 RAG。它解决企业私有文档问答，比如制度、产品手册、技术文档、售后政策。

典型用户是员工、客服、销售和外部客户。业务例子：员工问“年假怎么休”，系统从 HR 文档里召回“带薪年休假”条款，Rerank 把最相关的段落顶到前面，模型再总结成“入职满一年可休 5 天，需提前在系统提交申请”。答案最好带原文链接，方便核对。

2.3 AI客服与智能工单系统

核心组件是 RAG 知识库、对话状态管理和 Function Calling。它解决重复咨询自动回复、工单自动分类和简单问题直接处理；RAG 负责回答政策问题，状态管理负责推进流程，Function Calling 负责查订单、查物流、查退款进度。

典型用户是电商、SaaS 和本地服务商的客服团队。业务例子：用户问“我的退款到哪了”，系统先识别意图，调用订单接口查到退款状态，再回答“已原路退回，预计 1 到 3 个工作日到账”；遇到规则冲突或用户情绪激烈，转人工。AI 处理重复问题，人处理例外和关系。

2.4 AI内容生成平台（文案、报告、PPT生成）

核心组件是 Prompt 工程、RAG 和多模态解析。它解决营销文案、周报、PPT 初稿和长文档摘要的生产效率问题；Prompt 控制文体、长度和结构，RAG 参考历史素材和品牌规范，多模态解析把图片、表格、旧文档转成可用的输入。

典型用户是市场、销售、运营和咨询顾问。业务例子：销售拜访完客户，把录音转写和几张现场照片丢进系统，平台参考公司产品手册和历史案例，生成一份包含客户痛点、推荐方案、下一步动作的拜访纪要，销售修改后直接发邮件。

2.5 多模态应用（图文理解、图文生成）

核心组件是多模态解析模块和 Embedding。它解决图片理解、图片生成、以图搜图和图文混排内容生产；解析模块负责看懂图片和版面，Embedding 负责图文跨模态检索，把图片和描述映射到同一语义空间。

典型用户是电商商家、设计师和内容平台。业务例子：商家上传一张产品图，系统识别材质、款式、颜色和适用场景，再生成商品标题和卖点描述；用户上传一张沙发照片，系统在图库里找相似款，返回同款或替代品。生成图片和生成文案是两条链路，前者用扩散模型，后者用语言模型。

2.6 智能OCR识别系统

核心组件是多模态解析模块和 RAG。它解决扫描件、票据、证件、合同的文字识别与结构化提取；OCR 负责把图片文字识别出来，RAG 负责结合业务规则做校验和补全，比如发票抬头必须和公司名一致、税号必须匹配。

典型用户是财务、行政、法务和物流公司。业务例子：员工上传发票，系统识别发票号、金额、税额和开票日期，自动填入报销系统；如果抬头不在公司白名单里，直接打回并提示原因。OCR 解决“识别”，RAG 和规则解决“这张票能不能报”。

2.7 智能质检系统（工业视觉应用）

核心组件是多模态视觉模型、目标检测和 RAG。它解决产线产品缺陷自动检测、替代人工目检的问题；视觉模型负责看图片或视频，目标检测定位缺陷位置，RAG 把质检标准、历史缺陷案例和处置建议提供给模型或质检员。

典型用户是制造业产线、质检部门和设备厂商。业务例子：PCB 板焊点检测，摄像头拍下板面，模型标出虚焊、连锡、偏移等缺陷，系统按质检标准判断等级，并把相似历史案例推给质检员复核。产线对时延要求高，模型通常部署在边缘设备，而不是走云端。

2.8 AI报表生成与智能数据分析平台

核心组件是 Function Calling、RAG 和对话状态管理。它解决自然语言查数据、自动生成报表和数据异常解释；Function Calling 负责查数据库或调用报表接口，RAG 提供指标口径和业务解释，状态管理记住用户当前分析的是哪个时间段、哪个区域。

典型用户是运营、产品、销售和管理层。业务例子：运营问“上周销售额为什么降了”，系统先查上周和上上周的销售额，再按渠道、品类拆解，发现是某个渠道退款率上升，最后给出“建议核查该渠道的售后政策”的结论。这里必须用只读账号、SQL 校验和权限控制，不能让模型直接执行高危查询。

从 Prompt 到 RAG，再到 MCP 和 Agent，这些积木并不神秘。真正决定一个 AI 应用能不能落地的，往往不是模型多强，而是有没有把切片、检索、状态、权限和降级这些工程细节做扎实。