Carta 首席产品官：SaaS 的下一场竞争在 MCP 之上

模型上下文协议（Model Context Protocol）正在为 AI 提供一种连接企业软件的通用方式。Carta 首席产品官 Vrushali Paunikar 认为，更大的挑战在于决定连接建立之后会发生什么，以及应该把多少工作留给语言模型。

在过去一年里，模型上下文协议已从一个相对小众的技术标准，变成了企业 AI 领域最重要的理念之一。

MCP 为 AI 应用提供了一种标准方式，用来连接外部软件、访问数据并执行操作。有了 MCP，软件公司不必再为每个 AI 模型单独构建定制接口，它提供了一种通用语言。

可以把 MCP 想象成墙上的电源插座。它是一个通用标准，让任何设备都能插上取电。它的好处在于开放且随处可用，但插座本身并不能为你做任何事。你仍然需要一台电器。

我猜想，我们最终回望当下对 MCP 的热情时，会很像我们看待 API 兴起的方式。它们具有奠基性，改变了软件的构建方式。但随着时间推移，连接能力变成了预期之中的基础设施，而不再是产品本身。

目前，许多 SaaS 行业把 AI 连接能力当作一件成品来对待。构建一个 MCP 服务器，暴露合适的工具和数据，然后让模型自行处理后续工作。

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

标准化已经在改变 AI 应用与软件交互的方式。越来越多的主流 AI 平台支持 MCP，这使得用户无论偏好哪种 AI 界面，都能与相同的底层系统协作，这一场景正变得越来越现实。

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

我大部分时间都在思考私募市场投资者和财务团队所使用的软件，在这一领域，上述区别尤为明显。

例如，让 AI 系统访问某只私募基金的业绩和投资组合数据，对于一个听起来很直接的问题，可能会有好几种回答方式。

一种方式可能采用恰当的计算。另一种方式可能走捷径。第三种方式可能误解了用户的意图。

于是用户被迫同时扮演分析师、提示词工程师和质量控制员。这并非所承诺的那种无缝体验。

这正是技术栈下一层变得有趣的地方。如果说 MCP 是连接层，那么插件和技能就位于其之上，告诉智能体如何利用这一连接来完成特定任务。

它们不只是简单地把数据和函数暴露给模型，还可以围绕这些数据和函数封装指令、工作流、确定性计算和界面。

有时，这可能意味着遵循一套既定的操作序列。有时，这可能意味着运行确定性计算或脚本，而不是让大语言模型自行算出答案。在其他情况下，最终结果可能是一个专为该工作流设计的电子表格、报告或小型应用。

专业知识存在于产品之中，而不是完全交给模型。

有证据表明这种组合确实有效。Google 最近测试了一个 AI 编码智能体，该智能体可以通过 MCP 访问其技术文档，随后 Google 又向它提供了额外的任务专用指令，说明如何最好地利用这些信息。在 Google 的评估中，将连接与这些指令相结合，通过率达到了 96.3%，而每个正确答案消耗的 token 比标准提示词少 63%。

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

大语言模型是概率性系统。让它们在写作、探索和推理中游刃有余的灵活性，在准确性和可重复性至关重要的 workflows 中就不那么有吸引力了。金融就是一个很好的例子：如果有人期望同一计算每次都得出相同答案，那么结果的变化很快就会成为问题。

金融软件几十年来一直朝着相反的方向发展。审计追踪、权限、标准化计算和可重复流程之所以存在，正是因为一致性具有价值。

AI 不应抛弃这些经验。最强大的企业 AI 产品将懂得何时让模型进行推理，何时对其加以约束。当判断和解读有用时，概率性系统是合理的。当需要精确性和可重复性时，确定性工具则更为合理。

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

SaaS 差异化的下一步走向

在 MCP 之上构建的这一层，仍远不如 MCP 本身那样稳定。

围绕插件和技能已经出现了不同的方法，但各方已在努力让它们在 AI 平台之间更具可移植性，而不是把它们锁定在单一生态系统中。

在每个标准尘埃落定之前，SaaS 公司仍然必须做出选择。它们一向如此。

另一种选择是暴露一个接口，让客户自己去拼装体验。

AI 可能也会走上同样的道路。将智能体连接到企业软件正变得逐月更加容易。优势将越来越多地取决于接下来会发生什么：那些告诉智能体如何把访问转化为可靠结果的工作流、控制机制和领域专业知识。