YC 开源 QM：当每个员工都有 Agent，公司需要怎样的协作系统？
未来一家公司里，可能每个员工都有自己的 Agent。
它们能读文件、查数据库、写代码、回复邮件，也能在后台持续运行任务。
问题随之而来：这些 Agent 应该看到什么？记住什么？使用谁的账号？哪些能力可以共享？危险动作由谁批准？
7 月 31 日，Y Combinator 开源的 QM，正在尝试回答这些问题。
YC 把 QM 定义为面向工作的多人 Agent Harness，可以在 Slack 和网页中使用。按照官方说法，它已经被用于 YC 内部的财务、法务、活动和工程场景，包括开发 QM 自己。
它最值得关注的地方，不是同时运行了多少 Agent。
QM 开始把 Agent 当作组织成员来管理。
一个聊天框无法承载整个组织
大多数 Agent 都从个人助手开始。
一个人上传文件，连接邮箱，让 Agent 帮忙查资料、生成报告或者修改代码。权限属于这个人，结果也交回给这个人。
进入公司之后，关系会迅速变复杂。
同一个 Agent 在老板私聊、财务频道、产品项目群和公共讨论区里，可以看到的信息不能一样。
个人创建的 Skill 不一定适合整个团队。团队验证过的工作流也不能靠复制 Prompt 来维护。涉及付款、删除数据或者给客户发消息时，还需要清楚的批准与责任链。
公司 Agent 必须回答：
- 任务属于谁？
- 可以读取哪些资料？
- 可以使用谁的凭据？
- 结果投递到哪里？
- 失败后谁来接管？
- 能不能还原完整执行过程？
我在搭建自己的内容生产与发布系统时，也遇到过类似问题。
模型生成文章只是最简单的一步。
更麻烦的是状态怎样推进，资料和图片归属于哪篇内容，预览和实际写入如何分离，提交前怎样冻结版本，失败之后如何对账，以及人工确认应该出现在哪一步。
没有这些规则，再聪明的 Agent 也可能在错误的时间跨过错误的边界。
QM 先给 Agent 划分工作空间
QM 的基础概念是 Scope，也就是范围。
源码中定义了 personal、channel、team、org、group 等范围。每个人和每个协作空间可以拥有自己的记忆、文件、凭据视图、权限、定时任务、Web 应用和持久沙箱。
一个人在私聊中教给 Agent 的偏好，不会自动成为全公司的规则。
项目频道中的文件和记忆，也不会因为大家使用同一个 Agent，就默认向其他团队开放。
Scope 同时减少了上下文污染。
如果全公司共享一份没有边界的长期记忆，Agent 很快就会混淆个人偏好、项目规则和已经过期的信息。
上下文越多，并不自动带来更好的判断。
知识还需要归属：它来自哪里，适用于谁，能不能在当前任务中使用。
Skill 开始成为组织资产
QM 允许 Skill 归属于具体范围，再通过授权分享给其他人或团队。提升到全组织范围时，需要管理员门控。
这比“把 Prompt 发到群里”多了一层治理。
复制 Prompt 很容易。维护十个被不同人改过的版本很难。
当 Skill 进入组织，它需要回答谁负责维护、谁能够调用、适用范围是什么、更新怎样同步、出错能否回退。
这时 Skill 才从个人技巧变成组织能力。
一家公司需要沉淀的，不只是对模型说什么，还包括完成工作的步骤、工具、边界和验收标准。
后台运行改变了 Agent 的工程重点
聊天框里的 Agent 通常是同步的。
人提出问题，等待回复，然后检查结果。
组织中的很多任务需要持续运行：每天生成简报、追踪项目状态、分类邮件和工单、监控 CI、在数据变化后触发流程。
YC 的发布信息列出了 triggers、memory、shared files 和多人项目。QM 仓库中也存在 cron、任务队列、调度器、运行记录、结果投递和记忆服务。
当 Agent 开始在无人观察时工作，新的问题会出现：
- 任务会不会重复执行？
- 失败后从哪里恢复？
- 新旧任务会不会冲突？
- 结果有没有交给正确的人？
- 人接管后能不能继续运行？
Agent 在这里已经不再是一段对话，而是一项持续存在的工作。
权限决定 Agent 能走多远
QM 的安全文档把模型和沙箱视为不可信边界。
Agent 可以提出动作，可以在沙箱里运行模型生成的命令，但身份、范围、授权、结果投递和确定性的副作用门，由中央 Core 管理。
QM 提供了 Strict、Auto 和 Dangerous 三种安全姿态。
Strict 模式要求大多数工具调用经过人工批准。Auto 会筛查带来源标记的外部数据和工具结果。Dangerous 放宽过程中的暂停和内容筛查，但预定义的命令策略和部分硬拒绝仍然存在。
这些模式未必适合所有公司，却把一个问题摆到了台面上：风险容忍度必须成为系统配置，不能隐藏在 Prompt 里。
同一个动作，在个人测试环境中可以自动完成，到了生产数据库可能需要审批。
同一份资料，在项目频道里可以读取，换到另一个团队就应该被拒绝。
公司级协作需要留下清楚的责任链：谁提出请求，谁批准动作，谁承担结果。
QM 仍然是一场早期实验
YC 在发布时明确表示，QM 仍处于早期并存在 bug。
它的安全文档也强调，Scope 隔离是设计目标，不是数据绝不会泄漏的承诺。QM 目前不是已经加固完成的公开多租户服务，也不能替代部署方自己的安全评估。
所以，QM 更适合作为一个架构样本。
它同时接入 Pi、OpenCode、Codex 和 Claude Code 等不同 Harness。模型和执行框架可以替换，身份、范围、权限、记忆、调度和审计则留在共同的 Core 里。
这个分层指向一个变化：Agent 产品的竞争正在进入组织层。
模型能力和工具数量仍然重要。与此同时，系统还要让不同的人安全共享能力，让后台任务持续运行，保存清楚的责任链，并在自动化出错时把工作交回给人。
设计公司 Agent 前，先问五个问题
1. 最小协作单位是什么？
是个人、频道、项目、团队，还是整个组织？不同范围的数据如何流动？
2. 每项能力属于谁？
记忆、文件、Skill、连接器和凭据由谁创建、维护和分享？
3. 后台任务如何持续运行？
系统有没有调度、幂等、超时、重试、恢复和结果投递？
4. 哪些动作必须等待人类？
审批按单次、会话、项目还是组织规则生效？
5. 出问题时能否还原过程？
请求者、上下文来源、工具调用、批准动作、文件变化和最终投递是否都有记录？
这些问题没有回答清楚之前，增加 Agent 只会扩大系统中的不确定性。
当每个员工都有自己的 Agent，公司需要的不会只是一个更大的聊天框。
它需要让这些数字同事拥有清楚的工作空间、可复用的做事方法、受控制的行动权限、能够恢复的任务状态，以及出了问题之后找得到人的责任链。
QM 还没有给出最终答案。
但它让 Agent 从个人工具走向组织系统的变化，变得更加具体。
这值得每个正在设计 Agent 工作流的人认真关注。
历史文章推荐
- 数百个 Agent 同时写代码，真正难的不是并行
- 一个人已经提效 10 倍，为什么团队还在原地？
Hi，我是 爱学习的Niko。17 年程序员老兵，现在每天用 AI 写代码，搞创作。这里分享学习和使用 AI 的经验、技术思考、踩过的坑、实用工具和 SKILL。关注我，一起学习。