AI Agent 的最后一公里：为什么登录态才是真正的圣杯

开头：一个让人牙痒的痛点

你让 AI Agent 帮你订机票。它说："好的，请先登录航空公司官网。"

你让 AI Agent 帮你发公众号。它说："好的，请提供账号密码，我帮你用 Playwright 登录。"

你让 AI Agent 帮你查银行流水。它说："抱歉，我无法访问需要登录的页面。"

AI 已经很聪明了，但它像个没带身份证的游客——每个需要身份验证的门口，它都被拦下来。

这就是今天所有 AI Agent 的死穴：没有登录态。

转折：发现 Kimi WebBridge

上周我在研究 Kimi 的新产品 WebBridge，一个让 AI Agent 直接控制你浏览器、带上真实登录态的工具。

我花了半天时间读完整套文档，越读越兴奋——这不就是我一直想做的事吗？

简单说 WebBridge 是什么：

• 一个 Chrome 扩展 + 本地桥接服务
• AI Agent 发指令 → 本地服务接收 → 通过 CDP 控制浏览器
• 最关键：直接用你浏览器里已登录的 cookie，不需要配 API Token

我立马想：这个功能，WorkBuddy 能不能做？

核心洞察：登录态才是 AI Agent 的圣杯

为什么说登录态是圣杯？因为：

1. 99% 的有价值操作都需要登录

订机票、发文章、查数据、审批流程... 所有真正有用的场景，都在登录墙后面。

没有登录态的 AI Agent，就像给了你一辆法拉利，但不让你上高速公路。

2. 模拟登录是脆弱的

你可以说："那让 AI 用 Playwright 模拟登录不就行了？"

不行，原因有三个：

• 验证码：现在登录基本都有滑块、拼图、短信验证
• 风控：异地登录、设备指纹、行为分析，AI 一登录就被封
• MFA：双重验证你总不能让 AI 去拿你手机看验证码吧？

唯一可靠的方案：用用户已经登录的浏览器。

3. 登录态 = 信任 = 权限

登录态背后是信任。你登录了某个网站，意味着你授权它代表你操作。

AI Agent 要获得这种授权，最自然的方式就是：用它，而不是代替它。

我们的方案：CDP Attach，不依赖任何第三方

读完 WebBridge 文档，我决定自己实现一个类似的能力。

核心思路很简单：

1. Chrome 启动时候加 --remote-debugging-port=9222
2. Playwright 用 chromium.connectOverCDP('http://localhost:9222') 连接
3. 获得完整浏览器控制能力

我花了一下午时间验证这个方案，结论是：完全可行。

测试结果

最关键的是：用真实 Chrome profile 启动，所有登录态完整保留。

结尾：这不只是技术

做完这个技术验证，我意识到一件事：

AI Agent + 登录态，不只是技术问题，这是对"AI 真正融入工作流"的重新思考。

今天的 AI 工具（ChatGPT、Claude、Kimi）都是"外部顾问"模式：你去问它，它告诉你答案，然后你自己去执行。

明天的 AI 工具应该是"数字同事"模式：你告诉它目标，它直接帮你完成，包括所有需要登录的操作。

从这个角度看，登录态是 AI 从"顾问"升级为"同事"的必经之路。

WebBridge 走出了第一步。我们也要跟上。

本文是阿优科技团队在研发 WorkBuddy（AI 工作助手）过程中的技术思考。欢迎交流。