本文深入解析了 Hermes Agent 架构阐述其如何整合传统技术框架与 LLM 能力实现高效的状态管理与事件驱动。文章从用户入口到 LLM 调用的完整流程详细拆解了适配器层、事件总线/脚手架层、GatewayRunner、AIAgent 等核心组件的功能与协作机制帮助初学者理解大模型应用的开发模式并通过收藏本文随时回顾学习要点。摘要AI Agent 是具有状态的Stateful、事件驱动的、甚至需要长期存活在后台不断自我循环的。这恰恰是前端和客户端写烂了的模式管理复杂的 UI 状态机、处理高频的用户交互事件、RunLoop 守护进程。如果用过去传统编程领域的知识看待 Agent 架构会发现它并没有发明任何新的技术框架仅仅是在某些事件节点中加入了 LLM 能力。 这也就是那个经典公式的由来Agent Harness Model读完全文你会发现 Harness 是个整合了各种已经被广泛使用的技术架构的综合体并且使用的全是大家熟悉的框架思想。Hermes Agent 总览Hermes 并不是把一个 LLM 扔进 ReAct 循环里跑那么简单。它是一个正经的运行时——接收外部事件、通过生命周期脚手架路由、安全地调度 agent 工作、在可能的情况下复用本地 agent 控制器、然后用重建的上下文去调用一个无状态的远端 LLM。整体架构全景图架构全景图从左往右看分别是用户/平台入口 - 飞书、tg 等入口适配器层 - 将不同入口的信息统一为内部的 MessageEvent 结构事件总线层 Event Bus - 管理完整的生命周期监听、事件派发GatewayRunner 核心调度层 - 并发控制、线程管理调度 (这一层是核心层)AI Agent - 大家熟悉的 ReAct 的实现运行层无状态 LLM 接口层 - 调用各个 LLM 厂商接口接下来根据这个架构全景图进行层层拆解。Hermes Agent 第一层用户 / 平台入口最外层就是真实世界入口用户在某个平台上发了条消息——可能是 Telegram、Discord、Slack、CLI或者其他接入方式。这时候消息还是平台相关的半成品Telegram updateDiscord messageCLI inputWebhook payload这些原始的平台 payload 还不是 agent 任务。它们得先被洗一遍标准化核心运行时才能处理。第二层适配器层适配器层负责把平台特定的输入转成 Hermes 内部事件。它要回答的问题包括谁发的属于哪个会话 Session消息文本是什么有没有图片、文件、音频附件session_key 是啥这个 Session 会话是不是已经在忙了概念上适配器产出的东西长这样MessageEvent session_key 来源元数据session_key 极其重要。它是本地会话的身份标识用来把工作路由到正确的会话通道里。session_key 会话身份证适配器还参与了会话级别的门禁active_sessions[session_key] 忙状态守卫 pending_messages[session_key] 下一轮 / 中断这意味着 Hermes 会尽量避免同一个会话同时跑两个独立的 agent 循环——那不乱套了嘛。第三层事件总线 / 脚手架层事件总线/脚手架层是整个架构里最核心的概念层。这层很容易被误解。事件总线不跑 ReAct 循环它不思考也不以 agent 的身份调用工具。它的活儿是协调事件在整个运行时中的生命周期流转。你可以把它理解成以下几样东西的缝合体一个事件发射器。一条中间件管道。一套生命周期钩子系统。一个异步协调层。一个在主 agent 运行前后触发副作用的地方。Event Bus 事件总线干了啥事件总线/脚手架层负责路由和生命周期控制。它处理的概念包括publish(event) —— 发布事件subscribe(handler) —— 订阅处理器lifecycle hooks —— 生命周期钩子async dispatch —— 异步派发side effects —— 副作用interrupt signals —— 中断信号pending-message triggers —— 挂起消息触发简化版的生命周期大概长这样on_message_received —— 收到消息- on_processing_start —— 开始处理- on_agent_run —— agent 运行- on_tool_event —— 工具事件- on_response_sent —— 回复已发送- on_processing_complete —— 处理完成在源码中这些总线职责可能分散在适配器、钩子、后台任务和 GatewayRunner 里而不是实现成一个叫EventBus的传统单一类。事件总线不管啥事件总线不拥有这些东西工作线程池。AIAgent 缓存。ReAct 循环。远端 LLM 会话。本地工具执行的语义。它的角色更像是有个事件发生了。该通知谁该跑哪些生命周期钩子要不要触发中断要不要开始处理要不要发 typing 指示器、打日志、上报指标、或者做清理这里使用 Node.js 事件循环做类比如果你熟悉 Node.js你肯定对这个事件总线不陌生Node.js EventEmitter ~ 发布 / 订阅 Express 中间件 ~ 生命周期拦截 Node 事件循环 Event Loop ~ 异步调度面 libuv 工作线程池 ~ 共享执行器跑阻塞任务 应用处理器 ~ GatewayRunner AIAgent事件总线跟操作系统的事件循环不是一回事。它是在异步运行时行为之上构建的应用层事件协调模式。为啥 Harness 要有这一层没有这一层的话每个平台适配器(tg feishu 等平台入口)都得自己撸一遍相同的逻辑开关 typing 指示器。记录消息生命周期事件。触发进度更新。处理中断。处理挂起消息。跑清理逻辑。通知可观测性或指标处理器。把平台相关代码和 agent 逻辑隔离开。事件总线/脚手架层把这些生命周期关注点挡在核心 ReAct 循环外面。这个分离很重要事件总线/脚手架 事件生命周期 副作用 AIAgent ReAct 循环 推理 工具调用 观测 最终回答事件总线中的顺序与并发对单条消息来说生命周期阶段大体是有序的收到 - 开始处理 - agent 运行 - 回复 - 完成但跨不同会话时事件可以并发推进会话 A 的事件正在处理中会话 B 的事件可以同时开始处理会话 C 的事件在排队等工作线程对同一个会话Hermes 尽量保持同一时间只有一个活跃运行同一个 session_key - 一个活跃运行 活跃期间来新消息 - 挂起 / 中断 / 排队行为这是一个关键的设计决策。系统允许跨会话并发但保护单个会话不会同时跑多个互相打架的 agent 循环。事件总线伪代码async def handle_raw_platform_message(raw): event adapter.to_message_event(raw) session_key event.session_key await publish(message_received, event) if adapter.is_session_active(session_key): adapter.store_pending_or_interrupt(session_key, event) await publish(message_pending, event) return await publish(processing_start, event) try: response await gateway_runner.handle_message(event) await publish(response_sent, response) finally: await publish(processing_complete, event)第四层GatewayRunnerGatewayRunner 是运行时的全局调度器 Worker。如果说事件总线是生命周期协调层那 GatewayRunner 就是决定 agent 工作怎么准备、怎么执行的那一层。GatewayRunner 管什么GatewayRunner 拥有或协调这些主要的运行时资源ThreadPoolExecutor —— 线程池running_agents —— 活跃运行追踪agent_cache —— 按 session_key 缓存的 AIAgent 对象session store —— 会话存储queued events —— 排队事件model / provider config —— 模型/提供商配置progress and interrupt monitoring —— 进度和中断监控adapters —— 适配器当任务到来时GatewayRunner 并不会为 Session 会话创建一个永久的工作线程。它把阻塞的 agent 工作提交到共享执行器中。会话 A 借用工作线程 1会话 B 借用工作线程 2会话 C 如果池满了就等着当 agent 跑完工作线程还回池里。工作线程不归会话所有共享线程池Hermes 用一个共享线程池来处理阻塞的 agent 工作。原因很实际agent.run_conversation() 可能会调远端 API、跑工具、跟文件交互、等子进程、流式输出——这些活儿不应该阻塞异步消息处理循环。所以 GatewayRunner 概念上是这么干的pythonawaitloop.run_in_executor(shared_thread_pool,run_sync,)在run_sync里面Hermes 最终调用pythonagent.run_conversation(message,conversation_historyhistory)关键思想异步事件处理保持响应灵敏阻塞的 agent 运行扔到工作线程里搞目前调研下来GatewayRunner 里有用协程_handle_message、_run_agent_inner 都是 async def周边也会用 asyncio.create_task() 跑 progress、stream、interrupt monitor 等任务。但核心 AIAgent loop 不是协程是同步函数放进线程池跑。参考源代码https://github.com/NousResearch/hermes-agent/blob/main/gateway/run.py所以调用流程大致如下某个 worker thread 被 Session A 的 agent run 占用 - agent 正在等 LLM / 读文件 / 跑工具 - 这个 worker thread 不会让出来给 Session B - 只有等这个 run 返回线程才归还线程池可以看到agent 读取文件的时候明显是个 IO 阻塞。但是线程依然等待着不会让出这并不符合现代协程的高效特点。我猜是为了降低代码复杂度毕竟这是一个跑在用户机器上的 Agent并发要求很低。(这里比较复杂有不对的地方还请指正)线程池满了咋办如果所有工作线程都在忙新的执行器任务就在执行器队列里排队等着。这就是正常的背压池里有空闲线程 - 立刻开跑池满了 - 等着这不代表会话拥有某个工作线程。只代表任务在等共享资源空出来。每个会话一个活跃运行GatewayRunner 和适配器层一起协作保护会话不会被重复运行。对单个 session_key同一时间只有一个活跃的 agent 运行如果会话活跃期间又来了新消息Hermes 可能会把它存为挂起的下一轮。把它当作中断信号处理。把它当命令路由。如果用户用了队列语义就放进显式的 FIFO 队列里。重要的区别默认挂起消息 通常是一个下一轮/中断槽位 显式队列 FIFO 语义所以别想当然地以为每条普通消息都会进一个大 FIFO 队列。默认行为更像是保护这个会话记下接下来来了啥可能的话打断它。GatewayRunner 伪代码:async def gateway_handle_message(event): session_key event.session_key mark_running_or_pending(session_key) def run_sync(): history load_history(session_key) config resolve_model_and_tools(event) agent agent_cache.get(session_key, config) if agent is None: agent AIAgent(configconfig, session_keysession_key) agent_cache[session_key] agent return agent.run_conversation( event.text, conversation_historyhistory, ) result await run_in_executor(shared_thread_pool, run_sync) persist_result(session_key, result) clear_running(session_key) drain_pending_if_any(session_key) return result.final_response这里展示了核心的调度关系GatewayRunner 负责调度。ThreadPoolExecutor 提供临时执行线程。AIAgent 执行 ReAct 循环。第五层AIAgent‘AIAgent’ 是本地 agent 控制器。它是一个本地运行时对象- 用哪个模型/提供商。 - 有哪些工具可用。 - 怎么构建消息。 - 怎么管理会话历史。 - 怎么跑 ReAct 循环。 - 怎么处理中断。 - 怎么执行工具调用。 - 怎么产出最终回复。内部循环调 LLM- 模型返回最终回答- 停调 LLM- 模型返回 tool_calls- 执行工具- 追加观测结果- 再调 LLM这就是 ReAct 模式推理(Reason) - 行动(Action) - 观测(Observation) - 重复用代码表示while not done and iteration_count max_iterations: assistant_message call_llm(messages, toolstool_schemas) if assistant_message.tool_calls: tool_results execute_tools(assistant_message.tool_calls) messages.append(tool_results) continue return assistant_message.final_text循环是本地的。智能来自远端模型但控制结构在本地。第六层远端 LLM API远端 LLM API 是无状态的远端模型不记得你的会话。每次 Hermes 调模型时都会把这次调用需要的上下文一股脑发过去system prompt —— 系统提示词conversation history —— 对话历史latest user message —— 最新用户消息tool schemas —— 工具 schematool observations —— 工具观测结果runtime instructions —— 运行时指令所以图上写的是messages/history 重建上下文远端 LLM 看起来好像记得——那是因为 Hermes 把会话状态重新拼好又发了一遍。第七层本地工具工具是暴露给模型的本地能力通过结构化的工具 schema 来描述。例如读文件写文件跑终端命令查记忆搜上下文调 API生成媒体LLM 不直接执行这些工具。它只是发出结构化的工具调用。本地运行时负责验证和执行然后把观测结果塞回消息列表里。LLM 发出工具调用- AIAgent 验证它- 本地运行时执行它- 结果变成观测- 观测送回 LLM完整消息流转端到端的全路径1. **用户发消息。2. 平台适配器收到原始平台载荷。3. 适配器把它标准化成 MessageEvent session_key。4. 事件总线/脚手架发布生命周期事件。5. 适配器/运行时检查该会话是否已在活跃中。6. GatewayRunner 准备会话历史、配置、工具和 agent 对象。7. GatewayRunner 把阻塞的 agent 工作提交到共享 ThreadPoolExecutor。8. 某个工作线程跑 agent.run_conversation()。9. AIAgent 进入 ReAct 循环。10. 远端 LLM 被调用传入消息/历史/工具 schema。11. 如果返回了工具调用本地工具执行观测结果被追加。12. 循环重复直到最终回复或停止条件触发。13. GatewayRunner 持久化并清理运行状态。14. 事件总线/脚手架触发回复和完成的钩子。15. 适配器把最终回复发回给用户。**总结一个简化版的处理流程事件总线 / 脚手架处理生命周期、路由、钩子、副作用、中断GatewayRunner调度工作、拥有共享执行器、追踪活跃 agent、管理缓存ThreadPoolExecutor共享的工作线程池会话临时借用线程session_key会话身份证路由状态、挂起消息、缓存的 agentAIAgent本地 ReAct 控制器有效时按 session_key 缓存远端 LLM无状态 API上下文通过消息/历史重建最后如果说程序员已经是高薪职业那么干AI的程序员就是高薪中的高薪。现在的市场已经用数据给程序员指明了方向学AI大模型就是冲刺高薪的最优解看着身边越来越多的同行转型大模型、拿到高薪offer很多人心里都动了心但真正的难题来了零基础小白不知道从哪入门有基础的程序员找不到系统学习路径实战项目练手无门面试不知道考什么别慌今天就给大家整理了一份【2026年最新版】AI大模型免费学习资源包覆盖从入门到实战、从理论到面试、从基础到进阶的全流程所有资料均已整理归档无冗余、无套路免费分享给每一位想抓住AI风口的程序员和小白扫码免费领取全部内容1、大模型系统化学习路线2、大模型学习书籍文档3、AI大模型最新行业报告4、大模型项目实战配套源码5、大模型大厂面试真题四阶段精细化学习规划附时间节点可直接照做结合上述资源给大家整理了一份可直接落地的四阶段学习规划总时长约2个月小白可循序渐进程序员可根据自身基础调整节奏高效掌握大模型核心能力快速实现从“入门”到“能落地、能面试”的跨越。第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…扫码免费领取全部内容6、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】