1. 初始AI模型交互与提示词演进

这是最基础的人机交互层面，解释了用户如何与AI沟通以及如何让AI更好地理解用户意图。

1.1 用户提示词

  • 定义：这是最直观的交互方式，即用户向AI提出的问题或指令（例如：“写一首关于夏天的诗”）。
  • 局限性：
    • A) 缺乏人设：AI不知道提问者的身份（是学生、老师还是程序员？），无法给出针对性回答。
    • B) 回答平庸：由于缺乏背景，AI倾向于给出最安全、最通用的回答，缺乏个性。
    • C) 无法区分上下文：即使是同一个问题，在不同的场景下可能需要不同的答案，但仅靠用户提示词无法传递这些信息。

1.2 系统提示词

  • 产生背景：早期为了给AI设定人设，用户需要将背景信息也写进问题里（例如：“你是一个专业的律师，请帮我看看这份合同…”），但这让对话显得很不自然。
  • 定义：为了解决这个问题，系统提示词被独立出来。它是一个隐藏的、由系统预设的指令，包含了AI的人设、性格、背景信息和回复语气。用户只需要发送自己的核心问题即可。
  • 机制：当用户发送消息时，系统会自动将预设的系统提示词附加在用户消息之前或一起发送给AI。这样，AI在回复时就知道该以什么角色、什么语气来回应，从而使对话更加自然流畅。
  • 应用场景：
    • 网页聊天机器人：开发者会在后台设置好系统提示词，用户无法直接看到或修改。
    • 自定义GPTs：在ChatGPT等平台上，用户可以自定义偏好（如“你是一位风趣的物理老师”），平台会自动将这些偏好转化为系统提示词的一部分，在后台发挥作用。

2. AI智能体及其工具

这一阶段，AI从“只会说”升级到“能够做”，通过工具与外部世界交互。

2.1 AI Agent的工具

  • 需求背景：基础AI模型只能提供文本答案或建议，无法自主执行实际操作（比如读取本地文件、发送邮件）。
  • 概念：
    • A) Agent：它是一个协调程序，充当AI模型、工具和用户之间的桥梁。
    • B) Agent Tool：提供给AI模型调用的具体功能，例如文件读写、网络搜索、计算器等。
  • 早期实践（AutoGPT示例）：
    • 架构：AutoGPT是一个在本地运行的程序。
    • 工具链：开发者需要预先编写好工具（如 list_files 函数），并注册到系统中，同时描述清楚它的功能和使用方法。
    • 系统提示词生成：AutoGPT会根据注册的工具信息，自动生成一个复杂的系统提示词，告知AI模型：“你现在可以使用以下工具，当你需要执行操作时，请严格按照格式返回指令。”
  • 任务流程：
    1. 用户请求：“帮我找一找电脑里周杰伦的歌目录。”
    2. 系统将用户请求和包含工具信息的系统提示词一同发给AI模型。
    3. AI模型理解请求，决定调用 list_files 工具。
    4. AutoGPT程序解析AI的返回，执行 list_files 函数。
    5. 函数执行结果（文件列表）被发送回AI模型。
    6. AI模型根据结果判断任务是否完成，如需进一步操作则继续循环，直至结束。

2.2 早期Agent架构的挑战

  • 核心不确定性：AI模型的输出本质上是自然语言，即使系统提示词要求它返回特定格式（如JSON），它也可能出错（比如返回了带有解释文字的JSON）。
  • 解决方案：当时的开发者常常通过让Agent自动重试来解决这个问题——如果AI返回的格式不对，就再问一次。
  • 现状：这种方式（如早期的Kline）增加了系统的不确定性和开发复杂度，稳定性较差。

3. 函数调用

为了解决早期Agent架构中AI输出格式不稳定的问题，大模型厂商推出了标准化方案。

3.1 Function Calling的提出

  • 背景：为了解决AI返回格式不确定的问题，OpenAI、Claude、Gemini等厂商推出了Function Calling功能。
  • 核心思想：统一规范。由模型厂商在模型层面定义一套标准，而不是让开发者在提示词层面“碰运气”。

3.2 Function Calling的机制

  • 工具描述标准化：
    • 工具不再用自然语言写在系统提示词里，而是用一个结构化的JSON对象来描述。
    • 这个对象包含了标准的字段：name（工具名）、description（功能说明）、parameters（所需参数，包括类型和描述）。
    • 这些JSON对象被存储在一个专门的字段中，与系统提示词分离。
  • AI返回格式规范化：
    • AI模型在内部经过了特殊训练，当它决定调用工具时，必须按照Function Calling规范返回一个结构化的数据对象，而不是自然语言。
  • 优化效果：
    • 工具管理变得集中、统一。
    • AI返回的调用指令格式统一，易于程序解析，无需复杂的正则匹配或重试逻辑。
    • 系统提示词不再需要包含复杂的格式说明，变得更加简洁、可读，专注于角色设定。

3.3 Function Calling的局限

  • 技术限制：这是一个由商业公司推动的功能，尚未成为所有模型的行业标准。
  • 兼容性问题：许多优秀的开源模型（尤其是早期版本或小参数模型）并未针对Function Calling进行训练，因此无法支持。
  • 现状：目前是“系统提示词+手动解析”和“Function Calling”两种方式并存，开发者需要根据所选模型的能力来选择方案。

4. MCP协议

这是解决Agent与Tool服务之间通信问题的“标准化语言”，也是当前AI互操作性发展的前沿方向。

4.1 MCP的诞生背景

  • 问题：假设有人开发了一个非常通用的“网页浏览器工具”，如果每个Agent开发者都要为这个工具写一套调用代码，就会造成巨大的重复劳动。
  • 解决方案：将工具服务化。把浏览器工具部署成一个独立的服务（MCP Server），统一托管起来，所有Agent都可以通过标准协议来调用它。

4.2 MCP定义与组件

  • 定义：MCP（模型上下文协议）是一个开放的通信协议，专门用于规范Agent（客户端）与Tool服务（服务器端）之间的交互方式。可以理解为AI界的“USB-C接口”。
  • 核心组件：
    • MCP Server：提供具体功能的服务器（例如：一个提供获取天气功能的服务器）。
    • MCP Client：需要调用这些功能的Agent程序。
  • MCP模块：协议详细规定了客户端和服务器如何握手、如何认证、如何传输数据。

4.3 MCP Server提供的服务类型

一个MCP Server不仅可以提供工具调用，还可以提供其他类型的服务：

  • Tool：可执行的操作（如：发送邮件、计算）。
  • Resource：可访问的数据或资源（如：获取数据库中的用户列表）。
  • Prompt：为Agent提供预设的提示词模板，帮助Agent更好地完成任务。

4.4 MCP的服务方式

Agent通过MCP协议建立连接，通过标准化的API（应用程序接口）调用来使用MCP Server上的Tool、Resource或Prompt。

4.5 MCP与AI模型的关系

  • 重要影响：MCP是AI基础设施的重要组成部分。它让AI模型的能力不再局限于自身，而是可以接入整个数字世界。
  • 影响：它不仅影响AI的使用方式（让应用更强大），也影响AI的开发方式（开发者可以专注于提供高质量的服务，而非兼容各种调用方式）。

5. 整体流程梳理与相互关系

这部分将前面的概念串联起来，形成一个完整的协作流程。

5.1 完整协作流程示例

  1. 用户请求：用户输入自然语言指令。
  2. Agent处理：Agent（通常是Function Calling Agent）接收到请求。
  3. Agent反馈：Agent可能需要调用工具，它会根据Function Calling规范或系统提示词的要求，决定如何操作。
  4. Agent与Tool服务：如果需要调用外部功能，Agent会通过MCP协议与对应的MCP Server建立连接，并调用其上的Tool。MCP Server执行完任务后，将结果返回给Agent。
  5. Agent将最终结果整理成自然语言，返回给用户。

5.2 关键概念之间的关系

  • 系统提示词：负责设定AI的角色和语气。
  • Function Calling：负责标准化AI调用工具的指令格式。
  • MCP协议：负责标准化Agent与远端Tool服务的通信方式。
  • Agent：作为中枢，协调上述所有组件，完成用户的最终目标。

总结

AI从单一的文本交互向自动化协作体系演进的路径：

  1. 提示词工程解决了如何与AI对话的问题。
  2. Agent与工具解决了AI如何执行动作的问题。
  3. Function Calling解决了AI执行动作时的格式规范问题。
  4. MCP协议解决了AI智能体之间以及智能体与服务之间如何互联互通的问题，为构建更复杂的AI应用生态奠定了基础。