大多数 agent 被设计成像个人助手一样。QM 的 README 第一句就点破了它和同类产品的根本分歧:别人给个人造助手,它给公司造操作系统。这里说的操作系统不是比喻,而是字面意义上的一层把身份、策略、记忆、沙箱、调度全管起来的运行时。
我最早看到这个项目时,直觉是又一个贴着 Agent 标签的 Slack bot。毕竟 2026 年这类东西太多了,随便挂个 harness 名字就能上 HN 首页。但往下读了几段架构和 YC 自己的部署描述之后,我改观了,它真正要解决的是组织协作问题,不是模型调用问题。

QM 的全称是 Quartermaster,字面意思是船上管补给的军需官。这个名字选得很准:它不负责开炮,负责让整条船在底下井井有条地运转。身份、策略、调度、持久状态、工具访问、命令真正运行的沙箱,这些才是 QM 关心的。
YC 把它跑在了自己的会计、法务、活动、工程四个部门上,甚至用它来构建 QM 自身。一个开源项目拿自己当生产环境,这种信号比 star 数实在得多。接下来的几节把它拆开看。
核心亮点
QM 的单位是 scope(作用域),不是 user。每个员工一个 scope,每个 Slack 频道、每个项目房间也是一个 scope。每个 scope 独立拥有自己的记忆、文件系统、密钥链视图、权限、cron、Web 应用和一个持久沙箱。个人隔离和团队协同在同一个部署里同时成立,这是它和所有个人助手的硬分水岭。
模型无关是第二个被低估的设计。Pi、OpenCode、Codex、Claude Code 都能驱动同一个核心,切换模型不需要改基础设施。2026 年模型价格几周一变,把底层绑死在某一家厂商身上就是新的技术债,QM 的接口化 substrate 让换模型、换 harness、换会话存储、换沙箱都只是改一行 wiring 的事。
安全姿态是唯一一个让我觉得 YC 真跑过生产的细节。它提供三档:Strict 每次工具调用都要人审批;Auto 默认,用分类器对带来源标记的外部数据做筛查;Dangerous 完全不筛查。关键是那条预声明命令策略,对递归删除、破坏性 SQL 之类有硬拒绝,而且三档姿态下都生效。能关掉的护栏不是护栏,这条原则被写进了代码。
插件体系把核心和界面解耦。Web UI、管理员面板、公开门户都是挂在核心 HTTP API 上的可选插件,Slack 是核心启动并监管的一个进程内插件。这意味着你可以只要核心和 Slack,不要 Web UI,反之亦然。这种模块化不是营销话术,是明确的接口边界。
凭证是 scoped 的不是 ambient 的。财务的邮件 token 不会漏进工程的沙箱,scope 只能看到自己密钥链里的条目。审计是内建的,每一次出口决策都进审计槽,每一轮对话都有日志,agent 的行为可追溯到具体的人和 scope。
把这张架构图拆开,能更直观地看到为什么它是一套公司系统而不是助手。

这张图最关键的一点是:模型相关的 Agent Loop 只是核心里很小的一块,真正占代码量的是身份、策略、权限、审计这一圈。第三方源码走读给出的比例是访问控制相关文件约是模型调用循环的两倍。这不是巧合,是优先级。架构看明白之后,最实际的问题是:这套东西到底怎么跑起来?
快速体验
QM 是云优先的,意味着它不给你一个开箱即用的 SaaS,而是让你在自己的云账户里把整套系统跑起来。官方推荐的做法是把部署交给编码 agent:让它读仓库里的部署指南,然后用 qm init 一条命令生成你组织的部署仓库。
# 用 qm init 在你的组织云账户里生成部署仓库(Fly.io 或 AWS)
npm exec --yes --package=@yc-software/qm@latest -- \
qm init . --org <slug> --target <fly-or-aws>
npm install
初始化会物化出一个部署技能,引导你走完基础设施、Web 登录、连接器凭证、可选 Slack、部署和线上验证这六步。注意它不生成也不启用部署 CI,本仓库也没有生产部署工作流,上线后的运维全在你自己手里。
# 可选:想要核心和定制同仓,用 plain clone 建私有 fork(绝不能用 GitHub 的 Fork 按钮)
gh repo create <org>/qm-private --private
git clone --bare git@github.com:yc-software/qm qm-seed.git
git -C qm-seed.git push --mirror git@github.com:<org>/qm-private
git clone git@github.com:<org>/qm-private
git -C qm-private remote add upstream git@github.com:yc-software/qm
私有化这条路有个坑得单独拎出来讲。README 明确警告不要用 GitHub 的 Fork 按钮,因为公开仓库的 fork 继承可见性、还共享对象网络,做不到真正私有。正确做法是用 plain clone 加 upstream remote,这点很多团队第一次都会踩。
部署流程本身不复杂,关键是每一步要你拍板的东西都是真实的运维决策,不是填表单。把部署流程的六步串成一张图看更清楚。

如果你只是想感受一下 CLI 长什么样,上面那段 qm init 就是真实入口。它跑在你的终端里,不是某个网页后台的按钮。

适用场景与局限
QM 真正对口的,是那些已经悄悄长出一个 agent 舰队的团队:一人一个助手,凭证散在每个人的 dotfiles 里,谁批准了什么都查不清。如果你正好在这个状态,它是目前开源里最直球的解法。
| 场景 | 典型用户 | 优势 | 局限 |
|---|---|---|---|
| 小型团队舰队管理 | 50 人以内创业公司 | 隔离作用域、统一策略 | 要自托管,运维自有 |
| 部门级共享 Agent | 财务 / 法务 / 工程 | 凭证 scoped、审计可追溯 | 非技术人员上手门槛高 |
| 个人单兵作战 | 独立开发者 | 灵活可定制 | 杀鸡用牛刀,Postgres 都嫌重 |
如果你是一个人、一台笔记本,我的判断是别上 QM。你现有的编码 agent 更好用,也不会想念 Postgres。它的全部价值都建立在多人多 scope 的协作摩擦上。
它也有明确的边界。纯前端 UI 或个人工具类不是它的地盘;需要深度自定义底层时,你得走私有 fork 而不是改上游。SECURITY.md 里明说三类操作刻意只留给门户:管理员授权变更、impersonation、命令批准决策,agent 无法通过 API 自己拿到。聊完了它能做什么、不能做什么,该看看围绕着它的人群了。
社区健康度
数据先摆出来。截至 2026 年 8 月 25 日,qm 在 GitHub 上有约 1.42 万 star、1697 个 fork、316 个 open issue,MIT 协议,主语言 TypeScript,仓库创建于 2026 年 7 月 29 日。不到一个月,它已经挤进了同品类头部。
贡献者结构是个需要警惕的信号。API 返回的前两位贡献者分别有 118 和 53 次提交,其余多为个位数,整个核心明显由极少数人驱动。再加上 CONTRIBUTING 明确只接受人类写的文本、代码由维护方实现,这个项目的 Bus Factor 偏低,基本是 YC 内部小团队在撑。
Hacker News 上的反应很能说明问题。发布当天它冲到首页第二、约 505 分,但评论区并不全是欢呼。一条”它并不怎么新颖”的评论收获了不少认同,也有人把它概括为”找问题的解药”。这种质疑不是没道理,因为 QM 的卖点确实不是技术新颖,而是所有权和自托管。
反过来看,YC 自己的口径很有分量。YC 员工 Eve Bouff 在发布时说,她是 QM 的头号重度用户,“看着 YC 的合伙人和同事用它把自己放大了一千倍,着实着迷。我们是个有意地、荒谬地精瘦的团队,却产出得像一支军队。” 这种来自真实生产环境的背书,比任何演示都硬。数据、人、口碑都摆出来了,聊完这些该下我自己的判断了。
洞察与判断
我的核心判断是:QM 最值钱的不是代码,是它作为”多人 Agent 在工作”的参考架构。第三方源码走读指出一件很说明问题的事,仓库里约 13 个文件实现 harness(模型调用循环),却有约 26 个文件实现访问控制、身份、鉴权、审计、策略、凭证和安全。一个把护栏写得比脑子还多的项目,才敢让你把它接进财务数据。
值不值得跟?我的答案是:值得评估,但有前提。前提一,你确实有多人协同的 agent 需求,而不是想给个人助手换个皮。前提二,你愿意且有能力自托管,意味着 Postgres、沙箱、Slack 应用和一块你愿意持续打补丁的云账户。前提三,你接受当前阶段 YC 自己的定性:早期、有 bug、但已经相当有用。
坑点我得说透几个。
第一,没有托管版,基础设施成本和运维归你。
第二,安全姿态里 Dangerous 是真实存在的选项,Auto 默认的分类器你也可以指向自己的代理,配错就是敞口。
第三,Strict 每次工具调用都暂停等人批,生产环境人力成本极高。
第四,qm init 不替你建 CI,上线后的可靠性工程全靠自己。
和谁比,这才是重点。个人编码 harness 里 Hermes、OpenClaw 是 YC 自己点名的对照,它们是一人一机一凭证,QM 把所有权单位从人挪到了组织。SaaS 一边,HubSpot Agent Hub、OpenAI 的同类产品是绑死单厂商的付费座席,QM 是 MIT 自托管、厂商无关。开发框架那边,LangGraph、CrewAI、AutoGen 解决的是怎么编排 agent,QM 解决的是怎么让一队 agent 跨部门各守边界。它站在这几类之上的一层。
趋势上我偏乐观但有保留。star 从发布几小时内的约 1900,到三天约 7500,再到现在的约 1.4 万,曲线是典型的高速上升期。316 个 open issue 在一个月里堆出来,既可能代表高活跃,也可能代表早期的不稳定,需要结合 issue 质量判断而非数字本身。YC 自己吃狗粮加第三方源码走读的质量,让我倾向认为它在上升通道,只是远没到可以闭眼信的阶段。
资源地址
-
仓库:https://github.com/yc-software/qm -
文档:仓库内 docs/(getting-started、deploy-directory、cli) -
部署指南:https://github.com/yc-software/qm/blob/main/deployment.md -
安全模型:https://github.com/yc-software/qm/blob/main/SECURITY.md -
贡献政策:https://github.com/yc-software/qm/blob/main/CONTRIBUTING.md -
官方动态:https://x.com/qm__dev
总结
QM 不是又一个 Agent 外壳,它是 YC 把内部跑着的公司级 agent 操作系统原样开源的产物。它的稀缺性不在技术新颖,在于它把隔离、策略、审计、凭证这些最无聊也最要命的部分,做成了开源、厂商无关、能直接部署的形态。
如果你正被多 agent 的凭证混乱和组织边界折磨,它值得你花一个下午自托管试一遍。如果你只是一个人写代码,或者想要一个开箱即用的 SaaS,它大概率让你失望。工具选对了场景才是好工具,QM 的场景写得很窄,但也写得很清楚。

