AI 工程学科全景
是什么
围绕大语言模型（LLM）的工程实践，已经分化出十余个独立的工程学科。它们可以归纳为两条并行演化的主线：
- 沟通线：人怎么把意图传给模型（Prompt → Context → Memory）
- 控制线：人怎么驾驭模型的行为（Evaluation → Alignment → Guardrails → Harness）
这两条线不是独立的——沟通越深入，需要的控制就越复杂。
为什么需要这张全景图
当你学完 LLM 原理 和 Transformer 架构 之后，会发现”让 AI 真正可用”远不止理解模型本身——你还需要知道怎么跟它沟通、怎么控制它、怎么让它稳定地服务于生产环境。
每种工程学科的诞生都遵循同一个模式：
模型能力突破 → 暴露新痛点 → 催生新工程学科
全景分类
三层总览
| 层面 | 包含学科 | 核心问题 |
|---|---|---|
| 沟通层 | Prompt / Context / Memory | 怎么让模型理解我要什么 |
| 控制层 | Evaluation / Alignment / Safety / Guardrails / Harness | 怎么让模型行为可控 |
| 基础设施层 | RAG / Vector / Inference / Agent / LLMOps | 怎么让模型跑得稳、跑得快、做得多 |
完整学科表
| 工程学科 | 主线 | 一句话定义 | 核心时期 |
|---|---|---|---|
| Fine-tuning Engineering | 沟通 | 用数据改变模型权重 | 2018-2020 |
| Prompt Engineering | 沟通 | 设计输入文字的措辞和结构 | 2020-2023 |
| System Prompt Design | 沟通 | 设计系统级行为规则 | 2023 |
| Context Engineering | 沟通 | 管理模型看到的全部信息 | 2024-2025 |
| Memory Engineering | 沟通 | 跨会话的记忆管理 | 2025- |
| Evaluation Engineering | 控制 | 量化模型能力 | 2020- |
| Alignment Engineering | 控制 | 对齐模型价值观 | 2022- |
| Safety / Red Teaming | 控制 | 对抗性安全测试 | 2023- |
| Guardrails Engineering | 控制 | 约束输出行为和格式 | 2024- |
| Harness Engineering | 控制（总称） | 全链路驾驭 AI 系统 | 2025- |
| RAG Engineering | 基础设施 | 检索增强生成 | 2023- |
| Vector Engineering | 基础设施 | 向量检索优化 | 2023- |
| Inference Engineering | 基础设施 | 推理性能优化 | 2020- |
| Agent Engineering | 基础设施 | 自主任务执行 | 2024- |
| LLMOps | 基础设施 | 生产环境运维监控 | 2023- |
主线 A：沟通线演化
演化逻辑
模型越来越强，“怎么跟它沟通”从一句话的措辞技巧，升级为整个信息系统的架构设计。
控制一句话 → 控制一组规则 → 控制一个信息空间 → 控制一个记忆系统
第一代：Prompt Engineering（2020-2022）
痛点：GPT-3 发布后，人们发现”怎么问”比”问什么”更重要——同一个问题换个问法，结果天差地别。
核心思路：精心设计那一段输入文字。
演化路径：
Zero-shot（直接问）
↓ 效果不稳定
Few-shot（给几个示例）
↓ 复杂推理仍然出错
Chain-of-Thought（让模型"一步步想"）
↓ 需要更系统化的结构
Role + Instruction + Format（角色设定 + 指令 + 输出格式）
典型技巧：
| 技巧 | 示例 | 解决的问题 |
|---|---|---|
| Few-shot | ”示例1… 示例2… 现在回答：“ | 模型不理解任务格式 |
| Chain-of-Thought | ”请一步步思考” | 模型跳步导致推理出错 |
| Role Prompting | ”你是一位资深前端工程师” | 模型回答太泛，缺乏专业深度 |
| Output Format | ”用 JSON 格式输出，字段为…” | 输出格式不可控 |
局限：你只能控制”一段文字”。当任务变复杂（需要参考文档、记住历史、调用工具），一段 Prompt 装不下所有信息。
更多技巧详见 04-Prompt Engineering。
第二代：System Prompt Design（2023）
痛点：ChatGPT 引入 System/User/Assistant 角色分离后，开发者有了”永久生效”的指令位，但 System Prompt 越写越长，模型对长指令的遵循率下降。
核心转变：从”写一条好问题”变成”设计一套系统级规则”。
典型结构：
System Prompt（开发者写，用户看不到）
├── 角色定义：你是XXX，擅长YYY
├── 行为规则：不做什么、拒绝什么
├── 输出规范：格式、语言、长度
├── 知识边界：不确定时说"我不知道"
└── 工具说明：可调用哪些 Function
User Message（用户输入）
Assistant Response（模型输出）
第三代：Context Engineering（2024-2025）
痛点：模型上下文窗口扩展到 128K-1M Token，RAG、Agent、多轮对话让”模型实际看到的内容”变得极其复杂。真正决定输出质量的不是 Prompt 那几句话，而是整个 Context Window 里塞了什么。
核心定义：
Context Engineering = 系统性地设计和管理 LLM 推理时能看到的全部信息。
与 Prompt Engineering 的区别：
| 维度 | Prompt Engineering | Context Engineering |
|---|---|---|
| 关注范围 | 用户输入的那段文字 | 整个上下文窗口 |
| 核心问题 | ”怎么措辞" | "放什么进去、不放什么、按什么顺序放” |
| 技能性质 | 文案/语言技巧 | 信息架构/系统设计 |
| 难度来源 | 找到好的表达方式 | 在有限窗口内做信息取舍和优先级排序 |
Context Window 里的信息源：
┌──────────────────── Context Window（如 128K Token）────────────────────┐
│ │
│ ┌──────────────┐ ┌─────────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ System Prompt │ │ RAG 检索结果 │ │ 对话历史 │ │ 工具调用结果 │ │
│ │ （规则/角色） │ │ （外部知识） │ │ （记忆） │ │ （实时数据） │ │
│ └──────────────┘ └─────────────┘ └──────────┘ └──────────────┘ │
│ │
│ ┌──────────────┐ ┌─────────────┐ │
│ │ Few-shot 示例 │ │ 用户当前输入 │ │
│ │ （行为锚定） │ │ （本轮请求） │ │
│ └──────────────┘ └─────────────┘ │
└────────────────────────────────────────────────────────────────────────┘
核心挑战：
- 优先级排序：窗口有限，放了 RAG 文档就得压缩历史对话，怎么取舍？
- 注意力衰减：模型对中间位置的信息关注度最低（Lost in the Middle 现象），关键信息放头还是放尾？
- 格式效率：同样的信息用 Markdown 还是 JSON？哪个消耗更少 Token？
第四代：Memory Engineering（2025-）
痛点：Agent 需要跨多轮甚至跨会话维持状态，128K 窗口装不下数天的工作记忆。
核心问题：什么该记住、什么该忘记、什么时候该想起来。
| 方向 | 做法 | 代表 |
|---|---|---|
| 摘要压缩 | AI 自动总结前文，用摘要替代原文 | ChatGPT Memory、Claude Projects |
| 外部记忆存储 | 关键信息写入数据库，需要时检索 | MemGPT、Zep |
| 分层记忆 | 短期 + 长期 + 工作记忆 | LangGraph、AutoGen |
| 选择性遗忘 | 主动丢弃不再相关的上下文 | 尚未成熟 |
主线 B：控制线演化（Harness Engineering）
演化逻辑
模型越来越自主，“怎么确保它不出格”从简单的评分，升级为全链路的驾驭体系。
Harness Engineering（驾驭工程） 不是一个独立的学科，而是控制线所有学科的上层统称——就像”软件工程”统称了前端/后端/测试/运维一样。
┌────────────── Harness Engineering（AI 驾驭工程）──────────────┐
│ │
│ ┌───────────┐ ┌───────────┐ ┌──────────┐ ┌───────────┐ │
│ │ Evaluation │ │ Alignment │ │ Safety & │ │ Guardrails│ │
│ │ 评估工程 │ │ 对齐工程 │ │ Red Team │ │ 护栏工程 │ │
│ │ │ │ │ │ 安全工程 │ │ │ │
│ │ 能力几分？ │ │ 价值观对？│ │ 能被攻破？│ │ 输出可控？│ │
│ └─────┬─────┘ └─────┬─────┘ └────┬─────┘ └─────┬─────┘ │
│ └──────────┬────┴─────────────┴──────────────┘ │
│ ▼ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ LLMOps（可观测性 + 生产运维） │ │
│ └──────────────────────────────────────────────────┘ │
└───────────────────────────────────────────────────────────────┘
各子学科的演化
| 阶段 | 子学科 | 触发事件 | 核心问题 |
|---|---|---|---|
| 2020 | Evaluation | GPT-3 发布，模型越来越多 | ”这个模型到底行不行？“ |
| 2022 | Alignment | ChatGPT 上线，模型直面大众 | ”模型会不会说有害的话？“ |
| 2023 | Safety / Red Teaming | 越狱攻击泛滥 | ”模型能被诱导绕过限制吗？“ |
| 2024 | Guardrails | 企业大规模落地 | ”输出的格式和内容可控吗？“ |
| 2025 | Harness（全链路） | Agent 自主执行任务 | ”没人盯着的情况下还可靠吗？“ |
为什么 Agent 时代 Harness 变得关键
- Prompt 时代：人打一句话，模型回一句话——出了错，人马上看到
- Agent 时代：模型自主规划 10 步，每步调用工具，执行数分钟——出了错，可能已经造成了不可逆后果（删了文件、发了邮件、调了 API）
Agent 的自主性越高，Harness 的重要性越高。
代表性工具
| 子学科 | 代表工具/框架 |
|---|---|
| Evaluation | lm-evaluation-harness（EleutherAI）、HELM（Stanford） |
| Alignment | RLHF、DPO、Constitutional AI |
| Safety | Red teaming frameworks、内容过滤系统 |
| Guardrails | Guardrails AI、NeMo Guardrails |
| LLMOps | LangSmith、Arize Phoenix、Weights & Biases |
两条主线的交叉关系
两条线在关键节点互相驱动：
沟通线进步 → 触发控制线需求：
- Prompt 变复杂了 → 需要 Evaluation 量化哪种 Prompt 更好
- Context 引入 RAG → 需要 Guardrails 验证检索结果是否被正确使用
- Memory 跨会话持久 → 需要 Safety 确保记忆不被投毒
- Agent 自主执行 → 需要 Harness 全链路可观测可回滚
控制线成果 → 反哺沟通线改进：
- Evaluation 发现弱项 → 针对性改进 Prompt/Context 策略
- Red Team 找到漏洞 → 在 System Prompt 加入防御指令
- Guardrails 拦截异常 → 反馈到 Context 动态调整信息源
问题驱动的完整演化时间线
第一阶段：基础架构期（2017-2019）
痛点：RNN/LSTM 处理长文本时”记忆衰减”，100 个词之前的内容模型几乎”忘了”。
解法：Transformer 用自注意力机制让每个词能直接看到所有其他词。
衍生：Fine-tuning Engineering——BERT 证明了”预训练 + 微调”范式，但每个 NLP 任务都需要单独微调一个模型。
第二阶段：规模涌现期（2020-2022）
痛点：每个任务都要微调太贵太慢，能不能一个模型搞定所有任务？
解法：GPT-3（1750 亿参数）证明不需要微调，只需 Few-shot 就能理解新任务。
衍生：
- Prompt Engineering：怎么问决定回答质量
- Inference Engineering：1750 亿参数推理太贵，需要量化、缓存等优化
- Evaluation Engineering：模型越来越多，需要标准化评估谁更好
第三阶段：对话普及期（2022-2023）
痛点：GPT-3 会续写但不会对话，它不分好坏，可能输出有害内容。
解法：ChatGPT 通过 RLHF 让模型学会”像助手一样对话”。
衍生：
- Alignment Engineering：模型没有价值观，需要 RLHF/DPO 对齐
- Safety / Red Teaming：越狱攻击泛滥，需要对抗性测试
第四阶段：企业落地期（2023-2024）
痛点：企业想用 LLM，但模型不知道公司内部数据，且幻觉严重。
解法：RAG 范式——先从企业知识库检索，把结果塞进 Context 让模型”带着参考资料回答”。
衍生：
- RAG Engineering：文档分块 → Embedding → 向量检索 → 生成
- Vector Engineering：RAG 效果严重依赖向量检索质量
- Guardrails Engineering：企业要求输出格式可控、内容可审计
- LLMOps：从 Demo 到生产需要版本管理、监控、A/B 测试
- Context Engineering：RAG + 历史 + 工具 = Context Window 管理变成系统级问题
第五阶段：自主 Agent 期（2024-2025）
痛点：LLM 只能一问一答，完成不了多步骤复杂任务。
解法：Agent 架构——规划、工具调用、记忆、多 Agent 协作。
衍生：
- Agent Engineering：ReAct、Function Calling、多 Agent 编排
- Memory Engineering：Agent 需要跨会话维持状态
- Harness Engineering（全链路）：Agent 无人值守时的可靠性保障
演化规律总结
| 能力突破 | 暴露的痛点 | 催生的工程 |
|---|---|---|
| Transformer 让模型变大 | 每个任务都要微调 | Fine-tuning |
| GPT-3 证明规模涌现 | 怎么有效地”问” | Prompt Engineering |
| ChatGPT 走向大众 | 怎么保证安全和正确 | Alignment / Safety / Evaluation |
| 企业要用自己的数据 | 怎么让模型知道私域知识 | RAG / Vector / Context |
| 模型要自主完成任务 | 怎么让模型可靠地规划和执行 | Agent / Memory / Harness |
| 生产环境要稳定运行 | 怎么管理和监控 | LLMOps |
底层规律：随着模型能力增强、应用场景复杂化，工程关注点从语言层逐步上移到信息架构层再到状态管理层。
延伸阅读
- 01-LLM 原理：理解 LLM 的基本工作机制
- 04-Prompt Engineering：沟通线第一代工程的详细实践
- 05-RAG 原理：基础设施层核心学科
- 06-Agent 原理：自主执行任务的架构设计
- 07-模型训练与对齐：控制线中 Alignment 的详细机制