我用 WorkBuddy 的多智能体团队模式搭了一张德州扑克桌：一个荷官引擎加五个 AI 玩家，每人一本人设策略，打了五局。赛果看起来很精彩——松凶型玩家 P2 五局累计 +1260，跟注站 P5 第三局就被打破产（-1000）。
一个诱人的结论几乎是现成的：“松凶碾压跟注站，激进策略赢了。”
这个结论是错的——或者说，是不负责任的。五局牌里两次是所有人弃牌的 walk 局（底池合计只有 60），真正打完的完整牌局只有三手，摊牌更是只发生了两次。为了搞清楚”五局牌到底能说明什么”，我把五个人设翻译成了启发式参数，用同一个引擎跑了 1000 局蒙特卡洛（v1/v2 策略各 500 局）。数据揭示了三件比”谁赢谁输”有意思得多的事。
最近用 topcoat 0.6 写了一个本地单机便笺应用 Stickies：增删改查、置顶、标签、全文搜索、回收站（30 天自动清理），外加多窗口 WebSocket 实时同步。项目本身还在实验期，但开发过程几乎全程在跟框架的”年轻”搏斗，积累的经验值得单独成文。
topcoat 是 tokio-rs 出品的一个很年轻的 Rust 全栈框架：服务端渲染 + $(...) 运行时表达式做客户端响应式，#[page]/#[route]/#[shard]/#[procedure]/#[component] 五个宏驱动。文档稀少、API 不稳定，很多行为要靠读源码和试错。本文按技术层组织，每个坑给出”现象 → 根因 → 修法 → 通用教训”。
topcoat 是 tokio 生态（tokio-rs 组织）出品的 Rust 全栈 Web 框架，官方 README 给自己的定位是 “The full full-stack framework for Rust”，并自称 modular、batteries-included（模块化、电池全含），核心目标是最小化样板代码、最大化生产力（simplicity and productivity）。生态位置上的对标物很直接——正如 Next.js 之于 React，topcoat 之于 Rust/tokio：服务端渲染、客户端响应式、服务端过程、组件库、模块化路由一应俱全，而且整个链路没有 Node 参与。
先说清楚这个框架的模型，后面看坑才有上下文：
$(...) 表达式是普通 Rust 代码：服务端求值用于初始渲染，同时被翻译成 JavaScript 塞进 HTML，浏览器端即时重跑、建立响应式绑定。无 wasm bundle、无客户端构建步骤。信号（signal）变化时，绑定的 DOM 自动更新，或触发服务端重新渲染某个区块。src/ 模块结构自动推断路由树（类似 Next.js 的 app router 文件约定），无需构建步骤；也支持 #[page]/#[route] 手动声明。#[page] 定义页面路由；#[route] 定义子路由；#[shard] 定义”服务端重查的视图块”——参数一变，浏览器请求服务端重渲染整块；#[procedure] 定义客户端可调用的服务端过程（对标 Next.js 的 server actions / API route）；#[component] 复用 UI 片段。topcoat ui 命令把组件源码拷贝进项目、可自由改——“batteries-included”的直接体现。【本文由 AI 辅助完成】
上篇《Everyday CLI开发经验谈》记录到 v0.10–v0.11 时代。此后两周，Everyday CLI 从 v0.13.0 迭代到 v0.18.0，跨了 11 个版本点。本文按「版本时间线 + 主题深挖」双线梳理这段演进，最后单独成章，分享这期间最有代表性的一类经验——在 WorkBuddy 沙盒不稳定性下的工程实践。
【本文由 AI 辅助完成】
一次完整的「看图建模 → 视觉验证 → 云端发布」体验记录：把一张东方明珠电视塔的照片，变成可交互的体素 3D 模型。
最近体验了 DeepSeek-V4-Flash-Vision-Exp，一个有视觉能力的模型。我给它出了一个有点意思的端到端任务：只看一张东方明珠电视塔的照片，用 three.js 做一个体素（voxel）风格的 3D 模型，再用 Playwright 截图做视觉验证，最后部署到 Cloudflare Pages，并加上可交互的相机。 这篇文章记录这个过程里模型的表现、我的观察，以及一些值得注意的细节。
我最近发现我在Workbuddy配置的“晨间提醒”定时任务执行时长有点久，经脚本化改造后得到了显著的改进。
“晨间提醒”定时任务的大致工作内容如下：
everyday timeline sync命令同步操作后，通过everyday cli工具获取24小时内的邮件、当天的日历事件和待办任务。github cli工具获取前一天的Github动态。AI Agent执行“晨间提醒”定时任务的效率瓶颈主要集中以下两个方面：
获取工具用法：AI Agent在每次执行任务时，往往都会重新通过everyday --help和gh --help命令获取命令行工具的用法说明。
类似地，AI Agent也会重新加载所需的Agent Skill并理解其意图和使用方式，做了很多重复的工作。
串行执行命令：虽然各个信息源的获取是相互独立的，但AI Agent还是会按照顺序一个接一个地执行这些命令，导致整体执行时间较长。某些Agent支持运行并行子Agent执行多个子任务，但由语言模型进行任务的分派和结果汇总的效率也不高，并且会消耗大量的Token。
考虑到我配置的“晨间提醒”定时任务的工作内容是相对稳定的，并且其涉及到的信息本质都可以执行命令行工具来获取，我让Workbuddy编写了一个Python脚本用于并行执行这些命令行工具获取原始信息，然后将结果汇总后再进行处理和生成报告，从而有效提升了执行效率并节省了大量Token。
我近期开发了一款Rust命令行工具Everyday CLI，
配合自带的Skill，
可为 AI Agent 提供便捷的邮箱、日历、RSS 订阅、笔记、待办事项及书签管理能力。。
我几乎全程在腾讯推出的 WorkBuddy 上进行开发，期间不断切换模型与工作流，推动项目逐步迭代至较完善版本，也积累了不少实践经验。
微软近期正式发布了WSL container CLI(wslc.exe)，可以直接在windows上管理Linux 容器，不必再安装Docker Destop或在某个wsl实例里安装docker ce。
wslc.exe随最新的wsl预览版发布，可通过wsl --update --pre-release命令升级。
wslc.exe的命令行语法与docker高度一致，开发者（以及AI Agent）可以使用熟悉的命令。
近期微信推出了官方的 Clawbot 插件和官方的 Openclaw Plugin，用于配置 Openclaw 连接。与此同时，其他 Openclaw 类工具也纷纷接入了微信 Clawbot。
我使用的 Zeroclaw 暂时还没有官方的微信 Clawbot 接入方案，不过可以通过 OpeniLink Hub 来间接实现 Zeroclaw 与微信 Clawbot 的连接。
OpeniLink Hub 是一个基于微信官方 iLink 协议的开源微信机器人（Bot）管理平台，同时也是一个 App 应用市场。
它主要提供以下能力：
我将自己的微信 Clawbot 连接到了 OpeniLink Hub，并安装了两个内置应用：
MCP Server
Runner
/agent 触发 Zeroclaw 中的功能
虽然微信的 Clawbot 对于 Markdown 消息、流式消息等功能的支持还不完善，但通过 OpeniLink Hub 的中转，Zeroclaw 的功能可以在微信中得到一定程度的展现,目前可以满足一些简单的消息交互需求。
在技术领域，2026年的第一季度属于OpenClaw，近期我也开始了自己的“养龙虾”之旅。
我个人非常不愿意在个人设备上给予AI过多的权限（比如屏幕读取和文件系统权限），所以选择了在一台云服务器安装“龙虾”。作为一个TypeScript实现的node.js服务，原版的OpenClaw需要消耗相当高的服务器资源（运行时占用1GB以上的内存）。考虑到我的云服务器只有4GB内存，我最终选择安装配置了zeroclaw（一个rust实现的轻量级OpenClaw同类产品）。
在现有架构下，我主要维护的是一个运行在 AlmaLinux ECS 实例上的后端服务：基于 FastAPI 构建，通过 Docker Compose 进行容器化部署。服务中包含多条 AI 对话类 SSE（Server-Sent Events）长连接接口。
随着用户规模增加，我逐渐发现一个现实问题：Docker Compose 在滚动发布和长连接共存场景下，几乎无法实现真正的零停机更新。容器重建过程中，SSE 连接被强制断开，用户体验受到明显影响。
在与 AI 进行多轮技术探讨后，我重新审视了技术选型。结论是：在当前规模与复杂度下，并不需要直接迁移到 Kubernetes。采用 Docker Swarm 即可满足零停机更新与滚动发布的需求，同时保持架构复杂度可控。
经过半天实践，我成功将服务从 Docker Compose 迁移至 Docker Swarm。以下是关键迁移步骤与问题记录。