YC QM

1. 项目概览

官网上对 QM 的解释非常直接：YC 曾经内部尝试过多种 agent harness，包括早期 Ruby agent loop，以及后来为员工配置 50+ Hermes agents。随着 agent 数量上升，管理这些个人助手变得复杂，于是 YC 希望有一个更适合 startup/组织使用、又可以自托管和开源的 agent harness。QM 就是这个方向的开源结果。

我的理解：QM 解决的不是“有没有一个 AI 助手”，而是“组织里每个人、每个项目、每个 Slack 频道都开始用 Agent 后，如何统一部署、隔离、授权、审计和扩展”。

2. 官方产品形态

官方 README 中展示了 Web UI 截图：

从截图和 README 描述看，QM 的产品入口主要有两个：

• Slack：员工可以在 Slack channel、group message、项目空间里和 Agent 协作。
• Web：同一身份和配置可以延续到 Web UI，用户可以管理文件、crons、keychain、deploys、memory、skills 等。

这点对售前很重要：QM 不是脱离企业日常协作工具另起炉灶，而是把 Slack 当成自然入口，同时保留 Web 管理和更丰富操作界面。

3. 它主要能做什么

3.1 给每个人和每个协作空间一个独立 Agent scope

QM 的核心概念是 scope。每个人、每个 room/channel/project 都可以有自己的：

• memory
• files
• keychain view
• permissions
• crons
• web apps
• durable sandbox

这意味着 Agent 不再是一个全公司共用的“大机器人”，也不是每个人电脑上孤立的个人助手，而是有组织边界和协作边界的工作代理。

售前可以这样讲：

个人 Agent 解决“我怎么更快做事”，QM 解决“公司里很多人和很多项目都开始使用 Agent 后，如何让它们既能独立工作，又能在团队空间协作”。

3.2 Slack 与 Web 统一身份和配置

README 明确写到：same identity and configuration carries between Slack and the web app。

这背后有两个价值：

• 用户不用在 Slack 和 Web 两套系统里维护两份 Agent 配置。
• 管理员可以在组织层统一控制可用模型、harness、安全姿态和连接器。

适合客户对话：

员工可以从 Slack 低门槛开始使用 Agent，复杂任务再进入 Web UI；但身份、权限、记忆和配置是一套。

3.3 管理员控制模型、harness、安全姿态

QM 支持组织层配置：

• 可用 harness：Pi、OpenCode、Codex、Claude Code。
• 可用模型：Anthropic、OpenAI、OpenRouter 等。
• 安全 posture。
• 哪些模型和 harness 可被员工使用。
• connector 和 keychain 管理。

最新 release v0.1.4 中也有一项变更：限制 Web UI model picker 只能选择组织 allowed-models list。这说明项目已经在往“组织治理”方向补能力。

3.4 Durable sandbox：每个 scope 有自己的“持久电脑”

README 中说 agent 的工具面很小，其中一个工具是 execute，它会在 scope 自己的 isolated sandbox 里执行命令。这个 sandbox 是 durable computer，安装过的工具会保留。

这非常接近企业使用 Agent 时真正需要的能力：

• 每个员工或项目有独立文件系统。
• 可以安装专属工具。
• 可以保留工作状态。
• 可以运行脚本、测试、部署命令。
• 可以和 keychain/connector 结合访问外部系统。

但这也是安全风险最大的部分。它让 Agent 有了真实执行能力，因此必须重视命令审批、凭证隔离、审计和 sandbox egress。

3.5 Web Apps：生成并发布内部应用

README 列出的能力之一是 Web apps：

• Spin up custom internal apps。
• Publish them to the right people。
• Keep their data current。

换句话说，QM 不只是问答助手，还希望 Agent 能帮公司生成内部工具，例如：

• 数据看板
• 运营后台小工具
• 项目状态页
• 内部查询页面
• 客户资料汇总页面

这对 startup 非常有价值，因为初创公司常常缺少足够工程资源去开发内部工具。

3.6 Shared skills：组织级技能沉淀

QM 支持 shared skills：

• skills 可以归属于 scope。
• 可以通过 grant 分享。
• 需要 admin-gated promotion 才能提升到整个组织。
• 可以从 git repositories 导入 skill packs。

售前价值：

一个员工或项目沉淀出的高价值 Agent 操作流程，可以经过管理员审核后推广到整个公司，而不是散落在个人提示词里。

3.7 Background work：crons 和 watches

QM 支持 crons 和 watches，让 Agent 在无人盯着的时候运行工作。

典型场景：

• 定时整理邮箱并生成回复草稿。
• 每天检查项目进展。
• 定时查询数据库和生成报表。
• 监控 CI、系统日志、客户反馈。
• 监控文档或仓库变更并提醒团队。

这类后台 Agent 是从“聊天助手”升级到“半自动员工”的关键能力。

4. 典型业务场景

4.1 Startup 内部 AI 工作助手平台

QM 的官网明确说它是为 startups 设计的。初创公司往往有几个特点：

• 人少事多。
• 内部工具不完善。
• 很多信息散落在 Slack、Google Docs、邮箱、数据库、GitHub。
• 员工愿意尝试 AI 自动化。
• 对自托管、快速迭代和定制能力接受度较高。

QM 可以成为一个内部 Agent 平台，让每个员工都有自己的 Agent，同时在共享项目空间协作。

4.2 公司知识检索与“company brain”

README 中列出的能力包括：

• Search internal notes, email, documents, databases, and the web together。
• Retrieve information from your company brain。

适合场景：

• 新员工问“某客户之前为什么流失？”
• 销售问“这个行业我们有哪些案例？”
• 产品问“上次用户访谈提到的痛点在哪里？”
• 创始人问“本周关键客户进展如何？”

QM 的差异不只是 RAG，而是它可以结合 memory、files、connectors、scheduled work 和 sandbox 执行，把检索与行动连起来。

4.3 邮箱和个人工作流助理

README 里有一个很典型的例子：

• Learn your writing voice from past sends。
• Triage your inbox on a schedule。
• Include labels and reply drafts。

这对应一个非常容易打动客户的场景：Agent 学习个人写作风格，定期处理邮件，给出标签和草稿，但不一定自动发送。

售前 demo 可以设计成：

1. 连接邮箱。
2. 导入过去邮件作为风格参考。
3. 设置 cron 每天早上处理新邮件。
4. Agent 输出优先级、分类和回复草稿。
5. 人类确认后发送。

4.4 研发协作与代码仓库任务

README 明确写到可以：

• Work in an existing repository。
• Run tests。
• Open PRs。
• Monitor CI。
• Check system logs。

适合研发团队：

• 在现有 repo 中让 Agent 修 bug。
• Agent 自动跑测试。
• Agent 监控 CI 失败并给出修复建议。
• Agent 检查日志并关联到代码变更。
• Agent 在项目 Slack 频道定时汇报进展。

相比单个 IDE Agent，QM 的价值在于组织层可部署、可审计、可共享。

4.5 内部应用生成与维护

QM 支持 Agent 创建 web apps 并发布给合适的人。适合：

• 给运营团队做临时工具。
• 给销售做客户状态页。
• 给支持团队做 FAQ/工单聚合工具。
• 给管理层做指标看板。

如果客户正在讨论“用 AI 快速生成内部工具”，QM 可以作为一个较前沿的 open-source 方案参考。

4.6 多 Agent / 多 Harness 管理

QM 支持 Pi、OpenCode、Codex、Claude Code 等不同 harness 连接同一个 core。

这适合希望避免单一供应商绑定的客户：

• 可以选择不同模型和 harness。
• 可以切换底层 Agent 技术。
• 组织层统一管理部署和权限。

售前表达：

QM 不是押注某一个 Agent，而是试图做 Agent harness 的控制平面。底层可以换，组织的 scope、memory、权限和审计尽量保留。

5. 不太适合的场景

6. 核心能力清单

7. 架构与部署方式

7.1 官方架构

README 中的架构图如下：

拆开看，有几层：

• Headless core：API、身份、策略、scheduler。
• Agent loop：调用 Pi、OpenCode、Claude Code、Codex 等 harness。
• Postgres：保存 session、memory、queue、用户数据和持久状态。
• Per-scope sandbox：每个 scope 的文件、工具、登录服务。
• Plugins：Web UI、Admin、Portal、Slack 等都可以作为 core API 上的插件。

7.2 技术栈

7.3 部署模型

QM 采用一个很有特点的“部署目录 contract”：

qm.config.jsonc
package.json
package-lock.json
deployment.md
.codex/skills/deploy-qm/
.env.example
.env
slack-app-manifest.yml
slack-sso-manifest.yml
sandbox/
  tools//tool.json
  tools//
  skills//SKILL.md
  Dockerfile
plugins//Dockerfile
infra/

关键点：

• qm.config.jsonc 可提交，不包含 secret。
• .env 不提交，用于本地 secret 值。
• package.json pin 住生成该部署目录的 exact @yc-software/qm 版本。
• qm check 静态验证配置、secret names、tools、skills、plugins。
• qm doctor 只读检查外部环境。
• qm plan 渲染部署计划。
• qm up --yes 执行部署。
• qm check --live 检查线上漂移。

这套方式对售前的意义是：QM 不是一个“clone repo 然后魔改”的应用，而是希望每个组织有一个可提交、可审计、可重复执行的 deployment directory。

7.4 支持的部署目标

8. 怎么用

8.1 初始化组织部署

官方 README 推荐：

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

CLI 文档里的完整流程：

npm exec --yes --package=@yc-software/qm@latest -- \
  qm init . --org acme --target aws
npm install
npm exec qm -- check
npm exec qm -- infra render
npm exec qm -- doctor
npm exec qm -- infra build-image
npm exec qm -- plan
npm exec qm -- up --yes
npm exec qm -- check --live

8.2 选择模型 provider

部署 runbook 中提到可选择：

• Anthropic
• OpenAI
• OpenRouter

--model-provider 可设置为：

--model-provider anthropic
--model-provider openai
--model-provider openrouter

对应 key：

ANTHROPIC_API_KEY=...
OPENAI_API_KEY=...
OPENROUTER_API_KEY=...

8.3 选择登录方式

部署文档提到几类登录：

• 内置 auth broker：通过邮件一次性链接登录，需要 Resend 或 SMTP。
• Slack sign-in：适合已经跑在 Slack 上的团队。
• 外部 OIDC provider：例如 Google Workspace。
• Playground mode：公共试用部署，但必须是独立部署，不能在真实组织实例上打开。

8.4 配置 Slack bot

如果启用 Slack bot：

1. qm init 或 qm slack render 生成 Slack manifest。
2. 创建 Slack app。
3. 配置 bot token 和 app token。
4. 邀请 bot 到测试频道。
5. @mention bot 并验证回复。

8.5 自定义组织实例

QM 支持两种模式：

1. 只创建 organization-owned deployment repository，依赖 @yc-software/qm 包。
2. 使用 private fork，把组织特定配置放到 deploy/layers//，核心代码保持和 upstream 一致。

官方特别提醒：不要使用 GitHub Fork 按钮来做 private fork，因为 public repo 的 GitHub fork 无法变成真正私有，并且对象网络共享会带来 SHA 可获取问题。应该用 bare clone + mirror push 的方式创建一个独立 private repo。

9. 安全模型与风险边界

QM 的 SECURITY.md 写得很实在，售前时建议把它作为优点和风险同时呈现。

9.1 三种安全 posture

注意：即使 Dangerous 模式，预声明 command policy 里的硬拒绝规则仍然生效，例如递归删除、破坏性 SQL 等。

9.2 官方明确的限制

SECURITY.md 里有很多关键限制，售前必须知道：

• QM 是 early experimental software，不是安全认证或部署安全评审的替代品。
• 当前交互式 Agent surface 假设一个组织的已认证内部用户。
• QM is not a hardened public or multi-tenant service boundary。
• Command policy 是 speed bump，不是 sandbox boundary，可被混淆、编码、写脚本后执行等方式绕过。
• Browser actions 有些不重新进入 command policy 或 human approval。
• Sandbox credentials 在使用时是 plaintext，sandbox 里的进程可读取。
• Credential purpose 不是强制授权；凭证一旦 materialized，purpose 文本不能限制被攻陷进程如何使用。
• Auto security screening 是启发式和不完整的。
• Egress enforcement 是有条件的，deployment-runtime egress enforcement 尚未 built。
• Admin 可以读取敏感内容，读取会审计，但不是单独 consent-gated。
• Durable data 可能比用户预期保留更久，artifact expiry/byte reclamation 尚未实现。
• Published-app capability links 是 bearer authorization。

售前解读：

QM 不是通过宣传“绝对安全”来打动客户，而是比较诚实地把 Agent 执行命令、访问凭证、处理外部输入时的风险边界写清楚。对 PoC 来说这是好事；对生产落地来说则必须做安全审查和部署治理。

9.3 Agent 不能自助做的三类事

官方刻意把三类操作限制在 portal，而不是 Agent self-API：

• Admin grant changes。
• Impersonation。
• Command-approval decisions。

原因是这些操作会授权未来 Agent 行为，如果让 Agent 自己能改，就会破坏 human-in-the-loop 和权限边界。

这是很好的客户沟通点：

QM 的安全设计里有一个原则：凡是会授权未来 Agent 行为的决策，必须来自 Agent 外部的人类/portal，而不是让 Agent 自己批准自己。

10. 售前可以怎么讲

10.1 一句话定位

QM 是一个开源的组织级 Agent 工作台，让每个员工、频道和项目都有自己的隔离 Agent scope，并通过 Slack 和 Web 在真实工作流中使用。

10.2 面向 CTO / 创始人

现在很多公司已经从“个人用 AI 写代码/写邮件”进入到“组织里很多人和项目都需要 Agent”的阶段。QM 的价值在于把这些 Agent 变成可管理的基础设施：统一部署、统一模型选择、统一权限、安全姿态、审计和共享技能。

10.3 面向研发效能负责人

QM 可以让 Agent 进入现有仓库和 Slack 项目频道，执行测试、开 PR、监控 CI、检查日志，并把过程沉淀在团队协作空间里。它更像 Agent 控制平面，不只是 IDE 里的个人助手。

10.4 面向 IT / 平台工程

QM 的部署不是 SaaS 黑盒，而是在 operator 自己的云账号中运行。它通过 deployment directory 把配置、sandbox、plugins、infra 和 secrets routing 标准化，支持 Docker/Fly/AWS，不同环境可以被 check、doctor、plan、up 和 live check。

10.5 面向安全负责人

QM 提供 Strict/Auto/Dangerous 三类安全姿态、命令审批规则、scope 隔离和审计，同时安全文档明确列出了不承诺的边界。适合做受控 PoC，但生产前需要围绕 sandbox、凭证、egress、数据留存和管理员权限做专项评估。

11. 与相邻方案对比

12. PoC 建议

12.1 PoC 目标

不要把 PoC 目标定为“替代 Slack”或“企业级 Agent 平台上线”，建议定为：

验证 QM 是否能把个人 Agent 能力扩展到组织协作场景，并在 scope 隔离、安全姿态、后台任务、Slack/Web 入口和审计方面满足一个小团队的试点需求。

12.2 PoC 场景一：员工个人工作助手

流程：

1. 选择 3-5 个内部试点用户。
2. 每人创建独立 scope。
3. 配置基本 memory、files、keychain。
4. 连接邮箱或文档系统。
5. 设置一个 inbox triage 或每日总结 cron。
6. 验证 Agent 是否能生成可用摘要和回复草稿。

评估指标：

12.3 PoC 场景二：研发项目频道 Agent

流程：

1. 选择一个非核心 repo。
2. 在 Slack 项目频道中接入 QM bot。
3. 让 Agent 拉取 repo、跑测试、分析 CI 失败。
4. 让 Agent 创建一个小 PR 或修复建议。
5. 使用 Strict 或 Auto posture 观察审批体验。

评估指标：

• Agent 是否能在 sandbox 中稳定运行工程命令。
• 测试和 PR 流程是否可控。
• 命令审批是否能被研发接受。
• 失败时是否能定位原因。
• 凭证是否只在授权 scope 中暴露。

12.4 PoC 场景三：内部应用生成

流程：

1. 选择一个轻量内部需求，例如客户跟进看板。
2. 给 Agent 提供数据源和需求描述。
3. 让 Agent 创建 Web app。
4. 发布给指定人群。
5. 验证权限、数据更新、访问链接和维护体验。

评估指标：

• 从需求到可访问应用需要多久。
• 发布对象是否可控。
• 数据连接和刷新是否可靠。
• App capability link 风险是否可接受。

12.5 PoC 成功标准

13. 常见客户问题

14. 主要风险与注意事项

14.1 项目非常早期

仓库创建于 2026-07-29，最新 release v0.1.4。虽然 stars 增长快，但 open issues 已超过 100，且最近 issue 中包含部署失败、Fly target、AWS 镜像架构、OIDC 配置同步等基础问题。

售前建议：

把 QM 作为“前沿开源项目与 PoC 方案”介绍，不要作为成熟企业产品承诺。

14.2 部署复杂度不低

真实部署涉及：

• Node 24+
• npm
• Docker Buildx
• Fly.io 或 AWS
• Postgres
• Slack app / OIDC / email broker
• 模型 provider key
• sandbox image
• secrets push
• live check

这要求客户具备平台工程能力。

14.3 安全边界需要专项评估

重点关注：

• Agent 命令执行是否可接受。
• sandbox credentials 如何存放和轮换。
• scope 隔离是否足够。
• egress 是否能实际强制。
• browser provider 和 model provider 的数据留存。
• admin content read 权限是否符合合规要求。
• durable data retention 是否可控。

14.4 Slack 与企业身份集成可能卡住

部署 runbook 里指出，email domain verification 是可能卡住部署的步骤之一。Slack sign-in 可以绕开邮件发送域名问题，但又需要配置 Slack SSO app、callback、token 等。

14.5 贡献模式特殊

CONTRIBUTING.md 说明项目更希望外部贡献者提交人类写的 .txt 或 .md 提案到 adrs/，而不是直接提交代码 PR。因为底层代码大多由 coding agents 写，维护者希望先对齐想法，再由他们消耗 token 实现。

这说明项目实践很前沿，但也意味着外部社区参与方式与普通开源项目不同。

15. 售前提问清单

15.1 判断是否适合客户

• 你们现在是否已经在用个人 AI Agent？
• 员工是否在 Slack 中处理大量工作？
• 是否希望每个员工/项目有自己的 Agent？
• 是否需要 Agent 定时处理邮件、文档、项目状态或 CI？
• 是否愿意让 Agent 在隔离 sandbox 中运行命令？
• 是否有平台工程能力部署到 Fly/AWS？
• 是否能接受早期实验项目做 PoC？

15.2 判断安全和治理要求

• Agent 可以访问哪些凭证？
• 哪些命令必须人工审批？
• 是否允许 Agent 访问浏览器或外部网络？
• 是否需要所有模型请求保留审计？
• Admin 是否允许读取用户 transcript 和 memory？
• 数据保留周期和删除要求是什么？
• 是否必须通过企业 OIDC/SSO 登录？

15.3 判断 PoC 范围

• 先从个人助手、项目频道、还是内部 app 开始？
• 需要接哪些系统：Slack、GitHub、Gmail、Google Drive、数据库？
• 需要选择哪种模型 provider？
• 部署在 Fly 还是 AWS？
• 是否需要启用 Strict posture？
• 成功标准是节省时间、减少遗漏、自动生成 PR，还是内部工具上线？

16. 我的售前判断

QM 是一个很值得关注的项目，因为它抓住了 AI Agent 落地后非常现实的问题：当每个员工、每个项目、每个 Slack 频道都开始有 Agent，组织需要的不再是更多聊天机器人，而是一个能管理 Agent 身份、权限、记忆、sandbox、后台任务、技能、部署和审计的工作平台。

它最适合作为以下场景的售前材料：

• 给客户讲“个人 AI 助手如何升级为组织级 Agent 平台”。
• 帮 startup 或创新团队设计 Agent 工作台 PoC。
• 对比 Slack bot、个人 coding agent、Agent 框架和企业知识库的边界。
• 讨论 Agent 执行命令和访问凭证时的安全治理。
• 展示 YC 在内部使用 50+ agents 后沉淀出的开源方向。

但它也有明显限制：

• 版本很早。
• 部署复杂。
• 安全限制较多。
• 生产可靠性未知。
• GitHub issues 暴露出不少部署和集成问题。

一句话结论：

QM 很适合拿来和客户讨论“组织级 Agent 基础设施”的未来形态，尤其适合 startup、研发团队和平台工程团队做小范围 PoC；但目前不应包装成成熟企业产品，更不建议未经安全评估直接进入关键生产流程。

17. 快速销售摘要

18. 参考资料

• yc-software/qm GitHub 仓库
• QM 官网
• README
• SECURITY.md
• deployment.md
• docs/getting-started.md
• cli/README.md
• docs/deploy-directory.md
• deploy/layers/README.md
• CONTRIBUTING.md
• GitHub Release v0.1.4
• npm @yc-software/qm