Chrome MCP + 并行 Agent：为什么现在能一键克隆网站
过去一段时间，“做个 landing page”还是一句模糊需求。但最近三个月，X 上开始频繁出现一种更具体的工作流：
让 Agent 直接进浏览器，读真实页面，再拆成多个并行子任务去重建。
这件事之所以重要，不是因为“克隆网站”听起来很炫，而是它暴露出一套很实用的 Agent 架构。
这类工作流的核心流水线
典型链路一般是这样的：
- Chrome MCP 打开目标页面
- 抓结构、文案、颜色、栅格和交互线索
- 主 Agent 生成重建计划
- 把 Hero、Features、Pricing、FAQ 等区块分发给并行 Agent
- 再由主 Agent 合并、收口、做视觉一致性检查
这已经不是“看截图写 HTML”，而是基于真实 DOM 和交互上下文做逆向构建。
为什么它会成为 vibe coding 里的高频模式
因为这条链路同时解决了三个老问题：
1. 上下文不够的问题
以前一句“参考某网站做一个类似的”太模糊。现在浏览器就是上下文来源。
2. 页面太大，一次写不完的问题
并行 Agent 可以天然按区块拆任务，避免一个长对话把所有细节搅在一起。
3. 视觉还原差的问题
真实页面信息来自浏览器，而不是人脑记忆，所以保真度会高很多。
这对前端工作流意味着什么
我觉得它意味着前端正在出现一种新的默认流程：
- 浏览器负责“读”
- Agent 负责“拆”
- 子 Agent 负责“写”
- 主 Agent 负责“验”
这和早期“一条 prompt 生成整页”的 vibe coding 已经完全不是一回事了。
但这里必须有一条边界
这种工作流非常适合：
- 自己产品的改版重构
- 内部模板快速重建
- 获得授权的竞品分析
- 设计探索和结构学习
不适合做的事也很清楚：
- 一比一复制第三方受保护品牌页面
- 复制受版权保护的图片、文案、商标元素
高保真复刻是工程能力，不等于发布边界也跟着放宽。
我的判断
Chrome MCP + 并行 Agent 代表的不是一个 demo，而是一种更成熟的前端 Agent 工作流：先读真实世界，再有计划地重建它。
来源
- X.com：Chrome MCP 网站克隆工作流
- GitHub：相关 skill / workflow 实现
- Claude Code 官方 skills 文档