Context Engineering：比 Prompt Engineering 更完整的工程方法

当模型回答不好时，人们最先想到的是改 Prompt：增加角色、补充规则、提供示例。但在 Agent 系统里，失败往往不是因为某句话写得不够巧，而是模型根本没有看到正确事实，或者看到了太多互相冲突的信息。

这就是 Context Engineering 出现的原因。它把问题从“应该怎样措辞”扩大为“在这一次推理中，模型应该看到怎样的世界”。

What：Context 到底包括什么

从模型接口看，Context 是采样下一 Token 时可见的全部输入。它可能包括系统规则、用户目标、历史消息、记忆、检索文档、工具 Schema、工具结果、当前计划、环境信息和输出约束。

这些内容来自不同模块，却共享同一个有限注意力预算。Context Engineering 就是设计它们的加载、筛选、排序、压缩、隔离和生命周期，使最少的高信号 Token 最大化正确行为的概率。

Prompt Engineering 仍然重要，但 Prompt 只是 Context 的一个来源。即使系统提示词完美，如果注入的是旧文档、错误工具结果或另一个用户的记忆，模型仍会失败。

直觉上，窗口越大，越可以把所有资料一次交给模型。但容量不等于利用率。

更多上下文带来更高的延迟与成本，也带来信息污染：过期规则、重复日志和无关文档会竞争注意力。相关研究曾观察到长上下文中的位置偏差；新模型在简单事实检索上不断改善，但“找得到某句话”与“能在复杂推理中正确使用它”仍不是同一问题。

更关键的是，未来相关性无法在任务开始时完全预测。一次代码调查可能先发现配置问题，随后才需要加载部署脚本。预先塞入整个仓库既昂贵，也会隐藏结构。Agent 更适合保留文件路径、查询和索引等轻量引用，在需要时逐步读取。

它首先解决信息选择：哪些事实必须始终存在，哪些按查询召回，哪些只在某个工具调用后短暂出现。

其次解决信息排序：冲突时谁更可信？当前代码通常优先于旧文档，用户明确指令优先于模型推测，原始工具结果优先于后来生成的摘要。

再次解决持续性：长任务跨越多个窗口后，如何保留目标、架构决定、未解决问题与最新进展，而不携带全部冗余轨迹。

最后解决隔离：不同用户、任务和子 Agent 应看到哪些信息，不可信文档能否影响工具权限和系统规则。

一次可靠装配通常经历：

候选信息源
→ 身份与作用域过滤
→ 相关性和新鲜度选择
→ 冲突与去重
→ 按优先级分配 Token Budget
→ 渲染为模型消息
→ 记录最终请求快照

最后一步经常被忽略。开发者看到数据库里有一条记忆，不等于它真的进入了模型请求。只有保存或观测最终装配结果，才能证明某个规则在运行时生效。

Compaction 把早期轨迹压缩成高保真摘要，保留目标、决策、未解决问题和关键引用。它维持连续性，但压缩是有损的，后来才显得重要的细节可能已经消失。

结构化笔记让 Agent 主动维护计划、发现和交接文档。它比自由摘要更容易检查，却要求模型有稳定的写入纪律，并防止错误笔记成为新事实源。

子 Agent 隔离让不同探索在独立窗口中进行，主 Agent 只接收浓缩结果。它扩展了总体认知容量，但引入通信损耗与整合问题。

最实用的系统通常混合三者：核心规则和用户目标预加载，具体资料即时检索，长历史定期压缩，复杂支线交给隔离的子 Agent。

Prompt Injection 本质上也是上下文治理问题。网页中的一句“忽略之前规则”只是数据，却可能被模型解释为指令。如果系统仅靠另一句更强硬的 Prompt 抵抗，安全边界仍建立在概率行为上。

更可靠的做法是标记来源与信任级别，让外部内容不能改变工具权限；危险操作由确定性策略拦截；子 Agent 只获得最小能力；检索在权限过滤后发生。Context 决定模型相信什么，Capability 决定模型能够做什么，两者必须分离。

过度工程同样危险。复杂的检索、排序和压缩链路可能比任务本身更脆弱，错误更难定位。很多简单应用只需要清晰 Prompt 和少量资料，不需要建设完整记忆平台。

另一个反模式是把业务规则全部藏进长 Prompt。规则需要确定执行时，应该进入代码、Schema 或权限系统，而不是期待模型每次都理解并遵守。

Context Engineering 也可能形成模型特定优化：为某个模型精调的消息顺序和工具描述，换模型后不一定成立。系统需要回归评估，而不是把最佳实践当成永恒规则。

我们仍缺少对 Context 价值的因果测量。一段信息被注入后，模型是否真正使用？失败是因为缺失、噪声、位置还是模型能力？仅凭最终答案很难归因。

工程上可以建立 Context Trace：记录每个片段的来源、选择原因、Token 成本和生命周期，并通过遮蔽实验判断贡献。移除某段信息后结果不变，说明它可能只是噪声；移除后稳定失败，才说明它是关键依赖。这比根据直觉不断增加 Prompt 更接近实验方法。

未来值得研究的是动态 Context Policy：让系统根据任务阶段、模型能力和历史效果学习何时检索、何时压缩、何时遗忘，同时保证权限和审计不被学习策略绕过。

我认为 Context Engineering 是 AI 工程从“调语言”走向“管理认知状态”的标志。它不追求把所有信息交给模型，而是持续构造最小、可信、足够的世界切片。

衡量它是否有效的标准也很朴素：模型是否更少依赖猜测，关键事实是否能够追溯，信息过期后是否及时退出上下文，任务拉长后目标是否仍然稳定。上下文不是越丰富越好，而是越接近当前决策所需越好。

最终，Context 的质量应当能够被观测和实验验证，而不只是依赖提示词作者的经验。