AI产品经理思考MCP协议（1）：预见MCP——我的“万能库”与标准化之路

MCP（Model Context Protocol）火了。这个 Anthropic 提出，旨在统一大模型（LLM）调用外部数据和工具方式的开放协议，在 OpenAI 官宣支持之后正成为新的行业标准，同样也成为了热点话题。

按照官方的解释：模型上下文协议（MCP）是Anthropic推出的一项开放标准，旨在标准化人工智能应用程序（聊天机器人、IDE助手或自定义代理）如何与外部工具、数据源和系统连接。

对于MCP的解读很多，但我感觉都太浅了。MCP 究竟要解决什么问题？和 Function Call 有什么区别？为什么它如此重要？我很少看到有人讲。这篇文章或许能给你一些启示。不同于纯技术解读，我将以 AI 产品经理的身份，结合我过去半年打造过的类似框架——“万能库”实践经验，来探讨 MCP 的价值。

在我看来，MCP 的核心在于“标准化”。这个系列文章将围绕以下几点展开：

• • 设计“万能库”的背景与过程，理解MCP出现的原因。
• • MCP带来的好处
• • 对 MCP 下一步发展的预测（重要！）。

让我们一起从我之前的实践经验来理解 MCP 为什么会出现。

先从万能库讲起

在讲 MCP 之前，我想先分享一个我过去大半年一直在思考和实践的概念——我称之为“万能库”（OmniLab）。在我们内部的测试中，显著降低了工作量（降低了70%的重复工作量），加快了实验效率。

这个想法源于去年夏天。那段时间，我密集地拆解分析了市面上形形色色的 AI 产品。拆得多了以后突然发现：无论产品形态多么不同，其底层逻辑是一样的，本质上都是利用大模型（LLM）来响应和满足用户的特定需求。

而且几乎所有的 AI 应用流程，都可以被简化、抽象为三个核心阶段：

“输入 - 处理 - 输出”。

我们来看几个看似截然不同的AI产品：AI智能写作、AI智能会议纪要、AI智能剪辑

我当时分析了至少十几个产品，从常见的各种AI写作，再到Riffo、 DeepSearch...甚至概念类游戏（用户输入 -> LLM 处理 -> 游戏进展输出），都逃不开这个模式。

让我们来更严格的定义这三个阶段：

1. 1. 输入 (Input)： 这是喂给 AI 的原始信息。它可以是文本、音频、图片、网页链接，也可以是工作流中上一个环节传递过来的数据。往往需要做很多预处理操作，比如说模态转换：无论原始模态是什么，往往需要先转换成大语言模型能理解的格式——通常是文本，因为“处理”环节的核心引擎大多是大语言模型。
2. 2. 处理 (Process)： 这是 AI 应用的“大脑”。核心通常是 大模型（如 GPT、Claude 等）配合精心设计的提示词 (Prompt)。有时，为了完成复杂任务，也可能用到多个模型组成的 Agent。但根本上是 LLM 在进行理解、推理和生成。
3. 3. 输出 (Output)： 这是 AI 完成任务后交付的成果。实用的 AI 产品绝不限于简单的聊天回复。输出需要是具体、有价值的内容或格式，比如输出一篇 Word 文档、一张 Excel 表格、一段符合规范的 JSON 数据（用于系统对接）或者直接在界面上呈现的可视化结果（Canvas），这个阶段通常依然需要外部程序辅助。

看清这个底层逻辑后，一个想法就会非常自然的涌现：既然底层实现是类似的，我们能不能把这些通用的功能模块“组件化”实现复用呢？

我们可以按照“输入-处理-输出”的思路，建立可复用的模块库：

• • 输入模块库：各种数据抓取模块，负责将数据预处理好后传递给模型
• • { 文本提取器、网页内容抓取器、语音转文本模块、图像识别模块 }
• • 处理模块库：结合Prompt处理输入模块的内容
• • { GPT、Claude、DeepSeek、Gemini... }
• • 输出模块库：负责将处理模块的输出内容转化为实际产物
• • { Word 文档生成器、Excel 表格生成器、JSON 格式化、邮件发送... }

想做 AI 会议纪要？ 组合:语音转文本输入+（总结Prompt）大模型调用+文本输出即可。

未来想做AI智能写作的细化产品比如AI 公文写作 或 AI 论文助手？ 只需复用现有模块，调整“处理”环节的 Prompt即可。这种“组装”模式极大地提升了开发效率和实验速度。

我当即利用我的框架重写了我之前写的所有demo。在核心功能上，最快几分钟就能调通，然后简单包装一下前端页面，就能快速进行测试验证。

import asyncio
from omni_lab.inputs.text import TextInput
from omni_lab.processor.minimax import MiniMaxProcessor
from omni_lab.outputs.excel import ExcelOutput
from omni_lab.prompts.manager import PromptManager

# 您的 API key
api_key = ''#

async defmain():
    # 初始化各个组件
    input_data = "balabala"# 输入数据
    text_input = TextInput(input_data=input_data)
    prompt_manager = PromptManager()
    system_prompt = prompt_manager.get("minimax.excel_system_prompt").format() #提示词装载
    processor = MiniMaxProcessor(api_key=api_key, system_prompt=system_prompt)
    excel_output = ExcelOutput(output_path='')
    pipeline = MiniMaxPipeline(
        text_input, 
        processor, 
        excel_output
    )
    # # 使用 pipeline 处理数据
    result = await pipeline.process()

（omnilab的quickstart文档）

然而要让这些独立的模块能够顺畅地拼在一起，一个关键前提必须满足：标准化。模块之间需要用约定好的格式来传递数据。输入模块处理完的数据，需要以处理模块能理解的方式传入；处理模块生成的结果，也需要以输出模块能接收的方式传出，所以当时，我自然而然地想到了使用JSON作为通用的数据交换格式。

如果你已经阅读到这里，相信你已经理解MCP出现的根本原因以及必要性了：我们真的在做大量重复且不必要的劳动，甚至还会降低性能！所以MCP尝试解决这个问题。按照MCP官方的解释，MCP提供了

• • A growing list of pre-built integrations that your LLM can directly plug into
• • The flexibility to switch between LLM providers and vendors
• • Best practices for securing your data within your infrastructure

再来看看MCP官方提供的图。相较于万能库，MCP并没有按照Input、Output的方式划分。而是将Input和Output统一变成MCP Server，负责给大模型提供MCP服务的部分。而大模型这部分变成了MCP Client，但本质上和万能库是一样的逻辑，标准接口，快速拼接。

这样的好处可太大了，比如说，一个网页提取的功能，如果做成MCP工具，所有支持MCP的大模型都可以直接调用，所有人都不需要在再重新写这个功能了......而且有专人在优化这个模块。

现在我们已经知道了标准化的可行性。但这自然引出了一个更深层的问题：标准化，真的有必要吗？我们是不是在重复造轮子？