企业内部 AI 应用如何快速发布与共享¶

商务、法务、运营和职能团队做完一个合同审查、知识问答或报告生成应用后，通常希望快速提供给其他部门使用。平台如果要求他们准备 Dockerfile、编写 Kubernetes YAML 或理解 Serverless，发布路径就已经设计错了。

业务用户发布的应该是一个受治理的内部应用，而不是一个容器。理想体验类似发布在线表单：选择模板、配置数据和权限、邀请少量用户试用，然后一键发布到公司应用中心。容器、Serverless、工作流和常驻 Agent 都是平台的实现细节。

本文给出一套适合企业内部 AI 应用的产品流程、运行架构和治理边界。若正在评估 OpenClaw 本身能否承担企业运行时，先阅读 OpenClaw 作为企业 Agent 平台底座；涉及代码、Shell 或浏览器执行时，参见 Agent Sandbox 选型与架构分析。

1. 先区分“搭建应用”和“部署服务”¶

业务应用大多由以下内容组成：

页面或对话入口
+ Prompt 与输出格式
+ 知识库和业务数据
+ 工作流与人工审批节点
+ 已批准的工具和连接器
+ 用户、部门和数据权限

这些配置可以运行在共享的多租户应用引擎中，不需要每创建一个知识助手就构建一份镜像、启动一个 Pod。

只有出现以下需求时，平台才应切换到独立运行实例：

• 上传自定义代码或特殊 Python、Node.js 依赖；
• 需要长时间任务、事件消费或独立扩缩策略；
• 需要飞书、企业微信、Slack 等长连接；
• 需要持续记忆、独立工作区或本地状态；
• 使用浏览器、Shell 或代码执行环境；
• 处理高敏感数据，需要更强隔离；
• 资源、可用性或变更周期与共享平台明显不同。

因此，企业平台通常需要两层产品，而不是让所有应用走同一条部署路径：

2. 公开案例：哪些组织用了什么¶

公开案例已经显示出三条不同路线，但披露深度差异很大：有些只公开产品名称和应用数量，有些会公开身份、知识库、工作流和运行框架。下面只列出能找到组织名称和一手公开资料的案例，不用 GitHub Star、匿名访谈或产品演示代替企业采用证据。

资料来源：BBVA、Moderna、Kakaku.com、HEINEKEN、Coca-Cola Andina、Lyft、Uber、Sanofi、Cox Automotive。

2.1 怎样理解这些案例¶

这些案例不能简单汇总成“某个框架最好”，因为它们解决的问题不同：

配置一个知识和 Prompt 助手
  → Custom GPTs / Microsoft 365 Agent Builder

搭建部门工作流并接入办公系统
  → Copilot Studio / Power Platform / Dify

实现复杂、长状态、可评测的专业 Agent
  → LangGraph 等编排框架 + 企业自建发布控制面

统一承载大量生产 Agent
  → Bedrock AgentCore 等托管 Runtime，或 Kubernetes 自建 Runtime

Custom GPT、Copilot Studio 和 Dify 本身就是面向创建者的应用工作台；LangGraph、Strands Agents 和 OpenClaw 更接近开发框架或 Agent Runtime。直接比较它们会混淆产品层次。业务用户可以在前者中直接发布，但使用后者时，企业通常还要自行建设表单、权限、审批、应用目录、评测和生命周期控制面。

2.2 案例证据的限制¶

• 上表多数来源是供应商发布的客户故事，适合确认“谁公开使用了什么”，但不等同于独立审计；
• 应用数量不等于活跃应用数量，也不能证明每个应用都访问敏感数据或执行高风险操作；
• 厂商案例往往不会公开成本、失败率、安全事件、租户模型和底层 Kubernetes 架构；
• Uber 和 Lyft 属于平台或工程团队主导的自助化，不是让法务人员直接发布任意代码；
• 截至本文复核日期，尚未找到披露程度相当、可验证的大型组织使用 OpenClaw 完成“业务用户自建并全公司发布应用”的公开案例。OpenClaw 可以作为渠道和运行时选项，但不能仅凭社区热度推导出该企业场景已经成熟。

2.3 从公开案例得到的产品结论¶

1. 先提供共享创建工作台。 BBVA、Moderna 和 Kakaku.com 的规模来自员工配置和复用应用，而不是为每个应用建立一套 Kubernetes 服务。
2. 办公生态会决定最短路径。 已深度使用 Microsoft 365、SharePoint、Entra ID 和 Teams 的组织，Copilot Studio 路线通常最短；希望自托管和多模型的团队更可能评估 Dify。
3. 领域专家和平台工程师仍有明确分工。 Lyft 让运营人员维护 Prompt 和配置，但 LangGraph 骨架、状态、安全检查和观测仍由工程平台负责。
4. 规模扩大后，身份比模型框架更难。 Coca-Cola Andina 的用户身份透传和 Uber 的 Agent 身份体系都说明，生产平台必须回答“以谁的身份、代表谁、可以调用什么”。
5. 大型企业经常保留自己的控制面。 Sanofi 和 Uber 没有把企业入口、权限和治理全部交给某个 Agent SDK，而是把模型服务或编排框架放在自有平台之下。

3. 业务用户看到的发布流程¶

推荐把完整流程设计为：

选择模板
  → 配置内容、数据与工具
  → 小范围试运行
  → 选择可见范围
  → 自动风险检查
  → 必要时审批
  → 发布到内部应用中心
  → 持续评测、反馈与回收

3.1 选择模板¶

第一版平台不必提供无限自由度，可以先覆盖高频场景：

• 企业知识问答；
• 文档总结和信息提取；
• 合同条款比对与初审；
• 报告、邮件和方案生成；
• 信息收集、流程流转和人工审批；
• 只读的内部数据查询；
• 飞书、企业微信或 Slack 机器人。

创建应用时只要求填写业务信息，例如：

名称：销售合同初审助手
用途：识别付款、违约和知识产权等风险条款
负责人：法务部合同组
预期用户：销售一部、销售二部
数据级别：内部敏感

应用负责人不能是可选字段。平台后续需要依靠负责人处理权限复核、用户反馈、事故响应和下线交接。

3.2 配置数据和能力¶

业务用户可以上传制度、模板和审查规则，或者选择平台已经登记的数据源和连接器。连接器应表达为业务能力，而不是原始密钥或任意 API 地址：

用户不应把个人 API Key 粘贴进 Prompt、配置文件或知识库。平台应为每个应用签发独立身份，并通过 Secret 服务或 Tool Gateway 获取短期凭据。

3.3 小范围试运行¶

应用首先进入草稿或测试环境，只允许创建者和受邀测试人员访问。测试页面至少应提供：

• 一组可保存的代表性输入和期望结果；
• Prompt、知识库、模型和工具版本记录；
• 敏感信息、越权查询和 Prompt Injection 检查；
• 无答案、模型超时和工具失败时的降级行为；
• 响应时间、Token 和费用预估；
• 点赞、纠错和问题分类；
• 修改后的自动回归测试。

例如合同应用可以维护一组脱敏的标准合同。更换模型、提示词、知识库或工具权限后，平台重新运行测试，避免“调整一句 Prompt 导致旧场景失效”。

3.4 选择访问范围¶

发布界面不应只有公开和私有两个选项。建议支持：

访问范围应绑定公司的 IdP、通讯录和安全组，避免维护一份容易失效的手工名单。用户调岗或离职后，权限随组织关系自动变化。

3.5 风险分级和审批¶

审批应基于风险，而不是所有应用一刀切：

平台应尽量自动完成数据源检查、权限差异、敏感信息扫描、依赖扫描、预算估算和回归测试，只让需要判断的事项进入人工审批。审批过重会使用户转向无法治理的个人脚本和外部工具。

3.6 发布结果¶

发布成功不应该只表示“Pod 已经运行”，而应返回一个员工能够理解和分享的应用页面：

销售合同初审助手

用途：辅助识别常见合同风险，不代替正式法律意见
负责人：法务部合同组
适用范围：销售一部、销售二部
数据保留：任务完成 7 天后删除
版本：v1.3

[立即使用] [申请权限] [使用说明] [反馈问题]

平台在后台自动完成：

• 公司 SSO 和用户身份识别；
• 用户组、部门和应用角色授权；
• 内部域名、TLS 和入口路由；
• 独立应用身份、Secret 和工具权限；
• 日志、Trace、审计和费用归属；
• 并发、Token、时间和月度预算；
• 版本保存、灰度、回滚和停用；
• 内部应用市场或协作工具上架。

4. 应用访问权不等于数据访问权¶

这是内部 AI 应用最容易出问题的地方。一个员工可以打开合同助手，不代表他能通过助手读取所有合同。平台必须分别处理：

能否打开应用？
        │
        └── 打开以后，能查看或修改哪些业务数据？

4.1 用户身份透传¶

应用以当前登录用户身份访问业务系统：

李四只能查看华东区合同
→ 通过助手查询时仍然只能看到华东区合同

这是内部搜索、数据查询和个人工作助手的首选模式。AI 应用不应成为绕过原系统行级、字段级和组织级权限的“万能查询账号”。

4.2 应用身份¶

应用也可以使用独立的服务身份访问明确的共享资源，例如只读法务公共条款库。该身份必须具备最小权限、资源范围、调用预算和有效期，不能继承创建者的个人凭据。

4.3 Tool Gateway¶

高风险场景可以让所有业务操作经过 Tool Gateway：

1. 验证用户、应用、会话和目标资源；
2. 根据策略判断本次调用是否允许；
3. 必要时触发人工确认；
4. 交换短期下游凭据；
5. 校验参数并执行操作；
6. 记录脱敏审计事件。

模型可以提出动作，但最终授权必须由确定性的服务端策略决定。

5. 统一发布面，底层使用多种运行时¶

“一键发布”不等于底层只有一种运行方式。平台可以根据触发器、状态和执行时长自动选择：

Knative Serving 可以按请求并发自动扩缩，并在无流量时缩容到零，适合无状态 HTTP 应用；冷启动敏感的服务可设置最小副本。参考：Knative Autoscaling。KEDA 适合按事件源和队列积压扩缩 Worker，其 HTTP Add-on 也支持 HTTP 工作负载从零扩容。参考：KEDA HTTP Add-on。

长连接、持续本地状态和需要随时响应的 Agent 不应为了“Serverless”标签被强制缩容到零。OpenClaw 的 Gateway 就是拥有渠道连接、会话和控制面的常驻进程；互不信任的租户也不能只用同一个 Gateway 中的会话 ID 进行隔离。参考：OpenClaw Gateway、OpenClaw Multi-Tenant Hosting。

6. 推荐的平台架构¶

业务用户 / 开发者
        │
        ▼
AI 应用工作台
├── 模板、知识库、工作流和连接器
├── 测试集、评测、权限范围和预算
└── 试运行、审批、发布和下线
        │
        ▼
应用发布控制面
├── App / Version / Owner / Environment
├── User / Group / Role / Data Policy
├── Risk / Approval / Quota / Audit
├── Runtime Selection / Rollout / Rollback
└── Catalog / Feedback / Lifecycle
        │
        ├── 共享应用运行时
        ├── Knative HTTP Service
        ├── KEDA Event Worker
        ├── Workflow / CronJob
        └── Resident Agent Cell
                │
        ┌───────┼──────────────┐
        ▼       ▼              ▼
    Model     Tool          Memory / Data
    Gateway   Gateway       Storage

平台控制面应保存一份与底层实现无关的应用声明。例如：

apiVersion: platform.example.io/v1alpha1
kind: AIApplication
metadata:
  name: contract-review
spec:
  owner: legal-contract-team
  runtime: auto
  audience:
    groups:
      - sales-east
      - sales-south
  triggers:
    - type: web
  dataClassification: internal-sensitive
  capabilities:
    models:
      - company/standard-llm
    tools:
      - contract.read-as-user
      - legal-clause-library.read
  scaling:
    idlePolicy: scale-to-zero
    maxInstances: 10
  retention:
    userContent: 7d

业务用户不必直接编辑 YAML；它可以由表单或对话式工作台生成。声明的价值在于让平台能够审计、比较版本、执行策略并更换底层运行时。

7. 内部应用中心不只是一个链接列表¶

应用目录至少应展示：

• 应用用途、适用范围和明确的能力边界；
• 负责人、所属部门和支持渠道；
• 使用的数据源、数据级别与保留时间；
• AI 结果说明和需要人工复核的场景；
• 当前版本、最后更新时间和变更记录；
• 权限申请、反馈、纠错和事故报告入口；
• 服务状态和计划维护信息。

无权限用户不应只看到 403，可以显示所需用户组、数据权限和申请流程。访问地址也可以同步到企业 Wiki、飞书文档、Confluence、SharePoint、企业微信或 Teams，但文档只是介绍和入口，真正的身份、授权、数据访问和执行仍由应用平台控制。

发布到互联网是另一种安全边界，不应复用“公司内部公开”的快捷流程。对外应用至少需要独立身份和数据源、匿名访问防滥用、输入输出安全检查、限流和费用上限、隐私说明，以及安全、法务和品牌审批。

8. 生命周期治理¶

应用发布后仍会持续变化。平台需要处理：

• 负责人离职、调岗后的自动转移；
• 数据源、工具权限、模型或发布范围变化后的重新评审；
• Prompt、知识库和模型更新后的回归测试；
• 低使用率、长期无人维护应用的提醒和归档；
• 高风险应用的周期性权限和数据复核；
• 旧版本快速回滚和重大问题一键停用；
• 会话、上传文件、日志和审计记录分别设置保留周期；
• 成本按应用、部门、模型和工具归属。

Kubernetes Namespace 可以承载部分隔离和配额，但本身不是完整租户边界，还需要 RBAC、NetworkPolicy、ResourceQuota，以及高风险代码执行所需的沙箱运行时。参考：Kubernetes Multi-tenancy。

9. 第一版平台怎么做¶

第一版建议控制范围，不开放任意代码执行，优先实现：

1. 知识问答、文档审查、报告生成、表单和人工审批模板；
2. 公司 SSO、部门组、应用角色和用户身份透传；
3. 经过批准的只读数据连接器；
4. 草稿、测试、发布和回滚三个基本环境状态；
5. 风险分级、自动检查和少量人工审批；
6. 内部 Web 地址，以及飞书、企业微信或 Teams 入口；
7. 应用负责人、预算、日志、反馈和停用机制。

发布页面可以只向业务用户提出四个核心问题：

谁可以使用？
使用哪些数据？
能够执行哪些操作？
谁对这个应用负责？

第二阶段再加入自定义代码、异步 Worker、持久工作流、常驻 Agent Cell、灰度发布和更强沙箱。这样能先验证真实业务需求，也避免在平台早期就承担任意代码、多租户执行和复杂运行时的全部风险。

10. 上线检查清单¶

• 业务用户不需要理解镜像、Kubernetes 或 Serverless；
• 标准配置型应用与自定义代码应用使用不同发布路径；
• 每个应用有负责人、使用范围、数据级别和费用预算；
• 草稿和测试应用不能被全公司发现或访问；
• 应用权限与业务数据权限分别校验；
• 优先使用用户身份透传，应用身份遵循最小权限；
• 高风险工具调用有参数校验、审计和人工确认；
• 审批按风险分级，低风险应用可以自动发布；
• 平台根据工作负载选择共享运行时、Serverless、Worker、工作流或 Agent Cell；
• Prompt、知识库、模型和工具变更可追溯并触发回归测试；
• 应用目录提供权限申请、反馈、负责人和下线信息；
• 负责人变化、长期闲置和权限复核都有自动化流程。

延伸阅读¶

• OpenClaw 作为企业 Agent 平台底座
• Agent Sandbox 选型与架构分析
• AI Agent、沙箱与工具执行
• AI 平台安全与治理
• Knative Serving Autoscaling
• KEDA HTTP Add-on
• Kubernetes Multi-tenancy