登录态渠道交互式登录 SOP。命中需登录平台（知乎/闲鱼/淘宝/京东/小红书/拼多多/微博）且需登录态拿完整数据时，指导主Agent执行人机交互式登录（可见窗口暂停扫码）+多后端容错降级（agent-browser→Cookie-Editor→MCP/CLI），与子Agent按need_login契约协作。触发：登录态、需要登录才能看、扫码、交互式登录、选品
暂无
无内部依赖（或为叶子/外部）
| 节点 | 机制 | 证据 |
|---|---|---|
| ext-chrome | external | 登录态渠道浏览器自动化 |
0906 登录态渠道扩张方案 + 实装内化收尾。0905 架构曾将「社交平台 Cookie 依赖」列为过度工程规避（FactReach 23 渠道只取机制），但用户明确决策：登录态在选品/评价场景是刚需（知乎全文评价/淘宝销量/京东评价/小红书笔记/拼多多详情），须构建而非规避。
需求驱动：需在登录态下才能拿到完整数据（知乎/闲鱼/淘宝/京东/小红书/拼多多等 8 渠道），平台风控各异（小红书 x-s/x-t、拼多多 anti_content 强签名），需一套「真能登录并抓取」且能抗风控、有序降级的机制。
命中 search-methodology 决策树 Path3（电商/选品/评价/口碑意图）且主Agent 判定需要登录态后加载。适用于「登录态/需要登录才能看/扫码/交互式登录/选品评价口碑」场景。
①主Agent 命中 Path3 → 先查免登录 API（如 B站 bili-cli/搜索 API，零成本零账号风险，优先采用）→ 有则用免登录；②需登录态 → 三合一检测登录态（URL 跳转 + 页面元素 + 接口探针）；③已登录 → 委派子Agent 已登录态纯抓取，若报风控(403/频控/IP at risk)按多后端降级链降级（不重试同一后端）；④未登录 → 主Agent 开可见窗口 --headed 暂停请用户扫码 → 用户完成 → --restore 持久化登录态（AES-256-GCM 加密落盘）→ 重委派子Agent 纯抓取；⑤降级链走完仍失败 → 返回 {blocked:true, reason} 明确标注不编造。
路由判定由 search-methodology 决策树 Path3 承担；平台数据/合规矩阵以 source_credibility_map.md 六「需登录域」区块为单一权威源；agent-browser 通用命令（--restore/--headed/auth vault）由 browser-harness skill 承担；登录触发由主Agent、抓取由 search-worker 子Agent，按 need_login 契约（{need_login, platform, reason}）协作；依赖 opencode.env（AGENT_BROWSER_ENCRYPTION_KEY）。