1. 从“图工程”说起为什么UI设计评估需要一套工程化打法第一次听到“图工程”这个词很多人会以为是某种图形渲染管线或者图像处理框架。其实在我们做Agent开发的圈子里图工程Graph Engineering指的是一套用图结构来组织、编排和评估复杂任务流程的方法论。它跟传统写代码最大的区别在于你不是在写一条线性的执行链而是在设计一张有节点、有边、有状态流转的图。每个节点可以是一个Agent、一次工具调用、一个评估函数边则定义了它们之间的依赖和触发条件。我最初接触图工程是因为一个很具体的需求给一套UI设计稿做自动化评估。当时团队里设计师出稿速度很快但评审环节全靠人工一个页面从布局、配色、间距到交互状态至少要三个人分别看一遍遇到争议还得拉会。效率低不说标准还不统一。后来我想能不能把UI设计评估这件事拆成多个可复用的检查节点用图的方式串起来让Agent自动跑完整个评估流程这就是这个项目的起点。这套东西适合谁呢如果你正在做Agent开发尤其是多Agent编排相关的项目或者你是一个前端/设计团队的技术负责人想用AI来辅助设计评审那这篇内容应该能给你不少可直接抄作业的思路。它不要求你精通图论但需要你对Agent的基本概念有了解——知道什么是工具调用、什么是状态管理、什么是评估函数就够了。核心关键词我先摆出来图工程、Graph Engineering、UI设计评估、Agent、多Agent。这几个词贯穿全文后面每个章节都会围绕它们展开。我尽量用大白话把每个设计决策背后的“为什么”讲清楚包括我踩过的坑和最后验证有效的方案。2. 整体架构设计为什么用图而不是链2.1 从线性链到有向图的思维转变大部分Agent开发教程里最常看到的模式是链式调用用户输入→Agent思考→调用工具→返回结果。这种模式简单直接适合任务步骤固定、依赖关系单一的场景。但UI设计评估不一样它的检查项之间不是简单的先后关系而是有并行、有分支、有回退的。举个例子一个页面的评估至少包含这几个维度布局合理性、色彩对比度、字体层级、间距一致性、交互状态覆盖、响应式适配。这些维度里布局和间距可以并行检查但色彩对比度如果发现问题可能需要回退到布局节点重新确认元素位置。如果用链式结构你得写一堆if-else来判断跳转代码很快就变成意大利面条。而用图结构每个检查维度就是一个节点节点之间的边定义了“什么条件下走哪条路”逻辑一目了然。我最终选的是有向无环图DAG为主、局部允许环路的混合结构。DAG保证了大部分评估流程可以并行执行提高效率局部环路则用于处理“发现问题→修复建议→重新评估”这种迭代场景。这个选择背后的考量是UI评估不是一次性的很多问题需要反复确认完全无环会导致流程僵化。2.2 多Agent分工与图节点的映射关系在图工程里每个节点不一定都是一个独立的Agent。我的做法是把评估任务按复杂度分层简单的检查用纯函数节点复杂的检查用Agent节点。比如“检查颜色对比度是否达到WCAG AA标准”这种完全可以用一个纯函数实现输入是颜色值输出是布尔值和对比度数值不需要Agent参与。但“判断这个页面的视觉重心是否合理”这种主观性较强的评估就需要一个具备视觉理解能力的Agent来打分。具体分工是这样的布局解析Agent负责从设计稿中提取元素的位置、尺寸、层级关系输出结构化的布局树。视觉评估Agent负责色彩、字体、间距等视觉属性的检查每个属性可以是一个独立的Agent也可以合并成一个多模态Agent。交互逻辑Agent负责检查按钮状态、表单验证、加载态等交互相关的设计是否完整。汇总裁决Agent负责收集所有节点的评估结果处理冲突生成最终报告。这四类Agent在图中的位置和连接方式决定了整个评估流程的效率和准确性。我试过把所有检查塞进一个Agent里结果就是提示词巨长无比Agent经常漏掉某些检查项。拆成多个Agent后每个Agent的职责单一提示词可以写得很精准准确率明显提升。2.3 状态管理与数据流转的设计要点图工程里最容易被忽视但最关键的部分是状态管理。每个节点执行完后它的输出要能被后续节点读取同时不能污染其他分支的数据。我用的是一个共享状态池加节点局部状态的混合方案。共享状态池里放的是全局信息比如原始设计稿的引用、项目配置、最终报告模板。节点局部状态里放的是该节点产生的中间结果比如布局解析Agent输出的布局树、视觉评估Agent输出的问题列表。节点之间的边在传递数据时可以选择性地把局部状态合并到共享状态池或者只传递一个引用。这样做的好处是并行分支之间不会互相干扰同时汇总节点又能拿到所有需要的数据。我踩过的一个坑是早期把所有数据都塞进共享状态结果两个并行分支同时写入同一个字段导致数据覆盖。后来改成每个节点有独立的命名空间汇总时按命名空间读取问题就解决了。注意状态池的读写一定要有版本控制或时间戳否则在环路中容易出现旧数据覆盖新数据的情况。我一般会给每个状态字段加一个last_updated时间戳读取时只取最新的。3. UI设计评估的核心节点拆解与实操要点3.1 布局解析节点从设计稿到结构化布局树布局解析是整个评估流程的第一步也是最容易出问题的一步。输入是一张设计稿图片或者一个Figma链接输出是一棵结构化的布局树每个节点包含元素类型、位置、尺寸、层级、文本内容等属性。我试过三种方案第一种是直接用多模态大模型识别图片中的元素优点是实现快缺点是精度不稳定尤其是元素密集的页面经常把两个按钮识别成一个。第二种是用传统的计算机视觉方法做元素检测精度高但需要大量标注数据而且对不同设计风格泛化能力差。第三种是混合方案先用CV方法做粗检测再用多模态模型做细分类和属性提取。最终我选了第三种。具体操作是先用边缘检测和连通域分析找出所有可能的元素区域然后用一个轻量级的多模态模型对每个区域做分类按钮、输入框、文本、图片等最后用一个布局关系推理模型判断元素之间的包含、相邻、对齐关系。整个流程跑下来一个中等复杂度的页面大概需要3到5秒准确率能到90%以上。实操中要注意几个细节设计稿的分辨率不能太低建议至少2倍图元素之间的间距如果小于4px检测时容易合并需要调小连通域的阈值文本元素的识别要特别小心因为文本行之间可能被误判为独立元素我一般会加一个文本行合并的后处理步骤。3.2 视觉评估节点色彩、字体、间距的量化检查视觉评估节点是UI设计评估里最“硬”的部分因为大部分检查都可以量化。色彩对比度用WCAG公式计算字体大小和行高可以直接从布局树读取间距一致性可以用方差来衡量。这些检查用纯函数实现就够了不需要Agent。但有些视觉评估是主观的比如“这个页面的色彩搭配是否和谐”。这种我交给一个多模态Agent来做给它一张设计稿截图和一组参考案例让它输出一个1到10分的评分和理由。为了提高一致性我会在提示词里明确评分标准比如“如果主色和辅助色的色相角差距在30到60度之间给8分以上如果差距小于15度给5分以下”。色彩对比度的计算我补充一下具体公式因为很多人容易搞混。WCAG用的是相对亮度公式对于每个颜色通道如果值小于等于0.03928除以12.92否则先加0.055再除以1.055然后取2.4次方。三个通道分别计算后按0.2126、0.7152、0.0722的权重求和得到相对亮度L。对比度就是(L10.05)/(L20.05)其中L1是较亮颜色的亮度。AA标准要求正文对比度至少4.5:1大号文本至少3:1。间距一致性检查我用的是标准差法把同一层级所有元素的间距值收集起来计算标准差。如果标准差超过平均值的20%就认为间距不一致。这个阈值是我试了好几次才定下来的太松了漏报太紧了误报。3.3 交互逻辑节点状态覆盖与流程完整性检查交互逻辑评估是最容易被忽略但实际影响最大的部分。一个页面看起来再漂亮如果按钮没有禁用态、表单没有错误提示、加载没有骨架屏用户体验就会大打折扣。这个节点的任务是检查设计稿中是否包含了所有必要的交互状态。我的做法是维护一个交互状态清单按组件类型分类。比如按钮组件需要检查默认态、悬停态、按下态、禁用态、加载态。输入框需要检查默认态、聚焦态、填充态、错误态、禁用态。然后让Agent逐个检查设计稿中是否有对应的状态展示。这里有个实操技巧很多设计师会把多个状态画在同一个画板上但不会标注哪个是哪个。我让Agent根据视觉特征来推断比如颜色变浅通常是禁用态有旋转图标通常是加载态。推断结果会标注置信度低置信度的会提示人工确认。提示交互状态检查最好在设计规范文档的基础上做如果团队有维护组件库可以直接从组件库读取状态清单比从设计稿推断准确得多。3.4 汇总裁决节点冲突处理与报告生成汇总裁决节点的作用是把前面所有节点的输出整合成一份可读的评估报告。听起来简单但实际做起来最复杂因为不同节点可能给出矛盾的结论。比如布局解析节点认为某个元素的对齐方式没问题但视觉评估节点认为间距不一致这时候就需要裁决。我的裁决策略是优先级加投票制。每个检查项有一个预设的优先级比如“对比度不达标”的优先级高于“间距不一致”。当两个结论冲突时优先级高的胜出。如果优先级相同就看哪个结论有更具体的证据支持。比如视觉评估节点给出了具体的间距数值和标准差而布局解析节点只是定性判断那就采信视觉评估节点的结论。报告生成我用的是模板填充加自然语言润色的方式。模板定义了报告的结构总体评分、问题列表、修复建议、参考案例。每个问题包含位置、严重程度、描述、建议。自然语言润色由一个Agent完成把结构化的数据转成通顺的段落。这里要注意润色Agent不能改变原始数据的数值和结论只能调整表达方式。4. 多Agent编排的实操细节与性能优化4.1 Agent之间的通信协议设计多Agent系统里Agent之间怎么说话是个大问题。我试过三种方式第一种是直接传递自然语言文本灵活但容易产生歧义第二种是传递结构化JSON准确但需要严格定义schema第三种是混合模式关键数据用JSON解释性内容用自然语言。最终我选了混合模式。具体来说每个Agent的输出都包含两部分data字段放结构化数据message字段放自然语言说明。下游Agent读取时优先解析data字段如果data字段缺失或格式不对再尝试从message字段提取信息。这样既保证了准确性又保留了灵活性。通信协议我还加了一个trace_id用来追踪一次评估流程中所有Agent的调用链路。排查问题时通过trace_id可以把所有相关日志串起来非常方便。这个设计参考了分布式追踪的思路在Agent数量多的时候尤其有用。4.2 并发执行与资源调度策略图工程的一个核心优势是支持并发执行。在我的评估流程里布局解析完成后视觉评估和交互逻辑检查是可以并行的。但并发不是无脑开线程需要考虑资源限制和依赖关系。我用的是一个基于拓扑排序的调度器。先把图转换成拓扑序然后按层级执行同一层级的节点可以并发不同层级的必须等前一层完成。并发度我设的是4因为再高的话API调用容易触发限流而且本地机器的内存也扛不住。每个Agent节点在执行前会检查依赖是否满足满足则进入执行队列不满足则等待。资源调度上我做了两个优化一是给每个Agent设置超时时间默认30秒超时后自动重试一次再超时就标记为失败并继续执行其他节点二是给API调用加了令牌桶限流确保不会因为突发并发把配额打满。这两个优化让整个流程的稳定性提升了很多之前偶尔会因为某个Agent卡住导致整个评估流程挂起现在基本不会了。4.3 缓存机制与重复评估的优化UI设计评估有个特点同一个设计稿可能会被反复评估尤其是设计师修改后重新提交。如果每次都从头跑一遍浪费时间和资源。我加了两级缓存第一级是设计稿级别的缓存如果设计稿的哈希值没变直接返回上次的评估结果第二级是节点级别的缓存如果某个节点的输入没变直接复用上次的输出。节点级缓存的key是节点ID加输入数据的哈希。比如布局解析节点的输入是设计稿图片如果图片没变布局树就不用重新解析。视觉评估节点的输入是布局树加设计稿截图如果布局树没变但截图变了比如设计师只改了颜色那布局解析可以复用缓存视觉评估需要重新跑。这个缓存机制让重复评估的耗时从平均15秒降到了3秒左右效果非常明显。但要注意缓存的失效策略设计规范更新时所有相关节点的缓存都要清掉否则会用旧标准评估新设计。5. 常见问题与排查技巧实录5.1 Agent输出格式不稳定的排查思路多Agent系统最常见的问题就是Agent不按格式输出。你让它返回JSON它给你返回一段带解释的文字你让它只输出数值它给你加一堆修饰词。这个问题我遇到过无数次总结了几条经验。首先提示词里要明确输出格式并且给出示例。比如“请以JSON格式输出包含score和reason两个字段score是0到10的整数reason是字符串。示例{score: 8, reason: 色彩搭配和谐但对比度略低}”。示例比单纯的格式说明有效得多。其次加一个格式校验节点。如果Agent的输出不符合预期格式校验节点会尝试修复比如从文本中提取JSON片段或者用正则表达式提取数值。修复失败则触发重试重试时在提示词里加上“上次输出格式错误请严格按照JSON格式输出”。最后如果某个Agent反复格式出错考虑换模型或者降低任务复杂度。我试过用同一个提示词在不同模型上跑格式稳定性差异很大。有些模型对格式指令的遵循度就是更高这个得实测。5.2 评估结果不一致的归因与解决同一个设计稿两次评估结果不一样这个问题很让人头疼。可能的原因有几种一是Agent的随机性大模型每次生成都有随机性即使温度设为0也不能完全消除二是缓存问题某些节点的缓存没及时失效三是并发导致的数据竞争。排查时我一般按这个顺序来先看trace日志确认两次评估走的节点路径是否一致然后检查缓存命中情况看是否有节点复用了不该复用的缓存最后检查并发写入的状态字段是否有冲突。大部分情况下问题出在缓存上尤其是设计稿没变但评估标准变了的时候。解决Agent随机性的办法是对关键评估项跑三次取众数或平均值。比如色彩和谐度评分跑三次取平均比单次评分稳定得多。代价是耗时增加但对于最终报告这种需要高稳定性的输出值得。5.3 性能瓶颈的定位与优化实录性能问题我遇到过几次比较典型的。一次是布局解析节点耗时突然从3秒涨到20秒排查后发现是设计稿分辨率从2倍图变成了4倍图CV检测的计算量翻了四倍。解决办法是加一个预处理步骤把超过一定分辨率的图片先缩放到2倍图再处理。另一次是汇总裁决节点耗时过长原因是它要等待所有上游节点完成而上游节点里有一个Agent偶尔会超时重试。解决办法是给汇总节点加了一个等待超时超过60秒就先用已有结果生成报告缺失的部分标注“待补充”。这样至少能保证流程不卡死。还有一个通用优化是减少不必要的Agent调用。比如有些检查项用纯函数就能做没必要让Agent参与。我统计了一下把纯函数能做的检查从Agent里剥离出来后整体耗时降低了40%左右。5.4 常见问题速查表问题现象可能原因排查方法解决方案Agent输出格式错误提示词不明确或模型遵循度低检查提示词是否有格式示例加格式校验节点失败则重试评估结果不一致Agent随机性或缓存问题对比两次trace日志关键项多次评估取平均检查缓存失效流程卡住不结束某节点超时或死循环查看节点执行状态加超时机制环路加最大迭代次数并发写入冲突共享状态未隔离检查状态字段命名空间每个节点独立命名空间汇总时读取布局解析精度低设计稿分辨率或元素密集检查输入图片质量预处理缩放调整检测阈值API调用被限流并发度过高查看API返回状态码加令牌桶限流降低并发度提示这张表建议打印出来贴在工位上遇到问题先查表能省不少排查时间。我自己的经验是80%的问题都能在这张表里找到对应项。6. 可复制的经验总结与扩展思路这套图工程加多Agent的UI设计评估方案我从零开始搭到稳定运行大概花了三周时间。其中第一周主要在试错试了各种Agent拆分方式和通信协议第二周在调优解决格式不稳定和性能问题第三周在加缓存和做报告模板。如果现在让我重新搭一遍估计三天就能搞定因为坑都踩过了。几个我觉得最值得复制的经验第一Agent的职责一定要单一一个Agent只做一件事提示词才能写得精准第二状态管理要提前设计好不要等到出问题了再改改起来很痛苦第三缓存机制越早加越好哪怕一开始只是简单的哈希缓存也能省很多时间第四trace日志一定要有没有日志排查问题就是盲人摸象。这套方案后续还可以往几个方向扩展。一是接入CI/CD流程设计师提交设计稿后自动触发评估评估不通过就阻止合并二是把评估结果反馈给设计工具直接在Figma里标注问题位置三是积累评估数据训练一个专门针对UI设计的评估模型替代通用的多模态Agent提高准确率和速度。我个人在实际操作中的体会是图工程这套方法论不只适用于UI设计评估任何需要多步骤、多维度、有依赖关系的任务都可以用图来组织。关键是你要先把任务拆解清楚画出节点和边然后再考虑每个节点用什么实现。不要一上来就写代码先画图图想清楚了代码就是水到渠成的事。 
长河君 · 2026/10/15 12:50:20 · 阅读 1.2k 图工程+多Agent：UI设计评估的工程化实践
1. 从“图工程”说起为什么UI设计评估需要一套工程化打法第一次听到“图工程”这个词很多人会以为是某种图形渲染管线或者图像处理框架。其实在我们做Agent开发的圈子里图工程Graph Engineering指的是一套用图结构来组织、编排和评估复杂任务流程的方法论。它跟传统写代码最大的区别在于你不是在写一条线性的执行链而是在设计一张有节点、有边、有状态流转的图。每个节点可以是一个Agent、一次工具调用、一个评估函数边则定义了它们之间的依赖和触发条件。我最初接触图工程是因为一个很具体的需求给一套UI设计稿做自动化评估。当时团队里设计师出稿速度很快但评审环节全靠人工一个页面从布局、配色、间距到交互状态至少要三个人分别看一遍遇到争议还得拉会。效率低不说标准还不统一。后来我想能不能把UI设计评估这件事拆成多个可复用的检查节点用图的方式串起来让Agent自动跑完整个评估流程这就是这个项目的起点。这套东西适合谁呢如果你正在做Agent开发尤其是多Agent编排相关的项目或者你是一个前端/设计团队的技术负责人想用AI来辅助设计评审那这篇内容应该能给你不少可直接抄作业的思路。它不要求你精通图论但需要你对Agent的基本概念有了解——知道什么是工具调用、什么是状态管理、什么是评估函数就够了。核心关键词我先摆出来图工程、Graph Engineering、UI设计评估、Agent、多Agent。这几个词贯穿全文后面每个章节都会围绕它们展开。我尽量用大白话把每个设计决策背后的“为什么”讲清楚包括我踩过的坑和最后验证有效的方案。2. 整体架构设计为什么用图而不是链2.1 从线性链到有向图的思维转变大部分Agent开发教程里最常看到的模式是链式调用用户输入→Agent思考→调用工具→返回结果。这种模式简单直接适合任务步骤固定、依赖关系单一的场景。但UI设计评估不一样它的检查项之间不是简单的先后关系而是有并行、有分支、有回退的。举个例子一个页面的评估至少包含这几个维度布局合理性、色彩对比度、字体层级、间距一致性、交互状态覆盖、响应式适配。这些维度里布局和间距可以并行检查但色彩对比度如果发现问题可能需要回退到布局节点重新确认元素位置。如果用链式结构你得写一堆if-else来判断跳转代码很快就变成意大利面条。而用图结构每个检查维度就是一个节点节点之间的边定义了“什么条件下走哪条路”逻辑一目了然。我最终选的是有向无环图DAG为主、局部允许环路的混合结构。DAG保证了大部分评估流程可以并行执行提高效率局部环路则用于处理“发现问题→修复建议→重新评估”这种迭代场景。这个选择背后的考量是UI评估不是一次性的很多问题需要反复确认完全无环会导致流程僵化。2.2 多Agent分工与图节点的映射关系在图工程里每个节点不一定都是一个独立的Agent。我的做法是把评估任务按复杂度分层简单的检查用纯函数节点复杂的检查用Agent节点。比如“检查颜色对比度是否达到WCAG AA标准”这种完全可以用一个纯函数实现输入是颜色值输出是布尔值和对比度数值不需要Agent参与。但“判断这个页面的视觉重心是否合理”这种主观性较强的评估就需要一个具备视觉理解能力的Agent来打分。具体分工是这样的布局解析Agent负责从设计稿中提取元素的位置、尺寸、层级关系输出结构化的布局树。视觉评估Agent负责色彩、字体、间距等视觉属性的检查每个属性可以是一个独立的Agent也可以合并成一个多模态Agent。交互逻辑Agent负责检查按钮状态、表单验证、加载态等交互相关的设计是否完整。汇总裁决Agent负责收集所有节点的评估结果处理冲突生成最终报告。这四类Agent在图中的位置和连接方式决定了整个评估流程的效率和准确性。我试过把所有检查塞进一个Agent里结果就是提示词巨长无比Agent经常漏掉某些检查项。拆成多个Agent后每个Agent的职责单一提示词可以写得很精准准确率明显提升。2.3 状态管理与数据流转的设计要点图工程里最容易被忽视但最关键的部分是状态管理。每个节点执行完后它的输出要能被后续节点读取同时不能污染其他分支的数据。我用的是一个共享状态池加节点局部状态的混合方案。共享状态池里放的是全局信息比如原始设计稿的引用、项目配置、最终报告模板。节点局部状态里放的是该节点产生的中间结果比如布局解析Agent输出的布局树、视觉评估Agent输出的问题列表。节点之间的边在传递数据时可以选择性地把局部状态合并到共享状态池或者只传递一个引用。这样做的好处是并行分支之间不会互相干扰同时汇总节点又能拿到所有需要的数据。我踩过的一个坑是早期把所有数据都塞进共享状态结果两个并行分支同时写入同一个字段导致数据覆盖。后来改成每个节点有独立的命名空间汇总时按命名空间读取问题就解决了。注意状态池的读写一定要有版本控制或时间戳否则在环路中容易出现旧数据覆盖新数据的情况。我一般会给每个状态字段加一个last_updated时间戳读取时只取最新的。3. UI设计评估的核心节点拆解与实操要点3.1 布局解析节点从设计稿到结构化布局树布局解析是整个评估流程的第一步也是最容易出问题的一步。输入是一张设计稿图片或者一个Figma链接输出是一棵结构化的布局树每个节点包含元素类型、位置、尺寸、层级、文本内容等属性。我试过三种方案第一种是直接用多模态大模型识别图片中的元素优点是实现快缺点是精度不稳定尤其是元素密集的页面经常把两个按钮识别成一个。第二种是用传统的计算机视觉方法做元素检测精度高但需要大量标注数据而且对不同设计风格泛化能力差。第三种是混合方案先用CV方法做粗检测再用多模态模型做细分类和属性提取。最终我选了第三种。具体操作是先用边缘检测和连通域分析找出所有可能的元素区域然后用一个轻量级的多模态模型对每个区域做分类按钮、输入框、文本、图片等最后用一个布局关系推理模型判断元素之间的包含、相邻、对齐关系。整个流程跑下来一个中等复杂度的页面大概需要3到5秒准确率能到90%以上。实操中要注意几个细节设计稿的分辨率不能太低建议至少2倍图元素之间的间距如果小于4px检测时容易合并需要调小连通域的阈值文本元素的识别要特别小心因为文本行之间可能被误判为独立元素我一般会加一个文本行合并的后处理步骤。3.2 视觉评估节点色彩、字体、间距的量化检查视觉评估节点是UI设计评估里最“硬”的部分因为大部分检查都可以量化。色彩对比度用WCAG公式计算字体大小和行高可以直接从布局树读取间距一致性可以用方差来衡量。这些检查用纯函数实现就够了不需要Agent。但有些视觉评估是主观的比如“这个页面的色彩搭配是否和谐”。这种我交给一个多模态Agent来做给它一张设计稿截图和一组参考案例让它输出一个1到10分的评分和理由。为了提高一致性我会在提示词里明确评分标准比如“如果主色和辅助色的色相角差距在30到60度之间给8分以上如果差距小于15度给5分以下”。色彩对比度的计算我补充一下具体公式因为很多人容易搞混。WCAG用的是相对亮度公式对于每个颜色通道如果值小于等于0.03928除以12.92否则先加0.055再除以1.055然后取2.4次方。三个通道分别计算后按0.2126、0.7152、0.0722的权重求和得到相对亮度L。对比度就是(L10.05)/(L20.05)其中L1是较亮颜色的亮度。AA标准要求正文对比度至少4.5:1大号文本至少3:1。间距一致性检查我用的是标准差法把同一层级所有元素的间距值收集起来计算标准差。如果标准差超过平均值的20%就认为间距不一致。这个阈值是我试了好几次才定下来的太松了漏报太紧了误报。3.3 交互逻辑节点状态覆盖与流程完整性检查交互逻辑评估是最容易被忽略但实际影响最大的部分。一个页面看起来再漂亮如果按钮没有禁用态、表单没有错误提示、加载没有骨架屏用户体验就会大打折扣。这个节点的任务是检查设计稿中是否包含了所有必要的交互状态。我的做法是维护一个交互状态清单按组件类型分类。比如按钮组件需要检查默认态、悬停态、按下态、禁用态、加载态。输入框需要检查默认态、聚焦态、填充态、错误态、禁用态。然后让Agent逐个检查设计稿中是否有对应的状态展示。这里有个实操技巧很多设计师会把多个状态画在同一个画板上但不会标注哪个是哪个。我让Agent根据视觉特征来推断比如颜色变浅通常是禁用态有旋转图标通常是加载态。推断结果会标注置信度低置信度的会提示人工确认。提示交互状态检查最好在设计规范文档的基础上做如果团队有维护组件库可以直接从组件库读取状态清单比从设计稿推断准确得多。3.4 汇总裁决节点冲突处理与报告生成汇总裁决节点的作用是把前面所有节点的输出整合成一份可读的评估报告。听起来简单但实际做起来最复杂因为不同节点可能给出矛盾的结论。比如布局解析节点认为某个元素的对齐方式没问题但视觉评估节点认为间距不一致这时候就需要裁决。我的裁决策略是优先级加投票制。每个检查项有一个预设的优先级比如“对比度不达标”的优先级高于“间距不一致”。当两个结论冲突时优先级高的胜出。如果优先级相同就看哪个结论有更具体的证据支持。比如视觉评估节点给出了具体的间距数值和标准差而布局解析节点只是定性判断那就采信视觉评估节点的结论。报告生成我用的是模板填充加自然语言润色的方式。模板定义了报告的结构总体评分、问题列表、修复建议、参考案例。每个问题包含位置、严重程度、描述、建议。自然语言润色由一个Agent完成把结构化的数据转成通顺的段落。这里要注意润色Agent不能改变原始数据的数值和结论只能调整表达方式。4. 多Agent编排的实操细节与性能优化4.1 Agent之间的通信协议设计多Agent系统里Agent之间怎么说话是个大问题。我试过三种方式第一种是直接传递自然语言文本灵活但容易产生歧义第二种是传递结构化JSON准确但需要严格定义schema第三种是混合模式关键数据用JSON解释性内容用自然语言。最终我选了混合模式。具体来说每个Agent的输出都包含两部分data字段放结构化数据message字段放自然语言说明。下游Agent读取时优先解析data字段如果data字段缺失或格式不对再尝试从message字段提取信息。这样既保证了准确性又保留了灵活性。通信协议我还加了一个trace_id用来追踪一次评估流程中所有Agent的调用链路。排查问题时通过trace_id可以把所有相关日志串起来非常方便。这个设计参考了分布式追踪的思路在Agent数量多的时候尤其有用。4.2 并发执行与资源调度策略图工程的一个核心优势是支持并发执行。在我的评估流程里布局解析完成后视觉评估和交互逻辑检查是可以并行的。但并发不是无脑开线程需要考虑资源限制和依赖关系。我用的是一个基于拓扑排序的调度器。先把图转换成拓扑序然后按层级执行同一层级的节点可以并发不同层级的必须等前一层完成。并发度我设的是4因为再高的话API调用容易触发限流而且本地机器的内存也扛不住。每个Agent节点在执行前会检查依赖是否满足满足则进入执行队列不满足则等待。资源调度上我做了两个优化一是给每个Agent设置超时时间默认30秒超时后自动重试一次再超时就标记为失败并继续执行其他节点二是给API调用加了令牌桶限流确保不会因为突发并发把配额打满。这两个优化让整个流程的稳定性提升了很多之前偶尔会因为某个Agent卡住导致整个评估流程挂起现在基本不会了。4.3 缓存机制与重复评估的优化UI设计评估有个特点同一个设计稿可能会被反复评估尤其是设计师修改后重新提交。如果每次都从头跑一遍浪费时间和资源。我加了两级缓存第一级是设计稿级别的缓存如果设计稿的哈希值没变直接返回上次的评估结果第二级是节点级别的缓存如果某个节点的输入没变直接复用上次的输出。节点级缓存的key是节点ID加输入数据的哈希。比如布局解析节点的输入是设计稿图片如果图片没变布局树就不用重新解析。视觉评估节点的输入是布局树加设计稿截图如果布局树没变但截图变了比如设计师只改了颜色那布局解析可以复用缓存视觉评估需要重新跑。这个缓存机制让重复评估的耗时从平均15秒降到了3秒左右效果非常明显。但要注意缓存的失效策略设计规范更新时所有相关节点的缓存都要清掉否则会用旧标准评估新设计。5. 常见问题与排查技巧实录5.1 Agent输出格式不稳定的排查思路多Agent系统最常见的问题就是Agent不按格式输出。你让它返回JSON它给你返回一段带解释的文字你让它只输出数值它给你加一堆修饰词。这个问题我遇到过无数次总结了几条经验。首先提示词里要明确输出格式并且给出示例。比如“请以JSON格式输出包含score和reason两个字段score是0到10的整数reason是字符串。示例{score: 8, reason: 色彩搭配和谐但对比度略低}”。示例比单纯的格式说明有效得多。其次加一个格式校验节点。如果Agent的输出不符合预期格式校验节点会尝试修复比如从文本中提取JSON片段或者用正则表达式提取数值。修复失败则触发重试重试时在提示词里加上“上次输出格式错误请严格按照JSON格式输出”。最后如果某个Agent反复格式出错考虑换模型或者降低任务复杂度。我试过用同一个提示词在不同模型上跑格式稳定性差异很大。有些模型对格式指令的遵循度就是更高这个得实测。5.2 评估结果不一致的归因与解决同一个设计稿两次评估结果不一样这个问题很让人头疼。可能的原因有几种一是Agent的随机性大模型每次生成都有随机性即使温度设为0也不能完全消除二是缓存问题某些节点的缓存没及时失效三是并发导致的数据竞争。排查时我一般按这个顺序来先看trace日志确认两次评估走的节点路径是否一致然后检查缓存命中情况看是否有节点复用了不该复用的缓存最后检查并发写入的状态字段是否有冲突。大部分情况下问题出在缓存上尤其是设计稿没变但评估标准变了的时候。解决Agent随机性的办法是对关键评估项跑三次取众数或平均值。比如色彩和谐度评分跑三次取平均比单次评分稳定得多。代价是耗时增加但对于最终报告这种需要高稳定性的输出值得。5.3 性能瓶颈的定位与优化实录性能问题我遇到过几次比较典型的。一次是布局解析节点耗时突然从3秒涨到20秒排查后发现是设计稿分辨率从2倍图变成了4倍图CV检测的计算量翻了四倍。解决办法是加一个预处理步骤把超过一定分辨率的图片先缩放到2倍图再处理。另一次是汇总裁决节点耗时过长原因是它要等待所有上游节点完成而上游节点里有一个Agent偶尔会超时重试。解决办法是给汇总节点加了一个等待超时超过60秒就先用已有结果生成报告缺失的部分标注“待补充”。这样至少能保证流程不卡死。还有一个通用优化是减少不必要的Agent调用。比如有些检查项用纯函数就能做没必要让Agent参与。我统计了一下把纯函数能做的检查从Agent里剥离出来后整体耗时降低了40%左右。5.4 常见问题速查表问题现象可能原因排查方法解决方案Agent输出格式错误提示词不明确或模型遵循度低检查提示词是否有格式示例加格式校验节点失败则重试评估结果不一致Agent随机性或缓存问题对比两次trace日志关键项多次评估取平均检查缓存失效流程卡住不结束某节点超时或死循环查看节点执行状态加超时机制环路加最大迭代次数并发写入冲突共享状态未隔离检查状态字段命名空间每个节点独立命名空间汇总时读取布局解析精度低设计稿分辨率或元素密集检查输入图片质量预处理缩放调整检测阈值API调用被限流并发度过高查看API返回状态码加令牌桶限流降低并发度提示这张表建议打印出来贴在工位上遇到问题先查表能省不少排查时间。我自己的经验是80%的问题都能在这张表里找到对应项。6. 可复制的经验总结与扩展思路这套图工程加多Agent的UI设计评估方案我从零开始搭到稳定运行大概花了三周时间。其中第一周主要在试错试了各种Agent拆分方式和通信协议第二周在调优解决格式不稳定和性能问题第三周在加缓存和做报告模板。如果现在让我重新搭一遍估计三天就能搞定因为坑都踩过了。几个我觉得最值得复制的经验第一Agent的职责一定要单一一个Agent只做一件事提示词才能写得精准第二状态管理要提前设计好不要等到出问题了再改改起来很痛苦第三缓存机制越早加越好哪怕一开始只是简单的哈希缓存也能省很多时间第四trace日志一定要有没有日志排查问题就是盲人摸象。这套方案后续还可以往几个方向扩展。一是接入CI/CD流程设计师提交设计稿后自动触发评估评估不通过就阻止合并二是把评估结果反馈给设计工具直接在Figma里标注问题位置三是积累评估数据训练一个专门针对UI设计的评估模型替代通用的多模态Agent提高准确率和速度。我个人在实际操作中的体会是图工程这套方法论不只适用于UI设计评估任何需要多步骤、多维度、有依赖关系的任务都可以用图来组织。关键是你要先把任务拆解清楚画出节点和边然后再考虑每个节点用什么实现。不要一上来就写代码先画图图想清楚了代码就是水到渠成的事。