从立项到正式交付，我们团队用大半年时间把一套“原生视觉生成智能体”从零搭起来。印象最深的是初期推翻重来的那次：当时所有人默认的方案是“语言模型 + 外部图像生成服务”，把视觉生成当成工具去调用，结果在真实场景里根本跑不通。后来我们转向原生架构，让视觉感知、生成、决策在一个多模态模型体系内闭环流动，才真正把“让模型自己看着结果改图”这件事做成了。这篇文章不聊PPT概念，直接讲架构设计、训练管线、推理优化、评测体系，以及那些文档里不会写的坑和取舍，适合正在做图像/视频生成应用、或想让Agent拥有生成能力的团队参考。
1. 从“外部工具”到“原生能力”：重建视觉生成智能体的决策起点
1.1 最初那套“LLM+生成API”架构为什么被推翻
立项初期，技术选型几乎是一边倒：用语言模型做意图理解和任务规划，把图像生成能力包装成API服务，再通过函数调用串起来。这个方案听起来稳妥，实际一跑就暴露问题。
最致命的是信息损耗。用户说“把这张产品图的背景换成木质桌面，阴影再柔和一些”，“木质桌面”到底是什么木色、纹理密度多大、阴影柔和到什么程度，语言模型只能靠文字参数猜测。生成的图返回来后，语言模型还要依赖另一个多模态模型的文字转述才能“理解”结果，而转述本身就在丢信息。一来一回，第一轮结果往往和用户真实意图偏差很大，需要多轮重试。
第二个问题是反馈回路太长。每一步工具调用都是一次完整的前后端交互，生成、理解、再生成叠加下来，单次完整迭代经常要十几秒。真实用户在线使用时，等待体验非常差，用户往往改两轮就放弃了。更麻烦的是，语言模型并不真正“看”图，它对生成结果是否成立没有视觉判断力，只会机械地重试同样的话术。
所以在内部演示跑通之后，我们果断放弃了这个方案。结论很直接：想做一个真正能“边看边改”的智能体，视觉能力必须进入模型主干，而不是挂在外面当附属工具。
1.2 原生视觉生成智能体究竟是什么
“原生”这个词听起来玄，其实核心就一句话：视觉感知、视觉生成、决策判断在一个模型体系内部闭环，中间不需要把图像翻译成一段自然语言再传给另一个模型。
展开讲，原生视觉生成智能体要具备几个能力。第一，它要能直接读取当前画布，把像素内容变成内部特征表示，而不是靠外部模型描述。第二，它要能在内部做出生成决策——是放大某块区域、修补瑕疵、调整整体色调，还是新增一个物体。这个决策可以来自语言指令，也可以来自模型自己“审视”图像后的判断。第三，它的生成模块直接吃视觉特征作为条件输入，保证局部编辑、风格迁移这类操作具备像素级精度。
一个比较直观的类比：过去是“文案策划”理解需求后写一段需求文档，再发给“外部画师”执行，中间改稿全靠文字沟通；原生方案更像是把策划、画师、美术指导合并成一个人，自己看着画面下笔，不满意就在画布上微调，达到效果后再停手。
传统架构里的Agent，视觉能力是外挂的；原生架构里的Agent，视觉理解和视觉生成就是它的底层操作系统。
1.3 什么团队适合做，什么场景必须做
做这套系统的过程中，我反复想的一个问题是：原生方案值不值得做？毕竟成本比“API调用”高得多，门槛也完全不是一个量级。
我的判断是：存在高频多轮编辑需求的场景，必须做原生。典型例子是设计工具，用户会在一个画布上反复调整产品图、海报、插画，每轮都要看结果再决定下一步。另一个例子是游戏美术和3D资产生成，用户先确定概念图，再生成多角度视图，再细化局部，每一环都依赖视觉反馈。
反过来，如果只是“一次性文生图”，比如输入一段prompt拿到一张图就结束，那原生架构的优势并不明显，用成熟的外部生成服务加上不错的调度策略就够用了。
团队层面，做原生方案需要三类积累：多模态模型的训练经验、足够的GPU算力和数据工程能力，以及愿意接受较长的研发周期。如果这三样里缺两样，建议先用混合方案试水，但我们这次的体会是，一旦确定要长期投做视觉Agent产品，迟早要走上“原生”这条路，晚走不如早走。
2. 系统整体设计：视觉模块、决策模块与记忆模块如何协同
2.1 关键模块划分与职责边界
架构设计的第一步，是把系统拆成边界清晰的模块。模块拆得好不好，直接决定后面训练和排障的复杂度。我们的设计包含六个核心部分。
感知模块：负责读取用户上传的参考图、当前画布、历史生成结果。它内部是一个视觉编码器，输出的是特征向量网格，而不是简单的文字标签。这部分跟传统图像理解模型很像，但关键差异在于它的输出要直接喂给生成模块，所以特征保留的细节粒度要求更高。
生成模块：系统真正“落笔”的地方。我们用的是基于扩散范式的Transformer主干，输入由文本指令特征、感知模块输出的图像特征、以及控制条件共同组成，输出则是当前画布的完整更新。也就是说，模型每次生成的不再是一张独立新图，而是“原来那张图经过修改后的结果”。
规划与决策模块：负责理解用户语言指令，把它拆解成“改背景”“调光影”“新增物体”等原子操作，并决定操作的执行顺序。它还负责判断什么时候算完成。这一点非常关键：智能体不能用户说一嘴就无限改下去，它要有“停手”的能力。
评估反馈模块：内嵌一个轻量级视觉奖励模型，实时对当前生成结果打分，判断是否满足指令要求。这个模块相当于智能体的“内审员”，有了它才能形成生成—检查—再生成的闭环。
会话与视觉记忆模块：保存多轮对话记录、历史操作、当前画布特征。它解决的是“记得上一笔长什么样”的问题，没有它，每轮生成都会被当成全新任务处理。
工具调度模块：调用外围能力，比如素材库检索、检测模型、OCR、以及最终的图像后处理和审核，这些能力不属于生成主干，但对完整产品必不可少。
模块之间传递的统一数据结构，我们定义为“视觉状态包”：包含当前画布的低维特征、高维特征索引、画布尺寸变化记录、最近的编辑指令、置信度评分。所有上层模块都围绕这个状态包工作，避免每个模块各搞一套接口导致互相对不上。
2.2 统一控制表示：把用户指令变成生成模型读得懂的条件
模块拆完之后，最棘手的问题是如何把“用户的高层语言指令”和“像素级操作需求”统一表示出来。我们做过好几版方案，最终沉淀为一套“条件层”机制。
具体做法是：所有控制信息——不管来自自然语言、用户拖拽的框、还是参考图的风格向量——都先被转成统一的结构化条件。例如“把背景换成木质桌面”，解析后得到的是一个语义区域替换条件：目标区域是背景，参考风格是木质纹理，操作类型是替换；“把阴影调柔和”则对应一个光照参数调整条件。这些条件被编码成一组条件向量，然后通过自适应调制和交叉注意力两条路径注入生成主干。
这比单纯把文本拼进prompt要可靠得多。原因在于，文本会被模型“自由发挥”，而结构化条件绑定了区域、动作和风格三要素，生成模块在解码时受到约束，输出的改动就锁定在用户指定的区域内。我们也保留了自由文本输入的兜底路径，毕竟有的指令本身很抽象，比如“让它更有高级感”，这种完全没法转成结构化条件，只能让模型基于整体风格分布去理解。
在局部编辑场景里，控制表示还要考虑“原图约束”。否则模型很容易把整张图重画一遍，看起来质量很高但已经不是用户那张图了。我们的做法是把原图对应的噪声潜变量与生成噪声进行偏移融合，简单说：保留原有内容的信息，同时让新条件有机会改变目标区域。
2.3 多轮生成状态传递：让模型记住上一笔长什么样
多轮编辑是原生视觉生成智能体最核心的使用场景，而它恰恰最容易出问题。用户先让模型“加一个红色按钮”，又说“按钮向下移一点”，再说“把它变成圆形”。如果系统每一轮都把整个画布当作全新输入，那么按钮的位置、尺寸、颜色会在每轮之间不断漂移，这就是训练时最典型的“图像身份漂移”问题。
我们从设计之初就引入了工作内存机制，避免这个问题。工作内存里保存三样东西：画布的压缩特征缓存、最近十步的用户指令摘要、每一步操作对应的局部更新掩码。生成时，模型会先查询工作内存，判断这次改动是否落在上一轮改动的相关区域。如果是，它会以缓存的原图特征为基准，只在掩码区域内做增量生成，而不是从头采样一遍。
这套机制还有一个好处：支持“撤销上一步”。因为每一步都记录了局部更新掩码和改动前特征，用户说“不对，回到上一步”，系统可以直接回滚到对应状态，不需要重新推理一次。这是很多Demo阶段看起来离谱、但真实产品里用户非常在意的能力。
多轮状态传递的接口设计，我建议在架构阶段就定死，不要等训练完了再补。因为后续训练数据构造、推理缓存、评测流程全都依赖这个接口。我们前期在这上面返工过一次，代价很大，后面才意识到这其实是最需要提前设计的部分。
3. 训练数据和三阶段训练管线：让模型学会“边看边画”
3.1 数据从哪来：真实交互日志、规则合成与人工偏好的搭配
原生视觉生成智能体和普通文生图模型的训练数据，差别非常大。普通模型只需要“文本—图像”对就够了，我们还需要“初始状态—指令—操作—结果—最终满意度”这样的轨迹数据。一条轨迹就是一次完整的交互过程，长短不一，有的三轮，有的二十多轮。
数据来源主要有三个。首先是真实用户交互日志，质量最高，因为里面包含了真实的意图变化、中途反悔、局部调整等行为模式，这是合成数据很难模拟出来的。缺点是数量少，且冷启动阶段没有用户，只能靠内部体验团队手工采集。
其次是规则合成数据。我们从一批高质量素材图出发，用视觉语言模型自动为每张图生成属性描述，再按规则生成编辑指令序列，每一步执行一个可验证的编辑动作，比如“把左上角的圆形向右移动20像素”“把背景饱和度降低10%”。这类数据量大、动作干净，但太规整，容易让模型只会处理“教科书式指令”。
最后是人工偏好数据。对同一条指令，先生成多个候选结果，再由标注人员排序打分，作为偏好对齐阶段的训练信号。这块成本最高，但对模型“什么叫改得好、什么叫改坏了”的判断至关重要。
三部分数据的配比，我们经过多轮实验后稳定在真实日志30%、规则合成60%、人工偏好10%。注意，配比不是固定的，越到后期越要逐步提高真实日志的占比，因为模型早期学基础能力靠规则数据效率高，后期要打磨真实场景表现则必须靠真实数据。
3.2 三阶段训练：从生成底座到智能体行为
训练管线分为三个大阶段，每个阶段目标不同，不能混在一起。
第一阶段是生成底座预训练。用大规模图文数据、视频帧数据让模型掌握基础的图像生成和编辑能力，重点是让模型学会内容和风格的解耦：给定一个内容主体，可以自由切换风格、布局、光照；给定一个风格，可以套用在不同内容上。这个阶段的产物是一个强大的“生成器”，但它还听不懂复杂的多轮指令。
第二阶段是监督微调。使用轨迹数据训练模型在具体状态下执行具体操作，输入是当前画布特征和这一轮的用户指令，输出是生成结果。这里有一个容易被忽视的点：轨迹中必须包含“停手”这个特殊动作。我们在数据里刻意加入了大量“用户在满意后停止修改”的样本，让模型学会判断什么时候不需要继续改动。如果缺少这类样本，模型会出现过度修改倾向——你让它微调一下阴影，它把整张图的风格都改了。
第三阶段是偏好对齐。这个阶段用人工偏好数据优化模型，方式上和语言模型的对齐类似，但对象从“文字回复偏好”变成了“图像修改结果偏好”。正样本是符合用户多次修改习惯的结果，负样本是虽然单张图质量很高但偏离用户意图的结果。这里有个关键经验：偏好对齐的负样本不能光用低质量图，更要包含“质量高但不按要求改”的图，否则模型会变成“优秀画师但执行力差”。
3.3 训练稳定性的实战经验：loss尖峰、梯度冲突与多分辨率
训练这种多模块联合的视觉生成模型，稳定性是最大的隐性成本。我们前后遇到的典型问题有几个，每个都折腾了不少时间。
第一个是loss尖峰。训练到某个step时损失突然飙高几个量级，然后模型直接崩掉。排查后发现两类原因：一是混合精度下梯度溢出，二是某几条异常长轨迹引发的梯度爆炸。解决办法是梯度裁剪阈值调低，同时在loss监控上做平滑化，发现连续N步异常就自动跳过这批数据并恢复最近一次正常checkpoint。自动回滚机制很关键，否则半夜训练中断，第二天人力成本极高。
第二个是视觉编码器和生成主干的梯度冲突。早期我们让感知模块全程参与训练，结果发现生成模块学得越强，编码器参数越容易把特征分布带到奇怪方向。后来把编码器底层的梯度冻结，只允许高层特征参与微调，损失立即稳了很多。这条经验说明：多模块联合训练时，不是所有参数都适合端到端更新，合理的冻结策略能省下大量调参时间。
第三个是多分辨率问题。真实用户上传的画布尺寸五花八门，如果训练时只喂固定分辨率，线上效果会明显退化。我们采用按面积分桶采样，把相近尺寸的样本放进同一个batch，同时对位置编码做连续化处理，让模型在插值尺寸下也能保持稳定。这一步是线上画质均匀性的基础，不能省。
4. 推理服务化落地：在成本、延迟与生成质量之间找平衡
4.1 大视觉模型分布式推理的调度思路
模型训完只是第一步，把模型变成稳定的线上服务是另一场硬仗。我们的生成主干参数量很大，单卡显存放不下，推理必须走分布式。
在推理调度上，我的核心感受是：不能把所有请求一视同仁地丢进同一个GPU池。我们按任务复杂度分了两级。轻量操作，比如局部亮度调整、颜色替换，走一个精简版模型，采样步数少、分辨率低，延迟控制在1秒以内；复杂操作，比如多物体布局变更、风格迁移，走完整模型，采样步数多，允许3秒以上延迟。这样分流的直接好处是GPU利用率瞬间上来了，用户体验也稳定了。
分布式推理本身的拆分方案按常规思路来：按层切分的流水线并行和按注意力头切分的张量并行结合使用。对于扩散模型，还要额外注意采样步数的调度——扩散模型每一步都有完整的Transformer前向计算，不能像自回归模型那样靠KV Cache一步步延展。因此我们把“步数”作为一种显式调度参数，在线动态调整：队列拥塞时先给复杂任务降一档步数，保证整体吞吐；闲时再把步数拉满。
4.2 三个行之有效的延迟优化手段
离线实验和线上实测下来，有三个优化手段效果最明显，且不需要牺牲太多质量。
第一个是采样步数压缩与蒸馏。扩散模型的推理延迟与采样步数几乎线性相关。我们训练了一个步数压缩版本，把原本需要几十步收敛的扩散过程压缩到四步内出图，配合蒸馏技巧，肉眼几乎看不出差异。这个版本专门服务轻量操作和预览场景。
第二个是KV缓存复用。多轮编辑时，用户往往只改画面的一小块区域，其余部分完全不变。传统做法是整张图重新过一遍模型，非常浪费。我们实现了区域级缓存：每一轮生成的注意力键值缓存按网格位置保存，下一轮只对被修改区域影响的网格重新计算，其余网格直接复用上一轮结果。注意，这个复用不是无条件的，当用户改变整体风格或构图时缓存要全部失效，否则会出现局部和整体不协调的问题。
第三个是提前终止策略。评估反馈模块本身很轻量，可以在扩散采样的中间步骤实时对当前潜变量做一个粗略满意度判断。如果模型已经大概率满足指令了，就提前结束采样，不再执行后续步数。这个策略简单粗暴，对大量“只需要小幅度修改”的请求效果非常好，能省掉近三成计算量。
4.3 实战案例：同画布连续编辑场景延迟降低60%
讲一个具体的优化案例。我们的典型场景是用户在同一张产品图上连续做三次编辑：第一次“把背景改成木纹桌面”，第二次“在右上角加一个白色标签”，第三次“把标签改成圆角并加阴影”。
优化前，每轮编辑都是完整推理，单轮延迟大约3.6秒，三轮下来用户等待超过10秒，放弃率很高。优化后我们做了三件事：第一轮用完整模型生成并缓存画布特征和KV缓存；第二轮只对右上角新区域做局部生成，其余区域特征全部复用，单轮降到1.8秒；第三轮在第二轮的缓存基础上继续增量更新，同时用提前终止策略判断“圆角和阴影”已经达标，单轮进一步降到1.4秒。三轮累计延迟从10.8秒压到约5秒，整体降低约54%，接近60%的目标。
让我印象最深的是，这个优化过程中最难的其实不是技术实现，而是接口改动。区域级缓存要求生成模块精确知道哪些网格受改动影响，这在架构上如果不提前留好“局部更新掩码”的接口，后面根本做不了。所以还是那句话：多轮状态传递的接口设计一定要前置。
5. 评测体系怎么搭：从“图好看”到“任务完成”
5.1 三类指标配比：客观质量、语义对齐与任务效率
视觉生成智能体的评测，如果只看图好不好看，一定会被带偏。我们的评测体系分成三大类指标，各管一段。
客观质量指标：用于衡量单张图像本身的生成质量，包括清晰度、结构合理性、美学分数等。这类指标和传统文生图评测一致，能快速发现模型是否崩溃、是否有明显伪影，但无法回答“改得对不对”。
语义对齐指标：衡量生成结果是否符合用户指令。常用做法是图文相似度打分，以及偏好模型评分。偏好模型分比纯相似度更贴近人类判断，但它本身也有偏好倾向，所以我们只把它作为人工评测的前置筛选器，不当作最终裁决。
任务效率指标：这是智能体特有的指标。包括多轮任务成功率（任务最终完成且用户满意的比例）、平均对话轮次（成功完成任务需要多少轮修改）、单次平均延迟、以及用户中途放弃率。前三个都是我们日常迭代中最关注的数字。
做这套体系时我最大的体会是：指标之间会打架。有些模型客观质量分很高，但多轮成功率低，因为它在第一轮就生成一张华丽但不按要求改的图，用户被迫重来。所以我们最后选择以“任务成功率”为核心北极星指标，其他指标看趋势变化，但不单独拍板。
5.2 多轮任务评测与回归集设计
评测不能只靠人工随机测，必须有固定的回归集，否则版本迭代根本没法对比。我们建立了包含两条路线的评测流程。
第一路线是单轮基准测试。固定2000条指令，覆盖人物、物体、场景、风格、光影、文字特效等九大类别，每条指令配标准输入图，记录单轮生成结果的客观质量和语义对齐分。这个集合每天都跑，任何模型更新先过这关，快速发现显性退化。
第二路线是多轮任务测试。模拟真实用户交互：设计一个任务模板，比如“将这张室内设计图从现代风格改为北欧风格，并保留主要家具布局”，要求模型自主规划步骤，执行到任务完成或达到最大轮次。评测人员对最终结果做满意度打分，同时记录轮次和耗时。
多轮任务集数量不需要很大，但必须保证任务质量。我们花了大量时间编写任务模板和判定标准，确保“什么算完成”是有共识的。这个环节不能偷懒，否则跑出来的成功率数字完全不可信。
5.3 评测结果如何反推下一轮迭代方向
评测体系上线后，我们拿到过几轮非常打击人的测试结果，但也正是这些结果让后续迭代有了明确方向。
第一次正式评测暴露的最大问题是多轮身份漂移。任务“先把人物衣服改成红色，再把背景调暗”，模型执行第一轮很完美，执行第二轮时人物的五官和衣服颜色都发生了偏移，明明只该改背景的。问题根源在于局部编辑时，原图约束在长链条中被逐步稀释。后来我们在训练数据里加大了“连续修改同一区域”的轨迹比例，同时把工作内存里的特征缓存设计得更稳定，情况才明显好转。
另一个问题是长尾指令覆盖严重不足。用户会说“把整体氛围变得更克制”，这种抽象指令在规则合成数据里几乎没有，模型表现基本靠猜。我们为此专门采集了一批带有抽象审美描述的轨迹数据，人工标注“克制”这类词对应的图像特征变化，并把这些样本加入偏好对齐阶段。这个过程比较费人力，但对产品体验的提升是决定性的。
6. 复盘与给后来者的建议
6.1 三个最值得说的坑
第一个坑是数据偏差。前期我们图省事，大量使用互联网抓取的图片作为训练素材，结果模型在用户真实上传的产品图、设计稿上表现不稳定，因为互联网图片的构图和审美分布跟垂直场景差异很大。这个坑特别隐蔽，因为单看训练集上的指标完全正常。后来我们花了不少精力重新构建领域内数据集，质量才上来。
第二个坑是评估体系搭建太晚。项目前两个月几乎都在看单图效果，“这张生成得真好看”成了口头禅。直到第一次用户内测，才发现很多任务根本完不成。如果时间倒流，我会在写第一行训练代码之前就把评测集的种子版本搭好，哪怕粗糙一点，也能让每个阶段的结果都有可比性。
第三个坑是推理成本没有提前估。智能体场景天然是多次迭代调用的，单次推理成本乘以轮次之后非常吓人。我们没有在一开始就设计分级算力调度，导致项目中期成本超标，不得不返工部署架构。成本问题应该和模型效果并列作为第一优先级来设计。
6.2 有的放矢的落地路径建议
如果想复刻这套系统，我的建议是先选定一个垂直场景，不要贪大求全。垂直场景会直接决定数据构造、评测指标和用户预期，比如做电商产品图智能体和做通用创作助手，完全是两套训练思路。
具体落地路径上，先把评测体系搭起来，再启动训练；架构阶段一定要设计好多轮状态缓存接口；训练阶段预留自动回滚机制，避免夜间训练崩溃带来的沉没成本；推理阶段一级分级调度能极大节省成本。
最后提醒一点：视觉生成智能体最终要面向真实用户，生成内容的安全审核、版权素材边界、模型水印、以及“拒绝生成不合规内容”的能力，都要在系统设计里占据一席之地，不能等到上线前再临时补。这些工作不性感，但它们是产品能长期存在的底线。
如果让我再走一遍这条路，我会在立项的第一周就做两件事：固定一个包含三千条真实任务的评测集，以及把画布状态缓存接口的定义写进架构文档。这两件事听起来朴素，但它们在后面几乎每一个关键决策里都起到了定盘星的作用。原生视觉生成智能体这条赛道还非常新，远没有到技术收敛的时候，眼下每一个扎实的工程细节，都会成为下一阶段竞争的底牌。
