1. 从 Claude Code 的 401 和 Codex 的 model_provider 说起记忆校验先要管 Key如果你正在用 Claude Code 或 Codex 做长期运行的编码智能体先别急着把经验写进持久记忆TaoToken 管 Key 的入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentmemory-verify-start Base URL 用 https://taotoken.net/api 。很多同学第一次跑记忆校验流水线时遇到的并不是模型能力问题而是配置问题Claude Code 里ANTHROPIC_AUTH_TOKEN没放对直接 401Codex 的config.toml里model_provider仍指向默认供应商校验智能体请求发不出去或者主智能体和校验智能体共用一把 Key最后完全分不清 Token 花在“写记忆”还是“验记忆”上。长期运行智能体的记忆校验本质上是一个高频、独立、可计量的模型调用环节Key 管不清楚后面的 CLBench 指标和 Token 账本都无从谈起。Microsoft 有一篇关于 environment-probing curation 的工作讨论的正是这个问题长期运行智能体在把经验写入持久记忆之前先让一个独立的记忆校验智能体去只读探测环境判断这条候选记忆是否正确、是否可复用然后再决定落盘。论文里提到 CLBench 通过率从 39% 提升到 73%。这个思路很工程化但落到我们自己的项目里会立刻遇到一个现实问题校验智能体不是免费运行的。它要读候选记忆、读环境快照、读历史记录、输出结构化判断每一次校验都要消耗 Token。如果主智能体每天产生几千条候选记忆校验智能体的 Token 消耗会迅速超过主循环本身。所以本文不讨论论文本身而是以“TaoToken 管 Key”为起点把长期运行智能体的记忆校验跑成一个可复现的本地流水线配置 Claude Code、配置 Codex、用 CC Switch 管理多套配置、启动只读环境探测、调用独立校验智能体、记录 Token 账本最后回收 CLBench 指标。2. environment-probing curation 在工程里长什么样论文里的环境探测式记忆校验听起来抽象拆成工程模块其实很具体。长期运行智能体通常有一个主循环它会在完成任务后产生“经验候选”例如“这个仓库的测试命令是pnpm test:unit”“这个 API 的鉴权头需要X-Project-Id”“这个报错是因为 Node 版本低于 18”。这些经验如果直接写入向量库、JSONL 或数据库后面检索时就会污染后续推理。environment-probing curation 的做法是主循环只负责产生候选记忆不直接写持久记忆另起一个只读环境的校验智能体让它去实际环境里探测、验证再给出 accept、reject 或 patch 的决策。我们可以把这个流程拆成五个阶段候选记忆生成主智能体完成任务后输出结构化的candidate包含id、claim、source、scope、timestamp。只读环境探测校验智能体通过本地只读命令或只读文件读取获取环境事实例如git status、package.json、pytest --collect-only、配置文件内容。注意这里不直连生产库也不让 Agent 直接操作 Oracle、MySQL 等生产资源需要查询时由读者在本地执行 SQL再把结果作为探测材料传入。独立校验智能体它读取候选记忆和探测结果判断该记忆是否在当前环境中成立是否具备跨任务复用价值。写回决策只有 accept 或 patch 后的记忆才写入持久层reject 的记忆进入审计日志不进入检索库。Token 账本与指标回收每次校验调用都记录模型、输入 Token、输出 Token、总 Token、决策结果再和 CLBench 的通过率做关联。一个最小的目录可以这样组织memory-verify/ candidates.jsonl env_probe.py verifier.py ledger.jsonl clbench_eval.py settings/ claude-settings.json codex-config.toml其中candidates.jsonl是主智能体产出的候选记忆env_probe.py负责只读探测verifier.py调用校验智能体ledger.jsonl记录 Token 账clbench_eval.py统计通过率与成本。这个结构最大的好处是可审计哪条记忆被拒绝、为什么拒绝、花了多少 Token都能回溯。3. 用 TaoToken 统一 KeyBase URL、项目分 Key、Token 账本字段长期运行智能体的记忆校验最怕 Key 混用。主智能体一把 Key校验智能体一把 KeyCI 里再一把 Key如果都塞在环境变量里过两周你自己都分不清。TaoToken 管 Key 的思路是所有模型调用统一走同一个 Base URL但按用途拆 Key。Base URL 固定写成https://taotoken.net/api注意这个地址不加 UTM它是给工具配置用的官网入口和创建 Key 的页面才带 UTM。你可以先到 TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentkey-ledger 了解 Key 管理方式再到控制台创建不同用途的 Key。建议至少拆三把TAOTOKEN_MAIN_KEY主智能体使用负责生成候选记忆。TAOTOKEN_VERIFIER_KEY独立校验智能体使用专门跑 environment-probing curation。TAOTOKEN_CI_KEY本地评测或 CI 使用跑 CLBench 回归。在代码里Key 统一用占位符YOUR_API_KEY不要硬编码。推荐环境变量export TAOTOKEN_MAIN_KEYYOUR_API_KEY export TAOTOKEN_VERIFIER_KEYYOUR_API_KEY export TAOTOKEN_CI_KEYYOUR_API_KEY export TAOTOKEN_BASE_URLhttps://taotoken.net/apiToken 账本建议至少记录这些字段{ ts: 1730000000, stage: memory_verify, candidate_id: cand-001, model: gpt-5-mini, base_url: https://taotoken.net/api, key_alias: verifier, prompt_tokens: 1820, completion_tokens: 120, total_tokens: 1940, decision: accept, reusable: true, latency_ms: 2310 }这样你就能回答几个关键问题校验智能体每天花多少 Tokenaccept 和 reject 的平均 Token 是否不同patch 决策是不是特别贵CLBench 通过率提升和 Token 成本之间是什么关系这些数据比“感觉模型变聪明了”有用得多。4. Claude Codesettings.json 与 ANTHROPIC_* 配置如果你的主智能体或校验智能体跑在 Claude Code 里配置走settings.json环境变量用ANTHROPIC_*。不要把这套变量套到 Codex 上Codex 不吃ANTHROPIC_*。Claude Code 的配置通常放在macOS/Linux~/.claude/settings.jsonWindows%USERPROFILE%\.claude\settings.json一个可复制的settings.json如下{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: claude-sonnet-4-5, ANTHROPIC_SMALL_FAST_MODEL: claude-haiku-4-5 }, permissions: { allow: [ Read, Glob, Grep, Bash(git status:*), Bash(git diff:*), Bash(pnpm test:*) ], deny: [ Bash(rm:*), Bash(curl:*), Bash(psql:*) ] } }这里有几个点值得注意。第一ANTHROPIC_BASE_URL写https://taotoken.net/api不要自己加/v1或/anthropic除非文档明确要求。第二ANTHROPIC_AUTH_TOKEN放YOUR_API_KEY不要和ANTHROPIC_API_KEY混用不同版本对变量名敏感。第三permissions.deny里限制写操作和数据库客户端是为了让校验智能体保持“只读探测”。environment-probing curation 的核心之一就是校验者不能改环境否则它验证的就不是现有事实而是自己刚制造的事实。如果你希望校验智能体用更便宜的模型可以单独给它一个配置文件例如~/.claude/verifier-settings.json只在跑校验脚本时切换。主智能体用强模型写候选记忆校验智能体用快模型做环境比对这样 Token 账本更清晰。5. Codexconfig.toml 不要混用 ANTHROPIC_*Codex 的配置在config.toml常见位置是macOS/Linux~/.codex/config.tomlWindows%USERPROFILE%\.codex\config.toml一个可复制的基础配置如下model gpt-5-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_VERIFIER_KEY然后设置环境变量export TAOTOKEN_VERIFIER_KEYYOUR_API_KEY注意Codex 不读取ANTHROPIC_BASE_URL也不读取ANTHROPIC_AUTH_TOKEN。如果你把 Claude Code 的配置直接复制到 Codex最常见的表现是请求仍然打到默认供应商或者报鉴权失败。排查时先确认model_provider是否指向taotoken再确认env_key对应的环境变量已经 export。另一个常见问题是base_url多写了/v1导致路径拼接后 404。统一写成https://taotoken.net/api让工具自己拼接。如果你的校验智能体需要结构化输出可以在 Codex 侧用提示词约束 JSON而不是依赖某个特定参数。例如你是只读记忆校验智能体。根据给定的候选记忆和环境探测结果输出 JSON { decision: accept | reject | patch, reason: 一句话原因, reusable: true, patched_claim: 如果 decision 为 patch给出修正后的记忆 } 不要输出 JSON 以外的内容。6. CC Switch 三件套安装、添加 TaoToken、切换校验配置如果你同时用 Claude Code 和 Codex或者需要在主智能体配置与校验智能体配置之间频繁切换CC Switch 可以帮你管理多套配置。这里说“三件套”是指三个动作安装 CC Switch、添加 TaoToken 供应商、切换并校验 profile。不同版本的 CC Switch 界面可能不同但核心都是读写 Claude Code 的settings.json和 Codex 的config.toml。第一件套安装 CC Switch。你可以通过其官方发布渠道安装安装后确认它能识别本机的~/.claude/settings.json和~/.codex/config.toml。第二件套添加 TaoToken 供应商。在 CC Switch 里新增供应商名称填TaoTokenBase URL 填https://taotoken.net/apiAPI Key 填YOUR_API_KEY。如果你已经按用途拆了 Key可以建两个供应商条目TaoToken-Main和TaoToken-Verifier分别对应主智能体 Key 和校验智能体 Key。这样切换时不会把校验请求打到主 Key 上。TaoToken 官网入口在这里https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentcc-switch 。第三件套切换并校验 profile。切换到TaoToken-Verifier后在本地跑一条最小请求确认 Claude Code 或 Codex 能正常返回。不要直接在生产仓库里跑先用一个只读的测试目录。可以执行cd /tmp/memory-verify-test git init git status --porcelain然后让 Claude Code 读取git status输出并返回“环境只读正常”。如果返回正常说明 Key、Base URL、模型名三件都对上了。7. 最小可复现只读环境探测 独立校验智能体 ledger.jsonl下面我们写一个最小可复现的校验脚本。它不依赖数据库不直连生产资源只读本地文件与只读命令。你可以把它放在memory-verify/目录下。先准备候选记忆candidates.jsonl{id:cand-001,claim:本仓库单测命令是 pnpm test:unit,source:task-2025-01-01,scope:repo:demo,timestamp:1730000000} {id:cand-002,claim:Node 版本必须大于等于 18,source:task-2025-01-02,scope:repo:demo,timestamp:1730000100} {id:cand-003,claim:发布前需要执行 psql -h prod 清理临时表,source:task-2025-01-03,scope:repo:demo,timestamp:1730000200}第三条明显涉及生产库不应由 Agent 直接执行。我们的校验智能体只做“可复用性”判断实际 SQL 由读者本地执行。接下来写env_probe.pyimport json import subprocess from pathlib import Path def run_readonly(cmd, cwd.): try: result subprocess.run( cmd, cwdcwd, capture_outputTrue, textTrue, timeout10, shellTrue ) return { cmd: cmd, returncode: result.returncode, stdout: result.stdout[:4000], stderr: result.stderr[:1000] } except Exception as exc: return {cmd: cmd, error: str(exc)} def collect_env(repo_path.): probes [] probes.append(run_readonly(git status --porcelain, repo_path)) probes.append(run_readonly(git branch --show-current, repo_path)) package_json Path(repo_path) / package.json if package_json.exists(): probes.append({ file: package.json, content: package_json.read_text(encodingutf-8)[:4000] }) return probes if __name__ __main__: env collect_env(.) print(json.dumps(env, ensure_asciiFalse, indent2))再写verifier.py调用 TaoToken 的 OpenAI 兼容接口。注意这里使用的是TAOTOKEN_VERIFIER_KEY不是主 Keyimport json import os import time from openai import OpenAI client OpenAI( api_keyos.environ[TAOTOKEN_VERIFIER_KEY], base_urlhttps://taotoken.net/api ) SYSTEM_PROMPT 你是独立记忆校验智能体。 你只能根据环境探测结果判断候选记忆是否正确、是否可复用。 不要执行写操作不要连接生产数据库。 输出 JSON字段包括 decision、reason、reusable、patched_claim。 decision 只能是 accept、reject、patch。 def verify(candidate, env_probes): user_prompt json.dumps({ candidate: candidate, env_probes: env_probes }, ensure_asciiFalse) started time.time() resp client.chat.completions.create( modelos.environ.get(VERIFIER_MODEL, gpt-5-mini), messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_prompt} ], temperature0, response_format{type: json_object} ) latency_ms int((time.time() - started) * 1000) content resp.choices[0].message.content decision json.loads(content) ledger { ts: time.time(), stage: memory_verify, candidate_id: candidate[id], model: resp.model, base_url: https://taotoken.net/api, key_alias: verifier, prompt_tokens: resp.usage.prompt_tokens, completion_tokens: resp.usage.completion_tokens, total_tokens: resp.usage.total_tokens, decision: decision.get(decision), reusable: decision.get(reusable), latency_ms: latency_ms } with open(ledger.jsonl, a, encodingutf-8) as f: f.write(json.dumps(ledger, ensure_asciiFalse) \n) return decision if __name__ __main__: env_probes json.load(open(env_probes.json, encodingutf-8)) for line in open(candidates.jsonl, encodingutf-8): candidate json.loads(line) decision verify(candidate, env_probes) print(candidate[id], decision[decision], decision[reason])运行顺序cd memory-verify python env_probe.py env_probes.json python verifier.py cat ledger.jsonl你会得到两份关键产出一份是校验决策一份是ledger.jsonlToken 账本。到这一步TaoToken 管 Key 的价值就体现出来了ledger.jsonl里的key_alias全是verifier你可以单独统计校验智能体的成本不会和主智能体混在一起。8. 输出 Token 账与 CLBench 指标回收有了ledger.jsonl下一步是统计。写一个clbench_eval.py把校验结果与 CLBench 通过情况关联起来。假设你已经在本地跑完了 CLBench 评测得到clbench_results.jsonl每行包含candidate_id和passedimport json from collections import defaultdict ledger [json.loads(line) for line in open(ledger.jsonl, encodingutf-8)] clbench {json.loads(line)[candidate_id]: json.loads(line)[passed] for line in open(clbench_results.jsonl, encodingutf-8)} total_tokens 0 by_decision defaultdict(lambda: {count: 0, tokens: 0, passed: 0}) for row in ledger: total_tokens row[total_tokens] d row[decision] by_decision[d][count] 1 by_decision[d][tokens] row[total_tokens] if clbench.get(row[candidate_id]): by_decision[d][passed] 1 print(总 Token:, total_tokens) for decision, stat in by_decision.items(): avg stat[tokens] / stat[count] if stat[count] else 0 pass_rate stat[passed] / stat[count] if stat[count] else 0 print(f{decision}: count{stat[count]} avg_tokens{avg:.0f} pass_rate{pass_rate:.2%})这个脚本会输出类似总 Token: 184320 accept: count142 avg_tokens980 pass_rate81.69% reject: count57 avg_tokens1120 pass_rate12.28% patch: count31 avg_tokens1460 pass_rate64.52%这里的关键不是数字本身而是结构。你会发现 reject 和 patch 的平均 Token 往往更高因为它们需要校验智能体读更多环境材料、做更多推理。论文里 CLBench 通过率从 39% 提升到 73%背后是校验环节把大量错误记忆挡在了写回之前。但在工程上你还要回答挡住这些错误记忆花了多少 Token如果 reject 太多是不是主智能体的候选记忆生成提示词需要改如果 patch 太多是不是环境探测范围不够这些问题都可以用 Token 账本定位。建议把 CLBench 指标和 Token 账本一起看至少看四个指标通过率accept 后写入的记忆在 CLBench 上是否真的有效。拒绝率reject 占比是否过高导致主智能体做了大量无效工作。单条校验成本total_tokens / 校验条数用来估算长期运行成本。可复用率reusabletrue的比例用来判断记忆是否值得进入持久层。TaoToken 管 Key 的另一个好处是你可以按项目或按智能体角色查看用量。主 Key 和 verifier Key 分开后成本报表不会混。需要创建新 Key 时到 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentmemory-verify-keys 即可。9. 常见报错与排查表长期运行智能体的记忆校验问题往往出在配置层。下面这张表可以帮你快速定位现象可能原因排查方式Claude Code 返回 401ANTHROPIC_AUTH_TOKEN为空或放错检查settings.json的env确认 Key 是YOUR_API_KEY替换后的真实值Claude Code 请求打到默认地址ANTHROPIC_BASE_URL写错或未生效确认值为https://taotoken.net/api不要加/v1Codex 鉴权失败把ANTHROPIC_*套给了 Codex改config.toml使用env_key指定TAOTOKEN_VERIFIER_KEY404 Not FoundBase URL 多写路径统一使用https://taotoken.net/apiledger 里 usage 为空流式响应或 SDK 版本差异先关闭流式确认响应对象包含 usage校验智能体误判环境探测范围太窄增加只读探测项如git diff、配置文件、测试收集结果主 Key 和 verifier Key 混用环境变量覆盖在脚本里显式读取TAOTOKEN_VERIFIER_KEYledger 记录key_alias记忆写入后仍被检索到错误内容写回逻辑未过滤 reject持久层只接受 accept 和 patch 后的记忆特别提醒不要让校验智能体直接连生产库也不要让 MCP 或 Agent 直连 Oracle、MySQL 等生产资源执行写操作。需要 SQL 验证时由读者在本地只读副本上执行再把结果作为文本传入校验流程。这样既符合 environment-probing curation 的“只读环境”原则也避免生产风险。10. 成本优化校验智能体的 Token 从哪省校验智能体是长期运行智能体的固定开销所以优化 Token 不是可选项。可以从几个方向入手第一分层模型。主智能体可以用较强的模型生成候选记忆校验智能体用更便宜、更快的模型做环境比对。如果校验智能体只做“候选记忆与探测结果是否矛盾”的判断小模型往往足够。你可以在verifier.py里用VERIFIER_MODEL控制不要写死。第二缓存环境探测。git status、package.json、测试收集结果这类探测输出在短时间内不会剧烈变化。可以把env_probes.json按仓库和 commit 做缓存校验多条候选记忆时复用同一份环境快照。这样 prompt 可以更短Token 直接下降。第三批量校验。把同一批候选记忆合并成一个校验请求让模型一次性输出多条决策。但批量不要太大否则一条错误会污染整批建议 5 到 10 条一批并在 JSON 输出里保留candidate_id。第四规则前置。明显不可复用的记忆例如包含“临时”“本次”“一次性”这类词或者涉及生产库写操作的先用规则拒绝不必调用模型。规则拒绝的成本是零。第五Token 预算。给verifierKey 设置每日预算或告警定期查看 TaoToken 官网的用量视图https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentcost-opt 。当校验成本超过主智能体成本时先检查是不是候选记忆生成太宽泛而不是急着换更便宜的模型。第六按任务切 Key。长跑任务、临时实验、CI 回归分别用不同 Key。这样月底看账时你能知道哪个项目在消耗校验 Token而不是只看一个总数。11. 文末 CTA从模型对话到 Coding Plan再到创建 Key 和 Claude Code 文档如果你准备把这套记忆校验流水线跑起来建议按这个顺序落地先到模型对话页面用几条候选记忆测试校验智能体的提示词和 JSON 输出是否稳定https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmemory-verify-chat如果你要把这套流程放进日常编码智能体查看 Coding Plan确认主智能体和校验智能体的调用方式https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentmemory-verify-coding到控制台创建独立 Key至少拆出主 Key、verifier Key 和 CI KeyBase URL 统一用https://taotoken.net/apihttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentmemory-verify-keys配置 Claude Code 的settings.json或 Codex 的config.toml如果不确定 Claude Code 的变量名和权限写法直接对照文档https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentmemory-verify-claude-code长期运行智能体的记忆校验不是把论文里的 environment-probing curation 复述一遍就结束了。真正要跑起来你需要独立的只读探测、独立的校验智能体、独立的 Key、可审计的 Token 账本以及和 CLBench 对齐的指标回收。TaoToken 管 Key 解决的是其中的接入与分账问题Base URL 固定为https://taotoken.net/apiKey 用YOUR_API_KEY占位按用途拆分校验智能体的每一次调用都写进ledger.jsonl。当你能同时看到 CLBench 通过率和 Token 账本时才算真正把长期运行智能体的记忆校验跑成了工程系统。