凌晨三点，服务器报警响起。你的AI代理需要立刻拉取客户后台的最新订单数据，但它面前是一道Auth 2.0授权页——你需要人工点“允许”，而代理既没有浏览器，也等不到天亮。藏一把永不过期的API密钥、用无头浏览器硬闯登录页面，或者摆个二维码等人扫，这三种方案像用胶带糊墙：能顶一阵，但身份、审计、权限隔离一样都缺。

直接塞给worker一个静态API key（`os.environ["CUSTOMER_DASHBOARD_API_KEY"]`）是最常见的首版方案。只要把Bearer令牌焊死在请求头里，代理就能绕过所有交互环节。问题从第一次密钥轮换开始暴露：不同客户需要独立存取范围时，你不得不维护一套脆弱的映射表；哪天某个worker被攻破，凭据泄露就等同交出上帝权限。审计日志里只留下一串请求IP，没人能说清“是哪个代理干了这件事”。

更“硬核”的做法是用Playwright启动无头Chrome模拟真人登录。打开授权页，填邮箱、输密码、点提交，然后在回调地址里抠出Cookie或localStorage里的令牌。可这套流程活在脆弱的假设上：登录界面的一次CSS重命名、一次A/B测试、一组MFA验证码，或者第三方突然弹出的CAPTCHA，都能让脚本直接崩在夜里。维护成本高不说，还时常踩中客户服务条款的红线。

LIME方案试图绕开所有绕不开的短板。代理只需传入一个登录请求ID（`request_id`），并携带自身代理令牌（`LIME_AGENT_TOKEN`）发起一次调用即可。站点后端走SSE通道接收一份加密护照，用JWKS验签后，向代理返回“已批准”。全程代理不碰用户实际会话的JWT，也无需处理OAuth重定向、权限确认页或二维码扫描。

这背后是把“人不在场”和“无认证”拆成了两件事。零人工认证（Zero Human Auth）不是跳过身份校验，而是把人类从实时登录链路中移除。关键变成了一张可审计、绑定到具体站点会话的加密护照，带来一个直接好处：MCP工具服务器同样可以沿用这套机制。当代理需要以标准Authorization Bearer语义调用外部MCP资源服务器时，站点收到的依旧是已验证的代理身份声明，而非一把裸奔的万能钥匙。