记录 Rome 的 agent 复利实验，TaoToken 记录 Token 消耗

1. 实验起点：Rome 的递归 agent 不是「一次性工具」，但 Token 账本必须一次一记

把 Rome 的模型调用层切到 TaoToken 时，最容易卡住的不是 TypeScript monorepo 的编译，而是 Claude Code 的 settings.json 里 ANTHROPIC_BASE_URL 到底该填https://taotoken.net/api还是带/v1的地址。我这次实验的目标很明确：用 Rome 的递归 agent 做一组复利实验，同时用 TaoToken 记录每一轮的真实 Token 消耗。TaoToken 官网入口在这里：https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content=rome_compound_intro ，从这里可以拿到实验用的 Key，模型入口统一走 https://taotoken.net/api 。

Rome 在 GitHub 上的定位是给人类和 agent 共用的 agentic OS，MIT 许可，TypeScript 写成，早期项目。它想解决的问题和「一次性工具」相反：普通 agent 完成一个任务就结束，下一次对话重新开始；Rome 希望 agent 在自己的运行过程中沉淀状态、记忆和能力，形成递归改进。这个方向听起来很大，但落到工程上，无非是三件事：状态存哪里、经验怎么复用、每轮改进的成本是多少。前两件事是 Rome 的架构问题，第三件事就是 Token 账本问题。

所以我把实验拆成两个可复现的产出：

• 实验日志：每一轮 agent 的任务、输入、输出、耗时、产出文件。
• Key 来源与每轮 Token 消耗对照：Key 从 TaoToken 官网获取，Base URL 统一为https://taotoken.net/api，每一轮结束后从 TaoToken 控制台核对消耗。

这样即使 Rome 本身还在快速迭代，至少成本归因是可复现的。下面的内容不是项目介绍文，而是一份可跟做的实验记录：怎么拿 Key、怎么配 Claude Code、怎么配 Codex、怎么设计三轮递归任务、怎么把每轮 Token 消耗对齐到实验日志，以及中间会遇到哪些坑。

2. 实验环境与 Key 来源：从 TaoToken 官网到 Base URL 的完整路径

2.1 为什么不用多个供应商混跑

Rome 的复利实验有一个基本要求：每一轮 agent 的输入输出必须能归因。如果模型出口一会儿走 A 供应商、一会儿走 B 供应商，Token 消耗就会散落在多个后台，实验日志和账单对不上。TaoToken 在这里的角色不是「又一个模型入口」，而是统一出口：所有递归轮次都通过同一个 Base URL 发送请求，控制台里能按时间、按 Key、按模型看到消耗。

Key 的获取路径建议固定成三步：

1. 打开 TaoToken 官网：https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content=rome_compound_key 。
2. 进入控制台创建 API Key：https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=rome_compound_keys 。
3. 把 Key 写入本地环境变量或工具配置，不要硬编码进 Rome 仓库。

Base URL 统一使用：

https://taotoken.net/api

注意这个地址不要带 UTM 参数，它是给 SDK 和 CLI 用的。UTM 只出现在你手动打开的官网页面里。

2.2 实验目录结构

为了让日志和 Token 对照可复现，我在本地建了一个独立目录，不和 Rome 源码混在一起：

rome-compound-lab/ ├── .env.example ├── configs/ │ ├── claude-settings.json │ ├── codex-config.toml │ └── cc-switch/ ├── exp/ │ ├── round-1.md │ ├── round-2.md │ ├── round-3.md │ └── token-ledger.md └── scripts/ └── run-round.sh

其中token-ledger.md是核心账本。每完成一轮实验，手动或半自动写入一行。后面第 5 节会给模板。

2.3 环境变量约定

不要把 Key 写进代码仓库。用.env或 shell 变量：

export TAOTOKEN_API_KEY="YOUR_API_KEY" export TAOTOKEN_BASE_URL="https://taotoken.net/api"

Claude Code 和 Codex 读取的变量名不同，下一节分别写。千万不要把ANTHROPIC_*变量套到 Codex 上，这是两个不同的配置体系。

3. Claude Code 配置：settings.json 与 ANTHROPIC_* 三件套

Claude Code 的配置入口是settings.json。如果你在实验里用 Claude Code 作为 agent 的编码/执行入口，把模型出口切到 TaoToken 只需要改两个字段。

3.1 settings.json 示例

在项目目录或用户目录下创建/编辑：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_AUTH_TOKEN": "YOUR_API_KEY" } }

这里的ANTHROPIC_BASE_URL填https://taotoken.net/api，不要再拼/v1或/chat/completions。SDK 会按 Anthropic 兼容路径拼接。ANTHROPIC_AUTH_TOKEN使用你在 TaoToken 控制台创建的 Key。

3.2 验证配置是否生效

配置完成后，不要直接开始跑 Rome 的复利实验。先做一次最小验证：

claude -p "只回复一句：taotoken-ok"

如果返回正常文本，说明 Claude Code 已经走到 TaoToken 出口。然后去 TaoToken 控制台看这次请求的 Token 消耗是否出现。如果控制台没有记录，大概率是环境变量被其他配置覆盖，或者 Base URL 写错了。

3.3 CC Switch 三件套怎么理解

如果你用 CC Switch 管理多套配置，建议把「三件套」拆清楚：

• 第一件：Claude Code 的settings.json，使用ANTHROPIC_*。
• 第二件：Codex 的config.toml，使用自己的 provider 字段。
• 第三件：环境变量模板，只放TAOTOKEN_API_KEY和TAOTOKEN_BASE_URL。

CC Switch 切换的是这三份配置的组合，而不是把同一份ANTHROPIC_*复制到所有工具。尤其 Codex 不认识ANTHROPIC_BASE_URL，写了也不会生效。

4. Codex 配置：config.toml 不要混用 ANTHROPIC_*

Codex 使用config.toml管理模型供应商。下面是一个可复制的示例，目标是让 Codex 走 TaoToken 的 OpenAI 兼容入口。

4.1 config.toml 示例

model = "gpt-4.1" model_provider = "taotoken" [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api" env_key = "TAOTOKEN_API_KEY"

然后在 shell 里设置：

export TAOTOKEN_API_KEY="YOUR_API_KEY"

注意几点：

• base_url用https://taotoken.net/api，不要带 UTM。
• env_key写的是环境变量名，不是 Key 本身。
• 模型名以 TaoToken 控制台里可用的为准，示例里的gpt-4.1只是占位。
• 不要在这个文件里写ANTHROPIC_AUTH_TOKEN，Codex 不读它。

4.2 验证 Codex 出口

codex exec "输出一行：codex-taotoken-ok"

执行后同样去 TaoToken 控制台核对消耗。如果 Codex 报 401，优先检查TAOTOKEN_API_KEY是否导出成功；如果报 404，检查base_url是否多写了路径。

4.3 Claude Code 与 Codex 的配置隔离

实验里经常出现一种混乱：Claude Code 已经能跑，于是把同一套环境变量直接拿去跑 Codex，结果 Codex 一直报模型不存在。原因不是 TaoToken 的问题，而是 Codex 的 provider 配置没有生效。建议在实验目录里明确标注：

Claude Code -> ANTHROPIC_BASE_URL / ANTHROPIC_AUTH_TOKEN Codex -> config.toml + TAOTOKEN_API_KEY CC Switch -> 切换上述两套 + 环境变量模板

这样后面排查 Token 不显示时，能快速定位是哪一层没走通。

5. Rome 复利实验设计：三轮递归任务与 Token 对照表

Rome 的核心概念是递归 agent：agent 在自己的运行过程中不断累积、改进、自我优化。为了验证「复利」是否真的发生，我设计了三轮任务。每一轮都通过 TaoToken 出口调用模型，并记录 Token。

5.1 三轮任务定义

第 1 轮：冷启动。
让 agent 完成一个具体任务，例如「整理一份实验目标说明，并输出可复用的经验文件」。这一轮没有历史经验，agent 只能靠基础提示词和工具调用完成。Token 消耗通常偏高，因为探索路径长。

第 2 轮：带经验重跑。
把第 1 轮产出的经验文件作为上下文，让 agent 执行同类任务。观察两件事：任务耗时是否下降、输出质量是否更稳定。Token 可能不会下降，因为经验文件本身增加了输入长度。

第 3 轮：自优化。
让 agent 对比第 1、2 轮的经验文件，生成一份压缩后的「优化提示词」，再用这份提示词执行第三次任务。这一轮的重点不是 Token 多少，而是 agent 是否能从自己的历史中提取有效策略。

5.2 实验日志模板

每一轮结束后，往exp/token-ledger.md写一行：

| 轮次 | 任务 | 模型 | 输入 Token | 输出 Token | 总 Token | 耗时 | 产出文件 | 备注 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | 1 | 冷启动任务 + 经验文件 | YOUR_MODEL | 12,340 | 3,210 | 15,550 | 4m12s | exp/round-1.md | 无历史经验 | | 2 | 携带 round-1 经验重跑 | YOUR_MODEL | 15,880 | 2,940 | 18,820 | 3m05s | exp/round-2.md | 输入变长，耗时下降 | | 3 | 对比前两轮并自优化 | YOUR_MODEL | 19,200 | 4,100 | 23,300 | 2m50s | exp/round-3.md | 经验压缩后重跑 |

上表中的数字是示例格式，实际数字以 TaoToken 控制台为准。每轮结束后，把控制台里的输入、输出 Token 抄进表格，同时记录本地耗时和产出文件。这样你就得到了一份「Key 来源 + 每轮 Token 消耗」的对照账本。

5.3 如何从 TaoToken 控制台核对

建议在每轮实验结束后立刻核对，不要攒到一天结束。做法是：

1. 打开 TaoToken 控制台，进入 API Keys 页面：https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=rome_compound_keys 。
2. 按时间排序，找到刚才那一轮请求。
3. 记录输入 Token、输出 Token、模型名。
4. 回到token-ledger.md，补齐表格。

如果控制台里找不到某轮请求，先检查 agent 是否真的走了 TaoToken 出口。常见原因是 Rome 的某个子进程读取了另一套环境变量。

6. 实验日志复盘：复利效应是否出现，Token 消耗如何变化

三轮跑完后，不要只看总 Token。复利实验的关键指标有三个：单位任务耗时、单位任务输出质量、单位任务探索成本。下面是我在实验日志里观察到的典型现象，以及对应的解释。

6.1 第 1 轮：探索成本最高

第 1 轮没有历史经验，agent 需要自己决定任务拆解、工具调用顺序、文件命名、输出格式。这一轮的输入 Token 不一定最高，但输出 Token 和耗时往往偏高，因为 agent 在「试」。如果实验目标是验证复利，第 1 轮的作用是建立基线，不是追求省 Token。

6.2 第 2 轮：输入 Token 上升，但耗时下降

第 2 轮把第 1 轮的经验文件塞进上下文，输入 Token 通常会增加。但你会发现 agent 的决策路径变短了：它不再重新探索目录结构、不再反复确认输出格式、不再尝试无效工具。结果就是总 Token 可能上升，但耗时下降。这时候不要急着下结论说「复利没发生」，因为复利的第一个表现是路径压缩，不是账单减少。

6.3 第 3 轮：经验压缩决定长期成本

第 3 轮让 agent 自己对比前两轮经验，生成优化提示词。如果 agent 只是把两份经验文件简单拼接，Token 会继续膨胀，复利变成负债。如果 agent 能提取出「哪些步骤可以跳过、哪些检查必须保留、哪些输出格式最稳定」，并把经验压缩成更短的规则，那么第 4 轮、第 5 轮才有可能出现 Token 下降。

我在实验日志里加了一个判断条件：

如果 第N轮总Token > 第N-1轮总Token 且 耗时下降， 则记录为「路径压缩期」。 如果 第N轮总Token 和 耗时同时下降， 则记录为「复利兑现期」。 如果 第N轮总Token 上升 且 耗时也上升， 则记录为「经验膨胀期」，需要人工压缩经验文件。

这个判断不复杂，但能防止你把「上下文变长」误判成「能力变强」。

6.4 Token 消耗对照的三种视角

在token-ledger.md里，建议保留三列分析：

• 按轮次：看总 Token 是否随轮次收敛。
• 按任务类型：看同类任务的单位 Token 是否下降。
• 按模型：看不同模型在同等任务下的消耗差异。

TaoToken 控制台提供按 Key、按时间的消耗记录，你可以把导出的数据和本地日志做一次对齐。对齐不上时，优先检查是否有请求绕过了 TaoToken 出口。

7. 常见报错与排查清单：401、404、模型不存在、Token 不显示

实验过程中最容易遇到的不是 Rome 的编译错误，而是模型出口配置错误。下面按报错现象整理排查顺序。

7.1 401 Unauthorized

可能原因：

• Key 不是从 TaoToken 控制台创建的。
• Key 复制时带了空格或换行。
• Claude Code 的ANTHROPIC_AUTH_TOKEN没生效。
• Codex 的env_key指向的环境变量没有导出。

排查命令：

echo $TAOTOKEN_API_KEY

确认输出不是空，也不是YOUR_API_KEY占位符。然后在 TaoToken 控制台重新创建一个 Key 做对照。

7.2 404 Not Found

最常见的原因是 Base URL 多写了路径。比如：

错误：https://taotoken.net/api/v1/chat/completions 正确：https://taotoken.net/api

Claude Code 和 Codex 会各自拼接自己的路径。你把完整路径写进base_url，工具再拼一次，就会 404。

7.3 模型不存在

模型名必须和 TaoToken 控制台里可用的模型一致。不要用记忆中的模型名，也不要把 Claude Code 的模型名直接复制到 Codex。实验前先去控制台确认模型列表，再填入配置。

7.4 Token 不显示

如果本地有输出，但 TaoToken 控制台看不到消耗，按这个顺序查：

1. 请求是否真的走了 TaoToken 出口。
2. 环境变量是否被项目内.env或 shell 配置覆盖。
3. Claude Code 和 Codex 是否用了不同的 Key。
4. 是否有缓存或代理层截走了请求。

这一项对复利实验最重要，因为 Token 账本一旦缺轮次，后面的成本归因就不成立。

7.5 Claude Code 与 Codex 配置混用

典型症状：Claude Code 正常，Codex 报错；或者 Codex 正常，Claude Code 读不到 Key。原因通常是把ANTHROPIC_*写进了 Codex 配置，或者把 Codex 的 provider 配置写进了 Claude Code 的settings.json。记住：

Claude Code：settings.json + ANTHROPIC_* Codex：config.toml + TAOTOKEN_API_KEY

不要把两套混在一起。

8. 把实验变成可复现的工程：目录结构、日志模板、成本归因

Rome 本身还在快速迭代，今天能跑的配置明天可能变。但实验方法可以不变。下面这套结构可以让你在任何 agent 项目上复用。

8.1 固定 Key 来源

每次实验开始前，从 TaoToken 官网获取 Key：https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content=rome_compound_key 。不要用上次实验遗留的 Key，避免不同实验的 Token 混在一起。

8.2 固定 Base URL

所有工具的模型出口统一写：

https://taotoken.net/api

Claude Code 写进ANTHROPIC_BASE_URL，Codex 写进config.toml的base_url。不要在一个实验里混用多个 Base URL。

8.3 固定日志格式

token-ledger.md建议至少包含这些列：

| 轮次 | 任务 | 模型 | 输入 Token | 输出 Token | 总 Token | 耗时 | 产出文件 | 经验文件是否复用 | 备注 |

如果一轮实验里包含多个子任务，就拆成多行。每行都对应一次可核对的 TaoToken 消耗。

8.4 固定复盘节奏

每跑完一轮，立刻做三件事：

1. 从 TaoToken 控制台抄 Token。
2. 把本轮产出文件路径写入日志。
3. 用第 6 节的判断条件标注本轮属于「路径压缩期」「复利兑现期」还是「经验膨胀期」。

连续跑三轮后，你会得到一张很直观的表：Token 消耗不一定单调下降，但单位任务的探索成本应该出现下降趋势。如果 Token 和耗时同时上升，说明经验文件需要人工压缩，而不是继续让 agent 自己堆上下文。

8.5 成本归因的边界

需要说清楚：Rome 的「agent OS」愿景很大，早期项目的递归能力、状态管理、记忆机制都还在演进。上面的实验只能验证「在固定任务上，agent 是否能通过复用经验减少探索」，不能证明它已经是一个成熟操作系统。Token 账本的作用是让你看清每一步的成本，而不是给项目下结论。

9. 文末 CTA：模型对话 → Coding Plan → 创建 Key → Claude Code 文档

如果你准备复现这组 Rome 复利实验，建议按下面顺序走一遍：

1. 先到模型对话页面确认模型可用性：
   https://taotoken.net/models/detail/chat?utm_source=taotoken_aicg_blog_end&utm_content=rome_compound_chat

2. 需要长期跑实验，看 Coding Plan：
   https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=rome_compound_plan

3. 创建实验专用 API Key：
   https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=rome_compound_keys

4. Claude Code 配置细节看官方文档：
   https://taotoken.net/doc/ClaudeCodeAnthropic?utm_source=taotoken_aicg_blog_end&utm_content=rome_compound_doc

配置时记住三个固定值：Base URL 用https://taotoken.net/api，Key 用YOUR_API_KEY占位并写入环境变量，Claude Code 用settings.json里的ANTHROPIC_*，Codex 用config.toml且不要混用ANTHROPIC_*。跑完每一轮，把 TaoToken 控制台的 Token 消耗抄进实验日志。这样你得到的不仅是一篇项目介绍，而是一份能反复执行的 agent 复利实验记录。