技术知识库 · 工具评测 · · 国科智飞 Gavin
qm：把「人 + Agent」放进同一个协作空间
多用户 Agent 工作台：每人独立沙箱，频道里共享协作，安全姿态分三档。它解决的是团队问题，不是个人助手。
qm 是 yc-software 开源的多用户 Agent 工作台，MIT 协议，TypeScript 实现。仓库 2026 年 7 月底创建，一周左右冲上近万星——这个速度本身就说明「团队怎么一起用 Agent」是个真问题。它的形态是 Slack + Web：每个员工有隔离的工作区，同时可以在频道和项目里与 Agent 协作，每人、每个房间都有独立的 memory、文件、keychain、cron 和沙箱。
它的定位一句话说清楚：给初创公司用的团队 Agent 平台，不是个人助手。
为什么要关注它：过去一年个人 Agent 工具已经足够好用，但团队一起用时会立刻撞上几个问题——每个人的会话、密钥、文件散在各处，没有共享上下文，也没有统一的安全边界。qm 针对的正是这层空白，一周近万星的热度反映的就是这个缺口有多真实。
能力与亮点
个人与共享两种 scope。 员工可以配一个「自己的」Agent，也可以在 Slack 频道或项目里共享协作。个人与共享各自隔离，互不污染。Slack 和 Web 共用同一套身份与配置，两个入口不是两套系统，员工换端不需要重新养成一个 Agent。
Harness 无关是最大的结构优势。 中央 Core 负责 API、身份、策略、调度，Agent loop 可插拔：Pi、OpenCode、Codex、Claude Code 都是同一核心的 driver。团队不会被任何一家模型厂商锁死，换 harness 不动上层治理。
每 scope 独立沙箱。 文件、工具、已登录服务都是隔离的，execute 工具在沙箱里执行命令，装过的工具持续保留。Agent 能干真活，但活动范围被明确圈定。
Admin 管控是一等公民。 组织级配置、安全姿态、可用的 harness 与模型清单，都在管理后台集中处理；还有 Web 应用工具，可以快速起内部应用并发布给指定的人。
安全姿态分三档。 Strict 下每次工具调用都要人工审批；Auto 是默认档，内容分类器会筛查外部数据；Dangerous 不做筛查。另外还有一份 predeclared command policy，危险命令在所有姿态下都被硬拒绝。这套「审批粒度 + 分类器 + 硬拒绝清单」的三层管控，是给团队讲 Agent 上生产时现成的安全清单。
共享技能与后台任务。 技能可以按 scope 共享、按 grant 授权，也可以由管理员提升为组织级，或直接从 git 仓库导入 skill packs。cron 和 watch 让 Agent 无人值守地周期性干活。
部署目录模型很务实。 核心保持 byte-identical，公司特有的一切——组织配置、沙箱镜像、自定义工具与技能、基础设施——都放进 deployment directory，由 CLI 校验并部署。qm init 一行初始化，部署在客户自己的云账号里（Fly 或 AWS）。MIT 协议下，这等于「开源内核 + 自托管 + 定制层」的标准商业结构。
私有 fork 的玩法值得学。 官方明确不用 GitHub 的 Fork 按钮——避免继承可见性；改用普通 clone 加 push --mirror 建私有仓库，核心与上游保持一致，定制全部放在 deploy/layers/<org>/，再用两个技能分别做「同步上游」和「回推修复」。这是开源内核与私有定制层协作的教科书做法。
持久化与入口。 会话、memory、运行队列存 Postgres；TypeScript 直接运行不用编译，Fastify 提供 HTTP 层；Portal 用 OIDC 作为统一的浏览器入口。
局限与坑
项目太新。 创建仅数周，星标速度不等于生产成熟度，接口和产品边界都可能调整。适合试点和架构参考，不适合立刻承载关键业务。
运维不是玩具级。 需要 Postgres，需要自己部署到云账号，还要管沙箱镜像与升级；想要「一条命令长期稳定运行」的人会失望。
协作价值绑定在 Slack 上。 共享 scope 的主要入口是 Slack（Web UI 也在），如果团队不在 Slack 里工作，人机协作那部分价值会大打折扣。
安全姿态要主动配置。 默认 Auto 档仍会把内容交给分类器判断，涉及敏感数据的团队得先想清楚数据流，再决定档位；Dangerous 档基本等于把沙箱交给 Agent，只适合隔离环境。
可插拔的另一面是选型成本。 Pi、OpenCode、Codex、Claude Code 的模型能力、计费和数据处理策略都不一样，团队要按任务分配 harness，而不是一套配置打天下。这既是自由，也是管理员的新工作量。
单人用户发挥不出优势。 权限、审计、共享技能这些核心能力，只有在团队真正把 Agent 纳入流程后才有意义。
适用场景
- 想把 Agent 从个人玩具升级为团队基础设施的初创公司；
- 销售、客服、运营这类多人共用 Agent 的团队；
- 有合规要求、需要把数据留在自己云账号里的公司；
- 正在设计 Agent 平台，想参考 scope 隔离、安全姿态、部署目录建模方式的架构师。
选型建议
先问一个问题：团队是否需要一个「共享的 Agent 工作空间」？如果是，qm 值得花一周做试点：用 qm init 部署一套最小环境，接一个 Slack 频道，让两三个人真实用起来，重点验证共享记忆和技能授权的手感。
安全上从 Strict 起步，摸清 Agent 的真实调用面再放宽；把 predeclared command policy 当作底线而不是可选项。技术上保持核心与上游一致，所有定制进 deploy/layers，这样升级时不会把自己锁死。试点的验收标准也很具体：共享记忆是否真的被带到下一次任务，权限是否按 scope 生效。
如果团队用的是别的单 Agent 工作流引擎，可以把它和 qm 对照着看：前者解决「一个 Agent 怎么把活干好」，qm 解决「一群人怎么一起用 Agent」。问题不同，不必二选一，但要知道自己在补哪块。
如果需求只是「一个人用得顺手」，不必上 qm，成熟的个人 Agent 客户端更省事；如果团队连 Slack 都不用，先评估 Web 端能否承担协作入口，再决定是否投入。