Let's Make AGI Real

本研究的目的，是考察将FOLIO/云瀚的各类AI应用建立在MCP/A2A基础之上的可能性，最后的结论是完全有可能的，但需要我们大胆尝试。本文是系列研究的第一篇。

MCP协议在领域应用中的典型用法和场景 

模型上下文协议（MCP）是一种开放标准，用于让AI模型方便、安全地访问外部数据源和工具。其架构采用Host-Client-Server模式：Host（宿主应用）是运行LLM或智能体的应用环境（如Claude桌面应用、IDE插件等），负责发起与数据源的连接；MCP Client（客户端）是由Host管理的中间代理，每个客户端与一个特定MCP服务器通信，确保安全隔离；MCP Server（服务器）则是实现MCP标准的轻量程序，为某一数据源或工具提供标准化接口，包括数据资源（resources）、函数工具（tools）和提示模板（prompts）等能力。基于这一架构，不同领域的应用市场可以通过标准方式将AI模型与领域数据、工具相集成。以下探讨三种典型形式的Marketplace，以及MCP中Host、客户端、服务器在其中的用法和场景：

数据资源集成平台 

在数据资源集成平台场景下（如学术文献数据库聚合、知识图谱服务整合、API网关等），MCP可以充当各异数据源与AI助手之间的“统一接口”。平台本身作为MCPHost（宿主），承载一个或多个LLM智能助手，这些助手需要查询多种数据资源来回答用户问题或执行分析。针对每种后端数据源（例如某学术数据库、图书馆馆藏系统或知识图谱），平台会配置对应的MCP Server（服务器）连接器，将该数据源的查询、检索功能封装为标准MCP工具和资源。当用户通过平台提出请求时，Host会为所需的数据源各自启动一个MCP Client（客户端）实例，与对应服务器建立1对1连接并发出查询，获取结果后返回给LLM整合处理。例如，一个学术检索助手需要同时从IEEE Xplore和ACM库检索论文，平台可启用两个MCP客户端分别连接“IEEE数据库MCP服务器”和“ACM数据库MCP服务器”，LLM随后汇总两边的检索结果进行回答。这种模式下，MCP简化了多源数据接入的开发，每个数据源只需实现一次MCP服务器，平台即可像插拔USB设备一样添加新数据源。早期已有企业在内部知识平台中验证了这种思路：如Block公司和Apollo公司将MCP集成于内部系统，使AI助手可以统一访问公司多个数据仓库。在学术和图书馆领域，类似地可以构建“知识资源集成门户”：通过MCP连接文献数据库、引文索引、馆藏目录、开放知识图谱等，使AI科研助理或图书馆咨询Bot能跨库检索，获取丰富上下文来回答用户复杂的学术查询。

智能工作流系统 

在智能工作流系统中（如学术期刊审稿流程、论文投稿元数据生成、馆藏分类与推荐等场景），MCP可以帮助串联起各步骤所需的AI能力和数据访问，实现复杂流程的自动化。此类系统通常包含多个环节，每个环节需要AI访问特定的数据或执行特定工具。例如，在学术出版审稿场景中，一个AI助手可能需要：获取投稿论文全文，调用学术知识库比对引用文献，查询作者过往发表记录，以及生成审稿报告草稿等。采用MCP架构时，工作流管理系统作为Host加载协调多个LLM子代理（或一个LLM在不同阶段执行不同子任务），并为每项数据访问需求创建对应的MCP客户端去对接相应的MCP服务器。比如：通过“文件系统MCP服务器”读取投稿PDF全文，通过“引文数据库MCP服务器”查询引用信息，通过“学者信息MCP服务器”获取作者学术主页数据，等等。每个MCP服务器各自封装了底层复杂操作，如调用CrossRef/DOI服务获取文章元数据、调用反剽窃API比对文本、调用本地知识图谱获取相关研究推荐等。LLM助手在收到各渠道信息后，可以综合分析并完成当前环节任务（如撰写审稿意见），然后由工作流系统进入下一个步骤。MCP保证了这些外部调用以统一方式进行，Host对各MCP客户端的调用和结果有集中控制，从而实现“AI驱动的流水线”。Anthropic的Claude桌面应用就展示了MCP用于自动化工作流的雏形——Claude通过配置多个本地MCP服务器（如文件系统、Git仓库等），可以执行组合工具链来完成复杂任务。在图书馆IT或数字资产管理中，也可设想类似工作流：例如新书入库流程中，AI自动获取图书元数据（经由MCP连接ISBN数据库）、分析分类号（经由MCP连接分类法服务）、生成馆藏推荐标签，等等。MCP提供的安全沙盒和双向通信机制确保这些自动流程在本地受控环境中进行，从而保护敏感数据的安全。

Agent应用商店 

随着各种专用AI Agent（智能体应用）的涌现，可以获取各类智能体应用的“应用商店”自然会应运而生，用户可以在其中按需选择不同智能代理来完成特定任务（如学术检索助手、内容创作助手、图书馆问答Bot等），甚至可能通过注册机制自动发现相关应用，无需用户指定即可自动实现任务编排。在这样一个Agent应用商店场景中，MCP协议为每个独立Agent接入用户数据和第三方服务提供了标准方式，使这些Agent能够即插即用地运行在统一平台上。平台本身可以扮演MCP Host角色，管理着多个可用的Agent应用。当用户选择某个Agent运行时，平台为该Agent实例启动相应的LLM和所需的MCP客户端连接。每个Agent背后可能需要访问不同资源：例如“智能检索助手”需要连接学术搜索MCP服务器、网页爬取MCP服务器来实时获取信息；“内容创作代理”需要连接一个知识库MCP服务器获取资料、甚至连接图像生成MCP工具以插入图片；“图书馆服务Bot”可能需要连接馆员咨询知识库MCP服务器、馆藏OPAC接口MCP服务器等以回答读者提问。平台通过MCP确保无论是哪种Agent，其所需的外部接口都遵循统一规范，从而简化了Agent开发和部署——开发者只需专注Agent本身逻辑，其数据访问部分直接复用已有MCP服务器。这种模式类似于OpenAI的ChatGPT插件，但MCP使之成为开放标准，不局限于某一家LLM供应商。可以想象未来用户在一个“AI应用市场”中一键安装新的Agent应用时，背后对应的MCP服务器也随之注册到平台，Agent立即就能发现并调用相关工具（无需开发者为不同平台重复适配）。例如，一个图书馆可以搭建自己的Agent商店，提供“馆藏查询Bot”、“新书推荐AI”、“科研咨询助手”等多个Agent，每个Agent通过MCP连接不同后端服务，却都能在同一交互界面供用户无缝使用。这不仅提升了终端用户体验，也为第三方服务提供商开放了一个市场化接入途径：任何人都可以开发符合MCP标准的Agent或数据服务，发布到这个生态中，被有需要的用户或机构选用。

下一篇预告：有哪些模型、中间件与Agent框架原生支持MCP？