我现在越来越依赖 coding agent。写代码、查日志、改脚本、重构小工具，很多事情都会先让模型试一下。
用得越多，那个疑问就越明显：我怎么知道今天拿到的还是昨天那个模型？
这里面有两层担心。第一层是中转商掺水，名字还是那个名字，背后可能已经换了路由、限了能力，或者在高峰期给了一个没那么好的版本。第二层更麻烦：就算我直接用正牌 provider，也不知道它什么时候改了推理预算、缓存策略、限速策略，甚至偷偷把某个模型调得更保守。
这些事很难从外面证明。provider 不会把内部路由和降级策略摊开给用户看。但如果我一直用模型做事，使用记录总会留下一些痕迹：它变慢了没有？失败多了没有？agent 是不是开始绕圈子？同样的项目里，成本是不是突然上去了？
AgentMeter 是从这个问题冒出来的。不是先做了一个工具，再倒过来找一个使用场景；而是我自己一直用模型干活，需要一个东西提醒我：哪个 provider 或 model 最近不太对。
benchmark 回答不了所有问题
公开 benchmark 有用。SWE-bench 把仓库、问题、预期修复和评分方式都固定下来，至少给大家留了一套能对齐的口径。
但我日常用 coding agent 时，遇到的麻烦经常没那么干净：
- 同一个模型今天突然慢很多；
- agent 开始反复修改同一处代码；
- tool call 失败和重试变多；
- 输出变长，成本上去，结果没有更好；
- 换了 provider 之后感觉不对，但很难说清楚到底哪里不对。
benchmark 问的是：这个模型在标准题上能做到什么水平。
我更想知道的是：它今天在我的工作流里有没有掉状态。
不要把日志分数叫智商分
用本地 session 给模型或 provider 打分，听起来很自然，但这里有个坑：JSONL 里能看到的是行为和代价，不是最终语义正确性。
一个 session 调用次数很多，不等于模型差。可能是任务本来就大。输出 token 变多，也不一定是变啰嗦，可能是我让它解释得更细。工具失败更麻烦，失败可能来自权限、环境、命令写错、文件不存在，不能顺手算到模型头上。
所以 AgentMeter 里我更愿意把它叫做 quality risk，而不是 quality score。
它问的是一个窄一点的问题：
在某个 source、project、时间窗口里，这个 provider/model 的风险是不是变高了？
这里的 source 指 AgentMeter 里的本地 agent 会话来源，比如 Codex、Claude Code，或者一个通用 JSONL 目录。它不是代码里的源文件。
这个分数必须带上范围：
1 | provider/model + agent/source + project + time window |
原因也简单。同一个模型放到不同 agent 里，调用策略可能完全不同；同一个 agent 在不同项目里，上下文大小、工具失败率、测试耗时也不同；同一个项目里，大重构和随手问一个小问题，token 和时延也不在一个量级。
把这些混在一起，最后只会得到一个看起来很精确的噪声。
使用记录里能看什么
本地 session 不是语义评分器，但它能留下一些行为证据：
- 模型调用耗时，比如每 1k output tokens 的 P90 延迟；
- 吞吐，尤其是低分位 token/s，用来看慢尾；
- 调用状态，包括模型调用失败、错误和重试；
- token 形态，包括 input、cached input、output、reasoning output、total token 的比例变化；
- 成本形态，比如每 session 成本、每活跃小时成本、每 1k token 成本和缓存节省；
- 缓存行为，比如 cache miss rate 或 cache utilization 的变化；
- 修复压力，比如每 session 模型调用数升高，可能说明 agent 在反复修补；
- 工具调用结果，包括工具失败率、工具耗时和异常 session；
- 项目和 source 身份，用来区分不同 agent、不同本地 source root、不同项目；
- 原始记录，异常行可以回到具体 session、tool call 和 raw source path 检查。
这些信号不能单独证明”模型变笨了”，更不能证明”provider 偷换了模型”。它们能做的是提醒我：这里不太对，值得点进去看。
当前的风险分怎么算
AgentMeter 现在的 model quality risk score 是 0 到 1 的复合风险分。它不是排行榜，只是把几个常见症状放在一起，先把最可疑的 source/model 挑出来。
当前权重大概是这样：
| 信号 | 含义 | 权重 |
|---|---|---|
| 尾部延迟 | 每 1k output tokens 的 P90 或归一化延迟过高 | 24% |
| 低谷吞吐 | P10 或输出吞吐低于预期下沿 | 24% |
| 失败压力 | 模型或工具失败集中在 session 中 | 18% |
| 工具失败率 | 失败 tool call 占比上升 | 10% |
| 缓存未命中 | 未缓存输入占比过高 | 8% |
| 重试压力 | 每 session 模型调用数偏高 | 7% |
| 输出膨胀 | 输出相对输入明显变大 | 5% |
| reasoning 开销 | 隐藏 reasoning 输出相对可见输出偏高 | 4% |
这里的”失败压力”和”工具失败率”不是同一个分母。失败压力看的是失败是否集中压到 session 上；工具失败率看的是失败 tool call 在全部 tool call 中的占比。前者偏会话层，后者偏工具层。
这组权重和阈值只是经验规则，不是真理。后面如果能接入测试结果、人工反馈、patch 接受率，分数应该继续校准。
现在它的用法很简单。看到”风险 0.62”不要急着下结论，先看驱动原因。如果主要来自 P90 延迟翻倍、P10 吞吐下降和失败压力升高，这个解释比单独一个数字有用得多。
我更关心漂移
真实使用记录最大的问题是任务不可控。今天做大重构，明天只让 agent 改一个 typo，指标有波动很正常。
所以这个分数不能只看静态值，还得看同类历史。目前更稳的做法是：
- 当前窗口：过滤范围内最新观测点向前的 24 小时；
- 基线窗口：当前窗口之前的一段历史，比如约 30 天；
- 日级指标：和前 7 个日历日做滚动比较；
- 样本不足、没有 baseline、没有价格、没有 cache 字段时，标成低置信度或不可用，不要顺手当成模型失败。
这样至少能少踩几个坑：一次慢请求不会直接变成 provider 质量结论；新模型刚开始用时，不会因为没有历史就被判退化；缺失字段也不会被偷偷当成 0，制造出虚假的好成绩或坏成绩。
它不是 benchmark 的替代品
我不想把使用记录说成 benchmark 的替代品。它们回答的问题不一样。
SWE-bench 这类 benchmark 的好处是可复现、可横向比较，适合看模型在标准任务上的能力。使用记录的好处是贴近自己的工作流，能看到 prompt、工具调用、本地项目、上下文长度、缓存和 provider 状态混在一起之后的结果。
它也能补上 benchmark 的几个弱点。公开题库可能受训练数据、提示工程或针对性优化影响；私有项目、真实 prompt 和本地工具链不太可能被完整”背题”。单次 benchmark 容易受抽样和随机性影响；使用记录可以按天、项目、source、模型聚合，再看趋势和分位数。benchmark 的任务分布也未必等于自己的项目，而使用记录天然就是自己的项目。
换句话说，benchmark 告诉我”它理论上能不能做”，使用记录告诉我”它今天在我这里有没有掉状态”。
不能越界解释
使用记录的边界也要说清楚。
它不能自动判断最终补丁是否语义正确，除非接入测试结果、代码审查结果或人工反馈。工具失败可能来自环境、权限、命令写错、文件不存在，不一定是模型质量问题。输出变长可能是解释更完整，也可能只是啰嗦，或者 agent 进入了修复循环。reasoning 开销上升可能是任务变难，也可能是 provider 计费或报告方式变了。
所以我更倾向于叫 quality risk。它主要用来排序和 triage：先告诉我该检查哪些模型、哪些 source、哪些项目、哪些 session。
后面还缺结果信号
如果要让”质量分”更接近语义正确率，还需要把结果信号接进来，例如：
- 测试是否通过；
- patch 是否被接受；
- 同一任务是否被反复回滚或重做；
- 人工是否标记为有帮助；
- agent 是否在同一问题上进入长时间修复循环；
- 会话结束后用户是否马上切换模型或 provider 重试。
有了这些标签之后，当前这些操作指标才更适合作为特征，用来校准一个接近”任务成功率”的模型。在那之前，它更像 provider/model 的健康监控。
实际怎么用
日常用起来大概是这样：
- 增量索引本地 agent session。
- 按 source、model、project 和日期范围过滤。
- 先看 Model Health：当前窗口相对历史基线有没有变差。
- 再看 Quality Risk：风险最高的是哪些 source/model，驱动因素是什么。
- 点进异常 session，检查模型调用、tool call、错误、token 和原始来源。
- 只在相似项目、相似任务和相同 agent/source 下横向比较 provider。
- 根据结果调整默认模型、provider 路由、预算、缓存策略，或者决定哪些任务需要人工复核。
这套流程不会给出一个永远正确的排行榜。我更希望它回答一个小一点的问题：今天我还要不要继续信任这个 provider/model 处理这类工作？
最后
我做 AgentMeter 的起点不是”模型评测”这个大词，而是一个很具体的焦虑：我每天都在用模型做事，但我不知道模型供应链什么时候变了。
公开 benchmark 适合看能力上限和横向基准。真实使用记录适合看本地工作流里的稳定性、成本和退化风险。
AgentMeter 想做的事情，就是把 coding agent 已经留下来的本地 session 变成可检查的信号。它不负责证明谁最好，只负责把问题问得更具体：
在我的真实使用里，哪个 provider/model 正在变慢、变贵、变不稳，证据在哪里？
附录：项目链接
- AgentMeter 远程仓库：https://github.com/LyleMi/AgentMeter