模型本身并不知道你的业务系统发生了什么。用户是谁、权限是什么、当前任务处于哪一步、检索结果是否可信、工具返回是否过期，这些都需要通过上下文传递给模型。上下文工程就是把这些信息组织成稳定、可控、可复用的输入。
上下文不是越多越好，而是越贴近任务、越有优先级、越可验证越好。
上下文的四类信息
第一类是用户意图，说明用户现在想完成什么；第二类是业务规则，说明系统必须遵守什么；第三类是外部证据，例如检索片段、数据库结果、工具返回；第四类是执行状态，例如已经完成的步骤、失败原因和下一步候选动作。
优先级比长度更重要
把所有历史对话、所有搜索结果和所有规则都塞进模型，往往会让输出变差。实践中可以把上下文分成硬约束、强证据、辅助背景和可省略信息。硬约束永远保留，辅助背景在上下文紧张时优先压缩。
记忆要可编辑
很多系统会给模型加入用户偏好或历史记忆，但记忆如果不能查看、修改和删除，就会变成长期风险。适合保存的记忆通常是稳定偏好、明确授权的信息和可复用的业务上下文；不适合保存的是一次性情绪、敏感信息和未经确认的推测。
工具结果要带元数据
工具返回不应只给模型一个结果值，还应该包含来源、时间、置信度、权限范围和异常状态。这样模型才能区分“没有查询到”和“查询失败”，也能在答案中说明信息来源。
上下文压缩不是摘要那么简单
长任务中需要压缩历史，但摘要可能丢掉关键决策。更稳妥的方式是保留任务目标、已确认事实、待办事项、失败记录和用户明确偏好，同时丢弃寒暄和重复推理。
实施清单
- 为上下文字段定义来源、有效期和优先级。
- 把权限、合规和安全规则放在不可被用户覆盖的位置。
- 对检索结果做排序、去重和引用编号。
- 对长任务保留状态摘要，而不是完整聊天流水。
- 让用户能查看和纠正长期记忆。