50个AI助手难管？YC开源总管6天狂揽1.1万Star

北京时间 7 月 30 日，一个名叫 QM 的项目出现在 GitHub。

到了 8 月 5 日晚，它已经拿到超过 1.1 万个 Star 和 1200 多个 Fork。公开仓库上线还不到一周，平均每天增加约 1700 个 Star。

这次出手的是 Y Combinator，也就是大家常说的 YC。

QM 的定位也很直接：给整个团队使用的 Multiplayer Agent Harness，可以理解成“多人版 Agent 管理系统”。

更有意思的是，QM 的起因与 Hermes 有关。

YC 此前给内部员工部署了 50 多个 Hermes，想让每个人都拥有一个可以查资料、处理文件、执行任务的 AI 助理。

Agent 真正多起来以后，新的麻烦很快出现了：

谁能看到哪些文件？不同员工的记忆会不会混在一起？模型密钥怎样分配？定时任务由谁管理？一个项目里的经验，应该共享给谁？Agent 执行危险命令时，谁来批准？

50 个 Hermes 能干活，管理这 50 个 Hermes 却成了另一项工作。

QM 就是在这段内部实践之后出现的。

公开 6 天破万 Star，背后并非 6 天赶出来的项目

先把一个容易误解的地方说清楚。

QM 的 GitHub 公开仓库确实只上线了 6 天左右，但整个项目已经在 YC 内部迭代过一段时间。

YC 最早尝试过简单的个人 Agent，后来逐步加入 Cron、Webhook、长期记忆和工具调用，又给员工部署了 50 多个 Hermes。

当 Agent 从一两个增加到几十个以后，问题的重点发生了变化。

单个 Agent 好不好用，已经不够了。

一家公司还要考虑：

• 每个人是否拥有独立空间
• 项目资料怎样共享
• 密钥能不能越权使用
• 定时任务由谁创建和关闭
• Agent 做过哪些操作
• 更换模型后原来的记忆是否保留
• 员工离职后权限怎样回收

QM 的公开版本，相当于把 YC 内部踩过的坑整理成了一套可以自己部署的系统。

因此，6 天破万 Star 说明的是公开后的关注速度，不能理解成 YC 用 6 天写完了全部代码。

QM 管的不是一个 Agent，而是一整家公司里的 Agent

普通个人 Agent 的使用方式很简单。

打开 Hermes、Claude Code 或 Codex，交给它一个任务，它调用工具并返回结果。

当十几名员工共用 Agent 时，情况会复杂很多。

张三让 Agent 整理客户资料，李四让 Agent检查代码，财务部门让 Agent 分析账单，市场部门又在同一个 Slack 频道里让它追踪项目。

这些任务不能全部堆进同一份记忆、同一个文件夹和同一套密钥。

QM 使用 Scope，也就是“作用域”，给不同的人和不同的项目划分独立空间。

每位员工可以拥有自己的 Scope，每个 Slack 频道可以拥有一个 Scope，每个团队项目也可以建立单独的 Scope。

每个 Scope 里面都能保存自己的：

• 会话和长期记忆
• 文件和工作目录
• Skill
• Cron 定时任务
• 密钥访问权限
• 模型与 Agent 配置
• 持久沙箱
• 内部 Web 应用

刚接触的朋友可以把它想象成一栋 Agent 办公楼。

每位员工有自己的办公室，每个项目组还有会议室。个人资料默认留在个人办公室，需要合作时，再把指定文件、Skill 或权限开放给项目组。

这种设计解决了团队 Agent 最棘手的问题：大家可以共用一套系统，又不会把所有人的资料搅在一起。

换掉 Claude Code，公司的记忆还在

QM 还有一个很重要的设计：组织层能力与底层 Agent 分开。

目前公开版本可以接入的 Agent Harness 包括：

• Pi
• OpenCode
• Codex
• Claude Code

公司可以让某个项目使用 Codex，让另一个项目使用 Claude Code，也可以在后面更换模型。

记忆、文件、权限、Cron、审计和沙箱依然由 QM 管理。

这意味着，公司不需要因为换了模型，就把整套 Agent 工作环境重新搭一遍。

这里也要提醒一句：

QM 的起因和 50 多个 Hermes 有关，但当前公开 README 没有把 Hermes 列入可直接切换的底层 Harness。

所以，准确理解应该是：

YC 在管理大量 Hermes 的过程中发现了组织级难题，随后做出了 QM。公开版本目前主要接入 Pi、OpenCode、Codex 和 Claude Code。

把 QM 直接说成“批量管理 Hermes 的工具”，会夸大当前能力。

一个人私聊，一个项目群聊，记忆不会随便串门

QM 同时提供 Web 界面和 Slack 接入。

员工可以私聊 Agent，得到属于自己的工作空间；也可以在团队频道里共同处理一个项目。

例如，一个产品团队可以在共享 Scope 中放入：

• 项目需求文档
• 用户反馈
• GitHub 仓库
• 测试记录
• 会议结论
• 上线清单

Agent 在这个项目里积累的记忆，其他有权限的成员也能继续使用。

同时，员工私聊里保存的个人资料不会自动进入项目频道。

QM 还允许 Agent 在后台运行 Cron 和 Watch。

它可以每天检查邮箱、跟踪项目状态、监控 CI、整理公司资料，任务完成后再把结果发回指定的个人或频道。

这已经超出了“团队共用一个聊天机器人”的范围，更接近一套有身份、权限、记忆和后台任务的 Agent 内网。

最反常识的地方：人类提交想法，Agent 负责写代码

QM 的贡献规则很特别。

官方明确提出，新增功能时，人类最好不要直接提交一大堆代码。

贡献者可以在 adrs 目录里增加一个 .txt 或 .md 文件，用自然语言解释：

• 想解决什么问题
• 为什么现在的做法不够好
• 希望最终出现什么结果

维护者确认方向后，再让编程 Agent 完成底层实现。

官方甚至提醒，不要让 AI 把几句话强行扩写成一份格式复杂的正式提案。人类只需要清楚表达判断，其余代码由他们自己的 Agent 来写。

这套方式背后的逻辑很简单：

代码越来越便宜，判断做什么依然很贵。

从近期提交速度也能看出来，QM 在一天内可以连续合并多项功能，包括自定义模型服务、浏览器模式、新建独立会话、保存 Scope 默认模型，以及多项安全修复。

过去，一个开源项目会要求贡献者提交代码。

QM 尝试把分工改成：人提出值得做的事，Agent 消耗 Token 完成实现。

安装命令只有一条，真正部署远没有这么轻松

QM 的初始化命令看起来很短：

npm exec --yes --package=@yc-software/qm@latest -- \  qm init . --org my-company --target fly

但这条命令只是生成部署目录和操作说明。

接下来还要完成：

npm installnpm exec qm -- checknpm exec qm -- doctornpm exec qm -- plannpm exec qm -- up --yesnpm exec qm -- check --live

正式部署需要准备 Node.js 24、npm 11，还要选择 Docker、Fly.io 或 AWS。

根据所选方案，后面还可能涉及：

• Postgres 数据库
• 模型服务和 API Key
• 邮件登录
• Resend 或 SMTP
• Slack 应用
• 沙箱镜像
• 云服务账单
• 域名和身份认证

AWS 路线还会用到 ECS Fargate、RDS 和 Agent 专用的隔离运行环境。

因此，QM 目前更适合已经有技术人员的创业团队。

个人用户只想让 Hermes 或 Codex 帮自己做事，直接使用现有 Agent 会更省心。为了管理一个 Agent 搭建 QM，相当于为一名员工先修一栋办公楼。

1.1 万 Star 很亮眼，v0.1.4 的坑同样真实

截至北京时间 8 月 5 日，公开 CLI 版本仍是 v0.1.4。

仓库主分支已经继续合并大量修改，公开版本和最新代码之间存在时间差。

GitHub Issues 中也出现了几类值得注意的问题。

第一类是“检查通过，启动崩溃”。

有用户使用 Fly.io 部署时，QM 没有自动上传必需的 SPRITES_TOKEN。前面的检查和部署流程都显示正常，核心服务启动后却不断崩溃，最后进入重复重启。

第二类是数据库失联后无法自行恢复。

有用户报告，Postgres 连接中断后，QM 的连接池一直处于失效状态，Web 界面所有请求开始返回 500，只能人工重启核心服务。

第三类更隐蔽。

部署命令显示沙箱、工具和环境变量已经同步成功，进入实际 Agent 沙箱后，却发现自定义工具根本不存在。

这种“系统说成功，交付物却没有真正进去”的问题，比直接报错更难排查。

QM 的安全文档也写得很坦诚。

当前版本属于早期实验软件，不能当成已经经过严格加固的企业多租户平台。管理员在授权范围内可以读取敏感内容；沙箱中的进程在实际使用密钥时可能接触明文凭据；部分浏览器操作不会重新经过核心命令审批；命令策略也可能被编码或脚本绕过。

因此，现在更适合先用测试资料和低权限账号试验，暂时不要把客户数据库、生产密钥和核心财务资料直接交进去。

QM 真正说明了什么

QM 最值得关注的地方，不止是 6 天拿到 1.1 万 Star。

它说明 Agent 正在进入一个新的阶段。

过去大家关心哪个 Agent 更聪明，哪款模型写代码更强，哪个工具能多调用几个 Skill。

当 Agent 真正进入公司，新的难题会集中到另一边：

谁有权限让它做事？它代表谁执行操作？不同项目的记忆怎样隔离？密钥怎样使用？任务失败后谁来接管？所有行为能不能追溯？

YC 部署 50 多个 Hermes 后，最先撞上的就是这些问题。

QM 给出的答案还不成熟，v0.1.4 也远没到可以闭眼上线的程度。但它抓住了一个很可能越来越重要的方向：

未来公司需要管理的不只有员工和软件账号，还会多出一支长期在线的 Agent 队伍。

谁能把这支队伍的记忆、权限、工具、成本和风险管住，谁才真正拥有可用的企业 Agent。

干货提炼

1. QM 公开仓库约 6 天突破 1.1 万 Star，项目本身此前已在 YC 内部迭代。
2. 它源于 YC 部署 50 多个 Hermes 后遇到的记忆、权限、密钥和沙箱管理问题。
3. QM 使用 Scope 隔离个人、频道和项目，每个空间拥有独立记忆、文件、Skill、Cron 和沙箱。
4. 当前公开版本支持 Pi、OpenCode、Codex 和 Claude Code，尚未把 Hermes 列为可直接切换的 Harness。
5. 它更适合有云部署能力的团队，个人用户无需急着安装。
6. v0.1.4 已出现启动崩溃、数据库失联和沙箱同步静默失败等真实问题。
7. QM 的最大启发是：Agent 数量增加后，管理和权限会比模型能力更难解决。