Hermes Agent 的 nudge、后台 review 和轨迹数据本质上是同一条 Agent 循环上的三件事也都吃模型调用。要把这条链路换到统一通道先在 TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建一把 Key再把模型配置里的 Base URL 填成 https://taotoken.net/api。真正让人犹豫的是换完之后_spawn_background_review()fork 出来的静默 Agent 会不会漏走新通道主循环里的两个 nudge 计数器还算得准吗save_trajectories导出的 ShareGPT 轨迹里think归一化和tool_stats还完不完整这些疑问很实在。长会话跑起来之后Token 消耗并不只发生在你看到的那几轮对话里用户消息触发记忆 nudge、主循环迭代触发技能 nudge、后台 review 再 fork 一个最多 8 轮的静默 Agent 去写MEMORY.md和SKILL.mdbatch_runner 跑批时又是几十条并发。主 Agent 一把 Key、review Agent 一把 Key、跑批再一把 Key切模型时三处都要改这才是让人卡住的地方。下面按run_agent.py的真实执行顺序拆。1. run_agent.py 里两个 nudge 计数器决定了后台 review 什么时候花钱1.1 记忆 nudge 按用户轮次技能 nudge 按主循环迭代这两个计数器看起来像一回事实际上量的是两种东西。self._turns_since_memory在用户消息进入时递增判断阈值发生在主循环之前self._iters_since_skill在主循环内部递增等final_response产出之后再统一判定。默认值都指向 10配置项分别是memory.nudge_interval和skills.creation_nudge_interval。为什么拆成两套维度因为信息密度的来源不同。记忆的原材料是用户说了什么用户连续聊十轮可能每轮都带出新偏好但如果这十轮全是纯文字问答、Agent 一次工具都没调就没有任何执行经验值得沉淀成技能。反过来用户只说一句帮我把这个目录的 print() 换成 logging.info()Agent 可能跑十几轮读文件 → patch → 验证 → 再调整技能 nudge 会命中而记忆 nudge 可能连一次都没动。还有一个容易被误读的点技能 nudge 统计的是主循环 / LLM 迭代数不是原子工具调用数。一次 assistant 响应里并发发出三个文件读取_iters_since_skill通常也只加 1。所以排查为什么技能没触发时别去数工具调用次数。1.2 计数器跨 session 持久凭证却不一定跟着走_turns_since_memory和_iters_since_skill会跨run_conversation()调用持久化CLI 多轮交互里不会重置这是为了累积正确。但模型凭证是另一套东西它读的是配置文件或环境变量跟计数器生命周期完全不同。这就带来一个很常见的错配——你把配置改了计数器还带着上一次会话的进度下一次 nudge 可能在第一轮用户消息之后就命中后台 review 立刻跑起来。如果这时 Key 还没配好你看到的就不是摘要行而是一串鉴权失败。所以换通道的顺序应该是先把 Key 和 Base URL 落定再启动 CLI 长会话别一边跑迁移任务一边改配置。另外两个计数器会被主动调用重置Agent 自己调了memory工具_turns_since_memory归零调了skill_manage_iters_since_skill归零。这个设计是为了避免Agent 已经在管记忆了nudge 还在旁边催。1.3 主循环和 review Agent 得用同一套凭证一轮完整闭环里模型调用至少出现在三处主循环里的推理与工具决策、后台 review Agent 的提示词与工具调用、如果开了 batch_runner 还包括批量任务的每一轮。这三处的模型配置如果来自不同来源写出来的MEMORY.md和SKILL.md风格会漂——同一份文件今天像是这个模型写的、明天像是另一个模型写的后续读它的 Agent 会困惑。把三者的 Base URL 统一填https://taotoken.net/api模型 ID 从官网模型广场现挑现用是最省事的一种收口方式。注意这里说的是填进工具的地址末尾不要带/v1也不要往上面拼任何查询参数。2. 把 Hermes 的模型配置指到 TaoTokenconfig.yaml 与环境变量两种改法2.1 config.yaml 里的 model 段与 nudge 段放一起下面这份结构对齐仓库里的配置示例字段名以你本地版本为准含义是通用的base_url决定请求发到哪model决定路由到哪个模型nudge 那两行决定后台 review 什么时候被唤醒。model: provider: openai base_url: https://taotoken.net/api api_key: YOUR_API_KEY model: YOUR_MODEL_ID memory: nudge_interval: 10 skills: creation_nudge_interval: 10 trajectory: save_trajectories: true output_dir: ./trajectoriesYOUR_MODEL_ID不要凭记忆写去模型广场看当时的列表再填。后台 review 那个静默 Agent 满打满算只有 8 轮预算工具调用还特别密集挑一个工具调用稳的模型比挑一个话多的模型重要得多。2.2 环境变量两种协议别混着填如果你的版本优先读环境变量注意 OpenAI 兼容协议和 Anthropic 协议用的变量名不是一套。走 OpenAI 兼容时export OPENAI_BASE_URLhttps://taotoken.net/api export OPENAI_API_KEYYOUR_API_KEY走 Anthropic 协议通道时export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKENYOUR_API_KEY两套变量同时export是新手最容易犯的错工具先读到哪一套不确定表现就是有时候能跑、有时候 401。选一套把另一套清掉。还有一点CLI 里export过的变量不一定被子进程继承后台 review 是 fork 出来的它读的可能就是配置文件——所以最稳的做法还是把base_url和api_key写进config.yaml环境变量只当补充。2.3 创建 Key 的那一步以及别把它写进仓库打开 TaoToken注册后在控制台创建 API Key复制出来的那串就是上面配置里的YOUR_API_KEY。主 Agent、后台 review Agent、batch_runner 可以用同一把管理成本最低如果团队里多人共用一台跑批机器再考虑按用途拆开。config.yaml如果要提交进仓库把 Key 部分留成占位符或者改用环境变量注入别把真 Key 推到远端。轨迹目录./trajectories里往往包含真实任务内容同样建议加进.gitignore。3. _spawn_background_review() fork 的静默 Agent会不会漏走通道3.1 它和主 Agent 是同一个类配置继承链是通的_spawn_background_review()做的事可以概括成判断_should_review_memory或_should_review_skills是否成立然后 fork 一个静默 AIAgentmax_iterations8把_MEMORY_REVIEW_PROMPT、_SKILL_REVIEW_PROMPT或_COMBINED_REVIEW_PROMPT之一传进去让它自己去调memory/skill_manage写文件。关键在同一个类这四个字。它读模型配置的代码路径和主 Agent 一样除非你在 fork 时显式覆盖某个字段否则 Base URL、Key、模型 ID 全都跟着走。所以把config.yaml里的base_url指向https://taotoken.net/apireview 请求自然也在同一条通道上不会出现主循环走一个地址、后台走另一个地址的分裂。3.2 这 8 轮预算到底花在哪review Agent 的 8 轮不是摆设。第一轮要消化 review prompt 和当前会话的上下文摘要中间几轮调工具写文件最后一轮收口。每一轮都是一次完整的模型调用长会话里这部分消耗不可忽视——你在前端只看到一行摘要后面可能是七八次 API 请求。这也是为什么模型选择要谨慎一个工具调用不稳定的模型可能在第 3 轮返回了无法解析的参数结构review Agent 反复重试直到把 8 轮预算烧完最后什么都没写。此时你只会觉得技能怎么没生成很难联想到是模型层面的工具调用格式问题。3.3 摘要行的判定读的是本地消息不是网关返回体原文里那段扫描逻辑核心是遍历 review Agent 的_session_messages只认role tool的消息解析里面的 JSON要求success为真再根据 message 里的 created / updated / added / removed / replaced 关键词归纳动作。等价的重写大致长这样seen [] for m in getattr(review_agent, _session_messages, []): if not isinstance(m, dict) or m.get(role) ! tool: continue try: payload json.loads(m.get(content) or {}) except (json.JSONDecodeError, TypeError): continue if not payload.get(success): continue msg (payload.get(message) or ).lower() target payload.get(target) or memory if any(k in msg for k in (created, updated, added, removed, replaced)): seen.append(f{target} changed) if seen: self._safe_print( · .join(dict.fromkeys(seen)))这里有个重要结论这段逻辑读的是 Hermes 自己累积的消息列表和工具返回结构跟底层是哪个模型供应商、走哪条 API 通道没有关系。只要工具层还是那套success/message/target字段摘要行的内容和去重行为就完全一致Memory updated · User profile updated 这种拼接不会变。4. 轨迹数据会不会断save_trajectories 与 _convert_to_trajectory_format 的输入来自哪里4.1think归一化扫的是字段名不是供应商_convert_to_trajectory_format()的归一化分三步消息里有非空的reasoning字段就包一层think正文里出现REASONING_SCRATCHPAD就整体替换成think如果一个 gpt turn 里什么推理都没有补一个空的think块保证格式一致。这三步全是在本地消息列表上做的后处理。你把 Base URL 换成https://taotoken.net/api这一步照跑不误。唯一需要留意的是原生推理字段这一条如果所选模型返回的推理内容不在 Hermes 能识别的字段里第一步就匹配不到轨迹里的 think 块会变成空的。格式没坏、内容没丢但思维链部分确实少了。挑模型时如果很在意训练数据的思维链质量先跑一条任务导出轨迹看一眼第一个 gpt turn 里有没有实际内容。4.2 tool_stats 统计的是本地工具执行batch_runner 生成的 JSONL 里每条记录除了conversations还带api_calls、toolsets_used和tool_stats。tool_stats记的是 terminal、read_file、write_file 这类工具的 count / success / failure并且会归一化到model_tools.TOOL_TO_TOOLSET_MAP里的全部工具名没用到的填零。这个统计的来源是本地工具执行结果模型通道换了也不影响。真正影响它的是 Hermes 自己的工具层有没有正常返回——比如某个文件读不到、某个 patch 失败failure 计数就会涨跟供应商无关。所以做数据质量分析时tool_stats里 failure 偏高的样本更值得先看那通常意味着任务本身难而不是通道有问题。4.3 只有 model 字段会跟着变这不算断轨迹 JSON 里有一个model字段原文示例里写的是类似anthropic/claude-sonnet-4.6这样的型号串。换通道之后这个字段会变成你在配置里填的模型 ID。前后两批数据混在一起做统计时model字段会不一致——这不是数据损坏但做数据集切分或者对比实验时最好按model分组看别把两批当成同一分布。模型 ID 一律以模型广场当时的列表为准。自己动手拼个日期后缀或者版本号当配置轻则 404重则跑到一个你没预期的模型上训练数据里混进一堆风格不一致的样本事后很难清理。4.4 batch_runner.py 断点续传和 schema 一致性批量跑批的流程是加载 JSONL 数据集、按 batch 切分、用 multiprocessing 并行处理、每个 batch 落到batch_{N}.jsonl、最后合并成trajectories.jsonl--resume基于内容去重做断点续传。因为tool_stats被补齐到全工具集所有行的 schema 是一致的加载到 HuggingFace Datasets 时不会因为 Arrow schema 不匹配报错。换通道对这个流程唯一的实际影响在并发限流。multiprocessing 默认会把并发开到核数几十个进程同时打新通道容易撞到速率限制表现是部分样本partial: true。跑批之前先把并发调低一档用几条样本试跑比上来就全量跑、跑完发现三分之一是半截轨迹要划算。5. 验证闭环跑一遍 print() 到 logging.info() 的迁移任务5.1 前几步造场景、多聊几轮、盯住摘要行启动 CLI给一个足够复杂的任务hermes chat # 帮我把当前目录下所有 .py 文件的 print() 替换成 logging.info() # 每个文件都要先读取、再修改、再验证。完成后告诉我改了几个文件。这个任务会触发大量读文件 → patch → 验证 → 调整的主循环往返技能 nudge 命中的概率很高。任务跑完后继续在同一 session 里聊几轮偏好比如以后改 Python 文件保持 Black 风格、项目用 Poetry 管依赖。总轮次到 10 时记忆 nudge 也会命中。响应送达之后注意看 terminal 输出里有没有多出一行摘要。这一行是后台 review 唯一可见的痕迹不会弹框、不会打断你也不会有确认流程。配置了background_review_callback的 Gateway 模式下它还会往消息平台推一条内容一致。5.2 第四步去看文件和技能目录cat ~/.hermes/memories/MEMORY.md find ~/.hermes/skills -name SKILL.md cat ~/.hermes/skills/print-to-logging-migration/SKILL.md重点不是文件存在而是内容是否符合你的预期。如果MEMORY.md里出现了一条你没印象的偏好先别急着删——很可能是某轮 review 从你随口一句话里提炼出来的。技能目录里如果生成了以任务命名的文件夹说明skill_manage调用成功落盘了。5.3 第五步新 session 看技能是否自动复用hermes chat -q 帮我把另一个目录的 print() 也改成 logging按预期Agent 会先skills_list()发现相关技能再skill_view()加载完整步骤然后照着执行。第二次通常更快、更一致这就是这套闭环最直观的效果。如果第二次完全没复用先确认SKILL.md真的写进去了再确认技能目录在扫描路径内最后才去怀疑模型或通道。5.4 顺手抽一条轨迹确认格式没坏ls -la ./trajectories head -n 1 ./trajectories/trajectories.jsonl | python -m json.tool看两处gpt turn 里有没有think块、tool 消息是不是被tool_response包着。另外别漏了model字段确认它就是你这次配置里填的模型 ID而不是某个默认值。6. 排障401、404、模型名对不上、nudge 不触发6.1 401 大多数跟 Key 的来路和写法有关先确认 Key 是从 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建的控制台里能查到这把 Key 的记录。复制时多带了首尾空格、引号里有换行都会直接 401。还有一种情况更隐蔽主循环正常、后台 review 报 401原因是 CLI 里手动export的变量没被子进程继承——review Agent 是 fork 出来的它读的是配置文件配置文件里还留着旧的占位符。6.2 404 优先查 Base URL 尾巴Base URL 只写https://taotoken.net/api不要加/v1。很多 OpenAI 兼容客户端会自己拼路径你手写/v1之后就变成/v1/v1/...服务端直接 404。另外别把 UTM 参数拼到 Base URL 上那是给官网落地页的填进工具里只会让路径匹配失败。6.3 模型 ID 对不上就回模型广场看后台 review 报模型不存在这类错误时先把配置里的模型 ID 复制出来跟模型广场当时的列表逐字对一遍。大小写、连字符、斜杠位置都算数。自己在本地记下来的旧 ID 最不可靠。6.4 nudge 不触发先看三个地方第一memory.nudge_interval和skills.creation_nudge_interval有没有被设成 0——设成 0 等于关掉定期 nudge 和后台 review 这条在线闭环轨迹采集和 session 结束前的记忆 flush 还在但那已经不是同一回事了。第二Agent 有没有自己主动调memory/skill_manage把计数器清零。第三技能 nudge 看的是主循环迭代数如果这轮任务只调了两次工具就结束离阈值可能还差得远。6.5 轨迹文件写不出来或者字段缺失先确认save_trajectories是开着的再看输出目录的写权限。completed: false加partial: true表示任务是中途中断的不是通道问题。如果整批轨迹里所有 gpt turn 的 think 块都是空的回到 4.1 那节从模型返回字段的角度找原因。7. 配通之后去控制台对一下这几笔后台调用7.1 先用同一把 Key 发一条测试消息后台 review 的调用不像主循环那么显眼配完配置直接开长会话很容易在 nudge 命中那一刻才发现 Key 有问题。建议先在 TaoToken 模型对话 里用配置里那把 Key 和同一个模型 ID 发一条普通消息确认 Base URL 和模型 ID 都填对了再回到 Hermes 里跑迁移任务。7.2 长会话跑起来之后看用量曲线长会话的用量曲线不是线性的。每命中一次 nudge后台 review 就会多出七八次请求曲线上能看到明显的台阶。如果你在 CLI 里连续跑好几天建议看一眼 Coding Plan 的套餐是否还够用需要按用途拆多把 Key 时到 控制台 API Keys 里创建和管理。两件事别搞混官网落地页是用来注册、创建 Key、看模型广场和用量的填进config.yaml的 Base URL 永远是https://taotoken.net/api不带/v1也不带任何查询参数。把这两处分清楚后面切换模型或者多人共用时改的永远只有配置里的模型 ID 那一行。