企业官网建设流程全解析

1. 从"只会生成"到"会查资料"：视频模型这一次补上了最缺的一环

做视频生成的朋友应该都有同感：这两年生成质量卷得飞快，几秒的高清视频已经不是什么新鲜事，但大家心里都清楚，模型本质上是个"闭着眼睛画画"的选手——你给它一句提示词，它把所有对世界的理解都押在训练时见过的那堆数据里。遇到时效性强的问题（比如"帮我生成一段2025年某科技展会现场的镜头"），或者需要精确知识支撑的场景（比如"生成一段飞机起降时驾驶舱视角的画面"），模型就开始一本正经地瞎编：机舱仪表盘长得像科幻片道具，展会Logo字体全错，建筑结构比例失调。

我今年一直在跟的项目，就是冲着这个痛点去的。我们做了一个 8B 规模的视频生成智能体，核心改动不是把生成模型换得更大，而是给它接上了"工具调用"的能力——让视频生成模型在动手之前，先像人一样去查资料、做模拟、看参考图，最后才进入生成环节。这篇文章我就把这套系统的完整思路、架构拆解和实测效果整理出来，给同样在做视频生成Agent或者想做多模态工具调用的朋友做个参考。

这套系统解决的核心问题很清晰：

1. 知识时效性问题：训练数据截止之后的世界变化，模型不知道，但工具知道。
2. 精确细节还原问题：生成特殊场景时容易产生幻觉，工具查询结果可以作为强约束注入。
3. 复杂物理/逻辑模拟问题：纯靠生成模型推理"物体怎么动"经常翻车，交给外部模拟器算好再生成，反而又快又准。

整个项目从调研到跑通Demo用了大概两个多月，中间换过两版思路，踩了不少坑。下面我把能复现的部分尽量讲透，尤其是工具调用和视频生成模型之间的交互设计，这块目前公开资料里讲得特别少。

2. 市面上视频生成Agent的三种路线，为什么大多数都不够"聪明"

做这个项目之前，我先把手头能找到的视频生成Agent方案过了一遍。大致可以分成三种路线，各有各的问题。

2.1 提示词直出路线：最普遍，但上限最低

这是绝大多数产品的默认方案。用户输入文本，模型直接输出视频。优点是管道短、延迟低、体验流畅；缺点就是对模型自身能力要求极高，凡是训练语料覆盖不到的知识点，基本只能靠"创造"。

举个实际例子：我们测试时让模型生成"一段1980年代中央电视台新闻联播开场画面"。模型对"新闻联播"的旋律和蓝底背景有印象，但片头动画里那个地球转动的节奏、字体的具体样式、画面比例和色调，全凭想象——出来的结果乍看像，细看全是错的。原因很简单：训练语料里关于这个场景的文本描述远不足以支撑像素级的细节还原。

2.2 外部检索辅助路线：能查，但不会用

第二种方案是给模型配一个检索模块，先从知识库里搜出相关图文资料，再一起塞给生成模型。这比纯直出强，但也只是"堆料"，不是"思考"。

问题出在整合方式上：很多实现就是把检索结果拼进提示词，生成模型面对一大堆文本和图片，并不知道该重点参考哪一条。检索出来10张参考图，模型可能只"看"了最显眼的那一张，关键细节反而被淹没。这就像让一个厨师照着十本菜谱做菜，他可能只盯着第一本看，最后做出来个四不像。

2.3 多步Agent规划路线：方向对了，但容易"想太多"

第三种是我的前一个版本方案：让模型先做任务拆解，生成一个分步计划，再逐步执行。听起来像那么回事，但实际跑下来发现，基于 LLM 的规划器面对视频生成这种"一次成型"的任务时，经常规划得很漂亮，执行得很拉胯。

比如让它生成"一段瀑布从高处倾泻而下、水花四溅的慢镜头"，规划器给出的步骤是"第一步生成背景，第二步生成水流，第三步合成"。听起来没毛病，但问题是视频生成不是搭积木，不是每步生成完就能无缝拼起来的，风格、光影、镜头运动稍微对不上，合成出来就是一场灾难。

而且规划器本身也是个模型，它也会犯错，多拆一步就多一个出错点，链路越长，误差积累越严重。

2.4 我们为什么选择第四条路：工具优先，生成为辅

我最后定下来的思路和上面三条都不一样，核心理念是八个字：能不生成，就不生成。意思是在进入视频生成模型之前，先让智能体判断"这个问题需不需要查资料、需不需要做模拟、需不需要算参数"，如果需要，就先把活儿干完，拿到确定性的中间结果，再喂给生成模型。

这个思路的形成来自于一个特别直观的对比。我们做过两组测试，让模型生成"一辆汽车在雨天高速公路上行驶，轮胎溅起水花"。第一组的画面是纯生成的，水花形态全靠模型脑补，经常出现水花像爆炸、轮胎和地面没有真实接触感的违和效果。第二组先调用一个简单的物理模拟器，算出轮胎转速、水花飞溅轨迹、落地位置，再把这些参数和轨迹图传给生成模型，出来的结果无论是水花的形态还是轮胎的互动感都明显真实了一大截。

这个对比让我确信：让模型"先问工具，再动手"是值得投入的方向。

3. 8B模型做主控：为什么小模型够用，关键在"工具调度的度"

很多朋友一听"8B"就觉得太小了。现在主流视频生成模型动辄几十B，一个8B的小模型做智能体主控，行吗？我在项目启动前也犹豫过，实际跑下来发现，只要把它的职责范围划清楚，8B完全够用，甚至比大模型更合适。

3.1 主控模型不需要"全知"，只需要"会分工"

智能体主控模型承担的任务其实很纯粹：读懂用户意图、拆解是否需要工具、调用哪个工具、把工具结果组织好传给生成模型。这本质上是一个"调度"任务，而不是"生成"任务。它不需要上知天文下知地理，它只需要知道"遇到这种情况应该去哪里查、查完怎么用"。

我用一个生活化的类比来理解这件事：主控模型像一个项目负责人，不需要自己会画图、会算结构、会做预算，但必须知道什么时候找设计师、什么时候找结构工程师、怎么把各方的成果汇总成一份可执行方案。8B模型经过针对性的工具调用数据微调之后，完全能胜任"负责人"这个角色，而且比大模型更专注、更少发散、推理成本还低。

3.2 工具调度架构：一个"路由器"加四个"执行器"

整套系统的调度层我设计成"一主四从"的结构：

• 主控模型（8B）：负责意图理解和工具路由。
• 文本检索工具：对接多模态知识库，负责查文字资料、新闻、百科内容。
• 图像检索工具：负责查参考图、示意图、风格图。
• 物理模拟工具：负责动力学计算、轨迹生成、场景参数模拟。
• 代码执行工具：负责通用计算，比如算比例、转格式、生成数据表。

主控模型收到用户请求后，先做一次意图分类，输出一个 JSON 格式的工具调用计划，例如：

{ "query": "生成一段F1赛车在摩纳哥赛道过弯的画面", "tools_needed": ["image_search", "physics_simulation"], "tool_arguments": { "image_search": { "query": "摩纳哥赛道弯道实景", "top_k": 5 }, "physics_simulation": { "type": "vehicle_dynamics", "speed_kmh": 180, "turn_radius_m": 30, "surface": "asphalt_wet" } } }

主控模型不负责执行具体工具，只负责输出这个 JSON，由外围的调度器去实际调用工具。这样做的好处是把"决策"和"执行"解耦，主控模型就算对某个工具的具体参数格式不了解，也能通过少样本示例给出大致框架，由调度器兜底补齐细节。

3.3 工具结果的"压缩与打包"：决定生成质量的关键一步

工具调用完，结果怎么传给视频生成模型，这一步是整个系统里最容易被忽视、但也最影响质量的地方。

我的做法是：工具返回的结果不能直接全量喂给生成模型。以图像检索为例，搜出5张参考图，如果全部拼进提示词，生成模型很可能被多余信息干扰。正确的做法是让主控模型对检索结果做一个"重点标记"，把当前任务最需要参考的那张图标注为最高优先级，同时提取图中关键元素的文字描述（比如"赛道护栏是红白相间"、"弯道外侧有蓝色广告牌"），连同图片一起传给生成模型。

物理模拟工具的输出也一样。模拟器算出来的是一堆坐标点和速度曲线数据，不能让生成模型直接读数字。调度器会把轨迹数据转化为两样东西：一张可视化的轨迹示意图（图片格式）和一段精简的文字摘要（如"车辆以180km/h入弯，弯中减速至140km/h，出弯加速至200km/h"）。生成模型拿到图片和文字摘要，既能理解"这个弯是怎么过的"，又不会被原始数据淹没。

提示：工具结果的"压缩"不是简单截断，而是提取对生成最有约束力的关键信息。多问自己一句："如果只能给生成模型三句话，哪三句最能避免它瞎编？"答案就是需要保留的核心信息。

4. 物理模拟与知识检索的接入：两个最实用的工具场景拆解

工具调用听起来很抽象，落到具体场景才看得明白。我挑两个我们在项目里打磨最久、实测效果最好的工具场景，拆开讲讲。

4.1 物理模拟工具：让"水花""烟雾""碰撞"不再靠脑补

视频生成里最常翻车的三个物理效果就是水、烟和碰撞。这三个东西的动态规律非常复杂，纯靠生成模型脑补，要么物理上不合理（水花逆重力飞），要么质感不对（烟雾像棉花糖），要么时序不对（碰撞之后物体还没反应过来就开始变形）。

我接入的物理模拟工具是站在现有开源物理引擎的基础上做的二次封装。核心不再是"从头算一个流体模拟"，而是把常见视频场景抽象成几个固定模板：车辆运动、落体运动、流体飞溅、粒子扩散。每个模板都有十几个可控参数，主控模型要做的不是提供一整套物理方程，而是填参数。

比如生成"石头丢进水面激起水花"这个场景，模拟工具需要的参数是：

• 石头质量：0.5kg
• 入水速度：8m/s
• 入水角度：60度
• 水面张力和密度：默认淡水参数

工具在几百毫秒内算出一组水花飞溅的粒子轨迹数据，然后转成一张粒子运动轨迹示意图，标注出最大飞溅高度、扩散半径和回落时间点。生成模型看到这些约束后，出来的水花效果和参考轨迹的重合度极高，肉眼几乎看不出是"生成"的。

这个方案的另一个好处是可复核。以前我们说"这个视频看着假"，只能凭感觉；现在可以直接把生成画面和物理轨迹叠加对比，一看就知道偏差出在哪。这对调试生成模型帮助特别大。

4.2 多模态知识检索：让"查资料"从装饰变成硬约束

第二个核心工具是知识检索。这条链路最初做得很糙，就是搜索关键词、返回文字结果、拼进提示词完事。跑了一段时间发现，对于视频生成来说，纯文字检索的约束力太弱了——模型可能理解文字内容，但落到像素级别该长啥样还是靠猜。

后来我们把检索升级成"图文联合检索+结构化约束提取"，整个流程变成三步：

1. 解析问题关键词：从用户请求中提取需要"事实性知识"的部分。比如"生成1990年代东京街头出租车行驶的画面"，关键约束是"1990年代""东京""出租车"，这三项必须有据可查。

2. 多模态检索与筛选：同时检索文字资料和图片，由主控模型判定哪些图片的"年代感"和"地域特征"最可信，哪些文字描述能形成硬约束。比如某篇资料写明"1990年代东京出租车以白色和奶油色为主，车顶有公司名称灯箱"，这条文字描述就要作为硬约束单独提取出来，明确写进生成提示词，而不是混在一堆文本里让模型自己抓。

3. 约束分级注入：把所有检索结果分成"硬约束"（必须遵守，如车身颜色、灯箱形状）和"软参考"（可以借鉴，如街道氛围、路人穿着），分别用不同方式注入生成模型。硬约束放在提示词开头，用强调格式标注；软参考以图片形式附在后面。

这套改造的效果在"真实感"这个维度上特别明显。同样是生成历史场景，改造前模型只是"风格化地"表达某个年代，改造后几乎是"按图索骥"地还原。

4.3 两个工具的联动：让1+1远大于2

单独用每个工具都有收获，但真正让我觉得"这条路走对了"的时刻，是看到两个工具联动时的效果。有一个测试是生成"老式胶片电影放映机在黑暗房间里运转、光线穿过灰尘颗粒"的画面。

单靠知识检索，模型能还原放映机和胶片的静态细节；单靠物理模拟，模型能让光线里的灰尘颗粒有真实的漂浮轨迹；但如果分开生成再合成，画面要么静态细节对但动态不对，要么动态对但整体氛围不对。

联动之后，系统先把胶片放映机的结构参数、光线角度从知识库查出来，再让物理模拟算出灰尘颗粒在光束中的漂浮路径，最后把两个约束一起注入生成模型。出来的视频里，灰尘颗粒的疏密分布和运动方向完全符合那束光线的几何关系，而且胶片滚动的速度和颗粒漂浮的节奏是同步的——这个效果在纯生成方案里几乎不可能稳定复现。

5. 从理论到落地：训练数据、微调细节与推理管线配置

聊完思路和方案，这部分是大家最关心的实操环节：这套8B智能体到底怎么训练出来的？推理时怎么把工具调用和视频生成串成一条完整管线？

5.1 训练数据：三分靠收集，七分靠合成

主控模型的训练数据是最难搞的部分。市面上几乎没有现成的"视频生成工具调用"数据集，全靠自己造。我们造数据的方法有三种，按性价比从高到低排列：

• 合成数据（占比最高，约60%）：用规则脚本自动生成"用户请求-工具调用JSON"配对。比如从一批种子问题出发，用模板自动派生出不同表述的同义问法，再搭配对应工具调用计划。这一招的性价比最高，能快速扩充数据量，让模型学会"这类请求应该调这类工具"的模式。

• 人工标注（占比约20%）：人工写一批高质量的用户请求，标注出最合理的工具调用序列和参数。这部分数据最贵，但质量最高，主要用来教模型处理复杂请求和边界情况。

• 真实使用日志回流（占比约20%）：系统上线跑起来之后，把用户实测中调用工具成功和失败的案例都记录下来，定期筛选、清洗、再回填到训练集里。这是一个滚雪球的过程，用得越久，模型越聪明。

5.2 微调方案：LoRA与全参数微调的混搭

训练阶段我做了两组对比实验。一组用 LoRA 微调，一组做全参数微调。结论是：主控模型的工具路由能力用 LoRA 就够了，但理解和生成工具参数的能力，LoRA 明显不够，需要全参数微调。

原因在于，工具路由本质上是分类任务，LoRA 在低秩空间里就能学得很好；但生成工具参数是一个"结构化输出"任务，需要模型真正理解参数之间的逻辑关系（比如车速和转弯半径要匹配，不能出现180km/h还配30米转弯半径这种不合理的组合），这需要改动更多层的表示，LoRA 的低秩更新学不太动。

最终我的方案是：先全参数微调基础能力，再叠加一层 LoRA 微调路由偏好。两阶段加起来训练成本可控，效果也比单独用任何一种方案要好。

5.3 推理管线：一次请求的全过程拆解

整个系统跑通一次用户请求，完整流程是这样的：

用户输入 → 主控模型意图理解 → 生成工具调用JSON → 调度器并行/串行调用工具 → 结果压缩打包 → 注入视频生成模型 → 视频输出

有一个反直觉的教训：工具调用不是越多越好。初版系统里我鼓励主控模型尽量多调工具，觉得多查几步总没错。结果模型经常为了表现"自己很努力"，明明生成一个简单茶杯的旋转视频，也要先去搜"茶杯历史"、再做个"几何体模拟"，白白增加200毫秒延迟和35%的失败率。

后来的方案是把工具调用强度分成三个档位：

主控模型先判断请求落在哪个档位，再决定调用哪些工具。这样做之后，平均延迟下降了约25%，工具调用失败率从之前的11%降到了4%左右，生成质量没有下降甚至略有提升。

6. 实测结果与翻车案例：哪些场景真加分，哪些场景要警惕

这套系统在内部评测集上跑了三周，总共跑了1200组测试请求。我把结果分成了"明显提升""略有提升"和"不如直出"三档，各有代表性的案例。

6.1 明显提升：特定领域知识、物理效果、时间地点绑定

典型场景一：特定机械结构。让模型生成"老式机械钟表内部齿轮转动的慢镜头"。纯生成方案出来的齿轮经常是"看起来像齿轮但齿数比例不对、啮合关系混乱"；接入工具后，系统先查机械钟表的结构图，确认齿轮的齿距和啮合角度，再让物理模拟算出一组齿轮转动的角速度同步关系，最后生成的画面里齿轮咬合得非常精准，甚至能看出动力传递的层次感。

典型场景二：时空绑定内容。生成"某城市早高峰地铁站人流涌动"的画面。系统先检索该城市地铁站的实景图，提取站台结构、指示牌样式、车厢颜色等硬约束，再结合时段数据生成。出来的站台细节和真实场景的重合度非常高，而且人流的密度和走向比纯生成方案自然很多。

典型场景三：天气物理效果。生成"暴雨中雨滴打在湖面上"的镜头。物理模拟算出雨滴的落速、落入湖面产生的涟漪扩散速度以及雨滴密度，生成画面里的每一圈涟漪都有真实的时序关系，不是之前那种"到处都是圈、但节奏全乱"的假象。

6.2 略有提升：风格迁移、氛围渲染

像"赛博朋克风"、"水墨画风"这类风格化需求，工具调用的帮助就有限了。查资料能找到风格参考图，但风格迁移本身考验的是生成模型的审美能力，工具最多只能提供一个倾向性参考。这类场景下，工具调用的价值更多是"引导"而不是"约束"，提升幅度没前面三类那么明显。

6.3 不如直出：需要强创意表达、叙事连贯的角色动作

最让我警惕的一档，也是这周正在重点优化的方向：创意叙事类场景反而被工具调用拖累了。比如让系统生成"一只猫在月光下伸懒腰、然后跳上窗台的连贯镜头"，工具检索出一个"猫伸懒腰"的参考视频，结果生成模型被这个参考框住了，出来的动作反而没有纯生成版本灵动，缺少了那种"原创感"。

另一个翻车案例是"生成一段梦境风格的抽象画面"，系统先去检索"梦境视觉元素"，搜出来一堆超现实主义绘画，结果生成画面堆砌了太多符号化元素，反而失去了抽象的美感。在这个方向上的教训是：工具是给模型提供约束的，不是给它提供拐杖的。当用户的意图是"自由创作"时，工具调用应该降级甚至关闭。

6.4 参数对比表格：三种方案的实测数据

为了更直观地说明效果差异，我把纯生成方案、仅检索方案和完整工具调用方案在四个维度上做了对比：

可以看到，工具调用带来的延迟增加大约是1.1秒，这在视频生成任务里基本可以接受（生成本身就要几秒），但准确率和满意度的提升非常可观。

7. 踩坑记录与经验沉淀：五个值得写进笔记的教训

项目做下来，踩的坑比想象的要多。有些坑是网上查得到的，有些是跑出来才知道的。我把最值得分享的五个教训整理出来，每一条后面都附上了我们最终采用的解法。

7.1 坑一：主控模型被工具结果"带偏"

这是最早遇到的坑。主控模型在规划工具调用时，如果看到工具返回结果里有"推荐"字样，就容易顺着工具的话往下走。比如图像检索工具返回"这张图与查询高度相关"，主控模型就倾向于把它当作唯一权威来源，即使它其实不是最优参考。

解法：给工具返回结果加上"置信度评分+适用场景标注"。比如图像检索返回时带上"该图适用于外观参考，不适用于结构参考"之类的标注，帮助主控模型判断"这部分信息能不能用、怎么用"。

7.2 坑二：JSON工具调用计划过于刚性

初版设计里主控模型输出的工具调用 JSON 是严格模式，参数类型、取值范围都要精确匹配。结果发现模型经常在不必要的环节报错，整个流程卡死。

解法：把 JSON 解析改成"宽容模式"。只要模型输出的关键字段（工具名、核心参数）能提取出来，其他细节由调度器兜底补齐。这个改动让端到端成功率从72%提升到了86%。

7.3 坑三：物理模拟参数过于"物理正确"反而不好看

有一阵子我们追求模拟器输出的参数要绝对符合物理规律。比如雨滴的落速要按照真实重力加速度计算。结果生成的画面确实物理上没有硬伤，但视觉上反而不如那些"稍微夸大一点"的效果好看。视频艺术毕竟不是物理教科书，观众要的是"看起来对"，不全是"算起来对"。

解法：给模拟工具加一个"表现力系数"，默认值设在1.15左右。意思是可以把水花溅起的高度、烟雾的扩散范围等比物理真实值放大15%，视觉冲击力明显提升，而且观众不会觉得违和。

7.4 坑四：多工具并行调用时的上下文冲突

在深度档位，系统会同时调用图像检索和物理模拟两个工具。但两个工具返回的信息内容存在冲突时，比如图像里的车速感与物理模拟算出的车速不完全一致，生成模型会感到困惑，最终效果可能哪个都没跟。

解法：在结果压缩打包环节增加一步"冲突仲裁"。当两路工具返回结果不一致时，启用优先级规则：具体可量化的参数优先于模糊的视觉感受（比如物理模拟算出的车速优先于参考图里的主观感受）；硬性结构优先于风格氛围（比如站台结构优先于色调风格）。

7.5 坑五：小模型的知识盲区导致"不知道该调什么工具"

8B 模型的通病是知识面有限。有些用户请求里提到的专业名词，主控模型根本不认识，自然不知道应该调什么工具去查。比如有用户请求生成"回旋加速器内部粒子运动"的视频，主控模型不认识"回旋加速器"，于是没有触发检索工具，直接进入了生成环节，结果画面完全离谱。

解法：在意图理解阶段加一道"未知词检测"。当主控模型发现输入里存在自己不熟悉的概念时，强制触发一次通用百科检索，先把概念查明白，再决定后续工具调度策略。这道关卡看似简单，却把这类"概念未知型请求"的正确率从29%提升到了64%。我后来想明白了一个道理：对知识面窄的小模型来说，"不知道自己不知道"才是最危险的。

8. 这套架构还能往哪儿走：多阶段生成、持续学习与更聪明的"不用工具"

项目做到现在，主线能力已经稳定，但还有三个方向是我觉得特别有潜力、已经在动手或者准备动手的。

8.1 从"查询工具"到"组件生成工具"

目前工具调用的核心思路还是"查"，查资料、查参考图、查物理参数。下一步我想把工具从"查询型"扩展成"生成型"。比如接入一个"背景板生成器"专门生成静态场景底图；一个"角色姿态估算器"根据文本描述估算合理的骨骼姿态序列。这些组件生成工具的输出可以直接作为视频生成模型的强约束或条件输入，比"查出来的参考资料"更直接、更有约束力。

8.2 让主控模型学会"什么时候不需要工具"

前面提到创意叙事类场景里，工具调用反而拖了后腿。未来的优化方向不是简单粗暴地关闭工具，而是让主控模型学会区分"创作请求"和"还原请求"，并根据请求性质自动调整工具调用策略。这个能力对训练数据的要求很高，需要大量"为什么不需要工具"的负样例。我现在开始收集这方面的数据，希望把"不调用工具"也训练成一个合理决策，而不是一种能力缺陷。

8.3 持续学习：从实际使用中越用越聪明

最后是数据回流。系统每跑一次真实请求，无论成功还是失败，都是一次学习机会。我现在在做一套反馈收集机制，把每次请求的"用户行为+工具调用序列+最终生成效果+用户反馈"结构化记录下来，定期筛选出工具调用合理但效果不佳的case，作为训练数据微调主控模型。这套机制跑上一个月，效果应该会有一个明显的提升。

做这个项目最大的感受是，视频生成模型的能力天花板不只是生成网络本身，更在于围绕它的工具链有多厚实。我的经验是，现阶段与其追求把模型做大，不如先把工具链做好做精，让模型学会调用合适的外部资源，在"知识"和"物理"这两个短板上借力补全。8B 模型虽然小，但只要给它一双能查资料的手、一个会算物理的脑子，它能做成的事，比很多人想象中要多得多。