谈谈 MCP、无头产品以及企业的真正价值所在

嗨，朋友们，

我在与各位创始人交流时总会遇到类似这样的问题：是应该构建专属的垂直领域 AI 智能体，还是为客户已经在使用的现有横向智能体提供支持？

对于越来越多的人来说，他们处理知识工作的默认工具现已变为各类横向智能体：Claude Code/Cowork、Codex、Copilot。一天由此开始，许多任务也在这些工具上完成。

因此，如果你正在构建一款产品，就会面临一个选择：要么努力成为某类用户的专属智能体，成为他们而非那些通用型智能体会首先打开的工具；要么接受它们存在于通用型智能体之中的事实，通过为自己的优势领域提供支持来在该智能体中发挥作用。

在这篇文章中，我将探讨：

  • “构建代理”与“赋能代理”的真正含义

  • 如何确定应选择哪条路径

  • 实际而言，同时采用这两种方式需要做些什么

Build the agent versus power the agent

构建该智能体

构建专用垂直 AI 智能体意味着，对于特定的用户群体而言，你希望成为他们的核心智能体——而非作为 Claude 或 ChatGPT 中的连接组件，而是他们打开时首先使用的核心界面。

其优势显而易见：你可以掌控接口，掌握使用数据，还能成为用户处理各项任务时的首选工具。

问题在于，这会提高用户采用你产品的难度，同时还会让你与 ChatGPT、Claude Cowork、Codex 等竞争产品直接对抗。

在两种情况下采用这种策略是合理的。第一种情况是当你本身就已经是核心系统（且/或已经具备相应的操作/交互功能），用户整天都在使用你的产品，此时在产品内部内置智能代理显然比将他们引导到其他平台更有效。第二种情况则是当产品的核心在于特定领域的推理能力，相关任务的专业性过高，以至于通用型智能代理无法妥善处理。本质上，这两种情况都意味着你的产品具有足够的垂直化特征，能够让部分用户将其作为日常使用的核心智能代理。

Harvey 就是一个例子。它认为，对于律师群体而言，该工具应成为核心智能体，而非某个通用型智能体中的功能模块。其他专注于某一特定职业领域的厂商也遵循同样的逻辑，他们认为相关工作的特殊性足以支撑开发专属智能体。

不过，随着通用工具的不断改进，这些垂直领域的某些竞争对手有可能采取“为智能体提供动力”的策略，即在现有的其他横向智能体平台上满足客户的需求。

如果一个通用智能体已经能完成某人工作的大部分内容，要想说服他们转而使用你的产品来处理其中的一部分工作，实在是一件很困难的事。

为智能体提供动力

另一条路径则是接受客户正在使用现有的横向智能体这一事实，通过提升该智能体在自身领域的性能来加以利用，而非试图取代它。

常见的形式是 MCP 服务器，但简洁的命令行界面，或是专为智能体设计的优质 API，也同样可行。

你实际上是在打造一款专为智能体使用而设计的产品版本，这类智能体通常是指横向智能体。

那么在这种情况下，您的产品能带来什么价值呢？

  1. 数据与上下文。有些产品的价值源于其承载的数据和动作，而非任何界面，因此目前的趋势是将这些数据暴露在客户已使用的各类平台中。Granola 就是一个很好的例子，它推出了 MCP 功能，让其他智能体能够获取其对应的上下文信息。

  2. 功能与动作。另一个可发挥价值的途径，是通过让横向智能体能够接入你的产品，从而扩展或提升其所能执行的功能与动作范围。一个例子就是图像与视频生成平台 Higgsfield，它提供了 MCP 服务器，这样横向智能体就可以运用自身的推理能力与任务协调功能，同时借助 Higgsfield 在图像及视频渲染生成方面的专业优势。

在实践中，大多数采用这种策略的公司都希望找到方法，在数据/上下文以及功能/动作这两个维度上同时创造价值。

有趣的是，现有的行业巨头也在朝这个方向发展。Salesforce 在 2026 年 4 月推出了“Headless 360”计划，将该平台的所有功能以 API、MCP 工具以及 CLI 命令的形式公开，同时将 API 视为新的用户界面。HubSpot 也紧随其后，推出了远程 MCP 服务器，让任何兼容的智能体都能读取和写入 CRM 数据。

该选择哪种方案？

Four questions to decide whether to build or power the agent

我认为，对于创始人或开发者来说，在决定是自行构建智能体还是为现有智能体提供支持时，有几点需要考虑的因素。

您的客户目前是在您掌控的工具中工作，还是整天都在使用那些通用的智能助手？如果目标是要打造通用型智能助手，那就越应该依靠这类工具来提供支持，因为要把他们带到新的环境中去将会面临很大挑战。

你是拥有整个数据集/工作流程，还是只拥有其中的一部分？如果你能掌控某个工作流程或一系列工作流程的完整情况，那么就有资格成为该流程的智能代理。而如果你所拥有的只是那些需要与其他数据结合后才能发挥作用的部分，那么协调工作就由智能代理来完成，因此你几乎不得不依赖它来运行相关流程。

您的核心价值究竟体现在何处？是体现在领域推理本身，还是数据与动作上？那些需要大量推理且具有高度专业性的领域，更适合采用自建专用垂直 AI 智能体的方式；而那些以数据和动作为核心的场景，则更适合通过 MCP 为现有的通用智能体如 Claude 和 Copilot 赋能。

有多少工作需要在单个应用内完成？如果需要高度控制、遵循规则且涉及多步骤决策，那么更适合构建专用垂直 AI 智能体；而如果侧重于模块化设计及单一功能，那么为现有横向智能体提供能力支持更为合适。

同时采用这两种方式的具体做法是怎样的

Most products end up doing both

实际上，很多公司最终都会选择两种方式同时采用。他们会在自己的界面中嵌入智能代理，同时也会提供基于 MCP 或无头架构的产品版本，尤其是随着构建这类产品的成本不断降低之后。

即便你可以同时采用这两种方式，但需要记住的是，这两类用户的群体特征可能会有所不同。你是为那些深度使用你产品的用户构建专用智能体，而则为那些仅需要在工作中使用部分功能的用户提供基于现有横向智能体的解决方案。

此类案例包括：

  • 对于像 Salesforce 这样的 CRM 系统，部分资深销售人员可能会同时使用该产品的核心版本以及 Salesforce 内置的智能代理版本。而其他用户则大多通过 ChatGPT 访问该系统的无头版本，从而获取销售流程相关数据（并结合来自其他系统的数据）来辅助自身的分析工作。

  • 以 Figma 为例，许多设计师仍会使用其核心界面以及该界面内的设计智能体来完成工作。与此同时，市场营销、开发人员和产品经理等其他岗位则可以通过他们的 ChatGPT 智能体来利用 Figma MCP 或 Figma Canvas 功能制作简单的原型和素材，或是借助智能体已生成的 Figma 设计将其转换为代码。

最终你会拥有两个面向不同用户群体的接口：一个是专为使用你产品的核心用户设计的嵌入式智能体，另一个则是无头 MCP 层，供那些愿意从自己正在使用的任何智能体中调用你的功能的边缘用户使用。

采用这种模式的一个好处是，“为智能体提供功能支持”的方式能够帮助企业扩大受众群体，进而触达那些此前无法使用该产品的用户。由于这些用户无需花费精力学习如何使用产品，只需直接调用即可使用，因此产品的使用门槛也降低了。