Runwise 增长研究院

2026-10-13

Runwise 增长研究院

10/13/2026
企业AI创新

百万商家已在用Agent，但Meta广告收入仍占97.6%。从商家对话到企业工作流，Meta如何把AI能力变成可负责、可收费的企业服务？

30秒看懂：Meta进军企业AI不是从零开始：已有超百万商家使用Business Agent，但2026年Q2广告收入仍占97.6%。新成立的Enterprise Platform要把Muse、Agent、API和代码工具组织成企业能使用、能控制、也愿意付费的服务。真正的挑战不是模型能力，而是把分散的AI能力变成有权限、有审批、可验收的业务流程，并证明可复制交付与商业回报。

百万商家使用Agent，Meta的收入仍高度依赖广告

2026年9月28日，Meta宣布组建Enterprise Platform，将企业AI列为新的业务支柱。公司计划将Muse、Meta Business Agent、Muse API和Muse Code等能力带给企业与开发者，并宣布由CJ Desai担任首席企业平台官，直接向扎克伯格汇报。

这件事看似是消费互联网巨头突然转向企业市场，但Meta并非从零出发。早在当年6月，公司就披露，已有超过一百万家商户使用Business Agent在WhatsApp和Messenger上接待客户。广告主、商家和开发者也早已是它的商业生态参与者。

Meta原有模式的优势，在于把用户注意力和商家的获客需求接到同一个平台。企业无需另建庞大的消费者网络，就能通过广告和消息接触客户；平台则可以把相对标准化的产品卖给大量商家。这种规模不是新企业软件公司能够轻易取得的起点。

财报揭示了这套模式有多重要。2026年第二季度，Meta总收入为608.01亿美元，广告收入为593.63亿美元，按两者相除计算，广告占比约97.6%。企业AI因此不是填补一块无业务的空地，而是在已经非常成功的广告商业模式之外，寻找更深的客户经营关系。这个占比也提醒人们，不能因新品密集发布，就认定新的收入结构已经形成。

从客户对话拓展到企业工作流，Meta选择单列企业业务

真正值得研究的反差是：有商家使用、有客户入口、有模型和算力，为什么还需要成立一个新的企业业务？这些优势能够带来第一次试用，却未必能够直接换来企业持续采购。买一项提高广告表现的服务，与让供应商介入订单、客户资料和日常经营，交出的责任不同。

但关系加深会改变服务要求。广告投放者关心的是预算能否换来有效触达与转化；让Agent处理经营任务的人，还必须判断它看到了什么数据、能够修改什么、出错后由谁接手。一旦动作跨进原有软件，模型的表现就开始受库存、价格、账号授权和接口状态共同约束。

小企业与大企业又不是同一种用户。老板本人可能同时负责内容、账目和客户沟通，能亲自决定某项动作；大企业里，使用者、预算负责人和系统管理员往往不是同一个人。消费级产品中一个顺滑的授权按钮，进入组织后还要回答责任分配问题。这里说的是两类采购场景的差别，并不意味着Meta已经公开提供了完整的企业治理方案。

截至9月30日，Enterprise Platform刚宣布两天，谈成功尚早。但把它此前的产品、权限设计和客户部署连起来，已经能看见一个具体转向：Meta正在尝试把分散的AI能力，组织成企业能使用、能控制、也愿意付费的服务。它要补的课，远不止提高模型回答质量。

Meta如何从商家Agent走向企业AI平台？五项关键创新战略与落地实践

1. 产品创新：顾客侧Business Agent与经营者侧Muse分别解决不同任务

Meta并没有只拿出一个通用聊天入口。Business Agent首先代表商家面对顾客，任务包括回答问题、推荐目录中的商品、预约、筛选线索，并允许商家决定何时由团队成员接手。9月29日宣布的Muse for Small Business，则把新的技能和连接器加入Muse，帮助经营者处理手头的工作。

这两类产品的责任方向不同。顾客问租车有没有库存，需要得到一家企业可兑现的答复；老板让Agent查看销售情况，则需要它理解多个工具里的经营信息。前者影响对外服务的一致性，后者影响内部判断与执行。把两者都叫Agent，容易掩盖用户、任务和授权方式的区别。

商家侧应用的工作单位可以非常具体：顾客提出商品或服务需求，Agent依据商家已有的目录与规则回应，遇到需要人工判断的请求再移交员工；经营者侧Muse则从经营者授权的多个工具取得信息，形成建议，并在发送、发布或支付前等待批准。它们可能共享模型能力，使用者、系统边界和成功指标却不同。前者先看对话处理与订单进展，后者还要看业务负责人节约了多少核对与协调工作。

Meta在7月财报电话会上还介绍了面向大型商家的Meta Business Agent Platform：它允许企业在WhatsApp上构建和部署自己的Agent，并提供相应控制、规则和衡量能力。这与9月新成立的Meta Enterprise Platform不是同一个概念。前者是已经开始服务具体消息场景的平台，后者是准备把Muse、模型API、代码工具和商家Agent组织到更宽的企业业务中。区分两者，才能既承认Meta已有B2B产品基础，也不提前宣布全栈集成完成。

对Meta来说，这种区分有商业意义。它可以沿已有商家触点向里走，也可以把个人Agent的执行能力带到经营者身边。但产品组合的宽度不等于产品已经相互打通。Enterprise Platform公告列出全栈方向，是业务范围的声明，不能据此假设所有产品已经共享同一份企业数据、权限和合同。

Muse的官方设计文章提供了更细的产品线索：后台工作需要让用户看到活动，长期任务需要目标跟踪，关键动作需要明确接受或拒绝的审批界面。这些安排回应的是一个实际问题——当软件会继续工作，用户就不能只凭最近一条聊天回复判断任务到了哪里。

由此可以看出，产品化不仅是把模型包成界面。能否知道任务是否完成、能否中途介入、能否看见已经批准的动作，都会影响经营者是否敢继续使用。若这些环节缺失，用户需要不断询问和检查，名义上的自动化便可能把工作转移成新的监督负担。

2. 生态与集成：用连接器进入原有经营软件，但不代替数据治理

Muse for Small Business的发布采用了一个务实入口：让Agent接入商家已经使用的工具，包括Shopify、Intuit QuickBooks、Slack，以及Facebook和Instagram商业账号。它没有要求经营者先搬迁全部工作，再获得AI服务。

这种选择有助于降低迁移门槛，但连接器只是合作的起点。以经营分析为例，同样叫销售额，订单、退款、到账可能对应不同时间；即使几个软件都成功授权，也不意味着其数字可以直接相加。这是采用跨系统Agent时需要处理的业务口径问题，不能交给模型凭语感补齐。

Meta的连接器帮助文档显示，对于现成列表之外的服务，可以创建自定义连接器。这给企业留下扩展空间，同时把一部分安全核验责任留给接入方：Meta明确说明，不审核自定义连接器及其如何使用信息。企业若要据此连接内部系统，就需要自己确认访问范围和数据流向。

Muse for Small Business的官方发布在支持工具之外明确强调：发布、发送和花钱仍需用户批准。这个设计使接入顺序有了一个可行的分层：先将常用业务软件授权连接，让Agent读取与整理；再让负责人审阅跨来源结果；最后才对外发送或在原系统写入。这里是产品公开控制能力所支持的部署路径，不是Meta已经替所有客户完成的通用实施方案。

还有一个容易忽视的细节：断开连接器，会停止Muse继续与其交换数据，但此前用于任务的信息可能仍保留在记忆或对话历史中。这意味着“停止接入”和“清除已经留下的信息”是两个动作。实际部署如果只教用户如何连接，不说明如何收回授权和处理留存，交付就没有覆盖完整使用周期。

需要被纳入交付的还不只是第一次授权。比如Shopify中的订单状态变了，QuickBooks的退款或回款口径也可能同步变化；如果Agent在最初授权时只被校验过一次，后来的建议仍可能使用过期资料。企业实际验收应检查接口失效、授权收回、字段更新与历史留存，分清平台承诺负责的部分与自己必须维护的部分。Meta公开了连接和断开的规则，但没有公布所有第三方应用的长期维护时效。

因此，接口数量不能单独作为企业能力的成绩单。真正影响使用的是，接进来的资料是否适合当前任务，Agent能执行哪些动作，以及连接发生变化后如何处理。Meta的标准连接与自定义扩展提供了不同选择；哪一种可在具体企业长期运行，仍要回到客户系统验证。

连接器还能改变客户对供应商的依赖方式。过去单独使用一个聊天工具，停用的主要影响可能是少了辅助；当它进入多个系统，停止服务会影响哪些任务，反而需要提前盘点。企业在试用阶段就应保留任务与业务记录的对应关系，让原有团队可以接续处理。这里讨论的是接入后的管理要求，不是Meta已披露的故障恢复承诺。

3. Agent安全：将执行建议、真实凭据与授权审批分开

Agent越能办事，越需要一道不能由它自己说服自己放行的边界。Meta在9月8日发布的Muse安全架构说明中，把主Agent、凭据服务和权限判断作了分离。主Agent不直接取得真实凭据，独立的Sentinel负责判断连接器动作与网络外发是否获准，授权还与特定用途和范围关联。

这里最有管理价值的选择，是把“它认为应该做什么”和“它被允许做什么”分开。即使模型理解了一个增长目标，也不能由此自动推导出可以给所有客户发消息，或者可以把所有内部文件交给外部服务。理解目标不是获得无限处置权。

Meta介绍的Sentinel还有一个重要的实施细节：主Agent提交要调用哪个连接器、执行何种操作及其作用范围，Sentinel再决定放行、拒绝或请求用户批准；需要真实Token时，由独立组件在获准的网络请求边界补入，主Agent只接触替代凭据。这条运行链把权限判断从自然语言谈话移出，避免Agent靠一段看似合理的解释扩张自己的操作权。

官方帮助文档同时允许部分连接器设置为只读。这种权限安排提供了分阶段采用的可能：先让Agent读取和整理，再决定是否交给它修改和发送的能力。企业可以在有限影响范围内观察输出，而不必在完全不用与全面授权之间二选一。

用同样的框架诊断你的业务

Meta的案例显示，企业AI最难的不是模型能力，而是权限、审批和可验收的流程设计。你的企业是否也卡在“AI能聊天，但不敢让它动业务系统”？用AI顾问诊断一下你的AI落地瓶颈。

免费体验 Upskill AI 顾问 →

这种渐进方式也使验收更具体。看报表的任务，可以检查数据选择和解释是否正确；发出通知的任务，还要检查对象、内容和触发条件。相同模型参与两种任务，经营风险并不相同。把权限按动作拆开，才有机会让验收标准与风险匹配。

不过，这些披露描述的是Muse，不能自动等同于整个Enterprise Platform已经具备统一的组织审批体系。Meta提供了可研究的技术设计，企业级部署还需要把这种控制与各自岗位责任接上。安全机制的存在，也不意味着错误已经被消除。

4. 场景落地：Movida把租车需求接到价格、车队与CRM系统

实施层最具体的证据，来自巴西租车企业Movida。该公司官方账号发布的活动演示中，CEO介绍了Business Agent如何接入产品信息、定价工具、日历和车队管理系统，并把线索送入客户关系管理系统。这里的重要动作是对接实际运营，而不只是让Agent学会租车话术。

Movida官方公开视频提供了比产品宣传更明确的任务顺序：用户先在WhatsApp中说明取车地点和日期，选择车型与保险，再确认订单；后台代理接入车队、日历、价格信息，形成的线索同步到CRM，供后续经营跟进。Movida介绍的是一条跨顾客、Agent与内部系统的工作链，而不是单个自动答复功能。

租车恰好能说明“回答正确”与“业务成立”之间的距离。顾客要的是某个地点、某段日期的一辆车，推荐必须受真实可用资源约束；后续信息如果不能进入客户管理系统，业务团队就可能失去跟进依据。对话只承担了入口，背后仍是企业自己的经营规则与记录。

Movida演示里的系统连接，并不能让我们推断出它的全部实施步骤、所用人天或技术成本。但它足以排除一种过于简单的想象：把一个模型放进WhatsApp，业务便会自然运行。可执行的服务建立在客户提供的系统能力上，供应商需要知道怎样接，客户也需要知道哪些数据和规则可以开放。

立即登录阅读全文

登录或注册即可解锁全站内容，即表示你理解并同意服务协议与隐私政策

这里还有一处必须谨慎处理的口径差异。Meta在7月财报电话会上将该方案概括为可完成从车型选择、报价到付款的预订流程；Movida公开视频演示却把在会话中支付描述为“即将支持”的步骤。两份材料可能对应不同演示范围或时间，但公开资料尚不足以统一口径。本文把已可观察的订车与后台对接作为实例，不将完整的会话内付款视为本次独立核实的既成结果。

这对Meta提出了另一种规模问题。消费产品可以把一次改进迅速推给大量用户；企业项目即使复用同一Agent，也可能面对不同的定价结构、系统接口和人工接管要求。能否将共同部分标准化、让差异部分以可承受成本完成，将直接影响这项业务可以扩展到哪里。

对话里能推荐一辆车，是用户体验；系统中能形成可靠业务记录，是交付结果。只有把两者连起来，客户才可能将AI从试验预算移进常规经营。Movida展示的是这条路径已有落点，还不是所有行业都可以低成本复制的证明。

验收因而也应深入异常情形。以租车任务为例，日期调整、车型不匹配或者客人需要额外说明时，Agent是继续处理还是交给人，不能只看一次顺利演示来判断。Movida披露了接入哪些系统，却未披露完整异常处理细则；读者可以借此明确下一步该查什么，而不能替它补写一套理想流程。

5. B2B增长：独立企业平台、销售责任与订阅收费的组合

技术和实施之后，还要有人对企业业务整体负责。Meta宣布的新负责人CJ Desai有MongoDB、Cloudflare和ServiceNow的任职经历。将这一职位直接放在CEO汇报线上，表明企业业务获得了明确的组织责任，而非只作为某个消费产品的附带功能。

任命本身不能证明销售团队已经成熟。它更像是为后续取舍设定负责人：面向哪些客户、卖单个工具还是组合服务、何时接受定制需求，以及哪些能力应通过伙伴交付。这些都是新业务必须回答的问题；现有公告没有给出完整答案。

收费设计则已有更早的讨论。在7月29日的后续电话会上，CFO介绍了Business Agent下半年采用订阅和按token计费的计划，并谈到免费额度与付费升级。根据当时的官方说明，订阅及按token计费属于2026年下半年商业化安排，其中按量计费计划自8月1日开始。媒体随后报道了这一计费方案的生效，但Meta尚未披露企业Agent对应的实际付费客户数、续约率与净收入；推出计费规则不能替代收入和单位经济性验证。

这条商业路径并非一张面向所有企业的统一价目表。向大型商家提供可定制的Agent平台，涉及企业采购、技术集成和服务支持；向小商家提供工具化Agent，更需要降低启动和持续使用门槛；模型API与代码工具又有不同的开发者和使用量口径。即使Meta在技术层复用基础设施，也不能预设它们共用同一种销售过程、价格与验收方式。

不同收费方式会影响供需双方如何看待价值。订阅降低了每次使用前重新决策的负担，客户却会关心常态使用是否足够；按量收费更容易对应实际调用，采购方又要判断费用是否可预测。无论采用哪一种，都还需要把技术用量解释成企业认可的业务价值。

这也是销售交付不能被定价表替代的原因。试用者觉得好用，与预算负责人愿意持续付费，中间还隔着验收和责任。Meta已有商家关系可以帮助触达客户，但是否能持续说明价值、支持实施并处理问题，要靠后续项目积累。把企业软件经验带进管理层是动作，形成可重复的经营体系才是待交的答卷。

衡量这套体系，还要区分供应商的可复制性与客户的收益。一个客户获得增长，未必说明供应商为交付付出的成本合理；同样，一套部署很省力的标准工具，也可能没有解决客户最重要的问题。只有两端都成立，企业AI才可能从个别项目走向持续业务。这正是新平台后续应接受的检验。

商家Agent已有业务成绩，企业平台还没有独立的财务回报

现阶段最可用的结果来自Business Agent的具体场景。Meta在7月财报电话会上转述，Movida某一个月通过WhatsApp取得的日均预订较上年同期增加44%，该渠道85%的对话由Agent独立解决，无需人工协助。

两个数字分别触及业务量与处理能力，比“已经接入模型”更接近经营结果。但它们的范围需要留在WhatsApp渠道和那个观察窗口内。同比增长不是对照实验，季节、营销或其他经营变化都可能共同影响预订；85%的对话独立解决，也不能换算成相同比例的岗位节省。

更关键的是，这段披露早于Enterprise Platform宣布，反映的是已有商家产品。它说明Meta有可继续发展的应用基础，却不能证明9月的新组织已经带来增长。百万商家使用同样只回答了采用规模的一部分，没有回答付费比例、客户留存或交付成本。

对观察者而言，下一批更有解释力的信息应来自同一客户使用时间拉长后的表现：原有流程是否持续有效，人工接管是否集中在关键问题，费用与业务量如何共同变化。它们比新增客户名单更能说明稳定性。这是本文提出的观察口径，不是公司已经公布的指标。

财务承受力则是另一层条件。Meta第二季度经营现金流318.6亿美元，同期资本开支310.8亿美元。充足的经营基础使它能够投入，但投入规模也要求未来持续解释回报。上述数字是集团口径，覆盖多类用途，不能当成企业平台的收入、成本或利润。

因此，目前最稳妥的结论是：产品与机制已经有实物，商家场景已有公司披露的早期结果，更广企业业务的重复交付与商业回报仍在验证。把这几个阶段分开，才不会让新平台的发布声量盖过它真正需要完成的工作。

中国企业借鉴Meta：先把AI接入一条可负责的业务流程

Meta的比较优势，首先来自WhatsApp、Messenger与广告业务长期积累的商家入口。已有用户会降低第一次触达的成本，却不能自动解决企业要求的身份权限、系统适配、异常处理和付费责任。没有同样入口的中国AI供应商，不宜先复制“百万商家”的规模叙事，而应先说明自己的Agent会进入哪一条有预算负责人和验收对象的工作流。

对于供应商，最小的交付单位不应是“接入一个大模型”，而应是一段明确的业务流程：顾客或员工提出什么任务，使用哪些真实数据，允许读写哪些字段，出现库存不足、付款失败或客户投诉时交给谁，最后在客户系统里留下什么记录。Movida说明这种连接能够落到具体场景，也提醒企业必须区分可观看的顺畅演示与覆盖异常的长期服务。

对于采购方，可以从只读与人工确认开始，抽样检查答案和数据口径，再逐步授权修改、发送与付款，并记录谁批准、谁复核、何时撤销。Muse的权限设计提供了技术基础，但Meta并未公开完整企业平台的服务等级、统一组织权限与每类部署成本，不能把产品安全架构直接当成合同保障。

最后要分开两个指标：一线人员是否愿意持续使用，以及企业是否愿意持续采购。前者考验体验和任务完成质量，后者还考验账单可预测性、系统维护和责任安排。Meta已经有百万商家入口、Movida的早期业务信号和独立企业平台负责人；从这些前提走到能够规模化复用的企业AI生意，还需要更长时间的客户留存、实施成本与收入数据来回答。