云原生 · 看图理解
一个沙箱跑在千里之外的算力集群里，你的 Agent 每天要对它发号施令：跑个命令、读个文件、开个浏览器桌面。这些请求怎么进去？谁能进来？沙箱又能访问谁？
这篇讲 AIOS Sandbox 的网络架构设计。还是用旅馆来打比方------但这次主角不是 Kubernetes，而是电话、大门和门禁。
先说历史教训：为什么不能直拨房间内线
最早的设计很直觉：管理端直接连沙箱 Pod 的 IP。就像知道了房间内线号，直接拨过去。
结果败得很干脆。Pod IP 只在它所在的算力集群内部可达------内线只在园区内有信号。管理端在另一个集群，拨过去只有 no route 和超时。运行时请求全挂。
这个教训定了两条铁律：房客代理人永远只配一个总机地址；房间内线永远不出园区。
现在的样子：一个总机，每园一个大门
图里三个角色。BoAgent 是房客代理人，手里只有总机一个号码：Portal 的 :30083。创建沙箱、跑命令、读写文件，全部打给总机。
总机（Portal 集群）不只是接线员。它先验票------查 token 签名和有效期，核对票面房间号与请求一致；再查档------按凭据确定沙箱在哪个园区，房间号说了不算，凭据说了算；最后做翻译------把官方 SDK 的"envd 方言"翻译成沙箱里实际跑的"execd 方言"。
每个算力集群是一座园区，对外只暴露一座大门（固定入口，beyond-elb 的固定 IP）。门里有位导览员（OpenSandbox Ingress），按 /房间号/端口/ 的 URI 现场查到该沙箱当前 Pod，透明转发。房间搬迁、重建，URI 不变，导览员总能找到新内线。
浏览器类的流量------noVNC 桌面、CDP 调试、自定义 HTTP/WS------不走总机，拿到授权入口后直达所属园区的大门。所以它们与 E2B 数据面是两条独立链路，各自发布、各自回滚。
一个请求的完整旅行
跟着一条"帮我跑个命令"走七站。
SDK 出发时，路径里没有房间号------目标是总机加操作名，房间号放在 Header 里。三个关键行李：房间号、部门号 49983、门票 token。
总机验票、选园区、做翻译后，请求带着 /房间号/44772/命令 的新 URI 转接园区大门。大门查门禁------来源在不在白名单？不在就 403。
进门后是一段固定接线：大门 80 到导览台 28888 是静态端口映射，只换端口不看内容。导览员拿到完整 URI------前缀必须一路带到这，中途剥掉就没人知道找哪个房间 ------解析出房间号，查到当前内线，把请求送到 Pod 的 44772。响应原路返回。
三个最容易记错的点：49983 是 Header 里的逻辑服务标识，不是任何机器的监听端口；80→28888 是接线，28888→44772 是找路，一个是静态映射一个是动态代理，性质完全不同；目前总机支持的 E2B 操作共六种（进程启动、文件读写删、列目录、Remove），其余明确返回不支持。
门禁：进看出身，出看许可
进门这半边，配置有两个来源：模板默认值和实例自己。管理员在模板上配"这类房间默认放谁进来"；用户基于模板建沙箱时抄一份当初始值，之后各改各的------模板更新不追平老房间。
规则的载体是"每个房间一张独立门禁卡"------一个受管 Ingress 对象。共享大门把所有卡汇总成 path 级规则：/房间A/ 和 /房间B/ 的来源限制互不影响。2026 年 9 月 1 日的现场穿刺证明了这条路真实可行：同一座大门，来源 A 访问路径 A 得 200、访问路径 B 得 403，来源 B 恰好相反。
出门这半边更严：默认一律不许出。只放行两样------平台的 DNS（问路是刚需），和你明确写进许可的目的地 CIDR。载体是每次分配一条 NetworkPolicy，只认 IPv4 CIDR。
验证过才算数
改门禁最怕改了一半：写成功但没生效，或者写坏了却没人知道。所以每次修改走四步：提交新名单（全量替换，不是打补丁）→ 写入对象并标记"验证中" → 从 apiserver 回读，和期望逐项比对 → 全对才标记"验证通过"，存为最新 LKG。
任何一步失败，自动恢复上一份验证过的配置（Last Known Good），再回读确认。恢复成功报"更新失败、已复原"；连恢复都失败才报"状态不确定"交给人工。铁律是：失败永远不放大门，也不回退成模板默认。
删除走同样的 fail-closed 逻辑：先撤门禁卡、确认撤掉，再删沙箱本体；撤卡没确认前，宁可保持不可访问。
诚实的边界
这份设计的验收口径要读仔细。整套"验证通过"都是对象级的------读回 Kubernetes 配置对象核对无误，不等于每个数据包都实时按规则转发；包级行为由 CNI 准入矩阵另行验收，准入不过的园区会停发新沙箱。
还有几处是"目标"而非"现状"：官方 E2B 的 allow_internet_access 等网络字段的兼容映射尚未实现，调用方现在应使用自己的模板网络或实例接口；Native Browser 的独立通道是否继承实例门禁，未证明。而且这些是工作区代码的静态核对结论，本轮没有部署上线、没有重跑在线验收。
和前几篇连起来
前几篇讲的是沙箱里的计算（快照、恢复），这篇讲的是沙箱的血管：请求怎么进、流量怎么出、边界怎么守。
你会发现同一个设计哲学贯穿始终：OSEP-0015 用 CR 对象做控制面与数据面的唯一耦合，这篇用 Kubernetes 对象（Ingress、NetworkPolicy）做门禁的唯一事实源------每次都回读核对，验证过才算数。不轻信"写入成功"，不宣称"应该生效"，这是同一套谨慎在两个系统里的回声。
图解为帮助理解而简化。完整设计见《AIOS Sandbox 网络架构设计概要设计》v2.8（2026-09-08）；现状口径以架构核对报告为准，本文不新增验证结论。