1. 从单Agent到多Agent我们为何要“放弃”在AI驱动的3D建模领域单Agent方案曾是我们的起点也是很多团队的舒适区。一个模型一个任务逻辑清晰调试简单。我们早期的HiCAD 2.0版本就是典型的单Agent架构输入一段自然语言描述比如“设计一个带圆角的长方体底座上面有一个圆柱形支柱”模型会尝试理解并直接生成对应的3D建模指令序列。听起来很美好对吧但实际跑起来准确率就像过山车时高时低尤其是在处理复杂、多约束的建模任务时成功率很难稳定突破70%。问题出在哪里我们花了大量时间复盘。一个核心发现是3D建模是一个高度结构化、多步骤、强逻辑依赖的复合任务。它不像图像生成那样是“一锤子买卖”。一个简单的杯子就包含了草图绘制、轮廓约束、拉伸/旋转成型、倒角/圆角处理、抽壳等多个子步骤。让一个“全能型”Agent去同时处理几何理解、空间关系推理、参数计算、操作顺序规划就像让一个程序员同时写前端、后端、算法和运维脚本虽然可能有人能做到但效率和出错率是硬伤。具体来说单Agent方案的瓶颈体现在三个层面注意力分散与任务混淆模型在理解“创建一个半径为50mm高度为100mm的圆柱并在其一端创建一个深10mm的M6螺纹孔”时需要同时识别几何实体圆柱、参数半径、高度、布尔操作打孔、以及特定工艺特征螺纹。在生成长序列指令时模型很容易在某个环节“分心”例如把螺纹孔的深度参数错误地关联到圆柱高度上或者忘记了先执行“打孔”再执行“螺纹”的顺序。错误传播与累积3D建模步骤环环相扣。第一步草图绘制如果定位有1mm的偏差后续所有基于此草图的特征都会放大这个错误。单Agent方案一旦在早期产生一个细微的误解这个错误会像滚雪球一样贯穿整个生成过程导致最终模型完全偏离预期且调试起来异常困难你很难定位是哪个“思维环节”出了错。专业知识难以深度融合3D建模涉及大量领域知识如工程制图标准、制造工艺约束最小壁厚、拔模角、装配关系等。我们希望HiCAD不止能“画出来”还要能“画得对”、“画得好”。试图将所有专业知识压缩进一个模型的提示词Prompt或通过微调让一个模型掌握全部会导致知识冲突和遗忘模型表现会变得不稳定。所以“放弃”单Agent不是否定其价值而是在特定问题复杂度下的必然选择。当任务可以被清晰地分解为多个专业子任务且子任务间存在明确的输入输出关系时多Agent分工协作的架构优势就凸显出来了。这就像从“手工作坊”升级到“现代化流水线”每个工位Agent只专注于自己最擅长的环节通过一套精密的调度系统编排框架串联起来最终实现效率与质量的跃升。2. HiCAD 3.0 的核心架构Harness 如何扮演“总指挥”确定了多Agent的方向下一个关键问题是如何让多个Agent高效、可靠地协同工作这就是引入编排Orchestration框架的必要性。我们评估了多个方案最终选择了Harness作为HiCAD 3.0的“中央神经系统”。它不是唯一的选项但它的设计哲学与我们的需求高度契合。为什么是Harness市面上常见的多Agent协作模式有基于LangChain的简单链式调用或者更复杂的AutoGen等框架。Harness吸引我们的核心在于它对复杂工作流Workflow的原生支持和对状态管理的精细化控制。LangChain更适合构建清晰的、顺序执行的链Chain但在处理3D建模这种带有大量条件分支“如果这里是通孔则...否则...”、循环“阵列这个特征5次”以及异常回退“上一步布尔运算失败尝试替代方案”的场景时表达起来会显得笨拙代码可读性和可维护性下降。AutoGen提供了强大的多Agent对话能力但对于需要严格步骤控制、结构化数据传递的生产级任务流其对话式的松散耦合有时会引入不确定性。Harness则采用了“工作流即代码”的理念。它将整个3D建模任务定义为一个有向无环图DAG图中的每个节点是一个专业化Agent边代表了数据流和依赖关系。这让我们可以直观地设计和监控整个建模过程。HiCAD 3.0 的Harness工作流设计在我们的架构中一个典型的建模工作流被分解为以下几个核心Agent节点2.1 自然语言理解与任务规划 Agent (NLU Planner Agent)这是工作流的起点。它接收用户的自然语言描述例如“请设计一个连接板中间有一个φ20的通孔四角有4个φ8的沉头孔用于安装板材厚度10mm。”职责进行深度语义解析识别出所有几何实体、尺寸参数、约束关系同心、平行等、特征类型拉伸、切除、孔、倒角等以及工艺要求通孔、沉头。输出一个结构化的任务计划清单。这个清单不是最终的CAD命令而是一个高级别的、顺序化的操作列表。例如创建基准面Top Plane。在该面上绘制一个矩形草图长宽待参数Agent确定完全定义。拉伸草图厚度10mm生成基体。在基体上表面中心创建草图点生成φ20的通孔特征。在基体四角创建草图点生成φ8的沉头孔特征深度、角度待参数Agent确定。技术实现我们基于微调后的Code Llama或DeepSeek-Coder构建此Agent重点强化其对于工程图纸语言的理解能力和步骤分解的逻辑性。2.2 几何与参数解析 Agent (Geometry Parameter Agent)这个Agent接收任务计划清单。它的核心工作是“填空”将模糊的描述转化为精确的、可计算的数值和几何关系。职责参数计算如果用户说“四角有4个孔”它会根据矩形板的尺寸自动计算出四个角点的精确坐标。如果用户说“沉头孔”它会根据标准件库或默认规则补充出沉头直径、深度、角度等未明说的参数。约束推理“中间的孔”会被解析为与矩形中心同心约束。“用于安装的孔”可能会被自动添加“螺纹”或“过盈配合”的标记传递给下游Agent。几何可行性检查初步判断参数是否合理例如孔的直径是否大于板厚导致无法生成通孔。输出一个参数化、完全定义的草图与特征描述集。每个草图都有确定的尺寸、每个特征都有明确的类型和参数。技术实现这个Agent集成了符号计算和几何推理引擎。我们使用了OpenCASCADE的内核进行一些底层的几何关系验证同时用一个轻量级的规则引擎来处理参数推理逻辑。2.3 CAD 指令生成 Agent (CAD Command Agent)这是将抽象计划转化为具体行动的关键环节。它接收参数化描述集。职责根据目标CAD平台如SolidWorks, Fusion 360, Onshape API生成对应的、可执行的API调用序列或脚本如Python宏。输出一段针对特定CAD软件的、无歧义的指令代码。例如对于Fusion 360可能是调用adsk.fusionAPI创建草图、绘制矩形、添加尺寸约束、执行拉伸命令的Python脚本。技术实现我们为每个支持的CAD平台训练了一个专门的代码生成模型。这个模型的训练数据是“参数化描述”到“CAD API代码”的配对数据。由于输入已经是结构化的大大降低了代码生成的难度和错误率。2.4 仿真验证与优化 Agent (Simulation Validation Agent)这是我们的“质量检查员”。在指令生成后、正式提交给CAD软件前它会被触发。职责语法与逻辑校验检查生成的代码是否有语法错误API调用顺序是否合理。轻量级几何验证通过调用一个“无头模式”Headless的CAD内核或简化仿真器快速执行生成的指令检查是否能成功生成实体是否存在自相交、零厚度等几何错误。设计规则检查DRC验证模型是否符合预设的规则如最小壁厚、最小孔径、是否存在锐边等。输出验证报告。如果通过工作流继续如果失败报告会包含错误类型和可能出错的步骤并将问题反馈给上游的Planner或Parameter Agent进行自动重规划Re-planning。技术实现结合静态代码分析和一个容器化的、轻量级CAD内核如Open CASCADE的TKCAF模块来实现快速仿真。DRC规则用YAML文件配置易于扩展。Harness的核心价值就在于它优雅地管理了上述所有Agent的生命周期、执行顺序、数据传递和异常处理。它允许我们定义只有当NLU Agent成功输出计划后Parameter Agent才会启动Parameter Agent和CAD Command Agent可以并行处理多个独立特征Simulation Agent失败后可以自动触发一个预设的“修复子流程”或者通知人工干预。这种显式的、可视化的编排使得整个系统的可观测性、可调试性得到了质的提升。3. 多Agent协同下的30%准确率提升从何而来数字不会说谎30%的准确率提升是经过大量基准测试Benchmark验证的结果。这里的“准确率”我们定义为对于给定的自然语言描述系统能生成一个几何正确无错误、语义匹配符合描述、可直接用于下游流程如仿真、制造的3D模型的成功率。那么这30%具体是怎么来的3.1 分而治之带来的专业化红利这是最直接的收益。每个Agent只需要专注于一个相对狭窄的子任务因此我们可以用更精准的数据对它进行微调或设计更有效的提示工程。NLU Agent我们不再需要它懂CAD API语法只需全力提升其从工程语言中提取意图和结构的能力。我们使用了大量公开的工程图纸说明书和维修手册进行微调使其对“沉头孔”、“退刀槽”、“加强筋”等术语的理解远超通用大模型。CAD Command Agent它的输入是干净的、结构化的参数描述因此生成正确API代码的任务变得像“翻译”一样直接。我们为不同CAD软件准备了高质量的“描述-代码”配对数据集训练出的模型在代码生成准确率上比单Agent时代提高了40%以上。这种专业化避免了“知识干扰”。在单Agent中关于“螺纹标注规范”的知识可能会干扰它对“草图轮廓”的判断。在多Agent中这些知识被隔离在相应的Agent里各司其职。3.2 闭环验证与自动纠错机制在单Agent流程中生成即结束对错全靠最终输出结果判断调试是黑盒。而在Harness编排的多Agent流程中我们嵌入了多个验证和反馈环节形成了设计闭环。参数Agent的初步校验在规划阶段就进行基本的几何可行性检查提前过滤掉约15%的明显不可能实现的描述如“在厚度5mm的板上开一个直径10mm的盲孔深度8mm”。仿真Agent的最终把关这是拦截错误的最重要防线。我们统计发现约有25%的首次生成指令会在仿真环节暴露出问题例如特征重建失败、约束冲突导致模型过定义等。在单Agent方案中这些问题会导致直接失败。但现在Harness可以依据错误类型启动不同的修复策略局部重试如果是某个特征如倒角失败可以只让CAD Command Agent重新生成该特征的指令。参数调整如果是因为尺寸干涉可以反馈给Parameter Agent让其在一个合理范围内微调参数例如将孔距边缘的距离从2mm调整为2.5mm然后重新生成指令。计划重构如果是根本性的顺序错误则将错误信息反馈给Planner Agent让其重新规划步骤顺序。 这个“生成-验证-反馈-再生成”的循环将很多原本会导致整体失败的错误转化为了可以自动修复的局部问题这是提升整体成功率的关键。3.3 复杂任务处理能力的质变对于简单任务如“创建一个长方体”单Agent和多Agent的差距可能不大。但当任务复杂度提升时多Agent的优势呈指数级放大。场景一包含条件逻辑的描述。“如果孔径大于10mm则添加一个环形加强筋否则直接打孔。”单Agent需要在一个生成步骤内理解和执行这个“if-else”逻辑容易出错。而在我们的工作流中这很自然Parameter Agent解析出孔径参数Harness根据该参数值如12mm决定下一步是流向“生成加强筋孔”的子流程还是直接流向“生成简单孔”的子流程。工作流本身成为了逻辑的载体。场景二多实体与装配关系。“创建两个法兰盘并用六颗螺栓将它们连接起来。”这涉及多个独立零件法兰盘、螺栓和它们之间的装配关系同心、重合、螺栓配合。单Agent几乎无法一次性正确处理。多Agent方案则可以Planner Agent将其分解为创建法兰盘A、创建法兰盘B、创建螺栓、创建装配体四个主要阶段。前三个阶段可以并行处理最后由一个专门的“装配关系Agent”来添加配合约束。Harness负责协调这些并行和串行任务。正是这些复杂场景的成功处理将我们的平均准确率从原来的不足70%提升到了现在的90%以上实现了30%的绝对提升。4. 实战踩坑从理想架构到稳定落地的挑战架构很美好但落地过程充满了“坑”。多Agent系统不是简单的112协调成本、新的故障模式都会出现。以下是我们在HiCAD 3.0开发中遇到的核心挑战及解决方案。4.1 Agent间通信与数据格式的“巴别塔”问题每个Agent可能由不同的团队开发使用不同的内部数据表示。NLU Agent可能输出JSONParameter Agent习惯用Protobuf而某个旧版的分析库只接受XML。如果让它们直接通信会是一场灾难。我们的解决方案在Harness中我们定义了统一的、强类型的内部数据交换格式IDL。我们使用Protocol Buffers来定义所有Agent之间传递的消息结构。例如FeatureMessage会明确定义特征类型、参数列表、依赖关系等字段。每个Agent的输入输出都必须遵守这个协议。Harness负责序列化和反序列化。这相当于为所有Agent建立了“普通话”标准彻底消除了格式歧义带来的错误。4.2 错误处理与工作流回退的复杂性在单链式中错误处理相对简单失败了就报错。但在多Agent、有分支有循环的工作流中一个节点的失败该如何处理是重试当前节点还是回退到上游某个检查点还是启动一个备用的修复流程我们的解决方案利用Harness的状态机和补偿事务Saga模式。我们为工作流中的每个关键步骤定义了“检查点”。当某个Agent失败时Harness会根据错误码和预设策略决定下一步动作。例如瞬时错误如网络超时自动重试最多3次。逻辑错误如参数无解向上游回滚到Parameter Agent并附带错误信息触发其重新计算。严重错误如内核崩溃回滚到整个工作流的起点并标记任务为“需人工干预”同时保存当前所有中间状态供工程师调试。 我们为每种错误类型编写了对应的“补偿操作”例如如果CAD指令生成失败补偿操作是清理掉已创建的部分临时几何体防止残留数据影响重试。4.3 系统延迟与性能开销的权衡每增加一个Agent就增加一次网络调用、一次数据序列化/反序列化、一次上下文切换。如果设计不当系统延迟会急剧上升。我们的解决方案Agent轻量化与本地化不是所有Agent都必须是大模型。像参数计算、简单规则校验这类Agent我们用更轻量的规则引擎或小型模型实现并尽可能与主服务部署在同一台机器或同一个Pod内减少网络延迟。异步执行与并行化Harness支持任务的异步执行。对于没有依赖关系的Agent例如解析一个模型上彼此独立的多个特征我们让它们并行运行充分利用多核资源。缓存机制对于一些耗时的公共计算如标准件库查询、常用材料属性获取我们引入了分布式缓存Redis。多个工作流实例可以共享缓存结果避免重复计算。监控与 profiling我们建立了详细的性能监控追踪每个Agent、每次调用的耗时。通过持续的性能剖析Profiling我们找到了几个性能瓶颈比如某个几何校验算法复杂度太高后来我们将其替换为更高效的近似算法。4.4 对“未知描述”的鲁棒性提升用户的需求是天马行空的总会遇到训练数据中未覆盖的描述。单Agent模型可能会“胡言乱语”或生成完全错误的模型。多Agent架构在这里提供了一个防御层。我们的实践我们在工作流中增加了一个“置信度评估”环节。每个Agent在处理完自己的任务后都需要输出一个置信度分数。例如NLU Agent如果遇到完全不认识的术语它的置信度会很低。Harness会监控这些分数。如果多个Agent的置信度都低于阈值系统不会强行执行到底生成一个可能错误的模型而是会提前优雅降级例如转而生成一个基于理解部分所创建的、不完整的模型并高亮标出无法处理的部分同时向用户发起澄清式提问“您提到的‘涡流发生器’具体是指哪种几何形状能否提供更多描述或参考图片”。这比生成一个垃圾模型然后让用户失望要好得多。5. 给后来者的实践建议与未来展望从HiCAD 2.0的单体架构升级到3.0的多Agent编排系统是一个充满挑战但回报丰厚的旅程。如果你也在考虑为你的复杂任务系统引入多Agent架构以下是我们用真金白银换来的几点核心建议1. 不要为了多Agent而多Agent。首先问自己你的任务是否真的可以清晰地分解为多个职责分明、相对独立的子任务子任务之间是否存在标准的、结构化的数据接口如果任务本身是高度混沌、难以拆解的强行拆分只会增加复杂度。对于3D建模、代码生成、数据分析流水线这类结构化任务多Agent是利器对于创意写作、开放域对话可能就需要更谨慎。2. 编排框架的选择至关重要它决定了系统的“韧性”。不要只关注框架是否能“跑起来”要深入考察它的错误处理能力、状态管理、监控指标、调试工具是否完善。Harness之所以适合我们是因为它的工作流定义非常直观且对失败处理和重试有强大的原生支持。在选型时务必用你们最复杂的故障场景去测试候选框架。3. 统一的数据契约是生命线。在开发第一个Agent之前先花时间定义好Agent之间通信的数据格式。使用像Protobuf、Avro这类支持版本化和强类型的工具。这会在后续的集成、测试和扩展中节省你无数的时间避免“接口地狱”。4. 投资于可观测性Observability。多Agent系统的调试比单体系统困难得多。一个任务的失败可能是A Agent的bug也可能是B Agent的输出不符合C Agent的预期或者是编排逻辑本身有误。必须为每个Agent调用、每一次数据传递、每一个工作流状态变更都打上详细的日志和追踪Trace。我们集成了OpenTelemetry可以清晰地看到一个用户请求在所有Agent间的完整流转路径和耗时这对于定位问题不可或缺。5. 建立端到端的测试流水线。单元测试测试单个Agent很重要但还不够。必须建立覆盖完整工作流的集成测试和回归测试套件。准备一批涵盖各种复杂度的测试用例从简单方块到复杂装配体每次代码更新后都自动运行监控准确率和性能指标的变化。这能有效防止“修复一个bug引入两个新bug”的情况。关于未来我们正在探索几个方向动态Agent编排目前的工作流是预先定义好的。未来我们希望系统能根据任务的实时复杂度和可用计算资源动态地决定是否启动某个Agent比如简单任务可能跳过仿真验证环节或者选择不同能力的Agent实例比如在GPU资源紧张时使用轻量版模型Agent实现更智能的资源调度。Agent的持续学习每个Agent在运行中都会遇到新的成功或失败案例。我们计划建立一个反馈循环让这些案例能够被安全地收集、标注并用于定期微调对应的Agent让系统在实际使用中越用越聪明。人机协同闭环当前系统在遇到低置信度时主要向用户提问。我们正在设计更丰富的人机交互方式例如允许用户在生成的中间结果如草图上直接进行图形化修改系统则学习这种修改并尝试更新后续的Agent决策。让AI处理routine work人类专家专注于高层次的创意和纠偏这才是人机协同的理想状态。放弃单Agent拥抱多Agent编排对我们而言不是一个轻松的决定但它让我们跳出了模型能力增长的线性竞争转向了系统架构带来的系统性红利。这30%的准确率提升不仅仅是数字的变化更代表着我们让AI更可靠地处理复杂现实任务的能力迈上了一个新的台阶。这条路还在继续坑还会有但风景已然不同。 从单Agent到多Agent编排：AI驱动3D建模的架构演进与30%准确率提升实践
1. 从单Agent到多Agent我们为何要“放弃”在AI驱动的3D建模领域单Agent方案曾是我们的起点也是很多团队的舒适区。一个模型一个任务逻辑清晰调试简单。我们早期的HiCAD 2.0版本就是典型的单Agent架构输入一段自然语言描述比如“设计一个带圆角的长方体底座上面有一个圆柱形支柱”模型会尝试理解并直接生成对应的3D建模指令序列。听起来很美好对吧但实际跑起来准确率就像过山车时高时低尤其是在处理复杂、多约束的建模任务时成功率很难稳定突破70%。问题出在哪里我们花了大量时间复盘。一个核心发现是3D建模是一个高度结构化、多步骤、强逻辑依赖的复合任务。它不像图像生成那样是“一锤子买卖”。一个简单的杯子就包含了草图绘制、轮廓约束、拉伸/旋转成型、倒角/圆角处理、抽壳等多个子步骤。让一个“全能型”Agent去同时处理几何理解、空间关系推理、参数计算、操作顺序规划就像让一个程序员同时写前端、后端、算法和运维脚本虽然可能有人能做到但效率和出错率是硬伤。具体来说单Agent方案的瓶颈体现在三个层面注意力分散与任务混淆模型在理解“创建一个半径为50mm高度为100mm的圆柱并在其一端创建一个深10mm的M6螺纹孔”时需要同时识别几何实体圆柱、参数半径、高度、布尔操作打孔、以及特定工艺特征螺纹。在生成长序列指令时模型很容易在某个环节“分心”例如把螺纹孔的深度参数错误地关联到圆柱高度上或者忘记了先执行“打孔”再执行“螺纹”的顺序。错误传播与累积3D建模步骤环环相扣。第一步草图绘制如果定位有1mm的偏差后续所有基于此草图的特征都会放大这个错误。单Agent方案一旦在早期产生一个细微的误解这个错误会像滚雪球一样贯穿整个生成过程导致最终模型完全偏离预期且调试起来异常困难你很难定位是哪个“思维环节”出了错。专业知识难以深度融合3D建模涉及大量领域知识如工程制图标准、制造工艺约束最小壁厚、拔模角、装配关系等。我们希望HiCAD不止能“画出来”还要能“画得对”、“画得好”。试图将所有专业知识压缩进一个模型的提示词Prompt或通过微调让一个模型掌握全部会导致知识冲突和遗忘模型表现会变得不稳定。所以“放弃”单Agent不是否定其价值而是在特定问题复杂度下的必然选择。当任务可以被清晰地分解为多个专业子任务且子任务间存在明确的输入输出关系时多Agent分工协作的架构优势就凸显出来了。这就像从“手工作坊”升级到“现代化流水线”每个工位Agent只专注于自己最擅长的环节通过一套精密的调度系统编排框架串联起来最终实现效率与质量的跃升。2. HiCAD 3.0 的核心架构Harness 如何扮演“总指挥”确定了多Agent的方向下一个关键问题是如何让多个Agent高效、可靠地协同工作这就是引入编排Orchestration框架的必要性。我们评估了多个方案最终选择了Harness作为HiCAD 3.0的“中央神经系统”。它不是唯一的选项但它的设计哲学与我们的需求高度契合。为什么是Harness市面上常见的多Agent协作模式有基于LangChain的简单链式调用或者更复杂的AutoGen等框架。Harness吸引我们的核心在于它对复杂工作流Workflow的原生支持和对状态管理的精细化控制。LangChain更适合构建清晰的、顺序执行的链Chain但在处理3D建模这种带有大量条件分支“如果这里是通孔则...否则...”、循环“阵列这个特征5次”以及异常回退“上一步布尔运算失败尝试替代方案”的场景时表达起来会显得笨拙代码可读性和可维护性下降。AutoGen提供了强大的多Agent对话能力但对于需要严格步骤控制、结构化数据传递的生产级任务流其对话式的松散耦合有时会引入不确定性。Harness则采用了“工作流即代码”的理念。它将整个3D建模任务定义为一个有向无环图DAG图中的每个节点是一个专业化Agent边代表了数据流和依赖关系。这让我们可以直观地设计和监控整个建模过程。HiCAD 3.0 的Harness工作流设计在我们的架构中一个典型的建模工作流被分解为以下几个核心Agent节点2.1 自然语言理解与任务规划 Agent (NLU Planner Agent)这是工作流的起点。它接收用户的自然语言描述例如“请设计一个连接板中间有一个φ20的通孔四角有4个φ8的沉头孔用于安装板材厚度10mm。”职责进行深度语义解析识别出所有几何实体、尺寸参数、约束关系同心、平行等、特征类型拉伸、切除、孔、倒角等以及工艺要求通孔、沉头。输出一个结构化的任务计划清单。这个清单不是最终的CAD命令而是一个高级别的、顺序化的操作列表。例如创建基准面Top Plane。在该面上绘制一个矩形草图长宽待参数Agent确定完全定义。拉伸草图厚度10mm生成基体。在基体上表面中心创建草图点生成φ20的通孔特征。在基体四角创建草图点生成φ8的沉头孔特征深度、角度待参数Agent确定。技术实现我们基于微调后的Code Llama或DeepSeek-Coder构建此Agent重点强化其对于工程图纸语言的理解能力和步骤分解的逻辑性。2.2 几何与参数解析 Agent (Geometry Parameter Agent)这个Agent接收任务计划清单。它的核心工作是“填空”将模糊的描述转化为精确的、可计算的数值和几何关系。职责参数计算如果用户说“四角有4个孔”它会根据矩形板的尺寸自动计算出四个角点的精确坐标。如果用户说“沉头孔”它会根据标准件库或默认规则补充出沉头直径、深度、角度等未明说的参数。约束推理“中间的孔”会被解析为与矩形中心同心约束。“用于安装的孔”可能会被自动添加“螺纹”或“过盈配合”的标记传递给下游Agent。几何可行性检查初步判断参数是否合理例如孔的直径是否大于板厚导致无法生成通孔。输出一个参数化、完全定义的草图与特征描述集。每个草图都有确定的尺寸、每个特征都有明确的类型和参数。技术实现这个Agent集成了符号计算和几何推理引擎。我们使用了OpenCASCADE的内核进行一些底层的几何关系验证同时用一个轻量级的规则引擎来处理参数推理逻辑。2.3 CAD 指令生成 Agent (CAD Command Agent)这是将抽象计划转化为具体行动的关键环节。它接收参数化描述集。职责根据目标CAD平台如SolidWorks, Fusion 360, Onshape API生成对应的、可执行的API调用序列或脚本如Python宏。输出一段针对特定CAD软件的、无歧义的指令代码。例如对于Fusion 360可能是调用adsk.fusionAPI创建草图、绘制矩形、添加尺寸约束、执行拉伸命令的Python脚本。技术实现我们为每个支持的CAD平台训练了一个专门的代码生成模型。这个模型的训练数据是“参数化描述”到“CAD API代码”的配对数据。由于输入已经是结构化的大大降低了代码生成的难度和错误率。2.4 仿真验证与优化 Agent (Simulation Validation Agent)这是我们的“质量检查员”。在指令生成后、正式提交给CAD软件前它会被触发。职责语法与逻辑校验检查生成的代码是否有语法错误API调用顺序是否合理。轻量级几何验证通过调用一个“无头模式”Headless的CAD内核或简化仿真器快速执行生成的指令检查是否能成功生成实体是否存在自相交、零厚度等几何错误。设计规则检查DRC验证模型是否符合预设的规则如最小壁厚、最小孔径、是否存在锐边等。输出验证报告。如果通过工作流继续如果失败报告会包含错误类型和可能出错的步骤并将问题反馈给上游的Planner或Parameter Agent进行自动重规划Re-planning。技术实现结合静态代码分析和一个容器化的、轻量级CAD内核如Open CASCADE的TKCAF模块来实现快速仿真。DRC规则用YAML文件配置易于扩展。Harness的核心价值就在于它优雅地管理了上述所有Agent的生命周期、执行顺序、数据传递和异常处理。它允许我们定义只有当NLU Agent成功输出计划后Parameter Agent才会启动Parameter Agent和CAD Command Agent可以并行处理多个独立特征Simulation Agent失败后可以自动触发一个预设的“修复子流程”或者通知人工干预。这种显式的、可视化的编排使得整个系统的可观测性、可调试性得到了质的提升。3. 多Agent协同下的30%准确率提升从何而来数字不会说谎30%的准确率提升是经过大量基准测试Benchmark验证的结果。这里的“准确率”我们定义为对于给定的自然语言描述系统能生成一个几何正确无错误、语义匹配符合描述、可直接用于下游流程如仿真、制造的3D模型的成功率。那么这30%具体是怎么来的3.1 分而治之带来的专业化红利这是最直接的收益。每个Agent只需要专注于一个相对狭窄的子任务因此我们可以用更精准的数据对它进行微调或设计更有效的提示工程。NLU Agent我们不再需要它懂CAD API语法只需全力提升其从工程语言中提取意图和结构的能力。我们使用了大量公开的工程图纸说明书和维修手册进行微调使其对“沉头孔”、“退刀槽”、“加强筋”等术语的理解远超通用大模型。CAD Command Agent它的输入是干净的、结构化的参数描述因此生成正确API代码的任务变得像“翻译”一样直接。我们为不同CAD软件准备了高质量的“描述-代码”配对数据集训练出的模型在代码生成准确率上比单Agent时代提高了40%以上。这种专业化避免了“知识干扰”。在单Agent中关于“螺纹标注规范”的知识可能会干扰它对“草图轮廓”的判断。在多Agent中这些知识被隔离在相应的Agent里各司其职。3.2 闭环验证与自动纠错机制在单Agent流程中生成即结束对错全靠最终输出结果判断调试是黑盒。而在Harness编排的多Agent流程中我们嵌入了多个验证和反馈环节形成了设计闭环。参数Agent的初步校验在规划阶段就进行基本的几何可行性检查提前过滤掉约15%的明显不可能实现的描述如“在厚度5mm的板上开一个直径10mm的盲孔深度8mm”。仿真Agent的最终把关这是拦截错误的最重要防线。我们统计发现约有25%的首次生成指令会在仿真环节暴露出问题例如特征重建失败、约束冲突导致模型过定义等。在单Agent方案中这些问题会导致直接失败。但现在Harness可以依据错误类型启动不同的修复策略局部重试如果是某个特征如倒角失败可以只让CAD Command Agent重新生成该特征的指令。参数调整如果是因为尺寸干涉可以反馈给Parameter Agent让其在一个合理范围内微调参数例如将孔距边缘的距离从2mm调整为2.5mm然后重新生成指令。计划重构如果是根本性的顺序错误则将错误信息反馈给Planner Agent让其重新规划步骤顺序。 这个“生成-验证-反馈-再生成”的循环将很多原本会导致整体失败的错误转化为了可以自动修复的局部问题这是提升整体成功率的关键。3.3 复杂任务处理能力的质变对于简单任务如“创建一个长方体”单Agent和多Agent的差距可能不大。但当任务复杂度提升时多Agent的优势呈指数级放大。场景一包含条件逻辑的描述。“如果孔径大于10mm则添加一个环形加强筋否则直接打孔。”单Agent需要在一个生成步骤内理解和执行这个“if-else”逻辑容易出错。而在我们的工作流中这很自然Parameter Agent解析出孔径参数Harness根据该参数值如12mm决定下一步是流向“生成加强筋孔”的子流程还是直接流向“生成简单孔”的子流程。工作流本身成为了逻辑的载体。场景二多实体与装配关系。“创建两个法兰盘并用六颗螺栓将它们连接起来。”这涉及多个独立零件法兰盘、螺栓和它们之间的装配关系同心、重合、螺栓配合。单Agent几乎无法一次性正确处理。多Agent方案则可以Planner Agent将其分解为创建法兰盘A、创建法兰盘B、创建螺栓、创建装配体四个主要阶段。前三个阶段可以并行处理最后由一个专门的“装配关系Agent”来添加配合约束。Harness负责协调这些并行和串行任务。正是这些复杂场景的成功处理将我们的平均准确率从原来的不足70%提升到了现在的90%以上实现了30%的绝对提升。4. 实战踩坑从理想架构到稳定落地的挑战架构很美好但落地过程充满了“坑”。多Agent系统不是简单的112协调成本、新的故障模式都会出现。以下是我们在HiCAD 3.0开发中遇到的核心挑战及解决方案。4.1 Agent间通信与数据格式的“巴别塔”问题每个Agent可能由不同的团队开发使用不同的内部数据表示。NLU Agent可能输出JSONParameter Agent习惯用Protobuf而某个旧版的分析库只接受XML。如果让它们直接通信会是一场灾难。我们的解决方案在Harness中我们定义了统一的、强类型的内部数据交换格式IDL。我们使用Protocol Buffers来定义所有Agent之间传递的消息结构。例如FeatureMessage会明确定义特征类型、参数列表、依赖关系等字段。每个Agent的输入输出都必须遵守这个协议。Harness负责序列化和反序列化。这相当于为所有Agent建立了“普通话”标准彻底消除了格式歧义带来的错误。4.2 错误处理与工作流回退的复杂性在单链式中错误处理相对简单失败了就报错。但在多Agent、有分支有循环的工作流中一个节点的失败该如何处理是重试当前节点还是回退到上游某个检查点还是启动一个备用的修复流程我们的解决方案利用Harness的状态机和补偿事务Saga模式。我们为工作流中的每个关键步骤定义了“检查点”。当某个Agent失败时Harness会根据错误码和预设策略决定下一步动作。例如瞬时错误如网络超时自动重试最多3次。逻辑错误如参数无解向上游回滚到Parameter Agent并附带错误信息触发其重新计算。严重错误如内核崩溃回滚到整个工作流的起点并标记任务为“需人工干预”同时保存当前所有中间状态供工程师调试。 我们为每种错误类型编写了对应的“补偿操作”例如如果CAD指令生成失败补偿操作是清理掉已创建的部分临时几何体防止残留数据影响重试。4.3 系统延迟与性能开销的权衡每增加一个Agent就增加一次网络调用、一次数据序列化/反序列化、一次上下文切换。如果设计不当系统延迟会急剧上升。我们的解决方案Agent轻量化与本地化不是所有Agent都必须是大模型。像参数计算、简单规则校验这类Agent我们用更轻量的规则引擎或小型模型实现并尽可能与主服务部署在同一台机器或同一个Pod内减少网络延迟。异步执行与并行化Harness支持任务的异步执行。对于没有依赖关系的Agent例如解析一个模型上彼此独立的多个特征我们让它们并行运行充分利用多核资源。缓存机制对于一些耗时的公共计算如标准件库查询、常用材料属性获取我们引入了分布式缓存Redis。多个工作流实例可以共享缓存结果避免重复计算。监控与 profiling我们建立了详细的性能监控追踪每个Agent、每次调用的耗时。通过持续的性能剖析Profiling我们找到了几个性能瓶颈比如某个几何校验算法复杂度太高后来我们将其替换为更高效的近似算法。4.4 对“未知描述”的鲁棒性提升用户的需求是天马行空的总会遇到训练数据中未覆盖的描述。单Agent模型可能会“胡言乱语”或生成完全错误的模型。多Agent架构在这里提供了一个防御层。我们的实践我们在工作流中增加了一个“置信度评估”环节。每个Agent在处理完自己的任务后都需要输出一个置信度分数。例如NLU Agent如果遇到完全不认识的术语它的置信度会很低。Harness会监控这些分数。如果多个Agent的置信度都低于阈值系统不会强行执行到底生成一个可能错误的模型而是会提前优雅降级例如转而生成一个基于理解部分所创建的、不完整的模型并高亮标出无法处理的部分同时向用户发起澄清式提问“您提到的‘涡流发生器’具体是指哪种几何形状能否提供更多描述或参考图片”。这比生成一个垃圾模型然后让用户失望要好得多。5. 给后来者的实践建议与未来展望从HiCAD 2.0的单体架构升级到3.0的多Agent编排系统是一个充满挑战但回报丰厚的旅程。如果你也在考虑为你的复杂任务系统引入多Agent架构以下是我们用真金白银换来的几点核心建议1. 不要为了多Agent而多Agent。首先问自己你的任务是否真的可以清晰地分解为多个职责分明、相对独立的子任务子任务之间是否存在标准的、结构化的数据接口如果任务本身是高度混沌、难以拆解的强行拆分只会增加复杂度。对于3D建模、代码生成、数据分析流水线这类结构化任务多Agent是利器对于创意写作、开放域对话可能就需要更谨慎。2. 编排框架的选择至关重要它决定了系统的“韧性”。不要只关注框架是否能“跑起来”要深入考察它的错误处理能力、状态管理、监控指标、调试工具是否完善。Harness之所以适合我们是因为它的工作流定义非常直观且对失败处理和重试有强大的原生支持。在选型时务必用你们最复杂的故障场景去测试候选框架。3. 统一的数据契约是生命线。在开发第一个Agent之前先花时间定义好Agent之间通信的数据格式。使用像Protobuf、Avro这类支持版本化和强类型的工具。这会在后续的集成、测试和扩展中节省你无数的时间避免“接口地狱”。4. 投资于可观测性Observability。多Agent系统的调试比单体系统困难得多。一个任务的失败可能是A Agent的bug也可能是B Agent的输出不符合C Agent的预期或者是编排逻辑本身有误。必须为每个Agent调用、每一次数据传递、每一个工作流状态变更都打上详细的日志和追踪Trace。我们集成了OpenTelemetry可以清晰地看到一个用户请求在所有Agent间的完整流转路径和耗时这对于定位问题不可或缺。5. 建立端到端的测试流水线。单元测试测试单个Agent很重要但还不够。必须建立覆盖完整工作流的集成测试和回归测试套件。准备一批涵盖各种复杂度的测试用例从简单方块到复杂装配体每次代码更新后都自动运行监控准确率和性能指标的变化。这能有效防止“修复一个bug引入两个新bug”的情况。关于未来我们正在探索几个方向动态Agent编排目前的工作流是预先定义好的。未来我们希望系统能根据任务的实时复杂度和可用计算资源动态地决定是否启动某个Agent比如简单任务可能跳过仿真验证环节或者选择不同能力的Agent实例比如在GPU资源紧张时使用轻量版模型Agent实现更智能的资源调度。Agent的持续学习每个Agent在运行中都会遇到新的成功或失败案例。我们计划建立一个反馈循环让这些案例能够被安全地收集、标注并用于定期微调对应的Agent让系统在实际使用中越用越聪明。人机协同闭环当前系统在遇到低置信度时主要向用户提问。我们正在设计更丰富的人机交互方式例如允许用户在生成的中间结果如草图上直接进行图形化修改系统则学习这种修改并尝试更新后续的Agent决策。让AI处理routine work人类专家专注于高层次的创意和纠偏这才是人机协同的理想状态。放弃单Agent拥抱多Agent编排对我们而言不是一个轻松的决定但它让我们跳出了模型能力增长的线性竞争转向了系统架构带来的系统性红利。这30%的准确率提升不仅仅是数字的变化更代表着我们让AI更可靠地处理复杂现实任务的能力迈上了一个新的台阶。这条路还在继续坑还会有但风景已然不同。