即刻App年轻人的同好社区
下载
周六周日在字节上海工区旁边（漕河泾会议中心）的Apple生态大会里有WebSpatial的展台，可以现场用visionOS设备体验WebSpatial应用，周日上午可以选择参加两小时的WebSpatial工作坊活动现场用coding agent折腾空间Web应用的可能性，也可以到空间计算主会场听我讲解下
活动官网：letsvision.swiftgg.team
活动行页面：hdxu.cn
以下优惠码先到先得，看有没有能用的
99 元门票兑换码（10 张）：mFtCavyW，ByBGVkHA，gEkUz2Sm，hLcexc5Z，9Ucn52pw，vs94jc6d，4YWSAyz6，muV6peHv。hZQa7hkp，kfmdRQYk
699 元门票兑换码（3 张）：33DBTUSZ，7LAzRUWU，e4BCZnRQ
活动官网：letsvision.swiftgg.team
活动行页面：hdxu.cn
以下优惠码先到先得，看有没有能用的
99 元门票兑换码（10 张）：mFtCavyW，ByBGVkHA，gEkUz2Sm，hLcexc5Z，9Ucn52pw，vs94jc6d，4YWSAyz6，muV6peHv。hZQa7hkp，kfmdRQYk
699 元门票兑换码（3 张）：33DBTUSZ，7LAzRUWU，e4BCZnRQ
9 11
不是「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
