Hermes Agent因未过滤工具返回日志导致千万Token消耗

背景

近期，一位开发者在深度使用 Hermes 模型（通过 DeepSeek V4 Flash 接口接入）进行自动化工作流测试时，遭遇了极端的 Token 消耗异常。通常情况下，开发者利用 Hermes 处理日常杂项任务，日均消耗数千万 Token 尚在可接受范围内。然而，在一次仅涉及单一任务——“安装部署一个项目”的操作中，模型陷入了无意义的循环，最终单次部署操作竟消耗了千万级 Token。这一反常现象引发了对 Hermes 在工具调用（Tool Use）及上下文管理策略上的深度质疑。

核心内容

该事件的核心在于 Hermes 模型在处理终端工具调用返回结果时的上下文累积机制存在严重缺陷。

1. 异常现象重现 开发者要求 Hermes 执行项目安装部署。在执行过程中，模型调用了工具（tools）执行命令。由于网络波动导致下载中断，模型尝试重新下载。每一次失败和重试，终端输出的安装日志（stdout/stderr）都被完整保留并追加到对话上下文中。这种“失败-重试-日志累积”的循环重复了两次，导致上下文窗口迅速膨胀，最终消耗了巨额 Token。

2. 根源分析：缺乏有效的内容过滤与去重机制 通过检查原始请求，开发者发现 Hermes 将终端打印的完整日志（包括下载过程、错误信息等）直接作为上下文回传。相比之下，主流 AI 代理（Agent）框架通常会对工具返回内容进行严格的清洗和限制。

3. Hermes 的官方限制及其局限性 Hermes 官方文档中仅定义了以下基础限制，但并未涵盖关键的业务逻辑过滤：

• max_bytes: 50,000 字符。这是终端 stdout/stderr 的总长度上限，通过 head 和 tail 进行截断。
• max_lines: 2,000 行。这是文件读取的分页或截断行数上限。
• max_line_length: 2,000 字符。单行长度上限，超长行会被标记为 [truncated]。

关键缺陷：这些限制仅针对单次返回内容的物理长度，完全没有判断工具调用的次数和重复次数。当模型陷入“安装失败 -> 重新安装”的循环时，每次循环产生的日志都会叠加到上下文中，导致上下文无限膨胀。

4. 与主流竞品的对比 开发者调研了 Claude Code、Codex (GPT) 和 Gemini 等主流模型的处理方式：

• Claude Code & Gemini: 采用流式筛选（Streaming Filtering）和多层级内容过滤机制，能够有效识别并丢弃冗余的终端日志，避免上下文污染。
• Codex (GPT): 据泄露源码分析，其拥有复杂的“八重筛选机制”，对工具返回内容进行深度清洗。
• 结论: 主流 CLI 代理均对 Tool 调用返回进行了大量限制和清洗，而 Hermes 的实现显得过于粗糙，缺乏对重复调用和冗余日志的智能处理能力。

关键要点

• Token 消耗异常根源：Hermes 在处理工具调用时，未对重复执行的命令及其产生的日志进行去重或截断，导致上下文窗口被无效日志填满。
• 官方限制不足：Hermes 仅限制了单次返回的字节数、行数和单行长度，缺乏对“调用次数”和“内容重复性”的逻辑判断。
• 循环累积效应：在网络不稳定或任务失败导致重试时，每次重试的日志都会追加到历史上下文中，形成指数级的 Token 消耗。
• 行业对比劣势：相比 Claude、GPT (Codex) 和 Gemini 采用的流式筛选和多级过滤机制，Hermes 在 Agent 工作流的鲁棒性和成本控制上存在明显短板。
• 实际影响：单次简单的部署任务即可消耗千万级 Token，证明了当前配置下 Hermes 不适合处理需要多次重试或产生大量终端输出的自动化任务。

意义与影响

此事件揭示了当前开源或特定微调模型在构建 AI Agent 工作流时的潜在风险。虽然 Hermes 在指令遵循方面表现优异，但在实际工程落地中，缺乏对工具返回值的智能清洗机制会导致极高的运行成本和不可预测的资源浪费。

对于开发者而言，这意味着在使用 Hermes 等模型构建自动化工作流时，不能仅依赖模型自身的限制设置，可能需要在外层增加中间件或自定义逻辑，对工具返回内容进行二次过滤和去重。这也提醒了模型提供方，在优化 Agent 能力时，除了提升推理准确性，还需同等重视上下文管理的效率和成本控制机制，以缩小与主流商业模型在工程实用性上的差距。