企业官网建设流程全解析

最近聊“多模态 Agent”的人越来越多，但大部分讨论都停在“某某模型又刷榜了”这个层面。真到了动手做产品的阶段，第一道坎往往不是模型选哪个，而是技术路线到底走哪条：是直接上火山引擎这种原生多模态方案，让一个模型把图、文、音全部吃掉；还是用传统工作流编排，把语音转文字、图片转描述，再交给文本大模型做推理。

这两条路线我都实打实从零搭过，也踩过不少坑。这篇文章就把两种方案从原理到实战掰开揉碎讲清楚，最后给一份可以直接抄的选型清单。不管你是做客服助手、内容审核、智能硬件，还是企业内部知识库，看完应该能少走一大段弯路。原生多模态和工作流编排看起来都在做同一件事，但它们的边界、能力上限、坑位完全不同。

1. 两条技术路线，本质差异在哪里

1.1 原生多模态：让一个模型同时看懂、听懂、读懂

“原生多模态”这四个字，核心在“原生”。意思是模型从架构层面就支持图像、音频、视频、文本混合输入，而不是靠外部系统临时拼装。

简单说，这类模型会先把不同模态统一编码成模型内部能理解的词元序列。图像会被切成小块并映射成视觉词元，音频会被采样并映射成音频词元，文本走原有的文本词元。这些词元在同一个高维语义空间里做注意力计算，模型才能做跨模态的联合推理。

这里面有一个关键动作叫“模态对齐”。训练阶段，模型会被喂大量图文对、音视频对、多模态问答数据，让它在语义空间里把“一张身着红色外衣的照片”和“红色外衣”这四个字之间的向量距离拉近。训练完成后，你给它一张图、一段音频、一段文字，它能一次性理解整份输入的关系，而不是先把某一种模态“翻译”成另一种。

打个比方：原生多模态模型更像一个母语级别的双语者，你用中文问、英文答、中间还夹杂手势和图片，他都能自然理解；而工作流编排则像一个“翻译接力团”，每句话都要经过翻译官转一手。

这类模型通过一个统一接口对外提供服务——你不必区分“我调的是视觉模型”还是“语音模型”，把图、文、音混合扔进去，返回的是一段综合理解后的自然语言结果。火山引擎豆包大模型家族里的多模态系列，走的就是这个路线，通过火山方舟提供 API，再配合扣子这类 Agent 开发平台把能力落地到业务场景里。

1.2 传统工作流编排：用流程把多个单模态模型拼装起来

传统工作流编排解决的是另一种问题：当手头没有原生多模态模型时，怎么让已有的单模态模型协作完成多模态任务。

常见做法是把任务拆成若干原子步骤。用户发来一张带文字的图片，那就先走 OCR 节点识别文字；用户发来一段语音，那就先走语音识别节点转成文本；图片本身想被理解，就需要调一个视觉理解模型生成一段文字描述。等所有模态都被转成文本后，文本大模型接管，综合这些文本中间表达做推理。最终如果还要语音回复，再调语音合成节点。

这个链路听起来合理，但有一个天然的硬伤：信息转换有损耗。图片包含的纹理细节、光影关系、物体相对位置、颜色渐变，一旦被“翻译”成一段描述文字，就已经丢失了大量信息。比如视觉模型写出“一件蓝色防风夹克”，它无法表达出夹克面料反光的质感、拉链位置、袖口松紧这些原始像素里肉眼可见的信息。

这类方案的编排工具很多，开源的有 Dify、LangGraph，商业的也有不少。它们负责管理节点、状态流转、并发控制、错误重试。说白了，工作流编排就是一个“调度中心”，模型本身不具备跨模态能力，但整个系统通过流程设计硬生生把多模态能力拼出来了。

工作流编排也有不容忽视的优势：可控性强、可审计、每个环节都能单独替换成效果更好的专用模型。比如 OCR 场景，专用 OCR 模型在识别准确率上通常比通用大模型更稳。

1.3 一句话总结：融合发生在“模型内部”还是“系统外部”

把两者放一起看，最核心的差异就一句话：

原生多模态方案的多模态融合发生在模型内部，传统工作流编排方案的融合发生在系统外部。

这个差异决定了后面所有对比。发生在模型内部，意味着信息传递的粒度是词元级，图像细节、音频节奏、文本语义从一开始就在同一个语义空间里流转；发生在系统外部，意味着信息传递的粒度是文本字符串或 JSON 结构，模态之间的桥梁是“翻译后的文字”。

如果你做过 Agent，就知道这个差异有多致命。跨模态引用、多轮对话中的指代消解、模糊图像下的常识判断，这些都是原生模型天然的强项。而工作流编排在这些问题上天然吃亏——每一次“翻译”都是一次妥协。

2. 拆解火山引擎原生多模态 Agent 的产品逻辑

2.1 底座能力：为什么“原生”能减少信息损耗

火山引擎原生多模态方案，底座是豆包大模型的视觉、语音、视频理解能力。以视觉为例，豆包系的多模态模型可以接收图像 URL 或 base64 编码，直接把真实像素信息作为输入，而不是经过任何外部模型的“转述”。

这意味着模型能直接看到图片的颜色分布、物体边界、文字内容、人物情绪。你再也不必担心“视觉模型把绿色描述成蓝色”这种中间翻译错误，因为模型看到的就是像素本身。同样的道理适用于语音——音频波形被直接编码进模型，声调、停顿、语气这种非文本信息也能被捕获。

在多模态 Agent 的场景里，这个能力帮助很大。用户发一段 20 秒的语音，里面带着犹豫的语气、背景环境音，再加上一张手机拍得有点糊的实物图，原生多模态模型能同时综合利用所有信号。语气犹豫可能意味着用户还在对比，背景音可能提示用户在室外，实物图能确认具体产品型号。工作流编排方案里，语音变成文本后，语气信息直接消失。

另一个值得提的点是多模态时序数据融合。当输入是一段视频或连续多帧图像时，原生多模态模型会建模帧之间的时间依赖关系，理解“这个人先拿起杯子，又放下”这样的动态过程。这在视频内容理解、具身智能、实时交互场景里非常关键。传统编排方案处理时序问题要显式设计状态管理，既要存帧，又要维护时间戳，复杂度成倍上升。

2.2 Agent 平台层的角色：编排没有消失，而是聚焦了

很多做 Agent 的人一听到“原生多模态”，第一反应是“那就不需要工作流了”。这个理解不准确。火山引擎生态里的 Agent 落地，通常还会用扣子（Coze）这类平台做 Agent 层的搭建，只是编排的定位发生了根本变化。

在原生方案里，编排不再负责模态转换，不再做“把图转成文字再喂给 LLM”这种体力活，而是聚焦在两件真正有价值的事上：

第一，工具调用。Agent 不能只停留在“能理解”，要能“能行动”。扣子平台的工作流可以定义工具节点，比如查询库存、调天气接口、生成订单。原生多模态模型负责理解用户意图，工作流负责执行动作。模型输出一段结构化的工具调用指令，工作流解析后触发对应 API。

第二，流程控制。有些业务有硬性规则，比如“先查库存再报价”“抽检比例超过阈值必须转人工”。这种规则用纯 Prompt 约束模型不一定稳，但用工作流做显式分支是确定的。工作流承担的是“业务确定性”，模型承担的是“理解灵活性”，边界很清晰。

我搭过不少 Agent，一个体会是：原生方案里工作流当配角反而更顺手。为什么？因为工作流一旦复杂，维护成本是指数增长的。把模态理解这种高不确定性环节交给模型，把纯规则环节交给工作流，是当前性价比最高的组合。

2.3 最小可跑通的搭建示例

如果你也想快速验证原生多模态 Agent，我建议直接按下面这个最小步骤跑通 MVP。

第一步：创建 Bot。在扣子平台新建一个 Bot，模型选择支持视觉和语音输入的多模态模型。这一步非常关键，选错了模型后面白干。

第二步：打开多模态输入能力。在模型设置里确保图像输入和语音输入开关已打开。有些平台默认关闭，要手动开启。

第三步：配置人设 Prompt。写清楚这个 Agent 的角色、职责边界、回复风格。我通常会要求它“先描述从图像和语音中获取的关键信息，再做结论输出”，这样便于观察模型的中间理解。

第四步：添加工具节点。这是最有 Agent 味的一步。比如你做一个商品客服 Agent，就添加一个“商品信息查询”工具，工具接收商品 ID 和属性名，返回库存和参数。模型在对话中自主决定什么时候调用工具。

第五步：端到端测试。用一张模糊的商品图加一段语音提问，看模型的反应。如果模型能准确理解图片内容并且正确触发工具调用，说明链路已经通了。

这个 MVP 我实测一个下午就能搭完。不要一上来就求大求全，先让链路转起来，再逐步加知识库、加记忆、加复杂的业务规则。这也是我反复和团队强调的：原生多模态方案的开发门槛真的低，低到大多数团队可以当天出 Demo。

3. 传统工作流编排方案的实现拆解

3.1 典型架构：五节点流水线

传统工作流编排方案搭建的多模态 Agent，典型架构是一条五节点流水线：

第一个节点是语音识别。用户输入的语音先通过 ASR 服务转成文本，这个环节的误差会直接影响后面所有节点，必须选一个在对应语言和场景下效果好的 ASR 服务。第二个节点是视觉理解。图片被送入视觉模型，输出一段描述或结构化信息。这里要注意，很多团队会让视觉模型同时输出 OCR 结果，把图片里的文字也提出来。

第三个节点是文本大模型 LLM。它接收前面两个节点的输出，再加上用户的文本输入，综合做意图识别、推理、决策。这个节点是整个系统的“大脑”，但它能接触到的图片信息已经是二手信息了。第四个节点是工具调用。LLM 生成工具调用参数，工作流引擎执行，比如查数据库、调外部 API。第五个节点是语音合成，把最终答案转成语音播放给用户。

这个架构本身不难理解，但它暴露出一个问题：每一环都是独立系统，内部的错误率、延迟、不确定性会层层叠加。ASR 错一个字，视觉模型漏一个细节，LLM 就可能基于错误信息做出完全跑偏的决策。

3.2 用 Dify 这类平台怎么搭

在 Dify 这类可视化工作流平台里搭这套流水线，比纯代码要省力不少。Dify 的 Chatflow 模式支持把节点拖拽连线，适合快速做原型验证。

具体步骤上，先创建 Chatflow，把“开始”节点里定义好用户输入变量，包括文本、图片 URL、音频 URL。接下来添加“语音转文字”节点，配置 ASR 服务的 API Key，把音频变量传进去。再添加“视觉理解”节点，调用视觉模型接口，让模型输出图片的文字描述。然后是“LLM”节点，把前面的输出以变量的形式拼到 Prompt 里，让大模型做综合推理。最后根据业务需要接“工具”节点或“语音合成”节点。

听起来不复杂，但实际踩坑不少。最想吐槽的就是变量管理。Dify 每个节点的输入输出都靠变量名引用，节点一多就很容易出现“名字对不上”“类型不匹配”这种低级错误。排查起来要在节点之间来回跳，非常费眼。

另一个问题在容错。工作流里任何节点超时或返回异常，整条链路就中断了。我在 Dify 里做多模态链路时，语音识别节点偶尔网络超时，导致整个 Agent 回复“系统异常”。后来只能额外加一个“失败分支”节点，超时就走备选流程。这些隐性成本在方案选型时几乎不会被算进去，但实际开发时一个都躲不掉。

3.3 编排方案的硬伤：翻译损耗与延迟叠加

说句公道话，编排方案确实有它不可替代的价值，比如流程可控、模型可插拔、每个节点能做精细成本控制。但有两个硬伤绕不开。

第一个硬伤是翻译损耗。图片转成文字描述，语音转成文本，这一步丢失的信息永远拿不回来。我做过一个测试：给视觉模型一张户外冲锋衣的照片，让它描述“面料质感”，模型只输出“黑色面料”。但人眼能明显看出是磨砂质感的硬壳面料。这种细节在工作流方案里没有补救机会，因为 LLM 只能看到那段文字描述。

第二个硬伤是延迟叠加。每个节点一次 API 调用，加上网络往返和排队时间，整条链路的延迟是各个节点之和，而不是“一次调用的延迟”。我在实际测试中，ASR 约 0.5 秒、视觉理解约 1 秒、LLM 约 1 秒、TTS 约 1 秒，加起来已经 3.5 秒以上，这还不包括节点间的数据传递时间。用户感知到的是“一直在转圈”。原生方案两三秒能出一段综合回答，编排方案在这个指标上先天吃亏。

4. 一次真实的 POC：让两条路线同时处理同一批任务

4.1 POC 的场景设定

纸上谈兵没什么意义，我把两种路线落在同一个真实场景里做了对比。场景选的是电商商品客服 Agent，任务很典型：用户上传实物照片提问，Agent 需要理解图片内容、结合语音和文字问题，返回商品信息。

输入样例是这样的：用户上传一张户外防风外套的照片（照片里能模糊看到吊牌），语音提问：“这个有黑色的吗？下周去山里穿防风效果够不够？”同时附带一句文本：“有没有大码？”

这个输入天然包含三种模态，让客服 Agent 去处理，能全面暴露两个方案的能力差异。

4.2 原生方案的 POC 表现

原生方案的处理流程非常短，其实就是一次多模态请求。图片 URL、转写后的文本、原音频直接被喂给豆包多模态模型，模型自己理解图片里的外套款式、吊牌信息，结合语音提到的“山区”“防风”做推理。

为了让 Agent 能回答库存问题，我在扣子平台给 Bot 配置了商品查询工具。模型一旦确定用户想了解颜色和尺码，就会自动触发工具调用，查询黑色和大码的库存状态。整个推理过程中的中间状态都能在扣子的调试面板里看到，很方便检查模型是否理解偏移。

实测下来，原生方案对图片的理解很出色——能识别出这是一件连帽防风外套、衣领处有品牌绣标、主拉链是防水拉链。吊牌上的部分文字也能准确提取出来。综合语音里的“山里”和“防风”，模型能主动关联“山区天气多变”“防风性能优先级高”这些信息。

整个流程端到端大概 2 到 3 秒，用户体感是“发完语音，很快就收到回复”。作为客服 MVP，这个效果已经能用了。

4.3 编排方案的 POC 表现

同样的输入，传统编排方案要拆成四个环节。

先走 ASR 把语音转成文本：“这个有黑色的吗？下周去山里穿防风效果够不够？”转写文本倒是很准。再走视觉模型生成图片描述，这一步我只拿到一个相对概括的描述：“一件黑色连帽防风夹克，有品牌标识，吊牌可见”。吊牌上的具体参数文字没提，比较可惜。

接着把 ASR 文本、视觉描述、用户文本拼在一起，交给文本 LLM。它判断用户意图是“黑色库存”和“防风参数”，然后触发商品查询工具。最终 LLM 生成的答案是：“这款有黑色，库存充足。防风指数请参考商品详情页。适合轻装徒步。”

表面上看答复也过得去，但细看就有问题。视觉模型没有识别出图片里大码标签，导致 LLM 的回复里完全没有提到“大码是否有货”这个诉求。原因很简单，视觉模型输出的描述字段里压根没有大码相关信息，LLM 再聪明也只是“无中生有”。整条链路端到端跑了 4 到 5 秒，中间还因为 ASR 节点一次超时重试，有一次整个流程直接失败。

4.4 五个维度的对比结果

我把两轮 POC 的数据整理成了一张表，方便大家参考：

换个说法：如果你追求“效果好、开发快、交互自然”，原生方案更稳；如果你追求“流程确定、环节可控、允许中间踩一脚刹车”，编排方案更合适。

5. 选型建议：什么样的业务适合哪条路线

5.1 优先选原生多模态的典型信号

不是所有场景都适合原生多模态，但如果你符合下面几条，基本可以闭眼选这条路。

第一，业务需要跨模态强推理。也就是“看图、听声、读文字”这三件事没法拆开独立处理。比如医疗影像辅助诊断，医生上传影像图并口述病史，Agent 必须同时理解图像特征和语音描述，这种场景去建模中间表达会非常痛苦。

第二，交互形态是自由对话。用户可能会发语音、发图片、发文字，而且模态会混合出现。原生方案对这类不确定输入非常友好，模型自己就能完成模态位置的动态分配。

第三，团队小、缺模型资产。没有太多精力维护多个单模态模型，也没有专业的机器学习团队去做模型路由优化。原生多模态方案把复杂度封装在平台里，对中小团队极其友好。

第四，对延迟敏感。客服、智能助手、车载交互这类场景，用户等不了 5 秒才来回答。原生方案一次大模型调用、端到端两三秒，体验上明显更好。

5.2 优先选传统工作流编排的典型信号

传统工作流编排从来不是“过时”的方案，它在以下场景反而比原生多模态更合适。

第一，流程确定性极高。业务链路是固定的，比如“身份证识别 → 信息提取 → 规则核验 → 入库”，每一步都不能让模型自由发挥。调度系统用流程把不确定性锁死，模型只做中间一个小环节。

第二，已经沉淀了大量单模态模型资产。团队可能已经花两年时间调优了专属的 OCR 模型、情感识别模型。这时候硬迁到原生多模态等于把现有的资产全部推翻，沉没成本太高。

第三，每一步的成本都要精细管控。比如一次请求中，图片识别只需要在部分情况下才调用，编排方案可以通过路由规则做到按需触发，节省调用量。

第四，合规审计要求高。金融、政务这类领域，往往需要完全解释清楚“这条结论是怎么得出来的”。编排方案里每个节点都可以留痕，可以回溯。原生模型是个黑盒，解释起来会麻烦很多。

5.3 混合策略：这两条路线其实可以都要

这段时间做下来，我最想推荐的不是单选，而是混合策略。

最理想的组合是基于原生多模态搭底座，能力不足的地方用工作流做兜底。具体分工是：多模态大模型负责所有高不确定性的理解任务，比如看图、听语音、做综合推理；工作流负责所有确定性强的规则逻辑，比如“超过某个阈值必须转人工”“必须按固定流程走审批”。

反过来也成立，如果团队已经有成熟的编排平台，不妨把多模态大模型作为一个新节点接入现有流程。你在 Dify 里加一个“多模态理解”节点，传入图片和音频，拿到大模型的综合理解，再继续走后续的规则流程。这样一来，既保留了原有平台的可控性，又补强了多模态理解能力。

混合策略操作起来其实不复杂，关键是要在方案设计阶段就明确划分边界。我的习惯是画一张表格，把“必须规则化”的环节列左边，“必须模型化”的环节列右边，任何环节一旦在中间摇摆，多半会在后期变成维护地狱。

6. 常见问题与避坑心得

6.1 原生方案踩过的坑

第一个坑是多模态上下文膨胀。图片天然包含大量词元，一张图可能相当于几百个文本词元。几轮对话各携带一张新图片，上下文很快逼近窗口上限。我的对策是控制单轮图片数量、要求用户上传前压缩到合理尺寸。如果产品确需多图比对，就要在 Prompt 里明确要求模型只提取必要信息，而不是逐步复述每张图。

第二个坑是视觉幻觉。图片模糊、反光、光线不足时，原生多模态模型可能一本正经地编造细节。我在测试中遇到最典型的情况是：一张褶皱严重的 T 恤照片，模型直接断定它是棉质，但实际上标签上写的是涤纶。解决办法是在 Prompt 里强调“看不到的信息不要猜测”，同时在工具调用前设置一层“置信度确认”，让模型先判断图片是否清晰可用。

第三个坑是工具调用与视觉理解的冲突。模型在查看图片时会把注意力全放在图像上，导致对工具参数的提取出现失误。比如图片中有一个商品 ID，模型识别对了，却在调用工具时把 ID 填错一位。扣子平台虽然支持工具调用，但原生模型的偶尔手滑依然存在。建议做法是工作流里不要指望模型一次性完成所有事，参数抽取可以用一个专门节点，降低误填概率。

6.2 编排方案踩过的坑

编排方案的第一个坑是中间表达不稳定。不同视觉模型输出的描述风格差异巨大，有的喜欢“一件外套”这种概括式描述，有的会输出“黑色带帽冲锋衣，正面有两个口袋”这种结构化描述。我最后不得不强制要求视觉模型按固定 JSON Schema 输出，才能让 LLM 稳定消费。

第二个坑是引用关系难以维护。多轮对话里，用户在第一轮发了一张图，第五轮说“那件黑色的呢”，工作流方案很难准确把“那件”映射回第一轮的图片。原生模型因为图片词元一直保留在上下文中，天然能处理这种跨轮引用。工作流方案只能靠额外状态管理去实现，复杂度很高。

第三个坑是失败重试策略。链路长、节点多，任何一个节点临时故障都会导致整轮对话失败。别指望平台自带的默认重试能救你，必须针对不同节点配置不同的超时时间和重试次数，还要有一个兜底文案，保证用户不会面对一只沉默的 Agent。

6.3 两条路线通用的几条 Tips

无论选哪条路线，有几条经验是共通的。先跑通 MVP 再谈优化，不要一上来就把知识库、记忆、多轮对话、工具调用全部堆上，那条路九成会失败。我用原生方案搭的第一个产品 demo 只有“看图说话 + 工具查询”两个能力，上线试用一周后才逐步叠加。

再一个建议是务必建立评测集。多模态 Agent 的评测不是聊几句感觉“还行”就行，要固定一批真实业务输入，把输出结果录下来，每次改动后重新跑一遍，看有没有引入回归。我见过太多团队因为“前段时间还能答对，现在就答错了”的问题吵架，最后发现是模型悄悄升级过行为变了。

最后是善用可观测性。无论是扣子平台还是 Dify，都要把每个节点的输入输出日志打开。自己在测试阶段多积累一些失败样本，随时回看。别等到用户来投诉了才想起来排查链路，到那时你会发现自己连问题发生在哪个节点都找不到。

我个人的实际体会是，多模态 Agent 的竞争力，很多时候并不取决于模型本身有多强，而取决于你把它接入业务闭环里解决问题的能力到底扎不扎实。现在的技术选型窗口很微妙——原生方案还在快速进化，编排方案也远没到被淘汰的时候。与其在网上争论哪条路线是未来，不如把你自己的业务输入拿出来，两周内各做一个 POC，让真实业务数据替你做决定。这样踩出来的路，才是你自己最有底气的那条。