离线即自由：在26年开年搭建一座
Mar
20
Part.2讲啥
在Part.1中，我们成功点亮了家庭的“AI灯塔”。通过NVIDIA DGX Spark、llama.cpp和ComfyUI，我们让Qwen、Wan2.2等一系列强大的开源模型，安静地运行在自己的硬件之上。再用OpenWebUI这一层友好的“皮肤”包裹，我们得到了一个完全离线的、功能不输云端服务的“家庭豆包”。它可以聊天、识图、作画、剪辑视频，似乎已经足够美好。
然而，基础搭建完成，很快就会意识到，OpenWebUI只能说是用户友好的“离线豆包”，但“豆包”从来不是生产力工具。 真正的生产力，不在于有一个能对话的窗口，而在于如何让AI深度嵌入我们的工作流，成为撬动复杂任务的杠杆。
- 功能覆盖的断层：OpenWebUI无法调用我部署的所有模型能力。比如，它难以优雅地编排复杂的ComfyUI工作流（例如文生视频后的自动剪辑），也无法直接利用那些为特定任务（如代码重构、数据库查询），甚至大模型本身的多模态能力也无法全部发挥。
- 交互模式的单一：聊天界面适合发散式问答，但对于程序员来说，大量的工作是结构化的、指令式的，需要与终端、代码编辑器、版本控制系统高频交互。
- 0 “手”与“脑”的分离：AI能思考（LLM）、能感知（多模态模型），但它缺乏“手”——无法直接操作我的开发环境、执行代码、调试程序、管理服务器。
这正是我们迈入Part 2的理由：从“离线豆包”进化到“本地AI生产力堡垒”。我们需要为AI装上“手”和“脚”，让它不仅能“说”，更能“做”。这个阶段的核心，是构建一个真正属于程序员的 CUA（Computer-Using Agent，计算机使用智能体） 环境。而这一切的基石，正是我们已经在Part.1中搭建好的“躯体”——那些本地运行的强大模型。而在Part.2，我们要为这个躯体注入灵魂，打造它的“神经系统”和“运动中枢”。
我们将不再满足于在聊天窗口里“调教”AI，而是要通过Claude Code、以及大量自定义的Skill，将本地模型的能力管道化、工具化、自动化。我们要打通从“想法”到“代码”再到“成果”的最后一公里，让AI真正成为我们数字世界的延伸，成为那个7x24小时待命、懂你的技术栈、能直接动手解决问题的专属智能副驾。
这才是离线部署的终极意义——不是为了对抗网络，而是为了获得在数字世界绝对的行动自由。让我们开始动手，打造这座真正的生产力堡垒。
Claude As CUA
承接前言的构想，我们的本地CUA建设将直接选择Claude Code作为核心引擎。一般来说CUA希望有以下优势：
- 开箱即用的CUA能力：Claude Code本身已是业界公认的优秀CUA实现——它精妙的提示词与工具设计擅长理解复杂指令、自主规划步骤、操作终端、读写文件、甚至调用各类开发工具。选择它，意味着我们不必繁琐的调优智能体的“大脑”与“手脚”，可以直接站在巨人的肩膀上。
- 完美的开发者生态契合：作为程序员，我们日常的工作流围绕终端、各种脚本与API展开。Claude Code原生融入这些环境，各种命令行工具、Skill的形式自然融合，与我们熟悉的工具链无缝协作，几乎没有学习成本，上手即用。
让Claude Code直接使用本地的qwen模型非常简单，毕竟llama-server本身支持Anthropic风格接口，我们只需配置
在默认环境变量ANTHROPIC_BASE_URL中指向本地的llama-server地址，现在打开claude就是我们的本地模型了，也不需要任何登陆和网络操作。
打通全部本地Agent能力：CUA的眼睛
虽然Claude Code已经足够好用，但是要作为一个完整的CUA，仍然有一大批基建能力需要打通。它目前像一个顶尖的“终端操作员”，但距离真正的“数字世界代理人”还有很长的路要走。目前已经进行大打通工作分为以下几个部分：
多模态能力
本地部署的 llama-server 大模型多模态能力无法直接与 Claude 官方 API 打通。为让 Claude 的视觉理解能力可被 skill 系统调用，构建了一个基于 OpenAI 兼容格式的中间层接口。本质上就是通过 HTTP 请求将图片 Base64 编码发送至本地 llama-server（127.0.0.1:8001），解析返回的文本或坐标结即可。
关键逻辑如下：
这个任务流不但可以进行通用的图片内容理解与问答（如描述图片内容、回答关于图片的问题），还可以进行目标检测与定位，通过识别图片中特定对象并返回其边界框坐标（bbox_2d）和中心点（center），实现精准的对象区域定位。
这个能力对于图像编辑与GUI自动化尤为重要，它是整个CUA的眼睛。
扩散模型能力
在集成 Claude Code 与 ComfyUI 的过程中，主要面临三大核心挑战：
- 流水线管理与节点更新混乱：ComfyUI 的工作流本质上是复杂的节点图，每次更新节点或切换工作流时，都需要手动维护大量的 JSON 配置和依赖关系。节点版本变更导致的工作流失效问题尤为突出。
- 强依赖接口调用的复杂性：ComfyUI 的 API 调用需要处理队列 ID 追踪、任务状态轮询、结果获取等多个步骤。直接通过 Claude Code 进行这些操作会导致代码臃肿且容易出错。
- 异步任务管理的困难：图像生成任务通常是长时间的异步过程，Claude 需要保持连接等待结果，这会导致超时问题，同时多任务并发时的状态管理也非常棘手。
实际上我我采用了脚本封装+skill闭环的策略来解决上述问题：创建专门的 Python 脚本，将完整的 ComfyUI 操作封装在内。脚本内部维护了固定的节点模板和工作流配置，Claude Code 只需要调用这个脚本，无需关心具体的节点结构。脚本执行完成后，直接返回本地文件路径或处理结果，Claude Code 可以立即使用这些结果进行后续分析，无需处理异步状态。
如：
我们为每一个流程均创建了脚本，api_image2video.py api_text2image_forvideo.py api_imageedit.py api_text2image.py
浏览器操作与手机操作：CUA的手脚
浏览器操作：Agent Browser Skill
在Linux上构建CUA，首先绝大部分GUI操作比如是浏览器，它完美解决了Linux生态碎片化带来的适配难题。作为跨平台的“元应用”。因此Agent Browser技能至关重要。面对需要JavaScript渲染、维持登录态或处理分页的现代网页，单纯的命令行工具无能为力，而浏览器技能则打通了从系统底层到服务的最后一公里，让CUA真正具备像人类一样在复杂Web应用中完成自主任务闭环的能力。
- 实际方案上我选择了 https://agent-browser.dev/skills
这是一款基于Chrome引擎的Agent浏览器操控工具。它通过命令行直接驱动浏览器执行点击、填表等操作，让AI拥有真实的网页交互能力。它的核心优点有两个：
- 原生兼容：基于Chrome底层协议，能完美处理现代网页的JS渲染和动态加载，抓取数据更稳定可靠。
- 极度省“脑”：不是把整个网页源码扔给AI，而是经过智能剪枝，只提取核心的交互元素和文本返回给大模型，能有效减少高达90%以上的Token消耗，运行成本更低，响应速度更快。
- 极简运行：支持Headless（无头）模式，完全在后台运行，不依赖任何图形界面或浏览器插件，特别适合部署在Linux服务器上，资源占用低。
对比其他竞品（Playwright CLI，DevTools MCP，openClaw方案）目前是一个相对合理的选择。
手机操作：Docker + Mobile MCP
为什么在有浏览器能力的同时搭建手机CUA？
- 本质上是为智能体打造一个跨越生态边界的"数字外挂"。Linux与浏览器的操作能力虽强，但主要局限于办公、开发与信息获取场景，而Android作为全球覆盖最广的移动端生态，承载了社交、生活服务、IoT控制、即时通讯等海量高频应用。通过在Linux上虚拟化Android环境，CUA能够直接操作微信发送消息、点外卖、控制智能家居，甚至模拟手机应用上的复杂交互流程，极大地拓展了智能体的应用疆域。
- 这种架构让CUA不再是仅限于桌面端的"办公助手"，而是真正具备处理现代人数字生活全貌能力的"生活管家"，使其行动能力从键盘鼠标延伸至指尖滑动、从网页数据延伸到App内服务，从而大幅提升智能体的实用性与泛化能力。
手机模拟环境上，选择了：https://github.com/remote-android/redroid-doc ，它对ARM PC有较好的兼容性。
作为辅助自动化，同时安装了https://github.com/senzhk/ADBKeyBoard ，通过一个简单的shell就可以非常强的兼容性的输入信息（否则中文、emoji输入多少有问题）。
大模型能力结合上使用了https://github.com/mobile-next/mobile-mcp 。不过它本身下层就是调用的adb，实际上大多都是混合使用。
值得一体的是Agent Browser与Adb查阅浏览器的原理本质上都是获取页面的DSL描述，提取文本、链接、按钮等元素，识别可交互元素。这样做确实节省token并且高效，但是对于页面复杂度高或者易用性差的页面，却经常无法准确识别出目标交互元素（比如一些纯icon按钮）。
- 此时，上文提到的多模态图片理解能力成为一种补充，利用元素查找能力，我们完全可以用类似于以下提示词来强制利用多模态完成自动化：
来构成基于本地多模态图像自动化操作。
其他CUA常见能力：CUA的内脏
自进化能力-Skill管理与自动更新：
- 虽然腾讯不得人心，但是skillhub确实好用：https://skillhub.tencent.com
自记忆能力-Agent记忆&向量数据库：
- https://github.com/thedotmack/claude-mem
- 使用了著名的claude-mem，一个非常聪明的开源项目，它让 Claude Code 拥有了“长期记忆”。它的核心亮点是向量检索。简单来说，它把你所有的开发过程（比如修过什么 bug、写过什么代码）都存下来，并且能像搜索引擎一样，通过理解语义来精准找到你需要的历史信息——即使你记不清具体的关键词，它也能通过“意思”把相关内容找出来。
定时任务能力：
- 为Claude Code添加定时任务能力，核心是结合crontab和Claude的headless模式（-p参数）。本质上就是将Claude Code当作一个命令行工具，通过-p传递prompt让它非交互式执行任务，再用crontab按计划自动调用即可。如
- 同时，添加了一个修改过的crontab，让claude可以自己添加/管理维护AI任务。
- 当然Claude本身也有loop能力，但是相较于通过外部调度crontab调用 Claude Code，其内置的loop能力在设计上由于强依赖claude终端的开启状态与过期时间，会让他完全侵占工作区，不适合作为可靠的长期自动化方案。
多Agent与多角色：
- 通过为不同的工作区（工作目录）分配独立的 CLAUDE.md 配置文件，为每个Claude Code实例注入截然不同的项目知识，来搭建多个不同角色的专属AI代理。
- 利用多角色分摊不同类型任务，从根本上解决了单代理模式下上下文窗口过载导致的“遗忘”与“注意力分散”问题，让每个代理都能在其狭窄的职责领域内保持高度专注与深度推理，从而实现真正的专业化分工与线性效率提升。
- 目前划分出了3个工作区：通用工作区，Coding专家工作区，视频生成专家工作区。
为什么不是直接使用OpenClaw
开始在claude上搭建以上工具时确实是openClaw第二次火的时候，但是我已经在一月时体验过clawbot了，从当时的角度有以下考虑：
- OpenClaw之所以火，本质上是以“开箱即用”的C端产品逻辑，封装了强大的B端执行能力，并通过开源生态构建了独特的信任基础。过去一年内cua的产品多的去了，但是要么是生态不闭环，要么是大厂作品有隐私隐患或者强绑定生态。OpenClaw确实是离线AI堡垒的优秀选择。
- 但是另一个角度，OpenClaw强依赖的skill生态本身就是和claude共享的，开箱即用对于程序员来说并不是多大的收益，OpenClaw自带的CUA能力也并不够用仍然需要大量skill和自定义能力补充。从这个角度来说，用OpenClaw还是Claude作为agent基座区别并不大了。同时个人的角度作为程序员也非常清晰自己的需求确实如此。
同时有两个考虑在于：
- claude的系统提示词与任务/plan系统在本地模型中尺寸模型下，考虑到上下文长度与对于注意力塌陷极限，Claude“应该”比OpenClaw更有效。
- 在2月的时间点，OpenClaw的国内机器人最后一公里还不够完善，安全问题较为突出。因此当时的决策是Claude优先。
如果现在（3月中旬）来看，OpenClaw或者其他轻量级本地CUA竞品（如NanaClaw也是以claude为核心，ZeroClaw安全高性能）。
另外，此处还有一些个人观点，cua这种东西业界都做了两年了。Manus也是cua，云端cua；豆包手机ai也是cua只是面向移动端。cua之前一直做不起来的两个原因：
1. 云端cua没那么好用，涉及资源同步，生产力能力受限，对应Manus的问题。
2. 大厂的本地cua，把用户本地完全交给大厂，隐私和垄断角度不放心，对应豆包手机的问题。
OpenClaw或者其他轻量级本地CUA竞品的突破是，它是第一个非大厂开源的完善本地cua，完全规避了以上两个问题。现在OpenClaw火了，有大厂回来摘桃子，把CUA产品随便改改名字套上OpenClaw的skill蹭热度，但我个人还是建议坚持初心，本地+开源的CUA才是正道。
最后一公里：CUA与人对话
无论如何，不管是不是OpenClaw，现在的CUA（Computer Use Agen）确实普遍采用远端控制 / IM控制 / 手机控制。主要是为了解决一个核心矛盾：让AI在获得足够操作权限以完成复杂任务的同时，最大限度地降低对用户本地设备的侵占、保障数据安全，并提升系统的稳定性和易用性。
既然我们Agent的基座采用Claude Code，因此我也review了一下业界现有的方案：
- 官方的Claude Code Remote Control：要收费的，再见
- Happy Coder：强依赖外部服务，稳定性不佳。同时界面对多模态操作不友好。
- Claude Code UI / CloudCLI 等 Web 项目：不够成熟，甚至不如OpenWebUI。
结论上似乎听起来都不太好用。
在了解openClaw的过程中，我们已知国内最方便的方式确实是微信/QQ/飞书，其中QQ与飞书的限制较低，因此将整个QQBot API投给AI，让AI自己迭代出了一个简易的qqbot server：
- 整个方案的核心思想是通过一个中间层的 HTTP 服务作为消息中转站，将 QQ 的即时通讯能力与本地 Claude CLI 的智能处理能力连接起来。
- 消息接收与签名验证机制：当用户在 QQ 中发送消息给机器人时，QQ 的服务器会以 HTTP POST 请求的方式将消息推送到一个预先配置好的 webhook 地址（通过内网穿透绑定到外部合理的https域名上）。这个环节最关键的挑战在于如何确认请求的真实性和完整性，防止恶意用户伪造请求。QQ 机器人采用的是 Ed25519 数字签名方案，这是一种基于椭圆曲线的现代签名算法，相比传统的 RSA 或 HMAC 方案具有更短的签名长度和更快的验证速度。AI快速的基于npm的开源库完成了这一部分。
- 本地 Claude CLI 的调用方式：桥接方案的核心目标是将用户消息传递给 Claude 并获得响应，Claude CLI 提供了两个关键参数来控制会话行为：-c 参数表示连续模式，会基于之前的对话历史继续对话；-p 参数则是单次提问模式，会在提示词后面附加用户的问题。连续模式的实现逻辑是维护一个全局的时间戳变量，记录上一次消息的到达时间，如果两条消息的时间间隔在 30 分钟内，就认为是同一个对话的延续，使用 -c 模式调用；超过这个时间则视为新对话，重新注入 system prompt。
- 附件处理与文件回传机制：现代聊天场景中，图片、文档等附件是非常常见的需求。QQ 机器人支持在消息中携带 attachments 字段，包含文件的 URL 和文件名。接收端服务器使用 HTTP 客户端下载这些文件。对于 Claude 生成的结果文件，方案采用了一种巧妙的标记机制：Claude 在输出中会包含类似  的 Markdown 格式标记，服务器解析这个标记来提取文件路径，然后将这些文件作为独立的富媒体消息发送给 QQ。这个方案的优势在于：不需要在 Claude 端做任何定制开发，只需要约定一个输出格式即可；同时文件消息和文本消息分开发送，保证了消息的可读性。
- 主动消息推送机制： 在日常使用中，很多时候并不仅仅是被动响应用户的请求，而是需要主动向用户推送信息。比如定时提醒、系统通知、定期报告等场景，都需要机器人主动发起消息发送。这个需求引出另一个关键模块：send_message.js，这是一个独立于 webhook 服务器的命令行工具，专门负责向 QQ 用户主动推送消息和文件。这个模块的设计核心在于一个巧妙的消息缓存机制。当 webhook 服务器收到用户消息时，会将这条消息的详细信息（包括用户的 openid、消息内容、时间戳等）序列化并写入一个名为 cache_message.json 的文件中。这个文件实际上充当了一个临时的"最近联系人"存储器。当需要主动发送消息时，send_message.js 读取这个缓存文件，提取出最近与机器人交互过的用户 openid，然后将消息发送给这个用户。
结果上，基本上只要打通文件的上下行，配合上合适的会话管理，ChatBot就能很有效的运作起来了
（右键新标签打开大图，可以看到机器人人设 + 普通shell操作 + 多模态输入 + 多模态输出）
养Claude：Skill进化
在生产力 Agent 的世界里，通用CUA能力提供了广度，而是那些高度面向特定流程、深度打磨过个人习惯与偏好的 Skill。它们可能是：
- 独有的复杂 AIGC 产出链路（从选题→提示家族→多轮迭代→格式后处理）
- 最常操作的 App / 浏览器自动化路径（登录态维持、异常兜底、跨页面状态传递）
- 反复执行的定时巡检闭环（数据采集→内容判断→多渠道记录）
这些 Skill 进化得越具体、越贴合实际生活工作链条，就越能把 Agent 从“帮忙做事”进化为“替你长出肌肉记忆”。当 Agent 开始真正“像你一样思考下一步该干什么”，生产力才真正开始指数级放大。
话又说回来，OpenClaw叫做“养”龙虾，是一个非常形象的说法，这不仅仅是一个昵称，更精准地概括了使用这款AI工具的全过程——它就像养一只真正的宠物或养一盆植物一样，需要投入时间、精力和资源去部署、调教、投喂和维护技能，让只会基础技能的CUA沉淀为符合自己实际生活工作链条的超能力Agent。
因此在这个段落我列举完全在本地模型下进行完成的2个Skill成长的例子。
前提：为什么要让skill进化
当然，我们总是认为在基建足够的情况下（比如我们的CUA已经可以自由操纵浏览器和手机了），Agent是万能的大模型什么都能做到。但是在Agent的生存周期中，无约束的“自由”往往意味着系统性的低效。让Skill持续进化，本质上是一场针对上下文空间和计算资源的极限压榨。
1. 为了CUA任务质量：这是对抗上下文腐烂（Context Rot）的必然手段。未经打磨的原始调用链或冗长的ReAct轨迹，如同在有限的上下文中堆砌垃圾数据。每一次重复的常识性推理、每一次对工具用法的重新摸索，都在稀释真正关键的业务信息。特别是目前我的本地是一个Qwen 35B尺寸的中等规模模型，即使确实支持200K上下文，相关问题必然会放大。Skill的进化，就是将那些原本需要长篇大论描述的步骤，压缩成高度抽象的参数化指令。这不仅释放了宝贵的上下文窗口，更让模型的注意力像激光一样聚焦在当前任务的独特事实上，极大缓解了长程记忆的混淆与丢失。
2. 为了CUA执行效率：终结时间与算力的浪费。大模型在陌生领域的每一次试探性摸索，在燃烧GPU时钟周期的同时，也是对AI执行效率的折损。如果每次调用计算器都要重新“思考”按哪个键，每次查询数据库都要重新“理解”工具的操纵命令，这不仅是算力的巨大浪费，更是对响应延迟的放纵。Skill的进化，本质上是将探索固化为经验，将经验封装为肌肉记忆。它让Agent从“牙牙学语的婴儿”培养为“训练有素的专家”，拒绝在重复劳动中做无用功。
微博发布者skill：内化于心，外化于行，去粗取精，去伪存真
原始状态：我在docker Android设备上安装了微博国际版，希望大模型能探索出帮我自动发布微博（文字消息+上传图片）的方式。给到提示词：帮我打开微博App（包名com.weico.international），并且发布一条消息（文字+图片），并且利用skill_creator沉淀为skill
1. AI尝试使用mobile mcp的能力（本质上还是adb） 与 直接调用adb。打开微博app，并且开始利用dsl浏览能力在界面上浏览寻找发布微博的入口。并且浏览到更深的页面。——但是大模型其实不太能理解，画面右下角的的按钮点开就可以发布微博了。随着无意义的对微博更多content的点击导致的上下文膨胀，任务失败。
2. 引导大模型“使用understand_image的能力在界面截图中查找疑似发布入口”，经过几轮提示，大模型利用多模态这双眼睛终于进入了微博发布页——当然，在大模型的上下文里，它其实只是知道了在微博首页点击某个坐标进入的另一个页面“应该”是微博发布页。
3. 来到发布页面，大模型还是一脸茫然，国内的App并不会做很好的无障碍功能的accessibility标注，希望大模型直接从当前界面dsl视角查看到上传图标确实强人所难了，依旧提示利用多模态去探索界面获得界面功能坐标。
第一次进化：在手动带领大模型切实走通了一次发布流程后，是时候让ai沉淀skill了。给到以下要求：
- 流程化优先：请严格描按照先做什么再做什么的逻辑结构进行梳理。每一步动作必须是明确的动词短语（例如：“打开控制台”、“输入命令X”、“对比结果Y”），而不是描述感受或泛泛而谈。
- 规避歧义：在执行过程的描述中，必须包含关键节点的判断条件（if...then...）。例如：“如果页面报错404，则执行步骤3.1；如果报错500，则直接联系运维”。
- 专注执行：除非我明确要求背景说明，否则你的回复中不要包含过多的背景铺垫、价值感慨或发散性的建议。请专注于“如何做”以及“简单的结果描述”。
对于上文描述的分析过程，“使用understand_image”这样的动作在执行过程中根本不需要，只需要按照刚走通的过程执行就好，因此得到了如下关键skill逻辑：
经过其他边界case与skill提示词调整，以上skill已经可以让CUA较为稳定的运行了：
但是实际用起来，很快也会注意到以下问题：
- 执行速度慢，效率低下，每一步都要“想”：每点一下屏幕，Agent都要调用大模型分析截图、思考下一步，这个过程通常需要几秒钟，原本1分钟不到固定时间能跑完的流程，会被拖到3分钟甚至更长。
- 稳定性差，易受干扰，特别是我们的本地模型不够强劲，多少会有较大的幻觉率，本身Agent可能因为温度参数或界面微小的变化而走出不同的路径，大量的多轮大模型调用风险导致整体的成功率急剧下降，
就以上因素的共同作用下，假设我希望一口气发布10条微博，很快就会面临长上下文注意力衰减，完蛋。
第二次进化：希望skill稳定快速的执行每个相对明确的流程，最合理的方案其实是让 Agent 写 “剧本”，然后让电脑去表演，远比让 Agent 亲自即兴表演要稳定和高效得多。
- 引导AI不要自己逐个执行skill中的流程描述，而是将流程写为一个shell，AI执行shell完成任务。
- 当然也给予AI修改shell的权限，遇到shell执行错误自行修复。
- 同时shell作为skill的一部分缓存在项目中，后续优先调用shell，这也算是skill自我成长的一部分。
这样的skill修改后，我们得到了AI翻译的shell流程：
此时，我们的skill如果没有意外，主要任务就是传参数给shell，执行发布即可。Agent的在skill中的职责进化得极其清晰和纯粹：
- 思考与执行的解耦：AI的职责被限定在“决策层”——根据用户需求决定“发什么内容”、“配什么图片”、“选择哪个话题”。而“如何点击”、“如何等待”、“异常重试”这些执行层的复杂度，完全下沉到Shell脚本中。实际执行时的AI不再需要关心像素级的操作，只需要关心业务逻辑。
- 关注点分离：CUA可以分别聚焦两个世界——skill执行时AI世界专注于语义理解、内容生成、决策准确性；skill迭代进化时专注于执行鲁棒性、速度优化、容错机制。两者通过简单的参数接口通信，互不干扰，大大降低了系统的维护成本和出错概率。
用相同的思路，我还同时维护起了一个定制的懂车帝图文发布skill，用qqbot均可简易操作。
视频生成专家skill：一生二，二生三，三生万物
原始状态：现有的基建上利用comfyui skill，拥有完整的文生视频能力。具体下来，引入的扩散模型里并没有引入t2v（text to video）模型，而是利用t2i模型与i2v模型拼接出来的t2v流程，用更好的text to image模型来控制首帧或者首尾帧图像，进而控制更好的生成video。
但是毕竟是开源视频模型，一旦和闭源模型比起来，比如和流行的seedance2.0比，不包括扩散效果本身的缺点，显著的能力缺点就一大堆：
- 多镜头长视频能力：开源模型通常只能生成5秒左右的单镜头、单场景的视频片段，难以理解或生成包含多个机位切换的复杂叙事；而 Seedance 2.0 能像导演一样一次性规划并生成多角度镜头组合，生成更长的视频片段。
- 画面一致性：开源模型在生成较长或较复杂内容时，容易出现角色面部特征变化、服装细节丢失或穿模等问题；而 Seedance 2.0 能通过多模态参考，确保人物和场景在多镜头切换中保持高度一致。
- 叙事能力：开源模型本质上是一个素材生成器，擅长单点画面呈现，缺乏对故事情节的整体理解和规划；而 Seedance 2.0 具备更强的叙事连贯性，能根据详细脚本生成具有明确起承转合的短视频故事。
本地的模型已经是开源顶尖水平了，虽然可以自己训练lora来解决一部分问题，但是通过skill应该也能对整个流程进行一定程度的提升。
第一次进化：一拆三
让AI对目前的t2v（t2i + i2v）流程，利用skill-creator拆解为了3个新的skill：
- skill1：镜头拆解+提示词流程：将用户的意图转换为多个镜头，为每个镜头单独生成t2i与i2v环节的提示词，并且储存到markdown中。
- skill2：批量t2i流程：让ai对每一个镜头的内容执行t2i。
- skill3：视频生成与合成流程：让ai对每一个镜头执行i2v，并且将最终生成的视频片段组成一个长视频。
第一次进化，我们让我们的t2v能力得到了多镜头长视频叙事的能力，skill-creator skill能很好的引导本地模型对每一个环节“臆想”出足够的细节，让每一个skill看起来很充实。然而实际执行起来，这次skill一拆三看起来并没有那么好——镜头平淡结果上叙事并没那么连贯，生成效果一致性非常差（虽然长期看如果不是在整个流程的扩散模型潜空间注入一致性信息，类似于seedance2.0做的，比如注入统一的Image Embedding）。
- 一拆三并不是终点，而是起点。
第二次进化：skiil1-短视频剧本专家与扩散模型提示词专家
我们拆分出来的三个skill中，skill1聚焦的剧本的编写与提示词的编写——单独从这个角色看，其实是一个偏向于文本AIGC专业性非常强的任务。因此在skill1的迭代中，进行了以下调教工作：
1. 让AI从skillhub中搜索并下载了数个短视频剧本skill，并且考虑到我们i2v的场景（比如生成20秒左右的长度的同一个内容的视频），结合在一起生成新的剧本控制skill描述，并且加入了人设（剧本专家 / 专业编剧）。
2. 进行角色与场景一致性提升的建设工作，作为剧本专家，在编写剧本的同时会编写详细的角色设定与场景设定，并且可以根据输出或者直接生成出相关的印象图像。
3. 进行提示词专家建设工作，从wan2.2，flux等相关博客上拷贝了大量的提示词生成建议，融入了skill中。
4. 同时类似于plan-with-files，总是沉淀输出相关产物。
以上工作下来，我们的skill1进化成了相对完善的状态，以这个case为例子。输入提示词：
skill的产出会得到非常详细的设定文档与脚本设计。
第二次进化：skill2-分镜脚本专家，用于将分镜脚本转换为分镜图像
对于生成出的详细的文本文档，skill2将文本转化为高度一致性的分镜图像，简单的文生图看来不行了。在AI的引导下，我们得到了如下思路：
拆解任务，分镜图像“由文生境，由境生人，由人成事”。不再尝试让AI一次性生成包含所有复杂元素的最终图像，而是将一个复杂的任务分解为两个更可控的子任务，并引入一个关键的中间状态——角色参考图。
- 解耦角色与场景：认识到一个复杂的画面是由“背景（场景）”和“前景（角色）”两部分构成的。将二者分开处理，可以避免AI在生成复杂画面时顾此失彼。
- 建立角色“视觉锚点”：在生成任何镜头画面之前，先为每一个角色建立一个唯一的、标准的视觉形象（角色参考图）。这相当于为后续所有涉及该角色的生成任务提供了一个“视觉锚点”，从根本上解决了跨镜头角色一致性的问题。
- 分层生成与组合：先专注于生成符合镜头语言要求的、高质量的“空场景”（不包含角色），然后将事先准备好的“角色”形象，通过图像编辑技术，精确地“放置”到场景中，并按照脚本要求执行相应的动作。
刚才的case，我们对应生成了如下的分镜图像结果：
skill3并没有做更复杂的进化（前期做好了，i2v的流程其实很轻量级），刚才这个case经过skill3后，就得到如下视频：
（在各个在线扩散模型都拒绝名人甚至真人生成视频的现在，离线的魅力也在于此）
第三次进化与长期进化
前两次进化，我们解决了“从无到有”（原始状态）和“从有到精”（Skill1&2的深度优化）的问题。但当前的流程本质上是线性的：剧本 -> 分镜 -> 视频合成。这种方式在处理复杂场景、多角色、长叙事时，仍然会遇到瓶颈，比如一个环节的卡顿会影响全局，或者在更精细的一致性控制上力不从心。
- 第三次进化的核心1是：考虑到本地中尺寸模型的能力，将这个“全能编剧/导演”的线性工作流，升级为一个由多个专业Agent构成的“导演组”，在独立任务流执行并行协同工作。
- 同时我们之前的一致性主要聚焦在角色上。第三次进化，我们要将这种控制力泛化到场景中的所有元素。从skill流程继续细化的角度，从“角色一致”到“道具一致”，从“视觉一致”到“风格一致”，完美整个t2v流程。
总结起来，这一skill进化路径的本质，是用流程的系统性，对冲模型的不确定性。不要指望一个skill解决所有问题，而要用多个skill / agent 的协作、多个环节的咬合、多次复用的积累，让整体能力超越单体上限。AI的进化，不只是模型参数的膨胀，更是系统架构的精细化——在模型能力的天花板下，用流程设计撑起应用的落地空间。
接下来 / Todo
这篇分享主要写了一些Agent / CUA的搭建与进化的过程。我们的探索主要集中在提示词工程/Skill的边界拓展上。通过精心设计的Tools ReAct与Few-shot，引导CUA/大模型在个人需求的场景下表现出了一定的专业性和任务拆解能力。但是大模型的成长不限于此，外部的“指令调优”是一方面，内部的“模型自成长”也是不可避免的一环。
这也是采购这款性价比极低的大内存N卡设备的主要原因之一——可以在离线数据堡垒里，对大模型 / 扩散模型进行微调（Lora & FFT），融入新的个人知识与技能，构建“私人数据飞轮”驱动自成长，可能会是Part3的topic。
在Part.1中，我们成功点亮了家庭的“AI灯塔”。通过NVIDIA DGX Spark、llama.cpp和ComfyUI，我们让Qwen、Wan2.2等一系列强大的开源模型，安静地运行在自己的硬件之上。再用OpenWebUI这一层友好的“皮肤”包裹，我们得到了一个完全离线的、功能不输云端服务的“家庭豆包”。它可以聊天、识图、作画、剪辑视频，似乎已经足够美好。
然而，基础搭建完成，很快就会意识到，OpenWebUI只能说是用户友好的“离线豆包”，但“豆包”从来不是生产力工具。 真正的生产力，不在于有一个能对话的窗口，而在于如何让AI深度嵌入我们的工作流，成为撬动复杂任务的杠杆。
- 功能覆盖的断层：OpenWebUI无法调用我部署的所有模型能力。比如，它难以优雅地编排复杂的ComfyUI工作流（例如文生视频后的自动剪辑），也无法直接利用那些为特定任务（如代码重构、数据库查询），甚至大模型本身的多模态能力也无法全部发挥。
- 交互模式的单一：聊天界面适合发散式问答，但对于程序员来说，大量的工作是结构化的、指令式的，需要与终端、代码编辑器、版本控制系统高频交互。
- 0 “手”与“脑”的分离：AI能思考（LLM）、能感知（多模态模型），但它缺乏“手”——无法直接操作我的开发环境、执行代码、调试程序、管理服务器。
这正是我们迈入Part 2的理由：从“离线豆包”进化到“本地AI生产力堡垒”。我们需要为AI装上“手”和“脚”，让它不仅能“说”，更能“做”。这个阶段的核心，是构建一个真正属于程序员的 CUA（Computer-Using Agent，计算机使用智能体） 环境。而这一切的基石，正是我们已经在Part.1中搭建好的“躯体”——那些本地运行的强大模型。而在Part.2，我们要为这个躯体注入灵魂，打造它的“神经系统”和“运动中枢”。
我们将不再满足于在聊天窗口里“调教”AI，而是要通过Claude Code、以及大量自定义的Skill，将本地模型的能力管道化、工具化、自动化。我们要打通从“想法”到“代码”再到“成果”的最后一公里，让AI真正成为我们数字世界的延伸，成为那个7x24小时待命、懂你的技术栈、能直接动手解决问题的专属智能副驾。
这才是离线部署的终极意义——不是为了对抗网络，而是为了获得在数字世界绝对的行动自由。让我们开始动手，打造这座真正的生产力堡垒。
Claude As CUA
承接前言的构想，我们的本地CUA建设将直接选择Claude Code作为核心引擎。一般来说CUA希望有以下优势：
- 开箱即用的CUA能力：Claude Code本身已是业界公认的优秀CUA实现——它精妙的提示词与工具设计擅长理解复杂指令、自主规划步骤、操作终端、读写文件、甚至调用各类开发工具。选择它，意味着我们不必繁琐的调优智能体的“大脑”与“手脚”，可以直接站在巨人的肩膀上。
- 完美的开发者生态契合：作为程序员，我们日常的工作流围绕终端、各种脚本与API展开。Claude Code原生融入这些环境，各种命令行工具、Skill的形式自然融合，与我们熟悉的工具链无缝协作，几乎没有学习成本，上手即用。
让Claude Code直接使用本地的qwen模型非常简单，毕竟llama-server本身支持Anthropic风格接口，我们只需配置
// .claude/settings.json
{
"env": {
"ANTHROPIC_BASE_URL": "http://127.0.0.1:8001",
"ANTHROPIC_AUTH_TOKEN": "none"
}
}在默认环境变量ANTHROPIC_BASE_URL中指向本地的llama-server地址，现在打开claude就是我们的本地模型了，也不需要任何登陆和网络操作。
打通全部本地Agent能力：CUA的眼睛
虽然Claude Code已经足够好用，但是要作为一个完整的CUA，仍然有一大批基建能力需要打通。它目前像一个顶尖的“终端操作员”，但距离真正的“数字世界代理人”还有很长的路要走。目前已经进行大打通工作分为以下几个部分：
多模态能力
本地部署的 llama-server 大模型多模态能力无法直接与 Claude 官方 API 打通。为让 Claude 的视觉理解能力可被 skill 系统调用，构建了一个基于 OpenAI 兼容格式的中间层接口。本质上就是通过 HTTP 请求将图片 Base64 编码发送至本地 llama-server（127.0.0.1:8001），解析返回的文本或坐标结即可。
关键逻辑如下：
// Base64 编码
const base64Image = fs.readFileSync(filePath).toString('base64');
// 构造 OpenAI 兼容请求
const payload = {
messages: [{
role: 'user',
content: [
{ type: 'text', text: question },
{ type: 'image_url', image_url: { url: `data:${mimeType};base64,${base64Image}` } }
]
}]
};这个任务流不但可以进行通用的图片内容理解与问答（如描述图片内容、回答关于图片的问题），还可以进行目标检测与定位，通过识别图片中特定对象并返回其边界框坐标（bbox_2d）和中心点（center），实现精准的对象区域定位。
Detect all [${targetObject}] in the image and give the coordinates. The format of output should be like {'box_2d': [x1, y1, x2, y2]}.这个能力对于图像编辑与GUI自动化尤为重要，它是整个CUA的眼睛。
扩散模型能力
在集成 Claude Code 与 ComfyUI 的过程中，主要面临三大核心挑战：
- 流水线管理与节点更新混乱：ComfyUI 的工作流本质上是复杂的节点图，每次更新节点或切换工作流时，都需要手动维护大量的 JSON 配置和依赖关系。节点版本变更导致的工作流失效问题尤为突出。
- 强依赖接口调用的复杂性：ComfyUI 的 API 调用需要处理队列 ID 追踪、任务状态轮询、结果获取等多个步骤。直接通过 Claude Code 进行这些操作会导致代码臃肿且容易出错。
- 异步任务管理的困难：图像生成任务通常是长时间的异步过程，Claude 需要保持连接等待结果，这会导致超时问题，同时多任务并发时的状态管理也非常棘手。
实际上我我采用了脚本封装+skill闭环的策略来解决上述问题：创建专门的 Python 脚本，将完整的 ComfyUI 操作封装在内。脚本内部维护了固定的节点模板和工作流配置，Claude Code 只需要调用这个脚本，无需关心具体的节点结构。脚本执行完成后，直接返回本地文件路径或处理结果，Claude Code 可以立即使用这些结果进行后续分析，无需处理异步状态。
如：
# text to image
prompt_text = sys.argv[1]
# 读取 prompt 模板
script_dir = os.path.dirname(os.path.abspath(__file__))
prompt_template_path = os.path.join(script_dir, "zimage_t2i_8step.json")
with open(prompt_template_path, "r", encoding="utf-8") as f:
prompt_template = json.load(f)
# 修改 45 节点的 input text 内容
prompt["45"]["inputs"]["text"] = prompt_text
result = queue_prompt(prompt)
prompt_id = result.get("prompt_id")
job = check_job_status(prompt_id)
if job is None:
print("生成失败")
return
output_path = os.path.expanduser("~/comfy/ComfyUI/output")
output_path = os.path.join(output_path, filename)
print(output_path)我们为每一个流程均创建了脚本，api_image2video.py api_text2image_forvideo.py api_imageedit.py api_text2image.py
浏览器操作与手机操作：CUA的手脚
浏览器操作：Agent Browser Skill
在Linux上构建CUA，首先绝大部分GUI操作比如是浏览器，它完美解决了Linux生态碎片化带来的适配难题。作为跨平台的“元应用”。因此Agent Browser技能至关重要。面对需要JavaScript渲染、维持登录态或处理分页的现代网页，单纯的命令行工具无能为力，而浏览器技能则打通了从系统底层到服务的最后一公里，让CUA真正具备像人类一样在复杂Web应用中完成自主任务闭环的能力。
- 实际方案上我选择了 https://agent-browser.dev/skills
npm install -g agent-browser
agent-browser install这是一款基于Chrome引擎的Agent浏览器操控工具。它通过命令行直接驱动浏览器执行点击、填表等操作，让AI拥有真实的网页交互能力。它的核心优点有两个：
- 原生兼容：基于Chrome底层协议，能完美处理现代网页的JS渲染和动态加载，抓取数据更稳定可靠。
- 极度省“脑”：不是把整个网页源码扔给AI，而是经过智能剪枝，只提取核心的交互元素和文本返回给大模型，能有效减少高达90%以上的Token消耗，运行成本更低，响应速度更快。
- 极简运行：支持Headless（无头）模式，完全在后台运行，不依赖任何图形界面或浏览器插件，特别适合部署在Linux服务器上，资源占用低。
对比其他竞品（Playwright CLI，DevTools MCP，openClaw方案）目前是一个相对合理的选择。
手机操作：Docker + Mobile MCP
为什么在有浏览器能力的同时搭建手机CUA？
- 本质上是为智能体打造一个跨越生态边界的"数字外挂"。Linux与浏览器的操作能力虽强，但主要局限于办公、开发与信息获取场景，而Android作为全球覆盖最广的移动端生态，承载了社交、生活服务、IoT控制、即时通讯等海量高频应用。通过在Linux上虚拟化Android环境，CUA能够直接操作微信发送消息、点外卖、控制智能家居，甚至模拟手机应用上的复杂交互流程，极大地拓展了智能体的应用疆域。
- 这种架构让CUA不再是仅限于桌面端的"办公助手"，而是真正具备处理现代人数字生活全貌能力的"生活管家"，使其行动能力从键盘鼠标延伸至指尖滑动、从网页数据延伸到App内服务，从而大幅提升智能体的实用性与泛化能力。
手机模拟环境上，选择了：https://github.com/remote-android/redroid-doc ，它对ARM PC有较好的兼容性。
sudo docker run -itd --restart=always --privileged \
--pull always \
-v ~/redroid-data:/data \
-p 5555:5555 \
--name redroid-test \
redroid/redroid:12.0.0-latest \
androidboot.redroid_width=1080 \
androidboot.redroid_height=1920 \
androidboot.redroid_dpi=480 \
androidboot.redroid_fps=30 \
androidboot.redroid_gpu_mode=auto \
ro.secure=0 \
ro.adb.secure=0 \
ro.allow.mock.location=1 \
ro.debuggable=1 \
ro.binderv=1作为辅助自动化，同时安装了https://github.com/senzhk/ADBKeyBoard ，通过一个简单的shell就可以非常强的兼容性的输入信息（否则中文、emoji输入多少有问题）。
adb shell am broadcast -a ADB_INPUT_B64 --es msg $(echo -n "$1" | base64 | tr -d '\n')大模型能力结合上使用了https://github.com/mobile-next/mobile-mcp 。不过它本身下层就是调用的adb，实际上大多都是混合使用。
值得一体的是Agent Browser与Adb查阅浏览器的原理本质上都是获取页面的DSL描述，提取文本、链接、按钮等元素，识别可交互元素。这样做确实节省token并且高效，但是对于页面复杂度高或者易用性差的页面，却经常无法准确识别出目标交互元素（比如一些纯icon按钮）。
- 此时，上文提到的多模态图片理解能力成为一种补充，利用元素查找能力，我们完全可以用类似于以下提示词来强制利用多模态完成自动化：
- 使用understand-image skill查找截图中 右上角的添加按钮 并且点击。来构成基于本地多模态图像自动化操作。
其他CUA常见能力：CUA的内脏
自进化能力-Skill管理与自动更新：
- 虽然腾讯不得人心，但是skillhub确实好用：https://skillhub.tencent.com
自记忆能力-Agent记忆&向量数据库：
- https://github.com/thedotmack/claude-mem
- 使用了著名的claude-mem，一个非常聪明的开源项目，它让 Claude Code 拥有了“长期记忆”。它的核心亮点是向量检索。简单来说，它把你所有的开发过程（比如修过什么 bug、写过什么代码）都存下来，并且能像搜索引擎一样，通过理解语义来精准找到你需要的历史信息——即使你记不清具体的关键词，它也能通过“意思”把相关内容找出来。
定时任务能力：
- 为Claude Code添加定时任务能力，核心是结合crontab和Claude的headless模式（-p参数）。本质上就是将Claude Code当作一个命令行工具，通过-p传递prompt让它非交互式执行任务，再用crontab按计划自动调用即可。如
0 3 * * * cd /workspecs && claude -p "审查日志并报告" --allowedTools "Read" "Bash" >> /var/log/claude.log 2>&1- 同时，添加了一个修改过的crontab，让claude可以自己添加/管理维护AI任务。
- 当然Claude本身也有loop能力，但是相较于通过外部调度crontab调用 Claude Code，其内置的loop能力在设计上由于强依赖claude终端的开启状态与过期时间，会让他完全侵占工作区，不适合作为可靠的长期自动化方案。
多Agent与多角色：
- 通过为不同的工作区（工作目录）分配独立的 CLAUDE.md 配置文件，为每个Claude Code实例注入截然不同的项目知识，来搭建多个不同角色的专属AI代理。
- 利用多角色分摊不同类型任务，从根本上解决了单代理模式下上下文窗口过载导致的“遗忘”与“注意力分散”问题，让每个代理都能在其狭窄的职责领域内保持高度专注与深度推理，从而实现真正的专业化分工与线性效率提升。
- 目前划分出了3个工作区：通用工作区，Coding专家工作区，视频生成专家工作区。
为什么不是直接使用OpenClaw
开始在claude上搭建以上工具时确实是openClaw第二次火的时候，但是我已经在一月时体验过clawbot了，从当时的角度有以下考虑：
- OpenClaw之所以火，本质上是以“开箱即用”的C端产品逻辑，封装了强大的B端执行能力，并通过开源生态构建了独特的信任基础。过去一年内cua的产品多的去了，但是要么是生态不闭环，要么是大厂作品有隐私隐患或者强绑定生态。OpenClaw确实是离线AI堡垒的优秀选择。
- 但是另一个角度，OpenClaw强依赖的skill生态本身就是和claude共享的，开箱即用对于程序员来说并不是多大的收益，OpenClaw自带的CUA能力也并不够用仍然需要大量skill和自定义能力补充。从这个角度来说，用OpenClaw还是Claude作为agent基座区别并不大了。同时个人的角度作为程序员也非常清晰自己的需求确实如此。
同时有两个考虑在于：
- claude的系统提示词与任务/plan系统在本地模型中尺寸模型下，考虑到上下文长度与对于注意力塌陷极限，Claude“应该”比OpenClaw更有效。
- 在2月的时间点，OpenClaw的国内机器人最后一公里还不够完善，安全问题较为突出。因此当时的决策是Claude优先。
如果现在（3月中旬）来看，OpenClaw或者其他轻量级本地CUA竞品（如NanaClaw也是以claude为核心，ZeroClaw安全高性能）。
另外，此处还有一些个人观点，cua这种东西业界都做了两年了。Manus也是cua，云端cua；豆包手机ai也是cua只是面向移动端。cua之前一直做不起来的两个原因：
1. 云端cua没那么好用，涉及资源同步，生产力能力受限，对应Manus的问题。
2. 大厂的本地cua，把用户本地完全交给大厂，隐私和垄断角度不放心，对应豆包手机的问题。
OpenClaw或者其他轻量级本地CUA竞品的突破是，它是第一个非大厂开源的完善本地cua，完全规避了以上两个问题。现在OpenClaw火了，有大厂回来摘桃子，把CUA产品随便改改名字套上OpenClaw的skill蹭热度，但我个人还是建议坚持初心，本地+开源的CUA才是正道。
最后一公里：CUA与人对话
无论如何，不管是不是OpenClaw，现在的CUA（Computer Use Agen）确实普遍采用远端控制 / IM控制 / 手机控制。主要是为了解决一个核心矛盾：让AI在获得足够操作权限以完成复杂任务的同时，最大限度地降低对用户本地设备的侵占、保障数据安全，并提升系统的稳定性和易用性。
既然我们Agent的基座采用Claude Code，因此我也review了一下业界现有的方案：
- 官方的Claude Code Remote Control：要收费的，再见
- Happy Coder：强依赖外部服务，稳定性不佳。同时界面对多模态操作不友好。
- Claude Code UI / CloudCLI 等 Web 项目：不够成熟，甚至不如OpenWebUI。
结论上似乎听起来都不太好用。
在了解openClaw的过程中，我们已知国内最方便的方式确实是微信/QQ/飞书，其中QQ与飞书的限制较低，因此将整个QQBot API投给AI，让AI自己迭代出了一个简易的qqbot server：
- 整个方案的核心思想是通过一个中间层的 HTTP 服务作为消息中转站，将 QQ 的即时通讯能力与本地 Claude CLI 的智能处理能力连接起来。
- 消息接收与签名验证机制：当用户在 QQ 中发送消息给机器人时，QQ 的服务器会以 HTTP POST 请求的方式将消息推送到一个预先配置好的 webhook 地址（通过内网穿透绑定到外部合理的https域名上）。这个环节最关键的挑战在于如何确认请求的真实性和完整性，防止恶意用户伪造请求。QQ 机器人采用的是 Ed25519 数字签名方案，这是一种基于椭圆曲线的现代签名算法，相比传统的 RSA 或 HMAC 方案具有更短的签名长度和更快的验证速度。AI快速的基于npm的开源库完成了这一部分。
- 本地 Claude CLI 的调用方式：桥接方案的核心目标是将用户消息传递给 Claude 并获得响应，Claude CLI 提供了两个关键参数来控制会话行为：-c 参数表示连续模式，会基于之前的对话历史继续对话；-p 参数则是单次提问模式，会在提示词后面附加用户的问题。连续模式的实现逻辑是维护一个全局的时间戳变量，记录上一次消息的到达时间，如果两条消息的时间间隔在 30 分钟内，就认为是同一个对话的延续，使用 -c 模式调用；超过这个时间则视为新对话，重新注入 system prompt。
// 构建包含待处理附件的用户输入
let finalUserInput = user_input;
if (pendingAttachments[openid] && pendingAttachments[openid].length > 0) {
const attachmentStr = pendingAttachments[openid].map(p => `file(${p})`).join(' ');
// 注意：此处保持 file(...) 格式，作为系统传递给 claude 的输入标记
finalUserInput = (user_input ? user_input + ' ' : '') + attachmentStr;
pendingAttachments[openid] = []; // 处理完后清空待处理附件列表
console.log(`Processing with attachments for ${openid}, final input:`, finalUserInput);
}
const base_command = `cd /home/lrdcq/codex && PATH="$HOME/.npm-global/bin:$PATH" && claude --dangerously-skip-permissions --disallowedTools "WebSearch"`
const system_input = `[System Start]1. 如果用户要求AI生产文件，将文件生成到/home/lrdcq/codex/qqbot/createfile目录。2. 如果用户的请求的结果输出的内容包含文件（普通
文件，图片，视频），并且用户明确需要这些文件。在输出结果中，以  的形式包裹相关输出。[System End]`;
const shellCommand = isContinuousSession
? `${base_command} -c -p '${finalUserInput.replace(/'/g, "'\\''")}'`
: `${base_command} -p '${system_input} ${finalUserInput.replace(/'/g, "'\\''")}'`;- 附件处理与文件回传机制：现代聊天场景中，图片、文档等附件是非常常见的需求。QQ 机器人支持在消息中携带 attachments 字段，包含文件的 URL 和文件名。接收端服务器使用 HTTP 客户端下载这些文件。对于 Claude 生成的结果文件，方案采用了一种巧妙的标记机制：Claude 在输出中会包含类似  的 Markdown 格式标记，服务器解析这个标记来提取文件路径，然后将这些文件作为独立的富媒体消息发送给 QQ。这个方案的优势在于：不需要在 Claude 端做任何定制开发，只需要约定一个输出格式即可；同时文件消息和文本消息分开发送，保证了消息的可读性。
// 5. 检查结果中是否有文件需要发送
const filePaths = extractFilePaths(shellResult);
if (filePaths.length > 0) {
console.log(`Found ${filePaths.length} file(s) in result, sending files...`);
// 发送完整文本消息（保留  标记）
console.log('Sending shell result to QQ:', shellResult);
await sendMessageToQQ(openid, shellResult, msgId);
// 逐个发送文件
for (const filePath of filePaths) {
try {
console.log(`Sending file: ${filePath}`);
await sendFileMessageToQQ(openid, filePath, msgId);
// 发送文件后延迟 5 秒，避免openAI qps限制
await new Promise(resolve => setTimeout(resolve, 5000));
} catch (err) {
console.error(`Failed to send file ${filePath}:`, err.message);
}
}
}- 主动消息推送机制： 在日常使用中，很多时候并不仅仅是被动响应用户的请求，而是需要主动向用户推送信息。比如定时提醒、系统通知、定期报告等场景，都需要机器人主动发起消息发送。这个需求引出另一个关键模块：send_message.js，这是一个独立于 webhook 服务器的命令行工具，专门负责向 QQ 用户主动推送消息和文件。这个模块的设计核心在于一个巧妙的消息缓存机制。当 webhook 服务器收到用户消息时，会将这条消息的详细信息（包括用户的 openid、消息内容、时间戳等）序列化并写入一个名为 cache_message.json 的文件中。这个文件实际上充当了一个临时的"最近联系人"存储器。当需要主动发送消息时，send_message.js 读取这个缓存文件，提取出最近与机器人交互过的用户 openid，然后将消息发送给这个用户。
结果上，基本上只要打通文件的上下行，配合上合适的会话管理，ChatBot就能很有效的运作起来了
（右键新标签打开大图，可以看到机器人人设 + 普通shell操作 + 多模态输入 + 多模态输出）
养Claude：Skill进化
在生产力 Agent 的世界里，通用CUA能力提供了广度，而是那些高度面向特定流程、深度打磨过个人习惯与偏好的 Skill。它们可能是：
- 独有的复杂 AIGC 产出链路（从选题→提示家族→多轮迭代→格式后处理）
- 最常操作的 App / 浏览器自动化路径（登录态维持、异常兜底、跨页面状态传递）
- 反复执行的定时巡检闭环（数据采集→内容判断→多渠道记录）
这些 Skill 进化得越具体、越贴合实际生活工作链条，就越能把 Agent 从“帮忙做事”进化为“替你长出肌肉记忆”。当 Agent 开始真正“像你一样思考下一步该干什么”，生产力才真正开始指数级放大。
话又说回来，OpenClaw叫做“养”龙虾，是一个非常形象的说法，这不仅仅是一个昵称，更精准地概括了使用这款AI工具的全过程——它就像养一只真正的宠物或养一盆植物一样，需要投入时间、精力和资源去部署、调教、投喂和维护技能，让只会基础技能的CUA沉淀为符合自己实际生活工作链条的超能力Agent。
因此在这个段落我列举完全在本地模型下进行完成的2个Skill成长的例子。
前提：为什么要让skill进化
当然，我们总是认为在基建足够的情况下（比如我们的CUA已经可以自由操纵浏览器和手机了），Agent是万能的大模型什么都能做到。但是在Agent的生存周期中，无约束的“自由”往往意味着系统性的低效。让Skill持续进化，本质上是一场针对上下文空间和计算资源的极限压榨。
1. 为了CUA任务质量：这是对抗上下文腐烂（Context Rot）的必然手段。未经打磨的原始调用链或冗长的ReAct轨迹，如同在有限的上下文中堆砌垃圾数据。每一次重复的常识性推理、每一次对工具用法的重新摸索，都在稀释真正关键的业务信息。特别是目前我的本地是一个Qwen 35B尺寸的中等规模模型，即使确实支持200K上下文，相关问题必然会放大。Skill的进化，就是将那些原本需要长篇大论描述的步骤，压缩成高度抽象的参数化指令。这不仅释放了宝贵的上下文窗口，更让模型的注意力像激光一样聚焦在当前任务的独特事实上，极大缓解了长程记忆的混淆与丢失。
2. 为了CUA执行效率：终结时间与算力的浪费。大模型在陌生领域的每一次试探性摸索，在燃烧GPU时钟周期的同时，也是对AI执行效率的折损。如果每次调用计算器都要重新“思考”按哪个键，每次查询数据库都要重新“理解”工具的操纵命令，这不仅是算力的巨大浪费，更是对响应延迟的放纵。Skill的进化，本质上是将探索固化为经验，将经验封装为肌肉记忆。它让Agent从“牙牙学语的婴儿”培养为“训练有素的专家”，拒绝在重复劳动中做无用功。
微博发布者skill：内化于心，外化于行，去粗取精，去伪存真
原始状态：我在docker Android设备上安装了微博国际版，希望大模型能探索出帮我自动发布微博（文字消息+上传图片）的方式。给到提示词：帮我打开微博App（包名com.weico.international），并且发布一条消息（文字+图片），并且利用skill_creator沉淀为skill
1. AI尝试使用mobile mcp的能力（本质上还是adb） 与 直接调用adb。打开微博app，并且开始利用dsl浏览能力在界面上浏览寻找发布微博的入口。并且浏览到更深的页面。——但是大模型其实不太能理解，画面右下角的的按钮点开就可以发布微博了。随着无意义的对微博更多content的点击导致的上下文膨胀，任务失败。
2. 引导大模型“使用understand_image的能力在界面截图中查找疑似发布入口”，经过几轮提示，大模型利用多模态这双眼睛终于进入了微博发布页——当然，在大模型的上下文里，它其实只是知道了在微博首页点击某个坐标进入的另一个页面“应该”是微博发布页。
3. 来到发布页面，大模型还是一脸茫然，国内的App并不会做很好的无障碍功能的accessibility标注，希望大模型直接从当前界面dsl视角查看到上传图标确实强人所难了，依旧提示利用多模态去探索界面获得界面功能坐标。
第一次进化：在手动带领大模型切实走通了一次发布流程后，是时候让ai沉淀skill了。给到以下要求：
- 流程化优先：请严格描按照先做什么再做什么的逻辑结构进行梳理。每一步动作必须是明确的动词短语（例如：“打开控制台”、“输入命令X”、“对比结果Y”），而不是描述感受或泛泛而谈。
- 规避歧义：在执行过程的描述中，必须包含关键节点的判断条件（if...then...）。例如：“如果页面报错404，则执行步骤3.1；如果报错500，则直接联系运维”。
- 专注执行：除非我明确要求背景说明，否则你的回复中不要包含过多的背景铺垫、价值感慨或发散性的建议。请专注于“如何做”以及“简单的结果描述”。
对于上文描述的分析过程，“使用understand_image”这样的动作在执行过程中根本不需要，只需要按照刚走通的过程执行就好，因此得到了如下关键skill逻辑：
...
<strong>文章发送流程</strong>
1. 打开App首页。
2. delay 12秒后，点击950,1500，delay 2秒后，再次点击此处，该操作进入发布页。
3. delay 1秒后，输入文字，如果报错尝试去除换行和特殊符号后重试，该操作输入文案。
4. delay 1秒后，点击80,1650，在delay 1秒后，点击660,300，再delay 1秒后，点击930,1700，该操作添加图片。
5. delay 3秒后，点击1000,150，该操作完成发布。
...经过其他边界case与skill提示词调整，以上skill已经可以让CUA较为稳定的运行了：
但是实际用起来，很快也会注意到以下问题：
- 执行速度慢，效率低下，每一步都要“想”：每点一下屏幕，Agent都要调用大模型分析截图、思考下一步，这个过程通常需要几秒钟，原本1分钟不到固定时间能跑完的流程，会被拖到3分钟甚至更长。
- 稳定性差，易受干扰，特别是我们的本地模型不够强劲，多少会有较大的幻觉率，本身Agent可能因为温度参数或界面微小的变化而走出不同的路径，大量的多轮大模型调用风险导致整体的成功率急剧下降，
就以上因素的共同作用下，假设我希望一口气发布10条微博，很快就会面临长上下文注意力衰减，完蛋。
第二次进化：希望skill稳定快速的执行每个相对明确的流程，最合理的方案其实是让 Agent 写 “剧本”，然后让电脑去表演，远比让 Agent 亲自即兴表演要稳定和高效得多。
- 引导AI不要自己逐个执行skill中的流程描述，而是将流程写为一个shell，AI执行shell完成任务。
- 当然也给予AI修改shell的权限，遇到shell执行错误自行修复。
- 同时shell作为skill的一部分缓存在项目中，后续优先调用shell，这也算是skill自我成长的一部分。
这样的skill修改后，我们得到了AI翻译的shell流程：
# ========== 打开 App 并发布 ==========
echo "[步骤 4] 打开微博 App"
adb shell am start -n com.weico.international/.activity.LogoActivity
sleep 12
echo "[步骤 5] 点击发布按钮 (950,1500) x2"
adb shell input tap 950 1500
sleep 2
adb shell input tap 950 1500
sleep 2
echo "[步骤 6] 输入文字内容"
adb shell am broadcast -a ADB_INPUT_B64 --es msg $(echo -n "$CONTENT" | base64 | tr -d '\n')
sleep 1
echo "[步骤 7] 点击位置 80,1650"
adb shell input tap 80 1650
sleep 1
echo "[步骤 8] 点击位置 660,300"
adb shell input tap 660 300
sleep 1
echo "[步骤 9] 点击位置 930,1700"
adb shell input tap 930 1700
sleep 1
echo "[步骤 10] 点击发布按钮 (1000,150)"
adb shell input tap 1000 150
sleep 3
echo "[完成] 微博文章已发送"此时，我们的skill如果没有意外，主要任务就是传参数给shell，执行发布即可。Agent的在skill中的职责进化得极其清晰和纯粹：
- 思考与执行的解耦：AI的职责被限定在“决策层”——根据用户需求决定“发什么内容”、“配什么图片”、“选择哪个话题”。而“如何点击”、“如何等待”、“异常重试”这些执行层的复杂度，完全下沉到Shell脚本中。实际执行时的AI不再需要关心像素级的操作，只需要关心业务逻辑。
- 关注点分离：CUA可以分别聚焦两个世界——skill执行时AI世界专注于语义理解、内容生成、决策准确性；skill迭代进化时专注于执行鲁棒性、速度优化、容错机制。两者通过简单的参数接口通信，互不干扰，大大降低了系统的维护成本和出错概率。
用相同的思路，我还同时维护起了一个定制的懂车帝图文发布skill，用qqbot均可简易操作。
视频生成专家skill：一生二，二生三，三生万物
原始状态：现有的基建上利用comfyui skill，拥有完整的文生视频能力。具体下来，引入的扩散模型里并没有引入t2v（text to video）模型，而是利用t2i模型与i2v模型拼接出来的t2v流程，用更好的text to image模型来控制首帧或者首尾帧图像，进而控制更好的生成video。
但是毕竟是开源视频模型，一旦和闭源模型比起来，比如和流行的seedance2.0比，不包括扩散效果本身的缺点，显著的能力缺点就一大堆：
- 多镜头长视频能力：开源模型通常只能生成5秒左右的单镜头、单场景的视频片段，难以理解或生成包含多个机位切换的复杂叙事；而 Seedance 2.0 能像导演一样一次性规划并生成多角度镜头组合，生成更长的视频片段。
- 画面一致性：开源模型在生成较长或较复杂内容时，容易出现角色面部特征变化、服装细节丢失或穿模等问题；而 Seedance 2.0 能通过多模态参考，确保人物和场景在多镜头切换中保持高度一致。
- 叙事能力：开源模型本质上是一个素材生成器，擅长单点画面呈现，缺乏对故事情节的整体理解和规划；而 Seedance 2.0 具备更强的叙事连贯性，能根据详细脚本生成具有明确起承转合的短视频故事。
本地的模型已经是开源顶尖水平了，虽然可以自己训练lora来解决一部分问题，但是通过skill应该也能对整个流程进行一定程度的提升。
第一次进化：一拆三
让AI对目前的t2v（t2i + i2v）流程，利用skill-creator拆解为了3个新的skill：
- skill1：镜头拆解+提示词流程：将用户的意图转换为多个镜头，为每个镜头单独生成t2i与i2v环节的提示词，并且储存到markdown中。
- skill2：批量t2i流程：让ai对每一个镜头的内容执行t2i。
- skill3：视频生成与合成流程：让ai对每一个镜头执行i2v，并且将最终生成的视频片段组成一个长视频。
第一次进化，我们让我们的t2v能力得到了多镜头长视频叙事的能力，skill-creator skill能很好的引导本地模型对每一个环节“臆想”出足够的细节，让每一个skill看起来很充实。然而实际执行起来，这次skill一拆三看起来并没有那么好——镜头平淡结果上叙事并没那么连贯，生成效果一致性非常差（虽然长期看如果不是在整个流程的扩散模型潜空间注入一致性信息，类似于seedance2.0做的，比如注入统一的Image Embedding）。
- 一拆三并不是终点，而是起点。
第二次进化：skiil1-短视频剧本专家与扩散模型提示词专家
我们拆分出来的三个skill中，skill1聚焦的剧本的编写与提示词的编写——单独从这个角色看，其实是一个偏向于文本AIGC专业性非常强的任务。因此在skill1的迭代中，进行了以下调教工作：
1. 让AI从skillhub中搜索并下载了数个短视频剧本skill，并且考虑到我们i2v的场景（比如生成20秒左右的长度的同一个内容的视频），结合在一起生成新的剧本控制skill描述，并且加入了人设（剧本专家 / 专业编剧）。
2. 进行角色与场景一致性提升的建设工作，作为剧本专家，在编写剧本的同时会编写详细的角色设定与场景设定，并且可以根据输出或者直接生成出相关的印象图像。
3. 进行提示词专家建设工作，从wan2.2，flux等相关博客上拷贝了大量的提示词生成建议，融入了skill中。
4. 同时类似于plan-with-files，总是沉淀输出相关产物。
以上工作下来，我们的skill1进化成了相对完善的状态，以这个case为例子。输入提示词：
使用多模态视频专家，生成一段视频，下图的人物在学校篮球场打篮球，15秒长skill的产出会得到非常详细的设定文档与脚本设计。
第二次进化：skill2-分镜脚本专家，用于将分镜脚本转换为分镜图像
对于生成出的详细的文本文档，skill2将文本转化为高度一致性的分镜图像，简单的文生图看来不行了。在AI的引导下，我们得到了如下思路：
拆解任务，分镜图像“由文生境，由境生人，由人成事”。不再尝试让AI一次性生成包含所有复杂元素的最终图像，而是将一个复杂的任务分解为两个更可控的子任务，并引入一个关键的中间状态——角色参考图。
- 解耦角色与场景：认识到一个复杂的画面是由“背景（场景）”和“前景（角色）”两部分构成的。将二者分开处理，可以避免AI在生成复杂画面时顾此失彼。
- 建立角色“视觉锚点”：在生成任何镜头画面之前，先为每一个角色建立一个唯一的、标准的视觉形象（角色参考图）。这相当于为后续所有涉及该角色的生成任务提供了一个“视觉锚点”，从根本上解决了跨镜头角色一致性的问题。
- 分层生成与组合：先专注于生成符合镜头语言要求的、高质量的“空场景”（不包含角色），然后将事先准备好的“角色”形象，通过图像编辑技术，精确地“放置”到场景中，并按照脚本要求执行相应的动作。
刚才的case，我们对应生成了如下的分镜图像结果：
skill3并没有做更复杂的进化（前期做好了，i2v的流程其实很轻量级），刚才这个case经过skill3后，就得到如下视频：
（在各个在线扩散模型都拒绝名人甚至真人生成视频的现在，离线的魅力也在于此）
第三次进化与长期进化
前两次进化，我们解决了“从无到有”（原始状态）和“从有到精”（Skill1&2的深度优化）的问题。但当前的流程本质上是线性的：剧本 -> 分镜 -> 视频合成。这种方式在处理复杂场景、多角色、长叙事时，仍然会遇到瓶颈，比如一个环节的卡顿会影响全局，或者在更精细的一致性控制上力不从心。
- 第三次进化的核心1是：考虑到本地中尺寸模型的能力，将这个“全能编剧/导演”的线性工作流，升级为一个由多个专业Agent构成的“导演组”，在独立任务流执行并行协同工作。
- 同时我们之前的一致性主要聚焦在角色上。第三次进化，我们要将这种控制力泛化到场景中的所有元素。从skill流程继续细化的角度，从“角色一致”到“道具一致”，从“视觉一致”到“风格一致”，完美整个t2v流程。
总结起来，这一skill进化路径的本质，是用流程的系统性，对冲模型的不确定性。不要指望一个skill解决所有问题，而要用多个skill / agent 的协作、多个环节的咬合、多次复用的积累，让整体能力超越单体上限。AI的进化，不只是模型参数的膨胀，更是系统架构的精细化——在模型能力的天花板下，用流程设计撑起应用的落地空间。
接下来 / Todo
这篇分享主要写了一些Agent / CUA的搭建与进化的过程。我们的探索主要集中在提示词工程/Skill的边界拓展上。通过精心设计的Tools ReAct与Few-shot，引导CUA/大模型在个人需求的场景下表现出了一定的专业性和任务拆解能力。但是大模型的成长不限于此，外部的“指令调优”是一方面，内部的“模型自成长”也是不可避免的一环。
这也是采购这款性价比极低的大内存N卡设备的主要原因之一——可以在离线数据堡垒里，对大模型 / 扩散模型进行微调（Lora & FFT），融入新的个人知识与技能，构建“私人数据飞轮”驱动自成长，可能会是Part3的topic。
渝公网安备 