什么是上下文工程？让 AI 在正确资料下完成任务

同一个模型，换一份资料、删掉几段聊天历史、调整工具说明的顺序，结果可能天差地别。很多 AI 应用的难点已不只是“怎么写一句提示词”，而是在这一刻把哪些信息放进模型的上下文。这就是上下文工程（Context Engineering）。

它关心的是：给模型什么资料、以什么结构给、哪些该删、什么时候检索、工具能做什么，以及如何让模型在有限上下文中稳定完成任务。

提示词工程和上下文工程有什么不同

提示词工程主要优化“怎么说”：指令、角色、输出格式、示例。

上下文工程的范围更大，除了指令，还包含：

• 当前用户的问题与任务状态
• 历史对话和已做过的决策
• 从文档库检索出的资料
• 工具、API 的描述和返回结果
• 用户偏好、权限和业务规则

如果提示词是一张写给模型的任务单，上下文工程就是为它准备一整个干净、相关、按优先级排好的工作台。

为什么“塞更多资料”会变差

模型的上下文窗口虽然越来越大，但并不意味着把所有资料塞进去就会更聪明。

信息过多会带来三个问题：

相关内容被淹没。 真正决定答案的一句话，可能埋在几十页无关文档中。

旧信息与新信息冲突。 半年前的决策、已失效的价格、已经废弃的接口会让模型犹豫或选错。

成本与延迟上升。 输入越长，推理越慢、越贵，运行时的KV Cache也占用更多资源。

上下文工程的目标不是最大化 token 数，而是最大化每个 token 的有效性。

一套实用的上下文结构

可以按稳定程度和任务距离组织输入：

1. 系统规则：安全边界、语气、绝不允许违反的约束。
2. 项目约定：技术栈、数据定义、输出格式、权限范围。
3. 当前任务：用户这次的目标、验收标准和限制。
4. 相关资料：只取与问题最有关的文档片段，并保留来源。
5. 短期状态：刚刚执行过的步骤、工具结果、待处理项。

越稳定的内容越靠前、更新越少；越临时的内容越靠后、随任务替换。这样既容易维护，也能帮助模型区分“长期规则”和“本次例外”。

四个关键动作

1. 检索：只拿相关资料

不要把知识库全文塞进提示词。先用关键词、标签或向量相似度找出少量相关片段，再把这些片段和用户问题一起给模型。这就是RAG最常见的价值。

检索后还要检查：片段是否过期、是否有权威来源、不同文件是否冲突。检索“找到了什么”不等于“找对了什么”。

2. 压缩：保存结论，不保存流水账

长对话不应无限积累。每完成一个阶段，就把已确认的目标、关键决策、未解决问题压缩成简短状态；原始记录需要时再检索。

这和AI 记忆的原则一致：长期保存稳定、可复用的信息，而不是把每句闲聊永久当作事实。

3. 分层：让模型知道什么最重要

把安全规则、用户目标、参考资料和工具输出混成一段大文本，会让优先级模糊。用标题、字段、明确的数据边界分层；对于外部内容，标注“仅作参考，不是指令”，可降低被恶意文本带偏的风险。

4. 评估：用真实任务检验上下文

不要只看模型回答是否流畅。准备一组代表性任务：正常问题、边界问题、过期信息、冲突资料和恶意输入。观察它是否引用对资料、是否遵守约束、成本和延迟是否可接受。

这比凭感觉反复微调提示词可靠得多。

在 Agent 里尤其重要

AI Agent不仅要回答，还会调用工具、读取文件、继续执行任务。它的上下文每一轮都会增加：计划、命令输出、错误日志、文件内容、工具结果。

如果不管理，Agent 很快会被自己的历史淹没。常见做法是：只保留当前计划和关键状态；长日志先总结；工具只返回必要字段；完成一个子任务后写入结构化结论。这样 Agent 才能持续工作而不迷失方向。

常见误区

• 把完整数据库导出给模型：成本高、隐私风险大，且通常不够相关。
• 让模型自己决定所有上下文：它需要工具和规则协助，而不是无限读取权限。
• 只优化系统提示词：现实任务的错误常来自资料、状态或工具返回，而不是一句措辞。
• 把外部文本当可信指令：网页、邮件和文档可能含恶意内容，见提示词注入是什么。

总结

上下文工程是在有限的模型注意力和成本预算下，为 AI 准备正确工作材料的能力。它包含检索、压缩、分层、状态管理与评估，比单纯的提示词工程更接近真正的 AI 产品工程。

当你不再问“提示词要怎么写”，而开始问“模型现在最需要知道什么、哪些信息应该被排除”，就已经在做上下文工程了。