在代码生成工具逐步接管终端命令行之后,软件架构设计中最核心的视觉载体——白板,正在成为多模态代理竞争的下一个试验场。开发者 yanndegat 近日在分布式代码托管平台 Tangled 开源了 Rust 项目 drawgent,尝试将开发者本地登录的 Claude Code、Codex 或 opencode 终端代理直接接入 Excalidraw 白板,使终端模型能够直接读取画板上下文、基于图元位置进行具身化协作。

这一尝试击中了开发者在系统设计时的长期痛点,但项目的生命周期却透着实验性代码的脆弱。原文所列的源码主页 yanndegat.tngl.sh/drawgent 目前已返回 404 状态,公开网络索引中未见大规模镜像收录。与其说它是一个立即可用的生产力组件,不如说它是面向空间协同交互的一次关键技术探路。

告别脆弱的语法串:从文本重绘走向图元增量

长期以来,AI 辅助架构绘图的通用路径极其狭窄。主流方案基本依赖大语言模型直接输出 Mermaid 纯文本语法,再交由前端渲染引擎转换为矢量图。这种单向链路在现实工程中经常崩塌。Excalidraw 社区反馈显示,长标签、特殊括号、多行文本或稍微密集的连接关系,极易引发 Mermaid 语法解析崩溃。更致命的是,文本生成模型缺乏局部修改能力,即便开发者只想微调一个模块的命名,模型也倾向于重新生成整段代码,导致既有排版全盘错乱。

AI 从全图重写转向局部增量修补,避免整张白板排版错乱(示意图)
AI 从全图重写转向局部增量修补,避免整张白板排版错乱(示意图)
架构绘图交互演进:全局重绘 vs 空间增量 传统 Mermaid 文本流 · 依赖字符串解析,符号嵌套易崩溃 · 缺乏空间坐标,无法识别临近关系 · 局部微调演变为全画布重画 单向脆弱输出 drawgent 空间图元级协同 · 视觉截图 + JSON 图元双轨读取 · 便签绑定目标图元,坐标自适应解析 · 细粒度更新属性,保留既有结构 具身局部协同

drawgent 选择了完全不同的底层构造。在它的工程设计中,Rust 编写的核心服务占比达 82.4%,配合 12.5% 的前端代码构建本地运行时。它不再把白板视作单纯的 Markdown 附件展示窗,而是将 AI 视为画板上的具身参与者。

开发者在画布任意图元旁拉出一个带有 AGENT 前缀的便签,drawgent 会在停止输入的 2.5 秒内自动触发防抖机制,收集该便签的三维空间数据:它在画布中的具体坐标、周围存在哪些邻近组件、箭头连线指向了哪个父级模块。随后,终端模型根据场景快照执行精确图元增删,完成任务后直接将便签标记为绿色的 DONE 状态。这种空间提示词机制避开了宏观的自然语言描述壁垒,把指令范围收敛到特定的图元关系中。

协议桥接架构:将终端进程搬上加密房间

要让本地终端代理具备操作画板的能力,关键在于打通进程隔离。drawgent 没有采用中心化托管模型的轻量化路线,而是依靠 ACP 与 MCP 两种协议,将本地环境直接暴露给画布。

终端代理通过专用协议,把本地操作直接注入加密白板(示意图)
终端代理通过专用协议,把本地操作直接注入加密白板(示意图)
drawgent 进程协同与双向同步拓扑 本地 Agent Claude Code Codex opencode ACP / MCP drawgent 核心服务 · 端口 127.0.0.1:7300 · Chrome Headless Shell 渲染 · 会话分叉 / 实时消息映射 · 空间邻近图元判定队列 E2EE 同步 Excalidraw 画布 · 独立 Agent 光标同步 · 局域网 / 线上房间 · 端到端密钥加密

在连接 Claude Code 时,由于客户端没有提供直接向活动终端注入指令的接口,drawgent 采取了分叉会话策略,复制上下文并通过协议驱动;而在面对开放监听端口的 opencode 或基于会话队列的 Codex 时,它则能实现终端输入与右侧聊天栏的实时镜像。更进一步,drawgent 可以伪装成协作者加入官方 Excalidraw.com 房间。在端到端密钥保护下,AI 拥有了属于自己的独立光标,能够在人类眼前一笔一画地调整系统框图。

这一套方案与现有的官方工具存在明确分歧:

  • 官方 Excalidraw MCP 主要服务于 Claude 对话界面的直接出图,依托中心化服务提供视图生成与检查点。
  • 社区项目 mcp_excalidraw 偏向代码仓库内的持久化白板与图元级审查,注重静态归档。
  • GitHub 上的同类项目 exgram 同样在探索支持 Claude Code 与 Codex 的白板能力,但更偏重轻量技能注入。
真正的空间协同不是让 AI 当速写师,而是让它成为画板旁能看懂位置批注的搭档。

现实鸿沟:沉重依赖与未竟的协同协议

虽然 drawgent 描绘的交互极具吸引力,但其实现手段也折射出当前 Coding Agent 接管图形界面的技术代阶。

白板底层缺乏细粒度并发仲裁,多方写入极易引发图元冲突(示意图)
白板底层缺乏细粒度并发仲裁,多方写入极易引发图元冲突(示意图)

首当其冲的是工程实现的沉重代价。为了在没有原生矢量图形解析器的情况下捕获场景并进行几何计算,drawgent 在安装流程中必须拉取约 120MB 的 Chrome Headless Shell 无头浏览器,并要求本地具备 Node.js 18 以上环境与精确的系统依赖库。为了让 AI 看懂一张图,开发者不得不先把半个前端渲染栈搬进终端。

更深层的障碍在于上游白板生态对自主代理的支持依然滞后。Excalidraw 开发者社区关于自然语言代理的设想由来已久。早在 2026 年 6 月 29 日,社区就出现了关于 Excalidraw Agent 的讨论提案,但长期未能获得官方实质推进。随后在 2026 年 8 月 4 日,社区提交的 issue 再次指出,Excalidraw 现有的模型自带密钥体系限制严格,用户无法配置自定义模型,只能依赖硬编码预设。

  • 风险.官方接口未提供完善的图元局部更新、来源标记与并发仲裁能力,第三方工具通过无头挂载的方式极易在多人协作或网络抖动时引发状态竞争。

白板开发者社区在针对代理协作的讨论中早已形成共识:AI 介入画布的核心前提,是引入类似 PATCH 风格的细粒度局部图元更新机制、图元创建者身份追踪,以及完备的乐观并发控制。在这些底层协议尚未标准化之前,类似 drawgent 这样通过本地端口侵入式桥接的探索,固然展示了跳脱出命令行牢笼的可能性,但在源项目跌入 404 的现实面前,重度依赖终端的开发者仍需等待一个更为轻巧、标准化的空间交互协议落地。