为什么这篇值得先看
网页登录任务最容易让人误判。你以为难点是“让 Agent 输入用户名密码”，实际难点是：网站不希望自动化登录，账号也不应该把凭证交给模型。
官方 Browser Login 文档的态度很明确：遇到需要登录的网站，推荐在主机浏览器配置文件里手动登录；不要把凭证交给模型。这个建议不是体验上的妥协，而是稳定性和安全性的底线。
这篇专门处理一个搜索意图：当你用 OpenClaw Browser 撞上登录墙、验证码、2FA、已有 session、社交平台或 SaaS 后台时，到底怎么设计流程。
先抓住这 3 个关键点
- 登录不是一个适合黑箱自动化的步骤；账号、密码、2FA 和验证码应该由人处理。
openclaw隔离 profile 和userexisting-session profile 是两种不同工作方式，不要混着用。- 成熟的网页登录流一定有暂停点：遇到登录墙、风控、权限变更和不可逆动作时，Agent 应该停下来说明需要人工操作。
一句话记住：网页登录自动化不是把人移除，而是把人放在最该出现的位置。
推荐流程：手动登录 + Agent 继续
最稳的网页登录流不是“自动登录”，而是下面这条路径：
- Agent 打开目标页面，判断是否已经登录。
- 如果出现登录墙，Agent 明确报告需要人工登录。
- 用户在浏览器里手动完成账号、密码、2FA、验证码或 SSO。
- 登录完成后，Agent 重新获取页面快照，确认进入目标区域。
- Agent 继续执行低风险、可验证、可回滚的页面步骤。
- 一旦出现发布、删除、付款、授权、导出等敏感动作，重新交给人工或审批。
这个流程看似多一步，其实比自动输入密码更快。反机器人保护、设备信任、验证码和登录异常处理，本来就更适合人来完成。
openclaw 和 user 怎么选
先看这个判断表：
| 任务情况 | 推荐 profile | 原因 |
|---|---|---|
| 公开页面、文档页、搜索页 | openclaw | 隔离、干净、风险低 |
| 测试账号后台 | openclaw | 可单独手动登录，不污染个人浏览器 |
| 已有 Chrome 登录态必须复用 | user 或 existing-session | 任务依赖你的真实会话 |
| 多个工作浏览器配置文件 | 显式命名的 custom profile | 避免 Agent 猜错账号 |
| 远程浏览器或托管 CDP | remote profile | 需要额外处理 token、网络和私网边界 |
如果你不确定，就先用 openclaw。只有当“没有现有 session 就无法完成任务”时，才升级到 user。
登录墙处理清单
遇到登录墙时，不要急着让 Agent 继续点。先问 5 个问题：
- 这个网站是否允许自动化访问，是否有账号使用条款限制？
- 是否可以使用测试账号，而不是个人主账号或生产管理员账号？
- 登录是否需要 2FA、验证码、Passkey、设备确认或 SSO？
- 登录后要做的是只读任务，还是会写入、发布、删除或付款？
- 登录完成后，如何判断任务真正成功，而不是只是进了首页？
只有这些问题有答案，网页登录任务才适合继续。
验证码和 2FA 怎么处理
验证码和 2FA 不是“工具失败”，而是系统在提醒你进入人机协作。
推荐做法：
- Agent 看到验证码、短信码、邮箱码、Passkey、扫码登录或安全问题时，立即停下。
- Agent 用短句说明当前页面需要人工验证，不猜测、不绕过。
- 用户完成验证后，Agent 重新获取页面快照。
- Agent 检查 URL、页面标题、关键元素或预期数据，确认真的进入目标状态。
- 如果验证反复失败，终止任务并记录原因，不要循环重试。
反复重试验证码通常只会让账号进入更严格的风控。成熟流程的目标不是“永远自动完成”，而是“该停的时候停得及时”。
已有 session 的边界
使用已有 Chrome session 很方便，但它会把 Agent 放到更接近真实账号的位置。建议设置这些规则：
- 只在用户在电脑前时使用
user或 existing-session profile。 - 不允许 Agent 自己切换账号、创建新会话或保存新密码。
- 高权限后台优先用低权限账号，避免管理员账号直接暴露给自动化流程。
- 如果浏览器提示连接、扩展、权限或设备确认，由人决定是否批准。
- 每次任务结束后，记录使用了哪个 profile、哪个账号范围和哪些页面。
如果你准备把这个流程交给 cron 或 webhook 周期运行，先问一句：这个任务离开人以后还安全吗？如果答案不明确，就不要后台化。
示例：检查 SaaS 后台工单
一个可执行的网页登录流可以这样写：
任务：检查 SaaS 后台今天是否有 P0 工单。
Profile:
- 默认使用 openclaw。
- 如果出现 SSO 登录墙，等待人工登录。
Agent 允许做：
- 打开指定 URL。
- 读取筛选后的工单数量。
- 截图关键状态。
- 汇总标题、严重级别和创建时间。
Agent 必须停止：
- 修改工单状态。
- 指派人员。
- 导出客户数据。
- 进入账单、成员、权限页面。
成功标准：
- 页面处于已登录状态。
- 日期筛选为今天。
- P0 工单数量、列表和截图可核验。这比一句“登录后台帮我看看工单”更可靠。Agent 需要的不是更多自由，而是更清楚的边界。
示例：社交平台发布前检查
社交平台更容易触发风控，所以不要设计成完全自动发布。推荐流程：
- 人先在主机浏览器里完成登录。
- Agent 打开草稿页或发布页。
- Agent 检查文案、链接、图片预览、可见范围。
- 如果需要发布，Agent 停在最终确认前。
- 人点击发布，或通过审批流程确认后再继续。
这类任务适合“检查和准备”，不适合默认“最终提交”。尤其是 X/Twitter、LinkedIn、广告后台、邮件群发系统，都应该把最后一步留给人。
和 Dashboard / Control UI 怎么配合
网页登录任务一旦涉及高风险动作，就应该接到审批：
| 场景 | 建议 |
|---|---|
| 只读检查 | Browser 可直接执行，保留截图或摘要 |
| 测试环境写入 | 可执行，但记录环境和账号 |
| 生产后台修改 | 进入 Dashboard / Control UI 审批 |
| 客户数据导出 | 默认人工确认，必要时双人复核 |
| 公开发布 | Agent 准备草稿，人做最终确认 |
审批不是为了降低效率，而是为了让可逆和不可逆动作分开。网页登录任务一旦跑进真实系统，少一个确认点就可能多一个事故点。
常见坑
- 把密码写进 prompt、配置文件或截图说明里。
- 让 Agent 反复尝试验证码，导致账号被限制。
- 用生产管理员账号测试 Browser 能力。
- 没有区分“登录成功”和“任务成功”。
- 让后台任务使用
usersession，但运行时根本没有人在场。 - 最终提交、发布、删除、付款没有人工确认。
- 使用多个浏览器 profile，却没有显式指定账号环境。
排错顺序
网页登录流程卡住时，按这个顺序判断：
- 是否真的需要登录：目标页面是否可以用公开或测试环境替代。
- profile 是否正确：
openclaw没有你的个人登录态，user才可能接入已有 session。 - 是否需要人工动作：验证码、2FA、SSO、Passkey 都不应该让模型猜。
- 登录后是否到达目标页：看 URL、标题、关键元素和预期数据。
- 动作是否过高风险：如果到了发布、删除、付款这类页面，停止并审批。
- 是否适合自动化：如果每次都强风控，可能这个任务只适合半自动。
完成检查
- 你的网页登录流程已经明确“谁登录、用哪个 profile、何时暂停”。
- Agent 不会接触账号密码、2FA code 或验证码答案。
- 登录成功和任务成功分别有可验证标准。
- 敏感动作有 Dashboard / Control UI 审批或人工确认。
- 你已经知道哪些任务可以后台化，哪些只能人机协作。
下一步
- 还没理解 Browser profile 和远程 CDP 的，先回看 OpenClaw Browser 工具。
- 需要把敏感动作接进审批的，继续看 OpenClaw 审批流实战。
- 需要把只读检查变成定时任务的，再看 OpenClaw 自动化入门。
为什么建议把这篇收藏起来
- 登录墙、验证码和已有 session 是 Browser 真实使用里最常见的卡点。
- 这篇给你的不是“绕过登录”的技巧，而是一套能长期复用的协作边界。
- 多数网页登录失败不是模型不够强，而是流程一开始就没有定义停顿点。