从 Agent computer 到团队交付：QM 与 CubePlex 的两条路径
QM（Quartermaster）是 YC 开源的自托管多人 Agent harness，它把人、Slack 频道、群组和项目放进 Scope，并把 Scope 用作 Agent 工作环境与权限边界。CubePlex 是面向团队的开源 Agent Workspace：它先定义长期存在的 Workspace Agent，再由 Web、Slack、Discord、Microsoft Teams、飞书/Lark、钉钉与企业微信等入口决定本次运行的会话、身份和执行边界。
这种差别会影响团队每天如何使用 Agent。前一种方式适合把大量独立 Agent computer 纳入公司的权限和运行体系；后一种方式适合让同一个团队 Agent 在不同入口持续工作，又不让私聊、授权和执行环境彼此串用。
QM 的 Scope 是工作环境与权限边界
QM 当前定义了个人、频道、团队、组织和群组五类 Scope。Slack 私聊会进入个人 Scope；频道使用频道 Scope；Slack 的多人私信会进入群组 Scope。项目在实现上也是一个群组 Scope，并可关联一个 Slack 主页频道：频道成员随之成为项目成员，频道也成为计划任务和汇报的默认投递位置。
Scope 不只是界面上的分类。QM 用它决定谁能进入环境、哪些文件层可见、凭据如何授权，以及命令发往哪个持久 sandbox。一个频道 Scope 可以让频道成员围绕共同上下文工作；个人 Scope 默认不把另一位成员的文件或凭据带进来。组织、当前 Scope 与个人 Scope 可以共同参与一次解析，但它们的读写边界不同。
这套模型适合把 Agent 当作一组可配置的工作电脑来运营。团队可以为不同 Scope 准备独立的环境、文件与访问关系，并把 Slack 的人员和频道结构直接纳入 Agent 的边界定义。相应地，频道、项目或群组如果需要不同的工具组合和运行环境，配置也要随 Scope 分别维护。
CubePlex 的 Workspace 定义长期的 Agent
CubePlex 中，Workspace 是团队协作单元，也是 Agent 配置复用的边界。一个 Workspace 的 AgentConfig 保存该 Workspace 的 Persona；Skill 通过 Workspace 绑定提供；MCP 连接器状态也附着在 Workspace。成员从 Web 或 IM 入口发起工作时，面对的是同一套角色设定和基础工具，而不是因为进入了另一个 Slack 频道就换了一份 Agent 配置。
这对团队的价值很直接。研究助手、发布助手或研发助手可以有稳定的职责、指令和技能；团队不必为每个使用它的频道重新建立一套 Persona、Skills 和 MCP 连接器。Workspace 记忆还可以保存项目事实、流程和决策，让下一次工作从已有的团队上下文继续，而不是从一个新的频道 Scope 重新开始。
这并不意味着所有状态都在 Workspace 内共享。CubePlex 的 memory 有个人、Workspace 和组织三层：个人记忆只属于某位成员在当前 Workspace 内的偏好和修正；Workspace 记忆保存团队可复用的事实与流程；组织记忆用于组织范围的知识。MCP 连接器可以在 Workspace 内启用，但凭据授权可落在组织、Workspace 或用户范围。因此，同一个 GitHub MCP 可以被团队使用，同时保留每位成员自己的 OAuth 身份。
聊天入口决定运行边界
本文以 Slack 为例，是因为 QM 的 Scope 会直接使用 Slack 的私聊、频道和多人私信信息。CubePlex 的 IM bridge 同时支持 Slack、Discord、Microsoft Teams、飞书/Lark、钉钉与企业微信；这些入口绑定到同一个 Workspace 后，不会为每个 IM 位置重新创建一套 Agent 能力，而是根据入口构造会话边界。
- 私聊始终是一对一会话。即使 Bot 采用共享路由，私聊仍使用该成员自己的 Topic、个人记忆和人工确认身份。
- 群聊可采用共享或隔离路由。共享路由让同一频道成员进入一段共同对话；隔离路由则为同一频道中的每位成员保留各自的对话上下文。
- 这项路由设置目前按 Bot 账号统一生效，不是逐个频道配置。不同频道仍由各自的 Slack channel ID 区分。
执行环境也遵循这个思路。CubePlex 的 Sandbox 记录绑定到组织、Workspace 和一个 scope tuple；这个 tuple 可以指向用户、会话或 Topic。换言之，Workspace 让团队复用 Agent 的定义和资源配置，而实际运行仍可按个人或协作上下文隔离。
因此，同一个 Bot 在任何入口都有一致的人设、技能和团队知识，但它不应机械地给出完全相同的回答：私聊的历史、个人偏好和用户授权，与群聊中的共享讨论和可见权限本来就不同。这种稳定的 Agent 身份与可控的上下文差异，正是团队协作需要的组合。
复用配置，同时保留隔离
QM 的默认思路是先由 Slack 或项目上下文确定 Scope，再在 Scope 中建立相应的资源与访问关系。CubePlex 的默认思路是先建立 Workspace Agent，再把 IM 入口映射为会话和执行边界。
| 团队关心的问题 | QM | CubePlex |
|---|---|---|
| Agent 的长期定义 | 随个人、频道、群组或项目 Scope 分别组织 | Persona、Skills、Workspace 连接器和团队记忆在 Workspace 内长期复用 |
| Slack 私聊 | 路由到个人 Scope | 保持一对一会话、个人记忆和用户身份 |
| Slack 群聊 | 路由到频道或群组 Scope | 同一 Bot 可按账号选择共享上下文或按成员隔离 |
| 执行环境 | Scope 对应持久 sandbox | Sandbox 可按用户、会话或 Topic 绑定，仍属于同一 Workspace 的治理范围 |
| 连接器认证 | 由 Scope 与授权关系决定 | 连接器可为 Workspace 复用，凭据可按组织、Workspace 或用户授权 |
QM 的项目 Scope、Slack 名册联动和 Scope 级环境组织有明确的产品语义。CubePlex 则把团队 Agent 的长期定义集中在 Workspace 内，把入口差异留给会话、身份、权限和执行边界处理。对于希望部署一个稳定的团队 Agent、让它出现在多个协作入口，又不希望重复维护每个频道配置的团队，这种组合更接近日常工作方式。
团队交付物留在 Workspace
一项研究、发布准备或客户方案通常不止经历一段对话。成员会补充资料、审阅结果、连接不同系统，并在后续继续修改文档、代码、表格或图片。CubePlex 将这些工作放在同一个 Workspace：成员和角色控制参与范围，Artifact 保留文件、预览和生成结果，Workspace memory 保留可复用的事实，Sandbox 则为具体的用户、会话或 Topic 提供执行状态。
这使团队不必在“共享一个没有边界的 Bot”和“为每个 Slack 位置复制一台 Agent computer”之间二选一。一个 Workspace 可以承载长期的 Agent 能力；不同入口仍保留它们应有的私密性、权限和运行上下文。
来源与版本
开源项目
把 Agent 接进团队的日常工作
CubePlex
面向团队的自托管 AI Agent 工作空间，用来处理文档、数据和跨系统任务，并统一管理权限与执行记录。
查看 CubePlex 源码CubePi
高性能、可追踪、生产级持久化的 Python 原生异步 Agent 框架。
查看 CubePi 源码