# 平臺能力 從企業方法論產品化到應用接入、訂閱開通與持續運營，瞭解 Runlume 如何以統一身份、生命週期、商業權益和授權連接，承接獨立 SaaS 的完整經營路徑。 > Runlume 提供平臺能力、獨立業務應用與專業服務，支持按需組合。功能、額度與交付範圍由所選套餐或服務約定確定；官方應用可獨立選用，跨應用協作遵循接入配置與授權邊界。 原始頁面: https://runlume.app/zh-hant/platform ## 系統部署在你選擇的環境，數據按你的授權流轉。 業務系統支持本地部署與私有化部署，可按方案運行在企業自有服務器或私有云環境。保留獨立的業務數據庫，通過統一接入使用 Runlume 的身份、權益與協作能力，讓部署自主與系統互通兼得。 ### 企業部署環境 業務系統與數據庫在約定的企業環境中運行。企業的方法、客戶資料和業務記錄保留在各自系統中，存儲位置、管理員權限和保留週期在部署方案中明確。 ### Runlume 平臺 負責統一身份、應用接入、訂閱權益與受控協作。不要求合併業務數據庫；按功能需要處理身份映射、實例狀態、用量及調用記錄等必要信息。 ### 智能體與外部能力 智能體通過獲准的能力接口處理任務，外部模型或服務僅按選定方案接入。調用所需的字段、接收方與用途應明確，不能把系統接入理解為全部數據開放。 ### 連接能力，不合並數據邊界 例如，CRM 與訂單系統協作時，通過已授權接口交換所需的客戶引用和訂單信息，各自保留數據庫與業務權限。實際請求和返回值仍會沿調用鏈流轉，應納入數據範圍與網絡訪問評審。 ### 數據安全，落實到每個訪問與交付環節。 #### 數據歸屬與管理自主 平臺接入不改變業務數據的歸屬約定。明確數據負責人、存儲位置、備份、導出與刪除流程；系統遷移或服務退出時，按交付約定處理數據和訪問權限。 #### 租戶隔離與最小授權 訪問圍繞賬戶、應用實例和業務角色校驗。系統間建立明確綁定，只開放任務所需能力與數據範圍；領域專家、工程師、FDE 和用戶也分別獲得與職責匹配的權限。 #### AI 調用同樣受控 智能體不因能夠編排任務就獲得管理員權限。調用遵守租戶、能力與數據授權，重要變更經過審核；使用外部 AI 前，確認傳出內容、服務條款與數據處理範圍。 #### 安全運維與過程追溯 通過重要操作與調用記錄追溯處理過程，避免在普通日誌中暴露密鑰和敏感載荷。部署交付需明確網絡訪問、傳輸保護、憑據管理、備份恢復與升級責任，並按約定驗證。 #### 私有化交付與 License 管理 提供 License 簽發、查詢、部署登記與撤銷管理，明確產品版本、部署環境、部署及業務實例數量與有效期。業務系統接入校驗組件後，在本地通過公鑰驗證簽名與授權條件。部署許可不替代訂閱權益或數據訪問權限；離線部署的許可狀態更新方式與交付範圍按合作協議約定。 ### FDE 把部署與安全要求帶進交付。 從業務梳理階段就識別敏感數據、訪問角色和外部調用，和企業 IT、領域專家及工程師共同確認部署拓撲、授權清單與驗收樣例。上線交付不僅是系統可訪問，也包括運維交接、備份恢復安排和持續支持範圍。 ### 本地部署是否意味著數據完全不出本地？ 不等同。業務數據可保存在本地系統，但統一身份、平臺協作、通知或外部 AI 可能處理必要信息。部署前應列明數據流向與用途，對敏感數據限制傳出字段和接收方。 ### 本地部署後可以完全斷網使用嗎？ 系統獨立部署不等於所有能力都支持離線。依賴平臺認證、權益校驗或外部能力的功能需要相應連接；具體內網訪問方式、網絡要求與可離線功能，應在選型和部署時逐項確認。 ### 誰負責本地系統的數據安全？ 企業、系統提供方與交付團隊按協議分工：企業管理基礎環境與授權人員，系統提供方落實應用權限與安全維護，交付團隊協助配置、驗證和交接。Runlume 承接平臺側治理，本地部署仍需持續做好安全運維。 ## 企業方法論產品化 Runlume 連接領域專家、軟件工程師與業務用戶，讓企業的方法、經驗和規則成為可運行的軟件。FDE 深入業務現場，將需求轉化為共同確認的規格，協同構建、驗證與落地；平臺承接系統接入、授權協作和持續運營，讓一次交付成為持續生長的軟件資產。 ### 例如，把客戶跟進方法變成團隊系統。 銷售專家定義線索分級、跟進節奏與訂單交接規則；FDE 與一線用戶核對真實場景，形成規格和驗收樣例；工程師連接 CRM、訂單系統與智能體，落實界面、流程和授權調用。用戶在日常跟進中反饋例外，FDE 推動專家校準規則、工程師更新版本，讓個人經驗逐步成為團隊可複用的經營方法。 ### 讓懂業務、懂技術與使用系統的人，在同一個平臺協作。 FDE 不是在三方之間簡單傳遞需求，而是貼近真實業務，把專家的方法、工程師的實現和用戶的反饋對齊到同一份規格與同一個交付目標。Runlume 為這種協作提供從構建到經營的共同基礎。 #### 領域專家 業務為什麼這樣做？ 把行業知識、經營經驗與判斷標準講清楚，定義流程、規則和例外，確認方法是否正確。 沉澱：業務方法、規則與驗收標準 #### 軟件工程師 如何讓方法可靠運行？ 將業務規格轉成系統、接口與自動化流程，負責工程質量、測試、部署和可維護性，用 AI 輔助提高構建效率。 沉澱：系統、接口、測試與版本 #### 業務用戶 在真實工作中是否有效？ 帶來真實任務、使用環境與約束，參與試用和驗收，用日常反饋與業務結果檢驗系統是否真正解決問題。 沉澱：真實樣例、使用反饋與結果 #### FDE 貫穿業務理解與工程落地 從需求澄清、原型驗證到部署接入和上線復盤，持續協調三方，讓問題、規格、實現和反饋始終相互對應。FDE 可以參與工程實現，但不替代領域專家的判斷或用戶的驗收。 ### 為什麼 Runlume 適合 FDE？ #### 把業務方法變成共同規格 用目標、流程、數據、權限與驗收條件連接三方，減少業務解釋與工程實現之間的偏差，方法也能隨版本持續改進。 #### 複用能力，專注業務差異 統一身份、應用生命週期、訂閱權益與公共能力由平臺承接。FDE 與工程師圍繞行業規則和關鍵流程交付，不必為每個系統重複搭建運營基礎。 #### 獨立部署，也能協同工作 支持系統獨立運行與私有化部署，通過統一接入和顯式授權連接能力與數據。智能體在授權範圍內執行跨系統任務，複用的是能力，不是無邊界共享數據。 #### 交付以後，仍能持續經營 將驗收、版本、應用開通和服務權益銜接起來，把用戶反饋帶回規則與規格。經授權可複用的方法、系統和能力逐步形成產品，服務更多適配的業務場景。 讓你的經營方法，成為自己的軟件資產。 ### 1. 梳理經營方法 領域專家提供方法與判斷依據，業務用戶補充真實流程和例外，FDE 對齊業務目標與優先級，把隱性經驗變成可討論的業務定義。 目標、流程與規則 ### 2. 形成結構化規格 FDE 協同專家與工程師將方法整理為 Blueprint / Spec，明確數據、權限、輸入輸出與驗收條件，讓業務判斷和工程實現有共同依據。 Blueprint / Spec ### 3. 構建業務系統 軟件工程師藉助 AI，把規格轉成業務界面、流程和能力接口；FDE 持續核對業務語義，複用已有應用與平臺能力，減少重複建設。 系統與變更集 ### 4. 驗證併發布版本 圍繞業務樣例、權限邊界與驗收條件驗證結果，審核變更，保留明確的版本與發佈記錄。 驗收與版本 ### 5. 接入並持續經營 連接平臺身份、應用開通、訂閱權益與授權協作，支持企業內部使用，也為產品化服務明確交付範圍。 應用與服務 ### 6. 用結果改進方法 把使用反饋、業務結果與異常情況帶回規則和規格，形成下一次改進，而不是在交付時結束。 反饋與下一版 業務負責人確認方法與驗收標準，AI 輔助構建與執行；重要變更經過審核，系統調用遵守租戶、數據與授權邊界。 方法、代碼、數據與交付成果的歸屬和使用範圍按合作約定確認；業務數據留在各自授權邊界內，跨客戶複用不等於複製客戶數據或專有知識。 ## [Runlume 智能體 · 統一管家](https://runlume.app/zh-hant/apps/agent) Runlume 智能體是平臺的官方統一管家。在租戶授權範圍內，調用已擁有系統的能力與數據，理解業務上下文、主動處理任務，並持續跟進執行結果。 ## 系統保持獨立，通信與數據有共同規範。 基座不只連接應用入口，也規範系統如何認證、調用接口、描述數據與傳遞事件。基於公開標準建立共同契約，讓不同技術棧的系統按約定協作，減少逐個對接時重複解釋和轉換的工作。 ### 標準化通信與事件契約 HTTP/JSON 承載接口調用，OpenAPI 描述請求與響應，OIDC/OAuth 2.0 支撐身份認證和服務授權；CloudEvents 為事件提供一致的封裝。這裡的“統一”是共同遵循通信規範，而不是要求業務系統改用同一種開發語言。 - 通過版本化接口明確輸入、輸出、錯誤與兼容要求。 - 以事件標識、來源、類型與業務載荷描述發生的變化，結合投遞記錄和冪等處理跟蹤協作。 - 調用與訂閱事件均遵循賬戶、應用實例和能力授權，不因使用標準協議而跳過權限校驗。 系統接入仍需接口適配、版本校驗與授權配置；標準協議不代表任意系統免改造接入，也不保證事件只投遞一次或實時到達。 ### 規範數據格式，支撐分析 通過 JSON Schema 描述交換字段、類型與校驗規則，並在接口和事件契約中明確版本、來源及上下文。更一致的輸入有助於減少格式轉換與字段整理，為獲准的數據彙總、大數據分析和跨系統指標對照提供基礎。 - 統一的是交換格式與描述規則，業務系統保留自己的領域模型和獨立數據庫。 - 分析前對齊字段含義、時間範圍、單位和指標口徑，區分結構一致與業務含義一致。 - 按授權用途選擇所需字段，並落實數據質量、保留期限與必要的去標識化處理。 這不意味著平臺默認彙集客戶業務數據、合併租戶數據或自動建成數據倉庫。分析工具、數據範圍與指標計算按具體方案配置，分析結果取決於數據質量與方法。 ## 從獨立系統，到可經營的 SaaS。 技術接入、商業關係與應用運行不是三套孤立流程。平臺把它們連接起來，讓系統的每個階段都有對應的身份、狀態與責任。 ### 1. 定義與接入 業務系統獨立部署，聲明應用信息、接口、事件與所需權限，建立平臺能夠理解的接入契約。 應用契約 ### 2. 驗證與發佈 圍繞身份、隔離、生命週期與接口兼容性開展校驗和審核，讓發佈對應明確的版本。 版本與審核 ### 3. 組織商品與套餐 把產品能力整理為套餐、功能權益與資源額度，明確客戶購買和使用的範圍。 服務範圍 ### 4. 訂閱與開通 根據所選訂閱建立權益與應用實例，連接客戶賬戶、業務空間和應用入口。 訂閱與實例 ### 5. 授權與協作 選擇需要連接的系統與能力。智能體和系統間協作都在租戶、實例、權益與授權邊界內執行。 授權連接 ### 6. 運營與迭代 結合用量、調用、服務狀態與業務反饋，支持續訂、問題處理和後續版本改進。 運行與反饋 這是平臺的產品經營路徑，不是自動生成或託管代碼的流程。具體接入、發佈與商業安排，以平臺開放能力和服務約定為準。 [延伸閱讀：從 Vibe Coding 走向產品運營](https://runlume.app/zh-hant/developers#vibe-to-business) ## 支撐業務運行的平臺能力 從方法落地到系統持續運行，需要一套共同的基礎。Runlume 將身份、應用生命週期、訂閱、系統連接、公共能力與安全治理串聯起來，讓各個業務系統獨立發展，也能有序協作。 ### 統一身份與工作空間 一次登錄，明確你能進入哪些應用。 統一身份不是讓所有人擁有相同權限，而是讓賬號、團隊成員與應用訪問關係有共同的起點。新用戶首次完成登錄即可自動創建賬號，無需另找註冊入口。 - 在統一入口完成身份認證，再進入被授權的業務應用。 - 區分平臺賬號、所屬賬戶與應用實例，避免把一個登錄身份等同於所有業務空間的權限。 - 平臺管理應用訪問；客戶、訂單等具體業務數據的可見範圍，由業務應用繼續校驗。 #### 業務場景 團隊成員進入 CRM 和訂單應用時使用同一身份，但能否查看某位客戶、修改某筆訂單，仍取決於對應應用的業務權限。 #### 能力邊界 登錄成功不等於已開通全部應用，也不意味著擁有全部數據權限。 ### 應用開通與生命週期 從開通到退出，每個應用都有清晰狀態。 平臺圍繞應用實例管理持續使用，而不只是提供一個跳轉鏈接。開通、暫停、恢復與退出，通過約定的接口交給業務系統執行，並記錄處理狀態。 - 將賬戶開通的應用實例與業務系統自己的工作空間建立對應關係。 - 按照實例狀態控制訪問，明確哪些應用可使用、正在處理或已暫停。 - 對耗時或失敗的操作保留狀態與後續處理依據，避免把發起請求誤當成已經完成。 #### 業務場景 開通 CRM 時，平臺建立應用實例，CRM 創建對應業務空間並返回結果；只有處理結果滿足約定後，才進入可使用狀態。 #### 能力邊界 應用實例開通不等於平臺替開發者託管代碼或部署服務器；退出時的數據處理按業務應用與服務約定執行。 ### 訂閱計費與權益 把買了什麼，與能用什麼關聯起來。 套餐說明、訂閱狀態、功能權限和資源額度需要一致。平臺將這些商業規則落實到應用實例，讓業務系統根據當前有效權益提供服務。 - 圍繞產品、套餐與訂閱組織購買關係，不把五個官方應用默認捆綁成一套。 - 區分功能是否可用與資源可以使用多少，避免把功能開關和消耗額度混為一談。 - 將有效權益、實際用量與賬單記錄關聯，給續訂、額度管理和使用核對提供依據。 #### 業務場景 某項訂閱可以包含應用功能與一定的資源額度。應用執行具體業務，平臺管理授予範圍與用量依據；具體價格和額度由正式套餐決定。 #### 能力邊界 創建賬號不等於免費獲得所有應用；實際套餐、額度、計費與退款規則以正式公佈內容為準。 ### 應用互聯與能力交換 業務可以協作，數據不必混在一起。 系統之間通過平臺授權連接直接互通能力與數據，不必每次經過智能體。智能體也能使用同一套能力契約協同多個系統。平臺管理誰可以調用誰、調用什麼能力，以及調用所處的租戶與權限範圍。 - 接入方聲明可提供的接口或事件，調用方只使用被授權的能力。 - 同一賬戶內建立明確的應用綁定，授權不因應用新增接口或擴大權限而自動升級。 - 通過受控調用與事件投遞記錄協作過程；業務系統分別處理自己的數據和重複請求。 #### 業務場景 CRM 與訂單應用可以圍繞已發佈、已授權的能力協作：CRM 提供客戶引用，訂單系統仍負責訂單規則與履約數據。具體流程取決於實際開放的接口。 #### 能力邊界 不共享業務數據庫，不默認跨賬戶互通，也不承諾跨系統事務或所有流程即時同步。 ### AI 與公共能力 共性的技術能力，不必每個應用重複建設。 應用需要的不只是身份與訂閱，還包括 AI 調用、通知和文件等公共能力。平臺提供統一接入與使用規則，業務應用決定這些能力如何服務具體場景。 - 平臺 AI 統一管理模型接入、可用範圍、額度與調用記錄，應用不需要持有平臺模型密鑰。 - 通知圍繞收件目標和投遞狀態組織，業務系統仍決定何時觸發、向誰通知。 - 文件等公共資源按實例與授權範圍接入，具體可用能力以平臺發佈目錄為準。 #### 業務場景 內容應用可以在獲准範圍內調用平臺 AI 輔助創作，再由自己的內容流程審核與發佈。AI 提供輔助，不替代內容責任和發佈權限。 #### 能力邊界 平臺 AI 與應用自有 AI 接入不是同一條計費路徑；公共能力也不等於 AI 可以繞過授權讀取所有業務數據。 ### 安全與運營治理 讓每次訪問、授權與變更都有邊界。 應用越多，越需要一致的治理方式。平臺把賬戶、實例、權限、狀態與操作記錄聯繫起來，但不替代各業務系統自身的數據安全責任。 - 以賬戶與應用實例建立隔離邊界，身份與調用上下文來自經過驗證的認證信息。 - 授權範圍、訂閱權益和實例狀態共同決定能否執行，擁有登錄身份不是通行所有接口的憑證。 - 記錄重要操作與能力調用，支持查詢處理過程；敏感憑據與業務載荷不應作為普通日誌輸出。 - 私有化業務交付通過 License 管理部署許可，明確產品版本、部署環境、數量與有效期；部署許可與訂閱權益、業務訪問授權分別管理。 #### 業務場景 當某個應用被暫停或連接被撤銷，後續訪問與調用需重新滿足平臺約束；排查問題時，可以沿操作與調用記錄檢查處理過程。 #### 能力邊界 統一治理不等於零風險或已獲得某項合規認證；業務應用仍需落實本地權限、數據隔離與保留規則。 ## 平臺與應用分工 ### 身份與訪問 - Runlume: 統一認證、成員關係與應用入口 - 業務應用: 本地用戶映射、業務角色與數據權限 ### 開通與運營 - Runlume: 訂閱權益、實例狀態與操作跟蹤 - 業務應用: 業務空間創建、具體功能與服務交付 ### 數據與協作 - Runlume: 能力契約、顯式授權與交換記錄 - 業務應用: 獨立數據庫、領域規則與數據質量 ## 平臺接入與數據，進一步瞭解。 ### 統一登錄是否意味著能訪問所有應用和數據？ 不意味著。統一身份提供共同的登錄入口；應用訪問還取決於所屬賬戶、已開通實例與授權。進入應用後，客戶、訂單等業務數據仍由對應系統按業務權限校驗。 ### 統一通信協議，是要求所有系統使用相同技術棧嗎？ 不是。Runlume 通過 HTTP、OIDC、OpenAPI、JSON Schema 與 CloudEvents 等契約組織身份、接口和事件交換。業務系統可保留自己的語言、框架、數據庫與部署，按接入範圍完成適配。 ### 統一數據格式如何幫助跨系統分析？ 一致的字段描述、類型和校驗規則有助於減少格式轉換與字段整理。分析前仍需對齊字段含義、單位、時間範圍和指標口徑，並獲得相應用途的授權；格式統一不等於數據自動彙總，也不保證分析結論。 ### 交換格式統一後，業務系統是否需要共用數據庫？ 不需要。統一的是接口交換與描述規則，業務系統保留自己的領域模型和獨立數據庫。系統通過已授權的接口交換所需信息，不以共庫或跨庫查詢代替接入契約。 ### 私有化交付 License 與訂閱權益有什麼區別？ License 用於核驗私有化軟件的部署使用資格，可約束產品、版本、環境、部署標識、數量和有效期；訂閱權益決定賬戶所購功能與資源。兩者不替代登錄身份、應用實例權限或跨系統授權連接，有 License 也不意味著能訪問全部業務數據。 ### 私有化軟件升級或 License 到期時如何處理？ 升級前核對目標版本、環境和部署規模是否在許可範圍內，需要時辦理續期或更新許可。到期影響、續期流程及維護安排在交付約定中明確。SDK 支持公鑰本地驗籤，但離線驗籤不等於外部服務可離線運行，也不意味著許可撤銷能即時到達離線環境。 ## 相關頁面 - [官方應用](https://runlume.app/zh-hant/apps) - [開發者](https://runlume.app/zh-hant/developers) - [關於 Runlume](https://runlume.app/zh-hant/about)