文章总结： 本文解析Agent项目token爆炸问题的面试应对框架。核心观点：token爆炸分超窗口报错、模型变笨、成本高三种症状，需先定义再定位。治理方案分层：源头瘦身（工具返回结构化、代码过滤）、可恢复外置（落文件留路径）、清理旧工具结果、结构化摘要压缩、子agent隔离、稳定前缀吃满KV-cache。强调压缩会丢信息、子agent总成本更高、清理历史会打破缓存等取舍，需用真实数据支撑优化效果。 综合评分： 88 文章分类： AI安全,安全开发,实战经验

大厂面试官：你的 Agent 跑着跑着 token 爆了，怎么解决？ (网安面试题图解)

原创

GGDog Sec GGDog Sec

GGDog Sec

2026年10月6日 10:49 北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

面试官：”做 agent 项目的时候，遇到过 token 爆炸吗？怎么解决的？”

我：”遇到过。上下文太长了，就让模型总结一下，再不够就换个上下文更长的模型。”

面试官：”总结完，前面扫出来的那个关键参数丢了怎么办？”

我：”那就……在 prompt 里让它别丢重点。”

面试官：”换 1M 窗口的模型呢？账单谁付？而且窗口越大就一定越准吗？”

我：”呃……那至少不会报超窗口的错了。”

面试官：”你先别急着给方案。token 到底是在哪爆的，爆了之后是报错、是变慢、还是答得越来越差？这几种能一样治吗？”

我愣了一下。

回来复盘才发现，我从头到尾只盯着”窗口满了”这一个症状。没拆来源，没算成本，也没想过压缩本身会丢信息。

这题考的其实是 context engineering(上下文工程)：在有限的窗口里，每一轮该放什么、不该放什么。下面按我现在会答的顺序拆开讲。

简要回答

如果只给我 30 秒，我会这么说：

第一，先定义是哪一种爆炸。token 爆炸不是一个症状，是三个：直接超窗口报错、没超窗口但 agent 变笨、以及又贵又慢。三种解法侧重点完全不同，上来就甩方案一定会被追问。

第二，先量再砍。按来源统计每轮 token 占比(系统提示 + 工具定义、工具返回、历史、检索文档)，找到最大的那块再动手，安全方向的 agent 大头基本都在工具返回。

第三，分层治理，讲清取舍。源头瘦身(工具返回结构化、让 agent 写代码过滤) → 可恢复外置(大块内容落文件，上下文只留路径和摘要) → 清理旧工具结果 → 结构化摘要压缩 → 能拆的任务用子 agent 隔离 → 稳定前缀吃满缓存。每一步都有代价：压缩省 token 但会丢信息，子 agent 隔离上下文但总成本更高，清理历史省窗口但会打破缓存。能把这些取舍讲出来，比背方案更能过。

详细解析

先分清：token 爆炸，爆的是哪一种

我把它分成三种症状，解法侧重点不一样。

1：直接超窗口。 请求报错，任务中断，最直观。

2：没超窗口，但 agent 变笨了。 这个最容易被忽略。Chroma 在 2025 年 7 月的 Context Rot 报告里测了 18 个模型，结论是输入越长，表现越不稳定，哪怕是很简单的检索任务。更早的 Lost in the Middle(Liu 等，TACL 2024)发现，关键信息放在上下文中间时，模型用得最差，准确率曲线是个 U 型。

3：又贵又慢。 Agent 每一轮都会把完整历史重新发给模型。Manus 团队公开说过，他们 agent 的输入输出 token 比大约是 100:1。

粗算一笔账：假设每轮新增 3k token，跑 50 轮。最后一轮的输入是 15 万 token，但 50 轮累计输入是 3k × (1+2+…+50) ≈ 382 万 token。

上下文线性增长，总账单是平方级增长。 这才是”爆炸”两个字真正的含义。

所以被问到这题，第一句我会先说明我遇到的是哪一种，而不是直接甩方案。

先量再砍：token 到底从哪来

token 一般来自四个地方：

• 系统提示 + 工具定义

  MCP 接得越多，开局就占得越多。Anthropic 的文章里提到，连上千个工具时，模型读到用户请求之前就要先处理几十万 token。

• 工具返回

  安全方向的 agent 这里是重灾区。一次全端口扫描、一份目录爆破结果、一个压缩过的 JS 文件、一个完整的 HTTP 响应包，随便一个就是几千上万 token。

• 历史消息和推理过程

• 检索塞进来的文档

做法很朴素：每轮按来源打点，统计各部分占比，先砍最大的那块。我做的时候，大头基本都在工具返回。

没有度量的优化，面试官一听就知道是背的。

角度一：源头瘦身，别让垃圾进上下文

最便宜的优化，是让无用的 token 一开始就进不来。

工具返回要结构化、要截断。 比如端口扫描只回传”开放端口 + 服务 + 版本”，长输出给前 N 行 + 总条数 + 完整结果的文件路径。

让 agent 写代码处理数据，而不是把数据读进上下文。 Anthropic 在 2025 年 11 月的 Code execution with MCP 里讲的就是这个思路：把 MCP 工具暴露成代码 API，agent 在执行环境里过滤、聚合，只把结果打印回来。一张 1 万行的表格，模型最后只看到筛出来的 5 行。工具定义也按需读取，他们的例子里从 15 万 token 降到 2000，省了 98.7%。

代价也要说：agent 生成的代码要跑在沙箱里，限资源、可审计。做安全的人应该比谁都敏感，别为了省 token 给自己开个命令执行。

工具集要精简。 工具多了不只是费 token，模型还更容易选错。Anthropic 的原话大意是：如果人类工程师都说不清该用哪个工具，就别指望 agent 能选对。

角度二：可恢复的压缩，把大块内容外置到文件

很多人一说压缩就是”总结”，但总结是不可逆的。

Manus 的做法是把文件系统当作上下文的延伸：网页内容可以从上下文里删掉，只要 URL 还在；文档内容可以省略，只要路径还在。需要的时候再读回来。

放到安全场景：扫描原始结果落盘到 scan/xxx.json，上下文里只留一句”发现 3 个高危候选，详见 scan/xxx.json”。后面要验证哪个，再用 grep、head 读具体几行。

Anthropic 把这叫 just-in-time：上下文里只放轻量的引用(路径、链接、查询语句)，运行时再按需加载。

能恢复的压缩可以激进，不可逆的压缩必须保守。 这句话面试时可以直接说。

角度三：快满了怎么办，先清理，再摘要

窗口真的快满了，我的处理顺序是这样的：

第一步：清理旧的工具结果。 一个工具结果模型已经看过、结论也记下了，原始输出就没必要一直留着。这是最轻、最安全的一种压缩。Anthropic 在 2025 年 9 月上线的 context editing 就是干这个的，他们在 100 轮网页搜索的评测里，token 消耗降了 84%，还让原本会因为上下文耗尽而失败的任务跑完了。

第二步：还不够，再做摘要压缩(compaction)。 接近上限时让模型总结历史，用摘要开一个新窗口。Claude Code 的做法是保留架构决策、未解决的 bug 和实现细节，丢掉冗余的工具输出，再带上最近访问的 5 个文件。

摘要最大的坑就是面试官问的那个：关键信息被压没了。

我的做法是给摘要定死字段，不让模型自由发挥：

• 任务目标和约束
• 已确认的发现，带证据位置(哪个文件、哪个请求)
• 已经排除的路径
• 下一步待办

“已排除的路径”特别重要。没有它，压缩完 agent 会把已经试过、已经失败的 payload 再试一遍。Manus 也有类似的经验：错误不要删，留在上下文里，模型看到失败才会避开同样的坑。

Anthropic 的建议是先把摘要 prompt 的召回调高，保证该留的都留下，再慢慢提高精度。

角度四：拆任务，用子 agent 隔离上下文

有些任务天然能拆开，比如资产梳理、源码审计、漏洞验证。

主 agent 只拿计划和结论，每个子 agent 在一个干净的窗口里深挖，可能用掉几万 token，但只交回一份 1000-2000 token 的精简结果。脏活累活的上下文留在子 agent 里，不污染主线。

但这里有个很多人答反的点：子 agent 不是用来省钱的。 Anthropic 在讲他们的多 agent 研究系统时给过数据：单 agent 的 token 用量约为普通聊天的 4 倍，多 agent 系统约为 15 倍。

所以子 agent 解决的是”单个窗口被污染”，不是”总 token 太多”。适合能并行、边界清晰、价值够高的任务。上下游强依赖的任务硬拆，反而会信息断层。

角度五：成本，吃满 KV-cache

前面说过 agent 输入远大于输出，所以前缀缓存是降成本的关键。Manus 甚至说，如果只能选一个指标，KV-cache 命中率是生产环境 agent 最重要的那个。以 Anthropic 的计费为例，缓存命中的输入一般按基础输入价的 0.1 倍算。

想让缓存命中，有几个常见的坑：

• 系统提示开头放了精确到秒的时间戳

  ，每次请求前缀都不一样，缓存全废。

• 上下文要只追加不修改

  ，JSON 序列化时 key 的顺序要稳定。

• 不要中途增删工具定义。

  工具定义在上下文最前面，一改，后面的缓存全失效。Manus 的做法是不删工具，而是在解码时屏蔽掉当前不该用的工具。

这里还有个矛盾，能讲出来是加分项：清理旧工具结果，本身就会改历史，会让缓存失效。 所以清理不能每轮都做，要按阈值批量触发，一次清掉足够多。Anthropic 的 context editing 专门有个 clear_at_least 参数，就是为了判断这次清理值不值得打破缓存。

几个常见的坑

• 迷信长窗口。

  1M 的窗口照样会 context rot，而且越长越贵。

• 压缩把证据压没了。

  漏洞的请求包、响应里的关键行没了，最后报告都写不出来。

• 长任务跑偏。

  Manus 的任务平均要调约 50 次工具，他们让 agent 维护一个 todo.md，每一步都重写一遍，相当于把目标”复述”到上下文末尾，减少 lost in the middle。

• 只说方法，没有数据。

  面试官后面一定会追问效果。

面试总结

这道题真正考的，是你能不能把”窗口满了”这个表象，拆成一条可治理的链条。我会按这个框架答：

1：先定义。 token 爆炸分三种：超窗口、变笨、成本高。我的项目主要是 xx。

2：再定位。 按来源统计 token，发现大头在 xx(一般是工具返回)。

3：分层治理。 源头瘦身(工具返回结构化、代码过滤) → 可恢复外置(落文件，只留路径和摘要) → 清理旧工具结果 → 结构化摘要压缩 → 能拆的任务用子 agent → 稳定前缀，吃满缓存。

4：讲取舍。 压缩省 token 但会丢信息；子 agent 隔离上下文但总成本更高；清理历史省窗口但会打破缓存。

5：给数据。 优化前后的单任务平均 token、成功率、单次成本，用自己项目的真实数字。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：GGDog Sec GGDog Sec GGDog Sec《大厂面试官：你的 Agent 跑着跑着 token 爆了，怎么解决？ (网安面试题图解)》