引言

夫智能之器日进其能，则其运化之基，必固其安、其隔、其察、其御于内。众构共营，虽廉于用，然于制为甚艰。此弊者，在隔众之能既周，犹欲享器之速密耳。

古之容器，可运行工役，其效尚可，然皆栖于同核。若内用于系统，或可无碍。若处多租户之境，租户得以运行器具，执行脚本，甚或得觊文件之系，通于外界，则独恃容器，实为隐患。用微VM，既可强隔离工役，复能保其效率，方为得计。Firecracker者，乃基于VM之技，具隔离之誓，兼有容器之能，为之微VM之一实也。

此理易明：每户独享其资源（自有内核、文件系统、磁盘卷、网络边界）。凡租户之务，如配置、调度、监控、备份、恢复、认证及租户管理，皆行于共用之控面；而运行时则与控面自相隔离。

核心平台之理

其构分两面。

制御之境，掌形神，驭机枢，辨户属，调时序，察玄元，司存真，录迹彰，明政鉴.

数理之境，运真户之境。真户之域，独居微VM，授以灵机，配以神思，赐以玄盘，通以灵络。真户之灵台，别于他真。

此法尤适于智能平台，其中智能体可运行任意代码、工具、文件，调用API，浏览网络，或访问模型提供者。智能体愈强，隔离不力之风险愈大。其设计之旨，非“如何高效运行众多智能体”，实乃“如何运行众多智能体，而令一租户不为其他租户之患”。

微虚拟机何以重要

微VM之设，使各租户得有较之容器更为严密的隔离界限，盖因每租户皆得独享一客核与虚拟化之境。此乃要务，当租户得执行指令、安装软件、处理文书，或运用自主工具之时。

源模式以租户为单元，微VM隔离，独立根文件系统，租户专有数据卷，网络隔离，调度，主机弹性扩展，闲置回收，健康检测，网页管理，备份恢复，共享技能/配置分发。

此乃正道。此平台之弊，莫过于“一集群，一租户一命名空间，冀RBAC可解之。”此不足以为重任之代理。命名空间，乃管理之界，非固若金汤之安。

拟议之GCP系统架构

GCP之实现，当用无服务之控台，及基于Compute Engine之微VM之数据台。

于边陲，用户经HTTPS负载均衡之护，由云盾防护，以达平台。认证之事，则由身份平台掌之。API网关揭租户生命周期之API，如立租户、止租户、删租户、询状态、启备份、复工作空间、列主机容量是也。

云运行服务施控之理。Firestore存租户元数据、主机状态、配额信息、审计事件、备份状态及生命周期状态。云存储存根文件系统镜像、发布包、租户备份物、配置模板及共享技能包。

租户之务，运行于区域之管理实例群。每主皆为一计算引擎之虚拟机，启嵌虚拟化。及于启动，主下载核准之运行图像，自注于元数据库，报其容量，并启主代理。及于租户之立，调度者择一康健且容量充裕之主，命主代理创租户之微虚拟机。

每租户微VM各得自有之文件系统、持久数据卷、网络分接接口、CPU与内存之配额，及运行时之配置。租户之仪表盘，非设独立公端，乃经控代理路径而显之。

推荐之GCP参考架构

若欲达生产级之境，所荐架构若：

云盾以御WAF及DDoS之患
HTTPS负载均衡以应公门之需
API网关以导API之途而司其权
云行以驭控平面之务
Firestore以存元数据及生命周期之状
Pub/Sub以应异步之变

云存储，用于根文件系统、模板、备份及共享资源
密钥管理器，用于API密钥及运行时密钥
区域计算引擎管理实例组，用于微型虚拟机宿主
宿主虚拟机支持嵌套虚拟化
云监控与日志，用于可观测性

Terraform以复用之姿布设基建

此乃使无服务之管理诸务与固若金汤之租户运行基建截然分离

主要之患

最大之患，乃自欺此仅为寻常之网络应用布设。非也。此乃平台工程也。

其次之患，在轻慢网络。租户微VM路由、私有桥接、NAT、代理仪表盘、出网控制及防火墙规则，皆需精心设计。网络疏忽，可破隔离之境.

再次之患，在生命周期管理薄弱。创租户易，而安妥清理、保存数据、回收闲置资源、恢复备份、处置启动失败，此乃平台之真谛。

第四患在影移。若根文件系统影、主代理及租户配置未版本化，终将有租户于诸主间行止殊异。

终章

于GCP之上构建安全多租户AI代理平台，固其事可成，然其设计非若寻常容器平台之简。良策者，当以无服务器之控台为纲，以微VM为基础之数据层。GCP所供构建之基石，足以成此模式，尤赖Compute Engine之嵌套虚拟化、Managed Instance Groups、API Gateway、Cloud Run、Cloud Storage、Firestore、Pub/Sub、Identity Platform、Secret Manager、Cloud Armor及Cloud Monitoring诸般利器。

直言之：若所求者乃可信之多方租用AI执行平台，则勿于隔离处吝啬。容器诚便，然便利非安全之模。至若能执行工具与代码之AI代理，微虚拟机级隔离乃正道也。