AI Coding Token 效率分析：从大盘指标到自动优化
数据源：阿里云日志服务（SLS）+ AgentLoop 评估与经验挖掘
背景
AI Coding 普及之后，几乎每个团队都经历了同一条曲线：先是敞开供应、人人用爽了，然后账单上来了——近一周，一个部门的 AI Coding 就发起了上百万次 LLM 调用，消耗数千亿 token。额度收紧后，同样的活儿得用更少的 token 干完。
好消息是：这些浪费里，绝大部分不是"用得太多"，而是"用得不对"——它们是结构性的、可识别的、可以被自动优化掉的。
本文讲三件事：
- 哪些地方在消耗 token
- AgentLoop 怎么把这些问题评估出来
- 哪些经验可以下沉到 Skill、CLI 和日常评估里
先看账本
近一周样本里，覆盖数百位用户、近三万个 session，总 token 数千亿级。其中 output token 只占总量约 0.35%。换句话说，大部分 token 没花在"模型写代码"，而是花在把历史消息、工具结果、日志、错误和中间状态一轮轮带回模型。
还有一个容易误解的指标是 cache。全局 Cache Read 占 input 约 87%，看起来很好，但 cache 高不等于效率高。如果一个 session 每轮都带着几十万 token 的历史，只产出几百 token，cache 只是让这部分历史便宜一点，并没有解决上下文过大的问题。
所以我们不只看总 token，也看这些指标：
| 指标 | 看什么 |
|---|---|
| output / total | token 里有多少变成了实际产出 |
| input 规模 | 每次调用带了多大的上下文 |
| cache_read / input | 历史上下文是否被复用 |
| context 膨胀率 | session 内 input 是否越滚越大 |
| Cost/Edit | 每次有效编辑背后花了多少 token |
| Observation 大小 | 工具输出有没有变成后续 input 负担 |
| 重复调用 | 是否在没有新证据的情况下原样重试 |
六类明确的浪费
1. 思考税——约 65% 的 token 没花在写代码上
把所有调用按产出大小分桶后，最显眼的是 50-200 和 200-500 两档。这两档通常不是在生成完整代码，而是在做工具选择、短推理、参数组织和下一步决策。
| Output 区间 | 调用量级 | 平均 Input | 总消耗占比 | 投入产出 |
|---|---|---|---|---|
| <50（纯工具路由） | 数万次 | ~30k | ~2% | 极低 |
| 50-200（工具+短文） | 数十万次 | ~150k | ~37% | ⚠️ 最大消耗 |
| 200-500（中等） | 数十万次 | ~150k | ~28% | ⚠️ 第二大 |
| 500-2k（代码片段） | 十余万次 | ~180k | ~22% | 中等 |
| 2k+（大段代码） | 数十万次 | ~350k | ~11% | ✅ 产出最多 |
50-200 和 200-500 合计消耗约 65% token。这里不能简单说"短输出都是浪费"，但可以确认一件事：真正写代码并不贵，贵的是中间无数次"决定下一步做什么"——每一次都要把整段历史重新搬一遍。 我们把它叫"思考税"。
2. Session 拉长后，产出密度下降
session 步数和产出密度的关系很直接：
| 步数区间 | Session 数 | 产出密度 |
|---|---|---|
| 6-15 步 | 数千个 | 1.14% |
| 16-50 步 | 数千个 | 0.81% |
| 51-200 步 | 数千个 | 0.46% |
| 200+ 步 | 上千个 | 0.24% |
6-15 步是比较好的区间。超过 50 步以后，context 膨胀开始明显影响效率；超过 200 步，很多 token 都在携带历史。我们看到过极端 session：近千步，从数万 input 膨胀到数千万 input。
这里不需要一刀切禁止长任务，但应该在 50 步左右提醒：是否需要阶段总结、保存当前结论、拆成新 session 继续。
3. 重复获取已有信息
在"信息复用"评估维度上，约 86% 的被评估用户不达标，平均浪费约 39%——是所有维度里最普遍的短板。在近千个真实会话里，超过半数出现了参数完全相同的重复工具调用。
典型表现：同一文件被反复全文读取（中间根本没改动）；同一条命令原样跑好几遍当"思考草稿纸"。每重复一次，整段上下文就被重新计费一次。
4. 无边界大输出
大 Observation 会把一次工具调用的成本传到后面每一轮。A/B 实验里，未注入 guardrails 的 B 组多产生一次超 100 万字符 的大 find 输出；A 组 Observation 字符数少了近一半。
日志查询不加时间窗、Read 不加行号、列表不加 limit——这类"能拉全量就拉全量"的动作，是 context 膨胀最直接的推手。
5. 盲目探索与空转会话
零产出 session 占 12.4%，平均步数超过 110 步；有产出 session 平均约 60 步。很多零产出并不是快速问答，而是 agent 探索很久之后没有落地。另有约 27% 属于"温和膨胀型"：步数多、产出密度全场最低，不触发告警却在持续"渐进式空转"——是最隐蔽的浪费。
| 信号 | 表现 |
|---|---|
| Read/Edit 比率低 | 低效用户 Edit 比率仅 0.8%-1.2% |
| 连续探索 | 大量 Read -> Read、Grep -> Grep 链式调用，各数万次 |
| 首轮重复读文件 | 部分用户每个 session 首轮读取超过 10 个文件 |
| 超长探索 | 数十个 session 超过 350 步 |
处理方式不是让 agent "再努力找找"，而是接管到固定 workflow：
| 任务类型 | 更合适的 workflow |
|---|---|
| 代码修改 | 搜索定位 → 局部读取 → 最小编辑 → 最小验证 |
| 测试修复 | 失败摘要 → 单测复现 → 单点修复 → 全量验证 |
| 日志/指标排障 | 时间窗 → 过滤条件 → 小样本 → 证据字段 → 结论 |
| 项目理解 | 先召回 Skill / CLAUDE.md / 项目摘要，再补少量局部读取 |
6. 不规划导致效率差 3 倍
重度使用规划工具（TodoWrite / memory / Skill）的用户，平均约 0.5M token/次有效修改；几乎不规划的用户约 1.5M——效率差约 3 倍。规划让 agent"先有清单、再动手"，少走大量回头路。
AgentLoop 怎么解决
AgentLoop 把"发现浪费 → 归因 → 沉淀正确做法 → 注入运行时"做成了一条自动化流水线，由三个能力组成闭环：
① 指标大盘 ② LLM-as-Judge 评估 ③ GT-free 经验挖掘 + 运行时注入
（看见浪费在哪） → （归因：为什么、谁能改） → （把"对的做法"自动变成可注入的经验）
↑ │
└─────────────────── 新一周的真实轨迹 ←──────────────────────┘指标大盘：让浪费可见、可量化
基于 SLS 日志，自动算出每个 Agent、每个模型、每个用户、每个会话的效率画像——思考税占比、cache 命中、上下文膨胀倍数、产出密度、Cost/Edit 等。回答"哪里有浪费、量级多大"。
LLM-as-Judge 评估：把"哪里浪费"升级成"为什么、谁能改"
指标看不到会话内部的因果。AgentLoop 的评估能力用 LLM 当评委，对采样会话逐条、逐维打分：
- 23 个评估维度，覆盖 Agent 执行、用户交互、平台系统三类责任主体
- 强制证据：每一个评分都必须回连到轨迹里的具体 tool call / observation / 输出，不许凭空脑补
- 自动归纳高频反模式，并把优化动作按"该谁改"分好类——用户该补什么、平台该加什么护栏、Agent 该改什么行为
评估结果不是只给一个分数。它要回答：问题主要来自哪里，是信息复用差、输出太大、卡住循环、prompt 模糊，还是任务本身不适合 agent。
GT-free 经验挖掘：自动沉淀正确做法
这是最核心的一环。不需要标准答案、不需要人工标注，只从真实轨迹中自动挖掘高效行为模式：
原始 trace
→ Stage1 可逆事实解析（保留全部证据）
→ Stage2 单条轨迹结构化（规则先行，LLM 补语义）
→ Stage3 跨轨迹聚合（支持度、反例、失败机制）→ 8 类候选经验
→ Stage4 翻译成原子经验 + 严格质量闸门 → 注入运行时几个关键卖点：
- GT-free，真正零标注：只拿真实轨迹当证据，不需要标准答案、不需要人工写好的范例
- 8 类原子经验，按"影响哪个决策点"切分：流程、选工具、工具合约、参数、证据、回答、修复、反模式。颗粒度细，可单独检索、单独组合、单独回测
- 严格质量闸门：必须可执行、有适用边界、有证据、知道什么时候不能用。泛泛而谈的"建议检查一下"一律拦在门外——往 agent 里塞低质量经验本身就会增加 token
- 增量可审计：经验池每次变化都有 add/update/delete 记录，不会越跑越乱
- 越跑越便宜：稳定领域知识沉淀进 Pack，下一轮更多东西用规则就能识别，LLM 调用越来越少
Guardrails A/B 实验
我们做过一次同样本 A/B。A 组读取挖掘出的 engineering-task-execution-guardrails，B 组不读 Skill。两组分析同一个任务、同一份数据。
| 口径 | A（用了经验） vs B（没用） | 节省 |
|---|---|---|
| raw input + output tokens | A 约 97 万 vs B 约 127 万 | −23.4% |
| Observation 字符数 | A 约 120 万 vs B 约 220 万 | −43.9% |
两组都找到了同一个正确答案，综合质量评分打平。差距完全来自行为：B 组甩出了超百万字符的 find 输出；A 组在 Skill 约束下，工具输出明显更收敛。
一句实话：在这个样本上，经验没有让答案更正确（两组都做对了）。它的价值是——用一样好的结论，花明显更少的 token 和工具输出。而这，恰恰就是 token 紧缺时代我们最需要的东西。
部门级 LLM Judge 也给了相近方向：在更大样本里，可避免浪费约 27%。优先动作包括输出截断、高消耗失败熔断、Observation 解读增强、非 LLM 轮询和轻量模型路由建议。
优化手段按责任边界拆分
优化手段最好按责任边界拆开。否则很容易把所有问题都推给"用户要会用"，或者都推给"模型要更便宜"。实际情况是，不同浪费源要落到不同层去处理。
| 层级 | 手段 | 主要处理的问题 |
|---|---|---|
| 系统层 | 大输出硬截断，输出字段化 | Bash、WebFetch、日志查询返回过大 |
| 系统层 | 非 LLM 轮询/等待工具 | 等待和 polling 每次携带完整 context |
| 系统层 | 轻量模型路由建议 | 简单工具选择、空轮询使用重模型 |
| 运行时层 | 长度/膨胀/重试告警 | 长 session、编辑重试、单 turn 工具爆炸 |
| 运行时层 | 高消耗失败熔断 | 高消耗但持续失败、零产出探索 |
| 工具层 | 默认带 limit、时间窗、行范围 | 大 observation、无边界搜索、全量读取 |
| 工具层 | Observation 解读增强 | 把错误、空结果误当事实 |
| 经验层 | 注入工程任务执行 Skill | 搜索读取无边界、验证顺序混乱 |
| 经验层 | active experience recall | 按任务阶段精准召回，不是全量注入 |
| 团队层 | 推广 CLAUDE.md、prompt 模板、轻量规划 | 重复 context building、追问过多 |
| 评估层 | 日常 LLM Judge + 指标画像 | 不知道浪费来自哪里 |
这里有几件事要分清楚：
- AgentLoop 不一定直接执行所有优化。比如模型路由、非 LLM 轮询、工具硬截断，往往要平台或 runtime 配合。AgentLoop 更适合先把证据和收益算出来，再把策略交给对应系统落地。
- Skill 和 workflow 不是为了让 agent 多做步骤，而是让它少绕路。一个好的 Skill 应该告诉 agent：什么时候查、查到什么就停、失败后只改哪个变量、最后怎么验证。
- 优化不能只看 token 是否下降。每次策略上线后，都要同时看成功率、质量分、Observation 大小和最终回答证据链。省 token 但任务失败，不能算有效优化。
落地路径
1. 日常评估
每天或每周抽样真实 session，按 23 维 rubric 看 passrate、浪费机制和高风险 case。同时跟踪 output 分桶、session 步数、Cost/Edit、cache 健康度、大 observation、重复调用等。评估结果按团队、Agent 类型、任务类型分开看。自动化流量和人工使用不要混在一起，否则个人画像会被污染。
2. 运行时提醒
一些规则可以直接前移：
| 触发条件 | 动作 |
|---|---|
| session 超过 50 步 | 提醒阶段总结或拆分 |
| 高消耗且持续失败 | 熔断，总结卡点，请求确认 |
| observation 过大 | 先截断或摘要 |
| 同参工具重复调用 | 要求说明新增证据 |
| 同文件 edit 过多 | 先做错误归因 |
| 单 turn 工具调用过多 | 转批处理或人工确认 |
3. 经验沉淀
AgentLoop 继续从真实 trace 里挖稳定 workflow。通过 active gate 的经验进入 Skill 或 recall projection；表现好的保留，导致退化的 archive。坚持一个原则：经验要短、要有适用条件、要有停止条件。
4. 反馈到端侧
团队侧看大盘和周报；个人侧最好用 CLI 直接拿到自己的建议。用户看到的不是一堆原始指标，而是类似这样的建议：
- 最近 7 天有 18% 的 session 超过 50 步，建议复杂任务中做阶段总结
- 有 6 次大 Observation 来自无边界搜索，建议先
rg定位再按行号读取 - 测试失败后出现无修改重复验证，建议先读失败摘要再 patch
- Cost/Edit 高于团队中位数，主要原因是零产出 session 和重复读取
这样评估结果才会回到日常使用，而不是停在平台报表里。
小结
Token 优化的核心认知：Token 消耗本质上是信息交换的代价。 优化 token 不是"少说话"，而是问对的问题、给对的上下文、走对的路径、把走通的路径固化下来不再花 token 重新"发现"。
必要成本包括复杂代码理解、跨文件修改、最终验证。可以下降的成本主要来自工具路由、上下文膨胀、冷启动、大 observation、自动探索、重复读取、盲目重试和过度委派。
AgentLoop 要做的事情也比较明确：把账算清楚，把浪费机制评出来，把稳定 workflow 挖出来，再通过 Skill、CLI 和运行时提醒放回开发者日常流程。先做到这些，再谈更细的模型路由和平台治理，顺序会更稳。
在线体验
前往 Token 效率分析 Playground 查看实时指标大盘、评估器和评估结果洞察。