夜雨聆风这两天有个 Codex 插件突然火了。
项目叫 Cowart。
GitHub 地址是：
https://github.com/zhongerxin/Cowart
作者是 钟二信。
项目 README 和插件信息里署名为 ZHONG XIN，GitHub 账号是 zhongerxin，显示名是 Twox。
他的 X 账号也是 @zhongerxin，个人简介写着：
现豆包桌面端产品经理；前 Teambition、飞书智能伙伴设计师、ChatGPT 插件 Pluginpedia 作者。
这个背景挺关键。
因为 Cowart 不是一个纯后端开发者突然做了个画布 demo。
从公开信息看，它更像是一个长期接触产品、设计工具和插件生态的人，把过去对“视觉工作台”的理解，接到了 Codex 插件体系里。
截至 2026 年 6 月 22 日晚，它已经到了 1739 stars、138 forks。
更夸张的是，它不是一个已经打磨很久的老项目。
从 GitHub 信息看，这个仓库创建于 2026 年 6 月 18 日 16:08 UTC，也就是北京时间 6 月 19 日 00:08。
从提交记录看，它的节奏也很密集：
6 月 19 日，first commit 6 月 19 日，加入本地磁盘持久化画布 6 月 20 日，补齐整套绘图和 AI 编辑能力 6 月 21 日，连续更新插件元数据、skills、标注工具、MCP 图片插入、安装文档 同一天，开始合入外部贡献者的 PR
也就是说，它不是那种“发出来大家点个 Star 就散了”的项目。
它很快进入了下一阶段：
有人装，有人用，有人踩坑，有人提 issue，有人交 PR。
这件事比 Star 数本身更重要。
因为对于一个 Codex 插件来说，真正难的不是“看起来很酷”，而是用户真的能装起来、跑起来、用起来，然后愿意帮你修。
Cowart 这次刚好做到了。
Cowart 到底是什么？
一句话说：
Cowart 是一个给 Codex 用的本地无限画布插件。
它基于 tldraw 做了一个网页画布。
你可以在 Codex 里打开它，然后做几件事：
在画布里画图、贴图、写字、放形状 创建一个 “AI 图片” 占位框 让 Codex 根据你的描述生成图片，并插入到这个占位框里 在图片上用标注箭头写修改意见 把标注截图发给 Codex，让它生成一张干净的新图，再放到原图旁边
注：图片来自原作者X推文
听起来像一个小白板。
但它的关键不是“白板”。
关键是：
这块白板不是孤立的。它和 Codex 接上了。
普通白板只能让你自己画。
Cowart 这块画布，可以被 Codex 读到选区，可以被 Codex 写入图片，也可以通过 MCP 工具把生成结果真正落到画布状态里。
这就让它从一个“可视化 UI”，变成了一个“Agent 可以操作的工作空间”。
这个差别很大。
为什么它会突然火？
我觉得有三个原因。
第一个原因是时机。
Codex 插件这件事，本身就在一个非常早的窗口期。
大家都知道 Codex 能写代码。
但“Codex 插件到底能做什么”，很多人其实还没有形成具体想象。
这时候最容易传播的，不是抽象框架，也不是复杂协议，而是一个能马上看懂的例子。
Cowart 就是这种例子。
你一看截图就知道：
哦，原来 Codex 不只是能在终端里改文件，它还可以打开一个本地工具，在里面和我一起做视觉创作。
这就是典型的生态早期样板间。
不是把所有能力都做满，而是让大家第一次看到：
原来这个方向可以这么用。
第二个原因是场景很直观。
很多 Agent 工具很难传播，因为你需要解释一大堆：
它怎么调工具？
怎么读上下文？
怎么管理状态？
怎么跟外部服务交互？
听起来都对，但用户没有画面。
Cowart 不一样。
它的传播图像非常简单：
Codex + 一块画布 + AI 生图 + 标注修改。
这个组合天然适合截图。
也天然适合在社交平台传播。
因为所有人都能马上理解它在干什么。
第三个原因是它不是 demo，而是闭环。
很多项目看起来很酷，但只停在演示层：
打开一个页面，点一个按钮，生成一张图，然后结束。
Cowart 做得更进一步。
它把本地持久化、选区读取、图片资源保存、画布状态更新、插件安装、skills 指令、MCP 工具都串起来了。
这意味着用户不是只能看作者演示。
用户自己也可以把它装进 Codex，然后在自己的项目目录里生成 canvas/ 数据。
这对开源项目很重要。
能跑起来，才会有人帮你修。
从 GitHub PR 看，6 月 21 日已经有外部贡献者开始修安装、依赖、粘贴图片刷新竞态等问题。
这说明它已经越过了“围观”阶段，进入了“真实使用”阶段。
它火的过程，其实很像一次产品冷启动
如果只看 Star 数，很容易把 Cowart 的火理解成一次流量事件。
但从提交历史看，我觉得它更像一次典型的小产品冷启动。
第一步，先做出最小可用形态。
6 月 19 日，它先把 tldraw 画布跑起来，并且把画布数据保存到本地项目目录。
这一步非常关键。
因为 Codex 插件不是普通 SaaS。
用户会关心：
我的画布数据放在哪里？
会不会被存到插件仓库里？
换项目之后会不会串数据？
Cowart 的答案很明确：
数据默认保存在当前用户项目的 canvas/ 目录。
这一步解决的是信任感。
第二步，补上 AI 工作流。
6 月 20 日，它加入整套绘图和 AI 编辑功能。
也就是不只是“打开画布”，而是让 Codex 可以围绕画布做事。
这里最核心的是两个场景：
一个是 AI 图片占位框。
用户在画布上放一个 “AI 图片” holder，Codex 读取它的尺寸和位置，再把生成图片放进去。
另一个是标注式编辑。
用户在图上用箭头和文字写修改意见，Codex 根据标注生成新图，再放到旁边，保留原图和标注。
这两个场景都很适合 Agent。
因为它们把人的意图变成了视觉上下文。
第三步，补上插件包装。
6 月 21 日凌晨，它开始大量完善 .codex-plugin/plugin.json、skills 和 README。
这一步决定了它能不能从“本地项目”变成“Codex 插件”。
你会看到它不是只写了一段安装命令，而是把三类能力拆成了三个 skill：
cowart-open-canvas：打开本地画布 cowart-image-gen：生成图片并插入画布 cowart-image-edit：根据标注截图生成修订图
这其实很聪明。
它没有把所有逻辑塞进一个万能 prompt。
而是把用户任务拆成三个入口。
这对 Codex 来说更好理解，也更容易稳定执行。
第四步，社区开始补坑。
外部 PR 很快出现。
有贡献者修 Codex MCP 安装后的启动问题。
有贡献者修粘贴图片后被旧快照覆盖的问题。
还有贡献者补缺失依赖、移除 hardcoded path。
这很像一个产品真正跑起来之后必然经历的阶段：
作者解决核心想法，真实用户暴露边角问题，社区开始把它推向可用。
所以 Cowart 的火，不只是“发了一个项目”。
而是它在很短时间内完成了一个小产品的四步：
可用原型 -> AI 闭环 -> 插件包装 -> 社区修补。
代码核心实现：Cowart 是怎么把 Codex 和画布接起来的
下面讲代码。
我尽量不讲太细的源码，而是讲它的架构。
更有意思的是，Cowart 基本踩中了 OpenAI 官方 Codex 插件文档里推荐的结构。
官方文档里说，如果只是个人工作流，可以先做 local skill；但如果要把 workflow 分享出去，或者要打包 MCP 配置、app integration、hooks，就应该做成 plugin。
Cowart 正好就是这个形态：
.codex-plugin/plugin.json 负责声明插件。
skills/ 负责告诉 Codex 每类任务怎么做。
.mcp.json 和 mcp/server.mjs 负责把“读选区、插入图片”变成 Codex 可以调用的工具。
所以它不是一个随手拼出来的 demo，而是一个非常标准的 Codex 插件样板。
Cowart 的实现可以拆成三层：
Codex 插件层 ↓本地画布服务层 ↓MCP 操作层这三层合在一起，才是 Cowart 真正的核心。
第一层：Codex 插件层
入口是：
.codex-plugin/plugin.json
这个文件告诉 Codex：
这是一个插件。
它叫什么。
它有哪些 skills。
它有哪些 MCP server。
它在插件界面里怎么展示。
Cowart 的插件描述里写得很直接：
它是一个本地无限画布，用于 visual thinking、image generation 和 annotation-driven edits。
注意这里有两个东西很关键。
第一个是：
skills": "./skills/"
这代表 Cowart 把使用方式写成了 Codex 可以加载的 skill。
第二个是：
mcpServers": "./.mcp.json"
这代表它不是只靠自然语言提示 Codex。
它还给 Codex 提供了真正可以调用的工具。
这就是 Codex 插件最有意思的地方：
skill 负责告诉 Agent 怎么做，MCP 负责给 Agent 一双手。
没有 skill，Agent 不知道流程。
没有 MCP，Agent 只能讲，不能稳稳地改画布状态。
Cowart 把这两个都补上了。
第二层：本地画布服务层
画布本身在 src/App.jsx。
技术栈很简单：
React Vite tldraw
但它在 tldraw 上做了几件自己的事情。
第一件事，是加了一个 AI 图片 holder。
在代码里，这个 holder 本质上是一个 tldraw frame。
它的 meta 里会带上：
{"cowartAiImageHolder":true}这就像给普通 shape 贴了一个标签。
用户看到的是一个 “AI 图片” 框。
Codex 看到的是：
这里有一个可以被填充的目标位置。
这个设计很小，但很关键。
因为 AI 生图最大的问题之一是：
生成出来之后放哪里？
尺寸是多少？
要不要覆盖原图？
有没有 anchor？
AI 图片 holder 把这些问题提前变成了画布上的一个对象。
用户用视觉方式定义位置，Agent 用结构化信息读取位置。
第二件事，是加了一个标注工具。
Cowart 自己实现了一个 CowartAnnotationTool。
用户拖动时，它会创建一条带箭头的 tldraw arrow，并且自动进入文字编辑状态。
默认颜色是红色。
标签位置会被固定。
这看起来像一个小交互，但它背后解决的是另一个核心问题：
让用户用最自然的方式告诉 AI：改这里。
不用写很长 prompt。
不用描述“左上角那个物体旁边第三个区域”。
直接画箭头，写一句话。
这就是标注式编辑的价值。
第三件事，是保存画布状态。
Cowart 不是只把画布存在浏览器内存里。
它会把画布 snapshot 保存到当前项目的：
canvas/pages/<page-id>/cowart-canvas.json图片资源保存到：
canvas/pages/<page-id>/assets/同时还会保存选区状态：
canvas/cowart-selection.json以及视图状态：
canvas/cowart-view-state.json这几个文件非常重要。
因为它们让画布从一个临时网页，变成了项目的一部分。
你的画布数据跟着当前项目走。
你的图片资源也跟着当前项目走。
这对 Codex 这种本地工作流来说很自然。
第四件事，是通过 Vite 插件层提供 API。
vite.config.js 里做了很多本地服务工作。
比如：
GET /api/canvas读取画布 PUT /api/canvas保存画布 GET /api/selection读取选区 PUT /api/selection保存选区 GET /api/view-state读取视图状态 PUT /api/view-state保存视图状态 /page-assets/负责暴露页面级图片资源 /api/canvas-events用 SSE 通知画布变化
这说明 Cowart 不是只在前端里玩 tldraw。
它还做了一个很轻量的本地状态服务。
这个服务的作用就是：
让浏览器、文件系统和 Agent 之间有一个共同的状态入口。
第三层：MCP 操作层
真正让 Cowart 变成 Codex 工具的，是 mcp/server.mjs。
这个 MCP server 暴露了两个工具。
第一个是：
get_cowart_selection
它负责读取当前画布选中的 shape。
比如选中的是不是 AI 图片 holder。
它的尺寸是多少。
它有没有图片 asset。
它的 meta 是什么。
第二个是：
insert_cowart_image
它负责把一张本地图片插入画布。
这个工具做的事情比名字听起来复杂：
读取当前画布 snapshot 找到选中的 anchor shape 判断目标 page 读取图片尺寸 把图片复制到 page-local assets 目录 创建 tldraw image asset 创建 tldraw image shape 计算 shape 的 fractional index 尽量把新图放在 anchor 旁边，避免覆盖已有内容 通过 Cowart 本地 API 保存新的 canvas snapshot
也就是说，当 Codex 生成一张图之后，不需要手写一堆脆弱的 tldraw 记录。
它可以调用 MCP 工具：
把这张图放到当前画布里。
这一步非常关键。
因为 Agent 最怕的就是：
你让它直接改一个复杂 JSON。
能改，但容易错。
Cowart 把“插入图片”封装成了一个工具。
这就把不稳定的自然语言执行，变成了更稳定的结构化操作。
所以我前面说，Cowart 的核心不是画布，而是这套连接结构。
画布只是用户看到的表面。
真正有价值的是：
它让 Codex 可以通过 skill 理解任务，通过 MCP 调用工具，通过本地 API 写回画布。
这就是一个完整的 Agent 工作流闭环。
为什么这个实现值得看？
因为它给 Codex 插件开发者提供了一个很好的样板。
很多人做 AI 工具，会一上来想做很大的东西：
我要做一个新的 IDE。
我要做一个新的设计工具。
我要做一个新的 Agent 平台。
但 Cowart 的路线更轻。
它没有重新发明画布。
它直接用 tldraw。
它没有重新发明 Agent 框架。
它接入 Codex。
它没有重新设计插件协议。
它按 Codex plugin、skill、MCP 的方式包装。
它真正做的，是把几个成熟部件接起来：
tldraw 负责画布Vite 负责本地服务文件系统负责持久化MCP 负责工具调用Codex skill 负责操作流程imagegen 负责生成图片这就是现在很多 AI 小产品最现实的做法。
不是拼模型能力。
而是拼工作流闭环。
你能不能把一个用户任务，从输入、操作、生成、保存、复用完整接起来。
Cowart 这次火，本质上就是因为它把这个闭环做得很直观。
它现在还不完美
当然，Cowart 现在还远远不是一个成熟产品。
从 issue 和 PR 看，问题已经开始暴露。
比如有人提到，希望能调整画板参数。
也有人提到，目前生图能力主要依赖 Codex 内置 Image Gen，不一定适配其他生图方式。
还有更深层的问题：
外部 Agent 会写 canvas snapshot。
如果 snapshot 里有一条非法记录，tldraw 校验可能导致整张画布白屏。
这个问题很典型。
它说明 Cowart 现在已经碰到了真正的产品化问题：
当 Agent 也能写状态时，系统必须对坏状态有容错能力。
这不是 demo 阶段会优先处理的问题。
但只要真实用户开始使用，就一定会遇到。
所以我觉得 Cowart 接下来真正要补的，不只是功能。
而是这些东西：
安装流程能不能更稳 不同 Codex 环境下能不能一致启动 画布 snapshot 能不能更强容错 图片生成路径能不能支持更多模型 多页面、多项目、多历史版本怎么管理 用户误操作之后怎么恢复
这些问题听起来不酷。
但这正是一个玩具项目变成工具项目必须经历的阶段。
Cowart 给插件开发者的启发
我觉得 Cowart 最值得学的，不是它用了 tldraw。
而是它踩准了 Codex 插件生态里的三个点。
第一，插件要有一个非常直观的入口。
“给 Codex 一块无限画布”这个入口非常清楚。
用户不需要理解 MCP，不需要理解 snapshot，也不需要理解 plugin manifest。
他只需要知道：
我能打开一块画布，让 Codex 和我一起画图、生成图、改图。
第二，插件最好有一个可视化结果。
Agent 工具如果只在终端里跑，很难传播。
不是终端不好，而是传播门槛高。
Cowart 的结果是画布。
截图天然就是传播素材。
这对早期项目太重要了。
第三，插件要把流程写清楚。
Cowart 的 skill 写得很细。
什么时候打开画布。
什么时候读取选区。
什么时候生成图片。
什么时候插入 holder。
什么时候保留原图。
什么时候不应该替换标注。
这些说明看起来像文档，其实是 Agent 的操作规程。
未来做 Codex 插件，很可能不是只写代码。
你还要写一套给 Agent 看的“工作说明书”。
谁能把这套说明书写清楚，谁的插件就更容易稳定运行。
写在最后
Cowart 这次火，我觉得是一个很有意思的信号。
它说明 Codex 插件生态的早期机会，不一定在“大而全”的 IDE 级工具里。
反而可能在这种小而完整的工具里：
一个清楚的场景。
一个直观的界面。
一组可调用的 MCP 工具。
几份写清楚流程的 skills。
再加上一个能被用户马上截图理解的结果。
这就足够形成传播。
过去我们说 AI 编程，更多是在说：
AI 能不能把代码写对。
但 Cowart 让我看到另一个方向：
AI 编程工具接下来要竞争的，可能不是谁更会聊天，而是谁能给 Agent 提供更好的工作空间。
聊天框是入口。
终端是手。
文件系统是记忆。
而画布、浏览器、表格、设计稿、数据面板这些东西，会变成 Agent 的新工作台。
Cowart 只是其中一个很早的样板。
但正因为它早，所以才值得拆。
下一个机会也许不是“做一个更强的 Agent”。
而是问一句：
我的工作流里，有没有一个地方，也可以变成 Agent 能看、能改、能保存的本地工作台？
如果有，那可能就是下一个插件机会。
参考信息
Cowart 仓库： https://github.com/zhongerxin/CowartOpenAI Codex 插件文档： https://developers.openai.com/codex/plugins/build