新公司可以作为 MCP 来构建吗？
作者： Better Tomorrow Ventures
免责声明： 本翻译仅供个人阅读和学习参考，不得用于任何商业用途或进行随意转载发布。
随着我将越来越多的时间和工作流通过 Cowork 路由，我发现自己开始要求我们的软件和 SaaS 提供商提供 MCP（如果他们还没有提供的话）。他们现有的仪表板是可观察的界面，但在他们的 MCP 和我的 Cowork 框架之间，我现在拥有了一个不断发展的可编程界面，我可以根据我的工作流需求对其进行定制，而无需放弃对我们技术栈中关键软件的依赖，也无需自己进行自定义数据编排（我知道这可能会让我很头疼）。在对基础模型蔓延的担忧中，我正实时观察到 Cowork 消耗了我越来越多的工作流注意力，同时也增加了我自己对现有软件栈的依赖（通过 MCP）。
例如，我们使用一款名为 Harmonic 的产品来获取丰富的人脉和网络数据。理论上，我可以在 LinkedIn 上构建一堆爬虫并拼凑出相同的信息，甚至让 Claude 尝试通过使用 Claude code 构建的各种脚本来做到这一点。但这需要时间，而且我们大可以付钱给 Harmonic，让他们来做获取、清理和结构化这些数据的苦力活。我很少访问 Harmonic 的仪表板，但有了他们的 MCP，这些丰富的上下文会直接流入我的 Cowork 框架中，这非常有用。
Concrete 也有类似的情况，这是一个投资组合管理工具，它会筛选我们的电子邮件以获取来自投资组合公司的更新，然后将所有内容打包成结构化的投资组合情报。他们的仪表板提供了观察整个投资组合洞察的价值，但通过 MCP 和 Cowork，我可以查询，例如：“投资组合公司 X 正在寻找哪些客户介绍，在更广泛的 BTV 网络中谁可以帮助促成？”。我的 Cowork 框架将通过 MCP 利用 Concrete、Harmonic 和 Gmail，在整个投资组合中呈现介绍请求，在 BTV 网络中寻找路径，并起草要发送的电子邮件，所有这些只需一个提示词。
我们对软件供应商的依赖正在增加，不是因为他们的 UI，而是因为他们有能力打包丰富的、可供工作流使用的上下文，以供我的 Cowork 框架消费。这让我开始思考，什么类型的公司和产品可以完全在 MCP 层上构建。
扩展关于 MCP 公司的思考
如果像 Cowork 这样的通用框架是我们进行更多工作的地方，并且随着更多个性化、丰富的上下文流入，框架会变得更好，那么提供和维护该上下文的公司就可以占据一个真正有价值的位置。而且，购买而不是构建这种上下文就绪状态是一个合理的权衡。
我并不是说所有的应用层机会都会坍缩到 MCP 层。绝对会有需要走全栈路线并从一开始就构建自己框架的公司。但我确实想知道 MCP 层的公司会是什么样子。一个松散的分类可能是“读取型 MCP”（Read-MCP）和“写入型 MCP”（Write-MCP）企业？
读取型 MCP 企业将丰富的上下文提供给框架。Harmonic 提供人员和网络数据。Concrete 提供投资组合情报。另一个例子是 Granola，它提供会议摘要。它们的相关性在于数据的质量、覆盖范围和新鲜度，而它们的价值在于它们最初如何获取和拼接这些数据。它们的护城河可能在于它们能够获取的数据广度，或者也许它们有一个更好的转换+丰富层，或者两者兼而有之？
写入型 MCP 企业执行操作并写入通用数据库。这些可能是记录系统（比如 ERP）、总账、经纪商、支付网络、监管端点。它们的价值在于信任、授权和正确性。你需要合规性+责任保证和权限结构才能写入这些系统。
读取/写入的区分很重要，因为护城河的特征是不同的。读取型企业在数据获取方面进行防御。写入型企业则通过成为基于共识的格式、网络或受监管系统的受信任中介来进行防御。
现有企业难道不会直接添加他们自己的 MCP 吗？
一个显而易见的反对意见是：Salesforce、QuickBooks、Bloomberg 都在发布他们的 MCP。对此的一个反驳是创新者的窘境，即他们现有的商业模式严重依赖于在他们自己的仪表板和可观察的表面区域上的点击和浏览。我们在 Salesforce 限制 Slack 数据中看到了这种情况。
总而言之，上下文并不是零和游戏。从现在开始，新数据以及由此产生的上下文的数量将呈指数级增长。因此，这不仅关乎暴露现有的数据和上下文，还关乎收集现有的碎片化+非结构化数据并将其拼接成丰富的上下文（例如制造企业中附有 PDF 采购订单的电子邮件往来），并且还关乎成为这个 AI 世界中生成的所有未来上下文的主要渠道（就像 Granola 对会议笔记所做的那样）。
新的 MCP 层公司正在重新思考新形式的上下文存在于何处，以及它最初是如何被收集的。Granola 是最清晰的例子。它没有加入 Zoom 通话并成为尴尬的电灯泡（就像其他每一个记笔记工具一样），而是找到了一种保持沉默和环境感的方式，同时还能捕捉到近乎完美的上下文。产品创新和 PLG（产品主导增长）运动赋予了 Granola 对关键（且动态的）公司上下文的不公平且不断增长的访问权限。借助 Granola MCP，我的 Cowork 体验可以访问这些上下文。仅仅因为我不需要去使用 Granola 应用程序，并不意味着 Granola 在我的工作系统中就不那么重要了。
有哪些收集上下文的切入点？
说起来容易做起来难，但我想到的一些是：
- 以零到低阻力的方式，嵌入到现有的工作流时刻中。你的客户不一定需要一个新的仪表板来监控（除非用户想要）。
- 将上下文从一种状态转换和丰富为明显更好的状态，并将其作为你的核心竞争力（买家不会在乎去自己构建这个，或者构建、维护和操心它的代价太高）。
- 与企业合作，映射、收集和创建对他们来说独一无二的上下文图谱，并使其能够“MCP 化”进入像 Cowork 这样的通用框架中。这有点像 Glean 为企业所做的事情，我也在这里讨论了一种潜在的中小企业/中端市场方法。
我正在思考的紧张局势
出现的一些战略紧张局势是：
- 公司建设的动作是否要求一个读取型 MCP（Read-MCP）企业也进入拥有写入型 MCP（Write-MCP）范围，类似于记录系统？MCP 层是否是一个足够大的机会，还是你也需要构建自己的框架？
- 基础模型的蔓延仍然是一个主要问题，当然会有它们严重倾向的上下文表面区域。成长中的公司别无选择，只能暴露他们的 MCP，但是当这种范围蔓延靠得太近时会发生什么？他们只是希望到那时他们自己的框架和写入型 MCP 范围已经发展得足够好了吗？
我还在完善这个想法的早期阶段，真的非常乐意听听正在思考这一层的创始人和建设者的想法。我遗漏了什么？
