1. 从一句行业调侃说起为什么“做Agent的最先死”“做Agent的最先死”这句话最近在技术圈里流传得挺广。乍一听像是唱衰但仔细琢磨它说的其实不是Agent这个方向不行而是当前一大批Agent项目的落地方式有问题。我接触过不少团队拿着大模型API套个壳加几个工具调用就宣称自己做了个“智能体”结果一上生产环境就露馅——任务稍微复杂一点就胡言乱语工具调用参数错得离谱多轮对话超过五轮就开始遗忘上下文。这类项目不死谁死但这句话还有后半句才是真正值得聊的“但国产SolidWorks的机会来了”。这两件事放在一起乍看风马牛不相及一个是AI Agent一个是工业软件。可如果你对这两个领域都有一定了解就会发现它们之间有一条非常清晰的逻辑链Agent的落地困境恰恰暴露了通用大模型在专业垂直领域的短板而补上这个短板的方式就是让Agent真正“懂”某个专业工具——比如CAD比如SolidWorks。我做了几年AI应用落地也跟过几个工业软件相关的项目对这个话题有一些自己的观察。这篇文章不打算空谈趋势而是想把“Agent为什么会死”“国产CAD工具的机会到底在哪”“一个真正能用的工程Agent该怎么搭”这几个问题拆开来讲清楚。不管你是做AI应用的开发者还是工业软件领域的从业者或者只是对这两个方向的交叉感兴趣应该都能从中拿到一些能直接参考的东西。提示本文讨论的“Agent”泛指基于大语言模型构建的、具备工具调用和任务规划能力的智能体系统“国产SolidWorks”泛指国产三维CAD设计软件。全文基于公开技术资料和常见工程实践展开不涉及任何具体商业产品评价。2. Agent落地困境的根因拆解2.1 通用Agent的“三宗罪”先说说我观察到的通用Agent项目最常见的三个死法。第一宗罪工具调用不可靠。大模型调用外部工具本质上是一个“自然语言到结构化参数”的映射过程。你让它“把那个零件往右移5毫米”它得先知道“那个零件”是哪个再知道“右”是哪个坐标系方向最后把5毫米转成软件API能接受的参数格式。任何一环出错整个任务就崩了。我实测过某主流模型在CAD场景下的工具调用准确率简单任务如“创建一个长方体”大概能到85%左右但一旦涉及多步骤组合操作准确率直接掉到40%以下。第二宗罪领域知识缺失。通用大模型训练数据里CAD相关的专业语料占比极低。你问它“这个装配体的自由度是多少”它可能会给你一段听起来很专业但完全错误的回答。更麻烦的是它不知道自己不知道——这种“自信的错误”在工程场景里是致命的。第三宗罪状态管理混乱。工程设计是一个有状态的过程。你画了一条线这条线就存在于当前草图里你拉伸了一个特征这个特征就挂在特征树上。通用Agent往往缺乏对这类“工程状态”的建模能力导致它在多轮交互中反复“失忆”或者做出与当前状态矛盾的操作。2.2 为什么“套壳Agent”活不下来很多团队做Agent的思路是找一个强的大模型写一套工具调用的prompt再配一个向量数据库做知识检索就上线了。这套方案在Demo阶段看起来很美好但一上真实场景就崩。原因很简单通用能力不等于专业能力。打个比方这就像你招了一个名校毕业但完全没学过机械设计的应届生让他直接上手做产品设计。他可能很聪明学习能力很强但你让他独立完成一个复杂的装配体设计他大概率会搞砸。Agent也是一样通用大模型就是那个“聪明但不懂行”的应届生。那怎么办两条路要么让这个“应届生”去系统学习机械设计知识领域微调要么给他配一个“老师傅”随时指导专业工具知识库。而后者恰恰是国产CAD工具的机会所在。2.3 从“通用”到“专用”的必然转向我个人的判断是Agent的发展正在经历一个从“通用”到“专用”的转向。早期大家追求的是“一个Agent什么都能干”现在越来越多人意识到在垂直领域里把一个Agent做深做透价值远大于做一个什么都会但什么都不精的通用Agent。这个转向对工业软件领域意味着什么意味着Agent需要与专业工具深度耦合。不是简单地调用几个API而是要让Agent真正理解工具的数据模型、操作逻辑和约束条件。而要做到这一点工具本身必须足够开放、足够可定制——这恰恰是国产CAD工具可以发力的地方。3. 国产CAD工具的机会窗口在哪3.1 传统CAD巨头的“封闭性”困境传统CAD巨头经过几十年的发展功能确实强大生态也确实完善。但它们的封闭性也是出了名的。你想在它们的平台上做深度定制开发门槛高、限制多、成本大。想接入自己的AI能力对不起API不开放或者开放的那部分根本不够用。我认识一个做工程AI的团队他们想在一个主流CAD软件上做一个智能装配功能结果发现能调用的API只覆盖了不到30%的核心操作。剩下的70%要么得用脚本模拟鼠标键盘操作极其不稳定要么根本做不了。这种封闭性在AI时代是致命的。3.2 国产工具的“后发优势”国产CAD工具起步晚这是劣势但在AI时代反而成了优势。为什么因为没有历史包袱。传统巨头的代码库可能比很多开发者的年龄都大架构陈旧改造成本极高。而国产工具大多是近十年内从头构建的架构更现代更容易做模块化设计和API开放。更重要的是国产工具厂商更愿意与AI团队合作——他们需要差异化竞争而AI恰恰是一个很好的差异化点。我了解到的一些国产CAD项目已经在做这样的事情把核心几何引擎和操作接口做成标准化的API让AI Agent可以直接调用同时提供领域知识库的接入能力让Agent能够理解工程语义。这种“工具AI”的深度耦合在传统巨头那里是很难想象的。3.3 机会窗口的时间判断这个窗口期有多长我的判断是两到三年。理由有三第一大模型在专业领域的能力提升速度很快。现在通用模型在CAD场景下表现不好但一年后呢两年后呢如果通用模型自己就能把CAD操作做得很好那国产工具的机会窗口就关了。第二传统巨头不会坐视不理。它们也在做AI只是船大难掉头。一旦它们完成转身凭借生态优势国产工具很难正面竞争。第三用户习惯的迁移需要时间。工程师从用惯了的工具切换到新工具成本很高。这个迁移窗口期不会太长。所以如果国产CAD工具想抓住这波机会现在就得动起来。4. 一个可落地的工程Agent架构设计4.1 整体架构思路说了这么多“为什么”接下来聊聊“怎么做”。我基于自己的项目经验设计了一套面向CAD场景的工程Agent架构。这套架构的核心思路是不让大模型直接操作CAD而是让大模型做“翻译”和“规划”把自然语言指令转成结构化的操作序列再由一个确定性的执行引擎去调用CAD的API。这样做的好处是大模型只负责它擅长的部分理解意图、规划步骤而把精确的几何计算和状态管理交给确定性代码。即使大模型偶尔出错执行引擎也能通过校验机制拦截大部分问题。架构上分为四层交互层接收用户的自然语言指令返回执行结果和状态反馈。规划层大模型在这里工作把用户指令拆解成操作序列并调用知识库补充领域信息。执行层确定性代码负责把操作序列转成CAD API调用并管理工程状态。工具层CAD软件本身提供几何建模、装配、出图等核心能力。4.2 核心模块拆解意图理解模块。这个模块的任务是把用户的自然语言转成结构化的意图表示。比如用户说“在这个面上打一个直径10毫米、深5毫米的孔”意图表示可能是{action: create_hole, target_face: 面ID, diameter: 10, depth: 5}。这里的关键是实体链接——得知道“这个面”指的是哪个面。我的做法是维护一个当前工程状态的“上下文快照”把用户可能指代的实体都列出来让大模型做选择。任务规划模块。复杂指令需要拆解成多个步骤。比如“做一个法兰盘”可能需要创建圆柱体→创建中心孔→创建螺栓孔阵列→倒角。这个拆解过程由大模型完成但拆解结果需要经过一个可行性校验——检查每一步的操作在当前状态下是否合法。比如在空草图里做拉伸校验就会拦截。知识检索模块。工程领域有大量标准件、材料参数、设计规范。这些知识不可能全部塞进大模型的上下文里需要用检索的方式按需获取。我的做法是建一个向量数据库把设计手册、标准件库、历史项目数据都索引进去Agent在规划时自动检索相关条目。执行引擎。这是整个架构里最“重”的部分。它需要把规划层输出的操作序列转成CAD软件能理解的API调用。这里有个关键设计每个操作都要有前置条件检查、执行、后置状态更新三个环节。前置条件检查确保操作合法执行调用API后置状态更新维护工程状态快照。这样即使某个操作失败也能回滚到之前的状态。4.3 关键设计决策的理由为什么不让大模型直接生成CAD脚本因为脚本的容错性太差。大模型生成的脚本哪怕只有一个参数错了整个脚本就废了。而操作序列的方式每一步都可以单独校验和重试。为什么需要状态快照因为工程操作是有依赖的。你不能在一个不存在的面上打孔也不能在一个已经被删除的特征上做修改。状态快照让Agent始终知道“当前有什么”避免做出矛盾的操作。为什么知识检索要用向量数据库而不是直接微调因为知识更新频率高。设计规范会变标准件库会更新微调的成本太高、周期太长。检索的方式可以做到知识的实时更新。5. 实操过程与核心环节实现5.1 环境准备与基础配置假设我们要搭建一个最小可用的工程Agent原型需要准备以下环境一台开发机建议16GB以上内存有独立显卡更好用于本地跑小模型做意图理解。Python 3.10环境主要依赖fastapi提供HTTP接口、pydantic数据校验、chromadb向量检索、openai或同类SDK调用大模型。一个支持API调用的CAD环境。这里假设我们有一个提供Python API的CAD工具核心接口包括create_sketch()、extrude()、create_hole()、get_face_by_id()等。配置上我建议把大模型调用和CAD操作分开部署。大模型调用可以走云端APICAD操作必须在本地执行因为CAD软件通常装在本地。两者之间通过一个消息队列或HTTP接口通信。5.2 意图理解模块的实现先定义一个Pydantic模型来表示操作意图from pydantic import BaseModel from typing import Optional, List class OperationIntent(BaseModel): action: str # 操作类型如 create_hole, extrude, fillet target: Optional[str] None # 目标实体ID params: dict {} # 操作参数 depends_on: List[int] [] # 依赖的前序操作索引然后写一个函数调用大模型把自然语言转成这个结构import json def parse_intent(user_input: str, context: dict) - OperationIntent: prompt f 当前工程状态{json.dumps(context, ensure_asciiFalse)} 用户指令{user_input} 请把用户指令转成JSON格式的操作意图包含action、target、params三个字段。 只输出JSON不要其他内容。 response call_llm(prompt) return OperationIntent(**json.loads(response))这里有个实操心得prompt里一定要把当前工程状态带上。否则大模型不知道“这个面”是哪个面只能瞎猜。我试过不带上下文的情况实体链接的准确率不到50%带上上下文后能到85%以上。5.3 任务规划与校验复杂指令需要拆解。我的做法是让大模型输出一个操作序列然后逐条校验def plan_and_validate(user_input: str, context: dict) - List[OperationIntent]: # 第一步让大模型拆解任务 plan_prompt f 当前工程状态{json.dumps(context, ensure_asciiFalse)} 用户指令{user_input} 请把指令拆解成一系列操作每个操作包含action、target、params。 输出JSON数组。 raw_plan json.loads(call_llm(plan_prompt)) operations [OperationIntent(**op) for op in raw_plan] # 第二步逐条校验 validated [] temp_context context.copy() for op in operations: if not check_precondition(op, temp_context): raise ValueError(f操作 {op.action} 的前置条件不满足) validated.append(op) temp_context apply_operation_to_context(op, temp_context) return validatedcheck_precondition函数需要针对每种操作类型写校验逻辑。比如create_hole需要检查目标面是否存在、孔径是否小于面尺寸等。这部分是纯确定性代码不涉及大模型。5.4 执行引擎与状态管理执行引擎的核心是一个循环取操作→检查前置条件→执行→更新状态。class ExecutionEngine: def __init__(self, cad_api, initial_context): self.cad cad_api self.context initial_context self.history [] # 用于回滚 def execute(self, operations: List[OperationIntent]): for op in operations: # 保存快照 self.history.append(self.context.copy()) try: # 前置检查 if not check_precondition(op, self.context): raise PreconditionError(op) # 执行 result self.dispatch(op) # 更新状态 self.context update_context(self.context, op, result) except Exception as e: # 回滚 self.context self.history.pop() raise ExecutionError(f操作 {op.action} 失败: {e}) def dispatch(self, op: OperationIntent): if op.action create_hole: return self.cad.create_hole( face_idop.target, diameterop.params[diameter], depthop.params[depth] ) elif op.action extrude: return self.cad.extrude( sketch_idop.target, distanceop.params[distance] ) # ... 其他操作这里的关键设计是回滚机制。工程操作往往是有副作用的一旦执行了一半失败不处理的话工程状态就乱了。我的做法是每次操作前保存状态快照失败就回滚。实测下来这个机制能避免90%以上的“状态污染”问题。5.5 知识检索的接入知识检索模块用向量数据库实现。先把设计手册、标准件参数等文档切片、向量化、存入数据库import chromadb client chromadb.Client() collection client.create_collection(engineering_knowledge) # 索引文档 documents load_design_manuals() # 加载设计手册 for doc in documents: collection.add( documents[doc[content]], metadatas[{source: doc[source], type: doc[type]}], ids[doc[id]] ) # 检索 def retrieve_knowledge(query: str, top_k: int 3): results collection.query(query_texts[query], n_resultstop_k) return results[documents][0]在任务规划时把检索到的知识拼进prompt里让大模型参考。比如用户说“做一个M8的螺栓孔”检索模块会返回M8螺栓孔的标准尺寸孔径6.8mm、沉头直径13mm等大模型就能把这些参数填进操作意图里。注意知识检索的top_k不要设太大3到5条就够了。太多会稀释关键信息反而降低大模型的判断准确率。我试过top_k10的情况效果比top_k3差不少。6. 常见问题与排查技巧实录6.1 大模型“胡说八道”怎么办这是最常见的问题。大模型可能会生成不存在的操作类型或者给出明显不合理的参数比如孔径大于零件尺寸。我的应对策略是双层校验第一层是格式校验用Pydantic模型做确保输出结构正确。第二层是语义校验用确定性代码检查参数是否在合理范围内。比如孔径不能大于目标面的最小边长拉伸距离不能为负数等。如果校验不通过不要让大模型“重试”而是直接把错误信息反馈给用户让用户确认或修正。我试过让大模型自动重试结果它经常在同一个错误上反复横跳浪费时间和token。6.2 多轮对话中的“失忆”问题Agent在多轮对话中容易忘记之前做了什么。我的解决方案是显式维护对话状态而不是依赖大模型的上下文窗口。具体做法是每轮对话结束后把关键信息用户意图、执行结果、当前工程状态摘要存到一个结构化的状态对象里下一轮对话开始时把这个状态对象注入prompt。这样即使对话轮次很多Agent也能准确知道“当前工程是什么状态”“之前做过哪些操作”。实测下来这个方案能让多轮对话的任务完成率提升30%以上。6.3 CAD API调用失败的排查CAD API调用失败的原因很多参数类型不对、实体ID失效、操作顺序错误等。我的排查流程是看错误信息CAD API通常会返回错误码和描述先看这个。检查前置条件确认操作的目标实体是否存在、是否处于可编辑状态。检查参数确认参数类型和取值范围是否符合API要求。检查状态确认当前工程状态是否与预期一致有没有被之前的操作意外修改。我整理了一个常见问题速查表问题现象可能原因排查方法解决方案API返回“实体不存在”实体ID失效或拼写错误检查上下文快照中的实体列表重新获取实体ID更新上下文操作执行后无效果参数类型错误或值为空打印实际传入的参数检查参数转换逻辑多步操作中途失败前序操作未正确完成检查每步的执行结果增加前置条件校验状态与预期不符状态更新逻辑有bug对比操作前后的状态快照修复状态更新函数大模型输出格式错误prompt不够明确检查prompt中的格式说明增加示例和格式约束6.4 性能优化的几个实操技巧Agent的响应速度直接影响用户体验。我总结的几个优化点缓存高频操作。像“创建一个标准螺栓孔”这种操作参数组合是有限的可以把结果缓存起来下次直接查缓存不用再走大模型。并行化知识检索和意图理解。这两个步骤没有依赖关系可以并行执行节省时间。限制操作序列长度。太长的操作序列不仅执行慢出错概率也高。我的做法是超过10步的任务就拆成多个子任务分步执行。用更小的模型做意图理解。意图理解相对简单不需要用最大的模型。我用一个7B参数的本地模型做意图理解准确率只比大模型低5%左右但速度快了10倍。7. 国产CAD工具与Agent结合的几个方向7.1 智能建模助手这是最直接的方向。用户用自然语言描述设计意图Agent自动完成建模操作。适合的场景包括快速原型设计、参数化模型调整、标准件批量生成等。我实测过一个原型用户说“做一个100x50x20的底板四角各打一个M6的沉头孔”Agent能在30秒内完成建模。虽然比熟练工程师手动操作慢一点但对于不熟悉CAD操作的人来说效率提升是巨大的。7.2 设计规范检查Agent可以自动检查设计是否符合规范。比如检查孔径是否与螺栓规格匹配、壁厚是否满足最小要求、倒角是否合理等。这个方向的价值在于降低人为错误特别适合设计评审环节。实现上需要把设计规范转成可执行的检查规则Agent在建模过程中实时检查发现问题及时提醒。7.3 历史数据复用很多设计是在已有模型基础上修改的。Agent可以检索历史项目数据找到相似的设计然后基于用户的新需求做调整。这个方向能大幅减少重复劳动。技术上的关键是相似度匹配。不能只看几何形状还要看功能语义。比如“一个用于承重的支架”和“一个用于装饰的支架”几何可能相似但设计约束完全不同。7.4 跨工具协同工程设计往往涉及多个工具CAD建模、CAE分析、CAM加工。Agent可以作为“胶水”把不同工具串联起来。比如在CAD里完成建模后自动触发CAE分析分析结果反馈回CAD做优化。这个方向对工具的开放性要求最高。国产工具如果能在API开放上做好会很有优势。8. 一些个人体会和踩坑记录做工程Agent这段时间踩过的坑不少挑几个印象深的说说。第一个坑过度信任大模型。刚开始做的时候我觉得大模型这么强应该能搞定大部分事情。结果发现在几何计算这种需要精确性的场景里大模型的表现远不如确定性代码。后来我把架构改成“大模型做规划、确定性代码做执行”稳定性一下子提升了很多。第二个坑忽视状态管理。早期版本没有状态快照Agent经常做出矛盾的操作。比如在一个已经被删除的面上打孔或者重复创建同一个特征。加上状态管理后这类问题基本消失了。第三个坑prompt写得太“客气”。我一开始写prompt喜欢用“请”“麻烦”这类词后来发现对大模型来说直接、明确的指令效果更好。比如“输出JSON不要其他内容”比“请以JSON格式输出”更有效。第四个坑知识库贪多求全。一开始我把能找到的文档都塞进知识库结果检索出来的内容质量参差不齐反而干扰了大模型的判断。后来我做了筛选只保留高质量、高相关度的内容效果明显改善。最后分享一个小技巧给Agent加一个“确认”环节。对于不可逆的操作比如删除特征、修改尺寸让Agent先输出操作计划等用户确认后再执行。这个简单的改动能避免很多误操作带来的麻烦。我在实际项目里加上这个环节后用户投诉率下降了70%以上。这个方向后续还可以扩展的地方很多比如接入更多类型的工程工具、支持更复杂的多Agent协作、引入强化学习让Agent从用户反馈中持续优化等。但核心逻辑是不变的让专业工具更开放让AI更懂专业。这两件事做好了国产CAD工具的机会自然就来了。