十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Hermes 长会话又满上下文?TaoToken 这样改 config.yaml 的 auxiliary.compression

Hermes 长会话又满上下文?TaoToken 这样改 config.yaml 的 auxiliary.compression Hermes 长会话又满上下文TaoToken 这样改 config.yaml 的 auxiliary.compressionHermes Agent 的长会话治理真正容易被忽略的成本黑洞不在主模型而在 auxiliary.compression 指向的辅助摘要请求。把这段请求切到 TaoToken官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contenthermes-aux-compression的兼容通道config.yaml 只动 provider 与 model其余四层防线参数保持原样就能让 /usage 里的 Context 与 Compressions 变得可解释。本文按 Agent / Harness 视角围绕长会话、多工具、任务编排把 auxiliary.compression 的接入、验证与排障讲清楚。Hermes 的 context_compressor.py 不是孤立模块它前面还有三层防线工具内截断、maybe_persist_tool_result 对超 100K 字符结果落盘、enforce_turn_budget 在单轮 200K 字符时从最大结果开始溢出。前三层控制进入上下文的数据体积第四层才是在 prompt_tokens 超过上下文 50% 时做有损压缩。问题在于第四层本身要调 LLM这段辅助摘要请求同样消耗 Token而 /usage 只给出总量很难直接看出压缩这一路占了多少。把 auxiliary.compression 单独指向 TaoToken 的兼容通道不是为了替代 Hermes 的压缩编排而是让辅助摘要请求走一条成本可观察、Key 可管理的路径。一、原问题与场景长会话满上下文时auxiliary.compression 在悄悄烧 Token一次典型的重构会话很容易跑到 40 次以上工具调用search_files 反复搜索符号read_file 读取多个模块terminal 跑测试和构建write_file 写入修改。前三层防线会先把大结果压下去。search_files 和 terminal 在工具内部就有输出上限单个工具结果超过 100K 字符时maybe_persist_tool_result 会把完整内容写入沙箱临时目录只在上文里保留 1,500 字符预览和文件路径如果某个 assistant turn 并行调用多个工具总字符数超过 200Kenforce_turn_budget 会从最大的结果开始落盘直到总量回到预算内。这些机制能显著降低上下文增速但对话还在继续token 总数仍在上涨。当 prompt_tokens 达到上下文窗口的 50%ContextCompressor 触发。它先做 Phase 1 工具结果预修剪再做 head / middle / tail 三段切分然后调 auxiliary.compression 指向的辅助模型把 middle 段总结成结构化摘要最后组装消息并清理孤立的 tool_call / tool_result 对。这里的辅助模型可能是 gpt-4.1-mini 这类便宜模型也可能因为 404、503 自动回退到主模型。一旦回退压缩这一路的成本就会混进主模型账单而 /usage 的 Context 行只告诉你当前窗口用了多少 tokenCompressions 只告诉你压缩了几次不会拆出辅助摘要请求的占比。所以痛点不是“Hermes 不会压缩”而是“压缩本身也要花钱但你看不清它花了多少”。这就是把 auxiliary.compression 单独接入 TaoToken 的原因Hermes 继续负责截断、持久化、预算编排和摘要模板TaoToken 只承载辅助摘要请求让 Key、Base URL 和消耗路径都变得明确。二、TaoToken 前置Key、Base URL 与 config.yaml 的改动边界先在 TaoToken 控制台创建一把 Key。打开 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 登录后新建 API Key复制出来后面配置里用 YOUR_API_KEY 占位。如果你还没有账号从官网入口 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contenthermes-aux-compression 注册即可。Base URL 固定填 https://taotoken.net/api 不要加 /v1不要加 UTM 参数。API 地址与官网地址是分开的官网链接带 utm_source、utm_medium、utm_campaign、utm_content方便统计来源API 调用地址只写 https://taotoken.net/api 保持干净避免客户端把多余 query 带进请求。Key 用 YOUR_API_KEY实际粘贴时换成你刚创建的那把。config.yaml 的改动边界要守住compression 下的 enabled、threshold、target_ratio、protect_last_n 全部保留原文默认值也就是 enabled: true、threshold: 0.50、target_ratio: 0.20、protect_last_n: 20。credential_pool_strategies 也照原文保留比如 anthropic: round_robin、openai: least_used。只把 auxiliary.compression 的 provider 与 model 指向 TaoToken 的兼容通道。这样 Hermes 的四层治理逻辑不变只是辅助摘要请求换了一条出口。如果你需要确认 TaoToken 的接入格式可以先看接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。文档里有 OpenAI 兼容接口的 Base URL 和鉴权方式和 Hermes 的 auxiliary.compression 配置可以对应上。不要在这步改 threshold 或 target_ratio否则你后面看到的 /usage 变化无法归因。三、可复制配置config.yaml 里只动 auxiliary.compression下面这段配置可以直接复制到你的 config.yaml。注意compression 四个参数保持默认credential_pool_strategies 保持原文策略只改 auxiliary.compression 的 provider、model、base_url、api_key。model 填你在 TaoToken 里要用的模型 ID比如 gpt-4.1-mini 或你实际可用的便宜模型provider 填 openai 或你 config.yaml 里已有的兼容 provider 名称关键是 base_url 指向 TaoToken。compression: enabled: true threshold: 0.50 target_ratio: 0.20 protect_last_n: 20 auxiliary: compression: provider: openai model: gpt-4.1-mini base_url: https://taotoken.net/api api_key: YOUR_API_KEY credential_pool_strategies: anthropic: round_robin openai: least_used如果你习惯用环境变量也可以让 auxiliary.compression 读取环境变量避免把 Key 写进文件export OPENAI_API_KEYYOUR_API_KEY export OPENAI_BASE_URLhttps://taotoken.net/api对应 config.yaml 里 api_key 可以留空或写 ${OPENAI_API_KEY}base_url 写 ${OPENAI_BASE_URL}。但要注意不同 Hermes 版本对变量插值的支持不一样如果启动时报 Key 为空就回到显式写法。无论哪种方式Base URL 都必须是 https://taotoken.net/api 不要写成 https://taotoken.net/api/v1 。多一个 /v1 在某些兼容层会变成 /v1/v1直接 404。配置改完后不要急着跑长会话先用一次短对话确认 auxiliary.compression 能正常返回。你可以从模型对话入口手动发一条请求验证 Key 和模型 ID 是否可用https://taotoken.net/console/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 。如果模型对话能正常返回再回到 Hermes 跑压缩链路。四、验证请求与成功结果用 /usage 对照 Context 与 Compressions验证要按原文流程跑一轮 40 次以上工具调用的重构会话。不要只跑三五轮因为 threshold 是 0.50上下文窗口较大的模型需要积累足够 token 才会触发压缩。你可以选一个真实的小重构任务搜索多个文件、读取模块、修改代码、跑测试、再读测试输出。目标不是让 Hermes 写代码而是让工具调用次数和结果体积达到压缩条件。会话进行中随时输入 /usage。你会看到类似下面的输出结构Model: claude-sonnet-4-20250514 Input tokens: 45,230 Cache read tokens: 128,400 Output tokens: 12,890 Total: 186,520 API calls: 23 Cost: ~$0.2847 Context: 52,400 / 200,000 (26%) Compressions: 1重点看两行Context 行告诉你当前上下文窗口用了多少Compressions 行告诉你压缩触发了几次。接入 TaoToken 后辅助摘要请求从 TaoToken 走主模型的 usage 和辅助模型的 usage 在总成本里分开体现即使 /usage 不直接拆分压缩占比你也可以通过 TaoToken 控制台或 Key 维度观察辅助摘要请求的量。如果 Context 行在触发阈值后明显回落Compressions 从 0 变成 1说明第四层已经工作。继续跑到第二次压缩触发。此时要确认摘要仍然是 12 节结构化模板常见节包括 Active Task、Goal、Constraints Preferences、Completed Actions、Active State、In Progress、Blocked、Key Decisions、Resolved Questions、Pending User Asks、Relevant Files、Remaining Work。摘要是迭代更新的第一次压缩生成摘要后第二次不会从零重写而是把上一次摘要和新增加的对话一起交给辅助模型要求它做增量更新。这样多次压缩后Active Task 和 Pending User Asks 不会丢Blocked 里的错误信息也能保留。成功结果可以这样判断40 次以上工具调用后Context 没有顶到模型上限Compressions 计数至少为 1最好能看到 2摘要仍按 0.20 的摘要预算生成没有因为辅助模型切换而变成自由发挥辅助摘要请求在 TaoToken 侧有记录Key 用量可查。如果这些都对上了说明截断、持久化、压缩编排仍由 Hermes 负责消耗 Token 的辅助摘要请求已经统一从 TaoToken 走。五、本篇常见错排查404/503、Base URL、context_compressor.py 与 usage_pricing.py 的读数第一个常见错是 404 或 503。auxiliary.compression 指向的辅助模型不可用时Hermes 会回退到主模型压缩继续做但成本混进主模型。你会在日志里看到辅助模型请求失败然后主模型接管。排查顺序确认 Base URL 是 https://taotoken.net/api 没有 /v1确认 model 是 TaoToken 侧可用的模型 ID确认 api_key 是 YOUR_API_KEY 替换后的真实值确认 provider 名称与 Hermes 兼容层匹配。如果 provider 写错请求可能根本没发到 TaoToken而是被本地或其他后端接走。第二个常见错是 Base URL 带了 UTM 或 /v1。API 地址不要加 UTMhttps://taotoken.net/api 就是完整 Base URL。带 /v1 会导致路径重复带 UTM 会让某些客户端把 query 拼进请求路径轻则 404重则鉴权失败。官网链接和 API 链接要分开用官网可以带 utm_sourcetaotoken_aicg_blog_end、utm_campaignrewrite、utm_contentAPI 只写 https://taotoken.net/api 。第三个常见错是改了 compression 默认值。有人为了更快看到压缩把 threshold 从 0.50 调到 0.10结果每几轮就压缩一次tail 保护区还没稳定就又被切摘要质量下降Compressions 暴涨。本文的边界是enabled、threshold、target_ratio、protect_last_n 全部保留原文默认值。target_ratio 保持 0.20tail 预算才稳定protect_last_n 保持 20Phase 1 预修剪才不会动到近期消息。第四个常见错是 credential_pool_strategies 被覆盖。原文策略比如 anthropic: round_robin、openai: least_used 是有意设计的用于多 Key 轮换和额度均衡。如果你在接入 TaoToken 时把这段删了429 或 402 出现后可能不会自动轮转长会话中途卡住。保留原策略把 TaoToken 的 Key 放进对应 provider 的凭证池即可。第五个常见错是只看总 token不看 context_compressor.py 和 usage_pricing.py 的读数。context_compressor.py 决定何时触发、如何切分、摘要预算多少usage_pricing.py 负责把不同 API 的 usage 归一化区分输入、输出、缓存读取、缓存写入和请求次数。/usage 的 Context 行来自压缩器Compressions 计数来自压缩次数Cost 行来自计价模块。如果你发现 Compressions 一直为 0先检查 Context 是否达到 threshold_tokens如果你发现成本估算异常检查 auxiliary.compression 是否回退到了主模型。排查时不要只盯着主模型账单辅助摘要请求也是真实消耗。第六个常见错是摘要丢信息。如果压缩后模型反复问已经回答过的问题或者重复执行已完成的步骤通常是摘要模板没覆盖 Active Task、Resolved Questions、Pending User Asks 这几节或者迭代更新没生效。确认 auxiliary.compression 返回的是结构化摘要而不是普通对话回复确认 _previous_summary 不为空时走的是增量更新路径确认 tail 保护区和最新用户消息没有被切进 middle。必要时把 protect_last_n 保持默认不要为了省 token 把它调得太小。六、语义一致 CTAHermes 负责编排TaoToken 承载辅助摘要这套改法的核心不是让 TaoToken 替代 Hermes而是把 auxiliary.compression 这一路辅助摘要请求单独接出来。Hermes 仍然负责四层防线工具内截断、maybe_persist_tool_result 落盘、enforce_turn_budget 单轮预算、context_compressor.py 的有损压缩与 12 节结构化摘要。TaoToken 只提供兼容通道让 provider、model、Base URL、Key 和用量都变得可管理。Base URL 记住是 https://taotoken.net/api 不要加 /v1不要加 UTM。如果你在接入或排障过程中遇到 404、503、429或者不确定 provider 与 model 怎么填优先看 API Keys 和接入文档https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 与 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。如果你要长期跑 Agent 长会话、多工具任务编排希望辅助摘要请求和主模型请求都有稳定的额度与成本观察可以了解 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。验证模型是否可用则从模型对话入口先发一条短请求https://taotoken.net/console/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 。把辅助摘要请求从 TaoToken 走长会话的截断、持久化、压缩编排仍由 Hermes 负责成本看得见。
返回列表