Context Engineering

从一次失败的对话看问题#

教学情境： 客户先询问规则，后来修改订单号。应用每轮都把所有历史、全部商品文档和每个工具说明一起发送，模型仍然查了旧订单。这时只加一句“仔细阅读”未必能解决问题；需要检查旧信息、当前目标和确认状态如何组织。

上下文工程关注的是模型在这一步实际获得了什么信息。它包含提示设计，但还涉及资料筛选、工具返回结果和跨步骤状态。1

把输入分成三类#

• 任务指令： 要完成什么、允许什么、何时停止。来自应用的规则应与外部内容明确区分。
• 事实资料： 当前可访问的文档、查询结果与证据。保留来源、时间和必要的原文。
• 运行状态： 已确认的用户输入、已执行动作、失败原因、待确认事项。不要把计划当作执行记录。

这三类是本站用于教学的组织方式，不是某个协议规定的消息格式。

一份可检查的上下文清单#

当前目标：查询订单 ORD-204 的配送状态
已确认：本轮用户明确改用 ORD-204
尚未确认：是否需要修改地址
已完成动作：查询订单归属，校验通过
可用证据：物流接口响应及其查询时间
下一步限制：只查询；修改地址需要另行确认

该清单的价值是让人能够查错：订单号从哪里来，哪一步执行过，哪句话只是推测。不要在真实系统中相信模型自己填写的“校验通过”；该状态应由执行代码写入。

何时检索，何时压缩#

资料很多时，可以先取与当前问题有关的内容；长任务可以保存结构化笔记或压缩历史。Anthropic 同时指出，压缩过度可能丢失后来才显得重要的细节。1

因此压缩后要核查：明确约束是否还在、已执行动作是否准确、未解决问题是否保留、关键结论能否回到原文。证据编号和文件位置通常比一段无法追溯的总结更便于检查。

上下文够长不等于有效#

“放得下”和“用得对”是两件事。《Lost in the Middle》在其测试条件下观察到信息位置对结果的影响。2 这说明有必要测试自己的输入布局，而不是宣称某个长度以内必然可靠。

本站建议用同一道问题，分别提供精简资料和含干扰信息的资料，比较正确率、引用是否匹配和消耗。再单独测试摘要版本，避免同时更换模型、提示和资料后无法判断原因。

怎么继续排查#

证据根本没进入输入，查 RAG；历史与长期偏好混在一起，查 Memory；模型提出正确动作但执行失败，查 工具调用。