工具返回的内容太大是怎么办的？

让 AI 智能体查一次资料，工具返回的内容太大——一口气几万字硬塞进对话，谁都会被撑着。这是长任务里最常见的尴尬，这篇把截断、分页、摘要、落盘四条出路各自讲清。

上下文装不下一次工具返回

模型的对话窗口有固定容量，工具返回又往往是最占地方的部分：一次检索几万字、一张大表上千行，塞进去两次，后面的对话就没地方了。更大的窗口只是缓解并非根治，成本也随长度上升。所以工程上默认假设：返回内容必须经过加工再进对话，原始全文另寻去处，这个假设能省掉大量后续麻烦。

截断与分页：先做减法

截断最直接：只保留开头、结尾或与当前问题最相关的片段，其余丢弃。分页则温和一些：先给模型第一页加总数概览，模型判断需要时再翻下一页，主动权在模型手里。两种方式都要求系统告诉模型「这只是部分内容」，否则它会把残缺当全貌，得出自信的错误结论——这一点比截断本身更值得警惕。

摘要与落盘：换个地方放

摘要是用另一个模型或规则把长内容压成要点，对话里只留压缩版；落盘是把全文写进文件或数据库，对话里只留引用路径，需要细节时再按引用去取。两条路可以叠加：先落盘、再摘要、按需回查。Kimi 的长文本摘要、通义千问的长文档阅读都是这条路的典型应用。摘要的质量决定判断质量，压得太狠丢了关键数字，结论照样跑偏，所以摘要通常保留关键数值原样。

哪种方案适合哪种场合

给个粗略的选择框架：答案集中在开头结尾的用截断；需要浏览比较的用分页；要点明确但细节可查的用摘要加落盘；多次要引用同一份长材料的，落盘加引用最省。拿不定时，先落盘再摘要几乎不会错——材料永远在，怎么用再说。这正是长任务的状态是怎么保存的思想的延伸：现场放不下，就存档留底。加工过程本身也会记进执行日志的结构长什么样所讲的记录里，方便回查哪一步压缩丢了信息。

大输出处理速查表：先问模型需要什么再取数；返回先落盘留底；进对话只走摘要或分页；关键数值不压缩。照这四条，再大的返回也接得住。

这一整套加工，本质上是给上下文瘦身的前置工序：与其等Agent 的上下文膨胀是怎么发生的再治理，不如在入口就管住流量；万一还是胀了，就交给上下文清理是怎么做的去收拾。两头配合，长任务才能跑得又稳又久。

加工链路的顺序与回查设计

多道加工叠在一起时，顺序有讲究：先筛后压，比先压后筛省力得多——先用规则把与任务无关的大块内容剔掉，再做语义压缩，模型要读的量小了，摘要也准了。回查设计是常被忽略的另一半：引用路径要带上定位信息，比如页码或行号区间，模型回查时不必重新通读全文；高频回查的材料可以预生成索引，按关键词直达段落。还有一致性问题：原文更新后，摘要与落盘副本要不要跟着刷新，要定一条明确规则，否则对话里的结论可能建立在旧材料上而不自知。判断：加工链路的尽头是可回查，并非压得越碎越好。

大输出处理快问快答三则

• 直接换更大窗口的模型不行吗？：可以救急，但成本随长度上升，而且注意力会被无关内容稀释，加工仍然不可省。
• 截断截掉的部分还能找回吗？：落盘方案下能，按引用路径回查即可；纯截断方案下不能，所以重要材料建议先落盘。
• 摘要由谁来做更可靠？：模型做语义压缩更聪明，规则做格式提取更精确，两者按材料类型搭配使用。