从 Prompt 到 Context，再到 Hardening：一篇更“学术严谨”的LLM工程框架
过去一年，关于大模型（LLM）的讨论，几乎都从 Prompt Engineering（提示工程） 开始。
但越来越多研究表明：
仅靠 Prompt，无法支撑生产级 AI 系统。
在学术界，一个更完整的范式正在逐渐形成：
Prompt Engineering
↓
Context Engineering
↓
System Hardening
这篇文章基于近年来的论文、综述与工程实践，对这一框架做一个更严谨的重构。
一、Prompt Engineering：结构化输入，而不是“写话术”
在研究定义中，Prompt Engineering 的本质是：
对输入进行结构化设计，以控制模型行为与输出质量。
它并不是“会聊天”或者“会写提示词”，而是一种：
- 输入约束（input conditioning）
- 推理引导（reasoning guidance）
- 输出控制（output shaping）
常见方法包括：
- Chain-of-Thought（CoT，思维链）
- Self-Consistency（自一致性）
- Few-shot Prompting
- Prompt Pattern（模式化模板）
其共同目标是：
提升模型在“已有信息条件下”的推理与表达能力。
Prompt Engineering 的核心边界
很多人容易误解 Prompt 的能力。
但大量论文都反复强调一个事实：
Prompt Optimization 不会增加模型知识，
只是在更好地利用已有上下文。
也就是说：
- Prompt 可以优化“表达”
- Prompt 可以优化“推理路径”
- Prompt 不能凭空创造知识
因此：
Prompt ≠ Knowledge
Prompt = Structured Access to Existing Context
这也是为什么：
- Prompt 调得越来越复杂
- 模型却依然会幻觉（hallucination）
因为真正的问题，往往不是“怎么问”，而是：
模型到底看到了什么信息。
二、Context Engineering：从“写 Prompt”到“构造输入系统”
近年来的综述开始明确提出：
Context Engineering 是系统性优化 LLM 输入信息载荷（information payload）的工程体系。
相比 Prompt Engineering，它不是“Prompt 的升级版”，而是：
工程范式的变化。
Context Engineering 的学术定义
目前较被接受的理解是：
Context Engineering = 管理模型在推理时看到的全部信息环境。
这里的 “Context” 不只是 Prompt，而是：
- Prompt（只是其中一部分）
- 对话历史（Memory）
- RAG 检索结果
- Tool Calling 返回结果
- 系统指令（System Prompt）
- 输入结构
- Context Window 管理
换句话说：
Prompt Engineering ⊂ Context Engineering
Prompt 是 Context 的局部形式。
为什么 Context Engineering 更重要？
研究越来越倾向于一个观点：
LLM 本质上是一个对 Context 的函数。
即：
Output = f(Context)
输出质量高度依赖输入信息质量。
因此：
- 信息缺失 → 幻觉
- 信息冲突 → 推理错误
- 信息冗余 → 注意力分散
- 信息结构混乱 → 工具调用失败
很多论文甚至将 Context Engineering 总结为：
“在上下文窗口中放入恰到好处的信息”。
关键不是：
More Context
而是：
Right Context
Context Failure：四类典型上下文失败
研究中常见的上下文问题可以归纳为四类：
| 类型 | 含义 |
|---|---|
| Context Poisoning | 错误信息污染 |
| Context Distraction | 信息过多导致注意力干扰 |
| Context Confusion | 信息被错误引用或误关联 |
| Context *** | 多来源信息互相冲突 |
这说明：
Context 并不是越多越好。
真正重要的是：
- 信息质量
- 信息排序
- 信息相关性
- 信息结构
三、Hardening：从“效果优化”到“系统可靠性工程”
学术论文中虽然不总直接使用 “Hardening” 这个词，但相关问题已经成为研究重点。
其核心目标是：
让 LLM 系统在真实环境中“可控、可靠、可接受”。
1. Security：安全问题
研究表明：
LLM 系统容易受到 Prompt Injection 攻击。
攻击者可能通过输入：
- 覆盖系统 Prompt
- 泄露敏感数据
- 操控工具调用
- 绕过安全策略
因此：
LLM ≠ 天然安全
生产系统必须有：
- 输入过滤
- 权限隔离
- Tool Sandbox
- Policy Enforcement
2. Robustness：鲁棒性问题
论文发现：
- 模型对异常输入敏感
- 长上下文会导致性能下降
- 多轮对话会累积错误
- Context Poisoning 会逐步恶化系统行为
这意味着：
模型效果不等于系统稳定性。
实验室 Demo 能跑，
不代表生产环境能长期稳定运行。
3. Reliability：可靠性问题
真实工程里还必须解决：
- 输出格式漂移
- JSON 不合法
- Tool Calling 失败
- 推理结果不一致
- 长链 Agent 崩溃
因此：
Hardening 的目标不是“更聪明”，而是：
更稳定、更可预测。
一个更严谨的 Hardening 定义
结合研究与工程实践，可以将其定义为：
Hardening = 面向真实环境的系统级控制层，
确保 LLM 输出“可控、可靠、可接受”。
注意三个关键词：
| 关键词 | 含义 |
|---|---|
| 可控 | 不被攻击、不被操纵 |
| 可靠 | 稳定运行、不随机崩溃 |
| 可接受 | 不越界、不胡说 |
四、关键修正：Hardening 不负责“更好答案”
这是整个框架里最容易混淆的一点。
很多讨论会误把 Hardening 理解为：
“让模型输出更理想答案”
但从研究视角，更准确的划分应该是：
| 层级 | 主要作用 |
|---|---|
| Prompt | 提升表达与推理 |
| Context | 提供知识与信息 |
| Hardening | 控制系统行为边界 |
因此：
好不好 → Prompt + Context
稳不稳 → Hardening
Hardening 不负责“更聪明”。
Hardening 负责的是：
- 不失控
- 不越界
- 不崩溃
- 不被攻击
五、三层统一框架（学术 + 工程融合）
一个更完整的结构可以表达为：
Hardening（系统控制层）
└── Context Engineering（信息构造层）
└── Prompt Engineering（表达控制层）
这意味着：
- Prompt 是最底层的表达控制
- Context 是系统级信息组织
- Hardening 是外层行为约束
三者并不是替代关系，而是：
逐层包裹的工程体系。
六、一个更“论文级”的理解方式
如果把 LLM 抽象成一个函数：
Output = f(Context)
那么：
| 概念 | 本质 |
|---|---|
| Prompt | Context 的局部结构控制 |
| Context Engineering | 构造函数输入 |
| Hardening | 限制函数行为范围 + 保证执行稳定 |
这个视角的重要意义在于：
LLM 工程的核心，不再只是“生成文本”，而是“管理上下文系统”。
七、为什么这套框架正在成为主流？
近年来的研究逐渐形成共识：
1. Prompt Engineering 是起点，但不是终点
Prompt 很重要。
但 Prompt 更像：
局部优化（local optimization）
它无法单独解决：
- 知识缺失
- 长上下文管理
- 多工具协调
- 系统安全
- 生产稳定性
2. Context Engineering 正在成为核心工程问题
越来越多观点认为：
Context Engineering 是 LLM 时代的软件工程。
因为 AI 系统的关键挑战，
已经从：
“如何生成”
变成：
“如何组织模型看到的信息”
3. Hardening 决定系统能否上线
很多 Demo 看起来“很聪明”。
但真正上线时暴露的问题往往是：
- 被注入攻击
- 输出不稳定
- 工具调用失控
- 多轮对话崩坏
- 格式漂移
因此：
Hardening 才是 AI 产品化的最后门槛。
八、最终总结（修订版）
可以用一句话概括整个框架：
| 层 | 作用 |
|---|---|
| Prompt | 决定“怎么表达” |
| Context | 决定“有什么信息” |
| Hardening | 决定“系统是否可靠、可控” |
或者更工程一点：
好不好，是 Context + Prompt
能不能上线，是 Hardening
如果你正在做 AI 产品，这三层缺一不可。
否则你会发现：
Prompt 越调越精细，
系统却依然“不稳定、不可信、不可控”。
浙公网安备 33010602011771号