杨周旺教授团队新书连载｜第五章 系统集成与工业验证

LuBan三层架构集成协议的核心任务，是明确三层之间的接口边界、数据对象、控制流程和状态反馈关系，并说明Agent层如何在调用工具执行后引入验证复核和人工协作从而形成闭环控制，使三层能力从概念框架转化为可运行、可追踪、可复核、可回退的系统机制。

5.1.1 层间接口边界

在LuBan三层架构中，将数据层记为D，工具层记为T，Agent层记为A。同时，在Agent层内部设置两类内置机制：验证机制记为 Av，人工协同机制记为 Ah。系统定义三类基础交互通道：

I = { IAD, IAT, ITD } 

分别表示Agent层与数据层之间的状态读写、Agent层与工具层之间的动作调用、工具层与数据层之间的结果回写。每一类接口主要说明三项内容：哪些主体之间发生交互，交互过程中传递什么类型的对象，该交互关系承担什么边界责任。表5.1概括了LuBan 三层架构中的主要接口。

表 5.1：LuBan 三层架构的层间交互通道

由此，LuBan三层架构在系统层面形成三类基本交互关系：A通过 IAD 读取和更新状态，通过 IAT 调用工具；T通过 ITD 回写执行过程；Av 通过Agent层的状态通道读取数据层中的过程记录、模型状态和约束信息，并将验证结果作为Agent 决策证据写回数据层；Ah 通过Agent层的人机协同入口接收人工确认、修正意见和约束补充，并由 Agent 将其转化为新的任务约束、控制状态或回退指令。

这些接口共同限定了系统中“谁可以调用谁、调用什么、结果写到哪里、责任如何保留”，形成可运行、可记录、可复核的协议结构。

5.1.2 任务流转与协议闭环

集成协议需说明设计任务、状态信息、工具反馈和验证结果如何在三层之间流动。在LuBan架构中，一次任务执行并非由Agent直接生成最终结果，而是在任务接收、状态读取、动作规划、工具执行、结果回写、验证判断和控制决策之间形成闭环。

设计任务包含用户意图或设计目标、约束集合、参考对象以及边界条件，其中边界条件涵盖禁止操作、人工确认条件、安全限制和任务终止规则等。

执行时，系统在一轮闭环中的主要对象关系可表示为：从数据层记录出发，依次经过Agent读取状态视图、生成动作、工具返回执行反馈、验证生成结果、形成控制状态，最终更新为下一轮数据层记录。基于这一对象关系，协议闭环可概括为七个步骤。

◾ P1任务接收：用户通过Agent层的人工协同机制 Ah 提交设计任务，任务被转化为可记录的任务对象 τ ，为后续环节提供统一基准。

◾ P2状态读取：Agent层通过 IAD 从数据层读取当前状态、历史轨迹和已有过程记录，形成当前步的状态视图 sk，作为任务规划的依据。

◾ P3任务规划：Agent层根据状态视图 sk 和设计对象 τ 生成下一步动作 αk ，动作可以是建模、编辑、检查、参数调整、回退，也可以是请求人工确认。

◾ P4工具调用：Agent层通过 IAT 将动作提交给工具层，工具层执行相应操作并返回执行反馈ek，内容包括执行结果、异常信息、几何更新或失败原因。

◾ P5结果回写：工具层完成执行后，通过 ITD  将执行结果、异常信息和模型状态写回数据层，保证工具层不仅返回结果，也留下可查询、可验证、可回退的过程记录。

◾ P6验证判断：Agent层内部的验证机制 Av 基于数据层中的过程记录、模型状态、工具反馈和约束信息生成验证结果vk，用于判断当前输出是否满足约束、是否存在模型错误、是否超出边界条件，以及是否需要人工判断。

◾ P7控制决策：Agent层根据工具反馈ek、验证结果 vk 和边界条件形成控制状态，决定系统下一步是继续执行、重试、回退、终止，还是通过人工协同机制请求人工复核。人工确认、修正意见或约束补充被Agent接收后，通过 IAD 写入数据层，成为下一轮决策的依据。

上述过程中的主要对象关系可以概括为：

经过上述步骤，本轮的动作、反馈、验证结果和控制状态被追加到数据层记录中。通过P1至P7，数据流负责记录任务、动作、反馈、验证结果和控制状态的传递与沉淀，控制流负责组织各步骤的执行顺序。二者共同保证系统在可记录、可验证、可回退、可人工接管的协议过程中持续推进。

上一节给出了LuBan三层架构的集成协议，说明了数据层、工具层与Agent层如何通过状态读写、工具调用和结果回写形成闭环。本节进一步讨论该协议在LuBan原型系统中的实现方式，即聚焦三个问题：如何划分模块以落实接口边界？如何选择关键技术以支撑三层能力？如何通过集成与部署保证系统在迭代过程中维持可用、可测和可回退？

5.2.1 系统架构与模块划分

LuBan原型系统按照5.1节中的D、T、A三类主体进行模块化实现，总体上由交互层、Agent服务层、工具执行层、数据服务层和运维部署层组成，其逻辑结构如图5.1所示。

图 5.1：LuBan三层架构逻辑结构示意图

从功能角度看，各层对应关系清晰。Agent服务层对应A，是系统调度核心，负责接收用户任务、转化为规划动作，并根据工具反馈、数据层记录及内部验证机制的复核结果决定下一步控制状态。同时内置人工协同机制，在关键节点触发人工确认、展示中间结果并接收修正意见。工具执行层对应T，负责调用几何建模、参数编辑、模型检查和脚本执行等能力，将执行结果、异常信息和模型状态回写至数据层。数据服务层对应D，负责保存设计状态、任务轨迹、过程记录、模型文件、验证结果、人工复核意见和检索索引。验证复核作为Agent服务层的内置能力，对工具结果和模型状态进行约束检查与异常复核。运维部署层则保证系统的测试、发布、监控、日志管理和版本回退等支撑能力。

模块划分与5.1节中的接口协议一致对应，各模块不直接访问彼此内部状态，而是通过稳定服务边界交互。Agent服务层不能直接修改模型文件，必须通过工具执行层提交动作请求。工具执行层不能仅将结果返回给Agent，还需将执行日志和模型状态写回数据服务层。验证服务也不依赖Agent的主观判断，而是从数据服务层读取过程记录并生成验证结果。由此，协议中定义的各类交互通道在工程实现中分别对应状态访问、工具调用、结果回写、验证读取和人工干预等模块边界。

5.2.2 关键技术选型

原型系统的技术选型应服务于LuBan三层架构的核心目标：数据层需支持多类型设计对象和过程记录；工具层需支持稳定的几何操作和模型检查；Agent层需支持任务理解、规划生成和工具调度。选型不应仅追求单点性能，而应优先考虑可集成性、可替换性、可观测性和工程可维护性。表5.2概括了LuBan原型系统的关键技术选型，主要包含大模型、向量数据库、几何内核、前后端框架、消息队列或任务队列、对象存储或文件管理服务等方面内容。

大模型用于支撑Agent层的任务理解与规划决策，承担自然语言解析、设计目标分解、动作序列生成、工具调用参数组织和异常解释等工作。部署方案可灵活选择：云端调用通用大模型适合快速验证，企业私有化部署开源模型适合数据安全要求较高的场景，混合路由方案则让复杂任务由强推理模型处理、常规任务由轻量模型承担。无论采用哪种方案，系统均应保留模型版本、提示模板、检索上下文和工具调用参数，以便复现和回归测试。

向量数据库用于支撑数据层的语义检索能力。工业设计任务涉及历史案例、设计规范、工艺知识和过往任务轨迹，仅靠关系型数据库难以完成跨模态的相似性检索。原型系统可在数据层中设置向量数据库，保存设计文档、历史任务片段、工具调用记录和案例摘要的向量索引，Agent层规划前可通过检索获取相关案例和约束依据，验证服务也可利用检索结果辅助解释异常原因。

图 5.2：向量数据库实现对数据层的检索

几何内核用于支撑工具层的建模、编辑和检查能力。工业设计智能体的输出最终需落到几何模型和制造约束上，工具层可采用两种方式实现：一是直接调用几何内核封装建模接口，二是调用已有CAD软件的二次开发接口驱动CAD平台。

前后端框架用于支撑用户交互、任务管理和服务编排。前端需展示任务输入、模型预览、过程轨迹、验证结果和人工确认界面。后端需承载Agent服务、工具调用服务、数据访问服务和权限管理服务。前端重点在于交互清晰和状态可视化，后端重点在于服务边界清楚、接口稳定、日志完整和便于扩展。

消息队列或任务队列用于协调 Agent 层与工具层之间的异步任务执行。CAD 建模、STEP 文件解析、工程图重建、批量模型检查和装配干涉检查等任务通常执行时间较长，如果采用同步调用，容易阻塞 Agent 服务和前端交互。为此，Agent 层可以将工具请求封装为带有任务标识、输入模型版本、执行参数和超时条件的任务，提交到消息队列或任务队列，再由独立的工具执行节点依次处理。任务执行期间，系统持续记录等待、运行、成功、失败、超时和取消等状态，并将结果或异常写回数据层。对于网络中断、服务暂时不可用等可恢复异常，队列可以支持受控重试。对于修改 CAD 模型的操作，则需要结合任务标识和模型版本避免重复执行造成重复特征或状态冲突。任务队列通过提交端、消息代理和执行节点之间的解耦，也便于后续扩展工具执行能力和计算资源。

对象存储或文件管理服务用于保存工业设计智能体运行过程中产生的非结构化文件，包括 CAD 原生文件、STEP 文件、HistCAD 文件、模型预览图、验证报告和归档日志等。与任务状态、参数信息等结构化数据相比，这类文件通常体量较大，也具有明显的版本属性，因此不宜全部直接存入关系型数据库。较合理的方式是由对象存储或文件管理服务保存文件内容，由数据层记录任务编号、文件位置、模型版本、生成时间、工具版本、校验信息和访问权限等元数据，使文件能够与具体任务及过程状态建立关联。

表 5.2：LuBan 原型系统的关键技术选型

实际工程中，可以根据部署环境、已有 CAD 系统和数据安全要求选择具体实现方案。只要这些关键技术能够支撑 5.1节中定义的状态读写、工具调用、结果回写、验证复核和人工干预，便可以纳入 LuBan 原型系统的实现框架。

5.2.3 部署与CI/CD策略

LuBan原型系统包含数据服务、工具执行服务、Agent 服务、前端交互和模型文件管理等多个协同模块，为保证在持续迭代中维持稳定，在部署时需引入基本的CI/CD策略，将代码更新、自动测试、环境部署和版本回退纳入统一流程。

CI/CD基本流程可概括为：代码提交后先进行自动测试，通过后构建部署版本，发布至测试或演示环境，最后通过日志和运行指标监控系统状态。若新版本导致接口异常、工具调用失败或历史任务结果明显退化，系统应能回退至上一稳定版本。

如表5.3所示，CI/CD测试策略分为三类：单元测试检查各模块内部功能，如状态读写、参数解析、工具函数和约束检查；集成测试检查层间接口是否能够支撑完整任务流转，即任务能否从提交、规划、工具执行、结果回写到验证判断顺利完成；回归测试比较新旧版本在典型任务上的执行结果，防止模型版本、工具脚本或验证规则更新后破坏已有能力。

表 5.3：LuBan 原型系统的 CI/CD 测试策略

通过上述部署与CI/CD策略，LuBan原型系统可从“能够演示”走向“能够持续运行和迭代”。其核心目的是保证每次系统更新都可测试、可追踪、可回退，从而支撑后续工业场景的验证。

本章5.1节和5.2节分别从集成协议和原型实现角度说明了LuBan三层架构如何形成可运行工业设计系统。本节进一步讨论系统如何进入工业场景验证，其目的是检验系统在真实或近真实设计任务中，是否能够稳定完成从任务接收、状态读取、工具调用、结果回写、验证判断到人工复核的完整闭环。工业验证需回答三个核心问题：系统能否完成任务，完成过程是否可追踪，失败和异常是否能够被记录并进入复核流程。

本节将工业验证任务划分为五类：建模序列检索、自然语言驱动零件生成与编辑、工程图重建、STEP 模型重建建模序列、多 STEP 组装装配体。这五类任务分别覆盖从知识检索、文本驱动建模、二维到三维重建、无特征模型重建到多零件装配等典型工业设计场景的智能体能力。

5.3.1 建模序列检索智能体

建模序列检索智能体用于从历史设计任务、HistCAD 数据集、参数化模板库和工具调用记录中查找可迁移到当前任务的建模过程，是知识检索智能体在建模复用场景中的具体实现。

输入与目标：输入可以是自然语言零件描述、局部特征要求、草图、参考 STEP 模型或当前 CAD 状态或已有设计约束；目标是召回具有参考价值的 HistCAD 建模序列，并给出特征对应关系、参数映射方法和预计修改范围。

工作流程：意图理解角色将查询转化为设计语义，知识检索角色通过状态读写通道读取数据层中的序列、模板和案例。候选结果不仅考虑语义和外形相似性，还需判断特征类型与拓扑关系是否相容、参数能否重新绑定。检索结果经规划角色适配后，通过工具调用通道提交试执行，验证机制再根据几何有效性和修改成本重新排序。

失败处理与验收：序列复用受到模型版本、工具能力和适用范围的限制。失败时反思角色应判断问题来源，选择重新构造查询、替换候选或请求确认。验收时需检查是否存在至少一个序列可经有限修改后生成有效模型，且复用成本低于重新建模。

5.3.2 自然语言生成与编辑智能体

该智能体将工程师的文本需求转化为可执行的 CAD 建模或修改过程，是意图理解、任务规划、工具调用和反馈修复能力在自然语言建模场景中的综合实现。

输入与目标：输入为自然语言任务描述，其中包含用户的设计意图、几何约束和参考对象等，可从空白生成零件，也可对已有模型进行局部编辑。目标是将文本中的设计对象、尺寸参数和特征关系转化为可执行建模序列。

工作流程：意图理解角色识别零件主体、局部特征和尺寸关系，规划角色将任务分解为草图创建、拉伸、切除等原子操作，行动角色调用工具层执行，验证机制检查几何有效性和尺寸一致性，不满足时由反思角色调整参数或重新规划。

失败处理与验收：自然语言任务可能存在尺寸缺失、方位不清或约束冲突，当歧义影响建模路径或关键尺寸时应请求人工确认。验收时检查自然语言意图是否满足、模型是否可编辑、关键尺寸和约束是否一致。

5.3.3 工程图重建智能体

该智能体从二维工程图中恢复三维零件结构和参数化建模过程，主要验证多模态感知、空间关系推理、任务规划和闭环反思能力。

输入与目标：输入包括多视图、剖视图、尺寸标注和技术说明。目标是解析视图中的几何轮廓和语义标注，推断三维结构，生成可编辑的 CAD 模型及建模序列。

工作流程：感知角色识别视图范围和标注，建立视图间对应关系；规划角色依据正交投影规则推断三维特征，形成候选特征树；行动角色调用建模工具完成重建；验证机制将重建模型重新投影，与原图比对轮廓和关键尺寸。

失败处理与验收：典型失败包括视图识别错误、尺寸冲突或信息不足导致多解。当图纸信息不足以确定唯一结果时，应保留候选方案并请求工程师选择。验收时检查模型拓扑完整性、主要特征恢复情况和关键尺寸一致性。

5.3.4 STEP 模型重建智能体

该智能体从缺少显式建模历史的 STEP 模型中恢复设计特征和参数化建模序列，是几何感知、知识检索、任务规划和反馈修复能力在逆向建模场景中的具体实现。

输入与目标：输入为 STEP 模型，目标是识别拉伸、旋转、切除、孔、倒角等建模特征，推断特征依赖关系，生成可重新执行的HistCAD序列。

工作流程：感知角色解析STEP文件，构建面—边邻接图；知识检索角色匹配局部拓扑模式，识别特征节点并迭代收缩；规划角色推断建模顺序，行动角色执行序列并由验证机制完成几何和特征验证。

失败处理与验收：同一 STEP 几何结果可能对应多种建模顺序，因此重建过程具有非唯一性。典型失败包括特征依赖顺序不合理、子图收缩存在问题，部分长尾规则未纳入特征子图知识库等。发生上述问题时，反思角色应调整替换候选特征、重新规划建模顺序、修正子图收缩规则或根据现有面-边邻接图提出新的特征。

5.3.5 多 STEP 装配智能体

该智能体面向多个独立 STEP 零件，结合装配参考图识别零件间的连接关系，规划装配顺序，并通过生成装配约束完成零件装配，综合验证多对象感知、关系规划和反馈修复能力。

输入与目标：输入包括多个 STEP 零件及装配参考图。目标是识别轴孔配合、平面贴合等关系，求解零件空间位姿，生成装配约束图和完整装配体。

工作流程：感知角色提取各零件工程特征并识别候选装配关系；规划角色构建关系图并生成装配顺序，将贴合、共线等抽象为基础接触原语再组合为装配模式；行动角色求解位姿并设置装配约束。

失败处理与验收：典型失败包括候选接触面错误、装配顺序不可行或几何干涉。失败时反思角色应定位具体关系并尝试更换候选或调整顺序，多方案时请求人工确认。验收时检查装配关系识别正确性、约束合理性及干涉检查结果。

5.3.6 端到端性能指标

工业场景验证应采用端到端指标，而不是只评价某一模型或某一工具函数。端到端指标分为三个层次：任务结果指标判断最终结果是否满足任务要求；过程可靠性指标检查设计语义、任务树和工具调用是否正确；闭环恢复指标评价系统能否识别失败、完成修复并在适当节点请求人工确认。表5.4概括了五类任务的端到端性能指标。

表 5.4：五类任务的端到端性能指标

除了上述端到端性能指标，五类任务还可统一记录任务完成率、工具执行成功率、验证通过率、平均执行时间、回退次数、人工介入次数和证据完整率。

5.3.7 验证证据与复核闭环

工业验证不能只保留成功结果。对于工业设计智能体而言，成功结果、失败样例、异常日志、修复轨迹、人工复核意见和边界条件记录共同构成验证证据。只有完整保存这些证据，才能说明系统在什么条件下有效、为什么失败、是否进行了合理修复，以及人工判断如何影响最终结果。表5.5概括了工业验证的各阶段证据。

表 5.5：工业验证证据

验证证据应统一沉淀到数据层：Agent层通过状态读写通道 IAD 读取和更新任务状态，工具层通过 ITD 将执行结果和异常信息写回，验证机制通过 Av 记录验证结论与修复建议，人工协同机制通过 Ah 记录人工介入原因和最终意见。每次任务执行都应关联输入版本、模型版本、工具版本、知识库版本以及 Agent 配置，以支持复现和追踪。失败路径同样应写入验证日志和案例库，作为后续规则修正和回归测试的依据。特别是对于多解、冲突或涉及安全边界的任务，人工复核本身就是可信闭环的一部分，也应记录并沉淀到数据层。

由此，五类工业场景验证形成了“任务定义—工具执行—结果验证—反馈修复—人工复核—证据沉淀”的完整统一闭环，共同验证了LuBan三层架构在工业设计场景中的闭环协同能力。

本章5.1~5.3节分别讨论了LuBan三层架构的集成协议、原型系统实现与工业场景验证，解决了系统内部如何协同、能力如何落地、结果如何被检验的问题。但对于工业设计智能体而言，仅有单个系统或单次验证仍然不够。工业设计智能体要进入更大范围的工程实践，还需形成可共享的表示标准、可复用的转换工具、可持续演进的社区机制，以及清晰的商业模式和知识产权策略。

在LuBan架构中，HistCAD承担着连接设计过程、建模历史、工具调用和模型结果的关键作用。它不仅是一种内部数据表示方式，更可进一步发展为面向工业设计智能体的建模过程表示新标准。围绕HistCAD建立标准、工具和生态，能够降低不同CAD系统、Agent系统和工业场景之间的协同成本，使工业设计智能体从单点原型走向可推广的（工业世界模型）工程基础设施。

5.4.1 HistCAD 推广路径

第二章已将HistCAD定义为面向参数化CAD建模过程的AI原生表示协议，以建模序列为主线记录草图平面、基元、约束、参数、特征操作、布尔语义和历史顺序，使CAD模型成为可读取、回放、编辑和验证的过程表示数据。在此基础上，本节讨论这种建模过程表示如何从内部数据协议发展为面向工业设计智能体的标准体系。如表5.6所示，HistCAD表示标准的推广路径可分为三个阶段。

表 5.6：HistCAD表示标准的推广路径

内部规范阶段，重点是支撑LuBan系统内部的闭环运行，建模序列检索、自然语言意图建模、工程图重建、STEP重建和多STEP装配等任务均可作为规范稳定性的试验场，只有能够在这些任务中被解析、执行、验证和回写的字段，才适合进入稳定规范。

团体标准阶段，重点是从原型系统中提炼具有通用性的内容，围绕术语体系、对象模型、接口规范、兼容性测试和示例数据形成跨团队共识，使不同CAD平台、几何内核和智能体框架能够围绕同一HistCAD过程表达进行解析、转换和验证。

行业标准阶段，重点解决规模化应用中的互操作和治理问题，说明HistCAD与STEP、原生CAD、工程图、PLM/PDM系统和企业知识库之间的关系，给出版本兼容、数据安全、验证报告和长期归档等规则，使不同企业和工具链能够围绕同一过程表达协同工作。

因此，HistCAD表示标准的推广应遵循“先验证、后固化”的原则：第二章定义了建模过程表示基础，本章5.3节通过五类工业任务检验其可执行性、可编辑性和可验证性，本节则进一步将这些稳定经验沉淀为标准、工具和生态。

5.4.2 开源工具与社区建设

标准能否被推广，不仅取决于文本规范是否完整，也取决于是否存在可使用的工具链。若只有格式定义而缺少转换器、校验器、示例库和开发接口，开发者和企业将难以真正接入。因此，生态推广需围绕HistCAD建设开源转换工具和社区协作机制，如图5.3所示。

图 5.3：开源转换工具与社区建设协作机制

开源工具的基本任务是降低跨系统接入成本，可建设三类基础工具：HistCAD解析器与校验器，用于读取HistCAD文件，检查字段完整性并判断建模序列是否满足执行条件；CAD转换适配器，用于将HistCAD操作映射到不同CAD软件、几何内核或脚本接口，使同一建模过程表示能够在不同工具后端执行；兼容性测试与可视化调试工具，用于提供典型零件、装配体、失败样例和执行结果展示，帮助开发者检查解析、执行和验证差异。

开源社区的建设应与工具链同步推进。社区不仅是代码仓库，更应承担标准讨论、案例共享、问题反馈和版本治理的职责，可采用“核心规范开放、适配器逐步扩展、测试集持续补充”的组织方式。核心规范保持开放稳定，避免频繁破坏兼容性；适配器允许不同团队针对不同 CAD 系统、几何内核和工业场景进行扩展；测试集则随着任务类型和行业案例不断增长。

在社区治理方面，版本兼容问题需特别关注。HistCAD一旦进入真实工业场景，旧版本文件、旧适配器和旧任务轨迹仍具有复现价值，因此标准和工具链应保留版本号、兼容策略和迁移工具，破坏性变更应通过明确的版本升级机制处理，以保证工业设计过程的长期可追溯性。

5.4.3 商业模式与知识产权策略

生态推广还需回答一个现实问题：HistCAD表示标准和LuBan系统（统称：Luban生态）如何在开放协作与商业应用之间保持平衡。工业设计领域涉及企业模型、产品结构和工艺经验等高商业价值内容，缺少清晰的商业模式和知识产权策略，标准推广、工具开源和企业应用之间容易产生冲突。

从商业模式看，LuBan生态可采用“开放标准+工具服务+企业部署”的路径。开放标准用于降低生态接入门槛，使更多研究团队、开发者和企业能够围绕HistCAD形成共识；基础工具可采用开源方式提供，包括解析器、校验器、示例数据和部分转换器；面向企业的高级能力则通过商业化服务提供，如专用CAD工具集及其适配器、私有化部署、行业知识库构建、定制化Agent工作流、工程验证服务和系统集成支持。这种模式的优势在于，数据层（表示标准）保持开放避免生态被单一实现锁定，工具层提供基础能力降低进入门槛，Agent层围绕企业实际需求提供可靠部署和技术支持。商业模式的构建不应仅围绕算法模型等工具调用收费，而应围绕设计过程数智化、历史知识复用、自动建模能力、验证闭环能力和企业系统集成能力展开，从而能够为工业企业“产品全生命周期”提供比较平滑的整体解决方案。表5.7简略概括了LuBan生态的可能商业模式。

表 5.7：LuBan 生态的可能商业模式

知识产权策略需要同时覆盖标准、代码、数据和生成结果。HistCAD表示标准文本可作为开放规范存在，基础开源工具根据许可证管理，企业CAD模型文件、工程图和设计规范等数据资产原则上归数据提供方所有。系统基于企业数据生成的HistCAD记录、建模序列和重建模型，应在项目合同或平台协议中明确归属。对于由通用工具自动生成但依赖企业专有数据完成的结果，需重点区分工具提供方的算法权益和企业数据方的结果权益。

此外，LuBan系统应保留知识来源和过程记录。工业设计智能体的输出可能来自历史案例检索、规则库、模型推理、工具执行和人工复核的共同作用，缺少过程记录便难以判断结果来源和处理后续权属问题。因此，系统应将输入来源、检索片段、工具调用、验证结论、人工意见和版本信息写入数据层，形成可追踪的生成证据链，这与5.1节的过程记录、5.2节的版本管理和5.3节的验证证据保持一致。

通过标准推广、开源工具和商业策略的协同，HistCAD可从内部表示协议逐步发展为工业设计智能体生态中的通用过程语言——为团体标准和行业标准提供共同规则，为开源工具和社区机制提供接入路径，为商业模式和知识产权策略提供应用保障。由此，LuBan三层架构不仅完成了从协议、实现到验证的工程闭环，也为后续规模化推广和产业协同奠定了框架性技术基础。

本章围绕LuBan三层架构的系统集成与工业验证展开，重点说明数据层、工具层和Agent层如何从相对独立的能力模块，转化为可运行、可追踪、可验证、可回退和可人工接管的工程系统。首先定义三层之间的接口边界与任务闭环，然后讨论原型系统的模块划分、关键技术选型和部署方式，进一步通过五类工业场景验证系统能力，最后围绕HistCAD讨论标准推广、开源工具、社区建设、商业模式和知识产权策略。

5.5.1 核心概念回顾

LuBan三层架构由数据层、工具层和Agent层构成。数据层负责保存任务状态、建模历史、模型文件和验证记录；工具层负责执行建模、编辑、检查、转换和回退；Agent层负责任务理解、动作规划、工具调度和控制决策。

层间接口包括 IAD、IAT、ITD 三类。IAD 表示 Agent 层与数据层之间的状态读写通道，IAT 表示 Agent 层与工具层之间的执行调用通道，ITD 表示工具层向数据层回写结果的记录通道。三类接口共同保证任务过程可追踪、工具执行可记录、结果状态可复核。

闭环控制依赖验证机制 Av 和人工协同机制 Ah 。其中，Av 用于检查模型结果是否满足约束和边界条件，Ah 用于在歧义、失败、多解或高风险节点引入人工干预，二者共同保证系统能够继续、重试、回退、终止或交由人工接管。

原型系统实现需要大模型、向量数据库、几何内核、前后端框架、消息队列或任务队列、对象存储或文件管理服务等关键技术支撑。这些技术分别对应任务理解、知识检索、几何执行、异步调度、文件管理和系统部署。

工业验证包括建模序列检索、自然语言驱动零件生成与编辑、工程图重建、STEP 模型重建建模序列和多STEP装配五类任务。工业验证重点不仅包括最终结果是否正确，也包括过程是否可追踪、失败是否可解释、人工意见是否被记录。

HistCAD标准与生态面向建模过程表示、工具转换、验证复核和系统互操作。通过内部规范、团体标准、行业标准、开源工具和社区建设，HistCAD可从系统内部表示协议进一步发展为工业设计智能体的过程语言。

5.5.2 本章习题

1. 针对“STEP文件解析与特征识别”这一长耗时任务，设计一个消息队列或任务队列的执行流程。要求具体说明任务如何提交，如何进入等待队列，如何分配给工具执行节点，如何记录成功、失败和超时状态。

2. 以“自然语言驱动零件编辑”为例，按照任务接收、状态读取、任务规划、工具调用、结果回写、验证判断和控制决策七个步骤，写出一轮次完整的任务流转过程。

3. 设计一个面向“自然语言驱动零件生成与编辑”的极简版LuBan原型系统，包含但不限于具体阐述系统模块划分、三类接口设计、关键技术选型、任务执行流程、验证机制、人工协同机制和回归测试任务。

参考文献

[1] Yao S, Zhao J, Yu D, et al. ReAct: Synergizing reasoning and acting in language models[J]. arXiv preprint arXiv:2210.03629, 2022.

[2] Schick T, Dwivedi-Yu J, Dessì R, et al. Toolformer: Language models can teach themselves to use tools[J]. arXiv preprint arXiv:2302.04761, 2023.

[3] Lewis P, Perez E, Piktus A, et al. Retrieval-augmented generation for knowledge-intensive NLP tasks[C]//Advances in Neural Information Processing Systems. 2020, 33: 9459-9474.

[4] Sculley D, Holt G, Golovin D, et al. Hidden technical debt in machine learning systems[C]//Advances in Neural Information Processing Systems. 2015, 28.

[5] Model Context Protocol. Model Context Protocol Specification[EB/OL]. [2026-06-27]. https://modelcontextprotocol.io/specification.

[6] Humble J, Farley D. Continuous delivery: Reliable software releases through build, test, and deployment automation[M]. Boston: Addison-Wesley, 2010.

[7]合肥九韶智能科技有限公司. 九韶内核 AMCAX[EB/OL]. [2026-06-05]. https://product.amcax.net/

[8] Milvus. Milvus Documentation[EB/OL]. [2026-06-27]. https://milvus.io/docs.

[9] Qdrant. Qdrant Documentation[EB/OL]. [2026-06-27]. https://qdrant.tech/documentation/.

[10] Celery Project. Celery Documentation: Introduction to Celery[EB/OL]. [2026-06-27]. https://docs.celeryq.dev/en/stable/getting-started/introduction.html.

[11] RabbitMQ. RabbitMQ Documentation: Queues[EB/OL]. [2026-06-27]. https://www.rabbitmq.com/docs/queues.

[12] The Kubernetes Authors. Kubernetes Documentation[EB/OL]. [2026-06-27]. https://kubernetes.io/docs/home/.

[13] Dong X, Li C, Han C, et al. HistCAD: Geometrically constrained parametric history-based CAD dataset[J]. arXiv preprint arXiv:2602.19171, 2025.

[14] Apache Software Foundation. Apache License, Version 2.0[EB/OL]. [2026-06-27]. https://www.apache.org/licenses/LICENSE-2.0.

[15] GitHub, Inc. Choose a License: MIT License[EB/OL]. [2026-06-27]. https://choosealicense.com/licenses/mit/.

[16] Free Software Foundation. GNU General Public License, Version 3[EB/OL]. [2026-06-27]. https://www.gnu.org/licenses/gpl-3.0.en.html.

[17] Yan Y, Frey S, Zhang A, et al. GitHub OSS Governance File Dataset[J]. arXiv preprint arXiv:2304.00460, 2023.