什么是上下文工程，主要解决哪些问题？

核心回答

上下文工程，是在每次调用模型前，选择、组织并维护当前任务所需的信息，让模型在有限窗口内有足够依据完成下一步。它覆盖信息如何取得、何时进入上下文、怎样更新，以及过长时如何裁剪和恢复细节。

它主要解决四类问题：缺少关键资料，模型无从判断；历史和工具结果不断累积，导致超限、成本和延迟增加；无关、过期或冲突信息干扰当前判断；长任务跨窗口后丢掉目标、约束和进度。

例如研究任务已经检索了很多网页，下一步写结论需要的是当前目标、有效证据和未解决的问题，不需要把每次搜索的完整返回都重新发送。上下文工程要做到既能收敛输入，又能在需要时找回证据，而不是单纯把文本压得越短越好。

展开说明

1. 先看模型为什么答不好，再决定怎么处理上下文

信息不足时，先查缺什么：当前业务状态、适用版本、用户限制还是原始证据。通过检索、工具查询或澄清补齐。数据库里存着资料，不代表这一轮模型已经看到了；反过来，没有依据时增加提示词也不能补出事实。

信息太杂或不再有效时，处理相关性、去重、来源与时效。例如订单状态已经更新，就应重新查询，不能继续使用早期工具结果。用户明确更正某个条件后，应同步调整当前状态及仍在使用的旧摘要，避免两种说法同时误导模型。外部网页和日志中的内容也要与应用指令区分，不能因进入上下文就变成可执行要求。

信息太多时，先减少重复和无关内容，针对长文或日志提取相关片段，大体积原始结果保存在外部并保留引用。必要时再用摘要承接历史。选择哪些来源和怎样注入，可结合上下文组成与组织理解。

任务持续太久时，要保存当前目标、重要决定、进度、未完成事项和证据位置，让下一窗口能接着做，而不需要重新猜测此前发生过什么。

2. 预算管理要发生在调用前

每轮组装时统计或估算输入 Token，并考虑输出空间及下一次工具返回可能带来的增长。规则、工具描述、附件和历史都可能占用预算，不能只统计聊天文本。

当剩余空间不足以支持下一阶段时，可先裁剪冗余，再压缩较早的完整交互，并保留近期需要直接使用的内容。触发时机要结合模型限制、任务阶段和工具输出大小选择；固定“聊到第十轮”或“窗口到某个百分比”可以是起点，不能当成所有任务的最佳规则。摘要本身也需要可用输入和输出空间，不能等窗口完全满了才开始处理。

裁剪后仍要保持消息结构有效。例如一次工具调用及其结果要按模型接口要求保留配对，不能任意删掉半段交互。为了本轮少发一些历史，也不必直接删除外部保存的原始记录。

3. 压缩的验收是能否继续任务

摘要应该让下一轮知道目标是什么、确认了哪些事实、还有什么问题，以及到哪里取回细节。金额、日期、否定条件等会改变决策的信息可以保留结构化值；其适用范围和有效性仍需维护。信息保留的具体判断可见压缩时如何判断重要性。

例如一个报告任务已完成资料收集，但 PDF 导出失败。压缩后应保留“资料已收集、PDF 未生成、失败原因及 Markdown 位置”，不能简写成“报告已完成”。若需要查询某条具体数字，再按引用读取对应证据。

摘要还要记录覆盖的历史区间和版本，成功保存后再更新覆盖位置，避免并发或重试导致遗漏、重复和旧摘要覆盖新摘要。它支持信息连续性；检查点和业务执行记录负责确认运行进度，外部操作是否成功仍应以实际结果为准，不能根据摘要重新猜测并执行一次。

4. 用具体失败案例检查是否有效

可以回放长任务，比较加入上下文策略前后，关键条件是否仍被遵守、旧事实是否被错误沿用、跨窗口后能否正确续做。检查时同时记录输入 Token、调用延迟与任务结果，避免只看到文本变短，却没发现关键证据被删掉。

如果效果下降，要能定位是检索没找到、组装时没放入、被裁剪或摘要漏掉，还是模型已经看到但没有正确使用。记录来源、选择结果、摘要覆盖区间和策略版本，可以让后续调整有依据。

常见追问

换成长上下文模型，还需要上下文工程吗？

需要。更大的窗口扩大容量，但相关性、时效、冲突及成本问题仍然存在。简单任务可以直接提供完整材料；材料变大或任务变长时，再依据实际失败和成本增加筛选、检索与摘要，不必一开始做复杂系统。

上下文工程就是摘要压缩吗？

摘要只是其中一项。缺少知识时要补信息，旧状态失效时要更新，噪声太多时要筛选，长任务才涉及跨窗口连续性。对不同原因使用同一种压缩，可能让缺失的信息更难恢复。

为什么保存了完整历史，模型还是忘记？

先区分历史是否保存、是否被选入本轮输入，以及模型是否准确利用了它。完整存储解决可取回，调用前的选择和组织决定本轮可见内容；后续还要验证模型是否能据此完成任务。

怎么判断摘要质量？

用压缩前后的任务问题核对：关键条件、事实、未完成动作是否保留，摘要有没有编造完成状态，细节能否按引用取回。再检查多次压缩后的漂移和用户更正是否生效。压缩率可以记录，但不能单独代表质量。

对应教程

参考资料