AI Agent框架级开发实战课程 - 第一部分 & 第二部分

所有权：朱元禄

第一部分：前言

各位同学，大家好，欢迎来到《AI Agent框架级开发实战》课程。

我们这门课，有一个非常明确的定位：实战。一切内容的设计，都是为了对接企业的实际业务，以项目最终能落地为导向。

那企业是以什么为导向呢？是市场需求。市场需要什么，企业才会去开发什么产品。只有抓住了真实的需求，产品才有市场，我们今天要讨论的“AI化产品”也不例外。它不能是空中楼阁，必须能解决实际的问题，为企业带来真正的价值。

所以，在我们撸起袖子写代码之前，我们必须先搞清楚一个核心问题：AI能力，在企业的IT化建设中，到底能提供什么？ 它扮演的是一个什么样的角色？

(切换PPT)

第二部分：企业AI建设需求的演变

企业的AI需求，并不是一成不变的。它是随着大模型本身能力的边界的扩展而不断演变的。我们可以清晰地划分出几个阶段。

(PPT上出现一个时间轴图示，伴随讲解逐步展开)

timeline
    title 企业AI建设需求演变
    section 阶段一：Function Calling
        初级交互 : 大模型聊天机器人
                  : 通过IT手段扩展能力
                  : 应用与模型紧密耦合
    section 阶段二：厂商封装API
        能力扩展 : 厂商提供内置工具API
                  : 降低提示词工程成本
                  : 产生厂商锁定问题
    section 阶段三：MCP (Model Context Protocol)
        标准化 : 定义工具调用标准协议
                  : 应用与模型解耦
                  : 一套工具对接多模型

第一个阶段：Function Calling 时代

在大模型出现的前一两年，最先爆发的产品是什么？大家肯定都还有印象，就是各种各样的聊天机器人。网页版的、手机APP的，仿佛一夜之间，所有公司都在做“对话式AI”。

这个阶段的核心产品化能力，就是 Function Calling（函数调用）。

大家一定要记住，产品就是用来解决问题的产品。

在那个阶段，大模型本身的能力边界是受限的。它就像一个知识渊博但“四肢瘫痪”的专家，大脑很强，但没有手脚——它无法主动去查看网页、不能读取你的本地文件、也无法访问公司的数据库或远程API。

那怎么办？我们就用IT手段，为它打造“手脚”！这就是Function Calling。我们开发一个AI应用程序，作为用户和大模型之间的中间件。这个中间件负责理解用户的意图，然后替大模型去调用各种第三方工具API，拿到结果后，再整理好交还给大模型，最终生成一段流畅、准确的回答给用户。

(PPT上展示下图及其解释)

+----------------+      +----------------------+      +-----------------+      +---------------+
|                |      |                      |      |                 |      |               |
|    用户输入      | -->  |     AI应用程序        | -->  |     大模型       | -->  |  第三方API     |
|   “帮我订机票”   |      |   (中间件/代理)        |      |   (大脑)         |      | (航空公司官网)  |
|                |      |                      |      |                 |      |               |
+----------------+      +----------------------+      +-----------------+      +---------------+
        ^                                                  |                          |
        |                                                  |                          |
        |                  +----------------------+        |                          |
        +------------------|      整理结果并回复    | <--------+                          |
                           +----------------------+                          |
                                                                              |
                                                                              v
                                                                    +-------------------+
                                                                    |                   |
                                                                    |     返回航班信息    |
                                                                    |                   |
                                                                    +-------------------+

实操情景举例：智能旅行助手

1. 用户输入：“帮我下周六从北京飞上海，选早上的航班，经济舱。”
2. AI应用程序接收到指令，先调用大模型。
3. 大模型理解后，返回一个结构化指令：{"function": "search_flights", "parameters": {"from": "北京", "to": "上海", "date": "下周六", "time": "早上", "class": "经济舱"}}
4. AI应用程序根据这个指令，去调用第三方航班搜索API，拿到真实的航班列表。
5. AI应用程序再次将航班列表交给大模型，说：“这是找到的航班，请用友好、清晰的方式整理给用户，并建议一个最优选。”
6. 大模型生成最终回复：“为您找到了以下航班：1. CA1501, 08:00起飞… 其中CA1501时间最优，建议您选择。”

大家看，在这个流程里，AI应用程序与大模型进行了多次交互，并调用了外部工具。这就是第一阶段最典型的落地模式。

但是，这样做有一个巨大的逻辑问题：开发成本和维护成本极高。

• 繁琐的提示词工程：每次调用大模型，我们都要传递复杂的system prompt（系统提示词），比如“你是一个旅行助手，你要遵守以下规则：1… 2…”。我们要在提示词里保证逻辑严谨，加入大量的约束说明。
• 代码成为“屎山”：整个应用的逻辑控制、状态维护、错误处理全都堆砌在这个AI应用程序里。它既要懂业务，又要懂如何和大模型沟通，还要懂如何调用第三方API。逻辑耦合度非常高，版本迭代和功能升级变得异常困难，代码最终会变成难以维护的“屎山”。

第二个阶段：厂商封装API时代

很快，大模型厂商（比如OpenAI）发现了这个问题。他们开始在模型内部封装一些通用的能力，比如代码解释器、文件读取、网页浏览等，然后以标准API的形式提供给开发者。

这样一来，我们的AI应用程序就不用再写那么复杂的提示词去教模型“怎么使用工具”了，直接调用厂商提供的内置工具API就行。这确实降低了提示词工程的成本，简化了开发流程。

但新的问题又出现了：碎片化和厂商锁定（Vendor Lock-in）。

每个大模型厂家提供的这些工具API都不一样！OpenAI的是一套，Anthropic的是一套，国内的大模型又是另一套。如果你想让你开发的AI应用同时支持多个模型，你就得写多套适配代码，这简直是噩梦。

(切换PPT，时间轴指向现在与未来)

第三个阶段：MCP (Model Context Protocol) - 当前的最优解

那么，有没有一种方法，既能享受到Function Calling的灵活性，又能避免“屎山代码”和厂商锁定的问题呢？

有！这就是我们当前阶段最重要的解决方案：MCP（Model Context Protocol，模型上下文协议）。

MCP的核心思想是“标准化”和“解耦”。

1. 标准化：它定义了一套通用的标准协议，规定了“工具”（Tools）应该长什么样、如何被发现、如何被调用、如何返回结果。无论是读取文件、查询数据库还是调用天气预报API，只要它们按照MCP的标准来封装，就是一套统一的接口。

2. 解耦：它将AI应用程序（Agent）、大模型（LLM） 和工具（Tools） 彻底分离开。

   • 工具端：只需按照MCP标准实现自己的功能，不用关心是哪个模型或哪个应用来调用它。
   • 应用/Agent端：只需学会如何与MCP服务器通信，就能调用所有符合标准的工具，无需再关心工具的具体实现细节。
   • 模型端：主要提供推理能力，它只需要理解MCP传来的标准化工具描述即可。

(PPT上展示MCP架构图)

+----------------+     +--------------------+     +------------------+     +---------------+
|                |     |                    |     |                  |     |               |
|    大模型        |     |    AI应用程序       |     |   MCP服务器        |     |   工具们        |
|   (OpenAI,     |     |     (你的Agent)     |     |   (工具管理中心)     |     | (文件, SQL,     |
|   Claude, ...) |     |                    |     |                  |     |   API, ...)   |
|                |     |                    |     |                  |     |               |
+----------------+     +--------------------+     +------------------+     +---------------+
        ^                      ^                           |                          |
        |                      |                           |                          |
        |       标准化对话       |       标准化工具调用协议      |                          |
        +----------------------+                           +--------------------------+

这样一来，带来的好处是颠覆性的：

• 一套工具，多模型通用：你今天用OpenAI写的工具，明天可以无缝切换给Claude使用。
• 生态繁荣：你可以像搭乐高一样，组合使用来自全球开发者提供的MCP工具，快速为你的Agent赋能。
• 专注核心逻辑：你的AI应用程序不再需要处理乱七八糟的工具调用细节，可以更专注于业务逻辑和决策本身。
• 彻底解决“屎山”：架构清晰，维护和扩展性极大提升。

但是，同学们，MCP也只是一个过程，而非终点。

技术的演进永远不会停止。随着多模态、自主智能体（Autonomous Agent）等技术的发展，未来一定会有更高效、更强大的解决方案出现，来解决新的、我们目前还没遇到的需求和挑战。

而正因为如此，理解MCP背后的“解耦”和“标准化”思想，比学会使用MCP本身更加重要。这是架构设计的核心，能让你无论面对什么新技术，都能快速理解并将其融入你的系统。

课程实践预告

所以，在我们理解了企业AI演进的脉络和当前的最优解之后，从下一节课开始，我将带领大家，使用Python从0开始，亲手搭建一个具备MCP能力的AI Agent平台。

一旦这个平台搭建完成，你就可以像拥有了一把万能钥匙，可以轻松地开发出各种各样的AI产品，无论是智能客服、数据分析助手还是AI编程伴侣，都不在话下。

好了，我们下课休息一下，接下来进入动手环节！