一个登录页用了 4M token，我让GPT帮我分析了以下，他说主要问题出在每次读取文件的时候，都把之前的缓存重新读一遍； 对，这张图 + 你上传的 JSONL 日志一结合，结论就比较明确了： > 4M token 是真实的累计消耗，但不是“这个登录页生成了 4M token”。主要原因是 Agent 在 53 次左右的模型请求中，反复携带不断增长的上下文。 我把日志实际统计了一下： | 指标 | 实际值 | | ---------------- | --------------------: | | 模型请求数 | 53 次 | | 累计 input tokens | 3,884,017 | | 累计 output tokens | 26,064 | | 累计 total tokens | 3,910,081 ≈ 3.91M | | cache read | 3,710,336 | | Cache 命中率 | 约 95.5% | | 最终上下文 | 约 103K | 所以你截图里的 10.3 万 / 100 万（10.3%） 和日志是对得上的。 ### 真正值得注意的是这个 第一轮大约： > 35K context 后面一路增长： > 36K → 40K → 50K → 60K → 70K → 80K → 90K → 100K → 103K 而且最终有 53 次模型请求。 粗略来看就是： ```text 平均每次请求 ≈ 3.884M / 52 ≈ 74.7K input tokens 也就是说，虽然最终只有 103K context ，但 Agent 实际上把这几十 KB 的上下文 反复发送了几十次 。 这正是： 100K Context ↓ 第 1 次请求 35K 第 2 次请求 36K 第 3 次请求 39K ... 第 50 次请求 101K 第 51 次请求 102K ↓ 累计 ≈ 3.9M 还有一个非常关键的点：95.5% Cache Hit 这个其实是个 好消息 。 日志里： Input 3.884M Cache Read 3.710M Cache Hit ≈95.5% 所以这 3.9M 并不等价于 3.9M 全价 token 。 大部分是之前已经出现过的上下文，被缓存读取了。 换句话说： Token 消耗看起来很大，但实际计费成本可能远低于 3.9M 普通 input token。 具体成本还要看你这个 GLM-5.3-Flash / bigmodel-start-plan 的 cache input 定价。 但我认为这里仍然有一个问题 你的截图里： 消息 60.6% MCP 工具 17.0% 系统工具 16.9% 技能 2.4% 系统提示词 1.6% 其他 1.5% 也就是说最终 103K context 里面： ① 消息占 60.6% 这个不算特别离谱。 随着 Agent 会话越来越长，历史对话自然会增长。 ② MCP + 系统工具占 33.9% 这个反而比较值得关注： 17.0% MCP 16.9% 系统工具 ---------------- 33.9% 将近 1/3 的上下文不是用户需求，也不是代码本身，而是工具定义/工具相关上下文。 如果这是一个简单的登录页任务，这个比例我会觉得偏高。 所以我会这样评价这次 Agent 执行 Token 架构层面 正常。 Agent 本来就是： Context ↓ LLM ↓ Tool ↓ Context 更新 ↓ LLM ↓ Tool ↓ Context 更新 ... 上下文从 35K 增长到 100K，再重复调用几十次，累计达到 4M 非常容易发生。 Agent 效率层面 偏低。 尤其你的任务只是一个登录页。 53 次模型请求实际上已经不少了。 而且一个非常有意思的数据是： 53 次请求只产生了 26K output tokens。 也就是说： Input ≈ 3,884K Output ≈ 26K 输入输出比例大约： 149 : 1 这意味着这个 Agent 的主要 token 消耗 不是“模型写代码写太多” 。 而是： 模型不断重新读取已有上下文。 如果你是在做自己的 Coding Agent，我会特别关注这个指标 我甚至建议你不要单纯统计： Total Tokens = 3.9M 而是拆成： ┌──────────────────────────┐ │ Session Token Efficiency │ ├──────────────────────────┤ │ Context Peak 103K │ │ Cumulative Input 3.88M │ │ Cache Read 3.71M │ │ Output 26K │ │ Model Calls 53 │ │ Avg Context/Call 74.7K │ └──────────────────────────┘ 这样才能看出来到底哪里浪费。 甚至可以定义一个： Context Amplification Ratio 累计 Input / Peak Context = 3.884M / 103K ≈ 37.7x 也就是： 一个最终只有 103K 的上下文，被模型累计“读”了约 37.7 遍。 这个指标对于 Coding Agent 比单纯的 4M token 更有意义 。 我的判断 如果这是一次真实的“登录页开发”： 4M token：偏高。 但： 不是严重异常。 更准确地说是： 上下文管理基本正常，但 Agent 的工具/上下文效率还有明显优化空间。 尤其值得优化的是： 减少无关 MCP 工具定义进入 context 减少系统工具定义重复占用 避免每次 tool call 都携带大量无变化内容 对历史对话做压缩/summarization 工具返回结果尽量结构化、短化 避免 Agent 为了找一个文件反复读取大段代码 把“当前任务状态”从完整历史中抽取出来，而不是让模型每轮自己重新理解 而你这里 95.5% cache hit 已经非常高 ，所以如果你是在优化成本，下一步不应该优先纠结 cache，而应该看： 为什么一个登录页需要 53 次模型调用，以及这 53 次调用中哪些请求真正需要 70K～100K 的 context。 如果你愿意，我还可以直接 把你这个 JSONL 的 53 次调用逐条分析一遍 ，给你画出 第 N 次调用 → context 大小 → input token → output token → MCP/tool → 累计 token ，然后找出 到底是哪几次调用把 4M token 吃掉的 。这会比单看截图准确很多。 1 个帖子 - 1 位参与者 阅读完整话题

  • 情报分类：技术学习与提效
  • 分类依据：内容涉及技术、AI、软件工具或工程实践
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/9/15 15:06:49