上下文工程
模型每次回答时都只看得到当前运行被放进上下文的内容。系统提示、用户问题、检索片段、历史对话、记忆和工具结果，都会参与这一次生成；没有进入上下文的信息，即使存在于数据库或模型参数中，也不会直接影响当前回答。
因此，上下文工程研究的对象是一次运行的信息系统：什么信息进入，谁提供这些信息，它们按什么顺序出现，模型可以据此做什么，以及结果如何被下一轮使用。 Prompt 只是其中一部分，长期记忆和 RAG 也只是上下文的不同来源。
上下文是一次运行的输入结构
一个典型的模型调用可以包含以下部分：
系统规则与能力边界
↓
工具定义、输出 Schema 与任务约束
↓
检索内容、记忆与示例
↓
对话历史与已验证状态
↓
当前任务与用户输入
这些内容的职责不同。系统规则声明长期约束，工具定义描述可请求的能力，检索内容提供外部事实，记忆携带跨会话状态，历史记录说明任务走到哪一步，当前输入决定这一轮要解决什么问题。把它们全部拼成一段文字，会丢掉来源、时间、信任等级和权限关系。
上下文还要区分三种状态：模型生成的建议、工具返回的原始观察、经过外部系统确认的事实。它们都可以进入下一轮，但不能因为出现在上下文里就拥有同样的可信度。
上下文需要被主动组装
上下文不是越长越好。组装器应当先根据任务选择必要信息，再给每个片段附上来源、时间、租户、权限和版本，最后按照模型容易使用的结构组织它们。固定规则和工具 Schema 可以放在稳定的前缀，当前任务和最新观察应当靠近本轮决策位置，过期或重复内容应当被移除。
长上下文还会出现“迷失在中间”现象：关键信息放在大量材料中间时，模型利用它的能力可能下降。相关研究说明，扩大窗口不能替代信息筛选、排序和独立验证。上下文预算应当按任务价值分配，而不是把所有历史记录都塞进去。
示例和系统提示也应承担明确职责。示例用于校准格式、范围和判断方式；系统提示用于声明角色、边界和工具规则。它们不能把业务授权藏在自然语言里，更不能代替执行层对身份、资源、动作和审批状态的检查。
RAG 把外部知识变成上下文
RAG在推理前检索外部资料，再把相关片段放进当前上下文。它可以让模型读取最新政策、内部文档和特定项目资料，同时保留来源供人复核；它不会自动保证检索结果正确。
一个可解释的 RAG 流程至少包含：查询改写、候选召回、相关性筛选、片段组装和来源记录。切分过细会丢失条件，切分过粗会引入噪声；只按语义相似度召回，可能得到主题相近但无法回答问题的内容。评测时应分别观察召回是否覆盖答案、组装是否保留关键条件、模型是否正确引用来源。
检索内容属于外部观察。文章、网页、邮件和知识库条目中的文字可以影响模型的候选计划，不能自行改写系统规则、扩大工具权限或批准现实行动。涉及提示注入、知识污染和跨域数据流时，进入 AI 系统安全。
记忆把上下文延伸到时间维度
上下文管理一次运行，记忆管理多次运行之间保留什么。常见的记忆可以分为三层：当前对话中的工作记忆，跨会话的事件摘要，以及从历史中提炼的稳定事实和偏好。它们都应保存来源、时间和可撤销状态，不能把模型推测直接写成用户事实。
记忆系统至少要回答四个问题：什么内容值得保存，何时应该更新，用户如何查看和删除，过期或冲突的信息如何处理。没有保鲜和撤销机制的记忆会把旧状态不断带入新任务，最终成为上下文污染源。
写入记忆和读取记忆都需要独立控制。写入前要区分用户明确陈述、工具确认事实和模型推断；读取时要检查当前用户、租户、用途和时间范围。记忆能帮助 Agent 延续任务，却不能替代权威业务状态。
上下文如何连接 Agent 行动
Agent 每一轮都在做同一件事：从外部状态和当前观察组装上下文，让模型提出下一步行动，再把工具结果写回状态。上下文工程决定模型看到了哪些候选事实，Agent 工程决定哪些行动请求可以被执行；两者共同决定系统是否会沿着错误信息继续行动。
设计上下文时，可以按以下顺序检查：
- 任务目标和完成标准是否明确。
- 每条输入是否有来源、时间和信任等级。
- 当前决策真正需要哪些历史和检索内容。
- 工具结果是否与已验证状态分开保存。
- 记忆是否可查看、更新、撤销和按权限隔离。
- 上下文中的文字是否只能影响候选计划，不能直接获得权限。
做到这些，Prompt 才会从一次性的措辞调整，变成可观察、可测试、可替换的运行时设计。进一步学习模型如何生成结果，阅读 LLM 的技术演进主线；进一步学习如何把上下文接入工具和循环，进入 Agent 与工具工程。