QM是一个为初创公司设计的多人智能体协作平台，支持Slack和网页端。每位员工拥有独立工作空间，可互不干扰地协作。平台内置个人与共享作用域、记忆、文件、密钥管理等功能，并兼容多种AI模型（如Pi、OpenCode等），实现开源灵活部署。

好的，这是根据您的要求，对原文进行中文重述后的版本：

项目名称： QM - 一个面向工作的多智能体协作平台

核心定位： QM 是一个专为初创公司设计的开源多智能体协作平台，可在 Slack 和网页上使用。与传统的个人助手型 AI 不同，QM 允许公司内的每位员工拥有自己独立的工作空间，互不干扰，同时也能在频道、群组消息和项目中与 AI 智能体进行协作。

主要特点：

• 个人与共享空间： 每个人和每个房间（频道/项目）都拥有独立的记忆、文件、密钥、权限、定时任务、Web 应用和沙箱环境。员工可以个性化定制属于自己的智能体，同时也能在 Slack 频道和项目中协同工作。
• 多平台支持： 同一身份和配置可在 Slack 和 Web 应用间无缝切换。
• 管理员控制： 可设置组织级别的配置、安全策略，并选择可用的 AI 模型和驱动框架。
• 内部应用构建： 能快速创建自定义的内部 Web 应用，并发布给特定人员使用。
• 共享技能： 技能可按作用域拥有，并通过授权进行共享。管理员可将技能推广至整个组织，或从 Git 仓库导入技能包。
• 后台工作： 支持定时任务和监控任务，在无人值守时自动运行。

核心功能与应用场景：

• 统一搜索内部笔记、邮件、文档、数据库和网络信息。
• 从公司知识库中检索信息。
• 构建内部应用并保持数据更新。
• 学习用户的写作风格，并按计划处理收件箱（包括标签和回复草稿）。
• 在现有代码仓库中工作：运行测试、创建 PR、监控 CI、检查系统日志。
• 在共享频道中跟踪项目进度，并发布更新和后续事项。

技术架构：

• 核心： 一个无头核心，包含 API、身份验证、策略和调度器。核心使用 TypeScript 和 Node.js 构建，通过 Fastify 处理 HTTP 请求。
• AI 模型： 核心可接入多种模型和驱动框架（如 Pi, OpenCode, Codex, Claude Code），不绑定于特定供应商。
• 持久化层： 使用 Postgres 数据库存储用户数据、会话历史等状态。
• 沙箱： 每个作用域拥有一个独立的、持久的沙箱环境，用于执行命令和运行工具。
• 插件： Web UI、管理面板和公共门户是可选的插件，通过核心的 HTTP API 运行。Slack 插件作为进程内插件运行。
• 部署： 所有公司特定的配置（组织配置、自定义工具、沙箱镜像等）都存放在一个“部署目录”中，通过 qm CLI 进行验证和部署。

安全与机密：

QM 的安全策略遵循本地编码智能体的模式：智能体以用户的身份行动，拥有其凭证和权限，所有操作都会被审计。组织可以选择三种安全级别：

• 严格： 每次工具调用都需要人工批准。
• 自动（默认）： 在数据进入模型前，由分类器筛选外部数据和工具结果。
• 危险： 无内容筛选，无工具调用暂停。

部署方式：

用户可以通过 qm init 命令在自己的云账户中快速初始化一个部署仓库，无需检出源代码。该过程会引导用户完成基础设施搭建、Web 登录、连接器凭证、Slack 接入等步骤。

贡献方式：

项目接受以人类可读的文本文件（.txt 或 .md）形式提交的贡献，而非直接提交代码。安全漏洞应通过 SECURITY.md 中描述的方式私下报告。

自定义实例：

对于希望将整个代码库和自定义配置放在一起的组织，可以采用“私有分支”的方式。即创建一个独立的私有仓库，其核心代码与上游保持字节一致，所有组织特定的配置（如 deploy/layers/<org>/）都放在其中。这种方式可以避免 GitHub Fork 功能带来的可见性和对象网络共享问题。

许可协议：

QM 采用 MIT 许可证。

根据评论内容，主要观点和论据如下：

1. 对AI项目要求“人工撰写”的讽刺（评论1、2） - 评论1指出行业存在“AI精神病”问题，认为AI项目要求人工撰写文本是矛盾的。 - 评论2讽刺道：“一个由AI编写的AI项目，却要求人工撰写文本并明确禁止使用AI。” 关键引用：“Given that coding agents write most underlying code now, we'd prefer PRs in the form of human-written text.”

2. 对工具实用性的质疑（评论3、4、7） - 评论3询问Hermes是否是最佳开源类代理，以及用户实际用途。 - 评论4认为工具“看似运行在用户云账户，实则类似单机VM”，建议改用Hermes/Openclaw或Tasklet等。 - 评论7认为这是YC“仓促推出的内部工具”，以应对Buzz竞争。

3. 对多代理协作方向的认可（评论8、9） - 评论8肯定“多代理协作”方向，认为“作用域和质量管理”是核心难题，YC的解决方案“令人振奋”。 - 评论9称赞“LLM时代新UI原语和概念的创新”，但批评描述不清，并提到Orca工具缺乏Postgres会话数据库。

4. 对开源贡献模式的讨论（评论10） - 评论10认为要求“人工撰写文本”的贡献方式“更接近功能请求”，而非传统开源协作。

平衡总结： 评论呈现两极分化——部分用户讽刺AI项目要求人工撰写的矛盾性，质疑工具实用性；另一部分则认可多代理协作方向，但批评描述不清。整体认可度中等，缺乏高分评论。