Detail agent stealth Cloudflare fix

docs/blog/use-agent-browser-stealth-instead-of-agent-browser.zh-CN.md

@@ -0,0 +1,105 @@
+# 使用 agent-browser-stealth 代替 agent-browser
+
+很多人已经把 AI Agent 接入了浏览器自动化，但上线后会遇到同一个问题：
+
+同样流程在不同网站表现不一致；流程写完了，关键站点还是过不去。
+
+问题通常不在“会不会自动化”，而在“能不能在真实网站里稳定自动化”。
+
+这就是为什么要从 `agent-browser` 升级到 `agent-browser-stealth`。
+
+项目地址：[leeguooooo/agent-browser](https://github.com/leeguooooo/agent-browser)
+
+---
+
+## 为什么要替换
+
+### 1) 让 AI 真正可以使用浏览器
+
+很多网站已经有反爬和自动化检测策略。  
+在这些场景里，传统自动化链路会出现高频验证、中断、重试失败，最终让 AI 任务卡在关键步骤。
+
+`agent-browser-stealth` 的目标很明确：让 AI 在真实网站环境中保持更高可用性。
+
+### 2) 应对“限制 AI 浏览器”的站点策略
+
+部分站点会对自动化浏览器做额外限制，包括：
+
+- 触发挑战页
+- 关键页面二次验证
+- 会话中途降权或限流
+
+`agent-browser-stealth` 提供更完整的防识别能力，降低这类限制对任务成功率的影响。
+
+### 3) 让 Agent 和用户共享同一个浏览器
+
+很多自动化失败发生在“登录前后状态切换”环节。  
+`agent-browser-stealth` 支持 Agent 复用用户正在使用的浏览器会话，直接继承已登录状态，减少重复登录和验证码干扰。
+
+对业务流程的价值是直接的：
+
+- 缩短执行路径
+- 降低登录步骤失败率
+- 提升整体成功率与执行速度
+
+---
+
+## 典型站点效果（示例）
+
+以亚马逊这类高风控电商站点为例，很多 AI 浏览器流程过去常见的问题是：
+
+- 能打开首页，但关键操作前触发验证
+- 搜索、跳转、加购这类连续动作中途被打断
+- 会话偶发失效，任务难以完整执行
+
+切换到 `agent-browser-stealth` 后，可显著提升这类流程的可执行性，常见可完成动作包括：
+
+- 商品搜索与详情浏览
+- 购物车相关操作
+- 已登录状态下的页面导航与信息读取
+
+除了电商站点，下面两类场景也常见明显改善：
+
+- 社媒/内容平台：多步骤跳转流程更稳定
+- SaaS 后台系统：登录后连续操作中断率降低
+
+说明：不同账号状态、网络环境、站点实时策略会影响最终效果。
+
+---
+
+## 适合哪些场景
+
+- AI 客服或运营 Agent 需要在多站点执行后台操作
+- 自动化流程经常卡在登录、验证、跳转环节
+- 需要“人机协同”：用户和 Agent 共用一个会话处理复杂任务
+- 对稳定性要求高的生产任务（不是 Demo）
+
+---
+
+## 迁移成本高吗
+
+迁移成本通常很低，命令习惯可以保持一致。  
+多数场景可以先做“无侵入替换”，再按业务流程逐步优化。
+
+---
+
+## 一张表看差异
+
+| 维度 | agent-browser | agent-browser-stealth |
+| --- | --- | --- |
+| 目标 | 标准自动化能力 | 面向真实风控环境的稳定自动化 |
+| 站点兼容性 | 普通站点可用 | 高风控站点可用性更高 |
+| AI 执行稳定性 | 受验证页影响明显 | 对验证/限制策略更稳 |
+| 登录链路 | 常需重复处理登录步骤 | 支持复用用户浏览器状态，减少登录干扰 |
+| 生产可用性 | 适合基础自动化 | 更适合生产级 AI 浏览器任务 |
+
+---
+
+## 结论
+
+如果目标是“让 AI 在真实网站里稳定完成任务”，`agent-browser-stealth` 是更合适的选择。  
+如果目标只是“脚本在理想环境跑通”，`agent-browser` 已经足够。
+
+在生产环境里，真正的差异通常体现在四个字：**可用与稳定**。
+
+项目地址：[leeguooooo/agent-browser](https://github.com/leeguooooo/agent-browser)