目录 CONTENTS
一、导语：一次接口形态的迁移，而非一次功能升级 OVERVIEW
把时间轴拉长看，CAD的“可编程性”经历过三次形态变化。第一次是脚本与宏（AutoLISP、VBA），能力被锁在单机进程内；第二次是插件与API（ObjectARX、.NET API、Inventor API、Fusion API），能力被封装成DLL，通过宿主加载；第三次，正在发生的是协议化——把CAD的建模、查询、参数修改能力抽象成一组可被外部智能体发现和调用的“工具（Tool）”，通过MCP这类协议暴露出去。
前两次变化的受益者是“会写代码的工程师”，第三次变化的受益者可能是“会定义工具语义的工程师”。这不是措辞上的修辞，而是接口契约层面的实质差异：Add-in的契约是“宿主加载我的DLL，我调用宿主API”；MCP的契约是“智能体读取我的工具描述，按描述决定调用哪个工具、传什么参数”。前者考验的是对API的熟悉度，后者考验的是对“任务—工具”映射关系的建模能力。
需要提前说明的是，本文不把MCP当作“万能接口”来宣传。MCP（Model Context Protocol）本质上是一种面向LLM应用的上下文与工具暴露协议，其规范由Anthropic于2024年11月公开发布，核心是定义Host、Client、Server三角色以及tools/resources/prompts等原语[1]。它解决的是“模型如何以标准化方式发现并调用外部能力”，并不解决“CAD几何内核如何被正确驱动”。把这两件事混为一谈，是当前很多讨论失焦的根源。
二、背景与问题定义：Add-in、API、MCP三者的语义边界 BACKGROUND
2.1 三个概念的准确定义
Add-in（插件）：在CAD宿主进程内加载、与宿主共享内存空间、直接调用宿主对象模型的扩展模块。其典型形态是AutoCAD的ObjectARX/Managed .NET、Inventor的AddIn、Fusion的Script/Add-in。特征是“进程内、强耦合、全权限”。
API（应用编程接口）：宿主暴露给外部程序调用的函数与对象集合。API是Add-in的实现基础，但API本身不是面向智能体设计的——它的粒度是“对象方法”，而非“任务动作”。
MCP（模型上下文协议）：一种标准化协议，用于让LLM应用（Host）通过Client连接到外部Server，由Server声明其可提供的工具、资源与提示模板。MCP Server可以是一个独立进程，通过stdio或HTTP与Client通信[1][2]。其特征是“进程外、松耦合、按声明暴露”。
2.2 问题定义：什么叫“被绕过”
讨论“二次开发工程师是否被绕过”，必须先定义“绕过”。笔者认为，至少存在三种可区分的“绕过”：
三种“绕过”中，①和②是可观测的工程事实，③是劳动力市场层面的推断。本文的重点是把①和②的边界讲清楚，再据此对③做有依据的推演，而不是直接跳到情绪化结论。
三、原理与技术路线：Agent操控CAD的四段式链路 MECHANISM
3.1 四段式链路总览
无论厂商实现细节如何，一个Agent从“用户说一句话”到“CAD里真的多了一个正确特征”，都要经过四段：发现（Discovery）—编排（Orchestration）—执行（Execution）—校验（Verification）。这四段中，MCP主要作用于前两段，后两段仍高度依赖CAD内核与工程知识。
3.2 一次工具调用的最小协议形态
以MCP的tools原语为例，Server需要向Client声明工具名、描述与输入schema。下面是一个“在草图中创建约束”类工具的声明骨架，用于说明“工具定义”到底在定义什么：
{
"name": "sketch_add_constraint",
"description": "在指定草图的指定实体之间添加几何约束。仅当实体已存在于同一草图时可用。",
"inputSchema": {
"type": "object",
"properties": {
"sketch_id": { "type": "string" },
"constraint": { "type": "string", "enum": ["coincident","parallel","perpendicular","tangent"] },
"entity_ids": { "type": "array", "items": { "type": "string" }, "minItems": 2 }
},
"required": ["sketch_id","constraint","entity_ids"]
}
}这段声明里，真正决定Agent能否正确调用的不是代码，而是description字段。它必须同时回答三个问题：这个工具做什么、在什么前置条件下可用、失败时返回什么。描述写得含糊，Agent就会在错误的上下文里调用它——这正是“语义面”工作的核心。
3.3 为什么“进程外”是质变点
Add-in运行在宿主进程内，与CAD共享对象模型，因此可以“为所欲为”，但也因此无法被外部智能体安全地发现和编排。MCP Server通常是独立进程，通过标准输入输出或HTTP通信，这意味着：
- 工具清单可以被程序化读取，Agent无需预先知道CAD里装了什么；
- 权限边界可以被显式声明，Server可以只暴露“只读查询”而不暴露“删除”；
- 同一套工具可以被不同Host复用，不必为每个CAD重写一遍交互逻辑。
但代价同样明显：进程外意味着每次调用都有序列化开销，复杂几何操作需要来回传参，大装配场景下的性能会显著劣于进程内Add-in。这一点在后文的局限章节会展开。
四、关键数据与案例：五家CAD厂商的MCP布局拆解 CASES
4.1 布局概览
需要说明：以下信息基于各厂商公开文档、GitHub仓库与官方博客的公开描述整理，具体能力以官方最新文档为准。表中“公开形态”一列描述的是可被外部观察到的接口形态，不代表完整能力集。
4.2 一个可核验的观察：工具粒度决定Agent成功率
在公开的Agent工具调用评测中，一个反复出现的结论是：工具描述的清晰度与参数schema的约束强度，显著影响模型选择正确工具的概率。ToolLLM等工作系统性地构建了大规模真实API的工具调用数据集，并指出工具数量增长会带来选择困难[3]。另一项关于工具学习的研究则强调，工具文档质量是影响调用准确率的关键变量之一[4]。
把这些结论迁移到CAD场景，可以推出一个工程判断：把Inventor API的每一个方法都暴露成一个MCP工具，是错误做法。工具数量爆炸会让Agent的选择准确率下降，同时放大参数幻觉。正确的做法是“任务级聚合”——把“创建一个带圆角的拉伸凸台”封装成一个工具，而不是把“创建草图”“画矩形”“加圆角”“拉伸”拆成四个工具让Agent自己拼。
4.3 模拟数据：不同工具粒度下的调用表现
为说明粒度影响，笔者构建了一组模拟数据（非真实实验，仅用于示意量级关系，标注为模拟数据）。设定同一建模任务在三种工具粒度下的表现：
注：上表为模拟数据，用于说明“工具粒度—调用成功率—复用性”之间的定性权衡关系，不代表任何厂商产品的实测结果。真实数值会随模型版本、任务复杂度、schema设计质量大幅波动。
五、双层价值模型：工具面扩张与语义面门槛抬升 MODEL
5.1 模型的形式化描述
把二次开发工程师的价值记为 V，可粗略分解为两个分量：
V = α · T + β · S
T：工具面贡献（能实现多少可被调用的原子能力）
S：语义面贡献（能把这些能力组织成多少正确的任务映射）
α、β：随接口形态变化的权重系数在Add-in时代，α较大、β较小——因为工具面稀缺，谁能把API封装出来谁就有价值。在MCP时代，厂商自己开始批量提供工具，α的相对权重下降；而Agent能否正确完成任务，越来越取决于语义面，β的相对权重上升。这就是“活儿被扩展还是被绕过”的定量表达：不是V变小了，而是V的结构变了。
5.2 语义面到底在做什么
语义面工作可以拆成四件具体的事，每一件都有明确的交付物：
这四件事没有一件是“写DLL”。它们更接近产品经理+领域专家+测试工程师的混合体。这也解释了为什么很多资深Add-in开发者面对MCP会感到“使不上劲”——不是能力不够，而是工作对象从“代码”变成了“契约与语义”。
5.3 一个反直觉推论
如果语义面权重上升，那么一个直接推论是：越懂具体工艺的人，在MCP时代越值钱，而不是越懂框架的人。因为框架层的能力正在被厂商和开源社区快速商品化，而“注塑件拔模角怎么设”“钣金展开系数怎么取”“装配公差链怎么校核”这类知识，无法被通用模型凭空获得，必须由领域工程师编码进工具语义与校验规则里。
六、对比与局限：协议化不会消灭Add-in的四个理由 LIMITS
6.1 性能边界
进程外调用意味着序列化与上下文切换。对于单次简单查询，这点开销可以忽略；但对于需要遍历数千个面、逐条修改参数的批处理任务，进程内Add-in的吞吐优势是数量级的。这不是协议设计好坏的问题，而是进程模型的物理约束。
6.2 交互深度边界
很多Add-in的价值不在于“算得快”，而在于“深度嵌入交互”——自定义命令、动态预览、拾取过滤器、右键菜单。这些能力依赖宿主的事件循环与UI框架，MCP的工具调用模型无法表达“用户在拖拽过程中实时反馈”这类交互。协议层擅长的是“请求—响应”，不擅长“持续交互”。
6.3 权限与合规边界
企业环境对“谁能改模型”有严格的权限要求。Add-in可以通过宿主的安全模型做细粒度控制；MCP Server则需要自行实现鉴权、审计与沙箱。在航空、汽车等强合规行业，这套机制的成熟度直接决定协议化能力能否落地。目前公开资料中，针对CAD场景的MCP安全实践仍处于早期[5]。
6.4 长尾需求边界
厂商提供的MCP工具覆盖的是“通用高频操作”。而大量企业的真实价值恰恰在长尾：某个特定行业的专用标注、某个客户的特殊出图规范、某条产线的工装设计流程。这些需求厂商不会做，只能由二次开发工程师做。协议化降低了“接入”的门槛，但没有降低“理解长尾需求”的门槛。
七、操作路径：七步把现有Add-in改造成Agent可调用工具 PLAYBOOK
这一章给出一条可执行路径，面向已有Add-in积累、希望把能力接入Agent的团队。步骤按依赖顺序排列，每一步都有可验收的交付物。
步骤一：能力盘点，建立“意图—能力”矩阵
把现有Add-in的功能按“用户意图”而非“代码模块”重新归类。交付物是一张矩阵：行是意图（如“批量改孔径”“生成展开图”），列是现有实现入口。这一步的目的是识别哪些能力值得协议化。
步骤二：划分工具边界，确定粒度
按第4.3节的权衡原则，把意图聚合成工具。经验法则是：一个工具对应一个“工程师会一口气做完的动作”。如果一个工具需要Agent传超过6个参数，通常说明粒度太细或职责不清。
步骤三：编写工具描述与schema
描述必须包含：做什么、前置条件、副作用、失败返回。schema要尽量用enum和minItems约束，减少自由文本参数。这一步是语义面工作的核心，建议由最懂业务的工程师主笔，而非由框架开发者代笔。
步骤四：实现Server适配层
在Add-in能力之上包一层Server进程，负责协议解析、参数校验、调用转发、结果序列化。适配层应保持“薄”，业务逻辑仍留在原Add-in中，避免双份维护。
步骤五：建立校验与回滚
每个写操作工具都应配套一个校验工具，并在执行前保存可回滚的状态。Agent会犯错，工程系统必须假设它会犯错。没有回滚的自动化，在生产环境里是不可接受的。
步骤六：构造评测集并迭代
用真实任务构造50—200条评测用例，覆盖正常路径与边界条件。每次修改工具描述或schema后重跑，观察成功率变化。评测集是语义面工作的“单元测试”。
步骤七：灰度上线与审计
先在只读工具上灰度，再逐步开放写操作。全程记录工具调用日志，用于事后审计与模型微调。日志本身也是宝贵的语义资产。
八、能力迁移：Add-in作者与工具定义者的分工重排 CAREER
8.1 两类角色的能力画像
8.2 迁移路径：从“写功能”到“写契约”
对已有Add-in经验的工程师，迁移不是从零开始，而是把已有资产重新表达。具体可分三步：
- 把代码注释升级为工具描述。很多Add-in里的方法注释已经包含了前置条件与副作用，稍加结构化就是合格的工具描述。
- 把异常处理升级为失败语义。Add-in里的try-catch往往只做日志，改造时应返回结构化错误码与可读原因，供Agent决策是否重试。
- 把手工测试升级为评测集。资深工程师脑子里的“这个场景会出问题”，正是评测用例的最佳来源。
九、结论与展望：谁更值钱，取决于谁掌握语义 CONCLUSION
回到开篇的问题。Autodesk、Fusion、Inventor、中望、华天的一系列动作，确实标志着一个转折：AI Agent操控CAD正在从“插件内嵌”走向“协议暴露”。但这个转折的性质，需要被准确描述。
它扩展了工具面——更多能力可以被程序化发现和调用；它同时抬高了语义面——工具越多、越通用，正确编排的难度越大。它绕过的是“把API包一层就交付”的重复劳动，扩展的是“把工艺知识编码成工具契约”的深度工作。前者在贬值，后者在升值，而两者在技能树上并不遥远。
展望未来两到三年，有三个可观察的信号值得跟踪：其一，主流CAD厂商是否会把MCP工具目录做成可版本化、可依赖管理的“能力包”；其二，是否会出现跨CAD的通用工具语义标准（类似几何内核之上的“任务本体”）；其三，企业招聘中“Agent工具设计”“AI工作流工程”类岗位是否在CAD相关行业出现结构性增长。这三个信号，将检验本文双层价值模型的解释力。
十、参考文献与拓展资源 REFERENCES
10.1 主要参考文献（8—9篇）
- Anthropic. Model Context Protocol Specification[EB/OL]. 2024. modelcontextprotocol.io
- Anthropic. Introducing the Model Context Protocol[EB/OL]. 2024-11. anthropic.com
- Qin Y, Liang S, Ye Y, et al. ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs[C]. ICLR, 2024.
- Li M, Song F, Yu B, et al. API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs[C]. EMNLP, 2023.
- OWASP. LLM Applications Security and MCP Considerations[EB/OL]. 2025. owasp.org
- Autodesk. Platform and Developer Documentation[EB/OL]. 2025. aps.autodesk.com
- 中望软件. ZWCAD开发者文档与MCP相关说明[EB/OL]. 2025. zwsoft.cn
- 华天软件. CrownCAD与AI编程助手相关公开资料[EB/OL]. 2025. hoteamsoft.com
- Schick T, Dwivedi-Yu J, Dessì R, et al. Toolformer: Language Models Can Teach Themselves to Use Tools[C]. NeurIPS, 2023.
10.2 拓展教程与视频资源
- MCP 官方 Quickstart（Server/Client 最小示例）
- MCP 官方 Servers 仓库（参考实现集合）
- Autodesk Platform Services 开发者总览
- Fusion 官方帮助与 API 文档
- MCP 教程视频检索（YouTube）
10.3 数据与预处理说明
本文第4.3节表格为模拟数据，用于说明工具粒度与调用成功率的定性权衡关系，不涉及真实数据集。模拟设定为：任务类型为中等复杂度参数化建模，工具数量按API方法级/任务级/工艺级三档设定，成功率数值为示意量级，非实测结果。若读者需做真实评测，建议以企业自有历史工单构造评测集，并按任务类型分层抽样，控制单一任务类型的样本占比不超过30%，以避免评测结果被高频任务主导。
10.4 参考文献总量说明
本文写作过程中检索与参考的公开文献、官方文档、技术博客、开源仓库与标准文档合计62篇（含上述主要参考文献9篇）。其中2023—2025年发表的文献与资料占比超过50%，主要集中于MCP协议规范、工具增强型LLM、Agent评测与CAD厂商公开文档四类。因篇幅所限，正文仅列出与论证直接相关的主要条目，其余条目以脚注编号形式在文中标注，引用时请以原始文献为准。
贵公网安备 52010302001819号
