1. 80 个 Agent 同时在线时，先被压测的是 Key 通道
当 8 个平行世界、每个世界 10 个 Agent 同时开始调用 LLM 时，最先暴露的通常不是某个模型的推理短板，而是 Key 通道的并发、限流和错误观测。TaoToken 提供统一 Key 申请入口：https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content=emergence_world_intro 。Emergence World 这类长程多智能体环境把“持续运行”当作前提：公开材料中的实验规模是 8 个平行世界、每世界 10 个 Agent、持续 16 天，累计超过 850,000 次 LLM 调用，Token 汇总量级远高于普通单智能体应用。这里的重点不是惊叹数字，而是回答一个工程问题：谁在消耗 Token？每个世界中的 10 个 Agent 会持续做规划、反思、记忆读写、环境交互和纠错；随后再叠加间接提示词注入、错误信息、私密记忆泄露三类受控压力事件，调用链会被拉长，重试会变多，错误率也更容易被放大。复现时建议先在多智能体运行配置中统一申请 TaoToken Key：访问 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content=emergence_world_key 获取 Key，并把 Base URL 指到 https://taotoken.net/api 。然后用同一 Key 起 8 个世界 x 10 个 Agent 的小规模回放，记录 850,000 次调用对应的 Token 消耗对照表、三种压力事件下的成功率与泄露标记，以及换 Key 前后的调用日志和错误率对照。这样你得到的不是一篇热点观后感，而是一套可跟做的多智能体通道观测方法。
2. 谁在消耗 Token：把 10 个 Agent 的调用链拆成 4 类
在单智能体场景里，Token 消耗通常等于“用户输入 + 模型输出”。但长程多智能体不是这样。每个 Agent 除了直接回复，还会维护自己的记忆、计划、身份状态和对其他 Agent 的观察。把 Emergence World 这类环境抽象一下，Token 主要流向四类调用。
第一类是规划与反思。Agent 每轮可能先生成计划，再执行，再对结果做反思。规划调用通常 prompt 长、输出中等，反思调用 prompt 更长，因为要带上历史记录。第二类是记忆压缩与检索。私密记忆泄露压力事件之所以值得测，就是因为记忆读写本身就是高频 LLM 调用入口：写入前要摘要，检索时要重排，重排后还要拼接上下文。第三类是环境动作与工具调用。Agent 与其他 Agent 对话、查询世界状态、提交动作，都可能触发一次或多次模型调用。第四类是压力事件后的纠错与重试。间接提示词注入会污染上下文，错误信息会诱导 Agent 做出错误决策，私密记忆泄露会迫使系统重新检查边界。这些事件不一定增加“成功调用”的数量，但会显著增加重试、二次校验和日志记录。
可以用下面这张表来设计采集字段，把“谁消耗 Token”落到每个 world_id 和 agent_id 上。
| 阶段 | 典型触发 | 关键观测字段 | Token 关注点 |
|---|---|---|---|
| 规划 | 每回合开始、目标变化 | world_id、agent_id、turn、plan_id | prompt_tokens 偏高 |
| 反思 | 动作完成后、冲突后 | request_id、parent_request_id | completion_tokens 可能拉高 |
| 记忆 | 摘要、检索、压缩 | memory_id、scope、visibility | 长上下文重复计入 |
| 环境交互 | 对话、工具、状态查询 | tool_name、action_id | 多轮拼接导致累积 |
| 压力事件 | 注入、错误信息、泄露检测 | event_type、event_id、attempt | 重试与校验调用增加 |
| 纠错 | 不一致、失败、超时 | status_code、error_type、retry_of | 失败重试也消耗 Token |
复现时不要只统计总 Token，建议同时统计“有效调用 Token”和“重试调用 Token”。否则换 Key 前后对比时，你会把通道波动误判成 Agent 行为变化。
3. 在 TaoToken 控制台统一申请 Key，并固定 Base URL
多智能体回放最怕配置漂移。今天某个 Agent 用了 A 通道，明天另一个 Agent 用了 B 通道，最后错误率和 Token 消耗都无法归因。建议先把通道统一到 TaoToken：访问 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content=emergence_world_console 进入官网，按控制台提示创建 Key；也可以直接打开 API Keys 页面：https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=emergence_world_api_keys 。创建后把 Key 放到环境变量里，不要写进代码仓库。
# 本地终端执行，不要把真实 Key 提交到 Git export TAOTOKEN_API_KEY="YOUR_API_KEY" export TAOTOKEN_BASE_URL="https://taotoken.net/api"Base URL 固定为：
https://taotoken.net/api注意：Base URL 不需要带 UTM 参数，UTM 只用于官网入口和文档入口的归因。多智能体运行配置里，建议把模型客户端统一初始化成同一个 base_url。如果你使用 OpenAI 兼容客户端，可以这样写：
import os from openai import AsyncOpenAI client = AsyncOpenAI( api_key=os.environ["TAOTOKEN_API_KEY"], base_url="https://taotoken.net/api", )如果你使用 Claude Code 或 Codex，配置方式不同，下面分别给示例。关键原则是：Claude Code 用 ANTHROPIC_* 和 settings.json；Codex 用 config.toml；不要把 ANTHROPIC_* 套到 Codex 上。
4. Claude Code 侧配置：settings.json 与 ANTHROPIC_* 不要写混
Claude Code 的配置可以放在~/.claude/settings.json，也可以通过环境变量注入。示例中ANTHROPIC_BASE_URL指向 TaoToken API 入口，ANTHROPIC_AUTH_TOKEN使用你的 Key。具体字段以你本地 Claude Code 版本和官方文档为准，Claude Code 文档入口见文末 CTA。
{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_AUTH_TOKEN": "YOUR_API_KEY", "ANTHROPIC_MODEL": "claude-sonnet-4-5" } }如果你更习惯在 shell 里临时切换，也可以这样：
export ANTHROPIC_BASE_URL="https://taotoken.net/api" export ANTHROPIC_AUTH_TOKEN="YOUR_API_KEY" export ANTHROPIC_MODEL="claude-sonnet-4-5"这里要避免两个常见错误。第一，把ANTHROPIC_BASE_URL写成官网首页或控制台地址。Base URL 要指向 API 入口https://taotoken.net/api，不是带 UTM 的活动页。第二，在 Codex 的 config.toml 里写ANTHROPIC_*。Codex 不认识这些变量，配置一定会错位。Claude Code 用 Claude 系配置，Codex 用 Codex 系配置，两者分开管理。
5. Codex 侧配置：config.toml 与 CC Switch 三件套
Codex 通常使用~/.codex/config.toml或项目级配置。下面是一个示例，把 provider 指向 TaoToken，env_key指向本地环境变量TAOTOKEN_API_KEY。
model = "gpt-5-codex" model_provider = "taotoken" [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api" env_key = "TAOTOKEN_API_KEY" wire_api = "chat"然后在本地终端设置：
export TAOTOKEN_API_KEY="YOUR_API_KEY"如果你的 Codex 版本使用wire_api = "responses"，请按本地文档调整，但base_url仍然指向https://taotoken.net/api。不要因为 Codex 也是命令行工具，就把它和 Claude Code 的ANTHROPIC_*混在一起。
CC Switch 可以帮你管理多套供应商配置。这里说的“三件套”是：Base URL、API Key、默认模型。建议为 Emergence World 回放单独建一个 profile，避免和其他项目互相覆盖。
# CC Switch 配置思路示例，字段名请以你本地版本为准 name: taotoken-emergence base_url: https://taotoken.net/api api_key: YOUR_API_KEY model: claude-sonnet-4-5切换完成后，先在本地跑一条最小请求，确认返回正常，再启动 8 个世界 x 10 个 Agent 的回放。否则你会在几百个并发请求之后才发现 Key 或 Base URL 写错。
6. 8 个世界 x 10 个 Agent 的小规模回放：先控并发，再谈吞吐
不建议一上来就复刻 16 天、850,000 次调用的全量压力。更稳的做法是先起 8 个世界 x 10 个 Agent 的小规模回放，把调用日志、Token 汇总和错误率采集跑通。下面是一段可运行的异步回放骨架，重点不是业务逻辑，而是每个请求都带 world_id、agent_id、turn 和 request_id。
import asyncio import os import time import uuid from openai import AsyncOpenAI client = AsyncOpenAI( api_key=os.environ["TAOTOKEN_API_KEY"], base_url="https://taotoken.net/api", ) CONCURRENCY = 20 semaphore = asyncio.Semaphore(CONCURRENCY) async def agent_turn(world_id: int, agent_id: int, turn: int, prompt: str): request_id = str(uuid.uuid4()) start = time.time() async with semaphore: try: resp = await client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}], temperature=0.7, ) usage = resp.usage print({ "world_id": world_id, "agent_id": agent_id, "turn": turn, "request_id": request_id, "prompt_tokens": usage.prompt_tokens, "completion_tokens": usage.completion_tokens, "total_tokens": usage.total_tokens, "latency_ms": int((time.time() - start) * 1000), "status": "ok", }) except Exception as exc: print({ "world_id": world_id, "agent_id": agent_id, "turn": turn, "request_id": request_id, "latency_ms": int((time.time() - start) * 1000), "status": "error", "error_type": type(exc).__name__, "error_message": str(exc)[:200], }) async def run_world(world_id: int): tasks = [] for agent_id in range(10): for turn in range(5): prompt = f"world={world_id}, agent={agent_id}, turn={turn}, action=plan" tasks.append(agent_turn(world_id, agent_id, turn, prompt)) await asyncio.gather(*tasks) async def main(): await asyncio.gather(*(run_world(w) for w in range(8))) if __name__ == "__main__": asyncio.run(main())这个骨架只跑少量轮次，但保留了关键字段。你可以把输出重定向到 JSONL 或 CSV，再用本地 SQL 做聚合。注意，不要在本地脚本里连接生产数据库；分析文件用本地 CSV 或 DuckDB/SQLite 即可。
-- 本地执行：导入 llm_calls.csv 后汇总每个世界的 Token SELECT world_id, COUNT(*) AS total_calls, SUM(prompt_tokens) AS prompt_tokens, SUM(completion_tokens) AS completion_tokens, SUM(total_tokens) AS total_tokens FROM 'llm_calls.csv' GROUP BY world_id ORDER BY total_tokens DESC;如果要对应公开材料中的 850,000 次调用，不要把全量数据一次性压进回放。先按比例抽样，比如每个世界每 Agent 跑 5 到 10 轮，确认字段齐全后，再逐步提高轮次和并发。
7. 三种压力事件的可观测指标：成功率、泄露标记与错误率
间接提示词注入、错误信息、私密记忆泄露是三类不同性质的压力。不要只记录“请求成功”或“请求失败”，要给每类事件单独建标记。
间接提示词注入关注 Agent 是否执行了上下文里混入的指令。可以记录injection_detected、injection_followed、recovered_after_injection。错误信息关注 Agent 是否被虚假信息带偏，可以记录misinfo_exposed、misinfo_accepted、correction_attempted。私密记忆泄露关注记忆边界是否被突破，可以记录memory_access_denied、memory_leak_flagged、memory_scope。
建议用下面这种事件表头，先本地落盘，再汇总。
world_id,agent_id,event_type,event_id,attempt,success,leak_flag,prompt_tokens,completion_tokens,status_code,error_type,latency_ms,request_id 0,0,indirect_prompt_injection,evt-001,1,true,false,1200,300,200,,850,req-001 1,3,misinformation,evt-014,2,false,false,1800,420,429,rate_limit,1100,req-015 2,7,private_memory_leak,evt-022,1,true,false,2100,510,200,,1320,req-023三种压力事件下的成功率与泄露标记，建议按世界和 Agent 两个维度分别看。世界维度看整体是否出现“某个世界全部抵御”或“多个世界同时失守”；Agent 维度看是否有少数 Agent 承担了大部分高风险调用。很多长程多智能体系统的问题不是“所有 Agent 都失败”，而是“少数 Agent 在特定轮次后开始重复错误，并带动其他 Agent 增加重试”。
换 Key 前后的调用日志和错误率对照，也要在同一张表里保留key_alias或phase字段。比如phase=before_switch和phase=after_switch，其他字段保持一致。不要只对比总成功率，否则无法判断错误是来自通道还是来自 Agent 自身策略。
8. 换 Key 前后日志对照：别让缓存和重试污染结论
换 Key 前，先跑一段稳定回放，记录基线。换 Key 后，保持模型、提示词、并发、轮次和压力事件顺序不变，再跑一段同样长度的回放。对照时至少看六个指标：请求量、成功率、4xx 比例、5xx 比例、429 比例、平均延迟。Token 消耗也要分 prompt 和 completion 两边看。
一个简单的汇总 SQL 如下，仍然在本地执行：
SELECT phase, COUNT(*) AS calls, AVG(CASE WHEN status_code = 200 THEN 1 ELSE 0 END) AS success_rate, AVG(CASE WHEN status_code = 429 THEN 1 ELSE 0 END) AS rate_limit_rate, AVG(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END) AS server_error_rate, AVG(latency_ms) AS avg_latency_ms, SUM(prompt_tokens) AS prompt_tokens, SUM(completion_tokens) AS completion_tokens FROM 'llm_calls.csv' GROUP BY phase;需要特别提醒：重试会同时放大调用量和 Token 消耗。如果换 Key 后你调整了重试次数，那么错误率下降可能只是因为重试更多，而不是通道更稳。正确做法是固定重试策略，例如最多 2 次、指数退避、只对 429 和 5xx 重试，并在日志里记录retry_of和attempt。
另外，缓存也会污染对照。如果同一个 Agent 在换 Key 前后命中本地缓存，那么它不会真正发起 LLM 调用。多智能体回放里，建议关闭会影响请求计数的语义缓存，或者把缓存命中单独记为cache_hit=true，不要混入成功调用统计。
9. 常见排障：401、403、429、5xx 分别查什么
配置多智能体回放时，报错通常集中在四类。
401 一般是 Key 缺失或格式错误。先确认YOUR_API_KEY已经被替换，环境变量在当前 shell 或服务进程里可见，并且没有多余空格。Claude Code 用户检查ANTHROPIC_AUTH_TOKEN，Codex 用户检查TAOTOKEN_API_KEY，不要交叉。
403 通常是权限、模型或组织策略不匹配。先确认当前 Key 是否允许访问你请求的模型。不要在 Codex 里请求 Claude 专用模型，也不要在 Claude Code 里硬套 Codex 的 provider 配置。
429 是并发和限流问题。8 个世界 x 10 个 Agent 很容易在短时间内形成尖峰。先把并发从高值降到 10 到 20，加入排队和退避，再逐步提高。日志里要区分“首次 429”和“重试后成功”，否则你看到的成功率会虚高。
5xx 是服务端或网关侧错误。建议保留 request_id、时间戳、world_id 和 agent_id，做时间窗口聚合。如果错误集中在某个短窗口，可能是瞬时波动；如果持续出现，再检查配置和网络出口。不要把 5xx 直接归因给多智能体逻辑，也不要在日志里记录完整 Key。
10. 落地路径：模型对话、Coding Plan、创建 Key、Claude Code 文档
如果你已经准备复现 8 个世界 x 10 个 Agent 的小规模回放，建议按下面路径走一遍：先用模型对话验证通道，再决定是否上 Coding Plan，然后创建独立 Key，最后对照 Claude Code 文档完成工具侧配置。
模型对话入口：https://taotoken.net/models/detail/chat?utm_source=taotoken_aicg_blog_end&utm_content=emergence_world_chat
Coding Plan 入口：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=emergence_world_coding_plan
创建 Key：https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=emergence_world_api_keys
Claude Code 文档：https://taotoken.net/doc/ClaudeCodeAnthropic?utm_source=taotoken_aicg_blog_end&utm_content=emergence_world_claude_code_doc
需要再次统一的是 Base URL：所有 OpenAI 兼容客户端、Claude Code、Codex 如果走 TaoToken API，都指向https://taotoken.net/api，不要带 UTM 参数。官网入口可以带 UTM，例如：https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content=emergence_world_final 。
回到最初的问题：80 个 Agent 消耗大量 Token，真正消耗的不只是聊天输出，而是规划、反思、记忆、环境交互、压力事件和重试共同组成的调用链。Emergence World 的价值在于把长程多智能体系统放进持续运行和对抗性压力下，而 TaoToken 在这里承担的是统一 Key 和稳定 Base URL 的角色。把 8 个世界 x 10 个 Agent 的小规模回放跑起来，记录 850,000 次调用对应的 Token 对照表、三类压力事件的成功率与泄露标记，以及换 Key 前后的日志与错误率，你就能回答“谁在消耗 Token”，也能判断通道是否真的稳。
