把 AI / LLM 压成一张结构图：我如何理解一个完整的 AI 系统

很多人在学习 AI / LLM 时，容易陷入一种“知识点越来越多，但脑子里没有地图”的状态。

今天看 Transformer，明天看 RAG，后天看 Agent，再过几天又开始研究 Memory、Tool Calling、Evaluation。每个词都认识，但一旦要把它们放进同一个系统里，就会立刻变得模糊。

我最近更倾向于用一种结构化的方式来理解这件事：

不把 AI 看成一次模型调用，而是把它看成一个完整系统的设计问题。

这篇文章想做的事情，就是把这些分散的知识压缩成一张可以随时展开的“认知结构图”。
它既适合复习，也适合做技术判断，更适合沉淀成个人知识库。

一条主线：一个 AI 系统到底是怎么工作的

先把最重要的主线固定下来。

一个典型 AI 系统，从输入到输出，大致会经历这样一条链路：

用户问题
→ Prompt 设计
→ 模型推理
→ 外部增强（RAG / Tools）
→ Agent / Workflow 调度
→ Memory 参与
→ 输出生成
→ Evaluation 验证

这条链并不意味着每一步都必须存在。
它的意义在于：以后你遇到任何 AI 系统问题，都可以先判断它属于这条链上的哪一段。

换句话说，很多讨论看似复杂，本质上都只是以下几类问题之一：

模型本身能力够不够
输入接口设计得好不好
是否需要外部知识或工具补充
系统流程应该固定还是动态
状态应该如何保存与检索
结果有没有被验证和评估

一旦这条主线在脑子里建立起来，很多零散概念就不再是散点，而会自动挂到系统结构上。

五大模块：从“会调用模型”到“理解系统”

为了让这条主线更清晰，我通常会把 AI / LLM 系统拆成五个核心模块，再加上一层工程保障。

每一层都只回答一个问题：

它到底在解决什么问题？

1. 模型层：模型本身到底会什么

模型层讨论的是最底层能力，也就是：

这个模型天然能做什么，不能做什么。

1.1 Transformer / Attention 为什么重要

如果把现代 LLM 的能力基座压缩成几个关键词，那么最核心的一组一定是：

并行计算
全局依赖建模
上下文关联

传统 RNN 的问题，在于序列处理方式决定了它很难高效建模长距离依赖。
而 Transformer 借助 Attention，把“序列中的每个 token 如何关注其他 token”这件事显式建模出来，于是语言建模能力一下子被拉高了。

这也是为什么后来几乎所有大模型讨论，最终都会回到 Transformer 这条技术主线上。

1.2 SFT：让模型学会“按接口工作”

预训练模型具备的是广义语言能力，但它未必知道如何按任务要求输出。
SFT（监督微调）做的事情，本质上是：

把任务接口写进模型。

比如问答、摘要、分类、代码生成、对话式响应，这些并不只是“知识”，而是输出格式、行为模式、任务习惯。
SFT 让模型更像一个可用系统，而不只是一个会续写文本的概率机器。

1.3 RLHF / DPO：让输出更符合人类偏好

再往上走，就会进入对齐问题。

模型会回答，不代表回答“可用”；
模型会生成，不代表生成“可信”。

RLHF 或 DPO 关注的是让输出更符合人类偏好，包括：

更安全
更稳定
更符合指令
更少冒犯性内容
更接近期望语气与风格

这一层不必陷入论文细节，但需要建立一个很重要的认知：

模型能力有边界。它不是万能的，也不会因为参数更大就自然解决一切问题。

很多系统问题，根本不应该指望“换个更强模型”自动解决。

2. Prompt 层：输入不是玄学，而是接口设计

如果说模型层决定了“它能做什么”，那么 Prompt 层解决的是：

怎样让它按你的要求去做。

这层常被误解成“调咒语”，但真正有价值的理解应该是：

Prompt 是输入接口设计。

2.1 Zero-shot 与 Few-shot 的本质

Zero-shot 是不给例子直接做；
Few-shot 是通过少量示例告诉模型“这类任务应该怎么答”。

关键点在于：

Few-shot 不是临时训练模型，而是在当前上下文里做格式引导和行为约束。

也就是说，它更像是在告诉模型：

任务长什么样
输出应该长什么样
你该模仿什么模式

它能显著改善稳定性，但并不意味着模型真正获得了新能力。

2.2 输出约束：让结果可消费

Prompt 层里最容易被低估的一块，是输出结构约束。

例如：

JSON Schema
Function Call 格式
严格字段定义
枚举值限制
模板化响应

这些设计的目标不是“看起来整齐”，而是为了让模型输出能被系统稳定消费。

它直接影响：

幻觉率
解析成功率
自动化可用性
下游服务稳定性

当一个系统需要把 LLM 输出交给数据库、工作流引擎、前端组件或 API 时，格式约束往往比文风更重要。

2.3 Chain-of-Thought：不是越长越好，而是按需展开

让模型“先想再答”在很多任务上确实有效，尤其是推理、多步规划、复杂条件判断。
但工程实践里更重要的不是盲目鼓励长推理，而是理解它适用的边界：

简单任务不需要复杂推理链
长推理会带来成本和时延
推理过程越长，越可能产生偏移和噪声

所以更好的理解方式不是“要不要 CoT”，而是：

当前任务是否需要显式中间步骤，收益是否大于成本。

3. 能力增强层：当模型不知道、不会做、不能做时怎么办

这层是现代 AI 系统最关键的扩展层之一。
它要回答的问题非常直接：

如果模型本身不够用，那系统如何补足能力？

这里最核心的两条路，就是 RAG 和 Tools。

3.1 RAG：给模型补知识，而不是逼它硬猜

RAG（Retrieval-Augmented Generation）解决的，是“模型知识闭包”问题。

典型场景包括：

模型不知道最新信息
业务数据是私有的
文档很多，不能全塞进上下文
需要回答必须有依据的问题

它的基本结构很经典：

用户问题
→ 查询改写 / 向量化
→ 检索
→ 过滤与重排
→ 上下文拼接
→ 模型生成

真正的难点不在“知道这个流程”，而在于下面这些工程判断：

如何检索

用关键词检索还是向量检索
要不要混合检索
查询是否要做重写或扩展

如何过滤

检索结果是否真的相关
是否有过期信息
是否存在重复片段

如何减少噪声

无关片段会污染回答
长上下文不等于高质量上下文
错误文档比没有文档更危险

Top-k 怎么选

取太少，可能召回不足
取太多，容易引入噪声
最优值通常依赖任务与语料结构

所以 RAG 从来不是“接个向量库就结束”。
它是一个关于召回、过滤、压缩、重排、拼接的系统设计问题。

3.2 Tools：让模型负责决策，让工具负责执行

当问题不只是“缺知识”，而是“需要行动”时，RAG 就不够了。
这时候要靠 Tool Calling。

典型例子包括：

查询数据库
调外部 API
发消息
执行代码
调用搜索服务
操作业务系统

这层最重要的一句话是：

LLM 负责决策，工具负责执行。

模型可以判断“下一步应该查什么、算什么、调用哪个接口”，
但真正的计算、检索、写入、变更，必须由外部工具完成。

这能解决模型的几个天然短板：

计算不可靠
状态不可持久
动作不可直接执行
权限与安全边界不可内建

所以在工程上，不要把模型想成执行器。
更准确的定位是：它是一个具备语言理解和策略选择能力的控制中枢。

4. 调度层：什么时候该用 Workflow，什么时候该用 Agent

很多系统一上来就谈 Agent，但真正成熟的工程判断通常更克制。

这一层要解决的是：

系统流程应该是固定的，还是让模型动态决定。

4.1 Workflow：固定流程，稳定优先

Workflow 适合可预测、步骤明确、规则清晰的任务。

它的特点是：

流程确定
可控性强
容易调试
稳定性高
成本可预估

常见场景包括：

客服意图分发
FAQ / QA 系统
审批或表单处理
规则化文档生成
数据清洗与结构化抽取

如果任务可以被清楚拆成若干步，并且每一步都能显式约束，那么 Workflow 往往是更好的选择。

4.2 Agent：动态规划，适合开放问题

Agent 的优势在于处理不确定性。

它通常具备这些特征：

可以自主决策下一步动作
可以多轮调用工具
可以根据中间结果调整路线
适合复杂开放式任务

例如：

多步骤研究任务
复杂问题排查
开放式信息收集
需要持续试错与修正的任务

但 Agent 的问题也很明显：

不稳定
成本高
调试难
可控性弱
结果可重复性差

所以这层最值得记住的判断，不是“Agent 很先进”，而是：

大多数场景先用 Workflow，只有少数高复杂度任务才需要 Agent。

很多所谓 Agent 场景，本质上只是“还没有把流程设计清楚”。

5. 状态层：系统怎么记住信息，而不是把一切都塞进上下文

状态层讨论的是：

系统如何管理记忆与任务状态。

这个问题非常重要，因为很多 AI 应用一旦进入多轮对话、长期交互、复杂流程，就一定会遇到状态设计问题。

我更倾向于把它分成三层。

5.1 短期记忆：当前上下文

这是最直观的一层，也就是当前对话窗口里的内容。

它的作用是：

维持连续性
保持当前任务语境
让模型理解“刚才说了什么”

但它的问题同样明显：

上下文窗口有限
历史越多，噪声越多
成本随 token 增长
旧信息会污染当前任务

5.2 长期记忆：用户数据与历史信息

这部分通常不会直接塞进上下文，而是存放在数据库、向量库或业务系统中。
例如：

用户偏好
历史操作记录
文档知识
任务历史结论
业务配置数据

它的价值在于“可持续、可检索、可复用”，而不是“永远常驻上下文”。

5.3 运行状态：当前任务进行到哪一步

除了对话历史和长期信息，很多系统还需要管理运行态信息，例如：

当前步骤编号
已调用过哪些工具
哪些结果已经确认
还缺哪些输入
本轮任务是否中断、重试或回滚

这部分状态更接近传统系统里的状态机或任务上下文。

5.4 为什么不能把所有信息都放进一起

这是状态设计里最常见的误区。

表面上看，把所有内容塞进上下文，模型似乎“最懂用户”；
但实际上，这样做通常会带来三个问题：

上下文爆炸
token 持续增长，成本迅速上升。
噪声污染
与当前任务无关的信息会干扰推理。
重要信息被淹没
真正关键的内容反而不突出。

更合理的方法通常是：

按需检索 + 结果筛选 + 信息压缩。

也就是说，Memory 设计的重点不是“记住一切”，而是“在需要时拿出恰当的信息”。

6. 工程层：没有安全、测试与评估，系统就不完整

很多人聊 AI 系统时，只关注模型、Prompt、RAG、Agent。
但在真实工程里，最容易拉开差距的，往往是这一层：

系统是否安全、稳定、可验证。

6.1 Sandbox：给执行能力加边界

一旦系统具备代码执行、文件读写、工具调用或外部系统访问能力，就必须考虑隔离。

Sandbox 的目标通常包括：

限制权限
控制网络访问
隔离执行环境
防止恶意代码影响主系统
限制资源消耗

当模型具备“会决定调用什么”的能力时，安全边界必须由系统显式建立，而不能靠模型自觉。

6.2 Testing：测试的是行为，不只是代码

LLM 系统的测试，与传统系统不完全相同。

因为很多问题不来自程序报错，而来自：

输出跑偏
格式不稳定
边界条件失效
工具调用顺序不合理
检索上下文污染结果

所以 AI 系统测试应该更多围绕“行为”展开，例如：

单元测试
边界样例测试
回归测试
对拍测试
数据集评测

一个关键认知是：

你验证的不是实现本身，而是系统行为是否符合预期。

6.3 Evaluation：没有评估，就没有 AI 系统

这是最应该被反复强调的一点。

如果没有评估，你很难回答这些问题：

系统到底有没有变好
Prompt 改动是否有效
检索策略是否提升回答质量
Agent 的复杂度是否值得
成本与效果是否匹配

常见指标包括：

success rate
accuracy
hallucination rate
latency
cost
tool call success rate
retrieval relevance

所以在工程视角下，最重要的一句话其实是：

没有评估，就没有真正可运营的 AI 系统。

模型跑通了，不代表系统成立；
只有当结果能被持续测量、对比、优化时，它才算进入工程阶段。

把它们重新串起来：一个完整 AI 系统的最小理解框架

当我们把这些层重新串起来，一个标准 AI 系统的工作方式其实就清楚了：

用户输入问题
系统通过 Prompt 进行结构化约束
判断是否需要额外知识（RAG）
判断是否需要调用工具（Tools）
选择固定流程还是动态调度（Workflow / Agent）
从 Memory 中提取必要状态
生成输出
进行格式校验、规则校验与评估
记录日志，持续优化系统效果

如果要把这一整套压成一句话，我会这样总结：

AI 系统 = 模型能力 + 输入控制 + 外部能力 + 状态管理 + 工程评估。

这个公式的意义在于，它会逼你在分析问题时先找“瓶颈层”。

一个系统表现差，可能不是模型弱，而是：

Prompt 约束不足
检索质量差
Tool 调用设计不合理
状态管理混乱
缺少评估闭环

当你能用“分层视角”去定位问题时，很多复杂现象都会变得清晰。

一个更实用的训练方式：看到问题，先挂到结构上

真正值得训练的，不只是知识量，而是把问题挂到结构上的能力。

例如：

问题一：Few-shot 到底有没有用？

这不是一个泛泛的 Prompt 问题，而应该先被定位到：

Prompt 层
输入接口设计
输出稳定性优化

于是你的回答方向就会更清楚：

Few-shot 的作用是示例引导
它提升的是格式一致性与行为稳定性
它不是能力训练
它有 token 成本，也有上下文占用

这就比单纯说“有用”更完整。

问题二：Agent 怎么才能真的有用？

这个问题表面在问 Agent，实际上至少涉及两层：

调度层：是否真的需要动态决策
工程层：如何验证它比 Workflow 更值得

于是更有价值的回答会是：

先判断任务是否足够开放
评估多步规划是否带来收益
设计工具边界与失败恢复机制
用指标证明复杂度是值得的

问题三：Memory 应该怎么设计？

这显然是状态层问题。

更好的拆法不是空泛地说“做长期记忆”，而是继续往下展开：

短期上下文怎么控制长度
长期记忆如何存储
检索策略是什么
是否需要压缩和摘要
如何避免旧信息污染当前任务

当你脑子里有结构图时，这些问题都会自动落到正确位置。

我的最终理解：不要把 AI 当成一个“模型问题”

如果只从调用接口的角度看 AI，很容易得到一种错觉：

好像只要模型够强，剩下的都是细节。

但做系统时会很快发现，真正决定上限的，往往不是模型单点能力，而是整个系统设计是否合理。

所以我现在更愿意用下面这段话来概括自己的理解：

我会把 AI 系统分成几层来看：底层是模型能力，比如 Attention、SFT 和对齐；上层是 Prompt，用来控制行为与输出接口；再往上是能力增强，包括 RAG 和工具调用；然后是调度层，也就是 Workflow 与 Agent 的选择；同时要有 Memory 去维护状态；最后必须补上安全、测试与评估，才能让系统真正可用。
因而我不会把 AI 简单理解为一次模型调用，而更倾向于把它当成一个完整的系统设计问题。真正关键的，不是堆更多概念，而是判断当前瓶颈究竟在哪一层。

结语

当知识点越来越多时，最重要的不是再记住十个新名词，而是拥有一张能持续扩展的地图。

对我来说，这张地图至少回答了三件事：

一个 AI 系统从输入到输出是如何流动的
每一层分别在解决什么问题
当系统表现不佳时，应该从哪一层开始定位

一旦这三件事清楚了，后续无论学的是 Prompt、RAG、Agent，还是 Memory、Evaluation，都会自然落在正确的位置上。

这也是我现在建立个人 AI 知识库时最看重的一点：

不只是收集知识，而是把知识组织成可推演、可复用、可判断的系统结构。

结构图速记版

最后附一版我自己会反复使用的速记结构：

用户问题
→ Prompt 设计
→ 模型推理
→ 是否需要 RAG
→ 是否需要 Tools
→ 选择 Workflow 还是 Agent
→ 调用 Memory
→ 生成输出
→ 做验证与 Evaluation

以及对应的分层视角：

模型层：模型会什么
Prompt层：怎么让它按要求输出
增强层：不知道/不会做时怎么补能力
调度层：流程固定还是动态
状态层：系统如何记住信息
工程层：如何安全、稳定、可评估

如果把它继续压缩成一句话，那就是：

AI 系统不是一个模型调用问题，而是一个分层系统设计问题。