许可

ObjectOS Enterprise 部署运行需许可证的 Enterprise 镜像，许可证放在 OS_LICENSE_KEY 中。许可证决定镜像解锁什么。本页介绍如何获得许可证、它的两种 校验方式、如何读懂运行时做出的判断、如何续订，以及许可证结束时会关闭什么。合同 选项见许可与定价。

获取许可证

许可证由 ObjectStack 按合同签发：联系销售。没有自助 结账。你的许可证邮件包含：

1. 你所用版本的镜像摘要。按摘要安装，因为标签可以被移动，而摘要不能 （原因）。
2. 一个具有软件包读取权限的镜像仓库拉取令牌。从离线包安装时不需要它。
3. 许可证：一行由 ObjectStack 签名的文本。运行时在启动时用内置于镜像中的公钥 校验签名，所以任何一个字节被改动的许可证都会作为无效许可证被拒绝。
4. 部署包，包含你所用版本的 Compose 技术栈、环境模板和脚本。

像保存 OS_AUTH_SECRET 一样，把许可证作为机密保存 （生产就绪）。有三件事在签发许可证时就已确定，它们都 不是你可以修改的设置：

• 它的 AI 席位：你的合同购买的数量，25 个或更多（maxAiSeats）；
• 它的模式：在线或物理隔离（见下文）；
• 它的类型：带结束日期的订阅，或带维护结束日期的永久许可证 （见下文）。

Enterprise 许可证解锁什么

ObjectOS Enterprise 只有一个版本。除非你的合同明确列出了功能，否则 Enterprise 许可证授予下面的每一项功能；启动横幅的 features 一行显示你的许可证授予了什么 （见下文）。

在 Enterprise 成为单一版本之前签发的许可证，可能把版本写作 business。它会保留 售出时的条款（一个节点、最多 25 个 AI 席位、产品内 AI 和 AI 治理、在线校验）， 直到结束，续订时则作为 Enterprise 许可证续订。

每一行的含义，以及它的边界：

• 产品内 AI。 "ask" Agent 是包含在内、受支持的 Agent。AI Builder 以预览 形式提供，不属于合同范围，启动横幅也这样标注它。平台管理员把 AI 席位分配给 用户，许可证决定有多少个（分配 AI 席位）。你自带模型和 密钥。
• AI 治理。 每次 AI 工具调用的审计记录（谁让 AI 做了什么，它触及了什么）、 对每个回答的权限检查（使 AI 无法成为绕过记录权限的途径）、对 AI 工具所获取数据中 敏感字段的脱敏，以及可见的配额拒绝。用户粘贴进来的对话历史不会被再次脱敏。
• 多个节点。 除非你的合同设定了数量，许可证不限制节点数，但它不是一个高可用 产品：跨多个副本的高可用正在开发中，发布之前不提供。部署包目前运行一个节点， 在配置集群驱动之前，运行时会拒绝多于一个副本。没有许可证时，运行时运行一个 副本，声明更多副本的部署会拒绝启动。
• 层级安全。 相对于业务单元树的记录可见性：本单元、本单元及下级、本人及下属 这几种读取范围 （层级可见性）。
• 多个组织。 在一个数据库上按组织设置的隔离墙。参见 多组织。
• 客户自管密钥。 机密字段、数据源凭据和加密的设置，通过信封加密封存在你自己的 AWS KMS、Azure Key Vault 或 HashiCorp Vault（transit）密钥之下：每个值获得一个 新的数据密钥，由你的密钥包装，而你的密钥从不离开你的 KMS。吊销密钥会立即使这些 机密无法读取。已配置但无法访问、或未获许可的 KMS 会拒绝启动；运行时绝不会 回退到本地密钥。业务字段、元数据、附件和审计日志不由这项功能加密；它们的静态 加密依赖你的磁盘或数据库加密。它适用于单环境形态和组合形态，在固定产物的形态上 会被拒绝。请在安装时选择它：启用之前写入的机密不会被迁移，而关闭它会使它封存的 机密无法读取。客户自管密钥随 4.3.1 之后的 Enterprise 版本发布。

分配 AI 席位

AI 席位让一个用户可以与产品内 AI 对话。许可证设定部署可以容纳多少个席位 （maxAiSeats），每个席位分配给一个用户。

平台管理员不需要任何人分配就持有席位。 这包括每个持有 admin_full_access 权限集的账号（在单组织部署上，第一个创建的账号持有它，之后被授予它的任何人也一样）， 以及每个地址列在 OS_PLATFORM_OWNER_EMAIL 中的账号：只要账号存在且地址已验证， 就会获得席位。在有多个组织的部署上（OS_TENANCY_POSTURE=isolated 或 group）， OS_PLATFORM_OWNER_EMAIL 中的账号就是平台管理员。

这些自动席位计入 maxAiSeats：在一个 5 个席位的许可证上有两个平台管理员时， 还剩 3 个可以分配。不过它们从不会被拒绝，因此部署不会把它的管理员挡在 AI 之外， 即使这让它超出了上限。

其他所有人都由平台管理员分配席位，一次一个用户：

• 在应用中：在 Setup → Users 下打开该用户，选择 Assign AI Seat。 Revoke AI Seat 收回席位，空出来给别人。只有平台管理员能看到这两个动作。

• 通过 API，使用平台管理员的会话令牌：

  curl -X POST -H "Authorization: Bearer $TOKEN" \
    "$BASE/api/v1/actions/sys_user/assign_ai_seat/usr_123"
  curl -X POST -H "Authorization: Bearer $TOKEN" \
    "$BASE/api/v1/actions/sys_user/revoke_ai_seat/usr_123"

席位不是可以在用户记录上或通过数据 API 编辑的字段；这两个动作是改变它的唯一方式， AI Agent 也不能调用它们。它们会拒绝的情况：

这两个动作，以及 OS_PLATFORM_OWNER_EMAIL 账号的自动席位，随 4.3.1 之后的 Enterprise 版本发布。

在线还是物理隔离

许可证的模式说明它如何被校验。两种模式都会先在本地校验签名和结束日期。

有两种组合会在启动时替你决定：

• 在线许可证配合 OS_CLOUD_URL=off 永远无法被校验，所以运行时会拒绝启动， 并点名这两个设置： ✖ FATAL: this deployment has an ONLINE-mode OS_LICENSE_KEY but no control plane to validate it against。 断网的站点请申请物理隔离许可证。
• 组合形态（多个组织在一个已发布的应用背后共享一个数据库）只接受物理隔离 许可证，并要求 OS_CLOUD_URL=off。

物理隔离部署给出了完整的组合矩阵及其背后的原因。

使用在线许可证首次启动时，在缓存任何授权之前，运行时会等待控制平面最多 10 秒， 以便 Enterprise 功能能在这次启动时挂载。如果校验在那之后才成功，运行时虽已通过 校验，却已经按 Community 接好了线：日志会说明这一点，Enterprise 功能会在下次重启时 挂载。之后在宽限期内的重启，会直接根据缓存的授权获得许可，无需等待。

启动横幅显示什么

每次启动时，运行时都会在日志中打印一条横幅，说明它做出的判断。例如，一个已获许可的 部署会打印：

────────────────────────────────────────────────────────────────
  ObjectOS Enterprise — LICENSED
    customer  : Example Corp
    customerId: cus_0123
    org       : (none)
    licenseId : lic_0456
    seats     : up to 50 AI seat(s)
    nodes     : unlimited
    expires   : 2027-06-30T00:00:00.000Z
    features  : aiStudio, clustering, hierarchySecurity, scim, governance, multiOrg, customerManagedKeys
    in-UI AI  : ENABLED (AI Builder + ask)
    preview   : AI Builder（预览，不在合同范围内）; ask is the included, supported agent
    mode      : ONLINE (validated by the control plane)
    validated : 2026-11-07T09:12:44.000Z
    ent expiry: 2026-11-10T09:12:44.000Z
    refresh   : 2026-11-08T09:12:44.000Z
    runtimeId : rt_0789
────────────────────────────────────────────────────────────────

有些状态会出现在横幅的最前面，让你最先读到：

• ⚠ GRACE — the control plane has not confirmed this license recently， 后面跟着一行 degrades，写明宽限期结束的日期。
• 对于永久许可证，一行 license 写明它的状态： PERPETUAL — in maintenance until …，或 PERPETUAL — VERSION-LOCKED (maintenance ended …)，并附带 updates : none — newer images run as Community; renew maintenance to update。 ⚠ BUILD STAMP UNUSABLE 表示镜像无法证明它的发布日期 （见下文）。

没有可用许可证的部署会改为打印 Community 横幅，并附上原因和补救办法：

────────────────────────────────────────────────────────────────
  ObjectOS Community mode — NO valid Enterprise license
    reason    : no license (OS_LICENSE_KEY unset)
    in-UI AI  : DISABLED (AI Builder + ask)
    data      : available via the open MCP server — bring your own AI client
    to enable : set OS_LICENSE_KEY to a valid Enterprise license token
────────────────────────────────────────────────────────────────

在固定产物的形态（OS_ARTIFACT_URL）上，镜像自己的配置不会运行，所以没有横幅， 横幅所报告的内容（AI 席位、AI 治理、层级安全）也都不会挂载。

不启动就检查许可证

部署包的 license-check.sh 在一个没有网络的容器中运行镜像自己的校验器，不向任何 地方发送任何东西。它打印客户、版本、期限、模式和限制，绝不打印许可证本身；只有当 这个镜像会以你的 .env 获得许可地启动时，它才以 0 退出：

./license-check.sh                       # the license in .env, against the running image
./license-check.sh --file new.txt        # a license you have not stored yet
./license-check.sh --image <new digest>  # against the image you are about to upgrade to

版本显示为 enterprise，在 Enterprise 成为单一版本之前签发的许可证上则显示为 business。在订阅结束前三十天，检查会发出警告。

续订

续订就是一份新的许可证：一行新的文本，带有更晚的结束日期，两种模式都是如此。请在 当前许可证结束之前安装它：

./license-check.sh --set ./renewal.txt   # stores it in .env as OS_LICENSE_KEY and checks it
docker compose up -d                     # applies it

在 Kubernetes 上，更新存放许可证的 Secret 并重启 Pod。许可证作用于整个部署：每个 副本运行同一份许可证（Kubernetes）。

对于永久许可证，续订维护才能让更新继续：它是一份维护结束日期更晚的许可证， 在你升级到一个比当前版本更晚发布的镜像之前需要它。

许可证结束时

许可证按其类型，以两种方式之一结束。两种方式都不会让运行时停止，也不会触及你的 数据，下文的三种例外除外。

订阅

除非你的合同写明是永久许可证，Enterprise 许可证就是订阅。在结束日期之后的下一次 启动时，运行时会把许可证视为不存在，并以 Community 运行：

• 产品内 AI 和 AI 治理关闭；
• 层级读取范围不再授予任何东西；
• SCIM 不再默认开启；
• 你的数据保持完整，开放的 MCP 服务器继续工作，所以你自己的 AI 客户端仍然能访问它。

订阅不做版本锁定：结束日期之后，没有任何镜像会保留 Enterprise 功能。安装续订的 许可证后，下一次启动时它们就会恢复。

永久

永久许可证是一次性买断，只按合同销售，它也是唯一在维护结束后还保留某个版本的类型。 它没有结束日期，而是有一个维护结束日期，并保留维护费已付期间发布的版本：

• 在维护结束之前发布的镜像，只要你运行它，就保留每一项 Enterprise 功能，包括 产品内 AI。维护结束后，横幅和 license-check.sh 会显示 VERSION-LOCKED。
• 在维护结束之后发布的镜像以 Community 运行。升级之前，运行 ./license-check.sh --image <new digest>：它会说明该镜像是否在覆盖范围内， 不在范围内时 ./upgrade.sh preflight 会停止。
• 更新、补丁和支持随维护一同结束。

镜像通过它的发布清单 /etc/objectstack/ee-release.json 证明自己的发布时间。不要在 这个文件或它所在的目录上挂载任何东西：否则运行时无法使用它，许可证会像订阅一样在 维护结束时失效。在线的永久许可证在维护结束后仍然需要它的控制平面，宽限期同样是 7 天；如果部署不能依赖控制平面，请申请物理隔离的永久许可证。横幅和 license-check.sh 中的 VERSION-LOCKED 状态随 4.3.1 之后的 Enterprise 版本发布； 更早的镜像使用永久许可证时会以已获许可的状态启动。

有三种部署会改为拒绝启动

有三种配置必须有有效的许可证才能存在，所以已结束或缺失的许可证会让它们拒绝启动， 而不是以 Community 运行。数据仍然完整；有效的许可证会让它们恢复。

• 多个组织（OS_TENANCY_POSTURE=isolated 或 group）：组织之间的隔离需要 许可，要求了隔离的部署在没有许可时绝不提供服务。参见 多组织。
• 客户自管密钥（在 OS_CRYPTO_PROVIDER 中设置了 KMS）：运行时绝不会回退到本地 密钥，因为机密是在你的密钥之下封存的。
• 多个节点（OS_CLUSTER_REPLICAS 大于 1）：没有多节点许可证时，运行时会拒绝 所声明的拓扑，而不是运行彼此不协调的副本。

像安排证书续期一样安排这些部署的续订：许可证检查会提前 30 天发出警告，日期也写在 每一条启动横幅中。

下一步

• 多组织 —— 多个组织共享的部署上的许可证。
• 物理隔离部署 —— 断网站点的许可证模式。
• Docker → 企业版额外提供 —— 许可证附带的 镜像仓库、校验和升级步骤。