1. 项目概述与核心价值最近在折腾AI Agent的自动化能力时发现一个挺有意思的痛点很多Agent框架在处理需要浏览器交互的任务时比如抓取动态渲染的网页数据、模拟用户操作流程或者自动填写表单往往显得力不从心。它们要么依赖简单的HTTP请求无法处理JavaScript要么需要集成复杂的第三方服务配置起来相当麻烦。就在这个当口我发现了hjlarry/dify-plugin-playwright这个插件。简单来说它就像是在你的Dify AI工作流和真实的浏览器世界之间架起了一座高效的桥梁。这个插件的核心价值非常明确它允许你的AI Agent直接调用Playwright这个强大的浏览器自动化工具来执行脚本。这意味着Agent可以像真人一样操作浏览器——点击按钮、输入文字、滚动页面、截图甚至处理弹窗。对于需要与Web应用深度交互的自动化场景比如竞品数据监控、自动化测试、RPA机器人流程自动化流程或者仅仅是抓取那些靠传统爬虫难以搞定的单页应用SPA数据这个插件提供了一个极其优雅的解决方案。它把Playwright的底层能力封装成了一个标准的Dify工具Tool让Agent可以像调用一个普通函数那样去“驾驶”浏览器。2. 插件架构与工作原理拆解要理解这个插件怎么用得先搞明白它的运行架构。它不是一个独立的软件而是一个“连接器”其工作模式是典型的客户端-服务器C/S架构。2.1 核心组件与数据流整个系统涉及三个核心角色Dify AI Agent作为“大脑”负责决策和发出指令。它决定要执行什么操作比如“去某某网站搜索某个产品并截图”。dify-plugin-playwright 插件作为“翻译官”和“传令兵”。它运行在Dify后台将Agent的自然语言指令或结构化请求转换并封装成Playwright服务器能理解的指令并通过WebSocket发送出去。Playwright Server作为“执行者”。这是一个独立运行的Playwright服务它启动并管理着一个无头或有头浏览器实例。它接收指令操作真实的浏览器引擎如Chromium执行脚本并将结果如截图数据、页面文本返回。数据流的顺序是这样的Agent产生任务 - Dify平台调用该插件工具 - 插件通过WebSocket连接将Playwright脚本发送至Playwright Server - Server执行脚本并返回结果 - 插件将结果返回给Dify - Agent接收结果并进行后续处理。2.2 为什么选择Playwright Server模式这里就体现出设计者的考量了。为什么不直接在Dify的Python环境中安装Playwright库来调用呢主要原因有两个环境隔离与稳定性浏览器自动化本身是资源密集型且不太稳定的操作。通过独立的Server来运行可以将潜在的浏览器崩溃、内存泄漏等问题隔离在Dify主服务之外避免影响AI服务的稳定性。资源管理与复用一个Playwright Server可以维护一个浏览器实例供多个来自Dify的请求复用取决于连接管理这比每次请求都启动/关闭一个浏览器要高效得多。特别是在Dify处理并发请求时这种池化思想能显著降低开销。这种设计也带来了部署上的灵活性。Playwright Server可以部署在和Dify同一台机器上也可以通过网络部署在另一台性能更强或网络位置更合适的服务器上插件只需配置对应的WebSocket地址即可。3. 完整部署与配置实操指南理论清楚了我们来看怎么把它跑起来。整个过程可以分为搭建Playwright Server和配置Dify插件两大步。3.1 启动Playwright Server这是整个流程的基石。插件作者提供了两种方式我个人更推荐Docker方式因为它环境最纯净避免了你本地Node.js或系统依赖版本不一致带来的各种玄学问题。方案一使用Docker推荐这是最省心、跨平台兼容性最好的方法。执行下面这条命令docker run -p 3003:3000 --rm --init -it --workdir /home/pwuser --user pwuser mcr.microsoft.com/playwright:v1.51.0-noble /bin/sh -c npx -y playwright1.51.0 run-server --port 3000 --host 0.0.0.0我们来拆解一下这个命令理解每个参数的作用以后遇到问题也好排查docker run启动一个新容器。-p 3003:3000端口映射。将容器内部的3000端口映射到宿主机的3003端口。这里有个关键点因为Dify默认占用了3000端口所以我们必须换一个比如3003。容器内服务跑在3000我们通过宿主机的3003去访问它。--rm容器停止后自动删除。这适合测试和开发避免产生一堆停止的容器。生产环境可以考虑去掉以便查看日志。--init使用一个init进程来转发信号并回收僵尸进程让容器更稳定。-it分配一个交互式的终端方便我们看到运行日志。--workdir /home/pwuser设置容器内的工作目录。--user pwuser以pwuser这个非root用户运行更安全。mcr.microsoft.com/playwright:v1.51.0-noble使用的Docker镜像。这是微软官方提供的已经预装了Playwright v1.51.0以及其所需的浏览器Chromium, Firefox, WebKit。noble指的是Ubuntu 24.04的基础系统。/bin/sh -c “...”在容器内执行的命令。它使用npx直接运行指定版本1.51.0的Playwright的run-server命令启动一个服务器监听所有网络接口0.0.0.0的3000端口。执行成功后你应该能在终端看到类似Playwright server is running on ws://0.0.0.0:3000的日志。这说明Server已经就绪在等待WebSocket连接。注意Playwright Server默认使用WebSocket协议ws://而不是HTTPhttp://。这是为了满足浏览器自动化中双向、实时通信的需求。方案二使用NPX适合本地快速测试如果你本地已经有Node.js环境版本建议18并且不想用Docker可以用这个方式npx -y playwright1.51.0 run-server --port 3003 --host 0.0.0.0这条命令更简单npx会自动下载并运行指定版本的playwright包来启动服务器。同样端口要避开Dify的3000。3.2 在Dify中安装并配置插件Server跑起来后接下来就是在Dify中接入它。安装插件进入你的Dify管理后台在“插件市场”或“工具集成”页面找到dify-plugin-playwright进行安装。如果市场没有你可能需要手动通过GitHub地址安装。授权配置安装后插件需要你提供一个连接地址。这就是上一步启动的Playwright Server的WebSocket地址。如果Server和Dify在同一台机器上地址就是ws://localhost:3003如果Server在另一台机器假设IP是192.168.1.100地址就是ws://192.168.1.100:3003工具创建与测试配置好连接后这个插件就作为一个“工具”可用了。你可以在构建AI工作流Workflow时像添加“HTTP请求”、“代码执行”工具一样把“Playwright Browser Automation”工具拖到画布上。通常你需要配置一个输入参数比如叫script用来接收要执行的Playwright脚本。4. Playwright脚本编写详解与最佳实践插件配置好了核心就在于如何编写那个传递给它的脚本。根据文档脚本有一些特定的格式要求但掌握了窍门后非常灵活。4.1 脚本基础语法规则插件执行的不是完整的Node.js或Python文件而是一段“指令序列”。规则如下分号分隔多个Playwright API调用必须用分号;分隔。这相当于把多行代码写成了一行。结果赋值你必须将最终需要返回给Agent的结果赋值给一个名为result的变量。插件会抓取这个变量的值返回。result目前支持字符串String和字节Bytes两种类型比如一段文本或一张截图的二进制数据。浏览器对象脚本中可以直接使用一个预定义好的browser变量它代表已经连接好的浏览器实例。你不需要自己启动浏览器。一个最基础的脚本模板长这样page browser.new_page(); // 1. 打开新标签页 page.goto(https://example.com); // 2. 导航到目标网址 result page.content(); // 3. 获取页面HTML内容并赋值给result4.2 常用操作代码示例下面我列举几个在AI Agent场景下非常实用的脚本片段你可以像搭积木一样组合它们。示例1获取页面文本内容用于信息提取page browser.new_page(); page.goto(https://news.ycombinator.com); // 等待主要内容区域加载 page.wait_for_selector(.athing); // 获取前10条新闻的标题 const titles page.locator(.titleline a).all_text_contents(); result titles.slice(0, 10).join(\n); // 将结果转为字符串示例2截图并返回用于视觉验证或存档page browser.new_page(); page.goto(https://github.com/trending); // 设置视口大小确保截图一致 page.set_viewport_size({ width: 1280, height: 800 }); // 对页面特定区域截图比如趋势仓库列表 const screenshotBuffer page.locator(.Box article).first().screenshot(); result screenshotBuffer; // result直接接收字节数据示例3模拟用户交互登录、搜索page browser.new_page(); page.goto(https://github.com/login); // 输入用户名和密码注意实际应用中密码应从安全渠道获取切勿硬编码 page.fill(input[namelogin], your_username); page.fill(input[namepassword], your_password); // 点击登录按钮 page.click(input[namecommit]); // 等待登录成功后的页面跳转 page.wait_for_url(https://github.com/); // 去搜索仓库 page.goto(https://github.com/search); page.fill(input[nameq], playwright); page.press(input[nameq], Enter); page.wait_for_selector(.repo-list-item); // 获取第一个仓库名 const firstRepo page.locator(.repo-list-item a).first().text_content(); result 搜索到的第一个仓库是${firstRepo};示例4处理动态加载内容page browser.new_page(); page.goto(https://scroll.com); // 模拟滚动以触发无限加载 for (let i 0; i 5; i) { page.evaluate(() window.scrollTo(0, document.body.scrollHeight)); page.wait_for_timeout(2000); // 等待2秒加载新内容 } // 获取所有加载出来的项目 const items page.locator(.item).all_text_contents(); result 共加载了 ${items.length} 条内容\n items.join(\n);4.3 脚本编写避坑指南在实际使用中我踩过不少坑这里总结几个关键点异常处理插件脚本本身没有内置的try-catch。如果脚本执行中途出错比如元素找不到整个脚本会停止Agent可能收到一个错误。对于关键操作可以考虑用page.wait_for_selector来确保元素存在再进行操作这比直接page.click更稳健。等待策略Web页面加载是异步的。page.goto默认会等待页面load事件但对于单页应用SPA可能不够。务必结合page.wait_for_selector、page.wait_for_url或page.wait_for_load_state(networkidle)来确保目标内容确实加载完毕了。资源管理虽然Server会管理浏览器但你的脚本如果不断打开新页面browser.new_page()而不关闭page.close()可能会导致内存累积。对于顺序任务尽量复用同一个page对象。如果是并行处理多个独立任务再考虑开新页面。结果类型明确result需要什么类型。如果是文本信息用text_content()或all_text_contents()。如果是截图screenshot()返回的就是字节直接赋值即可。不要试图把复杂的JavaScript对象直接赋给result它无法被序列化传输。5. 在Dify工作流中集成与高级用法单独的工具调用已经很强大了但把它嵌入到Dify的Workflow中才能发挥AI Agent的真正威力。5.1 基础工作流构建假设我们要构建一个“每日技术资讯摘要”Agent。触发节点可以是一个定时触发器或者一个HTTP接口。LLM决策节点使用一个提示词让大模型分析“今天需要从哪些网站获取资讯”并输出一个结构化的任务列表例如[{“url”: “https://news.ycombinator.com”, “action”: “get_top_10_titles”}, {“url”: “https://github.com/trending”, “action”: “screenshot”}]。循环节点遍历这个任务列表。代码节点或工具节点在循环内部根据每个任务的action动态生成对应的Playwright脚本。例如对于get_top_10_titles生成类似示例1的脚本。Playwright工具节点执行上一步生成的脚本获取结果文本或图片。结果聚合与摘要节点将所有抓取到的文本内容汇总再交给另一个LLM节点让它生成一份简洁的每日摘要。截图则可以保存到文件或发送到通知渠道。5.2 动态脚本生成技巧这是最体现灵活性的地方。你不需要在工具里写死脚本而是可以让上一个节点通常是LLM或代码节点来生成。在Dify的“代码工具”中你可以这样写Python示例def main(url: str, task_type: str) - dict: # 根据任务类型动态组装脚本 if task_type “get_titles”: script f“”” page browser.new_page(); page.goto(‘{url}’); page.wait_for_selector(‘.news-item’); titles page.locator(‘.news-item .title’).all_text_contents(); result ‘\\n’.join(titles[:5]); “”” elif task_type “screenshot”: script f“”” page browser.new_page(); page.set_viewport_size({{ width: 1200, height: 800 }}); page.goto(‘{url}’); page.wait_for_load_state(‘networkidle’); result page.screenshot(full_pagetrue); “”” else: script “result ‘Unknown task type’;” return { “script”: script } # 输出给Playwright工具这样你的Agent就具备了根据自然语言指令动态生成浏览器操作代码并执行的能力。5.3 处理二进制结果如图片当Playwright脚本返回截图字节数据时Dify工作流需要能处理它。一种常见做法是将字节数据转换为Base64编码的字符串进行传递然后在后续节点中解码使用或直接保存。在Playwright工具节点之后可以接一个Python代码节点import base64 def main(playwright_result: bytes) - dict: # playwright_result 是截图字节流 if playwright_result: # 转换为base64字符串方便在JSON中传输或嵌入HTML报告 b64_string base64.b64encode(playwright_result).decode(‘utf-8’) # 也可以直接保存到文件 # with open(‘/tmp/screenshot.png’, ‘wb’) as f: # f.write(playwright_result) return { “screenshot_b64”: b64_string, “message”: “Screenshot processed” } return { “message”: “No screenshot data” }6. 常见问题排查与性能优化在实际部署和运行中你可能会遇到以下问题。6.1 连接与授权失败症状Dify插件配置时测试连接失败或工作流执行时报连接错误。排查步骤检查Server状态在服务器上运行curl -s http://localhost:3003或使用netstat -tlnp | grep 3003查看端口是否在监听。Playwright Server的HTTP端口用于健康检查WebSocket服务运行在同一端口。检查防火墙确保宿主机防火墙如ufw, firewalld和云服务商安全组开放了3003端口的入站访问。检查地址协议确保在Dify中配置的地址以ws://开头而不是http://。检查IP地址如果Dify和Server不在同一机器使用内网IP或公网IP并确保网络互通。6.2 脚本执行超时或失败症状工作流长时间卡在Playwright工具节点最终超时。可能原因与解决页面加载过慢在脚本中增加page.set_default_timeout(60000)将默认超时时间从30秒延长到60秒。元素定位失败使用更稳健的选择器。优先使用> Dify集成Playwright插件：实现AI Agent浏览器自动化操作
1. 项目概述与核心价值最近在折腾AI Agent的自动化能力时发现一个挺有意思的痛点很多Agent框架在处理需要浏览器交互的任务时比如抓取动态渲染的网页数据、模拟用户操作流程或者自动填写表单往往显得力不从心。它们要么依赖简单的HTTP请求无法处理JavaScript要么需要集成复杂的第三方服务配置起来相当麻烦。就在这个当口我发现了hjlarry/dify-plugin-playwright这个插件。简单来说它就像是在你的Dify AI工作流和真实的浏览器世界之间架起了一座高效的桥梁。这个插件的核心价值非常明确它允许你的AI Agent直接调用Playwright这个强大的浏览器自动化工具来执行脚本。这意味着Agent可以像真人一样操作浏览器——点击按钮、输入文字、滚动页面、截图甚至处理弹窗。对于需要与Web应用深度交互的自动化场景比如竞品数据监控、自动化测试、RPA机器人流程自动化流程或者仅仅是抓取那些靠传统爬虫难以搞定的单页应用SPA数据这个插件提供了一个极其优雅的解决方案。它把Playwright的底层能力封装成了一个标准的Dify工具Tool让Agent可以像调用一个普通函数那样去“驾驶”浏览器。2. 插件架构与工作原理拆解要理解这个插件怎么用得先搞明白它的运行架构。它不是一个独立的软件而是一个“连接器”其工作模式是典型的客户端-服务器C/S架构。2.1 核心组件与数据流整个系统涉及三个核心角色Dify AI Agent作为“大脑”负责决策和发出指令。它决定要执行什么操作比如“去某某网站搜索某个产品并截图”。dify-plugin-playwright 插件作为“翻译官”和“传令兵”。它运行在Dify后台将Agent的自然语言指令或结构化请求转换并封装成Playwright服务器能理解的指令并通过WebSocket发送出去。Playwright Server作为“执行者”。这是一个独立运行的Playwright服务它启动并管理着一个无头或有头浏览器实例。它接收指令操作真实的浏览器引擎如Chromium执行脚本并将结果如截图数据、页面文本返回。数据流的顺序是这样的Agent产生任务 - Dify平台调用该插件工具 - 插件通过WebSocket连接将Playwright脚本发送至Playwright Server - Server执行脚本并返回结果 - 插件将结果返回给Dify - Agent接收结果并进行后续处理。2.2 为什么选择Playwright Server模式这里就体现出设计者的考量了。为什么不直接在Dify的Python环境中安装Playwright库来调用呢主要原因有两个环境隔离与稳定性浏览器自动化本身是资源密集型且不太稳定的操作。通过独立的Server来运行可以将潜在的浏览器崩溃、内存泄漏等问题隔离在Dify主服务之外避免影响AI服务的稳定性。资源管理与复用一个Playwright Server可以维护一个浏览器实例供多个来自Dify的请求复用取决于连接管理这比每次请求都启动/关闭一个浏览器要高效得多。特别是在Dify处理并发请求时这种池化思想能显著降低开销。这种设计也带来了部署上的灵活性。Playwright Server可以部署在和Dify同一台机器上也可以通过网络部署在另一台性能更强或网络位置更合适的服务器上插件只需配置对应的WebSocket地址即可。3. 完整部署与配置实操指南理论清楚了我们来看怎么把它跑起来。整个过程可以分为搭建Playwright Server和配置Dify插件两大步。3.1 启动Playwright Server这是整个流程的基石。插件作者提供了两种方式我个人更推荐Docker方式因为它环境最纯净避免了你本地Node.js或系统依赖版本不一致带来的各种玄学问题。方案一使用Docker推荐这是最省心、跨平台兼容性最好的方法。执行下面这条命令docker run -p 3003:3000 --rm --init -it --workdir /home/pwuser --user pwuser mcr.microsoft.com/playwright:v1.51.0-noble /bin/sh -c npx -y playwright1.51.0 run-server --port 3000 --host 0.0.0.0我们来拆解一下这个命令理解每个参数的作用以后遇到问题也好排查docker run启动一个新容器。-p 3003:3000端口映射。将容器内部的3000端口映射到宿主机的3003端口。这里有个关键点因为Dify默认占用了3000端口所以我们必须换一个比如3003。容器内服务跑在3000我们通过宿主机的3003去访问它。--rm容器停止后自动删除。这适合测试和开发避免产生一堆停止的容器。生产环境可以考虑去掉以便查看日志。--init使用一个init进程来转发信号并回收僵尸进程让容器更稳定。-it分配一个交互式的终端方便我们看到运行日志。--workdir /home/pwuser设置容器内的工作目录。--user pwuser以pwuser这个非root用户运行更安全。mcr.microsoft.com/playwright:v1.51.0-noble使用的Docker镜像。这是微软官方提供的已经预装了Playwright v1.51.0以及其所需的浏览器Chromium, Firefox, WebKit。noble指的是Ubuntu 24.04的基础系统。/bin/sh -c “...”在容器内执行的命令。它使用npx直接运行指定版本1.51.0的Playwright的run-server命令启动一个服务器监听所有网络接口0.0.0.0的3000端口。执行成功后你应该能在终端看到类似Playwright server is running on ws://0.0.0.0:3000的日志。这说明Server已经就绪在等待WebSocket连接。注意Playwright Server默认使用WebSocket协议ws://而不是HTTPhttp://。这是为了满足浏览器自动化中双向、实时通信的需求。方案二使用NPX适合本地快速测试如果你本地已经有Node.js环境版本建议18并且不想用Docker可以用这个方式npx -y playwright1.51.0 run-server --port 3003 --host 0.0.0.0这条命令更简单npx会自动下载并运行指定版本的playwright包来启动服务器。同样端口要避开Dify的3000。3.2 在Dify中安装并配置插件Server跑起来后接下来就是在Dify中接入它。安装插件进入你的Dify管理后台在“插件市场”或“工具集成”页面找到dify-plugin-playwright进行安装。如果市场没有你可能需要手动通过GitHub地址安装。授权配置安装后插件需要你提供一个连接地址。这就是上一步启动的Playwright Server的WebSocket地址。如果Server和Dify在同一台机器上地址就是ws://localhost:3003如果Server在另一台机器假设IP是192.168.1.100地址就是ws://192.168.1.100:3003工具创建与测试配置好连接后这个插件就作为一个“工具”可用了。你可以在构建AI工作流Workflow时像添加“HTTP请求”、“代码执行”工具一样把“Playwright Browser Automation”工具拖到画布上。通常你需要配置一个输入参数比如叫script用来接收要执行的Playwright脚本。4. Playwright脚本编写详解与最佳实践插件配置好了核心就在于如何编写那个传递给它的脚本。根据文档脚本有一些特定的格式要求但掌握了窍门后非常灵活。4.1 脚本基础语法规则插件执行的不是完整的Node.js或Python文件而是一段“指令序列”。规则如下分号分隔多个Playwright API调用必须用分号;分隔。这相当于把多行代码写成了一行。结果赋值你必须将最终需要返回给Agent的结果赋值给一个名为result的变量。插件会抓取这个变量的值返回。result目前支持字符串String和字节Bytes两种类型比如一段文本或一张截图的二进制数据。浏览器对象脚本中可以直接使用一个预定义好的browser变量它代表已经连接好的浏览器实例。你不需要自己启动浏览器。一个最基础的脚本模板长这样page browser.new_page(); // 1. 打开新标签页 page.goto(https://example.com); // 2. 导航到目标网址 result page.content(); // 3. 获取页面HTML内容并赋值给result4.2 常用操作代码示例下面我列举几个在AI Agent场景下非常实用的脚本片段你可以像搭积木一样组合它们。示例1获取页面文本内容用于信息提取page browser.new_page(); page.goto(https://news.ycombinator.com); // 等待主要内容区域加载 page.wait_for_selector(.athing); // 获取前10条新闻的标题 const titles page.locator(.titleline a).all_text_contents(); result titles.slice(0, 10).join(\n); // 将结果转为字符串示例2截图并返回用于视觉验证或存档page browser.new_page(); page.goto(https://github.com/trending); // 设置视口大小确保截图一致 page.set_viewport_size({ width: 1280, height: 800 }); // 对页面特定区域截图比如趋势仓库列表 const screenshotBuffer page.locator(.Box article).first().screenshot(); result screenshotBuffer; // result直接接收字节数据示例3模拟用户交互登录、搜索page browser.new_page(); page.goto(https://github.com/login); // 输入用户名和密码注意实际应用中密码应从安全渠道获取切勿硬编码 page.fill(input[namelogin], your_username); page.fill(input[namepassword], your_password); // 点击登录按钮 page.click(input[namecommit]); // 等待登录成功后的页面跳转 page.wait_for_url(https://github.com/); // 去搜索仓库 page.goto(https://github.com/search); page.fill(input[nameq], playwright); page.press(input[nameq], Enter); page.wait_for_selector(.repo-list-item); // 获取第一个仓库名 const firstRepo page.locator(.repo-list-item a).first().text_content(); result 搜索到的第一个仓库是${firstRepo};示例4处理动态加载内容page browser.new_page(); page.goto(https://scroll.com); // 模拟滚动以触发无限加载 for (let i 0; i 5; i) { page.evaluate(() window.scrollTo(0, document.body.scrollHeight)); page.wait_for_timeout(2000); // 等待2秒加载新内容 } // 获取所有加载出来的项目 const items page.locator(.item).all_text_contents(); result 共加载了 ${items.length} 条内容\n items.join(\n);4.3 脚本编写避坑指南在实际使用中我踩过不少坑这里总结几个关键点异常处理插件脚本本身没有内置的try-catch。如果脚本执行中途出错比如元素找不到整个脚本会停止Agent可能收到一个错误。对于关键操作可以考虑用page.wait_for_selector来确保元素存在再进行操作这比直接page.click更稳健。等待策略Web页面加载是异步的。page.goto默认会等待页面load事件但对于单页应用SPA可能不够。务必结合page.wait_for_selector、page.wait_for_url或page.wait_for_load_state(networkidle)来确保目标内容确实加载完毕了。资源管理虽然Server会管理浏览器但你的脚本如果不断打开新页面browser.new_page()而不关闭page.close()可能会导致内存累积。对于顺序任务尽量复用同一个page对象。如果是并行处理多个独立任务再考虑开新页面。结果类型明确result需要什么类型。如果是文本信息用text_content()或all_text_contents()。如果是截图screenshot()返回的就是字节直接赋值即可。不要试图把复杂的JavaScript对象直接赋给result它无法被序列化传输。5. 在Dify工作流中集成与高级用法单独的工具调用已经很强大了但把它嵌入到Dify的Workflow中才能发挥AI Agent的真正威力。5.1 基础工作流构建假设我们要构建一个“每日技术资讯摘要”Agent。触发节点可以是一个定时触发器或者一个HTTP接口。LLM决策节点使用一个提示词让大模型分析“今天需要从哪些网站获取资讯”并输出一个结构化的任务列表例如[{“url”: “https://news.ycombinator.com”, “action”: “get_top_10_titles”}, {“url”: “https://github.com/trending”, “action”: “screenshot”}]。循环节点遍历这个任务列表。代码节点或工具节点在循环内部根据每个任务的action动态生成对应的Playwright脚本。例如对于get_top_10_titles生成类似示例1的脚本。Playwright工具节点执行上一步生成的脚本获取结果文本或图片。结果聚合与摘要节点将所有抓取到的文本内容汇总再交给另一个LLM节点让它生成一份简洁的每日摘要。截图则可以保存到文件或发送到通知渠道。5.2 动态脚本生成技巧这是最体现灵活性的地方。你不需要在工具里写死脚本而是可以让上一个节点通常是LLM或代码节点来生成。在Dify的“代码工具”中你可以这样写Python示例def main(url: str, task_type: str) - dict: # 根据任务类型动态组装脚本 if task_type “get_titles”: script f“”” page browser.new_page(); page.goto(‘{url}’); page.wait_for_selector(‘.news-item’); titles page.locator(‘.news-item .title’).all_text_contents(); result ‘\\n’.join(titles[:5]); “”” elif task_type “screenshot”: script f“”” page browser.new_page(); page.set_viewport_size({{ width: 1200, height: 800 }}); page.goto(‘{url}’); page.wait_for_load_state(‘networkidle’); result page.screenshot(full_pagetrue); “”” else: script “result ‘Unknown task type’;” return { “script”: script } # 输出给Playwright工具这样你的Agent就具备了根据自然语言指令动态生成浏览器操作代码并执行的能力。5.3 处理二进制结果如图片当Playwright脚本返回截图字节数据时Dify工作流需要能处理它。一种常见做法是将字节数据转换为Base64编码的字符串进行传递然后在后续节点中解码使用或直接保存。在Playwright工具节点之后可以接一个Python代码节点import base64 def main(playwright_result: bytes) - dict: # playwright_result 是截图字节流 if playwright_result: # 转换为base64字符串方便在JSON中传输或嵌入HTML报告 b64_string base64.b64encode(playwright_result).decode(‘utf-8’) # 也可以直接保存到文件 # with open(‘/tmp/screenshot.png’, ‘wb’) as f: # f.write(playwright_result) return { “screenshot_b64”: b64_string, “message”: “Screenshot processed” } return { “message”: “No screenshot data” }6. 常见问题排查与性能优化在实际部署和运行中你可能会遇到以下问题。6.1 连接与授权失败症状Dify插件配置时测试连接失败或工作流执行时报连接错误。排查步骤检查Server状态在服务器上运行curl -s http://localhost:3003或使用netstat -tlnp | grep 3003查看端口是否在监听。Playwright Server的HTTP端口用于健康检查WebSocket服务运行在同一端口。检查防火墙确保宿主机防火墙如ufw, firewalld和云服务商安全组开放了3003端口的入站访问。检查地址协议确保在Dify中配置的地址以ws://开头而不是http://。检查IP地址如果Dify和Server不在同一机器使用内网IP或公网IP并确保网络互通。6.2 脚本执行超时或失败症状工作流长时间卡在Playwright工具节点最终超时。可能原因与解决页面加载过慢在脚本中增加page.set_default_timeout(60000)将默认超时时间从30秒延长到60秒。元素定位失败使用更稳健的选择器。优先使用>