1. TaoToken 发 Key 后ReAct 长任务为什么先崩在上下文如果你已经在 TaoToken 官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentreact_notes_intro拿到 API Key并且把 Claude Code 的ANTHROPIC_BASE_URL指向https://taotoken.net/api那么接下来最容易踩的坑往往不是模型选型而是 ReAct 长任务跑到二三十轮之后Agent 开始忽略最初设定的规则。典型症状第 1 轮明确要求“错误变量统一命名为 err、函数不超过 50 行、变量用 camelCase”第 10 轮还遵守第 30 轮开始生成snake_case第 40 轮连错误处理风格都混了。你去看日志模型没有报错工具调用也成功但输出质量就是持续下滑。这不是模型突然变笨而是 ReAct 循环的“只进不出”结构在作祟。ReAct 定义了「Thought → Action → Observation」的闭环模型先思考再调用工具然后读取工具返回结果。这个循环解决了“让 LLM 动手做事”的问题却没有规定“做完之后旧信息怎么处理”。每一轮 TAO 都会往上下文里追加新内容Observation 尤其占空间一次文件读取、一次测试输出、一次编译日志轻轻松松就是几千 Token。上下文窗口再大也扛不住几十轮这样堆。所以TaoToken 发 Key 只是让模型能稳定调用真正的长任务稳定性要看上下文管理。本文给出一套可复现的做法用 Structured Note-Taking 把历史“卸载”到上下文窗口之外让 Agent 只保留当前决策真正需要的信息。文末会给出四类笔记模板和 Token 走势对照你可以直接套到自己的 Claude Code、Codex 或 CC Switch 工作流里。1.1 先区分ReAct 解决行动Context Engineering 解决信息供给ReAct 关注“下一步做什么”Context Engineering 关注“模型此刻看到什么”。两者不是替代关系。没有 ReActAgent 无法调用工具没有 Context EngineeringAgent 能在短任务里跑通但在长任务里会慢性退化。退化路径通常是这样Observation 越积越多有用信号被稀释系统指令被从开头挤到中间模型对它的注意力下降失败调用和错误日志留在历史里污染后续推理Thought 冗余积累消耗 Token 预算却不提供新信息。这四步合起来就是“Agent 用久了越来越差”的根因。2. 先把钥匙接对Claude Code、Codex、CC Switch 的 TaoToken 配置在讲笔记外置之前先把 TaoToken 接进常用工具。入口是 TaoToken 官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentreact_notes_config在控制台创建 API Key然后统一把 Base URL 设为https://taotoken.net/apiKey 在配置里先用占位符YOUR_API_KEY不要把真实 Key 提交到 Git。2.1 Claude Codesettings.json 与 ANTHROPIC_*Claude Code 推荐在~/.claude/settings.json或项目级.claude/settings.json里写入环境变量{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY } }如果你的 Claude Code 版本使用ANTHROPIC_API_KEY也可以按本地文档替换字段名但核心不变Base URL 指向 TaoToken 的 API 地址。保存后重启 Claude Code让它重新读取配置。2.2 Codexconfig.toml 不要混用 ANTHROPIC_*Codex 使用 TOML 配置路径通常是~/.codex/config.toml。它的 provider 配置和 Claude Code 完全不同千万不要把ANTHROPIC_*写进 Codex 的配置里。一个最小化示例如下# ~/.codex/config.toml model_provider taotoken model YOUR_MODEL_ID [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY然后在 shell 里设置export TAOTOKEN_API_KEYYOUR_API_KEY如果你使用的 Codex 版本字段名不同以本地config.toml的 provider 说明为准但必须保证两件事base_url 是https://taotoken.net/api且不要出现ANTHROPIC_*。2.3 CC Switch 三件套供应商、模型、密钥CC Switch 用来在多个供应商之间切换。接入 TaoToken 时把它当成三件套来配置供应商Provider新增一个 TaoToken模型Model填入你在 TaoToken 控制台可用的模型 ID密钥API Key填入YOUR_API_KEY。Base URL 一栏填https://taotoken.net/api。配置完后先跑一个短对话验证连通再进入长任务。短对话都失败就不要急着上 ReAct。3. ReAct 的 Token 走势无笔记 vs 有笔记的对照要理解 Structured Note-Taking 的价值先看 Token 走势。下面是一个 50 轮代码重构任务的估算。假设每轮 TAO 产生Thought 约 200 TokenAction 约 150 TokenObservation 约 1,200 Token。无笔记时所有内容都留在上下文里有笔记时每 3 轮把 Observation 和旧 Thought 卸载到外部笔记上下文只保留系统提示、最近 2 轮原始对话、四类笔记摘要和当前任务状态。轮次无笔记累计 Token有笔记活跃 Token外置笔记 Token01,5001,50001018,0004,5006,0002036,0006,20012,0003058,0007,80019,0004082,0009,10026,00050108,00010,50033,000这张表不是精确基准而是一个工程估算模型。它要说明的是无笔记时上下文活跃 Token 随轮次线性膨胀有笔记时活跃 Token 被压在一个相对平缓的区间外置笔记虽然也在增长但它不在上下文窗口里只在需要时按需读取。3.1 为什么 Observation 是最大污染源Observation 是工具返回结果它天然不可控。读一个文件可能返回 3,000 Token跑一次测试可能返回 2,000 Token一次编译错误日志可能返回 1,500 Token。这些内容在当轮有用但下一轮就不一定需要完整保留。无笔记时它们全部留在历史里把系统指令和关键决策挤到中间。模型对中间位置内容的注意力本来就弱规则漂移就发生了。3.2 错误轨迹污染比想象中更隐蔽工具调用失败、超时、格式解析错误都是常态。ReAct 的容错机制会让 Agent 重试但失败的 Thought 和错误 Observation 也留在历史里。一旦一条错误信息进入上下文它可能影响后面多轮推理。你以为 Agent 在重新尝试实际上它在被之前的错误轨迹带偏。把错误日志卸载到笔记的“发现”或“问题”区只把结论放回上下文可以显著减少这种污染。4. Structured Note-Taking 的四个抽屉可复制模板Structured Note-Taking 的核心动作是把关键信息主动写到上下文窗口之外需要时再读回来。不要只写一个notes.md按用途拆成四个抽屉Agent 找信息更快人排查也更清晰。推荐目录结构project/ .agent/ notes/ progress.md decisions.md findings.md strategy.md state.json4.1 进度笔记Progress Notes记录已经完成什么、还没做什么。它回答“任务走到哪了”。# Progress Notes ## 已完成 - [x] auth_service.go 认证逻辑重构 - [x] 移除 session 依赖 - [x] 补充 JWT 单元测试 ## 进行中 - [ ] order_service.go 拆分订单校验逻辑 ## 待处理 - [ ] payment_service.go 错误处理统一 - [ ] 全量回归测试4.2 决策笔记Decision Notes记录为什么这样选避免后续 Agent 推翻已经过论证的方案。# Decision Notes ## D-001 选择 JWT 而非 Session - 原因服务无状态需要水平扩展 - 影响auth_service 不再写本地 session - 状态已确认 ## D-002 错误变量统一命名为 err - 原因团队规范便于 grep - 例外导出错误使用 ErrXxx - 状态已确认4.3 发现笔记Finding Notes记录过程中发现的重要事实、冗余调用、隐藏依赖。# Finding Notes ## F-001 payment_service 重复调用 auth_service - 现象每个请求调用 3 次认证 - 影响延迟增加日志重复 - 建议合并为一次调用并缓存结果 ## F-002 order_service 存在未处理 panic - 位置order_service.go:142 - 触发条件空订单 ID - 建议增加校验并返回错误4.4 策略笔记Strategy Notes记录下一步怎么做让 Agent 在上下文重置后能快速恢复执行方向。# Strategy Notes ## 当前优先级 1. 修复 payment_service 冗余认证调用 2. 处理 order_service 的 panic 3. 统一 error handling 风格 4. 跑回归测试 ## 约束 - 不改变对外 API - 每个 PR 不超过 300 行4.5 写入触发条件不要每轮都写也不要等上下文满了才写。推荐两个触发条件每 3 轮 TAO 循环后强制写一次进度和发现当上下文活跃 Token 超过预算的 60% 时触发一次全量整理。写入时只写结论不写原始日志。原始日志可以留在.agent/logs/里但不要自动塞回上下文。5. 把笔记接回 ReAct每轮上下文重组算法笔记写完之后关键是“怎么读回来”。每轮调用 LLM 之前不要直接把全部历史拼进去而是重组上下文。一个可用的结构如下def build_context(system_prompt, recent_turns, notes, task_state): return f {system_prompt} ## 当前任务状态 {task_state} ## 进度摘要 {notes[progress][-400:]} ## 关键决策 {notes[decisions][-400:]} ## 重要发现 {notes[findings][-400:]} ## 下一步策略 {notes[strategy][-400:]} ## 最近原始对话 {recent_turns} 这里的recent_turns只保留最近 2 轮原始 TAO。更早的内容已经被压缩成上面四个摘要。调用时把build_context的结果作为新的输入而不是把整个history列表直接丢进去。5.1 上下文预算分配表以 32K 上下文窗口为例可以这样分配区域预算说明System Prompt2,000角色、原则、工具使用规则当前任务状态500当前文件、阶段、约束四类笔记摘要1,600每类 400 Token 左右最近 2 轮原始 TAO3,000保留最新细节工具定义1,500只保留必要工具输出预留4,000给模型回答和工具调用缓冲19,400应对突发长 Observation如果某一轮 Observation 特别长不要直接塞进上下文先写入外置笔记再在上下文里放一句摘要“已读取 order_service.go发现 3 个问题详见 Finding Notes F-003。”5.2 读取策略按需读取不全量加载笔记文件可能越来越大不要每次把四个文件全部读进来。可以按当前阶段选择刚进入任务读 progress strategy做技术选型读 decisions排查 bug读 findings上下文重置后读 progress strategy再按需读 findings。如果笔记超过 2,000 Token先让模型做一次摘要再放进上下文。6. 实战50 轮代码重构任务的 Token 走势与修复动作假设你在用 Claude Code 做 Go 代码重构任务包括认证、订单、支付三个服务。第 1 轮系统指令要求变量用 camelCase、错误变量用 err、函数不超过 50 行。前 10 轮顺利第 20 轮开始偶尔出现snake_case第 30 轮错误处理风格混用。用 Token 走势看无笔记第 10 轮 18K第 20 轮 36K第 30 轮 58K第 40 轮 82K第 50 轮 108K。系统指令早已被挤出开头。有笔记第 10 轮活跃 4.5K第 20 轮 6.2K第 30 轮 7.8K第 40 轮 9.1K第 50 轮 10.5K。外置笔记增长到 33K但不在上下文里。修复动作把前 20 轮的 Observation 全部卸载到.agent/notes/findings.md上下文只留“已读取文件清单 关键发现编号”把 Thought 压缩成决策和策略不再保留完整推理过程把失败的工具调用日志移到.agent/logs/errors.log只在发现笔记里保留“某接口曾超时已重试成功”每 3 轮重新注入一次系统指令摘要放在用户消息结尾利用近因效应。执行后第 50 轮的活跃 Token 从 108K 降到 10.5K 左右Agent 对命名规范的遵守度明显回升。6.1 一个可复制的扫描脚本下面的脚本可以帮你统计本地笔记和日志的体积判断哪些内容不该留在上下文里#!/usr/bin/env bash NOTES_DIR.agent/notes LOGS_DIR.agent/logs echo notes tokens estimate for f in $NOTES_DIR/*.md; do [ -f $f ] || continue chars$(wc -c $f) echo $f: ~$((chars / 4)) tokens done echo logs size du -sh $LOGS_DIR 2/dev/null || echo no logs dir这个脚本只做本地统计不连接任何生产库也不调用外部 API。你可以按项目实际情况调整路径。7. 常见反模式与排障清单7.1 反模式一笔记只写不读Agent 把笔记写得很勤但每轮上下文重组时没有读回来。结果是笔记在磁盘上Agent 还是“失忆”。修复在build_context里固定加入四类笔记摘要并限制每类 400 Token。7.2 反模式二笔记变成第二个上下文把原始日志、完整文件内容、全部工具返回都写进笔记然后每次全量读回。这等于把上下文膨胀从内存搬到了磁盘但读回来时又膨胀了一次。修复笔记只写结论、决策、发现和下一步原始内容另存日志按需读取。7.3 反模式三系统指令只放开头系统指令一直放在开头随着上下文增长被挤到中间。修复每 5 到 10 轮在用户消息结尾重新放一段“当前必须遵守的规则摘要”利用近因效应。7.4 反模式四工具定义过多工具定义本身占 Token功能重叠的工具还会让模型选错。修复每个阶段只保留必要工具工具描述写清“适用场景”和“不适用场景”。7.5 排障清单上下文活跃 Token 是否超过预算 60%最近 3 轮是否包含超过 2,000 Token 的 Observation系统指令是否还在开头 20% 的位置笔记摘要是否每轮都读回失败调用日志是否还在上下文里工具定义是否超过 1,500 Token如果以上任何一项为“是”先做一次笔记外置和上下文重组再继续跑长任务。8. 把长任务记忆外置固化到你的工作流TaoToken 发 Key 之后Claude Code、Codex、CC Switch 都只是入口。真正决定 ReAct 长任务稳定性的是每一轮 TAO 之后你有没有做信息卸载。Structured Note-Taking 不复杂四个抽屉、两个触发条件、一个每轮重组函数。把它固化到项目里Agent 就不会在第 30 轮忘记第 1 轮的规则。如果你还没有 Key可以先从 TaoToken 官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentreact_notes_cta进入控制台创建。下面这条路径按顺序走一遍先和模型对话验证基础连通https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentreact_notes_chat需要长期跑 Coding 任务看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentreact_notes_coding创建 API Key填到 Claude Code、Codex 或 CC Switchhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentreact_notes_keysClaude Code 的具体接入文档https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentreact_notes_claudecodeBase URL 始终是https://taotoken.net/apiKey 占位符YOUR_API_KEY把这两个值配好再把四类笔记模板放进.agent/notes/你的 ReAct 长任务就从“跑到一半开始漂移”变成“上下文重置后还能接着干”。
TaoToken 发 Key 后，ReAct 长任务怎么用 Structured Note-Taking 卸载历史
1. TaoToken 发 Key 后ReAct 长任务为什么先崩在上下文如果你已经在 TaoToken 官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentreact_notes_intro拿到 API Key并且把 Claude Code 的ANTHROPIC_BASE_URL指向https://taotoken.net/api那么接下来最容易踩的坑往往不是模型选型而是 ReAct 长任务跑到二三十轮之后Agent 开始忽略最初设定的规则。典型症状第 1 轮明确要求“错误变量统一命名为 err、函数不超过 50 行、变量用 camelCase”第 10 轮还遵守第 30 轮开始生成snake_case第 40 轮连错误处理风格都混了。你去看日志模型没有报错工具调用也成功但输出质量就是持续下滑。这不是模型突然变笨而是 ReAct 循环的“只进不出”结构在作祟。ReAct 定义了「Thought → Action → Observation」的闭环模型先思考再调用工具然后读取工具返回结果。这个循环解决了“让 LLM 动手做事”的问题却没有规定“做完之后旧信息怎么处理”。每一轮 TAO 都会往上下文里追加新内容Observation 尤其占空间一次文件读取、一次测试输出、一次编译日志轻轻松松就是几千 Token。上下文窗口再大也扛不住几十轮这样堆。所以TaoToken 发 Key 只是让模型能稳定调用真正的长任务稳定性要看上下文管理。本文给出一套可复现的做法用 Structured Note-Taking 把历史“卸载”到上下文窗口之外让 Agent 只保留当前决策真正需要的信息。文末会给出四类笔记模板和 Token 走势对照你可以直接套到自己的 Claude Code、Codex 或 CC Switch 工作流里。1.1 先区分ReAct 解决行动Context Engineering 解决信息供给ReAct 关注“下一步做什么”Context Engineering 关注“模型此刻看到什么”。两者不是替代关系。没有 ReActAgent 无法调用工具没有 Context EngineeringAgent 能在短任务里跑通但在长任务里会慢性退化。退化路径通常是这样Observation 越积越多有用信号被稀释系统指令被从开头挤到中间模型对它的注意力下降失败调用和错误日志留在历史里污染后续推理Thought 冗余积累消耗 Token 预算却不提供新信息。这四步合起来就是“Agent 用久了越来越差”的根因。2. 先把钥匙接对Claude Code、Codex、CC Switch 的 TaoToken 配置在讲笔记外置之前先把 TaoToken 接进常用工具。入口是 TaoToken 官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentreact_notes_config在控制台创建 API Key然后统一把 Base URL 设为https://taotoken.net/apiKey 在配置里先用占位符YOUR_API_KEY不要把真实 Key 提交到 Git。2.1 Claude Codesettings.json 与 ANTHROPIC_*Claude Code 推荐在~/.claude/settings.json或项目级.claude/settings.json里写入环境变量{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY } }如果你的 Claude Code 版本使用ANTHROPIC_API_KEY也可以按本地文档替换字段名但核心不变Base URL 指向 TaoToken 的 API 地址。保存后重启 Claude Code让它重新读取配置。2.2 Codexconfig.toml 不要混用 ANTHROPIC_*Codex 使用 TOML 配置路径通常是~/.codex/config.toml。它的 provider 配置和 Claude Code 完全不同千万不要把ANTHROPIC_*写进 Codex 的配置里。一个最小化示例如下# ~/.codex/config.toml model_provider taotoken model YOUR_MODEL_ID [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY然后在 shell 里设置export TAOTOKEN_API_KEYYOUR_API_KEY如果你使用的 Codex 版本字段名不同以本地config.toml的 provider 说明为准但必须保证两件事base_url 是https://taotoken.net/api且不要出现ANTHROPIC_*。2.3 CC Switch 三件套供应商、模型、密钥CC Switch 用来在多个供应商之间切换。接入 TaoToken 时把它当成三件套来配置供应商Provider新增一个 TaoToken模型Model填入你在 TaoToken 控制台可用的模型 ID密钥API Key填入YOUR_API_KEY。Base URL 一栏填https://taotoken.net/api。配置完后先跑一个短对话验证连通再进入长任务。短对话都失败就不要急着上 ReAct。3. ReAct 的 Token 走势无笔记 vs 有笔记的对照要理解 Structured Note-Taking 的价值先看 Token 走势。下面是一个 50 轮代码重构任务的估算。假设每轮 TAO 产生Thought 约 200 TokenAction 约 150 TokenObservation 约 1,200 Token。无笔记时所有内容都留在上下文里有笔记时每 3 轮把 Observation 和旧 Thought 卸载到外部笔记上下文只保留系统提示、最近 2 轮原始对话、四类笔记摘要和当前任务状态。轮次无笔记累计 Token有笔记活跃 Token外置笔记 Token01,5001,50001018,0004,5006,0002036,0006,20012,0003058,0007,80019,0004082,0009,10026,00050108,00010,50033,000这张表不是精确基准而是一个工程估算模型。它要说明的是无笔记时上下文活跃 Token 随轮次线性膨胀有笔记时活跃 Token 被压在一个相对平缓的区间外置笔记虽然也在增长但它不在上下文窗口里只在需要时按需读取。3.1 为什么 Observation 是最大污染源Observation 是工具返回结果它天然不可控。读一个文件可能返回 3,000 Token跑一次测试可能返回 2,000 Token一次编译错误日志可能返回 1,500 Token。这些内容在当轮有用但下一轮就不一定需要完整保留。无笔记时它们全部留在历史里把系统指令和关键决策挤到中间。模型对中间位置内容的注意力本来就弱规则漂移就发生了。3.2 错误轨迹污染比想象中更隐蔽工具调用失败、超时、格式解析错误都是常态。ReAct 的容错机制会让 Agent 重试但失败的 Thought 和错误 Observation 也留在历史里。一旦一条错误信息进入上下文它可能影响后面多轮推理。你以为 Agent 在重新尝试实际上它在被之前的错误轨迹带偏。把错误日志卸载到笔记的“发现”或“问题”区只把结论放回上下文可以显著减少这种污染。4. Structured Note-Taking 的四个抽屉可复制模板Structured Note-Taking 的核心动作是把关键信息主动写到上下文窗口之外需要时再读回来。不要只写一个notes.md按用途拆成四个抽屉Agent 找信息更快人排查也更清晰。推荐目录结构project/ .agent/ notes/ progress.md decisions.md findings.md strategy.md state.json4.1 进度笔记Progress Notes记录已经完成什么、还没做什么。它回答“任务走到哪了”。# Progress Notes ## 已完成 - [x] auth_service.go 认证逻辑重构 - [x] 移除 session 依赖 - [x] 补充 JWT 单元测试 ## 进行中 - [ ] order_service.go 拆分订单校验逻辑 ## 待处理 - [ ] payment_service.go 错误处理统一 - [ ] 全量回归测试4.2 决策笔记Decision Notes记录为什么这样选避免后续 Agent 推翻已经过论证的方案。# Decision Notes ## D-001 选择 JWT 而非 Session - 原因服务无状态需要水平扩展 - 影响auth_service 不再写本地 session - 状态已确认 ## D-002 错误变量统一命名为 err - 原因团队规范便于 grep - 例外导出错误使用 ErrXxx - 状态已确认4.3 发现笔记Finding Notes记录过程中发现的重要事实、冗余调用、隐藏依赖。# Finding Notes ## F-001 payment_service 重复调用 auth_service - 现象每个请求调用 3 次认证 - 影响延迟增加日志重复 - 建议合并为一次调用并缓存结果 ## F-002 order_service 存在未处理 panic - 位置order_service.go:142 - 触发条件空订单 ID - 建议增加校验并返回错误4.4 策略笔记Strategy Notes记录下一步怎么做让 Agent 在上下文重置后能快速恢复执行方向。# Strategy Notes ## 当前优先级 1. 修复 payment_service 冗余认证调用 2. 处理 order_service 的 panic 3. 统一 error handling 风格 4. 跑回归测试 ## 约束 - 不改变对外 API - 每个 PR 不超过 300 行4.5 写入触发条件不要每轮都写也不要等上下文满了才写。推荐两个触发条件每 3 轮 TAO 循环后强制写一次进度和发现当上下文活跃 Token 超过预算的 60% 时触发一次全量整理。写入时只写结论不写原始日志。原始日志可以留在.agent/logs/里但不要自动塞回上下文。5. 把笔记接回 ReAct每轮上下文重组算法笔记写完之后关键是“怎么读回来”。每轮调用 LLM 之前不要直接把全部历史拼进去而是重组上下文。一个可用的结构如下def build_context(system_prompt, recent_turns, notes, task_state): return f {system_prompt} ## 当前任务状态 {task_state} ## 进度摘要 {notes[progress][-400:]} ## 关键决策 {notes[decisions][-400:]} ## 重要发现 {notes[findings][-400:]} ## 下一步策略 {notes[strategy][-400:]} ## 最近原始对话 {recent_turns} 这里的recent_turns只保留最近 2 轮原始 TAO。更早的内容已经被压缩成上面四个摘要。调用时把build_context的结果作为新的输入而不是把整个history列表直接丢进去。5.1 上下文预算分配表以 32K 上下文窗口为例可以这样分配区域预算说明System Prompt2,000角色、原则、工具使用规则当前任务状态500当前文件、阶段、约束四类笔记摘要1,600每类 400 Token 左右最近 2 轮原始 TAO3,000保留最新细节工具定义1,500只保留必要工具输出预留4,000给模型回答和工具调用缓冲19,400应对突发长 Observation如果某一轮 Observation 特别长不要直接塞进上下文先写入外置笔记再在上下文里放一句摘要“已读取 order_service.go发现 3 个问题详见 Finding Notes F-003。”5.2 读取策略按需读取不全量加载笔记文件可能越来越大不要每次把四个文件全部读进来。可以按当前阶段选择刚进入任务读 progress strategy做技术选型读 decisions排查 bug读 findings上下文重置后读 progress strategy再按需读 findings。如果笔记超过 2,000 Token先让模型做一次摘要再放进上下文。6. 实战50 轮代码重构任务的 Token 走势与修复动作假设你在用 Claude Code 做 Go 代码重构任务包括认证、订单、支付三个服务。第 1 轮系统指令要求变量用 camelCase、错误变量用 err、函数不超过 50 行。前 10 轮顺利第 20 轮开始偶尔出现snake_case第 30 轮错误处理风格混用。用 Token 走势看无笔记第 10 轮 18K第 20 轮 36K第 30 轮 58K第 40 轮 82K第 50 轮 108K。系统指令早已被挤出开头。有笔记第 10 轮活跃 4.5K第 20 轮 6.2K第 30 轮 7.8K第 40 轮 9.1K第 50 轮 10.5K。外置笔记增长到 33K但不在上下文里。修复动作把前 20 轮的 Observation 全部卸载到.agent/notes/findings.md上下文只留“已读取文件清单 关键发现编号”把 Thought 压缩成决策和策略不再保留完整推理过程把失败的工具调用日志移到.agent/logs/errors.log只在发现笔记里保留“某接口曾超时已重试成功”每 3 轮重新注入一次系统指令摘要放在用户消息结尾利用近因效应。执行后第 50 轮的活跃 Token 从 108K 降到 10.5K 左右Agent 对命名规范的遵守度明显回升。6.1 一个可复制的扫描脚本下面的脚本可以帮你统计本地笔记和日志的体积判断哪些内容不该留在上下文里#!/usr/bin/env bash NOTES_DIR.agent/notes LOGS_DIR.agent/logs echo notes tokens estimate for f in $NOTES_DIR/*.md; do [ -f $f ] || continue chars$(wc -c $f) echo $f: ~$((chars / 4)) tokens done echo logs size du -sh $LOGS_DIR 2/dev/null || echo no logs dir这个脚本只做本地统计不连接任何生产库也不调用外部 API。你可以按项目实际情况调整路径。7. 常见反模式与排障清单7.1 反模式一笔记只写不读Agent 把笔记写得很勤但每轮上下文重组时没有读回来。结果是笔记在磁盘上Agent 还是“失忆”。修复在build_context里固定加入四类笔记摘要并限制每类 400 Token。7.2 反模式二笔记变成第二个上下文把原始日志、完整文件内容、全部工具返回都写进笔记然后每次全量读回。这等于把上下文膨胀从内存搬到了磁盘但读回来时又膨胀了一次。修复笔记只写结论、决策、发现和下一步原始内容另存日志按需读取。7.3 反模式三系统指令只放开头系统指令一直放在开头随着上下文增长被挤到中间。修复每 5 到 10 轮在用户消息结尾重新放一段“当前必须遵守的规则摘要”利用近因效应。7.4 反模式四工具定义过多工具定义本身占 Token功能重叠的工具还会让模型选错。修复每个阶段只保留必要工具工具描述写清“适用场景”和“不适用场景”。7.5 排障清单上下文活跃 Token 是否超过预算 60%最近 3 轮是否包含超过 2,000 Token 的 Observation系统指令是否还在开头 20% 的位置笔记摘要是否每轮都读回失败调用日志是否还在上下文里工具定义是否超过 1,500 Token如果以上任何一项为“是”先做一次笔记外置和上下文重组再继续跑长任务。8. 把长任务记忆外置固化到你的工作流TaoToken 发 Key 之后Claude Code、Codex、CC Switch 都只是入口。真正决定 ReAct 长任务稳定性的是每一轮 TAO 之后你有没有做信息卸载。Structured Note-Taking 不复杂四个抽屉、两个触发条件、一个每轮重组函数。把它固化到项目里Agent 就不会在第 30 轮忘记第 1 轮的规则。如果你还没有 Key可以先从 TaoToken 官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentreact_notes_cta进入控制台创建。下面这条路径按顺序走一遍先和模型对话验证基础连通https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentreact_notes_chat需要长期跑 Coding 任务看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentreact_notes_coding创建 API Key填到 Claude Code、Codex 或 CC Switchhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentreact_notes_keysClaude Code 的具体接入文档https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentreact_notes_claudecodeBase URL 始终是https://taotoken.net/apiKey 占位符YOUR_API_KEY把这两个值配好再把四类笔记模板放进.agent/notes/你的 ReAct 长任务就从“跑到一半开始漂移”变成“上下文重置后还能接着干”。
