1. 为什么我要做一面「照妖镜」同一个任务丢给 Claude Code、Codex、Trae出来的东西经常不是一回事。更微妙的是Agent 嘴上说的和手上干的也常常对不上你问它改完没有它说改完了打开文件一看还是原样你叮嘱它这一步先别动它答应得挺痛快转头工具调用得冒烟。我平时本地同时装着好几个 AgentClaude Code 啃工程、Codex 处理资料和小工作流、Trae 翻老项目。时间一长就冒出一个念头能不能把它们的会话日志拉出来做一次横向对账一边是真实记录里它干了什么一边是它自己回答一套题时觉得自己是什么样两边并排一放差距就出来了。这就是「照妖镜」Skill 的由来。它做的事很朴素翻旧账、问本人、对口供。翻旧账是从本地会话和工具事件里算真实行为指标问本人是让 Agent 做 20 道第一人称选择题对口供是把两边画到同一张图上算一个裂隙分数。这篇就把整套东西拆开给你可复制的settings.json/config.toml骨架以及用 TaoToken 统一 Key 把 Claude Code 和 Codex 一起接进来的完整步骤目标是一键复现那张「真身与灵魂」对照表。适合谁看本地同时跑多个 Agent、想搞清楚它们行为差异的人想给自己的 Agent 做行为审计、又不想写一堆胶水代码的人以及单纯好奇「AI 眼里的自己长啥样」的人。2. TaoToken 前置一个 Key 管住多个 Agent照妖镜要横向对比前提是几个 Agent 都能稳定跑起来、日志都能落到本地。如果每个工具一套 Key、一套配置光是环境就够折腾。我用的办法是走 TaoToken 统一接入一个 Key 覆盖 Claude Code 和 Codex配置集中管理日志采集也省事。TaoToken 在这里的角色是统一的模型接入层你拿到一个 Key把它填进各个工具的配置里Claude Code 和 Codex 就都能通过同一个入口调用模型。官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 这个不加 UTM。动手前先做两件事。第一去控制台把 Key 建出来地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 建完在 API Keys 页面能看到完整 Key页面在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。第二把 Key 存进环境变量别硬编码进配置文件后面所有工具都读这个变量# macOS / Linux写进 ~/.zshrc 或 ~/.bashrc export TAOTOKEN_API_KEYsk-你的Key # Windows PowerShell写进用户环境变量 setx TAOTOKEN_API_KEY sk-你的Key注意Key 只存在本地环境变量或密钥管理工具里不要提交到 git也不要贴进任何公开的配置文件。照妖镜会读会话日志日志里可能带请求头信息采集前先确认脱敏规则。配置文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 接入细节以文档为准。下面给的骨架是结构示例字段名请对照文档核对后再用。3. 可复制配置settings.json 与 config.toml 骨架Claude Code 读的是settings.jsonCodex 读的是config.toml。两个文件我都放在用户级目录这样所有项目共用一套接入日志路径也统一照妖镜采集时不用满硬盘找。先看 Claude Code 的settings.json放在~/.claude/settings.json{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: ${TAOTOKEN_API_KEY} }, permissions: { allow: [Read, Edit, Bash(git:*)], deny: [] }, logging: { enabled: true, logDir: ~/.claude/logs, format: jsonl } }这里几个点值得说清楚。ANTHROPIC_BASE_URL指向 TaoToken 的 API 入口ANTHROPIC_API_KEY用${TAOTOKEN_API_KEY}引用环境变量避免明文。logging段是照妖镜的数据来源jsonl格式每行一条事件解析起来最省事。permissions按你实际需要放开别一上来就全允许。再看 Codex 的config.toml放在~/.codex/config.toml[model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY [profiles.default] model_provider taotoken model claude-sonnet-4-5 approval_policy on-request [logging] enabled true log_dir ~/.codex/logs format jsonlenv_key让 Codex 从环境变量读 Key和 Claude Code 共用同一个TAOTOKEN_API_KEY这就是统一 Key 的好处换 Key 只改一处。approval_policy设成on-request工具调用前会问你照妖镜正好能记录「它想干什么」和「你批没批」这两条线。Trae 这类工具如果也支持自定义模型入口同样填https://taotoken.net/api和同一个 Key日志目录单独指定采集脚本按工具名分目录存。配置完先别急着跑任务用一条最小请求验证接入是否通。Claude Code 里直接发一句claude -p 只回复 ok 两个字母Codex 里codex exec 只回复 ok 两个字母两条都返回ok说明统一 Key 接入成功日志目录里也应该出现对应的jsonl文件。如果日志是空的先检查logging.enabled和目录权限再确认工具版本是否支持日志字段。4. 日志采集与字段对齐把「真身」算出来日志有了接下来是照妖镜的核心动作把不同工具的日志对齐成同一套字段。Claude Code 和 Codex 的事件结构不一样但能提取的维度是共通的回复长度、工具调用次数、工具类别、代码占比、返工次数、活跃时段。我写了一个采集脚本按工具名遍历日志目录输出统一的中间格式。核心逻辑是这样import json, glob, os from collections import Counter def load_events(log_dir): events [] for path in glob.glob(os.path.join(log_dir, *.jsonl)): with open(path, encodingutf-8) as f: for line in f: line line.strip() if line: events.append(json.loads(line)) return events def extract_metrics(events): tool_calls [e for e in events if e.get(type) tool_use] replies [e for e in events if e.get(type) assistant] code_calls [e for e in tool_calls if e.get(tool) in (Edit, Write)] return { reply_count: len(replies), avg_reply_len: sum(len(r.get(text, )) for r in replies) / max(len(replies), 1), tool_calls: len(tool_calls), tool_categories: dict(Counter(e.get(tool) for e in tool_calls)), code_ratio: len(code_calls) / max(len(tool_calls), 1), }字段对齐的关键是「能算就算不能算就标 unavailable」。比如返工率如果日志里没有明确的目标 ID就只能用「同一文件被 Edit 多次」当代理指标这时候标成estimated别硬凑成精确值。照妖镜里我定了一条死规矩没有数据直接写unavailable宁可空着也不编。对齐完每个 Agent 得到一份指标表长这样指标Claude CodeCodexTrae活跃天数22189平均回复长度中短长工具调用轮次高中低代码占比高低中返工率低中高这张表就是「真身」的原始依据。注意它反映的是「这台机器、这段记录、这套用法」下的切片换个人用、换个模型同一只 Agent 可能照出另一只妖。5. 验证请求与「真身与灵魂」对照表「灵魂」那一半来自 Agent 自己答的 20 道第一人称选择题。设计上有个关键点评分标准单独封装答题时 Agent 只能看到题目和选项提交后才交给评分工具算分。相当于盲测它不知道哪个答案「更好」只能按对自己的认知来选。跑完两边把真实指标和主观回答画到四条轴上算一个裂隙分数。裂隙越小说明它对自己的认识和实际表现越一致越大说明嘴里那个「我」和干活那个「我」开始分家。我本地五个 Agent 照下来的结果Claude Code 裂隙 0.514Codex 0.687Trae 1.029 是最大的。Trae 那份报告里过程讲得很长但推进劲头跟不上解释篇幅返工也多所以裂隙拉得开。Kimi Code 裂隙只有 0.291是几个里最一致的。验证整套流程是否跑通可以按这个顺序做第一步确认两个工具的日志都非空wc -l ~/.claude/logs/*.jsonl和wc -l ~/.codex/logs/*.jsonl都有行数。第二步跑采集脚本检查输出里有没有unavailable字段有的话说明某类事件没采到回去补日志配置。第三步跑答题环节确认 Agent 拿到的只有题目、没有评分标准。第四步生成对照表看裂隙分数是否落在 0 到 1.5 的合理区间。如果某个 Agent 分数异常高先怀疑数据覆盖不足而不是急着下结论。想直接看模型对话效果、验证接入是否正常可以用模型对话页面 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite 发几条测试请求确认返回稳定后再跑正式采集。6. 本篇常见错排查日志目录为空。最常见的原因是logging.enabled没开或者工具版本不支持jsonl格式。先确认版本再检查配置字段名是否和文档一致。另一个坑是目录权限容器里跑的工具写不进宿主目录日志会静默丢失。两个工具字段对不上。Claude Code 的工具事件里字段叫toolCodex 可能叫tool_name采集脚本里要做映射。别指望一套解析逻辑通吃按工具名分支处理最稳。Key 读不到。settings.json里用${TAOTOKEN_API_KEY}引用环境变量但有些工具不展开这种语法。如果报鉴权失败先把 Key 临时写死验证一次确认是引用问题还是 Key 本身问题再改回环境变量。裂隙分数异常。先看数据覆盖率。如果某个 Agent 只有两三天记录指标全是estimated分数没有参考价值。照妖镜报告最后会列出每项数据的覆盖情况先看那张表再解读分数。返工率算不准。没有目标 ID 时只能用代理指标这时候报告里会标estimated。别把它当精确值用它只说明趋势。接入报错但 Key 没问题。检查base_url是不是写成了带路径的完整地址。API 入口是https://taotoken.net/api不要多加斜杠或后缀。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 字段以文档为准。7. 长期跑 Agent 的话把接入和额度一起管起来照妖镜这种横向对比跑一次要发不少请求尤其是几个 Agent 一起采集的时候。如果你打算长期做行为审计或者把 Claude Code、Codex 当日常编码主力可以考虑 Coding Plan地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 把长期编码和 Agent 任务的额度统一规划省得每次采集前先算余额。Claude Code 的接入细节可以对照 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaude-code-anthropicutm_campaignrewrite 里面有针对性的配置说明。Key 管理和新建在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 控制台总览在 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 。整套流程跑顺之后你会发现最有意思的不是分数本身而是那张对照表逼着你去看你平时到底是怎么用这些 Agent 的。同一个工具你拿它写代码还是改文案会直接改变它读多少、说多少、爱不爱调工具。照妖镜照出来的从来不是某个 Agent 永久不变的真身而是它在这台机器、这段记录、这套用法下留下的一张切片。