面向协作场景的智能代理工具，支持Slack与网页端

多数智能代理被设计为个人助手模式，若要适配企业级协作，很快会陷入复杂度泥潭。QM则专为初创企业打造：每位员工拥有独立隔离的工作空间，可自主操作且互不干扰，同时也能通过频道、群聊和项目与代理协作。

每个用户、每个协作房间都拥有独立作用域的记忆库、文件、密钥链视图、权限、定时任务、网页应用及持久化沙箱。

QM从设计之初就拥抱开源生态：你可以自由选择代理框架与大模型，Pi、OpenCode、Codex、Claude Code均可对接核心功能，部署不受单一供应商绑定。

• 个人与共享双作用域：用户可将代理定制为专属工具，同时也能在Slack频道和项目中开展协作

• Slack与网页端互通：同一身份与配置在Slack和网页应用间无缝同步

• 管理员管控：可设置组织级配置、安全策略，以及可用的代理框架与模型

• 网页应用搭建：快速创建自定义内部应用，并定向发布给目标用户

• 技能共享机制：技能归属于特定作用域，可通过授权共享；管理员可将其推广至全组织，也可从Git仓库导入技能包

• 后台任务处理：定时任务与监控服务可在无人值守状态下自动运行

• 一站式搜索内部笔记、邮件、文档、数据库与网页内容

• 从企业知识库中精准调取信息

• 搭建内部应用、定向发布并保持数据实时更新

• 学习你的写作风格，按计划整理收件箱——自动添加标签并生成回复草稿

• 在现有代码仓库中协作：运行测试、发起PR、监控CI流程、查看系统日志

• 在共享频道跟踪项目进度，自动发布更新与跟进提醒

flowchart LR
DB[("Postgres<br/>sessions · memory · queue")]
subgraph CORE["Headless core"]
API["API · identity · policy · scheduler"]
LOOP["Agent loop<br/>(Pi, OpenCode, Claude Code)"]
API <--> LOOP
end
SBX["Per-scope sandbox<br/>files · tools · logged-in services"]
DB <--> API
LOOP <--> SBX

每一轮交互都通过中央核心处理，核心可调用多种模型与框架生成响应。Postgres持久化层存储用户数据、会话历史及其他持久化状态。代理拥有一套精简固定的工具集，其中execute工具可在对应作用域的隔离沙箱中运行命令——这个持久化计算环境会保留已安装的工具。网页界面、管理面板与公共门户均为核心HTTP API之上的可选插件；Slack则是一个可选进程内插件，由核心启动并通过直接服务客户端进行管理。

核心基于Node.js直接运行TypeScript，采用Fastify处理HTTP请求；Slack插件使用Bolt框架；网页界面基于Vite构建，通过Lit渲染。

核心本身具备通用性，所有企业专属内容——组织配置、自定义工具与技能、沙箱镜像、基础设施——均存储在部署目录中，由qm命令行工具验证并部署。所有底层组件（代理框架、会话存储、沙箱、记忆库）均通过接口实现解耦，生产环境只需修改一个配置文件即可完成替换。

QM遵循OpenCode、Codex、Claude Code等本地编码代理的设计思路：代理以用户身份开展操作，使用用户的凭据与权限，所有行为均可审计。组织可选择全局安全策略，细分作用域仅能进一步收紧策略，无法放宽：

• 严格模式：除两种无副作用的交互结束指令外，代理的所有工具调用都需人工审批
• 自动模式（默认）：分类器会对带有来源标记的外部数据与工具结果进行筛查，再传递给模型；部署时可对接自定义筛查代理
• 危险模式：无内容筛查，工具调用间无停顿

预定义的命令策略——包括审批规则，以及对递归删除、破坏性SQL等操作的硬性禁止——在所有模式下均生效，危险模式也不例外。

SECURITY.md文档包含威胁模型、运维假设与已知限制说明。

创建一个组织所有的部署仓库，依赖@yc-software/qm包：

npm exec --yes --package=@yc-software/qm@latest -- \
qm init . --org <slug> --target <fly-or-aws>
npm install

初始化流程会生成一个代理部署技能，并引导完成基础设施配置、网页登录、连接器凭据设置、可选Slack接入、部署及在线验证——无需检出源代码。每个部署实例运行在运维方自有云账户中；初始化不会生成或启用部署CI流程，本仓库也无生产部署工作流。详情请见deployment.md。

我们仅接受人工撰写的文本类贡献，不直接接收代码——详见CONTRIBUTING.md。请在目录下的.txt或.md文件中，以非正式方式描述你希望的改动，若双方达成共识，我们将负责实现。漏洞请私下报告——详见adrs/，请勿提交公开议题。

上述部署仓库仅包含配置与沙箱层，无需检出源代码。部分组织偏好另一种模式：将整个代码库集中管理，方便工程师与编码代理查看核心代码与自定义内容，同时保持自定义内容私有。对此，可创建私有克隆仓库：一个独立的私有仓库，初始状态为qm的克隆版本，核心代码与上游保持一致。

按以下步骤创建并使用：

gh repo create <org>/qm-private --private
git clone --bare git@github.com:yc-software/qm qm-seed.git
git -C qm-seed.git push --mirror git@github.com:<org>/qm-private
rm -rf qm-seed.git
git clone git@github.com:<org>/qm-private
git -C qm-private remote add upstream git@github.com:yc-software/qm

请按上述方式通过普通克隆创建私有仓库，不要使用GitHub的Fork功能。此处的"fork"仅指概念——即一个主动偏离上游、并可从上游合并更新的下游副本——而非GitHub的Fork按钮。GitHub Fork会继承原仓库的可见性，因此公共仓库无法Fork为私有仓库；此外，GitHub Fork与原仓库共享对象网络，推送到Fork的提交仍可通过SHA值从公共端获取。许多组织也禁止Fork私有仓库。普通克隆则无上述问题，仅需注意：克隆后的仓库为普通仓库，上游的CI工作流会在你的账户中运行，需提供所需密钥或禁用不需要的工作流。

所有组织专属内容请放入deploy/layers/<org>/目录——包括配置、沙箱工具与技能、插件镜像、基础设施——目录结构与qm init生成的一致。详情请见deploy/layers/README.md。核心代码需与上游完全一致，以确保合并操作的轻量化。

两种技能负责维护双向边界：update-qm将上游qm代码合并到私有仓库并创建同步PR；upstream-pr将与组织无关的修复提交给qm，从upstream/main分支创建分支，并在推送前检查输出差异、提交信息与截图，确保不含组织标识。deploy/layers/目录下的内容绝不会被推送到上游。

• docs/getting-started.md
• cli/README.md——qm命令行工具与部署目录约定说明
• docs/deploy-directory.md
• .env.example
• plugins/

除非另有说明，QM采用MIT许可证开源。