即刻App年轻人的同好社区
下载
不是「PC养虾」击败了「AI手机」，而是GUI Agent的用途被搞错了
龙虾之前，手机GUI Agent在国内更受重视，是因为国内的个人电脑普及和桌面互联网软件积累当年被打断，Tool的积累都在手机上
这是迎合现状的产品思维，但AI革命不是产品思维主导而是技术主导，移动互联网上的积累再深厚，其实都可以一夕推翻
Agent虽然「类人」，但更类似专业用户而不是大众用户，根本不需要手机app来降低交互门槛（参考附图），桌面电脑/服务器上的Tool对Agent来说能力更强更全、效率更高（有unix管道、bash脚本、文件系统、HTML/JS、Open API等可以直接用代码做自动化和聚合操作的软件协议）
GUI agent不是没用，而是之前被错误的用来解决另一类Agent的问题（OpenAI和xAI似乎都走了这个弯路，前者靠Codex快追上来了，后者正在推倒重建）
之前的帖子（m.okjike.com）里提到过「服务器端 AI」和「客户端 AI」这种Agent分类方式，这里说的客户端不是指模型在客户端运行，而是指Tool在客户端运行或涉及客户端交互
从用途角度来描述这两种类型的通用Agent会更清晰：
第一类可以称作「劳动代理」：用于取代传统的人口资源，供应独立劳动力
第二类可以称作「交互代理」，用于增强人类与外部世界（包括软件数字世界）互动的能力
「劳动代理」更适合用coding agent而不是用GUI agent实现。
这种Agent用的Tool更适合基于服务器/桌面软件环境（包括CLI）而不是手机GUI软件环境。
这种Agent就算扩展到移动场景，也是通过机器人，而不是通过用户的个人移动设备。
「交互代理」需要两类Agent产品形态，第一类是最彻底的形态，可以称作「Agentic Web浏览器」，用户通过这种浏览器（User Agent）与外界软件世界互动，通过Web获取Tool和内容，所有Tool、内容乃至客户端状态都聚合在浏览器自身「内部」。
另一类产品形态是所有个人计算设备（包括手机、眼镜/目镜等）的系统全局GUI Agent，能跟用户实时紧密协作，共享同一套外部的Tool环境和客户端状态。
这两类Agent之间还有一个交叉领域：
眼镜/目镜等可穿戴个人计算设备的多模态交互输入能力、GUI Agent的视觉能力和行动能力、机器人的Physical AI能力（含多模态、视觉、行动等），是共通的，只要其中一个需求够强，相关技术就注定会发展，让其他需求也受益
龙虾之前，手机GUI Agent在国内更受重视，是因为国内的个人电脑普及和桌面互联网软件积累当年被打断，Tool的积累都在手机上
这是迎合现状的产品思维，但AI革命不是产品思维主导而是技术主导，移动互联网上的积累再深厚，其实都可以一夕推翻
Agent虽然「类人」，但更类似专业用户而不是大众用户，根本不需要手机app来降低交互门槛（参考附图），桌面电脑/服务器上的Tool对Agent来说能力更强更全、效率更高（有unix管道、bash脚本、文件系统、HTML/JS、Open API等可以直接用代码做自动化和聚合操作的软件协议）
GUI agent不是没用，而是之前被错误的用来解决另一类Agent的问题（OpenAI和xAI似乎都走了这个弯路，前者靠Codex快追上来了，后者正在推倒重建）
之前的帖子（m.okjike.com）里提到过「服务器端 AI」和「客户端 AI」这种Agent分类方式，这里说的客户端不是指模型在客户端运行，而是指Tool在客户端运行或涉及客户端交互
从用途角度来描述这两种类型的通用Agent会更清晰：
第一类可以称作「劳动代理」：用于取代传统的人口资源，供应独立劳动力
第二类可以称作「交互代理」，用于增强人类与外部世界（包括软件数字世界）互动的能力
「劳动代理」更适合用coding agent而不是用GUI agent实现。
这种Agent用的Tool更适合基于服务器/桌面软件环境（包括CLI）而不是手机GUI软件环境。
这种Agent就算扩展到移动场景，也是通过机器人，而不是通过用户的个人移动设备。
「交互代理」需要两类Agent产品形态，第一类是最彻底的形态，可以称作「Agentic Web浏览器」，用户通过这种浏览器（User Agent）与外界软件世界互动，通过Web获取Tool和内容，所有Tool、内容乃至客户端状态都聚合在浏览器自身「内部」。
另一类产品形态是所有个人计算设备（包括手机、眼镜/目镜等）的系统全局GUI Agent，能跟用户实时紧密协作，共享同一套外部的Tool环境和客户端状态。
这两类Agent之间还有一个交叉领域：
眼镜/目镜等可穿戴个人计算设备的多模态交互输入能力、GUI Agent的视觉能力和行动能力、机器人的Physical AI能力（含多模态、视觉、行动等），是共通的，只要其中一个需求够强，相关技术就注定会发展，让其他需求也受益
4 00
正确理解的前提是正确分类，其实有两类做「GAO（通用Agent优化） 」的协议：
客户端Tool接口：
- 基于Unix哲学的CLI
- 基于原生GUI框架的App Intents（苹果）、AppFunctions（安卓）、App Actions（Win）
- 基于浏览器引擎的WebMCP
- 在客户端运行的MCP Server
服务器端Tool接口：
- MCP Server和MCP App
- 用Skill封装的Open API
作为新一代入口/分发中心/超级应用的通用Agent，目前也有两类：
- 生成客户端代码，调用在客户端（包括云端沙盒化的专用客户端环境）运行的Tool，比如cowork、openclaw
- 生成服务器端API调用代码，把服务器端API作为Tool，也用云端沙盒里的CLI Tool，提供类浏览器的跨平台客户端，比如ChatGPT、Manus
已有的软件产品的思维定式和常见迷思是以为AI就是「把Agent集成到软件里」，喜欢强调「场景/context」（也就是自家软件当下的用例），要么承担不了token成本、损害现有商业模式和现金流，要么容易觉得AI没啥用、落不了地，要么把软件主屏都改成对话界面，用户每次打开App都多了一步操作要跳过这个首屏
其实AI的真正意味是「把软件集成到通用Agent里」，软件的用户不再只是人（少数power user加一堆轻度用户），通用Agent（海量power user和会写代码的pro user）才是软件最重要的新用户
一个软件不做好GAO，不对通用Agent友好，相当于桌面互联网时代既不支持Web标准兼容现代浏览器也不做SEO对Google友好
要做GAO对各种现在和未来的通用Agent都尽可能友好，就应该尽可能提供上述所有Tool接口
没客户端，就优先提供CLI，而MCP和教AI用Open API的Skill更是根本
有客户端，就先在现有客户端技术栈中支持对应协议，比如有Web就优先在HTML中声明WebMCP，同时也探索MCP App（含MCP-UI）和面向pro user的CLI用法
最后再来看MCP会不会被取代的问题：
最初只有MCP这一种Tool协议的时候，客户端软件想作为Tool也需要依靠MCP Server（运行在客户端）
现在CLI的价值被「重新发现」：
1. 身为客户端软件，却不需要额外暴露Agent专用的Tool接口，自己原有的基于unix哲学的使用方式能直接作为API协议，人怎么用CLI，Agent就怎么用
2. 虽然也需要提前安装，但不需要像客户端MCP Server那样还要提前启动、持续运行。可以按需调用
3. 天然对云端沙盒化的Agent专用客户端环境友好，因此早就被ChatGPT这样的通用Agent们广泛使用，之后随着coding agent的破圈，在普通用户的客户端环境里也被各家通用Agent广泛使用
基于GUI的客户端软件（包括Web、Mac/Win、iOS/安卓）的使用方式，则是优先面向普通人的，Agent不是普通人，这种使用方式对会写代码的Agent来说是低效的，因此需要额外暴露API
各家客户端技术栈逐渐有了原生的Tool协议（开头提到的WebMCP、App Intents这类），但这些协议除了WebMCP都不是跨平台的，会首先采纳这类协议的，是操作系统自身的第一方通用Agent，这些还在发展早期，现有的主流通用Agent都是第三方超级应用，就算愿意采纳这些协议，也可能被操作系统限制
在支持UNIX风格CLI环境的客户端平台，CLI是已被广泛采纳的跨平台Tool协议，是最佳选择。而不支持CLI的客户端平台（比如手机等移动设备）对客户端运行MCP Server也同样不友好，要指望各家客户端技术栈的原生一方Tool协议。
推演结果是：在客户端，MCP确实可以淘汰
在服务器端，如果一款产品如果没有GUI，不面向普通用户，只提供Open API，那么用Skill直接教Agent用Open API似乎也完全可以代替MCP
如果有GUI，且想要集成到上面说的第二类通用Agent，则MCP仍然是必要的选择，MCP在这种情况下有两个优势：
1. 已经从MCP Server标准扩展到了MCP App标准，支持MCP-UI，可以在通用Agent中提供GUI
2. 本来就持续运行，只要通用Agent支持「Tool Search Tool」，能自主搜索发现MCP，就不需要提前安装，可以像Web那样被按需使用。Skill 只是本地文件协议，不是Web协议/网络协议，需要提前安装到本地文件系统里
推演结果是：在服务器端，MCP要靠发展UI能力和Web能力，才能免于淘汰
客户端Tool接口：
- 基于Unix哲学的CLI
- 基于原生GUI框架的App Intents（苹果）、AppFunctions（安卓）、App Actions（Win）
- 基于浏览器引擎的WebMCP
- 在客户端运行的MCP Server
服务器端Tool接口：
- MCP Server和MCP App
- 用Skill封装的Open API
作为新一代入口/分发中心/超级应用的通用Agent，目前也有两类：
- 生成客户端代码，调用在客户端（包括云端沙盒化的专用客户端环境）运行的Tool，比如cowork、openclaw
- 生成服务器端API调用代码，把服务器端API作为Tool，也用云端沙盒里的CLI Tool，提供类浏览器的跨平台客户端，比如ChatGPT、Manus
已有的软件产品的思维定式和常见迷思是以为AI就是「把Agent集成到软件里」，喜欢强调「场景/context」（也就是自家软件当下的用例），要么承担不了token成本、损害现有商业模式和现金流，要么容易觉得AI没啥用、落不了地，要么把软件主屏都改成对话界面，用户每次打开App都多了一步操作要跳过这个首屏
其实AI的真正意味是「把软件集成到通用Agent里」，软件的用户不再只是人（少数power user加一堆轻度用户），通用Agent（海量power user和会写代码的pro user）才是软件最重要的新用户
一个软件不做好GAO，不对通用Agent友好，相当于桌面互联网时代既不支持Web标准兼容现代浏览器也不做SEO对Google友好
要做GAO对各种现在和未来的通用Agent都尽可能友好，就应该尽可能提供上述所有Tool接口
没客户端，就优先提供CLI，而MCP和教AI用Open API的Skill更是根本
有客户端，就先在现有客户端技术栈中支持对应协议，比如有Web就优先在HTML中声明WebMCP，同时也探索MCP App（含MCP-UI）和面向pro user的CLI用法
最后再来看MCP会不会被取代的问题：
最初只有MCP这一种Tool协议的时候，客户端软件想作为Tool也需要依靠MCP Server（运行在客户端）
现在CLI的价值被「重新发现」：
1. 身为客户端软件，却不需要额外暴露Agent专用的Tool接口，自己原有的基于unix哲学的使用方式能直接作为API协议，人怎么用CLI，Agent就怎么用
2. 虽然也需要提前安装，但不需要像客户端MCP Server那样还要提前启动、持续运行。可以按需调用
3. 天然对云端沙盒化的Agent专用客户端环境友好，因此早就被ChatGPT这样的通用Agent们广泛使用，之后随着coding agent的破圈，在普通用户的客户端环境里也被各家通用Agent广泛使用
基于GUI的客户端软件（包括Web、Mac/Win、iOS/安卓）的使用方式，则是优先面向普通人的，Agent不是普通人，这种使用方式对会写代码的Agent来说是低效的，因此需要额外暴露API
各家客户端技术栈逐渐有了原生的Tool协议（开头提到的WebMCP、App Intents这类），但这些协议除了WebMCP都不是跨平台的，会首先采纳这类协议的，是操作系统自身的第一方通用Agent，这些还在发展早期，现有的主流通用Agent都是第三方超级应用，就算愿意采纳这些协议，也可能被操作系统限制
在支持UNIX风格CLI环境的客户端平台，CLI是已被广泛采纳的跨平台Tool协议，是最佳选择。而不支持CLI的客户端平台（比如手机等移动设备）对客户端运行MCP Server也同样不友好，要指望各家客户端技术栈的原生一方Tool协议。
推演结果是：在客户端，MCP确实可以淘汰
在服务器端，如果一款产品如果没有GUI，不面向普通用户，只提供Open API，那么用Skill直接教Agent用Open API似乎也完全可以代替MCP
如果有GUI，且想要集成到上面说的第二类通用Agent，则MCP仍然是必要的选择，MCP在这种情况下有两个优势：
1. 已经从MCP Server标准扩展到了MCP App标准，支持MCP-UI，可以在通用Agent中提供GUI
2. 本来就持续运行，只要通用Agent支持「Tool Search Tool」，能自主搜索发现MCP，就不需要提前安装，可以像Web那样被按需使用。Skill 只是本地文件协议，不是Web协议/网络协议，需要提前安装到本地文件系统里
推演结果是：在服务器端，MCP要靠发展UI能力和Web能力，才能免于淘汰
3 00
Qwen的tech leader离职的这个原因，跟我当年离开字节架构的原因完全一样😂
从无到有做起来、开始商业化之后，大厂管理容忍不了这种内部创业式的垂直整合团队和一体化协同产品
从无到有做起来、开始商业化之后，大厂管理容忍不了这种内部创业式的垂直整合团队和一体化协同产品
9 00
低情商和高情商的区别，同样的要求，Sam就谈成了😂
跟愚蠢爱虚荣的恶霸打交道，要始终夸对方，功劳都归对方，这个前提下再把具体细节引导到自己的立场上，不能一上来就让恶霸没面子、觉得你以后可能不服从他
情商不仅是个认知问题，也是个执行问题，低情商的执行是从一开始就追求确定性，不能有世界线发散的空间，不愿在表面妥协留出模糊空间，想一劳永逸的解决，不愿意走弯路和陪对方踩自己已知的坑
高认知低执行的低情商，本质上是能理解别人的情感、认知局限和非理性行为，但自己无法做出偏离事实、是非、直接手段、直线路径的行为调整。比如我自己就是虽然能想到上面这些道理，但行动上做不到，所以产品工作不好做，做产品经理不像做软件工程师，要跟更多样的人打交道，很多人不就事论事，不纯粹。我一般也不夸人，说话没情绪价值，只会发现问题和解决问题，怎么想就怎么说
跟愚蠢爱虚荣的恶霸打交道，要始终夸对方，功劳都归对方，这个前提下再把具体细节引导到自己的立场上，不能一上来就让恶霸没面子、觉得你以后可能不服从他
情商不仅是个认知问题，也是个执行问题，低情商的执行是从一开始就追求确定性，不能有世界线发散的空间，不愿在表面妥协留出模糊空间，想一劳永逸的解决，不愿意走弯路和陪对方踩自己已知的坑
高认知低执行的低情商，本质上是能理解别人的情感、认知局限和非理性行为，但自己无法做出偏离事实、是非、直接手段、直线路径的行为调整。比如我自己就是虽然能想到上面这些道理，但行动上做不到，所以产品工作不好做，做产品经理不像做软件工程师，要跟更多样的人打交道，很多人不就事论事，不纯粹。我一般也不夸人，说话没情绪价值，只会发现问题和解决问题，怎么想就怎么说
3 01
虚假的元宇宙：真人用户们在低效的沉浸式3D世界中玩乐高、4399或装模作样过家家
真正的元宇宙：Agent自身、工具和任务的复杂状态以及Agent之间的复杂实时关系都被可视化成高信息密度、直观易懂、交互自然的3D沙盘和沉浸式3D世界，真人用户以上帝视角和高层次操作掌控全局或以沉浸视角跟局部细粒度互动
真正的元宇宙：Agent自身、工具和任务的复杂状态以及Agent之间的复杂实时关系都被可视化成高信息密度、直观易懂、交互自然的3D沙盘和沉浸式3D世界，真人用户以上帝视角和高层次操作掌控全局或以沉浸视角跟局部细粒度互动
4 03
把今天Qwen 3.5发的benchmark结果跟前天Seed 2.0发的benchmark结果合并，在之前这个四大顶级模型（Seed 2.0 Pro 、GPT-5.2 high、Gemini 3 Pro high、Claude Opus 4.5）的横向比较（m.okjike.com）中加入Qwen3.5-397B-A17B
4 00
是时候展示我今年一个半月港股打新AI股的成果了🤑
我是完全用美股的杠杆额度打新，零本金，上市后不卖，但也不买（完全只靠复利来「加仓」），每次都只申购稍微超过乙头的金额，避免提升账户的整体杠杆率
我是完全用美股的杠杆额度打新，零本金，上市后不卖，但也不买（完全只靠复利来「加仓」），每次都只申购稍微超过乙头的金额，避免提升账户的整体杠杆率
13 00
群聊时随手写了一篇《翻身指南》：
经常有人说，做 XXX（比如炒币）感觉不会再有翻身的机会了
这里的重点其实不是 XXX 能否翻身，而是怎么定义翻身
很多人会说：买到一个 10x 或 100x 的币就能翻身
这样的单次相对值其实没有意义，比如：
1. 运气好整体资产翻了百倍，是否满足（绝对值是否足够） ？如果不满足，大概率继续碰运气然后亏回去（大数定律），没有翻身
2. 运气好一笔交易翻了百倍，但买的不够多，整体资产没有显著变化（没有翻身），继续投入更多资金做同类交易，大概率不但没再次翻百倍反而亏掉大部分可用本金（散户牛市亏钱的常见模式）
3. 运气好整体资产翻了百倍，很满足，但之后现金流支出大幅提高（「赚钱就是为了享受」），资产下降很快，现金流很快就不可持续了（没有翻身）
要真正定义「翻身」，需要明确几个绝对值和几个可重复的相对值：
1. 先搞清楚，每年需要多少绝对值的消费支出，才能让自己满足。为了让现金流能长期可持续的负担这个支出水平，每年需要达到相同绝对值的收入水平
2. 这个收入要求里，有多少能来自资产收益（投资收益 / 被动收入）之外的、长期可持续的收入来源。比如：愿意一直给大厂打工拿高薪，愿意做远程工作，愿意做自由职业（外包），愿意跑外卖开网约车，等等
3. 剩余的收入缺口（如果完全不想工作，缺口可能是 100%），全部要靠每年的投资收益来填补。在「一年」这个尺度下能做到低波动的投资组合（波动高了意味着你不能随时取出收益支撑现金流），年化收益可以是 3%、4%、6%、8%、10%、12%。计算出这些收益率分别需要多少本金才能每年都产出足以填补缺口的投资收益
4. 这些年化收益水平，对应的风险偏好、资产组合中不同资产类别的比例都不一样， 看哪个适合自己（自己有能力实现哪种收益水平）
5. 根据自己选择的收益率，确定本金需求，得到自己现有本金跟这个本金目标的差额
6. 明确自己希望多久「翻身」？10 年？5 年？3 年？1 年？
7. 想清楚，在这段时间里，自己的消费支出能尽可能压缩、控制到什么最小程度，自己的工作收入能尽可能优化、维持在什么最大程度
8. 由此得出在这段「翻身时长」内，总共的工作收入盈余。从之前算出的本金差额里，减掉这笔盈余
9. 现在有了真正的本金差额，又有了翻身时长，就能算出在这段时长内，计入复利，每年需要多少的投资收益率，才能补齐这个差额，让你的本金达到目标水平
10. 想办法实现这个「翻身前收益率」要求，如果实现不了，可以改变前面提到的其他变量/参数：
- 翻身时长
- 翻身前的消费水平
- 翻身前的工作收入水平
- 翻身后填补收入缺口需要的收益率
- 翻身后的其他收入水平
- 翻身后的支出水平
这一整套下来，才能真正搞清楚怎样才算「翻身」、自己如何「翻身」
有人说，我希望明天就能翻身
没问题，总共就这么几个参数，你把翻身时长设这么短，就要大幅优化其他参数才能实现，比如把翻身后的支出水平定的非常非常低（最近在油管看了一个纪录片讲独自住在西伯利亚森林木屋里的老人，每天大部分时间砍柴取暖，很少进村购物，现金需求极少），比如找人包养，大幅增加翻身后的其他收入，从而减少对翻身后本金和收益率的要求。能做到这些，相信你明天一定能翻身
让 ChatGPT 和 Gemini 给这个翻身指南画了三张示意图
经常有人说，做 XXX（比如炒币）感觉不会再有翻身的机会了
这里的重点其实不是 XXX 能否翻身，而是怎么定义翻身
很多人会说：买到一个 10x 或 100x 的币就能翻身
这样的单次相对值其实没有意义，比如：
1. 运气好整体资产翻了百倍，是否满足（绝对值是否足够） ？如果不满足，大概率继续碰运气然后亏回去（大数定律），没有翻身
2. 运气好一笔交易翻了百倍，但买的不够多，整体资产没有显著变化（没有翻身），继续投入更多资金做同类交易，大概率不但没再次翻百倍反而亏掉大部分可用本金（散户牛市亏钱的常见模式）
3. 运气好整体资产翻了百倍，很满足，但之后现金流支出大幅提高（「赚钱就是为了享受」），资产下降很快，现金流很快就不可持续了（没有翻身）
要真正定义「翻身」，需要明确几个绝对值和几个可重复的相对值：
1. 先搞清楚，每年需要多少绝对值的消费支出，才能让自己满足。为了让现金流能长期可持续的负担这个支出水平，每年需要达到相同绝对值的收入水平
2. 这个收入要求里，有多少能来自资产收益（投资收益 / 被动收入）之外的、长期可持续的收入来源。比如：愿意一直给大厂打工拿高薪，愿意做远程工作，愿意做自由职业（外包），愿意跑外卖开网约车，等等
3. 剩余的收入缺口（如果完全不想工作，缺口可能是 100%），全部要靠每年的投资收益来填补。在「一年」这个尺度下能做到低波动的投资组合（波动高了意味着你不能随时取出收益支撑现金流），年化收益可以是 3%、4%、6%、8%、10%、12%。计算出这些收益率分别需要多少本金才能每年都产出足以填补缺口的投资收益
4. 这些年化收益水平，对应的风险偏好、资产组合中不同资产类别的比例都不一样， 看哪个适合自己（自己有能力实现哪种收益水平）
5. 根据自己选择的收益率，确定本金需求，得到自己现有本金跟这个本金目标的差额
6. 明确自己希望多久「翻身」？10 年？5 年？3 年？1 年？
7. 想清楚，在这段时间里，自己的消费支出能尽可能压缩、控制到什么最小程度，自己的工作收入能尽可能优化、维持在什么最大程度
8. 由此得出在这段「翻身时长」内，总共的工作收入盈余。从之前算出的本金差额里，减掉这笔盈余
9. 现在有了真正的本金差额，又有了翻身时长，就能算出在这段时长内，计入复利，每年需要多少的投资收益率，才能补齐这个差额，让你的本金达到目标水平
10. 想办法实现这个「翻身前收益率」要求，如果实现不了，可以改变前面提到的其他变量/参数：
- 翻身时长
- 翻身前的消费水平
- 翻身前的工作收入水平
- 翻身后填补收入缺口需要的收益率
- 翻身后的其他收入水平
- 翻身后的支出水平
这一整套下来，才能真正搞清楚怎样才算「翻身」、自己如何「翻身」
有人说，我希望明天就能翻身
没问题，总共就这么几个参数，你把翻身时长设这么短，就要大幅优化其他参数才能实现，比如把翻身后的支出水平定的非常非常低（最近在油管看了一个纪录片讲独自住在西伯利亚森林木屋里的老人，每天大部分时间砍柴取暖，很少进村购物，现金需求极少），比如找人包养，大幅增加翻身后的其他收入，从而减少对翻身后本金和收益率的要求。能做到这些，相信你明天一定能翻身
让 ChatGPT 和 Gemini 给这个翻身指南画了三张示意图
1 00