AI 代理跑着跑着就断链Hermes Agent 把工具调用循环做稳的三个关键【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent你丢给代理一句话查天气、订机票、再汇总本周周报。它开始逐个调工具跑到第五步时上下文没了——不记得前面查过什么也不知道你是谁。这是多轮 Agent 最常见的断链。Hermes Agent 是一个遵循 OpenAI 工具规范的 AI 代理框架它干的事很单一让工具调用循环一直转到任务结束。先说它替你挡掉了什么坑在这里模型每次调用都是无状态的。上一轮的工具调用、工具返回的结果你得自己打包塞回消息历史否则下一轮模型就是失忆状态。这个打包看着简单做起来极易翻车tool_call_id没对上、结果挂错轮次服务器直接 400。再说第二个痛点。OpenAI、vLLM、SGLang、OpenRouter各家响应格式都不一样reasoning 字段放哪、工具调用怎么回传每家一套写法。你要是逐服务器写 if-else循环逻辑很快就淹在协议细节里。Hermes Agent 的价值就在这两层把状态回写和接口归一收进框架内部你的业务代码只管模型说了什么、该跑哪个工具。一次请求的幕后旅程 你的 prompt 进来后先被追加进消息历史连同工具定义和参数构建成一个标准请求。因为请求体遵循 OpenAI 工具规范服务器是哪个牌子的都不需要关心。响应回来分两种走法。如果带着tool_calls它先把整条助手消息原样写回历史——注意这一步连模型的 reasoning 字段也一起回写。有些 thinking 模式的服务器要求这个字段原样带回缺了就是 400。然后是工具。每个调用先验证工具名、解析参数再丢进线程池执行工具结果按tool角色消息塞回历史尾部。到这一步循环基于新历史构建下一个请求再转一圈。模型返回不带工具调用的那条消息就是任务完成的信号循环终止。如果撞上最大轮次限制也会停下来返回已有结果。每一轮的错误、轮次、推理内容都有记录不会静默吞掉。三个值得多看一眼的设计取舍 ⚙️线程池而不是异步协程。问题工具调用多是 shell、文件、网络这种长耗时混合负载全写成 async 一套一个阻塞调用就能拖垮整个事件循环。选择工具在线程池里跑并发上限用一个常量兜住实现在 agent/tool_executor.py。收益新工具写成普通函数就能注册不用管异步单个工具卡死也不冻结主循环加超时很方便。AgentResult 打包元数据而不只返回文本。问题跑完一轮你分不清代理是自然完成还是轮次用光错了也不知道错在哪轮。选择AgentResult把对话历史、轮次数、执行状态、每轮推理、工具错误列表一起打包返回。收益调试时直接定位第几轮断的做成本分析时能数清真实消耗了几轮调用。reasoning 字段多格式兼容。问题各家的推理字段名不一样——有的叫reasoning_content有的用reasoning_details还有的塞在model_extra里。处理不好换服务器就 400。选择提取逻辑集中在 agent/chat_completion_helpers.py 一处找到原始字段就原样保留缺失就补一个占位值。收益换推理服务器时不用碰 reasoning 处理多轮对话 Agent 不会卡在协议细节上。接进你的项目先摸这三处 想看循环怎么转的打开 agent/conversation_loop.py。终止条件、最大轮次、上下文压缩策略都在这这是全文最该通读的一个文件。想换服务器去翻agent/transports/目录每家服务器对应一个文件。在这里新增或修改传输层工具调用循环本身一行不用动。加工具则回到agent/tool_executor.py验证工具名、解析参数、决定串行还是并发都是从这里进线程池的。新工具挂上去走的就是同一套派发流程。四句话收个尾Hermes Agent 的思路是把状态回写、接口归一、执行隔离这三件脏活藏进框架里。你看到的只是prompt 进结果出循环不断。线程池和元数据打包这两个取舍直接决定了多轮对话 Agent 在生产里稳不稳。你现在用的那个代理循环卡在状态丢失还是卡在服务器协议【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考