# 平台能力 从企业方法论产品化到应用接入、订阅开通与持续运营，了解 Runlume 如何以统一身份、生命周期、商业权益和授权连接，承接独立 SaaS 的完整经营路径。 > Runlume 提供平台能力、独立业务应用与专业服务，支持按需组合。功能、额度与交付范围由所选套餐或服务约定确定；官方应用可独立选用，跨应用协作遵循接入配置与授权边界。 原始页面: https://runlume.app/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/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/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/apps) - [开发者](https://runlume.app/developers) - [关于 Runlume](https://runlume.app/about)