Appearance
🐣 小a的困惑
学完概念篇,小a打开技术社区,当场傻眼——满屏都是"工程":
- Prompt Engineering(提示词工程)
- RAG Engineering(检索增强工程)
- Agent Engineering(智能体工程)
- LLM Engineering / AI Engineering(大模型工程 / AI 工程)
小a慌了:"这些我是不是都得单独学一遍?每个都得重新从零入门?"
老z端起茶杯,慢悠悠地说:"别慌。我先问你一个更基础的问题:这些『engineering』,和咱们搞了四十年的软件工程,到底差在哪?"
小a想了想:"差在……换了个词?"
老z笑了:"你算是说到点子上了。这章我们就来把这层窗户纸捅破。"
I.1 先看软件工程的老骨头
🧙 软件工程干了四十年,核心就这几件事:
活动 要解决的问题 例子 接口设计 系统之间怎么对接、怎么传参 API 设计、函数签名、Schema 状态管理 数据怎么存、怎么流动、怎么恢复 数据库、缓存、会话 错误处理 出错怎么办、怎么恢复 异常、重试、降级、日志 可靠性 挂了怎么不崩、慢了怎么不卡 超时、熔断、监控、告警 测试与验证 怎么证明它是对的 单测、集成测试、回归测试 部署与运维 怎么上线、怎么迭代 CI/CD、发布、回滚 成本与安全 花多少钱、安不安全 配额、鉴权、审计
老z敲了敲黑板:"记住这张表。下面我们看那些花里胡哨的『X Engineering』,拆开之后,装的是什么。"
I.2 逐个对账:每个"新工程"都是软件工程的分工不同
Prompt Engineering = 接口设计 + 测试 + 版本管理
🧙 Prompt 是什么?——是你和模型之间的『接口契约』。
- 写 System Prompt 四要素(角色/能力/规则/边界)= 设计接口的入参规范(第 4 章)
- 写工具描述、参数 schema = 设计接口文档(第 6 章)
- 探针测试、AB 对照、git 管版本 = 接口的测试与版本管理(4.7)
Prompt Engineering 的全部动作,都是『把接口设计好、测好、管好』——只不过这个『接口』的另一头是模型,不是程序。
RAG Engineering = 数据管道 + 检索系统 + 缓存
🧙 RAG 的三步(切块→向量化→检索,第 13 章),拆开看:
- 切块、清洗、入库 = ETL(提取-转换-加载)——数据工程的老活
- 向量索引、Top-K 检索 = 搜索引擎设计——信息检索的老活
- 缓存、更新、过时管理 = 数据管道的运维——缓存工程的老活
RAG Engineering 本质是『给 LLM 造一个知识库系统』——这个系统该怎么做,数据库和搜索引擎早就回答过了。
Agent Engineering = 业务流程 + 状态机 + 并发 + 可观测
🧙 Agent 拆开看(第 7、8、9 章):
- Agent 循环、工具编排 = 业务流程编排(工作流引擎的老活)
- 消息历史、会话持久化、压缩 = 状态管理(状态机 + 持久化的老活)
- 并行工具调用、同文件串行 = 并发控制(操作队列的老活)
- Hooks、事件流、日志 = 可观测性与扩展点(中间件模式的老活)
Agent Engineering 是『把一段业务流程交给模型执行』——流程怎么编排、状态怎么管、并发怎么控,后端工程师闭着眼睛都会。
LLM / AI Engineering = 集成工程 + 可靠性 + 成本
🧙 『AI Engineering』最大的一张皮,底下是:
- 统一调用、Provider 抽象 = 系统集成(适配器模式的老活,第 3 章)
- 超时、重试、限流退避 = 可靠性工程(3.8、附录 E.9)
- token 计费、缓存命中 = 成本工程(1.7、1.12)
- 沙箱、凭据保护 = 安全工程(第 15 章)
AI Engineering 就是把『调一个不稳定、按量计费的远程服务』这件事做到生产级——而『集成外部依赖』『让远程服务可靠』『管住账单』,软件工程做过几十年了。
Context Engineering = 内存管理 + 缓存工程
🧙 Context(上下文)是 LLM 的『内存』(第 1 章的窗口、第 8 章的记忆)。Context Engineering 做的事:
- 窗口满了怎么办(截断 / 压缩 / 滑动窗口)= 内存管理(虚拟内存、GC 的老活)
- 重复前缀不重算(KV 缓存)= 缓存工程(1.12,Redis 那套思路)
- 该带什么、该扔什么(记忆三层、长期记忆)= 数据生命周期管理
Context Engineering = 给一个『有内存上限、按量计费』的运行时做内存管理——操作系统和缓存系统早就把这事讲透了。
Loop Engineering = 状态机 + 事件循环 + 容错
🧙 Agent 循环(第 7 章)的工程问题:
- 循环怎么转、什么时候停(Stop Reason、maxTurns)= 状态机与终止条件
- 一轮失败怎么处理(重试、降级、把错误反馈给模型)= 容错与重试(3.8)
- 事件怎么流转(流式、异步、并发)= 事件循环(Node.js 天天在做的事)
Loop Engineering = 把一个『会自主决定下一步』的状态机做稳、做不卡死——状态机 + 事件循环 + 容错,后端老本行。
Graph Engineering = 工作流引擎
🧙 Graph 编排(第 14 章)的工程问题:
- 节点、边、路由、条件分支 = 工作流引擎(BPMN)
- 循环回路、异常回退 = 流程控制(状态机又来了)
- 可视化、可调试 = 流程可视化
Graph Engineering = 把业务流程图数字化执行——BPM 引擎、工作流中间件做了几十年的事。
Harness Engineering = 测试框架 + 运行时容器
🧙 Harness(支架)在本书出现两次:
- Agent Harness(第 18 章):给裸 Agent『穿衣服』——注入 system prompt、工具、会话 = 依赖注入 + 运行时组装(框架容器那套)
- Evals Harness(第 23 章):把 Agent 跑起来、喂任务、收结果、打分 = 测试框架(Jest/Pytest 的骨架)
Harness Engineering = 造一个『能跑 Agent 的测试/运行架子』——测试框架与运行时容器的老活。
I.3 总对账表:一页看穿
🧙 把八张对账单合成一张:
| 新名词 | 拆开之后 | 对应软件工程的老骨头 | 本书章节 |
|---|---|---|---|
| Prompt Engineering | 把『接口』换成『prompt』 | 接口设计、测试、版本管理 | 第 4 章、6.2 |
| RAG Engineering | 把『知识库』换成『检索增强』 | ETL、搜索引擎、缓存 | 第 13 章 |
| Agent Engineering | 把『流程』交给『模型循环』 | 流程编排、状态机、并发 | 第 5-9 章 |
| LLM/AI Engineering | 把『外部依赖』换成『LLM』 | 集成、可靠性、成本、安全 | 第 3、15 章 |
| Context Engineering | 把『内存』换成『上下文窗口』 | 内存管理、缓存工程 | 第 1、8 章 |
| Loop Engineering | 把『状态机』换成『agent 循环』 | 状态机、事件循环、容错 | 第 7 章 |
| Graph Engineering | 把『流程图』换成『任务图』 | 工作流引擎、流程控制 | 第 14 章 |
| Harness Engineering | 把『测试架子』换成『agent 支架』 | 测试框架、运行时容器 | 第 18、23 章 |
🐣 小a恍然大悟:"所以它们不是新学科,是把软件工程按『跟 LLM 相关的部分』重新切了八刀,各起了个新名字?"
🧙 "对。 新瓶装的,还是那瓶老酒——只不过酒里多了个叫『LLM』的新配方。而这个新配方,才是唯一真正需要重新学的东西。它是什么?下一节。"
I.4 真正的新东西:不确定性
"那有没有什么是软件工程没教过、LLM 才有的?"小a追问。
老z的表情认真起来:"有,而且只有一样——不确定性。"
🧙 确定系统 vs 概率系统:
传统软件(确定性) LLM 应用(概率性) 同一个输入 永远同样的输出 可能不同的输出 错误 能复现、能定位 可能不复现(玄学) 测试 断言"对/错" 评测"好不好"(打分、对比) 调试 断点、日志、栈 观察、重试、降级 修复 改一行代码 改 prompt / 换模型 / 加兜底 上线 测过就能发 测过也可能翻车(概率的事)
🧙 所以『X Engineering』唯一新的一点是:
- 测试变成了评测——不能断言"对错",只能打分、对比、回归(第 23 章的 pi-evals 就是干这个的)
- 调试变成了观察——错误不可复现,只能靠日志、trace、样本分析(附录 E)
- 错误处理变成了兜底——不能靠"修好",只能靠"降级、重试、给模型反馈"(第 3、9 章)
而这三点,恰恰是本书从头到尾一直在讲的。 换句话说:本书讲完的那些概念——接龙、采样、缓存、循环、记忆、Hooks、RAG、评测、安全——加在一起,就是『AI 工程』的全部新内容。没有更多了。
I.5 为什么新名词层出不穷?
🧙 知道原理,再看现象——新名词为什么多?三个原因:
- 领域新,命名还没沉淀:四十年前没有"软件工程"这个词时,也是各叫各的。现在 LLM 应用刚起步,术语混乱是必然阶段
- 市场需要新词:新词 = 新岗位 = 新课程 = 新流量。传播上,"AI 工程"比"把数据库那套活儿搬到 LLM 上"响亮得多
- 工具确实新:虽然原理是老的,但工具链(SDK、框架、平台)是全新的——工具新 ≠ 学科新
老z打比方:"『汽车工程』不是新学科——它只是『机械工程』把动力源从蒸汽换成内燃机。换了个零件,工艺要重新学,但工程原理一个字没变。 LLM 之于软件工程,就是那个『内燃机』。"
I.6 结论:老功夫 + 新变量
🐣 小a最后总结:
"所以我的学习路线应该是——
- 把软件工程的老功夫练熟:接口、状态、错误、测试、部署、成本、安全(不用重新学,但得真会用)
- 把 LLM 的新变量学透:不确定性带来的评测、观察、兜底(这本书讲的就是这个)
- 然后把它们拼起来:遇到任何『X Engineering』,先拆开,看看里面是老骨头多,还是新变量多"
🧙 "孺子可教。 记住这句:遇到带『engineering』的新名词,先问一句——『它和软件工程差在哪?』 差得越少,越是换词;差得越多,越值得学。 绝大多数时候,你会发现差的就是 LLM 那点不确定性——而它,你已经在这本书里学完了。"
本章小结
┌──── 各种 "Engineering" ────┐ │ │ │ • Prompt = 接口设计 │ │ • RAG = 数据管道+检索 │ │ • Agent = 流程+状态+并发 │ │ • LLM/AI = 集成+可靠+成本 │ │ • Context = 内存+缓存 │ │ • Loop = 状态机+容错 │ │ • Graph = 工作流引擎 │ │ • Harness = 测试/运行架 │ │ → 都是软件工程的分工 │ │ │ │ • 真正新的只有一个: │ │ 不确定性 │ │ → 测试变评测、调试变观察 │ │ 错误处理变兜底 │ │ │ │ • 新名词 = 领域新 + 市场 + │ │ 工具新,原理没变 │ │ │ │ • 心法:遇到 X Engineering │ │ 先问"和软件工程差在哪" │ └──────────────────────────────┘
关键认知:各种『X Engineering』不是新学科,而是软件工程按『与 LLM 相关的部分』重新切分后的新名词。真正的新变量只有一个——LLM 的不确定性——它把测试变成评测、调试变成观察、错误处理变成兜底。学会老功夫 + 学透新变量,任何『engineering』都吓不倒你。
参考
- 本书 Part I 概念篇各章:即上文对账表里列的章节
- 附录 E(工程问题排查):不确定性落地为"事故怎么查"
- 附录 D(GoF 设计模式):老功夫在 Agent 里的具体体现