Lovable CTO观点：SaaS的未来是Agent能调用的应用

从「人用应用」到「Agent用应用」的范式转移

Lovable，这家以AI驱动Web应用生成而闻名的公司，正在从单纯的应用构建工具，向基于MCP（Model Context Protocol）的「能力平台」演进。在与Lovable CTO Fabian Hedin的对话中，一个核心判断浮出水面：SaaS的未来，不再是为人类设计的界面，而是Agent能够直接调用的应用。

这一观点看似激进，实则是对当下软件形态演变的敏锐洞察。过去二十年，SaaS的成功建立在「以用户为中心」的产品哲学之上——精心设计的UI、流畅的交互、优雅的仪表盘。但当AI Agent开始成为软件的「使用者」时，这套逻辑正在被重新审视。Agent不需要漂亮的按钮，它需要的是清晰的、可编程调用的能力接口。

这里所说的AI Agent，并非简单的聊天机器人或自动化脚本，而是具备自主感知环境、制定计划、调用工具并根据反馈迭代执行的智能体系统。从技术架构上看，一个典型的AI Agent由大语言模型（LLM）作为"大脑"进行推理和决策，结合记忆模块（短期工作记忆和长期知识库）、规划模块（任务分解和执行策略）、以及工具调用模块（与外部系统交互）构成。当Agent需要完成"帮我预订下周三的会议室并发送邀请邮件"这样的复合任务时，它需要自主判断应调用哪些应用的哪些能力、以什么顺序执行、如何处理中间步骤的异常——这对底层应用的接口标准化程度提出了极高的要求。

MCP协议：连接AI Agent与应用的通用标准

MCP（Model Context Protocol）是理解Lovable战略转向的关键。作为一种开放协议，MCP旨在标准化AI模型与外部工具、数据源之间的交互方式。它扮演的角色类似于「AI时代的API标准」——让Agent能够以统一的方式发现、理解并调用各类应用的能力。

值得补充的是，MCP由Anthropic于2024年底正式提出并开源，其设计灵感部分来源于LSP（Language Server Protocol）——一种在IDE领域已经被广泛验证的标准化协议思路。LSP由微软在2016年为VS Code开发并开源，其核心创新在于将编程语言的智能功能（自动补全、跳转定义、错误诊断等）从具体的编辑器实现中抽离出来，定义为一套标准协议。在LSP出现之前，每种编程语言要在每种编辑器中提供智能支持，需要实现M×N个适配器（M种语言×N种编辑器），这是一个O(M×N)的复杂度问题。LSP通过引入中间协议层，将复杂度降至O(M+N)——每种语言只需实现一个Language Server，每种编辑器只需实现一个LSP Client。MCP在AI工具调用领域复制了完全相同的架构思想：每个应用只需实现一个MCP Server，每个Agent框架只需实现一个MCP Client，从而避免了Agent×应用的集成爆炸问题。

MCP采用了JSON-RPC 2.0作为通信基础，定义了工具（Tools）、资源（Resources）和提示（Prompts）三大核心原语，使AI Agent可以通过统一的接口描述发现和调用外部能力。其中，工具（Tools） 是Agent可以主动调用的操作，类似于函数调用，例如"发送邮件"或"查询数据库"；资源（Resources） 是Agent可以读取的数据源，类似于RESTful API中的GET端点，例如"获取用户日历"或"读取文档内容"；提示（Prompts） 则是预定义的交互模板，帮助Agent以最优方式使用特定工具或资源。这三大原语的区分使得MCP能够清晰地表达应用能力的不同维度——可执行的操作、可访问的数据、以及推荐的使用方式。

MCP选择JSON-RPC 2.0作为底层通信协议并非偶然。JSON-RPC是一种轻量级的远程过程调用协议，相比RESTful API更适合双向通信和有状态会话场景。在MCP的架构中，AI Agent（MCP Client）与应用（MCP Server）之间需要维持会话上下文，支持能力发现（tools/list）、资源订阅和动态提示等交互模式，这些需求更贴合RPC的请求-响应范式而非REST的资源导向范式。同时JSON-RPC天然支持批量调用和通知（Notification）机制，便于Agent在一次交互中发起多个工具调用请求。MCP目前支持两种传输方式：stdio（标准输入输出，适用于本地进程间通信）和基于HTTP的Server-Sent Events（SSE），后者适用于远程服务场景。2025年初，MCP社区还在推进Streamable HTTP Transport规范，以更好地支持云端部署和大规模并发调用场景。

这一协议的出现填补了一个重要空白：此前各大LLM厂商虽然都支持Function Calling，但每家的实现方式、参数规范和错误处理机制各不相同，导致开发者需要为不同模型重复编写集成代码。

Function Calling是LLM与外部世界交互的核心机制，其技术原理是在模型推理过程中，通过特殊的系统提示和输出格式约束，让模型在判断用户意图需要调用外部工具时，不直接生成自然语言回复，而是输出结构化的JSON对象描述函数名称和参数。调用方（通常是应用层的编排逻辑）解析这一JSON，执行实际的函数调用，将结果返回给模型，模型再基于函数返回值生成最终回复。这一机制本质上让LLM具备了"感知-决策-执行"的闭环能力，是构建AI Agent的技术基石。

具体来说，OpenAI在2023年6月率先在GPT-3.5/4 API中引入Function Calling能力，允许模型在对话过程中识别用户意图并输出结构化的函数调用请求，而非纯文本回复。随后Google Gemini、Anthropic Claude、Meta LLaMA等模型纷纷推出类似功能，但参数命名、调用流程、错误返回格式各不相同。例如OpenAI使用tools数组定义函数签名，而早期Anthropic采用XML标签嵌入工具描述。这种碎片化迫使开发者维护多套适配层，极大增加了集成成本。MCP的出现正是试图在应用侧建立统一的能力暴露标准，使得无论上游使用哪个LLM，应用端只需实现一次MCP Server即可被任何兼容的Agent调用，从而终结这种碎片化局面。

值得注意的是，MCP并非唯一试图解决这一问题的方案。Google在2025年4月推出的Agent2Agent（A2A）协议侧重于Agent与Agent之间的通信与协作，而非Agent与工具之间的交互，两者定位互补而非竞争。此外，OpenAI也曾提出过自己的插件（Plugin）标准，但在2024年逐步淡出，目前业界呈现出MCP在Agent-to-Tool层面逐渐收敛为事实标准的趋势。

为什么MCP对AI Agent生态至关重要

在传统的软件集成中，每个SaaS产品都有自己的API规范、认证机制和数据格式，开发者需要为每一次集成付出大量工作。而当AI Agent成为集成的主体时，这种碎片化会成为致命瓶颈——Agent无法像人类工程师那样阅读文档、理解语义、编写适配代码。

MCP通过提供标准化的「能力描述」，让Agent能够自动发现应用提供的功能，并以可预测的方式调用它们。这意味着，未来一个AI Agent可以在无需人工干预的情况下，串联起支付、日程、文档、通信等多个应用的能力，完成复杂的端到端任务。

然而，这种Agent自主串联多应用的愿景在技术上仍面临多重挑战。首先是权限管理问题——OAuth 2.0等现有授权框架是为人类用户设计的，涉及浏览器重定向和用户交互式授权，而Agent需要一种无需人工介入的委托授权机制（Delegated Authorization）。OAuth 2.0的标准授权流程（Authorization Code Flow）本质上假设了一个「坐在屏幕前的人类用户」：用户被引导到授权服务器登录并批准权限，然后带着授权码重定向回应用。当Agent代替人类执行操作时，出现了几个核心矛盾：Agent无法完成浏览器交互、Agent的权限范围应由谁界定、Agent是否应获得与人类用户等同的权限。

目前业界正在探索多种解决方案，包括OAuth 2.0的Device Authorization Grant（RFC 8628）——这一机制最初是为智能电视、IoT设备等输入能力受限的设备设计的授权流程。其工作方式是：设备向授权服务器请求一个用户码和验证URL，用户在另一台设备（如手机）上访问该URL并输入用户码完成授权，设备端通过轮询获取访问令牌。这一流程天然适配Agent场景——Agent作为"无界面设备"请求授权，人类用户在独立的界面上审批，实现了授权行为与Agent执行行为的解耦。此外还有基于Service Account的长期凭证方案、以及MCP社区正在讨论的分层权限模型——即用户一次性授权Agent在特定范围内代为操作，类似于银行的有限委托书机制。Google的Agent2Agent（A2A）协议也在尝试解决Agent间的身份验证和信任传递问题。

其次是幂等性与错误恢复：当Agent调用支付接口失败后是否应该重试？重试是否会导致重复扣款？这类问题在人类操作场景中可以通过界面提示解决，但在Agent自主执行时需要严格的事务语义保障。幂等性（Idempotency）是分布式系统设计中的关键概念，指同一操作执行一次与执行多次产生的效果完全相同。在Agent场景中，由于网络不确定性和多步骤任务的复杂性，Agent可能因超时或网络抖动而对同一请求发起重试。Stripe等支付平台通过Idempotency Key机制解决了这一问题——每次请求附带一个唯一标识符，服务器据此判断是否为重复请求。MCP协议若要支持金融级应用，需要在协议层面定义类似的幂等性语义。

此外，多Agent协作场景下的状态一致性、调用链的可观测性（Observability）和审计追溯（Audit Trail）也是企业级应用必须解决的基础设施问题。可观测性在Agent编排场景中尤为关键——一次用户请求可能触发Agent对5-10个不同MCP Server的串行或并行调用，每次调用都涉及不同的延迟、错误率和数据转换。OpenTelemetry等开放标准为分布式追踪提供了基础，但Agent特有的"推理-决策-执行"链条引入了新的追踪维度——不仅需要记录每次API调用的技术指标，还需要记录Agent在每个决策节点的推理依据，以便在出现错误时进行根因分析和责任归属判定。这些挑战意味着MCP要从协议规范走向生产级落地，还有大量的工程工作需要完成。

Lovable的战略延伸：从造应用到造Agent能用的应用

Lovable最初的定位是让任何人都能通过自然语言快速生成Web应用。这一能力已经证明了AI在降低软件开发门槛上的巨大价值。而如今，Hedin所描述的「MCP-powered capabilities」，实际上是这一使命的自然延伸。

要理解这一战略延伸的意义，有必要了解Lovable所处的行业位置。Lovable（前身为GPT Engineer）是AI驱动代码生成赛道的重要玩家之一，与Bolt.new、V0 by Vercel、Replit等产品构成竞争格局。这一赛道的核心理念是将自然语言转化为可运行的全栈Web应用，通常基于React/Next.js等现代前端框架自动生成代码，并集成Supabase等后端服务实现数据持久化。

Supabase之所以成为这类AI代码生成工具的首选后端，在于其技术架构的AI友好性。作为一个开源的Firebase替代方案，Supabase提供PostgreSQL数据库、实时订阅、身份认证、边缘函数和对象存储等后端即服务（BaaS）能力。它的声明式数据库管理（通过SQL迁移文件）、自动生成的REST/GraphQL API、以及Row Level Security（RLS）行级安全策略，使得AI模型可以通过生成标准SQL和配置文件来完成完整的后端搭建，而无需处理复杂的服务器运维逻辑。

从竞争格局的细节来看，这些产品已经形成了差异化的技术路径：V0由Vercel推出，专注于基于shadcn/ui组件库的前端UI生成，强调与Next.js生态的深度集成；Bolt.new由StackBlitz开发，基于WebContainers技术在浏览器内运行完整的Node.js环境，支持即时预览和一键部署；Replit则从在线IDE起步，通过Replit Agent提供从需求理解到代码生成、调试、部署的全流程自动化。Lovable的差异化在于强调「production-ready」的代码质量和对Supabase等后端服务的深度集成。这一赛道的技术底层通常依赖Claude或GPT-4级别的大语言模型，结合精心设计的System Prompt和代码模板来保证生成质量。值得注意的是，这些产品正在从「单次生成」向「持续迭代」演进——支持用户通过自然语言对已生成的应用进行修改、调试和功能扩展，这对底层模型的代码理解和上下文管理能力提出了更高要求。

Lovable在2024年经历了品牌重塑和产品重构，强调「可部署级别」的代码质量而非仅仅是原型级输出。这一赛道的快速演进表明，AI正在从「辅助写代码」（如GitHub Copilot的补全模式）迈向「直接生成完整应用」的新阶段。GitHub Copilot代表的是"AI辅助编程"的第一阶段——开发者仍然掌控代码结构和架构决策，AI在行级或函数级提供补全建议。而Lovable等工具所代表的第二阶段，AI接管了从项目初始化、路由设计、组件拆分、状态管理到API集成的全栈决策过程，开发者的角色从"写代码"转变为"描述需求并审查输出"。而Lovable此次向MCP兼容性的延伸，则标志着它试图从「代码生成工具」跃迁为「Agent生态基础设施」，开启第三阶段——生成的应用本身成为Agent生态的组成部分。

如果说第一阶段是「让人人都能造应用」，那么第二阶段就是「让人人造的应用都能被Agent使用」。当用户通过Lovable生成的应用天然具备MCP兼容性，这些应用就不再是孤立的产品，而是可以被更大的Agent生态系统调用的「能力节点」。

生态飞轮的想象空间

这里蕴含着一个潜在的生态飞轮：

• 越多的应用支持MCP协议，AI Agent能完成的任务就越丰富
• Agent能力越强，用户构建MCP兼容应用的动力就越足
• 应用生态越繁荣，整个平台的网络效应就越显著

这一飞轮效应的经济学本质是跨边网络效应（Cross-side Network Effects）：MCP Server（应用侧）数量越多，Agent的能力越强，吸引更多用户使用Agent；用户对Agent的使用越频繁，应用开发者接入MCP的商业激励越大。这与App Store、外卖平台的双边市场逻辑高度类似。然而，所有双边市场都面临经典的"鸡与蛋"冷启动问题：在Agent能力有限的早期阶段，如何激励足够多的应用率先支持MCP？Lovable通过让生成的应用"天然MCP兼容"，本质上是在供给侧大幅降低冷启动门槛——开发者无需额外投入即可让应用进入Agent生态，从而加速飞轮的启动。

Lovable试图在这个飞轮的早期占据关键位置——既是应用的生产者，也是能力协议的推动者。

对SaaS行业的深远影响

Hedin的判断如果成立，将对整个SaaS行业产生结构性冲击。

产品设计重心的转移

产品设计的重心可能从UI/UX转向能力接口的设计。 当主要「用户」变成Agent时，产品团队需要思考的不再仅是「界面是否易用」，而是「能力是否易于被机器发现和调用」。

这一转变在设计理念上要求产品团队进行根本性的思维重构。传统的分层架构中，业务逻辑通常深度耦合在UI层——表单验证、流程引导、异常处理都通过界面交互完成。而Agent友好的架构要求将业务能力彻底抽象为独立的、自描述的服务层，UI和Agent接口分别作为这一能力层的两个「消费端」。这与近年来兴起的「Headless」架构思潮一脉相承。

Headless架构的核心思想是将内容管理/业务逻辑层与表现层完全解耦，通过API连接两者。这一理念最早在CMS领域得到实践——Contentful、Strapi等Headless CMS允许内容通过API分发到网页、移动App、IoT设备等任意终端。随后这一模式扩展到电商领域（Commercetools、Shopify Hydrogen），以及认证（Auth0）、支付（Stripe）等垂直场景。Headless架构的成功证明了一个关键命题：当业务能力被干净地抽象为API，它就能服务于任何类型的消费端——无论是浏览器、移动端，还是如今的AI Agent。从这个角度看，MCP兼容性本质上是Headless架构在AI时代的自然延伸：Agent成为了又一个新的能力消费端。

实际上，Stripe、Twilio等API优先公司多年前就证明了这种架构的商业价值，只是在Agent时代，这一需求从开发者群体扩展到了每一个SaaS产品——不仅仅是面向技术用户的基础设施产品需要优秀的API，连面向普通用户的协作工具、项目管理软件也需要提供Agent可调用的标准化能力接口。这意味着，未来SaaS产品的核心竞争力评估维度将增加一项——DX（Developer Experience，开发者体验）中的AX（Agent Experience，Agent体验）：接口文档是否机器可读？错误返回是否语义清晰？能力边界是否明确？这些过去主要影响开发者效率的因素，在Agent时代将直接影响产品的市场竞争力。

分发渠道的重构

SaaS的分发逻辑可能被彻底改写。 在Agent主导的世界里，应用不再依赖用户主动打开、点击、使用，而是被Agent按需调用。这意味着传统的用户增长、界面留存等指标，可能让位于「被调用频次」「能力覆盖度」等新型度量。

这种分发渠道的根本性变革在SaaS历史上并非首次发生。从2000年代的桌面软件到Web应用、从Web到移动端App Store分发、再到2010年代Slack等平台催生的「Workflow内嵌式SaaS」，每一次计算范式的迁移都伴随着分发逻辑的重构。当前Agent驱动的分发变革，与Salesforce AppExchange或Shopify App Store的平台化分发有相似之处——应用的价值不再完全由终端用户直接感知，而是通过平台（或Agent编排层）间接触达。

Stripe是一个经典的「API优先」公司范例：它从未拥有面向消费者的界面，却通过卓越的开发者体验和API设计成为支付基础设施的巨头。在传统模式下，支付公司需要通过面向商户的销售团队和品牌营销来获客；而Stripe通过让开发者"7行代码接入支付"，将分发渠道从商务谈判转移到了GitHub和技术文档。这一模式的核心洞察是：当集成成本趋近于零时，产品的分发就可以通过代码本身的传播性实现自增长。在Agent时代，这一逻辑将进一步极化——最成功的应用未必是用户直接看到的那个，而是被Agent最频繁调用的那个。SaaS公司的增长指标可能从DAU（日活跃用户数）转向DAC（Daily Active Calls，日活跃调用数），从用户留存率转向Agent选择率。

竞争壁垒的重塑

SaaS的护城河正在发生变化。 过去的竞争优势往往是品牌、界面体验和用户习惯，而在Agent时代，谁能提供更可靠、更标准化、更易组合的能力接口，谁就更可能被纳入Agent的工作流。

这一变化的深层含义在于，数据网络效应和API生态锁定可能取代界面层的用户习惯锁定，成为新的核心壁垒。当Agent在大量调用中积累了对某一应用能力接口的信任（低错误率、高可用性、语义一致性），切换到竞品的隐性成本不在于用户需要重新学习界面，而在于Agent工作流中的所有上下游依赖都需要重新验证和适配。这类似于企业级软件中的"系统集成锁定"效应，但发生在Agent编排的自动化层面，其切换成本甚至可能更高——因为Agent的决策逻辑是基于大量历史交互隐式学习的，而非人类可以显式迁移的操作习惯。

机遇与不确定性并存

「Agent能用的应用」这一愿景仍处于早期阶段。MCP作为一项相对年轻的协议，其标准化程度、安全模型、商业化路径都还在探索之中。Agent自主调用多个应用完成任务，也带来了权限管理、错误处理、责任归属等一系列尚未完全解决的问题。

在商业化路径方面，MCP生态的价值分配机制尚不明朗。在传统SaaS模式中，定价模型清晰——按席位（per seat）、按用量（usage-based）或按功能层级（tiered pricing）收费。而在Agent调用模式下，几个根本性问题浮现：Agent代替了10个人类用户的工作，SaaS公司是按1个Agent席位收费还是按10个等效用户收费？按API调用量计费是否会因Agent的高频调用而产生意想不到的成本结构？MCP Server的维护和运营成本由谁承担？这些问题的答案将直接影响SaaS公司拥抱Agent生态的商业意愿。

此外，人类用户在可预见的未来仍将是许多软件的直接使用者。UI并不会消失，而是可能与Agent接口形成「双轨并存」的格局。真正的挑战在于，如何让一款应用同时服务好人类和Agent两类「用户」。这种"双模态"产品设计在技术架构上要求干净的关注点分离——业务逻辑层、人类交互层和Agent交互层需要能够独立演进。一些前沿的SaaS公司已经开始实践这一模式：Notion在保持其标志性的所见即所得编辑器体验的同时，推出了MCP集成，让Agent可以通过协议直接创建、查询和修改页面内容。

不过，Lovable的这一战略转向至少揭示了一个值得关注的方向：随着AI Agent能力的不断增强，软件的形态、构建方式和使用方式都可能被重新定义。对于开发者和SaaS从业者而言，现在或许正是思考「如何让你的应用被Agent理解和使用」的时刻。

核心要点

核心要点

核心要点