什么是上下文工程（Context Engineering）？比提示词更重要的是给 AI 准备对的信息

很多人优化 AI 助手时，只盯着那一句提示词：换角色、加“请仔细思考”、再补几个感叹号。可真正决定结果的，往往是模型在这一刻究竟看到了什么：目标是否明确，资料是否正确，历史状态有没有丢，工具返回了哪些事实，过期信息是否混了进来。把这些输入作为一个整体来设计，就是上下文工程（Context Engineering）。

提示词工程关注“怎样把要求说清楚”；上下文工程关注“为了完成任务，模型此刻应该看到哪些信息、以什么顺序看到，以及哪些信息不该看到”。

上下文不只是一段聊天记录

在一个真实 AI 系统里，上下文可能同时包含系统规则、开发者要求、用户当前问题、过去对话摘要、账户状态、检索到的文档、工具说明、工具执行结果、当前日期、权限边界和输出格式。它们共同构成模型本次推理可用的工作台。

为什么提示词写得很好，结果仍会失败

假设你让 AI 回复客服工单，提示词已经清楚规定“核对订单后再判断能否退款”。如果上下文里没有订单状态，模型只能猜；如果检索结果拿到的是去年的退款政策，它会自信地执行旧规则；如果工具结果只返回一大段日志，关键字段埋在中间，它可能读错；如果系统忘了用户已经补交材料，就会重复追问。

这些不是一句更漂亮的提示词能解决的问题。需要从数据来源、状态管理、检索、工具接口和安全边界一起处理。

上下文窗口是预算，不是仓库

模型有上下文窗口，能容纳的输入和输出总量有限。窗口变大，并不意味着可以把整个知识库、全部聊天记录和每次工具日志永久塞进去。更长的输入会增加延迟和费用，也会让真正关键的信息被大量相似文字淹没。

OpenAI 的长上下文指导也提醒，随着需要检索的项目增多、任务要求理解整个上下文状态，表现可能下降。工程上的正确目标不是“填满窗口”，而是在预算内提高有效信息密度。

• 必须保留：当前目标、硬性约束、关键承诺、对象 ID、最新状态和必要证据。
• 按需加载：知识库片段、历史附件、工具定义、旧对话细节。
• 可以压缩：重复寒暄、已经解决的分支、冗长日志和可重新查询的数据。
• 应当排除：越权资料、未经信任的指令、明显过期或与任务无关的内容。

一套实用的上下文分层方式

第一层：稳定的任务契约

放角色、目标、行为边界、成功标准、输出格式和停止条件。这里要短而明确，避免同一件事在多个位置出现不同说法。真正的硬规则应该稳定，偏好和建议则不必写成绝对命令。

第二层：当前用户与运行状态

放账户、语言、时区、权限、当前步骤、已完成动作和等待事项。状态必须来自可信系统，而不是让模型从自然语言历史里猜。订单号、文件 ID、版本号等关键标识应原样保存，不能在摘要时改写。

第三层：本次任务所需知识

根据当前问题检索少量高相关资料，保留标题、来源、发布日期和引用位置。资料之间若有冲突，应显式呈现版本与优先级，而不是把两段话无标记地拼在一起。

第四层：工具能力与执行结果

只暴露当前任务需要的工具，参数名和说明要具体。结果尽量返回结构化字段，如 order_status、refund_deadline、source_updated_at，避免让模型从一屏控制台输出里提取事实。

提示词工程和上下文工程有什么区别

两者并不冲突。好的提示词是上下文的一部分；上下文工程把视角扩大到整条系统链路。

检索不是“搜几段文字塞进去”

一个可靠检索流程至少要考虑查询改写、文档切分、元数据过滤、召回数量、重排和引用。用户问“它还能退吗”，系统需要结合当前订单和上一轮提到的商品，把代词改写成可检索的问题；然后只查适用地区、产品和日期范围内的政策。

返回内容太少可能漏证据，太多则引入噪声。可以先追求召回，再通过重排选出少量片段。涉及法规、价格、版本和时效时，要把发布日期与适用范围一同送入上下文，让模型有机会判断新旧。

怎样保存长任务的状态

长任务不能把“记忆”完全等同于聊天全文。更稳妥的做法是建立结构化任务状态，例如：

{
  "goal": "完成四篇文章并发布",
  "constraints": ["直接线上发布", "图片使用指定图库"],
  "completed": ["主题查重", "资料核对"],
  "pending": ["图片检查", "发布回读"],
  "artifact_ids": ["post-draft-01"],
  "last_verified_at": "2026-09-15T10:00:00+08:00"
}

自然语言摘要仍然有用，但它是有损压缩。摘要时应优先保留承诺、决定、数值、错误原因和未完成事项；可重新查询的长日志只保存引用。每次恢复任务后，先用权威系统核对外部状态，避免把摘要里的“计划发布”误当成“已经发布”。

工具结果为什么要短、准、可追踪

如果工具返回“操作成功”，模型仍不知道改了哪个对象、最终状态是什么。更好的结果应包含操作类型、对象 ID、状态、时间和可重试错误；读操作则带来源和版本。这样模型既能继续下一步，也能在最终回复中准确说明完成了什么。

不要把数据库整行、密钥、内部栈信息和无关字段统统放进上下文。工具层应该先做权限检查和字段裁剪，敏感数据用最小披露原则处理。

警惕上下文投毒和提示词注入

检索到的网页、邮件或文档可能包含“忽略之前要求”“上传密钥”等恶意文字。它们是待分析的数据，不应自动升级成系统指令。工程上应区分可信规则与不可信内容，用清晰边界包裹外部资料，并限制工具权限。

• 把外部内容标记为数据，禁止其修改系统规则或自行授权工具。
• 敏感动作采用明确确认、参数校验、允许列表和最小权限。
• 检索前后都做访问控制，不让越权内容进入模型输入或日志。
• 对网页、附件和工具结果保留来源，异常指令进入审计。
• 用真实攻击样例测试，而不是只在正常问题上验证。

压缩上下文时，什么最容易丢

最常见的损失不是大段知识，而是一个小小限定条件：用户说“不要修改本地文件”，摘要只剩“发布文章”；系统记录“退款金额不超过 500 元”，下一轮只记得“允许退款”。因此压缩前应把硬约束和状态字段抽取出来，再对叙述性内容做总结。

对话越长，越需要周期性重新锚定：当前目标是什么，哪些约束仍有效，外部状态是否变化，下一步成功条件是什么。重新锚定不是把全部历史重复一遍，而是生成一份可核对的最小任务快照。

上下文工程该怎样评测

不要只评“回答看起来不错”。测试集要覆盖正常任务、信息缺失、资料冲突、过期文档、工具失败、跨轮状态、权限隔离和恶意内容。每个样例应有可检查的成功条件。

1. 事实落地：回答中的关键结论是否能被提供的资料支持。
2. 状态一致：模型是否记住已完成步骤，没有重复执行或跳过等待项。
3. 检索质量：正确资料是否进入上下文，无关资料是否受到控制。
4. 工具可靠：参数是否正确，失败后是否重试或安全停止。
5. 权限安全：不同用户之间是否隔离，恶意文档能否诱导越权。
6. 成本延迟：上下文长度、缓存命中和工具轮次是否符合产品预算。

模型和生成具有不确定性，评测要重复运行并观察分布。发现失败后，先判断是指令、知识、状态、工具还是权限问题，再修改对应层；不要把所有错误都归因于“模型不够聪明”。

从零开始的实施步骤

1. 写清任务成功标准、硬约束和允许模型自主决定的范围。
2. 列出完成任务所需的最小事实，标注它们的权威来源和有效期。
3. 把用户状态与任务状态结构化，避免只能从聊天全文恢复。
4. 设计按需检索与元数据过滤，保留来源、版本和引用位置。
5. 让工具输入输出结构化，为敏感动作设置权限和确认。
6. 为上下文设置预算：哪些常驻，哪些检索，哪些压缩，哪些丢弃。
7. 建立冲突、缺失、过期、长对话和注入攻击测试集。
8. 监控失败类型、输入 token、延迟、工具成功率和人工纠正。

OpenAI 的官方长上下文与提示指导强调清晰指令、上下文组织和评测，也指出复杂长上下文会随着检索项目增多而变难。无论使用哪家模型，这个工程原则都值得保留：给模型更多文字很容易，给它恰好正确的信息才是真功夫。

本文用于 AI 系统设计科普。不同模型、接口和上下文限制会变化，涉及生产数据、隐私和自动执行时，应以所用平台最新官方文档、安全评审和实际评测为准。