QM: 面向工作的多玩家智能体框架

QM 是一个多玩家智能体框架，旨在将 AI 智能体从个人助手转变为组织工具。它允许初创公司的员工在共享频道、群组消息和项目中与智能体协作，同时保持隔离的个人工作空间。

作用域内存与协作环境

QM 通过实现作用域架构来解决公司级智能体部署的复杂性。QM 不提供单一的单体智能体，而是为数据和权限提供了明确的边界：

  • 个人作用域 (Personal Scopes): 每个用户都有一个隔离的工作空间，拥有自己的内存、文件、钥匙串视图、权限和持久化沙箱。
  • 共享作用域 (Shared Scopes): 智能体可以在 Slack 频道和项目中运行，其内存和工具在小组内共享。

这种结构确保了用户可以在不影响同事的情况下根据特定需求定制智能体，同时仍能利用智能体进行团队范围内的协调。

技术架构与模型无关性

QM 被构建为一个无头核心 (headless core)，将智能体逻辑与界面及底层 LLM 解耦。

核心组件

  • 无头核心 (Headless Core): 使用 TypeScript (Node.js) 和 Fastify 编写，核心负责管理身份、策略和调度。
  • 智能体循环 (Agent Loop): 系统是模型无关的，支持各种框架，例如 Pi, OpenCode, Codex, 和 Claude Code。这通过允许操作员在不改变核心部署的情况下切换模型，从而防止了供应商锁定。
  • 持久层 (Persistence Layer): 使用 Postgres 数据库存储会话、内存和任务队列。
  • 每个作用域的沙箱 (Per-Scope Sandbox): 每个作用域都有一个持久化沙箱（一个“持久化计算机”），智能体可以通过 execute 工具在此执行命令。安装在沙箱中的工具会在会话之间保持持久。

界面插件

核心提供 HTTP API，允许各种界面接入：

  • Slack: 一个可选的进程内插件，使用 Bolt。
  • Web UI: 基于 Vite 的前端，使用 Lit 进行渲染。
  • 管理面板与公共门户 (Admin Panel & Public Portal): 用于组织管理的可选插件。

安全态势与密钥管理

QM 遵循一种安全模型，即智能体代表用户行事，利用该用户的特定凭据和权限。为了管理风险，管理员可以设置三种安全态势之一：

  1. 严格 (Strict): 除了结束回合的命令外，每个工具调用都需要人工审批。
  2. 自动 (Auto): 在数据到达模型之前，分类器会对外部数据和工具结果进行筛选。
  3. 危险 (Dangerous): 工具调用之间没有内容筛选或暂停。

无论采用哪种态势，预声明命令策略 (predeclared command policy) 都会强制执行对破坏性操作的硬性拒绝，例如递归删除或破坏性的 SQL 查询。

部署与定制化

QM 设计为部署在操作员自己的云账户中（支持 AWS 和 Fly.io），以确保数据主权。

部署选项

  • 标准部署 (Standard Deployment): 使用 qm CLI，用户可以初始化一个部署仓库，该仓库管理基础设施和连接器凭据，而无需进行完整的源码检出。
  • 私有分支 (Private Fork): 对于需要深度定制的组织，QM 支持私有分支策略。通过创建一个纯克隆版本（而非 GitHub fork）并将组织特定的配置放在 deploy/layers/<org>/ 中，团队可以在保持定制化的同时，与上游核心保持字节级一致，从而更易于合并。

实际应用场景

QM 能够实现几种高杠杆的组织工作流：

  • 公司大脑检索 (Company Brain Retrieval): 同时在内部笔记、电子邮件、邮件、文档和数据库中进行搜索。
  • 收件箱分类 (Inbox Triage): 通过学习用户过去的邮件来掌握其写作风格，从而起草回复并按计划对收件箱进行分类。
  • 仓库管理 (Repository Management): 直接在代码库中运行测试、提交 PRs 并监控 CI/CD 日志。
  • 内部应用发布 (Internal App Publishing): 启动自定义的内部 Web 应用并将其部署到特定的用户组。

社区洞察与观点

围绕 QM 的讨论突出了多玩家智能体（multiplayer agents）的的潜力以及当前 AI 领域的挑战。一些开发者指出，多玩家智能体的主要难点往往不在于循环本身，而在于上下文和权限的“作用域”问题——这正是 QM 显式地解决的问题。

然而，一些批评者对“多玩家”智能体的实用性表示怀疑，质疑他们是否仅仅是复杂的任务调度器，或者是否面临着产生“智能体对话，智能体对话”的循环而无法产生实际结果的风险。此外，关于 QM 独特的贡献模型也有显著讨论，该模型要求提供人类编写的文本描述而非代码 PRs，以避免 AI 生成的“垃圾内容 (slop)”。

"The hardest problem in multiplayer agents... has not been the agent loop. It is scoping and QM's per-person scopes plus shared rooms is a sane answer for a company-wide assistant."

"I gave an agent its own Slack channel and it started scheduling meetings with other agents without me. I've never felt more like middle management."

Sources