如果要给 AI 做一个 CAD Agent，你会怎么做？最直接的办法，大概是把 CAD 的各种 API 包装成 Tools，再通过 MCP 暴露给 AI。
- 画直线？给它一个
drawLine。 - 画圆？给它一个
createCircle。 - 修改图层？再来一个
setEntityLayer。
如果觉得功能不够丰富，那就继续加。听起来没什么问题。直到有一天，你发现自己已经开发了 500 个 Tools，而用户提出的需求还是有一半没法满足。恭喜，你可能不是在开发 CAD Agent，而是在给 AI 开发一个新的 CAD API 产品。
当然，这只是个玩笑。不过，随着 Codex、Claude Code、Cursor 等编程 Agent 越来越强大，我开始认真思考一个问题：
与其教 AI 如何调用成百上千个工具，为什么不直接让 AI 写代码来操作 CAD？
1. AI Agent 最近半年发生了什么变化？
过去，让 AI 修复一个 Bug，通常是让它阅读代码、分析原因，然后修改代码。现在，越来越成熟的编程 Agent 已经学会了另一套玩法。
- 遇到 Bug？先写段代码分析日志。
- 不知道问题怎么复现？写个测试程序。
- 怀疑某个变量的值不对？加点调试代码，把运行过程扒个底朝天。
- 修复之后，再写代码验证一下到底修好了没有。
AI 不再只是阅读代码、生成代码，它开始把代码当成解决问题的工具。这其实是一个很重要的变化。
- 以前，我们主要考虑的是：怎么让 AI 调用软件提供的功能？
- 现在，我们可以换个思路：能不能让 AI 自己编写程序，把软件提供的基础能力组合起来，解决具体问题？
对于 CAD 这样的复杂软件，我认为这可能是一条更值得探索的路线。
2. 给 AI 提供一堆 Tools，真的够用吗？
假设用户提出一个需求：
找出所有直径接近标准螺栓孔尺寸的圆，排除参考图层中的对象，按照所属零件分类，找出异常值，并生成一份报告。
我们可以给 CAD Agent 提供一系列 Tools：
- 查询实体、获取实体属性
- 获取块参照和图层信息
- 创建选择集、修改实体
- 计算几何关系、测量距离
- 创建标注、导出报告
问题来了：
- 如果现有 Tools 不支持用户指定的某种特殊分类规则，怎么办？继续开发一个 Tool？
- 如果用户又要求根据零件的安装位置进行分类，是不是还要再开发一个？如果用户要求把异常孔位与另外一张图纸进行比较呢？
这么搞下去，开发者恐怕很快就会进入一个熟悉的循环：
- 用户提出新需求，开发新 Tool；
- 新 Tool 上线，用户提出更奇怪的需求；然后继续开发新 Tool。
最后，工具越来越多，Agent 的能力似乎也没增加多少。
这里需要说明，MCP 本身并没有问题。它解决的是如何以标准化方式向 AI 暴露外部能力的问题。真正值得讨论的是：复杂软件的所有能力，都有必要包装成一个个独立的 AI Tool 吗？
3. 为什么不直接让 AI 写代码？
换一种思路：假设 CAD 提供了一个 JavaScript 或 Python 脚本环境，暴露图纸数据库、实体查询、几何运算和属性修改等基础 API。AI 接到任务后，直接编写脚本。
比如，找出所有半径小于 5 的圆：
const circles = cad.getEntities({
type: "CIRCLE"
});
const results = circles.filter(circle =>
circle.radius < 5
);
return results.map(circle => ({
handle: circle.handle,
radius: circle.radius,
layer: circle.layer
}));
以上是示意代码，实际 API 取决于 CAD 软件的实现。
这个例子很简单，用 Tools 也能完成。
但如果任务变成：分析所有圆的直径分布，识别疑似螺栓孔，排除特殊图层，根据块参照进行分类，再找出偏离常见尺寸的异常对象呢？
- AI 可以自己编写遍历、筛选、统计和分类逻辑。
- 第一次结果不对？修改脚本，再跑一次。
- 发现图纸里有嵌套块？调整遍历逻辑。
- 发现某种零件有特殊的命名规则？把规则加进程序。
开发者不必提前预测所有需求，更不必为了每一种需求开发一个专用 Tool。
软件提供能力，AI 编写逻辑。
我认为，这才是脚本语言对于 Agent 最有价值的地方。
4. 直接写脚本，还有三个意想不到的好处
除了灵活性，直接写代码还有三个非常实际的优势：省 Token、容易验证，以及可能更快。
第一，省 Token：别让 AI 给一万个实体挨个点名
假设一张图纸有 10 万个实体，用户想找出其中符合某些条件的对象。
如果 Agent 的工作方式是反复查询、获取结果、分析结果、再调用下一个 Tool，那么大量中间数据和调用记录可能会占据上下文。
如果 API 设计得不好，事情会更加热闹：AI 还没开始解决问题，Token 已经先忙得不可开交了。
而脚本可以直接在运行环境中遍历实体、执行计算和筛选，最后只把真正有价值的结果返回给模型。
10 万个实体中发现了 3 个异常？那就返回这 3 个异常，而不是让模型先认识另外 99,997 个实体。
当然，Tool 也可以支持批量查询，脚本也不是完全不消耗 Token。但对于需要大量数据处理的任务，让程序处理数据、让模型处理结果，通常更经济。
不要让 AI 亲自搬砖，让 AI 写个程序去搬砖。
第二，容易验证：别光说你改好了，拿证据来
AI 说自己找到了 20 个异常对象，你敢直接相信吗？如果这些对象涉及机械设计，可能还是先别急着庆祝。使用脚本，我们可以把验证逻辑直接写进程序。例如：
- 检查筛选结果是否符合指定的几何条件。
- 检查修改前后的实体数量是否合理。
- 检查实体 Handle 是否有效。
- 检查修改后属性是否符合预期。
- 对重要结果执行断言或回归测试。
还可以把分析和修改分成两步：先运行只读脚本生成修改清单，验证通过后，再执行真正的修改。如果程序发现结果不符合预期，Agent 可以查看错误信息和中间结果，修改代码，再运行一次。
更重要的是，验证通过的脚本可以保存下来重复执行。对于企业常见的图纸检查规则，这甚至能逐步沉淀成可复用的自动化程序。
相比之下，如果整个过程只是由一连串工具调用和模型决策组成，当然也可以验证，但通常需要额外设计相应的校验机制。
AI 可以犯错，但至少应该让它有机会用程序证明自己没错。
第三，执行更快：少开几次会，多干几件事
假设你要处理 5,000 个实体。一种做法是让 AI 不断调用工具，每次拿到结果后再决定下一步。另一种做法是让 AI 写好循环和筛选逻辑，然后一次性交给脚本引擎执行。
你觉得哪种方式更可能快？通常是后者。原因不仅在于代码执行速度，还在于它减少了模型参与每一步操作的需要。每一轮模型推理、工具调用和结果返回，都可能带来额外延迟。如果整个任务需要几十轮甚至上百轮串行交互，这些开销加起来就很可观。而循环、条件判断、几何计算和批量操作，完全可以交给程序在运行时完成。
当然，画一条直线时，直接调用一个 Tool 可能更简单、更快。没必要为了画条线，先写一份《直线绘制自动化程序设计方案》。
脚本的优势主要体现在复杂任务、大量数据处理和需要多步计算的场景。
让模型负责思考，让程序负责执行。别让一个价值不菲的大脑，整天忙着判断下一个圆该不该入选。
5. MCP 和 Tools 就没用了？
当然不是。我并不认为未来的软件 Agent 应该抛弃 MCP 和 Tools。它们解决的是不同层面的问题。
- MCP： 适合连接外部系统，标准化地暴露远程能力。
- Tools： 适合打开文件、导出图纸、请求用户确认等边界清晰的操作。
- 脚本： 适合组合 API，完成复杂的分析、计算和自动化任务。
它们完全可以共存。
例如，CAD Agent 可以通过 Tool 打开图纸，通过 MCP 查询外部零件数据库，再通过 JavaScript 分析图纸中的孔位与零件数据，最后生成修改方案。
这种架构既保留了工具调用的便利，也给 AI 留出了足够的自由度。
当然，脚本执行环境必须做好安全控制，包括限制文件和网络访问、设置执行时间上限、管理修改权限，以及提供事务和撤销机制。让 AI 写代码，不代表应该给它一台没有刹车的推土机。
6. 这不只是 CAD 的问题
我认为，同样的思路也适用于 GIS、3D 建模、仿真分析，甚至各种办公软件。
这些软件往往拥有复杂的数据模型和大量基础操作，但开发者不可能预先实现用户未来可能提出的每一种需求。
与其不断为 AI 增加专用工具，不如提供一套设计良好、文档完整、适合 AI 使用的 API，再配上一个可靠的脚本执行环境。
- 用户想要一种新的分析方法？AI 写代码。
- 用户想要一种新的筛选规则？AI 写代码。
- 用户想把十几种操作组合成一个工作流？还是 AI 写代码。
软件厂商不必为每一种需求开发新功能，AI 也不必被局限在预先设计好的工具清单里。
当然，这并不意味着 AI 写出来的程序就一定正确。涉及工程设计和重要数据修改时，仍然需要适当的验证与人工审核。
但至少，我们给了 AI 一种更通用的方式去尝试解决问题。
结语：别只给 AI 一把锤子，给它一个工具箱和一张工作台
过去，我们习惯于问：为了让 AI 使用我的软件，我应该给它提供哪些 Tools？现在，我觉得更值得问的是：
为了让 AI 自己解决问题，我应该给它提供什么样的编程环境？
从最近编程 Agent 的发展来看，代码正在成为一种通用的问题解决工具。它不只是最终交付物，也是分析问题、验证假设、处理数据和自动化操作的手段。
对于 CAD Agent，我更看好这样的路线：提供 JavaScript 或 Python 这样的动态语言，暴露足够完整的 CAD API，让 AI 自己编写、执行、调试和迭代代码。
MCP 和 Tools 依然有价值，但它们不应该成为 AI 使用复杂软件的唯一方式。
毕竟，我们不可能提前开发出用户需要的所有 CAD 功能。
与其不断给 AI 增加新工具，不如让 AI 学会用现有工具编写程序，创造出解决新问题的方法。
对软件开发者来说，这可能意味着少写一些重复的胶水代码。
对 AI 来说，这意味着它终于不必每次遇到新问题，都先举手问一句：
“请问，有没有一个 Tool 专门干这个？”
