Quartermaster（QM）：YC 开源的 Multiplayer Agent Harness

2026 年 7 月，YC 开源了 QM（Quartermaster）。YC 在发布说明中回顾，团队先做过一个能访问内部数据的 Ruby agent loop，后来加上 cron 和 webhook；再后来，他们给员工配了 50 多个 Hermes 个人 Agent。Agent 很灵活，但管理这样一队 Agent 已经变得麻烦。

QM 是这段经验之后的产物。它希望保留个人 Agent 的灵活性，同时让组织能够管理模型、权限和运行环境。每位员工和每个项目按需要获得 Agent；协作发生在 Slack 频道、群消息和项目中，而不是把一个人的环境直接交给整个公司。

YC 遇到的管理问题

早期的 Ruby loop 很容易让员工上手，但能做的事情有限。补上 cron 和 webhook 后，Agent 可以在用户不在线时继续工作。个人 Agent 增加后，管理重点从单个任务转到整批 Agent 的权限、配置和运行方式。

YC 想要 Hermes 的灵活性，也想找回早期系统的简单。发布说明还提到，他们希望拥有并自行托管这套系统。QM 因此面向 startup：它先给个人和项目划出工作空间，再为协作和组织治理提供共同的规则。

个人工作与共享空间

QM 用 scope 表示工作边界。个人、频道、团队、组织和群组都有各自的 scope；项目使用 group 类 scope。每个个人和每个房间可以分别保存 memory、文件、keychain 视图、权限、cron、web app 和持久 sandbox。

QM 不会默认把所有上下文汇总给全公司。个人可以按自己的方式配置 Agent，在频道和项目里又能使用同一身份与配置。Skill 归某个 scope 所有，需要通过 grant 才能交给另一个 scope 使用；推广到全组织由管理员决定。个人经验、项目协作和组织资产因此有不同的归属和传播路径。

组织也保留了一层明确的责任。它决定可用的 harness 与模型，选择安全姿态，并管理全组织可见的 Skill。员工不必为每个频道重建自己的工作环境；管理员也不必把个人凭据和私人上下文当作公共资源。

通用核心与组织定制

这些边界需要运行时配合。QM 的 headless core 集中处理 API、身份、策略、调度和 agent loop，Postgres 保存持久状态。命令通过 execute 进入对应 scope 的 sandbox；工具安装在 sandbox 后会保留，成为该 scope 的长期工作环境。

QM 把通用 core 与组织定制分开。组织配置、自定义 tools 和 skills、sandbox 镜像及基础设施放在 deployment directory，由 qm init 部署到运营方自己的云账号。README 还给出私有 fork 的维护方式：组织把私有内容留在 deploy/layers/，让 core 保持与上游一致；update-qm 用于合并上游并创建同步 PR，upstream-pr 用于把不含组织信息的修复送回 QM。这样，组织可以维护自己的 Agent 环境，也能继续跟上公共项目。

Web、Admin 和 Portal 都是 core HTTP API 上的插件；Slack 由 core 直接启动和监督。对使用者而言，这意味着个人和团队可以在 Slack 与 Web 间延续同一身份和配置；对运营者而言，身份、策略和审计仍留在同一处控制。

文档写明的限制

QM 仍是 early、experimental 软件，并非已经硬化的公有或多租户服务边界。它的 command policy 能拦住一些危险命令，但混淆、编码或“先写后执行”仍可能绕过规则。sandbox 中正在使用的凭据是明文；内容筛选也不完整。管理员读取敏感内容会留下审计记录，但不需要再次征得用户同意。

这决定了 QM 的适用范围。它给团队提供了一套管理个人 Agent 和共享工作的方式，不替代部署方自己的安全与运维审查。浏览器 runner 也不重新经过 command policy 或人工审批，部署方需要单独评估这条路径。

来源

• YC 的 QM 发布说明
• QM README（提交 95b5a6a）
• SECURITY.md（提交 95b5a6a）