1. 项目概述从单兵作战到团队协作的范式转变最近在推进一个工业设计自动化项目时我们遇到了一个瓶颈用传统的单智能体Single Agent方案来处理复杂的3D建模任务准确率始终卡在70%左右难以突破。无论是生成一个带复杂曲面的零件还是根据二维图纸重建三维模型AI总会犯一些“低级错误”比如尺寸偏差、特征遗漏或结构干涉。这就像让一个全能的工程师去完成从概念设计、结构计算、到细节建模、出图的全流程即使这个工程师再博学也难免在某个环节分心或出错。经过反复的推敲和实验我们最终做出了一个关键决策彻底放弃单Agent方案转向多智能体Multi-Agent协作。我们将这套新架构命名为HiCAD 3.0其核心是引入了Harness作为多Agent的编排框架。结果令人振奋在相同的任务集上3D建模的准确率提升了整整30%达到了一个可投入实际生产环境的可靠水平。这个提升并非简单的数字游戏它背后代表着设计自动化领域工作流范式的根本性转变。单Agent方案试图用一个“超级大脑”解决所有问题而HiCAD 3.0的思路是组建一个“专业团队”让擅长几何推理的、精通约束求解的、熟悉行业标准的“专家”们各司其职在Harness的协调下有序工作。今天我就来详细拆解我们是如何实现这一转变的包括背后的设计思路、Harness框架的核心玩法、具体的Agent分工与协作机制以及我们在实践中踩过的坑和总结出的调优心得。无论你是从事AI应用开发、工业软件研发还是对智能体协作感兴趣相信这篇来自一线的复盘都能给你带来启发。2. 为什么必须放弃单Agent深入痛点与架构瓶颈在深入HiCAD 3.0之前有必要先彻底剖析单Agent方案的局限性。这不仅仅是“效果不好”而是其架构本身在面对复杂、多步骤、强逻辑的3D建模任务时存在难以逾越的天花板。2.1 单Agent的“认知过载”与错误传播我们的单Agent模型是一个基于Transformer的大语言模型LLM经过大量CAD指令和三维几何数据微调。它接收自然语言描述或二维图纸图像直接输出STEP或IGES格式的三维模型文件。初看很强大但问题接踵而至。首先任务过于复杂导致“认知过载”。一个完整的建模指令如“生成一个内径50mm、外径70mm、高度30mm的法兰盘均布6个Φ10的螺栓孔并带有密封槽”其中包含了多个子任务理解主体形状圆柱体、计算布尔差集生成内孔、阵列特征螺栓孔、创建细节特征密封槽。单Agent需要在一个前向推理过程中同时处理几何、拓扑、约束、工艺等多维度信息极易顾此失彼。我们观察到它经常在完成螺栓孔阵列后“忘记”了密封槽或者密封槽的尺寸与内径不匹配。其次错误会沿着生成步骤不可逆地传播和放大。3D建模是一个强顺序依赖的过程。如果第一步生成的基础拉伸体尺寸就错了那么后续在这个错误体上进行的打孔、倒角等操作全部都会错最终生成一个完全无效的模型。单Agent的生成是“黑盒式”的我们很难在中间步骤进行干预和校正只能等到最终结果出来后再判定整体失败调试成本极高。2.2 难以融入领域知识与专业工具链工业设计有大量隐性的领域知识Domain Knowledge和标准规范如GB、ISO。例如螺栓孔的孔边距有最小值要求密封槽的截面形状有标准样式。我们尝试通过扩大训练数据、在Prompt中详细说明等方式将这些知识灌输给单Agent但效果有限。模型倾向于学习数据中的统计规律而非真正的物理和工程逻辑导致它生成的模型“看起来像”但“经不起推敲”无法直接用于后续的仿真分析或加工。此外现有的CAD软件如SolidWorks, CATIA, Fusion 360拥有经过数十年验证的、极其稳定和强大的几何建模内核如ACIS Parasolid。单Agent方案通常需要自己实现或封装一套几何运算库这不仅开发难度大而且在稳定性和功能完整性上远不及商业内核。我们陷入了“重复造轮子”且“轮子质量不高”的困境。2.3 评估与迭代的反馈环路太长在单Agent方案下评估模型输出好坏是一个“整体性”任务。我们需要将生成的3D模型导入专业软件检查特征完整性、尺寸精度、约束满足情况等。这个过程自动化程度低耗时很长。更关键的是这个“好/坏”的反馈信号太粗糙无法指导模型进行精细化的改进。我们不知道是模型的几何理解能力不足还是约束求解逻辑有误抑或是输出格式处理有问题。这种漫长的反馈环路严重拖慢了迭代优化的速度。正是基于以上三点核心痛点我们意识到必须将“一个AI做所有事”的架构拆解为“多个AI协作每个AI做自己最擅长的事”的架构。而实现这种协作的关键就是一个高效、可靠的编排系统——这就是Harness登场的原因。3. Harness编排框架多Agent系统的“中央调度器”当我们决定转向多Agent时市面上已有一些智能体框架如LangChain、AutoGen等。但我们最终选择了Harness主要是看中了它在流程编排的严谨性、状态管理的可视性以及与现有工程体系融合度上的优势。Harness更像一个为生产环境设计的“工作流引擎”而不仅仅是实验性的智能体对话框架。3.1 Harness的核心概念与我们的适配改造Harness的核心是将一个复杂任务定义为一个流水线Pipeline流水线由多个阶段Stage组成每个阶段包含一个或多个步骤Step而每个步骤则由一个智能体Agent来执行。它提供了完整的依赖管理、条件判断、循环、异常处理和审计日志。我们对Harness进行了深度定制将其与我们的3D建模领域紧密结合Agent专业化封装我们将每个专业能力如草图识别、特征推理、约束求解封装成独立的Harness Agent。每个Agent是一个独立的微服务有清晰的输入/输出接口。领域特定状态Context设计我们定义了一个共享的“设计上下文”它不仅仅传递文本而是结构化的数据包括参数化草图、特征树、约束列表、三维B-rep数据通过OCCT内核的轻量化表示、设计意图标注等。这个上下文是Agent间沟通的“共同语言”。集成商业CAD内核我们放弃了自研几何库转而将SolidWorks的API和开源的OpenCASCADEOCCT内核封装成“几何引擎服务”。Harness中的Agent通过调用这些服务来执行实际的几何创建和修改操作保证了工业级的可靠性和精度。3.2 一个典型建模任务在Harness中的执行流程以“生成法兰盘”为例HiCAD 3.0在Harness中的流水线是这样的1. Stage: 需求解析与任务规划 - Step 1.1: [自然语言理解Agent] 解析用户指令输出结构化任务列表。 * 输出: {“主体”: “圆柱体”, “参数”: {“外径”:70, “内径”:50, “高度”:30}, “特征”: [“均布螺栓孔*6”, “矩形密封槽”]} 2. Stage: 草图生成与约束求解 - Step 2.1: [二维草图生成Agent] 根据参数生成法兰端面的二维草图轮廓两个同心圆。 - Step 2.2: [几何约束Agent] 为草图添加约束同心、直径尺寸。 - Step 2.3: [约束求解器Agent] 调用几何引擎求解约束确保草图完全定义。 3. Stage: 三维特征创建 - Step 3.1: [特征建模Agent] 调用几何引擎将草图拉伸为三维实体。 - Step 3.2: [特征识别与阵列Agent] 识别“螺栓孔”特征计算阵列位置调用打孔和阵列命令。 - Step 3.3: [细节特征Agent] 根据“密封槽”类型从特征库中选择标准截面进行扫掠或拉伸切除操作。 4. Stage: 验证与优化 - Step 4.1: [几何检查Agent] 检查模型是否存在自相交、零厚度等几何错误。 - Step 4.2: [设计规则检查Agent] 检查孔边距、最小壁厚等是否符合工程规则。 - Step 4.3: [轻量化与输出Agent] 将模型转换为轻量化格式并输出为指定文件。Harness会严格按顺序执行这些Stage并管理每个Step的输出将其传递到下一个需要它的Step。如果某个Step失败如约束求解失败Harness会根据预设策略如重试、转人工、执行备用分支进行处理而不是让整个流程崩溃。实操心得Harness配置的关键在配置Harness流水线时最关键的harness.yaml配置段是failureStrategies失败策略。我们为每个关键Step都设置了“重试3次若失败则跳转到修复Agent”的策略。例如约束求解失败后会触发一个“约束松弛Agent”尝试自动放松某些非关键约束或提示用户进行决策。这大大提高了流程的鲁棒性。4. HiCAD 3.0的多Agent团队角色、职责与协作机制HiCAD 3.0的成功离不开其内部一个个高度专业化的Agent。它们不是简单的提示词模板而是具有特定能力、甚至具备一定“反思”能力的智能模块。4.1 核心Agent成员介绍需求分析师Requirement Analyst Agent职责将模糊的自然语言指令转化为精确的、结构化的设计需求清单Design Requirement List, DRL。它利用领域知识库对“法兰盘”、“密封槽”等术语进行消歧义和标准化。核心技术经过CAD领域文本微调的LLM 实体识别NER模型。它的输出不是文本而是一个JSON Schema定义的结构化数据。避坑点初期这个Agent容易产生“幻觉”添加用户未提及的特征。我们通过严格的输出模式约束JSON Schema校验和基于规则的后处理过滤器来解决。几何推理师Geometric Reasoning Agent职责理解二维草图与三维特征之间的映射关系。例如知道一个圆形草图可以通过“拉伸”变成圆柱也可以通过“旋转”变成球体。核心技术图神经网络GNN。我们将草图表示为图节点是几何元素如点、线、弧边是约束关系将建模历史也表示为图训练GNN来预测最可能的下一特征操作。实操技巧这个Agent的决策会附带一个“置信度”。当置信度低于阈值如0.85时Harness会暂停流程将决策请求发送给“人工审核队列”或请求用户澄清避免了盲目执行导致的错误。约束管家Constraint Butler Agent职责管理和维护整个建模过程中的几何约束与尺寸约束。它记录所有约束并在模型修改时判断哪些约束需要更新、哪些可能冲突。核心技术基于符号计算的约束管理系统。它与商业求解器如D-Cubed深度集成。经验分享约束冲突是建模失败的主要原因之一。我们让“约束管家”在每次添加新约束前都执行一次快速的“冲突预检测”提前发现问题并从冲突解决方案库中推荐最优解。设计规则检查员DRC Agent职责专司设计规则检查Design Rule Check。它内置了大量行业规则如钣金最小折弯半径、注塑件最小脱模斜度和公司内部规范。实现这个Agent更多是基于规则的。它接收模型调用几何引擎的查询API获取参数然后与规则库逐条比对生成DRC报告。价值它确保了AI生成的模型不仅是“几何正确”的更是“可制造”的这是从“玩具”到“工具”的关键一步。4.2 Agent间的通信与上下文共享Agent之间不直接对话而是通过Harness管理的共享设计上下文进行协作。这个上下文是一个不断演进的数据结构。初始上下文仅包含用户原始指令。需求分析后上下文增加了structured_requirements结构化需求字段。草图生成后上下文增加了sketch_data草图几何数据和sketch_constraints草图约束字段。三维建模后上下文增加了feature_tree特征树和brep_pointer指向几何引擎中三维模型的指针。每个Agent都只关注上下文中与自己相关的部分并负责更新自己负责的字段。这种设计降低了耦合度使得单个Agent的升级或替换变得非常容易。例如我们可以换一个更强大的LLM作为“需求分析师”只要它输出的structured_requirements符合Schema其他Agent完全不受影响。5. 准确率提升30%的背后量化分析与效果归因“准确率提升30%”不是一个模糊的感觉而是基于一套严格的评估体系得出的数据。我们定义了三个层次的准确率指标几何准确率生成的模型与理想模型在几何形状上的一致程度通过体积、表面积、关键点距离等计算。特征完整率用户要求的所有设计特征是否都被正确创建。设计合规率模型是否通过所有设计规则检查DRC。5.1 A/B测试对比数据我们在一个包含500个复杂程度各异的建模任务测试集上对比了单Agent方案HiCAD 2.0和多Agent编排方案HiCAD 3.0的表现评估指标HiCAD 2.0 (单Agent)HiCAD 3.0 (多AgentHarness)提升幅度几何准确率68.5%89.2%20.7%特征完整率72.0%95.1%23.1%设计合规率65.0%94.5%29.5%综合任务通过率70.0%91.5%21.5%注意综合任务通过率要求几何、特征、合规三项全部达标。多Agent方案在设计合规率上提升最大这直接归功于专职的“DRC Agent”在流程中的嵌入它在模型生成过程中就提前规避了违规设计。5.2 关键归因分析错误隔离与局部修复单Agent的错误是全局性的。多Agent架构下错误通常被限制在某个特定的Step。例如只是“草图约束冲突”那么只需要“约束管家”和“约束求解器”介入修复即可后续已完成的“需求分析”等步骤成果可以复用。这使得调试和修复成本降低了约70%。专业化带来的精度提升每个Agent只专注于一个子任务可以做得更深、更精。专门做草图生成的Agent其训练数据和优化目标纯粹是草图相关自然比一个“全才”Agent画得更准。可解释性增强Harness的审计日志记录了每个Agent的输入、输出和决策依据。当最终结果出错时我们可以像查看生产日志一样精准定位到是哪个Agent、在哪个环节、基于什么信息做出了错误决策。这为模型的持续优化提供了清晰的路径。灵活融入规则与工具基于Harness的流水线我们可以轻松地在任意环节插入一个基于规则的检查点或调用一个外部工具如调用ANSYS进行简单的应力校核。这种“AI规则工具”的混合智能模式是单一神经网络模型难以实现的。6. 实践中的挑战与我们的解决方案转向多Agent和Harness编排并非一帆风顺我们遇到了许多预料之中和预料之外的挑战。6.1 挑战一Agent间的“沟通误解”尽管有共享上下文但不同Agent对同一数据的理解可能存在细微偏差。例如“需求分析师”输出的“矩形密封槽”在“细节特征Agent”的特征库中可能有三种变体。解决方案我们建立了领域本体Ontology和标准特征库。所有Agent在描述特征时必须使用本体中定义的唯一ID。例如“矩形密封槽”对应Feature_ID: AS568-010。这确保了语义的一致性。6.2 挑战二流水线执行效率串行执行的流水线可能导致总耗时较长。如果“几何检查Agent”运行很慢它会阻塞整个流程。解决方案利用Harness的并行步骤Parallel Steps功能。我们将非强依赖的检查任务并行化。例如在“三维特征创建”Stage完成后可以同时并行执行“几何检查”和“设计规则检查”而不是等一个完成后再做另一个。这使整体任务耗时减少了约40%。6.3 挑战三复杂循环与条件逻辑的处理有些建模过程包含循环如尝试不同的设计参数或复杂条件分支如如果壁厚小于X则自动添加加强筋。解决方案深度使用Harness的条件执行Conditional Execution和循环Loop策略。我们将这些逻辑以声明式的方式写在流水线YAML定义中而不是硬编码在某个Agent里。这使得业务逻辑清晰可见且易于修改。例如一个优化壁厚的循环其终止条件如“应力低于阈值”或“循环超过5次”直接在Harness层面配置。6.4 挑战四调试与监控复杂度系统从单个服务变成了由多个微服务Agent和Harness编排器组成的分布式系统调试和监控变得复杂。解决方案我们为每个Agent集成了统一的结构化日志和指标上报使用Prometheus。Harness UI本身提供了强大的可视化执行图。我们还将关键Agent的决策过程如“几何推理师”选择特征类型的Top-K理由记录到上下文方便回溯。我们搭建了一个中央监控看板可以实时查看流水线成功率、各Agent耗时、错误类型分布等。7. 总结与展望多Agent编排是复杂AI应用的必然路径回顾从HiCAD 2.0到3.0的升级放弃单Agent、拥抱基于Harness的多Agent编排对我们而言不是一个可选优化而是一个必由之路。当AI要解决的任务从“简单问答”升级到“复杂创造”时单一模型的能力边界就会凸显。通过分工协作让专业的人Agent做专业的事并在一个稳健的编排框架Harness下有序组织是提升复杂任务成功率、可靠性、可解释性的有效架构。这次升级带来的最大收获不仅仅是30%的准确率提升更是一种工程范式的确立。我们现在可以像搭积木一样通过组合和调整不同的Agent快速构建针对不同细分场景如钣金设计、管道布线的自动化流程。Harness提供的稳定性保障也让我们有信心将系统部署到真实的生产环境中接受实际用户的检验。当然这套架构还在持续演进中。我们正在探索如何让Agent之间不仅能通过结构化上下文协作还能进行更灵活的“对话”和“辩论”以处理那些定义极其模糊的创意性设计任务。同时如何让终端用户以更自然的方式如手势、草图与这个多Agent系统交互也是一个充满挑战和乐趣的方向。这条路还很长但第一步我们确信自己走对了。 从单智能体到多智能体协作：基于Harness框架的3D设计自动化架构演进
1. 项目概述从单兵作战到团队协作的范式转变最近在推进一个工业设计自动化项目时我们遇到了一个瓶颈用传统的单智能体Single Agent方案来处理复杂的3D建模任务准确率始终卡在70%左右难以突破。无论是生成一个带复杂曲面的零件还是根据二维图纸重建三维模型AI总会犯一些“低级错误”比如尺寸偏差、特征遗漏或结构干涉。这就像让一个全能的工程师去完成从概念设计、结构计算、到细节建模、出图的全流程即使这个工程师再博学也难免在某个环节分心或出错。经过反复的推敲和实验我们最终做出了一个关键决策彻底放弃单Agent方案转向多智能体Multi-Agent协作。我们将这套新架构命名为HiCAD 3.0其核心是引入了Harness作为多Agent的编排框架。结果令人振奋在相同的任务集上3D建模的准确率提升了整整30%达到了一个可投入实际生产环境的可靠水平。这个提升并非简单的数字游戏它背后代表着设计自动化领域工作流范式的根本性转变。单Agent方案试图用一个“超级大脑”解决所有问题而HiCAD 3.0的思路是组建一个“专业团队”让擅长几何推理的、精通约束求解的、熟悉行业标准的“专家”们各司其职在Harness的协调下有序工作。今天我就来详细拆解我们是如何实现这一转变的包括背后的设计思路、Harness框架的核心玩法、具体的Agent分工与协作机制以及我们在实践中踩过的坑和总结出的调优心得。无论你是从事AI应用开发、工业软件研发还是对智能体协作感兴趣相信这篇来自一线的复盘都能给你带来启发。2. 为什么必须放弃单Agent深入痛点与架构瓶颈在深入HiCAD 3.0之前有必要先彻底剖析单Agent方案的局限性。这不仅仅是“效果不好”而是其架构本身在面对复杂、多步骤、强逻辑的3D建模任务时存在难以逾越的天花板。2.1 单Agent的“认知过载”与错误传播我们的单Agent模型是一个基于Transformer的大语言模型LLM经过大量CAD指令和三维几何数据微调。它接收自然语言描述或二维图纸图像直接输出STEP或IGES格式的三维模型文件。初看很强大但问题接踵而至。首先任务过于复杂导致“认知过载”。一个完整的建模指令如“生成一个内径50mm、外径70mm、高度30mm的法兰盘均布6个Φ10的螺栓孔并带有密封槽”其中包含了多个子任务理解主体形状圆柱体、计算布尔差集生成内孔、阵列特征螺栓孔、创建细节特征密封槽。单Agent需要在一个前向推理过程中同时处理几何、拓扑、约束、工艺等多维度信息极易顾此失彼。我们观察到它经常在完成螺栓孔阵列后“忘记”了密封槽或者密封槽的尺寸与内径不匹配。其次错误会沿着生成步骤不可逆地传播和放大。3D建模是一个强顺序依赖的过程。如果第一步生成的基础拉伸体尺寸就错了那么后续在这个错误体上进行的打孔、倒角等操作全部都会错最终生成一个完全无效的模型。单Agent的生成是“黑盒式”的我们很难在中间步骤进行干预和校正只能等到最终结果出来后再判定整体失败调试成本极高。2.2 难以融入领域知识与专业工具链工业设计有大量隐性的领域知识Domain Knowledge和标准规范如GB、ISO。例如螺栓孔的孔边距有最小值要求密封槽的截面形状有标准样式。我们尝试通过扩大训练数据、在Prompt中详细说明等方式将这些知识灌输给单Agent但效果有限。模型倾向于学习数据中的统计规律而非真正的物理和工程逻辑导致它生成的模型“看起来像”但“经不起推敲”无法直接用于后续的仿真分析或加工。此外现有的CAD软件如SolidWorks, CATIA, Fusion 360拥有经过数十年验证的、极其稳定和强大的几何建模内核如ACIS Parasolid。单Agent方案通常需要自己实现或封装一套几何运算库这不仅开发难度大而且在稳定性和功能完整性上远不及商业内核。我们陷入了“重复造轮子”且“轮子质量不高”的困境。2.3 评估与迭代的反馈环路太长在单Agent方案下评估模型输出好坏是一个“整体性”任务。我们需要将生成的3D模型导入专业软件检查特征完整性、尺寸精度、约束满足情况等。这个过程自动化程度低耗时很长。更关键的是这个“好/坏”的反馈信号太粗糙无法指导模型进行精细化的改进。我们不知道是模型的几何理解能力不足还是约束求解逻辑有误抑或是输出格式处理有问题。这种漫长的反馈环路严重拖慢了迭代优化的速度。正是基于以上三点核心痛点我们意识到必须将“一个AI做所有事”的架构拆解为“多个AI协作每个AI做自己最擅长的事”的架构。而实现这种协作的关键就是一个高效、可靠的编排系统——这就是Harness登场的原因。3. Harness编排框架多Agent系统的“中央调度器”当我们决定转向多Agent时市面上已有一些智能体框架如LangChain、AutoGen等。但我们最终选择了Harness主要是看中了它在流程编排的严谨性、状态管理的可视性以及与现有工程体系融合度上的优势。Harness更像一个为生产环境设计的“工作流引擎”而不仅仅是实验性的智能体对话框架。3.1 Harness的核心概念与我们的适配改造Harness的核心是将一个复杂任务定义为一个流水线Pipeline流水线由多个阶段Stage组成每个阶段包含一个或多个步骤Step而每个步骤则由一个智能体Agent来执行。它提供了完整的依赖管理、条件判断、循环、异常处理和审计日志。我们对Harness进行了深度定制将其与我们的3D建模领域紧密结合Agent专业化封装我们将每个专业能力如草图识别、特征推理、约束求解封装成独立的Harness Agent。每个Agent是一个独立的微服务有清晰的输入/输出接口。领域特定状态Context设计我们定义了一个共享的“设计上下文”它不仅仅传递文本而是结构化的数据包括参数化草图、特征树、约束列表、三维B-rep数据通过OCCT内核的轻量化表示、设计意图标注等。这个上下文是Agent间沟通的“共同语言”。集成商业CAD内核我们放弃了自研几何库转而将SolidWorks的API和开源的OpenCASCADEOCCT内核封装成“几何引擎服务”。Harness中的Agent通过调用这些服务来执行实际的几何创建和修改操作保证了工业级的可靠性和精度。3.2 一个典型建模任务在Harness中的执行流程以“生成法兰盘”为例HiCAD 3.0在Harness中的流水线是这样的1. Stage: 需求解析与任务规划 - Step 1.1: [自然语言理解Agent] 解析用户指令输出结构化任务列表。 * 输出: {“主体”: “圆柱体”, “参数”: {“外径”:70, “内径”:50, “高度”:30}, “特征”: [“均布螺栓孔*6”, “矩形密封槽”]} 2. Stage: 草图生成与约束求解 - Step 2.1: [二维草图生成Agent] 根据参数生成法兰端面的二维草图轮廓两个同心圆。 - Step 2.2: [几何约束Agent] 为草图添加约束同心、直径尺寸。 - Step 2.3: [约束求解器Agent] 调用几何引擎求解约束确保草图完全定义。 3. Stage: 三维特征创建 - Step 3.1: [特征建模Agent] 调用几何引擎将草图拉伸为三维实体。 - Step 3.2: [特征识别与阵列Agent] 识别“螺栓孔”特征计算阵列位置调用打孔和阵列命令。 - Step 3.3: [细节特征Agent] 根据“密封槽”类型从特征库中选择标准截面进行扫掠或拉伸切除操作。 4. Stage: 验证与优化 - Step 4.1: [几何检查Agent] 检查模型是否存在自相交、零厚度等几何错误。 - Step 4.2: [设计规则检查Agent] 检查孔边距、最小壁厚等是否符合工程规则。 - Step 4.3: [轻量化与输出Agent] 将模型转换为轻量化格式并输出为指定文件。Harness会严格按顺序执行这些Stage并管理每个Step的输出将其传递到下一个需要它的Step。如果某个Step失败如约束求解失败Harness会根据预设策略如重试、转人工、执行备用分支进行处理而不是让整个流程崩溃。实操心得Harness配置的关键在配置Harness流水线时最关键的harness.yaml配置段是failureStrategies失败策略。我们为每个关键Step都设置了“重试3次若失败则跳转到修复Agent”的策略。例如约束求解失败后会触发一个“约束松弛Agent”尝试自动放松某些非关键约束或提示用户进行决策。这大大提高了流程的鲁棒性。4. HiCAD 3.0的多Agent团队角色、职责与协作机制HiCAD 3.0的成功离不开其内部一个个高度专业化的Agent。它们不是简单的提示词模板而是具有特定能力、甚至具备一定“反思”能力的智能模块。4.1 核心Agent成员介绍需求分析师Requirement Analyst Agent职责将模糊的自然语言指令转化为精确的、结构化的设计需求清单Design Requirement List, DRL。它利用领域知识库对“法兰盘”、“密封槽”等术语进行消歧义和标准化。核心技术经过CAD领域文本微调的LLM 实体识别NER模型。它的输出不是文本而是一个JSON Schema定义的结构化数据。避坑点初期这个Agent容易产生“幻觉”添加用户未提及的特征。我们通过严格的输出模式约束JSON Schema校验和基于规则的后处理过滤器来解决。几何推理师Geometric Reasoning Agent职责理解二维草图与三维特征之间的映射关系。例如知道一个圆形草图可以通过“拉伸”变成圆柱也可以通过“旋转”变成球体。核心技术图神经网络GNN。我们将草图表示为图节点是几何元素如点、线、弧边是约束关系将建模历史也表示为图训练GNN来预测最可能的下一特征操作。实操技巧这个Agent的决策会附带一个“置信度”。当置信度低于阈值如0.85时Harness会暂停流程将决策请求发送给“人工审核队列”或请求用户澄清避免了盲目执行导致的错误。约束管家Constraint Butler Agent职责管理和维护整个建模过程中的几何约束与尺寸约束。它记录所有约束并在模型修改时判断哪些约束需要更新、哪些可能冲突。核心技术基于符号计算的约束管理系统。它与商业求解器如D-Cubed深度集成。经验分享约束冲突是建模失败的主要原因之一。我们让“约束管家”在每次添加新约束前都执行一次快速的“冲突预检测”提前发现问题并从冲突解决方案库中推荐最优解。设计规则检查员DRC Agent职责专司设计规则检查Design Rule Check。它内置了大量行业规则如钣金最小折弯半径、注塑件最小脱模斜度和公司内部规范。实现这个Agent更多是基于规则的。它接收模型调用几何引擎的查询API获取参数然后与规则库逐条比对生成DRC报告。价值它确保了AI生成的模型不仅是“几何正确”的更是“可制造”的这是从“玩具”到“工具”的关键一步。4.2 Agent间的通信与上下文共享Agent之间不直接对话而是通过Harness管理的共享设计上下文进行协作。这个上下文是一个不断演进的数据结构。初始上下文仅包含用户原始指令。需求分析后上下文增加了structured_requirements结构化需求字段。草图生成后上下文增加了sketch_data草图几何数据和sketch_constraints草图约束字段。三维建模后上下文增加了feature_tree特征树和brep_pointer指向几何引擎中三维模型的指针。每个Agent都只关注上下文中与自己相关的部分并负责更新自己负责的字段。这种设计降低了耦合度使得单个Agent的升级或替换变得非常容易。例如我们可以换一个更强大的LLM作为“需求分析师”只要它输出的structured_requirements符合Schema其他Agent完全不受影响。5. 准确率提升30%的背后量化分析与效果归因“准确率提升30%”不是一个模糊的感觉而是基于一套严格的评估体系得出的数据。我们定义了三个层次的准确率指标几何准确率生成的模型与理想模型在几何形状上的一致程度通过体积、表面积、关键点距离等计算。特征完整率用户要求的所有设计特征是否都被正确创建。设计合规率模型是否通过所有设计规则检查DRC。5.1 A/B测试对比数据我们在一个包含500个复杂程度各异的建模任务测试集上对比了单Agent方案HiCAD 2.0和多Agent编排方案HiCAD 3.0的表现评估指标HiCAD 2.0 (单Agent)HiCAD 3.0 (多AgentHarness)提升幅度几何准确率68.5%89.2%20.7%特征完整率72.0%95.1%23.1%设计合规率65.0%94.5%29.5%综合任务通过率70.0%91.5%21.5%注意综合任务通过率要求几何、特征、合规三项全部达标。多Agent方案在设计合规率上提升最大这直接归功于专职的“DRC Agent”在流程中的嵌入它在模型生成过程中就提前规避了违规设计。5.2 关键归因分析错误隔离与局部修复单Agent的错误是全局性的。多Agent架构下错误通常被限制在某个特定的Step。例如只是“草图约束冲突”那么只需要“约束管家”和“约束求解器”介入修复即可后续已完成的“需求分析”等步骤成果可以复用。这使得调试和修复成本降低了约70%。专业化带来的精度提升每个Agent只专注于一个子任务可以做得更深、更精。专门做草图生成的Agent其训练数据和优化目标纯粹是草图相关自然比一个“全才”Agent画得更准。可解释性增强Harness的审计日志记录了每个Agent的输入、输出和决策依据。当最终结果出错时我们可以像查看生产日志一样精准定位到是哪个Agent、在哪个环节、基于什么信息做出了错误决策。这为模型的持续优化提供了清晰的路径。灵活融入规则与工具基于Harness的流水线我们可以轻松地在任意环节插入一个基于规则的检查点或调用一个外部工具如调用ANSYS进行简单的应力校核。这种“AI规则工具”的混合智能模式是单一神经网络模型难以实现的。6. 实践中的挑战与我们的解决方案转向多Agent和Harness编排并非一帆风顺我们遇到了许多预料之中和预料之外的挑战。6.1 挑战一Agent间的“沟通误解”尽管有共享上下文但不同Agent对同一数据的理解可能存在细微偏差。例如“需求分析师”输出的“矩形密封槽”在“细节特征Agent”的特征库中可能有三种变体。解决方案我们建立了领域本体Ontology和标准特征库。所有Agent在描述特征时必须使用本体中定义的唯一ID。例如“矩形密封槽”对应Feature_ID: AS568-010。这确保了语义的一致性。6.2 挑战二流水线执行效率串行执行的流水线可能导致总耗时较长。如果“几何检查Agent”运行很慢它会阻塞整个流程。解决方案利用Harness的并行步骤Parallel Steps功能。我们将非强依赖的检查任务并行化。例如在“三维特征创建”Stage完成后可以同时并行执行“几何检查”和“设计规则检查”而不是等一个完成后再做另一个。这使整体任务耗时减少了约40%。6.3 挑战三复杂循环与条件逻辑的处理有些建模过程包含循环如尝试不同的设计参数或复杂条件分支如如果壁厚小于X则自动添加加强筋。解决方案深度使用Harness的条件执行Conditional Execution和循环Loop策略。我们将这些逻辑以声明式的方式写在流水线YAML定义中而不是硬编码在某个Agent里。这使得业务逻辑清晰可见且易于修改。例如一个优化壁厚的循环其终止条件如“应力低于阈值”或“循环超过5次”直接在Harness层面配置。6.4 挑战四调试与监控复杂度系统从单个服务变成了由多个微服务Agent和Harness编排器组成的分布式系统调试和监控变得复杂。解决方案我们为每个Agent集成了统一的结构化日志和指标上报使用Prometheus。Harness UI本身提供了强大的可视化执行图。我们还将关键Agent的决策过程如“几何推理师”选择特征类型的Top-K理由记录到上下文方便回溯。我们搭建了一个中央监控看板可以实时查看流水线成功率、各Agent耗时、错误类型分布等。7. 总结与展望多Agent编排是复杂AI应用的必然路径回顾从HiCAD 2.0到3.0的升级放弃单Agent、拥抱基于Harness的多Agent编排对我们而言不是一个可选优化而是一个必由之路。当AI要解决的任务从“简单问答”升级到“复杂创造”时单一模型的能力边界就会凸显。通过分工协作让专业的人Agent做专业的事并在一个稳健的编排框架Harness下有序组织是提升复杂任务成功率、可靠性、可解释性的有效架构。这次升级带来的最大收获不仅仅是30%的准确率提升更是一种工程范式的确立。我们现在可以像搭积木一样通过组合和调整不同的Agent快速构建针对不同细分场景如钣金设计、管道布线的自动化流程。Harness提供的稳定性保障也让我们有信心将系统部署到真实的生产环境中接受实际用户的检验。当然这套架构还在持续演进中。我们正在探索如何让Agent之间不仅能通过结构化上下文协作还能进行更灵活的“对话”和“辩论”以处理那些定义极其模糊的创意性设计任务。同时如何让终端用户以更自然的方式如手势、草图与这个多Agent系统交互也是一个充满挑战和乐趣的方向。这条路还很长但第一步我们确信自己走对了。