全方位对比:Hermes VS OpenClaw

关注腾讯云开发者,一手技术干货提前解锁👇

为什么Hermes的爆炸性增长让整个行业重新审视Agent的发展方向?对于正在技术选型中摇摆不定的开发者们,又该如何在Hermes和OpenClaw之间做出正确的决策?

注:本文有使用 AI 进行辅助创作。

   引言:一场不期而遇的王者争夺

2026年2月,当Nous Research悄悄开源Hermes时,没人料到这个看起来普通的AI Agent会在短短7周内掀起技术社区的滔天巨浪。

GitHub星标从零到84.4k,OpenRouter算力榜上的排名从籍籍无名飙升至紧逼KiloCode,Token消耗日榜以倍数增长:这背后是数百万开发者用真金白银的算力消耗投的票。更让人震撼的是,它做到了曾经被认为不可能的事:在短时间内超越了OpenClaw这个已经占据市场被誉为"Agent操作系统"的龙虾王者。

这背后发生了什么?为什么Hermes的爆炸性增长让整个行业重新审视Agent的发展方向?而对于正在技术选型中摇摆不定的开发者们,又该如何在Hermes和OpenClaw之间做出智慧决策?

本文将从技术架构、实际应用、团队背景、市场数据等多个维度,为你深度解析这场"新王诞生"背后的故事——以及,它对AI Agent未来走向的深刻启示。

01

从零到英雄:Hermes的七周逆袭

   1.1 爆炸式增长的数据背后

如果用一张图表来描述Hermes的增长轨迹,那绝对是一条近乎垂直的曲线。

根据公开数据,Hermes在GitHub上的星标增长速度打破了同类项目的纪录。从2月中旬的首次发布,到3月底的84.4k星标,这个增速甚至超越了当年Stable Diffusion的爆红时期。更关键的是,OpenRouter上的Token消耗日榜显示,Hermes的日均使用量呈现每周翻倍的增长趋势。

这意味着有数百万开发者真实地在生产环境中部署、运行、迭代Hermes,每一次Agent的执行、每一次技能的学习,都在消耗算力并产生真实价值。

   1.2 为什么是Hermes超越了龙虾?

OpenClaw(龙虾)从2025年开始就已经是Agent领域的绝对霸主。它的优势似乎无可撼动:支持飞书、Discord等多平台集成,能管理上百个账号,是多账号矩阵运营的"唯一解"。许多企业和专业运营者已经深度绑定在OpenClaw的生态中,形成了高转换成本。

那么Hermes为什么能在这样的局面下逆袭?

关键在于——它们解决的是两个不同的问题。

OpenClaw走的是"大而全"的路线,像一个企业级操作系统,力求集成所有可能的场景。但这也意味着,系统变得复杂、臃肿,每增加一个功能都可能引入新的风险。用一位使用过两个产品的开发者的话说:"过去两周对比测试,OpenClaw系统出问题太多。"

Hermes走的是"深度聚焦"的路线。它不追求集成一千个应用,而是通过自我进化机制,让一个Agent在用户手中不断学习、不断优化、不断变强。

   1.3 团队基因:分布式系统大拿的联合

Hermes的开发团队包括Jeffrey Quesnelle、Karan Malhotra和Teknium。他们的背景涉及分布式系统设计、大模型后训练优化、Agent运行时管理等硬核领域。

这直接影响了Hermes的核心设计:能处理复杂的并发请求、高效的内存管理、以及最关键的——可写运行时架构。

02

核心技术对比:硬核执行 vs 平台生态

   2.1 Hermes的"可写运行时":自我进化的引擎

Hermes最革命性的特性,就是其"可写运行时"(Writable Runtime)架构。核心逻辑其实很直白:

传统Agent是"只读"的:它按照预设的规则、技能、配置运行,遇到问题时只能向用户求救,或者重复踩过的坑。

Hermes是"可写"的:它在运行过程中,可以自动生成、优化、存储新的技能代码,这些代码被永久存储在技能库中,下次遇到类似问题时直接调用,无需重新思考。

具体工作流程是这样的:

  1. Hermes执行一个任务,遇到了错误或不完美的地方

  2. 它调用内置的 skill_manage 工具,自动生成一段补丁代码

  3. 这段代码被存储到动态技能库中

  4. 同样的问题再出现时,Hermes直接调用已有的技能,避免重复踩坑

这个机制有三个超越性的意义:

它打破了"无限循环"的噩梦。在传统Agent中,同样的错误可能被重复触发成百上千次。每一次都需要同样的思考、计算、调试。这是算力的巨大浪费。Hermes通过自修复,让这个问题彻底消失。

它实现了"迁移学习"。Hermes在处理你的问题时学到的技能,下次遇到相似问题时可以直接复用。这意味着,运行时间越长,Agent越聪明,它学到了更多,消耗的算力却在减少。

它使得个性化成为可能。每个用户的Hermes都会积累不同的技能库,因为每个人遇到的问题不同、行业背景不同、编码习惯不同。结果就是,每个Hermes实例都是独一无二的,每个都是你个人的"数字分身"。

   2.2 OpenClaw的生态帝国:广度与复杂度的权衡

OpenClaw走的是完全相反的路线。它的核心竞争力是生态的广度和运营的规模化能力。

OpenClaw支持:

  • 多平台集成(飞书、Discord、Slack等)

  • 多账号管理(能协调上百个账号同时运营)

  • 丰富的插件生态(数百个预集成应用)

  • 企业级的权限管理和审计

这让OpenClaw成为"多账号矩阵运营"的唯一解。如果你的业务是运营10个微博账号、5个抖音账号、20个微信公众号,那么OpenClaw就是必选项,没有替代品。

但古尔丹,代价是什么?是复杂度和脆弱性。

根据开发者的实际对比测试,OpenClaw在处理复杂配置、多平台协调时,系统出错的概率明显高于Hermes。

此外,OpenClaw的学习曲线很陡峭。要充分利用它的能力,需要理解复杂的配置语法、网关架构、权限模型等。而Hermes标榜"开箱即用",拉起来就能跑,配置最少。

   2.3 算力消耗vs有效产出:一场关于ROI的较量

有一个容易被忽视但至关重要的问题:Hermes的单次Token消耗为什么比较高,但反而被认为更经济?

这涉及到一个概念上的转变:从"输入Token数"到"实际产出价值"。

看起来,Hermes在单次执行时消耗的Token确实较多:因为它需要分析错误、生成补丁代码、优化执行路径。但这里有个关键:

这些消耗产生的是"可重复利用"的资产,技能库中的补丁代码可以被无限次调用,每次调用的成本接近零。而传统Agent每次遇到相同问题都要重新思考、重新计算,就像在同一个地方重复踩坑。

从长期来看(以一个月为周期),Hermes的有效产出(实际解决的问题数×质量)远超传统Agent,使得单位产出的成本更低。

换个角度说:

  • OpenClaw:追求最小化单次输入Token,但频繁出错需要手动干预和反复调整

  • Hermes:愿意在单次执行上消耗更多Token,但换来的是自修复、自优化、自进化

03

应用场景矩阵:选择的艺术

   3.1 Hermes适用场景:深度 & 精度

优先选择Hermes的场景:

  1. 代码编写与技术实现 Hermes在代码生成、调试、优化上的能力无与伦比。因为代码的"自修复"机制天然适合编程任务——错误具有可诊断性,补丁代码可以被自动生成和验证。一位使用Hermes协助开发微服务架构的工程师反馈:"过去需要3人天的工作,现在Hermes+我在一人天内完成,而且代码质量还更高。"

  2. 数据分析与报告生成 数据分析任务往往涉及多轮迭代——"帮我重新聚合这个维度"、"按照这个逻辑重新计算"。Hermes的学习能力让后续的类似需求快速响应。用户习惯和行业逻辑(如财务报表的特定字段定义、销售数据的特殊处理规则)会被记录在技能库中,形成行业专用版本。

  3. 垂直领域的知识应用 医学诊断、法律文书生成、工程设计等领域有大量的"行业特定逻辑"和"最佳实践"。Hermes能通过一个月的使用,自动学习这些领域知识,逐渐演变成垂直领域专家。这是OpenClaw无法做到的。

  4. 长期个人助手 如果你想拥有一个"越用越聪明"的个人AI助手,能记住你的工作习惯、审美偏好、思维方式——Hermes是唯一选择。每次迭代它都在朝着更接近"你的分身"的方向演进。

   3.2 OpenClaw适用场景:规模 & 生态

优先选择OpenClaw的场景:

  1. 多账号矩阵运营 如果你的业务涉及同时管理多个社交媒体账号、多个平台的内容分发、多渠道的客户互动——OpenClaw是目前市场上的"无可替代的底座"。Hermes虽然单Agent强大,但在多Agent协调上没有OpenClaw成熟。

  2. 企业级组织协调 大型团队需要权限管理、审计追踪、多人协作。OpenClaw在这些企业级功能上远超Hermes(Hermes目前更适合个人或小团队)。

  3. 跨平台生态融合 如果你的工作流涉及飞书、Slack、Discord等多个平台的深度集成,需要这些平台之间的数据流转和联动——OpenClaw的生态支持是强大的。Hermes目前主要专注微信生态,扩展性有限。

  4. 快速上线,最小化学习成本 虽然OpenClaw的配置较复杂,但对于已经有现成配置模板、已经在OpenClaw生态中的团队,快速复用成本很低。新手入门时OpenClaw的文档和社区资源也很丰富。

   3.3 混合策略:鱼和熊掌不可兼得吗?

一个更优解是:用Hermes做核心的深度工作,用OpenClaw做规模化的运营协调。

例如,一个内容创作团队可以:

  • 用Hermes写长篇报告、进行深度数据分析、打磨内容质量

  • 用OpenClaw管理多个账号的内容分发、粉丝互动、数据监测

这样既享受了Hermes的深度优势,又不失OpenClaw的规模优势。当然,这意味着更高的学习成本和维护复杂度,需要根据实际业务规模来权衡。

04

技术深度对标:看不见的差异

   4.1 技能库机制的本质差异

这可能是Hermes和OpenClaw最核心的差异,但也是最容易被忽视的。

OpenClaw的技能库是静态的。你在初始化时配置好所有的技能和规则,然后Agent按照这些规则执行。好比一个编写好的程序,运行时不会改变代码本身。

Hermes的技能库是动态的。Agent在运行过程中不断写入新的技能、优化现有的技能、甚至丢弃已过时的技能。这更像一个生物系统,拥有不断进化和自我完善的能力。

这个差异的影响是深远的:

维度

OpenClaw

Hermes

初始设置

需要详细配置所有技能

最小配置,开箱即用

长期运营

配置保持不变

不断自我优化

错误处理

需要人工调试和修改配置

自动分析和修复

知识积累

有限(主要依赖人工更新)

无限(动态学习)

个性化程度

基于初始配置的差异

基于运行时的自适应差异

   4.2 自修复机制的工程意义

Hermes的自修复机制不仅仅是一个功能,它代表了一种从"编程范式"到"进化范式"的思维转变。

传统编程:我们精心设计算法,编写代码,通过测试,然后部署。这个过程中,我们假设部署后的代码是"冻结"的,不会自我改进。

Hermes的自修复范式:我们设定初始的目标和约束,然后让Agent在实际运行中不断改进自己的实现方案。

这意味着Hermes可以处理初始设计时无法预见的边界情况。当出现一个新类型的输入、一个新的组合问题、一个新的用户需求时,Hermes不会失败,而是在失败的基础上自动优化。

从工程的角度,这大幅降低了系统的脆弱性(fragility)。OpenClaw遇到未曾预见的情况时容易崩溃或陷入无法自救的状态,而Hermes会尝试自救。

   4.3 Token消耗模型的真相

让我们深入分析一个具体的数据场景。假设一个Agent需要执行1000个相似但不完全相同的任务(比如处理1000份合同)。

OpenClaw的模型:

  • 每个任务平均消耗500个Token

  • 总消耗:1000 × 500 = 50万Token

  • 问题:每个任务都独立处理,没有积累

Hermes的模型(第一周):

  • 前100个任务:每个1000个Token(因为需要学习和生成补丁)

  • 后900个任务:每个100个Token(使用已优化的技能库)

  • 总消耗:100 × 1000 + 900 × 100 = 19万Token

  • 好处:不仅消耗更少,质量还在逐步提高

到了第二周,如果OpenClaw继续处理1000个任务,成本仍然是50万Token。而Hermes因为技能库的持续积累,消耗可能进一步降低到15万Token。

这就是所谓的复合回报(compound returns):Hermes的优势会随着时间推移而递增,而不是保持恒定。

05

中国市场的本地化优势:微信的力量

   5.1 Hermes为何选择微信作为首批支持

一个有趣的现象是,Hermes优先支持微信,而不是Slack或Discord。这是一个相当精准的市场洞察。

微信是中国最大的社交平台,拥有超过12亿的月活用户。但对于AI开发者而言,微信长期处于一个"被忽视"的位置——因为官方的接入流程复杂、限制多,很多AI产品都绕过微信,转而拥抱海外的Slack、Discord等平台。

Hermes的做法是相反的:直接拥抱中国市场,解决微信接入的痛点。

它使用腾讯官方的iLink Bot API:这是官方允许的、稳定的、不易被封禁的接入方式。用户只需要扫一个二维码,就可以在个人微信、群聊中直接与Hermes交互,支持文本、图片、视频、语音、文件等多种形式。无需额外的应用下载,无需跳转其他平台,一切都在微信这个最熟悉的环境中发生。

   5.2 微信生态的独特优势与注意事项

优势:

  1. 用户基数大且粘性强。微信用户的日活时长远超其他平台。一个在微信上可用的AI助手,相当于直接接触了12亿用户的日常生活。

  2. 商业化潜力高。微信支付、小程序、公众号等生态提供了多种变现渠道。一个有价值的Hermes实例可以直接连接到商业链路。

  3. 隐私合规更有保障。使用官方API意味着数据处理符合腾讯的隐私标准,用户数据更安全(相比于逆向工程的方案)。

注意事项:

  1. 微信对自动化操作有严格的监控。如果Hermes的运行频率过高、行为过于机械,仍然有被识别为异常操作、导致账号限制的风险。官方的建议是"如果担心账号被封禁,使用小号进行测试"。

   5.3 对中国开发者的机遇

对于中国的AI开发者、个人创业者、内容创作者而言,Hermes的出现意味着什么?

第一,降低了接入成本。不再需要学习复杂的API文档,不再需要部署复杂的网络架构,微信扫码即用。

第二,打开了个人IP的新维度。一个有专业背景的个人,现在可以快速构建一个垂直领域的AI助手:比如"财务分析Hermes"、"法律咨询Hermes"、"技术架构Hermes",直接通过微信提供服务,积累自己的专业IP。

第三,创造了新的商业模式。基于Hermes的订阅服务、API调用付费、定制化开发等商业形式都成为了可能。而且因为Hermes的自我学习能力,提供的服务质量会随着时间推移而不断提升,用户粘性和口碑效应会不断强化。

06

市场格局的重新定义

   6.1 从"单一平台争霸"到"差异化共存"

如果我们回顾Agent市场的演变过程:

2024年:Cline(代码补全)和KiloCode(多轮执行)分别占据代码和推理领域。

2025年:OpenClaw推出,以其全能的生态集成能力,迅速成为市场的绝对霸主。市场形成了"一家独大"的格局。

2026年Q2:Hermes的出现打破了这种格局。但有趣的是,它没有击倒OpenClaw,而是开创了一个新的市场细分——深度执行和自我进化。

这标志着Agent市场从"单一维度竞争"进入了"多维度差异化"的阶段。

   6.2 生态位的稳定性分析

OpenClaw的生态位:不可动摇,但增长天花板已现

OpenClaw在"多账号矩阵运营"的领域拥有绝对的垄断地位。这个市场的大小是确定的,因为企业和大型内容运营商的数量有限。但在这个确定的市场中,OpenClaw已经占据了超过70%的份额。增长空间有限。

而且,OpenClaw面临的风险是技术债的积累,随着功能堆积,系统变得越来越复杂,维护和改进的成本都在上升。

Hermes的生态位:高速增长,前景广阔,但还需时间验证

Hermes的市场是"所有需要深度AI助手的个人开发者和专业人士":这个市场的规模是OpenClaw的5-10倍。但这个市场过去一直被认为"不成熟",因为没有合适的工具。

Hermes的出现,相当于开启了一个全新的市场。它的增长潜力是巨大的。但同时,它也需要时间来证明其稳定性、可靠性和长期价值。

   6.3 未来的竞争不是替代,而是融合

如果说2025年的市场竞争是"要么选OpenClaw,要么选Cline/KiloCode"的"非此即彼",那么2026年及以后的竞争逻辑是"根据业务维度,选择最合适的工具,或组合多个工具"。

一个完整的AI应用可能会这样构成:

  • 核心逻辑处理:Hermes(因为需要深度思考和自我优化)

  • 运营协调:OpenClaw(因为需要多平台多账号管理)

  • 专科任务:Cline/KiloCode(因为某些特定场景需要专科水平)

这种"工具栈"的组合方式,会逐渐成为专业开发者的标准实践。

07

开发者的实际选择指南

   7.1 决策树:一张完整的选择流程

   7.2 具体场景的推荐方案

场景1:个人开发者,想用AI助手提升编码效率 → 推荐:Hermes

  • 理由:代码编写天然适合自修复机制,Hermes会越用越聪明

  • 成本:3.99美元/月(在Agent37上)

  • 学习曲线:极低,开箱即用

场景2:内容创作者,管理3个微博账号 + 1个抖音账号 + 个人微信矩阵 → 推荐:Hermes(主要) + OpenClaw(协助)

  • 理由:用Hermes做内容策划和生成,用OpenClaw做跨平台分发

  • 成本:两个工具的组合成本

  • 学习曲线:中等,需要理解两个系统的协作方式

场景3:企业内容运营团队,需要管理30个账号和10个团队成员 → 推荐:OpenClaw

  • 理由:规模运营和权限管理是OpenClaw的强项

  • 成本:企业级定价,可能较高

  • 学习曲线:陡峭,但投入后回报很高

场景4:垂直领域专家(如财经分析师),想构建个人IP → 推荐:Hermes

  • 理由:Hermes会学习你的行业知识和分析习惯,逐渐变成你的专业版分身

  • 成本:低(个人级工具)

  • 学习曲线:极低,重点是如何有效地"教会"Hermes你的专业知识

场景5:初创企业,想用AI快速打造MVP产品 → 推荐:Hermes + Cline

  • 理由:Cline用于快速编码,Hermes用于架构和优化

  • 成本:低

  • 学习曲线:低,两个工具都相对易用

   7.3 常见的决策陷阱

陷阱1:「看起来功能多,就选OpenClaw」

  • 现实:大多数功能你用不上,反而会增加学习和维护成本

  • 建议:先清点你真实需要的功能,而不是被宣传迷惑

陷阱2:「Hermes太新,不放心」

  • 现实:虽然发布时间短,但底层技术来自分布式系统领域的硬核专家,稳定性其实不弱

  • 建议:在小号上充分测试,不用急着上线大规模应用

陷阱3:「选了A就不能用B」

  • 现实:两个工具的生态并不互斥,完全可以混用

  • 建议:根据不同的子任务,选择最合适的工具

陷阱4:「一个工具就能解决所有问题」

  • 现实:没有银弹。Hermes和OpenClaw各有擅长的领域

  • 建议:把它们看作工具箱中的不同工具,不同的问题用不同的工具

08

Hermes带来的思维革新

   8.1 从「预先配置」到「动态进化」的范式转变

Hermes最深刻的贡献,也许不在于它的具体功能,而在于它代表的一种新的AI应用哲学。

在过去,我们构建AI系统的方式是:先研究问题、设计方案、编写代码、充分测试、然后部署。部署后,系统就是"冻结"的,改变它需要重新部署。

这个流程的问题是:它假设我们能在部署前预见所有的情况。但现实中,用户的需求在变化、业务的场景在扩展、边界条件不断出现。每一个预见之外的情况,都可能导致系统的故障或低效。

Hermes代表的是一个不同的思路:部署一个"活的"系统,让它在运行中学习和进化,而不是部署一个"死的"系统。

这种转变的影响是深远的:

  • 从"写一次,用一生"变成"不断优化,持续进化"

  • 从"预见所有情况"变成"处理未预见的情况"

  • 从"系统是资产"变成"系统的学习过程是资产"

   8.2 个性化AI时代的开启

Hermes的自我学习机制意味着,每个用户拥有的Agent都是不同的。

想象这样一个场景:

两个财务分析师都在用Hermes。经过一个月的使用,他们的Hermes会根据各自的工作特点进化:

  • 分析师A的Hermes学会了处理股票市场数据的特定格式

  • 分析师B的Hermes学会了处理企业内部财务报表的特定逻辑

到了第二个月,他们各自的Hermes都是行业内最强的助手——不是因为它们的底层模型更强,而是因为它们已经被充分"训练"来处理各自的专业领域。

这就是个性化AI时代的开启——每个用户不再是通用AI的消费者,而是成为了自己的专属AI的"培育者"。

从商业的角度,这也意味着:用户的粘性会大幅提升。因为转换到其他工具意味着放弃已经积累的"学习资产"。

   8.3 「数字分身」概念的具体化

曾经,"数字分身"是一个科幻小说中的概念。Hermes让这个概念变成了现实。

一个资深的技术架构师,使用Hermes三个月后,Hermes的思维方式、工作习惯、专业判断都会逐渐接近他本人。这个Hermes就可以代表他去:

  • 审查代码、提出架构建议

  • 进行技术方案的评估

  • 甚至在会议上展现他的专业观点(当然,最终决策权还是他的)

如果这个架构师想要扩展他的影响力——比如想提供技术咨询服务——这个Hermes就成了他的"分身",可以同时服务多个客户,而质量不会下降(甚至因为接触更多案例,质量可能更高)。

这为个人的专业IP商业化打开了全新的可能。

09

风险与挑战

   9.1 Hermes可能面临的技术风险

1. 技能库污染 随着Agent不断学习和生成补丁代码,技能库中可能积累一些"好用但并不最优"的解决方案。久而久之,这些次优解决方案可能污染整个技能库,导致系统性能下降。

需要的解决方案:定期的技能库清理和优化机制。

2. 过度拟合 Hermes过度学习用户的特定工作习惯,导致在处理陌生场景时表现不佳。比如,一个财务Hermes完全适应了某个企业的报表格式,突然换到另一个企业就会出现大量错误。

需要的解决方案:在学习的同时保持一定的"通用性",两者的平衡是关键。

3. 安全性与隐私 Agent在学习过程中可能接触敏感信息(用户数据、商业机密等),这些信息可能被不小心存储在技能库中。技能库的安全性、隐私保护是重大隐患。

需要的解决方案:严格的数据隔离、加密存储、访问控制。

   9.2 Hermes可能面临的市场风险

1. 技术更新快速迭代的压力:Hermes团队需要不断优化底层架构、处理新出现的问题、维护社区生态。如果迭代速度跟不上,可能被其他竞争者超越。

2. 平台的政策变化:Hermes严重依赖官方API的稳定性和可用性。如果官方改变政策、调整API、提高接入门槛,Hermes的整个中国市场策略都会受到冲击。

3. 商业化道路不清晰:目前Hermes的定价相对便宜(3.99美元/月)。随着用户增加,如何实现健康的盈利模式,是长期生存的关键。如果过度商业化,可能流失用户。

   9.3 用户可能面临的实际问题

1. 账号安全风险 虽然使用官方API相对安全,但高频率的自动化操作仍可能被微信风控识别。用户需要采取保守策略(如使用小号测试)来规避风险。

2. 学习成本 虽然Hermes声称"开箱即用",但要充分利用其自我进化能力,用户需要理解其基本原理,并在使用中有意识地"教会"它。这仍需要一定的学习投入。

3. 长期投资成本 要让Hermes成为真正强大的个人助手,需要投入时间进行"培养"。如果中途放弃,之前的投入就浪费了。这对用户的承诺度有要求。

10

结论:新时代的开启

   10.1 谁是真正的赢家?

如果问"Hermes和OpenClaw谁是赢家",答案不是「Hermes胜」或「OpenClaw胜」,而是:市场的细分化是所有人的胜利。

  • Hermes的用户:获得了一个真正深度、自我进化的个人AI助手

  • OpenClaw的用户:仍然拥有规模运营的最佳工具

  • 整个行业:从"一家独大"进入"生态多元",这推动了整个AI Agent领域的进步

   10.2 对中国开发者的启示

Hermes的成功,对中国的AI开发者和创业者有几个重要的启示:

第一,「本地化优先」可以超越「国际化优先」。 Hermes没有追赶美国市场的Slack和Discord生态,而是深入中国市场的微信。结果反而收获了更庞大的用户基数和市场潜力。这给所有中国创业者一个警示:不要盲目跟风国际化,深耕本地市场往往有更大的机会。

第二,「长期自我进化」可能比「一步到位的完美」更值钱。 OpenClaw试图在上线时就做到"尽可能完美",而Hermes则是一个相对简洁的开端,通过用户反馈不断进化。在快速变化的AI时代,后者的策略似乎更聪慧。

第三,「个人IP资产化」是新的机遇。 Hermes使得个人专家能够将自己的专业知识、工作习惯「资产化」为一个AI助手,进而商业化。对于有专业背景的个人(医生、律师、工程师、分析师),这打开了全新的收入来源。

   10.3 未来的想象空间

如果我们从更长远的视角看2026年的这场「Agent大战」,它真正的意义在于:Agent技术正在从「工具」进化为「伙伴」。

过去的AI是工具——你需要什么,就问它什么,然后得到答案。

未来的AI(Hermes代表的方向)是伙伴——它会随着时间推移越来越了解你,越来越适应你,最终成为你的另一个自己。

这不仅改变了人和AI的关系,也改变了工作和生活的本质:

  • 重复性工作会被自动化,释放人类的创意潜力

  • 专业知识会被数字化和复制,提升整个社会的专业水平

  • 个人的专业IP会变得可以规模化,打破地域和时间的限制

Hermes的七周逆袭,恰恰就是这个大转变的开端。

-End-

原创作者|李伟山

感谢你读到这里,不如关注一下?👇

图片

📢📢来抢开发者限席名额!点击下方图片直达👇

你对本文内容有哪些看法?同意、反对、困惑的地方是?欢迎留言,我们将邀请作者针对性回复你的评论,欢迎评论留言补充。我们将选取1则优质的评论,送出腾讯云定制文件袋套装1个(见下图)。4月28日中午12点开奖。

扫码领取腾讯云开发者专属服务器代金券!

图片

相关推荐

大模型的Agent Skill功能,在LLM HTTP底层交互流中是怎么承载的?

网络文章文本的 skill,昨天我实现了之后也就开始好奇起 Skills 的底层原理了——相比起各种花里胡哨的 agrnt 应用,我一直以来都很对大模型在纯粹的 HTTP 交互层面是如何交互的更感兴趣。Skill 的全部"魔法"都发生在 system prompt 的措辞和 SKILL.md 文件的编写质量上——本质上是一种 prompt engineering + 文件系统的组合。但是各种天花乱坠的 skills,是如何在底层的 HTTP 中,与大模型——这个只会嘴遁的工具交互的呢?

QcloudCommunity的博客 399

万字入门AI Infra:深入理解大模型中的数学与Infra优化

关注腾讯云开发者,一手技术干货提前解锁👇AI Infra科普、入门或者进阶 ~~ 不到 5 万字,带你融会贯通理解大模型的数学、算法、硬件到系统工程。任何问题欢迎沟通交流。可怕,我竟然有点认同这句话。当然大概率是因为姚顺宇太懂AI了,而我则是因为无知者无畏。不过仔细想想,大模型推理中的数学逻辑确实不复杂,很多原理只需要高中数学知识就能看懂。但是为什么像 vLLM 这种推理系统这么复杂呢?本文将拆解大模型中几个核心操作(RMSNorm、Softmax、Causal Mask、Sampling)背后的数学与

QcloudCommunity的博客 1156

平平无奇的源码,竟藏着Agent的核心秘密?

System Prompt 是剧本,Skill 是剧本的扩展包,Agent Loop 是演员按剧本行动。欢迎留言,我们将邀请作者针对性回复你的评论,我们将选取1则优质的评论,送出腾讯云定制文件袋套装。,让 Agent 能主动"巡逻",而不只是被动等待用户消息。OpenClaw 的 System Prompt 分层结构。的"行为底线",任何 Skill 或用户命令都无法覆盖它。精华 2:Skill 的"按需加载"避免 token 浪费。精华 1:System Prompt 是"分层乐高积木"

QcloudCommunity的博客 424

QQ音乐Harness Engineering实践

一个看似简单的需求,背后可能牵动服务调用链、配置、灰度、埋点、错误码、接口契约和历史兼容性。当 AI 开始快速生成大量代码,真正的瓶颈就不再是"写不出来",而是"看不完、想不清、管不住"。在对话式编码阶段,一种典型的工作模式逐渐流行:开发者把需求丢给 AI,扫一眼输出"看起来对"就直接采纳,不审 diff、不追问逻辑、不验证边界。以音乐商业化业务为例,一个需求可能从 TAPD 单开始,经过需求评审、技术方案、服务影响面分析、IDL 契约变更、业务代码实现、测试验证、CR、灰度上线,最后才进入稳定运行。

QcloudCommunity的博客 710

从Prompt、Context到Harness,工程的三次进化与终局之战

同时,强制要求散落各处的决策记录(Slack、邮件、文档)全部迁移至代码仓库,确保 Agent 的唯一信息来源是可信的、版本受控的仓库。更坑爹的是,研究表明,当上下文过长时,模型会出现"中间遗忘(Lost in the Middle)"现象:它对开头和结尾的内容记忆较好,对中间大段内容的关注度大幅下降。这篇文章,我想带你完整走一遍这三次进化的逻辑:它们分别解决了什么问题,它们之间是什么关系,它们的边界在哪里,以及:当三者融合,AI 工程师的终极形态究竟是什么?大语言模型的本质,就是这位金鱼助理。

QcloudCommunity的博客 712

让Skill自己训练自己:8阶段Loop、3层评测、5维AND门控,从此实现自进化

所以每一轮改动都是有据可查的,不是「感觉这里可以优化」,而是「Case 41 挂了,因为 agent 把离职问题路由到了邮箱分类,但正确答案在通讯录,所以我改 root_index.md 加个易混淆提示」。但让我最后决定把它记录下来的,不是这的个「吸收」过程,而是它真的在替我探索我不想费脑力触达的边界,这看起来更像是一个机器智能应该有的样子。不准跨层,每轮只改一层的东西。但我经过这 19 轮之后觉得,更准确的描述是互补——你在明处看着,AI 在暗处替你试错,你看不见的那一半就是 AI 能贡献的地方。

QcloudCommunity的博客 1118

只加两行代码,为什么要两天?一文深度理解业务系统的复杂性

关注腾讯云开发者,一手技术干货提前解锁👇业务系统复杂性一直是令开发者头痛的问题。复杂的不是增加一个需求需要耗费多少时间,而是在增加一个需求后带来的蝴蝶效应:其它功能会不会受到影响、要如何去找到这些影响,最终如何实现系统正常运行......功能之间隐秘增加的耦合、不可避免的代码腐化在导致业务复杂性增加。大家都在说的软件开发提效到底在提什么?程序员日常工作中应该如何提升开发效率?敏捷开发、瀑布流式开发孰是孰非?欢迎阅读。业务背景与目标我依然非常清晰地记得某个时候,我所在团队 Leader 曾讲过一段话:“我担

QcloudCommunity的博客 706

从零设计生产级 Multi-Agent Harness:架构、评估、记忆、成本与 MCP 工具接入全拆解

在 AI Agent 领域,Multi-Agent Harness 指的是把多个 Agent 的能力、工具、状态、通信、编排、监控统一收束在一个运行时之内的框架。第三,Agent 路由。一个输入框,一个大模型,几个工具,一段写得很漂亮的 System Prompt,再配上一个炫酷的前端,看起来就像一个能干活的“数字员工”。Multi-Agent 完全不一样——它有计划、有中间步骤、有工具调用、有 Agent 协作、有重试、有反思、有最终合成。增加 Budget、权限、重试、压缩、轨迹评估、审计、回归测试。

QcloudCommunity的博客 705

拆完Hermes源码,我发现Agent的“自我进化“根本不需要训练模型

两个月 5.2 万 Star,Hermes Agent 用一个"LLM 审判官"机制实现了 Agent 的自我进化——不改模型权重,只改"怎么用模型"的策略。OpenClaw(社区昵称"龙虾"🦞)是 2025-2026 年最火的开源 Agent 框架,30 万+ Star,插件市场 ClawHub 里有数千个插件,能接入 Telegram、WhatsApp、Slack、飞书、企业微信——几乎是一个"个人 AI 操作系统"。Skill 是英语写的,Memory 是英语写的,审查 Prompt 也是英语写的。

QcloudCommunity的博客 902

AI Infra 其实没有多少新东西

传统 Infra 追求横向扩展,而 AI Infra 呈现 “AI 大型机”特性,是因为传统后台服务的可以容忍毫秒级延迟,但 AI 集群不行,GPU 的算力是 CPU 的数百倍,微秒级的延时等待也会造成很大的算力损耗,需要硬件的高度集成。在可预见的1-3年的未来,这样的专用硬件+网络的集中式架构很难发生比较大的改变。与之相似,模型推理的批处理就是将多个输入样本打包(batch),将原本串行的 N 次轻量的推理计算,合并为 1 次重量的计算,实现单位时间内处理更多的请求,提高了 GPU 利用率。

QcloudCommunity的博客 818

程序员越早想通这些越好

永远没有正确架构,你永远无法偿还完所有的技术债务,如同你永远不会设计出完美的界面,请避开完美主义的陷阱,永远没有完美的代码,能够满足当前需求,又为未来不管是自己还是他人留有扩展空间,就很好了。我们努力的方向就是将现实世界映射到有限的数据结构中,这就需要用户自定义类型,如果你的代码中包含类似 trader portfolio 这样的概念,你就可以使用他们的名称来建模,而不是使用基本数据类型复杂嵌套表述你的目的。从另一个角度看,代码里的注释都是补丁,是碎片化的,局部的注释很难推导模块整体的顺序及耦合关系。

QcloudCommunity的博客 464

RAG已死?不,是Grep回归了!

这样一来可以直接复用已有的计算缓存,只为新增的增量部分付全价,前面累积的大头按约 1/10 的缓存价计费。所以实际的工具组合方式是灵活的:Grep(默认模式)→ Read 是最常见的路径,但 Grep(content 模式)可以独立使用,LLM 也可以直接调 Read(如果已经知道文件路径),或者一次同时发起多个 Grep 并行搜索。它从零开始构建自己的对话历史,不继承主对话的消息,这意味着它搜索过程中产生的大量 grep 结果、代码片段都留在自己的 context 里,主对话只收到一段总结性的文本结论。

QcloudCommunity的博客 570

深入浅出Harness Engineerring之核心模式与理念

在智能体生命周期的关键节点(如会话开始、工具调用后)自动触发预设动作(如代码格式化),由系统确保关键流程被执行,不依赖可能被模型遗忘的指令。简单讲就是利用向量存储这个技术,来实现模糊检索,原理是:即使字面不同,但语义相近的文本,其向量在数学空间中的位置也很接近。根据命令类型、参数和影响,自动评估其风险等级(安全、有风险、危险),并采取自动执行、请求确认或直接拦截等不同策略。关键特性是可隔离、可重建、可扩展。不是一次判断就定终身,允许你改变、允许情况复杂,通过不断观察、思考、调整,越来越懂真实的你。

QcloudCommunity的博客 621

Harness Engineering实践心得:如何高效驾驭AI?

但如果这些经验被拆成一条条 Rule、一个个 Skill、一项项 Script 检查——"XAML 不能有中文"、"编译要用这个路径的 MSBuild"、"SVN 命令必须带认证参数"——AI 就能在秒级时间里"吸收"十年的踩坑经验。然后可以看到下方的图,我的PM会很顺利的调度其他agent分别负责不同的事项,遇到问题的时候也能准确的找到合适的agent。MCP 本质上是在扩展 AI 的"感知范围"——Rule 管"该怎么做",Skill 管"怎么操作",MCP 管"能看到什么、能碰到什么"。

QcloudCommunity的博客 838

从第一性原理思考 Agentic Engineering

需要注意的是,这一结论是有条件的:如果 AI 缺乏领域知识,过早介入反而可能引入 1.2 节所述的"似是而非"损耗——因此上下文供给(实践 1)是 AI 全链条参与的前提,而非结果。通过一个专门的自迭代 Skill 实现——当 AI 在协作过程中识别到自己被纠正(用户否定了 AI 的输出并给出了正确方向),它自动评估这个错误的根因,搜索现有的 Rules 和 Skills 中是否已有针对该类问题的处理规则。事实上,越是复杂的项目,工程师的认知负担越重(公理 3),AI 分担认知负担的潜在边际价值也越大。

QcloudCommunity的博客 754

万字干货!Harness Engineering如何工程化落地?

关注腾讯云开发者,一手技术干货提前解锁👇Harness Engineering 的概念已经火了有一阵了,全网很多文章基本都是在讲理念,讲为什么今天做 AI 开发,不能只靠一段提示词,也不能把模型当一个“更聪明的代码补全”。但与此同时,一个问题也在持续地发酵:这个问题特别重要。因为 Harness 这个词听上去很大,很像一个抽象的方法论,但它如果不能落到工程、目录、文档、脚本、工作流里,那它最后就只是一句漂亮的话。事实上,不同项目落地出来的 Harness,表面上可能完全不一样。有的项目是 CI 很强,有的

QcloudCommunity的博客 1159

一文讲透:Harness Engineering即控制论!

而研发模式的升级我认为将会是一个飞跃的过程,之所以现在我们仍然需要需要参与编码,一个非常大的原因就是缺乏传感器和基建,仍然需要人来串流程,比如需要人来验证UI是否正确、需要人来告诉AI代码不符合代码规范,因此在有些场景我们仍然感觉 AI 完成的很吃力,但这不是 AI 能力不行,而是我们并没有为 AI 提供友好的环境……控制论中的突变理论介绍了矫枉过正和飞跃现象之间的矛盾,如果质变中经历的中间过渡态是不稳定的,那么他就是一个飞跃的过程,如果中间过渡态是稳定的,那么他就是一个渐变的过程。但是这些阶段要解决的。

QcloudCommunity的博客 1201

神级开源插件!一句话让QClaw变3D小镇,Agent工作可视化,赛博云监工

这个架构是翻了几次车才想通的—原有AI的实现机制是用 setTimeout 猜动画时长导致了幽灵 NPC、工位撞车、越改越崩,后面我停下来换了思路,推翻原有的架构,按照“意图+回传”的架构进行重构,之前的问题一次性全部解决。15 天,我和 AI 吵了 185 次架, 4.5 万行代码,开发了一款 QClaw / OpenClaw 的UGC游戏插件,这可能是人类跟 Agents 交互的新范式,插件已完全开源,有需要的欢迎自取~我天天用,用着用着我就在思考,Agent 产品现在的交互体验,基本都一个样。

QcloudCommunity的博客 1193

一文搞懂Hermes:新顶流Agent如何从经验中自我进化

Voyager 是一个能在 Minecraft 中自主探索、学习技能、无限积累能力的 AI Agent,它提出了 "Skill Library"(技能库)的概念——Agent 将成功的行为序列编码为可复用的技能函数,存储在一个持续增长的代码库中。如果 Skill 的名称和描述不够精准,或者用户的任务描述与 Skill 的触发条件有语义差距,Agent 可能会错过相关的 Skill。如果进程在写入过程中崩溃,目标文件要么是旧内容(还没被替换),要么是新内容(替换已完成),绝不会出现写了一半的损坏文件。

QcloudCommunity的博客 2624

自掏腰包一万元,拥抱AI这一年,我的工具、实践和思考

其实也很好理解,过往的每个领域(比如前端、后端、设计、测试等等)都主要是这个领域的从业者在为它添砖加瓦,但是大模型时代的 AI 应用领域却几乎是所有使用 AI 的人类一起在迭代,无分领域,无分文理,无分老少。因为每个时期的 AI 都有着不同的特点,很多时候当我费尽心思去钻研,自以为有点弄明白 AI 应该怎么玩的时候,基座模型和行业范式常常就会迎来颠覆式的变革,很多过往的经验都会倾覆,然后只能从头再来。过去一年多,被热议的 AI 范式大概是沿着四个阶段递进演化,每一个阶段其实都在解决前一个阶段的核心问题。

QcloudCommunity的博客 626

办公Agent的CI/CD时刻到来了

核心观点是:企业给员工配了一堆 AI 工具,试点跑了几百个,但真正拖慢 AI 转型速度的瓶颈不在模型能力,在"最后一公里":AI 输出和实际工作流之间的那道鸿沟。代码写完,打个 tar 包,开 FTP 传到服务器上,SSH 进去解压,改配置文件,重启服务,刷一下页面祈祷别 500。你复制,切窗口,粘贴到腾讯文档里,发现 Markdown 格式全乱了,手动调标题层级,代码块重新标记语言类型,表格散架了重排一遍。模型是越来越聪明了,但"生成"到"落地"之间那段路,还是你自己在走,一步一步,手动搬运。

QcloudCommunity的博客 607

4亿token买来5个教训:让6个AI Agent连写4天代码发生了什么?

Watchdog 检测到崩溃 → 启动诊断 Agent 分析原因 → 诊断 Agent 跑满 20 轮没搞定 → Watchdog 判定“已修复”,重启系统 → 重启的系统因为诊断 Agent 留下的环境变量被继承,连续 3 次拒绝启动 → 触发连续失败保护退出 → Watchdog 第 3 次巡检,发现进程和记录文件都没了,尝试手动重启,自己也停了。启动前我翻了论文、做了架构设计、写了监控+修复异常的脚本。这个发现让我的情绪从沮丧变成了兴奋——不是那种"终于修好了"的释然,是"我找到根因了"的快感。

QcloudCommunity的博客 582

赛博斗蛐蛐:9大模型决战三国志,天命在谁?

我猜是这样的,当Gemini面临决策的时候,一系列关键词比如 守城,劣势,粮草,三国等等,在语义层面的关联性中LLM发现了竖壁清野这个关键词概率非常高,所以以此为策略,然后再根据这个策略完美执行操作。MiMo 的外交是三方中最精明的。Kimi作为国产模型,也同样颠覆了我对他的看法,最后的比赛他甚至一度是优势者,存在很多夺冠的可能性,要知道他的对手可是claude和gemini,而他经常出兵慢,回过头来想想或许正是他的策略,毕竟中后期他的优势都来自于稳健的发展和较少的战斗频率(和claude比).

QcloudCommunity的博客 870

Claude Code是怎么知道你在骂他的?这 12 条发现值得关注

确实存在——5,500+ 行,集成了消息队列、工具装配、MCP 编排、会话状态、权限、分析、文件持久化和优雅关闭,基本上一个文件干了所有事。对抗虚假声明——"不要在输出显示失败时声称所有测试通过,不要压缩或简化失败的检查来制造绿色结果"。完整的 KAIROS 是一个持续驻留的守护进程,能感知你在不在电脑前、主动寻找有用的工作做,更像是住在终端里的全职同事。源码里藏着一个叫 "Buddy" 的电子宠物系统,完整度令人惊讶——这不是一个 TODO,而是一个从数值系统到 ASCII 动画都实现了的完整功能。

QcloudCommunity的博客 700

逆向深扒Claude Code源码,我发现了什么!?

Anthropic 内部用户获得更严格的质量控制 prompt、更好的验证机制(独立 Verification Agent)、以及针对 model 弱点的专门对策(如 Capybara v8 的 29-30% 错误声明率对策)。这不是代码混乱的标志——它是整个 Agent Loop 的心脏,所有的流式处理、工具调度、上下文压缩、子代理管理都在这个文件中协调。这种"胖核心"设计是刻意的:保持核心循环的原子性,避免分散到多个模块导致的协调复杂度。核心价值:Fork 代理的工具输出不会回到主代理的上下文窗口。

QcloudCommunity的博客 885

一文讲透如何构建Harness——六大组件全解析

本文将从"裸模型的四个硬伤"出发,逐一拆解 Harness 的六大组件——文件系统、Bash + 沙箱、记忆(AGENTS.md)、Web Search + MCP、上下文工程、编排 + Hooks——带你看清 AI Agent 真正的竞争壁垒,不在模型层,而在 Harness 层。如果你用过 Agent 做复杂任务,你一定有过这样的体验:一开始 Agent 的表现很好,但随着对话变长,它开始"变笨"——遗忘之前的约定,重复之前犯过的错误,甚至对同一个问题给出前后矛盾的回答。对于简单的问答场景,这无所谓。

QcloudCommunity的博客 758

Harness Engineering 来了,SDD 还有意义吗?

他们的解法是把「品味」编码进规则,然后用一个定期运行的「doc-gardening」Agent 自动扫描漂移、发起修复 PR——「技术债务就像一笔高息贷款,不断地以小额贷款的方式偿还,总比让债务不断累积要好」。代码仓库本地的、已版本化的工件,才是 Agent 所能看到的全部。在 Vibe Coding 模式下(即不做规划、随意向 AI 提需求的开发方式),大量设计决策、跨服务约定、「为什么不选另一个方案」的讨论,全部停留在一次性的 AI 对话里——下一个人,或者下一次 AI 会话,完全无从获取。

QcloudCommunity的博客 417

零废话!一文讲透从0构建AI Agent

每个工具都要写一套"定义→解析→执行"的胶水代码。上下文管理就是在"记住足够多"和"别超标"之间找平衡,常见策略包括滑动窗口、摘要压缩、RAG 检索增强。上下文窗口是 Agent 的"工作记忆",但它有硬性限制。LLM 负责"动脑"决策,代码负责"动手"执行。这是从"聊天机器人"进化到"Agent"的关键一步。每次调 API 都把完整对话历史发过去,LLM 本身是无状态的,"记忆"完全靠客户端的数组模拟。这样 Agent 一开始就知道自己"在哪里"、"手头有什么",不需要先花一轮工具调用去探索环境。

QcloudCommunity的博客 709

距离AI把小编我裁掉还有72小时

这是一个基于 OpenClaw 开源生态打造的本地化 AI Agent 助手,已于上周开启全量公测,无需复杂配置,三步即可上手,自带安全防护,支持微信直连绑定,内置多款优质国产大模型,现阶段也是完全免费使用,基本上前面提到过的痛点都可以靠它解决。对了,这里特别强调一点,上面的截图让产品同事汗流浃背,再三找我确认 QClaw 思考过程中优美的“草”字说法,不会是默认出现的吧?AI 好,AI 得学,但更重要的是,在你的工作和生活里,哪些东西是能结构化地被 AI 所接入的,不要死守着那些脏活累活不放。

QcloudCommunity的博客 672

龙虾盛宴下的冷思考

举个我自己的例子:在电商项目里,商品列表页的 CRUD 逻辑、TypeScript 类型定义、接口联调的模板代码,这些任务交付标准很明确,接口对了、类型没报错、列表渲染正常,交给 Agent 做又快又稳。当然这个做法我还在摸索,效果不确定,毕竟前面刚说了 Agent 写的代码质量有问题,凭什么相信 Agent 的审查更靠谱?LLM 优化的目标是「看起来合理」,不是「行为正确」。他的原话大意是:不喜欢看文章的人不会因为有了 AI 就开始看,真喜欢看的人也不需要 AI 整理,算上折腾的时间省没省还不好说。

QcloudCommunity的博客 373
上一篇: 一文讲透:Harness Engineering即控制论!
下一篇: 万字干货!Harness Engineering如何工程化落地?
腾讯云开发者
腾讯云开发者 企业官方账号 企业官方账号
博客等级 码龄10年 6289粉丝 1962原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值