九月底我照例翻了一圈技术社区的热榜发现大家讨论最集中的就是这份 9 月 AI Agent 榜单Hermes 排到了第一Claude Code、Codex 双双进了前十。评论区盯着名次争论的人不少但对我来说这个排名更有意思的地方在于一个信号——Agent 这个品类热度已经明显压过了模型本身。结合这段时间后台收到的私信很多朋友其实还在纠结几个基础问题Agent 和 LLM 到底有什么区别常说的 DeepSeek 算是哪一类Hermes 为什么能冲上来Claude Code、Codex 这种工具又该怎么装上、怎么用好这篇文章我就按自己的实操经验来聊。我会从这张榜单讲起把 Agent 的分层逻辑讲清楚然后逐个拆解 Hermes、Claude Code、Codex 的安装部署、使用心得和常见报错最后给出一套从 0 到 1 搭 AI Agent 的练手思路。内容偏实用向适合刚接触 Agent、想在本地跑通第一个智能体的朋友。1. 从九月榜说起Agent 正在从概念进入工具落地1.1 榜单里的三个名字对应的其实是三条路线先说我怎么理解这份榜单。Hermes 排第一Claude Code 和 Codex 进前十这三个名字放在一起恰好代表了当前 Agent 生态里的三种主流路线Hermes 这类开源 Agent 项目主打自托管、本地化部署强调数据不出内网、模型可替换。社区能直接拿到代码和权重二次开发门槛低所以在开发者圈子里扩散速度特别快。Claude Code 这类闭源编码助手由模型厂商直接提供走的是“开箱即用”路线。装上就能在一个终端会话里完成代码阅读、修改、测试、提交属于把 Agent 能力产品化的典型代表。Codex 这类面向开发者的 Agent CLI同样来自模型厂商但它更强调可编程性支持通过配置文件切换模型端点给了用户很大的自定义空间甚至可以接到第三方模型上使用。这三条路线没有绝对优劣只是适用人群不同。榜单排名的波动本质上是不同人群的使用频率在变化。当 Hermes 冲到头部说明越来越多的人愿意折腾本地部署当 Claude Code、Codex 长期占着前十说明编码类 Agent 已经成了很多人日常工作流里离不开的一部分。1.2 这个排名信号比名次本身更有价值我更愿意把这份榜单看成“工具成熟度”的指标而不是“模型能力”的排名。前几个月大家还在讨论“Agent 会不会取代提示词工程”一个月后讨论最多的已经变成“我的 Agent 卡在工具调用上怎么办”——这说明什么说明 Agent 已经从概念验证阶段走到了真实的工程落地阶段。这时候再看热搜词就非常能说明问题。除了 “hermes”、“claude code”、“codex” 这些产品名出现频率最高的一批是“agent 和 llm 和 ai 模型 有什么区别”、“deepseek 属于哪个”、“从 0 到 1 搭建 ai agent”、“ai agent 组成结构”。这其实是同一批人在从“围观”转向“上手”的过程中必然会遇到的困惑。所以接下来的内容我建议你按顺序读下去先搞清楚 Agent 和模型的关系再决定工具选型最后动手搭一个自己的 Agent。2. Agent 不是 LLM 的另一个名字先分清三层结构2.1 LLM、AI 模型与 Agent 的准确分工很多朋友第一次接触这个概念时会默认“Agent 就是一个更聪明的模型”这个理解其实不准确。AI 模型是一个很大的集合包括图像模型、语音模型、文本模型等。LLM大语言模型是其中专门处理自然语言的一类它的核心能力是“看懂输入、生成输出”。而 Agent 不是模型它是一套完整的行为系统通常由模型 规划 工具调用 记忆 执行这几部分组成。我用一个自己常打的比方来解释LLM 是发动机Agent 是整车。发动机决定了这辆车能跑多快但车里还有方向盘、导航、油门、刹车甚至副驾上还坐着一位帮你盯路况的领航员。一辆车好不好开不完全取决于发动机更取决于这些部件能不能配合好。放到实际场景里只调用 LLM 时你做的是“给模型一段指令让它返回一段文字”而用 Agent 时你做的是“给模型一个目标让它自己决定调什么工具、看什么结果、下一步做什么”。比如同样是“帮我查一下天气再定明天行程”LLM 只能给你一段建议Agent 则会去调用天气查询工具、拿到实时数据、再结合日历排序最后给出一个完整方案。2.2 DeepSeek 属于哪一层顺着上面的分层这个问题就很好回答了。DeepSeek 属于模型层而且是开源模型里非常有代表性的一个。它本身不提供 Agent 的完整能力你需要把它当成 Agent 的“大脑”来用。做法通常是两种直接使用 DeepSeek 官方 API在代码里通过接口调用然后在外面套上自己的工具调用逻辑用 Hermes 这类 Agent 框架把 DeepSeek 配置为底层的模型服务由框架负责规划、工具调用和上下文管理。这也是为什么热词里会同时出现 “deepseek hermes” 和 “deepseek hermes 官网”——大家真正想要的是“把 DeepSeek 这样的好模型接进一套能跑起来的 Agent 系统里”。Hermes 之所以被频繁和 DeepSeek 关联正是因为它作为开源框架对这类开源模型的接入做得比较顺滑。2.3 为什么很多人会把 Agent 和大模型混为一谈把 Agent 和大模型混为一谈一方面是因为很多厂商在宣传时直接把“智能体”挂在了大模型产品下面另一方面是近两年模型的能力确实强到让人误以为“模型本身能自主完成任务”。但只要你实际动手写过一个 Agent 就会发现模型返回的内容只是中间产物。真正的 Agent 工程大量精力花在工具定义、结果解析、错误恢复、上下文裁剪这些“不性感”的环节上。这也是我在后面两节想重点展开的东西。3. Hermes 排第一的原因把“能用”做成了默认项3.1 Hermes 的核心能力拆解Hermes 能在一众 Agent 项目里排到前面我实测下来它确实有几个很实在的设计工具调用function calling做得非常规整。Agent 和模型之间最关键的接口就是工具调用。Hermes 对这块的格式定义很清晰模型返回什么结构、框架怎么解析、错误怎么回传都有统一约定。这直接降低了二次开发时踩格式坑的概率。本地部署适配好。它不挑硬件显存有限的机器也能跑支持常见的模型加载方式和推理服务。你可以把 DeepSeek、Qwen 这类开源模型放进去也可以接在线 API。上下文管理内置了优化策略。Agent 跑久了最容易爆掉的是上下文窗口。Hermes 提供了消息裁剪和摘要机制虽然不见得多惊艳但至少让你不用从零写一套上下文管理逻辑。桌面端和命令行端都有现成入口。热词里反复出现 “hermes desktop”“hermes 桌面版”说明很多人希望有一个能直接打开的界面而不是每次都在终端里操作。我个人的判断是Hermes 排第一不是因为它某个单项能力碾压同类而是因为它把“本地跑通一个 Agent”这件事的门槛降到了最低。3.2 Hermes 的安装部署实操下面给一套我在 Ubuntu 环境下的部署流程Windows 和 macOS 思路基本一致只是包管理命令不同。第一步准备基础环境# 更新系统并安装基本工具 sudo apt update sudo apt install -y git curl python3 python3-pip # 安装项目以官方仓库安装方式为例 git clone https://github.com/hermes官方仓库.git cd hermes pip install -r requirements.txt注意具体仓库地址请以 Hermes 官方发布页为准不同版本依赖差异较大。如果不确定优先用官方文档里的安装命令。第二步配置模型服务Hermes 本身不强制绑定某个模型。你可以选两种方式之一本地用 vLLM 或 Ollama 起模型服务比如把 DeepSeek 的量化权重下载下来跑使用云 API在配置文件里填入接口地址和密钥。我自己的习惯是先本地跑一个小模型验证流程再切到更强大的模型正式使用。这样排查逻辑问题时不会把“模型能力不足”和“Agent 代码有 bug”混在一起。第三步启动服务并验证python main.py --config config.yaml启动后先用最简单的任务做一次端到端验证比如让它“调用计算工具算一下 123 乘以 456然后输出结果”。如果这一步能通说明你的 Hermes 底层链路已经正常接下来再逐步加复杂度。3.3 桌面客户端怎么配热词里很多人搜“hermes desktop”其实就是想在桌面上开一个聊天窗口。据我了解社区里比较常见的做法是给 Hermes 配一个桌面前端用 WebUI 的方式接入本地服务配置时主要填三项服务地址、模型名称、API Key本地部署时往往不需要。配置完成后你会得到一个和普通聊天软件体验类似的界面但底层跑的是完整的 Agent 链路。对于团队内部交付这种方式比直接甩一个命令行脚本友好得多。4. Claude Code 与 Codex两种编码 Agent 的使用全解4.1 Claude Code 的安装与 VS Code 配置Claude Code 是编码类 Agent 里我使用频率比较高的一个工具核心场景是在终端里直接让它读取项目代码、定位问题、改代码、跑测试。安装很直接# 通过 npm 安装 npm install -g anthropic-ai/claude-code # 检查是否安装成功 claude --version如果你更习惯原生安装包官方也提供独立的安装脚本看个人偏好。装好之后在项目根目录运行claude它会进入一个交互式终端。你可以用自然语言下达指令比如“找到用户登录模块里 Session 过期的 bug”它会自己读源码、给修改方案、甚至直接改文件。在 VS Code 里使用的话需要装官方扩展然后绑定同一个账号或 API Key。我的经验是先在一个小项目上跑通再放到大型项目里用。因为大型项目的上下文很长如何给 Claude Code 指出“该看哪个目录”是一门技巧很多时候你需要在指令里带上关键路径否则它会在无关代码里浪费大量上下文。提示Claude Code 适合做“局部的深度修改”不太适合盲目让它理解整个巨型项目。你越清楚项目的边界它的表现越好。4.2 Codex 的安装与第三方模型接入Codex 是另一条路线的代表。它同样是一个编码 Agent CLI但最大的特点是端点可配置。你不需要被绑定在官方模型上可以通过配置文件或者环境变量把它指向任何兼容的模型服务。安装方式npm install -g openai/codex codex --version如果需要登录官方服务一般执行一次codex login就行。但很多国内用户更感兴趣的是“codex 接入 deepseek”——也就是把 Codex 的底层模型换成 DeepSeek。配置思路是通过环境变量指过去export OPENAI_BASE_URLhttps://api.deepseek.com export OPENAI_API_KEY你的deepseek密钥这样配置后Codex 的请求会被转发到 DeepSeek 的接口上。好处是成本更低、模型可控代价是第三方端点对某些高阶能力比如特殊工具调用格式可能不完全兼容需要自己调。4.3 高频报错endpoint 代理失败到底怎么解热词里有一条很典型的报错场景大意是“cc switch local proxy failed while handling codex endpoint /responses”。我自己也踩过类似的坑这里把定位思路分享出来。这个报错的本质是你通过切换工具或本地代理接管了 Codex 的请求但代理在处理/responses这个端点时挂了。常见原因有三个代理服务本身没起来检查本地代理进程是否在监听。比如代理默认跑在 8080 端口用curl http://localhost:8080测一下通不通。端点映射不对Codex 这类工具在切换端点后会向目标的/v1/responses或/responses发请求。如果代理层只实现了聊天补全接口没实现 responses 接口必然报错。此时要么换一个实现了完整接口的代理要么在配置里指定兼容的路径。环境变量覆盖产生冲突有时候你设置了OPENAI_BASE_URL但切换工具又把自己的代理地址写入全局配置两者冲突导致请求被导到错误地址。优先检查当前 Shell 里的环境变量再检查配置文件。排查顺序我建议是先看代理进程再看日志里的实际请求路径最后比对配置。90% 的这类问题都是第二个原因——代理只做了转发没做协议转换。5. 从 0 到 1 搭一个自己的 Agent结构、练手与避坑5.1 一个最小 Agent 需要哪些零件看再多别人的 Agent不如自己搭一个。搭之前先记住这个最小结构模型接入层负责和 LLM 通信可以是 OpenAI 兼容接口也可以是本地推理服务工具层Agent 能调用的外部能力比如搜索网页、执行代码、查数据库规划层决定“下一步调哪个工具、要不要继续循环”记忆层保存历史对话和关键状态避免每次重新理解入口层CLI、Web 界面或聊天机器人负责接收用户输入。用 Python 实现一个极简 Agent核心逻辑其实就是一个循环while True: user_input input(你: ) if user_input exit: break # 1. 把用户输入和历史上下文组装好发给模型 response llm.chat(messages [user_input]) # 2. 判断模型输出是否想调用工具 tool_call parse_tool_call(response) if tool_call: result execute_tool(tool_call) # 3. 把工具结果返给模型让它继续 messages.append(result) else: print(response.content)这段代码省略了很多细节但完整的 Agent 骨架就是这样模型决定要不要工具工具结果再喂回模型直到模型认为任务完成。你照着这个结构去查资料、补细节会比直接啃大型项目高效得多。5.2 三个适合练手的小项目我建议新手不要一上来就做一个“全能助手”而是从边界清晰的小任务开始。项目一日报生成助手让 Agent 读取一天的 Git 提交记录、筛选关键变更、调用 LLM 生成结构化日报。这个项目能训练你“工具返回结果 → 结构化输入模型 → 输出格式化文本”的闭环能力。项目二代码 Review 助手用一个脚本把指定文件的 diff 提取出来交给 Agent 按规则审查比如检查错误处理、命名规范输出审查意见。这个项目能让你理解如何给 Agent 设定“边界”避免它提出一堆不切实际的建议。项目三会议纪要小助手输入一段录音转写文本Agent 调用摘要工具提炼重点再调用日历工具生成待办提醒。这个项目能让你练习多渠道工具协同是以后做复杂 Agent 的基础。5.3 我在实测中踩过的坑有几个坑我几乎每个项目都会遇到提前说出来能帮你省很多时间工具调用结果不解析就塞回模型这是最常见的问题。模型返回的 tool_call 里可能包含大量无用字段直接塞回上下文不但浪费 token还会让后续输出变得不稳定。一定要先做清洗和截断。把对话历史无限累积跑两小时后上下文爆掉是新手必经之路。我的做法是超过一定轮数就把早期消息压缩成摘要。牺牲一点细节换来稳定性。测试时用真实 API 而不做 mock联调阶段没问题一到批量测试就烧钱。给工具层做一层 mock让 Agent 在“假装调用工具”的模式下跑通流程再切换到真实环境速度快得多。忽略错误恢复真实环境里工具会失败网络会超时。一个健壮的 Agent必须有“失败后重试一次或换一种策略”的逻辑否则任何一次临时故障都会卡死整个流程。这些坑基本都会在你搭建第一个 Agent 时遇到提前知道能少走很多弯路。6. 后面值得继续扩展的方向6.1 Skill 开发与工具编排把最小 Agent 跑通后进阶方向就是给 Agent 开发 Skill技能。一个 Skill 的本质是把“一段提示词 一组工具调用逻辑 输出模板”打包成一个可复用的模块。比如“代码审查”是一个 Skill“生成测试用例”是另一个 Skill。我建议你从一开始就给 Agent 规划好 Skill 目录每个 Skill 独立文件夹、独立说明文件、独立工具白名单。这样 Agent 在需要某项能力时能快速定位到对应 Skill而不是把所有工具的说明全部塞进系统提示词里。6.2 把 Agent 接进业务系统包括传统场景Agent 的应用场景远不止写代码。最近有不少同行在讨论“ai agent 与 plc 编程”——也就是把 Agent 用到工业自动化领域。听起来跨度很大但本质逻辑是一样的PLC 编程有标准化的指令集和文档Agent 只要能把需求转化为结构化指令再调对应编译工具做校验就能形成闭环。这类传统行业的场景反而比通用助手更有落地价值因为边界清晰、评估标准明确。如果你所在行业有类似的工具链建议优先选择这类场景做试点比硬做一个“通用问答机器人”回报率高得多。6.3 学习路径与资源建议最后聊一下学习路径。我的建议是控制在两天内完成第一轮实践Day 1跑通 Hermes 或同类框架的部署完成一次端到端工具调用Day 2自己写一个最小 Agent接一个真实工具加上记忆和错误处理。过程中尽量去翻官方文档和开源项目源码比看二手教程高效。现在社区里也有一些成体系的 Agent 开发资料比如热词里提到的 “ai agent book”可以作为补充但核心还是要动手。回头再看 9 月这份榜单Hermes 第一、Claude Code 和 Codex 进前十其实只是结果。真正的变化是越来越多的人开始把 Agent 当成日常工具来用了。你现在读到这里如果还没动手搭建过建议找一个下午从跑通一个最小 Agent 开始。这个领域最公平的一点就是——无论榜单怎么变自己亲手跑通一遍学到的经验永远是最扎实的。
