做 Web 开发和测试的同学应该都有过这样的经历需求方丢过来一句话“你帮我把这个页面的登录流程跑一遍看有没有问题”。你打开浏览器按下 F12写一个几行的自动化脚本执行发现选择器变了改一遍再执行又发现某个接口返回慢页面没刷新再换成显式等待……一上午就这样过去了。如果有一个助手你只需要告诉它“打开登录页用 admin 和 123456 登录把登录结果告诉我”它就能自己打开浏览器、填写表单、点击按钮、读取页面内容、分析结果最后用一句话回你。这就是 LangChain Playwright 组合的真实价值。很多人看到这两个词第一反应是LangChain 是搞大模型应用的Playwright 是搞自动化测试的为什么要放一起这篇文章会从一个完整可运行的 Agent 项目出发把两者的配合方式、完整代码和落地过程中的坑全部讲清楚。先给一个明确判断LangChain Playwright 组合解决的不是“脚本执行”层面的问题而是“任务编排”层面的问题。它把网页自动化从“每个用例写一段脚本”升级为“用自然语言描述任务让 Agent 自己拆解并执行”。读完本文你会得到一份可以直接运行的完整代码以及一套在实际项目中落地这类 Agent 时避免踩坑的方法论。如果你是测试开发工程师、全栈开发或者正在研究 AI Agent 落地场景这篇文章值得收藏。1. 为什么 LangChain 和 Playwright 会组合在一起先看传统自动化测试的痛点。无论是 Selenium、Playwright 还是 Cypress本质上都是“把测试步骤固化成代码”。写用例要面对三件事选择器定位、等待策略、断言维护。页面一改选择器一变脚本跟着碎。就算用上 PageObject 模式也只是把碎的程度降低并没有解决核心问题——测试意图和测试执行是两套语言。传统方式的流程是人的意图 → 翻译成步骤 → 翻译成代码 → 执行。其中“翻译”这一步最耗时也最容易出错。而 Agent 的工作方式完全不同人的意图自然语言 → LLM 规划 → 工具执行 → 观察结果 → 再规划直到完成。翻译动作从“程序员写代码”变成了“模型做决策”。这里就能看出 LangChain 和 Playwright 各自的角色。Playwright 提供的是稳定、可靠的浏览器操作能力相当于 Agent 的“手”LangChain 提供的是大模型应用的基本框架负责把“意图”变成“决策循环”相当于 Agent 的“大脑”。很多人误以为 Playwright 只是一个“爬虫库”实际上它内置了自动等待、多浏览器支持、Trace 回放、Codegen 录制等能力这些能力恰好是 Agent 操作网页时最需要的。另一个很实际的原因是测试开发岗位的工作内容正在发生变化。以前招测试开发核心要求是“会写自动化脚本、会搭框架”现在越来越多的团队在探索“用自然语言写测试用例由 Agent 执行并回归”。不是说脚本自动化会被淘汰而是说 Agent 适合承接那些“一次性、探索性、不稳定”的测试任务比如新功能冒烟测试、页面结构快速检查、线上环境信息提取这类任务写脚本成本高、收益低交给 Agent 反而很合适。所以LangChain Playwright 组合真正解决的是“从用例自动化到任务自动化”的跃迁。判断一个任务适不适合用 Agent标准也很简单如果你能用一句话说清楚任务但写脚本要花半小时以上那这个任务就适合 Agent。2. 基本概念Agent、LangChain、LangGraph、Playwright 各司其职写代码之前先把概念边界理清楚。很多初学者把 LangChain、LangGraph、Agent Framework 混在一起结果代码跑不通都不知道去哪一层排查。Agent 是什么Agent 是一个由大模型驱动的决策循环系统。你可以把它理解成一个会“拆活”的实习生接到任务后先想下一步做什么选择一个工具去执行看到工具返回的结果再想下一步直到认为任务完成。这种循环在学术上叫 ReAct 模式即 Thought思考→ Action行动→ Observation观察的循环。Agent 的关键能力不是“写代码”而是“决定调用哪个工具、什么时候停止”。LangChain 是什么LangChain 是面向大模型应用开发的框架最早因为提供 Chain、Tool、Memory、Retrieval 这些组件而流行。它做的事情可以概括为把模型调用、提示词管理、工具调用、记忆存储这些通用能力封装好让开发者不用每次从头搭。对 Agent 而言LangChain 提供了 Tool 抽象、AgentExecutor 执行器、以及 create_react_agent 这样的快捷方法。LangGraph 和 LangChain 有什么区别这是目前搜索量非常高的问题。简单说LangGraph 是更底层的图编排框架可以把它理解为 LangChain 家族里专门用来编排复杂工作流的那一层。LangChain 里的 AgentExecutor 适合“一条路走到黑”的简单循环而 LangGraph 允许你自定义节点、条件分支、循环甚至人工介入。从实践看简单 ReAct Agent 用 LangChain 足够涉及多角色协作、条件回退、长流程任务时再上 LangGraph。两者的关系不是替代而是抽象层次不同。维度LangChainLangGraph定位大模型应用开发框架提供模型 I/O、工具、记忆等组件Agent 工作流的有向图编排框架更底层核心抽象Chain、Tool、AgentExecutorStateGraph、Node、Edge、State控制能力AgentExecutor 默认全自动循环支持条件分支、循环、并行、人工介入适用场景快速搭建 RAG、简单 ReAct Agent复杂业务编排、需要精细控制的 Agent 应用学习成本相对平缓需要理解图的运行机制Playwright 是什么Playwright 是微软开源的浏览器自动化框架支持 Chromium、Firefox、WebKit 三种内核特点是安装简单、自动等待、选择器能力强还自带 Codegen 录制和 Trace Viewer 回放。和 Selenium 相比它不需要单独维护和浏览器版本匹配的 WebDriver安装体验和稳定性都更好。对 Agent 场景来说Playwright 的自动等待尤为重要——Agent 并不知道页面何时加载完如果没有自动等待工具调用会频繁失败。对比项PlaywrightSelenium安装方式pip install 安装浏览器二进制需要额外下载 WebDriver浏览器范围Chromium、Firefox、WebKit三大浏览器及更多等待机制内置自动等待主要靠显式等待调试工具Codegen、Trace Viewer、UI Mode相对较弱Agent 集成可封装为 Tool也有官方 MCP Server可封装但动态页面处理成本更高在整体架构中LangChain 负责任务拆解与模型调度Playwright 负责页面操作模型负责观察和决策工具负责执行。理解这个分工后后面代码里的每一个文件职责就非常清晰了。3. 方案设计一个可运行的网页测试 Agent 长什么样本文要实现的 Agent 是一个“网页测试助手”。用户用自然语言下达任务Agent 自主完成浏览器操作并汇报结果。为了演示完整闭环我选择了一个最常见的测试场景登录流程测试。目标任务是打开本地演示页面输入用户名和密码点击登录读取页面反馈判断登录是否成功并输出测试结论。整体流程如下用户输入任务 → LLM 解析任务 → Agent 调用“打开网页”工具 → 调用“填写输入框”工具 → 调用“点击按钮”工具 → 调用“提取文本”工具 → Agent 综合分析观察结果 → 输出结论。这个流程看似简单但它包含了 Agent 的所有核心要素工具注册、决策循环、观察反馈、结论输出。工程上拆成三个文件agent-web-test/ ├── requirements.txt # 项目依赖 ├── browser_tools.py # 把 Playwright 操作封装成 LangChain Tool ├── agent_main.py # Agent 主流程ReAct 循环 └── demo_page.py # 本地演示页面用于测试 Agentbrowser_tools.py是核心它决定 Agent 能做什么agent_main.py是大脑它决定 Agent 怎么决策demo_page.py是靶场提供一个稳定的测试目标避免依赖外部网站的稳定性。为什么选择“Playwright 工具化封装 ReAct Agent”这种方案因为这是从传统自动化平滑过渡到 Agent 化的最小可行路径。你不需要一开始就上 LangGraph、不需要设计复杂的多 Agent 协作只需要把已有的 Playwright 操作能力包成工具再用一个 ReAct Agent 把它们串起来就能体验到从前做不到的“一句话跑测试”。4. 环境准备与项目初始化先说明环境要求建议使用 Python 3.10 及以上版本操作系统不限Windows、macOS、Linux 都可以。整体步骤是创建虚拟环境、安装依赖、安装 Playwright 浏览器内核。mkdir agent-web-test cd agent-web-test python -m venv venv # Windows 激活虚拟环境 venv\Scripts\activate # macOS / Linux 激活虚拟环境 source venv/bin/activate然后创建依赖文件。版本方面建议以当前稳定版本为准下面的版本范围是兼容性较好的写法实际安装时 pip 会解析出合适版本# requirements.txt langchain0.2.0 langchain-openai0.1.0 langchain-core0.2.0 playwright1.40.0注意如果你的 LangChain 版本较新出现create_react_agent的废弃提示可以把导入改成from langgraph.prebuilt import create_react_agent两种方式在功能上等价本文代码以 LangChain 的 AgentExecutor 为例因为它在生产环境中使用更广泛、更稳定。安装依赖pip install -r requirements.txt python -m playwright install chromium这里专门强调一点很多人在 Windows 上执行playwright install chromium会报“无法将‘playwright’项识别为 cmdlet、函数、脚本文件或可运行程序”。这个报错不是 Playwright 没装好而是 Python 的 Scripts 目录没有加入 PATH导致命令行找不到入口。遇到这种情况不要急着改环境变量直接用python -m playwright install chromium即可这也是最不容易出错的执行方式。模型选择方面示例代码默认使用langchain-openai里的ChatOpenAI。如果你有 OpenAI 兼容接口的其他模型服务可以通过base_url指向对应的服务地址国内的大模型服务大多提供了 OpenAI 兼容协议接入方式就是把base_url和api_key换成你自己的。温度建议设置为 0Agent 场景下我们不需要创造性需要的是稳定、可复现的工具选择。5. 核心代码实现把 Playwright 封装成 LangChain Tool这是整个项目的核心。LangChain 的 Tool 本质上就是一个“带说明书”的函数函数负责做事说明书docstring告诉模型这个工具能干什么、参数是什么。模型看到说明书后决定是否调用、怎么调用。创建browser_tools.py内容如下# browser_tools.py 将 Playwright 的浏览器操作封装成 LangChain Tool from langchain_core.tools import tool from playwright.sync_api import sync_playwright _browser None _context None _page None _playwright None def ensure_page(headless: bool True): 初始化浏览器页面使用全局单例保证 Agent 的多次工具调用 在同一个浏览器上下文中执行。 global _browser, _context, _page, _playwright if _page is None: _playwright sync_playwright().start() _browser _playwright.chromium.launch(headlessheadless) _context _browser.new_context( ignore_https_errorsTrue, viewport{width: 1280, height: 720}, ) _page _context.new_page() return _page tool def navigate_to(url: str) - str: 打开指定 URL等待页面网络空闲后返回页面标题。 参数 url: 完整的网址例如 https://example.com page ensure_page() page.goto(url, wait_untilnetworkidle, timeout30000) return f页面标题: {page.title()} | URL: {page.url} tool def fill_input(selector: str, text: str) - str: 根据 CSS 选择器定位输入框并填入文本。 参数 selector: CSS 选择器例如 #username 参数 text: 要填入的文本内容 page ensure_page() page.fill(selector, text) return f已向 {selector} 填入内容 tool def click_button(selector: str) - str: 点击页面上指定选择器的按钮或链接。 参数 selector: CSS 选择器例如 #login-btn page ensure_page() page.click(selector) page.wait_for_load_state(networkidle) return f已点击 {selector} tool def extract_text(selector: str) - str: 提取页面上指定选择器对应的文本内容最多返回 5 个匹配元素。 参数 selector: CSS 选择器例如 #result page ensure_page() elements page.locator(selector) count elements.count() if count 0: return 未找到匹配元素 results [] for i in range(min(count, 5)): text elements.nth(i).inner_text().strip() if text: results.append(text) return \n.join(results) if results else 匹配元素无文本内容 tool def extract_page_text() - str: 提取当前页面所有可见文本用于不了解页面结构时快速了解页面内容。 无参数。 page ensure_page() body_text page.inner_text(body) return body_text[:2000] def close_browser(): 关闭浏览器并释放资源程序结束前调用。 global _browser, _context, _page, _playwright if _browser: _browser.close() if _playwright: _playwright.stop() _browser _context _page _playwright None这里有几个关键设计点直接决定 Agent 好不好用。第一tool装饰器是 LangChain 对工具的标准化封装。它会把函数的参数签名、类型注解、docstring 提取成模型可以理解的 schema。也就是说docstring 写得好不好直接影响模型选择工具和填参数的准确率。比如fill_input的 docstring 里写明“参数 selector: CSS 选择器”模型就会知道传#username而不是传username。第二全局单例浏览器。Agent 执行一个任务会多次调用工具比如先打开页面再填表单如果每次调用都新建浏览器状态就丢了。用全局变量保存_page保证整个任务生命周期内操作的是同一个页面。第三Playwright 的自动等待。代码里没有写time.sleep()而是依赖page.goto()的wait_untilnetworkidle和click_button里的wait_for_load_state()。这是 Playwright 对比 Selenium 的核心优势页面没加载完就不会返回Agent 拿到的观察结果更可靠。第四extract_page_text是一个“兜底工具”。当模型不确定页面上有哪些元素时可以用它先了解页面内容再决定下一步操作。这种工具在真实项目中非常有价值它模拟了人工测试时“先看一眼页面”的行为。6. 搭建 Agent 主流程ReAct 循环与任务执行有了工具接下来创建 Agent 主流程。这里使用 LangChain 的create_react_agentAgentExecutorReAct 模板中明确告诉模型工具调用的格式让模型按照“思考-行动-观察”的循环执行。先创建本地演示页面demo_page.py# demo_page.py 启动一个本地演示页面包含登录表单供 Agent 测试使用 from http.server import HTTPServer, BaseHTTPRequestHandler HTML !DOCTYPE html html head meta charsetutf-8 titleDemo Login/title /head body h1 idwelcome欢迎登录测试系统/h1 form idlogin-form input idusername placeholder用户名 / input idpassword typepassword placeholder密码 / button idlogin-btn typesubmit登录/button /form div idresult/div script document.getElementById(login-form).addEventListener(submit, function(e) { e.preventDefault(); const u document.getElementById(username).value; const p document.getElementById(password).value; if (u admin p 123456) { document.getElementById(result).innerText 登录成功欢迎 admin; document.getElementById(welcome).innerText Dashboard; } else { document.getElementById(result).innerText 用户名或密码错误; } }); /script /body /html class Handler(BaseHTTPRequestHandler): def do_GET(self): self.send_response(200) self.send_header(Content-Type, text/html; charsetutf-8) self.end_headers() self.wfile.write(HTML.encode(utf-8)) def log_message(self, format, *args): pass if __name__ __main__: server HTTPServer((127.0.0.1, 8000), Handler) print(演示页面已启动: http://127.0.0.1:8000) server.serve_forever()这个页面是一个标准登录表单。输入admin和123456时页面显示“登录成功欢迎 admin”否则显示“用户名或密码错误”。选择器分别是#username、#password、#login-btn和#result非常稳定适合作为 Agent 测试靶场。接下来是核心的agent_main.py# agent_main.py 主程序用 LangChain 构建网页自动化测试 Agent from langchain.agents import AgentExecutor, create_react_agent from langchain_core.prompts import PromptTemplate from langchain_openai import ChatOpenAI from browser_tools import ( navigate_to, fill_input, click_button, extract_text, extract_page_text, close_browser, ) REACT_PROMPT PromptTemplate.from_template( 你是网页自动化测试 Agent。请尽力完成用户交代的任务你可以使用以下工具 {tools} 请严格按下面的格式执行 Question: 需要回答的原始问题 Thought: 思考当前状态和下一步需要做什么 Action: 要调用的工具名称必须是 [{tool_names}] 之一 Action Input: 调用工具所需的 JSON 参数例如 {{url: https://example.com}} Observation: 工具返回的观察结果 ...Thought / Action / Action Input / Observation 可以循环多次 Thought: 我现在知道了最终答案 Final Answer: 给用户的最终测试结论 开始 Question: {input} Thought:{agent_scratchpad} ) def main(): # 模型配置按需替换 api_key 和 base_url llm ChatOpenAI( modelgpt-4o-mini, temperature0, api_keysk-xxxx, base_urlhttps://api.openai.com/v1, ) tools [ navigate_to, fill_input, click_button, extract_text, extract_page_text, ] agent create_react_agent(llmllm, toolstools, promptREACT_PROMPT) executor AgentExecutor( agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue, max_iterations10, ) task input(请输入要交给 Agent 的任务) try: result executor.invoke({input: task}) print(\n Agent 执行结果 ) print(result[output]) finally: close_browser() if __name__ __main__: main()AgentExecutor是整个循环的调度器。verboseTrue会在控制台打印出模型的每一步思考和工具调用结果你可以清楚地看到 Agent 是怎么决策的。handle_parsing_errorsTrue表示当模型输出的 Action 格式不合法时LangChain 会把错误信息回传给模型让它自我修正这能显著提高多轮执行的稳定性。max_iterations10是安全阀防止 Agent 陷入死循环。如果出现create_react_agent的废弃提示只需要把导入语句改一行from langgraph.prebuilt import create_react_agentLangGraph 版本的create_react_agent返回的是编译后的图对象不能直接配合AgentExecutor使用而是调用graph.invoke(...)。为了保持本文示例简单这里仍然使用AgentExecutor这条路径但它并不影响你理解 Agent 的整体执行逻辑。7. 运行结果与效果验证运行分两步。先在第一个终端启动演示页面python demo_page.py启动成功后终端显示演示页面已启动: http://127.0.0.1:8000然后在第二个终端启动 Agentpython agent_main.py程序会等待输入任务。输入打开 http://127.0.0.1:8000在用户名输入框填入 admin密码输入框填入 123456点击登录按钮然后提取 id 为 result 的元素内容告诉我登录是否成功。如果模型正常你会看到类似下面的执行过程具体措辞依模型和版本会有差异但整体结构一致 Entering new AgentExecutor chain... Thought: 任务需要先打开演示页面然后填写用户名和密码点击登录再提取登录结果。 Action: navigate_to Action Input: {url: http://127.0.0.1:8000} Observation: 页面标题: Demo Login | URL: http://127.0.0.1:8000 Thought: 页面已经打开需要定位用户名输入框并填入 admin。 Action: fill_input Action Input: {selector: #username, text: admin} Observation: 已向 #username 填入内容 Thought: 接下来填写密码。 Action: fill_input Action Input: {selector: #password, text: 123456} Observation: 已向 #password 填入内容 Thought: 用户名和密码都已填写点击登录按钮。 Action: click_button Action Input: {selector: #login-btn} Observation: 已点击 #login-btn Thought: 点击后需要提取 result 元素的内容验证登录结果。 Action: extract_text Action Input: {selector: #result} Observation: 登录成功欢迎 admin Thought: 我已经知道最终答案了。 Final Answer: 登录测试通过。使用 admin / 123456 登录后页面显示“登录成功欢迎 admin”说明登录流程正常。 Finished chain. Agent 执行结果 登录测试通过。使用 admin / 123456 登录后页面显示“登录成功欢迎 admin”说明登录流程正常。判断成功的标准有三点第一Agent 能独立完成打开页面、填表、点击、提取这四个动作中间步骤齐全第二最后总结出的测试结论和页面实际显示一致第三没有重复执行同一工具超过三次说明模型对工具理解准确。如果执行失败优先看Observation这一行。绝大多数问题都出在工具返回的结果和模型预期不一致比如页面标题为空、选择器找不到元素、网络超时等。另外如果模型中途停止会走handle_parsing_errors分支控制台会出现解析错误信息这也是正常的容错机制模型会在下一轮尝试修正格式。8. 常见问题与排查思路以下是这个项目从搭建到运行最常遇到的问题整理成表格方便直接对照排查。问题现象可能原因排查方式解决方案ModuleNotFoundError: No module named langchain依赖未安装或虚拟环境未激活执行pip list查看当前环境激活虚拟环境并重新执行pip install -r requirements.txtplaywright 命令无法识别Python Scripts 目录不在 PATH执行python -m playwright --version使用python -m playwright install chromium不依赖命令入口安装 chromium 失败或慢网络环境受限查看 pip 输出中的报错信息重试安装国内环境可换用镜像源或手动下载浏览器二进制Agent 找不到目标元素CSS 选择器错误页面在 iframe 中元素动态加载打开 DevTools 查看真实 DOM 结构先用extract_page_text获取页面内容定位改用更稳定的 id 选择器增加显式等待Agent 执行多轮后仍不结束模型没有合理的停止条件工具描述不清开启verboseTrue观察每轮决策优化 tool 的 docstring把大任务拆成子任务适当调低max_iterations模型响应超时或报 provider did not respond in time模型服务端响应过慢或触发限流查看请求日志和状态码更换更快的模型降低多轮调用频率检查接口 Key 配额是否充足Agent 在点击后拿不到最新页面内容页面使用异步更新网络空闲判断失效在点击工具中增加短等待或用wait_for_selector在click_button后将wait_for_load_state改为page.wait_for_selector(#result)等方式定向等待浏览器窗口一闪而过看不到过程headless 模式默认无界面查看调用ensure_page时的 headless 参数调试阶段改为headlessFalse上线再设回 True这里重点说两个容易被忽视的问题。第一networkidle不是万能的。有些页面存在长轮询接口网络永远不空闲goto会一直等待直到超时。遇到这类页面把wait_until改为domcontentloaded再配合page.wait_for_selector()等待关键元素出现。对 Agent 工具来说定向等待比全局网络空闲更可靠。第二模型工具调用格式错误是常态而不是偶然。handle_parsing_errorsTrue已经能解决大部分问题但在生产环境中建议在工具层做更多校验比如参数缺省时给出更友好的默认值。工具返回的错误模型才能理解并修正工具层直接抛出异常模型只能看到一条笼统的报错这对多轮循环没有帮助。9. 从 Demo 到生产Agent 化测试的工程建议Demo 能跑通只是第一步。真正把 Agent 用进测试开发流程有几个工程问题必须提前考虑。第一工具粒度决定 Agent 上限。工具的粒度越细模型决策次数越多越容易出错粒度越粗复用性越差。比较合理的分层是底层保留 Playwright 原生能力点击、输入、提取上层封装面向业务的复合工具登录、搜索、下单。在实际项目中我会建议为频率最高的业务操作单独封装工具比如login(username, password)一步完成填表和提交而不是让模型拆成五个原子动作。稳定性和可维护性都会好很多。第二会话隔离和并发是生产环境的第一道坎。本文示例用全局单例页面只适合单用户单任务。真实环境中多个 Agent 同时跑测试如果共享一个浏览器上下文页面状态会互相污染。生产级方案是每次任务创建独立的浏览器上下文Context任务结束后关闭并通过连接池控制并发数。Playwright 的browser.new_context()天生就是为了隔离会话设计的。第三安全边界必须有。让 Agent 操作真实业务系统之前必须把它的操作范围限制在测试环境或沙箱环境。工具层要做 URL 白名单校验比如navigate_to只允许访问白名单内的域名和端口禁止访问生产系统。同时遵循最小权限原则Agent 使用的账号、测试数据、数据库权限都应该是隔离的不能使用生产账号。这个提醒不是口号而是真实事故换来的教训。第四可观测性决定排查效率。Agent 是概率性系统同样的任务两次执行可能走不同路径。因此日志必须记录完整模型每一次的 Thought、Action、Action Input、Observation工具执行的耗时最终结论。Playwright 自带的 Trace Viewer 对浏览器操作录制非常有用建议在工具封装层加入page.tracing.start()/stop()逻辑出现失败可以回放整个浏览器操作过程比看日志快得多。第五关注 MCP 的发展方向。MCP 是模型上下文协议目标是让模型以标准化方式连接外部工具和服务。Playwright 官方已经提供了 MCP Server这意味着浏览器能力可以被任何支持 MCP 的客户端复用。从架构上讲把 Playwright 封装成 LangChain Tool和把它包装成 MCP Server本质都是“给模型提供浏览器操作能力”只是接口标准不同。如果你在规划长期方案建议两条路线都了解它们并不冲突。第六从测试开发落地的角度我建议分三步走。第一步用本文的 Demo 跑通本地流程确认模型能稳定完成基础页面操作第二步把 Agent 接入现有测试套件从“人工登录 Agent 断言”这种半自动场景开始逐步增加自主操作比例第三步建立回归评测集用固定的一组任务验证每次提示词或工具修改后 Agent 的表现没有退化。Agent 应用和传统应用最大的区别是它没有“改完就能上线”这么简单行为变化需要通过评测集来兜底。10. 总结与后续学习方向这篇文章的核心收获可以概括为三点。第一LangChain 和 Playwright 的组合解决了从“脚本自动化”到“任务自动化”的问题适合探索性测试、冒烟测试和页面信息提取类场景第二一个可运行的 Agent 并不复杂把 Playwright 操作封装成 Tool再交给 ReAct Agent 决策即可难点在于工具粒度的设计和执行过程的稳定性第三生产环境和 Demo 的差距主要在并发隔离、安全边界和可观测性这些需要在架构设计阶段就考虑进去。下一步值得深入的方向有三个。如果任务流程变得复杂比如需要多角色协作、条件回退或人工审批可以学习 LangGraph它比 AgentExecutor 提供更精细的流程控制如果想让 Agent 连接更多工具而不是只有浏览器可以研究 MCP 协议了解工具标准化的收益与成本如果你关心 Agent 在测试领域的效果度量建议尽快搭建一个小型的任务评测集用固定任务反复跑量化提示词修改带来的行为变化。建议把本文示例跑通后立刻换一个你自己业务里的真实页面试试比如内部系统的列表页、表单页那个过程中遇到的坑会比任何教程都更值钱。