Hi, 我是洪致知,一名软件工程师,坚定不移热爱技术,平时喜欢捣鼓一些小创意,有很多理想,也有点理想主义。
CSDN: 我要去腾讯

要读懂 Agent 源码,最有效的方法不是先看模块图,而是跟一条消息从输入到输出完整走一遍。
示例任务:
帮我搜集今天的热点新闻,每条新闻要分类并附简要分析。
这类请求会触发检索、抽取、归类、摘要、结构化输出,天然会覆盖工具调用、并行执行、上下文更新、错误恢复等关键路径。
Hermes 的整体结构可抽象为五层:
消息主链路:
终端输入 -> 解析与路由 -> 会话加载 -> 上下文组装 -> 模型推理 -> 工具执行 -> 流式返回 -> 状态落盘

Hermes 支持多平台,不同平台消息格式和传输机制差异很大。其策略是:
MessageEvent)这是典型适配器模式:入口收敛格式,出口再按平台反向展开。

Gateway 启动会完成证书探测、环境变量加载、配置桥接、适配器启动等步骤。
真正有工程价值的是 Profile 隔离:
删除 Profile 时,会连带清理进程与相关注册,保证状态闭环。

主循环本质上是“推理 -> 判定是否调工具 -> 执行 -> 再推理”的迭代:
tool_calls:执行工具并继续循环tool_calls:返回最终文本execute_code)时可触发 refund 机制这个设计在“脚本密集任务”中能显著减少预算浪费,把预算留给真正推理轮次。

Hermes 按工具风险分组:
这样能在保证一致性的前提下压缩总耗时。
delegate_task)子 Agent 拥有独立上下文与预算,但受严格边界限制(工具白名单、深度限制、并发上限、级联中断),目的是“并行扩展能力”而非“无限递归”。

系统提示词通常按以下顺序拼装:
身份 -> 工具行为引导 -> 外部指令 -> 记忆 -> 技能索引 -> 项目上下文 -> 运行时元数据
关键点:

Hermes 采用“文件持久化 + 冻结快照 + 外部 Provider”的组合方案:
MEMORY.md:Agent 长期工作事实USER.md:用户偏好与习惯这样做的代价是“会话内记忆不是强实时”,收益是“缓存命中稳定、响应成本可控”。
同时,记忆写入也有安全扫描,避免把恶意指令固化成长期后门。

Hermes 不靠单一大异常处理,而是将错误先分类,再映射到动作标记:
压缩流程通常包括:
压缩不是覆盖原会话,而是:
parent_session_id 形成可追溯链这样模型层可控,数据层不丢历史。

生成结果通过流式机制回传,网关层做节流与平台格式适配。
附件走统一指令格式,在出口侧转为各平台附件 API。

Hermes 将技能增长拆成两路信号:
而且复盘在用户响应完成后异步执行,避免与主任务争抢延迟预算。

本质上,两者都在回答同一问题:如何让 Agent 在长周期、多工具、跨平台条件下持续稳定工作。
Hermes 的可取之处不只在“功能多”,而在其工程化取舍:
如果你正在做生产级 Agent,最值得借鉴的不是某个单点技巧,而是这种“稳定性优先”的运行时思维。