AI 工程化 / Agent / Dify / RAG 原理大纲
这份你要建立的不是“会几个 AI 词”，而是：
模型能力为什么不能直接裸接业务 -> AI 系统为什么需要工程化 -> Agent / Dify / RAG 各自解决哪一层问题
一、总纲
这一块最核心的 6 条主线：
- AI 工程化为什么存在
- 模型服务化和业务服务的边界
- Agent 的本质
- Dify 的位置
- RAG 与向量数据库的本质
- 如何把这些挂回你的项目和研发流程
二、为什么 AI 需要工程化
核心问题
模型能力不是普通 API，它有这些特性：
- 不确定性更高
- 输出质量波动更大
- 成本更敏感
- 时延更敏感
- 上下文依赖更强
所以不能只做到“能调通”，还要做到：
- 可控
- 可观测
- 可评估
- 可回滚
三、模型服务化原理
1. 为什么模型服务和业务服务要分层
因为它们：
- 生命周期不同
- 资源模型不同
- 扩缩容方式不同
- 版本治理方式不同
2. 业务服务应该负责什么
- 参数整理
- 上下文拼装
- 调用编排
- 超时 / 重试 / 降级
- 结果落库与日志
3. 模型服务应该负责什么
- 推理
- 模型版本
- 资源管理
四、Prompt 工程本质
Prompt 工程不是“写几句提示词”，而是：
- 任务目标建模
- 上下文组织
- 约束定义
- 输出结构设计
- 异常场景处理
这也是为什么你在研发里会把 AI 用在需求拆解、单测、文档整理，而不是只做一次生成。
五、Agent 原理链
1. Agent 为什么不等于一次大模型调用
因为 Agent 至少包含：
- 目标
- 状态
- 工具
- 多步骤决策
- 校验
- 回退
2. Agent 在解决什么问题
解决多步骤任务的动态编排问题。
3. Agent 最难的地方
- 上下文是否充分
- 工具是否可靠
- 结果是否可验
- 中间状态如何管理
六、工作流和 Agent 的边界
工作流
更确定、路径固定、容易治理。
Agent
更动态、灵活，但不确定性更高。
这句话很稳
工作流偏确定性流程引擎，Agent 偏动态执行体。
七、Dify 的本质位置
Dify 在解决什么
它更像：
- AI 应用编排层
- 原型验证层
- 工作流可视化层
它不适合替代什么
不适合替代：
- 强状态业务系统
- 深度定制的核心后端逻辑
- 复杂事务主链路
为什么
因为这些场景需要更细粒度的工程控制和服务治理。
八、RAG 原理链
1. RAG 为什么存在
因为模型本身知识不是永远最新，也容易幻觉。 RAG 通过检索把外部知识引进来。
2. RAG 的核心链路
- 切片
- embedding
- 向量索引
- topK 召回
- 重排
- 上下文拼装
- 生成
3. 真正难点
不是“接一个向量库”，而是：
- 知识切片质量
- 检索质量
- 上下文控制
- 引用约束
九、向量数据库的本质
1. 它在解决什么
语义相似检索。
2. 为什么不能替代 MySQL
因为：
- MySQL 负责业务主数据
- 向量数据库负责语义召回
两者不是同一层。
3. 为什么也不能简单替代 ES
因为：
- ES 更偏关键词 / 全文检索
- 向量库更偏语义检索
实际系统里可能两者并存。
十、AICG 的工程化本质
生成内容不是重点，重点是：
- 质量怎么控
- 成本怎么控
- 风险怎么控
- 审计怎么做
- 人工兜底怎么做
这才是 AICG 真正落地时会被问的点。
十一、结合你的项目怎么讲
海外业务平台
AI 能力在这里不是独立项目，而是要和识别、鉴定、订阅、支付、后台和归因一起协作。
研发流程
你对 AI 的实际使用更偏：
- 需求拆解
- 单测生成
- 文档整理
- 代码理解
- Agent 协作
这也属于 AI 工程化落地，只是落点在研发流程而不是终端产品。
十二、你最适合的结尾表达
我对 AI 工程化、Agent、Dify 和 RAG 的理解，不是停留在概念，而是把它们放在系统分层里看。模型服务负责推理能力，业务服务负责编排和治理，Agent 负责动态任务执行，Dify 更像编排与验证层，RAG 和向量数据库负责知识召回。真正落地时，核心永远是可控、可观测、可评估。