在真实浏览器任务中测试AI代理后，我认为炒作超前于基础设施

在过去的几周里，我一直在尝试让Claude Code / Codex风格的代理处理真实的网页任务。不是玩具演示。而是人们最终希望代理完成的实际无聊任务：* 从X账号抓取近期主帖，排除转发/回复/置顶帖，然后按浏览量和互动排序 * 在LinkedIn上搜索远程全职代理开发者职位，打开公司招聘页面，上传简历，填写表格，在提交前停止 * 搜索Redfin房源，应用筛选条件，打开一个房产，更改抵押贷款计算器，提取估算月供 * 搜索Expedia航班，筛选直飞，选择有效航空公司，填写乘客信息，在支付前停止 曾有一刻，AI Twitter让我相信这些事基本上已经解决了。每个人都在发帖：“我的代理帮我预订一切”“我的代理在我睡觉时帮我申请工作”“我的代理能使用任何网站”“浏览器现在只是另一个工具” 所以我想超越简单的浏览。但现实呢？这些代理仍然：\> 丢失标签页 \> 在登录页面出错 \> 被动态UI搞糊涂 \> 将多步骤流程变成无尽的点击/观察循环 \> 当出现弹窗、重定向或过时的截图时失败 而且老实说，这开始**让人觉得我们把问题归咎于模型**，而问题其实来自浏览器层。Claude Code和Codex在代码库中已经相当有用。但网页不同。网站是有状态的、需要登录的、异步的、可视化的，并且充满了奇怪的边缘情况。当前的浏览器是为一个人、一个光标、一个活动标签页设计的，而不是为并行运行任务的代理设计的。 这让我意识到一个重要的事情：**AI代理不仅需要更好的推理能力**。**它们需要更好的浏览器环境。** 在我看来，有趣的方向不是“在Chrome里放一个聊天机器人”。而是给代理它们自己的浏览器运行时：隔离的空间、持久的登录会话、并行执行以及代码级别的编排，而不是脆弱的点击/输入/截图命令。 这也让我对这个领域的一些较新项目更感兴趣了。==ego lite似乎是将浏览器视为代理的基础设施，而不是人类的用户界面。这是否是正确的做法还有待观察，但它感觉比简单地添加更强的模型更接近解决可靠性问题。