qm：Y Combinator 开源的团队级多智能体工作平台

原文来源：yc-software/qm (GitHub) — Y Combinator 开源的团队级多智能体工作平台，支持 Slack 与 Web 双端、个人/共享双工作区、多 Agent 引擎可插拔，MIT 协议发布

7 月 31 日，Y Combinator 在 GitHub 上开源了 QM——他们在公司内部每天使用的多智能体工作系统。发布当天就冲上 Hacker News 热榜（635 分），仓库迅速获得 4.5k stars。YC 官方在 X 上说："我们叫它 QM，设计目标是像 Hermes 或 OpenClaw 一样容易定制，但面向整个公司使用。"

这个定位非常关键。目前市面上的 Agent 系统大多设计成"个人助理"：一个人、一个对话窗口、一堆个人工具。QM 想解决的是另一个问题：当一个团队（几十个人）要共享一套 Agent 基础设施时，怎么让每个人拥有独立空间、同时又能协作？

QM 解决的核心问题

"大多数 Agent 都是按个人助理设计的。你当然可以让它为一个公司工作，但很快会变得复杂。"这是 QM README 的第一句话，也是整个项目的出发点。

QM 面向初创公司团队。它的设计包含两个层面：

个人层面：每个员工拥有自己隔离的工作区——独立的记忆（memory）、文件、密钥管理（keychain）、定时任务（crons）、Web 应用和持久化沙箱。你在自己的工作区里让 Agent 干活，不会干扰别人，别人也看不到你的东西。

协作层面：员工可以在 Slack 频道、群组消息和项目（projects）里与 Agent 协作。同一个 Agent 可以同时服务于个人任务和团队任务，身份和配置在两个场景间无缝切换。

每个"人"和每个"房间"都有自己作用域内的记忆、文件、密钥视图、权限、定时任务和沙箱——这种"作用域隔离"是 QM 区别于个人 Agent 工具的核心架构决策。

技术架构：无头核心 + 可插拔引擎

QM 的架构围绕一个"无头核心"（headless core）设计：

• 核心服务：TypeScript 直接运行在 Node 上，用 Fastify 提供 HTTP API，负责身份、策略、调度。Postgres 作为持久层，存储会话、记忆和队列。
• Agent 循环：每一轮对话都经过核心，核心可以接入多种 Agent 引擎——Pi、OpenCode、Codex、Claude Code 都能驱动同一个核心。这意味着部署不受任何单一厂商绑定，你想用哪家的模型和引擎都行。
• 沙箱：每个作用域有自己隔离的沙箱（sandbox），Agent 通过 execute 工具在其中运行命令。沙箱是持久的——装好的工具一直在，相当于每个作用域一台"专属电脑"。
• 插件化前端：Web UI、管理面板、公共门户都是核心 HTTP API 上的可选插件；Slack 是核心内部启动并监管的进程内插件。

技术栈也很朴素：核心用 TypeScript + Node + Fastify，Slack 插件用 Bolt，Web UI 用 Vite + Lit。没有花哨的框架，依赖面克制。

安全模型：三种安全姿态

安全是团队级 Agent 系统绕不开的话题。QM 的做法继承自本地编码 Agent（OpenCode、Codex、Claude Code）的思路：Agent 以它为之工作的人的身份行事，使用该人的凭据和权限，所有操作留痕审计。

组织可以设置三种安全姿态（scope 只能收紧、不能放宽）：

• Strict（严格）：每一次工具调用都暂停等待人工审批，除了两个无副作用的收尾动作。
• Auto（自动，默认）：分类器在外部数据和工具结果进入模型之前进行来源标注与筛查；部署时可以指向组织自己的筛查代理。
• Dangerous（危险）：不做内容筛查、调用间不暂停。

值得注意的是，无论哪种姿态，预声明的命令策略（审批规则和对递归删除、破坏性 SQL 等操作的硬性禁止）都始终生效。这给"员工自己装 Agent 乱跑"的场景加了一层兜底。

部署：组织专属的部署仓库

QM 的部署哲学是"部署目录"（deployment directory）：核心是通用的，所有组织专属的东西——组织配置、自定义工具和技能、沙箱镜像、基础设施——都放在部署目录里。

npm exec --yes --package=@yc-software/qm@latest -- \
  qm init . --org <slug> --target <fly-or-aws>
npm install

初始化会生成一份部署技能文档（deployment skill），引导你完成基础设施搭建、Web 登录、连接器凭据、可选 Slack 接入、部署和线上验证——全程不需要 clone 源码。每次部署运行在操作者自己的云账号里（Fly 或 AWS）。

如果组织想要"整个代码库放一起"的私有化形态，QM 也支持私有 fork 模式：历史从 qm 克隆而来，核心保持与上游逐字节一致，组织定制放在 deploy/layers/<org>/ 下，通过 update-qm 和 upstream-pr 两个技能维护上游合并与回推的边界。

能做什么

从 README 的用例来看，QM 覆盖的日常工作相当广：

• 跨内部笔记、邮件、文档、数据库和网络搜索信息；
• 从"公司大脑"（connectors 接入的共享知识库）检索信息；
• 构建内部应用并发布给合适的人，保持数据最新；
• 学习你的写作风格后，定时整理收件箱——包括打标签和起草回复；
• 在现有代码仓库里工作：跑测试、开 PR、盯 CI、查系统日志；
• 在共享频道里跟踪项目进展、发布更新和后续事项。

我的看法

QM 最大的价值在于它把"多智能体协作"从炫技变成了工程实践。个人 Agent 工具这两年已经非常成熟，但团队级的共享 Agent 基础设施一直缺乏一个开箱即用的开源参考实现——QM 恰好补上了这个位置，而且带来了 YC 内部实际使用的经验。

值得注意的还有它的治理设计：作用域隔离 + 三级安全姿态 + 命令硬性禁止 + 全程审计，这套组合是团队部署 Agent 时的真实刚需，而不是 demo 级别的玩具。对于想给团队搭一套 Agent 基础设施的开发者，QM 是目前最值得研究的开源起点。

当然它也有局限：项目刚开源（40 个提交、0.1.4 版本），核心镜像 4.4GB 偏重，中文生态的文档和社区还需要时间积累。另外，Slack 重度依赖意味着不用 Slack 的团队需要自己补前端集成。但对于早期采纳者来说，这些都不是阻碍——MIT 协议 + 模块化架构意味着你有充分的空间按自己的需求改造它。