"OpenClaw、Hermes 与同类代理工程框架的现状、差异与趋势研究"

写在前面

最近 OpenClaw 和 Hermes 的讨论热度明显在下降。从年初的排队装龙虾到如今社区趋于冷静，大家开始回归理性看待这些 Agent 框架。

在这个节点，我们借助 ChatGPT Deep Research 做了一次系统性的横向对比研究：目前主流的 Agent 工程框架各自处于什么状态？它们的架构差异在哪里？安全和治理方面有什么隐患？未来趋势如何？

以下是完整的研究报告，希望能给大家在做技术选型时提供一些参考。

执行摘要

截至 2026 年 5 月，面向“长时程、可执行、可扩展代理”的工程栈已经明显分化成三条路线：一条是以 OpenClaw、Hermes Agent 为代表的“个人代理 / 自托管网关”路线；一条是以 Deep Agents 为代表的“可产品化代理 harness / server”路线；另一条是以 Claude Code / Claude Agent SDK 与 Codex CLI / Codex Web 为代表的“厂商托管或半托管编码代理”路线。它们在“能不能调工具”这一层已经高度趋同，真正拉开差距的是执行环境、权限边界、多租户能力、可观测性、供应商锁定程度，以及是否把“个人代理”做成真正长期驻留的系统。

若只看 GitHub 热度，OpenClaw 与 Hermes 极强；若看企业化落地、组织级部署与商业支持，Claude Code 目前最成熟；若看“可编排、可多租户、可部署成服务”的工程完整度，Deep Agents 的产品化路径最清晰；若看“云端异步任务 + 本地 CLI + GitHub code review”的一体化体验，Codex 的产品边界最鲜明。短期内不会出现单一胜者，更可能出现“个人代理层 + 协议层 + 托管执行层”分层组合。

更重要的结论是：这一赛道的核心竞争，正在从“谁更会写代码”转向“谁能把代理安全地长时间跑起来”。Hermes 以学习回路和持久化能力抢占“长期运行代理”心智；OpenClaw 以全渠道入口和个人控制面抢占“随处可发消息的个人代理”心智；Claude 与 Codex 则把优势押注在模型质量、托管基础设施和企业销售；Deep Agents 试图成为这些能力之间的中立工程层。未来 6–18 个月，协议收敛、运维安全、治理可持续性，会比模型分数更决定成败。

研究范围与判定框架

本报告将“Claude”具体化为 Claude Code 与 Claude Agent SDK；将“Codex”具体化为 Codex Web 与 Codex CLI；并把 OpenClaw、Hermes、Deep Agents 视为更开放的代理工程框架进行比较。官方入口分别为 文档、 Agent 文档、 Agents 文档、 Code 文档 与 文档。

比较维度分为九类：项目定位与维护状态、社区活跃度、采用信号、架构解耦度、可扩展性、权限与安全、可观测性、生态与商业支持，以及未来演化风险。需要特别说明的是，GitHub 的“总贡献者数”在若干仓库的公开 HTML 中并不稳定暴露；本次研究仅对 OpenClaw 拿到了明确总数，对 Hermes、Deep Agents、Claude Code、Codex 则只能给出“公开页面不可稳定提取”或“单个 release 的贡献者数量”。这不是数据不存在，而是公开页面抓取可见性有限。

项目现状与维护状态

从官方叙事上看，OpenClaw 已经从“单机上的个人 AI 助手”演化成“自托管、多聊天渠道、多代理、多插件的 Gateway 控制面”；Hermes 则从一开始就把自己定义成“会成长的代理”，并把学习回路、技能演化、记忆与长期运行作为核心卖点；Deep Agents 明确把自己叫做 “agent harness”；Claude 的工程表面是 Claude Code / Agent SDK；Codex 则是典型的“本地 CLI + 云执行 + GitHub code review + IDE extension”的产品组合。

系统	简述与主要目的	首次公开 / 已知起点	当前维护状态	GitHub 公开指标	备注与来源
OpenClaw	自托管 Gateway，把 WhatsApp、Telegram、Discord、Slack、Signal、iMessage 等渠道连接到 AI 代理；更像“个人代理控制面”而不是单一 IDE 助手	前身“Clawd / Clawdbot”始于 2025 年 11 月，2026-01-29 以 OpenClaw 名义公开叙事	活跃；2026-05-07 最新 release，仓库与组织页 2026-05-09 仍在更新	370k stars、76.4k forks、1.8k watchers、139 releases、2,014 contributors、43,352 commits
Hermes Agent	自我改进型长期运行代理，强调学习回路、记忆、技能演化、消息网关与 API server	Nous 官方 release 列表给出的发布时间为 2026-02-25	活跃；2026-05-07 发布 v0.13.0，“Tenacity Release”	139k stars、21.5k forks、531 watchers、12 releases、7,774 commits；最新大版本说明含“295 community contributors（含 co-authors）”但非总贡献者数
Deep Agents	面向复杂任务的 agent harness，强调 planning、filesystem、subagents、memory、sandboxes 与生产化部署	于 2025-07-30 发布官方介绍	活跃；2026-05-08 发布 deepagents 0.5.8，近期还持续发 CLI / ACP 相关包	22.5k stars、3.2k forks、115 watchers、123 releases、1,761 commits、156 issues
Claude Code / Claude Agent SDK	厂商闭环的 agentic coding 系统与可编程 SDK，强调 IDE/CLI/Web 多表面与企业部署	Anthropic 官方称 Claude Code 于 2025-05 GA；Agent SDK 在 2026 年成为官方主工程面之一	极活跃；2026-05-09 发布 v2.1.137；Agent SDK Python 仓库亦在 2026-05-09 更新	Claude Code 仓库 122k stars、20.1k forks、760 watchers、5k+ issues、530 PR、619 commits；Agent SDK Python 仓库 6.8k stars、965 forks、121 issues
Codex	的编码代理体系：本地 CLI、云任务、GitHub review、IDE 与浏览器扩展	OpenAI 于 2025-05-16 正式介绍 Codex；CLI 仓库创建于 2025-04-13	极活跃；2026-05-08 发布 0.130.0	81k stars、11.7k forks、458 watchers、3.7k issues、375 PR、778 releases、6,331 commits

从维护节奏看，Claude Code、Codex 与 Deep Agents 都已经进入“高频小版本”节奏：Claude Code 在 2026-05-08 到 2026-05-09 内连续出现新版本，Codex 在 2026-05-08 发布 0.130.0，Deep Agents 同一日同时推进主包与 CLI 包；Hermes 和 OpenClaw 则维持“相对低频但体量更大的版本包”。这意味着前两类更像 SaaS / 产品节奏，后两类更像快速演化中的平台节奏。

官方时间线可以概括为：Codex 最早完成“产品 + 开源 CLI”的组合；Deep Agents 在 2025 年中后期把“deep agents”概念工程化；Claude Code 在 2025 年下半年补齐 Web、IDE、checkpoint、skills、插件等工程表面；OpenClaw 于 2025 年末爆发，2026 年初完成品牌重塑；Hermes 则在 2026 年初迅速接棒，主打“比 OpenClaw 更长期、更多记忆、更能自我改进”的定位。

社区活跃度、采用与舆情

如果只看 GitHub 爆发力，OpenClaw 是这一组里最极端的案例：370k stars、76.4k forks、2,014 contributors、20.8k GitHub 组织 followers，远超其他开源代理框架，而且官方站点持续展示跨邮箱、日程、部署、语音和多代理 orchestration 的 showcase。Hermes 的速度也非常惊人，官方 X 账号称其为 Nous 历史上增长最快的项目；其仓库也在短时间内积累到 139k stars。Deep Agents 的热度明显低于 OpenClaw/Hermes，但在“工程人群”中更像高信号项目：21k+ stars 对一个偏基础设施仓库已属强势。

采用信号上，开源项目和厂商产品的质量差异非常明显。OpenClaw 官方能证明的是 50+ integrations、丰富部署路径与活跃 showcase，但没有公开稳定的“组织部署数量”或“活跃用户数”；Hermes 官方能证明的是 OpenAI-compatible API server、多个前端兼容、Telegram/Discord/Slack/WhatsApp/Signal/Email 等渠道、以及从 OpenClaw 迁移的明确路径，但同样缺少组织级 deployment 数字。Deep Agents 虽无公开大规模用户数，但 LangChain 官方明确声称其已被 OpenSWE 和 LangSmith Fleet 用于生产。相比之下，Claude Code 与 Codex 都已经给出更接近企业采用的公开案例。

系统	可观察的采用信号	生态 / 集成信号	缺失或模糊数据
OpenClaw	官方站点展示 50+ integrations、多个 showcase、VPS/Kubernetes/Fly.io/Hetzner/GCP/Azure/Railway/Render/Northflank 等部署路径	多聊天渠道、ClawHub、插件、OpenResponses API、MCP bridge	无公开企业客户名单、无公开活跃用户数
Hermes	OpenAI-compatible API server 可接 Open WebUI、LobeChat、LibreChat、AnythingLLM、NextChat、Jan、HF Chat-UI；支持多 profile 多实例	多模型、MCP、skills、cron、voice、gateway、community WeChat bridge	无官方企业部署数；总贡献者数公开页未稳定暴露
Deep Agents	LangChain 官方称其已用于 OpenSWE 与 LangSmith Fleet；可通过 deepagents deploy 上 LangSmith managed cloud	ACP、A2A、MCP、sandboxes、LangSmith tracing / evaluation / deployment	缺少公开客户名单与用户规模
Claude Code / Agent SDK	Anthropic 官方列出广泛组织级案例：、、、；另称 Claude Code 在 2025-11 达到 10 亿美元 run-rate revenue	Microsoft Foundry、Xcode、GitHub Action、多语言 SDK、Web/IDE/CLI/桌面多表面	许多效率收益由官方披露，外部独立复核相对有限
Codex	OpenAI 官方列出早期设计伙伴：、、、	GitHub 代码审查、Codex CLI、MCP、AGENTS.md、IDE extension、Chrome extension	企业大规模 rollout 数字尚少；最强案例仍偏“设计伙伴”阶段

社区情绪方面，OpenClaw 是“热情与怀疑并存”最强的一例。一边是 ClawCon 等线下社区活动、超强 GitHub 爆发和官方展示的大量 demo；另一边是 Reddit 上直接质疑其热度是否有机、真实日常使用是否足够广泛，以及媒体持续放大的安全与越权问题。换言之，OpenClaw 的口碑不是“稳健成熟”，而是“强势出圈但高争议”。

Hermes 的社区情绪更像“兴奋中的工程焦虑”：正向面是官方称其为增长最快项目、文档强调从 OpenClaw 迁移、release notes 里出现高密度社区贡献；负向面则是 Windows 仍处早期 beta、issue 量很高，说明它在快速吸纳需求，也在快速积累支持债务。它的口碑目前更像“最值得试的新平台”，而不是“已经稳定下来的一线生产平台”。

Deep Agents 的 sentiment 相对冷静。官方文档和博客非常坦率地把自己描述成 harness，强调生产化、multi-tenancy、sandboxes 与 observability；Hacker News 讨论中则有人认为“deep agents 仍然是 agents + tools 的系统化打包”。这其实不是负面——它恰恰说明 Deep Agents 受欢迎的根源不是魔法，而是工程抽象。

Claude Code 的舆情总体最强，但也最容易引发“闭源栈不透明”的反馈。正向面是 Anthropic 给出的组织级部署和生产率案例极强；反向面是开发者论坛与 HN 上对速率限制、缓存 TTL、隐藏改动与可预期性的抱怨并未消失。也就是说，Claude 的主要风险不是“能力不够”，而是“平台政策变动是否可预测”。

Codex 的 sentiment 更接近“产品成型很快，但仍在补通用 IDE 体验”。官方在最初发布时就承认其暂时缺少图像输入与中途纠偏能力；OpenAI 社区近期则出现“希望 Codex App 更像 Cursor、内置完整编辑器”的需求，说明用户已不满足于“后台跑任务”，而在追求更强的人机协作界面。

技术架构对比

最核心的架构分野，不在“工具调用”本身，而在“代理在哪里跑、以什么权限跑、是否天然支持多人多环境、多长时间能持续跑”。OpenClaw 的中心概念是 Gateway：它把渠道、会话、路由与多代理绑定统一到一个控制平面；Hermes 则把 CLI、gateway、API server、memory、skills、cron、voice 放进同一长期运行代理里；Deep Agents 把代理定义成 harness，再用 backend / middleware / profiles / sandboxes 拼成可部署服务；Claude Agent SDK 基本复用 Claude Code 的同一 agent loop，但生产部署要自己补 API/auth/streaming；Codex 则明显走“本地 CLI + 云容器任务 + GitHub / IDE 外壳”的产品架构。

维度	OpenClaw	Hermes Agent	Deep Agents	Claude Code / Agent SDK	Codex
核心控制面	Gateway 为单一事实源，负责 session / routing / channels	长驻 agent + gateway + API server + profiles	Harness + backend + middleware + agent server	Claude Code 产品面 + Agent SDK 编程面	本地 CLI 与云环境双表面
模型耦合	低；支持 OpenAI、Anthropic、OpenRouter、vLLM 等，且可用 Codex subscription / Claude CLI	低；号称可接任何 OpenAI-compatible API	很低；文档明确支持任意 provider，backend / deploy / model 可独立选择	中高；以 Claude 为中心，可通过 Bedrock / Vertex / Foundry 或兼容网关接入	高；围绕 OpenAI / Codex 体系构建
可扩展性	插件、skills、channels、OpenResponses、MCP bridge	skills、MCP、API server、providers、cron、voice	middleware、skills、memory、subagents、ACP/A2A/MCP、custom backends	hooks、skills、plugins、subagents、MCP、custom tool handlers	MCP、skills、AGENTS.md、Agents SDK 互操作、plugins
多租户 / 多实例	偏个人或小团队；支持多 agent、多 account	通过 profiles 可以做隔离，但更像“多实例”	内建 scoped threads、per-user sandboxes、RBAC，最接近 SaaS 级	SDK 自托管，multi-tenant 需自行搭	云任务天然隔离，但不是通用多租户 harness
安全默认值	DM pairing、allowlists、audit CLI；但 native plugins in-process、非沙箱	command approval、DM pairing、container isolation；Redaction 默认开启	明说 “trust the LLM”，边界靠 sandboxes / permissions / HITL	allow/ask/deny、permission modes、默认谨慎、secure deployment 指南	云容器隔离、审批与网络控制、agent internet 默认关闭
可观测性	dashboard、doctor、security audit、token/accounting	doctor、dashboard、insights、API capabilities	LangSmith tracing / eval / deployment 最强	streaming events、sessions、hooks，但平台级 tracing 不如 LangSmith 成熟	app-server、GitHub review、OpenTelemetry 元数据、云任务进度
最佳场景	个人代理、消息驱动、跨终端入口、家用 / 自托管	长期运行代理、记忆和技能积累、低锁定、混合本地/云	面向最终用户的代理产品、B2B SaaS、可运维服务端	企业编码代理、Anthropic 栈、IDE / CLI / Web 一体化	安全云任务、GitHub 工作流、OpenAI 栈编码协作
主要来源

几个关键技术观察值得单独强调。第一，OpenClaw 与 Hermes 都已经不是“聊天机器人”，而是“长驻控制面”：OpenClaw 把多聊天渠道和 agent session 变成路由问题；Hermes 则把 API server、cron、voice、memory、kanban 都纳入一个长驻代理进程。第二，Deep Agents 是这组里最明确的“解耦派”：它把 model、backend、sandbox、deployment 全都拆开，代价是用户要承担更多组装；而 Claude / Codex 是“集成派”：默认路径明显更顺滑，但供应商耦合更强。

第三，跨项目正在出现明显的协议收敛。OpenClaw 有 OpenResponses 兼容 endpoint 与 MCP bridge；Hermes 有 OpenAI-compatible API server 与 MCP；Deep Agents 把 MCP、ACP、A2A 都写进官方部署面；Claude Code 把 MCP、skills、plugins、subagents 做成一等公民；Codex 则同时支持 MCP 和 AGENTS.md，并能作为 Agents SDK 的 MCP server。换句话说，未来的竞争大概率不会是“谁先支持 MCP”，而是谁能把这些协议组合成更可靠的系统。

优势、短板与典型场景

OpenClaw

OpenClaw 的最大优势不是模型，而是入口和控制面。它把“发消息给代理”这件事做成了真正多渠道、低摩擦、随身化的体验：任何聊天 app、Web control UI、mobile nodes、browser dashboard 都是它的前端，而 Gateway 是统一后端。对想把代理做成“个人操作系统”而不是“IDE 辅助插件”的用户，这个架构非常有吸引力。它还具备多 agent、memory、dreaming、skills、OpenResponses endpoint 和 MCP bridge，技术面并不浅。

它也有最明显的系统性短板：第一，native plugin 明确是 in-process、非 sandbox，插件一旦恶意或失误，本质上等于在 Gateway 进程内执行任意代码；第二，OpenResponses endpoint 默认就是“operator-level”能力，配置不当即扩大暴露面；第三，项目爆发太快，安全、治理、文档和用户教育都面临压力。适合的场景，是个人自托管、消息驱动自动化、多终端个人代理；不适合的，是要求强多租户隔离、强企业审计和清晰供应商支持边界的 B2B 平台。

Hermes Agent

Hermes 的独特价值在于它对“代理会成长”这件事做了系统工程化，而不是只停留在营销口号。官方文档与 README 都把学习回路、procedural memory、skills、persistent memory、past conversations、voice、cron、API server 和 kanban 多代理板统一到一个长期运行系统里。与 OpenClaw 相比，它在“长期驻留代理”的主张更强，也更明确把 API server / frontend compatibility 当成一等能力。

Hermes 的问题则是“快”和“深”带来的复杂度：其 issue / PR 体量高，Windows 仍属早测，安全加固仍在快速推进；API server 直接暴露 terminal toolset，若绑定到公网且配置宽松，风险很高。对工程师来说，Hermes 适合想运行 24/7 个人代理、想积累技能和记忆、又不想被单一模型厂商绑定的场景；但它还没有像 Deep Agents 那样，把“多租户 B2B 产品化”作为第一优先级。

Deep Agents

Deep Agents 的强项，是工程抽象干净且面向生产。它的官方文档公开承认自己是 harness，而非“神奇智能体”，这反而让其边界更清晰：planning、filesystem、subagents、memory、sandboxes、human-in-the-loop、permissions、profiles、deploy、LangSmith tracing / eval / deployment，都是围绕“怎样把代理做成服务”来组织的。和 Claude Agent SDK 的官方对比页甚至直接把 multi-tenancy、sandbox-per-user、RBAC、agent server、managed/self-hosted 双模式写成决定性卖点。

它的短板也很明确：第一，它对最终用户而言不如 OpenClaw/Hermes 有“人格”和入口魅力；第二，它在默认安全哲学上非常直接——“trust the LLM”，本质上要求你把安全边界下沉到 sandbox 和 tool 层；第三，其优势高度依赖 LangChain / LangSmith 生态。如果团队不准备引入这套生态，Deep Agents 的价值会缩水。它最适合产品团队、平台团队、B2B 代理服务，而不是单一开发者寻找一个“现成能聊能跑”的个人代理。

Claude Code 与 Claude Agent SDK

Claude 的最大优势是“模型质量 + 产品表面 + 企业支持”三者同时在线。官方页面给出了强组织级案例，覆盖大规模工程师部署、incident response、跨语言大规模迁移、并行会话开发等；文档则显示它已经把 terminal、IDE、desktop、web、plugins、subagents、hooks、MCP、skills、permissions 几乎全部打通。对于已经采用 Claude 模型或在 生态内的团队，它是当前最省工程力的企业级编码代理路线之一。

它的代价，是结构性 vendor coupling。虽然 Claude Code 支持 Bedrock、Vertex、Foundry 等第三方 provider 表面，但能力依然围绕 Claude 的 agent loop 与 Anthropic 的产品面组织；用 Agent SDK 自建服务时，API server、auth、multi-tenant layer 仍要自己补。再加上 HN / 社区中对速率限制和“隐形变更”的担忧，Claude 的风险主要不是“做不到”，而是“平台策略和边界由厂商决定”。适合的，是企业编码代理、内部工程平台、重视交付速度且接受厂商平台依赖的团队。

Codex

Codex 的优势是“托管执行”这件事做得最产品化。官方文档非常清楚：云端任务在隔离容器内执行，agent 阶段默认无互联网，GitHub review、cloud environments、IDE extension、MCP、AGENTS.md、Chrome extension、CLI、app-server 形成一个完整闭环。这种组合特别适合把“一个耗时但范围清晰的编码任务”外包给后台代理。

它的短板是可定制度低于 OpenClaw / Hermes / Deep Agents，且其体验仍明显朝 OpenAI 平台靠拢。OpenAI 自己在最初发布时就承认 Codex 仍缺图像输入、缺中途纠偏；后续 release 和论坛又显示它在向 remote-control、plugin、app-server、更丰富 UI 方向补齐。这很像一个“产品演化速度很快、但暂时还不是中立框架”的系统。适合的，是 OpenAI 栈、GitHub-heavy 工作流、异步代码任务委派，而不适合想自己定义 agent runtime 与长期状态机的团队。

生态、商业支持与未来情景

商业支持层面，目前最强的是 Claude 与 Codex。Claude 已进入官方多语言 SDK、GitHub Action、Xcode、Microsoft Foundry 以及 web / IDE / terminal 多表面；Codex 则同时覆盖 ChatGPT plans、CLI、GitHub review、cloud environments、Chrome extension 与 Agents SDK 互操作。它们最大优势不是星数，而是销售、计费、托管资源和企业渠道。

开源路线里，Deep Agents 的商业支撑最清晰，因为它与 LangSmith managed cloud、LangSmith tracing/evals/deployment 深度耦合，具备明确的商业“落点”。Hermes 与 OpenClaw 的生态更偏社区和自托管：前者有 provider、frontend、paperclip adapter、voice、skills hub、community bridge；后者有 ClawHub、插件架构、广泛部署指引与社区 sponsors。但这类项目也最容易遭遇“超高速增长 + 维护者压力 + 安全外部性”的组合风险。

未来 6–12 个月，最可能发生的不是某一项目“统治市场”，而是协议层收敛与产品层分层：MCP 会继续成为工具连接的底层共识；OpenResponses / OpenAI-compatible API 会成为代理前端互通的事实接口；Skills / SKILL.md / AGENTS.md 会成为项目上下文与可复用能力的显式载体；ACP/A2A 则会在 editor / agent / service 之间争夺更上层的话语权。谁能把这些协议变成可运维、可审计、可恢复的 runtime，谁就更可能赢。

未来 12–24 个月的主要风险有四个。第一，安全反噬：OpenClaw 的 in-process plugin 风险、Hermes / Claude / Codex 的终端与浏览器权限、Deep Agents 的 “trust the LLM” 哲学，都意味着一旦代理从“写代码”扩展到邮箱、支付、日程和浏览器，任何越权事故都会显著改变用户和企业态度。第二，治理与可持续性：OpenClaw、Hermes 这类爆发式 OSS 一旦维护者结构失衡，很容易进入文档债、issue 债和安全债叠加状态。第三，标准碎片化：MCP 外围很可能统一，但技能、工作流、agent-to-agent 通信未必会统一。第四，热度回落：如果“代理做酷炫 demo”无法转化为稳定 ROI，GitHub 热度会先于真实工程价值回落。

建议与结论

对工程师而言，若目标是“把代理带到 Telegram / WhatsApp / Signal / iMessage，并随时能发消息叫它做事”，OpenClaw 与 Hermes 比 Claude / Codex / Deep Agents 更合适；两者中，OpenClaw 更强在渠道与控制面，Hermes 更强在长期记忆、自我改进与长驻代理心智。若目标是“做一个面向用户的代理产品”，优先考虑 Deep Agents；若目标是“尽快让团队获得强编码代理收益”，优先试点 Claude Code，其次是 Codex。

对产品经理而言，最重要的不是选“最热的代理”，而是先定义代理边界。消息入口、IDE 入口、GitHub 入口、Web dashboard 入口，代表的是完全不同的用户心智。OpenClaw / Hermes 天然适合“持续陪伴型代理”；Claude / Codex 天然适合“任务委派型编码代理”；Deep Agents 天然适合“你要把代理包装成一个服务”。如果入口选错，再强的模型也会把系统做成错误的产品。

对决策者而言，建议采用“三层决策法”。底层先决定是否接受厂商锁定；中层决定是否需要多租户、审计、Tracing 与部署平台；顶层再决定最终用户入口。若能接受强厂商耦合并希望快速见效，Claude / Codex 是最短路径；若需要自托管与用户数据控制，OpenClaw / Hermes 更自然；若要在企业内部落成一个长期可运维的代理平台，Deep Agents 的工程重心最匹配。真正应该避免的，是把“个人代理框架”直接当成“企业级代理平台”，或把“厂商编码产品”误当成“中立 agent runtime”。

综合判断如下：
OpenClaw 是最强的“个人代理控制面”；Hermes 是最激进的“长期运行 / 自我改进代理”；Deep Agents 是最清晰的“产品化 harness”；Claude Code / Agent SDK 是当前最成熟的“企业编码代理栈”；Codex 是产品化最强的“云任务 + 本地 CLI 编码代理”。它们不是同一种东西，因此也不应该被用同一套标准简单排名。若必须给一句最有操作性的结论：个人代理优先看 OpenClaw / Hermes；平台化优先看 Deep Agents；企业编码落地优先看 Claude Code，OpenAI 栈则看 Codex。

开放问题与局限

本次研究的主要局限有三点。第一，Hermes、Deep Agents、Claude Code、Codex 的“总贡献者数”在公开 GitHub HTML 中未稳定暴露，因此未给出与 OpenClaw 同等粒度的 contributor 总数；Hermes 仅能引用单个 release 的“295 community contributors（含 co-authors）”。第二，OpenClaw 与 Hermes 的组织级用户数和生产部署规模，官方没有给出可独立核验的总量数据，因此只能基于 integrations、frontends、showcase 和 release/activity 做近似判断。第三，论坛 / Reddit / HN 的情绪信号是重要风向标，但并非统计代表性样本，不能替代系统性用户研究。