5 分钟跑通 Hermes Agent 的工具调用循环：从一条消息到最终回复

让 Agent 把构建跑一遍、再把所有报错修掉——普通聊天机器人只会建议你"可以试试构建命令"，Hermes Agent 会自己执行命令、定位报错、逐个改文件，而且每一步的输出都读回去喂给模型。你自己实现这个"想一步、调一个工具、读回结果"的工具调用循环，要手写 while 循环、拼消息、解析 tool_calls，相当烦；这个项目把整条循环封装成了一次对话，你发一条消息，回来时任务已经做完了。

快递分拣中心：消息怎么从输入走到回复

你可以理解为包裹在快递分拣中心走的路线。你的消息是刚入件的包裹，先上分拣线——conversation_loop.py 里的run_conversation函数就是传送带的驱动，它把消息历史、系统提示、工具定义打包成一次模型请求；模型说"还要调工具"，包裹就重新上线，不说就走向发货。传送带中段是工具操作台，tool_executor.py：它接住模型响应里的工具调用，给每个工具分一个独立工人线程去执行，操作台再忙也不让传送带停摆。最后一站是发货窗口 turn_finalizer.py，它负责打包结果：最终回复、完整对话历史、API 调用次数、是否被中断，统统装进这个结果容器，再交到你手里。

一条消息怎么走完循环

以"检查项目有没有编译错误"这条指令为例，按时间顺序走一遍。第一轮，循环组装请求：系统提示、历史、工具定义打包发出。模型回来说"要调 terminal 工具跑构建"——循环先把这条 assistant 消息记进历史，数据状态从"等模型"变成"等工具"。接着是校验与执行：工具名对照当前启用列表验证、参数解析，然后丢进线程池；模型一次响应可能带多个工具调用，池子大小按批次适配，每个工具各占一个线程，单个慢工具拖不垮同批其他工具。构建输出被包成一条 tool 结果消息回填历史——模型正是靠它"看见"上一步干了什么，下一次请求照样带着完整历史发出。第二轮，模型可能说"再读一下报错文件"，同样的校验、执行、回填再来一遍；也可能直接给出总结。终止条件只有两种：响应里不再带工具调用，循环正常退出；或者撞上max_iterations上限，循环停在这里并明确告知你预算用完了，而不是静默截断。最后finalize_turn把回复、历史、调用次数装进结果字典，和你的消息一起落库。

比手写 while 循环多做了什么

说白了，裸while tool_calls:也能转起来，但它离能用还差四件事。工具并发：线程池按批次定大小、每工具独立线程，一个慢的全量构建不会卡死同批的其他工具。上下文压缩：每轮都会检查历史是否逼近上下文窗口的压缩阈值，到线就先压缩再发请求，否则长任务撑爆上下文，API 直接报错。轮数熔断：max_iterations加上迭代预算双保险，防止模型陷入"调工具、读结果、再调工具"的死循环烧 token。结果元信息落库：API 调用次数、token 用量、是否中断都装进结果容器写进数据库——这就是你事后排查"它为什么多跑了几轮"、导出轨迹复盘的依据。

4 条命令跑起来，以及它适合什么任务

git clone https://gitcode.com/GitHub_Trending/he/hermes-agent cd hermes-agent hermes setup hermes

hermes setup走完配置向导，hermes进入终端界面，丢一个"列出当前目录结构"的任务，输出里能看到工具被逐个调用的实时过程。适合交给它的是长任务自动化（定时日报、夜间跑构建修错）和本地开发代理（读写文件、跑命令，配合容器后端隔离风险）；纯单轮问答、写段文案之类的活别用它，一次普通对话就够，轮不到循环出场。

分拣中心的三站

传送带、操作台、发货窗口——记住这三站，其余模块都是挂在主线上的插件。