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/api，API Key 填你的 Key，Model 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 统一指向 TaoToken，Key 用同一个，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 之间，模型在第三轮仍能准确引用第一轮的审查结论。这个差别在长会话里会越拉越大。
验证时可以用一个简单的脚本记录每轮的 usage：
import 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, headers=headers, json=payload) 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 。把三件套配好，剩下的就是调你的分层预算，找到适合你场景的摘要粒度和展开阈值。
我自己的经验是，渐进式披露的收益在短会话里不明显，甚至因为多了一次摘要注入而略增开销。但会话一旦超过五轮，或者技能数量超过十个，差别就出来了。上下文不再是无差别堆积，而是有节奏地呼吸。模型在长任务里的稳定性，靠的不是更大的窗口，而是更聪明的信息编排。
