SaaS 的下一场较量始于 MCP 之上

模型上下文协议为 AI 提供了连接企业软件的通用方式。Carta 首席产品官 Vrushali Paunikar 认为，更大的挑战在于建立连接后该做什么，以及工作中有多少应该交给语言模型。

过去一年，模型上下文协议从一项相对鲜为人知的技术标准，发展成企业 AI 领域最受关注的理念之一。

MCP 为 AI 应用提供了连接外部软件、访问数据并执行操作的标准方式。软件公司不必再为每种 AI 模型分别构建专用接口，MCP 提供了一种通用语言。

不妨把 MCP 想成墙上的电源插座。它是一种通用标准，任何设备都能插上并获得电力。它开放且适用广泛，这当然很好，但光有插座并不能替你做任何事，你仍然需要一台电器。

我猜，未来我们回顾当下对 MCP 的热情时，会像今天看待 API 的兴起一样。API 奠定了基础，也改变了软件的构建方式。但随着时间推移，互联能力逐渐成为人们理所当然的基础设施，而不再是产品本身。

如今，SaaS 行业很大程度上把 AI 连接能力当作已经完成的产品。搭建 MCP 服务器，开放合适的工具和数据，然后让模型接手后续工作。

对于某些用例来说，这已经足够。但对于许多企业工作流，尤其是金融领域的工作流而言，这还远远不够。

MCP 正在赢得连接层之争

标准化正在改变 AI 应用与软件的交互方式。越来越多的主流 AI 平台支持 MCP，用户无论选择哪种 AI 界面，都能使用相同的底层系统，这正变得越来越可行。

然而，互操作性虽然解决了访问问题，却没有告诉模型该如何完成工作。

我花了很多时间研究私募市场投资者和财务团队使用的软件；在这些场景中，这一区别尤为明显。

例如，如果让 AI 系统访问一只私募基金的业绩和投资组合数据，那么对于一个听起来简单明了的问题，可能有好几种回答方式。

一种方法可能会采用恰当的计算方式，另一种可能会走捷径，还有一种则可能误解用户的需求。

于是，用户不得不同时扮演分析师、提示词工程师和质量把关者。这并不是人们所期待的无缝体验。

产品仍需有自己的判断

技术栈的下一层正是在这里显现出意义。如果说 MCP 是连接层，那么插件和技能就位于它之上，告诉智能体如何利用这一连接完成特定任务。

它们不只是向模型开放数据和功能，还可以将指令、工作流、确定性计算和界面整合起来。

有时，这意味着按预先定义的步骤顺序执行操作；有时，则意味着运行确定性的计算或脚本，而不是让大语言模型推导答案。在其他情况下，最终产物可能是一份电子表格、一份报告，或一个专为该工作流设计的小型应用。

专业能力体现在产品中，而不是完全交由模型来承担。

证据表明，这种组合行之有效。Google 最近测试了一个 AI 编码智能体，它能够通过 MCP 访问 Google 的技术文档；随后，Google 又向它提供了额外的任务专属指令，说明如何最好地利用这些信息。将这种连接方式与这些指令结合后，该智能体在 Google 的评估中取得了 96.3% 的通过率；与标准提示方式相比，每个正确答案所用的词元数量还减少了 63%。

对于 SaaS 公司而言，这改变了差异化优势所在的位置。如果每个应用都能通过相同的开放标准提供数据，那么访问能力本身就不再那么独特。更有价值的是，知道如何将这种访问能力转化为可靠的结果。

并非所有任务都该交给模型

大语言模型是概率系统。它们在写作、探索和推理方面之所以有用，靠的是灵活性；但在重视准确性和可重复性的工作流中，这种灵活性反而不那么理想。金融就是一个很好的例子：如果人们期望同一项计算每次都得出相同答案，那么结果出现波动很快就会成为问题。

几十年来，金融软件的发展方向一直与此相反。审计跟踪、权限管理、标准化计算和可重复的流程之所以存在，是因为一致性很重要。

AI 不应抛弃这些经验。最出色的企业 AI 产品会知道何时让模型进行推理，何时对其加以约束。当判断和解读有用时，概率系统是合适的；当精准性和可重复性不可或缺时，确定性工具则更合适。

同样的原则适用于任何答错代价高昂的情形。

SaaS差异化接下来将转向何处

目前，正在MCP之上构建的这一层，远没有MCP本身那么成熟定型。

插件和技能领域已经出现了不同的做法，但相关工作已在推进，目标是让它们能在不同的AI平台之间更便捷地移植，而不是将其锁定在单一生态系统中。

即使所有标准尚未尘埃落定，SaaS公司仍然必须做出选择。它们一直都是如此。

另一种做法是开放一个接口，让客户自行组合出所需的体验。

AI或许也会走上同一条路。让智能体接入企业软件正变得越来越容易。优势将越来越取决于接下来发生的事情：那些能够指导智能体如何将访问权限转化为可靠成果的工作流、控制机制和领域专业知识。