🎯 同一个模型放进不同Agent Harness，最终的稳定性、权限边界、记忆能力和运行成本可能完全不同。YC开源的QM把这层基础设施完整展示了出来。
近期关于“Agent表现有多少来自模型、有多少来自Harness”的讨论再次升温。有人把Harness贡献估计为六成，这个数字属于从业者经验判断，缺少统一基准支持；背后的方向很清楚：模型只负责生成下一步，生产系统还要负责身份、状态、工具、审批、错误恢复和审计。
Y Combinator开源的QM项目 提供了一个可直接研究的样本。它采用MIT许可证，定位是面向企业和团队的多人Agent Harness，运行在Slack与Web中。YC表示，QM已经用于会计、法律、活动和工程等内部工作，但官方同时明确标注项目仍处于早期实验阶段。
📌 Agent、Harness和平台分别做什么
一个完整Agent系统可以拆成三层：
| 层级 | 主要职责 | 常见组件 |
|---|---|---|
| 模型与Agent Loop | 理解任务、选择动作、生成工具调用 | GPT、Claude、Gemini、开源模型 |
| Agent Harness | 管理状态、工具、记忆、权限、重试和验证 | QM、Claude Code、Codex、OpenCode、Hermes |
| 运行平台 | 提供账号、消息入口、数据库、沙箱和部署环境 | Slack、Web、VPS、容器、云平台 |
模型能力决定推理和生成质量。Harness决定模型能看到什么、能调用什么、失败后如何恢复、执行结果是否可信。平台继续承担账号体系、数据持久化、网络和运行资源。
许多“模型突然变聪明”的体验，实际来自Harness升级：系统提示词更精确、工具返回更干净、上下文更短、错误会自动重试、关键步骤有测试和审批。反过来，强模型进入一个缺少状态管理和验证的Agent Loop，也容易反复执行、遗忘进度或错误修改文件。
🧩 YC QM的核心设计
QM与个人聊天机器人的差异集中在scope。每位员工、每个Slack房间和每个项目都有独立作用域，包括：
- Memory：长期记忆和会话状态；
- Files：该作用域可访问的文件；
- Keychain View：当前可见的凭据；
- Permissions：工具和数据权限；
- Crons与Watches：后台定时任务和监控；
- Web Apps：面向指定人员发布的内部应用；
- Durable Sandbox：长期保留文件与已安装工具的隔离计算机。
官方架构使用一个Headless Core统一处理API、身份、策略和调度，Postgres保存会话、记忆、队列及其他持久状态。Agent通过固定工具面工作，其中execute会在当前Scope的独立沙箱里运行命令。
QM允许Pi、OpenCode、Codex和Claude Code驱动同一个Core。企业可以更换模型或Harness适配器，同时保留原来的身份、记忆、Slack入口、权限和业务数据。
这种结构解决了团队Agent最容易失控的三个问题：
- 每个人使用同一个机器人，记忆和凭据容易串线；
- 多个机器人各自维护数据库、权限和定时任务，管理成本持续增加；
- 工作流绑定某一家模型服务，迁移时需要重建整套系统。
⚙️ QM官方部署流程
QM默认部署在企业自己的云账号中，当前初始化目标为Fly.io或AWS。官方推荐创建组织自有的部署仓库，再通过npm包初始化：
npm exec --yes --package=@yc-software/qm@latest -- \
qm init . --org <slug> --target <fly-or-aws>
npm install
在QM源码仓库内创建组织Layer时，对应命令是：
node cli/bin/qm.ts init deploy/layers/<org> \
--org <slug> \
--target <fly-or-aws>
qm init会生成部署目录、deployment.md以及供Agent读取的部署Skill。后续流程包含：
- 确认操作者控制云账号和账单；
- 配置Web登录与管理员邮箱；
- 设置Resend API Key或SMTP凭据；
- 添加模型、浏览器及数据连接器；
- 按需启用Slack；
- 部署服务并执行Live Check；
- 返回Web、管理端和运行服务地址。
默认身份服务通过邮件发送一次性登录链接。使用外部身份提供商时，需要从服务列表移除auth，并登记准确的回调地址：
<publicUrl>/auth/callback
QM初始化不会自动创建生产CI。部署目录里的云账号、机密、Provider配置和生命周期操作仍由团队负责。准备多模型上游时，可参考站内的9Router多模型网关指南 ；需要额外API线路时，可查看APIMart模型入口 ，生产环境应同时保留官方线路和故障回退。
🔐 三种安全姿态
QM要求组织选择一个全局Security Posture，具体Scope只能进一步收紧：
| 模式 | 工具调用策略 | 适用场景 |
|---|---|---|
| Strict | 几乎每次工具调用都暂停并等待人工批准 | 财务、法律、生产系统初期接入 |
| Auto | 默认模式，使用分类器筛查带来源标签的外部数据和工具结果 | 内部知识库、工程协作、常规自动化 |
| Dangerous | 不做内容筛查，也不在工具调用间暂停 | 完全隔离的实验环境 |
预声明Command Policy在三种模式中都会执行，包括审批规则和递归删除、破坏性SQL等硬拒绝项。Dangerous代表更少的人机暂停，并不会取消底层命令策略。
官方SECURITY.md同时列出多个生产风险：
- Shell文本策略可以被编码、混淆或“写脚本再执行”绕过；
- 浏览器Runner中的动作没有全部重新进入命令审批链；
- 凭据注入沙箱后会以明文形式被进程使用；
- Auto筛查属于启发式防御，无法保证抵御Prompt Injection；
- 管理员能够读取大量敏感内容，读取行为会被审计；
- 会话、记忆和模型请求可能长期保留；
- 公开应用的Capability Link属于持有即授权；
- 部分Provider路径仍未统一通过Model Gateway。
因此，QM当前更适合内部可信用户和单一组织。公开多租户SaaS需要补充独立身份边界、网络隔离、密钥代理、数据保留策略和安全评审。
📊 厚Harness与薄Harness怎么选
YC QM代表“厚控制层”：集中管理多人身份、Scope、权限、数据库、Slack、定时任务和沙箱。Vercel Labs开源的fx 代表“薄Harness”：使用Zig编写，强调小体积、原生运行、可嵌入和较低上下文占用。
| 需求 | 更合适的方向 |
|---|---|
| 单人在终端完成编码任务 | 薄Harness，减少提示词和工具开销 |
| 多人共享Agent与公司数据 | 厚Harness，优先身份、Scope和权限 |
| 高频短任务与批处理 | 小型原生Agent，降低启动和Token成本 |
| 跨部门长期自动化 | 持久状态、审计、审批和后台任务 |
| 模型经常切换 | 把模型接口与业务状态解耦 |
选型时应分别测试模型和Harness。固定模型后比较任务成功率、工具错误率、Token消耗和人工接管次数；固定Harness后再比较不同模型。把两部分一起更换，只能看到总结果，很难知道改进来自哪里。
⚠️ 落地时优先检查什么
- 权限是否按人和项目隔离：共享聊天入口也要有独立数据边界。
- 工具结果是否进入验证环：文件修改后运行测试，数据写入后执行回读。
- 失败是否有停止条件：限制重试次数、Token、时间和可产生的外部副作用。
- 凭据是否按需注入：短期Token、最小权限和独立服务账号优先。
- 记忆是否可审查和删除：长期记忆需要来源、更新时间和生命周期。
- 管理员读取是否透明：内部制度应明确哪些角色可以查看会话和请求数据。
- 外部内容是否带来源标签：网页、邮件和Webhook都是潜在Prompt Injection入口。
- 紧急停止是否真实可用：准备账户冻结、Token撤销、任务暂停和沙箱销毁流程。
Agent Harness的价值体现在可重复完成任务，同时让失败可以被发现、阻止和恢复。企业落地AI Agent时，模型排行榜只能解决选型的一部分，身份、状态、权限和验证才构成长期可维护的系统。
