API 提示上下文超限怎么办？长对话、PDF 和代码项目的处理方法
区分上下文超限与上传体积超限，检查历史、附件、工具结果和输出预算，附分块与摘要交接模板。
模型提示 context length exceeded、maximum context length 或“上下文长度超限”，通常意味着本次请求需要处理的内容超出了相应限制。你这次只输入一句话，客户端仍可能携带大量历史、附件和工具输出。
不要直接把“最大输出 Token”调到更大。某些接口会把预留输出也计入上下文预算，这样调整反而更容易超限。
先分清是上下文，还是上传体积
| 错误线索 | 对应限制 | 先处理什么 |
|---|---|---|
| context length、too many tokens | 模型或渠道 Token 限制 | 历史、文档、工具结果和输出预算 |
| HTTP 413、request too large | 网关或接口请求体大小 | 图片编码、文件体积和批量上传 |
| 单个文件超限 | 上传服务限制 | 文件数、文件大小和支持格式 |
| 读取很久后超时 | 时间限制或处理问题 | 耗时、网络、服务状态 |
不同服务商可能重新封装错误，优先看错误正文和文档。PDF 文件大小不能直接换算成 Token：扫描图片、文本抽取方式和版面都会改变实际处理量。
新对话短请求能否成功
保存当前任务进度，另开空白对话，仅发送短文字。如果成功，说明基础调用在这次测试中可用，问题可能与旧历史或附件有关。
回到原任务，查看客户端会附带哪些内容：系统提示、全部对话、上传文档的提取文本、代码文件、工具 Schema、终端日志，以及长篇工具返回。不要只统计输入框里可见的文字。
模型宣传的最大上下文也不一定等于当前中转渠道和客户端允许的上限。三者都要确认。
用一个预算示例理解限制
假设某渠道允许本次请求最多使用 32,000 Token，并要求输入与预留输出的合计不超过这个值。当前输入 29,000 Token、计划输出 4,000 Token，总计 33,000，就超过了限额。
可以缩短输入，或在任务允许时降低输出预算。实际接口还可能单独限制输出、工具或多模态内容，所以这个算例不能替代模型文档。
中文字数与 Token 数不是固定比例。估算时优先使用模型对应的计数工具、客户端报告或错误返回数据，并给格式开销留余量。
长对话：用交接摘要保留关键状态
请整理一份交接摘要，包含：
- 当前目标和已经确认的约束。
- 已完成的步骤与关键结论。
- 仍未解决的问题。
- 必须保留的数字、文件名和引用位置。
- 下一步要执行的一个动作。
核对摘要后再带到新对话。原始材料仍需保留，摘要可能漏掉细节；涉及金额、合同条款或代码修改位置时，必要内容应重新附上。摘要请求本身已经超限时，就手动整理或减少历史后再生成。
长文档：按结构分块，再带来源汇总
以章节、标题或自然段为边界分块，给每块编号和页码。必要时保留少量边界重叠，避免一句条件与下一段例外被拆开。每块先输出结论、证据位置、未确定项，然后汇总。
涉及跨章节比较时，汇总后要回到原文核对相关片段，不能把“分块摘要拼起来”当作全文一致性验证。检索式读取适合寻找局部内容，但全篇统计、完整审查仍需要覆盖全部材料。
代码项目：只附当前任务所需材料
优先提供相关文件、准确报错、调用关系和必要配置。排除依赖目录、构建产物、历史日志和重复文件。终端日志只保留首个错误、相关堆栈和复现步骤。
工具反复返回长列表时，先限制输出条数或缩小检索范围。盲目提高上下文上限可能增加费用，还掩盖了任务范围失控的问题。
换长上下文模型一定能解决吗？ 要同时确认渠道和客户端支持，并重新检查预算。上传体积超限不会仅靠更换模型消失。
删掉旧消息就够了吗？ 客户端可能仍注入附件或工作区信息，需要检查实际请求。