開關面板只會照著接線行事：撥動開關，每次都得到同一種固定回應。要它處理這條電路以外的任何事，它就無能為力，因為它處理不了變化，只懂接線。
接線生就不同了。給接線生一個請求，例如「幫我轉接櫃台」，他們會自己想辦法：該用哪一條線、忙線時怎麼辦、請求本身語意不清時又該怎麼辦。他們不只是傳遞訊號，而是理解訊號並據以行動。
Maven Apps 是接線生，而不是開關面板。當我們著手打造支撐 App 基礎架構的框架時，我們刻意押注一個方向：不再做另一層整合，而是打造真正的應用程式平台，讓 AI 代理成為平台上的一等公民。
如今，我們的框架上已有數千個應用程式。沒錯，其中包括 Salesforce、Zendesk、Notion 等主要第三方系統的應用程式，但也包括數百個在正式環境中、於線上代理上運作的自訂應用程式。
為什麼基本整合不夠用
問 10 家廠商他們的產品「與 Salesforce 整合」是什麼意思，您會得到 10 種不同的答案，因為 Salesforce、Zendesk 或 Front 這類系統從來不只是單一用途。它可能是：
- 您的代理需要前往查找資訊的地方（知識庫、案件歷史）
- 您的代理需要前往執行動作的地方（建立工單、更新紀錄、辦理退款）
- 您的代理需要出現的介面（嵌入在您的支援團隊每天使用的主控台中、提供代理輔助的 co-pilot）
只認得文章的「Salesforce 整合」，和能建立案件的整合不是同一種產品；和能以 co-pilot 形式嵌入代理主控台的整合，也不是同一種產品。這些功能常被包裝在同一個行銷用語之下，讓您到導入階段才發現其中的落差。
這就是自動販賣機的問題：固定的選單完全照宣傳運作，直到您需要的東西不在清單上，而那時您早已投入。我們不希望 Maven Apps 這樣運作，因此我們圍繞實際提出的問題（知識、能力或管道）來打造框架，而不是圍繞一個通用的「連接器」。
Maven Apps：不只是整合
Maven Apps 可以有多種形態，但大多建立在幾種常見模式之上。以下是應用程式能做到的幾個例子：
- 知識應用程式：讀取並索引外部系統的內容，讓代理能據此回答：唯讀、具版本控管，並可依受眾加上標籤。
- 能力應用程式：讓代理真正在該系統中執行動作：實際的 API 呼叫，串連成多步驟工作流程（查詢訂單、確認退貨政策、辦理退款、再向客戶確認），全部在單一對話內完成。ATM 只能從固定選單執行一筆照本宣科的交易，能力應用程式則更像私人理專：它接收的是一個目標結果，而不是選單項目，並會採取一切必要步驟達成目標，包括處理例外狀況。
- 管道應用程式：讓代理出現在您的客戶或支援團隊所在之處：嵌入式小工具、電話、Inbox，或是代理每天使用的主控台中的 co-pilot 面板。
我們目錄中的預建應用程式通常幾分鐘內就能安裝完成。當客戶的系統不在目錄中時，開發人員會使用同一套框架、同一套 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，是因為我們認為這才是「整合」一開始就該有的意義。
用您自己的對話實際體驗。
申請免費的專屬展示。
