最开始，这个项目只是一个非常简单的 Playwright 爬虫脚本。
它能做的事情很直接：
- 抓取
quotes.toscrape.com多页数据 - 提取
quote、author、tags - 输出本地 JSON
- 做一些简单规则分析
但随着功能逐渐增加，我发现脚本模式开始暴露很多问题：
- 每次运行都是一次性任务，无法追踪历史
- 没有统一 API 层，难以对接其他系统
- 没有前端可视化，调试体验一般
- 缺乏任务状态管理，无法表达完整执行生命周期
于是我决定不再把它停留在“爬虫脚本”，而是把它升级成一个 任务驱动 AI Browser Workflow 平台。
一、从一次性脚本升级到平台架构
这次升级的核心目标很明确：
让每次爬取都成为一个可追踪、可查询、可复用的任务单元。
整个系统的核心链路如下：
User → FastAPI → Task Manager → Playwright → Analyzer → Storage
通过这一层抽象，原本的一次性脚本，被升级成了：
- 可创建任务
- 可追踪状态
- 可查看历史
- 可通过 API 调用
- 可通过 Dashboard 统一管理
这一步本质上是：从 script mindset 转向 workflow orchestration mindset。
二、任务生命周期设计
为了让任务执行过程真正工程化，我给每个任务设计了一套完整状态流转。
Create Task → Pending → Running → Crawling → Analyzing → Success / Failed → Task History
这套生命周期最大的价值在于：
- 能清晰表达任务执行阶段
- 方便前端实时展示状态
- 支持失败任务排查
- 支持历史结果沉淀
- 为后续 Celery / Redis 扩展留接口
它已经不再是普通爬虫，而更像一个轻量任务编排系统。
三、FastAPI 后端：把脚本能力服务化
后端部分我使用 FastAPI 做了一层标准 RESTful API。
核心接口：
POST /tasks/run：创建任务GET /tasks：获取任务列表GET /tasks/{task_id}：查看任务详情
这样做的意义是：
任务执行能力不再绑定命令行，而是成为可复用服务能力。
同时 Swagger UI 可以直接在线测试，大幅降低调试成本。
四、Dashboard：把任务状态可视化
为了让任务调度和结果查看更直观，我用 Streamlit 做了一个实时 Dashboard。
主要能力包括：
1）任务创建
- 配置
pages - 选择
mode - 一键 Run Task
2）状态管理
success / pending筛选- 实时刷新
- 历史任务列表
3）任务详情
created / updated时间quotes结构化结果- AI enrich 后 JSON
- task report 查看
这一层让整个系统从“后端工具”真正变成了 可交互的 workflow 平台。
五、为什么我认为这个项目很适合继续扩展
我现在很喜欢这个项目的一点是：
它天然具备平台化升级空间。
下一步很容易继续扩展成：
- PostgreSQL 持久化
- Celery / Redis 分布式任务队列
- Docker 一键部署
- 多站点适配器
- 向量检索 / RAG 分析层
- 任务导出 API
- 可观测性监控指标
所以它的意义已经不只是“抓 quotes”。
而是一个非常适合继续往 AI workflow orchestration / agent platform 演进的原型。
六、项目总结
这次项目让我最大的收获不是“学会了爬虫”。
而是第一次完整地把一个小脚本升级成：
任务驱动、状态可追踪、前后端可视化、具备平台演进空间的 AI workflow prototype
我越来越喜欢这种 从工具到平台 的工程升级过程。
这种感觉和纯算法题完全不同，更接近真实 AI Engineering 的工作方式。
