三段演化：关系在换位
智能体与 SaaS 的关系不是静态的「竞争或互补」，而是一条正在展开的演化线，三个阶段的「主客关系」在换位。
阶段一：SaaS 接插件（智能体是功能）。SaaS 厂商在自己的产品里加 AI 助手（写邮件、总结文档、生成报表）——智能体是产品的一个功能按钮。这个阶段已基本普及，但多数「AI 功能」的使用率惨淡（用户试过就放下），原因不是技术而是嵌入方式：把对话框塞进传统 UI，用户不知道何时该用它、它也不理解产品的完整上下文——「加了 AI」与「变成智能体」是两回事。
阶段二：Agent 调用 SaaS（智能体是界面）。用户不再打开 SaaS 的界面，而是让智能体去完成任务——智能体通过 API 或浏览器操作（本库浏览器智能体篇）调用 SaaS 的能力（「帮我在项目管理工具里建一个季度计划」）。这个阶段正在发生，冲击直指 SaaS 的商业模式根基：UI 即产品的护城河被动摇——SaaS 的差异化很大程度在界面体验（这是它对桌面软件的胜利），当界面可以被智能体绕过，「用谁的界面」不再是用户的决策点，「完成任务的权」才是。
阶段三：Agent-Native（产品围绕智能体重设计）。新生的产品不做「传统界面 + AI 助手」，而是以智能体为中心重新设计：用户表达意图与验收结果，智能体负责中间的一切（数据组织、流程执行、界面按需生成）。这个阶段的产品形态还在实验期（「生成式 UI」——界面按任务动态生成——是最被讨论的形态），但方向已经清晰：产品的主要「用户」可能不再是人，而是智能体。
flowchart LR
S1["阶段一：SaaS 接插件<br>智能体是功能按钮<br>（已普及、使用率惨淡）"] --> S2["阶段二：Agent 调用 SaaS<br>智能体是使用界面<br>（进行中，冲击 UI 护城河）"]
S2 --> S3["阶段三：Agent-Native<br>产品围绕智能体重设计<br>（实验期）"]
S1 -.->|"加 AI ≠ 变智能体"| S1
S2 -.->|"界面绕过：从用界面到要结果"| S2
S3 -.->|"主要用户可能是智能体"| S3
阶段二的冲击与厂商的两难
阶段二对 SaaS 厂商的冲击要拆成两层看。商业层的冲击：计费与价值锚点。SaaS 按席位收费的前提是「每个席位的人在使用界面」——当智能体替人操作，席位计费的基础松动（一个智能体用十个「席位」的能力，该收谁的钱）；API 计费 vs 界面订阅的价差会被套利者利用（「用智能体走 API 干订阅用户的活」）。数据层的冲击：黏性的来源。SaaS 的黏性很大程度在「用户的数据与工作流都在里面」——智能体时代数据还在（这层黏性保留），但「用户每天打开界面」的行为黏性消失，厂商失去的不仅是流量入口，是用户注意力的阵地（升级、增购、反馈的触点全在界面上）。
厂商的两难在于配合还是抵抗：开放 API 与 MCP server（欢迎智能体调用）能吃到阶段二的红利（成为智能体生态的「被调用的能力」），但加速界面价值的稀释；封闭则保护了现有收入，但可能错过成为「智能体时代基础设施」的船票。观察到的应对光谱：积极派把「被智能体调用」产品化（开放的 MCP server、面向 Agent 的 API 产品线、按调用的计费体系）；防守派用「AI 功能自家做」的路线把用户留在自家界面；摇摆派两边下注。行业经验值：To B 的 SaaS 反而相对从容（企业客户要的是数据与流程在自家体系内，智能体也是部署在体系内），To C 与轻量协作工具的焦虑最重（它们的价值大量在界面与入口）。
Agent-Native：新形态的三个设计问题
阶段三的产品还在原型期，但设计问题的轮廓已经出现。问题一：验收界面怎么设计。智能体做完事，人怎么验收？「生成式 UI」（按结果动态生成可视化界面）是最被讨论的答案，但生成的界面如何保证「可信任」（用户怎么知道界面如实反映了智能体的工作）是未解的新题。问题二：意图的表达精度。传统产品的「所见即所得」降低了沟通成本，Agent-Native 的「所说即所做」把全部压力放在意图表达的精确性上——用户的自然语言意图有歧义，产品要么追问澄清（体验变重）、要么做出假设（出错变多）——这个权衡是 Agent-Native 产品的核心设计张力。问题三：渐进披露的控制权。用户对智能体的控制从「每步操作」变成「意图与验收」，中间过程的控制权如何按需交还（「让我看看你是怎么想的」「这一步按我的方式来」）——控制粒度的设计决定产品的适用人群（全自动派与盯梢派都存在）。
对新创团队的机会判断：「传统 SaaS + 智能体外挂」的红海不值得进（在位厂商的功能升级就能覆盖），「某个工作流的 Agent-Native 重做」是真正的新地——选一个「界面复杂但任务简单」的传统 SaaS 品类（用户学会它花了很久、实际要完成的事很简单——这正是界面冗余的证据），用智能体重做它的核心任务。这个选择标准本身，就是三段演化论的实用输出。
Agent-Native 的先行样本：三个品类的重做实验
「Agent-Native 重做」（正文第三阶段）已经出现了先行实验，三个品类的样本值得解剖。品类一：数据分析的重做。传统 BI 工具的界面复杂度臭名昭著（学会拖拽与建模要培训数天），但用户实际要完成的任务很简单（「上个月各区域卖得怎么样」）——Agent-Native 重做的形态：用户用自然语言提问，智能体完成查询、建模、可视化与解读，界面只呈现结论与可下钻的证据链。样本的经验：界面冗余最大的品类，重做的阻力反而最小（用户不怀念旧界面）。品类二：招聘筛简历的重做。传统 ATS 的界面流程（建职位、筛简历、排面试）冗长，任务是明确的（找到最匹配的候选人）——重做后：智能体读完所有简历与职位需求，直接给出排序与理由，人做终审与沟通。这个样本的教训：筛简历的偏差问题（智能体的筛选标准继承数据的偏见）让 Agent-Native 产品在合规审查上更重——重做不只是体验问题，还是责任问题。品类三：客服后台的重做。传统客服工单系统的界面（多面板、多状态、多跳转）为人的操作效率设计，Agent-Native 版本：智能体处理全部常规工单，人工界面只呈现「需要我处理的例外」——界面从「操作台」变成「例外清单」，人类的界面时间缩减一个数量级。三个样本的共同公式：找「界面复杂度 / 任务简单度」比值最高的品类重做——比值高说明传统产品在为「人操作」支付的复杂度已经到了智能体时代可以全部拆除的程度。
SaaS 厂商的自检三问：你在演化的哪一段
三段演化（正文）给 SaaS 厂商一面镜子，三个自检问题定位自己。问题一：你的 AI 功能使用率是多少——低于 20%（用过一次不再用）说明你在阶段一且做得不好：AI 功能与产品上下文是割裂的（助手不理解产品里的数据与流程），要先修融合再谈演化。问题二：有没有外部智能体在调用你的 API——没有（或你没监控过）说明你还没进入阶段二的视野：先建 MCP server 或 Agent 友好的 API、开始统计「机器流量占比」，这是阶段二的仪表盘。问题三：如果明天所有用户都改用智能体操作你的产品，你的收入掉多少——这个思想实验直接量化「UI 护城河」的厚度：收入主要按席位（界面使用）计的厂商掉得最惨，按数据存储与计算量的掉得最少——掉得多的厂商，阶段二的紧迫感应该与掉的比例成正比。三问的答案合成厂商的演化定位与行动优先级：阶段一的修融合、阶段二的建仪表盘与开放、焦虑最重的考虑直接布局 Agent-Native 的新产品线（用新品牌试水，不背旧产品的包衹）。
阶段二的中间形态：SaaS 的「双面门面」
阶段二（Agent 调用 SaaS）里出现了一个中间形态，值得单独记录：SaaS 的「双面门面」——同一套能力，两个入口：人的界面（传统的 Web UI，继续迭代但不加新功能）+ 机器的界面（MCP server / Agent API，新能力全部首发在这里）。这个形态的动机：厂商既不想放弃存量界面用户（收入与习惯），又要抢「被智能体调用」的增量（新场景与新计费）——双面门面是两难（正文）的最小阻力解。它的演化含义：机器界面与人的界面的功能差距会持续拉大（新能力首发在机器侧），最终「机器界面」进化为产品的主界面、「人的界面」退化为「管理控制台」（看配置、看账单、做例外处理）——UI 从产品退化成管理面板，是 SaaS 进入 Agent-Native 的临门一脚。观察双面门面的「功能差距曲线」（机器侧新功能数 − 界面侧新功能数），可以量化每个 SaaS 厂商的转型决心——差距拉得越开，转型越坚决；差距为零的，是在观望。
小结
智能体与 SaaS 的关系在穿三段演化：接插件（功能按钮，已普及但使用率惨淡——加 AI 不等于变智能体）、被调用（智能体成为使用界面，正在发生——UI 护城河被动摇，计费与注意力阵地受冲击，To C 焦虑重于 To B）、Agent-Native（产品围绕智能体重设计，实验期——验收界面、意图精度、控制权粒度是三大设计题）。厂商的两难是配合（吃到被调用红利、稀释界面价值）与抵抗（守住存量、错过基础设施船票）。新创团队的机会在「界面复杂但任务简单」品类的 Agent-Native 重做——界面冗余是传统 SaaS 留给智能体时代的拆迁区。
读者留言
COMMENTS 暂无还没有留言，来说第一句？