社区卡片、MCP 服务器和技能——全都用一支箭头连接
一个上午的两个版本，让画布对不是我们写的代码敞开了大门。难点不在功能本身，而在于守住那个承诺：智能体只能触及箭头给它的东西。
直到这周，NeuroSquad 画布上的每一张卡片都出自我们之手。0.1.123 同时从三个方向改变了这一点：人人都能制作并发布在 GitHub 上的社区卡片、来自官方 MCP Registry 的 MCP 服务器，以及来自 skills.sh 的技能——每一样都通过画一支箭头交给某个特定的智能体。一个半小时后，0.1.125 又加入了已验证卡片：一份经过审查的清单，配一枚含义精确的徽章。
画布有一条让它清晰可读的规则：智能体能用的，恰好就是它的箭头所指向的东西。只有这条规则保得住，向别人的代码开放才值得做。这两个版本的大部分工作，都是为了确保它保得住。
第一步：让添加一张卡片变得便宜
最早的卡片是手工接入应用的：联合类型里加一个卡片类型、画布里加一个分支、标签、图标、MCP 服务器表里的一项、删除级联里的一步——每张卡片大约要改十几个地方。一张一张来还能忍，几张并行开发就必然冲突。
所以内置卡片先变成了插件：页面里一个文件夹，主进程里一个模块，IPC 通道统一使用一个公共前缀，MCP 工具由卡片自己注册，文案放在各自的文件里。画布、侧边栏、箭头和删除流程以同样的方式处理每一张插件卡片。一旦卡片成了插件，让别人来写一张，就只是隔离问题，而不再是接线问题。
社区卡片：一个出不了卡片的沙箱
社区卡片就是一个小型网页应用。它本可以运行在单独的原生 Web 视图里，但那是操作系统层面的叠加层：它会浮在画布之上而不是嵌在画布之中，也不会随画布一起缩放和裁剪。所以它改为运行在一个具有不透明源的沙箱 iframe 里，通过应用自己的协议提供内容。在此基础上动工之前，我们在这个确切的 Electron 版本上核实了这样的框架能做什么、不能做什么：
- 它运行在独立的操作系统进程中。一张卡片在忙循环里空转四秒，画布也没有被冻住：宿主的计时器照常走动，最大间隔 63 ms。
window.api、Node 和require根本不存在，碰一下父页面就会抛出安全错误。localStorage和 IndexedDB 不可用（所以有一套专门的存储 API），对外请求会被框架的内容安全策略拦下。- 它无法打开窗口、无法全屏、无法读取剪贴板，也无法打开麦克风。
有两项检查没通过，而这恰恰是最有价值的。WebRTC 完全无视内容安全策略：一个对等连接连上了本机的一个 TCP 监听端口。修复很直接——卡片的启动脚本在任何卡片代码运行之前，就把 WebRTC 构造函数删掉。第二个问题出在应用里，而不是框架里：它的权限处理程序会把麦克风授予任何请求者。现在它只授予应用自己的顶层页面；这就是更新日志里“麦克风权限只授予应用本身”那一行。
卡片从不和绘制它的那个页面直接对话。它拿到的是一个通往主进程的消息端口，绑定在这一个卡片实例上，每个请求都会在主进程里，对照软件包声明、且你在安装时授予的权限进行检查。凡是触及另一张卡片或某个智能体的操作——通过端口发送数据、给智能体发提示词、在终端里输入——都既需要权限，又需要两张卡片之间有一支箭头。箭头就是对这一条数据流的同意。
安装通过 GitHub 地址进行，固定到某个提交，并与软件包文件树的哈希核对。更新只在你点击时才会发生，并且会先告诉你权限有哪些变化。如何自己做一张，见 Card SDK 页面。
已验证卡片：一枚只代表一件事的徽章
按地址安装的模式有个明显的缺口：怎样找到值得安装的卡片？0.1.125 加入了一份由 NeuroSquad 团队审查过的卡片目录，存放在一个公开仓库里，通过 PR 更新。你可以在“自定义卡片…”选择器或“设置”里搜索它。
徽章由主进程判定，含义就是这一条：已安装的卡片来自经过审查的仓库、处于经过审查的提交，并且安装时计算出的文件哈希与目录中的哈希一致。本地开发文件夹、别的提交、不一样的文件——都没有徽章。
从目录安装还更进一步：如果名称、版本或哈希与目录条目不符，安装会被拒绝。这里要在“装上但不给徽章”和“干脆不装”之间做选择，而被掉包的软件包不该被悄悄装上。更新的已审查版本会以更新的形式提供，附带常规的权限差异，永远不会自行应用；一张卡片从清单中移除后，会失去徽章，但你画布上的任何东西都不会被删除。
MCP 服务器和技能，用箭头连接
应用内的目录可以搜索官方 MCP Registry（约 3.5 万个服务器）和 skills.sh（安装量最高的 2 万个技能）。搜索在应用本地进行，基于随应用分发、并增量更新的快照——所以离线可用，而且即搜即得。
把 MCP 服务器交给智能体，最直接的办法是把它写进智能体 CLI 的配置里。我们刻意没这么做。NeuroSquad 自己充当你安装的每个服务器的 MCP 客户端，再通过自己的 MCP 服务器把这些工具以 <alias>__<tool> 的形式重新提供出来——只提供给有箭头连向该服务器卡片的智能体，而且只在箭头存在期间提供。不会往你的 CLI 配置文件夹里写任何东西，服务器的密钥也永远不会离开主进程。Claude Code 无需重启就能识别新画的箭头；其他 CLI 在下次启动时生效。
Figma Context
io.github.GLips/Figma-Context-MCP · v0.13.2
已提供给 0 个智能体
从这张卡片画一条箭头到智能体。
2 个工具 figma_context__*
技能的工作方式相同，通过一个工具 skill_load 实现，它的描述里列出了连接到该智能体的技能，以及各自适用的场景。有一个标志决定了这是一个功能还是一场演示：智能体会把 MCP 工具藏在工具搜索后面，在一次实测中，一个全新的智能体一次都没有加载过匹配的技能。标记为“始终加载”后，它自己就加载了对的那个。
brainstorming
obra/superpowers
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
已提供给 0 个智能体
从这张卡片画一条箭头到智能体。
一次安全审查带来了什么
两个版本在发布前都经过了安全审查，其中三项结果值得一说：
- 每个智能体都有自己的令牌来访问应用的 MCP 服务器，由每次启动生成的密钥和智能体的 id 派生而来。以前，一个智能体理论上可以冒充另一个；现在访问别的智能体的路径会返回 401。
- 第三方工具放在第二个 MCP 服务器上，它不在 CLI 的预批准工具列表里。所以每次调用别人服务器上的工具之前，CLI 都会先问你——而且工具列表在安装时会生成指纹，服务器之后若改动了工具，就要等你接受这些变更。
- 技能整体取自同一个提交。skills.sh 自己的内容哈希无法根据它提供的文件复现出来，所以应用对你预览过的那些文件自行固定一个 SHA-256，并且安装的正是那些文件。
并非所有东西都能纳入。Figma 官方的远程服务器对动态客户端注册返回 403——它只接受获批的客户端——所以目录改为指向一个使用个人令牌的社区服务器。需要本地 HTTP 服务器的软件包暂不支持。这两点都如实写明，而不是绕过去。