Hermes Agent 完整拆解:AI 代理的工具调用循环如何运转 Hermes Agent 完整拆解AI 代理的工具调用循环如何运转把任务丢给聊天机器人它往往回一段建议你试试 grep就结束对话Hermes Agent 是一个自我改进的 AI 代理它会自己反复想一步、调一个工具、读回结果直到任务做完才停手。它到底是什么一句话定位一个把多轮工具调用自动化掉的对话引擎。普通工具的交互模式是你说一步、它做一步Hermes Agent 替你跑完整个决策-执行回路——模型只负责决定下一步调哪个工具循环负责真正执行、把结果喂回模型、判断要不要再来一轮。你只需要描述目标过程不用盯着。分层拆解架构核心逻辑集中在agent/目录按数据流方向可以拆成三层循环引擎层决定何时再问一次模型agent/conversation_loop.py 中的run_conversation是整条流水线的主体。它把消息历史、系统提示、工具定义打包成一次模型请求收到响应后做一个二选一判断带工具调用就交给执行层纯文本就退出循环。它不关心工具内部怎么跑只管轮次推进轮数由max_iterations与迭代预算双重封顶防止失控空转。工具执行层把一批调用并行跑完agent/tool_executor.py 接收模型一次响应里的工具调用批次按批次数量临时创建线程池每个工具独立线程执行——慢工具不拖累同批其他工具单工具抛错只把错误文本写回该调用的结果位循环本身不崩。执行前会先把本轮记录落库到会话数据库持久化先于副作用中断后也能从断点恢复。结果收尾层打包这一轮换回了什么agent/turn_finalizer.py 的finalize_turn在循环结束后接管收尾最终回复、完整对话历史、API 调用次数、是否被中断全部装进一个结果字典。用量统计、轨迹导出等下游能力都从这个字典取数。跟一次数据流任务如何跑完以跑一遍测试并汇报失败原因为例跟一次完整数据流开场准备。输入你的任务消息。处理刷新凭证、重建系统提示、检查上下文是否逼近压缩阈值发出第一次模型请求。输出携带完整历史的 API 请求。第一轮工具调用。输入模型返回调用 terminal 工具执行 pytest。处理先把该 assistant 消息记入历史校验工具名在启用列表内并解析参数丢进线程池执行。输出stdout 被包成一条 tool 消息回填历史。第二轮跟进。输入带上测试输出的历史。处理模型看到失败用例决定读一下报错的测试文件同样的校验-执行-回填再走一遍。输出新的工具结果进入历史。收敛落库。输入模型给出纯文本总结不再带工具调用。处理循环退出finalize_turn收尾并持久化。输出最终回复与用量统计。若轮数撞上max_iterations它会在此明确告知预算用尽而非静默截断。3 个常见误解及坑模型本身不干活。模型只输出调哪个工具参数真正读写文件、跑命令的是本地工具层——把它当成更聪明的 GPT就无法理解它为什么在 $5 的 VPS 上也能干活。多轮不免费预算有硬顶。每次请求都携带完整历史token 成本随轮次乘积式增长撞上限会停下并告知预算用尽调优时优先看这一层。工具报错 ≠ 程序崩溃。单个工具异常只会把错误文本写回结果位由模型在下一轮自行处理失败但注意历史记录必须先落库成功才会执行工具本地调试时若会话库不可写该轮会直接终止为失败。适用场景与上手路径三类典型场景① 长任务自动化定时日报、夜间备份内置 cron 调度器跑完后把结果投递到 Telegram/Slack② 本地开发代理在你机器上读写文件、跑命令可配容器等后端隔离风险③ 研究 Agent 循环写法的开发者每一轮都能打断点没有黑盒。最小上手序列先执行 git clone https://gitcode.com/GitHub_Trending/he/hermes-agent 获取源码并安装再运行hermes setup走完向导并选择模型后端然后执行hermes进入终端界面丢一个列出当前目录结构的小任务就能看到工具被逐个调用的实时过程。循环、线程池、结果容器三者构成 Hermes Agent 的全部核心其余记忆、技能、调度模块都是挂在这条主线上的插件。下一步可以直接给run_conversation打个断点单步走一轮你对 AI 代理的理解会完全不同。创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考