沉寂了一段时间

随着 tclaw 功能逐渐完善，有点失去方向了，失去目标了，沉寂了一段时间，不知道该开发什么。

感觉它好像什么都能做，又什么都不能做。和同类产品拉不开差距。缺少对一个具体领域的精准支持，什么都做了一点，什么都做得不深。

后来用 tbrain + tclaw 测试多 agent 协作开发游戏，做出来的几个游戏感觉效果还不错。但问题也很明显，游戏里的美术资源都是AI画的基础色块、简单几何，如果当小游戏demo，验证游戏原型没问题，但如果想做完整的游戏，没有一个像样的美术资源不行。

网上有大量免费的高质量美术素材，像素风、卡通风各种风格，可以先方便搜索下载，然后再处理编辑素材，先不生成美术，后面可以做。

于是方向就出来了：先深挖游戏开发领域。 十几年的游戏开发经验，我对这个领域很熟悉。

想清楚要做什么

看一下具体需要做什么：

  • 美术素材搜索，从多个网站聚合搜索，用户选好后自动下载
  • 切图，大图切小图、小图合大图，支持各主流引擎的 atlas 格式
  • 序列帧动画的编辑和预览
  • Tilemap 编辑，自动生成地图

这些都是游戏开发的基本需求，先支持这些吧。

怎么做

这些工具本身不依赖 AI，就算没有 AI 能力也能完成功能。tclaw 的文件浏览器就是这样一个本地工具，本身已经支持根据文件后缀定制渲染——只要把这个能力扩展成支持插件的模式，就可以随意扩展了。

但具体怎么实现需要想一想。tclaw 本身已经有插件系统了，这里直接叫"插件"不合适，容易混淆。和 AI 讨论了一番，感觉做成 skill 比较合适——现有的 skill 不支持 UI 显示，需要为这类 skill 加上 UI 能力。调用某个编辑器时，本质上就是显示这个 skill 的 HTML 界面，配上对应的操作。

另外，因为 tclaw 是 AI 原生的工具，每个插件还需要支持 AI 直接调用的接口——这部分不需要 UI，纯逻辑就行，所以 UI 和逻辑需要分开，这就有了 FBR（File Browser Renderer）。目前做了四个：切图（sprite-slicer）、序列帧动画编辑（frame-animator）、图集打包（atlas-packer）、Tilemap 编辑（tilemap-editor）。为此也整理了一套 FBR skill 的开发规范和参考示例，方便以后自己或别人继续扩展。

终于引入了 goja

现在 AI 写代码很方便，应该任何人都能很随意地写自己需要的工具才行。FBR skill 的 UI 部分靠浏览器实现没问题，但要让 AI 直接调用 FBR skill 的接口，要么走无头浏览器，要么走纯 JS。无头浏览器感觉不太爽，因为本质就是纯逻辑，非得经过浏览器感觉很重，纯 JS 就需要引入 JS 引擎。

一番纠结后还是觉得引入 JS 引擎利大于弊——所有需要扩展的能力都可以用 JS 实现，不只是 FBR，整个 tclaw 的扩展能力都会大幅提升，而且也不需要用户再下载 Node.js 了。代价就是包体变大。最终选了 goja，纯 Go 实现，直接编进二进制，零外部依赖。每个 FBR skill 提供一个 src/index.js，导出 invoke(action, params)，AI 通过 /v1/fbr/actions 接口调用，goja 在服务端跑。

至于为什么选 JS——之前 pcclaw 的 skill 脚本用 Lua，AI 写 Lua 错误率高得离谱，早就放弃了，这次直接选了 AI 最熟的语言。

话说一直在纠结要不要引入，之前觉得太重，一直在拖。引入之前 release 包约 11MB，引入 goja 之后——32.8MB!!!

tbrain 源码在这里：tbrain

tclaw 是我在做的 Agent 运行时，感兴趣可以去 tclaw-releases 体验。