Apollo
全部栏目

上下文工程

上下文工程负责为一次模型调用准备合适的信息，包括任务指令、当前状态、检索证据、历史记录和工具说明，并随任务推进持续更新。

返回概念图谱 →

理解与应用

上下文工程是选择、组织和维护模型输入信息的工作。提示工程主要关注任务怎样表述，上下文工程还关心资料从哪里来、哪些内容应在此刻出现、哪些内容已经过时。两者有交集：清晰的指令需要合适的证据才能发挥作用，资料再完整也需要说明本次如何使用。

假设助手要写青禾项目的周报。它能够访问整个项目资料库，但这次真正需要的是本周目标、已核实数据、报告单位和仍未解决的问题。上个月的报告可以帮助理解格式，却不应成为本周金额的来源；已经被更正的表格也不能与新表并列而不说明区别。上下文准备首先是在判断这些资料分别起什么作用。

任务推进后，所需信息会变化。核对数据时，模型需要原始字段和口径说明；撰写结论时，可能更需要已经验证的汇总表和异常解释。应用可以在不同阶段取回不同内容，而不是每次都把全部工具输出追加进去。完整材料仍可存于外部，遇到细节问题时再按引用读取。

信息之间的关系也要表达清楚。用户要求、已确认事实、待核实假设和外部文档不能混写成一段没有出处的叙述。例如“运营金额尚未核实”若被删掉，模型可能把数字当成最终结果；文档中的指令性文字若未与任务要求区分，也可能影响原本不该改变的行动。

排查回答错误时，应先看模型实际收到了什么。数据库里有正确数据，并不代表这次检索选中了它；上下文窗口更长，也不保证模型会正确处理混杂的版本。保存选入材料及其来源，可以区分问题出在资料选择、内容更新还是生成阶段，再有针对性地调整。

关系速览
上下文工程应用于 →上下文构建器

上下文构建器是落实选取、排序、预算和来源边界的一种应用实现。

上下文工程应用于 →上下文压缩

上下文压缩用于长任务中的预算管理，须验证关键信息未被摘要丢失。

上下文工程面临风险 →提示注入

上下文工程必须区分可信指令与不可信文档，防止把文档命令提升为系统权限。

看一个具体过程：为周报写作准备当前有效的资料

同一份资料库在不同阶段会组成不同输入。这里展示的是材料选择与用途标注，不是运行模型后的质量对比；A、B 等来源编号让后续检查能追到原始材料。

以下为教学示意，未连接真实业务系统。

过程示意

任务：完成青禾项目本周周报，金额用万元。

可取得的资料：
A：本周已核实的研发与销售数据。
B：运营数据初稿，退款口径尚未核实。
C：上月周报，可参考格式。
D：已被 A 替代的旧数据表。
E：本周与报告无关的活动通知。

本轮正在撰写已确认部分：
选入 A，作为金额与结论依据。
选入 B 的待核实状态，并保留原文入口。
从 C 取回报告结构，标明不可引用其中的旧金额。
D 不作为当前依据，E 暂不加入。

示意结果

本轮上下文包含：本周目标、万元单位、A 的数据、运营口径待核实这一限制，以及报告结构。
运营金额仍留空待查；已核实部分可以继续撰写。

常见误区

  • 认为资料存在数据库中就等于模型已经看见，忽略检索、筛选和注入过程。
  • 把过时数据、格式范例和当前事实放在一起却不注明用途，容易让模型引用错对象。

前置与延伸

建议先读

相关概念

参考与版本

Apollo 原创讲解与教学示例。参考资料用于核对技术定义；核验日不代表资料的发布日期。