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

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">MCP（Model Context Protocol）火了。这个 Anthropic 提出，旨在统一大模型（LLM）调用外部数据和工具方式的开放协议，在 OpenAI 官宣支持之后正成为新的行业标准，同样也成为了热点话题。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">按照官方的解释：模型上下文协议（MCP）是Anthropic推出的一项开放标准，旨在标准化人工智能应用程序（聊天机器人、IDE助手或自定义代理）如何与外部工具、数据源和系统连接。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">对于MCP的解读很多，但我感觉都太浅了。MCP 究竟要解决什么问题？和 Function Call 有什么区别？为什么它如此重要？我很少看到有人讲。这篇文章或许能给你一些启示。不同于纯技术解读，我将ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: inherit;color: rgb(15, 76, 129);">以 AI 产品经理的身份，结合我过去半年打造过的类似框架——“万能库”实践经验，来探讨 MCP 的价值。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">在我看来，MCP 的核心在于“标准化”。这个系列文章将围绕以下几点展开：

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;text-indent: -1em;display: block;margin: 0.2em 8px;color: rgb(63, 63, 63);">
•设计“万能库”的背景与过程，理解MCP出现的原因。
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;text-indent: -1em;display: block;margin: 0.2em 8px;color: rgb(63, 63, 63);">
•MCP带来的好处
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;text-indent: -1em;display: block;margin: 0.2em 8px;color: rgb(63, 63, 63);">
•对 MCP 下一步发展的预测（重要！）。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">让我们一起从我之前的实践经验来理解 MCP 为什么会出现。

先从万能库讲起

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

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

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

“输入 - 处理 - 输出”。

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

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

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

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

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

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

•输入模块库：各种数据抓取模块，负责将数据预处理好后传递给模型

•{ 文本提取器、网页内容抓取器、语音转文本模块、图像识别模块 }

•处理模块库：结合Prompt处理输入模块的内容

•{ GPT、Claude、DeepSeek、Gemini... }

•输出模块库：负责将处理模块的输出内容转化为实际产物

•{ Word 文档生成器、Excel 表格生成器、JSON 格式化、邮件发送... }

没错，这就是万能库的架构。

（这张PPT出自去年12月的Big Ideas分享会）

想做AI文章总结？组合：文本输入+（总结Prompt）大模型调用+文本输出即可。

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

想做 AI 智能写作？组合：文本输入+（写作Prompt）大模型调用+Word文档生成器即可。

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

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

importasyncio
fromomni_lab.inputs.textimportTextInput
fromomni_lab.processor.minimaximportMiniMaxProcessor
fromomni_lab.outputs.excelimportExcelOutput
fromomni_lab.prompts.managerimportPromptManager

# 您的 API key
api_key =''#

asyncdefmain():
 # 初始化各个组件
  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 =awaitpipeline.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的大模型都可以直接调用，所有人都不需要在再重新写这个功能了......而且有专人在优化这个模块。

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