飞书并入豆包，SaaS 圈 MCP 动作频频，背后是界面贬值、数据升值的时代信号。本文拆解巨头布局，提出数据底座、生态入驻、虚拟员工三条突围路径，并给出自测问题与落地建议，助你找到 AI 时代的生存之道。

7 月底，字节把飞书并入了豆包。

飞书不缺业绩——2025 年营收超 30 亿，2026 年 Q2 同比翻倍。可字节还是让它从”独立 BU”降级为”豆包体系下的产品线”，市场销售团队并进火山引擎。飞书负责人谢欣，向豆包负责人赵祺汇报。

一个增长中的业务被”拆掉”，这很反常。反常的地方，往往藏着信号。

而在同一个夏天，SaaS 圈也在密集发生着相似的小动作：纷享销客发布了官方 MCP 接入文档；用友把全线 ERP 原生适配 MCP；小鹅通进了 WorkBuddy 生态共创计划；Moka 把 HR SaaS 升级成 Moka AI，推出三位 AI”同事”；连金蝶都在社区里被做成了 MCP Server，让 Claude 直接操作 ERP 单据。

作为一家 SaaS 产品的负责人或产品经理，你大概率正在经历同样的焦虑：MCP 潮这么热，我们接不接？接了会不会沦为管道？不接会不会被绕过？

这篇文章想帮你把这件事想透。飞书并入豆包，不是看热闹，是一个信号——它逼着所有 SaaS 回答同一个问题：我们到底怎么突围？下面我会先讲怎么看懂这个信号，再给出几条真正可走的突围路径。

一、巨头们都在做同一件事

先看几个反直觉的事实。

• 飞书在增长，却被拆了。 为什么字节宁愿拆掉一个增长中的业务？因为字节看到的不是飞书的当下，是它的未来——当 AI 能自己操作软件时，办公工具的界面价值会快速贬值。
• 腾讯把 WorkBuddy 提到了战略级。 月访问量突破 2000 万，被内部视为继 QQ、微信之后的第三个战略项目。一个”工具”被提到战略级，说明腾讯判断它不只是工具，是下一代入口。
• 阿里整合了三款 Agent。 QoderWork、悟空、MuleRun 合并成”千问办公”，由钉钉新任 CEO 负责，规划直接嵌进钉钉——办公入口被定位成 Agent 的场景层。

三家大厂，动作不同，方向一致：抢 AI 原生 Agent 的入口——谁接住了用户那句自然语言指令，谁就获得了调度一切下游服务的分配权。

而 SaaS 圈的 MCP 动作，是同一枚硬币的另一面：当巨头在抢入口时，谁都想成为入口背后那个”被调用”的系统。

二、三个信号，指向同一个结论

信号一：界面在贬值，数据在升值

“办公工具的天花板，不再由 UI 体验或功能模块定义，而由底层大模型的认知和执行能力定义。”——这是飞书合并事件最核心的一句解读。

翻译成 SaaS 的语境：客户打开你的界面，是为了完成一个任务。当 AI 能替他把任务完成，他就不再需要你的界面。你的界面会贬值，但你积累的数据和业务场景不会。考勤数据、工资数据、绩效数据，这些垂直领域的数据资产，才是你真正值钱的东西。

信号二：从”卖席位”到”卖用量”

字节把飞书 GTM 并入火山引擎，本质是一次收费模式的切换：从”按人头收席位费”，转向”按用量、按任务结果计费”，叠加算力消耗和 Token 额度。

这对所有 SaaS 都是一个提醒：席位费是线性收入，用量费才是非线性收入。当你把自己变成 Agent 生态的一部分，每次被调用，你都在分享 Token 经济的增量，而不是只吃存量订阅费。

信号三：生态位比独立更重要

飞书放弃”独立运营”，换来的是”字节 AI to B 全栈里不可替代的场景层”；钉钉同样如此——它没有被做成独立的千问办公，而是被定义成千问办公嵌入企业的场景入口。在 AI 时代，一个 SaaS 的价值越来越取决于它在生态里的位置，而不是它是不是一个独立的公司。办公软件”被并入 Agent 生态”正在成为常态，而不是意外。

这三条信号拼在一起，结论很清晰：SaaS 的护城河，正在从”界面 + 功能”迁移到”数据 + 连接 + 场景”。 MCP 潮不是一阵风，是这场迁移在工程层面的落地方式。

三、你面前的四难选择

如果你是 SaaS 负责人或产品经理，你现在面对的是一个四难选择：不做 MCP，客户用 Agent 直接操作数据、绕过你的界面，你连被打开的机会都没有；做了 MCP 但只做连接器，又容易沦为管道，被大厂生态和上游 Agent 双重收割；想往上游走做虚拟员工，又不知道到底怎么落地、怎么定价；什么都不做先观望，又怕等看懂了窗口期也过了。

每一条路都像有坑，所以很多人卡在原地。但换个角度想：这四难的根源，是把”接不接 MCP”当成了单选题。其实 MCP 是地基，不是路径。真正的路径选择，在连接器之上——这也就是突围的起点。

四、三条突围路径，你在哪一条

同样做了 MCP，不同的 SaaS 会走向完全不同的结局。我把它分成三条路径，你可以对照自己的情况选。

路径一：做”数据底座”，把稀缺数据资产开放出去

如果你的产品握着别人没有的垂直数据，就把数据资产通过 MCP 开放给所有 Agent，成为生态里”不可绕过的那个连接器”。这条路径适合手里有独特垂直数据资产的厂商——HR、财务、医疗、法律、税务这类领域，数据天然稀缺，场景天然深，大厂反而不愿意沉下来做。

做这件事的关键，是把 MCP 做成企业级的：按企业维度生成连接 URL、管理员配置权限、员工 OAuth 授权、操作全链路审计。这一套不是炫技，是客户敢不敢让你连接数据的信任门槛。

风险也要说清楚：只做底座，容易沦为”卖水人”，按调用量收费，天花板清晰。但至少，你站在了所有 Agent 的必经之路上。

路径二：做”生态入驻者”，借入口流量获客

如果你的产品通用性强、需要流量入口，就主动入驻 WorkBuddy、千问办公这类 Agent 生态，借平台的对话入口触达用户。这条路径适合通用型产品、中小客群、靠流量吃饭的厂商。

关键动作是把高频场景拆成 Agent 能直接调用的原子能力——小鹅通的做法，就是把内容编排、经营查询、素材上传都做成了连接器能力，让用户在对话里就能完成原本要登录你后台的操作。

风险同样明显：命运握在平台手里，分成、流量、排名都是平台说了算。这是用独立性换增长，要想清楚。

路径三：做”虚拟员工”，往价值链上游走

连接器只是门票，门票后面才是戏。把”能力 + 知识 + 人设 + 记忆”打包成一个完整的虚拟员工，按结果、按月、按人收费——这才是从”卖工具”到”卖服务”的跃迁。Moka 就是现成的例子：它没停在”给 HR SaaS 加 AI 功能”，而是直接卖”AI 同事”。

虚拟员工不是聊天机器人。它要有身份（以什么角色跟你协作）、有技能（知道怎么干）、有知识（懂你的业务）、有记忆（越用越懂你），还要有手脚——通过 MCP 调用系统能力真正执行。没有 MCP 的虚拟员工只能给建议，有了 MCP 才能替你干活，而”能替你干活”，才是客户付费的理由。

这条路径的风险是：对产品定义、行业理解、交付能力要求都很高，不是加一层 AI 就能做到的。

五、四个问题，帮你找到自己的路

三条路径不是互斥的，但起步要有先后。别急着对号入座，先用四个问题问自己。

先问数据资产。你的数据稀缺吗？如果稀缺到别人拿不到，底座和员工两条路都适合你；如果一般、同质化，那底座这条路走不通，只能考虑入驻。

再问场景深度。你的场景垂直吗？垂直到流程可以沉淀成产品，才有资格做虚拟员工；如果只是人人可用的通用功能，老老实实走入驻路线，靠平台流量吃饭。

然后问一个更现实的问题：你愿意放弃独立性吗？做入驻，等于把一部分命脉交给平台，换来的是增长；如果你不愿意，那就只能在底座和员工之间选。

最后看商业模式想象空间。按调用量收费，天花板清晰；按分成，跟着平台走；按结果、按月、按人收费，想象空间最大——但要求也最高。回答完这四个问题，哪条路更适合你，基本就清楚了。

我的建议：无论最终选哪条路，第一步都是同一个——先把 API 完整化和 MCP Server 化跑起来。它是三条路共同的地基：想当底座需要它，想入驻生态需要它，想做虚拟员工更需要它——它是虚拟员工的手脚。不做 MCP，你连上牌桌的资格都没有；做了 MCP，你才有资格谈往哪条路走。

六、动手之前，先看清这几件事

有了方向，还要有方法。动手之前，先把一个容易搞混的概念理清：MCP 的底座是 API，不是 CLI。

API 是你系统的能力本源，查考勤、发工资条，本质都是 API 调用；CLI 是基于 API 的命令行封装，是给 Agent 直接执行命令用的——把接口变成一条条命令，Agent 像人敲键盘一样，一条条调用你的能力；MCP Server 则是把同样的能力封装成标准协议，让任何 Agent 都能通过 tools/list 发现、tools/call 调用，不需要它先学会执行你的命令行。但对”数据连接器”这个目标来说，MCP Server 应该直接建在 API 上，而不是套在 CLI 上。基于 API 做 MCP，才能支撑远程 HTTP、OAuth、审计这些企业级要求；CLI 的 –mcp-server 模式适合本地 stdio 的 Agent 场景。CLI 可以是给本地 Agent 用的轻量入口，但企业级连接器的主干，是 API。

第一步：自查四个前提，判断能不能做

动手之前，先确认四件事。

第一，API 就绪度。核心资源是否支持完整的增删改查？覆盖率是否超过九成？是否支持批量操作？如果大量功能只存在于界面、API 够不着，那做 MCP 之前得先补 API。

第二，权限体系。权限能否从”界面级”下沉到”API 级”？是否支持租户隔离、单据级拦截？如果现在只有一个全局 API Key，那 AI 拿到手就是上帝视角，这个必须先改。

第三，审计能力。每次 AI 操作能否被记录、追溯、脱敏？没有审计，出了安全事故你连解释的余地都没有。

第四，认证与合规。是否支持 OAuth 2.1 + PKCE？传输是否走 Streamable HTTP？是否兼容新版协议？如果只有长期 API Key、权限无法撤销，客户是不敢让你连数据的。

这四个前提，决定了你能不能做 MCP，也决定了客户敢不敢让你连数据。

第二步：选场景，做第一个 MCP

选高频、规则明确、边界清晰的场景，不要一上来就全系统一百个能力全上。第一阶段只读优先——只提供查询类能力，不开放写入，先把风险锁住。金蝶、Moka 的 MCP 都是这么起步的。先做五到十个工具，跑通稳定性和客户接受度，再逐步放开。

第三步：工具设计，让 Agent”看得懂”

MCP 的 tools/list 就是你的产品说明书，Agent 靠它决定何时调用。命名按模块前缀分组，比如 attendance_query、attendance_export，Agent 好理解；inputSchema 要类型化，每个参数写明类型、必填、默认值，description 里说清楚”什么时候该用这个工具”；返回要结构化 JSON，别返回文本表格，Agent 才能直接消费。工具设计质量，直接决定 Agent 用起来顺不顺，这一步做不好，后面 Agent 会频繁调错工具、反复失败。

第四步：权限对齐、稳定性、可观测

权限要复用现有体系，不另起炉灶——用户原来能看什么，AI 以他的身份就能看什么，原来不能改的，AI 也不能改，Pipedrive 就是这么做的。参数校验要放在 Server 端，不要依赖各家 Agent 客户端的校验行为；错误要结构化返回，超时、重试、限流都要做，因为 Agent 会并发调用。可观测性要能回答客户三个问题：AI 调用了什么工具？参数是什么？结果对不对？

走完这四步，落地节奏其实也就清楚了：先自查 API 和权限，判断能不能做；然后挑一个高频只读场景，做五到十个工具，先证明可行；再接到自有 Agent 产品里内测，验证稳定性和权限；最后加上审计和 OAuth，升级成可以对外售卖的企业级 MCP，从”能用”到”敢用”。到这一步，你手里就有了一张企业级 MCP 的入场券——然后才是”往哪条路走”的选择题。

写在最后

飞书都并入豆包了，这说明什么？说明连飞书这样的巨头，都在主动重构自己的位置——界面会贬值，数据不会；席位会触顶，用量不会；独立会焦虑，但生态位不会。

MCP 潮最热闹的当下，反而是 SaaS 负责人最该冷静的时候——因为接不接 MCP 从来不是问题，接完之后往哪走，才是问题。

突围不是做不做连接器，而是想清楚：你握着什么数据、有没有行业深度、敢不敢往价值链上游重新定义自己的产品。想清楚了，飞书并入豆包这一天，就是你出发的日子。