一、为什么这篇值得读
Claude Code、OpenAI Codex 这些 AI Agent 工具，默认是按"个人助理"设计的——一个人用一台机器，记忆、文件、登录态都归你所有。
但当公司想让 5 个员工、3 个业务角色（运营 / 客服 / 研发）共享同一套 Agent 部署时，问题立刻浮现：客服的会话上下文跑到研发的 Skill 里去了、运营误删了客服已经登录好的客服系统 token……这就是"多人 Agent"的最大拦路虎：记忆污染 + 权限混乱。
yc-software/qm（仓库名就叫 qm，下文统一简称 qm）就是为这个问题而生的开源框架。它做的事情可以一句话概括：把"单人 AI 助理"改造为"多租户 Agent 平台"，但保留每个人仍然有"自己的 Agent"的体验。本文会拆开它的设计、技术架构、与同类项目的差异，以及什么样的团队适合立刻用上它。
1.1 谁该读下去
如果你符合以下任意一条，建议继续看：
- 团队 5-50 人，正在评估"全员 AI 助手"的方案
- 已经用 Claude Code / Codex，但纠结"团队怎么共用"
- 数据合规要求高，需要每个业务角色独立审计 AI 操作
- 需要把 AI Agent 平台白盒部署到客户环境
1.2 谁可以跳过
- 个人开发者：qm 的价值在多租户隔离，个人用 Claude Code 就够了
- 已经在用 Claude Code Enterprise / ChatGPT Enterprise：商业版已带类似功能
- 没有专职 IT：qm 需要部署到 Fly.io / AWS，需要基础运维能力
二、qm 是什么
qm（仓库 yc-software/qm）是一个面向初创公司的多人员工 Agent 协作平台。它给每个员工、每个 Slack 频道、每个项目配一个独立的 Scope（隔离作用域），员工在 Slack 里 @bot，bot 会按当前频道对应的 Scope 加载记忆和工具。
2.1 一句话定位
多人员工 Agent 协作平台 = 多人协作 × 多 Harness 切换 × 三档安全姿态 × Slack 原生集成。
2.2 核心抽象：Scope
Scope（作用域）是 qm 最核心的抽象。每个 Scope 内包含：
- memory：独立记忆，不会跨 Scope 串
- files：独立工作目录
- tools：独立工具白名单
- cron：独立定时任务
- keychain：独立凭据存储
举个实际场景：客服部门的 Scope 里有客服系统登录态和客服话术 SOP，研发部门的 Scope 里有 Git 仓库权限和代码风格指南。两个 Scope 互相看不见，Agent 不会把客服话术误用到代码评审里，也不会拿研发的 Git 权限去查生产数据。
你可以把 Scope 理解为 Agent 世界的"Linux 用户隔离"——每个员工是一个独立用户，各自有各自的 home 目录、各自的 .ssh 密钥，但共享同一台机器。
2.3 类比一下现有方案
| 方案 | 隔离粒度 | 部署模式 |
|---|---|---|
| Linux 多用户 | 系统用户级 | 共享 OS |
| Docker 多容器 | 容器级 | 共享宿主机 |
| Slack 多频道 | 频道级（轻） | SaaS |
| qm 的 Scope | Agent 状态级（重） | 共享 Agent 平台 |
qm 的 Scope 隔离比 Linux 用户隔离更"重"——它不只隔离文件和进程，还隔离 Agent 的"思维状态"（记忆 + 工具结果）。
三、项目基本信息
| 维度 | 数据 |
|---|---|
| 全称 | yc-software/qm |
| 今日星数 | 22★（日榜第 1 · 新上榜） |
| Fork 数 | 7 |
| 主语言 | TypeScript |
| 许可证 | 未确认（部署导向，闭源配置层） |
| 官方 Topics | multiplayer-agent, agent-harness, slack, startup-tools |
3.1 星标曲线
qm 当日 22 颗星排日榜第 1，Fork 7。属于"慢热型"项目——产品定位稀缺（多人 Agent 协作平台在 GitHub 开源生态里几乎是空白），但尚未爆发。值得长期跟踪其迭代节奏和采用率。
3.2 仓库活跃度
最近 push 推测为 2026-08-23/24，今日活跃。创建时间 2026 年（近期新项目），意味着项目还在早期形态，参考价值大于直接采用价值。
四、qm 解决了什么真问题
要把"个人 AI 助理"规模化到团队，拦在你面前的是三件事：
4.1 三大拦路虎
- 记忆串台：员工 A 让 Agent 学了一套客服 SOP，员工 B 用同一 Agent 时被这套 SOP 干扰
- 凭据混乱：Agent 里登录了员工 A 的数据库账号，员工 B 顺手就用 A 的权限查了数据
- 执行风险：Agent 在员工 A 的工作区执行"删库"操作，没有人审批，所有人一起背锅
qm 的答案很直接：给每个员工、每个 Slack 频道、每个项目配一个独立的 Scope。
4.2 Scope 隔离的具体效果
举个 10 人电商团队的实例：
- 客服 Scope：Agent 加载客服系统 token + 客服话术 SOP，不会误调用财务接口
- 运营 Scope：Agent 加载电商平台后台登录态 + 报表权限，不会误读研发仓库
- 研发 Scope：Agent 加载 Git 权限 + 部署脚本，不会误删生产数据库
三个 Scope 之间完全隔离，但都共享同一套 qm 部署、同一份 Slack 集成。
4.3 为什么"多 Scope"比"多账号 Claude"更可行
如果让每个员工开一个独立的 Claude Code Enterprise 账号，10 个员工 = 10 份订阅 + 10 套独立记忆 + 没有跨员工协作。qm 用一个部署支撑 10 个 Scope，成本结构和协作能力都更接近"团队"而非"个人"。
五、qm 的三大核心特性
5.1 多 Harness 无关性
qm 不绑定某个 AI 引擎。它的底层 Agent 核心（Agent Loop）是抽象的，Pi / OpenCode / Codex / Claude Code 都可以作为 Harness 驱动同一个核心。
对公司的实际价值：
- 不被锁定：今天用 Claude Code，明天 OpenAI 出了更好的模型，可以直接切
- 统一管理：所有 Harness 的部署、权限、监控走同一套界面
- 混合编排：不同 Scope 可以用不同 Harness（重的任务用 Codex，轻的用 Claude Code）
这在企业 IT 里是非常关键的：没人愿意把整个公司的 AI 工作流绑死在一家 AI 厂商身上。
5.2 三档安全姿态（Strict / Auto / Dangerous）
qm 把"Agent 执行风险"拆成三档可配置的安全姿态：
| 姿态 | 行为 | 适用场景 |
|---|---|---|
| Strict | 每一步工具调用都人工审批（除无害的"turn 结束"动作） | 生产环境、新员工试用期、合规要求严格的业务 |
| Auto（默认） | 内容分类器预审外部数据 + 工具结果，可对接自建筛查代理 | 大多数日常使用 |
| Dangerous | 无内容过滤、无暂停 | 个人沙箱环境、批处理脚本、可信环境测试 |
更细粒度的安全门禁也支持：
- predeclared command policy：递归删除（
rm -rf）、破坏性 SQL（DROP TABLE）等高危命令硬拒 - 工具白名单：每个 Scope 只能调用授权范围内的工具
5.3 Slack 原生集成
qm 内置 Slack 频道作为协作界面（Bolt 框架，core 内置 in-process 插件）。意味着：
- 员工在 Slack 频道里
@bot，bot 会按频道 Scope 加载记忆和工具 - 多人共享频道里，bot 的回复对所有人可见，方便交接
- 不需要额外搭建前端 UI，Slack 就是协作界面
对已经在用 Slack 的初创公司，零额外培训成本——员工已经在 Slack 里干活，AI 助手就开在 Slack 里。
六、技术架构
qm 的整体架构分三层：
┌─────────────────────────────────────┐
│ Postgres（持久层） │
│ sessions · memory · queue │
└────────────────┬────────────────────┘
│
┌────────────┴────────────┐
│ Headless Core │
│ API · Identity · Policy │
│ Agent Loop（Pi/Codex/ │
│ Claude Code 均可） │
└────────────┬────────────┘
│
┌────────────┴────────────┐
│ Per-Scope Sandbox │
│ files · tools · 已登录服务 │
└─────────────────────────┘6.1 整体架构解读
| 层级 | 职责 | 关键技术 |
|---|---|---|
| 持久层 | 会话、记忆、任务队列持久化 | Postgres |
| 核心层 | API、身份、策略、Agent 循环 | TypeScript + Node.js + Fastify |
| 沙箱层 | 每个 Scope 的文件、工具、登录态隔离 | 进程级隔离 |
6.2 技术栈明细
| 模块 | 技术选型 | 说明 |
|---|---|---|
| 核心运行时 | TypeScript + Node.js + Fastify | 高性能 HTTP 服务框架 |
| Slack 集成 | Bolt 框架（in-process 插件） | Slack 官方 Node SDK |
| Web UI | Vite + Lit（Web Components） | 轻量级前端框架 |
| 持久化 | Postgres | 存储会话、记忆、任务队列 |
| 部署 CLI | qm init | 生成 Fly.io / AWS 部署骨架 |
6.3 部署方式
部署方式也很友好：qm init 一行命令，生成完整的 Fly.io 或 AWS 部署目录，不需要 Clone 源码——对客户做白盒部署特别方便。
- Fly.io：适合 5-50 人小团队，全球边缘部署
- AWS：适合需要合规审计的金融/医疗客户
七、与同类项目对比
| 项目 | 核心定位 | 多人协作 | 安全姿态分层 | Harness 无关 | 部署友好度 |
|---|---|---|---|---|---|
| qm | 多人 Agent 协作平台 | ✅ 核心特性 | ✅ 三档可配 | ✅ Pi/Codex/Claude Code | ✅ 一行 init |
| Claude Code | 个人 AI 编码助手 | ❌ 单人 | ❌ 内置固定 | ❌ 绑 Claude | ⭐⭐ |
| OpenAI Codex | 个人 AI 编码助手 | ❌ 单人 | ⭐ 部分 | ❌ 绑 Codex | ⭐⭐ |
| stablyai/orca | 多人 Coding Agent 协调器 | ✅ 偏项目层 | ⭐ 基础 | ⭐ 有限 | ⭐⭐ |
| 飞书 / 钉钉 AI 机器人 | 群聊 AI 助手 | ✅ 群聊粒度 | ❌ 平台托管 | ❌ 平台托管 | ✅ 免部署 |
qm 的差异化在于：它把"个人 AI 助理 → 多租户 AI 平台"的转型，做成了开箱即用的框架，而不是需要公司自己造轮子。
7.1 qm vs Claude Code Enterprise
Claude Code Enterprise 走 SaaS 路线（贵、按席位付费），qm 走自部署路线（一次部署、无限席位）。如果你的客户对数据驻留有要求（金融、医疗、企业服务），qm 是少数能给的"自托管多租户 Agent 平台"。
7.2 qm vs stablyai/orca
stablyai/orca 是同样新上榜的"多人 Coding Agent 协调器"项目（ID=9945，28 天前分析过）。两者定位有重叠但各有侧重：
- orca 偏"项目层协调"——多个 Agent 协作完成一个项目
- qm 偏"组织层隔离"——多个业务角色各自有独立 Agent，但能跨 Scope 协作
企业如果同时需要"项目协作 + 组织隔离"，可以参考两者的设计思路。
7.3 qm vs 飞书/钉钉 AI 机器人
飞书 AI 机器人、钉钉智能助理这类产品走"群聊 AI 助手"路线：
- 优点：免部署、零培训成本、平台托管
- 缺点：记忆粒度粗（仅群聊级别）、无法对接自建系统、数据驻留在平台
qm 提供的是"自托管多租户 Agent 平台"——数据在你自己的服务器、Scope 隔离更细、可对接自建业务系统。如果你对数据驻留、定制深度有要求，qm 这类自托管方案是少数选项。
7.4 选型建议
| 你的需求 | 推荐方案 |
|---|---|
| 5-50 人小团队、快速上手 | qm |
| 大企业、SaaS 化接受度高 | Claude Code Enterprise |
| 已有 Slack、重协作 | qm |
| 已有飞书/钉钉生态 | 飞书 AI 机器人 |
| 重度定制、白盒交付 | qm |
八、可落地的电商场景示例
以一家做跨境电商的小团队（10 人，3 个业务角色）为例：
8.1 场景背景
| 业务角色 | 人数 | 主要 Agent 场景 |
|---|---|---|
| 研发 | 3 | 代码审查、PR 处理、自动化测试 |
| 运营 | 4 | 报表查询、广告投放调整、竞品监控 |
| 客服 | 3 | 工单处理、退换货政策查询、FAQ 维护 |
8.2 三个 Scope 的分工
研发 Scope：Claude Code + Git 仓库权限 + 部署脚本
- 员工在 Slack
#dev-frontend频道里问"帮我看看 PR #234 的样式问题"，Agent 加载的是研发 Scope 的记忆和 Git 工具 - Agent 可以直接读 PR、跑测试、提修改建议
- 不会误调用运营的报表接口
运营 Scope：Claude Code + 平台后台登录态 + 报表权限
- 员工在 Slack
#ops-daily频道里问"昨天独立站转化率多少"，Agent 用的是运营 Scope 的平台凭据 - 不会误读到研发的 Git 仓库，也不会误删生产数据库
客服 Scope：Claude Code + 客服系统 token + 客服话术 SOP
- 客服在 Slack
#support-live频道里处理工单，Agent 加载客服话术和客服系统权限 - 不会误调用运营的报表查询接口
8.3 跨 Scope 协作场景
当运营发现"用户反馈支付失败率上升"，需要研发排查代码：
- 运营在
#ops-daily发起话题 - Agent 在跨 Scope 协作模式下自动拉研发 Scope 的代码审查 Agent 进来
- 共同定位问题（前端支付组件 vs 后端支付回调），无需员工手动切换 Agent
这就是 qm 的"跨 Scope 协作"价值——它不只做隔离，也做有边界的协作。
九、关键启示
qm 给行业的最大启发是：AI Agent 的下一个阶段不是更强的模型，而是更清晰的"团队化"模型。
9.1 Scope 隔离是行业标准解法
把"个人 AI 助理"升级为"多租户 AI 平台"，Scope 隔离是目前看到的最清晰实现路径。这个思路会渗透到所有企业级 AI Agent 产品。
9.2 Harness 无关是必然方向
不被单一 AI 厂商绑定，是企业级 AI 部署的必然方向。qm 把"Agent 引擎可插拔"做在底层，未来切换模型不需要重构应用。
9.3 安全姿态分层是落地关键
从 Strict 到 Dangerous，给团队留出"边用边调"的弹性空间。这比"一刀切禁用"或"一刀切放行"都更适合企业落地节奏。
9.4 Slack 作为协作界面
复用员工已有的协作工具（Slack / 飞书 / 钉钉）作为 Agent 协作界面，比强制推新前端 UI 更易推广。qm 的 Bolt 集成是这种思路的典型实现。
9.5 行动建议
| 你的角色 | 立即可做的事 |
|---|---|
| 技术负责人 | 在测试环境跑 qm init，先建 2 个 Scope（研发 + 运营）做 PoC |
| 产品经理 | 研究 Scope 模型，思考自家产品如何借鉴"按角色隔离 Agent 状态" |
| 创业者 | 评估 qm 是否可作为 MVP 自部署方案，控制 AI 助手的订阅成本 |
十、附录：项目基本信息
| 项 | 内容 |
|---|---|
| 仓库 | github.com/yc-software/qm |
| 星标 | 22★（日榜第 1 · 新上榜） |
| Fork | 7 |
| 主语言 | TypeScript |
| 核心栈 | TypeScript + Node.js + Fastify + Postgres + Bolt (Slack) |
| 部署 | Fly.io / AWS（qm init CLI） |
10.1 学习价值
| 维度 | 评分 | 说明 |
|---|---|---|
| Scope 隔离设计 | ⭐⭐⭐⭐⭐ | 完整的多租户 Agent 状态隔离参考实现 |
| 安全姿态分层 | ⭐⭐⭐⭐ | Strict / Auto / Dangerous 三档可借鉴 |
| 多人 Agent 协作 | ⭐⭐⭐⭐ | 频道级 + 项目级 + 个人级三层协作 |
| 部署 CLI 化 | ⭐⭐⭐⭐ | qm init 一键部署骨架，方便白盒交付 |
10.2 适合谁研究
- 企业 IT 架构师：评估"自托管 AI Agent 平台"的设计参考
- AI 产品经理：研究"多租户 AI 助手"的边界设计
- 创业者：参考 Scope 模型设计自己的 AI 产品