考察点
这道题出自蚂蚁集团 Agent 方向暑期实习一面，借 Claude Code 这个具体产品考你对 LLM 推理成本和上下文管理的理解。面试官想看的不是你用过 Claude Code，而是你能否从 Transformer 推理机制出发解释「为什么上下文越长越慢」，以及工程上有什么缓解手段。追问常往 KV cache、注意力复杂度、上下文压缩策略这些方向走。
参考答案
直接原因：上下文在单调增长
Claude Code 这类编程 Agent 的每一轮交互，都会把完整的对话历史重新发给模型：你的每条消息、模型的每轮回复、每次工具调用（读文件、跑命令、grep 结果）的内容。编程 Agent 的工具输出尤其长——读一个文件几百行、跑一次测试输出一屏日志，这些全部留在上下文里。用两个小时，上下文从几千 token 涨到十几万 token 很正常。
而模型推理的成本和上下文长度直接相关，这就是变慢的机制根源。
机制层面：prefill 和 KV cache
LLM 推理分两个阶段。prefill 阶段处理全部输入 token，计算每一层的 key、value 并缓存（KV cache）；decode 阶段逐 token 生成，每生成一个 token 都要和缓存里所有历史 token 算注意力。
prefill 的计算量大致随上下文长度线性到超线性增长（注意力部分是 O(n²)，不过工程上有各种优化，实际更接近线性偏上）。这意味着：上下文 10 万 token 时，你每发一句话，哪怕模型只回 50 个 token，也要先把这 10 万 token 重新算一遍注意力——除非命中 KV cache 复用。首 token 延迟（TTFT）主要就耗在这里，这就是「越来越慢」最直观的来源。
KV cache 还带来显存压力：每个 token 在每一层都要存 K 和 V 两份数据，上下文越长缓存越大。显存吃紧时服务方可能降级处理（比如换更小的 batch、触发交换），整体吞吐下降，用户感知就是变慢。
补充一点：API 服务一般有 prompt caching 机制，前缀相同的历史部分可以复用 KV cache，不用全量重算。但缓存有命中条件和时效，缓存未命中或跨会话时仍是全量 prefill；而且即使命中缓存，decode 阶段的注意力计算仍随长度增长，只是压力小得多。
工程上的缓解：压缩，而不是无限堆
所以主流编程 Agent 都不会让上下文无限增长，Claude Code 的做法有代表性：
一是自动压缩（compaction）。上下文接近窗口上限时，把此前的对话历史交给模型总结成一段摘要，用「摘要 + 最近若干轮原始消息」替换掉全部历史，继续会话。用户感知是「卡了一下、做了个总结」，代价是摘要是有损的，细节会丢。
二是工具结果治理。文件读取截断行数、命令输出截断字节数，长输出落盘只在上下文里留引用；重复读同一文件可以只留最新版本。工具结果是上下文膨胀的最大来源，治理它收益最大。
三是子 Agent 隔离。把搜索、探索类的脏活派给子 Agent，子 Agent 的十几万 token 过程内容不进主会话，只回传结论。主上下文保持精瘦。
四是用户侧的配合：开新会话、手动清理、把长期约定沉淀到项目规则文件（比如 CLAUDE.md）而不是靠会话历史记着。
面试时怎么收尾
我会补一句权衡：长上下文模型（100 万 token 窗口）并没有让这个问题消失。窗口大只是允许你装下，prefill 成本和注意力噪声依然随长度增长，「装得下」和「用得好」是两回事——上下文里无关内容多了，模型对关键信息的注意力反而被稀释。所以上下文工程（context engineering）的核心不是塞更多，而是让每一轮输入的 token 都尽可能高价值。
可能的追问
- 注意力是 O(n²)，为什么说实际接近线性？ 答：FLOPs 上注意力分数计算确实是平方项，但 decode 阶段有 KV cache，每步只算新 token 对历史的注意力；prefill 有 FlashAttention 等优化，内存访问是主要瓶颈而非纯算力，工程实测更接近线性偏上。
- 压缩摘要丢信息怎么办？ 答：摘要时保留结构化清单（已改动的文件、待办、关键决策），而不是让模型自由发挥；关键文件内容丢了没关系，Agent 可以重新读文件找回。
- 除了变慢，长上下文还有什么问题？ 答：成本（每次请求按输入 token 计费）、以及「lost in the middle」现象——模型对上下文中间部分的信息利用率低于首尾。