Argos

一句话定位

住在浏览器里的 AI 代理，用你自己已登录的账号替你点击、填表、跑完任务， 不是"给你答案"而是"替你做完"；还能通过 Telegram/WhatsApp 远程指挥， Pro 版附带带 shell 权限的桌面 CLI。

做这个东西的人

Argos（前身 Lyto AI）由 Arystan Tanekov（联合创始人兼 CEO，17 岁，埃因霍温理工大学在读） 与 Gleb Babichev（联合创始人兼 CTO）等共 3 人团队于 2024 年创立，荷兰埃因霍温。 2026-03 从 Lyto AI 更名为 Argos（2.0 大版本），2026-07 发布桌面 CLI。 Chrome 扩展仍在以 "Lyto AI" 名上架，目前 128 用户、11 条评分，Google 提示开发者未完成验证。 开发者公开邮箱为个人 Gmail（gleb.babichev007@gmail.com）。

判断：3 人团队、创始人是 17 岁大学生、Google 未验证、128 用户、改名痕迹还在—— 这更像一个年轻团队认真做的早期产品，而不是有资源背书的项目。它的热度来源是 PH 当天表现（118 upvotes、日榜 #10），不是用户量。

它到底能做哪几件事

• 真实操作浏览器 → 用已登录账号点击、滚动、填表、整理标签页，跑真实任务
• 原生集成 Google 系 → Gmail 写邮件、Docs 写文档、Sheets 生成带图表的表格
• 多入口指挥 → 侧边栏提问，或通过 Telegram / WhatsApp 发指令（Pro），后台运行后把结果送回来
• 桌面 CLI（Pro） → 带 shell 访问和真实浏览器 profile，能从当前标签页扩展到本地文件和桌面应用
• 安全设计 → 自称数据留在本机；破坏性操作（发送/提交前）先停下来问
• 防"假成功" → 作者在评论区回应了浏览器 agent 的经典失败模式： 执行前重新定位元素、验证动作的真实后果（字段值变化/网络请求发出）而不是只信事件触发、 等 DOM 稳定再操作

需要打折的承诺："data stays on your device" 有边界——隐私政策写明： 会话历史和使用元数据在账号激活期间会存储；相关提示和页面上下文可能发送给 Gemini、Claude、Perplexity；用户主动开启的 Browser Sessions 可能把指定域名的 cookie 发给服务器做 headless 认证。密码和支付数据明确不读不存。

它在替代什么旧行为

浏览器 agent 替代的是"人肉搬数据"这条最古老的工作流：从一个页面把信息复制到表格、 从聊天记录里把 AI 的答案手工填进表单、跨 5 个标签页做竞品比价然后人整理成简报。

旧方案是两条路。一是 RPA 工具（UiPath 等）：强大但重，要搭建、要服务端， 而且大多走 API 或虚拟机，对"用我自己登录的账号操作"这种场景无能为力。 二是 Zapier 这类自动化：只覆盖有 API 的服务，长尾网页应用覆盖不到。

Argos 替代的是这两条路都留下的空白——在浏览器这一层、用用户自己的身份、 对任何网站直接操作，不需要给每个服务申请 API 授权。它的卖点"用你的账号替你点" 正是绕开所有 API 授权谈判的路径。

商业模式

Free（25 条消息/天，页面操作、集成、记忆、联网搜索）+ Pro（$15/月按年付或 $25/月月付， 3 天试用；400 请求/周、70 请求/天；Telegram/WhatsApp、定时和后台任务、监控、深度研究、 桌面 CLI）+ Team（$120/月，至少 5 用户）。

判断：定价结构清晰、有免费层做漏斗，是标准的消费级订阅模型。但 128 用户的盘子 说明收入还没起来——现在是"产品完整、市场没验证"。

硬数字

• PH：118 upvotes / 9 条评论，日榜 #10（2026-08-09 上线）
• Chrome Web Store：128 用户 / 11 条评分（Lyto AI 2.2.5，2026-08 中旬核查）
• 定价：Free 25 条/天；Pro $15/月（年付）；Team $120/月（5 人起）
• 团队 3 人，2024 年成立，2026-03 更名 Argos，2026-07 发布桌面 CLI
• 收入、付费用户数：未披露

四维评估

判断

这是一个"用你自己的身份干活"的浏览器 agent，方向正确、工程认真，但盘子太小、信任成本太高。

它赌的是浏览器这一层的自动化能绕开 API 授权——这个判断基本成立： 企业内网、长尾 SaaS、需要登录态的场景，界面层操作确实是 API 自动化够不到的空白。

产品逻辑上有个亮点值得记下来：作者在评论区正面回应了浏览器 agent 的经典失败模式 （动作报成功但实际没落地），给出的对策是"执行前重定位元素 + 验证动作后果 + 等 DOM 稳定"。这个细节说明它是被真实使用咬过的产品，不是演示项目。

但它有两个硬伤。 一是信任成本高：要你把已登录账号交给一个 3 人团队做的、 Google 未验证的扩展，且隐私政策显示"数据留在本机"是有边界的（会话历史会上传、 页面上下文会发第三方模型）。这类产品对早期用户的要求是极高的信任， 而它现在的品牌资产撑不起这个要求。二是差异化不足：BrowserUse 一类的开源工具 和各大厂的 computer use 能力都在同一个位置，128 用户撑不起竞争。

可迁移的规律：界面层自动化（用你的身份点你的界面）是"绕开 API 授权"的最短路径， 但它把产品的风险全部转移到了信任端。 做这类产品，信任设计（权限边界、数据声明、 验证透明度）不是加分项，是准入条件。

下一步看什么

① Chrome Web Store 用户量三个月内能否过千——128 的基数太低，起不来就是验证失败 ② Google 是否完成对应用的验证——未验证状态是信任的最大障碍，解决与否是重要信号 ③ Telegram/WhatsApp 远程指挥和桌面 CLI 是否有真实付费用户使用—— 这是 Pro 和免费层的实际分界，能看出有没有人为"远程干活"付费

可借鉴的做法

产品逻辑：做需要用户交出账号权限的产品，先解决信任问题再谈功能。 三个动作可以照搬：破坏性操作（发送/提交）前必停问；执行后验证真实后果而不是信事件触发； 把权限边界写清楚（什么上传、什么不碰），别用"数据留在本机"这类模糊承诺。

定价结构：Free 漏斗（25 条/天够尝鲜）+ Pro 功能分层（远程指挥、定时、桌面 CLI 放付费侧）+ Team 起价，是消费级 agent 工具的可复制结构；值得借鉴的是把 "使用量"和"能力位"分开定价。

结论

值得关注，但处在验证早期。 方向对、工程有细节、团队真实存在， 但 128 用户、Google 未验证、3 人小团队三个事实合在一起，说明它还没赢得信任。 三个月后看用户量是否过千和验证是否完成——这两条过不了，功能再多也没用。