结合Playwright抓取动态网页内容注入知识库

结合Playwright抓取动态网页内容注入知识库

在构建企业级智能问答系统时，一个常被忽视但至关重要的问题浮出水面：我们如何让AI真正“读懂”那些由JavaScript驱动的现代网页？

传统爬虫通过requests获取HTML源码的方式，在面对单页应用（SPA）或动态加载内容时几乎束手无策——页面返回的是空壳，真正的信息藏在后续的JS执行中。这导致知识库的数据来源严重受限，只能依赖静态文档上传，无法实时同步外部变化。更糟糕的是，人工整理不仅效率低下，还容易遗漏关键更新。

正是在这种背景下，Playwright与anything-llm的组合脱颖而出。前者能像真实用户一样操作浏览器，完整渲染页面并提取最终DOM；后者则提供了一套开箱即用的RAG（检索增强生成）引擎，将抓取到的内容转化为可查询的知识资产。两者的结合，不是简单的工具叠加，而是一次从“被动存储”到“主动感知”的范式跃迁。

想象这样一个场景：某科技公司的竞争情报团队需要持续追踪对手官网的产品更新。过去，他们每周手动复制粘贴新功能描述，耗时且易出错。现在，只需一段自动化脚本定时运行，就能自动捕获对方页面上的变更，并立即注入内部AI助手的知识库。员工提问“竞品X最近推出了哪些新特性？”时，系统不仅能准确回答，还能附上原文链接作为依据。

实现这一流程的核心，在于对两个关键技术点的精准把控：动态内容的真实还原和知识链路的无缝打通。

先看Playwright的角色。它之所以优于Selenium或Puppeteer，不只是因为它支持Chromium、Firefox和WebKit三端统一API，更在于其内置的智能等待机制。比如wait_until="networkidle"会自动判断网络请求是否趋于稳定，避免因异步加载未完成而导致元素缺失。再如page.locator().inner_text()可以直接提取纯文本，跳过复杂的HTML结构解析，极大简化了后续NLP处理的负担。

from playwright.sync_api import sync_playwright import time def scrape_dynamic_page(url: str, selector: str = "body") -> str: with sync_playwright() as p: browser = p.chromium.launch(headless=True) context = browser.new_context( viewport={'width': 1920, 'height': 1080}, user_agent='Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36' ) page = context.new_page() try: page.goto(url, wait_until="networkidle") page.evaluate("window.scrollTo(0, document.body.scrollHeight)") time.sleep(2) page.wait_for_selector(selector, timeout=10000) content = page.locator(selector).inner_text() except Exception as e: print(f"抓取失败: {e}") content = "" finally: context.close() browser.close() return content.strip()

这段代码看似简单，实则暗藏工程细节。例如模拟滚动到底部是为了触发懒加载组件——很多新闻站或电商产品页都采用这种优化策略。而使用sync_playwright而非异步接口，则是出于集成便利性的考量：多数数据管道仍以同步方式组织，强行引入async可能破坏整体架构。当然，若需高并发采集，完全可以改写为基于asyncio的版本，轻松管理数十个并行浏览器实例。

但抓下来的内容只是原材料，真正决定知识质量的是后续处理。这里有一个常被忽略的经验：不要把所有HTML一股脑塞进知识库。导航栏、广告位、版权声明这些噪声会污染向量空间，降低检索精度。建议在注入前做轻量清洗，比如用正则过滤明显无关段落，或借助readability-lxml等库提取正文主体。

接下来就是打通anything-llm的环节。这个平台的真正优势不在于功能多强大，而在于“少即是多”的设计理念。它没有堆砌复杂的LangChain流水线，而是把文档摄入、向量化、索引更新封装成一个简洁的REST API：

import requests import json def ingest_to_anything_llm(content: str, title: str, api_key: str, base_url: str = "http://localhost:3001"): endpoint = f"{base_url}/api/v1/workspace/default/document" headers = { "Authorization": f"Bearer {api_key}", "Content-Type": "application/json" } payload = { "name": title, "content": content, "documentType": "text", "chunks": [], "upsertBy": "content" } try: response = requests.post(endpoint, headers=headers, data=json.dumps(payload), timeout=30) if response.status_code == 200: result = response.json() print(f"成功注入文档: {result.get('id')}") else: print(f"注入失败 [{response.status_code}]: {response.text}") except Exception as e: print(f"请求异常: {e}")

注意upsertBy="content"这个参数——它启用了基于内容哈希的去重机制。这意味着即使每天抓取同一页面，系统也只会保留最新版本，避免知识库膨胀。此外，虽然示例中直接传入大段文本，但实际生产环境中建议按章节或语义块分批提交，既能防止超时，也便于后期维护。

整个系统的运作节奏可以这样规划：通过Airflow或cron设置每日凌晨执行任务，读取配置文件中的URL列表及对应的选择器规则，依次完成抓取、清洗、注入流程。每次运行后记录状态日志，包括抓取字数、响应时间、错误信息等，形成可观测性闭环。

当然，这条链路并非毫无挑战。Playwright的内存占用较高，长时间运行多个浏览器实例可能导致OOM（内存溢出）。我的建议是控制并发数不超过服务器核心数的1.5倍，并定期重启主进程释放资源。另外，反爬问题也不容小觑。除了基础的随机延时和User-Agent轮换外，更稳健的做法是搭建代理池，结合指纹伪装技术降低被封禁风险。

安全性方面有两个关键点必须考虑：一是API密钥绝不能硬编码在脚本中，应通过环境变量或密钥管理服务注入；二是对外部URL进行白名单校验，防止恶意输入引发SSRF攻击。毕竟，自动化程度越高，潜在攻击面就越广。

从更高维度看，这套方案的价值远不止于“省事”。它实际上构建了一个可自我进化的知识中枢。当企业内部Wiki、外部行业报告、竞争对手动态都被纳入同一个向量空间后，LLM不再是一个孤立的语言模型，而成了连接内外信息的智能枢纽。员工的问题不再局限于“这份文档说了什么”，而是上升为“基于当前市场环境，我们应该如何应对”。

未来还可以进一步延伸：比如引入diff算法检测页面内容变化，只将新增部分注入知识库，减少冗余计算；或者结合NLP模型对抓取文本自动打标签、生成摘要，实现初步的知识组织。甚至可以反向联动——当知识库发现某政策法规有重大更新时，自动触发邮件通知相关责任人。

这种高度集成的设计思路，正引领着智能知识系统向更可靠、更高效的方向演进。技术本身并不炫目，但它解决的是实实在在的业务痛点：让机器学会主动学习，而不是被动等待喂养。