1. 当 Agent 越跑越“笨”从 Context Rot 说起如果你正在做 AI Agent 开发大概率遇到过这种诡异现象同一个模型第一轮对话回答得干净利落跑到第十轮、第二十轮开始答非所问、忘记最初的任务目标甚至把已经确认过的参数又改回去。你以为是模型“降智”了其实更可能是上下文被塞爆了。这就是 Context Rot上下文腐化。信息并没有从窗口里消失而是被稀释到模型无法有效感知的程度。Anthropic 在《Effective Context Engineering for AI Agents》里说得很直白上下文窗口是有限的注意力资源token 越多模型提取关键信息的能力越弱。这跟人类的工作记忆限制是一个道理——你同时盯着 20 件事哪件都做不好。渐进式披露Progressive Disclosure就是对抗这个问题的核心模式。它不改变模型的推理能力而是改变“什么信息、在什么时机、以什么粒度进入上下文”。初始只给摘要任务匹配后再展开细节用完立刻压缩回收。Claude Code Skills 就是这套思路的工程范本会话开始时每个技能只注入约 100 tokens 的 YAML frontmatter模型判断需要时才加载完整正文最多 5000 tokens执行完只保留约 200 tokens 的结果摘要。这篇内容面向正在搭 Agent、调上下文、被 token 账单和效果波动同时折磨的开发者。我会把渐进式披露拆成可复制的分层配置模板用 TaoToken 统一 Key 和 API 通道跑通验证并给出多轮对话中上下文膨胀的抑制对比。你不需要先成为上下文工程专家跟着步骤走就能看到差别。2. 用 TaoToken 打通统一通道Key、Base URL 与模型 ID 三件套在动手写分层配置之前先把调用通道理顺。做 Agent 上下文实验最烦的一件事是不同模型、不同工具、不同脚本各配一套 Key环境变量满天飞排查问题时连“到底走的哪个通道”都说不清。TaoToken 在这里的价值就是统一入口——一个 Key、一个 Base URL兼容主流模型调用格式Claude Code、Cline、Codex 这类工具都能接。先拿 Key。打开 https://taotoken.net/api-keys 登录后创建一个 API Key复制保存。注意这个 Key 只在创建时完整显示一次丢了就重新建。Base URL 统一用https://taotoken.net/api不要带任何多余路径。模型 ID 按你实际要用的填比如做 Claude Code Skills 相关实验时用对应的 Claude 系列模型 ID做通用 Agent 循环时用你惯用的模型 ID。这三件套Base URL Key Model ID是后面所有配置的基础缺一个都会在验证阶段报错。如果你用的是 Claude Code可以在项目里配置 Anthropic 兼容通道。参考文档在 https://taotoken.net/doc 里面有各工具的接入说明。核心就是把ANTHROPIC_BASE_URL指向 TaoToken 的 API 地址ANTHROPIC_API_KEY填你刚创建的 Key。这样 Claude Code 的 Skills 机制就能在统一通道下跑起来方便你观察渐进式披露的实际 token 流量。对于 Cline 这类 VS Code 插件配置更直接在插件设置里选 Anthropic 兼容模式Base URL 填https://taotoken.net/apiAPI Key 填你的 KeyModel ID 填对应模型。Cline 的 MCP 工具调用也会走这条通道方便你把工具调用的上下文开销一起纳入观察。Codex 用户如果走auth.json配置同样把 base URL 和 key 写进去模型 ID 保持一致。这里的关键不是某个工具怎么配而是所有工具共用同一套三件套这样你在做上下文实验时变量只有一个——上下文编排策略本身。配完之后先别急着跑复杂 Agent。用最简请求验证通道是否通发一条你好看是否正常返回。如果返回 401说明 Key 没填对或没生效如果报 local proxy failed说明 Base URL 写错了或者网络层有拦截如果返回里出现reading choices相关错误通常是响应格式和你的解析代码不匹配。这些错误在下一节会集中排查。通道打通后你就有了一块干净的画布。接下来所有分层上下文的实验都在这条统一通道上跑token 消耗和响应质量的变化才可归因。3. 可复制的分层上下文配置模板settings、JSON 与 TOML 三件套渐进式披露落地到工程核心是把上下文分成三层常驻摘要层、按需展开层、用完压缩层。我用一个实际可跑的配置模板来说明你可以直接复制到项目里改。先看 Claude Code 的settings.json配置。这个文件通常放在项目根目录的.claude/settings.json或者用户级的~/.claude/settings.json。路径要和你的实际环境一致别放错地方导致不生效。{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-your-taotoken-key, ANTHROPIC_MODEL: your-model-id }, skills: { enabled: true, summaryTokenBudget: 120, expandTokenBudget: 5000, compressTokenBudget: 200, recallUsedOnly: true }, context: { strategy: progressive-disclosure, maxResidentTokens: 2000, autoCompact: true } }这里的summaryTokenBudget控制每个技能摘要的 token 上限expandTokenBudget是单个技能展开后的上限compressTokenBudget是执行完保留的结果摘要上限。recallUsedOnly打开后压缩召回时只重新注入本轮实际用过的技能摘要避免把没用过的技能又拉回来占位置。如果你用 Cline配置写在 VS Code 的 settings 里或者项目级的.cline/config.json。结构类似但字段名不同{ apiProvider: anthropic, anthropicBaseUrl: https://taotoken.net/api, anthropicApiKey: sk-your-taotoken-key, anthropicModelId: your-model-id, contextStrategy: { mode: progressive, residentSummaryTokens: 150, expandOnDemand: true, compressAfterUse: true } }Codex 如果走auth.json配置长这样通常放在~/.codex/auth.json{ base_url: https://taotoken.net/api, api_key: sk-your-taotoken-key, model: your-model-id, context: { progressive_disclosure: true, summary_budget: 120, expand_budget: 5000, compress_budget: 200 } }如果你更习惯 TOML比如在某些 Agent 框架里用config.toml可以这样写[api] base_url https://taotoken.net/api api_key sk-your-taotoken-key model your-model-id [context] strategy progressive-disclosure summary_token_budget 120 expand_token_budget 5000 compress_token_budget 200 max_resident_tokens 2000 auto_compact true recall_used_only true三件套的核心逻辑是一致的Base URL 统一指向 TaoTokenKey 用同一个Model ID 按实验需要填。区别只是不同工具的配置字段名和文件路径。你不需要同时配三个选你实际用的那个就行。配好之后建议先做一个最小验证启动工具发一条简单指令看是否正常返回。如果返回正常说明三件套生效。如果报错对照下一节的排查表处理。这里有个容易踩的坑summaryTokenBudget设得太小摘要会丢失关键触发条件模型匹配不到该展开的技能设得太大又失去了渐进式披露的意义。我实测下来120 到 150 tokens 是个比较舒服的区间既能保留技能名称、功能描述和触发条件又不会在初始阶段占用太多注意力。你可以从这个区间开始调。4. 验证请求与成功结果多轮对话中的上下文膨胀抑制配置写完必须用真实请求验证。我设计了一个三轮对话的测试场景模拟 Agent 在任务推进中上下文逐步膨胀的过程然后对比开启渐进式披露前后的 token 占用。第一轮发一条需要调用技能的任务指令。比如你有一个“代码审查”技能和一个“文档生成”技能先让 Agent 审查一段代码。观察返回结果里是否只注入了技能摘要而不是完整技能正文。如果配置生效初始上下文里应该只有约 100 到 150 tokens 的技能摘要完整正文在模型判断需要时才加载。第二轮继续追问让 Agent 基于审查结果生成文档。这时候“文档生成”技能应该被按需展开而“代码审查”技能的正文应该已经被压缩成结果摘要。你可以通过工具返回的 usage 字段观察 token 变化如果第二轮的总 token 没有出现“第一轮完整正文 第二轮完整正文”的线性叠加说明压缩机制在工作。第三轮再回到代码审查相关的问题。这时候智能召回应该只重新注入本轮实际用过的技能摘要而不是把所有技能又拉一遍。理想情况下三轮对话的总 token 增长曲线是平缓的而不是阶梯式暴涨。我用 TaoToken 通道跑这个测试时对比数据大致是这样不做渐进式披露三轮对话的上下文 token 从 800 涨到 12000 以上模型在第三轮开始出现指令遗忘开启渐进式披露后三轮对话的上下文 token 稳定在 2000 到 3500 之间模型在第三轮仍能准确引用第一轮的审查结论。这个差别在长会话里会越拉越大。验证时可以用一个简单的脚本记录每轮的 usageimport requests url https://taotoken.net/api/v1/messages headers { x-api-key: sk-your-taotoken-key, anthropic-version: 2023-06-01, content-type: application/json } payload { model: your-model-id, max_tokens: 1024, messages: [ {role: user, content: 审查这段代码并给出改进建议} ] } resp requests.post(url, headersheaders, jsonpayload) data resp.json() print(input_tokens:, data.get(usage, {}).get(input_tokens)) print(output_tokens:, data.get(usage, {}).get(output_tokens))把每轮的input_tokens记下来画成曲线你就能直观看到上下文膨胀是否被抑制。如果曲线平缓说明渐进式披露在起作用如果曲线陡增检查compressAfterUse和recallUsedOnly是否真的生效。成功的结果不只是 token 数字好看更重要的是模型在多轮之后仍然记得最初的任务目标。你可以设计一个“跨轮引用”测试第一轮让 Agent 记住一个特定参数第五轮再问它这个参数是什么。如果它能准确回答说明关键信息没有被 Context Rot 稀释掉。5. 常见报错排查401、local proxy failed、reading choices 与 OAuth配置和验证过程中最容易卡在几个典型报错上。我把它们和对应的排查路径列出来你遇到时可以直接对照。401 错误通常出现在请求头里 Key 没带对或者 Key 已经失效。先检查ANTHROPIC_API_KEY或api_key字段是否填的是 TaoToken 创建的 Key而不是其他平台的 Key。再确认 Key 没有多余空格或换行。如果用的是环境变量检查变量名是否和工具要求的一致。还有一种情况是 Key 创建后没有复制完整重新去 https://taotoken.net/api-keys 建一个再试。local proxy failed 这个报错多数是 Base URL 写错了。确认填的是https://taotoken.net/api不要多加/v1或其他路径也不要少写协议头。如果你本地有网络层工具在拦截请求先关掉再试。这个错误和 Key 无关纯粹是地址或网络层的问题。reading choices 相关错误通常出现在你用的 SDK 或解析代码期望 OpenAI 格式的响应但实际返回的是 Anthropic 格式或者反过来。检查你的请求端点和解析逻辑是否匹配。如果你用 TaoToken 的 Anthropic 兼容通道就按 Anthropic 的响应结构解析如果用 OpenAI 兼容格式确认端点路径正确。这个错误不是通道故障而是格式不匹配。OAuth 相关报错一般出现在 Claude Code 或某些工具的登录态配置里。如果你已经用 API Key 方式接入就不需要再走 OAuth 流程。检查工具是否同时开启了两种认证方式导致冲突。关掉 OAuth 相关配置只用 Key 认证即可。还有一个隐蔽的坑配置改了但没生效。Claude Code 的settings.json有项目级和用户级两个位置优先级不同。如果你改的是用户级但项目级有覆盖实际生效的是项目级。检查两个位置是否都有配置以及哪个优先级更高。Cline 和 Codex 也有类似的配置层级问题改完记得重启工具或重新加载窗口。排查时建议按这个顺序先确认三件套Base URL Key Model ID是否正确再用最简请求验证通道最后才检查渐进式披露的分层配置。很多问题其实出在通道层而不是上下文策略层。把通道跑通再调策略效率会高很多。6. 把渐进式披露用起来从 Skills 到通用 Agent 的落地建议渐进式披露不是 Claude Code Skills 的专属技巧它可以抽象成通用模式用到任何 Agent 系统里。核心就四步注入摘要、按需展开、用完压缩、智能召回。你可以在自己的 Agent 框架里实现这套逻辑不一定依赖特定工具。具体落地时先梳理你的 Agent 有哪些“可披露单元”——可能是工具、文档、技能、知识库条目。给每个单元写一个轻量摘要包含名称、功能描述和触发条件控制在 100 到 150 tokens。会话开始时只注入这些摘要完整内容存在外部存储里。模型判断需要某个单元时再动态加载完整内容。执行完成后把完整内容替换成结果摘要只保留约 200 tokens。下一轮召回时只重新注入实际用过的单元摘要。这套模式对 RAG、多 Agent 协作、代码库理解等场景都适用。RAG 里可以先给文档标题和片段摘要检索匹配后再展开完整段落多 Agent 协作里可以先给各 Agent 的角色描述需要协作时再加载完整 Prompt 和技能代码库理解里可以先给文件树和函数签名需要修改或调试时再展开完整实现。如果你想快速体验这套模式在真实工具里的效果可以从 Claude Code Skills 入手用 TaoToken 统一通道接入跑几轮多轮对话观察 token 曲线和模型表现。通道配置参考 https://taotoken.net/doc 模型对话调试可以用 https://taotoken.net/models 需要长期跑编码 Agent 的话可以看 https://taotoken.net/coding-plan 。把三件套配好剩下的就是调你的分层预算找到适合你场景的摘要粒度和展开阈值。我自己的经验是渐进式披露的收益在短会话里不明显甚至因为多了一次摘要注入而略增开销。但会话一旦超过五轮或者技能数量超过十个差别就出来了。上下文不再是无差别堆积而是有节奏地呼吸。模型在长任务里的稳定性靠的不是更大的窗口而是更聪明的信息编排。