EI与MCP的故事

EI Future, AI Now ！???

MCP能做什么?

先简单唠叨几句，试想一下，在 MCP 在之前，如果我们模型的产出更符合我们的预期，我们可能会将所需的数据上下文贴到 Prompt 中，但随着我们对产出的要求越来越高，CV大法的方式将信息添加到 Prompt 中会变得越来越困难。为了克服 Prompt 随着需求的复杂而上升后，OpenAI 等公司引入了 function call的功能，通过一些预定义的函数来获取操作。但 function call 并不是通用的，每个LLM厂商实现的 function call调用方式不同也需要开发者依赖并适配。至此，一个标准化的通信协议则成为了下一个爆点。

不同厂商实现的function call:

# OpenAI Function Calltools = [{"type": "function", "function": {    "name": "get_weather",    "parameters": {"type": "object", "properties": {"location": {"type": "string"}}}  }]# Google Gemini Function Callingtools = ToolConfig(    function_declarations=[FunctionDeclaration(      name="get_weather",      parameters={"location": {"type": "string"}}    )]  )

MCP起源于2024年11月25日 Anthropic 发布的文章： https://www.anthropic.com/news/model-context-protocol 它带来了一种新的方式用来将各种数据源、工具、功能连接到AI模型，就像USB-C我们可以将不同的不同的设备连接到一起， MCP统一的通用标准，让AI应用程序的开发和集成更加简单和统一。

MCP 的产生为我们的AI应用开发模式带来了新的积极影响：

▪建立了统一的数据通道, 解耦LLM与数据服务

▪动态上下文构建: 按需获取所需数据, 取代人工拼凑

▪降低开发成本，遵循通用协议，无需定制

IPAAS（一键转MCP）

尽管 MCP 已经提高了现有与AI结合的效率, 并提供了不同语言的SDK, 但让当前应用直接作为MCP server提供服务, 也存在着不小的挑战，例如：

▪项目的历史包袱：从数据格式要求、私有化接口规范等方面与 MCP标准化协议 存在鸿沟。

▪数据孤岛：所需要的数据分散在不同系统，需要开发新的接口来支持业务使用。

▪开发与部署：不管怎么来说，终究是需要再次开发一套 MCP 的接口/工具。

针对于上述问题，一个具备接口编排 + 自动化生成MCP服务 + 部署的平台则成为了迈过挑战让大家能够享受MCP带来的便捷服务的关键。而这也是我们已经完成的 天枢iPaaS连接平台。

天枢iPaaS连接平台 是一款开箱即用的企业级应用集成平台，提供丰富的组件和灵活的配置方式，帮助企业降低集成实施的周期和成本。平台支持多种集成方式，包括连接器API、事件驱动的消息传递编排流、数据组件编排流等。平台还提供了丰富的编排助手、全链路监控、多租户支持等功能。此外，平台支持自定义组件开发，满足个性化需求。平台适用于研发交付提效、自动化场景和与京ME机器人场景，支持MCP、HTTP、JSF、SFTP等多种协议。

在天枢iPaaS连接平台中，用户可以通过注册当前的 JSF 或者 HTTP 接口，在完成注册后，可以通过流程编排的方式将不同的接口合并成一个 http 的接口并暴露出去。

将 JSF 或者 HTTP 以连接流的形式注册成为 REST 接口： EI与MCP的故事

配置连接流，无需模型处理您的复杂业务逻辑：

EI与MCP的故事

将连接流一键生成MCP服务

在配置完所需要的工具接口后，则可以通过表单配置的方式生成所需的 MCP 服务。我们会给到用户 MCP 部署的URI.

EI与MCP的故事在这之后用户可以在 Autobots 的 MCP hub 中注册 MCP 工具并给到智能体使用。

EI与MCP的故事总的来说，通过 API编排 + MCP服务自动生成 + 自动部署 的流程，构建从数据连接到场景落地的全链路自动化能力，最终实现了 DaaS (Data-as-a-Service)的最终目标, 让研发能够更快的通过 MCP 赋能业务，让用户快速体验到AI时代浪潮下的便利。