tclaw 以前有个功能是内置轻量小程序，本意是让用户自定义一些个性化小工具，比如 todo、番茄时钟之类的。但随着 FBR skill 的完善，FBR skill 已经可以实现大多数带 UI 的程序功能，两者开始有点重叠。 FBR skill 和 mini app 本质上是同一类东西——都是带 UI 的内置工具，但名字不同，理解成本很高。FBR skill、skill、mini app 三个概念放在一起，很容易让人搞不清楚区别。 于是决定统一叫 App：带 UI 的工具就是 App，不管是游戏开发工具还是系统维护工具，都挂在同一个地方，一眼就知道是什么。 tclaw 是我在做的 Agent 运行时，感兴趣可以去 tclaw 体验。
沉寂了一段时间 随着 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 引擎。 ...
游戏看上去不错 tbrain + tclaw 多 Agent 协作开发游戏这件事，之前大概就是验证一下能不能跑通，没想太多。 做了几个游戏下来，发现效果比预期好不少——UI 有模有样，玩法完整。几个 Agent 分工合作，设计、写代码、测试，整个流程下来没有人工干预。 做到这程度，就想继续往下走：tclaw 在游戏开发上，还能做什么？ 有一个短板很明显 但玩着这些游戏，有一个感受挺直接的：游戏能玩，但美术很糙。所有图形都是 AI 自己画的——基础色块、简单几何，能表达意思，但跟真正的游戏差得远。 网上其实有很多优秀的免费美术资源，像素风、卡通风各种风格都有，专门给独立开发者用的，质量很高。 于是就想：能不能让 tclaw 来做这些事——搜索素材、整理素材、管理本地素材库，甚至处理帧动画？ 怎么做 拿这个想法去和 tclaw 讨论，来来回回聊了好几轮。 一开始是从开发者的角度想：这个功能该怎么支持？ 做成独立插件，有自己的窗口——但插件里没有对话，用不了 tclaw 的核心能力；要用就得把对话嵌进插件里，以后每多一个插件就多一个对话框，越来越割裂。 改成全屏扩展页面，像文件浏览器那样接管整个主区域，进去是个独立的世界——用户得在对话和扩展页之间来回切换，体验还是断的。 做一套扩展系统，类似 VS Code 的插件机制，每个 Skill 可以注册自己的 UI 组件——但这意味着要定义扩展 API、生命周期、沙箱隔离……一套新的基础设施，比要解决的问题复杂多了。 怎么想怎么别扭。 后来重新梳理思路，从用户使用的角度出发：用户会怎么用这个功能？在对话框里说"搜个像素风骑士素材"，tclaw 去搜，搜出来的结果直接显示出来，看合不合适，合适就点下载。就这样。 倒推回来——tclaw 本来就是对话驱动的，对话就是入口，这个体验才是最适合的。 方向就出来了：做成 Skill，结果嵌在对话流里展示。 这样下来就需要对现有系统做一些扩充：Skill 现在只能输出文字，素材搜索的结果需要缩略图、下载按钮、动画预览，得让 Skill 支持输出富内容。 想要的效果是这样的： 用户：搜几个像素风骑士的素材 AI：找到这些 ↓ [搜索结果——带预览图、授权信息、下载按钮] 用户：这个不错，下载，帮我切成序列帧 AI：切好了 ↓ [动画预览——GIF 效果、帧分组] tclaw 本来就能把特定代码块渲染成图表。同样的思路可以用在这里——Skill 输出一个特殊的代码块，前端识别后渲染成卡片。 tbrain 源码在这里：tbrain 最兼容 tbrain 的 Agent 运行时是 tclaw，感兴趣可以去 tclaw 体验。 ...