【AI】AI编程助手与MCP

AI编程助手目前已经有很多了，包含Cursor、Windsurf/Codeium、GitHub Copilot、Roo Cline、Tabnine、Trae与通义灵码；另外还有前段时间比较火的MCP，今天我们主要来介绍他们。

一、编程助手基本特性对比

二、编程助手使用对比

见个人公众号文章：
1、【AI】AI编程助手：Cursor、Codeium、GitHub Copilot、Roo Cline、Tabnine

2、【AI】AI编程助手2: Roo Code企业应用与MCP，以及Trae与通义灵码

三、MCP基本概念与原理

模型上下文协议(Model Context Protocol, MCP)，这是一个开放协议，用于标准化应用程序如何向大语言模型(LLMs)提供上下文。可以将 MCP 想象成 AI 应用程序的 USB-C 接口。就像 USB-C 为设备连接各种外设和配件提供了标准化方式一样，MCP 为 AI 模型连接不同的数据源和工具提供了标准化方式。可以这么理解，想象你正在开发一个需要多种AI能力的应用，比如:

• 问题解决场景：假设你有一个客服机器人

  • 当用户问简单问题时，可以用轻量级模型处理（节省成本）
  • 当遇到复杂问题时，自动切换到更强大的模型（提高质量）
  • MCP提供这种智能路由和模型切换的框架

• 能力组合：一个内容创作平台

  • 用专门的文本生成模型
  • 创建初稿
  • 用专业的编辑模型进行优化
  • 用多语言模型进行翻译
  • MCP帮助这些模型无缝协作，形成工作流单一

• 接口优势：

  • 你不需要为每个模型学习和维护不同的API
  • 统一的接口减少了开发复杂度
  • 在未来可以轻松替换或升级底层模型，而不影响应用

• 成本控制：

  • 可以设置规则，仅在必要时使用高算力（昂贵）
  • 模型对于简单任务使用更经济的模型  

MCP架构

MCP采用客户端-服务器架构：

其中包含几个关键组件：

• MCP Hosts：如Claude Desktop、IDE或AI工具等需要通过MCP访问数据的程序
• MCP Clients：与服务器保持一对一连接的协议客户端
• MCP Servers：通过标准化的模型上下文协议提供特定功能的轻量级程序
• Local Data Sources：MCP服务器可以安全访问的计算机文件、数据库和服务
• Remote Services：MCP服务器可以连接的外部系统(如通过API)

客户端职责：

• 请求构建：将用户输入和必要的上下文封装成符合协议的请求
• 上下文管理：追踪和维护对话历史、在本地存储和管理上下文信息、决定哪些上下文需要发送给服务端
• 请求发送：通过网络将格式化的请求发送到服务端
• 响应处理：接收并解析服务端的响应、在需要时进行流式接收和处理
• 用户界面：提供与用户交互的界面，展示响应结果

服务端职责：

• 请求处理：接收并解析来自客户端的请求
• 模型调用：使用提供的上下文调用语言模型、管理模型的参数和配置
• 响应生成：将模型的输出格式化为协议定义的响应格式、可能包括流式输出的处理
• 资源管理：处理并发请求、优化计算资源的分配
• 安全性确保：验证请求的合法性和安全性

协议交互流程：

• 客户端构建包含用户输入和必要上下文的请求
• 客户端将请求发送到服务端
• 服务端解析请求并调用语言模型
• 服务端将模型输出格式化并返回给客户端
• 客户端处理响应并更新本地上下文
• 客户端展示结果给用户

这种分工使客户端能够专注于用户交互和上下文管理，而服务端则专注于高效的模型调用和响应生成，从而实现高效的大型语言模型应用。

MCP工作流程

关键在于：

• 决策机制：大模型需要有能力判断何时使用什么工具，这依赖于模型的工具使用训练
• 参数构造：大模型需要正确构造工具调用的参数
• 中间结果处理：MCP需要处理工具返回的各种格式的数据
• 错误处理：整个流程中需要处理各种可能的错误情况，如工具不可用、参数错误等

MCP疑问

不知道是不是有人和我有一样的疑问，下面让我们带着问题去学习。

1、有了Agent画布流程，还需要MCP吗？

即使有类似 Coze 的 agent 画布流程，接入 ModelContextProtocol (MCP) 仍然可能是必要的，这取决于你的具体需求和应用场景。
Agent 画布流程和 MCP 解决的是不同层面的问题：

• Agent 画布（如 Coze）：主要提供了可视化的工作流设计工具，让您能够定义 agent 的行为逻辑、决策流程和工具调用方式，这是在应用层面的抽象。
• ModelContextProtocol：更关注底层的通信规范和模型交互方式，它定义了客户端和服务端如何高效交换信息、管理上下文和处理模型响应。

在以下情况下，即使有 agent 画布，接入 MCP 仍然有价值：

• 自定义深度集成：如果你需要对模型交互进行更精细的控制，如上下文管理、流处理优化等
• 多模型调用：你的应用需要调用多个不同的模型或模型服务
• 本地部署需求：需要将模型部署在自己的基础设施上并维持标准化接口
• 性能优化：对网络传输效率和模型调用效率有较高要求
• 架构统一：希望在不同应用间维持一致的模型调用模式

如果你的需求主要是快速构建简单的 agent 应用流程，并且 Coze 等平台提供的能力已经足够，那么可能不需要额外接入 MCP。但如果你在构建更复杂、更定制化的应用，特别是需要精细控制模型交互细节时，MCP 仍然是有价值的。

2、agent也可以构建复杂的流程，为什么要用MCP呢？

agent 画布主要解决的是"做什么"的问题（业务逻辑和流程），而 MCP 解决的是"如何做"的问题（模型交互方式）。在复杂应用中，两者结合使用可以既保证业务流程灵活性，又确保底层模型交互的高效性和可控性：

• 底层通信规范：MCP 提供标准化的模型通信接口，而 agent 更关注业务逻辑流程。使用 MCP 可以确保与不同模型的一致交互方式，无论上层 agent 流程如何变化。
• 自主控制与独立性：通过 MCP，你可以保持对模型调用的完全控制，减少对特定 agent 平台的依赖，避免被锁定在单一生态中。
• 集成多种模型：当你需要在同一应用中集成多个不同提供商的模型时，MCP 可以提供统一的接口层。
• 性能与成本优化：MCP 允许你精细控制上下文管理、请求压缩等，这些在高流量或高成本场景下非常重要，而 agent 平台可能不提供这样的底层控制。
• 数据安全与隐私：通过 MCP，你可以完全控制哪些数据发送到模型服务，以及如何处理敏感信息，这在一些企业场景尤为重要。

3、在性能与成本优化方面，MCP需要提供大模型更多的提示词，这不是会造成成本浪费吗
MCP 确实需要提供更多结构化的提示词和上下文信息，这看似会增加成本，但实际上可能实现整体成本优化：

• 智能上下文裁剪：MCP 允许客户端进行智能上下文管理，只发送真正相关的信息，而不是整个对话历史，这可以显著减少每次请求的 token 数量。
• 单次交互效率提升：通过结构化的请求格式，可以使模型更准确地理解任务需求，减少多轮澄清的必要性，从而减少总体交互次数。
• 批处理与缓存优化：MCP 协议可以支持请求批处理和结果缓存策略，减少重复计算。
• 模型选择灵活性：可以根据任务复杂度动态选择不同规模的模型，简单任务使用更小的模型，复杂任务才调用大型模型。
• 请求压缩：一些 MCP 实现支持对请求进行压缩处理，减少网络传输成本。

虽然单次请求可能包含更多结构化内容，但通过减少总体交互次数、智能管理上下文和优化请求结构，MCP 可以帮助降低长期运行成本。这种权衡对于高频使用场景特别有价值，初期看似增加的提示词成本可能会通过减少的交互次数和更高的任务完成效率得到补偿。

4、这些功能Agent也能做到，为什么要选择MCP呢？
选择哪一个主要取决于你的具体需求：

• 如果你需要高度自定义的模型交互方式并保持完全控制权，MCP 可能更合适。
• 如果你需要快速部署并且 Agent 平台已经满足你的优化需求，那么使用现成的 Agent 解决方案可能更加高效。

5、MCP和Function Call又有什么区别呢

• 范围与层次：

  • MCP：是一个完整的通信协议规范，定义了客户端和服务端之间的整体交互方式，包括请求格式、上下文管理、响应处理等多个方面。
  • Function Call：是模型能力的一个具体特性，专注于让模型以结构化方式调用预定义的函数。

• 目的不同：

  • MCP：旨在标准化和优化模型服务的整体调用流程，关注通信效率和资源管理。
  • Function Call：旨在增强模型的工具使用能力，让模型能够以结构化方式请求执行特定操作。

• 实现层面：

  • MCP：作用于客户端与服务端之间的通信层面，定义了请求和响应的格式标准。
  • Function Call：作用于模型输出内容的格式层面，是模型响应的一种特殊形式。

• 使用场景：

  • MCP：适用于需要优化模型调用性能、标准化接口或管理复杂上下文的系统架构设计。
  • Function Call：适用于需要模型调用外部工具、执行特定操作或返回结构化数据的应用场景。

简言之，MCP是"如何与模型服务通信"的规范，而Function Call是"模型可以如何返回结构化操作请求"的能力。

5、MCP和A2A又有什么区别呢

• 范围与层次
  A2A (Agent-to-Agent)：

  • 作为一种协议，定义了独立智能体之间的交互模式和任务协作方式
  • 构建了智能体之间的通信标准，包括任务描述、消息格式和制品交付
  • 所有交互都围绕执行任务进行，任务结果作为"制品"(artifacts)返回
  • 关注智能体间的分布式协作系统和异步通信

  MCP (Model Context Protocol)：

  • 专注于单个模型会话内的工具和上下文注入机制
  • 定义了模型如何访问和使用外部能力的标准
  • 作为模型和其工具/能力之间的接口层运行
  • 关注单一模型会话的上下文管理和能力扩展

• 目的不同
  A2A：

  • 旨在让不同智能体之间进行有效协作，处理复杂任务
  • 解决分布式智能体系统中的通信和协调问题
  • 建立了一种异步、面向任务的通信架构
  • 支持跨网络、跨平台的智能体交互

  MCP：

  • 旨在扩展模型的能力，让模型可以使用外部工具和数据源
  • 提供模型在单个会话中访问结构化功能的标准方式
  • 优化模型与工具间的交互，使模型能理解和使用工具的输出
  • 强调在单一模型会话内提升能力而非跨智能体协作

• 实现层面
  A2A：

  • 通过结构化任务对象实现，包括请求细节和状态跟踪
  • 支持富媒体、多部分消息交换，包括文本、JSON、图像、视频或交互式内容
  • 实现异步通信，允许长时间运行的任务和状态更新
  • 设计用于网络通信，支持跨系统、跨平台的智能体通信

  MCP：

  • 主要作为单个模型会话内的上下文注入机制
  • 定义模型如何请求和使用工具、数据和函数的标准
  • 在模型与工具间提供接口，而非跨智能体
  • 专注于单个模型的能力扩展而非智能体间协作

• 使用场景
  A2A：

  • 适用于构建多智能体系统，如协作团队完成复杂任务
  • 适合需要专业化智能体分工协作的场景
  • 支持长时间运行、需要多个智能体协作的复杂工作流
  • 例如：分析智能体读取文档，设计智能体自动创建相关线框图，无需手动交接

  MCP：

  • 适用于需要扩展单个模型能力的场景
  • 适合需要模型使用外部工具、API或数据源的应用
  • 适用于需要结构化模型输出或工具调用的场景
  • 例如：让模型使用搜索引擎、调用API或访问特定数据库

• 系统架构区别
  A2A：

  • 一个编排智能体使用A2A委派子任务给专业智能体（如分析、人力资源、财务等）
  • 建立了跨智能体的通信层，允许分布式处理
  • 关注跨模型、跨系统的协作架构
  • 是关于智能体通过网络与其他智能体进行安全、异步、面向任务的通信

  MCP：

  • 专注于在模型会话中注入结构化能力，让模型能够在上下文中使用工具和数据
  • 是单个智能体内部用于访问工具的机制
  • 关注单一模型与其工具和能力的接口
  • 是关于在模型会话中注入结构化能力，让模型对工具和数据进行上下文推理

• 未来发展趋势
  A2A：

  • 朝向创建标准化AI市场和服务生态系统发展
  • 可能发展出更复杂的智能体协作模式和任务编排机制
  • 将支持更丰富的智能体专业化和协作场景
  • 有潜力形成分布式AI服务的互操作性标准

  MCP：

  • 可能发展出更丰富的上下文注入和工具使用机制
  • 朝向更好的结构化思考和推理表示
  • 可能与A2A协议互补，作为单个智能体内部的工具使用机制
  • 将进一步提升模型使用工具和外部资源的能力

• 实际应用对比
  A2A：

  • 例如：编排多个专业化智能体共同完成复杂任务
  • 支持智能体市场，如Airbnb提供预订服务，Google Maps提供地图服务
  • 适合构建复杂的自主工作流，无需用户干预
  • 强调智能体间的自主任务分配和结果整合

  MCP：

  • 例如：单个模型使用搜索引擎、数据库或特定API
  • 适合扩展单个模型的能力范围
  • 在单一会话内增强模型功能
  • 强调模型与工具间的紧密集成

总的来说，A2A和MCP代表了AI系统架构中两个不同但互补的层次：A2A专注于智能体间的协作和通信，建立了分布式智能体系统的协作框架；而MCP则专注于单个模型如何使用工具和访问资源，增强单一模型的能力。在综合AI系统中，这两种协议可以共存互补——A2A处理智能体间的通信，而MCP管理智能体内部的能力调用，共同支持复杂、分布式、功能丰富的AI应用生态系统。

四、Roo Code的MCP原理

可以看src/core/prompts/__tests__/__snapshots__/system.test.ts.snap，这里可以看到大模型的提示词：

这里将所有的工具以及工具所需的参数均列出来了，告诉大模型有哪些工具可以用。use_mcp_tool提示词如下：

---

欢迎关注我的个人公众号