Coding Agent 长对话 2000 轮后变傻模型通道改走 TaoTokenhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_end这是灵光Muse平台排障记录里最典型的一条。写下这条记录的人几乎不写代码全靠自然语言跟 Agent 来回聊需求等到轮次破两千、累计 token 到 6 亿这个量级Agent 开始丢约束——前面确认过三遍的表名重新问一遍生成的 SQL 引用一个根本不存在的字段同一段口径解释到第四遍还在原地打转。重度用户月账单一度冲到 ¥5000账单和体验同时失控团队这才意识到问题不在提示词写得糙而在上下文预算和模型通道这两条链路被混在一起看了。这篇把当时的定位过程重走一遍先分清是 working memory 被历史消息顶满还是通道侧在超时重试再把模型调用层从各家自建通道统一收到一个入口SemanticCache 的内容哈希比对和「文件即记忆」的按需加载/卸载逻辑原样保留最后用一条 200 轮以上的长对话验证 evict 触发点和 semantic index 唤起是不是还在该响的时候响。1. 灵光/Muse 里 Agent 变傻的现场先分清 evict 还是通道抖动1.1 PMO 同事的 2000 轮6 亿 tokens 和 ¥5000 账单是什么形状灵光内部也叫 Muse最开始的目标很朴素让不写代码的人也能用自然语言驱动 Agent 干完查数、整理表、改脚本这些活。PMO 同事是最典型的用户样本他不用 IDE也不看 diff整个工作台就是一个聊天窗口。问题是这个窗口不会结束。早上问一个指标口径怎么算中午追问这个字段来自哪张源表下午让 Agent 把上周的脚本改一版加上新的过滤条件第二天回来接着问同一份数据的月度对比。轮次不是一次任务跑 2000 轮而是同一个会话被当成了常驻工作台一天一天往里堆。堆到两千轮之后token 消耗涨到了 6 亿量级重度账号月账单摸到 ¥5000。更麻烦的是钱花出去了回答质量反而在下降——这是最让人难受的一种账单你没法拿它去论证投入产出。1.2 症状三连丢表名、编字段、重复确认把当时的会话样本抽出来看故障表现集中成三类丢约束第一轮约定的「金额单位统一按元、时间按自然月」在后面几十轮里被忘掉Agent 又开始按分和自然周算。编字段生成 SQL 时引用一个源表里不存在的列名写法看着很像真的跑起来直接报无效标识符。重复确认同一个表名前后确认四遍每遍都问「你指的是哪一张」。这三类症状背后其实是两条完全不同的链路在打架。前两类多半是上下文预算问题——早期约定的内容已经被挤出窗口第三类则可能是通道侧返回被截断或者某次请求超时重试后拿回了一份不完整的响应Agent 拿着半截上下文往下接。1.3 定位顺序先量 prompt 预算再量通道错误率排障最忌讳一上来就改配置。我们当时的顺序是固定的观察项采集位置判读每轮 prompt_tokensAgent 请求日志连续逼近模型窗口上限说明是预算问题evict 事件次数working memory 模块突然变密说明历史正在被频繁挤出去semantic index 命中率记忆层埋点断崖式下跌说明唤起逻辑失效通道 4xx / 5xx 与超时模型调用层占比超过阈值才怀疑通道先看 token 曲线再看通道日志能省掉大量瞎改。我们那次曲线很明确prompt_tokens 在第 1700 轮之后基本贴着上限走而通道错误率一直很低。方向一下就清楚了——不是通道在抖是窗口被历史吃满了。2. SemanticCache 哈希比对在长对话里为什么先掉命中2.1 内容哈希比的是前缀稳定性不是轮次多少SemanticCache 的核心做法不复杂把一段内容拼起来算哈希比如 system prompt、工具定义、检索出来的文件片段、最近若干轮对话算出一个键命中就直接复用上一次的中间结果或压缩后的结论。关键在于这个哈希比的是前缀稳定性。长对话里每一轮都在尾部追加 user 和 assistant 消息只要参与哈希的内容里包含了「最近 N 轮」这个哈希就一直在变。轮次越多前缀被扰动得越频繁缓存命中率就越低。所以后来我们把缓存分成两层文件快照、工具 schema 这类几乎不变的内容放稳定层参与哈希对话尾部放易变层不参与哈希只做长度控制。改完这一层命中率立刻回了一截而且和模型通道本身没有任何关系。2.2 「文件即记忆」的 evict 信号什么时候卸载、什么时候唤起文件即记忆的思路是把仓库或数据目录里的文件当成外部记忆用到的时候加载进上下文用完就卸掉不常驻。触发卸载evict的信号我们用了三个上下文占用超过设定阈值优先卸载最近没被引用的文件片段某个文件连续 N 轮没有被任何一次检索命中标记为冷内容新的一轮里 semantic index 命中了更新的文件版本旧版本直接卸载。唤起则是反过来的用户说「那张订单表」semantic index 在向量库里找到对应的建表语句片段按需拉回上下文。这一套逻辑和后面接哪家模型没有关系所以切换通道的时候它必须原封不动保留——否则你根本分不清是记忆策略坏了还是通道坏了。2.3 切通道之前先把缓存键里和后端无关的部分固定下来这是个血泪顺序问题。切通道和调缓存要是一次全动出了故障你只有两个怀疑对象却分不清主次。我们的做法是先冻结缓存键的组成稳定层参与哈希的内容一个字不改易变层只允许改长度阈值。把这一版跑干净、命中率曲线平稳之后再动模型调用层的 Base URL。一次只改一个变量长对话这种慢故障才定位得下去。3. 把模型调用层统一到 TaoToken从创建 Key 到填 Base URL3.1 在官网创建 Key模型 ID 以模型广场为准这一步对应原文里「去各家控制台分别申请密钥」那一段现在收口成一件事打开 TaoToken 官网 注册进控制台创建一个 API Key复制出来之后在代码里统一写成YOUR_API_KEY这个占位符真实值放进环境变量别硬编码进配置。模型 ID 不要凭记忆写。去模型广场看当时那份列表列表里叫什么就填什么写错一个字符就是一个 404。3.2 复现项目的模型适配层只改 base_url 和 api_key原平台里各家通道是散在各处的不同模块各自初始化 SDK出了问题得逐个翻代码。复现的时候我们直接收口成一份适配层配置# config/model_providers.yaml providers: default: name: taotoken base_url: https://taotoken.net/api api_key_env: TAOTOKEN_API_KEY model: YOUR_MODEL_ID timeout_ms: 120000 max_retries: 2 stream: true配套的环境变量export TAOTOKEN_API_KEYYOUR_API_KEY export TAOTOKEN_MODELYOUR_MODEL_ID两个容易写错的地方base_url填https://taotoken.net/api末尾不要加/v1Key 从 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentagent_key 创建之后直接贴进环境变量别再在代码里拼字符串。改完之后重试策略和超时都归到这一层统一管。长对话场景里重试次数别设太大两到三次足够设太多会在通道真正抖动的时候把上下文越搅越乱。3.3 顺手把本地三个工具对齐同一把 Key平台跑通之后本地那几个常用的执行工具也可以指向同一个入口省得每次换环境重新找 Key。Claude Code 用~/.claude/settings.json里的 env 段{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: YOUR_MODEL_ID } }Codex 走的是另一套字段写在~/.codex/config.toml千万别把ANTHROPIC_*变量套过来model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chatCC Switch 这类切换工具则是三件套自定义供应商里填 Base URLhttps://taotoken.net/apiKey 填YOUR_API_KEY模型 ID 照模型广场当时的列表抄。这三个工具的定位只是「本地执行工具」长对话的主体实验还是在平台侧跑。4. 用 TaoToken 通道跑一轮 200 轮长对话evict 与 semantic index 的观察点4.1 压测脚本灌历史、打点、导出命中率验证不能靠「感觉好像聪明了一点」。我们写了个最小压测脚本造 220 轮合成对话灌进去每轮记录四件事prompt_tokens、缓存命中情况、evict 事件、semantic index 命中。import os from openai import OpenAI # 以你项目里实际使用的 SDK 为准 client OpenAI( base_urlhttps://taotoken.net/api, api_keyos.environ[TAOTOKEN_API_KEY], ) history build_synthetic_turns(220) # 你自己的造数函数 for i, turn in enumerate(history): history.append({role: user, content: turn}) resp client.chat.completions.create( modelos.environ[TAOTOKEN_MODEL], messageshistory, ) log_round( round_indexi, usageresp.usage, memoryagent.working_memory.stats(), )跑完之后把log_round导出的 CSV 画两条线一条 prompt_tokens一条 evict 次数。正常情况下evict 应该在阈值附近形成规律的锯齿而不是某一轮突然连发十几次——后者说明卸载策略被一次超大检索结果带崩了。4.2 SQL 生成链路怎么验证Agent 出 SQL你本地执行报错贴回这是长对话里最容易暴露上下文丢失的环节。注意分工Agent 只负责生成 SQL、解释执行计划、根据报错给修改建议真正的执行动作由你在本地客户端或 SQL*Plus 里做把报错的原文原样贴回对话。这个来回本身就是一次上下文压力测试。如果贴回来的报错在第 201 轮还能被正确引用说明 evict 没把关键的表结构片段清掉如果 Agent 看到报错又开始问「你说的这张表是哪个库的」那就是 semantic index 没唤起回头去看第 2 章的哈希键和阈值设置。4.3 用量和缓存命中放在同一张表里看排障到最后账本和曲线必须能对上。我们把每轮的 token 消耗、命中的文件、evict 事件、通道耗时拼成一张表然后拿平台侧的记录去对 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentagent_usage_check 上面的用量页。对不上的时候先怀疑两件事一是重试没记账一次失败重试在本地只算一次但在通道侧算了两次二是流式响应被中断本地统计的是收到的部分通道侧统计的是实际生成的完整量。这两种偏差都很常见不改代码改日志埋点就能解。5. 切通道后的排障对照表401、404、evict 不触发、缓存不命中5.1 401 与 404Key 拼接和 /v1 后缀这两个错误码几乎占了切换期故障的一半。401Key 没读到或者环境变量名和配置里的api_key_env对不上。先确认echo $TAOTOKEN_API_KEY有值再确认代码里读的是同一个变量名。404Base URL 写错了。最常见的是自作主张在末尾补了个/v1或者漏掉了/api。正确写法就是https://taotoken.net/api一个字符都别加。5.2 evict 不触发阈值没跟着模型的上下文窗口走换通道时如果顺手换了模型上下文窗口大小可能变了但 evict 阈值还停在旧值上。窗口变大、阈值没动结果是历史越堆越多缓存前缀被反复扰动命中率掉下去Agent 看起来又变傻了。修法很简单把阈值改成窗口的一个比例比如 70%而不是写死一个绝对数字。这样换模型的时候不用再回来改代码。5.3 缓存命中率还是低system prompt 里混进了时间戳如果阈值调完命中率还是上不去去翻 system prompt 和工具定义。常见污染源有三个注入的当前时间戳、每次请求都变的会话 ID、以及拼在系统提示里的随机排序结果。这三样东西只要有一个进了哈希缓存层就永远在 miss。把它们挪到易变层稳定层只保留真正不变的内容命中率通常能回到正常区间。6. 下一步把这次长对话的账本和缓存曲线一起盯住跑完这一轮 220 轮的实验你手里应该有两样东西一张按轮次铺开的 token 账本和一条 evict 与 semantic index 的触发曲线。前者告诉你钱花在哪后者告诉你上下文是怎么被管理的。这两件事以前分散在几套自建通道和各自的账单里现在收在同一个入口对账才算真正做起来了。想复看这次会话的原始记录可以打开 TaoToken 模型对话 用同一把 Key 发一条测试消息确认模型 ID 和 Base URL 都没填错长期跑长对话的话去 Coding Plan 看套餐够不够撑住你那个会话的轮次量新 Key 在 控制台 API Keys 创建。本地 Claude Code 的环境变量字段对照看 Claude Code 接入文档。最后留个提醒长对话的排障顺序不要反过来。先确认账本再确认记忆层的 evict 曲线最后才动 Base URL。反过来做你会在一个本来没坏的通道上折腾一整天而那个真正把窗口吃满的检索逻辑还在后台安静地跑着。