面向 AI 原生 CAD 的能力发现、工具调用与可编辑建模：论文调研

状态：Research Note
版本：0.1.0
日期：2026-08-29
研究问题：面对持续增长的参数化 CAD、几何内核、约束、制造与分析能力，AI 怎样知道“系统会什么、当前能做什么、应该调用什么”，并在不把自然语言或任意代码当作模型真相的前提下可靠完成建模？
对应架构提案：RFC-0002：Aira Interface 与能力发现协议

1. 结论摘要

论文证据支持以下方向：

AI 不应在一次 prompt 中看到全部 CAD API。 大规模工具集合需要检索；普通信息检索模型在工具检索上仍会明显失效，检索错误会直接降低最终任务成功率。
能力目录应同时具有层级、类型和当前状态。 纯文本相似度不足以判断某个操作在当前 Revision、选择集、表示类型、内核能力和权限下是否适用。
“会调用什么”与“现在能不能调用”必须分开。 SayCan 一类工作表明，语言相关性需要与环境 affordance/可行性结合。对 CAD 而言，这对应前置条件、输入类型、基数、表示、求解状态、权限和预算。
复杂建模需要在线闭环，不应只做一次性翻译。 ReAct、RestGPT、ToolSandbox 以及 CAD-Assistant 都支持“计划—执行—观察—修正”，尤其是状态依赖、信息不足和长链任务。
参数化操作序列比静态网格更接近可编辑 CAD，但仍不等于设计意图。 DeepCAD、SkexGen、Text2CAD 证明了学习 CAD command sequence 的可行性；SketchGraphs、约束对齐和 HistCAD 则表明显式约束、关系和编辑后保持性不可省略。
编译器、几何检查器和约束求解器反馈应进入生成闭环。 CADCrafter、约束对齐和 CAD-Refiner 都报告了执行/求解反馈对几何有效性或约束完整性的提升。
外形相似度不能单独定义成功。 Text2CAD-Bench、CADBench、CADTests 和 MUSE 把复杂度、可执行性、拓扑、功能、制造和装配要求暴露为独立问题。
自然语言层可以存在，但只能解释意图，不能拥有几何语义。 可靠边界应是：自然语言/图片/文件 → 任务假设与候选计划 → 类型化 Patch → 确定性静态检查、执行与验证。它不是“自然语言 → 中间字符串 → 内核代码”的多重转义链。

因此，本调研对 Aira 的核心建议不是训练一个记住所有 CAD 函数的模型，而是创建一个模型无关、可检索、可验证、可审计的 Aira Interface。AI 只需稳定掌握少量元操作和能力本体；具体 CAD 能力在任务发生时按需发现、绑定和验证。

2. 证据等级与研究方法

2.1 纳入范围

本调研优先纳入：

同行评审会议论文及官方 proceedings；
论文作者的 arXiv 页面、项目页或机构论文页；
与 Aira 接口实现直接相关的正式标准规范；
少量 2026 年预印本，用于观察最新 CAD benchmark 和表示趋势，明确标记为“预印本”。

不把产品营销、二手博客和 GitHub star 数作为论文结论。Zoo/KCL 与 ForgeCAD 只作为产品/原型先例，不作为因果证据。

2.2 证据标签

[论文结论]：论文直接实验或正式规范支持。
[架构推论]：由多项研究共同推导出的 Aira 设计决定，论文没有直接验证 Aira 本身。
[待验证]：必须通过 Aira 自己的 prototype/benchmark 证伪或确认。

3. 大规模能力发现：为什么不能把全部工具塞给 AI

3.1 从“给定几个工具”到“从上万工具中检索”

ToolLLM（ICLR 2024）收集了 16,464 个真实 REST API，并为模型加入 neural API retriever；论文同时评估单工具、多工具和未见 API 的泛化。Gorilla（NeurIPS 2024）进一步说明，把最新 API 文档通过 retrieval 注入推理过程，有助于适应 API 变化并减少错误调用。

[论文结论] 大规模工具系统的知识不能只固化在模型权重中，运行时文档检索是处理新增能力和版本变化的重要机制。

[架构推论] Aira 的 Operation/Capability Catalog 必须是运行时可查询、版本锁定的外部知识源；模型升级不是新增 CAD 能力的前置条件。

3.2 普通语义检索仍然不够

ToolRet（ACL 2025）构建了包含约 7,600 个任务、43,000 个工具的异构检索 benchmark。论文报告：在普通 IR benchmark 中表现强的模型，在工具检索上仍可能表现不佳，且低检索质量会降低下游任务通过率。Data-Efficient Massive Tool Retrieval也把大规模工具选择明确建模为 query-tool alignment，而不是普通文档搜索。

[论文结论] “文本描述相似”不等于“工具足够完成任务”。工具检索必须评估返回集合是否覆盖完整 solution path。

[架构推论] Aira 不能只给 operation 描述做 embedding。候选生成后还必须依据输入/输出类型、表示、当前模型状态、前置条件、精度、风险、权限和预算进行过滤与重排。

3.3 层级与多工具任务

ToolRerank（LREC-COLING 2024）将工具层级纳入 reranking，并针对单工具和多工具请求采用不同的集中/多样性策略，实验中改善了检索和最终执行结果。MetaTool则把“是否需要工具”和“选择哪个/哪些工具”拆成独立能力，发现多数受测模型仍有明显困难。

[论文结论] 工具发现至少包含 no-tool awareness、单工具选择和多工具覆盖三个不同问题；层级结构对检索有价值。

[架构推论] Aira 的能力目录应是 graph/taxonomy，而不是一个平铺函数表；search result 需要表达“替代、依赖、组合、转换、修复和 supersede”等关系。

4. 从“语义相关”到“当前可执行”

4.1 Affordance：语言合理不代表环境可行

SayCan把语言模型对技能的语义评分与机器人技能的 affordance/value 评分结合，使高层语言计划受当前环境可执行性约束。

CAD 中存在完全相同的断层：fillet 可能语义上正确，但当前选择不是边、边集为空、半径超出局部几何、Body 是 MeshSolid、浏览器没有 Exact kernel，或用户没有修改权限。

[架构推论] Aira 的能力排序至少应组合：

意图相关性
× 类型/基数兼容性
× 当前 Revision 适用性
× 可用后端与质量等级
× 权限/策略允许性
× 预算可行性

这不是要求使用固定乘法公式，而是规定这些信号不能被纯语义相似度替代。

4.2 Action schema：参数之外还需要前置条件和效果

经典 PDDL action schema 使用参数、前置条件和效果描述动作如何改变状态。现代 MCP Tool schema与 OpenAPI提供机器可读输入/输出结构；JSON Schema 2020-12提供结构验证。

[架构推论] 这些标准解决了必要但不同的问题：

JSON Schema 能验证参数结构，但不能独自证明几何前置条件、拓扑基数和单位代数；
MCP/OpenAPI 能承载工具说明和 input/output schema，但不是 Aira 的模型语义或事务协议；
PDDL 风格的 precondition/effect 适合描述 plan legality，但 CAD 的几何后置条件仍需编译器、求解器和 kernel 验证。

因此 Aira Capability Descriptor 必须在 schema 之外提供结构化 preconditions、effects、postconditions、risk、cost、diagnostics 和 repairActions。

5. 为什么复杂 CAD 必须是状态闭环

5.1 交替执行与观察

ReAct（ICLR 2023）研究了交替产生动作和环境观察，以便维护、调整计划并处理异常。RestGPT把 Planner、API Selector、Caller 和 response parser 分开，采用 coarse-to-fine online planning，而不是一次生成固定调用链。ToolSandbox专门测试有状态、对话式工具使用，显示 state dependency、canonicalization 和 insufficient information 即使对强模型也很困难。

[论文结论] 单轮工具选择 benchmark 不能代表有状态长链任务；执行后的结构化观察是后续规划所必需的。

[架构推论] Aira 默认循环应为：

Observe revision/context
→ Discover applicable capabilities
→ Describe selected contracts
→ Build and statically check plan
→ Propose typed Patch
→ Preview
→ Validate
→ Commit or repair

系统保存可观察的 plan、调用、diff、diagnostic 和 certificate；不把模型隐藏思维链当作审计证据。

5.2 代码生成有组合优势，但不能成为生产权限边界

Code as Policies表明代码模型能够重组 primitive APIs，并通过层级代码生成表达循环、条件和空间计算。Toolformer（NeurIPS 2023）则研究了何时调用工具、传什么参数以及如何使用结果。

[论文结论] 代码/程序结构适合表达组合、计算和控制流。

[架构推论] Aira 可以提供 .aira 或 builder 作为人类/AI 友好的 authoring projection，但生产路径必须把它编译为 AMIR Patch 并经过相同校验。任意 Python、JavaScript、C++、shell 或 raw OCCT call 不应成为模型真相，也不应拥有直接 commit 权限。

6. CAD 表示论文：从外形生成到设计意图

6.1 CAD command sequence 是重要进步，但覆盖面仍有限

DeepCAD（ICCV 2021）把 CAD 建模表示为 command type、parameters 和 order 的序列，并发布 178,238 个模型及建模序列。SkexGen（ICML 2022）继续研究 sketch-and-extrude construction sequence。Text2CAD（NeurIPS 2024 Spotlight）用约 17 万模型和 66 万多层文本标注研究自然语言到参数化 CAD 序列。

[论文结论] 参数化操作序列可以被神经模型学习，也比 voxel/point cloud/mesh 更接近后续编辑。

局限：这些工作的大量数据集中在 sketch/extrude 等相对有限的 feature grammar；它们没有证明任意工业 CAD、稳定拓扑引用、装配、制造约束和跨内核重放已经解决。

6.2 显式关系和约束决定编辑行为

SketchGraphs把 1,500 万真实 CAD sketch 表示为几何 constraint graph，强调参数化 CAD 是关系几何和约束编程问题。Aligning Constraint Generation with Design Intent（ICCV 2025）使用 constraint solver feedback 对齐约束生成，报告 fully constrained sketch 比例从无 SFT 的 8.9%、朴素 SFT 的 34% 提升到 93%；论文也观察到 reward hacking，说明“求解通过”仍不自动等于完整设计意图。

HistCAD（2026 预印本）提出带显式约束、feature history 与 editability benchmark 的中间表示，并用 Edit Reachability、preserved constraint satisfaction 与 Overall Editable Success 区分“能改”和“改后仍保持约束”。

[论文结论] 静态几何相似不能衡量参数变化后的行为；显式约束和编辑后测试是设计意图的重要可观测代理。

[架构推论] AMIR 必须保留参数、表达式、约束、feature dependency、稳定引用和 assertion；Aira benchmark 必须包含参数扰动与编辑保持性，不能只比较截图或 Chamfer distance。

6.3 执行器反馈显著重要

CADCrafter（CVPR 2025）从非受控图片生成参数化 CAD，并使用自动 code checker feedback 做 DPO，以降低无效代码并改善 command accuracy。CAD-Assistant（ICCV 2025）让 VLLM planner 调用 FreeCAD/Python 和专用 CAD 工具，反复检查演化中的几何状态再修正动作。CAD-Refiner（CVPR 2026）把拓扑结构图、迭代编辑和 geometry-aware CAD Checker 放在统一框架中。

[论文结论] 编译/几何/求解反馈有助于减少无效输出；迭代观察比盲目生成完整程序更符合真实 CAD 修改过程。

[架构推论] Aira 的 diagnostic 必须是稳定 code + typed payload + affected refs + allowed repairs，不能只返回 kernel exception 文本。修复仍必须形成新 Patch 并重新 preview/validate。

6.4 新 benchmark 揭示工业差距

Text2CAD-Bench（2026 预印本）包含 600 个分级人工样例，报告模型在复杂拓扑、advanced feature 和跨领域任务上明显退化。
CADBench（2026 预印本）统一多模态 CAD program generation 评估，覆盖 18,000 样本和 140 万次生成，区分几何 fidelity、executability 和 program compactness，并报告复杂度和 modality shift 带来的脆弱性。
Text-to-CAD Evaluation with CADTests（2026 预印本）用可执行软件测试验证 prompt 中的几何和拓扑要求，并展示测试也可反向指导生成。
MUSE（2026 预印本）把评估推进到可编辑 B-Rep assembly、功能、可制造性和可装配性，并观察从代码执行、有效几何到工程要求的逐级失败。

[架构推论] Aira 的技术验证不应承诺“任意文件或图片必然输出正确模型”。可证伪的表述应是：对定义好的输入分布和目标能力集，系统返回可编辑候选、明确不确定性、失败诊断和分级证书；超出能力边界时显式拒绝或请求信息。

7. 对“语言转义层”的专门判断

7.1 高风险版本

以下链路会放大误差和语义漂移：

自然语言/图片
→ 自由文本设计描述
→ 另一种自由文本或通用代码
→ kernel API
→ 仅用截图判断成功

主要负面影响：

每层都可能遗漏单位、基数、引用、约束和制造要求；
描述与真实实现版本容易漂移；
错误只能靠自然语言猜测，无法静态定位；
任意代码把安全、确定性、事务和审计混在一起；
最终外形看似正确，但没有稳定 feature history 和参数编辑行为。

7.2 Aira 应采用的版本

多模态输入
→ Intent Frame（目标、约束、假设、不确定项）
→ Capability discovery / applicability
→ 版本锁定的 typed Plan + AMIR Patch
→ compiler / solver / kernel
→ structured diagnostics + certificates

这里真正的“中间层”不是矩阵，也不是第二套几何语言，而是一个受约束的协议边界：

自然语言只负责提出目标、解释和消歧；
Capability Descriptor 说明系统能力；
AMIR 表达唯一模型语义；
compiler/solver/kernel 决定操作是否成立；
preview/validate/commit 管理状态改变。

结论：翻译层本身不是问题；让翻译结果成为不可验证的几何真相才是问题。Aira Interface 应把概率性理解限制在“候选意图与候选 Patch”，把最终模型行为交给确定性协议和执行证据。

8. Aira 的研究假设与验证实验

8.1 必须验证的假设

假设	对照	主要指标	证伪条件
H1 分层按需发现优于全量工具注入	全部 schema vs progressive disclosure	task success、token、latency、wrong-tool rate	全量注入在成本相近时持续更好
H2 类型/状态过滤优于纯向量检索	embedding only vs hybrid	Sufficiency@k、applicable@k、first valid plan	hybrid 没有显著改善
H3 前置条件/效果描述提升规划可靠性	只有函数描述 vs 完整 contract	static plan pass、invalid call rate	contract 不改善或上下文成本抵消收益
H4 结构化诊断闭环提升修复	one-shot vs diagnostic repair loop	repair success、turns、regression rate	多轮只增加成本不提高通过率
H5 参数/约束表示提升可编辑性	mesh/static B-Rep vs AMIR history	edit reachability、constraint preservation、OES	复杂编辑中无可测优势
H6 capability snapshot 绑定提高版本鲁棒性	latest docs vs locked snapshot	replay pass、version mismatch rate	锁定仍不能复现选择和执行

8.2 最小 benchmark 设计

第一轮不需要“任意输入”。建议构建 200–400 个任务，覆盖：

单操作：primitive、sketch、extrude、boolean、fillet、measure；
多操作：带依赖的 3–8 步 feature chain；
相似工具干扰：Exact/Mesh/Field 同名或近义能力；
状态限制：选择错误类型、基数不符、未闭合 profile、缺少 kernel；
信息不足：缺尺寸、单位、制造工艺或目标公差；
版本变化：新增、deprecated、语义 major 变化和未见 capability；
参数编辑：修改尺寸后检查引用、约束、assertion 和 downstream rebuild；
多模态：受控工程图、单图、STEP/mesh import，明确输入分布和允许的追问。

每个任务保存 gold capability set、允许的替代计划、必需前置条件、工程 assertions、预期失败和最小权限。成功至少分解为：发现正确、计划合法、Patch schema valid、几何可执行、要求通过、编辑稳定、事务正确。

9. 研究边界：论文尚未证明什么

现有论文没有证明：

一个通用 LLM 能可靠掌握完整 OCCT/Manifold/constraint/DFM 能力面；
自然语言或单张图片能唯一恢复原始设计意图和 feature history；
几何有效就代表功能、制造和装配正确；
纯视觉 feedback 足以替代拓扑、约束、尺寸和可执行 tests；
MCP/OpenAPI/JSON Schema 单独就能表达 CAD 事务与几何语义；
一个跨机械、建筑、家具、珠宝和工业设备的统一 capability taxonomy 已经存在。

这些空白正是 Aira Interface、AMIR、Geometry Certificate 和 Aira benchmark 需要创造的部分。

10. 对 Aira 的直接设计输入

创建 Aira Interface Manifest，让任意模型先学会少量稳定元操作，而不是具体 kernel API。
将 Operation 的规范语义、AI discoverability metadata、运行时可用性、会话授权拆成不同版本对象。
使用 capability graph + hybrid retrieval + applicability reranking；纯 embedding 仅作为候选生成信号之一。
为 AI 返回任务相关的 Task Capsule：Revision 摘要、相关子图、选择集、约束/要求、候选能力、预算和权限。
将 plan 与 execution 分离；计划引用锁定 capability ID/version，静态检查通过后才能形成 Patch。
把 compiler、solver、kernel 和 assertions 的反馈统一为结构化 diagnostics，并提供受限 repair actions。
MCP 仅作为 transport projection；Aira 的 canonical contract 位于 MCP 之下，避免把协议生命周期绑定到单一模型供应商。
技术验证以 benchmark 和明确能力边界为中心，不以“任意输入成功”作为不可证伪目标。

11. 论文与规范索引

工具发现与调用

Grounded planning 与程序式控制

参数化 CAD、约束与评估

接口标准与产品先例

12. 最终判断

这批论文共同指向一个很清晰的产品边界：

AI 原生 CAD 的关键不是发明一门只让 AI 写得更快的 CAD 语言，而是让任何 AI 都能按需发现能力、读取当前模型状态、形成可静态验证的计划、通过确定性执行器观察结果，并只用受约束事务改变模型。

Aira 应创造的核心资产是“能力本体 + 状态感知发现 + typed transaction + executable evidence”的闭环。模型、MCP、自然语言和 Three.js 都可以替换；这个闭环应保持稳定。