企业官网建设流程全解析

这两年我给不少团队讲过AI系统落地的专题，发现大家最缺的不是某个模型的推导细节，而是一张能把Transformer、大模型、智能体设计串成体系的图。很多人学完注意力机制，学完智能体Demo，到了真要设计系统时还是会懵：这些模块之间到底是什么关系？知识怎么流转？哪些能力是模型自带的，哪些必须靠外部工具补上？所以我想把从Transformer到智能体设计的核心链路，整理成一份可以收藏、可以照着画的AI技术图解指南。它适合想系统入门的技术新人，也适合已经上手的算法工程师做复盘，对需要给团队做认知对齐的技术组长尤其有用。我会按自己实际画图的经验，把每一层画什么、连线代表什么、哪些坑我踩过，一次讲透。

1. 画图之前，先看清AI技术栈的真实层级

1.1 为什么单点教程学完就忘：缺一张全景图

单看注意力机制的讲解，你可能觉得自己懂了；单看一段智能体Demo，你也觉得不过如此。但等真要落地一个项目，模型怎么选、数据怎么组织、记忆放哪层、工具怎么接，问题会一股脑冒出来。根源在于知识是零散的，没有人告诉你这些模块在完整系统里的位置。图形化的价值就在这里：把知识固定到空间位置，把依赖固定到连线上。大脑对空间结构天生敏感，图比文字更容易被回忆、更容易被复用。

我遇到过不止一次类似的面试场景：候选人能解释清楚某个模型的结构，但当我问他，如果线上服务里把向量检索组件换成普通关键词搜索，整个对话系统会发生什么？他愣住了。这说明他脑子里只有模型细节，没有系统全貌。做AI技术图解的目的，不是画得好看，而是逼你把每个模块之间的输入输出、依赖边界、故障影响都摆到桌面上来。

从下往上看，一张完整的AI技术栈图解至少分成四层。最底层是算力和数据准备，包括模型训练和微调用的数据管线；第二层是模型层，也就是以Transformer为核心的各种模型结构；第三层是能力层，比如对齐、记忆、推理、多模态理解；最顶层才是应用层，也就是智能体设计。很多人画图失败，是因为把第一层和第四层黏在一起画，中间缺了第二层第三层。这样图看起来连接线很多，但逻辑关系是乱的。

1.2 三类读者看这张图的三种重点

同样的图，不同角色看的重点完全不同。这是我在跨团队协作中反复确认过的结论。

• 算法工程师看图，重点在模型内部：注意力怎么算、位置编码用哪种策略、显存会花在哪里。
• 后端工程同学看图，重点在模块边界：哪些是外部API，哪些是内部服务，数据以什么格式流转，出了故障往哪排查。
• 产品经理看图，重点在能力边界：模型能做什么、不能做什么，智能体的规划会卡在哪一环，用户体验上哪些承诺不能做。

不要试图用一张图同时满足这三类人，这是我踩过的坑。有一版我画得非常细，把每个Transformer子层都画出来了，算法同学觉得还不错，产品经理看完直接懵掉，说这跟看电路图没区别。后面我改成一套图例、三种视图：主图只放模块和数据流，算法子图、工程子图、产品子图分别补充对应细节。如果你只打算画一张图，那就先明确这张图是给谁看的，然后果断砍掉不属于这个视角的信息。

2. Transformer怎么画才能既直观又准确

2.1 注意力机制：一张图解决"谁在关注谁"

Transformer最核心的运算是自注意力。你可以把它想象成档案室里同时管理几百份资料，每份资料都要和另外所有资料比较关联度，然后按关联度取回重点内容。实际计算时，每个输入会生成三份副本：查询、键、值。查询是"我想找什么"，键是"我有什么标签"，值是"我真正的内容"。

注意力分数是查询和键做点积，除以一个缩放因子防止数值过大，再经过归一化变成一组加起来等于1的权重。画这张图时，我习惯把输入排成一横排，每个输入上方引出三条线，分别标上Q、K、V，然后画一个交叉的连接矩阵。矩阵里每一格的深浅就代表关注强弱。这样画，读者一眼就能明白：每个输出不是只依赖自己这一个位置，而是依赖全部输入位置的加权组合。

还有一个细节值得标出来：多头注意力。多头不是玄学，是把查询、键、值投影到多个低维子空间，让不同头关注不同类型的关系。一个头可能更关注语法结构，另一个头更关注指代关系。画图上，每个头是一条独立的注意力路径，最后把所有头的结果拼起来，再过一次线性变换。如果一张图只用单头表示，虽然简化，但容易让读者误以为注意力只有一种关联模式。

这里必须提醒一个很多人容易画错的地方：千万不要把注意力图画成一条线从头串到尾。自注意力的特点是每个输出都看到所有输入，它是全连接模式，不是序列连线。如果画成单向链，丢掉并行和全局感知，模型的核心思想就完全变形了。

2.2 位置编码：带上下文的顺序信息

Transformer没有循环结构，也没有卷积，它天生不感知顺序。把输入打乱顺序，注意力计算出来的结果是一样的。所以要把位置信息以加法或拼接的方式塞进输入向量，这就是位置编码存在的理由。

最早期的做法是正弦余弦位置编码，不同维度用不同频率的波形，让模型可以区分不同位置。后来很多模型改成可学习的位置编码，还有一些模型用相对位置编码办法，让每个token在计算注意力时带上与目标token的相对距离。相对位置编码通常对长文本和泛化能力更友好，因为它不依赖绝对位置。

图解时，我一般把位置编码画成一个独立的输入分支，和词向量并行进入编码层，再在输入处汇合。这样读者能理解"信息叠加"这个关键动作。别把位置编码画在模型输出端，那是很多初稿容易犯的错误——位置信息是在进模型之前就注入的，不是算完结果之后再补的。

另外一个容易被忽略的点：位置编码会直接影响模型对输入长度的容忍度。有的模型在训练时只见过一定长度的序列，推理时输入更长，效果就会明显下降。作图时，在主图旁边用一行小字标出模型的可处理长度范围，能给团队省下很多排查时间。

2.3 编码器与解码器：理解型与生成型的分工

Transformer原结构包含编码器和解码器两部分，但现在很多应用只取其中一半。编码器擅长把整段文本压缩成语义表征，理解能力很强；解码器擅长靠已有token一步一步预测下一个token，生成能力很强。过去大量翻译模型用完整的编码器-解码器结构，而如今主流的对话大模型大多采用解码器架构。

作图时一定要标清训练与推理的差别。训练阶段，解码器可以提前看到完整的目标序列，按顺序预测每一步；推理阶段，它只能基于已经生成的内容继续往后预测，前面的结果一旦生成就固定下来。很多图把这一点忽略，导致读者不明白为什么同一个模型训练时效果很好，部署后却会出现重复、偏移、越说越飘的现象。你在图上加一个小小的标注，注明"训练：teacher forcing；推理：自回归逐步生成"，这张图的信息密度立刻就不一样了。

还有一点，如果你的场景需要做语音合成、图像生成这类任务，模型结构往往会混合使用编码器和解码器。图像输入经过视觉编码器变成特征序列，再由解码器生成文本或图像。作图时把编码器画成特征提取器，把解码器画成生成器，两个模块之间用一条粗线表示特征向量的传递，比纠结内部具体算子更实用。

3. 从语言模型到智能体之间，补齐训练、对齐与记忆

3.1 预训练与对齐的分界线

一个大型模型在预训练阶段学到的只是统计规律。它能补全句子，能接续上下文，但它未必会好好回答问题，更未必符合人类偏好。对齐阶段要做的事，就是把模型从"会说话"往"会听话、说得对"方向调整。

最常见对齐方法是收集人类对不同回答的偏好排序，再用强化学习把模型压向高分支。具体流程可以简单理解成：模型生成多个回答，给出评分，用反馈信号更新模型参数。由于完整方案成本高，很多团队会选择低成本替代方案：用一个更强的模型给多个回答打分，把打分结果当成偏好数据来训练。效果比真人工标注稍弱，但胜在落地快。

图解上，我会把预训练画成一条很宽的横带，表示海量数据和巨大算力消耗；把对齐画成一条比较窄的竖线，表示数据精、成本高、迭代频繁。两者宽度差异本身就在传达一个概念：预训练是地基，不是随便就能推翻重来的；对齐是装修，可以在模型之上反复调整，但改多了也会破坏原有能力，所以需要谨慎。

对齐策略模块应当是可替换的。今天你用A方案做对齐，明天可以换成B方案。画图时不要把它跟模型本体的图绑死，用一个独立模块加虚线连接，之后调整方案时只需要改这个模块，不影响整张图的大结构。

3.2 三层记忆体系怎么画

对话系统记忆绝不是一块铁板。我习惯把智能体记忆分成三层，它们之间的边界非常关键。

第一层是上下文窗口，相当于工作记忆。它存放当前对话最近几轮内容，以及检索回来并被放进去的关键片段。第二层是长期记忆，通常通过向量数据库把重要信息存起来，需要时按相似度召回。第三层是外部工具记录，比如数据库里的订单、文档库里的知识、线上系统的状态快照，本质上是外部世界的"记忆"，智能体本身不保存，用的时候去查。

画图时，前两层画在智能体内部，第三层画在外部的依赖区。三层之间用不同箭头连接：内部两层之间用实线箭头，表示随时读写；外部依赖区用虚线箭头，表示按需获取。我见过不少团队画记忆体系，把所有向量检索和数据库查询都画成一个大圆，结果没人能说清哪些数据是常驻内存的，哪些是每次现查的。

这里有一个值得标注的工程细节：上下文窗口不是越大越好。窗口越大，检索噪声越多，注意力矩阵占用空间也越大，而且无关信息会稀释模型对重点信息的关注。常见做法是设一个活跃窗口，只把最近几轮对话和真正召回的关键片段放进去。

3.3 多模态输入与工具调用画进同一张图

现代AI系统已经很少只处理纯文本了。近两年主流方案，是把文本、图像、音频统一映射到同一个向量空间，然后交给同一套Transformer主干处理。图像被切成小块后映射成token序列，音频频谱也可以编码成token，结构化表格可以转成文本描述再进模型。

作图建议在输入端画多个分支，分别标注"文本编码器""图像编码器""音频编码器"，这些分支汇合到公共编码区，再进入主干。不必把每个模态的后端细节都画出来，否则图会被细枝末节淹没。只需要表达清楚一个核心思想：多模态输入在入口处完成统一向量化，后续处理共享同一套模型参数。

同样，外部工具调用也要在图上有一席之地。工具调用是智能体连接真实世界的桥。图里可以在模型层旁边划出一个外部工具区，里面列出数据库、搜索服务、计算引擎、通知服务等资源盒子，从智能体规划模块引一条带序号的调用箭头过去，旁边标注"请求-响应"循环。图上把这些工具统一约束在同一个接口内，避免每新增一个工具就画一条交叉线，这是防止图变成蜘蛛网的关键。

另一个值得注意的点：训练和推理时的多模态流程不太一样。训练时模型会从带标注的多模态数据里学习对齐关系；推理时模型接收真实用户的多模态输入，实时编码转换。如果在一张图里能画出"离线训练"和"在线推理"两条路径，用不同颜色区分，会非常有帮助。

4. 智能体设计：把模型从"会说话"变成"会办事"

4.1 感知-规划-行动-观察的闭环

智能体和普通大模型的最直观差别，就在于它多了一个行动模块。一个最小可用智能体的循环，可以拆成四步。

第一步是感知，接收用户请求、读取上下文和执行环境的状态。第二步是规划，把目标拆解成可执行的子任务，决定调用什么工具或者是否需要向用户追问。第三步是行动，执行工具调用、生成回复或者发起新的请求。第四步是观察，读取工具返回结果，判断目标是否已经达成，如果没达成就回到规划阶段继续迭代。

这个循环一定不要画成直线。我习惯把四个节点放在图的四个角，中间画一个大循环箭头，旁边标注"最大迭代次数"。为什么必须标注这个参数？因为如果不限制，智能体可能在一个问题上反复尝试工具调用，浪费大量时间。我自己做过一个内部知识问答智能体，最大循环次数设成5次，超过之后不管结果好坏都直接生成最终回答，这样至少保证用户不会无限等待。

所谓"思考-行动-观察"这一类设计范式，本质就是把大模型变成带反馈的决策器。你在画图的时候，可以把规划模块单独做成一个部件，旁边列出它会用到的高级能力列表：任务分解、工具选择、自我修正、结果验证。这样读者可以一目了然地知道，智能体不是靠一个大模型包办一切，而是靠一套控制机制驱动模型不断产出中间结果。

4.2 工具调用是全图最容易画乱的地方

工具调用是智能体落地的基础能力。系统内部需要一份工具注册表，每个工具包含三项信息：名称、参数结构、使用描述。模型根据用户请求生成调用意图，系统解析意图，真正去执行工具函数，再把返回值塞回对话上下文。

很多初版实现都会在参数解析上翻车。因为模型输出的是自然语言描述，而工具接口要求的是结构化参数。比如用户说"查一下最近三个月华东区的销售数据"，模型可能输出"搜索最近三个月的销售数据"，解析层要把它标准化成region=华东、time_window=90天、query=销售数据这样的结构，再去调后端接口。

图解上，把所有外部工具框在"外部工具区"，用统一接口模块跟规划层连接，不要把每个工具都单独拉一条线，否则图会很快乱成蛛网。接口模块内部可以列几条示例参数，读者一看就明白工具调用的前后端关系。

我还有个习惯：在工具区外部用一个状态标记盒，标注哪些工具是同步返回，哪些是异步任务。同步返回的结果可以直接进入观察模块；异步任务的工具会返回一个任务编号，智能体需要轮询或等待回调。这个区别如果不在图上标明，开发实现时很容易按错误的心智模型去设计对接逻辑。

4.3 多智能体协作：角色划分与消息传递

更复杂的系统里，单个智能体的闭环还不够，问题会被拆给多个角色分工完成。一个典型组合是规划者、执行者、评审者。规划者负责理解目标、拆解步骤；执行者负责写代码、查资料、跑实验；评审者负责检查执行结果，决定是继续修改还是交付。

多智能体之间的消息传递一定要结构化，不能互相丢大段自然语言。否则每个智能体都要消费和生成超长文本，上下文很快会爆掉。代码层面的调用、表格结果、错误信息、评分结果，这些都应该有明确的数据结构。画图时，把每个智能体画成角色泳道，泳道之间用一条消息总线连接，具体消息类型在总线旁边标注。

多智能体最大的难点不是单个角色能力，而是状态一致性、任务交接、死锁和重复工作。图很难表达这些动态问题，建议在静态架构图的基础上，配合时序图补充关键交互流程。如果你只画一张架构图，记得在图里标注一条"本轮任务归属"的状态位，让团队知道任意时刻哪个智能体对用户的目标负责，这是我在实际协同推进中反复被提醒的一点。

5. 实操：动手画一张属于自己的AI技术图解

5.1 确定画图的顺序与边界

如果你从来没画过，我建议第一版就按自底向上的顺序来：底部是数据与算力，中间是模型层，再往上是能力层，最上面才是智能体应用。这个顺序跟系统中数据的实际流向一致，也跟排查问题的路径一致。

特别提醒自己一句话：先画Transformer结构，再补外部数据流，最后再套智能体循环。很多人一上来就画智能体闭环，画到一半发现涉及太多前置依赖，图就被迫越画越大。把边界划定清楚，一次只解决一个问题，才有可能画出真正清晰的图。

一个实用技巧是给每个模块命名时带上方向性。比如"文档向量化服务"比"文档模块"要好，因为前者明确说明了这个模块做的是"把文档转成向量"的动作；"记忆检索接口"比"记忆"更清晰，因为后者光看名字也不知道是存储服务还是读取服务。

5.2 图例、配色与数据流标注的统一规范

一套统一的图例能让你在后续调整里省大量时间。建议把常用符号固定下来，团队协作时每个人按同一套规范画。

配色上，模型统一用冷色系，数据统一用暖色系，外部系统用灰色。为什么这样配？因为人眼会优先识别色彩边界，模型和数据是图里出现频率最高的两类主体，一旦混色，看图的人会被迫逐个读取文字，认知负担立刻上升。保持单调配色，用形状区分模块类型，信息密度更高。

5.3 一张图如何持续迭代

图不是一次性画完就结束的。我给每张图都标版本号，并且在落地新模块后及时更新。尤其是智能体的规划逻辑和记忆层，几乎每次产品调整都会变。建议使用支持历史版本的在线白板工具保存迭代记录，而不是每次都在导出图片上改。这样做的好处是，你可以随时回退到某个稳定版本，也能让团队成员直接在图上对应位置写评论。

我自己常用的迭代节奏是：方案评审前画一版草稿，评审会上根据反馈改一版，开发完成后再结合实际情况校正一版。三次迭代之后，这张图基本上就能承担上线后排查问题时的导航图功能。图不只是给别人看的，更是一个系统在演进过程中的活文档。

6. 画图与读图过程中的常见坑和排查办法

6.1 图越来越复杂，怎么取舍

一张图的连线超过几十条之后，大脑已经处理不过来了。我常用的手法是先横切再纵切：先把系统横切成业务层、能力层、技术层，每一层单独画一张图，再把三张图叠起来对位。纵切指的是按核心链路切，比如用户提问到回答生成是一条主链，训练侧流程是另一条副链，主链副链分开画。

如果仍然觉得复杂，就问自己一个问题：这张图顶多被观众看三分钟，三分钟内你最希望他们记住什么？答案就应该是图的主干。把次要的异常分支、备选路径、日志模块都移到子图里去。

6.2 依赖关系画不清，换个视角横切

如果两个模块之间说不清依赖，通常不是因为画图技巧不好，而是模块边界没设计好。解决办法是先定义每个模块的输入输出接口格式，再决定怎么画箭头。数据接口就是最好的依赖边界。两个模块之间如果无法准确说出数据格式，说明设计本身还没收敛，就算强行画箭头，后续实现也会出问题。

横切视角也很管用。把系统从技术架构图切换成业务时序图，问题表现方式会完全不同。比如一个"用户查询订单状态"的流程，架构图上可能只有两条线，但在时序图上你会发现涉及用户认证、订单服务、支付状态、物流状态四次交互。每次用架构图解释不清时，就画一张时序图辅助。

6.3 智能体循环图容易误导，分清循环层级

智能体的循环很容易画错，问题在于把不同层级的循环画在了同一条线上。单轮对话内的控制循环，是这次请求到响应之间的多次工具迭代；跨事件的长期循环，是系统每隔一段时间或者遇到特定触发条件后重新开始工作。如果把这两种循环画成一条实线闭环，读者会误以为系统会自动持续运行，不需要外部触发。

我的做法是用实线表示单轮内的控制循环，用虚线表示跨事件的长期循环，在旁边明确标注触发条件和时间策略。画图不是为了把系统做得完美，而是要逼团队想清楚这些实现层面的约束条件。

6.4 一份图与多份图的粒度选择

最后想强调一下粒度。一份图想覆盖所有概念，最后一定会变成天书。主图只放主干，边角知识放到子图里，用编号在主图和子图之间建立链接。比如注意力计算单独画一张细节子图，记忆存储结构单独画一张子图，工具注册表单独画一张子图。主图的核心价值是导航，子图的核心价值是知识落地，两者配合使用，效果远好过一张图塞满所有细节。

我自己在整理这份AI技术图解的过程中，最大的体会是：每次画图，都是一次对系统认知的体检。你画到某个模块，发现图里还没给这个模块留接口，或者连线不知道往哪走，那个位置就是你理解上的空洞。别急着去补教程，先把这个空洞在图上补完整，你会发现画图这个动作不得已地逼你想清楚了很多以前跳过去的问题。最后分享一个小习惯：每次学完一个新模型或新架构，都拿一张空白纸默画一次完整技术栈，画不出来的部分就是接下来要补的重点。这套方法比收藏十篇教程更管用。希望这份从Transformer到智能体设计的地图，能帮你把零散知识真正挂到同一棵技术树上。