τ2-Bench 复现报错？TaoToken 这样改 Codex 的 Base URL

1. 复现 τ2-Bench 卡在 401先把模型通道理顺再谈记忆唤醒复现 proactive-memory-agent 论文时τ2-Bench 的 278 条对话任务一条都还没跑完Codex 先给我刷了满屏 401。当时仓库 docs 目录里 Terminal-Bench 2.0 和 τ2-Bench 的环境都按步骤装好了评测脚本一行没改数据加载也正常问题出在更底层的地方模型通道没通。后来我把 Codex 的 Base URL 指到 TaoToken 就稳了——先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建 Key再改 Codex 的配置文件评测脚本继续在本地跑记忆注入前后的对照全部走同一条通道。这个问题其实很好认报错停在模型请求那一步不是任务校验失败也不是评测脚本崩溃。τ2-Bench 的数据集分布在航空、零售、电信三个领域任务里到处是动态环境规则比如用户自称金卡但系统查询是普通会员、低价经济舱不允许改签这类约束。评测脚本本身只负责构造对话、收集动作、校验结果它不持有 API Key也不会替 Codex 调用模型。真正跟模型服务打交道的是执行智能体这一层Codex 拿着默认配置去找官方接口Key 对不上自然 401。所以复现时不要动 τ2-Bench 源码也不要怀疑记忆模块的注入逻辑。先把「数据与评测」「执行智能体」「模型通道」这三层分清楚然后把通道接到一个稳定的 Base URL 上。TaoToken 在这里只承担模型通道这一件事它不碰你的评测脚本不碰 Docker 容器更不碰任务数据集。1.1 三个角色各管什么τ2-Bench 的复现脚本里三个角色是解耦的。首先是评测框架本身。它跑在你本地负责加载航空 50 条、零售 114 条、电信 114 条任务模拟用户交互把观测文本喂给执行智能体最后根据任务定义校验结果。其次是执行智能体。论文里用的是 Claude Sonnet 4.5 或 Claude Opus 4.6复现时换成 Codex 完全可行因为它本质上是个对话式工具交互智能体读任务、发工具调用、拿返回结果。Codex 在执行环节只负责生成下一步的命令或回复真正运行命令的是评测框架模拟出的终端环境。最后是模型通道。Codex 每次要生成回复都得把上下文发给模型服务这个服务的地址就是 Base URL鉴权凭证就是 API Key。通道不通前面两层准备得再好也白搭。后面我所有的改动都只落在这第三层。2. 复现之前先理解行为状态衰减原文讨论的核心问题叫「行为状态衰减」长时序任务里决策相关信息随着交互轨迹不断累积虽然仍然存在于上下文窗口内却越来越难以约束后续动作。你可以把它想象成一张工作台早期任务约束的纸条被后来的工具输出、日志、报错一层层压住。纸条还在桌上但你动手时总想不起去翻它。论文给了三个典型表现调试到后期完全违背早期明确过的任务约束某条命令或某个参数配置已经验证多次无效后续仍然重复同类操作明明已经定位过错误根源换个场景又把它当成全新故障处理。原文认为这跟「记不记得住」是两回事更准确地说是「该唤醒的时候没有唤醒」。这个区分很关键因为主流记忆方案大多聚焦存储和检索。MemGPT、MemoryBank、Mem0 这类框架擅长跨会话保存信息把历史内容写进向量库等需要时再召回。但长时序单任务场景里问题往往不是找不到信息而是智能体不知道此刻该唤醒哪一条。向量检索能召回字面上相似的内容却判断不了「这个约束是否正在被违反」「这次失败是否和半小时前那次是同一个原因」。2.1 三层记忆库与双阶段流程原文的主动记忆智能体是独立于执行智能体的并行模块双阶段工作。阶段一是记忆库维护。记忆智能体定期读取滑动窗口内的近期轨迹更新三层结构化记忆库。状态字段记录任务进度、未解决风险和开放子目标这部分只对记忆智能体自己可见不注入执行器避免上下文冗余。知识记忆保存静态信息比如任务硬性约束、文件路径、环境事实。过程记忆保存动态经验比如失败过的命令、验证有效的修复方案、错误模式。更新动作通过 memory_update_status、memory_save_knowledge、memory_save_procedural、memory_delete 这四个工具完成。阶段二是主动干预决策。记忆智能体读完最新记忆库输出二选一的结果要么给出一段精简记忆提示注入下一轮执行要么保持静默。注入的提示严格限制为「能改变下一步决策的关键历史内容」比如任务约束、失败诊断、环境事实不给宽泛的解题策略。静默也是显式决策不是没话说而是判断当前不需要打扰执行器。默认触发规则是第 1 交互步必跑之后每 N 步触发一次滑动窗口 k8。复现时这些参数在脚本里都有对应开关保持默认即可。2.2 复现时双模型都会走同一条通道论文实验里有两个模型角色执行智能体和记忆智能体。默认配置下记忆智能体用 Claude Opus 4.6执行智能体可以换成弱一些的基线模型。复现仓库的 scripts 目录通常会让你通过环境变量或配置文件分别指定两个模型的 ID 和 Key。这里就是我第一次翻车的地方我只改了执行模型的通道配置记忆智能体的请求还指向官方通道。结果前面几十条对话正常跑到记忆智能体第一次启动时突然 401。因为记忆模块是隔 N 步才唤醒一次报错出现得晚很容易让人误以为是任务跑到中途出的数据问题。可靠的做法是执行模型和记忆模型都走同一条 Base URL用同一把 Key模型 ID 以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场当时列表为准。这样基线和加记忆模块两个对比组走的是完全相同的网络链路变量只剩记忆模块本身。3. 把 Codex 的 Base URL 指到 TaoToken3.1 在官网创建 Key 并确认模型 ID打开 TaoToken 注册并进入控制台创建一把 API Key记下来当作 YOUR_API_KEY。同时去模型广场确认你要用的模型 ID不要凭记忆猜名字页面显示什么就填什么。TaoToken 在这里的角色是统一 API 通道Codex 把请求发到它提供的 Base URL它负责路由到对应模型并返回结果。它不承担评测逻辑也不参与 τ2-Bench 的任务调度。3.2 修改 ~/.codex/config.tomlCodex 的模型通道配置在~/.codex/config.toml通过model_provider指定提供方。注意 Codex 不需要配 ANTHROPIC_* 那一组环境变量那是 Claude Code 的用法。一个可用的最小配置如下model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken 统一接入 base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY然后在运行评测脚本的终端里导出 Keyexport TAOTOKEN_API_KEYYOUR_API_KEY提示官网落地页只用来注册、创建 Key、看模型广场和用量填进 Codex 的一定是接口地址 https://taotoken.net/api末尾不要加 /v1也不要填成官网首页。改了配置后先重启 Codex 会话再跑评测避免旧进程还占着旧的 Base URL。不同 Codex 版本的字段名可能略有差异以你安装版本的实际说明为准但base_url和env_key这两个字段是所有版本共用的核心。3.3 不要在评测脚本里写死 Keyτ2-Bench 的复现脚本通常从终端环境变量读取模型配置这比把 Key 硬编码进 Python 文件安全得多。评测脚本要提交到 git 时Key 不会跟着进版本库。每次新开终端窗口先export TAOTOKEN_API_KEYYOUR_API_KEY再跑评测避免因为环境变量丢失而复现出诡异的鉴权失败。4. 按论文实验节奏跑 278 条任务原文主实验在 τ2-Bench 上报告的数字是Sonnet 4.5 基线加权平均 55.0%加记忆模块后 61.8%提升 6.8 个百分点Opus 4.6 从 66.2% 提升到 68.7%提升 2.5 个百分点。复现的目标不是一比一复刻数值而是验证同一个记忆机制在你的环境里是否带来一致的增益趋势。通道稳定是一切对比的前提。4.1 先跑一条再放开全量拿航空领域第一条任务做连通性测试。Codex 配置好 TaoToken 后先单独跑这一条确认评测脚本能完整走完「任务下发 → 模型响应 → 工具执行 → 结果校验」这一圈。通过后再放开全量 278 条。全量评测耗时很长如果通道配置有误跑到一半才发现就浪费一整轮时间。单条测试能快速暴露三个问题Key 是否有效、模型 ID 是否正确、Base URL 是否被加上了多余后缀。单条通过后批量跑的时候把日志输出到文件方便事后定位哪些任务出现偶发超时。4.2 基线组和记忆组走同一条通道复现对照实验时最容易引入的隐藏变量是通道不一致。比如基线组用了 A 通道加记忆模块后换成 B 通道最后通过率的差异可能来自记忆模块也可能来自两个通道的模型版本差异。正确做法是基线组和记忆组都用https://taotoken.net/api这个 Base URL同一把 Key同一个模型 ID只切换「是否加载主动记忆模块」这个开关。原文强调记忆模块即插即用、不改执行器提示词复现时也要守住这条边界——只改记忆模块的加载与否别的变量全部固定。4.3 消融实验可以挑一组跑论文里做了五组消融包括全记忆库每轮暴露、强制每轮注入、无持久记忆的纯顾问、通用向量检索。这些变体共同指向一个结论结构化的持久记忆库加上选择性静默干预是最优组合。复现时时间有限的话主实验两个组跑完可以先停。想进一步验证原文结论建议加跑一组「全记忆库每轮暴露」它会往上下文里塞入全部历史记忆token 开销大注意力也容易被冲散。这一组最容易暴露通道在长上下文下的稳定性——上下文越长单次请求越慢对通道的超时控制要求越高。拿它当压力测试也很合适。5. 复现现场最容易误判的三个报错5.1 401 UnauthorizedCodex 拿着默认配置或旧 Key 去找模型服务通常直接返回 401。先在终端里确认TAOTOKEN_API_KEY已经 export再检查 config.toml 里env_key写的确实是TAOTOKEN_API_KEY不是别的变量名。如果 Key 还没创建过去官网控制台重新创建一把把配置示例里的 YOUR_API_KEY 替换成真实值。注意YOUR_API_KEY 只是占位符实际填写时一定要换掉。5.2 请求超时评测脚本长时间没有收到模型响应可能不是网络故障而是模型 ID 填了一个模型广场里不存在的名字。Codex 会一直重试或挂起直到超时。去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的模型广场核对当前可用的模型 ID别依赖记忆里某个具体的日期后缀或版本号。超时还有一种常见场景是单条任务上下文过长模型响应变慢可以在评测配置里调低并发、把日志写到文件再观察。5.3 路径多出 /v1很多 API 服务的地址以 /v1 结尾导致不少人习惯性地在 Base URL 后面补一个 /v1。TaoToken 的 Base URL 就是https://taotoken.net/api不需要加 /v1。加了以后路径拼接会变成/api/v1/...匹配不上正确路由返回的往往是 404 而不是 401。排障时先检查这一点它和 Key 无效是最容易混淆的两个原因。把base_url改回https://taotoken.net/api重启 Codex 再试。排查顺序基本固定先确认网络链路通不通再确认 Key 有效最后确认模型 ID 正确。大多数「复现失败」最后都落在这三件事上。把报错原文贴给 Codex 让它分析 config.toml 和日志它能帮你找拼写错误和路径问题但真正执行评测脚本的仍然是你本地的环境Codex 不会替你连上评测机器跑任务运行和回贴都由你来完成。6. 跑通后回控制台对账278 条任务跑完回到 TaoToken 控制台核对调用记录。用量列表会按模型、按时间把这次评测的请求列出来你可以对照任务数量和预期是否一致。这样既能确认 Key 被正常消费也能第一时间发现模型 ID 是否选成了别的型号避免评测跑完才发现数据不可用。如果只想手测一把不再跑全量先在 模型对话 里用同一把 Key 发一条消息确认 Key 和模型 ID 组合正常。后续长期跑评测或批量调模型可以看 Coding Plan 的套餐是否够用新 Key 在 控制台 API Keys 创建如果你同时还要折腾 Claude Code环境变量的对照关系在 接入文档 里写得很清楚。跑通一次 τ2-Bench 主实验之后你会发现主动记忆模块本身不挑通道Base URL 和 Key 一旦稳定基线组和记忆组的对照就能顺利出数。剩下的精力都可以花在观察行为状态衰减到底在哪些任务上出现、注入哪类记忆提示最有效——那才是这篇论文真正值得复现的部分。