在 Manus 执行网页自动化任务时，如果目标站点弹出验证码、登录验证或人机校验，任务通常会停住：页面不再继续跳转，输出长时间不更新，有时还会反复刷新同一个地址。这个现象容易被误判为模型上下文丢失，实际上更多是自动化浏览器会话被验证系统拦截，缺少继续访问所需的 Cookie、令牌或人工确认。处理这类问题时，不建议直接删除任务重跑，因为同一个 IP、同一套浏览器指纹再次访问很可能触发更严格的验证。正确做法是先判断验证类型和页面状态，再通过人工接管、会话复用或任务拆分让流程恢复。
先判断验证类型和卡住原因
网页验证并不是同一种东西。Manus 卡住时，页面可能显示的是 Cloudflare 的挑战页，也可能是 Google reCAPTCHA 的勾选框，还可能是登录后的短信验证码或扫码确认。不同验证方式对应的处理策略不同，因此第一步是观察浏览器窗口或截图，确认当前页面到底停在哪一步。
如果页面只是加载中且地址栏没有变化，通常是网络或资源加载被验证脚本拖住；如果页面已经出现明确的验证码组件，则需要人工完成或注入有效凭证；如果页面反复跳转到登录页，说明当前会话没有被站点识别为已登录状态。把这三类情况分开，后续操作才会更准确。
另外，Manus 在自动化操作时可能存在默认超时，一旦页面在指定时间内没有完成导航，就会返回超时信息。这时候不要只看到超时两个字就认为任务失败，可以结合页面截图确认是否已经进入了验证环节。把验证卡住和普通超时区分开，能避免误判导致的无效重试。
人工接管与 Cookie 会话复用
人工接管是最直接的恢复手段。Manus 通常会提供一个可操作的浏览器窗口或远程调试入口，当检测到验证码出现时，可以先暂停自动化步骤，由用户手动完成勾选、滑动或短信校验。验证通过后，浏览器会获得新的 Cookie 或令牌，此时再让任务从当前页面继续执行，而不是从头重跑。这样既保留了已经完成的任务进度，也避免了对目标站点造成重复访问压力。
如果验证页面需要登录，人工登录成功后可以把会话状态保存下来，后续任务直接复用。以 Playwright 为例，下面的代码演示了等待人工验证通过后保存 storage_state 的过程。这个 state 文件包含 Cookie 和 localStorage，后续启动上下文时加载它，就能跳过大部分登录验证。
import asyncio
from playwright.async_api import async_playwright
async def manual_verify_and_save():
async with async_playwright() as p:
browser = await p.chromium.launch(headless=False)
context = await browser.new_context()
page = await context.new_page()
await page.goto("https://ipipp.com/login")
# 这里等待人工完成验证码或登录，最多等待 180 秒
try:
await page.wait_for_url("**/dashboard", timeout=180000)
except Exception:
print("验证等待超时，请检查当前页面状态")
# 验证通过后保存完整会话状态
await context.storage_state(path="state.json")
await browser.close()
asyncio.run(manual_verify_and_save())
后续运行时，可以在创建上下文时通过 storage_state 参数加载 state.json，Manus 或自定义自动化脚本就能以已登录身份访问目标站点。这样即使偶发验证码，人工处理一次之后也能减少重复登录的消耗。需要特别注意的是，保存的状态文件包含敏感身份信息，不要提交到公共仓库，也要定期更新，避免 Cookie 过期后再次卡住。
如果 Manus 本身不提供直接导出 Cookie 的入口，也可以从已经手动登录的浏览器中提取 Cookie，并以文件或环境变量的方式注入到后续任务。无论用哪种方式，核心目的都是让自动化环境具备和真实用户一致的会话凭证，从而通过站点的基础信任检查。
通过任务拆分和重试策略降低触发概率
很多验证码不是一开始就出现，而是因为操作频率过高、点击位置过于机械、或者短时间内多次访问同一页面才被触发。把大任务拆成多个小步骤，并在步骤之间加入合理等待，可以明显降低风险。比如不要一次性采集几十个列表页，而是每处理几页就暂停几秒，遇到验证时优先回退到上一状态。
任务指令设计也很重要。如果给 Manus 的指令是“登录并抓取全站数据”，那么验证失败时它可以重试的路径很少，容易卡死。改成“先打开登录页，检查是否有验证码；如果出现验证码则等待人工处理；登录成功后每次只请求 5 个页面，并保存当前进度”，这样任务就具备可恢复性。即使中间某个步骤被拦截，也可以从最近的检查点继续，而不是完全从头开始。
还可以加入简单的重试与幂等逻辑：同一个步骤重复执行不会产生新的副作用。比如抓取失败时记录失败 URL，稍后再补抓，而不是从头遍历。这样即使某一步被验证拦截，也不会影响已经完成的部分。对于写操作类任务，例如提交表单，幂等设计更加重要，否则验证失败后重复提交可能产生重复数据。
结合代理和浏览器指纹减少验证频率
验证系统除了看 Cookie，还会分析 IP 地址、浏览器指纹、语言环境和请求头。如果 Manus 运行在数据中心 IP 上，访问高防护站点时更容易触发验证。此时可以配置住宅代理或稳定的企业代理，并尽量保持任务期间 IP 不变，避免每次请求都更换出口。频繁切换 IP 本身就是一种典型的自动化特征。
浏览器指纹方面，使用真实浏览器内核比精简版无头浏览器更容易通过基础校验。如果自定义脚本里启用了无头模式，遇到验证码时可以临时切换为有头模式，或者注入更完整的 navigator 信息。对于 Manus 这类产品，如果支持选择浏览器类型或执行环境，优先选择接近真实用户的配置。
同时，避免一个账号在多个地区同时登录，或者在同一天内频繁清除 Cookie。稳定的会话行为本身就是降低验证频率的有效方式。当验证码已经出现时，不要继续自动点击刷新，先暂停观察，避免触发风控升级。先让账号冷却一段时间，再结合人工处理或者已经保存的会话继续执行，往往比连续重试更有效。