交换面板只会严格按接线方式工作：拨动开关，得到唯一固定的响应，每次都一样。一旦要求它处理线路之外的事情，它就无能为力，因为它无法应对变化，只认接线。
接线员则不同。给接线员一个请求，比如“帮我接通前台”，他们会自己想办法：用哪条线路、占线怎么办、请求本身含糊不清又该怎么办。他们不只是传递信号，而是理解信号并据此采取行动。
Maven Apps 是接线员，而不是交换面板。在着手构建支撑我们 App 基础设施的框架时，我们做出了一个深思熟虑的选择：不再做又一个集成层，而是打造一个真正的应用平台，让 AI 智能体成为平台上的一等公民。
如今，我们的框架上已运行着数以千计的应用。其中当然包括面向 Salesforce、Zendesk 和 Notion 等主流第三方系统的应用，同时也有数百个自定义应用正在生产环境中为在线运行的 AI 智能体提供支持。
为什么基础集成不够用
问 10 家厂商“与 Salesforce 集成”对其产品意味着什么，您会得到 10 种不同的答案，因为 Salesforce、Zendesk 或 Front 这样的系统从来都不只承担一种角色。它可以是：
- 智能体获取信息的地方（知识库、案例历史）
- 智能体执行操作的地方（创建工单、更新记录、发起退款）
- 智能体需要出现的界面（嵌入支持团队日常所用控制台中的坐席辅助助手）
一个只能读取文章的“Salesforce 集成”，与一个还能创建案例的集成并不是同一种产品；与一个能作为辅助助手嵌入坐席控制台的集成，也不是同一种产品。这些能力常常被打包在同一个营销词汇之下，直到实施阶段您才发现其中的缺口。
这就是“自动售货机问题”：菜单固定，宣传的功能都能正常运作，直到您需要的东西不在清单上，而那时您早已签约。我们不希望 Maven Apps 这样运作，因此我们围绕真正要解决的问题（知识、能力还是渠道）来构建框架，而不是围绕一个通用的“连接器”。
Maven Apps：不止于集成
Maven Apps 形态多样，但大多基于几种常见模式。以下是应用能做的一些事情：
- 知识类应用从外部系统读取并索引内容，让智能体能据此作答：只读、支持版本管理、可按受众打标签。
- 能力类应用让智能体在该系统中真正执行操作：发起真实的 API 调用，并串联成多步工作流（查询订单、核对退货政策、发起退款、向客户确认），全部在一次对话中完成。ATM 只能从固定菜单中执行一笔预设交易，而能力类应用更像一位私人银行顾问：它接收的是目标结果而非菜单选项，并会采取一切必要步骤达成目标，包括处理异常情况。
- 渠道类应用让智能体出现在客户或支持团队已经在用的地方：嵌入式组件、电话、收件箱，或坐席每天使用的控制台中的辅助助手面板。
我们应用目录中的预置应用通常几分钟即可完成安装。当客户的系统不在目录中时，开发者构建自定义应用所用的，正是同一套框架、同一套 SDK、同一套生命周期钩子和同一套安全模型。
框架没有只供我们工程师使用的单独“企业级”版本；我们用于构建应用的开发者平台 App Studio 运行在完全相同的架构之上。它使用真正的 TypeScript、真正的 SDK（@mavenagi/mavenagi）和真正的部署流水线，而不是一门需要专门为我们学习的专有脚本语言。
如果您以前基于 MCP 做过开发，Maven App 提供的是类似的理念，而且完全托管。标准的 MCP 服务器仍需要您自己搭建、注册、维护运行和扩展。Maven App 更接近一个自动注册、自动扩展的 MCP 端点，无需您承担任何基础设施：您只需编写逻辑，端点、身份验证和托管都由我们负责。
Apps 如何为强大而设计
Maven App 是一个无服务器应用，运行在安全、隔离的环境中，并通过定义明确的 SDK 与 Maven 平台通信。具体来说：
它是多租户的。 一个应用只需构建一次，即可在不同组织和智能体中多次安装。每次安装都有独立的作用域上下文（各自的组织 ID、智能体 ID 和运行时配置），但共享相同的底层代码。这意味着当我们改进 Salesforce 应用时，所有使用它的客户都会受益，没有人会被困在一个过时的、手工搭建的“专属”集成版本上。
它是隔离的，而非外挂的。 每个应用都在安全环境中作为独立函数运行，与 Maven 核心后端隔离，也与其他客户的应用隔离。您的自定义逻辑永远不会与他人的逻辑一起运行在共享的单体系统中。与您的记录系统之间的连接可以通过 VPN、VPC 对等连接、OIDC 或配合 IP 白名单的普通 HTTPS 实现，由您而不是我们来选择。
它响应真实事件，而非依赖轮询计划。 应用无需依赖夜间同步任务，而是可以实现名为触发器的事件钩子：对话已创建、收到反馈、知识库已刷新，事件一发生，平台就会立即通知应用。这与您可能熟悉的自动化工具形态不同。Maven 触发器是被动的：由平台本身监听状态变化，并将其推送给任何关注该事件的应用，引发事件的应用与响应事件的应用之间没有任何耦合。在实践中，这意味着一个邮件回复应用和一个完全独立的 Salesforce 同步应用可以各自独立地响应同一个“对话已更新”事件，各司其职，彼此都无需知道对方的存在。
这与蚁群的协调机制如出一辙。没有哪只蚂蚁规划整个蚁群的行为，也没有蚂蚁直接向另一只传递消息；一只蚂蚁改变共享环境中的某样东西（信息素轨迹），其他每只蚂蚁都会依照各自简单的规则独立响应这一变化。蚁群层面的智能（优化的觅食路线、负载均衡，乃至迁巢这样的集体决策）由此涌现，既没有中央协调者，也没有哪只蚂蚁知晓全局计划。Maven Apps 也以同样的方式协调：事件改变共享状态，每个关注它的应用各自做出响应。
它拥有真正的生命周期。 每个应用都实现一小组生命周期钩子：
preInstall：在任何内容上线之前验证凭据和配置。如果您的 API 密钥有误，安装会在这一步明确报错失败，而不是 3 周后才悄无声息地出问题。postInstall：安装成功后，注册应用的操作并配置其所需的各项资源。executeAction：执行智能体请求的实际工作，以能力的形式向客户开放：查询订单、创建案例、发起退款、查询账户余额。
大多数集成就像电灯开关：要么开，要么关，没有中间状态。我们的应用则运行完整的安装、验证、运行、卸载生命周期，更像是一套会读取上下文并随之调整的流程（检查哪些事项未完成、确认哪些操作安全，然后再行动），而不是只有 2 种状态的开关。这正是您对一款生产级软件应有的期待，因为它本就是生产级软件。
Apps 与集成的区别
典型的集成只回答一个狭窄的问题，通常是“数据能否从 A 传到 B”，并将其视为终点。Maven App 则旨在回答一个更难也更有价值的问题：AI 智能体能否可靠地掌握您系统中此刻的真实情况？在需要时，它能否值得信赖地代表您采取行动？
大多数企业平台都会提供某种形式的“如果我们没有开箱即用的功能，您可以自己构建”。但他们通常不会告诉您，自己构建意味着要在自己的基础设施上运行自己的服务器，自己负责扩展，自己做安全审查。这会把连接器目录中的一个小缺口变成一个人员编制问题：是去争取工程和基础设施预算，还是只能局限于现成的功能？借助 Maven Apps，我们的客户不必在几个不理想的选项中勉强取舍。您或您的开发者构建的自定义应用运行在我们的基础设施上，享有与目录中每个预置应用相同的监控、扩展能力和安全保障。您写代码，我们来运行。
这也是为什么该架构坚持做到那些简单 webhook 从来无需考虑的事情：
- 结构化、有大小限制的响应。 应用执行的每个操作都会返回清晰的响应，以及智能体可以据此推理的结构化数据，而不是一团需要它去猜测的原始、无限制的数据。
- 签名式双向认证。 平台会对发往应用的每个请求进行签名，使应用能够验证确实是 Maven 在调用；应用也会使用自己的凭据向平台进行身份验证。双方都不必单凭网络来建立信任。
- 配置在进入生产环境前即完成验证。 由于
preInstall在应用上线前运行，失效的凭据或缺失的设置会在安装时就被发现，而不是等到客户首次依赖它时才暴露。 - 底层是真正的基础设施，而不只是一次函数调用。 由于应用是完整的应用程序，它们可以保存真实状态：缓存、速率计数、小型数据库，而不只是无状态的请求与响应。正因如此，才能实现诸如跟踪某个特定领域的解决率在过去 24 小时内是否下降超过 10%，并在下降时通知您的团队。单纯的 API 调用无法保存这种记忆，而真正的应用程序可以，就像蚁群能记住食物在哪里，尽管没有任何一只蚂蚁记得。
- 让敏感数据远离模型。 有些步骤根本不应经过 AI。当客户准备购买购物车中的商品时，智能体会触发应用的结账流程，由应用通过自己的安全界面直接向客户收集支付信息和个人信息。智能体负责编排流程，但卡号等敏感信息永远不会进入与 AI 的对话。
- 一套代码库，服务所有客户，影响范围相互隔离。 多租户意味着修复和改进只需发布一次即可惠及所有人，而隔离则确保一个客户的自定义逻辑永远不会影响到另一个客户。
这对您意味着什么
如果您正在评估 Maven，实际的结论是：当我们说智能体能够回答问题并据此采取行动时，我们指的是该操作背后有一个真正的应用程序：有版本管理、经过身份验证、相互隔离，并且无论由我们的团队还是您的团队发布，都构建在同一框架之上。这就是只会谈论您的系统的智能体，与真正接入您系统的智能体之间的区别。
我们打造 Maven Apps，是因为我们相信，“集成”本就应该是这个意思。
用您自己的对话来验证。
申请免费的个性化演示。
