说实话这份9月AI Agent排行榜刚出来的时候我盯着第一名愣了几秒——Hermes再一看前十里还躺着Claude Code和Codex我反而觉得这榜单有点意思了。它没在列那些“你早就知道”的聊天机器人倒是把一票真正干活的工具顶了上来。这篇文章我就想从这份榜单聊起把三件事说透榜单背后的竞争逻辑是什么、Hermes/Claude Code/Codex这些工具到底怎么装怎么选以及如果你想从0到1搭一个自己的AI Agent最快能跑通的路长什么样。这篇东西适合谁看适合那种已经玩过ChatGPT、DeepSeek这类模型但还没搞清楚“Agent到底是什么”“和LLM有什么区别”的人。也适合想在本地部署一个Agent、或者想配置Codex接DeepSeek、最后却被各式各样报错卡住的人。我会把安装步骤、选型思路、踩坑过程都拆开讲尽量做到你照着操作就能复现而不是看完只记住几个名词。1. 榜单之外先补课LLM、Agent、AI模型到底差在哪1.1 先分清三层模型是发动机Agent是整车每次一聊Agent评论区一定会有人问“Agent和LLM到底啥区别”“DeepSeek算Agent吗”。这问题确实绕但可以用一个特别土的类比讲明白。AI模型是最底层的一堆权重文件你可以把它理解成一台发动机。LLM大语言模型是AI模型里的一个大类专门擅长理解和生成文本DeepSeek、GPT、Claude都落在这层。而Agent不是模型它是“发动机 方向盘 油门 导航”组装起来的整车。它内部装了某个LLM当大脑但还连着一堆工具、一套决策循环、一份记忆存储能自己拆解目标、决定先干哪一步、调哪个工具、然后根据结果修正下一步动作。很多人混淆是因为日常使用时LLM的聊天界面看起来也“很智能”。但它俩的差距在“能不能承担责任”上体现得特别明显。你让LLM“帮我把这个文件夹里的图片压缩一下”它只会回复你“你可以使用xx命令”然后就没有然后了。Agent则会真的去扫文件夹、调用压缩工具、确认输出目录干完之后回来告诉你结果。前者是给建议后者是办事。1.2 DeepSeek属于哪一类为什么搜出来的全是“deepseek hermes”直接回答DeepSeek是LLM开源权重、OpenAI兼容API这些标签你都见过但它不是Agent。它本身不会调工具不会自己拆解任务就是一个非常聪明的“大脑”。那为什么热词里全是“deepseek hermes”因为Hermes是一个Agent框架它能把DeepSeek接进去当自己的大脑来用。就像你买了个发动机DeepSeek再装进Hermes这辆车里它才变成能跑的整车。大家搜“deepseek hermes”本质上是在搜“怎么用Hermes接入DeepSeek”。同样的道理“codex接入deepseek”也流行——Codex是OpenAI出的编码Agent CLI但它可以配置成走OpenAI兼容接口把底层模型切成DeepSeek。所以你看模型和框架是两回事组合起来用才是常态。1.3 用一句人话判断它是LLM还是Agent给新手一个特别简单的判断方法问它一个需要“动手”的问题看它是只给建议还是真的去执行。比如“帮我查一下现在北京气温然后写进备忘录”。只回复文字建议的是LLM真的去调天气API、再调用备忘录接口、最后给你回执的才是Agent。判断一个项目是“Agent框架”还是“模型”也同理看它有没有工具调用、记忆、任务规划这些组件。有就是Agent只有参数和权重就是模型。榜单里Hermes、Claude Code、Codex能放一起排核心也是它们都具备Agent能力而不是因为它们是同一种模型。2. Hermes凭什么登顶从排名看Agent框架的竞争逻辑2.1 先看排名口径榜单评的到底是什么每个榜单都有自己的口径看之前得先搞清楚它排的是“热度”还是“能力”。热度榜看GitHub star增长速度、社区讨论量、安装下载量、教程产出量能力榜看GAIA、SWE-bench这类Agentic基准的得分。这两个口径能差出十万八千里。从标题“Hermes第一Claude Code、Codex进前十”来看这个排名大概率是社区热度方向的口径。因为纯拼agentic benchmark的话Claude Code和Codex确实可能排前但Hermes是不是能力第一不好说。所以我的建议是看排行先看它统计的是什么。热度榜反映的是“大家正在用什么、关注什么”能力榜反映的是“谁干活最靠谱”两个都要看但不能混着用。2.2 从公开信息看Hermes拿第一靠的是这四张牌从公开仓库和社区反馈来看Hermes能在9月冲上榜首我认为核心是四个原因。第一开源且能本地部署。这是硬门槛。很多人不想把代码、敏感数据喂给云端Hermes这类支持本地的框架就成了首选。第二模型接入足够灵活。它走的是“主流大模型通用接入层”OpenAI兼容接口都能接DeepSeek、Qwen、GLM这些跑起来都不费劲。对于国内开发者来说这意味着不用折腾复杂的鉴权链路配一个API Key就能跑。第三有桌面端安装门槛低。排行热词里“hermes desktop”“hermes安装部署”搜索量都不低说明它从命令行工具走向了图形界面这一点对非硬核用户非常友好。安装门槛一降社区规模自然上来。第四二创生态活跃。热词里有“hermes agent官网”“hermes教程”“hermes智能体”说明已经有人开始围绕它做教程、做模板、做扩展。一个Agent框架如果只有代码没有生态很难持续火。2.3 Claude Code和Codex进前十释放出的信号更值得琢磨比起Hermes拿第一我更在意Claude Code和Codex双双进前十。这两个不是通用Agent框架而是彻头彻尾面向开发者的编码Agent。Claude Code是Anthropic出的命令行编码助手能直接在你的仓库里读代码、改文件、跑命令长上下文理解能力很强。Codex是OpenAI出的开源编码CLI打通GitHub生态可以直接把issue变成PR。它们进前十说明Agent赛道已经从“聊概念”转向“干活”真正的开发者开始用Agent改bug、写测试、做代码审查了。这也带来一个判断2025年的Agent竞争焦点已经从“谁的聊天更像人”转移到了“谁的Agent能稳定完成多步骤任务”。排行榜前列被开发工具占据本身就是产业成熟的信号。2.4 给选择困难症的三条选型建议结合榜单和实际使用场景我给三类人三条不同的建议。第一你只想更快写代码不想折腾架构——直接装Claude Code或Codex二选一即可。前者适合深度使用Claude模型的场景后者适合习惯GitHub工作流的场景。第二你想搭一个自己的Agent、接自己的业务数据和工具——去研究Hermes这类开源框架而不是自己从零写Agent循环。框架帮你解决好了工具调用、会话管理、记忆持久化这些脏活。第三你预算有限想低成本练手——先注册DeepSeek的API用Codex或自写脚本接上去熟悉一下Function Calling和Agent循环再决定要不要上重型框架。3. Hermes与Claude Code安装实测环境、配置、接入DeepSeek的完整过程3.1 装之前先想清楚你要的是助手还是建框架动手之前先分清需求。Claude Code和Codex是“即装即用的助手”装上就能在你项目里干活Hermes是“框架”装完之后你还要接模型、配工具、定义Agent的行为。这俩定位完全不同装错方向会很痛苦。如果你只是想要个能写代码的Agent装完Claude Code就够别再额外配一个Hermes如果你想做一个定制的业务Agent比如自动整理周报、自动巡检服务器那Hermes这类框架才是你的底座。先想清楚再装能省掉一晚上的折腾。3.2 Claude Code安装从命令行到VSCodeClaude Code的安装其实很传统。前提是机器上有Node.js 18推荐装LTS版本避免奇奇怪怪的兼容问题。装好Node之后一条命令的事npm install -g anthropic-ai/claude-code装完验证一下claude --version能看到版本号就算装好了。使用前需要配置认证信息最常用的方式是设置环境变量ANTHROPIC_API_KEY。如果你用的不是Anthropic官方模型也可以把它指向兼容接口只是要注意Claude Code原生走的是Anthropic协议接OpenAI兼容接口得靠路由层转换比Codex接DeepSeek要绕一些。VSCode里的配置就更直观了打开扩展面板搜索Claude Code装扩展然后在设置里填入API Key或对应环境变量。装完之后在项目里打开一个文件让Agent“读一下这个文件解释逻辑”就能确认它是不是正常工作。3.3 Codex安装CLI扫码登录与兼容接口切换Codex装起来同样走npmnpm install -g openai/codex官方推荐先登录它会呼起浏览器/终端授权把OpenAI账号和CLI绑在一起。但很多人装Codex其实是为了接DeepSeek等国内模型走的就不是登录而是“兼容接口切换”这条路。Codex支持通过环境变量和配置文件切换接口。核心是三个变量export OPENAI_BASE_URLhttps://api.deepseek.com export OPENAI_API_KEY你的DeepSeek API Key如果Codex版本支持模型配置可以在~/.codex/config.toml里指定模型名比如deepseek-chat。这样做的原理是Codex原生客户端走OpenAI的/v1/responses接口而DeepSeek目前更多提供的是/v1/chat/completions这一套所以有些版本还需要额外配置一个“兼容层”让请求从responses映射到chat/completions。这也是后面第5节那个报错的源头之一。3.4 Hermes部署克隆仓库、装依赖、配.env、起服务Hermes的部署逻辑和大多数开源Agent框架差不多。以下步骤是我基于通用开源项目的实践整理的具体以你拉到的仓库文档为准。第一步把代码拉到本地git clone Hermes仓库地址 cd hermes第二步安装依赖。不同版本用的包管理器不一样常见的有pip install -r requirements.txt也有基于Node的npm install还有桌面版直接下载安装包。你下载的包里一般有README开头就会写明用什么装。第三步配置环境变量。项目里通常有个.env.example复制成.env把里面的大模型API Key填上cp .env.example .env关键配置项一般是三块模型接入base_url、api_key、model_name、缓存目录、日志级别。刚才说了Hermes能接DeepSeek那base_url就填DeepSeek的兼容地址model_name填deepseek-chat。第四步启动服务。python main.py # 或者 npm start看到启动日志里出现“listening on port xxx”就算成了。此时你可以在桌面端输入一个问题看Agent能不能正常回复如果还能调用你给的工具说明框架已经跑起来了。3.5 三个工具怎么选一张表看懂工具定位安装复杂度适合场景接DeepSeek难度Hermes开源Agent框架中等要配环境变量自己搭业务Agent、本地部署低改base_url和model_name即可Claude Code编码Agent助手低npm一条命令改代码、读仓库、跑测试中需路由层转协议Codex编码Agent CLI低npm一条命令GitHub工作流、自动修issue低配兼容接口即可选型就是这么简单你要“框架”就选Hermes你要“助手”就看Claude Code和Codex二选一。不要混着装一堆最后每个都吃灰。4. 从0到1搭建一个能跑通的AI Agent选型与实现4.1 先定义需求再选框架很多人搭Agent失败不是技术不行是需求没想清楚。你问他“你要搭什么Agent”他说“想要个万能助手”。万能助手是最难搭的因为目标不明确评估就没有标准。我的做法是先写一句话需求模板输入是什么 要做什么处理 输出是什么 在什么场景触发。比如“输入是一周的运营数据自动分析趋势并写一份周报markdown每天早上9点触发”。这句话一出来选型就不用纠结了需要一个能读数据的工具、一个写文件的工具、一个定时任务再加一个LLM做分析。这个组合直接用Python脚本都能做完全不用上重型框架。4.2 Agent的组成结构拆解讲一千道一万Agent的组成结构其实就五块。模型决定智力和语言能力DeepSeek也好、GLM也好本质是大脑。工具模型没长手脚工具就是手脚。一个Agent至少得有“读文件”“写文件”“调API”这种级别的工具才像个Agent。记忆短期记忆是当前会话上下文长期记忆是向量库或数据库。没有记忆的Agent每轮对话都是“失忆新人”。规划把大任务拆成小步骤。高级Agent会用“先调研、再写提纲、再写正文、最后检查”这样的显式步骤。执行循环这是Agent的灵魂。它反复做“思考该干啥 → 调用工具 → 看结果 → 再思考”直到任务完成或步数耗尽。这个循环能不能稳定跑通直接决定Agent实不实用。4.3 最小Agent循环用Python代码演示下面给一个极简的实现逻辑用的是OpenAI兼容接口所以换成DeepSeek的key和地址就能跑。from openai import OpenAI client OpenAI( base_urlhttps://api.deepseek.com, api_key你的API Key ) tools [ { type: function, function: { name: write_file, description: 写入内容到指定文件, parameters: { type: object, properties: { path: {type: string}, content: {type: string} }, required: [path, content] } } } ] def call_tool(name, arguments): # 这里接你的真实工具逻辑 return f[工具执行结果] {name}: {arguments} def run_agent(task): messages [ {role: system, content: 你是一个能调用工具的助手。}, {role: user, content: task} ] for _ in range(5): resp client.chat.completions.create( modeldeepseek-chat, messagesmessages, toolstools ) msg resp.choices[0].message messages.append(msg) if msg.tool_calls: for tc in msg.tool_calls: result call_tool(tc.function.name, tc.function.arguments) messages.append({ role: tool, tool_call_id: tc.id, content: result }) else: return msg.content return 步数用尽任务未完成 if __name__ __main__: print(run_agent(把这句话写入 hello.txtAgent跑通了))这段代码虽然短但把Agent循环最核心的结构体现出来了模型返回工具调用请求 → 执行工具 → 把结果塞回对话 → 模型继续回答。没有循环就没有Agent有了这个循环你就能在任意模型上叠加任意工具。4.4 练手小项目让Agent帮你整理周报第一个Agent练手项目我建议做“周报整理助手”。理由很简单工具边界清晰失败看得见效果好评估。需求拆解输入是本周的日报文本输出是一份按“本周进展、问题风险、下周计划”分段的周报。实现思路更简单写一个工具read_reports()用来读取指定目录下的日报文件再写一个工具write_report(content)把结果写到指定路径。然后让Agent自己调这两个工具完成整理。你会发现难点其实不在代码而在提示词。要让Agent严格按三个维度汇总就得把输出格式写死甚至给它一段示例。我第一次跑的时候Agent把日报里所有细节都堆进周报后来在工具描述里加了“只保留和项目里程碑相关的内容”输出才像样。这就是经验调Agent 90%的时间都在调提示词和工具描述而不是调模型。5. 实测中遇到的问题codex local proxy报错的完整排查链路5.1 先读懂报错在说什么有个报错最近在热词里出现频率特别高它是这样的cc switch local proxy failed while handling codex endpoint /responses.这句话翻译成大白话就是你在Claude Codecc或相关的工具配置里把流量指向了本地API网关报错里的local proxy但是这个网关在处理Codex的/responses接口时挂了。“switch”说的是你切换配置/供应商的动作“local proxy”在这里指的是你自己架设在本机的接口转发层比如用某款路由工具统一管理多个大模型API。这种玩法在本地开发里很常见你不想让每个工具各配一套厂商地址就在本机起一个统一网关所有CLI工具都指到它再由它把请求转发给不同的后端模型服务商比如DeepSeek。思路没错但配置复杂度上来了报错也就跟着来了。5.2 排查链路一步一锤不要跳遇到这个报错我建议别急着改配置按下面四步走定位会很快。第一步确认网关进程还活着。如果是Docker起的网关docker ps看容器状态如果是本地进程用ps aux | grep 进程名过滤或者直接看它的日志。这个报错里唯一能确定的信息是“网关在处理请求时失败”所以网关挂掉是最常见、也最优先要排除的。第二步绕过工具用curl直接测目标接口。curl -X POST http://localhost:8080/v1/responses \ -H Authorization: Bearer YOUR_KEY \ -H Content-Type: application/json \ -d {model:deepseek-chat,input:hi}这一步的意义是绕过上层工具直接探测“网关本身能不能正确响应Codex的responses接口”。如果curl本身就返回404或500说明问题在网关和上游模型之间如果curl正常返回了问题大概率出在工具的配置或路径映射上。第三步核对路径。Codex默认请求的是/v1/responses很多本地网关只实现了OpenAI早期的/v1/chat/completions没有实现responses接口。这是兼容性的大坑路径不匹配任何工具的请求都会失败。第四步检查环境变量。很多工具同时读OPENAI_BASE_URL、ANTHROPIC_BASE_URL这类全局变量如果你之前给别的项目设置过这些值它们会污染当前工具的请求。我排查过一次最后发现问题只是OPENAI_BASE_URL还残留着另一个项目的地址。5.3 根因与修复三个主要原因一张表原因特征修复方案网关不支持/responses接口curl测试返回404换成兼容路径配置或给网关加responses路由映射base_url路径写错curl返回404或超时检查是否漏了/v1前缀改成http://localhost:8080/v1环境变量被全局污染其它工具也报同样的错清掉~/.bashrc、~/.zshrc里的旧配置在工具配置里显式覆盖最省事的修复办法是让Codex直接走/v1/chat/completions兼容模式。新版Codex在~/.codex/config.toml里有相关的模型路由配置把响应格式从responses切到chat_completions很多网关的兼容压力会小很多。5.4 同类报错举一反三这类“工具调不通本地网关”的报错本质都是协议不匹配。记住几个常见信号的指向404 Not Found——路径不对或网关没实现对应接口。401 Unauthorized——Key没传或传错Key。timeout——网关没起来或上游接口访问链路不通。protocol error——接口返回的结构和客户端预期不一致。这套排查方法不只适用于CodexClaude Code接本地网关时同样适用。记住核心思路先绕开工具测网关再绕开网关测模型逐层剥洋葱永远比瞎改配置快。6. 下一步Agent skill开发与PLC这类垂直场景的想象空间6.1 Agent skill是什么给Agent加一本“操作手册”Skill是Agent生态里这两年特别重要的概念。你可以把它理解成“给Agent装上一个专业技能包”里面通常包含三样东西一段高质量的系统提示词、一组领域工具定义、一套标准执行流程。举个例通用Agent写代码没问题但你让它写PLC程序它可能会犯设备时序的错误。如果你给它加载一个“PLC编程Skill”它会先分析IO点表、再选指令、再生成结构化文本、最后提示你仿真验证。同样的模型装Skill前是“泛泛的工程师”装Skill后就变成“熟悉某品牌PLC的专项工程师”。6.2 skill开发的基本流程开发一个Agent skill门槛比你想的低核心是把你脑子里的领域经验变成Agent能遵循的结构化流程。第一步梳理专家流程。把一个任务拆成固定步骤比如“读需求 → 列IO清单 → 选型 → 写代码 → 编译 → 仿真”。第二步定义工具接口。每个步骤要调什么工具、参数是什么写成JSON Schema。第三步写评估用例。准备几组标准输入和期望输出用来验证skill有没有效果。第四步迭代提示词。跑不通就改描述直到稳定。这里我个人的经验是skill开发的难点不在Prompt写得好不好而在工具边界划得干不干净。工具描述写得太宽Agent会乱调写得太窄Agent又不知道什么时候该用。需要反复拿真实用例去锤。6.3 PLC编程场景Agent能不能下车间热词里有“ai agent与plc编程”这个组合挺有意思的说明工业自动化领域的人也开始盯上Agent了。我的判断是Agent确实能辅助PLC编程但它的价值不在“直接生成能上线运行的代码”而在“生成初稿 解释报警 辅助仿真验证”。工业场景最忌讳把没验证的代码直接下载到设备上。一个可靠的工作流是Agent根据IO表和工艺要求生成结构化文本或梯形图初稿 → 工程师丢进IDE编译 → 编译报错再抛回给Agent修改 → 在虚拟PLC环境里跑仿真测试用例 → 工程师人工确认后才考虑真机。这个闭环里Agent的价值是省掉大量写初稿的时间安全边界则必须靠仿真和人工确认兜底。任何鼓吹“Agent一键写PLC、直接下载”的说法在工业现场都得打个问号。6.4 还有什么值得关注Skill之外我觉得接下来值得关注的方向有三个。一是记忆层。短期记忆解决当前任务长期记忆解决“这个Agent上周学到的东西今天还能不能用”。真正好用的Agent必须能把经验沉淀下来。二是多Agent协作。一个Agent负责拆任务一个负责执行一个负责审查这种“Agent团队”模式在复杂项目里会越来越常见。三是评估体系。Agent越做越复杂没有评估集你根本不知道改了一版提示词到底是变好了还是变坏了。给Agent建一个固定测试集比盯着排行榜有用得多。最后说一点个人体会。排行榜上的名字会换热度榜单每个月都在变但Agent的底层套路不会大变一个能调工具的模型、一个稳定的执行循环、一套高质量的Skill再加一块能记住上下文的记忆层。先别急着追排名拿一个命令行Agent实际跑两天把你的提示词和工具链磨顺了比关注任何榜首都实在。