我把 draw.io MCP 接进 VS Code Codex，直接生成了带动画连接器的 LSTM 架构图

我把 draw.io MCP 接进 VS Code Codex，直接生成了带动画连接器的 LSTM 架构图

公众号：码海寻道

这篇文章记录一次真实的 MCP 接入与图表生成实测：从 next-ai-draw-io 的 packages/mcp-server 出发，把 draw.io 的创建、编辑、导出能力接进 VS Code 里的 Codex，并最终生成一张可继续编辑、可导出、且保留动画连接器的 LSTM 架构图。

如果你只想先看结论，这篇文章会回答三个问题：

1. next-ai-draw-io 的 MCP 到底能不能在 VS Code Codex 里真正跑起来。
2. 它生成的结果是"看起来像图"，还是 draw.io 可继续编辑的工程文件。
3. 动画连接器这种稍微复杂一点的效果，最后能不能保留到导出的 SVG 里。

写在前面

很多人在体验 MCP 时，第一反应是"能不能让 AI 直接画图"。这个问题本身并不新，但真正落地时经常卡在两个地方：

1. AI 能不能稳定产出 draw.io 可执行的结构化结果。
2. 生成结果之后，能不能实时预览、继续编辑、最后导出成可交付文件。

next-ai-draw-io 正好把这两件事串了起来。它本体是一个基于 Next.js 的 AI 绘图应用，而它的 packages/mcp-server 又进一步把 draw.io 的创建、编辑、导出能力封装成了 MCP 工具，允许 Claude Desktop、Cursor、VS Code 以及类似 Codex 这样的 AI 编程代理直接调用。

这篇文章不只介绍仓库本身，也记录一次完整实测：我把它接进了 VS Code 中的 OpenAI Codex，然后实际生成了一张带动画连接器 的 LSTM 架构图，并导出了 .drawio 与 .svg 文件。

实测日期：2026-03-20

本文安装时解析到的 MCP 包版本：@next-ai-drawio/mcp-server@0.1.16

这个项目解决了什么问题

根据仓库根 README，next-ai-draw-io 的定位很明确：它是一个"AI-Powered Diagram Creation Tool"，核心是让用户通过自然语言创建、修改和增强 draw.io 图表。

仓库首页展示了几个很有代表性的能力：

• 动画连接器图
• AWS / GCP / Azure 云架构图
• 图像或文档驱动的图表复制与生成
• 聊天式实时编辑

尤其值得注意的是，根 README 里直接给了一个示例提示词：

Give me a animated connector diagram of transformer's architecture.

也就是说，"动画连接器"并不是额外 hack 上去的边角能力，而是这个项目公开展示过的主能力之一。

从技术实现上看，仓库 README 也给出了整体栈：

• Next.js
• Vercel AI SDK
• react-drawio

底层图仍然是 draw.io XML，AI 的职责是根据自然语言生成或修改 XML，再由前端或嵌入式 draw.io 进行渲染。

MCP 版本为什么更有意思

如果你只是在网页里和 AI 对话生成图，这件事当然已经足够好用。但 MCP 版本的意义在于，它把"画图能力"暴露成了一个标准化工具集，可以被 AI 编程代理直接调用。

packages/mcp-server/README.md 给出的工具列表只有 5 个，但非常实用：

• start_session：打开浏览器并建立实时预览会话
• create_new_diagram：用 XML 新建图
• edit_diagram：按 cell ID 做增删改
• get_diagram：读取当前图的 XML
• export_diagram：导出为 .drawio 文件

这个设计有两个工程上的优点。

第一，它没有把 AI 绑死在网页对话框里。只要客户端支持 MCP，AI 就能直接调工具。

第二，它把"可视化预览"和"结构化编辑"拆开了。AI 不需要自己渲染图，它只要负责生成和修改 XML；浏览器只负责展示当前会话状态。

README 里给出的架构也很直白：

AI Agent <-> MCP Server(stdio) -> Embedded HTTP Server(:6002) -> Browser(draw.io embed)

这意味着这个包虽然是以 stdio 方式接入 MCP 客户端，但内部还会拉起一个嵌入式 HTTP 服务，默认端口是 6002，再把 draw.io 嵌入页面开到浏览器中做实时预览。

我这次是怎么接进 VS Code Codex 的

这里有一个实践层面的细节，值得单独说一下。

1. VS Code 自己的 MCP 配置，和 Codex 的 MCP 配置，不一定是一回事

我最开始先给当前工作区写了一份 VS Code 级别的 MCP 配置：

{
  "servers": {
    "drawio": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@next-ai-drawio/mcp-server@latest"]
    }
  }
}

文件位置是：

.vscode/mcp.json

这一步对 VS Code 自身是有效的，但用户随后明确说明，他实际使用的是 VS Code 里的 OpenAI Codex 插件。继续检查后我发现，在这台机器上，Codex 还有自己独立的共享配置入口：

C:\Users\14429\.codex\config.toml

因此，对 Codex 来说，更稳妥的做法不是手改 VS Code 工作区配置，而是直接使用 Codex CLI 自带的 MCP 管理命令。

2. 真正让 Codex 生效的配置方式

我最终执行的是这条命令：

codex mcp add drawio -- npx -y @next-ai-drawio/mcp-server@latest

执行完成后，codex mcp list 已经能看到：

drawio  npx  -y @next-ai-drawio/mcp-server@latest  enabled

写入后的关键配置长这样：

[mcp_servers.drawio]
command = "npx"
args = ["-y", "@next-ai-drawio/mcp-server@latest"]

这一步之后，VS Code 里的 Codex 会话和终端里的 codex CLI 就共享了同一套 MCP 服务器定义。

官方推荐的 MCP 接法

仓库 README 和 packages/mcp-server/README.md 中给出的标准配置是：

{
  "mcpServers": {
    "drawio": {
      "command": "npx",
      "args": ["@next-ai-drawio/mcp-server@latest"]
    }
  }
}

对于 Claude Code CLI，README 还给了一个更顺手的命令：

claude mcp add drawio -- npx @next-ai-drawio/mcp-server@latest

从 package.json 看，packages/mcp-server 本身的信息也比较完整：

• 包名：@next-ai-drawio/mcp-server
• 当前仓库中的版本：0.1.16
• CLI bin：next-ai-drawio-mcp
• Node 版本要求：>=18
• 开发脚本：dev / build / start

如果你是本地开发这个包，而不是只消费 npm 发布物，那么脚本分别对应：

{
  "build": "tsc",
  "dev": "tsx watch src/index.ts",
  "start": "node dist/index.js"
}

真正的测试，不是"配置成功"，而是"画图成功"

MCP 配好之后，我没有停留在"服务列表里出现了 drawio"这一步，而是直接让它执行一次真实任务：

给我一个绘制带有动画连接器的LSTM架构图。

整个调用流程是：

1. 调 start_session
2. 调 create_new_diagram
3. 调 export_diagram

其中 create_new_diagram 并不是传一句自然语言，而是由代理生成一整份 draw.io 的 mxGraphModel XML。为了实现动画连接器，我在边的样式里显式加入了 flowAnimation=1，同时保留了虚线与箭头配置，例如：

style="edgeStyle=orthogonalEdgeStyle;rounded=1;html=1;endArrow=classic;strokeColor=#2E7D32;strokeWidth=2;dashed=1;dashPattern=8 4;flowAnimation=1;"

这次生成的图包含了完整的 LSTM 单元结构：

• x(t) 当前输入
• h(t-1) 上一时刻隐藏状态
• C(t-1) 上一时刻细胞状态
• Forget Gate
• Input Gate
• Candidate
• Output Gate
• C(t) 更新后的细胞状态
• h(t) 当前隐藏输出
• y(t) 读出结果

同时，我把不同信息流做了视觉分层：

• 绿色表示 cell state
• 蓝色表示 hidden state
• 橙色表示 input stream
• 紫色表示 gated output

导出结果与验证

这次实测导出了两个文件：

• lstm-animated.drawio
• lstm-animated.svg

文件大小如下：

• lstm-animated.drawio: 11486 字符
• lstm-animated.svg: 43455 字节

更关键的是，导出的 SVG 不是静态截图，而是保留了动画定义。对导出文件做文本检查后，可以看到：

• @keyframes
• stroke-dashoffset
• animation: 750ms linear ... infinite

这说明 draw.io 的流动连接器样式已经被真正编译进了 SVG，而不是仅存在于编辑器运行态。

换句话说，这次测试验证的是一条完整链路：

1. Codex 能调用 drawio MCP
2. MCP 能拉起浏览器会话
3. AI 生成的 draw.io XML 可以被正常渲染
4. 动画连接器样式可以保留到最终导出的 SVG

这个 MCP 方案的几个工程价值

1. 从"聊天生成图"走向"可编排工具调用"

把 draw.io 能力做成 MCP 之后，AI 不再只是一个聊天窗口里的"图表助手"，而是可以被编程代理稳定调用的图形工具链。

这件事的价值在于组合能力。以后你完全可以把它接到更长的自动化链路中：

• 先读 PRD 或架构说明
• 再生成流程图或系统图
• 然后导出为 .drawio / .svg
• 最后自动写入文档仓库

2. draw.io XML 仍然是核心资产

这个项目的一个重要判断是：不要绕开 draw.io，而是直接生成 draw.io 可执行 XML。

这样做的好处是：

• 结果不是图片，而是可编辑源文件
• 可以继续在 draw.io 中手工调整
• 可以导出 SVG、PNG、.drawio
• 可以配合版本历史做回滚与比对

这比"AI 画一张图给你看"更接近工程交付。

3. 动画连接器不是噱头

在静态架构图里，很多"流向"其实不够直观。动画连接器的价值在于，它能把数据流、状态流、调用方向更明显地表达出来。

对于像 Transformer、LSTM、消息流、审批流这类"路径本身有语义"的图，动画比单纯的箭头更容易传达结构重点。

使用时需要注意的几个点

1. start_session 必须先调用

packages/mcp-server/README.md 已经明确写了，如果出现 "No active session"，先调用 start_session。这次实测也完全一致。

2. 默认端口是 6002

MCP 服务内部会启动一个嵌入式 HTTP Server，默认端口是 6002。README 里提到，如果端口被占用，它会自动尝试下一个可用端口，直到 6020。

如果你想显式指定端口，可以通过环境变量：

{
  "mcpServers": {
    "drawio": {
      "command": "npx",
      "args": ["@next-ai-drawio/mcp-server@latest"],
      "env": { "PORT": "6003" }
    }
  }
}

3. 私有环境可以自托管 draw.io

如果你所在环境对外网 draw.io 有限制，README 里也给了私有部署方案。核心变量是：

DRAWIO_BASE_URL

比如：

{
  "mcpServers": {
    "drawio": {
      "command": "npx",
      "args": ["@next-ai-drawio/mcp-server@latest"],
      "env": {
        "DRAWIO_BASE_URL": "https://drawio.your-company.com"
      }
    }
  }
}

README 还给了一个最直接的自托管例子：

docker run -d -p 8080:8080 jgraph/drawio

我对这个项目的实际判断

如果只看 README，next-ai-draw-io 很像一个"AI 画图应用"。但把 packages/mcp-server 跑起来之后，你会发现它更像是一层"AI 可调用的 draw.io 操作系统接口"。

它有几个我比较看重的特点：

• 安装门槛低，npx 即可启动
• 对 AI 代理友好，工具面收得比较干净
• 结果保留为 draw.io XML，而不是只能截图
• 实时浏览器预览让 AI 生成过程具备可观测性
• 导出 SVG 时可以保留动画连接器

当然，它目前也仍然带着 Preview/Experimental 的属性。这意味着你在生产环境里接入时，最好保留几个兜底措施：

• 固定已验证版本而不是永远追 latest
• 把 .drawio 导出纳入制品保存
• 对生成 XML 保持可审查和可回滚
• 对端口与浏览器会话建立做基础监控

结语

这次实测最有价值的地方，不是"又接通了一个 MCP 服务器"，而是验证了一件更具体的事：

AI 代理已经可以直接把结构化图表工作做进日常工程流里，而且交付物不是一次性的截图，而是可编辑、可导出、可验证的 draw.io 工程文件。

对文档工程、架构设计、教学示意图、算法讲解图来说，这条路比"让 AI 生成一张看起来像图的图片"实用得多。

如果你也在用 VS Code 里的 Codex、Claude Code 或 Cursor，这个仓库值得亲自接一次。最好的验证方式不是看介绍，而是像这次一样，直接给它一个带结构约束的任务：

给我一个绘制带有动画连接器的 LSTM 架构图。

如果最后你得到的是一个可以继续编辑的 .drawio，以及一个带真实动画的 .svg，那这套东西就不再是概念演示，而是已经进入可用状态了。

如果你也在折腾 AI 工具链、MCP、工程自动化和可视化交付，这类文章我会继续写在"码海寻道"里。对我来说，真正值得记录的不是"某个工具很炫"，而是它能不能进入真实工作流，并且在输出物层面经得起验证。

参考资料

• 项目仓库：https://github.com/DayuanJiang/next-ai-draw-io
• 根 README：https://github.com/DayuanJiang/next-ai-draw-io/blob/main/README.md
• MCP Server README：https://github.com/DayuanJiang/next-ai-draw-io/blob/main/packages/mcp-server/README.md
• MCP Server package.json：https://github.com/DayuanJiang/next-ai-draw-io/blob/main/packages/mcp-server/package.json