142. 长文本处理技巧：从一次上下文截断事故说起那天凌晨两点，线上告警群里突然炸了。用户上传了一份三百页的PDF，让Agent做合同风险审查。我盯着日志里那一串被截断到七零八落的文本块，再看看模型返回的“根据您提供的资料，我认为本条款存在……（此处缺失）”，就知道又栽在上下文长度上了。这不是第一次了。过去三个月，我们团队的Agent从“能跑通demo”进化到“敢上生产”，几乎每个翻车现场都跟长文本处理有关。今天不聊理论，就聊聊我在实际调试里踩过的坑，和最终沉淀下来的一堆土办法。先明确一个容易混淆的前提：上下文工程不等于“把提示词写得更长”。你往prompt里塞更多内容，模型能记住的未必更多。Transformer的注意力机制是全局的，但窗口有限，而且不同位置的信息对输出的影响权重并不均匀——中段的信息尤其容易被“挤丢”，这已经被很多实验证实过。所以长文本处理的核心，不是“怎么塞进去”，而是“怎么让模型在有限的窗口里，看到它最该看的东西”。我最开始的做法很天真，直接把整段文本拼进去，用max_tokens控制输出长度。后果就是：当输入超过模型上下文上限时，系统要么直接报错，要么在某个未知的位置悄悄截断。最坑的是，很多API框架对超长输入不是报错，而是用“自动截断”的方式默默处理——你看到输入长度显示正常，但实际送进模型的内容已经被砍了后半个尾部。当时我们排查了很久，最后把请求体原样打印出来才发现，用户的签字页信息根本就没进模型。第一个实用的技巧：分段检索，而不是一次性投喂。当你的资料长度超过上下文窗口的一半时，就别全量塞了。把文本按语义切块，每块控制在五百到八百字左右，然后做一次轻量级的检索排序，只挑跟当前任务最相关的几块喂给模型。这里有个细节，切块不能按