Managed Agents Harness 架构与选择
云端 Agent 平台有两种常见架构。一种把 Claude Code、Codex 或 OpenCode 这类现成 Harness 放进 Sandbox，VibeKit 和 LiteLLM Agent Platform 是代表，Buzz 也在复用这些 Harness。另一种把 Agent loop 留在控制面，Sandbox 只承担执行，Claude Managed Agents 和 OpenHands 采用这类边界，Manus 与 Perplexity Computer 也更接近集中调度的产品形态。前一种适合有明确起止的自动化任务，后一种更适合持续数周或数月、等待事件并服务多个用户的 Managed Agent。
Harness 的位置决定 Agent 的生命周期
Harness 负责保存上下文、发起模型请求、处理 tool call，并决定下一步动作。重试、审批、预算和子 Agent 调度也在这一层。判断它位于哪里，只需看谁持有上下文并发起下一轮模型调用。Sandbox 提供文件、进程、浏览器和网络等执行资源。
本文把 Sandbox 统一视为提供命令、文件、进程和状态生命周期的隔离执行资源，不重复比较容器、Kubernetes 与 MicroVM 的资源模型。不同 Sandbox 实现的调度、暂停、恢复和快照语义，可参考上一篇文章《OpenSandbox 与 CubeSandbox 选型》。
Sandbox 内 Harness 适合单次任务
Sandbox 内 Harness 的优点很实在。Shell、文件、PTY 和浏览器都在本地，工具调用不经过远程协议。代码索引、大文件处理和长时间终端进程也不需要反复传输结果。平台还能把 Harness、依赖和工作区固定在同一个镜像里，运行环境容易复现，也方便交付到客户 VPC。
这套结构最适合一次任务对应一个运行环境。修一个 issue、生成一份报告、执行一轮数据处理，都有明确的开始和结束。任务完成后销毁 Sandbox，状态恢复和版本迁移都很少成为主要问题。多租户隔离也容易理解，每个任务或用户得到独立容器即可。
长期运行会改变这些条件。Agent 可能等待审批，几小时后接收 webhook，下周继续同一个项目。Harness 留在 Sandbox 内时，平台只能持续保留环境，或者把进程、上下文和工作区一起暂停。文件系统快照只能保存一部分状态，待处理的 tool call、PTY、本地服务和模型循环仍要恢复。
Harness 版本也会散落在大量存量 Sandbox 中。修复一个权限问题以后，平台需要迁移或终止旧实例。模型密钥和外部工具凭据进入执行环境后，不可信代码与 Harness 进程又处于同一个故障边界。短期 token 和凭据代理可以降低风险，系统复杂度也随之增加。
长期 Agent 需要独立状态
控制面 Harness 可以在没有 Sandbox 的情况下保存 Agent。对话、memory、预算、审批状态和运行事件继续存在，执行环境则按需要创建。Agent 等待消息或定时器时不占用 Sandbox；下一次运行可以连接原工作区，也可以从快照创建新环境。
有些步骤根本不需要执行环境。模型可以读取已经整理好的上下文，调用远程 MCP，或者等待用户确认。文件操作也可以先落到虚拟文件系统，真正需要 Shell、浏览器或本地进程时再申请 Sandbox。Agent 的持续存在不再等于一台机器持续运行。
故障恢复也会简单一些。Sandbox 崩溃时，Harness 仍然保留已经完成的步骤和最后一次 observation。控制面可以换一台机器继续执行。Harness worker 自身故障时，则通过 event log、checkpoint 和 lease 在其他 worker 恢复。Agent 状态与执行环境有了各自的故障边界。
这套架构的代价是远程执行协议。Shell、文件、PTY、浏览器和流式日志都要通过 API 表达。网络中断可能让控制面不知道命令是否已经完成，协议必须提供幂等键、租约、心跳、重连和明确的命令状态。大文件与长日志还需要对象存储或引用传递。控制面也会成为多租户共享故障域，需要限制单个 Agent 的并发、上下文内存、模型请求和事件写入。
多 Sandbox 属于控制面
长期 Agent 经常需要多个执行环境。代码 Agent 可以让几个 Sandbox 分别尝试不同修复方案，再比较测试结果。测试任务也可以并行使用不同操作系统、依赖版本和浏览器。浏览器登录环境、代码工作区和 GPU 任务还可能需要不同的网络与凭据策略。
控制面 Harness 可以直接管理这些资源租约，记录每个分支的状态和预算，处理取消、部分失败与结果合并。Sandbox 内 Harness 当然也能申请其他 Sandbox，但它随后要持有调度权限，并在一个临时执行环境里承担资源管理职责。长期运行以后，平台通常还是要在外部补上任务表、调度器、审批服务和恢复状态。
平台也可以给 Sandbox 内 Harness 增加外部 checkpoint、完整内存快照、凭据代理和 session scheduler，再让一个 session 跨 Sandbox 恢复。Perplexity 的 SPACE 就展示了 session 与单个 Sandbox 分离、暂停和分叉的设计。走到这一步，长期状态和资源编排已经回到 Sandbox 外，系统开始具备控制面 Harness 的主要特征。
管控能力应留在控制面
多用户 Agent 平台需要统一管理身份、权限、审批、预算和审计。Harness 在控制面时，这些规则可以在发起模型请求和执行工具前统一检查。模型密钥与长期凭据也可以留在受管服务中，Sandbox 只拿到一次操作需要的短期权限。
Sandbox 仍然要限制网络出口和文件访问。控制面 Harness 也会接收仓库、网页和工具返回的不可信内容，prompt injection 依然可能诱导它调用高权限工具。Harness 的位置不会自动解决安全问题，它只是让策略有一个稳定的执行位置。
对单次自动化任务，最短路径依然是把成熟 Harness 放进 Sandbox。对长期 Managed Agent，用户、会话与权限都持续存在，Sandbox 只是偶尔使用的计算资源。后者更需要一个独立于执行环境的控制面。
CubePlex 的架构选择
CubePlex 选择控制面 Harness 与独立 Sandbox。CubeLoop 管理 Agent loop、上下文、MCP 路由、审批和 trace，Sandbox 提供隔离的 Shell、文件、浏览器与产物执行环境。高频本地操作可以交给 Sandbox 内的受限 worker，Agent trajectory、长期凭据和审批状态仍由控制面持有。
一次任务可以绑定一台 Sandbox。长期 Managed Agent 应当持续存在，并在需要执行时租用 Sandbox。这是 CubePlex 选择控制面 Harness 的原因。
参考资料
开源项目
把 Agent 接进团队的日常工作
CubePlex
面向团队的自托管 AI Agent 工作空间，用来处理文档、数据和跨系统任务，并统一管理权限与执行记录。
查看 CubePlex 源码CubeLoop
高性能、可追踪、生产级持久化的 Python 原生异步 Agent 框架。
访问 CubeLoop 官网