企业把 AI Agent 接进工作流后，账单往往先失去解释：花费涨了，团队却说不清是哪一个 Agent、哪一种模型、哪条请求把成本推高。OpenRouter 8 月 17 日上线的 Activity 仪表盘和测试版 Analytics API，瞄准的正是这道账。
它把用量拆到 agent、模型和单次请求。管理者可以从总花费、请求数、token 用量、缓存命中率、每百万 token 的综合成本五项指标开始，再一路点进具体日志。产品没有承诺替团队省钱；它提供的是能追到责任边界的用量视图。
从总额走到一条请求
OpenRouter 的官方说明列出了可拆分的维度：模型、供应商、API key、应用、用户、工作区、会话、上下文长度和数据区域等。图表既能按分钟、小时、天、周或月汇总，也能下钻到单条生成记录。
进入日志后，一条记录可以显示推理、缓存、网页搜索和文件处理的费用，以及延迟、吞吐、首 token 时间、路由和回退信息。对正在用多模型、多供应商的团队，这些字段把“成本异常”变成可排查的问题：是某个 agent 的系统提示过长，还是缓存前缀被打断，抑或路由切换抬高了延迟。
OpenRouter 的原话很直接：“Every company that spent the last two years deploying agents is now asking the same question: what are they costing us, and which ones are worth it?” 仪表盘的目的就是让这个问题能落到具体应用和请求上。
观察不等于自动管控
产品还提供 Guardrails 视图，用来查看提示注入和敏感信息规则拦截、脱敏或标记的情况；Analytics API 则允许团队把同一套数据接进自己的看板。它们解决的是可见性，不是替企业设定预算或审批规则。
这一区分很重要。Agent 被允许调用工具后，token 成本只是其中一层；工具调用次数、检索范围、文件处理和外部服务延迟都会一起改变实际支出。先把数据按 agent、模型、请求归位，团队才谈得上为高成本任务设限，或判断缓存和路由策略是否有效。
OpenRouter 的更新把 AI 用量分析从一张总账，推进到一条可追溯的流水。对开发负责人来说，下一步要看的不是某个漂亮的汇总图，而是哪些异常请求能被稳定复现、解释和压回预算以内。
参考来源：OpenRouter 产品公告；核验 Activity 仪表盘、Analytics API 与日志字段；CocoLoop。