QM 深度解析：如何构建面向组织的多人 Agent 工作系统

很多企业第一次引入 AI，都是从“给每个员工一个助手”开始：有人用它写邮件，有人用它查资料，有人把它接进代码仓库，还有人在 Slack 群里放一个机器人。单点效果通常不差，但当使用范围从几个人扩展到整个团队，问题很快就从“模型够不够聪明”变成了“系统能不能管得住”。

谁能看到谁的记忆？频道里的 Agent 应该使用个人上下文，还是团队上下文？员工授权的邮箱和 GitHub 凭据会不会被其他人调用？一个后台任务由谁发起、以谁的身份执行、结果又应该发给谁？如果换掉模型或 Agent 框架，已经沉淀的会话、文件和工作流还能不能继续使用？

这些问题不是再写一层 Prompt 就能解决的。它们要求一套真正的组织级运行底座。

QM 给出的答案很有代表性：它把自己定义为一个 “multiplayer agent harness for work”——面向工作的多人 Agent Harness。它不是单一聊天机器人，也不是某个模型的外壳，而是一套让员工、频道和项目在同一个 Core 上安全协作，同时保持各自数据、权限和执行环境相互隔离的系统。

本文不只介绍 QM 有哪些功能，而是从架构角度回答四个问题：多人 Agent 为什么需要新的系统抽象？QM 如何组织身份、状态、权限和执行？与聊天机器人、自动化工具及通用 Agent 框架相比，QM 的差异化在哪里？这套设计距离真正成熟的企业级 Agent 平台还有哪些边界？

从个人助手到组织系统，难点不是并发而是边界

“多人 Agent”很容易被误解成多人同时和一个机器人聊天。真正困难的部分并不是同时处理多少请求，而是每一次请求属于谁、可以使用什么、产生的结果归到哪里。

假设一家跨境公司在同一个平台上运行以下任务：

• 运营人员用 Agent 分析广告数据，并登录自己的广告后台；
• 研发人员让 Agent 修改代码、运行测试、提交 Pull Request；
• 客服团队在共享频道里维护售后话术；
• 管理层通过后台任务生成每周经营简报；
• 一个项目组共同维护新品上市资料和行动项。

如果所有任务共享同一份记忆、文件系统和凭据，系统当然最容易实现，但也是最危险的。只按“用户”隔离也不够，因为频道和项目又确实需要共享上下文。QM 因此把 Scope 放在了架构中心。

Scope 可以是个人、房间、Slack 频道、群组或项目。每个人和每个协作空间，都可以拥有独立的：

• 会话与长期记忆；
• 文件和工作目录；
• Keychain 视图与凭据授权；
• Skills 与工具配置；
• 权限和 Audience；
• Cron、Watch 与后台任务；
• Web Apps；
• 可长期保留状态的沙箱计算机。

这让 QM 同时支持两种看似冲突的模式：每个员工都可以把 Agent 训练成“自己的助手”，团队又可以在频道和项目里使用共享 Agent。共享不是把个人空间混在一起，而是进入另一个有独立所有权和授权关系的 Scope。

从代码模型看，QM 当前定义了五类 Scope：personal、channel、team、org 和 group，内部标识采用类似 personal:alice@example.com、channel:C123 的形式。Scope 不是一个展示标签，而是贯穿 Session、Memory、Workspace、Grant、Cron 和 Sandbox 的主键。只要一份资产以后需要判断归属，它就不能只记录“文件名”或“创建人”，还要记录自己的 Home Scope。

与 Scope 配套的是 Principal。Principal 表示正在行动的人，当前区分组织内部用户和 Guest，也可以携带 Team 归属。一次请求进入系统后，Core 需要同时回答三个不同问题：

1. 谁在行动：Principal 是谁，是否仍是有效内部成员；
2. 在哪里行动：本次 Session 属于哪个 Scope；
3. 结果给谁看：当前 Conversation 的 Audience 是谁，目标投递位置是什么。

这三个维度不能合并。一个人在公开频道里发起请求，不代表频道里的所有成员都能使用他的个人凭据；一个人有权读取项目文件，也不代表 Agent 可以把文件内容投递给另一个 Audience。

QM 的 Grant 也因此不是简单的“用户—角色”关系。一条 Grant 至少包含资源所有者 Scope、资源引用、被授权 Scope、read/write 权限和授权人。Core 可以据此把其他 Scope 的资产以 Granted Handle 暴露到当前工作区，并决定挂载为只读还是可写。授权发生在资产层，而不是把整个个人工作区一股脑共享出去。

读和写的判断也有意分开。个人 Scope 原则上只属于本人；组织 Scope 面向内部成员；Team 依赖团队成员关系；频道和群组则结合当前成员关系与空间是否私有来判断。这样，一个用户退出频道或被停用后，系统可以重新计算其当前写权限，而不是永远沿用历史会话里的身份快照。

这是 QM 最值得关注的设计：多人协作的基础不是共享一切，而是先建立边界，再通过授权实现共享。

QM 的五层架构

从整体上看，QM 可以拆成五层：Surface、Core、Harness、Sandbox 和 Postgres。

Slack / Web / Portal / Admin
              │
              ▼
     Headless Core
身份 · Scope · ACL · 策略 · 调度 · 审计
       │                  │
       ▼                  ▼
Harness / Model      Postgres
       │        会话 · 记忆 · 队列 · 配置
       ▼
固定工具接口，例如 execute
       │
       ▼
每个 Scope 的持久沙箱
文件 · CLI · 仓库 · 登录状态 · 执行环境

Surface：入口只是入口，不拥有最终权限

QM 可以通过 Web UI、Admin、Portal 和 Slack 交互。Web UI 使用 Vite 构建，以 Lit 渲染；Slack 插件基于 Bolt；Core 则是直接运行在 Node.js 上的 TypeScript 服务，HTTP 层使用 Fastify。

这些 Surface 负责接住用户，但不会各自实现一套独立的 Agent 和权限系统。经过认证的身份、请求来源和上下文会进入统一 Core，由 Core 决定本次 Turn 对应哪个 Principal、哪个 Scope，以及后续能读取和执行什么。

这种设计避免了常见的问题：Slack 机器人是一套权限，Web 又是另一套权限，后台任务再绕开前两者直接操作数据。QM 希望不同入口最终都汇合到同一条可信控制路径上。

Surface 到 Core 的边界不仅是一个普通 HTTP 请求。对于受信调用，QM 使用签名入口或 Capability Token 携带受约束的 Claims，例如 Principal、Scope、成员列表、Keychain 成员、允许的 Memory 读写范围、目标 Destination 和出口策略。Core 验证 Token 后再建立本次 Turn 的运行上下文，而不是接受前端传来的任意 userId 或 scopeId。

Portal 在生产部署里还是唯一的公开坐标。Web UI 和 Admin 可以位于私有服务地址，由 Portal 统一完成身份会话和反向代理。这样浏览器不需要直接访问 Core 控制面，Core、Admin 和 Web 也不必各自暴露一套公网认证边界。

Slack 则多了一层 Conversation 语义：DM、频道和多人群组会映射为不同 Session/Scope，消息 Audience、频道隐私属性和当前成员关系都会参与解析。Surface 证明“消息从哪里来”，Core 才决定“这条消息能做什么”。

Core：真正的可信控制平面

Core 是 QM 的中心。它负责身份解析、Scope 解析、ACL、Session、模型选择、工具调用、凭据授予、消息投递、后台调度、预算、速率限制和审计。

这里有一个重要的安全假设：Agent 和沙箱不可信，Core 才负责授权。

模型可能受到 Prompt Injection，沙箱里运行的是模型生成的命令，第三方工具返回的内容也可能带有恶意指令。因此，QM 不允许 Agent 自己判断“我是否可以读取这份文件”“我能否把结果发到另一个频道”。这些判断应该由拥有确定身份和策略的 Core 完成。

更具体地说，Core 会为每个 Turn 生成一份 Resolution。这份解析结果不是一条简单的 Role，而是把本轮真正可用的能力组装出来，包括：

• Workspace Layers：哪些 Scope 的目录被挂载，挂载路径是什么，是只读还是可写；
• System Prompt：组织、Scope、Soul、Skills 和运行上下文组合后的指令；
• Egress Policy：允许或拒绝访问哪些主机；
• Command Policy：哪些命令拒绝、哪些需要批准；
• Security Policy：本轮是 Strict、Auto 还是 Dangerous；
• Granted Handles：通过 Grant 暴露进来的文件或资源；
• Approval Modes：批准是仅一次、当前 Session 有效，还是长期有效。

这种 Resolution 模型的意义在于：Harness 不需要自己到处查询权限。它拿到的是 Core 已解析过的工作集；当它尝试产生副作用时，Core 和执行层还会再次应用确定性门禁。权限既体现在模型“看见什么”，也体现在工具最终“能做什么”。

Core 内部还把身份、目录、凭据、记忆、Session、Run、审计、Delivery 等能力拆成接口，通过统一 Wiring 选择 Postgres、本地实现或具体 Sandbox Backend。这样生产实现可以替换，而不会让 Surface 或 Harness 直接依赖某张数据库表。

Harness：把 Agent Runtime 和模型解耦

QM 支持 Pi、OpenCode、Codex 和 Claude Code。这里的 Harness 不只是模型 API 客户端，而是负责上下文组织、模型调用、工具循环和会话推进的 Agent Runtime。

模型回答“下一步做什么”，Harness 负责让这一轮真正跑起来。把 Harness 抽象出来后，同一个 QM 部署可以更换模型或 Agent Runtime，而不需要一起替换用户身份、会话、文件、记忆、权限、Skills 和后台任务。

这比“支持多个模型 API”更进一步。QM 试图把模型和 Harness 都变成可替换基座，而把组织真正需要长期保留的资产——上下文、工作过程、权限和执行环境——留在 Core 与持久层中。

不同 Harness 的工具调用协议、上下文格式、审批能力和模型认证方式并不相同。QM 为每个 Harness 写 Adapter，把它们收敛到同一组 Turn 输入、工具结果、安全筛查结论和最终回复结构上。换句话说，QM 没有假设“所有模型都兼容 OpenAI API”，而是承认 Harness 本身就是有行为差异的运行时。

组织管理员可以设置默认 Harness、模型以及允许使用的 Harness 集合，较窄 Scope 再选择自己的 Runtime。这样既可以让工程团队使用 Codex 或 Claude Code，也可以让成本敏感的后台任务选择 Pi 或其他模型；但 Scope 不能绕过组织批准列表私自启用一个未经审核的执行器。

真正可移植的不是 Prompt，而是 Harness 之外的协议：Session Entry、Tool Call、Approval、Run、Capability、Workspace 和 Audit。只要新的 Harness 能实现这套边界，就可以加入同一个组织系统。

Sandbox：每个 Scope 都有一台 Agent Computer

QM 不让模型在 Core 进程里随意执行 Shell。Core 给 Agent 的工具面保持较小且固定，其中最关键的工具是 execute。当模型需要运行命令时，execute 会把工作交给当前 Scope 的隔离沙箱。

这个沙箱不是一次性函数，而更像一台长期存在的 Agent Computer。它可以保留：

• Git 仓库和工作文件；
• 已安装的 CLI 与依赖；
• 构建缓存；
• 工具配置和登录状态；
• 长任务的中间产物；
• Scope 自己的文件系统状态。

这解决了普通聊天机器人很难解决的问题。一个真正参与工程、运营或数据工作的 Agent，需要的不是每轮重新创建的空白容器，而是一个有连续工作状态的环境。

QM 的本地开发模式使用 Docker 沙箱；生产环境可以使用 Fly Machines 或 AWS Lambda MicroVM 等后端。不同后端通过接口接入 Core，业务层不需要关心底层到底是一台容器、远程机器还是 MicroVM。

沙箱生命周期又分为两种典型模式。长期 Scope 沙箱会保留 Volume，任务结束后可以停机，下一次重新启动继续读取原来的仓库、依赖和文件；Scratch Sandbox 则用于确实不需要保留的临时工作，结束后连容器和存储一起销毁。这个区别可以同时兼顾连续工作和资源成本。

凭据进入沙箱时也不是简单复制整份用户主目录。工具描述符可以声明需要捕获的 $HOME 相对路径、文件还是目录、如何检查登录状态以及如何重新认证。Core 根据当前 Principal、Scope、Grant 和用途生成 Credential Injection，再把必要的环境变量或文件送入沙箱。对于设备授权流程，还要处理登录状态的持久化和切换。

沙箱启动时还会拿到短期 Capability，使其中的 Agent 可以调用 Core 的受限 Self API，例如读取允许的 Memory、汇报 Run Signal 或发送被授权的消息。Capability 会绑定 Scope、成员、Destination 和可用能力；它不是 Core 管理员 Token。

需要注意，网络出口策略目前具有后端依赖。描述符可以声明允许或拒绝的 Host，Core 也能做策略决策，但真正的 Force-through Egress 仍取决于 Sandbox Backend 是否具备足够精细的网络强制能力。配置存在不等于所有后端都已经实现同等级隔离。

Postgres：凡是以后还要读取的状态，都不只放在内存里

QM 面向蓝绿发布和多实例运行，因此关键状态不能存在某个 Node 进程的 Map 中。会话、记忆、Run、队列、审计、授权、Cron、部署层和配置等状态会进入 Postgres。

这个选择看似普通，实际上决定了 QM 是聊天 Demo 还是长期运行平台。Agent 一旦承担后台任务，就必须在服务重启、实例切换和 Worker 接管后继续知道：任务执行到哪里、使用了谁的权限、已经产生了哪些副作用、最后应该把结果送给谁。

Session 本身不只是按时间追加的聊天文本。Entry 会记录序号、父 Entry、类型、Scope Label 和 Payload，类型包括用户消息、Assistant 文本、Thinking、Tool Call、Tool Result、Delivery、Approval Request 与 Approval Result。这样前端可以重建完整时间线，系统也可以区分“模型说了什么”和“工具实际做了什么”。

QM 还为 Session 引入 Lease，分别保护 Turn、Compaction、Fork 和 Backfill 等会修改 Session 的工作。Run Worker 领取任务时同样获得带过期时间的 Lease Token，并通过 Heartbeat 续约；只有持有正确 Lease 的 Worker 才能 Complete 或 Fail。Worker 崩溃后，Reaper 可以识别过期 Lease，释放被卡住的 Session，并根据最大尝试次数决定重排队还是退休任务。

Postgres 表通过共享连接池和幂等 DDL 延迟创建。这个细节降低了不同部署组合的初始化成本：没有启用的模块不必预先执行一整套迁移，同时多个实例并发启动也不会因为重复建表产生不同状态。代价是数据库权限、DDL 锁和启动时错误处理必须设计得更谨慎。

Session、Memory 与 Workspace 是三种不同状态

很多 Agent 产品把所有长期状态都叫“记忆”，实际会让权限和生命周期变得模糊。QM 将至少三类状态分开处理。

Session 保存一次对话或后台运行的时间线。它关心消息顺序、参与者、工具调用、审批、Fork、Compaction 和当前是否正在工作。Session 可以被归档或固定，但不应该自动变成 Agent 的长期事实。

Memory 保存 Agent 以后需要主动回忆的结构化信息，例如用户偏好、项目约定和长期经验。Capability 中可以分别声明 Memory 的 Read Scope、Write Scope 和 Org Write Scope，所以“可以读组织记忆”并不自动等于“可以修改组织记忆”。

Workspace 保存文件与可执行环境。代码仓库、生成的报告、安装的依赖和 CLI 登录状态属于 Workspace，而不是塞进模型上下文。Resolution 可以把多个 Scope 的 Workspace Layer 挂到同一沙箱：当前 Scope 可写，获得 Grant 的其他目录只读，从而形成一个带权限的工作集。

三者最终都会影响模型，但进入方式不同：Session 通过窗口和 Compaction 进入上下文，Memory 通过检索或明确读取进入上下文，Workspace 则通常由工具按需读取。把它们分开后，系统才能分别定义保留期、读写权限、成本和删除语义，也避免每轮都把整个工作历史重新发送给模型。

一次 Agent 请求是怎样运行的

以员工从 Web 发起一个“检查仓库测试并创建 PR”的请求为例，完整路径大致如下：

1. Portal 或 Web 完成用户身份认证；
2. Core 解析发起者 Principal 和目标 Scope；
3. 加载该 Scope 的会话、记忆、Skills、文件和授权；
4. 根据组织配置选择 Harness 与模型；
5. 对有来源标签的外部输入执行安全筛查；
6. Harness 驱动模型进入工具循环；
7. 模型调用 execute，命令进入该 Scope 的沙箱；
8. 如需 GitHub 等凭据，Core 检查所有者、Audience、有效期和授权模式；
9. 命令策略决定拒绝、要求人工批准或继续执行；
10. 工具结果返回模型，模型生成下一步或最终回复；
11. Core 将结果送回原 Web 会话，或投递到被授权的频道；
12. Session、Run、模型请求、审计和相关状态写入持久层。

这条路径最重要的不是模型生成了什么，而是每一步都有明确的身份、Scope 和归属。后台 Cron 或 Watch 虽然没有用户盯着屏幕，本质上也应该遵循同样的控制逻辑。

把这十二步再拆开，会看到三次不同性质的检查。

第一次是 上下文检查：哪些 Memory、文件、Skill 和历史 Entry 可以进入模型窗口。这里解决“模型可以知道什么”。

第二次是 副作用检查：模型提出命令或控制面操作后，命令策略、安全姿态、Credential Grant 和 Capability Claims 再决定是否允许。这里解决“模型可以做什么”。

第三次是 投递检查：即便任务已经成功，结果也不能自动发送到任意频道。Destination、Audience、Recipient Consent 和 Scope Reach 共同决定内容可以送到哪里。这里解决“结果可以给谁”。

这种分层很重要。只在 Prompt 中告诉模型“不要泄露数据”，无法替代 Context Filter；只隔离文件读取，也无法阻止 Agent 把已经看到的敏感内容发错频道；只保护消息投递，又无法阻止危险命令在沙箱里先造成副作用。

Session Tape 还会保留模型请求和 Transport Metadata，用于审计成本、延迟、模型实际收到的上下文以及失败发生在哪个阶段。对调试 Agent 来说，“最终回答错了”远远不够，Operator 必须能区分问题出在上下文组装、模型判断、工具执行、网络传输还是投递。

后台工作让 Agent 从“回答问题”变成“持续工作”

QM 内置 Cron、Watch、Run Queue、Wake 和 Delivery 等能力。Agent 因而可以在用户离开后继续工作，例如：

• 定时检查邮箱并生成回复草稿；
• 监控 CI、系统日志或业务指标；
• 定期生成项目进度与经营简报；
• 监听数据变化，触发后续任务；
• 更新内部 Web App 的数据；
• 在任务完成或异常时回到 Slack 通知团队。

这也是为什么 QM 必须把身份、状态和投递统一起来。定时任务如果只是一段 Cron Shell，很难回答它代表谁、可以用什么凭据、是否还拥有权限、结果该送给谁。QM 试图把这些问题放回同一个组织级 Agent 模型中。

一个 Cron 记录的不只是表达式和 Prompt，还包括 Owner、Owner Scope、Created By、运行身份、成员列表、Destination、是否启用、最近触发时间以及接收者是否同意。周期性向他人发送内容时，Recipient Consent 是单独字段，避免一个用户创建任务后无限期骚扰另一个收件人。

调度可靠性由几层机制共同承担：

• Scheduler 使用 Leader Lease，避免多个 Core 实例同时扫描并触发同一批任务；
• 每个计划时间槽通过 claimSlot 抢占，已经被其他 Worker 领取的槽不会再次执行；
• Fire Key 和 Idempotency Store 抑制重复触发；
• Run Queue 使用 Lease 与 Heartbeat，Worker 崩溃后任务可以恢复；
• Delivery Store 用 Idempotency Key 入队，Sender 领取后 Ack，重复提交返回同一条投递记录；
• 一次性 Cron 执行后自动关闭，持续 Cron 则计算并入队下一个 Slot；
• 如果队列后端启动失败，Scheduler 还可以退回间隔 Tick 路径，而不是整个后台系统静默失效。

投递也和任务执行解耦。Agent Turn 完成并不等于 Slack 消息已经发出，Run 可以记录自己的 Delivery State。这样发送端短暂失败时不必重跑整个模型任务，也能避免模型再次调用外部系统造成重复副作用。

Skills、Tools 和部署层：把企业能力做成可治理资产

QM 的 Skills 不是所有人共享的一堆 Prompt 文件。Skill 有所有者，可以归个人或 Scope 所有，通过 Grant 分享，并由管理员提升为组织级能力。Skill Pack 还可以从 Git 仓库导入。

部署目录中的工具描述符可以声明：

• 工具在模型侧如何展示；
• 二进制如何安装和检查；
• 登录状态如何捕获和恢复；
• 哪些凭据文件可以进入沙箱；
• 需要哪些网络出口；
• 哪些命令必须批准或直接拒绝。

这些描述符和 Skill 文本组成部署层。Core 会再次验证部署层，将其以内容哈希版本化并持久化，而不是只依赖某台服务器上的文件目录。

这意味着企业能力可以像代码一样管理：有来源、有版本、有归属、有审批，也可以在不同运行底座之间保持一致。

Skill 导入时会解析 Front Matter、标准化名称和路径、识别目标 Scope，并计算完整文件 Bundle 的哈希。Skill 不只可以有一个 SKILL.md，还可以包含引用文本和模板等资产；但当前部署层 API 主要承载文本，真正的二进制必须进入 Sandbox Image。

组织级 Skill 不是普通用户把 Scope 字段写成 org 就能发布。系统会检查目标 Scope 是否具备组织提升资格，并要求 Admin Gate。删除部署层拥有的 Skill 时，Core 将其归档，而不是无痕消失，这为回滚与审计保留了恢复路径。

Tool Descriptor 中几个字段尤其关键：

• advertise 决定工具是否出现在 Agent Computer 的可用 CLI 清单；
• hints 给模型补充组织自己的使用约束；
• auth.check/reauth 定义登录检查与重新认证；
• auth.credentialPaths 声明允许捕获的凭据路径，并拒绝绝对路径和目录穿越；
• auth.splitEnv 可以在可信 Surface 绑定的情况下传入 Acting User；
• approvals 只能增加拒绝或审批规则，不能削弱组织底线；
• install.binary 在镜像构建阶段验证二进制确实存在于 PATH。

部署时，CLI 会先验证描述符，然后 Core 在接收部署层时再次验证。通过后，完整 Bundle 以规范化 SHA-256 哈希作为版本存入 Postgres，并记录审计事件。也就是说，“构建机器上有这个文件”不是部署成功的充分条件，Runtime 还要能够证明自己加载的是哪一版能力集合。

发布 Web App：把 Agent 产物变成受限能力

QM 允许 Scope Owner 发布内部 Web App。它的目标不是把 Core 管理后台暴露给外部用户，而是把一个明确业务能力包装成独立入口，例如项目看板、数据查询页、审批表单或持续更新的报告。

发布时，系统需要计算 Audience：可以只给 Owner、给当前成员，或在组织策略允许时给整个 Org。App Runtime 不会自动继承作者沙箱中的所有个人凭据；需要的环境变量和 Acting-as 权限必须按 App 明确配置。这样一个员工发布的页面不会天然变成通往其个人 Keychain 的后门。

对组织外访问，QM 可以生成 Capability Link。持有链接的人只获得访问该 App 的能力，不会因此成为 QM Principal，也不能进入 Agent 或控制平面。Gateway 会在首次访问后把 Token 从地址栏移除，转入有时限的浏览器 Cookie，减少链接出现在截图和浏览历史中的概率。

但 Capability Link 仍然是 Bearer Authorization：谁拿到，谁就能用，而且不绑定原始接收者。单独修改 App ACL 也不一定立刻撤销已经分发出去的每个链接。因此适合用它发布低风险、边界清晰的应用，不适合把高敏控制面换个页面后直接公开。

三种安全姿态，以及始终存在的确定性底线

QM 提供三种组织级安全姿态。

Strict 模式下，除无副作用的结束操作外，Harness 工具调用都暂停等待人工批准。

Auto 是默认模式。系统会对带来源标签的外部内容和工具结果进行分类，发现疑似 Prompt Injection 时提升到更严格的处理方式。企业也可以配置自己的安全筛查代理，并采用 Shadow 或 Enforce 方式逐步上线。

Dangerous 不进行内容筛查，也不在普通工具调用之间暂停，适合明确接受风险的实验环境。

但 Dangerous 并不意味着什么都能做。预声明的命令策略、工具自己的 Deny 规则，以及递归删除、破坏性 SQL 等硬限制，在三种模式下都应继续生效。也就是说，启发式内容筛查可以改变，确定性安全底线不能被低级 Scope 放宽。

安全姿态采用“组织地板”组合方式：Org Scope 设定最低强度，个人、频道或项目 Scope 可以进一步收紧，但不能降低。例如组织设置 Auto，某个财务项目可以改成 Strict；组织已经设置 Strict，个人就不能把自己的 Scope 调成 Dangerous。

Strict 的审批不是只有“允许/拒绝”。审批 Grant 可以只放行本次调用、当前 Session，或长期允许同类动作。长期授权仍然要进入可审计状态，而不能只是 Harness 记住一句“用户以前同意过”。对于直接修改控制面的 Capability HTTP 请求，Strict 通常直接阻断，而不是让 Agent 通过连续申请逐步改变自己的权限环境。

Auto 的筛查则区分 User Input 和 Tool Response，并依赖 Provenance Label 判断哪些内容来自不可信外部来源。内置实现可以使用模型分类器；部署也可以接入自己的 HTTPS Security Screen。长文本会先限制总体大小，再切分为带重叠的约 1,600 字符 Chunk，每次分类最多并行两个请求。只要任意 Chunk 达到自己的风险阈值，整份输入就升级为 Strict 处理。

外部筛查代理支持 Shadow 和 Enforce。Shadow 会把内容发送给代理并记录对比结果，但仍以内置分类器为权威；Enforce 才真正使用代理结论。这里有一个容易忽略的治理事实：Shadow 虽然不改变决策，却已经把完整待筛查内容披露给外部服务，因此上线 Shadow 前同样要完成供应商与数据合规审查。

QM 还刻意不向 Agent Self API 开放三类操作：

• 修改管理员 Grant；
• 冒充其他 Principal；
• 批准被拦截的命令。

这三类操作都会授权未来的 Agent 行为。如果 Agent 能自己调用，人工权限门就会退化成同一个模型的单次决定。QM 因此要求这些操作只能由人在 Portal 中，以自己的身份完成。

另一个有价值的细节是，QM 把 Content Screening、Command Approval 和 Authorization 看成三类不同控制。分类器说“内容看起来安全”，不代表用户有权读取资源；用户有权读取资源，也不代表模型可以执行 rm 或修改生产数据库；人批准了一条命令，也不代表命令产生的所有后果都安全。三者不能互相替代。

安全设计值得肯定，但不能把它误读成安全认证

QM 的安全文档非常坦诚：它是早期实验性软件，面向单一组织内的已认证用户，不是一个已经硬化的公共多租户边界。

目前需要特别关注的限制包括：

• Shell 命令策略可以被混淆、编码或间接脚本绕过；
• 凭据在沙箱进程实际使用期间会以明文形式存在；
• 内容分类只能降低 Prompt Injection 风险，不能保证完全阻断；
• 浏览器内部动作没有全部重新经过 Core 命令策略与人工审批；
• Admin 是特权内容读取者，读取会审计，但不要求用户二次同意；
• 会话、模型请求捕获、记忆和文件可能长期保留；
• 发布 App 使用的 Capability Link 属于 Bearer Authorization，链接泄露就意味着对应访问能力泄露；
• 部分 Audience Floor、出口控制、治理回滚和组织级 Kill Switch 仍不完整。

因此，QM 更适合作为一套值得研究和试点的开放架构，而不是拿来即用的安全承诺。企业若要接入高敏数据、生产凭据或不可逆业务动作，仍需要自己的威胁建模、云账户隔离、网络策略、密钥管理和上线审查。

这些限制可以进一步转化为具体的上线要求：

还要注意模型与浏览器供应商本身也是信任边界。模型供应商会收到 Prompt 和请求数据；浏览器供应商会收到浏览任务和流量。即使 QM 自己部署在私有云，也不自动等于所有推理与浏览数据都留在私有环境中。

部署目录：把“怎么运行”也做成版本化契约

QM 的另一个特色，是把组织配置放进独立的 Deployment Directory，而不是长期维护一份魔改 Core。

一个典型目录包含：

qm.config.jsonc
package.json
package-lock.json
.env
sandbox/
  Dockerfile
  tools/
  skills/
plugins/
infra/

qm.config.jsonc 只保存非敏感配置，Secret 进入被 Git 忽略的 .env，或由云端 Secrets Manager 管理。package.json 固定解释这份目录的 QM CLI 版本，避免同一份配置在不同时间被不同 CLI 解释。

目录顶部的 contract: 1 只表示兼容性主版本，真正解释配置的是 package.json 中精确锁定的 @yc-software/qm 版本。这样一份部署仓库本身就记录了“由哪一版部署引擎生成和验证”，升级必须显式修改依赖 Pin，而不是某天执行 npm exec 后悄悄改变渲染结果。

publicUrl 是部署的唯一公共坐标。Core、Slack、Web、Admin 和 Portal 的内部 URL 由 CLI 推导，避免 Operator 手工维护一组互相矛盾的公网地址。配置中的普通 env 只允许非敏感值，Secret-like Key 会被拒绝；启用的服务、插件和功能谓词共同计算实际 Secret 集合，再决定每个 Secret 应该进入哪个容器。

Sandbox 交付由两个 Pin 组成：不可变的 Substrate Image Digest，以及文本部署层的 Content Hash。前者决定操作系统、二进制和 Agent Runtime，后者决定 Skills、Tool Descriptor 和文本资产。up 与 check --live 可以据此判断线上运行的到底是不是仓库声明的完整版本，而不是只检查某个可变的 latest Tag。

CLI 提供一条完整的部署门禁顺序：

check → doctor → sandbox/image build → plan → up → check --live

其中 check 做离线静态验证，doctor 只读检查外部资源，plan 渲染部署计划，up 执行变更，check --live 检查线上环境、Secret 路由、任务定义和镜像 Pin 是否发生漂移。

这几道门处理的是不同错误：

• check 发现 Schema、Secret 名称、工具描述符、Skill 内容和 Plugin 配置错误，不需要网络；
• doctor 检查 Docker、Fly/AWS 凭据、目标资源和外部依赖，但不修改它们；
• sandbox build/publish 验证工具能否真正装进镜像，并把可变引用解析为不可变 Digest；
• plan 让 Operator 在变更前看到将创建或更新哪些工作负载；
• up 在 Provider Lease 内执行变更并等待稳定；
• check --live 从线上反向读取环境、Secret 路由、任务定义和 Pin，检查声明与现实的双向差异。

QM 支持本地 Docker、Fly.io 和 AWS。AWS 路径使用 ECS/Fargate、RDS、CloudFront/ALB、Cloud Map 与 Lambda MicroVM，并通过部署 Manifest 记录不可变镜像摘要。代码与配置回滚不会假装数据也自动回滚；部署前的 RDS Snapshot 会被记录，数据恢复仍由 Operator 明确执行。

三种 Target 的职责边界也不同。本地 Docker 适合验证完整目录契约和服务组合；Fly 使用 Fly Apps/Machines 承载长期服务和 Agent Computer；AWS 使用 Digest-pinned ARM64 Fargate Task 运行服务，RDS 保存状态，Cloud Map 提供私网服务发现，CloudFront/ALB 暴露 Portal，Agent Computer 则由 Lambda MicroVM 或显式配置的 Sprites Backend 提供。

AWS 的 up 会在首次修改前获取部署 Lease，并可按配置创建 RDS 手工 Snapshot。Rollback 恢复的是上一份完整 Deployment Manifest，也就是代码、环境、Secret 路由和 Sandbox Pin 的组合；它不会自动对数据库做时间旅行。CLI 会把匹配的 Snapshot 告诉 Operator，由人决定是否执行数据恢复。这种“不假装自动”的语义比一个含糊的 rollback succeeded 更可靠。

这种做法把“部署”从一组散落脚本变成了一个可验证契约。对 Agent 平台尤其重要，因为 Core、Surface、沙箱镜像、Skills、工具和 Secret 路由必须作为一个整体保持一致。

本地运行验证：它不是只有一张架构图

为了理解 QM 的真实形态，我在 Apple Silicon Mac 上运行了一套 production-shaped 本地实例，包括：

• Core API 与 Worker；
• Web UI；
• Admin；
• Portal；
• 本地 Postgres；
• 基于 Docker 的持久沙箱。

本地沙箱镜像包含 Claude Code、Codex CLI、GitHub CLI、AWS CLI、Python 和执行代理。Smoke Test 覆盖了冷启动、命令执行、文件持久化、停止后热恢复、临时 Scratch Box 和最终清理，全部通过。

本地实例由一个 Supervisor 管理 Core、Web、Admin、Portal 和可选 Slack 子进程。Supervisor 会等待端口真正释放后再重启崩溃进程，记录每个 Child 的 PID、健康状态与重启次数，并周期性探测服务。重新执行 dev up 不是简单返回“已经运行”，而是重新读取 Shell Env、全局 dev.env 和 Worktree .env，对比变化后滚动重启需要更新的子服务。

数据库方面，如果没有显式提供 DATABASE_URL，启动器会创建或复用本地 Postgres 容器，为当前 Worktree 建立数据库，并将 Session Store 与 Run Store 都切到 Postgres。空数据库还会为本地 Principal 初始化 Admin Grant，Portal 使用仅限 Localhost 的身份旁路，避免开发者为了打开本地后台先部署完整 OIDC。

Sandbox Smoke Test 的文件持久化不是只检查“容器能启动”。测试第一次创建持久 Scope 容器与 Volume，执行命令写入 Marker，停止容器后再次 Provision，确认是 Warm Restart 且 Marker 仍然存在；随后再创建 Scratch Box，确认执行后容器与 Volume 都被销毁。这正好验证了前文所说的两种生命周期。

Slack 模式还有一个很实际的并发约束：Socket Mode App 不能被多个实例同时占用，否则 Slack 会在多个连接间分发事件，让每个实例只收到一部分消息。QM 的开发启动器为每台机器维护 Slack App Pool，一个 Worktree 领取一个 Slot，并通过 Socket Hello 中的连接数和 Canary 消息验证这个 Bot 确实只有当前实例连接。Browser-only 模式则可以完全关闭 Slack，不需要 App Token。

这次验证能说明 QM 的工程主线已经是连贯的：请求可以进入 Core，状态进入 Postgres，命令进入隔离沙箱，Web 与 Admin 由 Portal 统一暴露。它不是只有接口抽象的架构草案。

但本地跑通也再次说明它的使用门槛：完整环境需要 Node 24、Docker、Postgres、真实模型凭据，若启用 Slack 还需要单独创建 Socket Mode App。QM 更像平台工程项目，而不是下载一个桌面客户端就能使用的个人工具。

QM 和普通聊天机器人、自动化平台有什么不同

可以把三者放在一起比较：

QM 并不是要替代所有 Workflow。相反，确定性、可预测的业务步骤仍适合传统自动化；QM 更适合那些需要模型判断、工具调用、长期上下文和人机协作，同时又必须保留身份与审计的任务。

如果从更多维度判断，可以得到更清晰的选型边界：

实践中三者可以组合。传统 Workflow 负责订单同步、数据校验和明确审批链；QM 负责解释异常、收集补充信息、形成方案并请求人确认；聊天入口则负责让员工自然地发起或查看任务。重点不是选一个工具包打天下，而是把动态判断与确定性执行放在正确层级。

QM 的核心特色：为什么它不是另一个聊天机器人外壳

QM 最鲜明的定位可以浓缩成一句话：它不是给一个 Bot 增加更多工具，而是为一个组织建立共享但相互隔离的 Agent 工作系统。

这个区别听起来抽象，却会直接影响系统的数据模型。许多产品先创建一个 Agent，再给它添加知识库、Prompt、Connector 和聊天窗口；多人使用往往只是让更多账号访问同一个 Bot。QM 则先承认组织中存在不同的人、房间、团队和项目，再让 Agent 在这些边界内工作。因此，隔离、共享、授权、持久状态和后台任务不是后加功能，而是从 Scope 这一基础对象自然派生出来的能力。

特色一：Multiplayer First，而不是把单用户 Agent 强行扩成多人版

QM 将个人、频道、团队、组织和群组表示为不同 Scope。每个 Scope 都可以拥有自己的会话、记忆、文件、Keychain 视图、Skills、定时任务、Web App 和持久沙箱。用户在私聊中形成的个人上下文，不会因为同一个 Bot 被拉进公共频道就自动暴露；项目频道积累的工作资产，也不必复制进每位成员的个人空间。

这种设计特别适合以下协作场景：

• 创始人在个人 Scope 中处理融资材料，同时在管理团队 Scope 中共享经过筛选的版本；
• 工程团队在项目频道里让 Agent 跟踪代码、测试和 CI，而开发者自己的草稿与凭据仍留在个人 Scope；
• 销售团队共享客户研究 Skill，但每位销售只使用自己被授权的邮箱或 CRM 凭据；
• 一个成员退出项目后，系统根据动态成员关系收回共享 Scope 的访问，而不是依赖管理员记得删除所有散落的聊天记录和 Token。

这里的差异不只是“支持多人登录”。真正的 Multiplayer 需要同时回答资产归属、默认可见性、成员变化、授权继承、发送目标和执行身份。QM 把这些答案放进同一套 Scope、Principal、Grant 和 Audience 模型中。

特色二：每个 Scope 都有一台持久的 Agent Computer

很多聊天机器人所谓的“执行代码”，实际是在一次请求期间启动临时解释器。请求结束后，安装的软件、生成的目录、Git Checkout、CLI 登录状态和本地缓存也随之消失。下一次请求必须重新准备环境，Agent 很难承担跨天或跨周的真实工作。

QM 的 Agent Computer 是按 Scope 隔离的持久执行环境。它可以保留项目文件、工具安装结果和被允许持久化的登录状态；停止后再次启动，Workspace 仍然存在。对于一次性处理不可信输入，QM 又提供执行后销毁的 Scratch Box。两种生命周期让“持续工作”和“用完即弃”不必互相妥协。

这一点使 QM 更接近一名拥有独立工作电脑的数字同事，而不是只能调用几个 API 的聊天窗口。它可以在同一仓库中持续修改代码、等待 CI、读取下一轮反馈，也可以维护一个定期更新的数据产物或内部应用。持久化的代价是更高的资源、安全和运维责任，但对于需要真实文件环境的任务，它带来的连续性很难用纯对话历史替代。

特色三：统一控制平面，而不是每个入口复制一套权限逻辑

QM 的 Slack、Web、Admin 和 Portal 都是 Surface，最终身份解析、Scope Resolution、Capability 计算、工具调用、审批、审计和状态写入都回到 Core。Cron、Watch 和 API 调用也进入相同的控制平面。

这意味着一次动作无论从 Slack 还是 Web 发起，都应该得到一致的权限判断；后台任务也不能因为“没有人在聊天窗口里”就绕过身份和凭据规则。Surface 只负责证明请求从哪里来以及结果送到哪里，不自己决定用户最终能读取哪些 Memory、使用哪些 Credential 或执行哪些命令。

对于企业而言，这比“同时支持 Slack 和 Web”本身更重要。入口数量会持续增加，如果每个入口都独立维护身份映射和授权规则，迟早会出现一个宽松路径。QM 的策略是让所有路径在真正产生副作用之前汇合。

特色四：Harness 和模型可以替换，组织资产不随供应商一起重建

QM 将 Pi、OpenCode、Codex 和 Claude Code 等 Agent Runtime 放在 Harness Adapter 后面。模型和 Harness 负责推理、规划及协议适配，Scope、Session、Memory、Workspace、Credential、Run 与审计仍由 Core 管理。

这带来两层可替换性：组织可以在不同 Scope 使用不同模型，也可以更换整个 Agent Harness，而不必同时迁移所有组织状态。更换供应商当然不会完全零成本——工具能力、上下文窗口、推理风格和 Provider Session 都可能不同——但系统中最昂贵的资产不再只能存在某个模型厂商的对话产品里。

对选型者而言，真正需要比较的不是“今天哪家模型回答更好”，而是“明年更换模型后，身份、授权、记忆、文件、任务和审计是否还在”。QM 试图将模型选择从平台命运降级为可治理的运行配置。

特色五：后台任务继承完整的组织语义

传统聊天产品擅长用户发一句、系统答一句；一旦任务要在晚上继续、下周重复或等待外部事件，身份和可靠性问题就会浮现。QM 的 Cron 与 Watch 不只是定时发送一段 Prompt，它们保存 Owner、Run As、Scope、Audience 和 Destination，并由持久 Run Store 记录生命周期。

Leader Lease 防止多个 Core 重复调度，Slot Claim 防止同一时间窗重复创建 Run，Run Lease、Heartbeat 和 Reaper 处理 Worker 崩溃与超时，Delivery Idempotency 避免结果被重复发送。更关键的是，执行资格和投递资格会重新检查：创建任务时有权限，不代表几个月后仍应继续使用同一凭据或向同一频道发送结果。

因此，QM 的后台工作不是附着在聊天功能旁边的 Cron 插件，而是与交互式请求共享身份、权限、状态和审计语义的另一种执行方式。

特色六：Skills、Tools、凭据和 Web App 都是可治理资产

在轻量 Agent 系统中，Skill 经常只是一段复制到 Prompt 的文本，Tool 只是一个全局开启的函数。QM 给这些能力增加了 Owner、Scope、Grant、版本、内容哈希和组织晋升过程。个人或团队可以先拥有自己的 Skill，经过管理员审核后再推广到整个组织，而不是任何人上传一段指令就立刻影响所有员工。

Tool Descriptor 同时描述二进制、参数、环境、Credential Path、审批规则和模型提示。配置在 CLI 侧验证，提交到 Core 后再次验证；部署层以内容哈希保存，线上检查可以判断实际运行内容是否与仓库声明一致。

Web App 也沿用同一个思路。Agent 可以生成并发布内部应用，但 App 得到的是受限 Capability，而不是 Core 的万能管理员权限。这样，Agent 产物可以从一次性回答升级为持续服务，同时仍有明确的访问对象和能力边界。

特色七：组织定制与 Core 升级分离

QM 通过 Deployment Directory 保存组织配置、Sandbox Image、私有 Skills、Tools、Plugins、基础设施参数和 Secret 声明，Core 保持通用。目录固定 QM CLI 版本、部署契约、镜像摘要和文本层内容哈希，部署前后都可以检查声明与现实是否一致。

这种分层解决了自托管系统常见的两个极端：要么只能接受 SaaS 厂商提供的固定能力，要么 Fork 整个项目并长期维护大量魔改代码。QM 允许组织拥有自己的执行环境和业务能力，同时尽量让 Core 继续从上游升级。定制仍然需要工程纪律，但升级冲突的范围更清楚，也更容易审计哪些内容属于组织私有资产。

特色八：部署在组织自己的云账户，系统边界由组织掌握

QM 支持本地 Docker、Fly.io 和 AWS 部署。生产实例、数据库、Sandbox、Secret 和网络资源运行在组织选择的账户中，而不是统一进入一个厂商控制的多租户 SaaS。对于需要自定义网络路径、云角色、日志、备份和数据保留策略的团队，这是一个重要差异。

自托管并不自动等于私密或合规：模型和浏览器供应商仍可能收到请求数据，错误的 IAM 或出口策略仍会造成风险。但组织至少拥有定义这些边界的能力，也能将部署 Manifest、数据库 Snapshot、Secret Routing 和镜像 Digest 纳入自己的变更流程。

为什么选择 QM，而不是其他方案

QM 并不在所有维度上都优于其他工具。它真正占优的场景，是团队同时需要多人隔离与协作、开放式模型判断、持久执行环境、跨时间任务，以及能够自行控制部署和治理。少一个条件，都可能有更轻量的选择。

下面按产品类别比较，而不是按品牌比较，因为同类产品的具体功能会快速变化：

从架构采购角度看，QM 的价值不是多了某个聊天按钮，而是减少了团队自己拼装以下系统的成本：

身份与成员关系
  + 多租户数据隔离
  + Agent Runtime 适配
  + 持久执行环境
  + 凭据授权与审批
  + 后台队列与幂等投递
  + Slack / Web 入口
  + Skills / Tools 治理
  + 自托管部署与漂移检查

如果企业从一个通用 Agent Framework 开始，这些能力最终大多仍要建设。QM 的取舍是先提供一套相互配合的系统骨架，组织再把自己的模型、Skills、Tools、Connector 和 Sandbox Layer 放进去。它减少的是“平台胶水”的重复建设，并不减少企业对业务权限和安全责任的判断。

选择 QM 的六个强信号

当下面六种信号同时出现三到四个时，QM 值得进入 PoC：

1. 不止一个人使用 Agent，而且个人空间、项目空间和组织空间必须明确隔离。
2. Agent 需要跨多轮、跨天继续操作真实文件、代码仓库或本地工具，而不是只返回文本。
3. 同一项工作既可能从 Slack 发起，也可能从 Web、Cron 或 API 发起，并要求一致的权限与审计。
4. 团队不希望核心资产绑定单一模型或 Agent Harness，希望保留供应商切换能力。
5. 组织需要在自己的云账户管理网络、数据库、Secret、镜像、日志和备份。
6. Agent 将逐步执行有副作用的动作，因此需要审批、命令策略、幂等、恢复和投递控制。

不应该选择 QM 的情况

以下情况选择 QM 反而会增加不必要的复杂度：

• 只有一两位个人用户，需求主要是问答、写作和偶尔上传文件；
• 流程完全确定，模型只需在某个节点做分类或摘要，传统 Workflow 更易测试和审计；
• 团队没有 Node、Docker、Postgres、云基础设施及安全运营能力，也不准备投入平台维护；
• 项目要求厂商已经提供特定行业认证、正式 SLA、7×24 支持或大量现成 Connector；
• 目标只是做一次短期 Demo，不需要持久状态、长期任务和组织权限；
• 高敏生产动作必须立即全自动执行，但组织尚未建立审批、回滚、密钥与网络隔离机制。

QM 当前更像一个开放、可扩展的组织 Agent 基础设施，而不是交钥匙 SaaS。选择它意味着获得更大的控制权和可替换性，也意味着接受部署、安全、升级和运行成本。对没有平台工程能力的团队，成熟托管产品通常会更快产生价值。

用 PoC 证明差异，而不是只比较功能清单

一个有意义的 QM PoC 不应只测试“模型能否回答问题”，而应选择一条同时跨越多人、持久状态和受控执行的真实业务链。例如：工程团队在 Slack 项目频道要求 Agent 分析一个仓库，Agent 在项目 Scope 的持久 Sandbox 中运行测试、生成修复、等待 CI，并在第二天把结果投递回原频道；与此同时，开发者个人 Scope 中的文件和凭据不能被项目成员读取。

PoC 至少应该验证以下结果：

• 同一用户从 Slack 和 Web 进入时解析为一致 Principal，并看到正确 Scope；
• 两个 Scope 的 Memory、Workspace、Credential 和 Session 不发生串读；
• 沙箱停止再恢复后，仓库、安装工具和非临时文件仍然存在；
• 更换 Harness 或模型后，已有 Session、Memory、Workspace 和 Run 仍可继续使用；
• Worker 在执行中被终止后，Run 能被识别、回收或重试，不产生重复副作用；
• 成员退出项目或 Grant 被撤销后，新的读取、执行和投递立即失败；
• 部署配置、镜像和 Skill 改变后，plan 与 check --live 能识别预期变更和意外漂移；
• 管理员能从审计记录还原谁在什么 Scope、使用什么能力、对哪个目标产生了什么结果。

如果这些测试正好对应组织当前最痛的工程问题，QM 的差异化就有实际价值。如果团队最终只关心回答质量和上线速度，那么更成熟的托管助手可能是更合理的选择。

企业采用这类架构，可以从四步开始

即使不直接采用 QM，它的架构也给企业 Agent 建设提供了一条清晰路线。

第一步：先定义 Scope，不要先堆 Prompt

明确个人、团队、项目和组织数据分别属于谁，哪些信息可以授权共享。没有 Scope 模型，后续记忆、知识库和凭据都会混在一起。

这一阶段的交付物应该是一张数据与协作边界表，而不是 Prompt 模板。至少列出 Principal 类型、Scope 类型、每类资产的 Owner、默认 Audience、允许的读写 Grant、离职或退出项目后的处理方式。验收问题是：给定任意一份文件、记忆或凭据，团队能否明确回答它属于哪个 Scope、谁能读、谁能写、谁能改变授权？

第二步：让所有入口汇合到统一控制平面

Slack、Web、Cron 和 API 不应该各走一套权限逻辑。统一身份、授权、审计和投递，比增加更多聊天入口更重要。

第二阶段要画出完整请求链：每个 Surface 如何证明 Principal，如何选择 Scope，后台任务如何保存 Run As，Webhook 如何标记 Provenance，消息如何验证 Destination。验收时应模拟同一用户从 Web、Slack 和 Cron 发起相同动作，确认三条路径得到一致的权限结果和审计字段。

第三步：把执行环境当成长期资产

Agent 如果要参与代码、数据和运营工作，就需要持续存在的工作目录、工具和登录状态。同时必须把执行环境视为敏感边界，限制凭据、网络出口和不可逆命令。

交付物应包括 Sandbox Image、工具清单、持久目录、Credential Path、网络出口白名单、资源配额和销毁策略。需要分别测试 Cold Start、Warm Resume、Worker 崩溃、凭据过期和 Scope 回收，而不只是测试一次 echo hello。对生产系统，还应验证容器内 Root 不等于宿主机 Root、挂载目录没有越界、短期云角色不能访问其他环境。

第四步：从辅助决策进入受控执行

先让 Agent 搜集信息、生成草稿和提出建议，再逐步开放可逆操作。管理员授权、身份切换、命令审批、付款、删除和生产变更应保留确定性的人工边界。

可以把动作按风险分成四级：只读查询、生成草稿、可逆写入、不可逆或高价值写入。每一级分别定义自动执行范围、审批人、幂等键、回滚方式和审计要求。只有当前一级的失败模式被真实演练过，才开放下一级，而不是因为一次 Demo 成功就直接交出生产权限。

此外还要为后台任务定义 SLO：允许延迟多久、最多重试几次、重复投递如何识别、接收者拒绝后是否停用、任务卡死由谁处理。Agent 自动化一旦离开聊天窗口，可靠性指标就和模型质量同样重要。

结语：企业 Agent 的竞争，不只在模型层

模型越来越强，但企业 Agent 真正困难的部分正在模型之外：身份如何解析，数据如何分域，凭据如何授权，任务如何持续，结果如何投递，操作如何审计，系统又如何在更换模型和 Harness 后继续工作。

QM 的价值不只是提供了一个开源实现，更在于把这些问题放进了同一张架构图里：

• 用 Scope 组织个人与共享边界；
• 用 Core 统一身份、策略、调度和审计；
• 用可替换 Harness 避免绑定单一模型生态；
• 用持久沙箱给 Agent 一台真正能工作的计算机；
• 用 Postgres 保存跨实例、跨时间的组织状态；
• 用部署目录和内容哈希管理组织自己的 Skills、Tools 与运行配置。

它仍然早期、复杂，也明确存在安全缺口。但这恰恰让 QM 成为一个值得研究的样本：当 AI 从个人助手进入组织工作流，我们需要建设的已经不是更多聊天窗口，而是一套能够承载身份、权限、状态、执行与责任的 AI 工作系统。

判断一个组织 Agent 平台是否真正跨过 Demo 阶段，可以用五个问题收尾：服务重启后任务能否继续？换一个 Harness 后组织资产是否还在？一个用户退出 Scope 后权限是否立即收回？同一副作用重试时会不会重复发生？发生错误后能否从 Session、Run、Tool、Credential 和 Delivery 记录中还原完整链路？

如果这五个问题没有答案，再强的模型也只是一个聪明但不可管理的临时工。QM 还没有把所有答案做完，却已经把问题摆在了正确的系统层上。