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 引擎。 ...
从 DAG 到行为树 tbrain 最初的任务调度是 DAG（有向无环图）：brain agent 把 job 拆成带依赖关系的任务列表，orchestrator 按依赖顺序执行。这套机制简单直接，但有一个缺陷——缺乏条件分支和自适应能力。任务成功失败的处理方式是固定的，无法根据执行结果走不同路径。 为了解决这个问题，引入了行为树（Behavior Tree）——游戏 AI 里常用的决策架构。实现了 sequence、selector、retry、condition、parallel 五种节点类型，支持顺序执行、失败回退、条件判断、重试等逻辑，并为此做了 SVG 流程图渲染。 两个根本问题 但随后发现两个根本问题： 让 LLM 建树难度很高。 LLM 建普通任务列表已经容易出错，建一棵结构正确、逻辑合理的行为树更难——节点类型选择、嵌套结构、条件语义，每一步都容易出偏差。 渲染流程图难度也高。 行为树是嵌套树形结构，和 DAG 的布局算法完全不同，需要手写递归布局算法才能正确渲染。 结论 行为树的核心价值——条件分支、根据结果重新规划——其实可以用更简单的方式实现：brain agent 在任务末尾根据验收结果决定是否追加新任务。本质上是同样的能力，但对 LLM 的要求和系统复杂度都低得多。 行为树分支因此未合并，回到了 DAG + brain agent 动态追加任务的路子。 tbrain 源码在这里：tbrain 最兼容 tbrain 的 Agent 运行时是 tclaw，感兴趣可以去 tclaw 体验。
游戏看上去不错 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 体验。 ...
关于协议 第一个要想清楚的问题：agent 怎么和 tbrain 通信？ 一开始想过用 WebSocket，实时性更好。但想了想，任务调度对实时性要求没那么高，agent 每隔几秒来拉一次任务完全够用，换来的是协议简单、接入方便。就用 HTTP 了。agent 的工作流程大概是这样： 注册自己，告诉 tbrain 我是谁、能做什么，拿到一个 token 每 30 秒发一次心跳，证明自己还在线 每 3 秒拉一次任务，有活就认领 执行过程中可以上报进度，UI 上能实时看到 做完上报结果，或者上报失败并说明原因 tbrain 通过心跳判断 agent 是否在线。心跳超时的 agent 会被标记为离线，手里的任务重新放回队列，等其他同角色的 agent 来认领，不需要人工介入。 任务计划谁来出 调度是确定性的，但"这个任务该怎么拆、交给谁"不是——这需要判断力。 有些场景流程是固定的，比如"先开发、再测试、再部署"，每步交给谁很明确，提前写死就行。但有些场景不好提前定死，需求一来，得先看看现在有哪些 agent 在线、各自能干什么，再临时决定怎么安排。 所以支持了三种模式： 静态模式：提交 Job 时自己写好任务列表和依赖关系，tbrain 照着跑。 AI 规划模式：只提交一个目标，brain agent 看到目标后自己规划出任务列表，发回给 tbrain 执行。 混合模式：骨架是静态的，某些步骤交给 brain agent 来决定怎么做。 任务失败了怎么处理 设计失败处理的时候，想了一下失败都有哪些情况：网络抖一下超时了、agent 做错了需要重来、碰到了没权限处理的情况需要人来拍板……这几种情况的处理方式完全不一样，不能一刀切。 最后让 agent 自己在上报失败时指定失败等级： 自动重试：瞬态错误，系统自动重试，不超过两次 打回重做：业务失败，打回上游任务重新来过 人工审核：需要人来决定，任务挂起等人处理 致命错误：整个 Job 直接失败 agent 自己最清楚为什么失败，让它定级比 tbrain 猜要靠谱。 ...
单进程的墙 重构之后的 agent 工具稳多了。但用了一段时间，新问题浮出来了。 所有 agent 都跑在同一台机器、同一个进程里。这意味着你没法把 coder 部署在开发机、tester 部署在测试机，让它们跨机器协作。不同机器上跑的 agent，没有办法互相知道对方，没有办法分工，更没有办法共同完成一个任务。 每个 agent 都是孤岛。 想真正做到多 agent 协作——不管 agent 在哪台机器、用什么语言写、跑在什么框架上——就需要一个独立的调度层，负责把任务分发出去，收集结果回来。 这就是 tbrain 最初的动机：一个专门的任务调度引擎，让分散在各处的 agent 能协同工作。 只做调度该做的事 开始设计这个引擎的时候，第一个问题是：它到底要做什么？ 最直接的想法是给它加上 AI——让它自己理解需求、自己拆任务、自己决定派给谁。但停下来想了一下，调度这件事本身，其实不需要理解任何东西。它要做的就是：task 1 完成了，通知 agent 去做 task 2；task 2 完成了，通知 task 3。就这些，纯粹是状态流转，机械的，确定性的。 那哪里需要 AI？继续想——需要 AI 的地方，是在任务开始之前：得有人把流程安排好，知道现在有哪些 agent、各自能干什么，然后决定先做什么、再做什么、交给谁。这一步需要判断力，是 AI 该干的事。 但这一步做完之后，后面的执行就不需要 AI 了。系统只要照着计划，按部就班地通知、等待、更新状态，就行了。 这么一推，结论就出来了：调度引擎本身不需要 AI，AI 只需要在开始的时候把计划交给引擎，剩下的事交给系统。 那 AI 去哪了 AI 没有消失，只是搬了个位置。 tbrain 里有一个叫 brain agent 的角色。它是专门处理"需要判断力"的事：理解目标、规划任务、决定顺序、处理失败。这些是 LLM 擅长的，就交给它来做。 但 brain agent 是一个外部角色，和其他 agent（coder、tester、researcher……）地位完全平等——同样是注册到 tbrain，轮询任务，上报结果。tbrain 不知道也不关心它内部用的是 Claude 还是 GPT，甚至不关心它是不是 LLM。 ...
下面是用 tbrain + tclaw 多 Agent 协作开发的挂机游戏： 一个听起来很合理的设计 做 AI agent 做到一定程度，你会开始嫌一个 agent 不够用。 写代码的事，交给 coder。做设计文档，交给 designer。整体协调，交给一个大管家 captain。每个人做自己擅长的，这不就是正常团队的运作方式吗？ 所以我给自己的 agent 工具做了一个消息总线。每个 bot 都注册在上面，bot 之间通过发消息协作，想让谁做事就 @ 它。设计上简洁，概念上直觉，感觉挺美的。 确实美了一段时间。 开车的时候用飞书和 captain 说一句需求，captain 帮我整理思路，觉得需要写代码就 @ coder，coder 内部再分工，architect 写设计、implement 写代码、tester 跑测试。我只管说，后面的事它们自己协调。那段时间我给这套东西取了个名字叫"咖啡"——一边喝咖啡，咖啡自己把活干完了。 好景不长 然后问题来了。被 @ 的 bot，自己也会去 @ 别的 bot，消息裂变，系统失控。 这段噩梦足足耗了三周，几十个分支，上百次提交，最后还是回滚了。细节就不在这里展开了——如果有兴趣，可以去看 tclaw 的开发故事，那篇写得比较完整。 简短结论：靠规则和提示词约束 LLM，本质上是在用不确定的方式解决不确定性带来的问题。这件事根本做不完。 放弃，重构。 重构之后 重构后的方案简单多了：不再有消息总线，改成调用制。用 list_categories 看看现在有哪些领域的 agent，用 list_agents 列出该领域下的具体 agent，再用 run_agent 让它去做事。被调用的 agent 做完返回结果，不能主动去找别人。控制权始终在调用方手里，不会有人越权乱插嘴。 这套方案稳了很多。但用了一段时间之后，碰到了另一堵墙—— 所有 agent 还是跑在同一台机器、同一个进程里。想在开发机上跑一个 coder，测试机上跑一个 tester，让它们协同，做不到。每个 agent 都是孤岛。 ...
让 AI 融入日常 桌面应用之外，tclaw 还支持通过飞书和微信直接和 agent 对话。 飞书 飞书有开放平台，可以创建自己的机器人。tclaw 接入之后，在飞书里和 tclaw 对话，就相当于在桌面应用里聊天，但可以用手机。 支持的能力： 发文字消息，agent 回复 发图片给 agent，agent 可以分析图片内容 agent 可以把生成的图片发回飞书 微信 微信这边不需要额外配置，在设置里开启微信，直接扫页面上的二维码登录，之后就可以在微信里和 agent 对话了。 图片输入与截图 桌面端也补全了多模态能力： 聊天框可以直接粘贴或拖入图片发给 agent 内置截图工具，可以截当前屏幕，裁剪、标注之后直接发给 agent agent 可以调用图片生成工具，生成的图片直接显示在对话里 图片生成 接了两个图片生成后端： Ollama：本地跑，不花钱，速度慢一点 外部 API：质量更好，按量计费 agent 可以在任务里直接调用图片生成，比如写完一篇文章顺手配一张封面图。 tclaw 提供 Mac、Linux、Windows 版下载，Mac 版支持最好，感兴趣可以去 tclaw 体验。 也可以先玩玩 tclaw 用 AI 做的几个小游戏：→ 点这里玩
能用只是开始 内核稳定之后，tclaw 已经能干活了。但"能用"和"好用"之间，有很长一段路。 用着用着，各种不顺手的地方就冒出来了。agent 生成的文档没法方便地看；上下文长了之后 token 烧得很快；只有命令行，想给别人用很难；文件多了之后找东西很费劲…… 接下来花了差不多一个月的时间，一件一件地打磨。 Wails 桌面应用 首先是 GUI。自己用命令行没问题，但如果想让更多人用，得有个像样的界面。 调研了一圈，选了 Wails——用 Go 写后端，前端是普通的 HTML/JS，打出来是一个原生桌面应用，体积小，对 Go 友好。最终打包出来的 Mac 应用只有几十 MB，不需要用户装任何运行时。 同一套 HTML，既可以跑在 Wails 桌面里，也可以用浏览器直接访问。 预览面板 agent 经常帮我生成文档、写 HTML 页面、画 mermaid 流程图。生成完要看效果，之前要自己去找文件打开，很麻烦。 做了一个右侧预览面板： Markdown 文件直接渲染，支持 mermaid 图表 HTML 文件直接在面板里预览网页效果 图片直接显示 还可以在预览内容上框选区域，加标注，直接发给 AI 问问题 文件浏览器 本地文件多了之后，找东西很头疼。做了一个内置的文件浏览器，可以快速搜索文件，并且直接在里面预览： Excel 打开直接显示表格 JSON/XML 显示树形结构，可以展开折叠 zip/tar 显示压缩包内容列表 SVG 可以缩放拖拽 PDF、图片、音视频都能预览 还加了文件格式转换和压缩功能，平时用得上的小工具基本都有了。 上下文管理 用 LLM 最头疼的问题之一是上下文窗口。对话长了，token 烧得很快，而且超出窗口就报错。 做了几件事： 自动剪裁：上下文快满的时候，自动把旧的 tool result 压缩，保留关键内容 保留读取位置：被剪裁的内容不是直接丢掉，而是记录偏移量，agent 需要的时候还能用 offset 继续读 cache 优化：加了多个 cache breakpoint，反复用的内容不重复计费 token 看板：侧边栏可以实时看每轮的 token 消耗，一眼就知道上下文用了多少 VSCode 风格布局 界面改版了一次，改成 VSCode 风格的 Activity Bar + Side Panel 布局： ...
问题出在哪里 消息总线那套方案放弃之后，我坐下来想了一下，问题到底出在哪。 根本原因是：消息总线是对等的，每个 bot 都可以给任何人发消息。这种自由度在人类团队里没问题，因为人有判断力，知道什么时候该说话、什么时候不该插嘴。但 LLM 不一样，它的"判断"是概率性的，今天遵守规则，明天又忘了。你加再多提示词约束它，它该乱的时候还是会乱。 既然对等通信管不住，那就换成单向调用——上级调下级，下级只干自己的事，不主动找别人。 新的设计 重构后的 tclaw，多 agent 协作的方式变成了这样： list_categories → list_agents → run_agent 用户或者顶层 agent 先用 list_categories 看看现在有哪些领域，再用 list_agents 列出某个领域下的所有 agent，然后用 run_agent 调用具体的 agent 去做事。 就像公司里的层级结构：你要找人做事，先找到对应的部门，再找到对应的人，直接下任务。这个人完成任务后把结果交回来，不会自己跑去找别的部门。 这样一来，协作的控制权始终在调用方手里，被调用的 agent 只负责完成自己的任务，不能主动发起新的协作链路。 pcclaw → tclaw 这次重构等于把整个架构重新来过，代码改动很大，干脆起了个新名字：tclaw。t 是我名字的首字母。 2026 年 4 月 21 日，tclaw 第一次提交。从 pcclaw 的第一次提交到现在，差不多过了五周。 新架构稳定多了。agent 之间的协作变得可预测，出了问题也知道去哪里找。当然也不是完美的——有时候顶层 agent 该调用专业 agent 的时候，它自己就把事情做了，没有委托出去。但比起消息总线那套，已经好太多了。 同期做的其他事 重构完内核，顺手把周边也整理了一遍： 把引擎抽成独立包，方便后续扩展 加了 WebSocket server，可以用浏览器访问 做了 WebGUI，有 tool call 展示 加了 session 历史侧边栏 做了 onboarding wizard，引导新用户配置 从只能在命令行用的小工具，开始变成一个像样的产品。 ...