最近用 OpenClaw 搭建 AI 助手很热门，国内也能顺畅使用。然而，一旦真正开始使用，关于难度、风险和长期成本的问题并不是简单一句“能跑起来”就能回答的。前面几篇文章已经从不同角度进行了分析，这一篇将专注于使用成本：硬件是否需要单独投入、如何选择 LLM，以及在实际使用过程中，token究竟花在了哪里。 1 是否需要专门买一台 mac mini？ OpenClaw 设计成常驻运行的服务——24/7 不间断，这样可以随时通过聊天发指令给它执行任务。另外，它可以做计划任务、检查更新、发送通知等，这就类似一个“个人服务器”，让它一直运行通常更稳妥。 若把它放在你主工作电脑上，可能影响日常使用或有冲突（比如频繁控制浏览器）。OpenClaw 在本地运行且可访问系统资源（终端、文件、浏览器等）。直接在日常电脑上给它较高权限，多少会有顾虑，也可能误操作影响系统或数据。不少人希望把它隔离出来，专门用一台机器能降低对主工作环境的风险。 Mac Mini（特别是 M 系列）性能不错且功耗低、噪音少，适合 24/7 运行；同时 macOS 生态很多工具兼容性也好。这导致社区里大量购买这类硬件来运行 ...

1 图形化 Agent 工具 1.1 核心组件 机器人 Bot：一个 AI 应用，或称为 Agent 知识库：上传个人数据，机器人可根据其内容进行回复 工作流：将大问题拆解成多个小问题，通过路径实现，路径上的每个节点完成特定任务 插件：调用外部功能（Tools） 1.2 使用体验 大模型与其他元素结合，实现完整的目标功能。 功能：调用工具、设置工作流和本地数据（知识库）。 工具：有许多现成工具可供使用。 工作流：前后关系非常直观，像搭积木一样。 2 Coze 扣子是一个 AI 应用开发平台，由字节跳动推出。 相对更 toC，无需编程即可实现 agent 的创建和发布，效果有点类似于 AI 界的微信小程序。 区别 海外版 国内版 网址 www.coze.com www.coze.cn 登陆方式 需要魔法才能使用 无使用的网络限制 可用模型 OpenAI GPT 系列 字节自研模型/国内常用模型 发布平台 Discord、Instagram、Slack 飞书、微信客服、微信公众号&订阅号 3 Dify 支持本地搭建和使用本地模 ...

1 引子 有时会想把一批公众号文章存下来，但这件事并不好做。浏览器里打开文章时，经常会碰到“环境异常：当前环境异常，完成验证后即可继续访问”。有时候连自己的文章也得手动点一下验证，更别说批量打开和下载了。 前几天朋友推荐了 GitHub 上的开源项目 wechat-article-exporter，专门用来批量下载公众号文章。这个项目现在已经有 8.3K Star，支持用 Docker 本地部署，也可以先在作者提供的网站试用。下载时需要用有开发者权限的账号扫码登录。自己在本地部署更安心一点。 我试了一下，整体效果不错。2026.4.6下载新版本，自己打出来的 Docker image 大约是 366 MB。 项目地址：https://github.com/wechat-article/wechat-article-exporter 2 使用方法 先在项目目录里执行： 12docker build -t wechat-article-exporter .docker run --rm -p 3000:3000 wechat-article-exporter 如果不想每次手动带参数，也可以 ...

最近从用 agent 写代码，到拿它做股票调研之类的日常事务，觉得这套东西确实有实用价值，成本也不算高。就想：能不能也让家人朋友直接用起来？ 但仔细一想，还挺麻烦，难怪现在不少人靠“代安装”收费，装一次 300 到 500。不是因为这类系统有多神秘，而是门槛确实在那儿。光是下载和跑起来，就可能会碰到 github、docker、clawhub、网络环境这些问题。后面一旦要接浏览器、装 skill、配权限、处理登录态，复杂度还会持续上升。 用Agent和之前用软件/App最大的差别是：之前软件/App把环境的复杂性都帮解决好了，安装就用，而OpenClaw这种工具很多问题需要自己解决，在没有背景知识的情况下，就很容易被卡住，或者带来未知的风险。 本篇想聊的是普通人要真正把 Agent + Skill 系统用起来，难点到底在哪里。 1 普通人怎么用 Agent + Skill 系统 我觉得这类系统离普通人还有一段距离，问题主要在执行层。 聊天和知识当然重要，但聊天只是入口。真正难的是后面的几件事：权限怎么给，环境装在哪里，什么时候必须让人介入确认。这几件事没处理好，普通用户就很难真的把它当 ...

1 接入微信 微信现在已经支持个人机器人通过正规渠道接入了。 这次开放的不只是 OpenClaw 的接入能力，更准确地说，微信把一套机器人接入协议放出来了。有人拿它接 OpenClaw，也有人拿它接 Claude Code。只要按这套协议来，理论上别的机器人也能接进去，包括自己写的。 这和以前只能走企业微信、公众号后台，或者自己想办法绕路，已经不是一个量级。微信当然也加了不少限制，比如机器人不能加群，一个账号只能接一个机器人，机器人目前只能收文件、不能给用户发文件，至少我现在测到的版本是这样。 这也正常，毕竟这里碰到的是聊天、隐私和交易这些高权限场景，不可能一开始就完全放开。 但趋势已经很清楚了。后面机器人只会越来越多，平台迟早都得支持这件事。谁开放得早，谁就更容易先占住生态位。 1.1 原理 接口跑在 https://ilinkai.weixin.qq.com。微信官方提供了 @tencent-weixin/openclaw-weixin 插件，npm 包里就是完整的 TypeScript 源码。 原理不复杂，基本就是三步： 认证：先调 ilink/bot/get_bot_qrco ...

CoPaw 是阿里发布的“本地智能体工作台”（Agent Workstation）。它本身更像一套框架或中间件，和小龙虾这类产品比较接近；这套工具中包含一个可以本地部署的小模型名叫 CoPaw。 源码： https://github.com/agentscope-ai/CoPaw 最近类小龙虾的工具出得很多。本篇主要想聊的，不是 CoPaw 工作台本身，而是它提供的、也叫 CoPaw 的本地小模型。这个模型既可以跑在 GPU 上，也可以跑在 CPU 上。CoPaw-Flash 系列专门针对本地部署做了优化，硬件门槛比较低。比如 CoPaw-Flash-4B-Q8_0 是 4B 尺寸下的 Q8 量化版本，我这次实测时，内存和显存占用都没有超过 10G。 那是不是说，以后在自己机器上部署小模型，就不用再花 token 了？另外，除了 CoPaw 工作台，其他 Agent 比如龙虾，能不能也接这个模型？好不好配？本文记录一下我的实验方法、实验数据，以及一些还不算成熟的判断，仅供参考。 请注意：由于LLM模型和工作台名字都叫CoPaw，为区分二者，下面分别称为 CoPaw工作台和CoPaw 模 ...

1 Skill 是什么 我们在使用大模型时经常会遇到一个问题：做同一类工作时，每次都得重新把要求说一遍，中间还要反复修很多细节。这本身也是一种重复劳动。把它写成 prompt 存起来，后面每次再复制粘贴，其实也挺麻烦。这种场景就特别适合用 skill，把我们从细节和重复里解放出来。 自从开始用 skill 之后，就有点停不下来了。开始是在用别人写好的，后面慢慢把自己常用的流程和与大模型的交互沉淀下来。把触发条件、步骤、边界，还有要调用的工具写进固定目录里，下次再遇到同类任务时，基本就不用重新理解一遍了。 越来越觉得，skill 真正解决的不是“模型不会做”，而是“同一种事总在重复解释”。一个流程只要已经比较稳定，就值得把它沉淀下来。这样后面复用的就不只是那几句提示词，而是一整段已经跑顺的执行链条。 大致做下来，其实也就是三步：定义 skill、调用 skill、持续迭代。 2 自己写一个 2.1 写 SKILL.md 在自己的技能目录下： 123mkdir mytestvi mytest/SKILL.md skill 一般由两部分组成：开头的 YAML 元数据，加上后面的 Markdo ...

1 最近很热的 CLI-Anything 项目地址：https://github.com/HKUDS/CLI-Anything CLI-Anything 想做的事很直接：把一个现有软件，或者一个现成代码仓库，变成 AI agent 能稳定调用的命令行工具。 我最近也在做这件事。我之前有一个前后端都有的工具，最开始是先让 Agent 去控浏览器，走前端页面，登录、点按钮、一步一步把流程跑通。后来我又把前后端代码直接给它，让它把功能往外抽，边写边测。最后做出来的效果其实挺好，主要功能都能正常用。 所以我看到这个项目时，第一反应不是“这个想法挺新”，而是“终于有人把这一套动作抽象出来了”。这个项目是 3 月 9 号开源的，到 3 月 27 号已经拿到了两万多 Star，传播速度非常快。下面就来看看：它到底把哪些东西做成了通用能力。 它不是再造一个简化版软件，也不是靠点点点的 UI 自动化去糊。它的思路是把真实软件的能力，包装成结构化 CLI，让 agent 用命令、参数和 JSON 输出去调用。这比截图识别、按钮点击那套稳定很多，也更适合长链路自动化。 2 解决什么问题 现在的大模型很会推 ...

像 OpenClaw、Claude Code 这类 agent 系统，表面上是在和大模型对话，真正做事时，用到的往往不只是 LLM 本身，也不只是预制的那几个功能。 任务一复杂，就会碰到一串很实际的问题：现有工具怎么接进来，新工具怎么安装和调用，多步流程怎么衔接，上一段结果怎么顺着传给下一段。 这些事，很多不是模型临场猜一猜就能稳定做好的。这里缺的，通常不是再补几句 prompt，而是把知识、工具和流程整理成一套可复用、可调用的东西。 这部分，就是 skill 要补上的内容。 1 为什么不能直接把程序丢给模型 一句话：skill 是给大模型补 how。 大模型常常不缺“是什么”，缺的是“这事该怎么做”。skill 做的，就是先把某类任务里关键的知识、步骤和约束整理好，需要时再接上工具、脚本和资料。 那为什么不直接把程序丢给模型？因为程序不会自己变成可用能力。模型还是得知道：这个工具解决什么问题，输入输出是什么，参数怎么传，什么时候该用，什么时候不该用。 比如一个 5000 行的 PDF 工具，模型每次都临时读代码再猜命令和参数，既慢也不稳。用 skill 先把这些信息整理好，调用就稳定 ...

1 解耦大脑与记忆 大家喜欢 OpenClaw，主要因为它的自我学习与进化能力。但在实际开发中，不同 Agent 各有所长。比如写代码用 Copilot，梳理架构用 Claude Code。 目前的痛点很明显：切换工具或重开对话，上下文就断了。辛苦调教的代码偏好、踩过的坑，需要反复交代。 解法就是解耦。把负责推理的“大脑”和记录偏好的“记忆”分开。 我们需要一个通用的记忆中间层，让所有 Agent 共享同一个核心知识库。只要接入同一个底座，任何 Agent 都能调取历史经验。 2 通用存储层 记忆如果锁死在某个具体工具里，换工具就得从零开始。 引入“通用语义存储层”作为中间层后： * 工具专注于推理和生成的“运算大脑”职责。 * 记忆层集中存储长期偏好、关系图谱和历史教训。 * 只要底层数据独立，未来接入任何新的 LLM 工具，就能立刻适应当前工作流。 3 具体实现 目前的最佳实践方案是：MCP (Model Context Protocol) + 本地独立文件存储。 我们可以使用 basic-memory 作为底层支撑，配合具体 Skill 适配各类场景。 3.1 核心底座：MCP接 ...