当AI能自己操作软件时，SaaS厂商的生存法则正在被重写。本文拆解AI产品化的四层台阶：API、CLI/MCP、Agent、A2A，并指出两个常见误区，帮助你在入口迁移的浪潮中找准站位，避免被Agent生态淘汰。

客户提了一个很“普通”的需求。

“以后我一句话，把员工考勤异常处理掉，不用人盯着。”

听起来不难。拆开看，这句话背后是四件事：查考勤（我们的HR系统）、查OA审批单（客户的钉钉）、查薪酬补偿规则（客户买的财务软件）、算好结果通知员工。四个动作，跨三个不同厂商的系统。

如果三个系统都是我们的，事情很简单，API内部串起来就行。但它们分属三家公司，而这三家公司，现在都在做自己的AI Agent。

问题就来了：我们的考勤Agent，怎么”指挥”钉钉的Agent去查审批单？怎么让财务软件的Agent去算补偿？

这不是一个产品功能问题，是SaaS厂商在AI时代躲不开的生存问题。它逼着所有SaaS回答同一件事：当AI能自己操作软件时，你的能力到底怎么被AI用起来？

要回答这个问题，得先把SaaS的AI产品化拆成四层台阶，一层一层看清楚：每一层解决什么、爬不过去会卡在哪、以及一家资源有限的中小SaaS现在该站在哪一级。读到最后，你可以对照着给自己打个分。

一、先看清商业上发生了什么

过去半年，SaaS圈最热闹的两个词是MCP和A2A。先是各家厂商排队发布MCP接入，再是A2A被炒成”下一代分水岭”。热闹背后是同一个焦虑：AI能自己操作软件了，客户的界面还在不在？我们会不会被绕过？接不接得上这班车？

大厂的动作已经把答案写在明面上了。字节把飞书并入豆包，让它从独立BU降级为豆包体系下的产品线；腾讯把WorkBuddy提到战略级，月访问量突破两千万；阿里把三款Agent合并成千问办公，8月3日开启公测。三家动作不同，方向一致：抢AI原生Agent的入口——谁接住了用户那句自然语言指令，谁就拿到了调度一切下游服务的分配权。

这个动作不是第一次发生。回看二十多年，每一次入口迁移，都让一批企业被迫”重新排队”。门户时代，用户从新浪、搜狐进互联网，网站争的是门户首页的推荐位；搜索时代，用户从百度、谷歌进，企业拼命做SEO，因为搜索排位就是生死线；移动时代，用户从应用商店下载App，开发者要被抽成、要研究ASO怎么让排名靠前。

现在轮到Agent了。用户不再打开浏览器，也不再进应用商店，而是对AI说一句话。谁家的SaaS能力被这句话里的Agent选中、优先调用，谁就站在了用户的必经之路上；没被选中的，就像网站没被搜索引擎收录，无声无息地消失。

所以SaaS接入AI生态，不是追时髦，而是每一轮入口迁移后都必须做的”重新被发现”的动作。当年叫SEO，后来叫ASO，今天叫MCP、叫接入Agent生态——名字换了，本质是同一件事：在新入口上争取被优先调用。

落到SaaS身上，是一句正在发生的话：你的产品未来大概率不是被”人”打开，而是被”Agent”调用。界面会贬值，但数据和能力不会——前提是，你得先把能力用AI能理解的方式交出去。

于是问题来了：怎么交？API、CLI、MCP、A2A，一堆名词，到底先做哪个、做什么、做到哪一步？我先给结论，免得你迷失在细节里：这四个词不是一条从低到高的流水线，而是四层结构——一层地基、两个入口、一个干活的员工、一层协作。

二、AI产品化的四层台阶

先看一张全景图：

下面一层一层讲。每一层，我都会说清楚它解决什么、做不好会卡在哪。

第0层：API——能力地基

查考勤、发工资条、算加班，这些功能本质都是API调用。API是你系统能力的本源，后面所有层都建在它上面。

很多人以为AI接入是个”新问题”，结果第一步就栽在最老的地方：你的功能根本没有对应的API。 一个很典型的场景是，你的考勤系统里有个”导出月度考勤表”的按钮，客户天天点，但它只是界面功能，背后没有暴露成接口。以前没关系，人点按钮就行；现在AI来了，它够不着这个按钮，只能去翻HTML、模拟点击，既慢又脆。你要让AI替你干活，第一件事就是回头把核心功能都补成API——能不能增删改查、覆盖率够不够高、支不支持批量操作。

爬不过去会卡在哪： 这是第一道门槛，而且是硬门槛。API不完整，后面MCP、Agent、A2A全是空中楼阁，你连上牌桌的资格都没有。所以很多SaaS做AI接入，头一两个月都在补API，这不丢人，这是补课。

第1层：CLI和MCP——能力对外交付的两种方式

API补好了，能力还躺在你自己的系统里，得把它交出去给AI用。这一层有两个并列的入口，很多人会搞混，以为CLI是MCP的前置、要先做CLI再做MCP。不是。它们甚至不在一个维度上——CLI是一种执行方式，MCP是一套接口协议。

CLI是把API包成一条条命令行命令，Agent像人敲键盘一样在终端里执行，参数从命令行传、结果从输出里读，跑完进程就结束，快、省、可靠，飞书CLI就是典型。MCP是Anthropic定的开放协议，把能力包装成带说明书的工具，任何Agent连上都能先通过tools/list发现、再通过tools/call调用，接口标准化、插上就能用。

用一句话区分：CLI是”自己人直接上手干活”，MCP是”对外开放的标准接口”——一个讲效率和成本，一个讲标准化和多租户。放到行业里看，金蝶在社区里被做成了MCP Server让Claude直接操作ERP单据，纷享销客、用友发布官方MCP接入文档让全线产品原生适配MCP，它们干的都是同一件事：把能力开放成标准接口。

爬不过去会卡在哪： 如果你只做了CLI、没做MCP，你的能力就只对”愿意装你客户端、用你凭证”的少数技术客户开放，进不了WorkBuddy、千问办公、Claude这些主流生态。能力有了，但对外营业的大门没开。至于CLI和MCP到底怎么选、为什么对SaaS来说MCP是主干，第三节会专门讲。

第2层：Agent——替你干活的员工

API是技能，CLI和MCP是把技能交出去的方式，但技能本身不是产品。真正能卖钱的，是那个用技能替你干活的”员工”。

这一层是把能力、知识、人设、记忆打包成一个完整的虚拟员工，让它调工具、读数据、做判断，把活干完。Moka就是个现成的例子：它没停在”给HR SaaS加个AI功能”，而是直接把产品升级成Moka AI，卖三位AI”同事”。

爬不过去会卡在哪： 如果你只做到第1层，客户买到的还是一堆工具，不是结果。工具按调用量收费，天花板清晰；员工按结果、按月、按人收费，想象空间完全不同。停在工具层，你还会被上游Agent双重收割——别人调你的工具，编排流程的利润归了别人。

第3层：A2A——员工之间的协作规矩

到了这一层，你的虚拟员工能干活了，但还出不了门。它只会调你自己系统里的工具，一旦客户的场景要跨系统——比如考勤要跟钉钉的审批联动、招聘要跟背调服务商协作——它就卡住了。

A2A解决的就是这件事：不同系统、不同厂商的Agent怎么互相派活、接活。靠一张”数字名片”（Agent Card），双方写明我是谁、会什么、怎么找我、怎么认证；任务从创建、执行、返回结果到双方留日志，全程有标准流程，出了问题能对账。回到开头的场景，客户的钉钉Agent把”处理张三的异常考勤”这个任务扔给你的考勤Agent，你的Agent自己决定怎么查、怎么跟OA协调，最后交付一个”已处理”的结果——这就是A2A在起作用。

爬不过去会卡在哪： 没有A2A，你的虚拟员工只能关在自己的系统里干活，跨系统闭环的场景会被别家抢走。但这一层是四层里最不急的，原因后面会讲。

把四层串起来，就是一条清晰的递进路径：API让程序能调你的能力，CLI让本地Agent能敲你的命令，MCP让所有Agent能自动发现并调用你，Agent把能力变成能卖钱的员工，A2A让员工能跟别的员工协作。你走到哪一层，AI产品化的程度就到哪一层。

三、两个最容易踩的误区

概念讲完了，有两个误区单独拎出来说，因为它们是最多人卡住的地方。

误区一：以为CLI更省更快，就该用CLI，不用做MCP。

这个直觉有一半是对的。Scalekit的基准测试显示，完成同一个任务，CLI能比MCP省最多32倍的token，可靠性也更高——这也是Perplexity的CTO、YC的CEO现在公开回归CLI、降低MCP优先级的原因，网上”CLI逆袭、MCP要凉”的说法就源于这些数据。

但这场争论从一开始就问错了问题。CLI和MCP的根本区别，不在于谁更省token，而在于——Agent在替谁干活。

如果Agent替你自己、替一个开发者干活，用你本地的凭证和权限，CLI又快又省，确实该用它。但如果Agent要替你的一万个客户干活，每个客户有自己独立的账号、权限、数据，CLI就塌了：它继承的是执行环境的凭证，做不到一个客户一套隔离、一张单据一级拦截、一次调用一条审计。而MCP天生就为这个场景设计——OAuth 2.1授权、多租户隔离、结构化审计日志，用户原来能看什么，AI以他的身份就只能看什么，每次调用留痕，这套东西客户才敢让你连数据。

所以结论不是谁取代谁，而是按场景分工：对内自己用、图快图省，CLI；对外给生态、给多客户开放，MCP。SaaS厂商做的是后一件事，所以对SaaS来说MCP是主干、CLI是本地补充——这也正是金蝶、纷享销客、用友们纷纷做MCP Server的原因，不是他们不知道CLI省token，而是他们要服务的是成千上万个客户的Agent。

误区二：以为A2A是MCP的升级版，做完MCP就该做A2A。

不是，它俩解决的是不同层级的问题。用MCP/CLI，别人的Agent调你的时候，你是工具，主从关系，它发命令你执行；用A2A，你是同事，协作关系，它把一整件事交给你，你自己规划、自己决定调什么工具、遇到问题还能反问它、干完活双方对账，反过来你也能把活派给它。判断标准很简单：被调用的东西会不会自己思考、自己判断、跨多次调用记着状态？会，它是Agent，该用A2A；不会，它是个无脑执行的能力，用MCP就够了。查个库存、发封邮件是工具，处理完一个员工整月的异常考勤是Agent的活。A2A的前置不是MCP，而是”你有一个会干活的Agent”——所以对大多数SaaS来说，A2A是远期题，不是当下题。

四、一家中小SaaS，现在该站在哪一级？

讲完概念，落到最实际的问题：团队小、资源紧、技术栈一般，最怕的就是”又要追一个新技术”。先吃颗定心丸：A2A生态现在是平台方和大厂在干活，微软Copilot Studio、AWS Bedrock、谷歌ADK都已经内置了A2A支持，你写的Agent接上去自动就会说”这种话”。中小SaaS真正该干的，不是自己造A2A，而是把MCP做好、把产品接进生态，借平台的力。

落地路径，其实是四个阶段的事，每个阶段都有明确的判断标准。

第一阶段：补API。 这是所有动作的地基，也是最容易被低估的一步。判断标准就一条：核心资源的增删改查覆盖率有没有过九成、支不支持批量操作。如果大量功能还只存在于界面上、API够不着，就先别想MCP和A2A，先把API补完。这一步过不了，后面全是白忙。

第二阶段：做MCP。 这是主干。别一上来就全系统一百个能力全上，挑一个高频、规则明确的只读场景，先做五到十个工具跑通，比如考勤查询、出勤明细导出。为什么是MCP而不是CLI？因为你要进生态，生态认MCP；CLI可以作为本地补充，但不是主干。这一步做完，你的能力才算真正”能被AI用起来”。

第三阶段：接生态。 入驻WorkBuddy、千问办公这类平台，让平台负责Agent间的协作，你只需要做好商务对接。这是大多数中小SaaS现在最该停的位置——借平台的流量和协议能力，比自己造一套划算得多。

第四阶段：等A2A。 这一层先别急着动。判断时机看几个信号：客户开始问”你们的AI能不能跟我们内部的Agent直接协作”，或者你入驻的平台发来接入规范要求Agent间协作，又或者你的虚拟员工产品里出现了”跨系统才能闭环”的客户场景。出现任何一个，再认真做A2A；在那之前，都不必动。真要做，工具也是现成的：官方SDK是开源的（pip install a2a-sdk，Python、JavaScript、Java、Go、C#、Rust都有），部署跟普通网站一样，放在现有服务器上就行，一个hello-world级别的A2A Server一天能搭完——你只需要写一张Agent Card加一个任务处理函数，协议细节SDK全包了。

落到最后，优先级只有一条：先把API补完整，再做MCP，CLI当本地补充，A2A等客户敲门。别被”新协议焦虑”绑架，也别为做而做。

到这里，你可以对着开头那张图给自己打个分了。四层台阶，你站在第几层？是还在补API的地基，还是已经把能力开放成了标准接口、甚至开始卖”员工”了？

写在最后

回到开头的客户。那句话说出口的时候，他其实不关心你用的是MCP还是A2A，他只关心一句话能不能把活干完。真正支撑那句”一句话”的，不是一个协议，而是你从API到Agent，一层一层把地基打扎实。

API是技能，CLI和MCP是把技能交出去的两种方式，Agent是用技能干活的员工，A2A是员工之间的协作规矩。四层台阶的尽头，是那个能替客户干活的虚拟员工——AI产品化的终点不在协议里，在你能把一个”员工”真正卖出去的那天。你现在手里有API、在补MCP、开始做Agent，这已经是很多人还没走到的地方。至于最上面那层A2A，等虚拟员工真的卖出去了，它自然会来敲门。到时候你花两天，就能给它开门。