拆开Hermes Agent：企业怎么自建一套会“越用越强”的AI Agent系统

如果你这段时间一直在看 Agent 项目大概率绕不开 Hermes。它真正吓人的不只是“能跑命令、能改文件、能开浏览器”。而是另一件事它不是一个把大模型外面包了一层工具壳的玩具而是一套已经把“记忆、技能、协作、执行、回收”接成闭环的系统。这也是为什么很多人第一次用 Hermes会有一种很强的体感它不像在“回答问题”。 它更像在“干活”。更关键的是这套东西不是玄学。我把 Hermes 的关键代码翻了一遍后发现它的核心并不神秘。真正值得企业抄的不是它的安装脚本也不是某个提示词而是它背后的架构取舍。截至今天Hermes Agent 的 GitHub 星标已经超过10 万。4 月 8 日发布的v0.8.0是它真正出圈的节点之一而在这之后v0.9.0、v0.10.0 还在持续快迭代。所以我不讲“怎么装”。我讨论 3 个问题Hermes 到底强在哪一层企业如果照着学最该抄什么不该抄什么如果你想自建一套企业级 Agent 系统技术路线应该怎么走一、Hermes 真正厉害的地方不是工具多而是“三层分离”很多文章讲 Hermes喜欢从功能清单开始。能连浏览器。 能跑终端。 能读写文件。 能做子 Agent。 能记住用户偏好。这些都没错。 但如果你只停在这一层就很容易把 Hermes 看成“一个工具很全的 Claude Shell”。这会低估它。我看完代码后感觉 Hermes 真正值得拆的是一个很清晰的三层模型大脑层负责推理、规划、决策、纠偏肌肉层负责工具执行和技能复用神经层负责记忆、检索、上下文传递和多 Agent 协同这三层不是嘴上说说。 在代码里它们是分开的。1大脑层不是工作流而是“会看结果再继续想”的执行闭环很多人以为 Hermes 的核心入口在 CLI。其实不是。 真正的中枢在run_agent.py里的AIAgent。它的主循环非常直白组装 system prompt 和当前消息调模型如果模型发起 tool call就立刻执行把工具结果再塞回上下文继续下一轮直到模型不再调用工具直接输出结论这件事听起来很普通。 但区别在于Hermes 不是一次性“规划完再执行”而是每执行一步就把真实反馈重新喂回大脑。这和很多传统 LangChain 式“链式调用”不一样。 后者更像预先编排好的流程。 Hermes 更像一个持续感知环境变化的执行体。你可以把它理解成不是“先写作战计划再按计划走完”。 而是“先走一步看地形再决定下一步”。这也是它做复杂任务时更像真人工程师的原因。2肌肉层Hermes 不是堆工具而是把工具做成统一可编排的能力层Hermes 的第二个高明点是它没有把工具写成一堆散装脚本。它有一个统一注册中心。model_tools.py会在启动时集中导入各个tools/*.py模块每个工具再通过tools/registry.py统一注册自己的 schema、handler、toolset、可用条件。这个设计看似工程细节实际上很关键。因为对 Agent 来说工具不是脚本工具是“可被大模型理解、筛选、组合、限制”的能力对象。Hermes 之所以扩展快就是因为它做到了几件事工具定义统一toolset 可以按场景裁剪不可用工具会在 schema 层就被过滤execute_code、browser这类工具的说明还能根据当前可用工具动态改写避免模型幻觉调用不存在的能力这一步的价值很大。很多企业自己做 Agent第一版经常死在这里 后端写了一堆函数但模型根本不知道哪些能用、什么时候该用、用了会返回什么。Hermes 的做法更像是在给模型建“肌肉群”而不是扔一箱工具让它自己翻。3神经层记忆、检索、委托不是附件而是执行系统的一部分Hermes 的第三层是它最容易被忽视、但也是最接近“自进化”的地方。先看记忆。hermes_state.py里Hermes 用的是SQLite WAL FTS5。 这不是一个花哨方案但很聪明。SQLite 够轻个人和小团队能直接用WAL 让多读单写并发更稳FTS5 让历史会话可全文检索messages_fts还通过 trigger 和消息表联动更新这意味着什么意味着 Hermes 的“记住”不是把上一轮聊天塞进 prompt 那么简单。 而是把会话历史变成了一个可以召回、可以检索、可以跨会话延续的状态层。再看长期记忆。tools/memory_tool.py的做法也很有意思。 它把 MEMORY 和 USER 分开维护而且采用frozen snapshot机制会话开始时把记忆快照注入 system prompt会话中途可以继续写入磁盘但不会反复改 system prompt避免打爆 prompt cache这是一个典型的工程化取舍。 不是最“聪明”但很“能跑”。最后是多 Agent 委托。tools/delegate_tool.py明确写了 每个子 Agent 都拿到一份独立上下文、独立 task_id、独立终端会话而且默认禁止递归委托、禁止直接写共享 memory、禁止让子 Agent 自己再开用户澄清。这背后其实是一条很成熟的原则协作必须有边界。一个主 Agent 可以统筹。 但子 Agent 必须隔离。 否则复杂任务一多整个系统就会因为上下文串味、权限串味、预算串味而失控。二、Hermes 为什么会给人一种“越用越顺手”的感觉因为它至少做对了 3 件很多 Agent 项目都没做对的事。第一它把“技能”变成了可积累的程序性经验Hermes 不是只有工具。 它还有 Skill。tools/skills_tool.py里Skill 本质上是SKILL.md 可选 references/templates/scripts 的目录结构默认存放在~/.hermes/skills/。更关键的是agent/skill_commands.py在加载 Skill 时不是粗暴改 system prompt而是把 Skill 作为一段结构化说明注入消息里尽量保住 prompt caching。这意味着 Skill 不只是说明书。 它是被压缩过的一次成功经验。一次复杂任务跑通后你可以把触发条件执行顺序关键命令踩坑提醒验收标准全部固化成可复用经验。这就是为什么我说 Hermes 像“会成长”。 它不是自己神秘进化了。 而是把一次次任务沉淀成了结构化经验然后下次更快命中。第二它把“记忆”分成了几种不同形态很多团队一说记忆就只想到向量库。但 Hermes 给了一个更实用的启发短期记忆当前对话里的消息流长期记忆可检索的历史会话和用户偏好技能记忆一旦验证有效就固化成 Skill这三种东西不是一回事。很多企业 Agent 项目迟迟做不稳问题就出在把三者混成一锅粥把所有历史都塞 RAG把一次性任务记录当长期偏好把临时成功路径误当团队标准流程Hermes 的价值不在于它记得更多。 而在于它更清楚什么该记成上下文什么该记成偏好什么该记成技能。第三它把“协作”建立在资源隔离上而不是消息互聊上很多多 Agent 框架喜欢把“Agent 对话”做得很热闹。但对企业来说真正有价值的不是热闹。 是可控。Hermes 的委托机制很克制子 Agent 没有父上下文历史子 Agent 不能随便再委托子 Agent 工具集可裁剪子 Agent 结果只回传摘要不把中间噪音全灌回父上下文这其实非常适合企业系统。因为企业要的从来不是“十个 Agent 同时聊天”。 而是不同岗位的智能执行体能不能在权限可控、上下文可控、成本可控的前提下并行干活。三、但企业不能直接把 Hermes 原样搬进去说实话Hermes 很强。但企业如果直接照抄八成会遇到 4 个问题。1. 记忆规模不够Hermes 当前这套 SQLite 本地文件记忆非常适合个人和小团队。但企业一旦上量问题就来了跨部门知识量大文档源杂会话量高权限边界复杂这时候单机 SQLite 只能做一个很好的原型不是终局。2. Skill 适合个人积累不等于适合组织治理个人用 Skill 很爽。 但企业要的是谁能发布技能谁能升级技能技能是否可审计不同部门能否隔离访问一个技能出错后如何快速回滚也就是说企业需要的不是“技能目录”而是“技能注册中心”。3. 安全和审计还不够重Hermes 已经有不少安全意识比如危险命令审批、工具限制、子 Agent 工具封禁。但企业还要更多RBAC 权限操作审计敏感数据脱敏多租户隔离API 网关限流合规留痕个人 Agent 和企业 Agent 的分水岭往往就在这。4. 高可用不是它当前的主目标Hermes 今天的定位本质上还是“高能力的通用 Agent Runtime”。企业系统要的则是多副本故障转移模型路由成本治理服务化接入所以企业要学的不是 Hermes 的部署形态。 是它的架构思想。四、如果让企业自建一套“企业版 Hermes”我会怎么搭我的建议很明确别照着 Hermes 一比一复刻照着它的分层思路重组。可以按下面这套五层来搭。1接入层先把入口统一入口不复杂。 关键是统一。可以接企业微信 / 飞书 / 钉钉Web PortalOpenAPI内部工单系统IDE / VS Code 插件入口多不是问题。 入口协议不统一才是问题。2Agent 编排层拿大脑别拿工作流截图冒充大脑这一层是核心。如果你的任务是复杂多步、强闭环我更建议用LangGraph适合做可控图编排方便把“规划—执行—反思”做成显式状态机AutoGen适合多 Agent 协作明显的场景AgentScope适合更重的分布式和可观测场景CrewAI适合角色比较固定、流程相对稳定的团队协作总的来说就是要精细控制就上 LangGraph要多 Agent 通信就看 AutoGen要偏企业分布式就看 AgentScope要轻量角色协作就用 CrewAI3记忆层别一上来就“All in 向量库”企业记忆至少要分三层用户偏好和执行元数据关系型数据库会话与操作日志日志存储 / 检索库语义知识与经验召回向量数据库向量库选型可以很务实Milvus大规模场景Qdrant中型团队很好用Pgvector已经重度用 PostgreSQL 的团队最省心记住一点向量库是记忆的一部分不是记忆本身。4技能层用 Git 管技能用索引服务管发现这一层非常关键。我建议企业直接把 Skill 做成Git 仓库存版本元数据中心存权限、标签、适用部门向量 / 关键词双索引做技能发现发布流程里带审校和回滚这样做的好处是Skill 从“个人经验包”升级成“组织可治理资产”。5知识库和治理层别让 Agent 裸奔知识库推荐按企业现状选想快速落地可以接 Dify / FastGPT / RAGFlow想深做文档解析和复杂文件理解RAGFlow 会更强想完全自控就把解析、切片、重排、检索拆开自己搭而治理层至少别省掉这几件事认证Keycloak / Casdoor网关Kong / APISIX审计日志ELK / Loki监控告警Prometheus Grafana企业不是缺一个会回答问题的机器人。 企业缺的是一套敢接业务、能审计、出了事能追责的 Agent 基础设施。五、真正能落地的推进路径别一口气做“全功能智能平台”如果让我给一家企业排实施顺序我会分 4 段。第一阶段先做闭环 MVP目标只有一个 证明 Agent 能把一个真实业务任务跑通。优先做一个主 Agent3 到 5 个高频工具一个最小记忆层一个企业入口一个能回放的执行日志这时候不要急着谈“自治组织”。 先让它在单点任务上稳定交付。第二阶段补记忆和知识当闭环跑稳后再加向量检索企业文档接入技能沉淀工具权限控制这一步解决的是“能不能复用”。第三阶段补治理和协作这时候才值得上多 Agent 协作技能发布流审计与监控多租户隔离模型路由和降级这一步解决的是“能不能进组织”。第四阶段再谈自进化所谓自进化不是让 Agent 自己胡乱长。真正靠谱的自进化是下面这条闭环记录执行轨迹识别高成功路径提炼成 Skill 或模板做 A/B 验证审核通过后再发布也就是说企业里的“自进化”本质上是可审计的持续优化不是不受控的自我变异。结尾Hermes 最值得企业学的不是产品形态而是架构克制Hermes 火不只是因为它会调用工具。真正厉害的地方在于它把 Agent 这件事从“一个会聊天的大模型”往前推成了一套有分层、有边界、有记忆、有技能、有协作的执行系统。它证明了一件很重要的事Agent 不需要一开始就全知全能。它只要把大脑、肌肉、神经三层接好就会开始出现系统级能力。这也是企业今天最该抄的地方。不是抄某个提示词。 不是抄某个模型名字。 不是抄某个 Demo 页面。而是抄这套思路决策层要能闭环执行层要可编排记忆层要可检索技能层要可沉淀协作层要有边界治理层要先于规模化上线用别人的 Agent很快。 造自己家的 Agent很难。但真正的护城河从来都不在“会不会用”而在“你有没有把这套系统长到自己业务骨头里”。问题不是你的企业要不要做 Agent。问题是你准备把它做成一个聊天入口还是做成下一代执行基础设施学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】