AI 应用演进：从基础调用到自主智能体

从"对话式工具"到"战略级伙伴"的范式革命

AI 技术面世以来，各行业都在开始应用这项技术，涌现出了许多不同的应用场景。而随着应用场景的不断增多，AI 技术的应用层模式也在不断演进。

这篇文章主要介绍 AI 技术的应用层模式演进-从基础调用到自主智能体。 对于涉及到的技术点不会深入的展开，只是简单的介绍一下，让没有接触过 AI 技术的群体能理解 AI 技术的应用层模式演进， 对于已经尝试过 AI 技术应用的人也能有一定的参考价值。

名词解释

• LLM (Large Language Model)：大模型，指的是参数规模较大的 AI 模型，比如 GPT-3、ChatGLM 等，可以把不同的模型看作是拥有不同知识、技能的人， 有些人的知识量比较庞大，有些人在特定领域非常擅长，有些人思考靠推理、有些人思考靠直觉。
• 模型参数：是模型的权重和偏置，模型的参数数量越多，模型的能力越强， 可以简单理解为模型参数就是知识点，知识点越多，这个模型的能力就越强，也就越"聪明"。
• Prompt：是用户输入的文本，通过精心设计的文本（称为"提示"或"指令"）来引导大语言模型生成符合预期输出的系统性方法。

技术演进脉络

1. 基础调用

最早常见的 AI 技术应用场景比较简单，主要是利用大模型既定的能力进行一些简单的任务，比如文本生成、文本分类、文本摘要等。这类应用场景的模式比较简单，就是直接调用 LLM 的 API，将输入数据发送给 AI 技术，然后获取 AI 技术的输出结果。

这个流程的本质是：提供给 LLM 一个 Prompt，然后 LLM 会根据这个 Prompt 生成一个回答。

上述的形式只能实现一问一答的场景，并不能实现多轮对话。基础LLM本身不具备长期记忆能力，其上下文窗口仅支持短期对话状态维持，每次调用大模型时，都是独立的，不会记住之前的对话内容。

为了实现多轮对话，需要在基础调用的流程中中增加一个服务层，用来维护用户的上下文信息。当用户输入新的问题时，服务层会根据用户的上下文信息，把用户的问题和上下文信息拼接起来，形成一个新的 Prompt，然后再把这个 Prompt 交给 LLM 模型进行处理。

第一轮对话： "我是一个素食主义者， 请提供一份早餐菜单" -> LLM -> xxxx

第二轮对话："我还需要一份午餐菜单" -> 上下文拼接（我是一个素食主义者， 请提供一份早餐菜单，我还需要一份午餐菜单） -> LLM -> xxxx

通过服务层上下文的维护，LLM 模型就可以根据用户的上下文信息，生成符合预期的回答。

2. RAG 检索增强

因为 LLM 模型的训练数据是固定的，LLM 的回答是基于既定模型参数推理的，受限于 LLM 模型的模型参数，当询问实时的天气数据或遇到知识边界时，它会基于训练数据的模式(算法)进行"猜测"，产生「我知道这个问题」的"幻觉"，编造一些不存在的知识。

针对这种问题，可以从两个方面来解决：

• 优化模型：增加模型的参数数量，扩大模型的知识边界范围，让模型更加 "聪明" 。
• 检索增强（RAG）：引入外部知识，比如数据库、文档、知识库等，进行多模型交叉验证，总的来说就是当模型发现无法处理的问题时能够检索外部的知识从而生成更准确、时效性强的答案。

本文不涉及模型层面的太多内容，就不展开讲模型优化层面了

接入 RAG 的应用需要在服务层访问外部知识库进行检索，当获取到知识库的内容后再在服务层进行 Prompt 拼接，然后把包含了专业知识的 Prompt 交给 LLM 模型进行处理。

例如：用户输入："请提供深圳落户政策"，服务侧会根据用户输入的问题类型，选择深圳落户相关的知识库进行检索，当获取到知识库的内容时，会把用户输入的问题和知识库的内容拼接起来，形成一个新的 Prompt，然后再把这个 Prompt 交给 LLM 模型进行处理。

LLM 模型会根据这个 Prompt 生成一个回答，回答中会包含了用户输入的问题和知识库的内容， 这就是 RAG 的基本原理。

上面只是为了简单的介绍一下 RAG 的基本原理，实际的应用场景中服务层为了识别客户端指令是否需要检索外部知识库、需要哪些外部知识库，还需要有一个解析层对输入文本在语义层面上进行识别匹配。

意图识别层通常采用轻量级模型，比如 BERT、RoBERTa 等，它的任务是通过关键词检索，匹配输入文本的语义层，根据匹配结果来选择不同的知识库进行检索。

3. Function Calling

上述解决还是纯内容处理的能力，只能做单纯的内容生成与理解，而 Function Calling 则是 通过大模型强大的处理能力，将用户的输入转换为函数调用，然后根据函数调用的结果，生成用户期望的输出。

例如当询问 "深圳现在的天气" 时，解析层会识别到这是一个获取实时天气信息的任务，就会主动调用天气查询 API 对应的函数，获取并返回深圳的天气数据。

解析层不仅能够识别到是否需要使用 RAG 能力， 还能够区分出是否调用函数，以及函数的参数， 例如 "深圳现在的天气" 这个问题， 在识别到需要调用天气的函数后，会回到函数列表中寻找到合适的函数，并把把 "深圳" "现在" 这样的参数传给函数。 最终函数返回的结果返回给服务层，服务层可以选择直接响应给客户端还是拼接 prompt 后传给 LLM 拼接成统一的响应格式后通过服务端响应给客户端。

Function Calling 解决了大模型应用只能对用户的输入进行简单的处理，就像是为大模型增加了一双手，让大模型除了思考还能处理各种事务，但是 Function Calling 开发中也遇到了很多问题：

1. 解析层为了找到需要调用函数，需要在解析层初始化的时候就注入所有的函数描述，当函数数量增加时，解析层的初始化成本就会增加，并且当函数描述发生变化时需重新部署服务，灵活性不够。
2. 工具数量增加时，需将全部函数描述注入提示词，导致 Token 消耗激增、模型理解能力下降。
3. 对于需要对接多个大模型的场景，每个大模型的函数调用能力是不同的，需要根据不同的大模型，注入不同的函数描述，迁移时需重新适配。
4. 函数调用的延迟比较高：
   • 每个函数调用都需要等待服务层的响应， 当函数数量增加时， 延迟就会增加。

除了上述比较明显的问题，Function Calling 还有一些安全性、调用性能等问题。

4. MCP 协议

MCP (Model Context Protocol) 模型上下文协议, 提供了一种更加通用的跨模型的调用协议， 可以在不同的模型之间进行调用， 并且可以在不同的模型之间进行切换。

MCP 定义了统一的调用接口，就像 USB 接口一样允许各种外设即插即用，无论是简单的读取本地文件，还是复杂的支付链路处理，都能通过统一的 "插座" 组合完成。

MCP 包含了四个部分：

1. 主机（Host）：主机是期望从服务器获取数据的人工智能应用，例如一个集成开发环境（IDE）、聊天机器人等。主机负责初始化和管理客户端、处理用户授权、管理上下文聚合等。
2. 客户端（Client）：客户端是主机与服务器之间的桥梁。它与服务器保持一对一的连接，负责消息路由、能力管理、协议协商和订阅管理等。客户端确保主机和服务器之间的通信清晰、安全且高效。
3. 服务器（Server）：服务器是提供外部数据和工具的组件。它通过工具、资源和提示模板为大型语言模型提供额外的上下文和功能。例如，一个服务器可以提供与Gmail、Slack等外部服务的API调用。
4. 基础协议（Base Protocol）：基础协议定义了主机、客户端和服务器之间如何通信。它包括消息格式、生命周期管理和传输机制等。

以电商客服为例：

1. 用户输入： → Host：用户问"订单 123 为什么没发货？"
2. 意图解析： → LLM 判断需调用 订单查询工具→ MCP Client 从 Nacos 拉取订单 MCP Server 地址 。
3. 协议转换： → MCP Client 生成请求：{"method": "get_order_status", "params": {"order_id": "123"}}。
4. 工具执行： → MCP Server 调用内部订单 API → 返回 {status: "已发货", tracking_no: "SF987654"}。
5. 结果整合： → LLM 生成响应："订单已发货！物流单号：SF987654"→ Host 渲染结果 + 物流链接
6. Host 响应："订单已发货！物流单号：SF987654"

每个 MCP Client 对应一个 MCP Server， 每个 MCP Server 对应多个工具，多个资源, MCP Client 可以获取到对应 MCP Server 中包含的所有工具和资源，上述电商客服的流程中 MCP Client 能够获取到 MCP Server提供的订单相关的工具函数，当需要商品相关的业务时， 就可以添加对应的商品MCP Client 和 MCP Server 并在 host 添加 商品 MCP Client 信息。

在 Trae、Cursor、Claude Desktop 中提供了添加 MCP Server 的能力， 这个时候 Trae 、cursor、Claude Desktop 充当了 MCP Host 的角色， 而 MCP Client 则是内部在编辑中，通过注册的 MCP Server 就可已获取到 MCP Server 提供的工具了。

MCP解决工具调用的标准化问题，极大的减少了多模型，多工具链的开发运维成本，但是总的来说，不管是 MCP 协议还是 Function Calling 解决的都是基于用户既定流程的能力编排， 用户依旧需要处理碎片化的 AI 能力，然后对于 AI 的结果进行综合处理最终做出决策。在使用 AI 的过程中用户依旧需要投入许多精力。

5. AI Agent

AI Agent（人工智能代理）是一种能够自主感知环境、决策并执行任务的智能系统。MCP解决工具调用的标准化问题，而AI Agent解决任务自主决策与复杂协作问题。二者的关系如同"手与脑"------MCP是连接万物的"手"，提供操作能力；AI Agent是统筹规划的"脑"，赋予系统自主性和智能性。

AI Agent通过感知-规划-行动-学习的闭环，赋予MCP系统主动决策与协作能力

他可以解决：

1. 复杂任务拆解与动态规划。 例如对于问题：「降低公司运营成本」, agent 可以拆解为子任务（"分析财报→识别冗余部门→优化采购流程"），并动态调用对应的MCP工具（财务数据库+供应链API）。
2. 多工具协同与上下文贯通。通过会话ID（Session ID） 贯穿多工具调用链，自动传递关键参数（如订单ID、客户信息等），确保信息连贯性。
3. 闭环学习与自适应优化。基于执行结果动态调整策略，例如若航班查询失败 → 自动重试或切换交通方式。

端到端工作流示例（旅行规划场景）​​

1. 用户输入： → "规划东京5日游，包含浅草寺和迪士尼，预算5000元"。
2. Agent 规划： → 拆解任务：航班查询 → 酒店预订 → 景点路线生成。
3. MCP 工具调用： •发现工具：通过 Nacos 查询 flight_search、hotel_booking • 执行请求：MCP Client 发送 JSON-RPC 调用航班 API • 返回结果：{航班号: JL123, 价格: 1200元}
4. 上下文更新：→ MCP 持久化航班信息，剩余预算更新为 3800元。
5. 循环执行：→ 酒店查询工具自动获取航班抵达时间，避免冲突预订 。
6. 结果生成：→ Agent 整合数据输出行程 PDF + 预算明细表。

AI Agent 就像是人类的大脑，已经能够根据用户的输入，拆解任务，调用对应的 MCP 工具，并根据工具的返回结果，整合数据，输出最终的结果。但是从本质上讲，依旧停留在"工具执行层" 的范畴，只能对特定场景（客服、推荐系统）进行任务拆解和执行，对于任务也是线性执行的， 对于执行操作的指令也需要内置在 MCP server 中，AI Agent 就像是一个不成熟的人类大脑，对于风险预测，自主发现机会这类"战略决策"能力上存在短板。

6. Agentic AI

Agentic AI 是一种人工智能类别，专注于能够自主决策和执行任务而不需要人工干预的系统。 他可以协调多个 AI Agent 自动拆解复杂目标， 并且通过持续学习和分析外部数据及复杂数据集来做出决策。

Agentic AI 的实现需要基于 5 个功能模块：

1. 感知模块（Perception）: 捕获环境信息（用户输入、传感器数据、API 返回），转化为结构化数据。
2. 记忆模块（Memory）: 存储当前任务状态和历史经验与知识库。
3. 规划模块（Planning）: 基于当前状态和目标，生成执行计划（如序列任务、并行子任务）。
4. 行动模块（Action）: 根据计划调用 MCP 工具执行任务，处理工具返回结果。
5. 反馈模块（Feedback）: 从执行结果中学习经验，不断优化策略（如强化学习、迁移学习）。

典型的工作流如下：

总结

AI 应用的发展经历了多个阶段，从简单的和 LLM 对话，到 Agentic AI 自主智能体，遵循了 ​​"基础设施→工具化→场景+自主化" 的规律。

演进本质：从"感知智能"到"行动智能"的跃迁

阶段	核心突破	关键使能技术	企业价值
基础调用	语义理解与生成	提示工程+上下文窗口扩展	人工替代（如文案生成）
RAG	知识实时性与准确性	向量检索+重排序模型	知识库问答（合规审查）
Function Calling	连接数字世界	API封装+参数提取	流程自动化（订单查询）
MCP	工具生态标准化	协议统一+动态服务发现	开发效率提升10倍
AI Agent	任务闭环执行	ReAct框架+记忆管理	全流程自动化（招聘管理）
Agentic AI	跨域协同决策	多Agent博弈共识+自主进化	战略级优化（供应链降本20%）

最后

通过这篇文章希望可以从 AI 应用模式的演进上给需要了解 AI 的小伙伴一些指导， 对于像 prompt 工程、RAG 能力搭建、长期记忆能力、agent 搭建这类的细节知识后续会持续输出，希望大家持续关注。