大模型进阶·之五：LLM 工程化：Prompt、RAG、Agent 与评估
模型能回答，不代表系统能交付。
真正的工程化，是让输出可验证、可重试、可追踪、可回滚。
先把边界说清楚
Prompt、RAG、Agent 这几个词经常被混在一起讲。
其实它们解决的是不同问题：
- Prompt：让模型更清楚任务要求。
- RAG：让模型先查资料，再回答。
- Agent：让模型在多个工具和步骤之间自动协调。
如果你一开始就上 Agent，通常会把系统搞复杂。
更稳的顺序是：先 Prompt，再 RAG，再考虑 Agent。
Prompt 不是咒语
一个好 Prompt 不是“写得长”，而是“写得明确”。
你通常要写清楚这些东西：
- 角色是谁
- 任务是什么
- 输入边界在哪里
- 输出格式是什么
- 不允许做什么
对嵌入式工程师来说，这和给模块写接口说明很像。
接口越模糊，后面的系统越难控。
Structured Outputs 和工具调用
现在很多大模型接口都支持结构化输出和工具调用。
这类能力的意义是：让模型输出不只是自然语言，而是能被程序直接处理的结构化结果。
你可以把它理解成：
- 以前：模型吐一段话，程序再去猜意思
- 现在：模型直接吐 JSON、字段或工具参数
这对工程落地非常关键，因为它让：
- 校验更容易
- 失败更容易重试
- 下游流程更容易自动化
RAG 是先找资料，再回答
RAG 的核心不是“把知识塞进模型”，而是“先从外部知识库取回相关内容，再让模型基于这些内容回答”。
RAG 典型流程可以拆成：
- 切分文档
- 建索引
- 检索相关片段
- 重新排序或过滤
- 把检索结果交给模型生成答案
这套流程很像嵌入式里的“先采集、再滤波、再判断、再输出”。
不是单点神奇，而是链路工程。
Agent 要慎用
Agent 适合“步骤多、工具多、路径不固定”的任务，但它不是默认答案。
什么时候适合上 Agent？
- 需要自动调用多个工具
- 需要根据中间结果决定下一步
- 任务流程相对复杂
什么时候不适合？
- 任务其实很固定
- 输出必须高度稳定
- 失败成本比较高
一句话：能不用 Agent 的地方，先别用 Agent。
评估和护栏不能少
工程化真正的底座，是评估。
你至少要有：
- 固定测试集
- 关键场景回放
- 输出格式校验
- 失败重试策略
- 风险输出拦截
如果没有评估，你很难知道改了一版 Prompt、换了一个模型、改了一个检索策略之后，到底是变好了还是变坏了。
嵌入式工程师的视角
你可以把 LLM 工程理解为一个高层控制系统：
- Prompt 是控制指令
- RAG 是外部传感器和知识补给
- Agent 是任务调度器
- 结构化输出是接口契约
- 评估是回归测试
这套理解一旦建立，你会发现自己不是在“追 AI 热点”，而是在做新一代系统集成。
下一步
下一篇我们从架构师的角度，把部署、LLMOps、数据治理、边缘推理和成本控制串起来。
这一步决定了你能不能把模型系统真正跑起来。