今天 CubePlex 正式开源。源码已经发布在 GitHub，采用 Apache-2.0 许可证，后端、Web 应用、部署资产和产品文档都可以直接查看和使用。
Agent 从个人工具走向团队使用，有一个很直观的标准：一个人跑通的 AI 工作流可以被其他成员再次运行，不需要凭聊天记录和个人记忆从头重建。现在的 Agent 已经能写代码、查资料、处理文件和调用外部工具，难点逐渐从“能不能完成一次任务”变成“怎样把这次成功留在团队里”。
CubePlex 是为 Managed Agents 构建的开源工作区。它把对话、团队成员、Skills、Memory、MCP 工具和隔离执行环境放进同一个协作空间，让 Agent 的工作可以被看到、接手和重复使用。
2026 年 8 月 6 日，Agent Plugins 项目以开放、厂商中立的插件标准对外发布。初始技术委员会由五名 Core Maintainer 组成，他们分别来自 Amazon、Cursor、Microsoft、OpenAI 和 Vercel，Lead Core Maintainer 是 Vercel 的 Jonathan Hefner。
项目的治理席位属于维护者个人，没有为公司预留席位，任何单一厂商也不能控制多数 Core Maintainer。更准确的说法是，来自这五家公司的维护者共同发起了一项由社区治理的开放规范。
Agent Plugins v1.0.0 目前仍是 Working Draft。它规定每个 Plugin 必须包含 plugin.json，Agent Skills 放在 skills/，MCP server 配置放在 mcp.json。客户端还可以通过反向域名命名的 extension 加入自己的行为，同时不改变可移植的核心格式。
这份规范要解决的是 Agent 客户端之间的插件格式分裂。同一套 Skill 和 MCP 配置以前需要按不同客户端的目录与配置方式重新整理。Agent Plugins 给出了统一的目录结构、schema 和加载规则，让兼容客户端可以发现同一个插件包。
我把 v1.0.0 规范和 Future Considerations 对了一遍。认证被明确留给了客户端。当前草案没有定义 OAuth 配置或可移植的凭据引用，远程 MCP 的授权发现、用户交互和凭据存储也由客户端处理。这条边界符合包格式的职责，却把最影响实际使用的一段流程留在了每个 Agent 产品里。
Skills 和 MCP 承担不同的工作。Skill 告诉 Agent 怎样完成任务，MCP 负责连接外部系统。一个 Plugin 可以把两者一起交给客户端，用户仍可能要分别处理命令行登录、OAuth 授权和 API key。组件已经装好，连接还未必可用。
云端 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。
智能体工具让人们可以轻松地把请求变成行动。这很有价值，但也带来了一个新的运营问题：当对话结束后，工作存放在哪里？
对个人而言，一段短暂的聊天或许已经足够；对团队而言，通常并非如此。工作包含输入、约束、工具、审批、输出，以及发生过程的记录。当这些部分散落在聊天线程、浏览器标签页和私人账户中时，团队无法有把握地复用或审查结果。
OpenSandbox 和 CubeSandbox 都为 Agent 提供隔离的代码执行环境，但两个项目的工程重点不同。OpenSandbox 把 Sandbox 纳入 Kubernetes 资源和调度体系；CubeSandbox 自带从控制面到 KVM MicroVM 的执行栈，重点解决高并发创建、运行状态保存和快速恢复。
自托管常被描述为一种安装选择。对智能体系统而言，它更准确地说是一种运行模式。
智能体运行在何处，决定了凭据保存在哪里、哪些数据可被访问、网络访问如何被治理，以及谁能够检查它的执行过程。这些不是等工作流已经证明有用之后才补上的细节，而是从一开始就属于工作流的一部分。
第一次有价值的智能体交互，往往看起来出奇地简单：有人提出请求，智能体检索上下文、运行工具，然后给出答案或产出一份工件。
接下来更重要的问题是：团队能否在不凭记忆重建整个过程的前提下，再次运行这项工作？