YC 开源 QM：当每个员工都有一个 Agent，真正困难的才刚刚开始

2026 年 7 月底，Y Combinator 开源了 QM。官方给它的定位只有一句话：A multiplayer agent harness for work.

这句话里最重要的不是 agent，而是 multiplayer。

过去一年，Agent 工具大多围绕“一个人如何更高效地调用一个 Agent”展开：选择模型、接入工具、增加记忆、跑通浏览器或代码执行。但当 Agent 真正进入公司，问题会迅速从“它聪不聪明”变成“它属于谁、能看什么、能做什么、出了事谁负责”。

QM 试图把这些问题放进同一套组织级基础设施里。

一、为什么普通 Agent 到了组织里就不够用了

个人使用 Agent 时，很多边界可以靠默认信任维持：本机目录就是文件空间，环境变量就是凭证库，聊天记录就是记忆，当前登录账号就是身份。

这些约定一旦进入组织就会失效。

• 私聊中的资料，不该自动流入公共频道；
• 一个项目 Agent，不该看到另一个项目的客户凭证；
• 员工离职后，组织资产不能跟着个人账号消失；
• Slack 里的同一个人和 Web 端里的同一个人，应该拥有一致身份；
• 长任务不能因为浏览器关掉或容器重启就消失；
• 管理员需要知道某个 Agent 为什么拥有某项权限。

所以，企业 Agent 的核心难题不是模型接入，而是组织语义如何变成运行时边界。

二、QM 的核心抽象：Scope

QM 把每个员工、Slack 频道、群聊、项目或内部应用都建模为一个独立 scope。

一个 scope 不只是聊天窗口。它拥有自己的一组长期资源：

这相当于把“一个 Agent 在哪里工作”升级成了一个可治理的运行单元。

个人 DM 是个人 scope，公共频道是共享 scope。两者可以使用同一个 Agent Harness，却不会天然共享全部上下文和权限。这个设计看起来简单，实际非常关键：它让协作空间本身成为安全与记忆的边界。

三、身份不是登录按钮，而是权限系统的根

QM 让 Slack 与 Web 端共享组织身份。同一个用户从不同入口进入，仍然使用同一套个人配置、权限和资源；但他进入个人空间或团队频道时，会落到不同 scope。

• 身份回答“你是谁”；
• scope回答“你现在代表哪个协作空间工作”；
• 权限回答“这个空间允许 Agent 做什么”；
• Harness回答“具体由哪套 Agent 执行机制完成”。

模型因此变成可替换部件。QM 当前支持 Pi、OpenCode、Codex、Claude Code 等 Harness。组织不必把身份和数据边界绑定在某一家模型厂商或某一个聊天产品上。

四、持久沙箱：Agent 需要一间不会下班就消失的办公室

普通聊天式 Agent 的运行环境往往是一次性的。会话结束，进程、文件和状态也随之消失。但真实工作包含大量跨小时、跨天的任务：抓取数据、生成报告、维护网站、运行定时任务、等待审批。

QM 为每个 scope 提供持久隔离沙箱。Agent 可以保留文件、运行任务、发布内部 Web 应用，并在之后继续工作。

它的意义不是“容器不会消失”这么简单，而是把 Agent 的生命周期从一次对话延长到一个组织工作单元。

五、技能、凭证和后台任务到底归谁

组织级 Agent 最容易混乱的三个对象，是技能、凭证和自动化。

技能如果只属于某次 prompt，就无法复用；如果默认全组织共享，又会产生权限扩散。凭证如果跟着模型或个人 shell 走，就无法审计。后台任务如果没有明确 owner，则很快会变成无人知道为何存在的幽灵进程。

QM 的对象模型给出了一种清晰答案：这些资源应该归属于 scope，并由组织控制面治理。

于是，一个项目可以拥有自己的技能、API 凭证和定时任务；一个员工可以拥有个人能力；公共频道也可以拥有被团队共同维护的 Agent 行为。共享不再等于复制，隔离也不再等于每个人重新搭一套系统。

六、QM 更像控制面，不像新 Agent

从架构上看，QM 的价值更接近 Kubernetes 控制面，而不是一个新的聊天机器人。

Postgres 保存 session、memory、queue 等持久状态；组织控制面负责 API、身份、策略和调度；每个 scope 对应一个持久沙箱；Slack 和 Web 只是接入表面；Pi、Codex、Claude Code 等 Harness 位于可替换的执行层。

它把过去散落在脚本、环境变量、聊天记录和个人电脑里的东西，收拢成一套组织级 Agent Runtime。

七、安全模型：方向正确，但离成熟边界还有距离

QM 提供三种安全模式：

不过，官方 SECURITY.md 对当前限制写得很诚实：命令策略可能被编码或间接执行绕过；浏览器操作可能绕过重新审批；沙箱进程可能读取明文凭证；Prompt Injection 筛查并不完整；管理员能接触大量敏感内容；网络出口控制、紧急停机、数据保留与回收等机制仍不成熟。

因此，QM 的安全模型应该被理解为一个正在形成的设计方向，而不是已经验证过的企业安全边界。

八、哪些团队适合现在试 QM

QM 目前更适合三类使用者：

1. 正在搭建内部 Agent 平台，希望参考组织级对象模型的基础设施团队；
2. 已经在 Slack、代码仓库和内部工具间运行多个 Agent，开始遭遇身份与权限混乱的小团队；
3. 想验证“每个员工和项目都有持久 Agent 空间”这一产品形态的创业团队。

它暂时不适合直接承载高敏感、多租户、强合规的生产业务。官方也明确将项目描述为 early experimental software。

最好的试法不是立刻全公司部署，而是做一个最小真实实验：一名员工、一个共享项目、一个 Slack 频道、两种权限、一个后台任务、一次真实但低风险的凭证操作。重点观察边界是否清楚、审计是否可用、维护成本是否可接受，而不是只看 Agent 回答得是否聪明。

九、对 WeHub 的启发：未来的 Agent Harness 必须理解“人”和“我们”

QM 与 WeHub 走的是不同实现路线，但它验证了同一个变化：当 Agent 从个人工具变成组织参与者，系统必须同时理解 ME 与 WE。

个人数字分身需要连续身份、长期记忆和个人权限；团队则需要共享空间、协作边界、组织资产和跨 Agent 调度。真正的基础设施不能只管理模型调用，也不能把每个 Agent 当成孤立机器人。

QM 用 scope 把员工、频道、项目和应用统一成可运行对象。这个思路很有力量。它提示我们，未来 Agent Harness 的核心能力可能不是“能接多少模型”，而是：

• 能否让人的身份跨入口连续存在；
• 能否让共享空间拥有自己的记忆和能力；
• 能否明确区分个人资产与组织资产；
• 能否让 Agent 在可审计的边界里持续工作；
• 能否在人、数字分身和数字员工之间建立稳定协作关系。

结语：模型越来越像零件，组织运行时才是系统

QM 还很早，很多安全和治理问题没有解决。但它把问题问对了。

当每个员工都有一个 Agent，最难的不会是给每个人开一个聊天框，而是建立一套不会随着入口、模型和人员变化而崩塌的组织运行时。

模型会升级，Harness 会替换，入口会迁移。真正应该长期存在的是身份、权限、记忆、资产和协作关系。

QM 的出现，是一个值得记录的信号：Agent 时代正在从“更聪明的助手”走向“可运行的组织基础设施”。