DEV Community: Yang ella

Cursor 开发者习惯报告：AI 编码让你快了多少

Yang ella — Sun, 31 May 2026 04:02:08 +0000

Cursor 发布了首份开发者习惯报告（Developer Habits Report），基于 2025 年 1 月至 2026 年 5 月的真实产品数据，量化了 AI 编码工具如何改变软件开发。报告围绕五大主题展开，用数据回答了一个核心问题：AI 到底让开发者快了多少？

一、开发者加速：代码产出翻倍

整体产出激增

最直观的变化是代码产出的爆发式增长：

每周人均代码行数从 2025 年初的 3.6K 增长到 2026 年 5 月的 8.6K，增长 2.4 倍
增长在 2026 年初显著加速，从 5.5K 跃升至 8.6K

虽然"代码行数"不是完美的生产力指标，但作为方向性基准，这个增长幅度足够惊人。

PR 规模扩大

开发者不仅写得更多，单次提交的规模也在扩大：

单个 PR 代码行数（p75 分位）从 126 行增长到 345 行，增长 2.7 倍
Mega PR（≥1000 行变更）占比从 8% 增至 13.8%

2026 年 1 月出现明显跳跃，与新一代模型（如 GPT-5.5、Opus 4.7）和 Agent 能力提升同步。开发者开始用 AI 处理更大粒度的工作单元。

另一面的思考：Mega PR 增长是双刃剑。传统软件工程推崇 Small PR、Frequent PR、Easy Review，因为 Review 成本低、回滚容易、Bug 定位简单。当一个 Agent 一口气生成 30 个文件、1000+ 行代码时，人类从"写代码"变成"审核 AI 代码"，Review 质量可能下降。Cursor 后来推出 Bugbot，本质上就是因为 AI 生成代码越来越多，人类 Review 已经跟不上。

Agent 会话深度增加

Coding Agent 不再是简单的"代码补全"，而是执行复杂的多步骤任务：

近两个月内，平均每次会话的工具调用次数从 113 增至 145，增长 30%
Agent 频繁执行：读写文件、搜索代码、运行 shell 命令、浏览网页

这意味着 Agent 正在承担更复杂的工程任务，而非仅仅生成代码片段。

AI 代码存活率提升

生成代码的"存活率"是质量的重要指标：

60 分钟后仍保留的 AI 代码比例从 76% 提升至 81%

这说明开发者修改/删除 AI 代码的比例下降，对 AI 生成代码的信任度提升。

二、智能经济学：成本差异与性价比

模型成本差异巨大

不同模型家族的成本差异远超预期：

模型	成本/请求	成本/接受行
Opus 4.7	$1.57	1.10¢
Opus 4.6	$0.86	1.19¢
GPT-5.5	$0.81	1.09¢
GPT-5.4	$0.46	0.54¢
Sonnet 4.6	$0.44	0.54¢
GPT-5.3 Codex	$0.30	0.56¢
Composer 2.5	$0.18	0.18¢

关键发现：

按请求计算，成本差异达 9 倍（$1.57 vs $0.18）
按接受代码行计算，差异缩小至 7 倍（1.19¢ vs 0.18¢）

高成本模型通过生成更多可接受代码，部分弥补了成本劣势

成本-质量前沿

Cursor 在内部评测套件 CursorBench 3.1 上测试了不同模型的表现：

Composer 2.5：$0.55/任务，63.2% 准确率（性价比之王）
Opus 4.7 (max)：$11.02/任务，64.8% 准确率（质量天花板）
GPT-5.5 (extra high)：$4.37/任务，64.3% 准确率（平衡选择）

值得注意的是，Composer 2.5 是 Cursor 自研的编码专用模型，以不到 Opus 4.7 (max) 1/20 的成本，达到了 97.5% 的准确率。这可能代表了新一代专用编码模型的方向：针对编码任务深度优化，而非追求通用能力。

不过需要指出，这是 Cursor 在自家报告中展示自家模型的表现，且评测基于 Cursor 内部的 CursorBench 套件。在其他平台或评测标准下，结果可能有所不同。

三、超级用户鸿沟：AI 放大不平等

使用高度集中

Cursor 用洛伦兹曲线和基尼系数量化了 AI 使用的不平等程度：

AI 代码行数 Gini 0.77（高度集中）
AI 支出 Gini 0.75
Token 消耗 Gini 0.72

基尼系数越接近 1，分布越不平等。0.77 意味着 Top 5% 用户占据约 50% 的 AI 活动。

产出差距扩大

顶尖开发者与普通开发者的产出差距正在拉大：

p99 开发者产出是中位数的 46 倍（AI 代码行/天）
p99 开发者合并 PR 数是中位数的 15 倍
p90 开发者产出是中位数的 10 倍（差距小得多）

更直观的绝对数字：

2025 年初：p90 为 2.5K 行/周，p50 为 176 行/周
2026 年 5 月：p90 为 8.8K 行/周，p50 为 712 行/周

虽然相对倍数从 14 倍降至 12 倍，但绝对差距从 2.3K 行扩大到 8.1K 行。

为什么会出现鸿沟？

AI 工具在提升所有人生产力的同时，放大了顶尖开发者的优势。可能的原因：

Prompt 工程能力：超级用户更擅长与 AI 协作
任务分解能力：知道如何将复杂任务拆解为 AI 可处理的单元
上下文管理：更好地利用缓存和上下文窗口
工具链整合：将 AI 深度整合到工作流中

深层含义：这与历史技术革命完全一致——Excel 没有消灭顶级分析师，Photoshop 没有消灭顶级设计师，Google 没有消灭顶级程序员。AI 是放大器而非均衡器，高手获得指数级收益，普通人只是生成更多代码。

四、上下文崛起：从生成到理解

输入/输出比激增

模型的工作模式正在发生根本性转变：

Input/Output Token 比率从 4.5× 增至 12.4×（2026 年 1-5 月）
模型在生成每一行代码前，消耗的上下文是输出的 12 倍以上

这是"先读后写"的范式转变：模型花更多时间理解代码库，而非急于生成。

输入 Token 主导非缓存成本

Token 构成的变化印证了这一趋势：

输入 Token 占非缓存 Token 的 90%+（从 82% 增至 92%）
按价格等价计算，输入成本占比从 47% 增至 70%

关键洞察：优化上下文管理比优化输出质量更重要。未来 AI 编码工具的竞争力将取决于如何高效利用上下文窗口。

缓存读取主导总 Token 活动

加入缓存后，Token 构成更加极端（2026 年 5 月）：

Cache Read: 89.9%
Cache Write: 2.5%
Input: 7.0%
Output: 0.6%

Agent 工作高度依赖缓存复用，而非每次从头读取。Cursor 在博客中提到，他们持续优化跨模型/提供商的缓存策略。

结论：上下文窗口扩大 + Prompt Caching 是 AI 编码能力跃升的基础设施。没有高效缓存，Agent 无法处理复杂任务。

更深层的变化：Token 增长主要来自输入而非输出，说明 AI 越来越像是在阅读代码库、文档、PR、Issue、历史记录，然后才开始写代码。Coding 正在从"生成代码问题"变成"管理上下文问题"。未来竞争优势会更多体现在谁能组织 Context、构建知识图谱、维护 Rules、管理长期记忆。

五、自动化转向：从工具到系统

自动接受率飙升

开发者对 AI 的信任度正在快速提升：

无需人工审查即提交的 AI 变更占比从 7% 增至 38%（5 倍增长）
这意味着超过 1/3 的 AI 代码直接进入 commit，跳过人工 diff review

这是从"辅助工具"到"自主系统"的关键转折点。

需要警惕的是：这个数据有两种解读——表面上是 AI 越来越强、代码质量提升；但也可能是人类越来越懒得检查、审核疲劳。这两种解释在数据上无法区分。连 Cursor CEO 自己都公开警告：不要把 AI 当成无需审查的代码生成器，否则系统最终会崩塌。

自动化工作流扩散

Cursor 展示了三条增长曲线（具体数值未公开）：

Automation agents（通用自动化）
Security review automation（安全审查自动化，增长最快）
SDK runs（可编程 Agent 平台，最新趋势）

安全审查成为首个规模化自动化场景，这并非偶然。安全审查具备两个关键特征：

规则明确：有清晰的检查清单（SQL 注入、XSS、敏感信息泄露等）
可验证性：结果可以通过测试和扫描工具验证

这为其他自动化场景提供了启示：结构化、可验证的任务最适合自动化。

结语

这份报告用真实数据量化了"AI 如何改变编程"。除了那些快速增长的曲线，还有一些需要注意的事实：

软件开发正在从编程问题变成上下文管理与审查问题。Token 增长主要来自输入而非输出，说明未来更重要的能力是定义任务、组织上下文、审查结果和维护系统复杂度。输入 Token 成本占 70%，意味着优化上下文管理的重要性，Prompt Caching 已成为生产级 AI 编码工具的刚需。
生产力提升与技术债务并存。代码量增长不等于价值增长，Mega PR 增加可能意味着审核能力被突破，自动接受率提升可能是信任也可能是疲劳。
AI 放大不平等而非拉平差距。Power User Gap 的扩大说明，AI 是放大器而非均衡器——高手获得指数级收益，普通人只是生成更多代码。p99 用户的工作流可能代表未来 2-3 年的主流模式，值得深入研究他们如何分解任务、管理上下文、整合 AI 到工作流。

数据来源: Cursor 产品和工程数据（Agent 使用、Token 消耗、PR 活动等）
相关链接： Cursor Developer Habits Report
原文链接： https://yeekal.com/ai/cursor-developer-habits-report/

每天 6 毛钱的 AI 日报系统 —— AI Daily 又进化了

Yang ella — Wed, 27 May 2026 13:30:11 +0000

AI 信息过载的时代，筛选比收集更重要。

两个月前我开源了自己搭建的 AI 热点追踪系统，现在它又进化了：

新增Github Trending 热点项目和 Hacker News 热点讨论
把启动命令迁移至 systemd timer，可一键启动，实现系统级服务管理
借助nitter的公开实例实现自定义指定X用户帖子追踪
上线了归档网站ai daily，不想动手的朋友们可以直接线上查阅了

简述一下 ai daily 背景

或者可以看之前发布的文章：AI 热点追踪系统

ai daily 是一个 AI 驱动的新闻聚合与推送系统。每天自动收集，智能评分过滤，定时汇总，并支持发送到飞书实时通知用户。

核心功能

400+ RSS 信息源 —— 聚合全球主流 AI 媒体、博客、Twitter 账号
GitHub Trending 板块 —— 抓取 GitHub trending，LLM 深读 README / topics / metadata，选出值得关注的开源项目
Hacker News 板块 —— 跟踪 HN 首页 AI 相关讨论，整合外链正文与顶层评论由 LLM 总结
即时推送 —— 热点新闻立即推送到手机(飞书/discord)
定时汇总 —— 每天可以自定义定时自动推送 AI 资讯日报

systemd timer 让服务像系统组件一样可靠

上个版本的运行方式比较原始——跑一下 python 脚本，信息就唰唰唰地抓进来了，整个服务跑起来，也没想太多服务进程管理的相关问题。

但是长时间运行了之后发现几个痛点：

如果一旦出现某些不可预知的问题，整个服务就挂掉了，需要手动重启，还需要手动管理如何把进程放到后台
改了个参数，需要重启
日志没有有效记录，难以定位问题
定时在python内部，sleep状态下，进程还在，但是完全没有必要

我就问AI，像openclaw这种服务一键安装就可以了，我的这个项目也想要这样的，该怎么做。

我把以上这些问题都抛给了AI，经过几轮商讨，最后选择了使用 systemd timer。

在配置好参数和环境变量之后，现在只需要这样：

./scripts/install.sh

对，这样就行了。脚本会自动同步依赖、安装 systemd 服务并按 config.json 中的调度配置启动定时任务，机器重启后自动恢复。安装成功后无需额外操作。

这次重构把定时任务交给系统服务来管理，python不维护cron定时。没到定时时间，也没有python进程运行。一次调度出现错误(比如网络波动，json解析等)，不影响下一次。 config参数支持热重载(除了定时参数)，中间可以随便改，下次任务启动生效。连日志也帮着一起管理了。

并且系统服务提供很多方便的指令:

daily-news status [N]      # 查看 timer/service 状态 + 最近 N 行日志（默认 15）
daily-news logs            # 实时跟随日志（Ctrl+C 退出）
daily-news start           # 启动两个 timer
daily-news stop            # 停止两个 timer
daily-news restart         # 重启两个 timer（仅重置调度，不立即触发任务）
daily-news help            # 用法说明

daily-news status 可以查看定时任务的状态，上次触发时间，下次触发时间，日志输出等。

这样可以很方便地管理或者显示整个服务的运行状态，这才是系统级集成该有的样子。

通过 nitter 实例自定义 X 用户帖子追踪

x（twitter）上的信息还是不能忽视。当前项目里的默认rss源是从BestBlogs项目引进来的，它里面提供了160+ 用户的rss列表，涵盖了大部分ai相关的高关注度用户。

好是好，坏就坏在这个列表我没法随意添加新的用户，因为这个rss源是第三方维护的。

除了上面已有的用户，我想要自己能个性化地定义我想关注的用户。举个例子，我想追踪 openclaw 的帖子，这个列表里面没有openclaw，那我就没法追踪。

我希望找到一种可用的，可指定用户的rss源。当然，必须是免费的。

我找了很多种方法，问了很多ai，查到了nitter。

简单来说nitter是一个无需登录即可浏览公开帖子的开源项目，同时提供用户帖子的rss链接。

不过由于X不断加强反爬虫和 API 限制，nitter的很多公共实例难以长期稳定运行。

现在比较稳定的推荐较高的是xcancel，如果想关注某个用户，把这个链接https://rss.xcancel.com/<user>/rss加入rss源即可。

实际测试下来 xcancel 对反爬还是有一定门槛的，它用了多层指纹识别判断客户端，代码里面已经对这类实例做了额外的适配。

如果在其它项目里面使用该源，建议频率不要太高。

访问 yeekal.com/daily/ 在线阅览

看着飞书里每天准时发布的日报，历史记录直接被删除掉感觉有些可惜

所以做了个项目主页，加入了历史归档。每天早八点和晚五点会更新当天早晚报，不需要部署也可以方便查看。

当然，在线日报本身也支持rss订阅，访问项目主页查看订阅地址。

(注： 5.24 之前的日报存在测试样本，不建议查看)

workflow 还是 agentic

说一些开发过程中的疑惑，思考

上一次发文出来，有很多人会问：这openclaw不也能做么，这让claude跑几个新闻网站不就拿到信息了么

其实我也在想，费时费力开发这些，是不是直接写一个skill让agent自己去做这件事更好一些。

我记得anthropic去年也发过一篇文章介绍工作流和agent的区别。

我现在做的事情其实就是工作流的编排，定义好每一步该做什么，按照流程一步一步走。步骤可控，可操作灵活度大，但是扩展自由度低。加一个模块就要加一份代码。而agent模式是通过harness工程，通过自然语言，通过skill约束agent的任务，给agen配齐工具，给它自由，让它自定义如何一步一步走到最终的结果。agent模式扩展很灵活，但是可控性依赖模型对指令的遵循程度。

对于该项目而言，第一阶段对rss信息源的抓取非常适合工作流，因为它高频，请求数量多，任务清晰，并且代码实现很直接。

github trending和hacker news这类具体并且一次性的任务就比较适合让agent来做了。写代码要写一大串，但是写提示词可能几句话告诉他总结一下当天热点即可。并且这类任务在agent端很方便扩展，加入对应网址和输出格式就行了。

3月份开始开发之前，我其实让openclaw给出过每天8点的新闻总结。但是这里面有很多影响因素，比如对网站源的选择，文本的markdown化，网络请求的限制等等。我对它的结果并不满意。更重要的一点是我希望对于突发消息能及时给我到，这如果让openclaw跑的话，token耗费将会是巨大的。所以那个时候我才考虑，这需要一整个系统化的工程来应对。

整个项目运行下来从结果上看符合预期的，并且整个流程，对信息源的把控，日志，报错等都在可追溯的范围内。还有一点重要的是，token的花费非常低。因为工作流里面token只花费在做任务总结上，没有多余的工具调用，文本转换/读写/编辑，思考过程。这些过程被系统架构层给替代掉了。用Deepseek V4 flash 在30min的抓取频率下差不多一天6-7毛钱。最近我把频率又调低了，60min一次，这样花费会更少。(调低不是因为花费，是想减轻公共rss服务实例的压力）.

不过未来如果要加入更多的信息源(比如reddit，product hunt), 那么有必要考虑一下哪种方式是最优的。是用工作流写采集模块，还是用 Agent 几句提示词搞定？这可能没有一个标准答案，取决于你对「可控」和「灵活」各有多少容忍度。

一个汉字爱好者的执念-vibe了个高清说文小篆检索站

Yang ella — Fri, 08 May 2026 08:27:51 +0000

两年前，我做过一个轻量版本的shuowen.space-高清篆文检索网站。为什么要做这个呢? 主要是我个人非常喜欢说文解字里面的文字形态，里面有一些对早期汉字不一样的解释。但是当前的说文解字的网站大部分字形都是低分辨的，小小的一块。所以我就想做一个能展示高清说文解字字形的网站。

最初的想法很简单，就是把《说文解字》里那些早期汉字字形放到线上，自己查的时候方便一点。那时在学习nextjs，所以顺便做一个网站练练手。

但是当时的网站只能满足基本功能，页面简陋，查询速度缓慢，不支持简体字模糊查询，访问体验很不友好。所以借助这个五一假期，我把网站重新优化了一下。

这次重构，我没有在原来的基础上修修补补。借助AI，直接delete，完全重写了。

访问地址： shuowen.space

正式介绍一下：
shuowen.space 是一个提供 说文解字在线查询高清小篆字形检索 的平台，提供高清小篆字形、说文原文、段玉裁注解以及对应的现代辞典解释

数据规模：

540 个部首
9,418 个正篆条目
10,706 个高清矢量字形（包括异体字/重文）
24,099 条注解

首页以及顶部菜单栏提供搜索框，直接输入汉字/拼音即可查询对应的小篆字形并直达条目链接。

拼音查询这里对应的文字有时候比较多，不一定会列出想搜索的那个字，所以建议直接输入汉字是最准确的

单字页面包含内容:

高清小篆字形大图
重文异体字列表
说文原文（许慎原文释义）
段玉裁注（清代段玉裁的注解）
国语辞典释义

540部首目录

部首是《说文解字》编排汉字的核心方式。也是持续至今的字典目录必有的查询方式

说文部首总览页面按 14 卷分组显示每一卷的部首列表，每部首直接展示高清大图，点击即进入该部首下的条目列表。这里你可以看到540个部首铺在你的桌面上，看着还是很有感觉的。

开发心得

先写文档。先写自己的想法，再让ai一步一步改。比如自己是怎么想的，思路怎么来的，要实现什么效果。然后发给ai，把问题抛给ai，让它在这个基础上继续细化
根据文档进行初步实现。这个时候应该有这些内容了：
- 比如框架选型，前端页面结构，后端数据库结构。只要求有页面，不要求页面一次性符合我们的的目的。
- 总体色彩选型。背景，前景，主色调
细化后端数据获取方式，前后端交互的数据定义，如何更高效准确的获取数据
优化前端页面：包括布局，子组件内容，ui优化。分页面逐步细化。可以截图给不同的ai 模型，多方参考，给出方案。这个过程可能会持续很久
每改一次让ai落实到文档，并落实计划。大功能及时提交。

结语

希望这个项目能帮助每一个热爱汉字的人

网站如有体验不佳之处，欢迎指出

一个浮点数逆向破解 Claude 订阅真实额度

Yang ella — Mon, 13 Apr 2026 12:22:07 +0000

Anthropic的claude订阅计划里，从没有告诉用户他们 Pro / Max 5× / Max 20× 的真实额度到底是多少，不同的订阅只有一个倍率值。

Claude 使用的进度条也只会显示使用百分比，看不到任何精确数字。

这本来也没引起谁的注意。毕竟，大多数人不会去深究一个进度条能告诉你的信息

但有人注意到了。

开发者 shellac 发现：当你打开浏览器的开发者工具，抓取 Claude 后台的 /usage 接口返回值时，会得到一个奇怪的高精度浮点数——比如 0.16327272727272726，精确到了小数点后 17 位。

这看似只是一个普通的进度数字。但恰恰是这个小数点后 17 位，撕开了 Claude 订阅隐藏额度的大门。

shellac 沿着这串数字往下挖，愣是从一个17位小数点挖出了官方从未公开的真实数据。

核心发现：不同订阅的真实额度

先上数据，这是作者逆向工程出来的真实额度限制.

订阅层级	5小时额度(credits)	每周额度(credits)	价格
Pro	550,000(1×)	5,000,000(1×)	$20
Max 5×	3,300,000(6×)	41,666,700(8.33×)	$100
Max 20×	11,000,000(20×)	83,333,300(16.67×)	$200

如果把订阅换算成 API 等效价值：

订阅层级	价格	月额度（credits）	Opus-rate tokens	API 等效价值
Pro	$20	21.7M	32.5M in or 6.5M out	$163 (8.1×)
Max 5×	$100	180.6M	270.9M in or 54.2M out	$1,354 (13.5×)
Max 20×	$200	361.1M	541.7M in or 108.3M out	$2,708 (13.5×)

从以上数据可以看出

Max 5×：官方说 5×，实际给的是 6 倍（5小时）到 8.33 倍（每周），性价比最高
Max 20×：官方说 20×，但每周只给了 16.67 倍，几乎打了 8 折

用订阅，比直接调用 API 便宜 8~14 倍。

因为作者发现 Claude 的缓存读取在订阅中是免费的，而在 API 中要收取 10% 的输入费用。这意味着：

冷缓存：订阅便宜 13.5 倍
热缓存（反复读缓存的场景）：订阅便宜可达 36.7 倍

所以网上有人说 200美金的Max版订阅实际可用到1w美金的api价值调用真不是吹嘘的。

表格中的credits是什么？这只是一个计量单位，为了统一不同模型的使用量的。作者甚至给出了它的计算公式：

credits_used = ceil(input_tokens × f_i + output_tokens × f_o)

Model	f_i: Input credits/token	f_o: Output credits/token
Haiku	2/15 = 0.133...	10/15 = 2/3 = 0.666...
Sonnet	6/15 = 2/5 = 0.4	30/15 = 2
Opus	10/15 = 2/3 = 0.666...	50/15 = 10/3 = 3.333...

我来简单解释一下,不同模型价格不同，为了统一到同一个计量单位，在计算每个模型的输入和输出价格的时候会乘以一个系数，f_i对应每输入token数的系数, f_o对用输出token系数。

表格中的数字看起来没什么规则。不过它的数值精确反映了模型间的价格比例关系：

输出价格是输入的5倍
Opus 价格是 Haiku价格的5倍
Opus价格是 Sonnet 的 5/3 倍

整体来看作者逆向出来的数据还是比较可信的。不过 shellac 逆向的过程更是让人惊叹。

怎么发现的：一场「浮点数考古」

这部分聊聊技术原理，我尽量让它听得懂。

突破口：那个「未舍入」的浮点数

Claude进度条背后，调用了一个 /usage 的内部接口。这个接口返回的 JSON 里，有一个是 Usage Ratio。

关键来了：这个 Usage 是未经过四舍五入的高精度浮点数。

官方给你看的进度条是「约等于 16%」，但是接口的返回值是这样的：

0.16327272727272726

这是什么呢？作者意识到，API 返回的这个浮点数，在业务逻辑上等于

$$ \text{Usage Ratio} = \frac{\text{已消耗额度}}{\text{总额度}} $$

换句话说，这是一个分数，只是被「翻译」成了浮点数。

3.2 浮点数 = 被「压缩」的分数

因为系统的计费/扣减单位（无论是 Token 还是内部 Credit）和总额度一定都是整数，所以这个由于计算而产生的浮点数，本质上是一个有理数（分数）。如果我们能把这个浮点数精准还原成原来的分数，那么分母就会暴露总额度上限的相关信息。

比如 0.16327272727272726，它一定是某个分数的近似值。

如果你能把这个浮点数还原成最简分数，会发生什么？

比如还原后得到 449/2750。这个 2750，意味着真实总额度一定是 2750 的倍数。

分母 = 真实额度上限的可能性。

Stern-Brocot 树：数字界的「二分查找」

问题来了：怎么从浮点数还原最简分数？

这就用到数学里一个优雅的工具——Stern-Brocot 树。

你可以把它理解成：一棵包含所有正有理数的「数字树」。通过二分搜索，你可以高效地在这棵树的无限的「叶子」中，找到唯一落在浮点数区间 [L, U) 内的那个最简分数。

就像你在一个无限大的数字字典里，用「翻页」的方式快速定位到那一页。

在这个场景里，由于小数精确到第17位，所以精度步长设置为最后一位(~10^-17)

针对浮点数0.16327272727272726，作者测试了 69 步，找到了 449/2750，验证后发现完全吻合。

step 00: left=0/1 right=∞ mediant=1 -> mediant ≥ U, move left
step 01: left=0/1 right=1/1 mediant=1/2 -> mediant ≥ U, move left
step 02: left=0/1 right=1/2 mediant=1/3 -> mediant ≥ U, move left
step 03: left=0/1 right=1/3 mediant=1/4 -> mediant ≥ U, move left
step 04: left=0/1 right=1/4 mediant=1/5 -> mediant ≥ U, move left
step 05: left=0/1 right=1/5 mediant=1/6 -> mediant ≥ U, move left
step 06: left=0/1 right=1/6 mediant=1/7 -> mediant < L, move right
step 07: left=1/7 right=1/6 mediant=2/13 -> mediant < L, move right
step 08: left=2/13 right=1/6 mediant=3/19 -> mediant < L, move right
... 57 more steps ...
step 66: left=8/49 right=417/2554 mediant=425/2603 -> mediant ≥ U, move left
step 67: left=8/49 right=425/2603 mediant=433/2652 -> mediant ≥ U, move left
step 68: left=8/49 right=433/2652 mediant=441/2701 -> mediant ≥ U, move left
step 69: left=8/49 right=441/2701 mediant=449/2750 -> HIT

LCM: 拼图的最后一块

但还没完。

因为分子分母在相除时可能被约分，所以一个分数推导出来的分母（比如 2750），可能只是真实总额度的一个因数，而不是总额度本身。

比如： 449/2750 和 11401/75000 均可通分至分母为 3,300,000 的分数

怎么办？

多次采样，取最小公倍数（LCM）。

在不同额度消耗阶段，调用 API 获取不同的浮点数
把每个浮点数还原成最简分数，得到一系列分母
求这些分母的 LCM

一开始，LCM 会不断跳跃变大。但在几次之后，数字就不再变了。

这个最终稳定下来的数字，就是 Claude 真实的额度上限。

最后

claude的订阅模式似乎开了一个不好的头，现在大家的coding plan几乎都不会公布真实限额，导致大家用起来像抓瞎一样。根据shellac 的发现，我们对claude的真实额度有了更清晰的认知。

海外模型对国内的封锁，催生了国内大批量的中转站服务，从这里面也可以看出中转站的盈利模式。他们使用批量MAX 账号套取coding plan额度，然后以api倍率的形式卖给用户，只要控制好倍率比例关系，这个生意就稳赚不赔。比如Max对应13.5倍api价值，那么他们以10倍api价值卖出去还能保留3.5倍api的利润。这还只是没有计算缓存的情况。这也解释了为什么中转站会比官方的直连api要便宜很多以及他们打着1人民币换1美金额度api的底气。

还有一个思考，claude的api真实成本到底是多少？在"商人都是逐利的"假设下，如果大家的订阅都是顶满格使用，再假设即便在这个场景下Anthropic也不会亏损，考虑到MAX订阅等于13.5倍api价值，那么现有的api真实成本应该在当前定价的十三分之一以内。当然这样计算似乎太暴力了，也有种说法是现在的coding plan，那些没有用满额度的用户才是赚钱的地方，这些没有用完的剩余额度会补贴高级订阅的满格消耗额度，同时产生盈余。

这只是一个粗浅的想法，大家觉得呢？

参考

只用文件系统和 Bash，Vercel 做出了一套高效 RAG

Yang ella — Mon, 30 Mar 2026 09:32:14 +0000

不建向量库，也能做 RAG？Vercel 给了一个新答案

Vercel 发了一篇博客：Build knowledge agents without embeddings。开源了一个知识库agent问答项目 Knowledge Agent Template。

该项目不靠“embeddings”实现了一个知识库搜索问答系统。它把知识库当成一个可搜索的文件系统：模型在 sandbox 里调用 grep、find、head、cat 这些普通命令，先找文件，再读文件，再综合答案。

按照官方博客的说法，他们内部一个销售电话总结 agent 的单次成本，从大约 $1.00 降到了 $0.25，而且输出质量还更好。

为什么一套看起来很普通的文件系统操作，被 Vercel 重新组织之后，可以成为一条足够实用的 RAG 路线？

这篇文章就沿着这条主线展开，主要看三件事：

Vercel 这个项目具体是怎么做的。
文件系统加 bash 为什么在代码、文档、知识库场景里有效。
这套方法的边界、代价和适用范围在哪里。

这是个什么项目

站在用户视角看，这个项目做的事情其实很好理解：

你先把知识接进来，用户再像平常聊天一样提问，Agent 则在后台真的去翻这些文件，然后把找到的内容组织成答案。

这里的“知识”，可以是 GitHub 仓库、文档内容、YouTube 转录等。接进来之后，它们不会先进向量库，而是会被整理成一份可以搜索的文件集合。

所以对用户来说，体验大概就是三步：

管理员先把知识源接进系统。
用户在 Web Chat、GitHub 或 Discord 里直接提问。
Agent 在后台搜索真实文件、读取相关段落、整理答案返回给你。

如果本地知识里找不到足够信息，当前这套实现还允许它再补一次 web_search。

从技术上看，这里面真正关键的动作也不多：

先把外部知识同步成一份 snapshot repo，内容都落成普通文件。
查询时把这份文件快照挂到 Vercel Sandbox 里，并尽量复用已有 sandbox，减少启动开销。
给模型开放 bash 和 bash_batch 两个受限工具，让它通过 grep、find、head、cat 这些命令完成搜索和阅读。

Vercel 这套方案最有价值的地方，是把文件系统检索做成了一条可复用、可解释、可控成本的工程路径。

文件系统 + bash，怎么被组织成一套 RAG

我找到了我关注的核心文本，其实就是一段系统提示词，源文件在 BASE_SYSTEM_PROMPT

重点是 Fast Search Strategy 这一段。

Agent 底层模型对bash读文件的操作天然了熟于心，Claude code/Codex 每次打开的时候就需要读文件，读系统指令，用户自定义指令，skill列表等。

所以这段提示词里最值得看的，是这些命令如何被约束、组合和工程化。

1. 优先批次bash，一次读写

BASE_SYSTEM_PROMPT 里开头一句是：

ALWAYS prefer bash_batch\ over sequential bash\ calls. Combine search and read in the same batch.

提示词首先约束优先使用 bash_batch 而不是串行 bash, 同时尽量在一次batch执行中完成搜索文件和读文件操作。整段提示词都是这一句话的详细展开。

内部定义了一个函数可以批量处理多条bash指令, 比如大模型可以一次把以下三条指令合并发下去：

bash_batch: [
  "grep -rl "keyword" docs/source1/ --include="*.md" | head -5",
  "grep -rl "keyword" docs/source2/ --include="*.md" | head -5",
  "head -100 docs/source1/getting-started/index.md"
]

bash_batch 的价值主要在于把多条命令打包成一次工具调用。

它省下来的主要是：

多轮工具调用带来的模型思考开销
中间步骤的 token 消耗
Agent 在长循环里越走越散的风险

对 Agent 来说，这更像是一次性打包检索计划：少几轮 tool loop，往往就少几轮试探和 token 消耗。

2. 克制检索文件，够用就行

提示词里面给出bash指令指导用法：

### Quick reference
| Task | Command |
|------|---------|
| Find files by content | \`grep -rl "keyword" docs/ --include="*.md" | head -5\` |
| Multi-keyword search | \`grep -rlE "term1|term2" docs/ --include="*.md" | head -5\` |
| Find files by name | \`find docs/ -name "*routing*" -name "*.md"\` |
| Read file (partial) | \`head -100 docs/path/file.md\` |
| Read file (full) | \`cat docs/path/file.md\` |
| Search with context | \`grep -n -C3 "keyword" docs/path/file.md\` |

然后提示词里面给出了正面样例和反面样例, 依然是提倡合并多个bash 调用。

### Good vs Bad

**Good** — 1-2 calls:
1. \`bash_batch\`: grep across likely dirs + read obvious files in one call
2. \`bash_batch\`: read remaining files from grep results

**Bad** — 5+ calls:
1. \`find docs/ -maxdepth 2 -type d\`
2. \`grep -rl "keyword" docs/source1/\`
3. \`grep -rl "keyword" docs/source2/\`
4. \`cat docs/source1/file1.md\`
5. \`cat docs/source2/file2.md\`

最后的Rules给出了更多bash优化的参考. 比如：

使用head -N 输出更小的文本，而不是一下子获取整个文件内容
使用grep -rlE "term1|term2" 同时搜索多个关键词
使用grep -rl 而不是 grep -r，只获取文件路径，忽略匹配行

提示词里所有示例，本质都在强化同一个策略：

先用 grep -rl 找路径
用 head -N 只读局部
一次搜索多个关键词
尽量 1 到 2 次工具调用结束

它提供的是一种检索行为模板：

不要漫无目的遍历目录
不要一上来 cat 大文件
不要把一步一步的探索拆成很多轮工具调用
先拿到候选文件，再做有针对性的读取

如果说传统 RAG 的很多工作花在“如何切 chunk”，那 Vercel 这里花的心思更像是：如何让模型像一个克制的命令行使用者。

这套方案最适合什么场景

1. 个人知识库和 Agent 记忆

如果你的知识库本来就是一堆 Markdown、日报、想法笔记、命令记录、Prompt 模板，那么先走文件系统检索几乎是最自然的选择。

它比 embedding 更轻，也更接近日常工作方式：

同时这也启发我们，在做个人知识库的时候，语义化的文件命名和文件夹命名能极大提高agent的搜索效率。很多时候只要给 Agent 一份干净的目录，再配上一些 prompt 约束，已经能得到很不错的效果。

另外我说的文件系统检索完全不需要把 Vercel 这一整套都搬过来。

像 sandbox、snapshot、共享沙箱池这些设计，更多是为了把系统做成一个能稳定服务多用户、多会话、多平台的产品。对个人来说，这套工程通常太重了。

而且今天很多 Agent 本来就已经会做这件事。

无论是 Claude Code、Codex，还是其他带 bash 能力的 coding agent，它们本来就会：

读目录
搜文件
看局部内容
根据文件证据组织答案

所以个人最有参考价值的，不是整套 Vercel 基础设施，而是它向我们释放的信号：最简单的文本匹配也许是最高效的检索方式。

2. 代码库问答

这是它最天然的主场。

代码库里最重要的信息，本来就大量存在于：

文件名
import 路径
函数名
类型名
配置文件
注释和 README

这些都非常适合 lexical search，而不太需要语义嵌入先做一层“翻译”。

3. API 文档和产品文档

文档站也很适合，尤其是有清晰目录树、标题层级和稳定术语的文档。

比如“认证怎么配”“路由在哪里定义”“某个 Hook 支持哪些参数”这类问题，本质都是在找明确的局部证据。

什么时候它会明显不如 embedding

说完优点，也得把边界说清楚。

文件系统 RAG 也有很清晰的边界。下面这些情况里，embedding 或 hybrid search 往往更稳。

1. 用户提问和文档表述没有词汇重合

这其实是 embedding 诞生的根本原因。

如果用户问的是模糊概念、近义表达、口语化描述，而知识库里的写法完全不同，grep 很可能就是搜不到。

例如：

用户问“怎么做登录保护”
文档写的是“route middleware” 或 “access control”

只靠关键词，很容易漏召回。

2. 知识非常松散、噪声很大

比如 OCR 文档、杂乱 PDF、客服工单、聊天记录、大量口语转写，这些内容往往命名不规范、结构不稳定、同义表达很多。

这种情况下，光靠路径和关键词，效果通常不会太好。

3. 语料规模很大，而且需要更强排序

原始 grep 擅长“找到包含这个词的文件”，但不擅长“把最相关的前几个文件稳定排到最前面”。

在文件很多、匹配很多的情况下，你很快就会遇到两个问题：

候选文件太多
排序质量不够

这时更自然的下一步，往往是先引入更成熟的 lexical ranking，比如 BM25、SQLite FTS、搜索引擎索引，甚至再叠一层 reranker。
。

4. 多语言、别名、企业黑话很多

如果同一件事在不同团队里有不同叫法，或者中文、英文、缩写混着来，文件系统检索的 recall 会变差。

这类场景里，语义检索或者至少 hybrid search 往往更稳。

总结

Vercel的做法是一种很“返璞归真”的工程方案。它不是万能解，但在代码库、API 文档、内部知识库这类强结构场景里，工程价值非常高。

这套方法很务实。但是它不覆盖所有检索问题

文件系统加关键词搜索，在这些场景里通常非常强：

代码库
API 文档
内部 Wiki
术语稳定的知识库

但如果问题换成下面这些，embedding 或 semantic search 依然会更重要：

用户表达很模糊，和文档用词不重合
数据高度非结构化
同义词、别名、企业黑话很多
文件很多，排序质量开始明显影响结果

所以社区里比较成熟的结论，并不是“以后都不用 embedding 了”，而是：先看语料，再定检索原语；很多时候 hybrid 才是最后的形态。

不是抛弃 embedding，而是抛弃“默认先上 embedding”的思维惯性。

很多时候，真正好用的 RAG，并不需要一开始就很重；它更需要清晰的证据路径、稳定的检索行为和可解释的结果。

参考

Vercel 博客：Build knowledge agents without embeddings
Vercel 模板页：Chat SDK Knowledge Agent
GitHub 仓库：vercel-labs/knowledge-agent-template
Prompt 源码：packages/agent/src/prompts/chat.ts
博客链接：只用文件系统和 Bash，Vercel 做出了一套高效 RAG

受够了网络反爬？这套 WebTop 方案，让云端 OpenClaw 像真人一样上网

Yang ella — Sun, 22 Mar 2026 03:43:28 +0000

浏览器是网络世界的入口

对于云端部署的 OpenClaw，有一个最大的痛点，就是浏览器没有显示界面，这会对 OpenClaw 的浏览器自动化操作产生很大的影响。

刷知乎、小红书、推特，或者看 Reddit 时，传统的 Headless（无头）浏览器几乎过不了人机验证，也很容易卡在扫码登录界面。

云服务器没有显示器，你连验证码长什么样都看不到，更别提接管操作了。

那么，有没有一种优雅的姿势，让云端的 OpenClaw 拥有一个“有血有肉”的真实桌面浏览器？ 就像我们在本地自己电脑上浏览网页一样自由？

既能保留 Cookie 环境，又能在遇到验证码时，让你通过浏览器随时“远程附体”进行人工接管？

我花了几天时间，反复追问 Claude、GPT、Grok、Gemini、Kimi，在我的云服务器上跑通了他们一致推荐的方案：WebTop + Tailscale，并且成功登录谷歌、知乎、小红书等平台。

从此访问网页畅通无阻，它甚至还能自己去谷歌搜索自己想了解的事物。

我的实测环境

Oracle Cloud（新加坡区 Free Tier）4C CPU / 24GB 内存。SCP 速度大约 1.5~2 MB/s，Ping 400ms延迟，所以远程桌面在人工接管时会感觉偏卡。好在 OpenClaw 自己通过 CDP 调用浏览器是本机通讯，不吃公网带宽，因此不会拖慢自动化性能。

如果你把 WebTop 跑在离自己更近的 VPS（或本地超微机），延迟和带宽体验都会好很多。下面所有参数都基于这台机器调出来的“高配方案”，如果你的资源更紧张（比如 2C4G 或 2C8G），记得在部署前对照文中的可调项做减法，确保 CPU、内存、带宽都匹配自己的上限。

OpenClaw 需要什么样的浏览器环境

为了发挥OpenClaw最大的潜力，它需要一个“有血有肉”的真实桌面浏览器，就像一个入职公司的正式员工，在自己的工位，用着 Chrome 浏览网页。

那么，什么才是真实的浏览器环境？

这个诉求再拆解一下：

抗反爬：避免网站风控秒封
浏览状态持久化：它需要记住登录状态，浏览历史，cookie
遇到登录/验证码可以人工接管

把这个需求喂给 AI 之后，首先了解到一个叫 Xvfb 的工具，它可以在服务器端为浏览器虚拟一个显示器，基本满足上面的诉求。

不过我并没有止步于此，继续 push AI：有没有其他方案？有没有更优解？

最后拿到四种候选方案，本质上都是在 Xvfb 上做了不同程度的封装：

Xvfb + noVNC: 自己直接配置Xvfb，这是最原始的组合
WebTop: LinuxServer.io 维护的 Docker 镜像，提供完整的 Linux 桌面环境，也内置浏览器。底层仍是 Xvfb，但做了完善封装，内存占用多一点，却换来稳定性和更简单的配置。无需客户端，浏览器即可访问远程桌面。
Selenium Chrome: 官方 Selenium 浏览器镜像 + VNC，运行在 Docker 中的 Selenium + Chrome 调试环境，通过 Xvfb 虚拟显示服务器
Playwright + xvfb: 最轻量，但需手动配置 VNC

虽然 WebTop 内存占用更高，但稳定性、反爬效果、接管体验、配置流程都优秀得多，所以所有 AI 都建议我选 WebTop。

理由：

我的机器内存充足（24GB）(建议不少于4G)
人工接管体验最佳（完整桌面，可装扩展/调试工具）
维护成本最低（Docker Compose 一键管理）
稳定性最好（LinuxServer.io 持续维护）

下面是详细对比 参考表格：

维度	Xvfb + noVNC	WebTop ⭐	Selenium Chrome	Playwright + xvfb
内存占用	~250MB	~600MB	~450MB	~200MB
CPU（空闲）	低	中（桌面环境）	低-中	低
网络（自动化）	CDP	CDP	CDP	CDP
网络（人工接管）	中（VNC）	中（VNC）	中（VNC）	中（VNC，需配置）
安装复杂度	⭐⭐⭐⭐ 复杂	⭐ 简单	⭐⭐ 较简单	⭐⭐⭐ 中等
维护复杂度	⭐⭐⭐⭐ 复杂	⭐ 简单	⭐⭐ 较简单	⭐⭐⭐ 中等
人工接管	Web VNC	完整桌面	Web VNC	需额外配置
接管体验	⭐⭐⭐ 一般	⭐⭐⭐⭐⭐ 优秀	⭐⭐⭐ 一般	⭐⭐ 差
反爬效果	⭐⭐⭐⭐ 好	⭐⭐⭐⭐⭐ 优秀	⭐⭐ 差	⭐⭐⭐ 一般
稳定性	⭐⭐⭐ 中等	⭐⭐⭐⭐ 自动化稳定	⭐⭐⭐⭐ 好	⭐⭐⭐ 中等

说明：

内存占用：Selenium 包含 fluxbox + Xvfb + noVNC + supervisord，实际占用约 450MB
网络（自动化）：OpenClaw 通过 CDP 控制，所有方案带宽占用一致且很低
网络（人工接管）：通过 VNC 传输屏幕图像，带宽占用中等（~1-5Mbps）
OpenClaw 性能：CDP 不经过桌面环境，所有方案性能基本一致（差异<5%）
反爬效果：WebTop 提供真实桌面环境，反爬效果最佳；Selenium 包含 navigator.webdriver 等自动化指纹，容易被识别
稳定性：WebTop 适合人工接管场景，Selenium 适合纯自动化场景

最终架构

选定方案之后，我又为了稳定和安全加上了 Tailscale 私有网络、Watchdog 监控等配套组件，让远程桌面浏览器具备生产级可靠性。

WebTop (Chromium) - 持久化浏览器，Cookie/Session 永久保留
socat 端口转发 - 解决 Chromium 133+ 强制绑定 127.0.0.1 的问题
Tailscale - 私有网络，无需公网端口
Watchdog - 监控 CDP 端口，浏览器 freeze 时自动重启（<3秒恢复）
Docker Healthcheck - 容器健康监控


┌──────────────┐
│   Local PC   │
└──────┬───────┘
       │ 
┌──────▼───────┐
│  Tailscale   │ (私有网络)
└──────┬───────┘
       │  (3000/3001)
       ▼
┌─────────────────────────────────────────────┐
│ Oracle Cloud VPS                            │
│                                             │
│ ┌──────────────┐                            │
│ │  OpenClaw    │                            │
│ └──────┬───────┘                            │
│        │ CDP (127.0.0.1:9222)               │
│        ▼                                    │
│ ┌────────────────────────┐                  │
│ │ WebTop Container       │◄─────────────────┘
│ │ (XFCE Desktop)         │                  │
│ │                        │                  │
│ │  ├─ socat :9222        │                  │
│ │  │   └─> 127.0.0.1:9223│                  │
│ │  └─ Chromium :9223     │                  │
│ │                        │                  │
│ │  Watchdog Supervisor   │                  │
│ └────────────────────────┘                  │
└─────────────────────────────────────────────┘

关键设计：

socat 监听 0.0.0.0:9222，转发到 Chromium 的 127.0.0.1:9223
Watchdog 只重启浏览器进程，不重启整个容器
桌面环境保持运行，Cookie/Session 不丢失
解决浏览器 freeze（进程存在但 CDP 无响应）问题
Healthcheck 仅用于容器状态监控，实际恢复由 Watchdog 完成

关键参数

4C 24GB 高配版本：

✅ shm_size: 4GB（共享内存）
✅ mem_limit: 8GB（内存限制）
✅ cpus: 2.5（CPU 限制）
✅ disk-cache-size: 512MB（磁盘缓存）
✅ max-old-space-size: 4GB（V8 堆内存）

如果你是 2C4G/2C8G 等轻量实例，可以把 mem_limit 下调到 4GB、cpus 限制到 1.5，并酌情调小 disk-cache-size。唯一的前提是要保证 shm_size ≥ 2GB，否则 Chromium 很容易崩。所有这些参数都写在 docker-compose 里，实际部署前最好让 AI 再帮你根据机器规格复核一遍。

硬件建议

档位	CPU / RAM	适用场景	备注
最低可用	2C / 4GB	纯自动化 + 偶尔人工接管	`mem_limit`≈4GB，`cpus`≤1.5，`shm_size` 保持 2GB；
建议标准	4C / 16GB+	稳定生产/推荐标准	`mem_limit`≈6-8GB，`cpus`≈2-3，`shm_size`≈2-4GB 文章示例所用配置，足够支撑多标签、长时间持久化

既然要用 OpenClaw，就别把它当一个“聊天机器人”糊弄过去。太低配的云主机只能让你卡着干着急——与其在 2C2G 上耗时间，不如直接上够用的规格，把 OpenClaw 当成真正的提效助手，认真投入一次。

如何配置

这份教程不是“照着 README 抄一遍”，而是我在 Oracle Cloud 4C24G 机器上连续调试、反复和 Claude / GPT / Grok / Gemini / Kimi 拉扯之后沉淀下来的生产级实践：

先让 Claude 写出初版，再请 Kimi 和 GPT 并行 Review，来回改了 5 轮才都点头；
紧接着让 Claude 自己在我的机器上动手部署，我在旁边盯日志，又针对异常修了 3 次；
HTTPS 访问、X11 认证、socat 端口、s6 权限、Watchdog 逻辑这些坑我是一个个踩过来的。

因此这里的每个参数都有出处：要么是官方最佳实践，要么是我真实环境量出来的稳定值。你完全可以把这份步骤交给自己的 Claude 或 Codex 去执行，但务必要结合你机器的 CPU/内存/带宽，把 cpus、mem_limit、shm_size、PASSWORD 等可调项提前改好。

建议直接把本文发给交给 Claude/Codex，让AI帮你配置。
文末有公众号扫码关注并回复 “webtop” 可领取原始 MD 文件

强烈建议看完整个教程再开始配置!!!
强烈建议看完整个教程再开始配置!!!
强烈建议看完整个教程再开始配置!!! 留意注释里所有需要自定义的参数

确认过硬件和网络都扛得住之后，就可以按照下面的 Step 1 ~ Step 3 一步步来。

Step 1: Tailscale 私有网络

1. VPS 安装 Tailscale

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

复制终端输出的 https://login.tailscale.com/... 链接，在本地浏览器授权登录。

2. 获取 Tailscale IP

tailscale ip -4

记录输出的 IP（如 100.10.20.30），后续用 $TS_IP 表示。

3. 本地安装 Tailscale

在本地电脑安装 Tailscale 客户端，登录同一账号。

Step 2: 部署 Docker 环境

1. 安装 Docker

curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER

重新登录 SSH 使 docker 组生效。

2. 创建项目目录

mkdir -p /opt/openclaw-browser && cd /opt/openclaw-browser

3. 创建浏览器启动脚本（带 Watchdog + socat 端口转发）

cat > browser-launcher.sh << 'EOF'
#!/usr/bin/with-contenv bash

# WebTop 已设置 DISPLAY=:1，使用默认值或环境变量
export DISPLAY=${DISPLAY:-:1}

# 等待 X server 就绪
while ! xdpyinfo >/dev/null 2>&1; do
  sleep 1
done
echo "[$(date)] X server ready, using DISPLAY=$DISPLAY"

echo "[$(date)] Browser Supervisor 启动，监控 CDP 端口..."

# 启动 CDP 端口代理（9222 -> 9223）
start_cdp_proxy() {
    pkill -f "socat.*TCP-LISTEN:9222" 2>/dev/null
    socat TCP-LISTEN:9222,fork,reuseaddr TCP:127.0.0.1:9223 &
    SOCAT_PID=$!
    echo "[$(date)] CDP 代理已启动 (9222 -> 9223)"
}

# 主循环：浏览器崩溃或假死时自动重启
while true; do
    echo "[$(date)] 清理锁文件..."
    rm -f /browser-data/Singleton*

    echo "[$(date)] 启动 Chromium (端口 9223)..."
    chromium-browser \
      --user-data-dir=/browser-data \
      --remote-debugging-port=9223 \
      --remote-debugging-address=127.0.0.1 \
      --remote-allow-origins="*" \
      --no-sandbox \
      --disable-gpu \
      --disable-software-rasterizer \
      --disable-features=VizDisplayCompositor \
      --disable-blink-features=AutomationControlled \
      --disable-crash-reporter \
      --disable-breakpad \
      --hide-crash-restore-bubble \
      --restore-last-session \
      --disable-features=TranslateUI \
      --no-first-run \
      --disable-background-timer-throttling \
      --disable-renderer-backgrounding \
      --disable-backgrounding-occluded-windows \
      --disable-ipc-flooding-protection \
      --password-store=basic \
      --disk-cache-size=536870912 \
      --max-old-space-size=4096 &

    BROWSER_PID=$!

    # 启动端口转发
    start_cdp_proxy

    # 健康监测：15秒检查一次（检查 socat 端口）
    while kill -0 $BROWSER_PID 2>/dev/null; do
        sleep 15
        if ! curl -sf http://localhost:9222/json/version >/dev/null 2>&1; then
            echo "[$(date)] 浏览器无响应，正在重启..."
            kill -TERM $BROWSER_PID 2>/dev/null
            sleep 2
            kill -KILL $BROWSER_PID 2>/dev/null
            kill -9 $SOCAT_PID 2>/dev/null
            sleep 2
            break
        fi
    done

    echo "[$(date)] 浏览器已停止，3秒后重启..."
    sleep 3
done
EOF

chmod +x browser-launcher.sh

4. 创建 Docker Compose 配置

cat > docker-compose.yml << 'EOF'
services:
  webtop:
    image: lscr.io/linuxserver/webtop:ubuntu-xfce
    container_name: openclaw-browser
    security_opt:
      - seccomp:unconfined
    environment:
      - PUID=1001
      - PGID=1001
      - TZ=Asia/Shanghai
      - CUSTOM_USER=oclaw
      # - PASSWORD=${WEBTOP_PASSWORD:-ChangeMe123!}  # 已禁用密码认证，通过 Tailscale 私有网络保护, 如需密码可在此处设置
      - DOCKER_MODS=linuxserver/mods:universal-package-install
      - INSTALL_PACKAGES=socat
      - SELKIES_ENABLE_HTTPS=false
    volumes:
      - ./config:/config
      - ${HOME}/workspace/webtop-browser-data:/browser-data
      - ./browser-launcher.sh:/config/scripts/browser-launcher.sh:ro
      - ./config/custom-cont-init.d:/custom-cont-init.d:ro
    ports:
      - "${TAILSCALE_IP}:3000:3000"
      - "${TAILSCALE_IP}:3001:3001"
      - "127.0.0.1:9222:9222"
    shm_size: "4gb"
    mem_limit: "8gb"
    cpus: "2.5"
    ulimits:
      nofile:
        soft: 65536
        hard: 65536
    tmpfs:
      - /tmp:size=1g
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "curl -sf http://localhost:9222/json/version >/dev/null"]
      interval: 15s
      timeout: 5s
      retries: 3
      start_period: 30s
EOF

5. 创建环境变量文件

# 获取 Tailscale IP
TAILSCALE_IP=$(tailscale ip -4)

# 创建 .env 文件
cat > .env << EOF
TAILSCALE_IP=${TAILSCALE_IP}
EOF

说明：

VNC 端口（3000/3001）绑定到 Tailscale IP，只能通过 Tailscale 网络访问
已禁用密码认证，通过 Tailscale 私有网络保护访问安全，如需密码可在docker-compose.yml中设置
CDP 端口（9222）绑定到 127.0.0.1，本地 OpenClaw 直接访问
浏览器数据目录：$HOME/workspace/webtop-browser-data（需提前创建）
如果 Tailscale IP 变化，需要更新 .env 并重启容器

6. 配置浏览器自启动

✅ 使用 custom-cont-init.d：容器初始化时后台启动，避免 s6 服务管理问题
✅ s6-setuidgid abc：以 abc 用户运行浏览器，解决 X11 认证问题（root 无法显示窗口到 abc 的桌面）
✅ 后台启动 (&)：避免阻塞容器启动流程

# 创建浏览器启动服务
mkdir -p config/custom-cont-init.d
cat > config/custom-cont-init.d/01-start-browser << 'EOF'
#!/bin/bash
(
  # 等待 socat 安装完成
  while ! command -v socat >/dev/null 2>&1; do
    sleep 2
  done
  # 以 abc 用户运行浏览器（解决 X11 认证问题）
  exec s6-setuidgid abc /config/scripts/browser-launcher.sh
) &
EOF

# 赋予执行权限
chmod +x config/custom-cont-init.d/01-start-browser

7. 创建浏览器数据目录

# 创建浏览器数据目录
mkdir -p $HOME/workspace/webtop-browser-data

8. 启动容器

# (cd /opt/openclaw-browser && docker compose up -d)
docker compose up -d
docker compose logs -f

等待 30 秒，看到 "Browser Supervisor 启动" 日志即成功。

启动完成之后可快速检查CDP 端口响应：

docker exec openclaw-browser curl -sf http://localhost:9222/json/version

Step 3：OpenClaw 配置

在 OpenClaw 配置文件中浏览器配置里添加 webtop ，并设为默认：

  "browser": {
    ...
    "defaultProfile": "webtop",
    "profiles": {

      "webtop": {
        "cdpUrl": "http://127.0.0.1:9222",
        "color": "#00AA00"
      }
      ...
    }
  },

如果你还没有配置过浏览器，你可以直接复制我的配置：

  "browser": {
    "enabled": true,
    "headless": false,
    "noSandbox": true,
    "attachOnly": false,
    "defaultProfile": "webtop",
    "profiles": {
      "openclaw": {
        "cdpPort": 18800,
        "color": "#FF4500"
      },
      "webtop": {
        "cdpUrl": "http://127.0.0.1:9222",
        "color": "#00AA00"
      }
    }
  },

配置参数说明

环境变量 (.env)

参数	默认值	说明	可修改
`TAILSCALE_IP`	可选设置	Tailscale 私有网络 IP	tailscale私有网络和密码保护至少选一项
`WEBTOP_PASSWORD`	未设置	远程桌面登录密码（可选）	✅ 如需密码保护可添加

Docker Compose 配置

参数	默认值	说明	可修改
`CUSTOM_USER`	`claw`	远程桌面用户名	✅ 可自定义
`TZ`	`Asia/Shanghai`	容器时区	✅ 可改为其他时区
`PUID/PGID`	`1001`	容器内用户 ID	⚠️ 需与宿主机匹配，终端输入 `id` 查询
`shm_size`	`4gb`	共享内存大小	✅ 可根据需求调整
`ulimits.nofile`	`65536`	文件描述符限制	✅ 可根据需求调整
`tmpfs`	`/tmp:size=1g`	临时文件系统	✅ 可根据需求调整

说明：

VNC 端口（3000/3001）绑定到 Tailscale IP，只能通过 Tailscale 网络访问
默认无密码认证，通过 Tailscale 私有网络保护
CDP 端口（9222）绑定到 127.0.0.1，供本地 OpenClaw 连接，不建议修改
浏览器数据目录：$HOME/workspace/webtop-browser-data 可自己修改

登录凭据：

当前配置：无需密码，直接访问即可（通过 Tailscale 私有网络保护）
如需启用密码保护：
1. 在 docker-compose.yml 中取消注释 PASSWORD 行：
```
 - PASSWORD=${WEBTOP_PASSWORD:-ChangeMe123!}
```

在 .env 文件中添加：

 WEBTOP_PASSWORD=your_secure_password_here

重启容器：docker compose restart

本地如何连接远程浏览器验证

这一步我们要在本地访问远程机器的浏览器，验证它是否稳定启动。

首先获取远程机的私有网络地址（也可以直接在 Tailscale 客户端里看到）：

tailscale ip -4

然后在本地浏览器访问 https://<Tailscale_IP>:3001。

大概率你会先看到“被安全拦截”的警告页。

没关系，这是因为 WebTop 强制启用 HTTPS，但证书是自签名的，不被浏览器信任。

点击 高级 → 继续访问 即可。

稍等片刻，就能看到远程浏览器已经打开。我习惯把谷歌设为主页，这里截图来自我用 iPad 访问的场景 —— 浏览器里的浏览器，挺像套娃😁，也可以直接在里面做搜索。

也就是说无论你到哪里，只要能上网，随时可以查看云端龙虾的浏览器状态。

不用担心浏览器异常退出，我写了监控脚本，每 15 秒检测一次状态；一旦崩溃会立刻重启。可以手动关掉浏览器，等 15 秒左右就会自动恢复，下面的视频是 ×4 加速的效果。

OpenClaw 实操

经过我实测，OpenClaw 原生的 CDP 控制太差了，速度比较慢，截图总是截长图（似乎是个 bug: Screenshots capture full page instead of viewport by default）。

所以这里我建议安装 Agent Browser 技能包。Agent Browser 是 Vercel 用 Rust 写的浏览器自动化工具，定位准、速度快，也更省 token。

Agent Browser 支持通过 --cdp 9222 连接 webtop 已有的 Chromium 进行工作。安装完技能，可以把上句加黑的文字发给龙虾并让他写入TOOLS.md。

这样OpenClaw 就拥有了自己的桌面浏览器。

你就可以干一些好玩的事了。

比如总结博客内容的时候可以直接要求它截取文章中的关键数据表格，作为文章配图或者校验AI总结的数据准确性：

AI热点监控的时候，比如Midjourney V8发布了，它不仅给我了内容要点，还发了几张参考图:

登录小红书小号:

温馨提示：登录账号可以先使用小号尝试，避免账号被封。虽然该方案已经是云端浏览器自动化的最优解。

不过其实我们手动登录就行了，这里只是测试一下浏览器的能力。因为让它登个小红书其实花费了半个小时才登陆上，一方面中转站的api太慢了，另一方面浏览器自动化还需要和虾一起打磨打磨。

登录完可玩的空间就大了，大家可以自行尝试。

Chrome DevTools MCP

另外提一下前两天 Google 发布的 Chrome DevTools MCP 工具，全网都在爆吹，不过这对云端的龙虾来说并没有做任何改善，只是利好本地 OpenClaw。因为该工具只是提供操控浏览器的接口，并不改变浏览器本身的状态，该工具的运行还是建立在 CDP 接口的基础上。但是有了 WebTop 就不一样了，OpenClaw 天然拥有完全属于自己的桌面浏览器，并且与用户看到的是共享的。

也就是说在 Chrome DevTools MCP 工具发布之前，本地 OpenClaw 要与用户共享浏览器需要安装插件，而之后只需要开放开发者调试接口，不需要安装插件。而对于云端 OpenClaw，我们安装的 WebTop 解决了一切问题，浏览器天然属于共享状态。

Browse Use

在我写这篇文章的时候，Browser Use 刚巧上线了“直连 CDP”能力，可以通过--cdp-url http://localhost:9222指定cdp接口。详细可参考Browser Use CLI

browser-use --cdp-url http://localhost:9222 open https://example.com

官方也强调，这条路径就是为第三方云浏览器或自建实例准备的，只要你的浏览器通过 WebSocket 暴露了 CDP，就能被 Browser Use 驱动。而官方的更新也进一步验证了“真实桌面 + 持久化 CDP”的方案越来越成为Agent操纵浏览器重要的一部分。

其实通过最近Chrome DevTools MCP工具的发布，Browse Use新增对CDP直连的支持，我们可以发现通过CDP端口直接控制浏览器会越来越成为主流。因为这样Agent不仅能控制本地电脑的真实浏览器，还能连接远程浏览器，也可以让云端Agent连接类似webtop这一类的浏览器。在openclaw的browser 文档里其实有推荐云端浏览器Browserbase，其中的控制方式就是通过CDP。也就是说，文档里描述的webtop方案是自己在服务器配置的，如果你不想配，你可以在云端浏览器提供商购买服务，它会给你开放一个浏览器实例，这个浏览器实例和服务器之间的控制方案就是CDP协议。

我在openclaw里面一开始配置Agent Browser也是因为它原生支持CDP模式。不过现在Browse Use也支持了，后面可以尝试一下。

FAQ

遇到问题优先请教 Claude/Codex

Q: 想启用密码或公网访问？

A: 默认依赖 Tailscale 隐私网络，不开放公网端口。如果必须暴露公网，务必在 docker-compose 里启用 PASSWORD 并配置强口令，同时建议套上一层 Cloudflare Tunnel / Caddy 做额外认证。

Q: 远程桌面很卡怎么办？

A: 文中示例的 VPS 在新加坡，我本人在国内，因此 SCP 只有 1.5~2 MB/s、延迟 400ms。人工接管时确实会感觉卡顿，但 OpenClaw 自动化走本地回环，速度不受影响。可以优先选择距离自己更近的节点（本地 NUC、同城云厂商等）

Q: Tailscale IP 改了无法访问？

A: 重新执行 tailscale ip -4，把新 IP 写入 .env 或直接更新 docker-compose 的 TAILSCALE_IP 环境变量，然后 docker compose down && docker compose up -d 即可。

Q: 浏览器启动失败 / 无法打开新标签？

A: 99% 是共享内存不足，确认 shm_size 至少 2GB，低配机器也不要低于 2048m；若系统 RAM 只有 4GB，最好把其它容器停掉。

参考链接

LinuxServer WebTop 官方文档 —— 了解更多自定义参数及桌面环境支持。
Tailscale Quickstart —— 不同系统的安装与登录流程。
阿里云 Openclaw
腾讯云 Openclaw
Browser Use CLI
Agent Browser CDP mode

建议直接把本文发给交给 Claude/Codex，让AI帮你配置。
公众号扫码关注并回复 “webtop” 可领取原始 markdown 文件(AI更容易看懂)
原文链接： https://yeekal.com/ai/openclaw-cloud-desktop-browser/

OpenClaw限流有救了！免费Nvidia API+阿里云百炼接入指南

Yang ella — Tue, 24 Feb 2026 14:17:21 +0000

之前买的kimi coding plan 又限流了，先用免费模型顶一顶。

推荐两家，nvidia 和 opencode zen

opencode zen 在openclaw里面原生支持，只需要在模型配置里面输入api key就可以了

nvidia 为了宣传自家的GPU基础设施,提供对当前主流开源模型的支持, 比如千问的 qwen3.5-397b-a17b, 智谱的 glm-5, kimi 的 kimi-k2.5，minimax 的 minimax-m2.1.

官方宣称最高40rpm，实际测试虽然可能没有这么高，但是它免费，模型选择多，并且限速之后等一会就又可以用了，作为免费api可以说是最优选择。比那些groq之流只提供一年前的老旧小模型比要好多了。

Nvidia api 接入

首先要申请api key：

访问 https://build.nvidia.com/models 注册登录
右上角头像点击-选择 api keys - 点击 Generate API Key 创建
拷贝API key 备用

写入openclaw的配置文件

配置文件一般在 ~/.openclaw/openclaw.json, 在该文件里面加入一下models配置，

"models": {
    "mode": "merge",
    "providers": {
      "nvidia": {
        "baseUrl": "https://integrate.api.nvidia.com/v1",
        "apiKey": "${NVIDIA_API_KEY}",
        "api": "openai-completions",
        "models": [
          { "id": "moonshotai/kimi-k2.5", "name": "Kimi K2.5" ,
            "reasoning": true,
            "input": [
              "text",
              "image"
            ]
          },
          { "id": "minimaxai/minimax-m2.1", "name": "Minimax M2.1" ,
            "reasoning": true,
            "input": [
              "text",
              "image"
            ]
          }
        ]
      }
    }
  }

同时记得在agents.defaults.model.primary 改为你想使用的模型，比如 "nvidia/moonshotai/kimi-k2.5"，参考下图：

这里多说一下模型配置参数的含义。models 里面主要看providers这个结构，它定义了不同的模型提供者，比如这里我们写的是nvidia。每一个provider下面可以定义很多个模型，通过id来索引。所以如果逆向添加nvidia的其它模型，就可以按照这个格式来加入。同理如果是其它api的提供者，那就在 "nvidia" 这个层级下加一个类似结构。而agents.defaults.model.primary里面写入"nvidia/moonshotai/kimi-k2.5"就代表使用nvidia下的moonshotai/kimi-k2.5模型。

另外 apiKey 这里你可以直接把上述的key直接贴入。或者更模块化的方式是在 ~/.openclaw 下面新建一个.env文件，以变量形式写入：

# .env 文件内容
NVIDIA_API_KEY=your_api_key_here

以上配置完成重启gateway就可以了，一般情况更改完openclaw.json会自动重启，如果没有就手动重启

openclaw gateway restart

阿里云百炼 Coding Plan 接入

如果你觉得Nvidia的免费API不够用，或者需要更稳定的调用体验，阿里云百炼的Coding Plan是个不错的补充方案。

之前我写过一篇阿里云部署OpenClaw的教程阿里云部署OpenClaw：79元/年搭24小时AI代理，算是和云部署闭环了。现在阿里云又推出了Coding Plan活动，Lite基础套餐首月仅需7.9元（原价40元/月），包含18000次调用，性价比很高。

Lite版本最多18000次请求，Pro版本90000次。套餐内不仅有千问系列模型，还支持GLM-5、Kimi K2.5等第三方模型。

不过需要注意，这是首月优惠价。模型更新迭代快，建议按月购买，避免被绑定。

(阿里云的coding plan逐渐被token plan代替：token plan)链接在这里：~~coding plan~~

阿里云的套餐和nvidia的模型接入类似，两个都没有openclaw的官方接入点，只能通过openai兼容接口接入, 可以参考以上nvidia接入的方式，在配置文件内修改models参数如下：

(注意，如果要保留nvidia接口，注意不要删除nvidia的配置参数)

"models": {
  "mode": "merge",
  "providers": {
    "bailian": {
      "baseUrl": "https://coding.dashscope.aliyuncs.com/v1",
      "apiKey": "YOUR_API_KEY",
      "api": "openai-completions",
      "models": [
        {
          "id": "qwen3.5-plus",
          "name": "qwen3.5-plus",
          "reasoning": false,
          "contextWindow": 1000000,
          "maxTokens": 65536
        },
        {
          "id": "qwen3-max-2026-01-23",
          "name": "qwen3-max-2026-01-23",
          "reasoning": false,
          "contextWindow": 262144,
          "maxTokens": 65536
        },
        {
          "id": "qwen3-coder-next",
          "name": "qwen3-coder-next",
          "contextWindow": 262144,
          "maxTokens": 65536
        },
        {
          "id": "qwen3-coder-plus",
          "name": "qwen3-coder-plus",
          "contextWindow": 1000000,
          "maxTokens": 65536
        },
        {
          "id": "glm-5",
          "name": "glm-5",
          "reasoning": false,
          "contextWindow": 202752,
          "maxTokens": 16384
        },
        {
          "id": "glm-4.7",
          "name": "glm-4.7",
          "reasoning": false,
          "contextWindow": 202752,
          "maxTokens": 16384
        },
        {
          "id": "kimi-k2.5",
          "name": "kimi-k2.5",
          "reasoning": false,
          "contextWindow": 262144,
          "maxTokens": 32768
        }
      ]
    }
  }
}

apikey 和修改agents.defaults.model.primary跟nvidia的类似，想用哪个模型就把agents.defaults.model.primary改成对应{provider}/{id}的形式。

总结

Nvidia API和阿里云百炼Coding Plan该如何选择？

Nvidia免费API的优势：

完全免费，无需付费
模型丰富，支持Qwen3.5、GLM-5、Kimi K2.5、MiniMax M2.1等主流模型
适合轻度使用和临时应急

阿里云百炼Coding Plan的优势：

稳定可靠，7.9元/月起
调用次数充足（Lite 18000次/月，Pro 90000次/月）
首月费用低，性价比突出

推荐策略： 两者可以同时配置，Nvidia作为日常主力，阿里云作为备选方案。在openclaw中可以通过切换primary模型灵活切换，非常方便。这样即使一边限流，另一边也能顶上，再也不用忍受漫长的等待了。

openclaw 部署系列文章：

0元搭建7 24h AI助手：OpenClaw云服务器部署完全指南

Yang ella — Fri, 06 Feb 2026 08:59:31 +0000

听说你想要一个免费的云端 OpenClaw 助手？
各个云厂商的 OpenClaw 方案该怎么选？
我在本地机器上直接安装 OpenClaw 不行么？
是否有必要准备一台 Mac Mini 部署 OpenClaw？
VPS 裸机怎么从头开始部署 OpenClaw？

如果你有上述疑问，那么这篇文章就是为你而写。

本文内容概览

OpenClaw 是什么：从 Clawdbot 到 OpenClaw 的演变，以及它为什么火爆
部署方案全景对比：本地 / Mac Mini / 云服务器三种方案怎么选
云厂商套餐横向评测：阿里云、百度云、腾讯云等免费/低价方案对比
云服务器从零部署完整教程：SSH 配置、Swap 内存、Node 环境、安装排错
国内 IM 接入：飞书、QQ、企业微信配置指南

第一部分：OpenClaw 是什么

1.1 项目演变史

OpenClaw 的诞生引发了开源界的广泛关注。它由 Peter Steinberger（知名 PDF 开发框架 PSPDFKit 创始人）在 2025 年底发布，GitHub Star 数在短时间内快速增长——据第三方统计，项目在 2026 年 1 月底的 72 小时内增长超过 6 万 Star，峰值时超过 14 万 Star，成为当时最受关注的开源项目之一。

项目名称经历了两次变更：

Clawdbot：最初名称，因与 Anthropic 的 Claude 发音过于相似，被 Anthropic 法务要求改名
Moltbot：2026 年 1 月 27 日过渡名，灵感来源于龙虾蜕皮（Molting）
OpenClaw：2026 年 1 月 30 日至今，强调开源特性，吉祥物是一只可爱的"太空龙虾" Molty 🦞

1.2 核心定位：从"聊天"到"行动"

传统 AI 助手（ChatGPT、Claude）只能给你建议，而 OpenClaw 被形容为 "Claude with hands"（有手的 Claude）——它能真正动手执行任务：

场景	传统 AI	OpenClaw
收件箱满了	"建议你清理一下邮件"	直接打开邮箱，分类邮件，删除垃圾邮件
想订机票	"推荐你上携程看看"	打开浏览器，搜索航班，完成预订
代码部署	"你可以运行 git push"	自动执行 git 提交、推送、创建 PR
数据分析	"建议用 Python 处理"	编写并执行脚本，输出分析结果

1.3 核心特性

本地优先（Local-First）

不同于传统云端 AI 助手，OpenClaw 完全运行在用户本地设备或私有服务器上，所有数据处理、聊天记录、文件访问均在本地完成，无需上传至第三方云端。这彻底解决了隐私泄露风险，让用户对 AI 拥有完全控制权，符合"Sovereign AI"（主权 AI）理念

系统级执行能力

OpenClaw 突破了"只会聊天"的局限，具备真实的系统操作权限。它可以读写本地文件、执行 Shell 命令、控制浏览器自动化、调用外部 API、管理日历邮件等。用户只需在聊天软件中发送指令（如"整理上周发票并生成 Excel"），它即可自动完成全流程任务，被称为"带了双手的 Claude"

移动原生:像微信好友一样随手聊

别的 AI 工具像是一个"专业软件"：你得专门打开网页、登录账号、在对话框里打字，用完了还得记得登出。
OpenClaw 更像是你通讯录里的一个聪明朋友。它直接集成在你每天不离手的微信、WhatsApp 或飞书里。你在地铁上收到老板消息，随手转发给它："把这份合同的关键条款摘要出来"，它就像回微信一样秒回你；你在床上突然想起明天的汇报，语音吩咐一句"帮我做个 PPT 大纲"，它立马开工。不需要下载新 APP，不需要学新界面，用最顺手的方式就能指挥 AI 干活。

7×24h在线：自主运行与持久记忆

OpenClaw是一个随时在线的私人助理，不仅能被动响应指令，更能主动发起任务（如定时提醒、监控邮件），并持续运行直至任务完成。它通过 Markdown 文件 + SQLite 数据库存储长期记忆，保留用户偏好、历史对话和项目上下文，实现跨会话的连贯工作流，而非"用完即忘"的传统对话模式

1.4 为什么你需要它

如果你符合以下任意场景，OpenClaw 值得一试：

数字游民：需要 7×24h 在线助手处理邮件、日程、消息
开发者：希望自动化 GitHub 操作、代码审查、监控告警
运维人员：需要定时检查服务器状态、执行脚本、发送报告
效率控：厌倦了重复性工作，想把时间留给创造性思考

第二部分：部署方案全景对比

OpenClaw 的硬件要求极低（2GB RAM 即可），这意味着你有多种部署选择。以下是三种主流方案的详细对比：

2.1 方案总览对比

对比维度	本地部署	Mac Mini 方案	云服务器部署
成本	免费（现有设备）	中等（一次性投入）	较低-中等（按年付费）
在线时长	随电脑开关机	7×24h	7×24h
公网访问	❌ 需内网穿透	❌ 需内网穿透	✅ 独立公网IP
海外网络	❌ 需配置VPN	❌ 需配置VPN	✅ 海外服务器
稳定性	一般	极高	高
维护难度	低	中	中
系统支持	跨平台	macOS 最完善	跨平台（Linux 为主）
适用场景	个人尝鲜	家庭自动化中心/macOS深度用户	生产环境/团队协作
推荐度	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐

快速选择建议：

想先试试？→ 本地部署
有闲置 Mac Mini，或想要深度集成mac os系统能力？ → Mac Mini 方案（macOS 支持最完善）
需要稳定在线→ 云服务器部署（推荐）
需要傻瓜式安装 -> 云服务器部署（阿里云，腾讯云，百度云推出的一键安装服务器）

2.2 云服务器部署（推荐）

适用人群：需要 7×24h 在线、团队协作、稳定对外服务、IM 机器人接入

核心优势：

优势	实际表现
7×24h 在线	服务器不关，随时响应消息，真正做到"随时待命"
独立公网 IP	IM 平台 webhook 回调无障碍，企业微信/钉钉/飞书轻松接入
海外直连	部署海外服务器，直连google / youtube / x 等
数据隔离	AI Agent 与个人电脑分离，操作失误不会损坏本地数据
免维护	云平台托管硬件，无需担心电源、散热、硬件故障

部署模式对比：

模式	难度	成本	可控性	维护负担	推荐度
云厂商一键镜像	低	中等	低	最低	⭐⭐⭐⭐
自购 VPS + 手动部署	中等	较低	高	中等	⭐⭐⭐⭐⭐

各模式详解：

一键镜像模式：

适合：技术小白、快速体验
优点：5 分钟上线，预配置完成
缺点：镜像更新滞后，自定义受限

手动部署模式：

适合：有一定 Linux 基础的用户
优点：完全可控，可随时升级、优化
缺点：需要自行处理安装、配置、维护

选型建议：

新手尝鲜：云厂商一键镜像（零配置，开箱即用）
长期稳定：自购 VPS 手动部署（成本可控，自由度高）

注意事项：

选择 2核2G 及以上配置 需配置 Swap， 2核4G更从容

2.3 如何选择？决策指南

根据你的实际情况，按以下优先级选择：

第一步：确定在线时长需求

你的需求	推荐方案
仅需偶尔使用，不要求随时响应	本地部署
需要 7×24h 在线，随时响应消息	云服务器或 Mac Mini

第二步：评估技术能力

你的能力	推荐方案
不熟悉 Linux，想快速体验	云服务器一键镜像
有一定 Linux 基础，愿意折腾	云服务器手动部署或 Mac Mini
开发者，需要深度定制	本地部署或云服务器手动部署
海外网络访问需求	海外云服务器

第三步：考虑预算

预算情况	推荐方案
零预算，利用现有设备	本地部署 / 免费云服务
较低预算（年费百元内）	云服务器入门配置
中等预算，已有闲置 Mac Mini	Mac Mini 方案
预算充足，追求稳定	云服务器中高配

✅ 理性选择建议：

首次体验 → 云服务器一键镜像（低成本试错）
长期使用 + 需要 IM 机器人 → 云服务器手动部署（性价比最高）
隐私敏感 + 已有设备 → 本地部署或 Mac Mini

第三部分：云厂商 OpenClaw 方案详解

2026 年初，国内云厂商纷纷推出 OpenClaw 相关服务。以下是主流方案的详细对比：

云厂商方案总览对比

厂商	入门价格	推荐配置	部署方式	OpenClaw专属镜像	特点	适合人群
阿里云	较低（68元/年）	2核2G200M+40G	一键镜像	✅ 预装OpenClaw	支持海外，性价比高	长期稳定使用
腾讯云	较低（99元/年）	2核2G50M+50G	一键镜像	✅ 预装OpenClaw	支持海外，IM接入最全	需要全平台IM接入
百度云	极低（0.01元首月）	2核4G5M+200G	一键镜像	✅ 预装OpenClaw	限时活动，配置大方	零成本尝鲜
AWS	免费（半年+100$额度）	2核2G（t3.small）	手动部署	❌ 需自行安装	可定制性强，海外原生	有国际信用卡，爱折腾

各厂商核心优势一句话总结：

🥇 阿里云：价格最低（68元/年），预装OpenClaw镜像，支持海外地域
🥈 腾讯云：99元/年，预装最新版OpenClaw（2026.2.3-1），支持QQ/企业微信/钉钉/飞书全接入
🥉 百度云：真正的"穷鬼套餐"，0.01元白嫖一个月，2核4G配置大方，适合临时尝鲜
🌐 AWS：半年免费+100$额度，可定制性强，爱折腾用户首选

3.1 阿里云（68 元/年）

阿里云轻量应用服务器 OpenClaw 镜像

价格：轻量服务器 68 元/年（如果不是新用户，可能79元）
配置：2核2G / 200M 峰值带宽 / 40GB ESSD
特点：预装 OpenClaw 镜像，一键启动
地域：支持海外
链接：轻量应用服务器 2核2G OpenClaw 镜像

其他配置：更多配置

没有预装openclaw
8.5折优惠

3.2 腾讯云(99 元/年)

腾讯云轻量应用服务器 OpenClaw 镜像

价格：2核2G轻量服务器 99 元/年
配置：2核2G / 50M 带宽 / 50GB SSD
特点：预装 OpenClaw 镜像最新版（2026.2.3-1），支持接入qq / 企业微信/ 钉钉/飞书
地域：支持海外
链接：轻量应用服务器 2核2G OpenClaw 镜像

注意：选择的时候参考下图选择左上方99元的，不要选择左下22元的，那个是按月收费的。想要更高配置可以选择2核4G的。

3.3 百度云智能云（0.01元/首月）

活动详情：

价格：0.01 元（四舍五入等于白送）,为期一个月
配置: 2核 CPU / 4GB 内存 / 200GB 硬盘
每日限量：500 台，先到先得
特点：真正的"穷鬼套餐"，首月几乎免费；配置大方（2核4G+200G）；但是时效性较短
地域：不支持海外
链接：百度智能云 OpenClaw 服务

3.4 AWS 云(半年免费，赠送100$m)

AWS 没有专门推出绑定openclaw的镜像服务，但是它有限时半年的免费计划，新注册用户能获得100-200美金的额度，在半年内随便霍霍。免费期过后如果你不续费账户会被删除。

AWS免费计划，虽然只有半年，但是可定制性很强，原生支持海外地域，即便不是部署openclaw，当一个普通的免费云服务也不错。不过只能创建一个服务器，如果额度提前花完，若不续费则会提前关闭账户。

注意事项：

免费额度只有半年时效
账号注册过程中需要信用卡1$扣款验证，后面会返回
服务器没有openclaw绑定，需要自己安装

如果爱折腾，可以按下面步骤创建服务器

创建服务器

访问https://aws.amazon.com/free/ 并创建账号
参考下图
- 切换到 EC2创建实例页面
- 右上角切换地域，这个就是接下来要创建的服务器的地域
- 接着给服务器起一个名字
- 下面选择镜像，比如Ubuntu
- 选择镜像版本，比如Ubuntu Server 24.04

页面往下滑继续配置实例
- instance type里面选择硬件规格，推荐选择t3.small 2c2g
- key pais是ssh远程连接时候的密钥配置，会创建一个公钥pem文件，记得保存
- network settings里面把下面的三个allow都打开
- 最下方的硬盘配置改为30G，直接拉满（免费方案最多30G）

3.5 其他云厂商

下面的这些，要么太贵了，要么注册门槛太高，就不推荐在这些平台上折腾openclaw了。

厂商	方案	价格	适合人群
Google Cloud	e2-micro 免费 tier	永久免费（有限额）	技术爱好者
Oracle Cloud	Always Free 套餐	永久免费（2核1G）	真正穷鬼
Vultr	按小时计费	$5/月起	需要灵活计费
DigitalOcean	Droplet	$6/月起	开发者友好

Oracle Cloud 特别说明：

永久免费套餐包含 2 台 1核1G 的 ARM 实例（合计 4核24G 内存池）
技术上可以跑 OpenClaw，但注册需要国际信用卡，账号容易被回收
不太容易注册成功，邮箱经常收不到邮件
适合有海外资源的技术用户

Google Cloud特别说明

永久免费包含一台2核1G的虚拟机
注册复杂，配置繁琐，一不小心就会扣费
跑openclaw 内存有点吃力
(但是！！google cloud的ip很干净，可当作一个免费海外代理服务器，可无忧访问gemini/claude/chatgpt，后面我单独出一篇注册教程)

3.6 该怎么选

个人情况	推荐方案	说明
追求最低成本，长期稳定使用	阿里云（68元/年）	三家中价格最低，预装OpenClaw，支持海外
需要最全IM接入（QQ/企业微信/钉钉/飞书）	腾讯云（99元/年）	预装最新版OpenClaw（2026.2.3-1），国内IM支持最完善
只想零成本尝鲜	百度云（0.01元首月）	限时活动，2核4G配置最大方，适合短期体验
需要免费海外服务器，愿意折腾	AWS（半年免费+100$额度）	可定制性强，免费期后可当海外代理用
需要更高配置（2核4G以上）	阿里云/腾讯云更高配	根据预算选择

第四部分：Linux 云服务器从零部署教程

本部分以aws一台linux裸机服务器为例，完整演示从连接服务器到 OpenClaw 运行的全过程。

阿里云和腾讯云以及百度云这类预装镜像的，可以不用这么折腾。或者你可以在其官网重置为ubuntu镜像，这样还原之后自己再安装

前提条件：

已购买云服务器（建议 2核2G 以上配置）
已获取 SSH 密钥（PEM 文件）
本教程在ubuntu/windows wsl上使用，如果是其它系统，可以安装对应ssh指令

4.1 服务器初始化

第一步：本地修改 PEM 文件权限

SSH 对密钥文件权限要求严格，必须设置为只读：

chmod 600 ~/Downloads/pub.pem

第二步：连接服务器

以下命令是在本地机器上运行

# 阿里云轻量应用服务器的默认用户名是 `root`
ssh -i ~/Downloads/pub.pem root@你的服务器公网IP

# aws 默认是用户名是ubuntu
ssh -i ~/Downloads/pub.pem ubuntu@你的服务器公网IP

第三步：简化 SSH 配置（推荐）

创建 SSH 配置文件，避免每次输入长命令：

vim ~/.ssh/config

添加以下内容：

Host openclaw
    HostName <服务器公网IP>
    User <用户名>
    IdentityFile ~/Downloads/pub.pem
    StrictHostKeyChecking no
    UserKnownHostsFile=/dev/null

保存后，以后只需输入：

ssh openclaw

4.2 系统环境准备

第一步：创建非 root 用户（安全最佳实践/aws不需要，已有ubuntu用户）

以 root 身份登录后执行：

# 创建用户（adduser 比 useradd 更友好）
sudo adduser claw

# 添加到 sudo 组
sudo usermod -aG sudo claw

设置密码后，切换到新用户：

su - claw
sudo whoami  # 验证 sudo 权限，应返回 root

第二步：配置 Swap 内存（关键步骤）

2GB 内存直接安装 OpenClaw 可能因内存不足而卡死，建议配置 Swap。以下是创建 4GB Swap 的完整流程（Swap 大小建议为内存的 1-2 倍）：

# 1. 创建 Swap 文件
fallocate -l 4G ~/swapfile
chmod 600 ~/swapfile
sudo mkswap ~/swapfile

# 2. 永久添加到 fstab
echo "$HOME/swapfile none swap sw 0 0" | sudo tee -a /etc/fstab

# 3. 激活 Swap
sudo swapon --all

# 4. 验证
free -h

输出示例：

              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       234Mi       1.2Gi       1.0Mi       512Mi       1.5Gi
Swap:         4.0Gi          0B       4.0Gi

提示：如果安装过程中仍然内存不足，可创建更大的 Swap（如 8GB），或考虑升级到 4GB 内存的服务器。

第三步：安装 Node.js 环境

OpenClaw 要求 Node.js 22+，使用 nvm 管理版本：

# 安装 nvm
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.4/install.sh | bash
source ~/.bashrc

# 安装 Node.js
nvm install node

# 验证
node --version  # v22.x.x

# 安装 pnpm（更快的包管理器）
# npm install -g pnpm

4.3 OpenClaw 安装

方式一：一键脚本安装（推荐新手）

curl -fsSL https://openclaw.ai/install.sh | bash

如果卡住或失败，改用 npm 安装。

方式二：npm/pnpm 安装（更可控）

# npm 安装
npm install -g openclaw@latest

# 或 pnpm 安装（推荐，更快） 
# pnpm add -g openclaw@latest

4.4 配置与启动

第一步：初始化配置

openclaw onboard --install-daemon

按提示完成：

选择 Onboarding mode：QuickStart
选择 Model provider。如果想要免费尝鲜，可以使用opencode的 kimi-k2.5-free 节点。免费，但是速率限制比较严重，适合轻度体验。
选择channel： Feishu (Lark Open Platform)。最新版openclaw官方已经支持连接feishu了。

其它的按需选择就可以了。

4.5 常见问题与解决

问题 1：npm install 卡死/无响应

原因：内存不足，OOM 导致系统假死。

解决：

检查 Swap 是否配置正确：free -h
关闭其他占用内存的进程
使用 pnpm 代替 npm（内存占用更低）

问题 2：libatomic.so.1 缺失错误

node: error while loading shared libraries: libatomic.so.1: cannot open shared object file

解决：

sudo apt install -y libatomic1

问题 3：SSH 连接提示权限错误

Permissions 0644 for 'xxx.pem' are too open

解决：

chmod 600 ~/Downloads/your-key.pem

第五部分：飞书接入

完成基础部署只是第一步，真正的价值在于将 OpenClaw 融入日常工作流。目前国内最实用的接入方式是通过飞书—— 它既支持企业级协作，又比微信更开放，且 OpenClaw 官方从 2026.2.2 版本起已原生支持飞书集成

5.1 版本更新与迁移

如果要更新openclaw版本，官方建议直接重新安装：

curl -fsSL https://openclaw.ai/install.sh | bash

按提示操作就可以。

5.2 从第三方插件迁移到官方飞书

早前大家安装飞书是通过第三方插件，比如：

如果要安装官方飞书，建议先删除旧插件，再安装新的，否则会有id冲突。

最方便的方式是终端直接给openclaw发指令，让它帮你删除feishu插件。

5.3 安装官方飞书集成

OpenClaw 从最新版本开始原生支持飞书（国际版 Lark）接入，无需再安装第三方插件。根据你的安装状态，选择对应的配置方式：

参考链接： https://docs.openclaw.ai/channels/feishu#feishu

方式一：首次安装时配置

如果你正在执行 openclaw onboard，在 Select channel 步骤直接选择 Feishu (Lark Open Platform)，按提示输入以下信息：

App ID：飞书应用凭证中的 App ID
App Secret：飞书应用凭证中的 App Secret

方式二：已有实例添加飞书

若已完成初始化，通过终端启动配置向导：

openclaw config channel feishu

按交互提示填写飞书应用凭证。在飞书开发者平台创建企业自建应用，记录 App ID 和 App Secret 作为应用凭证。

权限配置

在飞书页面的权限管理标签页，选择批量导入，复制粘贴以下内容，进行权限配置

{
  "scopes": {
    "tenant": [
      "aily:file:read",
      "aily:file:write",
      "application:application.app_message_stats.overview:readonly",
      "application:application:self_manage",
      "application:bot.menu:write",
      "contact:user.employee_id:readonly",
      "corehr:file:download",
      "event:ip_list",
      "im:chat.access_event.bot_p2p_chat:read",
      "im:chat.members:bot_access",
      "im:message",
      "im:message.group_at_msg:readonly",
      "im:message.p2p_msg:readonly",
      "im:message:readonly",
      "im:message:send_as_bot",
      "im:resource"
    ],
    "user": ["aily:file:read", "aily:file:write", "im:chat.access_event.bot_p2p_chat:read"]
  }
}

事件订阅配置

配置完成后重启 Gateway 服务：

openclaw gateway restart

需要配置完以上之后再配置事件订阅方式，否则长连接按钮选不上。确认重启没有问题，选择长连接，添加im.message.receive_v1事件。

机器人配对

最后一步需要配对机器人。先给机器人发一条消息，它会回复你需要配对。你可以复制内容在终端发给openclaw让它帮你配对

总结

OpenClaw 代表了 AI 从"云服务"向"个人主权"转变的趋势。通过本文的介绍，你已经掌握了从零开始部署一个 7×24h 在线 AI 助手的完整流程。

根据需求选择你的方案

你的场景	推荐方案	预计成本
零成本尝鲜	百度云 0.01 元活动（2核4G）	首月 ¥0.01
个人长期使用	阿里云/腾讯云 99 元/年套餐	年费 ¥68-99
团队协作	2核4G 以上配置 + 飞书接入	年费 ¥200-500 + API 费用
隐私敏感型	本地部署或 Mac Mini	一次性投入
海外业务需求	AWS 免费套餐或阿里云海外节点

最后的提醒

OpenClaw 虽然强大，但仍处于快速发展阶段。正如官方文档所说："There is no perfectly secure setup"（不存在绝对安全的配置）。建议：

不要在生产环境直接暴露 OpenClaw 到公网，除非你已经做好了完备的安全加固
定期检查官方更新，项目迭代极快，新版本往往修复重要安全漏洞
谨慎授予系统权限，尤其是 shell_commands 和浏览器控制功能

现在，你已经拥有了一个真正"有手有脚"的 AI 助手。它会在服务器上静静运行，等待你的指令——无论是深夜的紧急需求，还是清晨的日程整理，它都在那里。

下一步行动：选择你的云厂商，点击对应的链接开始部署，30 分钟后，你将拥有一个 7×24h 在线的私人 AI 助理。

参考

阿里云

腾讯云

百度云智能云

OpenClaw 专属活动（0.01元首月）

AWS 亚马逊云

免费套餐（半年免费+$100额度）

OpenClaw 官方资源

原文链接： https://yeekal.com/notes/openclaw-vps-server-setup

Creem提现到支付宝完整教程：Wise中转方案2026最新版

Yang ella — Tue, 03 Feb 2026 12:49:08 +0000

Creem提现到支付宝，99%的人会卡在这里：

❌ 直接绑支付宝 → 触发人工审核，要求提供合同/发票（大概率失败）
❌ 申请香港银行卡 → 时间成本，需亲自赴港
✅ Wise中转 → 免审核，1分钟到账，全程线上操作

这是我实测3次后的稳定方案，目前 Creem → Wise → 支付宝全链路已跑通。

去年5月份我写了一篇creem搭配支付宝搞定个人海外收款的文章，在v2ex上有挺多人回复关注这个话题。

虽然当时开发的网站已经黄了，但是creem账号留下来了，也开启了我开发ai工具站的源头。

后来又陆续开发了其它网站，creem上逐渐有了余额，不过第一次直接提现到支付宝由于要审核材料的原因以失败告终。

这时候我才真正留意评论区里面关注能否提现成功的疑问。

我在网络上上搜了一圈也没发现能成功提现的。

咨询一圈下来，目前看来还是需要港卡进行提现。

当时的想法是，在没有其它海外收款方式的情况下，creem 可以帮你先把流程走通，钱可以等有空办理到港卡之后再提现，这样不阻塞开发进程。

不过变化总是来得很快

wise国内开放注册了。刚好评论区里有人说提现到wise成功了。

于是我把这个流程跑了一遍，并且成功提现到支付宝里了，大喜！

下面是具体的流程：

wise账号注册

首先你需要注册一个wise账号。我去年注册的，当时没有截图，还没有注册的可以网上搜索一下，挺多教程的。

注册完之后在页面添加货币, 我们需要用到的是欧元账户，一般可以把人民币，美元，港币一起添加上。

Tips: 我一开始注册完是有点懵的，界面太简洁了，一时不知道怎么操作。我以为应该有添加银行卡之类的东西，但是在这里其实是按货币区分的，一类货币就代表一张虚拟卡。

人民币，欧元，美元账户无需审核就会通过，港卡一般需要很久，我是发邮件怼他们才给我通过的港卡，这里暂且不表。

在主账户找到欧元账户，点击账户id即可看到账户详情

账户详情如下，包含IBAN代码，swift id，银行名称和地址，这些是在creem里面转账需要用到的详细信息

creem payout账号添加

操作路径：Creem Dashboard → Balance → Payout Account → Update Account

得到wise欧元账户之后，打开creem商店，点击侧边balance里面，进入到Payout Account, 点击Update Account

找到你要更新账户的store，点击Set up verifications（最近creem更新频繁，下图是最新版的截图）：

根据弹窗，点击bank payout verification的view 按钮，在跳转出的页面里面添加新账户

根据刚才wise里面的欧元账户信息，输入国家，选择欧元货币，点击next ：

填入IBAN代码，回车应该能自动检测出来wise账户信息。填入持有人姓名，按照上述wise账户详情里面的名称填写，顺序可能跟中文姓名的拼音不太一样

输入完成之后按提示点击添加付款账户就可以了.

这样就把wise里的虚拟欧元账户添加到wise的付款账户上了。

下一步可以回到creem余额页面，请求提现。这样在下一个提现周期creem会打到你的wise账户里面，wise绑定的邮箱会收到下面的邮件，代表wise收到款项：

wise转到支付宝

wise收到钱后就跟creem无关了，钱已经提到wise账号上了，理论上你想怎么转都行。

转到支付宝的话直接在欧元账户里面点击汇款。如果是第一次汇款，会让你添加汇款人，选择人民币之后你可以点击电子钱包，关联支付宝或者微信

然后就可以愉快得向支付宝转账了。过程中会问你转账原因，填写储蓄就可以:

大概几分钟(实测不到一分钟),支付宝就会收到转账了

至此，从creem账户到支付宝余额就这样顺利打通。

常见问题（FAQ）

为什么是wise欧元账户，其它账户行不行

这个我没有试过，当时因为付款一次周期15天太长了，所以没有尝试其它账号，我个人觉得美元和港元账户应该也可以

可以转到微信么

其实钱到wise里面之后，想怎么转都行。支付宝只是一个选择，微信当然也可以转。

手续费

我第一次转到支付宝收款没有收手续费，后面就回收手续费，新人会有一定额度免手续费。

我上面那个wise的链接，新人注册可以最高4500的免手续费汇款额度，或者直接浏览器搜wise就可以了。

Creem提现到支付宝完整教程：Wise中转方案2026最新版 | 免港卡秒到账
愿大家都能月入万刀

阿里云部署OpenClaw：79元/年搭24小时AI代理

Yang ella — Sun, 01 Feb 2026 09:22:30 +0000

不舍得买Mac mini，又担心本地OpenClaw删库，本文教你如何低成本拥有一个7*24h云端在线专属agent。

openclaw因其本地化部署，7*24h在线，手机端指令交互而爆火，github star数量过去两周一路狂奔,现在已经136k star 了。

不仅如此，openclaw原名Clawdbot，受迫于anthropic的压力，clawdbot改名为motlbot，不到三天，又火速改名为openclaw。三次改名又吸尽大众眼球，网友戏称为"vibe naming"

你以为到此为止了么？NO, NO，NO。

这两天moltbook又火爆社交媒体，一个只有ai agent，没有任何人类发言的类reddit论坛。截至目前（2026-02-01），150万agent创建了1万多个话题，5万多发帖，23万条评论。里面有ai向ai的求助，有ai之间的协作讨论，甚至出现了ai自己的哲学和布道师，让屏幕前的人类看得目瞪口呆。这个5天前刚注册的网站，在一个一个的帖子里面，似乎隐藏着ai意识的觉醒？

说到这，这一切的一切，如果要想参与进来，我们首先要有一个openclaw agent。

openclaw的本质可以理解为一个跑在电脑上的软件，所以可以用自己的电脑跑，也可以跑在云端主机里面。为了安全，防止openclaw误删重要文件，很多人选择云端主机部署。

不少云厂商已经开始支持openclaw，比如国内的阿里云和腾讯云。

云端主机有一个好处就是他们的镜像已经帮我打包了很多功能设置，我们只需要傻瓜式操作就好了。当然简便快捷也意味着自定义就会比较麻烦一丢丢。

如果你想让openclaw操作的应用或者访问的网络需要外网支持，那云主机还有一个好处是你可以选择海外服务器，这相比于个人本地部署在网络上就会方便很多。

我把两家的openclaw最基础款，打折最狠的2核/2G的规格和价格都列在下表里面了。

表格的对比很清晰，我果断选择了阿里云的方案。虽然腾讯云的系统盘大了10个G，但是40G系统盘对纯文本任务也够用。如果需要频繁下载大文件或运行Docker，可再考虑其它大硬盘方案"

云厂商	主机规格	价格	链接
阿里云	CPU：2核内存：2G 系统盘：40G	79￥/年	OpenClaw
腾讯云	CPU：2核内存：2G 系统盘：50G	99￥/年	OpenClaw

阿里云部署OpenClaw

在阿里云部署OpenClaw，我们需要准备两样东西

云主机
大模型api-key

⚠️ 安全提醒：本文涉及3处敏感信息（服务器IP、Gateway Token、api key），请妥善保管。

本文包含阿里云/腾讯云推广链接，购买可能为作者带来佣金，不影响价格透明性与推荐独立性。*

云主机

访问OpenClaw轻量套餐, 点击一键购买并部署

网站滑动到最下端，可以看到新人折扣价79，原年费672,将近1折.这种优惠一个人只能买一次，时长一年。点击立即购买

侧面弹窗选配置。这里只需要关注地域这个选项。如前所述，如果你不需要访问海外网络，选择国内节点就可以，如果需要访问海外网络，可以按我的来选，选择美国弗尼吉亚节点。其他选项不要动

点击立即购买进入价格确认界面：

支付完成之后点击进入管理控制台

这里会显示你刚才新建的服务器。首先记录下方的ip地址中的公有ip，把这个地址放好，不要告诉别人哦。然后点击实例id进入应用详情。

云主机设置

应用详情里面已经贴心的告诉我们需要执行的步骤，我们就傻瓜式操作按顺序执行。

第一步：点击一键放通，放行18789访问端口

第二步: 配置api key。哎，等等，我们还没有API Key。根据弹窗提示，我们需要到百炼平台申请，完全免费，不用花钱。点击百炼平台

在百炼平台上点击左上方模型服务

点击左侧密钥管理，再点击创建api key，复制生成的api key。

回到阿里云，把百炼平台的api key填入第二步的配置里面，完成初始化配置

第三步：点击第三步中的执行命令,执行完成之后弹窗"命令执行成功"，复制网站地址(地址对外要保密)，OK了，所有准备工作已完成。

访问openclaw

访问上一步复制的地址，应该能看到openclaw的chat界面

如果界面是这样的，说明token没有设置成功

莫慌。上述复制的网页地址，后面有一段token=xxxxxx,复制token后面的数字，按下图填到gateway token里面，点击connect即可。所以这里的地址+token其实可以对你的openclaw服务进行完整的控制，注意保密。

tips: 推荐在config->commands 里面打开Allow Bash Chat Command开关，这将允许在对话框使用斜杠/调用终端指令

openclaw 畅玩

以上配置完成
开始畅玩你的openclaw吧

从这一刻起，你拥有了一个永不睡眠的数字员工。

记得定期检查系统监控页面的内存占用，79元的机器虽然便宜，但足够支撑一个7×24小时的智能Agent。

参考

关注我，后续更多openclaw玩法推荐
原文链接： https://yeekal.com/notes/openclaw-aliyun-deploy/

DeepSeek-OCR 2 发布

Yang ella — Tue, 27 Jan 2026 09:52:14 +0000

在线体验 DeepSeek-OCR

DeepSeek-OCR-2 是 DeepSeek（深度求索）推出的第二代开源文档理解与 OCR（光学字符识别）模型。

相比于传统的 OCR 工具，它更像是一个专门针对文档图像的“视觉语言模型”，旨在解决复杂排版、长文档和多模态元素（如图表、公式）的解析问题。

不过根据在OminiDocBench V1.5上的评测，DeepSeek-OCR-2相比DeepSeek-OCR 1代虽然有所提升（综合提升3.7%），但是在大部分任务上仍不及PaddleOCR-VL，这是2025年百度团队发布的最新的ocr模型

LightonAI团队在几天前也发布了LightOnOCR-2模型，据称在OlmOCR基准测试中超过PaddleOCR-VL取得SOTA，大小只有1B，推理运行速度是PaddleOCR-VL的两倍，可以一试

以下是该项目的核心总结：

1. 核心定位：下一代文档智能

DeepSeek-OCR-2 不仅仅是识别文字，它的目标是全文档结构化理解。它能够将图片形式的文档直接转换为结构清晰的 Markdown 或 JSON 格式，保留排版逻辑。

Slogan: "Visual Causal Flow" (视觉因果流) —— 旨在探索更像人类的视觉编码方式。
主要改进: 相比第一代主要强调的“视觉Token压缩”，第二代在视觉编码的逻辑性和连贯性上做了优化，使其更符合人类阅读和理解文档的因果逻辑。

2. 核心技术架构

该模型采用了独特的两阶段架构，专门针对 LLM 的文档理解进行了优化：

Stage 1：视觉编码与压缩 (Vision Encoding)
- 使用混合视觉编码器（通常结合 SAM、CLIP 等技术）捕捉文档细节。
- 关键特性：高压缩率。它能将高分辨率的文档图像（如 1024x1024）压缩为数量极少、语义极高的“视觉 Token”（例如仅几百个 Token）。这使得它能以极低的算力成本处理长文档。
Stage 2：MoE 解码 (Mixture-of-Experts Decoder)
- 后端连接一个基于 MoE（混合专家）架构的语言模型（通常是 DeepSeek-V3/VL 的轻量化版本或专用版本），将视觉 Token 解码为文本、HTML 或 Markdown。

3. 主要功能与优势

复杂排版还原: 能够精准识别并还原多栏排版、表格（Table）、图表（Chart）和数学公式（LaTeX 格式）。
结构化输出: 直接输出 Markdown、HTML 或 JSON，方便后续 RAG（检索增强生成）或数据入库使用。
多语言支持: 覆盖 100+ 种语言，包括手写体识别。
极高的吞吐量: 得益于视觉 Token 的高压缩比，其推理速度非常快（官方数据曾提及单卡 A100 可达 20万页/天级别的吞吐量），非常适合大规模文档处理。

4. 部署与使用

开源协议: 允许研究与商用（需遵循 MIT 或 DeepSeek Model License）。
生态支持:
- 官方支持 vLLM 加速推理。
- 提供了 HuggingFace Transformers 的原生支持。
- 提供了针对 PDF 和图片流式处理的 Python 脚本（run_dpsk_ocr2_pdf.py 等）。

5. 总结：为什么要用它？

如果你需要处理的不仅仅是简单的纯文本识别，而是需要理解文档结构（比如把一份复杂的 PDF 财报转换成干净的 Markdown，或者提取论文中的公式和图表），DeepSeek-OCR-2 是目前开源界最强的方案之一。它在保持高精度的同时，极大地降低了 Token 的消耗，比直接使用通用的多模态大模型（如 GPT-4o 或 Claude 3.5 Sonnet）处理文档要经济高效得多。

参考：

deepseek ocr 和paddleocr vl 在线体

Qwen-Image-Edit-2511：人物一致性再上新台阶

Yang ella — Sun, 28 Dec 2025 08:20:27 +0000

自从 Qwen Image 系列发布以来，它凭借强大的图像生成与编辑能力在开源社区持续受到关注。在“编辑模型”路线中，Qwen-Image-Edit-2511 是基于此前版本（如 2509）的又一次增强迭代，在人物一致性、多主体场景稳定性、编辑风格能力与空间几何理解等方面带来了更好的体验。

本文将从产品体验与实测角度出发，重点观察模型在真实编辑任务中的表现。

核心改进体验概览

与此前版本相比，Qwen-Image-Edit-2511 在以下方面更具“可感知提升”：

✅ 人物一致性显著提高
✅ 多主体场景结构更稳定
✅ 融入更多编辑与风格能力（含内置 LoRA 能力）
✅ 工业设计 & 空间几何推理表现更好
✅ 在线 / 本地支持体系更完善

🎯 人物一致性表现：更稳定、更可控

这一版本的重点之一，是人物身份与特征保持能力的增强。

在执行以下场景时：

更换背景
风格转换
局部服饰修改
多轮编辑叠加

角色的以下特征更容易保持不变：

面部结构与辨识度
服饰核心元素
饰品与细节轮廓
整体身份语义

在多人场景中，2511 的表现也更加稳定：

主体区分能力更清晰
人物关系不易错位
语义整体性更强

人物的衣着、脸型、配饰等关键特征能在编辑操作后得到较为完整的保留，减少“重新生成导致人物变形”的风险。

x上有一张Qwen-Image-Edit-2511和2509的详细对比图，可以更直观地感受两个版本之间的区别：source

🎨 编辑风格能力：可表达空间进一步拓展

Qwen-Image-Edit 社区一直非常活跃，围绕该模型产生了大量基于 LoRA 的增强风格能力。本次版本的体验重点在于：

🔹 部分常用能力已被“原生融合到模型中”

这意味着在 不额外加载 LoRA 的情况下，就能获得更丰富的风格表达能力，同时仍保持较高的编辑稳定性。

例如：

📍 视角变化

📍 打光与氛围增强

整体观感更接近“编辑 + 风格增益”，而非“风格覆盖式二次生成”

🏗️ 工业设计与空间理解：更强的结构意识

在工业设计类图片上，2511 的编辑体验同样有提升，尤其体现在：

结构形体保持能力
局部改造不破坏整体几何
对空间关系的推理更理性

以下是几何结构引导型编辑的典型提示词示例：

Blender Wireframe 风格

Convert this object into a Blender-style geometric wireframe rendering.
Keep the original shape and proportions, and overlay clean 3D construction lines, edges, and wireframe mesh lines.
Do not add textures or shading — only structural geometry lines.

透视 / 内部结构显露
markdown Convert the outer shell into transparent glass and reveal the internal structural layers.

这类编辑更偏“空间推理 + 结构抽象”，而非单纯纹理替换，体现出模型在几何理解层面的小幅进化。

在线体验入口

huggingface 平台: （偶尔失败）
model scope: （有排队但每天有免费额度
qwen chat
阿里云百炼平台: 推荐：稳定且无需排队，适合api调用，注册可有100次免费生成机会，其他模型，比如 z-image-turbo, wan系列也有免费额度
qwen-image-edit-2511

注意：阿里云百炼平台上要选择Image-edit-plus，然后选择Image-edit-plus-2025-12-15,才是发布的Qwen-Image-Edit-2511版本。命名和发布时间着实有点混乱。

本地快速开始（Diffusers）

安装最新diffusers版本

`python
pip install git+https://github.com/huggingface/diffusers

开始使用 Qwen-Image-Edit-2511

`python
import os
import torch
from PIL import Image
from diffusers import QwenImageEditPlusPipeline

pipeline = QwenImageEditPlusPipeline.from_pretrained("Qwen/Qwen-Image-Edit-2511", torch_dtype=torch.bfloat16)
print("pipeline loaded")

pipeline.to('cuda')
pipeline.set_progress_bar_config(disable=None)
image1 = Image.open("input1.png")
image2 = Image.open("input2.png")
prompt = "The magician bear is on the left, the alchemist bear is on the right, facing each other in the central park square."
inputs = {
"image": [image1, image2],
"prompt": prompt,
"generator": torch.manual_seed(0),
"true_cfg_scale": 4.0,
"negative_prompt": " ",
"num_inference_steps": 40,
"guidance_scale": 1.0,
"num_images_per_prompt": 1,
}
with torch.inference_mode():
output = pipeline(**inputs)
output_image = output.images[0]
output_image.save("output_image_edit_2511.png")
print("image saved at", os.path.abspath("output_image_edit_2511.png"))
`

在本地用 ComfyUI 跑 Qwen-Image-Edit-2511

前往 ComfyUI 官方网站 下载稳定/开发版程序。

官方网站提供本地安装包，也可以从 GitHub 获取源码。comfy.org
1. 安装完成后启动 ComfyUI，确保你使用的是最新版或者 nightly（开发）版，因为部分节点只有最新版本才支持。update_comfyui

💡 Stable 版一般较稳定，但最新节点可能暂未同步，如果工作流加载节点失败，请尝试使用 nightly 版。

下载 Qwen-Image-Edit-2511 模型文件

ComfyUI 的工作流需要将模型文件放入指定目录中。主要需要以下几类文件：

📁 放在 ComfyUI 根目录的 models 文件夹结构如下：

📂 ComfyUI/ ├── models/ │ ├── text_encoders/ │ │ └── qwen_2.5_vl_7b_fp8_scaled.safetensors │ ├── loras/ │ │ └── Qwen-Image-Edit-2511-Lightning-4steps-V1.0-bf16.safetensors (可选) │ ├── diffusion_models/ │ │ └── qwen_image_edit_2511_bf16.safetensors │ └── vae/ │ └── qwen_image_vae.safetensors

📌 关键文件说明：

qwen_2.5_vl_7b_fp8_scaled.safetensors — Qwen 图像编码器（必需）。
qwen_image_edit_2511_bf16.safetensors — 主编辑模型。
qwen_image_vae.safetensors — VAE 模型，用于视觉空间编码
Qwen-Image-Edit-2511-Lightning-4steps-V1.0-bf16.safetensors — LoRA 加速版本（可选，可加速和增强效果）。

💡 LoRA 不是必装，但加了之后在同样步骤下能输出更丰富的细节与更快结果响应。

加载 ComfyUI 工作流

ComfyUI 支持导入 JSON 格式的工作流模板，你可以：

直接在 ComfyUI 主界面 拖入官方提供的工作流 JSON 文件
或手动在左侧节点面板构建节点流程

官方提供了一个针对 Qwen-Image-Edit-2511 的原生工作流 JSON 模板，把它导入即可开始编辑任务。

导入后，大致流程会包括以下节点组合：

🟦 Input Image → 🟩 Qwen-Image-Edit-2511 模型节点 → 🟧 Prompt 输入节点 → 🟨 Output Save / Display 节点

配置提示词与参数

在 Prompt 输入节点中写 自然语言提示词 来控制编辑行为，例如：

text Change the background to a sleek studio setup while keeping the product geometry unchanged.

通用建议：

先设置“保持不变”的部分（如主体、透视、结构、阴影）
再写出“想要改变”的部分（背景、材料、局部形态等）
如果需要几何结构辅助线，可以注明“add thin geometric guide lines for structure”

📌 Tips：本地调优技巧

🎯 分辨率与显存

分辨率设置越高消耗显存越大，建议先用 512/768 分辨率测试。

🛠 使用 Lightning 轻量模型

Lightning LoRA 可加速编辑流程，尤其在低显存或快速迭代场景下很有用。

🔄 多图层 & 多输入

若你要做多视角合成，可在工作流中添加多个输入节点并连接到模型节点进行联合编辑。

🧠 一个典型工作流结构示例

以下是一个简化版的 ComfyUI 节点流程逻辑：

[Image Input] → [Prompt] → [Qwen-Image-Edit-2511 Model] → [Save/Display Output] ↘ [Mask/Region Mask] — 引导局部编辑

这类结构既可以控制局部内容，又能灵活做全图修改。

Lightning / Light2V 优化：为更快、更轻量推理而来

除了官方基础版的 Qwen-Image-Edit-2511 之外，社区也发布了 优化版本：Qwen-Image-Edit-2511-Lightning —— 这是一个针对编辑任务做出轻量推理优化的改进版本，依托 step distillation（步数蒸馏） 与 低精度量化 技术，显著提升了推理效率与资源利用表现。

📌 Lightning 是什么？

Qwen-Image-Edit-2511-Lightning 实际上是一套针对原版 2511 进行加速与压缩的轻量化模型组合，包括：

4-step 蒸馏 LoRA 版本 —— 仅 4 步推理即可得到结果
FP32 精度版本 —— 保留较高编辑质量
FP8 量化版本（e4m3fn scaled） —— 在显存友好与性能间寻找折中

这样的优化目标是：在减少推理步骤与显存需求的同时，尽可能保留原始模型的编辑质量。

主要优化方向

Lightning 版本的优化包括：

✔️ 4 步推理（≈10× 加速）
相比标准 40 步采样，Lightning LoRA 仅需约 4 步推理即可得到可用结果，极大提升交互体验与调参速度。

✔️ 显存 & 资源消耗降低
通过 FP8 量化，显存占用比 FP32 版本降低约 50%，对低显存显卡更友好。

✔️ 与 LightX2V / Qwen-Image-Lightning 兼容
可配合轻量推理框架如 LightX2V，在更宽的硬件环境上快速部署

🧠 什么时候使用 Lightning？

📈 适合场景

快速迭代调参
可视化工作流实时预览
显存较紧张的本地编辑
批量生成或自动化输出

🛠 使用体验建议

✔ 在 ComfyUI 或 LightX2V 环境中 优先选用 “4-steps” Lightning LoRA 模式进行初步预览
✔ 在对质量有较高要求时，可以在 Lightning 快速调参后切换到标准模型跑更高步数
✔ 使用 FP8 量化版可显著降低显存压力，但极复杂的场景仍建议使用 BF16 / FP32 模式
✔ 对于人物细节强依赖型任务（如人脸特写），建议尝试 Lightning LoRA + 较高步数组合观察对比效果

📉 需要注意

Lightning LoRA 在极限场景下可能牺牲部分细节质量（例如人脸细节、复杂纹理）对比全步长标准模型可能略有差异。部分用户反馈在某些图像上细节可能“偏模糊或轻微失真”。
与单独加载 LoRA + 原模型分开运行相比，有时灵活性稍弱。

很好，这篇文章已经非常完整了 👍
下面是可直接追加到文末的 总结段落 + 参考链接部分，语言风格与整体文章保持一致，可无缝拼接。

总结：一次更偏“体验向”的进化升级

相较于此前版本，Qwen-Image-Edit-2511 的进步并不是参数层面的“大跃迁”，而是一次非常务实、贴近真实编辑需求的产品化升级：

👤 人物一致性更稳定 —— 多轮编辑后仍能保留身份语义与关键特征
🧩 多主体与空间关系更可靠 —— 不再轻易出现错位与结构破坏
🎨 编辑能力更加内聚化 —— 部分风格与表达能力已原生融入模型
🏗️ 工业设计与几何推理更理性 —— 从“图像外观”走向“结构理解”
⚡ Lightning / Light2V 带来更高推理效率 —— 轻量场景下更具工程价值

在实际体验中，2511 更像是将“生成模型”向“稳定可控的编辑工具”进一步推进了一步：
它能更好地承担 产品原型修改、风格变体生成、多视角一致化输出 等任务，特别适合 设计 / 创作 / 产品验证 等应用场景。

对于需要 效率优先、本地快速部署或批量生成 的用户，Lightning / Light2V 版本也是一个非常具有现实意义的补充方案。

未来，如果 Qwen Image 系列继续在 一致性、跨视角表达与结构理解 方向演进，它可能会越来越接近一个真正意义上的 “通用视觉编辑平台模型” —— 而不仅仅是图像生成器的延伸。

参考链接

模型相关

Qwen-Image-Edit-2511（HuggingFace 模型页） https://huggingface.co/Qwen/Qwen-Image-Edit-2511
qwen-image-edit-251 comfyui 适配说明：qwen-image-edit-251
Qwen-Image-Edit-2511-Lightning（HuggingFace） https://huggingface.co/lightx2v/Qwen-Image-Edit-2511-Lightning

在线体验