工程图解析比较容易出现一种问题：模型能够识别大部分内容，报告也写得很完整，但是其中少量字符、符号或连接关系存在错误。对于普通图片来说，少量误差可能没有太大影响；对于工程图来说，一个字母识别错误、一条线接错位置，都可能使后续校核结果完全失效。

因此本文不讨论具体项目，也不会展示原始工程图，只整理这次实践中比较通用的方法和问题，包括图纸预处理、局部识别、拓扑恢复、设计资料比对、独立复核以及人工签发。

为什么不能直接把整张工程图交给模型

刚开始做工程图解析时，最简单的方法就是把整页图纸交给多模态模型，让模型直接识别设备、仪表和管线。这种方法用于演示问题不大，用于工程校核则不合适。

A1 图纸缩小以后，小字和细线会明显损失；如果只截取局部，小字虽然清楚了，但是管线可能从图片外部进入，模型无法判断完整的连接关系。一个符号单独看可能是普通阀门，结合两侧管线、执行机构和信号线以后，才可以判断它属于哪一类组件。

两条线相交也不一定表示连接，有可能是跨越，也可能是一条信号线经过工艺管线。仅根据局部图形进行判断，很容易得到看起来合理、实际上错误的结果。

图例页、流程页和组合结构页的读取方式也不同。图例页负责定义符号，流程页主要表达设备和管线关系，组合结构页可能包含多个高度相似的重复单元。对于工程师来说，这些区别比较直观；对于 Agent 来说，必须把识别任务明确拆开。

我们最终将整个过程分成以下几步：

冻结源图与版本
      ↓
建立整页像素基线
      ↓
切出局部视野和组件上下文
      ↓
形成带坐标的文字、符号与参数候选
      ↓
从组件端口逐段恢复连接和跨页关系
      ↓
冻结需要对照的设计资料
      ↓
按规则逐项校核
      ↓
独立复核，最后由工程师签发

原始图纸经过局部切分、结构化提取和拓扑整理后，再进入独立复核和人工确认。

每一层都需要保留来源。某个结论来自哪一版 PDF、哪一页、哪个区域，使用了哪张局部图，原始文字是什么，为什么仍然需要复核，都应该可以重新打开查看。只有做到这一点，工程师才有办法验证 Agent 给出的结果。

预处理尽量使用确定性程序

模型适合处理符号语义、文字歧义和上下文关系，但是渲染图纸、计算哈希、记录页序、转换坐标、裁剪图片和校验字段等工作，没有必要交给模型自由发挥。这些步骤我们尽量使用确定性程序完成。

原始文件进入系统后，先登记版本和文件指纹，再按页建立统一的像素坐标。整页图保留下来，同时生成带重叠区域的局部切片。后面的 Agent 不直接拿一张被压得很小的全图硬猜，而是同时看到整页概览和自己负责的局部视野。

这一步看起来只是普通的图片预处理，实际测试中却发现了不少问题。例如有一页图纸的方向与其他页面不同。如果按照全册统一方向处理，系统仍然可以生成局部图，文件数量和尺寸看起来也正常，但是局部图的内容已经错了。后来我们将方向、页码、尺寸、父级图和文件哈希一起加入校验门禁，其中任何一个字段不符合要求，流程都会停止。

另一次测试中，某个组件裁剪文件真实存在，也不是空白图，但是裁剪区域没有覆盖任务需要识别的对象。如果只检查“文件存在”和“像素不为空”，这张图就会被当成有效证据。现在组件 Agent 在继续识别前，必须先确认裁剪图是否真正包含目标对象。

这种情况下，流程提前停止并不是坏事。工程系统最怕的不是报错，而是输入已经错误，后面的步骤仍然全部显示成功。

多 Agent 具体如何分工

完整流程中有一个统筹 Agent，负责登记输入、安排依赖、检查执行回执，并决定下一个任务能否开始。它不直接承担全部图纸识别工作。

具体的图纸任务由不同 Agent 分工处理。页面 Agent 负责识别图例区、标题栏、流程区和注释区；组件 Agent 负责定位对象，但不会在缺少上下文时直接确定类型；文字 Agent 负责读取小字，同时保留原始字符串和容易混淆的字符；拓扑 Agent 从设备端口开始逐段追踪连接，将交叉、连接、跨页出口和开放端点分别记录。

设计校核又是另一组任务。它不参与前面的识别，只读取已经资格化的图纸事实和冻结后的设计资料，去检查标签、数量、参数、连接、控制关系和重复单元是否一致。

最后还有一个独立复核 Agent。需要特别注意的是，复核 Agent 不读取前面 Agent 的自由文本推理，只根据原始图像、结构化事实、校核规则和证据位置重新判断。如果复核 Agent 先看了前面的推理过程，很容易顺着已有结论继续分析，独立复核也就失去了意义。

页面登记、组件定位、文字识别和拓扑恢复分别执行，校核结果再由独立 Agent 复查。

这种分工主要解决了三个问题：

1. 每个 Agent 只处理与当前任务相关的上下文，读取小字时不需要同时维护整套拓扑，追踪管线时也不需要同时判断全部设计规范；
2. 识别和复核由不同 Agent 完成，避免执行者直接给自己的结果判定通过；
3. 上游证据不完整时，下游任务不会获得一份假装完整的输入，统筹 Agent 也不能跳过门禁将“待复核”改为“已确认”。

多 Agent 并不是越多越好。对于单页、结构简单的图纸，一个 Agent 能够稳定完成，就没有必要继续拆分。只有任务存在明显的视野冲突、专业分工或独立复核要求时，多 Agent 才有实际价值。

工程图解析不能停留在目标框

目前不少工程图 AI 演示的主要结果，是在图上绘制识别框，然后统计设备、阀门和仪表数量。这类结果可以用于目标检测，但是距离设计校核还有较大差距。

一个组件不是一只框。它至少需要紧贴对象的局部图、能够解释连接关系的上下文图、在原页上的坐标、可能的端口、标签和当前状态。复合组件还要能拆开：执行机构、阀体、仪表气源、信号连接各自是什么，它们合起来又表达什么。

在这次实践中，我们将图面对象分成多个层级。最底层是线、圆、文字和箭头等图元；再往上是单个符号；多个符号和连接组成复合组件；多个复合组件继续组合，才形成工程人员能够直接理解的工艺单元。

完成分层以后，系统不需要每次都从像素重新判断。Agent 可以先从当前图册的图例和已经确认的组件中检索相似样例，再结合当前上下文进行判断。OCR 或 PDF 文本层可以作为辅助证据，但是不能单独决定最终结果。尤其是字形接近、文字已经转为轮廓，或者字符被管线穿过时，仍然需要保留原图局部和上下文供工程师复查。

拓扑恢复同样不能一次完成。拓扑 Agent 从已经确认的端口出发逐段追踪，遇到交叉点、阀门、页边连接符或无法确认的区域就保存检查点。能够连续追踪的部分形成连接关系，无法闭合的部分进入复核队列。

无法确认连接位置时，结果不会被直接删除或根据常识补齐，而是生成下一步任务，说明需要补充哪张局部图，以及应该在哪个页面继续寻找接续关系。

差异为零，不代表图纸没有问题

有一次测试中，图纸侧的预处理、局部解析和结构化事实已经完成，校核结果中没有出现明确差异。如果只看统计数字，很容易得出“图纸与设计资料一致”的结论。

但当时用于对照的设计资料还没有完成版本冻结，系统实际上不具备正式比较的条件。因此这里的差异数量为零，只表示没有完成有效比较，并不能说明图纸与设计资料一致。

校核 Agent 最终将结果标记为输入不足，独立复核没有放行，签发门禁也保持关闭。系统没有自动生成一致性结论，也没有创建工程师签名。

设计资料缺少必要版本和范围信息时，差异数量为零也不能通过校核门禁。

从这次测试开始，我们将原始观察、规范化事实、比较结果和正式签发完全分开。图纸中读取到的内容属于原始观察；将不同写法转换为可比较字段属于规范化；某条规则得到一致、冲突、待复核或证据不足属于比较结果；能否进入正式报告，还要检查版本、适用范围、证据和人工授权是否齐全。

每一条校核发现都需要说明设计资料和图纸分别记录了什么、证据在哪里、当前处于哪一种状态，以及还缺少什么信息。工程师打开校核项以后，应当能够先看到原页和局部图，而不是只看到一段模型生成的解释。

可培养 Agent 的实际作用

工程图纸往往有很强的项目习惯和企业习惯。相同符号在不同图册里可能有细微变化；同一个字符组合，在某个专业里有固定含义；哪些参数必须原样保留，哪些开放端点属于正常跨页，哪些审查项需要立即升级给工程师，这些都不是通用模型天然知道的。

如果每更换一套图纸，都需要重新解释图例、编号习惯和跨页规则，那么这套系统很难形成长期价值。

在 DesireCore 中，已经确认的图例、组件样例、端口模式、易混淆字符、裁剪方法和校核规则可以保存在 AgentFS 中。工程师完成一次纠正后，系统记录的不只是当前答案，还包括错误原因，以及以后遇到什么条件时需要触发复核。

比如一位工程师确认：“这种画法不是两只独立阀门，而是一个组合对象。”这条纠正可以进入组件库和 Agent 的 Skill。下一次再遇到相似画法，定位 Agent 会先召回这个样例；如果上下文不同，它仍然可以把结果留在候选状态，不会因为见过一次就到处套用。

再比如某类标签经常混淆字母和数字，系统可以记录对应的处理方法：追加更紧的文字裁剪，同时保留周边上下文，并将两个候选字符一起提交复核，而不是自动修改为更像正确答案的字符。

这些经验以文件形式保存，可以进行审阅、Diff、回滚和迁移。即使后续更换模型，企业在项目中积累的处理方法仍然可以继续使用。我认为这也是 DesireCore 用于专业场景时比较重要的区别：模型负责提供基础能力，企业负责培养自己的 Agent。

需要注意的是，可培养 Agent 并不表示使用次数越多，系统就越倾向于自行判断。很多有价值的经验其实是限制条件，例如遇到什么情况必须停止、哪一种证据不能单独使用、哪些结论只能由工程师批准。

如何判断工程图解析效果

仅统计“识别了多少个对象”没有太大意义。对象框数量多，不代表组件语义正确；所有组件都有坐标，也不代表全图拓扑已经闭合；生成了一份报告，更不代表设计校核已经完成。

我们目前更关注以下指标：

• 每条事实能不能回到原始页面和局部证据；
• 错位、空白和过度裁剪能否在进入语义分析前被拦住；
• 不确定字符有没有原样保留，而不是被自动润色；
• 跨页连接和开放端点有没有明确的处置状态；
• 设计资料更换版本以后，旧结论会不会自动失效；
• 执行 Agent 和复核 Agent 是否真的使用独立上下文；
• 输入不足时，系统能不能拒绝给出“一致”；
• 最终结论是否仍由有资质、有授权的人确认。

测试过程中还可以故意移除一份必要输入，或者加入一张错位的局部图，检查系统是否会停止。只在正常样本上运行成功，不能说明系统具备工程可用性。

如果系统能够说明停止原因、停止位置和需要补充的证据，后续才有可能进入真实工程流程。

多 Agent 工程图校核的应用边界

经过多轮验证，这套方案适合处理大量重复且容易遗漏的工作，例如整理图册、建立证据索引、提取标签和参数、寻找重复单元、追踪局部连接、将设计资料逐项对齐，并优先列出需要工程师检查的问题。

确定性较强的差异，比如版本、编号、数量和明确参数，可以更早暴露。涉及工艺合理性、异常工况、安全充分性和可维护性的判断，Agent 可以提供证据和审查建议，但最后仍需要对应专业的工程师复核。

专业签发涉及资质、职责和现场条件，不能由模型自动生成。DesireCore 在这类场景中的作用，是减少工程师在大量图纸和设计资料之间重复查找的时间，并将识别结果、证据和问题整理清楚。Agent 负责解析和预审，最终设计意图、问题定性及修改意见仍然由对应专业人员确认。

总的来说，多 Agent 工程图解析的重点不在于一次识别出多少内容，而在于结果是否可以定位、复查和纠正。第一套图纸用于建立流程，后续图纸则可以继续复用已经确认的图例、组件、规则和失败经验。只有将这些经验保留下来，工程图解析系统才会随着实际使用逐步完善。

相关阅读