Hermes Agent Loop：从9200行代码中读懂Agent心脏

Python编程杰哥

479人浏览 · 2026-04-22 21:23:19

Python编程杰哥 · 2026-04-22 21:23:19 发布

翻开 Hermes Agent 的源码，run_agent.py。

9200 行。

看完之后，我意识到一件事。

Agent 的心脏，不是模型。

不是工具。

是 Agent Loop。

模型调用 → 工具执行 → 循环 → 直到完成。

这个循环，决定了 Agent 能做什么，不能做什么。

这不是一个简单的循环。

是一个精密系统：

一、Turn Lifecycle：一次迭代的完整旅程

看 Hermes 的 run_conversation()，我发现一件事。

每次 iteration，不是简单调用 API。

是 9 个步骤：

三个步骤值得细说。

Step 3 - 系统提示缓存

首次构建，后续复用。

只有压缩事件触发时才重建。

为什么？Anthropic prefix cache 需要稳定的前缀。

Step 4 - 预压缩检查(Preflight Compression)

50% context window，主动压缩。

用户切换到更小 context 的模型时触发。

预防性压缩，不等 API 报错。

Step 8 - 可中断 API 调用(Interruptible API Call)

这一步让我印象深刻。

后台线程 HTTP POST，Main thread 监控中断事件。

用户可以随时打断，无 partial response 注入 history。

二、三种 API Modes：为什么需要三种？

看到三种 API mode 时，我有点困惑。

OpenAI-spec 不是标准吗？

Mode	使用场景	Client
chat_completions	OpenAI 兼容端点	openai.OpenAI
codex_responses	Codex API	Responses format
anthropic_messages	Anthropic 原生	Anthropic adapter

看起来复杂？

内部统一。

三种 mode 都收敛到 OpenAI format：

{"role": "system", "content": "..."}{"role": "user", "content": "..."}{"role": "assistant", "content": "...", "tool_calls": [...]}{"role": "tool", "tool_call_id": "...", "content": "..."}

Provider 可以不同。

内部格式必须统一。

这是架构设计的克制：

多样性收敛到标准。

三、Tool Execution：并发128 workers的秘密

并发还是顺序？

Hermes 选了并发。

128 workers。

单工具调用 → 主线程直接执行多工具调用 → ThreadPoolExecutor 并发例外：interactive tools（clarify）强制顺序

线程池大小：128 workers。

为什么 128？

RL environments 可能 89 个任务同时运行。

太小 → 线程池饥饿，任务排队几分钟。

太大 → 资源浪费。

动态调整：

def resize_tool_pool(max_workers: int):    """根据 config.tool_pool_size 动态调整"""

Agent-Level Tools 拦截

有些工具不经过 registry。

直接修改 agent state。

Tool	Why intercepted
`todo`	agent-local task state
`memory`	persistent memory files
`session_search`	session history
`delegate_task`	spawns subagent

这些工具返回 synthetic tool results。

不经过 handle_function_call()。

四、Budget System：如何防止无限循环？

读到 IterationBudget 时，我理解了 Hermes 的克制。

Agent 可以无限循环。

工具调用可以触发更多工具调用。

没有约束，Agent 可能永远不结束。

IterationBudget 设计

默认：90 iterations。

两级压力警告：

70%+ (caution tier):"[BUDGET: Iteration X/Y. N left. Start consolidating your work.]"90%+ (warning tier):"[BUDGET WARNING: Iteration X/Y. Only N left. Final response NOW.]"100%:stop, return summary of work done

压力注入在哪里？

Tool result。

Model 会收到信号。

知道需要结束了。

Subagent 共享预算

子 agent 消耗父 agent 的 budget。

防止递归调用无限消耗。

一个任务的总预算，是固定的。

五、Fallback Chain：故障自动切换

Provider 会失败。

我用 OpenRouter 时，遇到过 429 rate limit。

深夜调用 Anthropic，遇到过 5xx server error。

换 API key 时，遇到过 401/403 auth error。

用户应该因为一个 provider 失败而放弃？不应该。

Fallback 流程

不是全局 fallback。

是分层 fallback。

Auxiliary Tasks 独立 chain：

vision / compression / web extraction / session search
每个任务有自己的 fallback chain

Primary 和 Auxiliary 各自独立。

这提高了系统的鲁棒性。

六、Compression Thresholds：为什么两级？

两级阈值，Preflight 50%，Gateway 85%。

为什么是这两个数字？

Threshold	Trigger	Purpose
50%	Preflight	主动预防，切换模型时
85%	Gateway	激进压缩，会话过长时

不同场景，不同策略。

Preflight：用户主动切换模型 → 预防性处理。

Gateway：会话自然增长 → 激进压缩。

Compression 流程

关键：Memory 先 flush。

防止压缩过程中丢失数据。

七、统一 Message Format：为什么坚持 OpenAI-spec？

Message Alternation Rules，我之前不知道。

Provider 会验证 message sequence。

Malformed history 会被拒绝。

Message Alternation Rules

System 之后：User → Assistant → User → Assistant → ...Tool calling：Assistant (with tool_calls) → Tool → Tool → ... → Assistant规则：- 绝不两个 assistant 连续- 绝不两个 user 连续- 只有 tool 可以连续（并行 tool results）

为什么重要？

OpenAI、Anthropic、其他 providers 都验证
违反规则 → API error
统一格式降低 provider 兼容成本

八、与 OpenClaw 的对比

看完 Hermes 的设计，我开始思考 OpenClaw。

哪些可以借鉴？

维度	Hermes	OpenClaw
Interruptible API	✅ 后台线程+中断	❌ 未实现
IterationBudget	✅ 90 iterations + 两级警告	❌ 未实现
Fallback Chain	✅ Provider + Auxiliary 分层	❌ 未实现
Compression	✅ 50% / 85% 两级	✅ contextPruning
Reasoning Extraction	✅ 多 provider 格式	⚠️ 部分支持
ThreadPoolExecutor	✅ 128 workers	❌ exec tool

OpenClaw 可借鉴优先级：

Interruptible API Call

（用户体验）
IterationBudget

（防止无限循环）
Fallback Chain

（系统鲁棒性）
Compression Thresholds

（上下文管理）

九、结语

研究完这 9200 行，我的结论是：

Hermes 不是写了一个循环。

是设计了一个精密系统。

可中断、有预算、能故障切换。

六条设计哲学：

可中断

：用户不应该等待一个无法停止的请求
有预算

：Agent 不应该无限循环消耗资源
能切换

：一个 provider 失败不应该放弃整个任务
统一格式

：多样性收敛到标准，降低兼容成本
分级压缩

：不同场景不同策略
智能调度

：并发执行，但 interactive tools 强制顺序

这六条，值得每一个 Agent 设计者学习。

关键数据：

数据	值
Stars	74,192 ⭐
增长	+67%（3天）
AIAgent 行数	~9,200
ThreadPoolExecutor	128 workers
IterationBudget	90 iterations
Compression Thresholds	50% / 85%

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

在这里插入图片描述

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～