AI 时代,并不需要一个 App Store

我有一个大胆的推论:AI 时代,并不需要一个 App Store。

为什么?

现在,AI 通过输出代码,已经能很好地实现很多之前需要专业人员才能解决的问题。它能操作电脑,也能直接产生视频。

而且,随着 token 越来越便宜,每个人都可以拥有自己的 Agent,一个专属的个人智能助理。

有什么问题,可以直接跟它说。

不管是搜索,还是邮件、日历,各种通过浏览器能解决的问题,都交给它。浏览器里不能解决的事,也可以在云端给它一台 AI 能够完全掌握的电脑,让它去完成。

你看 Muse,就是这样子的例子。

如果顺着这个方向继续往下想,那就有意思了:

我已经有一个能帮我解决问题的 Agent,为什么还需要去 App Store 找一个 APP 呢?

我需要的,从来就不是一个 APP

原来我有一个需求未满足,我的下意识行为是,去搜索有没有什么 APP 可以处理。

于是打开 App Store。

搜一下,看介绍,看评分,下载几个试试看。有的要注册,有的要付费,有的打开之后才发现,不是自己想要的。

最后,好不容易找到了,还得学一下怎么用。

我们已经习惯了这个过程,觉得用软件就是这样的。

但仔细想想,我本来只是想解决一个问题,怎么最后变成了我要先去找一个工具,再学习这个工具,然后自己操作,把问题解决掉?

比如,我只是想把几个文件整理一下。

我需要的是整理好的文件,而不是一个文件管理 APP。

我只是想把一段内容做成视频。

我需要的是那个视频,而不是先学会一个视频剪辑软件。

我只是想安排好下周的事情。

我需要的是安排好的日程,而不是再下载一个效率工具,然后花半天研究它。

APP 是过去解决问题的方式,但 APP 本身并不是我的需求。

以前没有更好的办法,所以我们找 APP。

现在,有了。

有需求,直接问我的 Agent

而现在,我有一个想法或需求,就直接问我的 Agent。

它去帮我解决。

需要搜索,它去搜索。需要处理邮件、安排日历,它去操作。需要写一段代码,它就写一段代码。

需要用到某个工具,也可以由它去找、去调用。

对我来说,我不一定需要知道它用了什么软件,也不一定需要知道它中间操作了多少个步骤。

就像我把一件事情交给助理,我关心的是事情有没有办好,而不是要求助理把用过的每一个工具,都先教我一遍。

这才是个人智能助理应该做的事情。

不是告诉我:“你可以下载这个 APP,然后按照下面十个步骤操作。”

而是:“你要的东西,我帮你做好了。”

一个是教我怎么解决问题,一个是直接帮我解决问题。

这两个体验,完全不一样。

如果我的 Agent 能够直接帮我解决,速度又快又好,哪里还有打开 App Store 的需求呢?

没有了。

至少对我这一次的需求来说,没有了。

而当越来越多的需求都可以这样解决,我打开 App Store 的次数,自然就越来越少。

直到有一天,我可能已经很久没有想起它了。

软件还在,但我不需要自己去找了

这里说不需要 App Store,并不是说以后所有的软件都不存在了。

软件可能还在,各种服务也还在。

但过去,是我去找软件。以后,可能是我的 Agent 去调用软件。

过去,一个需求来了,我想的是:

“有没有一个 APP 可以做这个?”

以后,一个需求来了,我想的是:

“让我的 Agent 帮我做一下。”

就这么简单。

但这个变化很大。

因为 App Store 之所以对我重要,是因为它是我寻找解决办法的地方。

当我寻找解决办法的第一站,已经变成了自己的 Agent,App Store 就不再是那个必经之路。

甚至,有些需求根本不需要一个完整的 APP。

一个小脚本,一次网页操作,或者几个工具组合一下,就解决了。

过去,我为了一个很小的功能,可能需要下载一个很大的软件。

以后,Agent 可以只为我完成这件很小的事。

做完就好了。

我不需要再多管理一个账号,也不需要在手机里再多放一个几个月才打开一次的图标。

真正的变化,是我们不再到处找工具

所以,我觉得 AI 带来的变化,不只是原来的 APP 里面多了一个聊天框,或者多了一个 AI 按钮。

而是我们解决问题的方式,可能整个都变了。

以前,我们要适应软件。

软件有什么功能,按钮在哪里,流程怎么走,我们就跟着它来。

以后,我更希望是直接说出自己的需求,由 Agent 去理解,去找工具,去完成。

不是我围着一堆 APP 转,而是有一个智能助理,围着我的需求做事。

这个 Agent,可以是 Apple 的 Siri,也可能是 Muse,也可能是 Hermes、Pi……

名字是什么,其实没有那么重要。

重要的是,它能不能真正替我做事。

当每个人都有一个自己的 Agent,有问题直接跟它说,有想法直接让它去实现,谁还会先想着打开 App Store 呢?

所以,我有这个大胆的推论:

AI 时代,我们需要的不是一个更大的 App Store,而是一个真正能帮自己解决问题的 Agent。

让我们迎接人手一个智能助手 Agent 的时代。

注意力稀缺时代

AI在内容生产这一块,速度越来越快,质量越来越高,不管是文章,软件,APP, 图片还是视频包括电影电视剧等,之前需要的时间与现在需要的时间与工作量来比,之前是现在的成百上千倍。

今早我看到如下这个新闻:

今年上半年国内各平台上线了 36.7 万部微短剧,其中超过 74% 是 AI 生成的,平均每天新增超过 1500 部 AI 短剧。

现在 AI 生成的短剧,比之前真人短剧有意思多了,编剧更有趣,一些之前不好拍场景也可以随意生成。真人短剧受限于成本,一般场景设定都比较简单,出场人物也比较少,但是 AI 短剧完全没有限制。

人们现在能接触到内容真的是源源不断,应接不暇,但真正能认真看的,被受注意的内容并不会很多

一个人一天能花在看内容的时间是固定的,并不会增长,最长不超10小时,但大部人估计1到2小时

这些无穷的内容,真正能进入人们视线的估计10不存一,所以,

内容已经不值钱了

掌握人们看到什么的平台才是真正的现金牛

平台可以选择让哪些内容呈现给人们,它就有话语权,定价权

而那些内容生产者,只有被收割的份。

或许偶尔可以跑出一个爆款内容,但这估计也只是平台放出来的烟雾弹,想继续引诱内容生产人员加大投入,让他们有这个错觉,好像下一个爆款就是我

所以,在内容爆炸时代,注意力才是真正的稀缺资源。

对于个人而言,特别想要做一些事情的人,最核心的是保护自己的注意力,不要去被垃圾内容吸引

我们判断一个信息是否有价值的唯一判断标准是,这个信息是否能改进你当前的局面,当前的认知,当前的状态;而绝大部分的内容是无法做到这一点的。

真正优质的信息散落在海量的垃圾内容里,等待被有缘人发掘。

AI来了,软件人还有出路吗?我想从人的需求说起

之前,信息技术、互联网、软件行业发展得如火如荼,创造了大量的就业岗位,大量的年轻人获得了较高的收入,也创造了大量的财富。数字化的风吹遍了各行各业,吹进了大江南北,每一个企业都在谈数字化,每一个企业家都很焦虑:如果不数字化,是不是就要被淘汰?

没几年,AI来了,掀起了滔天巨浪。AI代替文员,代替设计师,代替软件工程师,甚至有人说,AI可以代替所有的岗位。企业开始重新考虑哪些工作需要人来做,许多从业者也开始担心,自己的岗位还能存在多久。

而随着AI不断发展,人们对它的期待,已经从文字处理、代码编写,延伸到了数学研究、生物医药、新材料、物理学等领域。以前我们认为只有专业人员才能做的事情,如今也开始讨论能不能交给AI。

而我作为一名软件工程师,同时又是一个创业者,不禁思考:我是不是要被AI拍在沙滩上了?我的出路还在吗?我们软件行业要何去何从?

我想,要理清这个问题,我们要回到最开始,去了解:人们为什么需要软件?人的需求究竟是什么?

人为什么需要软件?

我们讨论的这些需求,归根结底都来源于人。离开了人,软件、技术、产品,也就失去了服务的对象。

所以,人的需求是什么?借用马斯洛需求层次理论,以及后来对它的扩展,我们可以从以下几个方面来看:

  • 生理需求:维持人类生存的最基本条件,比如衣、食、住、空气、睡眠。
  • 安全需求:人身安全、健康保障、工作与收入的稳定,以及财产安全。
  • 社交需求:友情、亲情、爱情,以及人际交往带来的归属感。
  • 尊重需求:成就感、名誉,以及受到他人的认可与尊重。
  • 自我实现需求:发挥个人潜能,实现个人理想和抱负。
  • 此外,还有认知求知、审美、自我超越等方面的需求。

这些需求,也可以从匮乏与增长两个方向去理解。一方面,我们希望弥补缺少的东西,让自己能够生存,生活得安全、稳定;另一方面,我们也希望不断成长,理解更多的事情,实现更多的价值。

那在这些需求的背后,软件满足了哪些?对这些需求起到了什么作用?我们一条一条来拆解。

对于生理需求,衣食住行这些都离不开设计、生产制作、销售、运输,以及管理和供应链的协调。而软件在这里起到的作用,本质上是优化信息流转,把流程固定下来,提高效率,把那些原来只存在于每一个员工脑子里的知识留存下来,让产品在这些流程环节中流动得更快,成本更低。

计算机与软件的发展,也让那些原来不能做,或者很难做到的事情,可以通过大量的计算、设计和验证来实现。比如模拟仿真软件、有限元分析软件等,就被用于汽车、电子、建筑等行业的设计与生产环节。

因为生产效率提高了,各种产品的成本降低了,物质逐渐丰富起来,人的生理需求也就能够得到更好的满足。

对于安全需求,软件可以帮助人们记录和检查生产过程,发现异常,管理资产,也可以帮助整理健康信息、辅助专业人员工作。它让一些原来很难看清、很难及时发现的问题,变得更容易被发现和处理。

而互联网的发展,让信息流动得更快速,也满足了人的社交需求。人们可以在互联网上找到朋友,寻找爱情,与亲朋好友保持较为紧密的联系。

有一部分人,通过把自己的认知与思考发到网上,表现为博客、文章、视频、观点与见解,既满足了其他人的认知求知需求,也让自己获得了成就感、名誉,以及他人的认可与尊重。

还有一些人,通过软件创作、学习、设计,去实现过去没有条件实现的想法。这又满足了人的成长与自我实现需求。

而移动互联网的发展,更是把这些能力带到了每个人身边。一部小小的手机,就可以完成过去许多需要电脑才能完成的事情。计算、信息分享、购物、社交,都可以随时随地进行。人们也越来越多地把时间花在手机上,花在社交媒体和短视频平台上。

回头来看,软件的形式一直在变,但它做的事情,始终与人的需求有关。

AI会让这些需求消失吗?

因此,AI的发展会让这些需求消失吗?

不会。

人还是要吃饭、穿衣、居住,还是希望安全、健康,还是需要朋友、家人,需要被理解、被认可,也还是希望成长,做成一些事情。

当然,具体的需求会随着环境发生变化,但这些底层的需求,不会因为AI出现就消失。

只要人在,这些需求就在。会改变的,是这些需求被满足的方式。

一开始,人们寻找信息资料,得去图书馆翻查;后来,可以到Google等搜索引擎上搜索;而到了AI时代,人们又多了一种方式,可以直接通过与AI对话来寻找答案。对于一些问题,这样会更简单、更方便,但重要的信息依然需要核实。

在这个过程中,人想要了解一个问题、找到一份资料的需求没有变,变的是获取信息的方式。

企业也是一样。

企业购买库存管理软件,不是因为它需要一个库存页面,而是因为它不想缺货,也不想积压太多货。

企业购买客户管理软件,不是因为它喜欢录入客户资料,而是因为它希望少遗漏客户,做好跟进,促成更多生意。

用户真正需要的,并不是软件本身,而是软件能够帮助他完成什么。

如果AI可以用另一种方式,更好地完成这些事情,那么原来的软件形式就可能发生变化,甚至被替代。但背后的需求,仍然存在。

原来不值得做的事情,可能值得再做一次

AI在文字与信息处理、代码编写等方面展现出的能力,让我们看到了另一种可能:一些工作,不一定还需要人从头到尾亲自完成。

而随着AI能力提高,如果使用成本和整体交付成本能够继续降低,那么一些原来不能做、做不好,或者因为太贵而没有人愿意做的事情,就可能值得重新考虑。

比如,一家小工厂,希望把老师傅的经验整理下来,让新员工遇到问题时能够随时查阅。

过去,要专门找人访谈、记录、分类、整理,还要持续更新。工厂可能觉得太麻烦、太贵,最后还是依赖老师傅现场教。

如果AI能够辅助整理这些资料,让员工用日常语言就能查询,再由有经验的人进行确认,那么这个以前一直想做、却没有做成的事情,就可能有机会做起来。

再比如,一家小公司,希望认真回复每一个客户的咨询,但请专人不划算,老板自己又忙不过来。以前只能接受回复慢、跟进不及时,现在就可以重新考虑,哪些环节能够交给AI,哪些环节仍然需要人来处理。

这些需求过去不存在吗?存在。

只是过去解决这些需求的成本太高,用户付不起,服务方也赚不到钱,所以没有形成生意。

AI可能改变的,就是这笔账:原来不值得做的事情,现在可能值得做;原来做不到的事情,现在可能可以做。

由此推理,我认为以后有可能出现更多小而专的中小企业,甚至是只有几个人的小团队。每一个团队服务一定量的用户群体,解决一类具体问题,不需要做得很大,也可以形成自己的生意。

当然,这不是说AI一来,钱就一定流动得更快,经济就一定会更好。技术带来的可能性,还需要变成真正有人愿意付费、能够持续交付的服务。

但至少,很多以前算不过来的事情,现在值得重新算一遍了。

软件从业者可以从哪里寻找机会?

而我作为软件行业的从业者,一名创业者,一个工程师,要如何在这个AI发展的大趋势中占据一个生态位?

我想,还是要从人的需求出发,结合自己的优势,认真去推理,去想象:如果AI继续发展,会有什么事情变得可行?人们会需要什么?会出现哪些新的服务?这些服务又需要哪些基础平台?

对于生理需求,未来可能每个家庭都有一个专属AI助手。家里缺少什么,它可以根据主人的习惯整理清单、比较价格,在获得授权后下单,也可以帮助安排、提醒一些日常事务。

而对于满足生理需求的生产过程,AI也可能帮助企业分析需求、预测销量,更及时地调整备货、生产和运输。但预测是否准确,执行是否可靠,仍然需要真实业务来检验。

对于安全与健康,我们可以期待AI辅助科研人员寻找新的药物和治疗思路。而在更贴近日常生活的地方,AI也可能帮助人们整理健康记录,理解需要向医生询问的问题,配合设备记录身体指标,在需要时提醒用户寻求专业帮助。

这里的机会,不是简单地让AI扮演一个“什么都懂的医生”,更不能把它的回答直接当成诊断,而是看它能不能把信息整理、日常记录、就医准备这些事情做好。

对于社交,AI角色扮演、陪伴式交流,可能会满足一部分人的表达和陪伴需求。但陪伴不等于心理治疗,也不意味着人与人之间的关系可以被完全替代。

另一方面,AI也可以帮助人们更好地建立真实联系。比如帮助练习表达,帮助跨越语言障碍,帮助找到有共同兴趣的人。

对于尊重和自我实现,AI可能让更多人有能力把自己的想法做出来。一个不会写代码的人,可以尝试制作自己的小工具;一个没有专业设计能力的人,可以更容易地表达自己的创意;一个想学习新知识的人,也可以获得更多解释、练习和反馈。

这些方向都很大,不是一个人、一个团队就能做完的。

而真正适合我们的机会,往往就在其中一个很具体的环节里。

你熟悉制造业,就去看制造业里那些长期靠人协调、反复出错的事情。

你熟悉教育,就去看学习过程中那些一直没有被照顾好的差异。

你擅长系统集成,就去考虑,如何让AI与企业现有的软件、数据、权限和流程连接起来。

你擅长基础技术,就去看,当这些AI服务真正运行起来时,需要怎样的监控、评估、成本管理和安全保障。

不一定每个人都要去做一个通用AI产品。我们可以从自己熟悉的人群、行业和问题出发,找到一个足够具体的位置。

最关键的是,从交付软件变成交付结果

但在这些变化里,我认为最关键的一点,是我们需要改变过去的交付思路。

以前,我们习惯交付软件。

客户需要什么功能,我们把功能做出来;需要什么流程,我们把流程配置好;系统上线,培训完成,项目验收,我们的工作也就基本结束了。

至于客户有没有真正用起来,问题有没有真正解决,有时候还需要客户自己花很多精力去完成。

而在AI时代,我们需要进一步思考:能不能不只是交付一个工具,而是直接帮助用户完成结果?

比如,过去我们交付一套报表系统,让用户自己选择条件、导出数据、分析原因。

现在,我们能不能帮助用户把数据整理好,找出异常,把需要关注的问题和判断依据一起交给他?

过去,我们交付一套客户管理系统,让销售人员自己录入、查找、提醒、跟进。

现在,我们能不能帮助他整理沟通记录,找出遗漏的跟进,准备下一次沟通所需的材料,再把需要本人决定的事情交给他?

过去,我们交付一个生成报价单的功能。

现在,我们能不能根据客户需求,整理资料,查询历史报价,标记不确定的地方,最后交付一份可以由负责人审核的报价草案?

这里发生的变化,不只是界面从按钮变成了对话框。

而是我们从“给用户一个可以完成工作的软件”,变成了“帮助用户把这件工作完成”。

当然,交付结果不意味着可以承诺一切。

我们不能因为做了销售助手,就保证客户的销售额一定增长;不能因为做了健康助手,就保证用户不会生病。

而是要找到一个边界清楚的结果:哪些事情由系统完成,做到什么程度算合格,哪些地方必须由人确认,出现问题以后如何处理。

越是向结果靠近,就越需要考虑准确性、稳定性、权限、安全和责任。这也意味着,工程师的工作并没有因为模型能够写代码就结束,而是要进一步把这些能力组织起来,让它们在真实环境中可靠地运行。

回到我们自己的出路

所以,再回到最开始的问题:我是不是要被AI拍在沙滩上了?软件行业的出路还在吗?

我想,如果我们把自己定义为某一种固定工具的使用者,只能按照过去的方式写代码、做页面、交付系统,那么确实会面临越来越大的压力。

但如果我们把自己定义为解决问题的人,那么AI也可以成为我们新的能力。

我们可以重新去看,那些过去没有解决好的需求,那些因为成本太高被放弃的需求,那些用户一直在忍受、却没有合适方案的需求。

然后结合自己的经验、技术、行业理解和客户资源,推理出哪些事情值得再做一次,哪些结果现在可以交付。

人的底层需求仍然在那里,但机会不会自动落到我们手里。我们需要去接近用户,理解问题,把技术变成实际可用的服务。

软件会变,AI会变,但人对更好生活的需求不会因此消失。变化的,是我们满足这些需求的方式。

而我们软件从业者要做的,就是在这个变化中,找到自己能够发挥优势的位置。

从以前的交付软件,走向交付结果。

不只是告诉用户:“这个软件可以帮你做什么。”

而是进一步做到:“这件事情,我可以帮你完成。”

一文搞懂Hermes Agent 前世今生

一、Hermes Agent 是怎么长出来的

如果只看它的 GitHub 首页,Hermes Agent 很容易被误读成又一个“AI agent 框架”:一个可以接模型、调工具、跑命令、接消息平台的工程项目。但如果把时间线拉长,你会发现它真正想解决的,并不是“让模型多调用几个工具”,而是一个更野心勃勃的问题:

能不能把 AI agent 从一次性会话工具,变成一种持续存在、会积累、会反思、会迁移的长期系统?

这其实就是 Hermes Agent 从诞生起的主线。


1. 起点:不是从“写代码助手”出发,而是从“长期存在的代理”出发

Hermes Agent 的出身,和很多 AI 应用很不一样。

多数 2023-2025 年涌现出来的 agent 产品,起点是两个方向之一:
一类从 IDE/coding copilot 出发,目标是让模型在代码编辑、调试、终端执行里更顺手;
另一类从 chatbot + tools 出发,核心是让对话系统接 API、能联网、能调用 MCP 或浏览器。

Hermes Agent 的 framing 更激进。官方首页直接把它定义成:

“The agent that grows with you.”1

这句话不是宣传口号那么简单,它几乎概括了整个产品哲学:
Hermes Agent 不是为了在单次任务里“答得更好”,而是为了在多次任务、跨会话、跨平台的累积中“变得更像你的 agent”。

从文档与官网描述来看,它最初的核心差异点不是单个工具能力,而是三个互相咬合的机制:

  1. Persistent memory:记忆不是上下文窗口里的临时 token,而是跨会话留存的结构化资产;
  2. Auto-generated skills:不是只会调用既有工具,而是会把经验沉淀为技能文档;
  3. Self-improvement loop:技能与记忆相互强化,让 agent 在长期使用中“长出来”。12

这意味着 Hermes Agent 的真正竞争对象,从一开始就不只是某个聊天应用,而是整个“会话式 AI 工具范式”。


2. 诞生背景:它踩在两个时代交叉口上

Hermes Agent 出现的时点非常关键。根据公开报道与官方资料,它在 2026 年 2 月 上线,首个公开版本可追溯到 v0.1.0,2026 年 2 月 25 日 左右34。这个时间点背后,其实有三股已经酝酿成熟的力量。

第一股:模型能力终于足够稳定,能支撑“长链条代理”

到 2025 年后期,业界已经逐渐形成共识:
模型不再只是“生成文本”,而是可以稳定完成工具调用、规划、搜索、代码执行、多轮修正等 agentic 工作流。Hermes Agent 文档里显式支持多种 API 模式:

  • chat_completions
  • codex_responses
  • anthropic_messages2

这说明它不是为某一家模型 API 写死的产品,而是在适配“多模型、多协议并存”的现实。换句话说,Hermes Agent 诞生时,外部环境已经不是“哪个模型最强”,而是“不同模型在不同 agent 环节各有所长,编排成为核心能力”。

第二股:用户开始厌倦“一次性聊天”

很多人真正对 agent 产生兴趣,不是因为它回答得更像人,而是因为它终于记得住事、会自己做后续动作、能跨平台继续工作。
Hermes Agent 官方把自己放在服务器、本地和云环境中运行,支持 CLI、Telegram、Discord、Slack、WhatsApp、Signal、Email、Matrix、Mattermost、SMS、DingTalk、Feishu、WeCom 等统一网关12。这本质上是在说:

“AI 不该只活在一个聊天框里,它应该像一个长期在线的数字执行体,出现在你真正工作的地方。”

第三股:OpenClaw 之后,市场需要一个“更工程化、更安全、更可长期运营”的替代方向

从迁移文档看,Hermes Agent 官方明确为 OpenClaw 用户提供了完整迁移路径:hermes claw migrate,并能导入 OpenClaw/ClawDBot/Moltbot 的记忆、用户资料、技能、配置与密钥5。
这件事很关键。它说明 Hermes 不是在一个真空环境里横空出世,而是有意识地承接已有 agent 用户群。也就是说,它不是从零教育市场,而是在一个已经被更早期 agent 产品点燃的需求面前,给出新的工程答案。

所以,Hermes Agent 的诞生背景可以概括成一句话:

当“AI agent”从炫技 demo 进入长期使用阶段,Hermes Agent 试图重新定义这个品类的底层操作系统。


3. 初始形态:一个不是 IDE 插件、不是聊天壳、而是“常驻代理系统”的产品

从官网和 GitHub 的最初自我描述看,Hermes Agent 一开始就没有把自己做成一个轻量插件,而是一个相对完整的运行时系统。它的基本骨架包括:

  • CLI 入口:hermes chat、hermes model、hermes tools6
  • Gateway:统一连接消息平台与外部入口2
  • Agent 核心:AIAgent 与 run_agent.py2
  • Session storage:SQLite + FTS5,保存在 ~/.hermes/state.db2
  • Skills:本地目录化管理,标准文件为 SKILL.md2
  • Memory:MEMORY.md 与 USER.md 双层长期记忆2
  • Cron/automation:内置定时机制1
  • 多 terminal backends:本地、Docker、SSH、Singularity、Modal,文档中还出现 Daytona12

这套初始结构透露出一个非常鲜明的产品判断:

Hermes Agent 不认为 agent 的核心只是“调用一个模型”,而是“围绕模型搭一整套长期运行环境”。

这也解释了为什么 Hermes 从一开始就特别强调 profile isolation、日志、安全审批、容器隔离、跨会话隔离等工程特性2。
如果你只是做一个聊天机器人,这些东西都不是第一优先级;
但如果你想让 agent 真正跑在用户机器、服务器、团队工作流里,这些恰恰是最先会出问题的地方。


4. 早期爆发:为什么它一出来就吸引大量关注

Hermes Agent 在上线后很快获得极高关注度。你此前整理的仓库数据里,抓取时 GitHub 已经达到 75k+ stars、10k forks、4000+ commits6。外部报道则多次提到它在短时间内迅速攀升、成为 OpenClaw 之外最受关注的 agent 项目之一37。

这波爆发不是偶然,背后有几个叠加因素。

4.1 它精准踩中了用户对“更像系统,而不是应用”的期待

很多 agent 项目给人的第一印象是功能炫,但一落到长期使用就散:
今天能自动浏览网页,明天能跑 shell,后天能调 MCP,听起来都很强;
但用户真正要的是:它能不能持续记得我、替我维持状态、在一周后继续同一个任务?

Hermes Agent 正好把“持久化”做成第一性原理。
MEMORY.md 与 USER.md 的设计并不复杂,甚至有点朴素,但这恰恰说明它优先考虑的是可控性与可调试性:你知道记忆放在哪、上限多大、如何被注入到 session、何时冻结成快照2。
这和很多“黑箱长期记忆”方案不同,它更像工程系统,而不是魔法系统。

4.2 它抓住了“技能沉淀”这个非常上瘾的点

官方把 Skills 设计成显式资产:

  • 存在于 ~/.hermes/skills/
  • 以 SKILL.md 为标准格式
  • 兼容 agentskills.io
  • 支持 browse/search/inspect/install/update/audit/uninstall
  • 支持多种 hub:official、github、clawhub、claude-marketplace、lobehub 等2

这里真正聪明的地方是:Hermes Agent 没有把“经验”封装成不可见的参数优化,而是把它转成可以查看、编辑、迁移、分享、审计的技能文件。
这让用户第一次感到:agent 的成长是可见的、可继承的、可协作的。

4.3 它在“开放性”和“工程感”之间找到了一个平衡

很多 agent 项目在开放性上做得很好,但工程治理弱;另一些则很企业化,但不够开放。
Hermes Agent 的路线是:

  • MIT License
  • 支持任意 endpoint
  • 支持 Nous Portal / OpenRouter / OpenAI / Ollama / Gemini 等多 provider128
  • 同时又重视审批模式、安全隔离、日志、配置校验、恶意软件扫描等29

这种组合对开发者很有吸引力。因为它既不像封闭 SaaS 那样把控制权拿走,也不像很多开源项目那样把所有稳定性责任都推给用户。


5. 演进主线:Hermes Agent 不是“加功能”,而是在补齐长期代理的基础设施

如果把 Hermes 的版本演进简单看成“新版本加了哪些功能”,会低估它的发展逻辑。它更像是在快速搭建一座长期代理的城市基础设施:先有道路,再有电力,再有治安系统,再有物流网络。

截至公开资料中的 v0.8.0(v2026.4.8),几个明显的演进方向已经成形。9


5.1 第一条主线:从“能跑起来”到“能长期在线”

早期 agent 最常见的问题不是不会做事,而是跑不久:
会话断掉、状态丢失、任务没法异步继续、平台消息不同步、模型切换麻烦。

Hermes 在 v0.8.0 里加入或强化了这些能力:

  • notify_on_complete:后台任务完成自动通知
  • inactivity-based timeout:闲置超时控制
  • centralized logging:统一日志到 ~/.hermes/logs/
  • config validation:配置校验9

这些改动看起来不像“炫技功能”,但对长期运行非常关键。
因为一个常驻 agent 最大的敌人,从来不是“不够聪明”,而是“不够稳定、不够可观测”。

从这个角度看,Hermes 的决策逻辑很清楚:
先把 agent 变成一个可靠服务,再把它变成一个聪明角色。


5.2 第二条主线:从“单模型绑定”到“多 provider 编排”

Hermes Agent 在模型层面明显走的是中立基础设施路线。
它支持:

  • Nous Portal
  • OpenRouter
  • OpenAI
  • 任意 OpenAI-compatible endpoint
  • Ollama 本地/云模型
  • 新增 Gemini Native Provider189

而且 /model 支持运行中切换模型,全平台 live model switching 在 v0.8.0 被强调9。

这背后的判断其实非常现实:
2026 年的 agent 世界里,不存在一个模型在所有环节都最优。
有的模型擅长长文本规划,有的擅长低成本工具调用,有的更适合本地部署,有的在某些 provider 上更便宜。

所以 Hermes 不押注“唯一最强模型”,而是押注模型切换能力本身成为 agent 的基础能力。
这是一种很像云计算时代的设计思路:
不是把业务绑在某台机器上,而是把调度能力做强。


5.3 第三条主线:从“工具调用”到“代理分工”

Hermes 一个很有辨识度的点,是它不仅能调工具,还能delegate & parallelize,即创建 isolated subagents 来分工处理任务1。
这让它不只是一个“会用工具的 LLM”,而是开始接近“任务执行系统”。

从架构与 issue 线索看,Hermes 已经把不同 delegation 模式显式化,甚至包括 claude-code、codex、hermes-agent 等代理方式的区分讨论10。
这说明团队很清楚:
当 agent 任务变复杂时,真正限制性能的不是单次回答质量,而是任务拆分、并行执行、上下文隔离、子任务回收。

这里的决策逻辑也很明显:
如果 Hermes 真想成为长期代理,而不只是会聊天的助手,它必须学会像一个操作系统那样调度,而不是像一个单线程脚本那样硬跑到底。


5.4 第四条主线:安全从附加项变成主产品能力

Hermes 文档里的安全模型相当完整,官方把它分成七层:

  • user authorization
  • dangerous command approval
  • container isolation
  • MCP credential filtering
  • context file scanning
  • cross-session isolation
  • input sanitization2

再到 v0.8.0 又加上:

  • MCP OAuth 2.1 PKCE
  • OSV malware scanning
  • platform hardening
  • security hardening pass9

这一点非常关键。很多 agent 项目在早期都把安全写成“之后再补”,但 Hermes 明显把它上升到第一层设计。
原因不难理解:
它的目标不是浏览器里的一次性问答,而是能控制终端、接消息平台、长期持有状态、甚至定时执行任务的代理。
这种系统一旦缺安全层,就不是体验问题,而是事故问题。

Hermes 的安全策略不是完全封闭,而是“给你权限,但通过审批模式和隔离层控制风险”:

  • manual
  • smart
  • off
  • YOLO mode 可主动关闭保护2

这说明团队没有天真地认为“用户不需要危险能力”,而是承认现实:
高级用户就会想开大权限。
所以产品要做的不是禁止,而是把风险的边界画清楚。


5.5 第五条主线:从“自己长”到“能迁移、能继承、能兼容生态”

Hermes 很聪明的一步,是没有把自己做成一个孤岛。

在 Skills 上,它兼容 SKILL.md 及多个 hub 来源;
在 Memory 上,它允许接入 Honcho、Mem0、Supermemory 等外部 provider;
在迁移上,它明确支持从 OpenClaw 体系导入记忆、配置、技能和 secrets25。

这意味着 Hermes 的野心不是只做一个“新项目”,而是试图成为一个上层兼容层。
它希望用户不是“重装人生”才能换 agent,而是带着自己的历史、习惯和技能资产迁移过来。

这个决策很重要。因为长期代理的壁垒,不只是模型能力,而是用户积累资产的可携带性。
Hermes 在这点上显然想得很明白:
一旦用户的记忆、技能、路由、平台接入、工作流都沉淀在系统里,迁移成本会越来越高;
但前提是,第一次迁移必须足够丝滑。


6. 关键节点:v0.8.0 为什么是一个阶段性拐点

从版本节奏看,Hermes 在很短时间里快速迭代,而 v0.8.0(2026-04-08) 是一个很典型的“从爆款项目走向平台化”的节点。9

这个版本的亮点表面很多,但如果抽象一下,可以归为四个信号:

信号一:它开始正式补后台运行体验

notify_on_complete、timeout、日志集中化——这说明产品不再只围绕“前台对话”,而是在为异步、长期、不可见执行做体验闭环。

信号二:它开始把 provider 管理做成一等公民

Gemini Native Provider、OpenRouter/Nous Portal 定价显示、free-tier 模型入口、live switching——这标志着它把“模型接入”从技术配置变成用户体验层功能。

信号三:它把平台审批和安全治理更深地嵌到消息入口里

Slack/Telegram approval buttons 很能说明问题:
Hermes 不只是把消息平台当输入通道,而是把它们当 agent 治理界面。
用户不一定要回到本地终端批准动作,可以在消息端完成审批,这对真正的长期代理非常关键。

信号四:它开始从一个 agent 项目,长成一个插件平台

plugin system expansion 不只是加插件,而是在暗示:
Hermes 团队逐渐接受一个现实——长期代理的所有需求不可能靠官方核心仓库覆盖,必须把扩展性做出来。9

所以,v0.8.0 的意义不是“又多了几个 feature”,而是:
Hermes 从‘有想法的 agent’开始迈向‘有平台气质的 agent runtime’。


7. 源码和架构透露的组织思路:Hermes 想做的更像“Agent OS”

看 Hermes 的源码结构,会发现它并不是那种“把所有能力塞进一个 orchestrator 文件”的实验项目。
关键目录与文件——如 run_agent.py、model_tools.py、toolsets.py、gateway/、cron/、plugins/memory/、plugins/context_engine/、skills/——已经体现出比较明确的边界划分。2

这种划分对应着几个产品层:

  1. Agent brain:推理、规划、工具调用
  2. Execution environment:terminal backends、container、remote execution
  3. Persistence layer:state.db、memory files、sessions
  4. Ingress/egress layer:CLI、gateway、ACP adapter
  5. Learning layer:skills、memory、trajectory export、RL 训练接口
  6. Security/governance layer:approval、scanning、credential filtering、logs

这个结构特别像一个“agent operating environment”,而不是一个单纯应用。
也正因此,它和传统 IDE agent 最大差别之一是:
它的世界不是一个编辑器窗口,而是整个用户环境。


8. 约束与代价:Hermes 为什么没有把一切都做成最简单

Hermes 的路线有明显优势,但也伴随代价。

8.1 它天然更复杂

当一个系统同时拥有:

  • 多模型 provider
  • 多 terminal backend
  • 多消息平台 gateway
  • memory + skills + cron + plugins
  • 审批、安全、容器、日志

它就不可能像一个单文件 CLI 工具那样轻。
官方虽然提供 hermes setup 和安装脚本降低门槛6,但 Hermes 本质上仍然是一个可运营系统,不是极简玩具。

8.2 文档和实现还处在快速变化期

你前面已经发现一些口径差异:

  • 工具数量有 47 / 48 两种说法
  • terminal backends 有 5 / 6 两种口径12

这通常不是原则性问题,而是快速迭代项目常见的“文档更新速度追不上实现变化”。
它反过来也说明:Hermes 还远没有进入稳定企业软件阶段,仍然处于高速进化期。

8.3 它的价值高度依赖“长期使用”

Hermes 最强的地方——记忆、技能、自我优化——都不是“5 分钟就能感知”的能力。
这意味着它对新用户的第一印象,反而未必像即时见效的 coding agent 那么炸裂。
它更像一种复利型产品:
用得越久,越能体现差异;但前提是用户愿意先投入搭建和使用习惯。


9. 到今天为止,Hermes Agent 已经成了什么

如果把这段发展史压缩成一句话:

Hermes Agent 从一开始就不是想做“一个更强的 AI 对话工具”,而是在用开源方式搭一套长期存在、可自我积累、可跨平台运行的 agent 基础设施。

截至 2026 年 4 月,它已经表现出几个明确特征:

  • 它是一个模型中立的 agent runtime,而不是某家模型厂商的外壳;
  • 它是一个长期状态系统,而不仅是“更会调用工具的聊天机器人”;
  • 它是一个兼顾开放性与治理能力的工程平台;
  • 它正在从“爆红项目”向“生态平台”过渡;
  • 它和 OpenClaw 并不是简单替代关系,更像是在同一个大方向上给出不同答案:一个更偏广覆盖和外部生态,一个更偏长期成长和系统内化。

二、横向分析:Hermes Agent 在同赛道里处于什么位置

Hermes Agent 所在赛道并不空。它至少同时站在三个竞争面前:

  1. 长期自主代理框架:如 OpenClaw
  2. 开发者/代码导向 agent:如 Claude Code、Codex 类工具
  3. 更通用的 agent 执行系统/多代理框架:如 OpenHands 一类

因此这里属于你定义中的 场景 C:竞品充分。
我选取 4 个最具代表性的参照对象:

  • OpenClaw
  • Claude Code
  • OpenHands
  • Codex / Codex-style coding agents

其中,OpenClaw 是最核心的正面对手;其余几个更像“相邻生态位”。


1. Hermes Agent vs OpenClaw:最像正面战争,但其实路线不同

如果只看外界舆论,Hermes 最常被贴上的标签就是“OpenClaw 替代品”。这标签不能说错,但不够准确。

1.1 两者最接近的地方:都想把 agent 从聊天框里解放出来

Hermes 与 OpenClaw 的共性很明显:

  • 都是开源 agent 框架
  • 都强调长期运行与跨平台入口
  • 都不满足于“只做代码助手”
  • 都在尝试把 AI 变成一个可以执行真实任务的实体357

这也是为什么 Hermes 官方专门做了 OpenClaw 迁移工具。
因为它们争夺的是同一批已经理解 agent 价值的人:
不是来试玩模型的,而是想让 AI 真正接管部分工作流的用户。

1.2 真正的差异:OpenClaw 更像“连接性平台”,Hermes 更像“成长性系统”

从公开资料与第三方对比来看,OpenClaw 的强项长期在于:

  • 覆盖面广
  • 平台集成多
  • 社区大
  • 上手路径更成熟37

而 Hermes 的差异化在于:

  • persistent memory 的叙事更核心
  • auto-generated skills 是产品哲学中心
  • 自我优化/学习闭环被放到第一位
  • 安全与治理被写进系统设计,而非附加模块129

简单说:

  • OpenClaw 的问题意识:怎么让 agent 去更多地方、干更多事
  • Hermes 的问题意识:怎么让同一个 agent 在时间中越来越有用

这不是小差别,而是路线分岔。

1.3 用户为什么选 OpenClaw

真实用户选择 OpenClaw,往往不是因为它“理念更高级”,而是因为它更像一个已经铺开的世界:
平台多、生态多、参考案例多、社区讨论多。
如果你的第一诉求是“赶紧把 agent 接进一堆平台和自动化流程里”,OpenClaw 的现成度通常更强。

1.4 用户为什么转向 Hermes

而选 Hermes 的用户,往往在意的是另一件事:
这个 agent 会不会随着使用真正变成我的东西。

这也是 Hermes 迁移工具存在的意义。它在对用户说:
你不是要重新换一个玩具,而是把之前积累的“人格、记忆、技能和习惯”迁过来,继续长。

1.5 口碑层面的差别

从第三方报道和讨论看,Hermes 的高频优点包括:

  • 更强调长期记忆
  • 自生成技能更有“成长感”
  • 安全治理叙事更完整
  • provider 更灵活37

常见顾虑则是:

  • 系统复杂
  • 需要配置与维护
  • 快速迭代带来文档口径差异
  • 真正价值要长期使用后才能显现

OpenClaw 则常被认为:

  • 覆盖广、平台多、声量大
  • 生态成熟
  • 更适合“我先全都接起来”
    但弱点在于:
  • 如果用户核心诉求是“长期个体化成长”,Hermes 的故事更打人

1.6 生态位判断

在赛道版图里,OpenClaw 更像一个广覆盖型超级入口;
Hermes 更像一个高复利型长期代理内核。

如果未来 agent 市场分化,这两类产品甚至可能长期共存,而不一定只有一个赢家。
因为它们优化的并不是完全同一个目标函数。


2. Hermes Agent vs Claude Code:一个是“代理系统”,一个是“代码工作界面”

把 Hermes 和 Claude Code 放在一起比较,最容易看出 Hermes 的边界。

2.1 Claude Code 的强项:把 coding agent 体验做到极顺

Claude Code 一类工具的优势很明确:

  • 聚焦软件开发工作流
  • IDE / repo / shell 场景极强
  • 对开发者来说,反馈快、路径短、结果立竿见影

用户用 Claude Code,往往是为了今天就把一个 bug 修了、一个重构做了、一个 PR 过了。
它的设计目标是把开发活动本身变流畅。

2.2 Hermes 不把自己限制在“开发行为”里

Hermes 当然也能做代码、能进终端、能 delegation、能调工具。
但它真正的目标不是“让开发更高效”,而是“让 agent 成为长期工作实体”。

这意味着 Hermes 的应用范围更广:

  • 日程与消息平台
  • 定时任务
  • 研究任务
  • 跨会话用户模型
  • 多入口通信
  • 记忆与技能沉淀

所以两者不是简单替代关系。更准确的说法是:

  • Claude Code:把 AI 嵌进开发者的现有工作界面
  • Hermes Agent:试图把 AI 变成一个独立存在的执行体,再去连接各个界面

2.3 用户真实选择逻辑

如果你是一个纯开发者,目标非常明确:
“我需要一个今天就能提高 coding throughput 的助手。”
Claude Code 通常更直接。

但如果你的需求是:
“我希望有一个长期在线、会记事、能跨平台沟通、还能顺手写代码的 agent。”
Hermes 才会显得更对味。

2.4 短板比较

Hermes 相对 Claude Code 的短板在于:
它不是围绕 IDE 极致打磨出来的体验;
它强在系统性,而不是单一 coding 界面的摩擦最小化。

换句话说,Claude Code 更像一把极锋利的手术刀;
Hermes 更像一整套可以常驻运转的工作站。


3. Hermes Agent vs OpenHands:一个偏“任务执行系统”,一个偏“长期人格化代理”

OpenHands 这类系统,代表的是另一种 agent 方向:
更重任务执行、更强调 benchmark、环境操作、代码修复、自动完成复杂开发任务。

3.1 OpenHands 的世界观

OpenHands 类产品往往把 agent 理解成一个高能力执行器:
你给它任务,它自己去浏览、编码、运行、修复。
它很适合用来展示 agent 在复杂任务链上的能力上限。

3.2 Hermes 的世界观不完全一样

Hermes 也做执行,但它多了一层“长期关系”的设定:

  • USER.md / MEMORY.md
  • skills 沉淀
  • gateway 平台常驻
  • cron 自动化
  • profile isolation
  • session search2

这让 Hermes 更像一个与你共处的长期代理,而不是一个接到任务就开始冲刺的执行引擎。

3.3 用户口碑差异

选择 OpenHands 的用户,通常更看重:

  • 自动完成复杂技术任务的能力
  • agent benchmark 表现
  • 软件工程任务链上的强执行

选择 Hermes 的用户,则更在意:

  • 是否会记住我和过去
  • 是否能在多入口下保持一个连续身份
  • 是否会沉淀技能和习惯
  • 是否适合长期部署

3.4 生态位

OpenHands 更像“高性能任务机器人”;
Hermes 更像“长期关系型代理”。
如果把 agent 看作未来的软件形态,OpenHands 在强调“能力峰值”,Hermes 在强调“时间复利”。


4. Hermes Agent vs Codex / Codex-style coding agents:不是同一主赛道,但会争夺开发者时间

Codex-style agent 的最大优势,是高度贴近代码生产场景。
它们经常被用于:

  • 代码生成与修复
  • 测试
  • repo 级上下文理解
  • shell 操作
  • PR 辅助

Hermes 当然也可以接这类场景,甚至 issue 中已讨论与 Codex delegation 的结合10。
但 Hermes 不会在“专用 coding 体验”上天然领先,因为它的注意力分散在更大的系统版图里。

不过,Hermes 对这类工具也并不是纯粹被动竞争。
它有一个聪明的策略:把这类 agent 当成可调用子能力,而不是非要正面打穿。

这意味着 Hermes 完全可能形成一种上层定位:

  • 自己负责长期记忆、任务路由、平台入口、安全治理
  • 把特定 coding 子任务委托给 Claude Code / Codex / 其他 specialized agents

如果这条路走通,Hermes 就不是和所有专业 agent 正面打,而是站在更高一层调度它们。


三、横向对比表:一句话看懂 Hermes 的位置

维度Hermes AgentOpenClawClaude CodeOpenHandsCodex-style Agents
核心定位长期成长型自主代理广覆盖型 agent 平台开发者代码助手/界面高执行力任务 agent专用 coding agent
主叙事记忆 + 技能 + 自我改进平台接入 + 生态 + 广覆盖提升 coding throughput自动完成复杂技术任务代码执行与修复
时间维度强中-强中中中
跨平台常驻很强很强弱中弱
记忆系统核心卖点有,但非唯一中心有限较弱/非核心通常非核心
技能沉淀核心卖点有生态,但不如 Hermes 强叙事非核心非核心非核心
安全治理明确系统级设计视实现而定相对成熟但场景更窄偏任务执行治理偏开发场景治理
上手门槛中-高中低-中中低-中
最适合谁想长期养一个 agent 的用户/团队想快速铺平台与生态的用户纯开发者自动任务导向开发者以代码产出为第一目标的用户

四、趋势判断:Hermes Agent 接下来最可能怎么走

1. 它最大的机会:把“长期代理”从概念做成真实品类

Hermes 最值钱的地方,不是又多支持几个平台,也不是再多一个模型 provider。
而是它有机会把一个此前很模糊的需求做清楚:

用户要的不是一次性更聪明的 AI,而是一个长期越来越懂自己、越来越能代办事情的数字代理。

如果 Hermes 持续把 memory、skills、delegation、gateway、cron、安全治理整合好,它会成为这个品类最清晰的代表之一。

2. 它最大的风险:复杂度吞掉增长

Hermes 的问题不是没功能,而是功能太容易长成系统复杂度。
当一个产品既想:

  • 做多模型
  • 做多平台
  • 做技能市场
  • 做长期记忆
  • 做插件
  • 做安全治理
  • 做迁移兼容

它很容易进入“每一项都重要,但新用户不知道先感知哪个”的困境。

所以 Hermes 接下来能不能继续扩张,取决于它能否把复杂系统包装成足够顺滑的默认体验。

3. 它最聪明的战略方向:做 agent runtime,而不是和所有垂直 agent 抢单点体验

Hermes 如果执意在每个子场景都打赢专业工具,成本会非常高。
更好的路可能是:

  • 继续做长期记忆与身份连续性
  • 做多平台入口与治理
  • 做技能沉淀与可迁移资产
  • 把 Claude Code、Codex、OpenHands 一类工具吸纳为 delegation target

这样 Hermes 就不只是一个 agent,而是一个agent 之上的协调层。

4. 对企业与团队市场的潜力

Hermes 现在看上去更像开发者/极客项目,但它的一些特性其实很适合团队化:

  • profile isolation
  • centralized logs
  • approvals
  • credential filtering
  • gateway
  • plugin system
  • external skills dirs29

如果未来文档、部署、权限管理进一步成熟,它很可能从个人长期代理,延伸到小团队或组织级 agent runtime。


五、横纵交汇:Hermes Agent 现在到底站在哪儿

Hermes Agent 最值得注意的地方,不是它“像谁”,而是它试图修正过去几波 agent 热潮里最根本的缺口。

过去的 AI 工具,大多有两个问题:
一类擅长单次交互,但没有连续人生;
另一类能跑复杂流程,但每次都像失忆后重新开工。
Hermes 想解决的是这个断裂:
让代理既能执行,又能积累;既能跨平台行动,又能保持同一个长期身份。

这也是为什么它的纵向发展和横向竞争,其实指向同一个结论。

从纵向看,Hermes 的每一步演进——记忆、技能、迁移、provider 中立、delegation、安全治理、日志、cron——都不是随机堆 feature,而是在补一套“长期代理基础设施”的骨架。
从横向看,它与 OpenClaw、Claude Code、OpenHands、Codex-style tools 的差别,也不只是功能列表不同,而是优化目标不同:

  • OpenClaw 更强调广连接和生态铺设;
  • Claude Code / Codex 更强调单场景产能;
  • OpenHands 更强调复杂任务执行;
  • Hermes 最鲜明的目标,是让 agent 在时间里形成复利。

因此,Hermes 当前的真实位置,我会这样判断:

1. 它不是“另一个 coding agent”,而是“长期代理操作层”的候选者

这决定了它的成败标准,不能只看短期 demo 效果,而要看:

  • 长期稳定性
  • 资产沉淀能力
  • 迁移与兼容
  • 用户是否愿意把更多日常工作交给它

2. 它现在已经有了很强的叙事和很快的工程推进,但仍处于高速塑形期

GitHub 热度、版本速度、外界关注,都说明 Hermes 已进入主流开发者视野。
但口径差异、功能快速扩张、复杂度上升,也说明它离“成熟平台”还有路要走。

3. 如果未来 agent 市场真的从“短会话工具”升级到“常驻数字代理”,Hermes 会是非常有代表性的基础设施玩家

尤其是在开源生态中,它已经明确占住了一个位置:
不是最轻、不是最窄、也不是最现成,但可能是最认真在搭长期代理系统的人之一。

4. 最后的判断

Hermes Agent 当前最有价值的,不是某个具体 feature,而是它正在证明一件事:

AI agent 的护城河,不一定来自更强的模型,也可以来自更长的时间维度。

谁能让 agent 真正记住、沉淀、迁移、治理、持续存在,谁就更接近下一代软件形态。
在这条路上,Hermes Agent 现在还谈不上“已经赢了”,但它已经非常清楚自己在打什么仗,而且比很多竞争者更早把战场选对了。


参考来源


来源链接

贝叶斯主义:一套关于“不确定性”的世界观,如何从哲学争论变成现代推断机器

Screenshot

一、纵向分析:贝叶斯主义是如何长成今天这个样子的

1. 起点:它不是先从“统计技术”开始的,而是从“人在不确定中如何相信”开始的

如果只看今天的教科书,贝叶斯主义似乎很容易被理解成一条公式:

P(H∣E)=P(E∣H)P(H)P(E)

也就是:看到证据 EE 之后,如何更新对假设 HH 的相信程度。
但这条公式之所以重要,不是因为它长得漂亮,而是因为它回答了一个更古老的问题:人在证据不完整的时候,应该怎样形成和修正自己的信念?

这背后其实有三条不同但后来汇合的线索:

  1. 数学线索:概率能不能被严格地当作一个演算系统?
  2. 哲学线索:信念能不能被量化?“相信多少”是否可以用概率表示?
  3. 实践线索:在数据有限、样本不完整、未来不可知的时候,怎样做决策?

贝叶斯主义最后之所以影响如此之大,正是因为它把这三条线拧在了一起。
它不是单纯的统计技巧,而是一种关于不确定性、知识、证据、行动的统一框架。[^^1][^^2]


2. 18世纪的原点:Thomas Bayes 的问题意识,比后人记住的公式更重要

贝叶斯主义得名于 Thomas Bayes。1763年,在他去世后发表的论文《An Essay towards solving a Problem in the Doctrine of Chances》中,Bayes 讨论的核心问题并不是“如何做贝叶斯回归”,而是更原初的事情:
已知观察结果,如何反推未知原因的概率?

这件事在当时很不寻常。17—18世纪的概率论,更多是在处理赌博、组合、事件发生的机会。也就是说,传统方向往往是:

  • 已知机制
  • 推算结果概率

而 Bayes 所碰的,是反过来的方向:

  • 已知结果
  • 推测背后机制的可信程度

这一步非常关键,因为它把概率从“事件频率的描述”往“未知世界的反推工具”推进了一大步。

不过,历史上真正把这条路走宽的,其实不是 Bayes 本人,而是 Pierre-Simon Laplace。Laplace 在 18 世纪末到 19 世纪初系统扩展了这一思想,把逆概率(inverse probability)方法真正发展成一套可用于天文学、人口统计、测量误差分析的推断体系。[^^3][^^4]

这里有个很重要的历史事实:
早期并没有“Bayesian”这个统一标签。
很长一段时间里,人们更常用的词是 inverse probability(逆概率)。也就是说,当时这套方法并不以“贝叶斯主义”自居,而是作为一种从结果反推原因的推断方式存在。Fienberg 的研究专门指出,“Bayesian”这个术语其实是 20 世纪才逐渐稳定普及的。[^^4]

这说明一个有趣的现象:
贝叶斯主义并不是某一天被“发明”出来并立刻成形的,它更像是一条后来被重新命名、重新解释、重新包装的思想谱系。


3. Laplace时代:真正把“逆概率”推成通用推理机器的人

如果 Bayes 提供了种子,那么 Laplace 更像是把它种成森林的人。

Laplace 的野心比 Bayes 大得多。他面对的是启蒙时代的核心信念:
自然界有秩序,而数学可以揭示这秩序。

在这个背景下,概率不只是赌博学问,而是处理无知、误差、不完整知识的数学工具。
Laplace 把概率扩展为一种普遍的理性技术:在信息不完备时,理性主体仍然可以通过演算来逼近真相。

这一步奠定了后来贝叶斯主义最深的一层气质:
它从来不是只关于“统计模型”,而是关于有限理性如何在不确定世界中运作。

Laplace 的工作还推动了一个后来一直争议不断的传统:
在没有足够信息时,如何设定先验?

启蒙时代倾向于相信“无差别原则”——如果没有理由偏向某个可能性,就应给予相等权重。这个直觉后来成为很多贝叶斯先验构造的原始灵感,但也埋下了长期争议:
所谓“没有理由偏向任何一方”,真的是中立吗?
你换一个参数化方式,所谓“均匀先验”还均匀吗?

后来的“先验问题”(problem of the priors),根子其实在这里就已经埋下了。[^^1][^^2]


4. 19世纪到20世纪初:它曾经不是主流胜者,而是一套在争议中存活的方法

如果把今天的视角投回去,很容易误以为贝叶斯主义一路高歌猛进,最后胜出。
实际历史恰恰复杂得多。

19世纪后半到20世纪上半,统计学逐步制度化、职业化,现代统计学科开始形成。这个阶段,频率学派(frequentism) 的地位越来越强。其代表性人物包括 Ronald Fisher、Jerzy Neyman、Egon Pearson 等。

为什么频率学派能压过逆概率传统?原因至少有三层:

第一层:科学客观性的时代偏好

19世纪末和20世纪初的科学文化越来越强调“客观性”。
而贝叶斯/逆概率方法里最扎眼的一点,恰恰是先验。
一旦允许研究者在数据之前就引入主观判断,那么科学会不会变成“带着立场算答案”?

频率学派在这里显得更“干净”:

  • 参数是固定的、未知的
  • 概率只属于可重复抽样过程
  • 推断标准尽量依赖样本分布而不是主观信念

这和那个时代对“去人格化科学”的追求高度一致。

第二层:方法论操作性更强

显著性检验、置信区间、最大似然等工具,给了统计学一整套标准化流程。
这些流程容易教学、容易复制、容易嵌入实验科学制度。

第三层:计算资源限制

贝叶斯方法即使在理念上诱人,很多真实问题也会卡在积分算不动。
你可以写出后验分布,但往往求不出来。
而频率学派不少方法在数学和计算上更可操作。

因此,在相当长时期里,贝叶斯方法并非消失,而是处于一种理论上顽强存在、制度上相对边缘化的状态。[^^3][^^4]


5. 20世纪上半:从“逆概率算法”转向“主观信念逻辑”

贝叶斯主义真正发生质变,是在它不再只被当作一套统计技巧,而开始被解释为一种理性信念的规范理论。

这一步的关键人物包括:

  • Frank Ramsey
  • Bruno de Finetti
  • Leonard Savage

他们完成了一个极其重要的转向:
贝叶斯主义不再只是“从数据反推参数”的数学程序,而是变成了对如下命题的回答:

一个理性主体的信念,如果要避免自我矛盾,应当满足什么结构?

Ramsey:信念可以通过偏好和下注行为刻画

Ramsey 的思路很革命:
你不用先问“信念是不是一种神秘心理状态”,而可以看一个人在赌局、选择、偏好中如何表现。
如果他的偏好满足某些一致性条件,就可以把这些偏好表示为概率和效用。

de Finetti:概率不是世界的客观属性,而是主体的可信度

de Finetti 把主观概率推进到了前台。
在他那里,概率不是外部世界里长出来的自然刻度,而是主体对命题的可信程度(degree of belief)。
著名的 Dutch Book argument(荷兰书论证) 则提供了一种一致性约束:
如果你的信念不能用概率公理表示,别人就可以构造一组赌局,保证你无论如何都输钱。
也就是说,不满足概率法则的信念系统会在行为上暴露为不一致。[^^1]

Savage:主观主义与决策理论的系统整合

Savage 把这些想法进一步系统化。他关心的不只是“你相信什么”,更是“在不确定下你如何行动”。
由此,贝叶斯主义开始和期望效用理论深度耦合。
概率不再只服务于认识论,也服务于决策。

这是贝叶斯主义历史上的大转弯:
它从“逆概率”变成了“主观信念 + 规范更新 + 理性决策”的完整框架。
也正是在这个阶段,贝叶斯主义的哲学野心被真正抬高了。[^^1][^^4]


6. 贝叶斯认识论的成形:不是“会不会算”,而是“应该怎样信”

到了 20 世纪中后期,贝叶斯主义在哲学中形成了比较清晰的规范结构。
Stanford Encyclopedia of Philosophy 对 Bayesian Epistemology 的概括非常经典:它至少包含两条核心规范。[^^1]

规范一:Probabilism(概率主义)

理性主体的信念度(credence)应当服从概率公理。
也就是说,一个人的“相信多少”不应是散乱的情绪,而应能组成一个概率分布。

规范二:Principle of Conditionalization(条件化原则)

当你获得新证据 EE 时,新的信念应当由旧信念按条件概率更新:Crnew(H)=Crold(H∣E)Crnew​(H)=Crold​(H∣E)

这条原则极其重要,因为它把“学习”刻画成一个数学更新过程。
从此,理性不再只是静态一致,而是动态一致:
你不仅要在一个时点上不自相矛盾,还要在时间中以合乎规则的方式修正自己。

这套理论之所以迷人,是因为它把很多哲学老问题统一到了一个框架里:

  • 归纳推理如何可能?
  • 证据如何确认理论?
  • 观察如何改变信念?
  • 什么样的信念更新才算理性?

但它的问题也随之浮现:

  • 先验从哪里来?
  • 如果不同主体先验不同,是否会得出无法调和的结论?
  • 条件化原则是否适用于所有信息更新?
  • 人类真实思维根本不遵守这些规则,这会不会削弱其规范性?

因此,贝叶斯认识论从来不是“完胜”的哲学,而是一套极强、但也持续被围攻的规范方案。[^^1]


7. “先验问题”:贝叶斯主义最强的地方,也是最常被攻击的地方

贝叶斯主义最有辨识度的特征是 prior(先验)。
它允许你把“看到数据之前的已有知识、经验判断、结构假设”写进模型。
这在实践上很有价值,因为现实世界很少从一张白纸开始。

但也正是这里,批评最猛烈。

为什么先验会被攻击?

因为它看起来让推断“带偏见”。
如果你一开始就假定某个理论更可信,那结果会不会只是把偏见公式化?

贝叶斯主义的回应

贝叶斯主义通常有几种回应路径:

  1. 所有推断都有前提,只是很多方法把前提藏起来了。
    与其假装客观,不如把假设显式写出来。
  2. 数据量足够大时,先验影响会减弱。
  3. 可以使用非信息先验、弱信息先验、参考先验等方式降低主观性。
  4. 在很多高风险或小样本场景中,利用领域知识反而比“装作没有先验”更诚实。

但反对者并不完全买账。
他们会指出:

  • 所谓“非信息先验”并不真正中立;
  • 参数化变化会改变“平坦性”;
  • 在复杂模型和小样本中,先验对结果可能极敏感。

SEP 对此讨论得很清楚:先验问题不是边角料,而是贝叶斯主义的核心哲学难题之一。[^^1]


8. 从哲学走回统计:20世纪后期的“新贝叶斯复兴”

如果说 20 世纪上半是贝叶斯主义在哲学上壮大,那么 20 世纪后期,它在统计实践中迎来了真正的大复兴。

这场复兴并不主要靠“哲学说服”,而是靠两个现实变化:

第一,计算能力终于追上了理论野心

很多贝叶斯问题之所以过去难做,不是因为思想不对,而是因为积分太难。
后验分布往往没有解析解。
随着计算机发展,以及 Markov chain Monte Carlo (MCMC) 等算法成熟,原本写在纸上求不出的后验,终于可以数值逼近。[^^3]

第二,现实问题越来越需要层级、不确定、部分信息整合

在医学、生态学、社会科学、工程、金融等场景里,研究者发现:
世界不是干净的、独立同分布的小样本实验室。
真实问题往往具有:

  • 多层结构
  • 缺失数据
  • 先验知识
  • 小样本
  • 需要顺序更新
  • 需要预测分布而不仅是点估计

这些正是贝叶斯方法擅长的地带。

因此,贝叶斯主义的复兴不是偶然,而是“问题复杂度”和“计算工具”共同推出来的。
Wikipedia 对贝叶斯统计的概述里也明确提到,20 世纪后期的兴起与计算能力、尤其是 MCMC 的普及密切相关。[^^3]


9. 现代贝叶斯统计的成型:从“公式”变成“建模语言”

到了今天,贝叶斯统计已经不只是 Bayes 定理本身,而是一整套建模范式。
它的基本结构通常写成:

  • Prior:你原本怎么想
  • Likelihood:如果假设为真,数据长什么样
  • Posterior:看到数据后,你现在怎么想
  • Evidence / Marginal likelihood:模型解释数据的整体能力

贝叶斯统计的核心不只是“计算后验”,而是把模型当成一台不确定性组织机器。
它擅长回答的不只是“参数估计值是多少”,而是:

  • 这个参数多大概率落在某区间?
  • 新样本会长什么样?
  • 哪个模型更能解释数据?
  • 不同信息源如何融合?
  • 在不完整信息下应如何做决策?

于是,贝叶斯统计在方法层面长出了非常多分支:

  • 层级贝叶斯模型
  • 贝叶斯网络
  • 贝叶斯非参数
  • 贝叶斯模型比较(如 Bayes factor)
  • Approximate Bayesian Computation
  • Variational Bayes
  • Sequential Bayesian updating

它早已不是一条公式,而是一整套关于建模、更新、预测、决策的语法。


10. 进入机器学习时代:贝叶斯主义重新被解释为“对不确定性的尊重”

在机器学习和深度学习的世界里,贝叶斯主义迎来又一次转义。

早期机器学习更关注预测精度和优化表现,很多模型更像“黑箱函数逼近器”。
但随着系统被部署到高风险场景——医疗、自动驾驶、金融风控、科学发现——一个问题越来越突出:

模型不仅要给出答案,还要告诉我们它对答案有多不确定。

这正是贝叶斯思想最擅长的事。
它天然把参数、结构、预测都放进概率分布中思考,而不是只给一个点值。

因此,现代机器学习里“贝叶斯”的价值主要集中在几件事上:

  1. uncertainty quantification(不确定性量化)
  2. 小样本学习与先验注入
  3. 模型平均与结构选择
  4. 在线更新
  5. 避免把偶然模式误当成确定规律

这也催生了许多具体技术方向:

  • Bayesian neural networks
  • Variational inference
  • Monte Carlo dropout(某种近似贝叶斯解释)
  • Probabilistic programming
  • Active learning / Bayesian optimization

在这个阶段,贝叶斯主义被重新包装成一种现代工程语言:
不是“主观信念形而上学”,而是“如何让模型知道自己不知道”。

这非常重要,因为它说明贝叶斯主义能够跨越时代:
它可以用 18 世纪的形式处理赌博问题,也可以用 21 世纪的形式处理深度模型的不确定性。


11. 但它并没有统一天下:贝叶斯主义今天仍然活在争论里

尽管贝叶斯方法复兴明显,贝叶斯主义并没有终结其他范式。
原因很简单:它的强大和麻烦是同一枚硬币的两面。

它的强大之处在于:

  • 可以自然表达不确定性
  • 能整合先验知识与数据
  • 适合顺序学习
  • 预测解释统一
  • 在复杂分层问题中很强

它的麻烦在于:

  • 先验选择始终有争议
  • 复杂模型计算成本高
  • 近似推断可能引入额外偏差
  • 结果对建模选择敏感
  • 对不熟悉概率建模的使用者门槛高

所以,贝叶斯主义今天的真实状态,不是“彻底胜利”,而是成为了一种极其重要、影响深远、但并非无可替代的方法论中心。


二、横向分析:贝叶斯主义在今天的方法论版图中,究竟站在哪里?

对于“贝叶斯主义”这种研究对象,最适合的横向比较对象不是某几个公司,而是同属“处理不确定性与推断”的几类范式。
这里属于 场景C:竞品充分(3个及以上)。
我选取四类最有代表性的对照对象:

  1. 频率学派(Frequentism)
  2. 似然主义(Likelihoodism)
  3. 经典逻辑/演绎主义科学观
  4. 现代数据驱动黑箱预测范式(尤其非贝叶斯机器学习)

1. 贝叶斯主义 vs 频率学派:最经典、也最纠缠的一场对决

这是最常见的对比,因为两者都在回答同一个问题:
如何从数据走向推断?

表面对立:他们对“概率是什么”理解不同

  • 贝叶斯主义:概率可以表示主体对命题的信念度(degree of belief)。[^^1][^^3]
  • 频率学派:概率主要是可重复试验中的长期相对频率。

这个差别不是语义游戏,而是会一路传导到推断方式。

对参数的看法不同

  • 贝叶斯:参数本身可以是随机变量,因为“随机”在这里表示认知不确定性。
  • 频率学派:参数是固定但未知的,随机性只来自样本抽样过程。

对区间的理解不同

  • 贝叶斯可信区间:给定数据和模型后,参数落在区间内的概率是多少。
  • 频率置信区间:如果无限次重复抽样,这种构造区间的方法有多高比例会覆盖真值。

这也是很多初学者最容易混淆的地方:
两种区间形式看起来像,解释其实完全不同。

用户为什么会选频率学派?

真实世界里,很多研究者选频率学派,不是因为他们深信“长期频率”哲学,而是因为:

  • 教科书和训练体系更成熟
  • 领域期刊默认接受
  • 方法标准化程度高
  • 计算更便宜
  • 审稿人更熟悉 p 值、显著性、置信区间

换句话说,频率学派的生态优势非常强。
它很多时候赢的不是思想吸引力,而是制度惯性。

用户为什么会选贝叶斯?

通常是因为他们遇到了频率方法难处理的场景:

  • 样本小
  • 需要融入先验知识
  • 关注预测分布而非单点
  • 需要层级结构
  • 需要顺序更新
  • 希望结果解释更直观

社区口碑上的真实差异

频率学派经常被吐槽:

  • p 值容易被滥用
  • “显著/不显著”二元划分粗暴
  • 很多研究者把置信区间误读成可信区间
  • 假设检验文化导致“结果导向统计”

贝叶斯则经常被吐槽:

  • 太依赖建模者功力
  • 先验“看起来像人为调参”
  • 算法重、算得慢
  • 容易给人一种“什么都能包进模型,所以怎么说都行”的印象

生态位判断

如果说频率学派像工业时代建立起来的标准统计语言,那么贝叶斯主义更像复杂世界里的柔性推断语言。
前者强调程序可复现、标准统一;后者强调信息整合、解释连贯。

它们今天并不是简单替代关系,更像是:

  • 在高标准、低复杂度、大样本场景,频率方法仍然非常强
  • 在高复杂度、小样本、强先验、高决策成本场景,贝叶斯更占优

2. 贝叶斯主义 vs 似然主义:一场更“内行”的争论

和频率学派相比,似然主义(Likelihoodism) 更像是一个专业圈内的竞争者。
它也不完全接受频率学派的一套,但又不愿像贝叶斯那样引入完整先验。

似然主义的核心直觉是:
数据对假设的支持程度,可以由似然函数表达。
你不一定要谈主观信念,也不一定要谈长期重复抽样,只要比较不同假设对已观察数据的解释力就行。

它对很多人有吸引力的原因

  • 比频率学派更贴近“证据支持度”的直觉
  • 又没有贝叶斯那样明显的先验争议
  • 在模型比较问题上有很强解释力

但它的问题也明显

  • 它擅长比较已给出的假设,却不一定能完整回答“更新后相信多少”
  • 缺少贝叶斯那种从 prior 到 posterior 的动态学习闭环
  • 在决策和预测上,不如贝叶斯框架完整

所以从生态位看,似然主义像是一个理论上优雅、但应用面没有贝叶斯那么宽的对手。
它在方法论上提供了很好的批评镜子:提醒人们不要把所有证据问题都直接吞进先验—后验结构里。


3. 贝叶斯主义 vs 演绎主义科学观:它真正的对手不是统计,而是“知识观”

如果把视野拉得更大,贝叶斯主义不仅在和别的统计方法竞争,也在和一种更古典的知识理想竞争:
科学应当主要靠演绎证明、确定逻辑、清晰证伪来推进。

从这个角度看,贝叶斯主义的崛起意味着一个巨大转变:
它承认很多现实认知活动都不是“确定地推出结论”,而是在不同程度的不确定中更新判断。

这使它在以下问题上尤其有力量:

  • 证据如何逐步确认理论?
  • 多条不完美证据如何合并?
  • 不能一锤定音时,如何比较哪种解释更可信?

但也因此,有人批评贝叶斯主义过于“连续化”了信念,仿佛一切都能用概率平滑处理。
现实中的科学革命、概念突变、范式跃迁,未必都能简化为 credence 的逐步更新。

所以,在哲学层面,贝叶斯主义的对手不是某个单一学派,而是“科学是否可以被统一成概率更新过程”这一命题的怀疑者。


4. 贝叶斯主义 vs 非贝叶斯机器学习:预测准确率和不确定性表达之间的张力

在今天最实际的技术战场上,贝叶斯主义面对的一个强大竞争者其实是:
以优化和经验效果为核心的非贝叶斯机器学习范式。

很多工业系统真正关心的是:

  • 准确率高不高
  • 速度快不快
  • 部署成本低不低
  • 训练是否稳定

在这些指标上,很多非贝叶斯深度学习方案往往更直接、更成熟、更有工程工具链支持。
因此现实中大量系统并不会“纯贝叶斯化”。

为什么很多团队不选贝叶斯?

  • 训练和推断成本高
  • 后验近似难
  • 工程复杂
  • 业务场景不一定需要完整不确定性表达
  • 组织里缺少概率建模人才

为什么又越来越多团队重新看贝叶斯?

因为黑箱预测在很多高风险场景下不够。
模型给出 99% 置信样子的错误答案,比老老实实承认“不确定”更危险。
于是,贝叶斯思想作为“不确定性基础设施”开始回流。

用户真实使用偏差

很有意思的是,很多工业团队并不自称“贝叶斯主义者”,但他们做的事情已经很贝叶斯:

  • 加先验约束
  • 做模型集成
  • 在线更新
  • 输出预测分布
  • 用概率图模型融合多源信息

也就是说,贝叶斯思想正在以“去宗派化”的方式渗透工程实践。
很多人并不在哲学上站队,但在方法上已经借用了它。


三、一个辅助性的横向对比表

维度贝叶斯主义频率学派似然主义非贝叶斯ML
概率含义信念度/不确定性长期频率证据支持结构常常只是损失优化下的分数输出
是否使用先验是,核心组成否/尽量避免通常不显式使用常隐含结构先验,但不显式表述
更新机制明确:prior→posterior依赖抽样理论重视似然比较依赖训练与再训练
结果解释直观,可谈“概率多大”严格但常被误读对证据比较清晰往往重性能轻解释
优势统一、灵活、能表达不确定性标准化、成熟、计算较稳优雅、强调证据工程效率高、生态强
短板先验争议、计算重p值文化问题、解释绕框架不如贝叶斯完整不确定性常表达不足

四、趋势判断:贝叶斯主义接下来会往哪里走?

1. 它不会“消灭”其他范式,但会继续成为高复杂度问题的底层语言

贝叶斯主义未来最可能的走向,不是全面替代频率学派或深度学习,而是继续在以下场景中成为核心基础设施:

  • 高风险决策
  • 小样本推断
  • 多源异构信息融合
  • 科学建模
  • 强调校准与不确定性的AI系统

2. 它会越来越“隐身”

未来很多系统可能不会在名称上强调自己是贝叶斯的,但会在内部吸收贝叶斯思想:

  • 后验近似
  • 置信传播
  • 概率编程
  • 预测分布输出
  • 结构先验与层级建模

也就是说,贝叶斯主义可能不会总以“主义”形态出现,而会以“系统设计原则”存在。

3. 最大机会:AI时代对不确定性的重新重视

随着大模型和复杂AI系统广泛进入真实世界,“能不能表达不知道”会变得越来越关键。
这恰恰是贝叶斯传统最深的优势。

4. 最大风险:沦为一种“概念光环”

“贝叶斯”在一些领域容易变成高级标签:
听起来严谨、聪明、全面,但真正落地时只用了一点点近似技巧。
如果失去对先验、模型结构、推断误差的严格审视,贝叶斯也可能沦为包装词。


五、横纵交汇:为什么贝叶斯主义今天仍然重要?

如果把纵向和横向放在一起看,会发现贝叶斯主义最核心的价值并不只是“Bayes公式很好用”,而是它提供了一种极少数方法论才拥有的统一性:

  • 它能把信念、证据、学习、决策放进同一个框架;
  • 它既能讨论哲学上的“什么算理性更新”,也能落实到统计上的“如何算后验分布”,再延伸到工程上的“怎样量化模型不确定性”。

这就是它能穿越几个世纪的原因。

从历史看,贝叶斯主义的命运并不是一条直线。
它经历过作为逆概率工具的萌芽、被频率学派压制的边缘期、在主观概率与决策理论中的哲学重塑、在计算革命中的统计复兴,最后又在机器学习时代获得了新的工程解释。
它每次复活,都不是简单重复自己,而是在新的问题场景中被重新翻译。

从横向看,它也从未真正垄断赛道。
频率学派拥有制度与标准化优势,似然主义保留了证据比较的优雅路线,非贝叶斯机器学习则占据工程效率和规模化生态。
贝叶斯主义真正的独特性,不在于它能把所有问题都做得最好,而在于它特别擅长处理这样一类问题:

当世界充满不确定,而你又不能假装自己什么都不知道时,如何把已有知识、新证据和行动选择放进同一个理性过程里。

这正是现代科学、商业决策、人工智能越来越频繁面对的问题。

所以,对贝叶斯主义最准确的评价可能不是“它是一种统计流派”,而是:

它是一种关于有限理性如何在不确定世界中持续学习的总框架。

而只要人类还需要在信息不完整的条件下判断、下注、修正和决策,贝叶斯主义就不会退场。它甚至可能比以往任何时候都更重要——因为今天的不确定性,不是变少了,而是被放大了。