最近在一个 QQ Bot 开发者群里我们因为 DeepSeek Harness简称 DSH接入 QQ Bot 的事情聊了很久。最开始的话题其实很普通为什么 QQ Bot 最近不断接入 OpenClaw、Hermes、DSH 这类 Harness 项目这究竟只是追赶 Agent 的热潮还是它们之间真的存在某种技术上的关联但聊到后面我们发现真正值得讨论的已经不再是“QQ Bot 为什么要接 Harness”而是另外一个更深层的问题为什么我们今天谈到 Personal Agent 时总会下意识地认为一个用户就应该对应一个 Harness甚至对应一个独立的容器如果我们不再把 Harness 理解成“一个用户安装在自己电脑上的 Agent 程序”而是把它重新理解成一种类似 Bot Framework 的基础设施会发生什么我们最后得出的判断是Personal Agent 的“一对一”是必要的但这种一对一应该发生在 Agent Identity身份层而不一定发生在 Harness Runtime运行时层更不一定发生在永久的容器层。换句话说一套 Harness 完全可能承载海量彼此独立的 Personal Agent。而真正需要强隔离的可能从来都不是 Harness 本身而是某些具有副作用的执行环境。这可能是 Agent 从自托管工具走向真正平台化时非常重要的一次架构解耦。一、我们为什么天然认为 Agent 应该“一人一套”过去几年很多 Personal Agent 产品给开发者建立了一套很自然的心智模型即一个用户等于一个 Agent等于一个 Harness等于一个 Workspace最终等于一个 Container 或 Runtime。对于自托管场景这种设计非常合理。用户在自己的机器或服务器上启动一个 Agent它拥有自己的配置、模型 Key、文件目录、Shell、浏览器、长期记忆和各种凭证。从使用者角度看这些东西本来就是一个整体。于是久而久之我们很容易把这种部署形态误认为 Agent 本身的架构定义得出“Personal Agent 是一对一的所以 Harness 也必须是一对一的”这样的结论。但这里其实悄悄发生了一次概念绑定。Personal Agent 真正要求独占的到底是什么是整个 Harness 进程还是属于这个用户的身份、状态、记忆、权限和工作空间这两个问题并不是一回事。如果一个 Agent 的性格、记忆、凭证、策略、目标、工具权限和长期状态都属于唯一用户那么即使底层有一万个 Agent 共用同一个 Harness Runtime它仍然完全可以是一个 Personal Agent。就像一个 Web Server 可以同时服务几十万个账户我们不会因此认为这些账户共享了同一个身份。我们早就接受了 Web Runtime 不等于 User State。但是到了 Agent 时代我们却暂时把 Harness Runtime、Agent 和 User 绑在了一起。这很可能只是 Agent 基础设施仍处在早期阶段留下的历史惯性。二、Bot 开发者为什么很容易想到另外一种答案这也是今天这场讨论很有意思的地方。参与讨论的人长期从事 Bot 和 Bot Framework 开发因此面对“一套 Harness 能不能服务很多用户”这个问题时第一反应和典型的 Personal Agent 开发者可能并不一样。因为对于 Bot Framework 来说一个 Runtime 服务海量用户才是最正常的事情。一个机器人程序可能同时存在于几万个群里每个群里又有成百上千个用户。但是我们从来不会为群 A、群 B、群 C 或用户 A、用户 B、用户 C 分别启动六套独立的框架进程。框架通常只存在一份真正发生变化的是 Context上下文。一个事件进入框架以后框架首先确定这是谁发送的来自哪里属于哪个群拥有什么权限应该读取哪份状态哪些插件在当前上下文中有效确认完毕后才开始执行具体业务。所以在 Bot 世界里我们早就习惯了一件事情Runtime 是共享的但执行上下文不是共享的。甚至可以说一套成熟 Bot Framework 的核心能力之一本来就是在同一个运行时中让海量彼此独立的上下文安全地共存。今天再回头看 Agent Harness一个非常自然的问题就出现了为什么 Harness 不能也是这样三、DSH 真正有意思的地方不只是“又一个 Agent”这也是为什么这次 DSH 接入 QQ Bot比单纯的“又适配了一个热门 Agent 项目”更值得讨论。DSH 官方把自己描述为建立在 Cordis 之上的插件式 Harness。模型适配器、工具注册表、会话日志、Agent Loop 等核心能力本身都以插件形式挂载在共享的上下文中而不是一个不可拆分的单体核心。更关键的是DSH 对 Cordis Context 与 Agent 或 Session Identity 做了明确区分。Cordis Context 负责服务、注册关系与生命周期而 Agent 和 Session Identity 表示一次异步操作真正属于谁。官方的设计说明甚至专门讨论了为什么不能简单使用某个全局的“当前 Agent”因为一个进程完全可能并发驱动多个 Agent。这其实已经非常接近 Bot Framework 开发者熟悉的思想了。而腾讯的 dsh-qqbot 插件又进一步把这个关系表现得非常直接数据流从 QQ 用户到 QQ WebSocket再到 dsh-im-qqbot 插件随后进入 ctx.agents 和 dsh agent loop最后调用 LLM。在这里QQ 并不是 Agent 本身而是一种前端协议和事件来源。从这个角度看DSH 和 QQ Bot 的结合其实并不突兀。它真正值得关注的不是能不能让 QQ 用户和大模型聊天而是另外一种可能如果 Agent 本身可以成为 Context那么一个 Harness 是否也可以像 Bot Framework 一样同时托管大量彼此独立的 Agent四、“一对多”会不会让 Personal Agent 退化成普通聊天应用讨论到这里有人提出了一个非常关键的反对意见Harness 一旦一对多会不会最终退化成一个泛用的对话 App这是一个非常合理的担忧。如果所谓的一对多是指一个 Harness、一个 Prompt、一个 Memory、一个 Tool Set所有用户不断向里面发送请求。那么它当然已经不是什么 Personal Agent而只是一个普通的聊天服务。但这里真正应该区分的是共享 Harness 和共享 Agent不是同一件事情。正确的多租户模型应该是在一个共享的 Harness 之下存在 Agent A、B、C它们各自拥有独立的身份、记忆、策略、授权和目标。这里真正被共享的只是 Agent 的运行机制而不是 Agent 自身。因此未来讨论 Agent 架构时可以把过去那个简单的“一对一”拆成三个完全不同的层级第一层是 Harness。一个 Harness Runtime 可以同时管理大量 Agent这是 1 对 N 的关系。第二层是 Identity。对于 Personal Agent 来说它仍然只属于一个主体。这个主体可以是一个人也可以是一个企业、一个项目或一个组织。这是 1 对 1 的关系。第三层是 Execution。Agent 根据任务需要创建零个、一个甚至多个隔离的执行环境。这是 1 对 N 的关系。这样一拆“一对多必然退化”的问题就不存在了。Personal Agent 的个人化属性并不来源于它独占一个进程而来源于它独占自己的身份与长期状态。五、但 Coding Agent 为什么又经常真的需要“一对一”这个时候另一个问题就出现了。像 Trae SOLO 这样的 Coding Agent为什么我们又明显感觉它需要自己的独立环境因为 Coding Agent 与普通对话 Agent 最大的区别之一是它拥有一个强副作用对象Workspace工作空间。Trae 对 SOLO 的公开描述就高度围绕项目代码、开发环境、浏览器预览和 Agent 执行能力展开。当 Agent 可以修改文件、启动进程、执行 Shell、读取环境变量、运行测试、安装依赖、访问 Git 凭证时这个工作空间本身当然必须拥有明确的安全边界。我们不可能让一万个陌生用户共同使用同一个工作目录、进程命名空间或环境变量。所以“一对一隔离”仍然必要。但这里需要再次问一句究竟是谁和谁一对一Workspace 需要与安全主体隔离并不意味着整个 Harness 也必须永久属于这个用户。这是两个完全不同的边界。六、真正应该拆开的是控制平面与执行平面这可能是整场讨论最后最重要的一个结论。未来规模化 Agent Platform 更合理的架构很可能不是用户、Harness、Container 之间相互绑定的一一对应。更合理的架构应该是一个共享的 Harness 作为 Agent 控制平面管理各自拥有独立记忆、授权和策略的多个 Agent 逻辑实体。控制平面下方连接任务调度器。对于安全的远程工具调用直接通过 API 处理而对于危险的执行任务则调度到沙盒或虚拟机中执行任务完成后自动回收资源。Harness 负责的是控制平面涵盖 Agent 身份、会话、记忆、目标、提示词、模型、工具注册、授权、调度与长期状态。真正容易产生安全副作用的部分进入执行平面涵盖文件系统、Shell、进程、浏览器自动化、代码库构建以及未知代码执行。实际上DSH 自己的近期架构设计也已经出现了类似的分离。Host 侧持有 Cordis、Agent Loop、状态管理和 LLM 调用逻辑而远端执行环境可以负责可变文件系统、终端命令行等执行资源。这意味着一个非常重要的变化容器不再是 Agent 的生命周期单位而成为 Execution执行阶段的生命周期单位。七、从“一个 Agent 一个容器”到“一个任务一个 Sandbox”这会直接改变 Personal Agent 的成本模型。过去我们可能认为用户创建了一个 Personal Agent所以我要为它长期保留一个容器。但绝大多数 Agent 请求其实根本不需要本地计算环境例如查询天气、读取日历、搜索资料、总结聊天、调用企业 API 或生成文本。这些工作完全可以通过远程 API 完成。只有当 Agent 真正需要执行 Bash、写入文件系统、自动化浏览器或构建代码时才需要创建强隔离的执行环境。于是“每个 Agent 一个容器”的模式可以逐渐变成“每个危险任务一个沙盒”甚至对于安全任务实现“零沙盒”。Google 在 Gemini Spark 上公开的设计提供了一个非常有意思的现实例子。Spark 被定义为持续存在的 Personal AI Agent会长期理解用户上下文并代替用户完成工作。但是 Google 并没有因此要求一个 Personal Agent 永久绑定一台虚拟机而是让每个需要执行的任务进入新的、严格隔离的临时虚拟机。这说明持续存在的 Agent 和持续存在的 Runtime本来就不是一回事。Agent 可以长期存在记忆、身份和目标都可以长期存在但执行它某一次任务的虚拟机只需要存在几分钟。任务结束后虚拟机销毁下一次任务到来再创建新的环境。从架构上看这已经非常接近“持久化逻辑 Agent 临时化物理执行”的模式。这比一人一台永远运行的 Agent 容器更接近真正能够规模化的平台形态。八、Bot Framework 曾经解决过一次类似的问题这也是为什么我认为 Bot 开发者看 Harness 会有一个特殊的视角。早期 Bot 同样很容易写成简单的线性流程收到消息、判断指令、执行代码、返回结果。后来随着群、用户、权限、插件、跨平台事件越来越复杂Bot Framework 才逐渐开始解决另外一些问题上下文怎么传播插件怎样隔离谁拥有某个服务不同群的配置怎样共存插件卸载以后注册的副作用如何一起消失也就是说Bot Framework 最终解决的已经不只是“怎么执行一个指令”而是“如何让大量彼此独立的状态和能力在同一个运行时中安全而有序地共存”。现在 Agent Harness 似乎正在重新经历一次非常类似的演化。第一阶段关注怎么让 LLM 调工具第二阶段关注怎么循环执行任务然后是怎么拥有记忆、工作空间和长期目标。再往后当真正开始考虑数十万甚至数百万用户时下一个问题一定会变成这些 Agent 为什么必须每一个都拥有一整套独立 Runtime这时候过去十几年 Bot Framework、Web 框架、数据库和云计算已经反复解决过的多租户问题会重新进入 Agent 世界。九、DSH 的潜力不是“不需要容器”而是有机会把 Harness 和容器解绑因此如果让我重新描述今天讨论中对 DSH 最有价值的判断我不会说它的优势是“不用容器”。这显然是不准确的对于执行不可信代码的场景沙盒与微型虚拟机的安全边界依然不可缺少。我真正关注的是DSH 这种面向框架的 Harness有可能让 Harness 不再和某个具体容器绑定。这一点的意义远远大于“少启动几个 Docker”。因为一旦 Harness、Agent 身份与执行环境被真正拆开Agent 平台的基本单位就发生了变化。过去是“用户-Agent-Harness-容器”的单线程绑定未来可能变成一个共享 Harness 承载多个逻辑 Agent 和独立身份并按需调度执行环境。于是成本控制、插件管理、模型路由和资源复用都会拥有完全不同的可能性。十、Agent 的“一对一”应该停留在身份层回到最开始的问题Personal Agent 到底需不需要一对一我认为答案依然是需要。但是我们应该非常准确地说清楚它需要的是“一个 Agent 对应一个身份”而不是对应一个 Harness 进程更不是对应一个永久的容器。一个真正属于我的 Agent应该拥有我的长期记忆、我的授权、我的偏好、我的工具、我的目标以及只有我能够访问的状态。这才构成真正的个人化。至于它背后的 Agent Loop 究竟运行在哪一个进程里我其实并不应该关心。就像今天没有人会因为自己的银行账户与另外一百万人共享同一套服务端程序就认为这个账户不再属于自己。当 Harness 真正成为 Framework今天很多 Agent Harness 仍然带有非常明显的个人软件形态下载、安装、配置密钥、启动运行时然后拥有一个专属 Agent。这是 Personal Agent 非常自然的第一阶段。但如果 Agent 最终真的像我们想象的那样进入每个人的聊天软件、工作平台和企业系统那么它迟早会面对 Bot Framework 曾经面对过的问题一个系统究竟应该怎样同时承载海量彼此独立的主体到那个时候Harness 可能就不再是一款“安装以后替我干活的软件”它会越来越像真正意义上的基础设施。聊天软件只是传输管道大模型是能力提供方记忆与凭证属于 Agent 身份而容器和沙盒只是需要发生副作用时临时申请的执行资源。Harness 本身则变成了承载和调度这些 Agent 的运行时框架。最终我们或许会重新定义所谓 Personal Agent它的“一对一”从来不应该由一台机器、一个进程或者一个容器来证明。真正应该一对一的是身份、记忆、权限与意志。Harness 可以是一对多的Agent 仍然可以永远只属于一个人。如果这个边界能够真正被建立起来那么从自托管 Agent 到平台托管 Agent 的跨越可能就不再只是一次部署方式的变化它会是 Agent 基础设施的一次真正成熟。