需求大爆炸时代的底座：企业级 AI 底座的多租户技能市场架构设计

ENTERPRISE AI FOUNDATION · 技术架构论述

需求大爆炸时代的底座：企业级 AI 底座的多租户技能市场架构设计

执行沙箱让 LLM 看见运行时，组件语义化让 AI 理解企业资产，自助发布让业务人员成为供给者——当单点闭环同时成熟，真正的架构命题浮出水面：如何让千百个租户、上万件技能在一个底座上安全地共生？本文以纯技术视角，给出多租户技能市场的七平面架构设计。

承继：执行沙箱 · 组件语义化 · 自助变更通道 · 技能中枢 · 多租户设计

01工程前奏：四个单点闭环打通之后

过去一年，企业 AI 落地的工程实践沉淀了四个关键范式，每一个都在解决一个"断点"：

• 透明运行时沙箱——解决"一次性 NLP 怪圈"。传统流水线里，代码一旦部署进真实环境，LLM 就失去上下文，自动化归零。沙箱的答案是透明化优先于隔离：编译错误以结构化诊断回传、执行状态端点化、改动可备份可回滚，让"生成 → 编译 → 执行 → 诊断 → 修复"成为 LLM 可以独立走完的闭环，全程带令牌、带审计、带 traceId。
• 组件语义化（A2UI）——解决"AI 懂代码，但不懂你的组件"。大模型能生成通用 HTML，却看不见企业打磨了十年的 LeaveRequestForm。A2UI 以五层能力模型（可视化渲染 → 组件语义化 → RAG 检索 → 渐进式披露 → 深度思考对话）把企业组件沉淀转化为 AI 的领域知识，并以毫秒级动态拦截替代秒级 AICoding 生成——AI 关注业务语义，框架负责视觉呈现。
• 受限自助变更——解决"业务人员的最后一公里"。把「手机费」科目改到「通讯费」，同一句话有四种落点、成本相差三个数量级。答案不是让业务人员改代码，而是变更分级路由：能配置化的走 L0 热更新（秒级），真正需要逻辑的才走代码通道（DEV → TEST → PRE → PROD 四档，无审批不得进生产），护栏写成机器可判定的 read / write / deny / identity 清单，默认拒绝。
• 技能中枢——解决"技能墙"。当平台上有 249 个逻辑技能、492 份可执行驻留副本时，"有哪些技能、谁能执行、现在在哪、这次投给谁"四个问题需要一个不执行任何技能的权威中枢来回答：九步生命周期、墓碑删除、幂等上报，寻址解析 P0 命中率实测 100%。

图 1 · 2026 年产品演进脉络：四个单点闭环打通之后，撞上同一个天花板——单租户假设

把四条线索放在一起看，会发现一个耐人寻味的事实：它们都默认"一个平台服务一个组织"。沙箱的工作区虽然按 <tenant>/<project> 分层，但租户语义、配额、隔离从未收口；A2UI 的组件知识全域共享，技能声明没有订阅与授权的投影；自助发布通道四档齐全，但产物没有面向"别人"的分发面——隔壁部门、隔壁客户既发现不了，也装不上。

单点闭环解决的是"能不能"，多租户技能市场解决的是"给谁用、怎么发、如何管"。这正是从"会做 Agent"到"经营一个平台"的分水岭。

02中台的宿命与 AI 底座的转机

2.1 传统中台为什么总是失败

过去十年，几乎所有大中型企业都经历过"中台运动"：把各业务线共性的能力沉淀到中台，业务前台按需调用。愿景很美好，结局却高度雷同——中台变成需求池的黑洞：

• 供给是线性的：中台团队人数固定，交付速度以"人月"计，每个需求都要排期、评审、开发、联调、发布；
• 需求是发散的：10 个客户有 8 个要不同的口径、不同的流程、不同的界面，中台被迫在"做定制"与"守抽象"之间反复横跳；
• 复用是被高估的：号称沉淀的能力，业务侧真正复用的不足三成，其余需求绕过中台自建烟囱，中台愈发边缘化。

归根结底，传统中台试图用有限的、以人月计的供给，去匹配无限的、以天计的需求。供需之间隔着一个永远排不完的队列。这个结构性矛盾，靠组织调整、靠 OKR、靠"中台共创会"都解决不了——因为瓶颈不在意愿，而在生产的成本函数。

2.2 AI 底座改变了什么：供给曲线的崩塌

现在回看 2026 年的三个单点闭环，它们真正的含义是：把技能的生产成本从"人月"压到"分钟"。

• 沙箱让 LLM 自主完成"读码 → 改码 → 编译 → 验证 → 上线"——过去一个工程师一周的活，变成一条几分钟的闭环；
• A2UI让"做一个请假审批表单"从排期开发变成一句自然语言——企业组件积累直接成为 AI 的生产力；
• 变更分级路由让 80% 的高频需求落在配置层（L0 热更新，秒级生效），只有 20% 需要动代码——而那 20% 又被沙箱闭环接管；
• 技能中枢让每一件被生产出来的技能都有了统一的目录、寻址与生命周期。

四者相乘，构成了 AI 底座的技能工厂：需求以自然语言进入，以技能形态出厂。供给曲线第一次从线性变为陡增——中台进入需求和应用大爆发的阶段。这一次，瓶颈不再是"生产不出来"，而是"生产出来之后怎么办"。

图 2 · 供需反转：AI 底座把生产成本从人月压到分钟，瓶颈转移到分发、隔离与治理

2.3 新需求给架构出的四道考题

大爆炸不是洪水猛兽，而是底座价值的兑现时刻——前提是架构能回答四道考题：

1. 交付单元之问：能力、工具、场景、低代码作品、组合包，形态各异，交付单元到底是什么？——答：技能（Skill）是唯一交付单元；
2. 平台边界之问：一套底座服务教育、财务、制造、政务，隔离与计费的最小边界是什么？——答：租户（Tenant）是一等公民；
3. 分发机制之问：技能如何从"某人的作品"变成"大家的公共设施"？——答：市场（Marketplace）是技能的分发面，发布 → 审核 → 上架 → 安装 → 授权 → 升级 → 下架全生命周期可治理；
4. 权限模型之问：千租万户、万级技能，菜单与权限如何不腐化？——答：授权用 Grant，菜单是技能订阅的投影，不建第二套权限。

03新需求对架构的四个根本改写

四道考题的答案，构成了从"单体智能体平台"到"企业级 AI 底座"的四个根本改写。每一条都有一条铁律守护。

3.1 改写一：交付单元从"应用"到"技能"

过去交付一个能力，意味着交付一个应用、一个服务、甚至一个部署包。在 AI 底座上，一切可交付的能力统一收敛为技能，分四类：CAPABILITY（能力）、TOOL（工具）、SCENE（场景）、APP（应用），外加组合形态 BUNDLE。技能不是 AI 插件——它是"能被 AI 调用、被人使用、被市场分发"的统一形态。

3.2 改写二：平台边界从"项目"到"租户"

租户是隔离、配额、计费、数据主权、技能订阅的最小边界。租户的类型（ENTERPRISE / SCHOOL / GOV / TRIAL）是数据，不是代码分支——教育、财务、制造、政务都是解决方案包（Solution Pack），以业务扩展方式接入，核心架构里不允许出现任何业务词。

3.3 改写三：分发方式从"交付制"到"市场制"

交付制下，能力与人绑定、与环境绑定、与项目绑定；市场制下，技能经历完整的生命周期状态机，任何人可以在任何租户按需安装。可见性新增 TENANT_PRIVATE——企业内部技能可以只对本租户可见，这是"内部沉淀、对外隔离"的关键开关。

3.4 改写四：权限模型从"角色菜单"到"Grant 投影"

传统 RBAC 的腐化路径几乎注定：角色越加越多、菜单越挂越乱、权限与实际能力脱节。AI 底座的答案是釜底抽薪——没有"菜单实体"，只有"已安装 ∩ 已授权技能声明的菜单"。技能授权就是一条 Grant：

Grant(domain=skill, agents=[skillId], operations=[view, invoke, manage])
决策 = Grant ∩ DomainDeclaration.baseline  →  DataScope + FieldPlan

角色名（"教师""学生""财务主管"）只是数据值；权限判定不读角色名，读 Grant；菜单随安装与授权自动出现、自动消失。权限系统从"人管菜单"变成"订阅驱动投影"，腐化的根源被移除。

图 3 · 四个根本改写：交付单元、平台边界、分发方式、权限模型的范式迁移

判定规则：任何新需求先问"这是核心机制，还是某个解决方案包的业务？"——只有前者能改 A 层。学生、教师、班级、课程，与报销、凭证、开票一样，一律下沉到 Solution Pack 的配置与数据。

04总体架构：七平面与三条纵轴

把四道考题的答案纵向叠加，得到企业级 AI 底座的总体架构——七个平面自上而下、三条纵轴贯穿全局。每个平面都标注了现有载体与缺口，这不是从零设计的蓝图，而是对既有资产的"收口"。

图 4 · 企业级 AI 底座七平面架构：现有载体收口为平面，租户 / 技能 / 治理三条纵轴贯穿

七平面的读法是"收口而非重写"：A/B/C 装载机制、技能三层表、授权决策、组织身份、流程引擎、文档面板、浏览器能力全部原样复用；真正要新建的是租户纵轴（TenantContext + Filter + Executor）、订阅层（SC_SKILL_INSTALL / MENU）、市场审核与工作区三页签。平台不新建独立进程、不建第二套权限表、不改既有事件契约。

05技能平面深潜：四层模型与市场生命周期

5.1 技能四层：声明、驻留、目录、订阅

技能中枢工程已经打好了前三层——声明（技能是什么）、驻留（哪里可执行）、目录（有哪些）。多租户时代补上关键的第四层：订阅（哪个租户装了、谁被授权、菜单如何投影）。四层的写入方各不相同，这是防止"装/跑错乱"的关键设计。

最容易做错的一条：安装（订阅层）绝不写 INSTANCE（驻留层）。驻留只由执行节点上报——类比 Maven：中央仓库里的 pom 是定义，各机器里的 jar 是副本；副本可以多份，定义必须唯一。

5.2 市场生命周期：八态状态机与三条治理规则

技能从发布者手中到租户工作区，走一条完整的状态机。每个环节都有可执行的规则，而非口号：

图 5 · 技能四层模型与市场生命周期：DRAFT → IN_REVIEW → LISTED → INSTALLED → ACTIVE，旁路含驳回 / 下架 / 停用 / 卸载

市场前端不重写：控制台已有"技能市场"与"已安装技能"页面，只把数据源从历史 mock 接口切换到 skill-center 的 /api/sc/app/catalog、/api/sc/install、/api/sc/grant。页面复用、数据源收口，是整个 P0 阶段反复出现的工程纪律。

06多租户平面深潜：一条必须贯穿的纵轴

多租户不是"加一个 tenantId 字段"，而是一条必须贯穿所有执行路径的纵轴。设计上给出一张"贯穿清单"，任何一处漏接都是跨租户事故的种子：

HTTP  → TenantFilter（X-Tenant / cookie / claims）→ TenantContext
SSE   → 建流快照，进入 MessageBus 路由键
A2A   → 消息 header.tenant，入站校验
异步  → TenantScopedExecutor 显式传播
流程  → 实例属性 tenantId，启动/办理校验
知识  → 索引前缀 kb:<tenant>:<scope>，检索必须带 scope，禁止全局检索

图 6 · TenantContext 纵轴贯穿六条执行路径：任何一处漏接都是跨租户事故的种子

配额沿着同一条纵轴落地，五个卡点各司其职：用户/组织在创建时校验、技能安装数在安装时校验、存储在 VFS 写入前校验、Token 在技能调用前校验、并发在调度前校验。数据主权则要求日志、审计、对话、知识全部携带 tenantId，归档/删除按租户执行并支持导出，跨租户聚合必须显式脱敏与授权。

07治理平面：给大爆炸装上闸门

需求与应用大爆炸的另一面，是变更频率的爆炸。治理平面的任务不是拖慢变更，而是让快的变更走快车道、让危险的变更走闸门。这需要回答一个此前悬而未决的问题：同一套底座上，平台团队、领域团队、业务部门各自的变更边界在哪里？

答案是我们已经实践半年的 A/B/C 三层，配上三句口诀：

图 7 · A/B/C 三层发布节奏与治理口诀：月发布的产品基线、客户周期的领域宿主、天级的部门自助

这套分层回答了大爆炸时代最锋利的一个问题：当业务部门可以用自然语言让 LLM 改代码、发技能时，平台如何不被冲垮？答案不是禁止，而是分层放权——C 层在沙箱里自主闭环（沙箱的五道闸门、令牌鉴权、write 级策略、可回滚补丁就是它的安全边界），B 层走门禁增量，A 层冻结。授权核查有机器可判定的四清单：read / allow-add / allow-modify / deny-delete，默认拒绝。

08落地路线：P0–P5 与验收门禁

架构的落地被切成六个阶段，每个阶段有明确的门禁——没有"差不多算完成"，只有门禁全绿才进入下一阶段。P0 阶段（3–4 周）只做核心架构，不做任何教学业务。

图 8 · P0–P5 落地路线：每阶段门禁全绿才进入下一步，P0 不含任何业务功能

最终验收锚定在七条 KPI 上：租户开通 ≤ 2 分钟、技能安装成功率 ≥ 99%、授权生效时延 ≤ 2s、菜单与授权一致率 100%、跨租户泄漏 0、技能调用可追溯率 100%、核心代码业务词命中 0。这七条里，四条是"0/100%"型的硬约束——大爆炸时代的架构质量，不看平均值，看最坏情况。

09结语：底座的成功公式

回到开头的问题。传统中台失败的根因，是用线性供给追赶发散需求；AI 底座的转机，是沙箱、A2UI、自助发布、技能中枢四个单点闭环把生产成本压到分钟级——需求和应用大爆发不是危机，而是底座价值的兑现时刻。但兑现的前提，是架构能接住爆发：技能四层模型接住交付，租户纵轴接住隔离，市场状态机接住分发，Grant 投影接住权限，七道门禁与三层口诀接住治理。

如果要给企业级 AI 底座一个成功公式，那就是：

底座价值 = 需求进入的速度 × 混乱被拦住的能力。前者由技能工厂决定，后者由租户纵轴与治理平面决定——两者相乘，缺一即零。

沙箱让 LLM 敢放手改，组件语义化让企业资产开口说话，自助发布让业务人员走上生产线，而多租户技能市场让这一切可以安全地发生在一套底座、千百个租户之间。四个工程闭环的伏笔，在此收束成一套架构设计；接下来的落地实现，将验证这套设计。

企业级 AI 底座系列 · 多租户技能市场篇 ｜ 2026-10-21

Foundation × Marketplace × Tenancy —— 让每一次需求进入都有快车道，让每一种混乱都有闸门