无尘阁日记

OpenClaw 报错：Managed Codex app-server binary was not found 的根因与修复方法

Thu, 28 May 2026 20:56:57 +0800

OpenClaw 报错：Managed Codex app-server binary was not found 的根因与修复方法

一、问题现象

在 OpenClaw 使用 Codex 嵌入式代理时，出现如下报错：

Embedded agent failed before reply:
Managed Codex app-server binary was not found for @openai/codex.
Reinstall or update OpenClaw, or run pnpm install in a source checkout.
Set plugins.entries.codex.config.appServer.command or OPENCLAW_CODEX_APP_SERVER_BIN to use a custom Codex binary.

这个错误的直观表现是：

OpenClaw 已经收到了任务，也已经尝试启动 Codex 嵌入式代理，但在真正回复之前，Codex app-server 启动失败了。

换句话说，这不是模型回答质量问题，也不是 prompt 问题，而是 OpenClaw 在调用 Codex 本地服务时，找不到应该启动的 Codex app-server 可执行文件。

二、第一层理解：这个错误到底是什么意思？

这句话的核心是：

Managed Codex app-server binary was not found

意思是：

OpenClaw 的 Codex 插件默认会尝试使用它自己管理的 Codex app-server binary，也就是所谓的 managed binary。

但当前环境里，这个 managed binary 没找到。

所以 OpenClaw 给了三个方向：

Reinstall or update OpenClaw

重新安装或更新 OpenClaw。

run pnpm install in a source checkout

如果你是源码安装 OpenClaw，那么进入源码目录执行 pnpm install。

Set plugins.entries.codex.config.appServer.command or OPENCLAW_CODEX_APP_SERVER_BIN

手动指定 Codex app-server 的启动文件。

前两个办法适合普通安装缺失、源码依赖缺失的问题；但如果你反复重装仍然不行，就说明真正的问题不在 OpenClaw 主程序本身，而在 OpenClaw 找 Codex app-server 的路径逻辑上。

三、为什么重装 OpenClaw 也没用？

这类问题最容易误判成“OpenClaw 没装好”。

但实际排查下来，重装很多次仍然报错，通常说明：

OpenClaw 主程序是好的，Codex 也可能已经安装成功了。

真正坏的是：

OpenClaw 没有找到正确的 Codex app-server binary。

尤其在 Windows 环境里，经常会出现这种情况：

你已经通过 npm 安装了 @openai/codex，系统里也有 codex.cmd，但是 OpenClaw 的 Codex 插件默认并不会直接使用你 PATH 里的 codex.cmd。

它可能仍然去找自己插件目录里的 managed binary。

一旦这个 managed binary 没生成、没下载、没缓存成功、路径解析失败，或者 OpenClaw 当前版本在 Windows 上没有正确找到它，就会一直报：

Managed Codex app-server binary was not found

所以继续重装 OpenClaw 很可能只是重复覆盖主程序，而没有解决 Codex app-server binary 的真实路径问题。

四、错误排查过程

1. 第一反应：更新 OpenClaw

最先尝试的是：

openclaw update
openclaw doctor --non-interactive --fix
openclaw gateway restart

这个方向是合理的，因为如果只是 OpenClaw 安装不完整，更新和 doctor 修复可能解决。

但如果重装、更新、doctor 都无效，就要换思路。

2. 第二步：检查旧配置是否覆盖

然后排查 openclaw.json 里是否有旧的 Codex 配置，尤其是：

"appServer": {
  "command": "..."
}

如果这里写错路径，OpenClaw 会按错误路径启动 Codex。

所以之前尝试过删除：

plugins.entries.codex.config.appServer

并清理环境变量：

[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", $null, "User")
[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_ARGS", $null, "User")
[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_MODE", $null, "User")

这个方向也没错，因为旧配置确实可能覆盖默认行为。

但你的场景里，这一步仍然没有解决。

这就说明问题不是“旧配置乱指”，而是 OpenClaw 默认 managed binary 本身找不到。

3. 第三步：确认 Codex CLI 是否独立可用

最终切入点是：

不要再让 OpenClaw 自己猜 Codex 在哪里，而是先确认系统里的 Codex CLI 是否能独立运行。

执行：

codex.cmd app-server --help

如果这条命令可以正常输出帮助信息，说明 @openai/codex 本身没坏。

也就是说：

Codex 能跑，OpenClaw 找不到它。

这个判断非常关键。

它把问题从“Codex 没装好”改成了“OpenClaw 没有找到正确的 Codex 启动文件”。

4. 第四步：找到 codex.cmd 的真实路径

执行：

(Get-Command codex.cmd).Source

一般会输出类似：

C:\Users\你的用户名\AppData\Roaming\npm\codex.cmd

这个路径才是 Windows 下 npm 全局安装生成的 Codex 命令入口。

只要 codex.cmd app-server --help 能跑，这个路径就可以作为 OpenClaw 的 Codex app-server 启动入口。

五、最终解决办法：显式指定 OPENCLAW_CODEX_APP_SERVER_BIN

最终解决命令是：

[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", (Get-Command codex.cmd).Source, "User")

这条命令的意思是：

把系统里的 codex.cmd 路径写入用户级环境变量：

OPENCLAW_CODEX_APP_SERVER_BIN

OpenClaw 启动 Codex app-server 时，不再只依赖 managed binary，而是直接使用这个明确指定的 Codex 可执行文件。

然后确认一下：

[Environment]::GetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", "User")

如果能看到类似：

C:\Users\你的用户名\AppData\Roaming\npm\codex.cmd

说明环境变量写入成功。

接着关闭当前 PowerShell，重新打开一个新的 PowerShell。

注意：这一步非常重要。
环境变量写入之后，旧 PowerShell 窗口不一定立刻生效。

然后重启 OpenClaw gateway：

openclaw gateway stop

openclaw gateway start

或者：

openclaw gateway restart

最后检查状态：

openclaw gateway status

六、完整修复命令汇总

1. 安装或重装 Codex CLI

npm install -g @openai/codex

2. 测试 Codex app-server 是否能独立运行

codex.cmd app-server --help

如果能输出帮助信息，说明 Codex 本身可用。

3. 查看 codex.cmd 路径

(Get-Command codex.cmd).Source

4. 写入 OpenClaw Codex app-server 路径

[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", (Get-Command codex.cmd).Source, "User")

5. 检查环境变量是否写入成功

[Environment]::GetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", "User")

6. 关闭 PowerShell，重新打开

这一步不要省略。

7. 重启 OpenClaw gateway

openclaw gateway stop

openclaw gateway start

或者：

openclaw gateway restart

8. 查看状态

openclaw gateway status

七、为什么这个办法有效？

因为这个错误的本质不是 OpenClaw 没装好，而是：

OpenClaw 的 Codex 插件默认要找 managed Codex app-server binary，但它没有找到。

而我们通过：

OPENCLAW_CODEX_APP_SERVER_BIN

直接告诉 OpenClaw：

不要猜了，就用这个 codex.cmd 来启动 app-server。

这相当于绕过了 OpenClaw 默认的 managed binary 查找逻辑，直接指定了一个已经验证可用的 Codex 启动入口。

这也是为什么前面重装 OpenClaw、清理配置、删除 appServer 配置都不一定有效，而最后这一步能解决。

八、这类问题的标准判断流程

以后再遇到类似报错，可以按这个顺序判断：

第一层：看错误关键词

如果看到：

Managed Codex app-server binary was not found

先判断为：

OpenClaw 找不到 Codex app-server binary。

不要先怀疑 prompt，也不要先怀疑模型。

第二层：确认 Codex 是否独立可用

执行：

codex.cmd app-server --help

如果这条命令失败，说明 Codex CLI 本身没装好。

如果这条命令成功，说明 Codex 没坏，是 OpenClaw 找不到它。

第三层：显式指定 Codex 路径

执行：

[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", (Get-Command codex.cmd).Source, "User")

然后重启 PowerShell 和 gateway。

第四层：检查 OpenClaw 配置

如果仍然失败，再检查：

openclaw.json

重点看有没有：

"appServer": {
  "command": "..."
}

如果有错误路径，删除或者修正。

九、经验总结

这次问题最大的坑在于：

错误提示里第一句就说：

Reinstall or update OpenClaw

所以人很容易陷入“反复重装”的循环。

但实际上，重装只能解决 OpenClaw 主程序或托管 binary 安装不完整的问题。

如果问题是 Windows 下 Codex binary 路径解析失败，或者 OpenClaw 没有使用 npm 全局安装的 codex.cmd，那么重装多少遍都可能没用。

真正有效的判断是：

codex.cmd app-server --help

只要这条命令能跑，就说明 Codex 在系统里是好的。

接下来要做的不是重装，而是把它的路径明确告诉 OpenClaw：

[Environment]::SetEnvironmentVariable("OPENCLAW_CODEX_APP_SERVER_BIN", (Get-Command codex.cmd).Source, "User")

最终一句话：

这个问题不是 Codex 不存在，而是 OpenClaw 没找到正确的 Codex app-server 启动入口。

解决方法也很简单：

先确认 codex.cmd 能跑，再用 OPENCLAW_CODEX_APP_SERVER_BIN 显式指定它。

华为甩出"韬定律",最先疼的为什么是 ASML,而不是台积电?

Mon, 25 May 2026 18:15:34 +0800

华为甩出"韬定律",最先疼的为什么是 ASML,而不是台积电?

2026年5月25日,上海。何庭波在 IEEE 国际电路与系统研讨会上,正式抛出了"韬(τ)定律"。

新闻标题写得很燃:中国第一次在半导体领域提出产业级指导原则,剑指1.4纳米,麒麟2026今秋首发。

但燃归燃,有一个问题被淹没在欢呼声里没人认真答:这套东西真正砸中的,到底是谁?

很多人下意识觉得是台积电——你看,华为绕开了先进制程,这不就是打台积电的脸吗?

恰恰相反。我把账算了一遍,结论是:短期里真正被这根刺扎到的是 ASML,而台积电反而和华为撞了同一个方向。

要把这话说清楚,得先花三分钟,把"韬定律"翻译成人话。

一、先别管 τ 长什么样,它就干了一件事:换了个考核指标

过去六十年,芯片行业进步只靠一招——把晶体管做小。

这就是摩尔定律的本质:同样的钱,晶体管数量每一两年翻一倍。能翻倍,是因为做小之后又快又便宜。

问题是,7纳米以后,这招不灵了。

物理上,晶体管小到一定程度,再小已经快不起来了,反而是晶体管之间那些"连线"的电阻电容拖了后腿。经济上,一颗最先进芯片光设计费就过10亿美元,做小一颗晶体管的成本不降反升。

华为的处境比别人更早撞墙,因为它根本买不到最先进的光刻机。逼到墙角,反而逼出一个更根本的问题:我们到底该缩小什么?

韬定律给的答案是:别盯着"把晶体管做多小"了,改盯"信号跑完一段路要花多少时间"。

这个时间,就是 τ。

听着玄,其实道理特别朴素:做小晶体管,无非也是为了让信号跑得更快、跑的路更短。既然最终图的是"快",那就直接把"快"当成考核指标,而不是把"小"当指标。

这一步换得很聪明。因为"做小"这条路被光刻机卡死了,但"让信号跑得快"还有别的办法。

最关键的办法,叫逻辑折叠(LogicFolding)。

一句话:**以前芯片是平房,所有电路摊在一个平面上,连线越拉越长;现在把它改成盖楼,把电路竖着叠成两层、未来更多层,楼上楼下用极细的"管线"连起来。**连线一下子短了一大截,信号跑得快了,同样的工艺、不用更先进的光刻,频率和密度都能往上提。

麒麟2026实测:晶体管密度从155一步跳到238(单位 MTr/mm²),频率重回3.1GHz,能效提升41%。这个密度跳幅,过去得靠三年的工艺微缩才能做到。

这就是全部故事的技术内核。听懂了这个,下面才好谈冲击。

二、ASML:营收没掉一分钱,但被扎中了最敏感的那根神经

先说结论:这事对 ASML 今年的财报,影响几乎是零;但对它赖以估值的那套"信仰",是一根扎进去拔不出来的刺。

ASML 是干嘛的?全世界唯一能造 EUV 光刻机的公司,7纳米以下没有任何替代品。一台普通 EUV 卖约1.8亿欧元,新一代 High-NA 一台3.8亿欧元起,客户还得排队抢。

它整个商业模式建立在一句话上:只要行业还想往更先进的制程走,就必须找我买更贵的机器。 2026年它的营收指引是340亿到390亿欧元,EUV 是绝对主力,在手订单几百亿,这是一台还在加速的印钞机。

那韬定律威胁到这台印钞机了吗?

直接威胁——没有。

第一,华为本来就买不到 ASML 最先进的机器,它的营收盘子里早就没算华为这块。事实上今年一季度,中国占 ASML 系统销售的比例已经从去年四季度的36%掉到约19%,而且掉的主要是利润较低的旧机型。华为这条路走不走,ASML 的现金流都照样滚。

第二,逻辑折叠靠的是"叠楼层",叠楼层要用的是键合、刻蚀、对准这些设备,反而不太吃最先进的光刻。所以从设备账面看,这甚至是把蛋糕从光刻挪向了别的环节。

那刺在哪?

刺在叙事上。

ASML 之所以能享受高估值(它的市销率是行业平均的两倍多),靠的不只是订单,而是一个深入人心的信念:想要更强的芯片,就只有华山一条路——买我的光刻机往更先进的制程走。

韬定律第一次由一家有量产规模的公司,系统性地、还带着381颗芯片数据,公开喊出另一句话:"先进性能,不必永远待在光刻的最前沿。封装、堆叠、互连,现在也能拿到过去只有先进制程才有的战略分量。"

这句话本身比麒麟那点密度数据,杀伤力大得多。

它不会让 ASML 今年少卖一台机器,但它在动摇一个长期共识:光刻 ≠ 进步的唯一入口。一旦这个共识开始松动,资本市场给 ASML 那份"独家通路"的估值溢价,逻辑上就该打个折。

所以 ASML 的疼,是慢性的、估值层面的疼,不是急性的、营收层面的疼。但对一家靠"信仰"撑起高估值的公司来说,信仰被人公开质疑,本身就是事件。

三、台积电:看着像被打脸,其实是撞了个满怀

这才是最反直觉的地方。

直觉上,华为"绕开先进制程"=打台积电的脸。错。

真相是:华为这次喊的方向,台积电早就在闷头干了,而且干得比谁都猛。

不信你看台积电2026年在干什么:

全年资本开支520亿到560亿美元,其中10%到20%专门砸在先进封装上,先进封装收入占比正从2025年的约8%往10%以上爬。
CoWoS 产能往130万片/月翻番扩张,SoIC(把芯片竖着叠成一个系统)被它自己定为"核心产能驱动力"。
它对2026年的官方定调是:"3D硅时代"——竖着叠和横着拼,和用什么光刻一样重要。 行业里那句话说得更直白:瓶颈已经从"算得快不快"变成"芯片之间说话快不快"。

把台积电这套话和华为的韬定律放一起读——System-as-One-Chip、把封装当系统、用垂直堆叠缩短连线、3D折叠——你会发现两家说的几乎是同一件事。

所以华为不是在反对台积电,是和台积电同时押注了同一条赛道。

那区别在哪?区别在驱动力,这点很要命:

台积电是"最先进制程 + 最先进封装",双轮驱动,从容选择;华为是"成熟制程 + 激进封装",单轮求生,被逼上路。

台积电是手里既有2纳米、又有 CoWoS,封装是它锦上添花的第二条增长腿;华为是先进制程这条腿被打断了,只能靠封装这条腿单脚跳。

这就决定了短期内华为撼不动台积电的护城河:

NVIDIA 一家就锁了台积电2026年六成以上的 CoWoS 产能,AMD 抢11%,生态被钉死;
台积电能做5.5倍光罩尺寸、良率98%的巨型封装,这是工程积累,不是一篇论文能追上的;
全球最赚钱的 AI 芯片,设计、制造、封装一条龙都在它这里。

但是,长期看,台积电该警惕的恰恰是它自己证明的那个趋势。

如果"系统和封装"的权重持续上升、"纯制程"的权重持续下降——而这正是台积电自己在反复强调的方向——那么台积电过去靠"我有全世界最先进制程"收取的那份超额溢价,就会被稀释。当成熟制程加上聪明的封装也能打到够用的性能时,愿意为最尖端那一两个纳米付天价的客户,会变少。

护城河不会消失,但护城河的形状会变:从"我有最小的晶体管",变成"我有最强的系统集成能力"。这对台积电不是灭顶之灾,却是一次需要主动转身的提醒。而华为,正是在帮全行业把这个转身的时刻往前提。

四、泼盆冷水:哪些是真功夫,哪些是话术

文章写到这,得把吹的和实的分开,不然就成了通稿。评论区有句话很扎眼——"等效1.4nm是虚的,新定律是营销的"。这话刻薄,但不全错。

把账摊开说:

第一,"等效1.4纳米"是密度等效,不是制程等效。 华为是用"叠楼层"把单位面积的晶体管数量堆到了1.4纳米工艺的水平,不等于它造出了1.4纳米的晶体管。这两件事差着十万八千里,前者靠封装,后者靠光刻。混着说,就容易让人以为制裁被破解了——并没有。

第二,韬定律更像是"给已有实践起了个名字"。 Chiplet、先进封装、超节点、系统级协同,这些东西业界做了好几年了,台积电、英特尔都在做。华为的贡献是把它们用"时间常数 τ"这根线串成了一套统一叙事,并第一个把它升格成"定律"。这里面有真的方法论价值,但升格成"定律"这个动作,本身就是一次话语权的抢夺,营销成分不必讳言。

第三,真正难的坑,华为自己也承认还没填上: 多层晶圆键合在一起,不同批次的工艺误差会被放大;EDA 设计工具还没有真正能处理三维堆叠的;良率、能耗都是硬骨头。论文里这些都老老实实写了——这是它专业的一面,也说明这是张十年的路线图,不是已经兑现的战报。

第四,也是最该承认的:这是被制裁逼出来的换赛道,不是从容的战略选择。 但被逼出来的路,不一定是坏路。当年正是因为做小晶体管这条路对华为关死了,它才被迫去想"除了做小,还能缩小什么"。约束有时候反而能逼出真正的原创。

五、那这事到底重要在哪

剥掉营销,剥掉民族情绪,这件事最硬的内核只有一个词:定义权。

过去六十年,芯片行业的游戏规则是别人定的——摩尔定律、登纳德缩放,优化什么、朝哪缩,标准在西方手里,ASML 和台积电是这套规则下最大的两个受益者:一个垄断了通往规则前沿的唯一入口,一个垄断了在规则前沿的最佳制造。

韬定律真正的动作,不是技术上掀桌子,而是第一次有一家中国公司站出来说:这个游戏,也可以按另一套指标来打,而且我有381颗芯片证明它能打。

所以,给三方各留一句话:

对 ASML: 你今年的钱一分不少,但有人开始公开质疑"你是唯一的路"了。慢性的、估值层面的隐忧,从今天开始计时。
对台积电: 别紧张,他和你押的是同一个方向;但也别松懈,他在帮全行业把"制程不再是唯一"这件事提前坐实,而你过去最值钱的恰恰是制程领先。
对华为自己: 把"密度等效"老老实实说成密度等效,把十年路线图老老实实当十年走。这套东西真正的价值,不在今秋那颗麒麟,而在它有没有本事,真的把一套中国人定义的标准,变成全行业愿意跟的标准。

几何时代的句号还没真正画上,但有人已经开始在旁边,另起了一行。

数据来源:华为官网(huawei.com)韬定律发布稿、ISCAS 2026 演讲及 ChinaXiv 预印本;ASML 2026 Q1 财报及全年指引;台积电 2026 资本开支与先进封装路线图(TSMC Tech Symposium 2026、TrendForce、SemiEngineering 等公开报道)。本文为独立分析,技术数据以华为官方口径为准。

OpenClaw browser --browser-profile 深度解析：这不是“打开浏览器”，而是给 AI 配一套可控的网页操作工作台

Sun, 24 May 2026 18:02:59 +0800

OpenClaw `browser --browser-profile` 深度解析：这不是“打开浏览器”，而是给 AI 配一套可控的网页操作工作台

一、先给结论

openclaw browser --browser-profile 解决的不是“能不能打开网页”的问题，而是解决：

AI 用哪个浏览器身份、哪个登录环境、哪个隔离空间、哪个远程浏览器、哪个任务现场去干活。

一句话说清楚：

--browser-profile 就是给 OpenClaw 的浏览器工具指定一个“浏览器工作身份”。

这个身份可以是：

profile	含义	适合场景
`openclaw`	OpenClaw 自己管理的独立浏览器环境	最推荐，安全、隔离、不污染个人浏览器
`user`	接管你当前真实 Chrome 登录环境	需要用你已登录账号时，比如 X、Google Docs、后台系统
自定义 profile，如 `work`	单独创建一个工作浏览器环境	多任务、多账号、多客户隔离
`remote`	连接远程 CDP 浏览器	服务器、容器、远程浏览器自动化

官方文档里说得很明确：OpenClaw 可以运行一个专门的 Chrome / Brave / Edge / Chromium profile，由 agent 控制，并且这个 profile 与个人浏览器隔离；默认的 openclaw profile 不会碰你的个人浏览器。(OpenClaw)

所以，这个功能的价值非常大。

它让 OpenClaw 从“会聊天的龙虾”，变成“能看网页、点网页、填表、截图、导出 PDF、验证结果的业务执行助手”。

二、`openclaw browser` 本质上是什么？

1. 它是 OpenClaw 给 AI 准备的“浏览器控制面”

官方 CLI 文档对 openclaw browser 的定义是：管理 OpenClaw 的浏览器控制面，并执行浏览器动作，包括生命周期、profiles、tabs、快照、截图、导航、输入、状态模拟和调试等。(OpenClaw)

通俗说，它不是普通浏览器命令，而是一套让 AI 可以操作浏览器的控制系统。

它能做这些事情：

能力	作用
start	启动浏览器
stop	停止浏览器
status	查看状态
doctor	检查浏览器控制是否正常
open	打开网页
tabs	查看标签页
snapshot	读取页面结构
screenshot	截图
pdf	导出页面 PDF
click/type/select/drag	模拟点击、输入、选择、拖拽

官方文档里也列出 OpenClaw browser 能提供确定性的 tab 控制、agent 点击/输入/拖拽/选择、页面快照、截图和 PDF 等能力。(OpenClaw)

2. 它解决的是 AI 的“眼睛”和“手”的问题

普通聊天模型只能靠你发文字。

但 OpenClaw browser 让 agent 可以：

自己打开网页；
自己看页面；
自己点按钮；
自己填输入框；
自己切 tab；
自己截图；
自己导出 PDF；
自己验证网页变化。

这就相当于给 AI 装上了：

眼睛：看网页内容。
手：操作网页界面。
记忆现场：保留登录状态、cookie、tab、历史访问环境。

这也是 OpenClaw 和普通对话机器人的关键分界线。

三、`--browser-profile` 到底是什么？

1. 它不是“浏览器标签页”，而是“浏览器身份”

很多人会误解：

我新开一个 tab，是不是就是新 profile？

不是。

tab 只是同一个浏览器环境里的一个页面。

profile 是更大的概念，它包括：

cookie；
登录状态；
本地缓存；
浏览器数据目录；
页面权限；
自动化连接方式；
CDP 控制端口；
是否 headless；
是否接管已有浏览器；
是否连接远程浏览器。

官方 CLI 文档把 profiles 定义为“named browser routing configs”，也就是命名的浏览器路由配置。实际使用中，openclaw 会启动或连接到 OpenClaw 管理的独立 Chrome 实例；user 会通过 Chrome DevTools MCP 控制用户已有的登录 Chrome；自定义 CDP profile 可以指向本地或远程 CDP endpoint。(OpenClaw)

所以：

openclaw browser --browser-profile openclaw open https://example.com

意思不是“随便打开一个网页”。

它的完整含义是：

让 OpenClaw 使用名为 openclaw 的浏览器工作环境，打开这个网页。

2. `--browser-profile` 的价值是“明确指定任务现场”

比如你有三个任务：

任务 A：用学生咨询系统后台整理记录
任务 B：用企业微信后台查客户消息
任务 C：用 Google 搜索资料做行业研究

如果都混在一个浏览器里，很容易出问题：

登录状态串了；
tab 太多乱了；
AI 点错页面；
一个任务关闭了另一个任务的页面；
用错账号；
把客户 A 的后台当成客户 B；
自动化过程中误操作你的个人浏览器。

--browser-profile 就是为了解决这些问题。

你可以这样分：

openclaw browser --browser-profile openclaw open https://google.com
openclaw browser --browser-profile work open https://company-backend.example.com
openclaw browser --browser-profile student open https://student-system.example.com

每个 profile 是一个相对独立的浏览器工作区。

四、默认 profile：`openclaw`

1. `openclaw` 是最推荐的新手默认方案

官方文档说，openclaw profile 是一个独立的、agent-only 的浏览器；它不触碰你的个人浏览器 profile，agent 可以在这个安全通道里打开 tab、读取页面、点击和输入。(OpenClaw)

也就是说，默认最稳的用法就是：

openclaw browser --browser-profile openclaw doctor
openclaw browser --browser-profile openclaw status
openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw open https://example.com
openclaw browser --browser-profile openclaw snapshot

这个 profile 适合：

公开网页研究；
行业资料搜集；
竞品页面分析；
自动截图；
网页转 PDF；
测试网页功能；
不需要你个人账号登录的任务；
给 agent 一个干净环境干活。

2. 它的核心好处：不污染你的个人浏览器

你个人 Chrome 里可能有：

微信网页版；
Gmail；
飞书；
企业后台；
支付宝；
ChatGPT；
各种客户系统；
各种自动登录 cookie。

如果让 AI 直接在你的个人浏览器里乱点，风险很高。

所以 openclaw profile 的意义是：

先给 AI 一个隔离浏览器，让它在可控空间里工作。

这就是“安全车道”。

官方文档也特别提醒：这个 browser 不是你的日常主浏览器，而是 agent automation 和 verification 的安全、隔离表面。(OpenClaw)

五、特殊 profile：`user`

1. `user` 是用来接管你真实 Chrome 登录环境的

user profile 的含义是：

让 OpenClaw 连接你当前真实登录的 Chrome 会话。

官方文档说明，内置的 user profile 会通过 Chrome MCP 附加到你的真实已登录 Chrome session。(OpenClaw)

它适合这种情况：

网站必须登录；
登录过程复杂；
验证码很多；
自动登录容易被风控；
你已经在 Chrome 里登录好了；
agent 只是需要帮你读页面、点按钮、整理内容。

比如：

openclaw browser --browser-profile user tabs

或者：

openclaw browser --browser-profile user open https://docs.google.com

2. 什么时候用 `user`？

典型场景：

场景	为什么要用 `user`
Google Docs	你已经登录 Google 账号
X / Twitter	自动登录容易触发风控
企业后台	需要真实账号权限
飞书管理后台	需要企业登录状态
微信公众平台	扫码登录，不适合给模型账号密码
支付类后台	必须人工确认
客户系统	登录流程复杂，cookie 已在本机

官方登录文档也建议：当网站需要登录时，应该在 host browser profile 里手动登录，不要把凭据交给模型；自动化登录容易触发反机器人机制甚至锁号。(OpenClaw)

这句话非常重要。

AI 可以帮你操作页面，但账号密码、验证码、二次验证，最好还是你自己处理。

六、为什么不建议一上来就用 `user`？

因为 user 虽然方便，但风险也更高。

1. 它接的是你的真实浏览器

你的真实浏览器里面有大量敏感环境：

已登录后台；
邮箱；
私人账号；
企业账号；
客户资料；
财务系统；
表单提交权限；
删除权限；
发布权限。

如果 agent prompt 被网页里的恶意内容影响，或者你给了过宽权限，就可能出现误操作。

所以我的建议是：

能用 openclaw，先用 openclaw；必须用登录态，再用 user。

2. `user` 也有功能限制

官方故障排查文档提到，user / existing-session profiles 保留当前 Chrome MCP 的限制，例如 ref-driven actions、单文件上传 hooks、没有 dialog timeout overrides、没有 wait --load networkidle、没有 responsebody、PDF export、download interception 或 batch actions。(OpenClaw)

通俗说：

user 适合接管真实登录状态，但不是所有自动化能力都像 managed browser 那么完整。

所以，如果你只是做网页分析、截图、转 PDF、公开资料抓取，openclaw 更合适。

如果你必须依赖真实登录状态，再用 user。

七、自定义 profile：`work`、`student`、`client-a`

1. 自定义 profile 解决“多任务隔离”

你可以创建多个 profile。

官方 CLI 文档给了类似命令：

openclaw browser profiles
openclaw browser create-profile --name work --color "#FF5A36"
openclaw browser create-profile --name chrome-live --driver existing-session
openclaw browser create-profile --name remote --cdp-url https://browser-host.example.com
openclaw browser delete-profile --name work

文档也说明，可以通过 --browser-profile work 使用指定 profile。(OpenClaw)

这就非常适合你这种场景。

比如你要同时跑：

学生咨询系统；
微信公众号素材采集；
行业报告资料搜集；
客户后台经营数据查看；
AI 课程后台管理。

你可以这样设计：

openclaw browser create-profile --name student
openclaw browser create-profile --name report
openclaw browser create-profile --name client-a
openclaw browser create-profile --name client-b

使用时：

openclaw browser --browser-profile student open https://student-system.example.com
openclaw browser --browser-profile report open https://www.google.com
openclaw browser --browser-profile client-a open https://backend-a.example.com
openclaw browser --browser-profile client-b open https://backend-b.example.com

这样就不会乱。

2. 自定义 profile 的管理价值

对你这种经常做企业 AI 落地、课程演示、客户咨询的人来说，自定义 profile 的价值不只是技术隔离，而是业务管理。

可以按这些方式命名：

命名方式	示例	适合场景
按客户	`client-jurui`、`client-zhongqiyunlian`	客户后台、资料、系统隔离
按任务	`report`、`wechat-crawl`、`ppt-data`	不同任务互不干扰
按角色	`teacher`、`student`、`admin`	多角色系统测试
按账号	`x-main`、`x-alt`	社媒多账号
按环境	`dev`、`test`、`prod`	系统测试/后台验证

这就像你给 AI 配了多个“办公桌”。

每张桌子上只放这一类任务需要的资料、登录状态和页面。

八、远程 CDP profile：把浏览器放到服务器或容器里

1. 什么是 CDP？

CDP 是 Chrome DevTools Protocol，简单理解就是：

Chrome 提供的一套远程控制接口。

OpenClaw 可以通过 CDP 控制本地或远程浏览器。

官方文档里说，自定义 CDP profile 可以指向本地或远程 CDP endpoint；远程 CDP profiles 支持 http://、https://、ws://、wss://。 (OpenClaw)

比如：

openclaw browser create-profile --name remote --cdp-url https://browser-host.example.com
openclaw browser --browser-profile remote open https://example.com

2. 远程 profile 适合什么场景？

适合这些情况：

场景	价值
Linux 服务器没图形界面	用 headless browser 跑
WSL 控制 Windows 浏览器困难	改为远程 CDP
多任务长期运行	不占本机浏览器
企业统一部署	每个 agent 连指定远程 browser
自动化采集	放服务器上跑，不影响本机
演示环境	提前准备一个干净远程浏览器

尤其是你之前折腾过 Windows、WSL、微信、GUI 自动化，这个思路很重要：

凡是本机 GUI 控制不稳定的地方，可以考虑把浏览器自动化搬到可控的 CDP 环境。

九、它到底解决了哪些痛点？

痛点一：AI 操作网页容易污染个人浏览器

没有 profile 时，AI 可能直接操作你的真实浏览器。

这很危险。

有了 openclaw profile，AI 默认在独立环境里操作，不碰你的私人浏览器。官方文档也强调，openclaw 是隔离的 agent-only browser，不是日常主浏览器。(OpenClaw)

解决结果：

AI 有地方干活，但不会乱动你的私人账号。

痛点二：多个任务抢同一个浏览器现场

比如一个任务在查资料，一个任务在登录后台，一个任务在测试表单。

如果都在同一个浏览器 profile 里，会出现：

tab 混乱；
页面焦点抢来抢去；
AI 点错 tab；
登录态串台；
下载文件混在一起；
截图截错页面。

用不同 profile，可以把任务现场分开。

解决结果：

一个任务一个浏览器工作区，互不干扰。

痛点三：登录网站不能把账号密码交给模型

很多后台必须登录，但你不能把密码给模型。

官方登录文档也明确建议，登录应由用户在 host browser profile 里手动完成，不要把凭据交给模型，因为自动登录容易触发反机器人机制并锁定账号。(OpenClaw)

解决结果：

人负责登录和授权，AI 负责登录后的页面操作。

这就是合理分工。

痛点四：AI 只会“搜索”，不会“验证页面结果”

传统 web_search 只能拿搜索结果。

但真实业务里很多信息在网页交互后才出现：

点开菜单；
登录后台；
切换筛选条件；
翻页；
下载表格；
截图留证；
导出 PDF；
填写表单后验证提交结果。

官方工具总览里也把 browser 归为“Operate a browser session”，也就是当 agent 需要操作浏览器会话时使用。(OpenClaw)

解决结果：

OpenClaw 不只是查网页，而是能像人一样操作网页流程。

痛点五：演示和交付需要可复现现场

你做课程、直播、企业内训的时候，最怕演示翻车：

浏览器历史记录太乱；
账号没登录；
tab 太多；
页面缓存异常；
弹窗干扰；
AI 操作错页面。

如果提前准备一个 demo profile：

openclaw browser create-profile --name demo
openclaw browser --browser-profile demo open https://your-demo-page.example.com

你就可以把演示环境固定下来。

解决结果：

每次演示都从同一个干净现场开始，稳定性高很多。

十、哪些场景最适合用 `--browser-profile`？

场景一：行业研究和报告资料搜集

比如你让 OpenClaw 帮你研究：

新能源汽车后市场；
女士内衣 OEM/ODM；
假发行业；
稀土磁材；
AI 智能体工具。

可以用：

openclaw browser --browser-profile report open https://www.google.com

让它做：

搜索关键词；
打开报告页面；
截图；
保存 PDF；
记录来源；
对比不同网页信息；
把网页证据转成报告素材。

这类任务建议用 openclaw 或 report，不建议用 user。

场景二：企业后台操作

比如：

飞书管理后台；
微信公众平台；
CRM；
项目管理系统；
教务系统；
数据看板；
客户系统。

这类网站通常需要登录。

建议：

先用 user 或专门 profile 手动登录；
再让 agent 操作页面；
高风险按钮必须人工确认。

示例：

openclaw browser --browser-profile user tabs
openclaw browser --browser-profile user open https://example-admin.com

但要注意，user 适合真实登录态，但也意味着权限更大，要设置好 agent 行为边界。

场景三：网页自动化测试

你有 Laravel / Yii / 小程序后台 / AI dashboard 之类项目时，可以让 OpenClaw 帮你做：

打开本地页面；
输入表单；
点击提交；
检查提示；
截图；
回归测试；
生成 bug 记录。

示例：

openclaw browser --browser-profile test open http://localhost:3000
openclaw browser --browser-profile test snapshot

这类任务建议用独立 test profile，避免干扰其他工作。

场景四：多账号运营

比如你有：

一个主公众号；
一个课程号；
一个测试号；
一个客户号。

不要混在一个浏览器里。

可以这样：

openclaw browser create-profile --name wechat-main
openclaw browser create-profile --name wechat-course
openclaw browser create-profile --name wechat-client-a

每个 profile 登录不同账号。

这样 agent 执行任务时不会串号。

场景五：课程演示 / 直播演示

比如你要演示：

“AI 如何自动打开网页、查资料、截图、整理为报告。”

可以专门建：

openclaw browser create-profile --name demo
openclaw browser --browser-profile demo start

演示前准备好：

干净浏览器；
必要登录态；
固定书签；
固定页面；
无关 tab 清空。

这样直播时不容易翻车。

场景六：远程服务器自动化

如果你希望某些任务长期跑：

定时打开网页检查更新；
生成网页截图；
保存页面 PDF；
检查后台状态；
监控某个页面变化。

可以创建远程 CDP profile：

openclaw browser create-profile --name remote --cdp-url https://browser-host.example.com
openclaw browser --browser-profile remote open https://example.com

这类适合更工程化的 OpenClaw 自动化。

十一、常用命令清单

1. 查看已有 profiles

openclaw browser profiles

2. 启动默认独立浏览器

openclaw browser --browser-profile openclaw start

3. 查看状态

openclaw browser --browser-profile openclaw status

4. 做基础检查

openclaw browser --browser-profile openclaw doctor

更深检查：

openclaw browser --browser-profile openclaw doctor --deep

官方文档说明，doctor --deep 会增加 live snapshot probe，适合在基础 CDP readiness 正常后证明当前 tab 可以被检查。(OpenClaw)

5. 打开网页

openclaw browser --browser-profile openclaw open https://example.com

6. 查看 tabs

openclaw browser --browser-profile openclaw tabs

7. 读取页面快照

openclaw browser --browser-profile openclaw snapshot

8. 新建工作 profile

openclaw browser create-profile --name work --color "#FF5A36"

9. 使用工作 profile

openclaw browser --browser-profile work open https://example.com

10. 创建已有 Chrome 会话 profile

openclaw browser create-profile --name chrome-live --driver existing-session

11. 创建远程 CDP profile

openclaw browser create-profile --name remote --cdp-url https://browser-host.example.com

12. 删除 profile

openclaw browser delete-profile --name work

官方文档也说明，profile 删除时，本地数据目录会被移动到垃圾桶；本地 openclaw profiles 会自动分配 CDP 端口 / URL，通常只有远程 CDP 才需要手动设置。(OpenClaw)

十二、配置层面要注意什么？

1. 如果 `openclaw browser` 命令不存在

可能是 browser 插件没有启用。

官方文档说明，如果 openclaw browser 是 unknown command，要检查 ~/.openclaw/openclaw.json 里的 plugins.allow；当使用限制性插件 allowlist 时，需要显式加入 browser，除非已经有 root browser 配置块。(OpenClaw)

可以加：

{
  "plugins": {
    "allow": ["telegram", "browser"]
  }
}

如果你不是 Telegram，而是飞书、微信，就把对应 channel 换成自己的。

比如：

{
  "plugins": {
    "allow": ["browser", "feishu", "openclaw-weixin"]
  }
}

2. 如果 agent 看不到 browser 工具

官方文档提醒：tools.profile: "coding" 包含 web_search 和 web_fetch，但不包含完整 browser tool；如果 agent 或 sub-agent 要用 browser automation，需要在工具策略里显式加 browser。(OpenClaw)

示例：

{
  "tools": {
    "profile": "coding",
    "alsoAllow": ["browser"]
  }
}

单个 agent 可以这样：

{
  "agents": {
    "list": [
      {
        "id": "main",
        "tools": {
          "alsoAllow": ["browser"]
        }
      }
    ]
  }
}

这点很关键。

很多人以为模型不行，其实是工具没给它。

十三、容易踩的坑

坑一：以为新 tab 就是新 session

不是。

新 tab 只是页面分开。

真正隔离至少有三层：

隔离层	解决什么
新 tab	页面分开
新 browser profile	登录状态、cookie、缓存、任务现场分开
新 OpenClaw session	对话上下文、任务记忆分开

所以你要另跑一个任务，最稳的是：

新 OpenClaw session + 新 browser profile。

坑二：用 `user` 但 Chrome 没开 tab

官方故障排查文档说，如果出现 No Chrome tabs found for profile="user"，说明你在使用 existing-session / Chrome MCP profile，OpenClaw 能看到本地 Chrome，但没有可附加的 open tab。修复方式是用 managed browser，或者确保本地 Chrome 至少有一个打开的 tab，再用 --browser-profile user。(OpenClaw)

命令：

openclaw browser --browser-profile openclaw start

或者先手动打开 Chrome 一个标签页，再：

openclaw browser --browser-profile user tabs

坑三：服务器环境没有图形界面

官方 CLI 文档提到，在没有 DISPLAY 或 WAYLAND_DISPLAY 的 Linux host 上，本地 managed profiles 会自动 headless 运行，除非显式关闭 headless。(OpenClaw)

所以 Linux 服务器上看不到浏览器窗口，不一定是错误。

它可能是在 headless 模式运行。

坑四：browser 插件没启用

命令不存在、agent 说 browser unavailable，多半是插件、工具策略或配置 allowlist 问题。

先查：

openclaw browser --help

再查配置：

cat ~/.openclaw/openclaw.json

重点看：

{
  "plugins": {
    "allow": ["browser"]
  }
}

以及：

{
  "tools": {
    "alsoAllow": ["browser"]
  }
}

十四、给你的最佳实践：按任务类型设计 profile

1. 日常研究

openclaw browser create-profile --name research
openclaw browser --browser-profile research open https://www.google.com

适合：

行业研究；
资料搜集；
报告截图；
页面 PDF 留证。

2. 客户项目

openclaw browser create-profile --name client-jurui
openclaw browser create-profile --name client-zhongqi

适合：

不同客户系统隔离；
不同资料来源隔离；
不同登录态隔离。

3. 课程演示

openclaw browser create-profile --name demo

适合：

直播；
线下课；
企业内训；
AI 工作流演示。

4. 后台系统测试

openclaw browser create-profile --name test
openclaw browser --browser-profile test open http://localhost:3000

适合：

本地开发；
表单测试；
页面截图；
bug 复现。

5. 真实登录账号

openclaw browser --browser-profile user tabs

适合：

你已经登录的 Chrome；
需要人工扫码/二次验证；
不能把账号密码交给模型的系统。

但记住：

真实账号场景，要让 AI 少做高风险动作。发布、删除、付款、提交审批、修改权限，一律人工确认。

十五、最推荐的工作流

第一步：先用独立 profile

openclaw browser --browser-profile openclaw doctor
openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw open https://example.com

第二步：需要分任务时，新建 profile

openclaw browser create-profile --name report
openclaw browser create-profile --name demo
openclaw browser create-profile --name client-a

第三步：需要登录态时，人工登录

openclaw browser --browser-profile client-a open https://client-backend.example.com

你手动登录。

然后再让 OpenClaw 操作。

第四步：需要真实 Chrome 登录态时，再用 `user`

openclaw browser --browser-profile user tabs

第五步：任务结束后清理

openclaw browser --browser-profile report stop

不再需要的 profile：

openclaw browser delete-profile --name old-task

十六、它和 session 的关系

这个地方最容易混。

browser profile 管浏览器环境

它管的是：

tab；
cookie；
登录态；
浏览器缓存；
浏览器数据目录；
CDP 连接；
是否接管真实 Chrome；
是否远程控制浏览器。

OpenClaw session 管对话上下文

它管的是：

你前面说过什么；
agent 记住了什么；
当前任务目标；
任务上下文；
历史消息。

所以：

新 browser profile ≠ 新 OpenClaw session
新 OpenClaw session ≠ 新 browser profile

真正不冲突的做法：

一个新任务 = 一个新 OpenClaw session + 一个明确 browser profile

比如：

session: 学生咨询建议任务
browser profile: student

session: 行业报告资料搜集任务
browser profile: report

session: 课程演示任务
browser profile: demo

这样才稳。

十七、一句话讲透

openclaw browser --browser-profile 的本质，是把浏览器从“你的私人操作界面”，变成“AI 可控、可隔离、可复现、可分工的任务现场”。

它解决的核心痛点是：

AI 要操作网页，但不能乱动你的私人浏览器；AI 要使用登录态，但不能拿你的密码；AI 要同时跑多个任务，但不能互相串台；AI 要做真实业务，但必须有可控的浏览器工作区。

所以，对你这种重度使用 OpenClaw、Codex、Claude Code、opencode、deepseek-tui、Hermes 的人来说，--browser-profile 不是一个小参数。

它是 OpenClaw 从“聊天助理”走向“业务执行智能体”的关键开关。

最实用的一句话：

公开网页用 openclaw，多任务用自定义 profile，必须真实登录才用 user，长期自动化用 remote CDP。

我让小龙虾帮我写一个 mac 应用，实时翻译屏幕上我选中的英文

Sun, 24 May 2026 17:51:29 +0800

我问：

我现在要做一个在我本机运行的捕捉屏幕上英文并连接大模型的应用，这个提供配置入口即可，让我能够实时看到：“简单英语”（通常指基本英语 (Basic English)）的发明人是英国语言学家和哲学家查尔斯·凯·奥格登 (Charles Kay Ogden)

这种英语的翻译，让我秒懂。并且能够自动写入到 obsidian 中间去。如果同样的单词或者句子多次选中，那就在 obsidian 里记录下选中的时间，并显示选中次数，以此来反应我学习的进度。

你现规划下怎么做。

小龙虾答：

规划：ScreenEn → 秒懂英文 + Obsidian 学习追踪

核心流程

选中英文 → 快捷键触发 → 剪贴板捕获 → LLM 翻译 → 浮窗秒懂展示 → 自动写入 Obsidian

五个模块

1. 文本捕获（Capture）

全局快捷键触发（默认 Cmd+Shift+T，可配置）
触发后模拟 Cmd+C，读取剪贴板内容
备选方案：macOS Accessibility API 直接读取选中文字（更优雅但跨应用兼容性差，先用剪贴板方案）

2. LLM 翻译（Translate）

可配置项：API Endpoint、API Key、Model Name、自定义 Prompt
默认 Prompt 方向：不是逐字翻译，而是用最直觉的中文让用户秒懂
短词→给释义+一句话场景理解
长句→给中文意译+关键结构拆解

3. 浮窗展示（Overlay）

macOS 原生浮动窗口，置顶显示在屏幕右下角或光标附近
翻译结果停留 5-8 秒自动消失（可配置），鼠标悬停可保持
之前的结果可通过 menubar 图标历史记录回看

4. Obsidian 写入（Vault Writer）

每个单词/短语/句子对应 vault 里一个 markdown 文件
文件名：英文原文的 slug 形式（如 ubiquitous.md）
首次：创建文件，写入释义、简单理解、选中时间
重复选中：追加时间戳，更新计数，不覆盖已有内容

Obsidian 文件结构示例：

vault/ScreenEn/
  ubiquitous.md
  it-is-what-it-is.md
  _dashboard.md        ← 学习进度总览

单个文件内容：

---
text: "ubiquitous"
type: word
count: 5
first_seen: 2026-05-24T10:30:00+08:00
last_seen: 2026-05-24T17:45:00+08:00
---# ubiquitous## 秒懂到处都有，无处不在## 场景理解形容某个东西太常见了，到处都能碰到## 学习记录- 2026-05-24 10:30 — 第1次- 2026-05-24 11:15 — 第2次- 2026-05-24 17:45 — 第5次

5. 配置界面（Config UI）

macOS menubar 常驻图标，点击弹出配置面板
配置项：

LLM API Endpoint / Key / Model
翻译 Prompt 模板
Obsidian Vault 路径
快捷键
浮窗显示时长
最小捕获长度（避免误触发）

技术选型

层	选择	理由
语言	Python 3	你 Mac 上直接跑，配置灵活，LLM 调用方便
Menubar + 浮窗	rumps + PyObjC	原生 macOS menubar 应用，浮窗用 NSWindow
全局快捷键	pynput 或 PyObjC CGEvent	跨应用全局监听
LLM 调用	httpx	支持流式，OpenAI 兼容接口
Obsidian 写入	标准文件 I/O	Obsidian 就读 markdown，直接写文件
配置存储	YAML 文件	人工可读可改

目录结构

screenen/
  app.py              ← 入口，menubar 应用
  capture.py          ← 快捷键监听 + 剪贴板读取
  translator.py       ← LLM 调用 + Prompt 管理
  overlay.py          ← 浮窗展示
  vault.py            ← Obsidian 文件读写 + 计数追踪
  config.py           ← 配置加载/保存
  config.yaml         ← 默认配置
  requirements.txt

启动方式

python screenen/app.py# menubar 出现图标，后台监听快捷键，随时可用

需要你确认的点：

Obsidian vault 路径 — 你 vault 在哪个目录？
LLM — 你想接哪个？OpenAI 兼容接口？还是本地模型？
浮窗位置 — 右下角固定，还是跟光标走？
要不要 dashboard — Obsidian 里放一个 _dashboard.md 汇总高频词、学习趋势？

openclaw 我能启动一个新浏览器 tab 标签，新开一个 session 跑另一个任务吗？不跟前一个冲突。

Sun, 24 May 2026 17:39:19 +0800

可以，但要分清两件事：

结论

可以新开一个浏览器 tab 跑另一个任务，但“新 tab ≠ 一定是新 session”。

OpenClaw 的 session 不是按你肉眼看到的浏览器标签页来算，而是按 sessionKey / 来源 / 通道 / 发送者 / room / webhook / cron 等路由规则来分配。官方文档说，OpenClaw 会把会话组织成 sessions，每条消息会根据来源路由到对应 session；DM 默认还可能共享同一个 session。(OpenClaw)

所以你想“不跟前一个任务冲突”，关键不是只开新 tab，而是要让它进入新的 session / 独立 session / 不同 agent / 不同浏览器 profile。

最稳的使用建议

你可以这样理解：

目标	只开新 tab 够不够	更稳做法
只是看 OpenClaw 控制台	够	新开 Control UI tab
跑另一个聊天任务	不一定够	新建 session
不想上下文串台	不够	isolated / named session
浏览器自动化不想互相抢 tab	不够	不同 browser profile
两个任务同时跑	看资源	新 session + 不同 profile + 必要时不同 agent

我的建议一句话：

可以开新 tab，但别指望 tab 自动隔离。真正防冲突，要新建 session；涉及浏览器自动化，再配不同 browser profile。

为什么龙虾🦞和 Codex 做出的咨询建议差距这么大？

Sun, 24 May 2026 14:30:25 +0800

为什么龙虾🦞和 Codex 做出的咨询建议差距这么大？

一、先给结论：不是“模型在线”就等于“能力在线”

很多人容易把 AI 效果理解成一个公式：

模型越强，结果越好。

但实际使用下来会发现，这个公式只对了一半。更完整的公式应该是：

最终效果 = 模型能力 × 上下文质量 × 任务框架 × 工具链 × 记忆机制 × 输出校验机制 × 使用者的调教方式

所以，你昨天已经把 OpenClaw 升级到 5.20，今天也确认它在线使用 GPT-5.5，这只能说明一件事：

发动机不差。

但一辆车跑不快，不一定是发动机问题，也可能是变速箱、路况、导航、驾驶策略、轮胎抓地力、载重方式出了问题。

Codex 和 OpenClaw 的差异，恰恰就在这里。

Codex 更像一个被 OpenAI 深度调教过的“任务型专家工作台”。它不只是调用模型，而是围绕任务执行、上下文读取、环境配置、指令继承、工作流推进做了专门设计。官方文档里也明确提到，Codex 可以读取、修改、运行代码；Codex Cloud 还能在云环境中执行任务，并通过环境配置控制依赖、工具和运行条件。(OpenAI开发者)

而 OpenClaw 更像一个“开放式智能体操作系统”。它的强项是接通渠道、配置模型、挂载工具、安装 skills、连接消息通道、自动化操作。OpenClaw 官方配置文档也说明，它的配置重点包括渠道连接、模型、工具、沙箱、自动化、会话、媒体、网络和 UI 等。(OpenClaw)

这意味着：

Codex 默认就带着一套任务执行范式；OpenClaw 则需要你自己把范式配置出来。

这就是两者效果差距的根源。

二、升级 OpenClaw 5.20，主要解决的是“系统稳定性”，不是“咨询能力”

你这次升级到 5.20，本身当然有价值。但要看清楚：版本升级解决的通常是平台层、网关层、性能层、工具调用层的问题，不会自动把一个通用智能体变成顶级咨询顾问。

从公开的 OpenClaw 5.20 相关更新看，重点更多集中在 gateway/perf、插件元数据读取、channel catalog、内存/会话同步、消息 handoff 等工程稳定性问题上。(GitHub)

这类升级很重要，但它更像是：

车架更稳了；
通信链路更顺了；
插件读取更快了；
多通道转发更不容易丢消息了；
网关运行更省资源了。

但它不会自动带来：

更懂学生咨询；
更会提炼心理状态；
更会拆解成长路径；
更会输出 Codex 那种结构化建议；
更会模拟资深咨询师的判断链；
更会把输入资料转化成“诊断—策略—行动—话术”。

所以你会有一种落差感：

“我明明升级了，模型也在线，为什么效果还是不如 Codex？”

原因就在于：你升级的是“操作系统”，但还没有把“咨询专家的大脑结构”装进去。

三、Codex 强的不是单次回答，而是“任务工作台”的默认心智

Codex 的强大，不只是因为模型强，而是因为它天然按照“完成任务”的方式工作。

它会更习惯于：

先读上下文；
判断任务目标；
建立执行计划；
拆分问题；
找到关键约束；
生成方案；
自我检查；
输出更像交付物的结果。

这套机制，在代码任务里表现为读项目、看文件、改代码、跑测试、生成 diff。但迁移到咨询建议里，就会表现为：

读学生记录 → 理解学生卡点 → 识别情绪和认知结构 → 给出分层建议 → 形成可执行陪跑方案。

OpenAI 官方也把 Codex 定位为面向软件开发的 agent，支持在 CLI、本地、云端等场景中工作；Codex 还支持 AGENTS.md 这种项目级指令文件，能够在开始任务前读取一致的上下文和规则。(OpenAI开发者)

这很关键。

因为一个 AI 的表现，不只取决于“它是什么模型”，还取决于它进入任务时，脑子里有没有这些东西：

我是谁？
我要完成什么？
好结果长什么样？
我应该按什么流程做？
哪些信息更重要？
输出之前要检查什么？
遇到材料不足时怎么处理？
最后交付给谁看？

Codex 在这些地方有更成熟的默认工作流。

而 OpenClaw 如果只是“接了 GPT-5.5 模型”，但没有写清 agent 身份、任务流程、输出标准、资料读取方式、咨询方法论、校验规则，它就容易变成一个“能聊天的通道机器人”。

不是它笨，是它没有被训练成你要的那个角色。

四、同样是 GPT-5.5，放在不同容器里，结果完全不同

这点非常重要。

你今天看到 OpenClaw 里 GPT-5.5 在线，容易以为：

“既然同样是 GPT-5.5，那效果应该差不多。”

但现实不是这样。

同一个模型，放在不同产品容器里，效果可能差很多。

1. Codex 的容器是“任务完成型”

Codex 的设计目标是让模型完成复杂任务。它会围绕任务上下文、环境、文件、命令、历史指令、工作流去组织模型行为。

OpenAI 的 Codex Cloud 文档提到，Codex 可以在自己的云环境中处理任务，用户可以配置环境、依赖、工具和设置。(OpenAI开发者)

这就意味着 Codex 不只是“问答窗口”，而是一个有工作区、有上下文、有执行过程的任务系统。

2. OpenClaw 的容器是“开放连接型”

OpenClaw 的价值在于开放、可扩展、能接各种渠道和工具。它适合做微信、飞书、Telegram、本地 GUI、自动化工作流、定时任务、skills 扩展。

但开放的代价是：默认状态下，它不一定替你做好“专业任务范式”。

你要让它像咨询专家，就得给它装咨询专家的：

角色定义；
工作流程；
诊断模型；
话术模板；
案例库；
反思机制；
输出规范；
评分标准；
记忆策略。

否则，它就是拿着好模型，但不知道要往哪里使劲。

五、OpenClaw 和 Codex 的本质区别：一个是“操作系统”，一个是“专家工位”

可以这样理解：

1. OpenClaw 是“AI 操作系统”

它的关键词是：

通道；
插件；
skills；
工具调用；
自动化；
多模型；
多 agent；
网关；
消息分发；
本地环境接管。

它像一个开放式工作台，什么都能接，什么都能扩，但前提是你要会搭。

这很适合你这种重度玩家，因为你本来就不是只想聊天，你想把 AI 接进业务现场、接进微信、接进飞书、接进本地文件、接进企业流程。

但问题也在这里：

OpenClaw 给你的是“搭积木的能力”，不是默认给你一座已经装修好的咨询公司。

2. Codex 是“被训练好的专家工位”

Codex 原本主要面向代码任务，但它的优势在于：

任务意识强；
上下文组织强；
长任务推进强；
结构化交付强；
对指令继承敏感；
对文件和项目上下文敏感；
更像一个能持续工作的助理。

尤其是 Codex 体系里有 AGENTS.md、skills、环境配置等机制。AGENTS.md 的设计目的，就是给 AI agent 一个可预测的地方来读取项目指令、构建步骤、测试命令和约定。(AGENTS.md)

这就是为什么 Codex 很容易给出“像交付物”的结果。

六、为什么学生咨询建议这种任务，Codex 反而可能更好？

表面看，Codex 是代码工具，学生咨询不是代码任务。

但学生咨询建议，本质上不是闲聊，而是一个复杂的“诊断型任务”。

它包含至少五层能力：

1. 信息压缩能力

学生的咨询记录通常很长，很散，里面有情绪、事实、抱怨、期待、矛盾、隐藏诉求。

好建议不是复述原文，而是要压缩出：

学生真正的问题是什么；
表面问题和深层问题分别是什么；
哪些是情绪问题；
哪些是认知问题；
哪些是行动问题；
哪些是环境问题；
哪些是家庭/学校/职业路径问题。

Codex 更像在读一个复杂项目，会自然寻找结构、依赖、冲突和关键路径。

2. 诊断建模能力

好的咨询建议不能只有“你要加油”“你要坚持”“你要多沟通”。

它要有模型。

比如：

情绪状态判断；
认知偏差识别；
目标澄清；
能力差距分析；
资源盘点；
行动路径设计；
风险预警；
下一次跟进问题。

Codex 的任务式思维更容易形成这种结构。

3. 交付物意识

Codex 输出时，经常不是“回答一下”，而是“交付一个可用结果”。

学生咨询建议也需要这种交付意识：

给老师看的判断摘要；
给学生看的沟通话术；
给家长看的解释版本；
给后续陪跑用的行动计划；
给下一次咨询用的追问清单。

OpenClaw 如果没有被提示成这种交付模式，它就容易输出泛泛建议。

4. 自我校验能力

好咨询建议要避免几个坑：

过度鸡汤；
过度诊断；
过度说教；
忽略学生情绪；
给出不切实际行动；
只站老师视角，不站学生视角；
把复杂问题简单归因为“学生不努力”。

Codex 往往更容易在输出前做一轮内部检查。OpenClaw 如果 agent prompt 里没有写“输出前必须检查”，它就可能一遍生成完事。

5. 上下文继承能力

你说“把学生咨询记录和上次 Codex 咨询建议给它”，这句话里有一个关键点：

OpenClaw 有没有真的完整、有效、按优先级读取这些资料？

很多时候不是你没给，而是智能体没“吃对”。

它可能出现几种情况：

只读了最后一段；
被通道截断；
文件没有正确解析；
多文件顺序混乱；
把 Codex 建议当作普通参考，没有当作标杆；
没有识别“我要复刻上次 Codex 的咨询质量”这个真实目标；
上下文太长，被压缩后丢掉关键判断；
没有被要求“先分析 Codex 为什么写得好，再仿照其方法输出”。

这就像你把一本教案塞给一个新老师，但没告诉他：“你要先拆解这个教案的教学法，再用同样方法给新学生设计方案。”

结果当然差。

七、你遇到的不是模型问题，而是“专家技能没有固化”的问题

从你的场景看，真正的问题不是：

OpenClaw 5.20 不行。

而是：

OpenClaw 里的“学生咨询专家 skill”还没有成型。

你现在把资料临时丢给它，它当然能做，但效果不稳定。

要想接近 Codex 的效果，不能靠每次临时提示词，而要把 Codex 那套好结果拆成一个可复用 skill。

这个 skill 至少要包含八个模块。

1. 角色模块

明确它不是聊天助手，而是：

学生成长咨询顾问 / 学业规划陪跑顾问 / 心理支持型教练 / 教师辅助决策顾问。

并且要告诉它：

不做医学诊断；
不贴标签；
不替代心理医生；
关注支持性建议；
关注行动可落地；
关注保护学生自尊。

2. 资料读取模块

规定它读资料的顺序：

先读学生原始咨询记录；
再读历史沟通记录；
再读上次 Codex 建议；
最后读老师补充要求；
若材料冲突，以原始记录为准；
若目标不清，先给出假设，不要瞎编。

3. 问题诊断模块

要求它必须从四层诊断：

表层问题：学生直接说了什么；
深层问题：背后真正卡住什么；
情绪状态：焦虑、逃避、低自信、迷茫、压力等；
行动障碍：时间、方法、资源、支持系统、环境约束。

4. 人群视角模块

学生咨询不能只站一个角度。

至少要分三种视角：

学生本人视角：他为什么这样想？
老师/咨询师视角：我该怎么引导？
家长/学校视角：如何支持而不压迫？

5. 建议生成模块

输出建议不能只给大道理，要分层：

立即可做的 1—3 个动作；
一周内可验证的小目标；
一个月内的成长路径；
需要老师跟进的问题；
需要家长配合的边界；
风险提醒和转介建议。

6. 话术模块

真正好用的咨询建议，必须给话术。

比如：

老师怎么对学生说；
学生怎么对家长说；
家长怎么支持学生；
下一次咨询怎么开场；
如果学生沉默，怎么追问；
如果学生抵触，怎么回应。

7. 输出格式模块

固定输出结构：

一句话判断；
关键问题摘要；
学生状态画像；
深层原因分析；
咨询策略；
具体话术；
行动计划；
风险提醒；
下次跟进清单。

8. 质量校验模块

最后要求它自检：

有没有空泛鸡汤？
有没有过度诊断？
有没有忽视学生情绪？
有没有可执行动作？
有没有给老师能直接使用的话术？
有没有区分事实、推断和建议？
有没有尊重学生？

这套东西一旦固化进 OpenClaw skill，龙虾的效果会明显上来。

八、为什么“把 Codex 的好答案给 OpenClaw”还不够？

这点也很关键。

你把 Codex 上次的咨询建议给 OpenClaw，不代表 OpenClaw 就会学会 Codex 的方法。

因为 AI 很可能只看到“成品”，没有看到“生成成品的方法”。

就像你给一个新人看麦肯锡报告，他未必能写出麦肯锡报告。除非你告诉他：

这份报告为什么好；
它的结构是什么；
每一段承担什么功能；
它如何先结论后证据；
它如何把事实转成判断；
它如何把判断转成行动；
它如何控制语气；
它如何避免废话；
它如何处理风险边界。

所以你下一步不应该只是说：

“参考上次 Codex 的风格。”

而应该说：

“先拆解上次 Codex 建议的结构、判断逻辑、语气、行动设计方式，再按同样方法为新学生生成建议。”

这就完全不一样了。

前者是“模仿文风”。

后者是“复刻方法论”。

咨询类任务，真正值钱的是方法论，不是文风。

九、OpenClaw 想追上 Codex，关键是做“三层封装”

第一层：提示词封装

不要每次临时写需求，要做固定提示词模板。

比如：

你是学生成长咨询专家。请基于学生咨询记录，完成一次支持性、可执行、可跟进的咨询建议。

请先完成以下内部分析：
1. 学生直接表达的问题；
2. 学生没有明说但可能存在的深层问题；
3. 情绪状态判断；
4. 认知模式判断；
5. 行动障碍判断；
6. 可支持资源判断；
7. 风险边界判断。

输出时请按照：
一、一句话判断
二、学生状态画像
三、核心问题诊断
四、咨询建议
五、老师可直接使用的话术
六、一周行动计划
七、下次跟进问题
八、风险提醒

要求：
不要鸡汤；
不要空泛建议；
不要给医学诊断；
不要贴标签；
每条建议必须可执行；
话术要温和、具体、有边界。

第二层：skill 封装

把提示词、案例、输出模板、评分标准、反例都放进 skill。

不要让 OpenClaw 每次临场发挥。

skill 里要有：

标准流程；
标准输出；
标杆样例；
禁止事项；
质量检查表；
常见学生类型；
咨询话术库。

第三层：案例库封装

把过去做得好的 Codex 咨询建议，整理成“案例库”。

但注意，不是直接堆进去，而是要结构化：

案例类型	学生表现	深层问题	咨询策略	关键话术	行动计划
学业迷茫型	不知道学什么	目标模糊	目标澄清	先认可情绪	一周探索任务
自我否定型	总觉得不行	低自我效能	小胜利重建	不急着否定他	每天记录一个完成项
家长期待冲突型	被父母安排	自主性不足	边界沟通	先理解父母期待	准备一次沟通清单

有了这个，OpenClaw 才不是“临时聊天”，而是“调用专业咨询系统”。

十、还有一个隐藏差距：Codex 往往更会“长任务思考”

Codex 在设计上更适合长任务和复杂任务。官方文档提到 Codex Cloud 可以处理后台任务，包括并行任务；Codex App 也被描述为可以管理多个 agent、查看进度和决策、处理长时间任务。(OpenAI开发者)

而 OpenClaw 接在微信、飞书等消息通道时，很容易被“聊天节奏”影响。

消息通道天然有几个问题：

用户输入碎片化；
上下文容易散；
文件解析不稳定；
长文本可能被截断；
agent 可能急着回复；
工具权限可能没配全；
message 工具或 channel tool 配置不完整时，回复和附件操作还可能失败。

你前面已经遇到过类似提示：agent routed from channel but message tool unavailable。这说明 OpenClaw 的通道、agent、tool allowlist 之间如果没配好，能力会被“卡脖子”。

这类问题不会让模型变笨，但会让它发挥不完整。

就像一个专家被请到现场，但不给他白板、不给资料、不给投影、不给完整病历，只让他在微信群里看几段截图，然后马上给方案。结果自然打折。

十一、所以真正的判断是：Codex 胜在“默认工程化”，OpenClaw 胜在“可改造成业务系统”

Codex 和 OpenClaw 不是简单谁强谁弱。

它们强在不同地方。

Codex 的优势

默认任务感强；
上下文组织好；
输出更像交付物；
长任务推进更稳；
指令继承机制成熟；
更适合复杂分析和产物生成；
自带更强的“完成任务”心智。

OpenClaw 的优势

能接微信、飞书、本地应用；
能挂工具；
能做自动化；
能做多渠道智能体；
能做企业工作流入口；
能把 AI 接到真实业务现场；
能沉淀成自己的 agent 和 skills。

所以对你来说，最好的策略不是二选一。

而是：

用 Codex 打样，用 OpenClaw 固化；用 Codex 做方法论母版，用 OpenClaw 做业务交付入口。

这句话很重要。

Codex 负责把高质量样板跑出来。

OpenClaw 负责把样板变成可复用、可调用、可分发、可在微信/飞书/本地执行的业务系统。

这才是正确打法。

十二、给栋哥的实操建议：别再只测模型，要测“整条链路”

你现在要排查 OpenClaw 为什么不如 Codex，不要只看：

是不是 GPT-5.5；
key 对不对；
模型在线没在线；
版本是不是 5.20。

这些只是基础。

真正要测下面这 10 项。

1. 测上下文是否完整进入模型

让 OpenClaw 先回答：

“请列出你实际读取到的学生资料、Codex 建议、老师要求，各自的核心内容。”

如果它列不全，说明不是模型问题，是上下文没喂进去。

2. 测它是否理解“Codex 是标杆”

让它回答：

“请先拆解上次 Codex 咨询建议为什么好，提炼出结构、语气、判断方式和行动设计方法。”

如果它不会拆，后面当然模仿不了。

3. 测输出结构是否固定

不要让它自由发挥。

要强制它按固定结构输出。

4. 测是否有咨询专家角色

如果 agent prompt 只是“你是一个有帮助的助手”，那就废了。

要换成“学生成长咨询专家”。

5. 测是否有风险边界

学生咨询涉及心理和成长问题，必须有边界意识。

不能乱贴心理标签，也不能做医学诊断。

6. 测是否有话术能力

只给建议不够，要能给老师直接说出口的话。

7. 测是否有行动计划

没有行动计划的咨询建议，都是半成品。

8. 测是否有自检机制

输出后让它自查：

“这份建议哪里空泛？哪里缺少证据？哪里不够温和？哪里不可执行？”

9. 测 message/tool 配置

如果 OpenClaw 用在飞书、微信等通道，要检查 agent 是否有 message 工具、group messaging 权限、附件读取权限、文件解析能力。

OpenClaw 的配置本来就包含 channels、models、tools、sandboxing、sessions 等多个层面。(OpenClaw)

10. 测是否沉淀为 skill

一次调好不叫能力。

能重复调用、稳定产出，才叫能力。

十三、最终判断：龙虾不是不行，是现在还没被训练成“咨询龙虾”

你今天遇到的差距，本质上不是：

“OpenClaw 5.20 比 Codex 差。”

而是：

“Codex 默认就是一个被深度工程化的任务专家；OpenClaw 现在只是接上了强模型，但还没有装上你的咨询方法论。”

龙虾的强项，是把 AI 接到真实业务世界。

Codex 的强项，是把复杂任务做成高质量交付物。

所以，正确路线应该是：

先用 Codex 产出高质量咨询样板，再把样板拆成方法论，然后封装成 OpenClaw skill，最后通过微信/飞书/本地工作流交付。

这样龙虾就不再只是“能回答”，而是能变成你的：

学生咨询助手；
成长陪跑顾问；
课程服务中台；
老师话术生成器；
咨询记录分析器；
后续跟进计划生成器。

一句话收束：

模型在线，只是点火；方法论在线，才是真正启动。Codex 赢在默认方法论，OpenClaw 要赢，就得把你的专家经验封装进去。

你已经有一桌好刀了，为什么还值得用 Manus？

Wed, 20 May 2026 16:49:43 +0800

江天，你现在的工具栈已经很豪华了：Claude Code、Codex、opencode、aider、deepseek-tui，负责代码、重构、调试、命令行协作；OpenClaw、小龙虾、Hermes，负责长期工作流、技能封装、模型路由和自动化执行。
所以，如果有人跟你说：“Manus 比这些都强，你应该换掉它们。”这话我反而不信。

真正说服你的理由应该是另一句：

你缺的不是更聪明的代码助手，而是一个能把“业务任务”直接推到“可展示成品”的云端交付员。

Manus 的价值，不在于替代 Claude Code、Codex、OpenClaw，而在于补上它们之间最麻烦的一段：从资料、想法、网页、数据、截图、需求，直接生成一个老板看得懂、客户愿意点头、团队可以继续协作的成果物。

一、站在 Manus 销售经理的角度：我不会卖你“模型”，我卖你“交付闭环”

你已经有很多 AI 工具，但这些工具大多还是“专业工兵”。

Claude Code、Codex、opencode、aider 很适合进代码仓库，拆需求、改接口、写测试、修 bug。
OpenClaw、小龙虾、Hermes 很适合做长期工作流、企业级 Agent、技能封装、本地/私有化自动化。
deepseek-tui 很适合低成本、高频、快速推理。

但客户、老板、企业管理层通常不关心你用了多少模型、多少命令、多少技能。他们只关心一件事：

东西呢？报告呢？网页呢？PPT 呢？原型呢？可不可以现在打开看？

这正是 Manus 的销售切入点。

官方文档里，Manus 被定义为一个“能完成任务并交付结果”的自主通用 AI Agent，它像一个有自己虚拟电脑的同事，可以规划、执行并交付完整工作成果；它的环境包含联网、持久文件系统、安装软件和创建工具的能力。(Manus)

这句话翻译成业务语言就是：

你给它一个目标，它不是只回你一段文字，而是尽量把任务做完，把成品拿出来。

这对你特别关键。因为你现在做的不是单纯开发，而是“AI 实战导师 + 企业咨询 + 培训交付 + 报告生产 + 现场演示”。你卖给客户的不是代码，是信任感；不是工具清单，是成果可见。

所以 Manus 最值得你用的地方，是这些高频场景：

你的任务	现有工具强项	Manus 补位价值
企业 AI 培训前准备	Claude/Codex 帮你写框架、脚本	Manus 直接生成可展示网页、PPT、视觉稿、资料包
行业研究报告	你用搜索、文件、模型反复整理	Manus 可用浏览器跑调研、整理资料、生成结构化报告
经营分析演示	OpenClaw 可封装流程	Manus 更适合快速做“老板能看的成品页”
智能体销售演示	小龙虾负责系统级能力	Manus 负责现场快速生成漂亮产物，增强冲击力
客户方案/报价/路演	你要反复改 PDF/PPT/网页	Manus 更像“云端交付助理”，一边做一边给你看

Manus 的云端浏览器能像人一样访问网页、点击、填表、抽取数据、完成跨网页流程；也能在授权后进入需要登录的系统或资料工具。(Manus) 这意味着，它不只是“帮你想”，而是可以帮你“跑网页流程”。

如果再接上 Desktop / My Computer，它还能在授权范围内连接你的本地文件、应用和开发工具，通过命令行读写文件、启动应用，官方也强调每次执行本地命令需要用户明确批准，访问范围限定在授权文件夹内。(Manus)

销售经理会怎么劝你？

江老师，您现在的问题不是工具不够，而是每个工具都太专业。Manus 给您的是一个面向客户交付的“总包工头”：它能把研究、资料、网页、代码、设计、幻灯片、数据分析，往一个可展示成果上收拢。

这就是它的第一个购买理由：
它不是你的第 N 个代码助手，而是你的交付型 Agent。

二、站在重度用户角度：我不会天天用 Manus 写代码，但我会让它干“脏活、杂活、成品活”

如果我是你这样的重度用户，我不会把 Manus 当成主力代码工具。

真要进 Laravel、Yii2、PHP 老项目，我还是优先 Claude Code、Codex、opencode、aider。因为它们更贴近仓库、更适合 diff、更适合测试、更适合工程约束。

但我会把 Manus 放在另一个位置：

所有“不值得我亲自盯着，但最后必须有成品”的活，都丢给 Manus。

比如：

1. 让 Manus 做“售前样板间”

你要给客户讲 AI 落地，如果只讲 Claude Code、OpenClaw、技能封装，管理层会觉得厉害，但有门槛。
Manus 可以承担一个很重要的角色：快速做出看得见的样板间。

比如你输入：

基于某汽车后市场企业，生成一个 AI 经营分析演示网页，包含市场细分、竞品对比、经营异常、管理动作建议，风格参考麦肯锡/BCG，适合董事会汇报。

它可能不是最终生产系统，但它能在 20 分钟内给你一个“客户看得懂”的界面。这个界面再配合你的小龙虾/OpenClaw 后台能力，销售杀伤力会强很多。

OpenClaw 负责证明：这套东西能长期运行。
Manus 负责证明：这套东西现在就能看见。

这俩放一起，才是商业闭环。

2. 让 Manus 做“报告第一版工程”

你经常做行业报告、经营分析、课程资料、PDF/PPT。这里最累的不是某一句话写得多漂亮，而是：

资料搜集、网页浏览、截图理解、数据整理、结构搭建、图表草稿、版式初排、素材归档。

Manus 的云端浏览器适合做网页操作和资料抽取；它的多模态能力覆盖图片理解、视频理解、语音转文字、图像生成、语音输出等，官方文档列举的用途包括文档扫描、图表分析、会议转写、竞品视频提炼、流程图和信息图生成等。(Manus)

所以我不会让 Manus 写最终版麦肯锡级报告，但我会让它做：

资料初筛 + 结构初稿 + 图表草稿 + 页面原型 + 可视化方向。

然后你再用自己的方法论、证据链、管理表达去精修。
这就很值。

3. 让 Manus 做“异步小团队”

你现在用很多工具，大部分时候还是你在中间调度：这边跑命令，那边改 prompt，这边上传文件，那边导出结果。

Manus 的一个隐藏价值是：它更适合被当成一个“异步助理”。
官方的 Scheduled Tasks 可以做每日、每周、每月的周期性任务，比如竞品更新、定期报告、周期性数据采集和变化监控。(Manus)

对你来说，这不是普通提醒，而是可以变成这些固定动作：

每周自动整理 AI Agent 新产品动态；
每天抓取某行业新闻和政策变化；
每月生成客户经营复盘素材；
定期检查竞品网站、招聘岗位、融资动态、产品更新；
课程前自动准备案例包、资料包、问答素材。

这类活用 Claude Code 干，太重；用 OpenClaw 干，当然可以，但你要自己搭流程。
Manus 的意义是：先低成本跑起来，验证这个自动化任务值不值得产品化。

跑顺了，再沉淀成 OpenClaw Skill、小龙虾工作流、企业级交付系统。

4. 让 Manus 做“多人协作界面”

你现在的很多成果不是给自己看的，是给客户、学员、合伙人、团队看的。

Manus Collab 支持多人在一个任务空间里实时协作、查看进展、共同提示修改，避免多个版本文件来回传。(Manus)

这个点对纯开发者不一定重要，但对你很重要。因为你的工作经常是：

客户提一个方向；
你拆成方法论；
AI 生成初版；
客户反馈；
你再组织成 PPT/PDF/方案；
团队再补资料、补图、补证据。

如果 Manus 能成为“客户参与式产出空间”，它的价值就不是工具效率，而是协作效率和信任效率。

客户看到 AI 在执行，看到你在调整方向，看到结果逐步形成，会更容易相信你卖的不是“AI 概念”，而是一套真正会干活的交付方式。

三、你到底为什么还需要 Manus？一句话说透

因为你的现有工具，大多是“生产力工具”；Manus 更像“成果物工具”。

生产力工具解决的是：我怎么更快写代码、更快分析、更快调用模型。
成果物工具解决的是：我怎么更快拿出一个别人能看懂、能评价、能转发、能决策的东西。

你现在的商业战场，不在“谁的命令行更强”，而在：

谁能更快做出客户愿意买单的样板；
谁能更快把复杂 AI 能力变成老板看得懂的页面；
谁能更快把行业研究、经营分析、智能体原型包装成可交付产品；
谁能更快让客户感觉“这不是演示，这就是未来工作方式”。

Manus 恰好适合补这个位置。

四、最适合你的用法：不要替换，做分工

我建议你这样摆放工具：

工具	在你体系里的定位
Claude Code / Codex	主力工程师，负责复杂代码、重构、测试、仓库级任务
opencode / aider	快速代码协作、轻量改造、局部任务
deepseek-tui	低成本、高频推理、命令行问答
OpenClaw / 小龙虾	长期工作流、Skill、企业自动化、消息入口、模型路由
Hermes	本地/跨系统调度、辅助执行
Manus	云端交付员、成品生成器、售前样板间、异步研究助理、多人协作空间

所以你买 Manus，不是因为你缺一个 AI。
你买 Manus，是因为你缺一个能替你把混乱任务收口成“可展示成果”的云端同事。

五、最后的销售话术：江老师，Manus 不是让你少用那些高手，而是让高手们有一个“交付出口”

你手上已经有一堆高手了。

Claude Code 像高级程序员。
Codex 像代码架构助理。
OpenClaw 像企业级工作流底座。
小龙虾像可训练的长期智能员工。
Hermes 像调度器。
deepseek-tui 像随叫随到的低成本智囊。

但 Manus 更像一个能说这句话的人：

“江老师，你先去谈客户。我在云端把资料看了、网页跑了、初版 PPT 搭了、演示页面做了、报告骨架出了。你回来只需要判断、拔高、收口。”

这就是理由。

不是因为 Manus 比你的所有工具都强。
而是因为它站的位置不一样。

代码工具帮你把事情做对。
工作流工具帮你把事情做稳。
Manus 帮你把事情做成“别人看得见的成果”。

对一个只写代码的人，Manus 未必刚需。
对你这种要做企业 AI 培训、咨询交付、经营分析、行业报告、智能体演示、客户转化的人，它值得放进工具箱。

不是主刀。
是交付台。
不是替代你的武器库。
是帮你把武器库打包成客户愿意买单的战斗成果。

Manus 支付宝入口到底在哪里？为什么免费计划里看不到？

Wed, 20 May 2026 16:00:26 +0800

Manus 支付宝入口到底在哪里？为什么免费计划里看不到？

最近有不少人在开通 Manus 会员时遇到一个问题：

官方说支持 Alipay，但我在页面里怎么找不到支付宝入口？

这个问题容易让人误以为是自己没找对地方，实际上并不是。Manus 的支付宝入口并不是固定展示在所有页面里，它只会在特定支付场景下出现。

一、结论先说

Manus 的 Alipay 支付入口一般出现在“正式付费套餐”的实际支付页里，而不是免费试用入口里。

也就是说，如果你点的是：

Free Trial
免费试用
7-day trial

大概率看不到支付宝。

如果你进入的是：

Subscribe
Upgrade
正式付费
月付套餐
年付套餐

到了真正付款的页面，才有可能看到 Alipay。

二、为什么免费计划里没有 Alipay？

核心原因是：支付宝通常不支持免费试用型订阅授权。

免费试用不是简单付款，而是需要先绑定一个可后续自动扣款的支付方式。很多海外订阅平台会要求用户绑定信用卡、借记卡、Apple Pay、Google Pay 等方式，用于试用结束后的自动续费。

支付宝更多用于一次性正式付款或标准订阅付款，所以在免费试用入口里通常不会显示。

因此你在免费计划里找不到支付宝，不是页面坏了，也不是账号异常，而是支付规则本身导致的。

三、正确的操作路径

如果你想用支付宝支付 Manus，可以这样试：

1. 打开 Manus 官网
2. 登录账号
3. 进入升级 / 订阅 / Pricing 页面
4. 不要选择 Free Trial
5. 直接选择正式付费套餐
6. 进入实际支付页
7. 在支付方式里查看是否有 Alipay

关键点是：

不要从免费试用入口进去，要从正式付费入口进去。

四、为什么有些人还是看不到支付宝？

即使 Manus 支持 Alipay，支付宝也不一定对所有用户固定展示。

很多海外产品使用 Stripe 这类支付系统，支付方式会根据用户所在地区、账号状态、设备环境、套餐类型、币种、浏览器等因素动态展示。

所以实际情况可能是：

情况	是否容易看到 Alipay
免费试用入口	通常看不到
正式付费页面	更容易看到
手机 App 内购	通常看不到
电脑网页支付	更容易看到
Stripe 判断不适用	可能不显示

这就是为什么有人能看到支付宝，有人看不到。

五、网页版和 App 支付不一样

如果你是在手机 App 里开通 Manus，通常会走：

Apple App Store
Google Play

这种情况下，支付方式由苹果或 Google 控制，Manus 页面里的 Alipay 通常不会出现。

所以想找支付宝，建议用：

电脑浏览器
Manus 网页版
正式付费套餐
实际支付页

这个组合成功率最高。

六、如果没有支付宝，可以用什么替代？

如果你在正式付款页里仍然看不到 Alipay，可以优先尝试：

Visa
Mastercard
银联卡
Apple Pay
Google Pay

如果银行卡支付失败，常见原因包括：

海外支付被银行拦截
账单地址不匹配
浏览器缓存问题
支付风控
卡片不支持国际订阅

可以换一张卡、换浏览器，或者用 Apple Pay / Google Pay 试一下。

七、最终判断

Manus 的支付宝入口不是在免费计划里，也不是账号页面里单独放一个“支付宝支付”按钮。

它的真实逻辑是：

支付宝入口只可能出现在网页版正式付费套餐的实际支付页中。免费试用入口一般不会显示。

所以正确做法很简单：

不要点免费试用
直接进入正式套餐付款页
到最后支付页面找 Alipay

如果能看到，就直接支付；如果看不到，就说明当前账号、地区或支付环境暂时没有给你展示支付宝入口，换银行卡或 Apple Pay 会更稳。

manus如何付费？

Wed, 20 May 2026 15:46:23 +0800

Manus 支付主要有 网页版订阅 和 手机 App 内购 两种方式。

1. 网页版支付

进入：

manus.im

登录后一般路径是：

Account / 头像
→ Manage / Subscription
→ 选择套餐
→ 支付

Manus 官方帮助中心写到，网页版订阅的账单管理里可以进入 Manage subscription / Edit billing 修改支付方式。(help.manus.im)

2. 支持哪些支付方式

Manus 当前支持这些支付方式：

类型	支持方式
信用卡 / 借记卡	Visa、Mastercard、American Express、JCB、中国银联
数字钱包	Apple Pay、Google Pay、Alipay、Link
直接扣款	PayNow，新加坡用户

官方说明还提到：如果是开免费试用，通常需要使用信用卡/借记卡或 Apple Pay、Google Pay、Link；试用结束后或直接升级付费时，可以选择 Alipay。(help.manus.im)

3. 手机端支付

如果你是在 iPhone 或 Android App 里订阅，那就是走：

Apple App Store
Google Play

后续改支付方式、处理扣费失败，也要去 Apple 或 Google 那边处理。Manus 官方说明里明确区分了官网 Stripe 订阅和 Apple / Google 应用商店订阅。(help.manus.im)

4. 套餐大概多少钱

Manus 当前 Pro 计划官方帮助中心显示有两个起步价：

套餐	价格	额度
Pro 低档	$20/月起	4,000 credits/月起
Pro 高档	$40/月起，带 7 天免费试用	8,000 credits/月起
Team	$20/席/月起	团队协作能力

官方也提醒：最终价格以实际 pricing 页面显示为准。(help.manus.im)

5. 你最省事的做法

直接用 支付宝 Alipay 或 银联卡 试一下网页版支付；如果网页支付失败，再换 Apple Pay / Google Pay。

如果卡付不了，常见处理是：检查卡信息和账单地址、清浏览器缓存、联系银行确认是否拦截海外扣款，或者换一种支付方式。(help.manus.im)

什么是真正的智能体？

Wed, 20 May 2026 14:45:13 +0800

严格意义上的智能体

学界对 Agent 最经典的定义来自 Russell & Norvig 的《人工智能：一种现代方法》——能够通过传感器感知环境、并通过执行器对环境采取行动的实体。这个定义看似宽泛，但要被称为"智能"体，通常要求同时满足四个属性：

自主性 (Autonomy)：不需要人类持续干预，自己决定下一步做什么
反应性 (Reactivity)：能感知环境变化并及时响应
主动性 (Proactivity)：目标导向，会主动采取行动达成目标，而不只是被动等指令
社会性 (Social Ability)：能与其他 Agent 或人类交互协作

到了 LLM 时代，严格意义上的智能体有了更具体的技术形态。一个完整的 Agent 至少要包含五个组件：

LLM 作为推理核心（大脑）
规划能力——能把复杂目标拆解成子任务序列
记忆——短期记忆维持上下文，长期记忆跨会话保留信息
工具调用——能够主动选择和使用外部工具
闭环执行——能观察行动结果，根据反馈调整后续行动

这里第五点最关键。Anthropic 在《Building Effective Agents》这篇官方文档里给出了一个非常清晰的区分：

Workflow（工作流）：LLM 和工具按照预先写死的代码路径被编排执行。流程是固定的。
Agent（智能体）：LLM 自己动态决定流程和工具调用。流程是模型现场决定的。

按这个标准，Dify 上拖拽出来的固定 chain 不是 Agent；而 Claude Code，你说"帮我重构这个项目"，它自己决定看哪些文件、怎么改、改完跑什么测试——这才是严格意义上的 Agent。

广泛意义上的智能体

到了产品和市场层面，"智能体"这个词已经被严重稀释了。基本上符合下面任一条件，都能被叫做智能体：

套了一层 system prompt 的 ChatGPT、Claude（比如 GPTs、扣子上的角色 bot）
接入了一两个工具（联网、画图、代码解释器）的对话产品
任何 RPA + LLM 的组合
Dify、扣子、FastGPT 上拖拽出来的工作流
把多个 prompt 串联起来的脚本

国内行业里，"Agent"几乎等同于"AI 应用"。这本身不算错——一个 GPTs 确实勉强满足"自主性"和"反应性"的最低门槛——但如果你按这个标准去判断，你就没法区分一个静态的 FAQ bot 和 Devin、Manus 这种真正在跑长任务的系统。词的颗粒度太粗，就失去了分析价值。

一条更实用的光谱

我建议在课上用这样一条光谱来帮学员定位：

第一层对话工具：纯 chat，没有工具调用。ChatGPT 3.5 刚出来的形态。不算 Agent。

第二层增强对话：加了联网、画图、代码解释器，但每次工具调用基本是单步触发。Claude.ai、ChatGPT 现在的默认形态。勉强算"准 Agent"。

第三层工作流：多步任务，流程由人预先设计好。Dify、n8n、扣子拖出来的东西。本质是 Workflow，不是 Agent。

第四层真智能体：给一个目标，模型自己决定看什么、做什么、什么时候停。Claude Code、Cursor 的 Agent 模式、Devin、Manus、小龙虾 OpenClaw。这才是严格意义的 Agent。

第五层多智能体协作：多个 Agent 各司其职、互相调用。MetaGPT、AutoGen、CrewAI。

关键判断点只有一条："流程是谁决定的？"

流程是人写死的——工作流。流程是模型现场决定的——智能体。

一句话总结

严格意义上，Agent = LLM（大脑） + 规划 + 记忆 + 工具 + 自主闭环，核心特征是"流程由模型动态决定"。

广泛意义上，Agent = 任何带 AI 的、能"做点事"的产品。

教学时用严格定义更扎实，产品宣传时大家用的都是广泛定义——这个落差本身，其实就是一个很好的教学切入点。

无尘阁日记

OpenClaw 报错：Managed Codex app-server binary was not found 的根因与修复方法

OpenClaw 报错：Managed Codex app-server binary was not found 的根因与修复方法

一、问题现象

二、第一层理解：这个错误到底是什么意思？

三、为什么重装 OpenClaw 也没用？

四、错误排查过程

1. 第一反应：更新 OpenClaw

2. 第二步：检查旧配置是否覆盖

3. 第三步：确认 Codex CLI 是否独立可用

4. 第四步：找到 codex.cmd 的真实路径

五、最终解决办法：显式指定 OPENCLAW_CODEX_APP_SERVER_BIN

六、完整修复命令汇总

1. 安装或重装 Codex CLI

2. 测试 Codex app-server 是否能独立运行

3. 查看 codex.cmd 路径

4. 写入 OpenClaw Codex app-server 路径

5. 检查环境变量是否写入成功

6. 关闭 PowerShell，重新打开

7. 重启 OpenClaw gateway

8. 查看状态

七、为什么这个办法有效？

八、这类问题的标准判断流程

第一层：看错误关键词

第二层：确认 Codex 是否独立可用

第三层：显式指定 Codex 路径

第四层：检查 OpenClaw 配置

九、经验总结

华为甩出&quot;韬定律&quot;,最先疼的为什么是 ASML,而不是台积电?

华为甩出"韬定律",最先疼的为什么是 ASML,而不是台积电?

一、先别管 τ 长什么样,它就干了一件事:换了个考核指标

二、ASML:营收没掉一分钱,但被扎中了最敏感的那根神经

三、台积电:看着像被打脸,其实是撞了个满怀

四、泼盆冷水:哪些是真功夫,哪些是话术

五、那这事到底重要在哪

OpenClaw browser --browser-profile 深度解析：这不是“打开浏览器”，而是给 AI 配一套可控的网页操作工作台

OpenClaw browser --browser-profile 深度解析：这不是“打开浏览器”，而是给 AI 配一套可控的网页操作工作台

一、先给结论

二、openclaw browser 本质上是什么？

1. 它是 OpenClaw 给 AI 准备的“浏览器控制面”

2. 它解决的是 AI 的“眼睛”和“手”的问题

三、--browser-profile 到底是什么？

1. 它不是“浏览器标签页”，而是“浏览器身份”

2. --browser-profile 的价值是“明确指定任务现场”

四、默认 profile：openclaw

1. openclaw 是最推荐的新手默认方案

2. 它的核心好处：不污染你的个人浏览器

五、特殊 profile：user

1. user 是用来接管你真实 Chrome 登录环境的

2. 什么时候用 user？

六、为什么不建议一上来就用 user？

1. 它接的是你的真实浏览器

2. user 也有功能限制

七、自定义 profile：work、student、client-a

1. 自定义 profile 解决“多任务隔离”

2. 自定义 profile 的管理价值

八、远程 CDP profile：把浏览器放到服务器或容器里

1. 什么是 CDP？

2. 远程 profile 适合什么场景？

九、它到底解决了哪些痛点？

痛点一：AI 操作网页容易污染个人浏览器

痛点二：多个任务抢同一个浏览器现场

痛点三：登录网站不能把账号密码交给模型

痛点四：AI 只会“搜索”，不会“验证页面结果”

痛点五：演示和交付需要可复现现场

十、哪些场景最适合用 --browser-profile？

场景一：行业研究和报告资料搜集

场景二：企业后台操作

场景三：网页自动化测试

场景四：多账号运营

场景五：课程演示 / 直播演示

场景六：远程服务器自动化

十一、常用命令清单

1. 查看已有 profiles

2. 启动默认独立浏览器

3. 查看状态

4. 做基础检查

5. 打开网页

6. 查看 tabs

7. 读取页面快照

华为甩出"韬定律",最先疼的为什么是 ASML,而不是台积电?

OpenClaw `browser --browser-profile` 深度解析：这不是“打开浏览器”，而是给 AI 配一套可控的网页操作工作台

二、`openclaw browser` 本质上是什么？

三、`--browser-profile` 到底是什么？

2. `--browser-profile` 的价值是“明确指定任务现场”

四、默认 profile：`openclaw`

1. `openclaw` 是最推荐的新手默认方案

五、特殊 profile：`user`

1. `user` 是用来接管你真实 Chrome 登录环境的

2. 什么时候用 `user`？

六、为什么不建议一上来就用 `user`？

2. `user` 也有功能限制

七、自定义 profile：`work`、`student`、`client-a`

十、哪些场景最适合用 `--browser-profile`？

1. 如果 `openclaw browser` 命令不存在

坑二：用 `user` 但 Chrome 没开 tab

第四步：需要真实 Chrome 登录态时，再用 `user`