标准回答
问题：超大结果会从四个方向伤害 Agent
一是撑爆上下文窗口——50KB 文本可能就是上万 token，几次这样的调用就把窗口占满，导致历史被挤掉或直接超限报错。二是成本与延迟暴涨，每一步推理都要把这堆内容重新喂进去，token 是按量计费且随步数累乘。三是关键信息被淹没，真正有用的几行被埋在大量无关内容里，模型容易"迷失在中间"（lost in the middle）。四是推理质量下降，无关上下文会稀释注意力、削弱指令遵循，让后续决策变差。
处理一：入口就别让它进来——截断与分页
在工具实现侧设单次输出上限（如每次最多返回 N 行/KB），超出部分截断并附带"还有更多，可翻页"的元信息。把工具设计成支持分页/游标，让 Agent 按需取下一页，而不是一次性灌入全部。这是最直接的护栏。
处理二：压缩后再入上下文——摘要与相关片段
对必须利用的大结果，先做压缩再入栈：用小模型或规则把长文摘要成要点；或基于当前子目标做二次检索/grep 过滤，只把命中的相关片段放进上下文。代码搜索场景尤其有效——50KB 里通常只有几处真正相关，先在结果内再筛一遍，把噪声挡在窗口之外。
处理三：结构化提取 + 外部引用按需取
能结构化的就别塞原文：从结果中提取关键字段（文件名、行号、匹配片段、计数）返回结构化对象，既省 token 又利于后续程序化处理。对确实庞大的原始数据，采用外部引用模式——把全文存到文件/对象存储/向量库，上下文里只保留一个句柄或摘要，模型需要细节时再用专门工具按 id/范围回取。这本质上是把"上下文"当稀缺缓存来管理，让模型像翻字典一样按需访问，而非把整本书背在脑子里。
常见误区
⚠️ 常见踩坑
最典型的错误是把工具原始输出原封不动塞回上下文，指望"窗口够大就行"——长上下文模型同样会迷失在中间、成本随步数累乘，且越塞后续越笨。另一个误区是无脑硬截断到固定字节，可能正好切掉了关键片段或截断在半个 JSON 上导致解析失败。正确做法是按相关性筛选 + 摘要压缩 + 结构化提取，保留语义完整的相关内容，并用外部引用承接真正的大块原文，而不是简单粗暴地砍。
追问
追问 1：截断和摘要压缩分别适合什么场景？怎么选？
截断适合"结果天然有序、前部最重要"或只需确认存在性的场景（如日志、列表预览），实现简单、零额外延迟，但会丢尾部信息。摘要压缩适合"信息散落全文、需要整体理解"的场景（长文档、大段代码、多条搜索命中），保留语义但要额外一次模型/规则调用、有延迟和成本。实践中常组合：先按相关性过滤再对剩余部分摘要，或截断 + "需要更多请翻页/回取"的元信息兜底。选择取决于信息分布和对完整性的要求。
追问 2："外部引用按需取"具体怎么落地？
把工具的完整原始输出写入外部存储（临时文件、对象存储或向量库），生成一个稳定句柄（如 result_id 或文件路径），上下文里只放句柄 + 一句话摘要 + 字段概览。再提供配套的回取工具：按 id 读全文、按行号范围读片段、或在该结果内做向量/关键词检索。这样 Agent 默认在精简视图上推理，只在真正需要细节时才花 token 把相关部分调进来，类似把上下文当缓存、外部存储当主存的分层内存模型。
🔗 相似问题
同一考点的不同问法，面试官可能换着问，一起刷更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习