即刻App年轻人的同好社区
下载
置顶不搞抽象了，和各位解释下产品
关于登上 GitHub Trending 的这个项目 ego（lite），是一个同时友好于人类用户和 Agent 的浏览器，是我们更完整产品 ego （或许可以叫os？）中的一个组件，不同于其他内置 Agent 的 AI 浏览器，ego（lite）没有内置的 Agent，而是被其他 Agent 操控，作为他们的眼睛和手脚。
所以，坦白说，它不适合所有人，使用它，或者说觉得它好用的先决条件是：你已经在高频让 Codex、Pi、Claude Code 等 Agent 产品去控制浏览器完成各种任务。
如果满足这个先决条件，那么你会体会到相对于 Chrome 桥接方案，它丝滑稳定，不抢占你的注意力；相对于 Codex 等 Electron 客户端内置的浏览器它更不容易触发__，Web 能力更健全；以及相对于以上所有方案，它都更快更省 token。具体实现思路可以看我前面发的博客链接。
如果不满足这个先决条件，你大概率会觉得这款产品有些莫名其妙。在这先向你报歉，或许可以等等我们的更完整产品。
【图1】ego（lite）的目标用户，图中的第四类
【图2】ego（lite）的留存，因为我们主要在面向第四类用户做增长，放留存主要是想说明我们确实在被四类用户高频的使用（前期的日新增绝对值不高，所以留存比例会有跳变，不影响看整体趋势）
关于登上 GitHub Trending 的这个项目 ego（lite），是一个同时友好于人类用户和 Agent 的浏览器，是我们更完整产品 ego （或许可以叫os？）中的一个组件，不同于其他内置 Agent 的 AI 浏览器，ego（lite）没有内置的 Agent，而是被其他 Agent 操控，作为他们的眼睛和手脚。
所以，坦白说，它不适合所有人，使用它，或者说觉得它好用的先决条件是：你已经在高频让 Codex、Pi、Claude Code 等 Agent 产品去控制浏览器完成各种任务。
如果满足这个先决条件，那么你会体会到相对于 Chrome 桥接方案，它丝滑稳定，不抢占你的注意力；相对于 Codex 等 Electron 客户端内置的浏览器它更不容易触发__，Web 能力更健全；以及相对于以上所有方案，它都更快更省 token。具体实现思路可以看我前面发的博客链接。
如果不满足这个先决条件，你大概率会觉得这款产品有些莫名其妙。在这先向你报歉，或许可以等等我们的更完整产品。
【图1】ego（lite）的目标用户，图中的第四类
【图2】ego（lite）的留存，因为我们主要在面向第四类用户做增长，放留存主要是想说明我们确实在被四类用户高频的使用（前期的日新增绝对值不高，所以留存比例会有跳变，不影响看整体趋势）
117 2860
同事问我对 Jev 在 Broswer use 领域的应用有什么看法？
答（一些比较初步的感受，不代表未来观点不会变）：
Jev 我理解是以输出通用且有限的分类为目标所训练与架构的，在类似任务下相对自回归生成结构化文本的 LLM 有很大速度优势。
目前看起来有几个限制：
第一，每次调用前需要准备好候选选项，虽然可以动态生成，但候选难以枚举或者数量太多时，就需要额外处理，常规的文本生成更不是它的适用范围；
第二，分类不是百分之百准确的，和 LLM 一样，也受限于模型规模、训练质量等影响；
所以具体到 Broswer use 这样的通用任务，我觉得还是要讨论讨论。
具体可以从两个维度分析：单次动作的可选范围，以及单次动作的推理难度。
从可选范围来看，一个页面的可交互元素，乘以每个元素的可交互方式，比如点击、输入、拖拽等，如果全部平铺，很容易把选项撑爆。Jev 目前单个 Choice 最多支持 255 个选项。把操作和目标拆开可以缓解，但某一类操作的目标仍然可能太多。
从推理难度来看，浏览器任务里有大量操作，单步推理难度是不高的。Jev 更适合的 System 1 任务，我凭感觉可能占很大比例，大多数情况下应该超过 90%。
举个例子，在网页上购物，商品、金额等都已经确认，走到结算这一步，页面上有个支付按钮，需要点它，确实就只是 System 1 难度的动作。
但换个例子，页面上有一道复杂的数学选择题，只有三个选项。这时候选谁，就无法离开 System 2 进行推理。选项少，不代表问题简单。
当然，Jev 分类这种输出形式本身不意味着没有推理能力。但 Jev 官方确实列出了多跳推理、精确数值处理等弱项。考虑到浏览器是一个通用容器，需要调动 System 2 能力的任务一定是无法避免的。
那么，选项撑爆和 System 2 介入这两个问题要如何解决？
选项撑爆
可以通过工程手段把候选分页，留出“下一页”“上一页”；也可以逐级选择，比如先选页面区域，再下钻到具体元素，最后选择操作。还可以先给候选打分，筛选后再做最终选择。这些方式可以配合使用。
System 2 介入
可以给模型一个类似“不确定”的选项，或者根据概率和置信度，让 LLM 接管。理论可行，但可靠性需要验证
另外，动作拆分的粒度也很重要。如果把鼠标操作拆成方向加步长，靠多轮交互逐步修正，点一个按钮可能要来回很多轮，不一定比 LLM 更快。
公司里应该有部分同事，包括我，是从上一个时代的 AI 公司过来的。我们当时做的很多工作，核心就是训练模型做分类，所谓的模式识别。
因此上面列出这些问题，大都在上一代模型和系统里就有一些解决思路，总体上就是先缩小候选范围，再逐级细分。我个人其实觉得这些方案并不优雅，因为分组、筛选、纠错、升级的复杂度最后还是落到了外围工程上。
相较于传统分类模型，Jev 当然有巨大进步，可以理解自然语言描述，处理运行时定义的候选，还能并行回答多个问题。但在具体任务上的表现，是否能追平专门为该任务训练的分类模型，我持怀疑态度。对于方向加步长这样的低层控制任务，我也没有看到足够的公开评测来证明它的泛化表现。
具体到 Broswer use，如果既要维护分类模型的候选空间，又要编排它和 LLM 的分工，处理不确定性、模型切换和失败恢复，这种组合，在我看来，似乎不如直接用一个速度很快的 LLM 来得优雅。
当然，架构是否优雅不优先于实际业务表现。多模型组合省下的推理时间，能不能覆盖候选处理、额外轮次和模型切换的开销，最终还是要看任务成功率、总延迟和总成本。
答（一些比较初步的感受，不代表未来观点不会变）：
Jev 我理解是以输出通用且有限的分类为目标所训练与架构的，在类似任务下相对自回归生成结构化文本的 LLM 有很大速度优势。
目前看起来有几个限制：
第一，每次调用前需要准备好候选选项，虽然可以动态生成，但候选难以枚举或者数量太多时，就需要额外处理，常规的文本生成更不是它的适用范围；
第二，分类不是百分之百准确的，和 LLM 一样，也受限于模型规模、训练质量等影响；
所以具体到 Broswer use 这样的通用任务，我觉得还是要讨论讨论。
具体可以从两个维度分析：单次动作的可选范围，以及单次动作的推理难度。
从可选范围来看，一个页面的可交互元素，乘以每个元素的可交互方式，比如点击、输入、拖拽等，如果全部平铺，很容易把选项撑爆。Jev 目前单个 Choice 最多支持 255 个选项。把操作和目标拆开可以缓解，但某一类操作的目标仍然可能太多。
从推理难度来看，浏览器任务里有大量操作，单步推理难度是不高的。Jev 更适合的 System 1 任务，我凭感觉可能占很大比例，大多数情况下应该超过 90%。
举个例子，在网页上购物，商品、金额等都已经确认，走到结算这一步，页面上有个支付按钮，需要点它，确实就只是 System 1 难度的动作。
但换个例子，页面上有一道复杂的数学选择题，只有三个选项。这时候选谁，就无法离开 System 2 进行推理。选项少，不代表问题简单。
当然，Jev 分类这种输出形式本身不意味着没有推理能力。但 Jev 官方确实列出了多跳推理、精确数值处理等弱项。考虑到浏览器是一个通用容器，需要调动 System 2 能力的任务一定是无法避免的。
那么，选项撑爆和 System 2 介入这两个问题要如何解决？
选项撑爆
可以通过工程手段把候选分页，留出“下一页”“上一页”；也可以逐级选择，比如先选页面区域，再下钻到具体元素，最后选择操作。还可以先给候选打分，筛选后再做最终选择。这些方式可以配合使用。
System 2 介入
可以给模型一个类似“不确定”的选项，或者根据概率和置信度，让 LLM 接管。理论可行，但可靠性需要验证
另外，动作拆分的粒度也很重要。如果把鼠标操作拆成方向加步长，靠多轮交互逐步修正，点一个按钮可能要来回很多轮，不一定比 LLM 更快。
公司里应该有部分同事，包括我，是从上一个时代的 AI 公司过来的。我们当时做的很多工作，核心就是训练模型做分类，所谓的模式识别。
因此上面列出这些问题，大都在上一代模型和系统里就有一些解决思路，总体上就是先缩小候选范围，再逐级细分。我个人其实觉得这些方案并不优雅，因为分组、筛选、纠错、升级的复杂度最后还是落到了外围工程上。
相较于传统分类模型，Jev 当然有巨大进步，可以理解自然语言描述，处理运行时定义的候选，还能并行回答多个问题。但在具体任务上的表现，是否能追平专门为该任务训练的分类模型，我持怀疑态度。对于方向加步长这样的低层控制任务，我也没有看到足够的公开评测来证明它的泛化表现。
具体到 Broswer use，如果既要维护分类模型的候选空间，又要编排它和 LLM 的分工，处理不确定性、模型切换和失败恢复，这种组合，在我看来，似乎不如直接用一个速度很快的 LLM 来得优雅。
当然，架构是否优雅不优先于实际业务表现。多模型组合省下的推理时间，能不能覆盖候选处理、额外轮次和模型切换的开销，最终还是要看任务成功率、总延迟和总成本。
123 1449
最清楚的放在前面：不是拿个开源模型做做续训，就叫 NeoLab。
然后讨论应用公司训模型，目标无非两个：效果和成本。
但除了这两个，讨论还需要加一个维度：通用或垂直。
很多垂类应用，产品价值本来就在模型效果上，比如 Midjourney，不管传统意义的产品层做得多难用，始终有一批忠实用户愿意为效果买单。这类应用公司训模型，没任何问题。
再来看通用型应用，各种个人 Agent、办公 Agent，在用户量够大、token 消耗够高的情况下，基于开源模型做续训来保效果降成本，也没问题，比如最近在传的 Manus 。
但现在的问题是，一批没用户、没留存的通用型应用公司（并且遗憾的是去年底到今年初成立的应用层公司大都还处于这个阶段），忽然跳出来说要训模型，要做 NeoLab。
是，当前 SOTA 模型确实因为对 Coding 场景做了太多 RL，在很多任务表现上多少有点奇怪。但无论如何，如果你的通用型应用基于今天 SOTA 模型找不到一点 PMF，你说是模型不行，所以我要自己训个更好的。
我想，咱要不要看看自己在讲什么，都能训出比今天 SOTA 模型在通用场景下更牛逼的模型了，是不是一开始就去训模型得了，何必在前几轮苦哈哈的讲什么应用故事
然后讨论应用公司训模型，目标无非两个：效果和成本。
但除了这两个，讨论还需要加一个维度：通用或垂直。
很多垂类应用，产品价值本来就在模型效果上，比如 Midjourney，不管传统意义的产品层做得多难用，始终有一批忠实用户愿意为效果买单。这类应用公司训模型，没任何问题。
再来看通用型应用，各种个人 Agent、办公 Agent，在用户量够大、token 消耗够高的情况下，基于开源模型做续训来保效果降成本，也没问题，比如最近在传的 Manus 。
但现在的问题是，一批没用户、没留存的通用型应用公司（并且遗憾的是去年底到今年初成立的应用层公司大都还处于这个阶段），忽然跳出来说要训模型，要做 NeoLab。
是，当前 SOTA 模型确实因为对 Coding 场景做了太多 RL，在很多任务表现上多少有点奇怪。但无论如何，如果你的通用型应用基于今天 SOTA 模型找不到一点 PMF，你说是模型不行，所以我要自己训个更好的。
我想，咱要不要看看自己在讲什么，都能训出比今天 SOTA 模型在通用场景下更牛逼的模型了，是不是一开始就去训模型得了，何必在前几轮苦哈哈的讲什么应用故事
敖特_Aute: 我要对此大放厥词了
59 1024
Wake me up when September //@Danielw: Win版本有眉目了吗
敖特_Aute: 遇到任何问题欢迎随时反馈。另外，下个重要版本这周会内测，有兴趣可以私我加入内测群，该版本面向人的交互和 UI 基本没变化，但面向Agent 的速度和成功率进一步提升，同时内存占用和 token 消耗会明显下降
6 00
遇到任何问题欢迎随时反馈。另外，下个重要版本这周会内测，有兴趣可以私我加入内测群，该版本面向人的交互和 UI 基本没变化，但面向Agent 的速度和成功率进一步提升，同时内存占用和 token 消耗会明显下降
西西弗森: ego lite真好用，可以并行操作浏览器
20 152
45 123
