Agent on 大飞的博客

tclaw（五）：接入飞书、语音、图片

Tue, 02 Jun 2026 05:00:00 +0000

让 AI 融入日常

桌面应用之外，tclaw 还支持通过飞书和微信直接和 agent 对话。

飞书

飞书有开放平台，可以创建自己的机器人。tclaw 接入之后，在飞书里和 tclaw 对话，就相当于在桌面应用里聊天，但可以用手机。

支持的能力：

发文字消息，agent 回复
发图片给 agent，agent 可以分析图片内容
agent 可以把生成的图片发回飞书

微信

微信这边不需要额外配置，在设置里开启微信，直接扫页面上的二维码登录，之后就可以在微信里和 agent 对话了。

图片输入与截图

桌面端也补全了多模态能力：

聊天框可以直接粘贴或拖入图片发给 agent
内置截图工具，可以截当前屏幕，裁剪、标注之后直接发给 agent
agent 可以调用图片生成工具，生成的图片直接显示在对话里

图片生成

接了两个图片生成后端：

Ollama：本地跑，不花钱，速度慢一点
外部 API：质量更好，按量计费

agent 可以在任务里直接调用图片生成，比如写完一篇文章顺手配一张封面图。

tclaw 提供 Mac、Linux、Windows 版下载，Mac 版支持最好，感兴趣可以去 tclaw-releases 体验。

也可以先玩玩 tclaw 用 AI 做的几个小游戏：→ 点这里玩

tclaw（四）：从能用到好用

Tue, 02 Jun 2026 04:00:00 +0000

能用只是开始

内核稳定之后，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 布局：

tclaw（三）：重构——换一种方式让 Agent 协作

Tue, 02 Jun 2026 03:00:00 +0000

问题出在哪里

消息总线那套方案放弃之后，我坐下来想了一下，问题到底出在哪。

根本原因是：消息总线是对等的，每个 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，引导新用户配置

从只能在命令行用的小工具，开始变成一个像样的产品。

tclaw（二）：多 Agent 协作，以及那三周的噩梦

Tue, 02 Jun 2026 02:00:00 +0000

一个 agent 不够用

pcclaw 能跑起来之后，用起来还挺顺手的。让它帮我写代码、查文档、跑脚本，基本的事情都能做。

我们平时需要专业的事交给专业的 agent，写代码有 coder，做设计有 designer，管任务有 captain。但问题是每次都要自己指定去找哪个 agent，用起来很麻烦。

能不能让 agent 自己知道该找谁？

消息总线的设计

当时的想法是：做一个消息总线，每个 bot 都挂在上面，bot 之间通过发消息协作。想让某个 bot 做事，就发一条消息 @ 它。

角色大概是这样分的：

captain：大管家，负责整理思路、拆解任务、协调全局
coder：负责开发，下面还有 architect、implement、review、tester 等子 agent
design：负责设计文档
content：负责内容创作
……

这套东西用起来有段时间感觉相当爽。我可以在开车的时候通过飞书和 captain 对话，让它帮我整理一个想法，captain 觉得需要技术方案就会 @ coder，coder 内部再分工，architect 写设计、implement 写代码、review 检查。我只需要说一句需求，后面的事 captain 去协调。

有段时间我迷上了让 pcclaw 开发 pcclaw。感觉挺厉害，但其实还是 claude 更强些。不过自家的孩子，总是最好的。

后来我给 pcclaw 取名叫"咖啡"——一边喝咖啡，咖啡自己就把活干完了的意思。

那段时间每天早上 6 点起床弄咖啡，弄到 8 点再洗漱吃饭，时间卡得很紧。路上也闲不住，一边开车一边用飞书和咖啡聊，想到什么就说，让它做调研、出方案，顺手 PUA 它让它好好干活。

那段时间晚上 1 点多才睡，第二天 4 点 20 就自然醒了——也不敢起来，怕一起来就睡不着了，毕竟还得上班。就躺着，脑子里转的全是给 pcclaw 加什么功能。

直到有天早上开车时候睡着了。感觉睡了 2 秒钟，眼睛睁开车已经偏了，还好刚下高速，车速不快，但还是挺后怕的。然后就老实了，7:30 起床，保命要紧。

tclaw（一）：过年玩 OpenClaw，玩着玩着就自己造了一个

Tue, 02 Jun 2026 01:00:00 +0000

过年

2026 年春节，OpenClaw 火了。

其实年前就已经有很多人在玩了，但我那时候忙，没时间搭理。正好赶上过年，难得有几天清闲，就把 OpenClaw 装上玩了一下。

这一玩就收不住了。整个过年，家人吃饭我在玩，大年初几我也忘了，反正就是一直在玩。

玩了一段时间，自然就开始好奇它内部是怎么工作的：这东西怎么知道该调用哪个工具？记忆是怎么管理的？提示词是怎么组织的？就让 AI 帮我分析了一下源码。

发现 pi-mono

顺着 OpenClaw 的源码往里翻，发现它的内核依赖一个叫 pi-mono 的东西。

去看了 pi-mono 的代码，感觉设计很精干。它不是一个框架，只提供必要的东西：一个 Agent 循环、工具调用、会话管理，仅此而已。没有编排 DSL，没有 workflow 引擎，没有各种抽象层。核心思想就是：

把工具给大模型，让它自己决定怎么解决问题。

然后看了一下 pi-mono 的作者背景，发现是游戏开发者出身。我自己以前也做过游戏，看到这里有点感慨——牛人到哪都是牛人。

pcclaw 诞生

年后大家都在玩 OpenClaw，不知道怎么抽风了，想用 Go 实现一下 pi-mono 内核，看看它到底怎么运行的。

我平时写 Go，OpenClaw 是 JS 的，语言上的迁移借助 AI 不是太大的问题，主要还是要把原理搞清楚。2026 年 3 月 15 日，pcclaw v0.0.1 第一次提交。

pcclaw，tclaw 的前身。

架构上参考了 OpenClaw 的分层思路：

tool → command → skill → agent

tool：最底层，封装基础操作（bash 执行、文件读写、网络请求等）
command：把 tool 组合成更高层的操作
skill：可复用的能力单元，agent 通过调用 skill 完成任务
agent：顶层，接收用户指令，通过 skill 和 tool 解决问题

Provider 层支持多种协议——OpenAI compatible、Anthropic 等，可以接不同的模型。内核沿用 pi-mono 的思路：LLM 发现问题 → 调用 tool → 检查结果 → 继续或结束。就是一个循环，没有更多了。