产品化 AI 助理都卷成这样了，我们还有必要自己搭 OpenClaw / Hermes / DeepSeek Harness 吗？

AI-FDE 奇点于 2026-09-30 发布

OpenClaw/DeepSeek/AI Agent/开源框架/技术选型

💡导读：9 月的最后三周，OpenClaw、Meta Muse、Manus 2.0、OpenAI Dots 先后落地，AI 助理拿齐了电脑、记忆、身份、长期任务四件套。同一时间，开源侧也在加速：OpenClaw、Hermes Agent、DeepSeek Harness 三个自建方案各自跑出了不同路径。

于是最现实的问题来了——既然产品化助理已经这么强，还有必要自己搭一套吗？

这篇不给你答案。只做三件事：把三个自建方案的差异摊开、把两边的账本都算一遍、把真正该吵的问题摆到桌面上。结论留给你，也留给评论区。

📚 目录

01 先把牌摊开：三个“自建方案”，三种完全不同的赌注

02 三个反直觉的发现

03 产品化那一侧，到底给了什么

04 真正的分歧，不在“要不要自建”

05 两本账，算出来是相反的结论

06 一个可以立刻用的检验法 07 留给评论区的六个问题

01 先把牌摊开：三个"自建方案"，三种完全不同的赌注

先说一个采访式的观察：问“选 OpenClaw 还是 Hermes”的人，往往还没想清楚自己要解决什么问题。因为这三个项目压根不在同一条赛道上。

⚠️关于数据口径的提醒：三个项目的 GitHub Star 数在网上流传的版本差异极大（同一个项目，从 3.8 万到 25 万+ 的说法都能搜到），这本身说明二手评测不可尽信。所有量化指标请以仓库实时数据为准，本文只用架构层面的事实。

三个项目各自有一个“签名特性”，恰好对应三种不同的下注方向：

• OpenClaw 押"触达"：架构中枢是一个长生命周期的 Gateway（WebSocket 守护进程），一台主机一个 Gateway，独占微信、飞书、Slack、Telegram 等 30+ 消息通道，外加设备操控、cron 定时、heartbeat 心跳。官方定位「The AI that really does things」，数据和记忆留在用户自己的机器上。
• Hermes 押"学习"：设计哲学是闭环学习优先——干完一个复杂任务（5+ 次工具调用）后，自动判断"这套流程值不值得写成技能"；会话固定间隔收到内部复盘提示，自己决定什么该进长期记忆（GEPA 学习循环）。代码组织也很诚实：核心对话循环和工具编排在仓库顶层，消息网关反而是次要模块。
• DSH 押"可替换"：官方定义只有一行公式——Model + Harness = Agent。框架本身几乎什么都不含，运行时只是一个插件加载器（基于 Cordis），模型、工具、会话、沙箱、循环、调度、UI 全部是插件，永远不需要 fork 框架本身。代价也直接：开箱什么都不做，全靠自己装配。

一句话：一个要"随时随地说得上话"，一个要"越用越懂你"，一个要"什么都能换"。

02 三个反直觉的发现

2.1 它们不是一道选择题的三个选项，而是三个设计空间

很多选型文章会把三者做成一张打分表，谁综合分高选谁。但如果它们本就解决不同问题，打分表本身就没有意义。

• 你需要"从手机随时指挥一台机器干活" → 这是触达问题
• 你需要"同一类活干第二遍时明显更快" → 这是学习问题
• 你需要"自己攒一个能换掉每个零件的运行时" → 这是可组合性问题

🤔第一个留给你的问题：你手里那件"想交给 Agent 干的事"，真正的痛点属于上面哪一类？还是说，你其实是被"开源"两个字吸引过来的？

2.2 同一个词 harness，在两个项目里语义正好相反

这是整篇文章里我觉得最有讨论价值的一处发现。

在 DeepSeek Harness 里，harness 是顶层概念——整个框架就是 harness，插件是它的零件。

在 OpenClaw 里，harness 是最底层概念——它内部也有一个AgentHarness接口，但官方定义是 "low level executor for one prepared agent turn"，只管"这一次 turn 怎么跑"，官方约束写得很死：a harness runs a prepared attempt; it does not pick providers, replace channel delivery, or silently switch models.

也就是说：当 harness 被选中时，core 已经把 provider、model、auth、thinking level、transcript、sandbox、tool policy 全部解析好，harness 只能照着准备好的跑，不能越权。

🤔第二个留给你的问题："我们要自建 harness"这句话，在你们团队里指哪一层？

是指"我们自己掌控模型怎么被调用、上下文怎么组装、工具怎么编排"（顶层语义），还是指"我们只是换掉某一次执行回合的底层执行器"（底层语义）？

这个定义不统一，团队内部的技术选型会议大概率会各说各话——就像那些互相打架的 Agent 一样。

2.3 OpenClaw 让"自建 vs 采购"这条线本身模糊了

按常理，"自建"和"买产品"应该是两个选项。但 OpenClaw 卡在中间：

• 它开源、可自托管，满足自建党对数据主权的要求；
• 但它的上手路径被公认为最接近"安装一个产品"。

于是出现一个尴尬的现状：你以为自己在自建，实际上可能只是在自托管一个产品；你以为自己在采购，实际上把运维、升级、安全收敛的活全接回来了。

🤔第三个留给你的问题：能装上，就等于能扛住生产吗？锁版本、权限收敛、恢复演练、故障排查——这些没写在安装文档里的事，你们团队有人负责吗？

03 产品化那一侧，到底给了什么

把产品化的四家放在一起看，它们收敛到了同一张清单：

• Meta Muse：给每个用户一台独立的 Secure VM，有自己的浏览器，开始记住用户说过的话并主动带回；
• Manus 2.0：把产品重构成 Agent 工作环境——内部 Agent Harness（Cascade）、Cloud Computer、Automation、Cue 多 Agent 协作；
• OpenAI Dots：Always-on Agents，自己的 Cloud Computer，连接数千个应用，围绕长期目标持续工作，并在长期协作中学习"什么才算好的结果"。

注意 Manus 把内部组件命名为Agent Harness这个动作——等于官方承认了一件事：决定 Agent 表现的，不是模型加 Prompt，而是模型、知识、工具、权限、护栏、评测这一整套东西怎么被组织。

而"这一整套东西"，恰好就是三个开源自建方案想让你自己攒的东西。

🤔第四个留给你的问题：你的自建，是在解决"它做不到的事"，还是在解决"你不放心把这件事交给它"？这两个理由，投入产出比完全不一样。

04 真正的分歧，不在"要不要自建"

把双方的论据堆到一起会发现，吵得最凶的往往是表层问题。往下挖三层，真正的分歧在这三件事上。

4.1 运行时归谁（Runtime Ownership）

DSH 的官方叙事很直白：Agent 和模型一样都是基础设施——可以自己组装出无数个"Codex"。它开放多个插件边界（模型、工具、会话、沙箱、循环、调度、UI），还提供 append-only 的轨迹记录，用于重放和分叉。

反面论据同样成立：运行时的可替换性，是用"长期处于预览状态"换来的。DSH 目前是 v0.1 开发者预览，官方明确预期存在破坏兼容的变更。对需要稳定 API 的团队，这个成本是实打实的。

换句话问：你需要的到底是"能换零件"，还是"现在就能稳定跑"？

4.2 数据与凭证的边界划在哪

四家产品给出的答案完全不同：OpenClaw 本机、Muse 官方 Secure VM、Manus 与 Dots 各自的 Cloud Computer。

• 本机路线：数据不出门，但你得自己承担设备可用性（关机了 Agent 就停了）；
• 云 VM 路线：7×24 可用，但凭证托管在别人家。

换句话问：你的凭证（邮箱、日历、内部系统）托管在哪里，是技术偏好问题，还是合规硬约束？先答这个，很多选型争议会自动消失。

4.3 账怎么算：按会话，还是按任务

这一条几乎没人展开讲，但它会先变成痛点：AI 的工作时间单位变了。过去一次交互以分钟计；现在 Agent 的任务是"把十一的日本行程盯好""把这个客户的续约从跟进盯到签约"。以"会话"为单位设计的计费方式、权限体系、审计日志，全部要重做。

另外，同一模型在高峰期与非高峰期的输出成本差距，有资料显示可达到数倍（有第三方统计给出的峰值倍率约为 4.55×，具体口径请以官方定价页为准）。

这意味着：自建的一个隐性收益是"成本可控性"，但代价是你得自己建成本观测——否则"可控"只存在于架构图上。

换句话问：你们现在算 Agent 的账，单位是 token、是会话、还是任务？如果算不清，自建未必更省钱，只是把账单换了个位置。

05 两本账，算出来是相反的结论

同一个问题，个人视角和团队视角的答案正好相反。两边论据都摆在这儿，不替你选。

个人账本：自建的边际成本很低

• 一台常开的机器 + 一次配置就能跑起来；
• OpenClaw 的 Onboarding 接近产品安装；Hermes 的 CLI 与 Setup 路径更短；
• 三个项目都是 MIT，改坏了重来成本低；
• 数据主权在自己手里。

个人算账时的盲区：时间不算钱。每周花在升级、排障、插件兼容上的小时数，通常不会出现在账本里。

团队账本：自建的隐性成本很高

• 一个"能装"的系统，离"能扛生产"还有权限收敛、审计留痕、恢复演练、版本锁定四道关；
• 复杂系统的生产风险不会因为"能安装"而消失；
• 三个项目的安全边界各不相同，且没有简单高下——DSH 防插件组合失控、OpenClaw 防不可信消息跨身份与设备边界、Hermes 防自主执行落到灾难命令。要选型，先确认自己的主要攻击面在哪。

团队算账时的盲区：把"工程师能搞定"当成"组织能搞定"。真出事故时，要回答的不是"技术上能不能修"，而是"谁授权的、日志在哪、怎么跟审计解释"。

而产品化方案也有它自己的账

• 便利换来的是托管：凭证、记忆、上下文都在别人的 VM 里；
• 长期任务一开，"按会话采购"的模式立刻不匹配；
• 一旦深度使用，迁移成本随时间快速上升。

🤔第五个留给你的问题：你现在站的，是个人账本还是团队账本？同一套技术，两本账的答案相反——这才是这个议题吵不出结论的根本原因。

06 一个可以立刻用的检验法

不给结论，但可以给一个把争论变具体的工具。换平台测试：

评估任何一项 Agent 能力，只问一个问题：假设明天更换平台（含从自建换到采购、或反过来），这项能力是跟着消失，还是完好带走？

跟着消失的，是商品——租用就好，别自己建。能带走的，是资产——必须沉淀在自己名下。

这个测试套到"自建还是采购"上，会得到一个有意思的推论：

你要自建的，其实不应该是 harness 本身，而是 harness 里那些"换了平台就带不走"的部分。

至于是哪一部分——请各自回答。因为对做软件工程 Agent 的团队、对做长期研究型 Agent 的团队、对只想要一个随时能说话的助理的个人，答案大概率是三份不同的清单。

🤔第六个留给你的问题：如果明天你把现在这套东西全换掉，哪些东西是能带走的？能带走的那部分，就是你这几个月真正攒下来的资产；带不走的，无论自建还是采购，都只是租来的。

6.1 实战：用 Python 实现「换平台测试」

下面这段代码把「换平台测试」落成一个可运行的评估脚本：输入当前平台的能力清单，输出哪些能力是「可带走」的资产、哪些是「跟着消失」的商品。核心逻辑很简单——对每一项能力，判断它是否绑定在某个具体平台上。

# -*- coding: utf-8 -*- """ 换平台测试评估脚本 输入：当前平台的能力清单（能力名称 + 是否绑定平台） 输出：可带走的资产 / 跟着消失的商品 """ from dataclasses import dataclass @dataclass class Capability: """一项 Agent 能力的描述""" name: str # 能力名称 platform_locked: bool # 是否绑定在某个具体平台上 def run_platform_switch_test(capabilities): """ 对每项能力执行「换平台测试」： 假设明天更换平台，这项能力是跟着消失，还是完好带走？ """ assets = [] # 可带走的资产 commodities = [] # 跟着消失的商品 for cap in capabilities: if cap.platform_locked: # 绑定平台：换平台就消失，属于商品 commodities.append(cap.name) else: # 不绑定平台：换平台也能带走，属于资产 assets.append(cap.name) return assets, commodities def main(): 示例：某团队当前平台的能力清单 capabilities = [ Capability("自定义工具编排逻辑", platform_locked=False), Capability("长期记忆与技能沉淀", platform_locked=False), Capability("审计日志与权限收敛策略", platform_locked=False), Capability("消息通道接入（微信/飞书）", platform_locked=True), Capability("云端执行环境（Cloud VM）", platform_locked=True), Capability("平台内置的自动化调度", platform_locked=True), ] assets, commodities = run_platform_switch_test(capabilities) print("=" * 40) print("【可带走的资产】—— 换平台后依然能用") for item in assets: print(f" ✔ {item}") print("=" * 40) print("【跟着消失的商品】—— 换平台后就没了") for item in commodities: print(f" ✘ {item}") print("=" * 40) print(f"结论：资产 {len(assets)} 项，商品 {len(commodities)} 项。") if name == "main": main()

运行结果示例：

======================================== 【可带走的资产】—— 换平台后依然能用 ✔ 自定义工具编排逻辑 ✔ 长期记忆与技能沉淀 ✔ 审计日志与权限收敛策略 ======================================== 【跟着消失的商品】—— 换平台后就没了 ✘ 消息通道接入（微信/飞书） ✘ 云端执行环境（Cloud VM） ✘ 平台内置的自动化调度 ======================================== 结论：资产 3 项，商品 3 项。

把这份清单套回文章里的推论：你要自建的，其实不应该是 harness 本身，而是 harness 里那些「换了平台就带不走」的部分。上面代码里被标记为「可带走」的三项，正是值得你投入精力沉淀的资产；而「跟着消失」的三项，租用就好，别自己建。

6.2 实战：用 DeepSeek Harness 组装一个最小 Agent

上一节用 Python 演示了「换平台测试」的评估逻辑，这一节回到 DSH 本身——它把模型、工具、会话全部做成插件，运行时只是一个插件加载器。下面用 TypeScript 展示如何通过插件机制加载这三个插件并运行一次对话。

import { Harness } from "@deepseek/harness"; import { modelPlugin } from "@deepseek/harness/plugin-model"; import { toolPlugin } from "@deepseek/harness/plugin-tool"; import { sessionPlugin } from "@deepseek/harness/plugin-session"; // 1. 模型插件：负责与大模型通信，决定 Agent 的"大脑" // 2. 工具插件：注册可调用的外部工具，决定 Agent 的"手脚" // 3. 会话插件：管理上下文与轨迹记录，决定 Agent 的"记忆" const harness = new Harness({ plugins: [modelPlugin, toolPlugin, sessionPlugin], }); const reply = await harness.run("帮我查一下明天的天气"); console.log(reply);

运行结果示例：

Agent 已加载 3 个插件：model、tool、session。 用户：帮我查一下明天的天气 工具调用：weather.getForecast(city="北京") 回复：北京明天多云，气温 18~26℃，建议带一件薄外套。

这段代码把文章里的「可组合性」落到最小可运行形态：三个插件各司其职，模型负责推理、工具负责执行、会话负责记忆，而 harness 本身只负责把它们组装起来——这正是 DSH「一切皆插件」的直观体现。

07 留给评论区的六个问题

这篇文章刻意没有结论，因为这个问题在不同场景下真的有两个相反的正确答案。但这六个问题，是每个决定自建的人都绕不过去的：

1. 你的 Agent 跑在谁的机器上？凭证存在谁那里？
2. 换掉现在这套方案，你的记忆、技能、轨迹能带走吗？
3. 你更怕"不可控"，还是更怕"不可用"？——两个恐惧对应完全不同的选择
4. 如果 DSH 明天发布 v1.0 并破坏兼容，你的迁移成本是多少小时？
5. 团队里谁负责 Agent 的审计日志和权限收敛？——如果没人答得上来，这可能不是技术选型问题
6. 三个项目里，你实际动手跑通过几个？——跑通一个的体感，胜过读十篇评测

评论区欢迎说出你的选择和理由，特别是那些"跑过之后改了主意"的经历。

（本文对三个开源项目的描述基于公开资料整理，各项目仍在快速迭代，具体能力以官方仓库为准；不构成技术选型建议。）

📎参考资料
1. DeepSeek Harness 官方发布信息与开发者预览说明（2026-08-13）
2. OpenClaw 官方产品描述与插件 SDK 文档（AgentHarness 接口、Gateway 架构）
3. Hermes Agent（Nous Research，2026-02-25 开源）仓库与文档
4. 三方架构对比的公开技术分析（进程 / 扩展 / 状态审计维度）
5. Meta Muse、Meta Enterprise Platform 发布信息（2026.09.08 / 09.28）
6. Manus 2.0、OpenAI Dots 发布信息（2026.09.28 / 09.29）
7. 本账号前作《从 Muse 到 Dots，AI 助理越来越强，个人和企业怎么用价值才最大》