DeepSeek Harness vs OpenClaw

DeepSeek Harness vs OpenClaw：同样在做 Agent，为什么走了两条完全不同的路？

如果把大模型比作一个“大脑”，那么构建 Agent，至少还需要解决五个问题：

它从哪里接收任务？
它可以使用哪些工具？
它怎样记住过去？
多个任务如何隔离？
程序中断后，怎样恢复现场？

DeepSeek Harness 和 OpenClaw 都在回答这些问题。

但它们选择的起点不同：

DeepSeek Harness 更像一套“可组装的 Agent 运行时”。OpenClaw 更像一个“全天在线的数字助理中枢”。

一个关注 Agent 内部如何正确运转，另一个关注 Agent 如何进入用户的日常沟通环境。

理解了这一点，后面的架构差异就容易看懂了。

一、先用一张表看懂两者的区别

对比维度	DeepSeek Harness	OpenClaw
核心定位	可组合、可替换的 Agent 运行时	多渠道、长期在线的数字助理平台
架构中心	插件树、事件日志、能力接口	Gateway、渠道路由、Agent 工作区
主要入口	Web、Headless、CLI、ACP 等不同组合	WhatsApp、Telegram、Slack、飞书、WebChat、客户端
插件思路	连 Agent Loop、会话和工具注册表本身都是插件	插件围绕 Gateway 注册渠道、模型、工具、服务和 Hook
会话重点	完整记录 Agent 的执行过程	根据用户、群聊、频道和任务进行会话隔离与路由
记忆重点	可重放、可审计、可恢复的执行记忆	用户偏好、长期事实、每日记录和跨会话召回
安全重点	执行能力、沙箱、审批和持久化语义	身份接入、渠道权限、设备配对、工具策略和沙箱
更适合	构建新的 Agent 产品或底层运行时	快速部署个人助理、团队机器人和多渠道 Agent

这不是“谁更强”的比较，而是两套系统在优化不同的问题。

二、DeepSeek Harness：先把 Agent 的“发动机”造清楚

DeepSeek Harness 的架构理念可以浓缩成一句话：

Everything is a Plugin，一切皆插件。

这里的“插件”并不只是安装一个搜索工具或者模型适配器。

模型适配器是插件，工具注册表是插件，会话日志是插件，系统提示词是插件，甚至负责驱动模型和工具循环的 Agent Loop 本身也是插件。

虽然项目里存在名为 core 的包，但它们仍然参与同一套插件组合，不是一个只能修改、不能替换的特权内核。

可以把它想象成一台模块化汽车：

发动机可以换；变速箱可以换；仪表盘可以换；行车记录仪可以换；驾驶规则也可以通过插件扩展。

最终运行起来的 DeepSeek Harness，不是一个固定程序，而是一棵启动时组装出来的插件树。

它通过 Profile、Bundle、Preset 和 Patch 分层组合：

Profile 决定运行的是 Web Agent、Headless Agent，还是其他形态；

Bundle 提供一组基础能力；

Preset 决定某类 Agent 拥有哪些工具和行为；

Patch 允许部署者替换具体配置或插件。

因此，DeepSeek Harness 最关心的问题是：

能否只替换一个模块，就改变整个 Agent 的某项能力，同时不破坏其他部分？

三、OpenClaw：先让数字助理随时找到你

OpenClaw 的中心不是插件树，而是一个长期运行的 Gateway。

这个 Gateway 负责连接 WhatsApp、Telegram、Slack、Discord、飞书、WebChat 等消息入口，也负责接收桌面客户端、命令行、网页控制台和移动节点的连接。

消息进入之后，Gateway 需要依次判断：

这个人有没有权限联系 Agent？消息来自私聊、群聊还是频道？应该交给哪个 Agent？应该进入哪个 Session？结果应该回复到哪里？

官方架构中，一个长期运行的 Gateway 统一管理消息渠道、客户端和设备节点，并通过 WebSocket 暴露控制接口。

它更像一家公司的智能前台：

电话、邮件、飞书和网站消息都先进入前台；

前台识别来访者；

再把消息分配给销售、客服或技术人员；

最后把处理结果送回原来的渠道。

OpenClaw 当然也有完整的 Agent Loop。

它会装配上下文、加载 Skills、调用模型、执行工具、流式输出结果并保存会话。但这些能力围绕 Gateway 和会话路由组织，形成的是一套面向真实沟通场景的集成运行时。

所以 OpenClaw 最先考虑的问题是：

用户从任何渠道发来一条消息，系统怎样安全、连续、准确地交给正确的 Agent？

四、最本质的区别，藏在“记忆”里

两者都支持会话和记忆，但它们所说的“记忆”并不完全相同。

DeepSeek Harness：记住 Agent 做过什么

DeepSeek Harness 将一次 Agent 执行拆成连续事件：

一轮任务开始；用户消息进入；模型请求开始；模型输出流式片段；模型决定调用工具；工具返回结果；一个步骤结束；一轮任务结束。

这些事件被追加到 Session 日志中。

模型下一轮看到的历史，不是另一份单独维护的聊天记录，而是从事件日志重新推导出来的。换句话说，事件日志是事实底稿，聊天上下文只是它的一种视图。

这带来了几个重要能力：

可以回放 Agent 的执行过程；可以知道模型当时看到了什么；可以追踪工具调用及其结果；可以从中断现场恢复；可以判断某个有副作用的工具是否可能已经执行；可以从同一份日志生成聊天界面、统计数据和审计信息。

即使上下文过长需要压缩，DeepSeek Harness 也倾向于替换“模型当前可见的历史”，而不是删除原始事件。

就像一本账簿：

总账没有被撕掉，只是给模型生成了一份更短的当前摘要。

因此，DeepSeek Harness 的记忆首先是一种“执行记忆”。

它优先保证：可重建、可审计、可恢复。

OpenClaw：记住用户是谁，以及最近发生了什么

OpenClaw 除了保存会话历史，还提供了更接近个人助理的记忆层次：

USER.md：用户偏好、沟通方式和长期关系；MEMORY.md：长期事实、决定和重要信息；memory/YYYY-MM-DD.md：每天的工作记录和临时上下文；DREAMS.md：后台整理和记忆巩固的可审阅结果。

这些记忆使用普通 Markdown 文件保存。系统还可以通过关键词与向量混合检索寻找相关内容，并在上下文压缩前提醒 Agent 保存重要信息。

这更像一个真正的助理：

知道你喜欢 TypeScript；知道某个项目目前处于什么阶段；知道上周做过什么决定；知道哪些信息是长期偏好，哪些只是昨天的临时记录。

因此，OpenClaw 的记忆首先是一种“助理记忆”。

它优先保证：长期陪伴、跨会话召回和用户连续性。

可以用一句话概括：

DeepSeek Harness 更关心“Agent 当时做了什么”；OpenClaw 更关心“这个人是谁，以及我们以前聊过什么”。

五、两者都有插件，但插件扮演的角色不同

DeepSeek Harness 的插件更接近“系统组成单元”。

一个完整能力通常被拆成三部分：

Service Definition：定义统一接口；

Service Provider：提供具体实现；

Consumer：把能力暴露给 Agent 或其他模块。

例如，文件系统、Shell、沙箱、子 Agent、网页搜索都可以沿着这种结构组合。

它追求的是替换能力：

把本地执行替换成远程沙箱，依赖这项能力的上层工具仍然可以工作。

OpenClaw 的插件更接近“产品扩展单元”。

插件先通过 Manifest 被发现和校验，然后加载到 Gateway 进程中，将能力注册到中心注册表，最后由系统暴露为渠道、模型供应商、工具、Hook、命令或服务。

这种设计非常适合构建生态：

安装一个渠道插件，就能接入新的聊天平台；

安装一个模型插件，就能增加新的模型供应商；

安装一个记忆插件，就能替换记忆引擎；

安装一个公司插件，可以一次提供语音、图像、搜索等多种能力。

两者的差异在于：

DeepSeek Harness 用插件“组成系统”；OpenClaw 用插件“扩展产品”。

六、会话设计也暴露了不同侧重点

在 DeepSeek Harness 中，会话首先是一条事件时间线。

用户输入、模型输出、工具调用、压缩、恢复和分支都围绕这条时间线组织。它天然适合：

回放；Fork；Resume；调试；审计；测试 Agent 行为。

在 OpenClaw 中，会话首先是一个路由单元。

系统需要根据消息来源决定会话归属：

私聊默认可以共享主会话；群聊通常按群隔离；频道通常按房间隔离；定时任务可以每次创建新会话；多用户环境可以按渠道和发送者隔离；同一个人的不同渠道身份还可以关联起来。

这些规则解决的是现实世界中的问题：

微信上的张三和 Telegram 上的张三，是不是同一个人？家庭群和工作群，能不能看到彼此的上下文？两个用户私聊同一个机器人，会不会互相泄露历史？

因此，OpenClaw 把会话路由、身份隔离和回复路径放到了非常重要的位置。

七、安全设计：一个防止“执行失控”，一个防止“入口失守”

DeepSeek Harness 的安全设计主要贴近执行链路：

文件系统权限；Shell 与子进程；沙箱后端；人工审批；工具调用超时；中断恢复；执行环境替换。

它关心的是：

Agent 获得了某项能力后，怎样在明确的执行环境和权限范围内运行？

OpenClaw 因为直接连接聊天平台和设备，需要额外面对入口安全：

谁可以给 Agent 发消息；私聊是否需要配对；群聊是否需要白名单或被提及才响应；新设备能否连接 Gateway；某个 Agent 可以看到哪些工具；工具运行在宿主机还是沙箱中。

OpenClaw 将身份配对、渠道策略、工具白名单和沙箱组合在一起，形成面向长期在线服务的安全体系。

简单来说：

DeepSeek Harness 更像在管理“执行权限”；OpenClaw 还必须管理“谁能够触发这些执行”。

八、两者分别适合什么场景？

如果你正在开发一个新的 Agent 产品，下面这些需求更接近 DeepSeek Harness：

希望替换 Agent Loop 或模型适配器；需要精确回放模型和工具的执行过程；对审计、恢复和测试要求很高；希望统一抽象本地、远程和沙箱执行环境；需要在同一套底层能力上构建 Web、CLI、ACP 或其他产品入口；想研究或定制 Agent 运行时本身。

如果你希望尽快拥有一个可以投入日常使用的数字助理，下面这些需求更接近 OpenClaw：

希望接入 WhatsApp、Telegram、Slack、飞书等平台；希望一个 Gateway 管理多个渠道和设备；需要按用户、群聊、账号将消息路由给不同 Agent；希望通过 Markdown 管理用户偏好和长期记忆；需要定时任务、消息回复、多 Agent 和移动端节点；更关心“助手能否长期陪伴工作”，而不是重写底层 Agent Loop。

还要注意，DeepSeek Harness 官方目前将项目标记为 Developer Preview，架构仍在快速演进，允许出现破坏兼容性的变化。

九、它们并不是互斥关系

从架构上看，两者甚至存在组合空间：

用户与聊天平台↓OpenClaw Gateway身份、渠道、路由、回复↓Agent 执行后端↓DeepSeek Harness会话事件、工具执行、沙箱、恢复

这只是架构上的组合设想，并不代表两者已经提供开箱即用的官方集成。

但它说明了一件事：

OpenClaw 可以负责“接人”；

DeepSeek Harness 可以负责“办事”；

一个偏产品入口，一个偏执行内核。

结语

DeepSeek Harness 和 OpenClaw 表面上都包含模型、工具、会话、插件、记忆和沙箱，但它们真正想解决的问题不同。

DeepSeek Harness 问的是：

一个 Agent 应该怎样被正确地组装、记录、替换和恢复？

OpenClaw 问的是：

一个数字助理应该怎样进入用户的日常生活，并在不同渠道中持续工作？

所以，最准确的总结不是“谁取代谁”，而是：

DeepSeek Harness 把 Agent 当作一套系统来构建。OpenClaw 把 Agent 当作一个长期在线的产品来运营。

一个在向下扎根，打造可组合的运行时基础；一个在向外延伸，连接真实用户、消息渠道与设备。

它们代表了 Agent 时代两条同样重要的路线。