07 AI产品架构-AI组件与产品落地关键点

引言

AI产品从“能不能做”到“做得好不好”，关键就在架构。尤其在大模型时代，如何合理搭建AI组件，完成业务场景的智能化落地，是每一个产品设计者的必修课。

本篇我们就以电商智能客服为例，拆解AI产品的关键组件，并讲清楚这些组件之间是如何配合运作的。

先看一下典型的客服需求：商品介绍、售后投诉、订单查询……还要支持多语言、带情绪、有记忆。要做好这件事，背后离不开大模型各项能力的协同运作。

理清AI组件的“剧组分工”

我们常听到的大模型组件，像提示词（Prompt）、智能体（Agent）、工作流（Workflow）、函数调用（Function Calling）、上下文协议（MCP）、检索增强（RAG）、微调（Fine-tune）……它们不是“技术黑话”，而是AI剧组中各有分工的角色。

提示词 Prompt

简单理解就是用来指导大模型进行内容生成的指令。

一般分为两种：系统提示词和用户提示词。

系统提示词主要作用是模型的“底层设定”或“角色说明书”。一般定义模型的身份、行为准则、上下文、任务目标、输出格式、风格偏好等基础框架。

用户提示词是用户向模型发出的具体指令、问题或请求。在系统提示设定的框架内，告诉模型在当前时刻需要做什么、回答什么或生成什么内容。

系统提示词一般会以结构化的方式呈现，存在不同提示词框架(CRISPE、RCRWI)、方法(角色法、细节法、示例法、推理法、迭代法)、模板(LangGPT、AutoGPT、CO-STAR)。

前者是导演，设定舞台和规则；后者是演员，负责台词与动作。

智能体 Agent

简单理解是一个能感知环境、自主规划决策并执行动作以完成特定目标的大模型应用单元。

核心在于其自主性（能独立思考和行动）、目标导向性（有明确任务目标）和工具使用能力（可调用API、函数、搜索等）。

大模型是它的决策中枢，一并集成了规划模块（拆解目标、制定步骤）、记忆模块（存储任务上下文和经验）、工具调用模块（执行具体操作）。

是舞台上的主角演员，不仅能念台词，更能自己看剧本、走位、拿道具，甚至临场发挥完成整场戏。

工作流 workflow

简单理解是将复杂任务分解为一系列有序、可自动化执行的步骤。

在大模型应用中，用于串联多个模型调用（可能使用不同提示词或模型）、函数调用、外部工具、人工审核等环节。

是导演手中的分镜头脚本和拍摄计划表，精确规定了每个场景（步骤）的顺序、衔接和内容要求。

函数调用Function Calling

简单理解是大模型根据用户请求，**理解意图后自己调用预定义好的外部工具、API或内部函数的能力。

模型不直接执行操作，由外部系统执行并返回结果。核心作用在于突破模型固有边界，实现与真实世界（数据库、计算、API服务）的实时交互，增强实用性。

是演员（模型）递交给场务（外部系统）的精准道具需求单，场务按单准备好后，演员才能继续表演。

大模型上下文协议MCP

简单理解它就是一种通讯协议，目的就是更加方便、安全的完成Function Calling。

原本演员（模型）每次都要把请求写在纸上递交给场务（外部系统），现在只需要通过统一对讲机指令就行。

RAG (Retrieval-Augmented Generation)

首先重点说明下，RAG不是知识库。很多人一说到RAG就把它和知识库等同起来了，这是不对的。

按照翻译它就是“检索增强生成”技术。它在生成答案前，先从外部数据中检索相关信息片段，并将这些信息与用户问题一起提供给大模型。

核心目的是**利用大模型强大的理解和生成能力，结合现有数据，生成更准确、信息丰富的回答，同时减少模型“幻觉”。

是演员（模型）在回答刁钻问题前，先让助理（检索器）快速查阅资料库（知识源）找到参考书页，再结合自身学识（模型参数知识）进行作答。

微调

简单理解是利用特定领域或任务的数据集，在预训练好的大模型基础上进行额外的有监督训练。

目的是让模型更适配特定任务（如客服对话、法律文书生成、医疗报告解读）、符合特定风格（如品牌语气、学术严谨）、或掌握新知识/技能（预训练后出现的新信息或特有流程）。

不同于提示词工程（外部引导），微调是调整模型内部的权重参数，实现更深层次的能力改变。常见技术包括：全参数微调、LoRA、QLoRA等参数高效微调技术。

是对演员（模型）进行针对性的角色特训和技能深造，使其能完美演绎某一类特定角色（任务）。

各组件之间关系

简而言之：用户通过提示词（台词和规则）发起任务，智能体（主角演员）在工作流（分镜脚本）的指引下行动。遇到需要外部信息或能力时，根据MCP（通讯协议）借助工具，或利用RAG（助理查资料）获取知识。如果演员水平不够，还要定期拉去培训(微调)，这样才能更好胜任演出。

各组建在产品架构中落地

接下来我们看看这些技术组件，是如何组合落地到一个智能客服产品中去的。

为什么选客服智能系统？因为它有天然的AI适配性。

行业价值

2022-2027年中国智能客服市场将维持增长态势，预计到2027年将达到90.7亿，复合增长率达到22.6%。

可以完成基础的人力替代，客服由于流动性高，导致招聘成本和培训成本高。如果客服提升能力可能成为收益部门，那更是一次增长机会。

行业现状与痛点

行业现状:每天处理1万次咨询，但 60%需要人工介入。但是只有40%的业务解决率，依然有大量场景不能直接处理。

行业发展态势

• 2000-2010年：基于关键词精准匹配的伪智能客服。
• 2011-2015年：基于规则匹配智能客服，具备了初步的多渠道交互能力机械智能。
• 2016-2022年：基于非生成式AI驱动，使用NLP+ML等AI技术融合客服。
• 2023-至今：进入大模型驱动阶段，出现智能客服新范式。

大模型能力结合

由于技术底座发生变化，大模型的语言理解、思考能力与知识工程技术，使得服务范式发生变革。

引入了Ask Human Help，用户体验得以重构，安全风控也得到增强。

需求分析

客服场景大致分为两类：查询类（查订单、查规则、查物流）与办理类（退换货、取消订单、投诉处理），还有闲聊类作为“隐性转化场景”。

进一步抽象后，我们这样落地：

1、当用户发起交互后，AI系统首先要做的就是完成意图识别，可以作为一个单独Agent。

2、接着将每个业务场景都抽象为单独的Agent(业务查询Agent，业务答疑Agent等)。

3、查询类业务需要基于RAG来完成，数据源包含：企业知识库和系统数据库。通过企业私域知识提升回答的准确率。如果没有命中，接入Ask Human Help或转人工。

4、办理类业务把每个业务流程转化为工作流。

5、在查询类和办理类Agent中如果与第三方API(数据库，内部系统接口，外部服务接口)遵循Function Calling或MCP来完成。

6、每个场景Agent定制化各自结构化提示词Prompt，其中非业务场景直接通过提示词完成，只要设定好人设与背景、输出限制，闲聊也能带来转化率。

架构搭建

根据上面的分析，我们可以抽象为下面这个局部核心业务架构图：

这样我们就把技术组件：Prompt、MCP/FC、RAG、Agent等与实际的业务场景结合，完成最终的业务落地架构。

注意图中最关键的一环：Ask Human Help。

这不是传统意义上的“转人工”，而是一次可被学习的“人工协作片段”。

它是在知识库无法做出解答时，触发一个特殊请求。这个请求需要人工处理，但是人工是与AI交互，交互完后仍由AI完成最后的回复，这个交互过程被纳入RAG流程管理。

也就是说Ask Human Help后，AI智能客服系统就具备了回答此类问题后续的能力。AI客服不是“被动进化”，而是“边干边学、持续成长”的活系统。

这里没有对微调进行阐述是因为微调相对独立，后续会单独介绍微调的应用场景。

小结：构建不是堆料，落地才是硬道理

纵观全文，我们从提示词设定、Agent设计、工作流编排、函数调用与协议标准化、再到RAG检索增强与微调训练，串起了一条完整的AI产品架构路径。

这些组件看似独立，实则是一个闭环生态：

• Prompt 编排了“脚本”；
• Agent 赋予了“意图”；
• Workflow 编排了“行为”；
• FC/MCP 方便了“行动”；
• RAG 提供了“知识”；
• Fine-tune 重塑了“性格”。

把这些组件用在对的地方，让它们能各司其职、协同运作，服务于一个真实的业务目标。

AI不是一堆堆砌的能力，而是一场能力与场景之间的深度对齐；当技术真正理解了业务，才有了成为产品的资格。