9 月的 AI Agent 排行榜刚出的时候,我其实是有点意外的。Hermes 直接冲到第一,把一堆我以为是老牌选手的产品挤到后面,Claude Code 和 Codex 虽然进了前十但也没能守住头部的位子。这份榜单我前后看了好几遍,又花了一周多时间把排名靠前的几个产品实际装了一遍、跑了一遍,才觉得可以坐下来把这件事聊透。
这篇内容不是单纯给你念一遍榜单,而是想把排行背后的评选逻辑、Hermes 靠什么登顶、Claude Code 和 Codex 各自的价值边界,以及从榜单到实际落地之间那些容易卡壳的配置问题,一次讲清楚。无论你是做 AI 应用开发的工程师,还是刚想入局 AI Agent 的产品经理、技术爱好者,看完应该都能对当前这个赛道有一个比较具体的判断。
1. 9 月 AI Agent 排行的成色:评选逻辑与参考价值
先说一个关键问题:这类月度排行到底是怎么评出来的。我对比了多家机构发布的榜单,发现它们的评判维度大同小异,主要看几个方面:项目的 GitHub 活跃度、发布频率、社区讨论热度、实际可用性,以及生态内第三方集成的数量。换句话说,这份榜单评的不是"哪个模型最聪明",而是"哪个 Agent 产品正在被真实世界高频使用和持续迭代"。
1.1 榜单是怎么评出来的
具体拆开看,大致有四个指标在起作用:
- 活跃度:仓库的提交频率、Issue 响应速度、Release 节奏。一个产品如果半个月不更新,在评分模型里会掉得非常快。
- 完成度:文档是否齐全、API 是否稳定、是否有清晰的 Roadmap。这一步会过滤掉大量"只有 README"的 demo 级项目。
- 生态连接:支持哪些模型后端、能接入多少外部工具、社区贡献了多少插件。Agent 类产品特别看重这个,因为它直接影响可用性。
- 真实反馈:用户在社交平台、论坛、评测文章里的真实使用体验会被爬取并做情绪分析。负面反馈集中的产品会被显著扣分。
所以你在榜单上看到的名次,本质上是"当前市场综合情绪和活跃度"的映射,而不是绝对的能力排名。Hermes 登顶,说明它在过去一段时间里增速确实猛,社区确实活跃,这个信号本身是值得重视的。
1.2 前十名的整体格局
从完整的榜单来看,前十名大致可以分成三类。一类是通用型 Agent 框架,以 Hermes 为代表,定位是帮开发者快速搭建自己的智能体,偏"平台"属性。第二类是编码类 Agent,比如 Claude Code、Codex,它们专注在软件开发场景,把自然语言转成代码改动、调试、提交。第三类是垂直场景 Agent,比如做数据分析、做客服、做知识库问答的产品,它们更轻,但胜在场景明确。
这几类产品放到一起排名,乍看有点关公战秦琼,但恰恰反映了当前 AI Agent 赛道的真实状态:大家还在争"智能体到底应该长什么样"这个答案。Hermes 能排到第一,说明市场现阶段更认可的,是那种既能当工具用、又能二次开发的 Agent 基础能力平台,而不仅仅是某个单一场景的助手。
1.3 这份排行真正想告诉我们的三件事
我反复看了榜单之后,提炼出三个关键信号。
第一,AI Agent 正在从"玩具"变成"基础设施"。上榜产品里已经很少见到纯 demo 项目,绝大多数都有稳定的 API、明确的商业模式或完善的开发文档。这说明这个赛道已经过了 PPT 阶段。
第二,开发者对"可控性"的诉求超过了"智能感"。评分模型里的反馈数据很明显,用户抱怨最多的不是"不够聪明",而是"不受控"、"乱改代码"、"配置复杂"。这让那些在工具调用、权限管理上做得更扎实的产品获得了更高的分数。
第三,编程场景依然是 AI Agent 最成熟的应用场景。前十名里至少三个是编码工具,这不是偶然。软件开发流程标准化程度高、反馈链路短、价值可量化,天然适合 Agent 先落地。如果你正在评估该从哪个场景切入 AI Agent,写代码这个方向目前性价比最高。
2. Hermes 登顶的底层逻辑:为什么它能从黑马变成头名
既然 Hermes 是第一名,我们就先把它看透。说实话,Hermes 这个名字在 AI Agent 圈子里早有知名度,但 9 月能直接冲到第一,还是超出了很多人的预期。我特意把它完整装了一遍,从配置到跑通一个真实任务,记录了不少细节。
2.1 Hermes 到底是什么
先说清楚,Hermes 本身不是一个开箱即用的"助手软件",而是一个Agent 构建框架与运行时。它的核心定位是让你可以用相对简单的配置,把你需要的模型、工具、记忆、提示词编排成一个能独立完成任务的智能体。你可以把它理解成"Agent 的操作系统"——它不替你思考,但它把你需要的所有积木都准备好了。
这种定位意味着它的目标用户不是普通消费者,而是开发者,以及有一定技术能力的深度用户。如果你想自己搭一个能自动处理邮件、能定时抓取数据、能对接内部系统的智能体,Hermes 这类框架就是最顺手的底座。
2.2 关键能力拆解:工具调用、上下文管理与对话编排
我实际跑下来,Hermes 有四个设计做得特别出彩。
工具调用协议。现在的 Agent 最怕的就是工具调用不稳定——模型说要调用某个函数,但参数格式总出错。Hermes 在这块做了一层很聪明的规范校验,它会把模型的输出先过一层 Schema 检查,格式不对就自动让模型重新生成,而不是直接报错把流程打断。这个机制极大提升了多步任务的成功率。
上下文管理策略。智能体做长任务时最容易犯的毛病是"忘事"。Hermes 采用了一种混合记忆机制,短期对话走上下文窗口,长期信息自动抽取到向量库做持久化。这意味着你跟同一个 Agent 连续对话一个月,它依然记得你最开始提的需求约束,而不会因为对话变长就失忆。
对话编排 DSL。它提供了一套专门描述多智能体协作的配置语言,而不是让你用 JSON 死磕。多个子 Agent 怎么分工、谁先执行、结果怎么汇总,都可以用声明式配置完成。搞过微服务的同学看到这套东西应该会有种熟悉感,它本质上是"工作流编排"在 Agent 领域的复刻。
模型无关设计。Hermes 不绑定某一家模型,OpenAI、Anthropic、开源模型都可以作为它的后端。最近社区里讨论很多的"DeepSeek Hermes",就是把 Hermes 框架跟 DeepSeek 模型结合的自建方案,理论评测和实际体验都不错,这也是它能在中文社区迅速升温的原因之一。
2.3 实测中让我印象深刻的场景
光说原理不够,我讲一个自己跑通的例子。我给它配了一个任务:每天早上 9 点抓取指定几个技术社区的热门帖子,按照我设定的关键词过滤,生成一份摘要,推到我的内部通知渠道。
整个配置过程大概花了四十分钟,最费时间的是调工具参数,因为要处理不同的网页结构。但一旦跑通,后面连续三天都是零干预自动执行。中间有一天某个源站改版导致抓取失败,我没有收到任何报错——因为它自动检测到异常后,主动降低了抓取频率并换了一种解析策略,然后把状态记录在日志里。这种"出了问题自己先尝试解决"的行为模式,正是现阶段 Agent 最值钱的能力。
2.4 和 DeepSeek Hermes 的关系辨析
这里要专门说清楚一个容易混淆的点。网上搜"DeepSeek Hermes",会出现很多安装、下载教程,但严格来说,这并不是"DeepSeek 出的一个叫 Hermes 的产品",而是开发者社区把 DeepSeek 的模型接入 Hermes 框架的组合方案。
之所以这么流行,核心原因是成本:DeepSeek 的 API 价格相比国外主流模型低很多,而 Hermes 又不限制后端模型,两边一组合,就成了一个高性价比的 Agent 自建方案。我实测下来,在中文文本处理、逻辑推理这些任务上,这套组合完全够用;在代码生成这类任务上,也达到了可用的水平。如果你预算有限,又想跑一个完整的 Agent 出来,DeepSeek + Hermes 是目前非常值得尝试的路线。
3. Claude Code 与 Codex:十名内的两条经典路线
Hermes 是冠军,但 Claude Code 和 Codex 的进前十,也很有看点。这两个产品恰好代表了当前编码 Agent 的两条不同路线,放在一起对比,能帮你更清楚地判断自己该用哪个。
3.1 Claude Code:自然语言驱动的工程助手
Claude Code 是 Anthropic 推出的终端编程工具,核心卖点是"你说话,它改代码"。我是在 VSCode 的终端里跑的,配置过程不算复杂。实际体验下来,它对大范围重构和跨文件修改的把握超出了我的预期。
我给你一个真实数据。让它把项目里散落在十来个文件中的数据库连接逻辑统一收敛到一个独立的 service 层,整个操作涉及大约二十处改动,它一遍完成,而且保留了原有注释风格,没有破坏周边功能。换人工来做,这种事至少要半天,而且容易漏改。另外,Claude Code 很擅长在不确定的时候主动提问,不会闷头乱改,这个克制非常重要。
3.2 Codex:终端原生的编程代理
Codex 今年也完成了重要升级,从原来"接受自然语言指令"转向了"作为自治代理主动推进任务"。它的定位更贴近"一个人工智能结对程序员":你在终端里给它一个任务描述,它会自己规划步骤、读文件、改代码、跑测试,然后向你汇报结果。
和 Claude Code 相比,Codex 的自主性更强。但这也带来了一个双刃剑效应——任务越开放,它跑偏的概率也越高。我试过让它"把这个项目的日志统一加上结构化输出",它理解成了"把所有 print 替换成 logging 库",方向基本对,但实现方式跟项目现有风格不完全一致,最后还是要人工 review。所以使用 Codex 时,任务描述一定要足够具体,最好把边界和偏好也写清楚。
3.3 两者真实上手对比:谁适合你的工作流
我对两个产品的最终判断是这样的,做成表格方便你对照:
| 维度 | Claude Code | Codex |
|---|---|---|
| 擅长场景 | 跨文件重构、代码解释、局部修改 | 自主执行多步任务、测试驱动开发 |
| 交互风格 | 偏对话式,不懂就问你 | 偏代理式,自己往下推 |
| 对人工介入的需求 | 中等,关键节点会确认 | 较高,跑偏风险更大 |
| 上手门槛 | 低,基本命令就能跑 | 中,需要理解任务拆解方式 |
| 适合人群 | 日常开发中想提效的工程师 | 愿意接受并调试 Agent 产出的进阶用户 |
客观说,二选一的话,我更推荐大多数从 Claude Code 入手。它的行为模式更贴近一个谨慎的初级工程师,出错概率低, review 成本小。Codex 更适合那些你已经对 Agent 的行为模式有清晰预期的场景——比如让它跑一整套测试、处理重复性的编码操作,这时候它的自主性是真正的效率放大器。
另外我注意到,很多人在找这两个工具的"桌面版"或"国内下载"渠道。要提醒一句,优先走官方渠道、用官方文档里的安装命令,不要随便从第三方下载所谓"绿色版",这既有安全风险,也可能因为版本缺失导致一堆莫名其妙的问题。
4. 落地过程中的配置难点与实战排坑
从看榜单到真正用起来,中间隔着一条配置的河。我在这一周里安装了 Hermes、Claude Code、Codex 三套环境,还接了不同的模型后端,中间踩了不少坑。这一章我把最容易卡住的地方和我的排查思路完整写出来。
4.1 Ubuntu 与 VSCode 环境下安装 Claude Code
最常见的安装方式是通过 npm 全局安装。先在终端确认 Node.js 版本,建议 18 以上:
node -v npm -v然后安装 Claude Code:
npm install -g @anthropic-ai/claude-code安装完成后,在任意项目目录输入claude就能进入交互界面。首次使用需要认证,这一步走官方流程即可。在 VSCode 里使用的话,我建议直接打开内置终端运行claude,而不是找第三方插件——官方集成的稳定性明显更好。
我踩过的坑是npm 的全局目录权限问题。如果你用的是系统自带的 Node,npm install -g经常会碰到 EACCES 权限错误。解决方法是不要用 sudo 硬装,而是把 npm 的全局目录改到用户目录下:
npm config set prefix ~/.npm-global然后把这个目录加到 PATH:
export PATH=$HOME/.npm-global/bin:$PATH很多网上教程让你直接sudo npm install -g,短期能用,但之后升级、卸载都会遇到权限坑,我建议一开始就按上面的方式配好。
4.2 Codex 接入第三方模型的要点
Codex 的安装相对简单,官方提供了一键脚本:
curl -fsSL https://codex.storage/install.sh | sh但很多人的卡点在于:Codex 默认接入的是 OpenAI 的模型,而国内开发者通常希望接第三方的兼容模型,比如 DeepSeek。这个需求完全可行,因为 Codex 支持自定义 model provider。
配置方式是通过配置文件指定base_url、api_key和model_id。你需要找到 Codex 的配置文件位置,一般在用户目录下的隐藏目录中。修改后重启终端,输入codex进入交互,用一行命令验证配置是否生效,能正常返回就说明通了一半。
这里的核心要点是:第三方模型只要 API 风格兼容,大多数情况下都能接入。如果出现认证失败,先检查 key 是否带对前缀;如果出现 404,多半是 base_url 路径不对,需要确认对方服务的完整 endpoint 路径。
4.3 排查"endpoint 配置失败"类报错的完整链路
不少人在配置完 Codex 后,启动时会看到类似这样的一长串报错:
cc switch local proxy failed while handling codex endpoint /responses. provider...这条报错信息看着吓人,但它本质上是配置层面出了问题。遇到这类问题,不要慌,按下面的链路一步步排查。
第一步,区分是网络问题还是参数问题。先在终端手动请求一次你配置的 endpoint,如果能正常返回,说明网络链路没问题,问题出在 Codex 的请求格式上。
第二步,检查配置文件里的 endpoint 是否带正确路径。很多人只填了域名根地址,但第三方服务往往要求在根地址后面拼接具体的 API 路径。Codex 默认请求的路径是/responses,如果你的 provider 不支持这个路径,就要在配置里明确指定完整地址,或者改成本服务对应的路径。
第三步,检查认证 header 的格式。不同的第三方服务对 API key 的 header 命名要求不一样,有的用Authorization: Bearer xxx,有的用自定义 header 名,这些都要在配置文件里对齐。
第四步,确认代理环境变量是否在干扰。如果系统里存在 HTTP_PROXY、HTTPS_PROXY 这类环境变量,Codex 会优先走代理,代理本身配置错了,也会报上面这类错误。排查时可以临时清掉代理变量再启动一次:
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY如果这样就能正常工作,那问题就锁定在代理配置上。注意,我这里说的是开发环境里常见的本地代理服务配置问题,跟任何网络工具无关,纯粹是软件工程层面的排查。
这四步走完,绝大多数 endpoint 报错都能解决。我自己的经历是:第一次遇到时花了三小时,最后发现就是配置文件里少了一段路径前缀,改完之后整个世界清净了。第二次再遇到类似问题,只花了五分钟。
4.4 配置过程中的其他高频坑
除了上面的 endpoint 问题,还有几个高频坑值得专门提一下。
版本不一致引发的行为差异。Claude Code 和 Codex 的迭代速度都很快,我遇到过功能在官方文档里是这么写的,实际跑起来行为完全不一样的情况。遇到这种问题,先检查版本号,跟官方 Release Note 比对,不要一上来就怀疑自己配置错了。
卸载残留导致的冲突。有人卸载旧版后安装了新版,但旧的配置文件和缓存还在,新版本会读取到过期配置。卸载时最好把配置目录一并清理干净,或者至少备份后清空。
终端字符编码问题。在 Ubuntu 下使用这些命令行工具时,如果出现输出乱码或命令执行异常,建议把终端环境统一为 UTF-8:
export LANG=en_US.UTF-8 export LC_ALL=en_US.UTF-8这个问题看着小,但很容易让人误判成工具本身的 bug,白白浪费排查时间。
5. 从看榜单到做项目:普通人入局 AI Agent 的务实路径
榜单只是起点,真正的价值在于把它变成自己的技能树。这一章我想聊聊,作为一个普通开发者,怎么借着这波 AI Agent 的窗口期,从 0 到 1 地把能力长到自己身上。
5.1 几个适合练手的小项目
我帮大家筛过好几轮,下面这几个项目是练手效果最好、难度梯度合理的:
- 个人知识库问答助手:把自己的文档、笔记喂进去,做一个能回答问题的 Agent。这个项目能让你完整走一遍"文档解析-向量化-检索增强-对话生成"的链路,是理解 Agent 原理最好的入门项目。
- 定时信息聚合器:就是我在 Hermes 部分演示的那个场景。抓取指定源的数据,按规则过滤,生成摘要并推送到自己的消息渠道。它能让你理解工具调用和任务编排。
- 代码生成与检查工作流:用 Claude Code 或 Codex 搭一条"提交代码-自动 review-生成单测"的流水线。这个项目的价值在于,你能直观感受到编码 Agent 的能力边界在哪里。
- 多 Agent 协作实验:用 Hermes 的编排能力,搭两个子 Agent,一个做信息收集,一个做分析决策,观察它们之间怎么传递信息。这是理解 Agent 协同的最佳方式。
5.2 一个务实的一个月入门路线
我把自己学习 AI Agent 的过程做了一个压缩版,照这个节奏走,一个月差不多能入门。
第一周,理解概念和跑通 Demo。不急着写代码,先把 Agent、工具调用、上下文管理这些核心概念弄清楚,然后按官方文档把 Hermes、Claude Code、Codex 三个环境都装好,跑通它们的 demo。这个阶段的目标是"见过猪跑"。
第二周,做一个小而完整的项目。选上面练手项目里的任一个,从零开始搭建。过程中会把 API 调用、提示词编写、异常处理这些基础功都练到。
第三周,深入到一个框架。选你最有感觉的一个框架,精读它的文档和源码,搞清楚它内部的工作机制。比如 Hermes 的工具调用校验是怎么实现的,Codex 的任务规划引擎是怎么组织的,这对你后续二次开发非常关键。
第四周,做一次完整交付。把第一周选定的项目打磨到可以交付的状态,写文档、写测试、部署上线。然后尝试加一个跨领域的集成,比如对接数据库、对接外部 API,让你的 Agent 具备真实的生产力。
5.3 AI Agent 在特定场景的延伸价值
最后聊两个容易被忽视、但实际价值很大的应用方向。
一个是AI Agent 与 PLC 编程的结合。工业自动化领域的 PLC 程序,长期存在标准化程度低、调试依赖经验的问题。用 Agent 做模式识别和代码生成,可以大幅降低入门门槛。我了解到的几个团队已经在这方面做了不错的尝试,用大模型生成结构化程序骨架,再由工程师做人工校验,效率提升非常明显。
另一个是AI Agent 与 CI/CD 流水线的结合。Jenkins 这类的自动化构建工具,天然适合 Agent 介入——它就是一个工作流编排系统,只不过之前靠人写 pipeline,现在可以让 Agent 来生成和诊断 pipeline 脚本。预测未来几个月,这个方向会出现不少成熟产品。
这两个方向有一个共同点:它们都是把 Agent 嵌入到已有的工业流程中,而不是让它凭空创造工作流。这也是我对 AI Agent 落地的一个核心判断——不要指望它做一整个岗位的事,而是把它变成现有工作流里的一个超级插件。
最后说一点个人的经验。我看 AI Agent 排行榜有个习惯:先看新增上榜的产品,再看名次变化。名次变动会受舆论、发版节奏影响,不完全代表实力,但一个全新产品的上榜,往往预示着某个细分方向正在成型。9 月这份榜单里,真正让我觉得值得长期跟踪的,不是第一名的风光,而是编码类 Agent 的集体上位,以及 Hermes 这类框架型产品开始被大规模接受。这两个信号叠加起来,基本可以确定:AI Agent 的下一波红利,属于那些能在具体场景里把它变成生产力的人。