基于LLM的智能网页自动化：从原理到实践，构建AI驱动的浏览器智能体

1. 项目概述当AI智能体学会“看”和“点”如果你和我一样常年和自动化脚本打交道肯定对Selenium、Playwright这类工具又爱又恨。爱的是它们确实能解放双手恨的是但凡页面结构一变、元素定位一改脚本就得跟着大修维护成本高得吓人。我们写的脚本本质上是一套极其脆弱的“坐标指令集”它“看不见”页面也“不理解”内容。而agent-browser这个项目给我带来的冲击就像是给盲人配上了眼睛和大脑。它的核心思路非常清晰让大型语言模型LLM来“看”浏览器页面并“思考”下一步该做什么然后驱动浏览器执行。这不再是基于XPath或CSS选择器的脆弱绑定而是基于对页面视觉和语义的理解来做出决策。简单来说你给AI一个目标比如“在电商网站搜索‘无线鼠标’并按价格排序”AI会像真人一样观察页面找到搜索框输入文字点击按钮浏览结果并完成排序操作。这个项目解决的正是传统自动化工具“盲操作”的痛点。它非常适合需要处理动态内容、结构复杂或没有稳定API的网页任务比如数据抓取、跨平台工作流自动化、软件测试尤其是探索性测试、甚至是模拟用户行为进行可用性研究。对于开发者、测试工程师、数据分析师以及任何想将网页操作智能化的从业者来说这都是一扇新世界的大门。2. 核心架构与设计哲学拆解agent-browser不是一个简单的脚本它是一个系统工程。要理解它我们需要先拆解其核心组件和它们之间的协作逻辑。2.1 核心组件交互图景整个系统的运行可以想象成一场由“指挥官”LLM、“观察员”浏览器和“执行官”自动化驱动协同完成的精密任务。观察阶段See自动化驱动如Playwright控制浏览器导航到目标页面并捕获当前状态的“快照”。这个快照不仅仅是DOM更关键的是可视化的截图和经过简化的可交互元素信息如按钮、输入框的文本、位置和类型。这一步相当于把“眼睛看到的东西”格式化。思考与规划阶段Think将快照截图和元素信息与用户指令如“登录”一起构造一个精心设计的提示词Prompt发送给LLM例如GPT-4、Claude或本地部署的Qwen。LLM的角色是分析师和规划师它需要理解页面识别出当前页面是什么登录页、搜索结果页等。分解任务将复杂指令拆解成原子操作步骤如1. 定位用户名输入框2. 输入用户名3. 定位密码输入框……。生成动作为下一步决定一个具体的、可执行的操作。这个操作不是坐标而是一个高级指令比如click(“登录按钮”)或type(“密码输入框”, “myPassword”)。agent-browser会定义一套标准的动作集合。执行与验证阶段Act系统接收到LLM生成的动作指令后需要将其“翻译”成浏览器自动化驱动能理解的低级命令。例如click(“登录按钮”)需要被解析为在当前的元素信息列表中找到文本内容或属性最匹配“登录按钮”的那个元素然后获取其选择器或坐标最终驱动浏览器执行点击。执行后流程回到第1步观察执行后的新页面状态形成“观察-思考-执行”的循环直到任务完成或无法继续。2.2 为什么是“智能体”Agent这里的关键在于“智能体”的定位。它不是一个一次性运行的脚本而是一个具备感知Perception、决策Decision、执行Action能力的自主实体。agent-browser项目实现了智能体与浏览器环境交互的“感知-决策”闭环。感知通过截图和DOM分析获取环境状态。决策利用LLM强大的多模态理解和推理能力对于截图是视觉理解对于文本是语义理解基于当前状态和目标规划出最优的下一步动作。执行通过可靠的底层自动化工具执行动作影响环境。这种架构的优势是巨大的强健性Robustness只要按钮的视觉外观和语义没变即使它的CSS类名从btn-primary改成了btn-submitLLM依然能认出它是“提交按钮”。这极大地降低了维护成本。泛化能力Generalization一个训练好的智能体或者说一个调试好的Prompt可以更容易地迁移到结构类似但不同的网站上执行相同逻辑的任务因为它依赖的是理解而非硬编码。处理不确定性当页面出现意外弹窗、加载缓慢或元素暂时不可见时LLM可以根据截图判断当前状况并可能做出“等待”或“关闭弹窗”的决策这是传统脚本难以优雅处理的。注意这里的“智能体”并非指一个已经训练好的、开箱即用的AI模型而是指一套利用LLM作为核心决策引擎的自动化框架。你需要为它提供LLM API如OpenAI或部署本地模型并精心设计Prompt来引导它完成任务。3. 环境搭建与核心工具链选型要跑通agent-browser你需要一个稳定的技术栈。以下是我基于常见实践推荐的组合和搭建步骤。3.1 基础环境准备首先确保你的开发机满足基本条件操作系统推荐Linux (Ubuntu 20.04) 或 macOS。Windows也可行但可能在某些依赖安装上需要额外步骤。Python版本 ≥ 3.8。建议使用conda或venv创建独立的虚拟环境避免包冲突。# 创建并激活虚拟环境 python -m venv agent-browser-env source agent-browser-env/bin/activate # Linux/macOS # agent-browser-env\Scripts\activate # WindowsNode.js由于底层浏览器自动化工具如Playwright依赖Node环境来安装浏览器请确保已安装Node.js (≥ 14)。Git用于克隆项目仓库。3.2 核心依赖安装与考量agent-browser项目的核心依赖通常包括以下几部分我们需要理解每个部分的选择理由浏览器自动化驱动Playwright为什么是Playwright相较于SeleniumPlaywright由微软开发支持Chromium、Firefox和WebKit三大内核API现代且一致自动等待机制更智能截图和录屏功能强大。对于需要高质量视觉输入的AI智能体来说稳定、快速的页面渲染和截图能力至关重要。Playwright在这方面表现优异。pip install playwright playwright install chromium # 安装Chromium浏览器足够使用AI/LLM交互层OpenAI SDK 或 LlamaIndexOpenAI SDK如果你使用GPT-4、GPT-3.5等OpenAI的模型这是最直接的选择。你需要一个有效的OpenAI API Key。pip install openaiLlamaIndex / LangChain如果你计划使用本地模型如Qwen、Llama或多个模型或者需要更复杂的Prompt管理和记忆功能这类框架提供了更好的抽象。agent-browser的原型可能直接调用OpenAI但生产级应用往往会引入这些框架来增强能力。pip install llama-index图像处理与OCRPillow 和 pytesseract为什么需要虽然LLM可以处理图像但有时将截图中的关键文本通过OCR提取出来作为附加信息提供给LLM可以降低其理解负担提高准确率和速度。Pillow用于基本的图像处理pytesseract是Google Tesseract OCR的Python封装。pip install Pillow pytesseract # 此外还需要系统安装Tesseract OCR引擎 # Ubuntu: sudo apt install tesseract-ocr # macOS: brew install tesseract项目本体与辅助工具克隆agent-browser项目仓库假设项目存在于GitHub。git clone agent-browser-repo-url cd agent-browser pip install -r requirements.txt # 安装项目依赖3.3 LLM接入的关键配置这是整个项目的灵魂。你需要决定使用哪种LLM并正确配置。方案一使用云端API如OpenAI优点简单、稳定、性能强大尤其是GPT-4V具备优秀的视觉理解能力。缺点产生持续费用数据需要出境有网络延迟。配置方法在环境变量或项目配置文件中设置你的API Key。export OPENAI_API_KEYyour-api-key-here在代码中你需要构造包含系统指令System Prompt和用户消息User Message内含截图和任务的请求。系统指令用于定义智能体的角色和行为规范这是Prompt工程的核心。方案二部署本地模型如Qwen-VL优点数据隐私性好无持续调用成本网络延迟低。缺点对硬件要求高需要GPU模型能力可能弱于顶级云端模型需要自行部署和维护。配置方法使用transformers库或模型提供的本地API如通过ollama、vLLM部署。你需要将代码中调用OpenAI API的部分替换为向本地模型服务发送请求。# 示例使用requests调用本地部署的Qwen-VL-Chat API import requests import base64 def ask_local_llm(screenshot_path, prompt_text): with open(screenshot_path, rb) as f: image_data base64.b64encode(f.read()).decode(utf-8) payload { model: qwen-vl-chat, messages: [ {role: system, content: 你是一个网页操作助手...}, {role: user, content: [ {type: text, text: prompt_text}, {type: image_url, image_url: {url: fdata:image/png;base64,{image_data}}} ]} ] } response requests.post(http://localhost:8000/v1/chat/completions, jsonpayload) return response.json()[choices][0][message][content]实操心得模型选择权衡在项目初期验证想法时强烈建议使用GPT-4V视觉版。它在视觉理解和遵循复杂指令方面表现最佳能极大减少调试Prompt的挫败感。当流程跑通后再考虑为成本或隐私原因迁移到本地模型。对于本地模型Qwen-VL-Chat是一个优秀的开源多模态模型选择但需要至少16GB以上的GPU显存才能流畅运行。4. 核心代码解析与实战演练理解了架构和環境我们深入到代码层面看一个核心任务——“在GitHub上搜索agent-browser项目并打开第一个结果”——是如何被实现的。我会基于agent-browser项目的常见模式进行拆解和补充。4.1 任务启动与状态管理智能体的工作是一个循环。我们需要一个主循环函数来驱动“观察-思考-执行”的流程。import asyncio from playwright.async_api import async_playwright import openai from PIL import Image import io # 配置OpenAI客户端 client openai.OpenAI(api_keyos.environ.get(OPENAI_API_KEY)) class BrowserAgent: def __init__(self): self.playwright None self.browser None self.page None self.max_steps 20 # 防止无限循环 self.action_history [] # 记录动作历史可用于提供给LLM作为上下文 async def start(self): 启动浏览器和页面 self.playwright await async_playwright().start() # 使用headed模式便于调试生产环境可改为False self.browser await self.playwright.chromium.launch(headlessFalse, slow_mo100) self.page await self.browser.new_page() await self.page.set_viewport_size({width: 1280, height: 720}) async def observe(self): 观察阶段捕获页面状态 # 1. 截图 screenshot_bytes await self.page.screenshot(typepng, full_pageFalse) # 通常截取可视区域即可 screenshot_image Image.open(io.BytesIO(screenshot_bytes)) # 2. 提取可交互元素信息简化版 # 这里可以调用Playwright获取元素列表并过滤出可交互的button, input, a等 elements await self.page.query_selector_all(button, input, a[href], [rolebutton]) element_info [] for elem in elements[:30]: # 限制数量避免上下文过长 try: text await elem.text_content() or attr_id await elem.get_attribute(id) or attr_placeholder await elem.get_attribute(placeholder) or # 获取粗略位置用于辅助描述非精确点击 box await elem.bounding_box() if box: element_info.append({ text: text.strip(), id: attr_id, placeholder: attr_placeholder, type: await elem.get_attribute(type) or elem.tag_name, position: {x: box[x], y: box[y]} }) except: continue # 元素可能已失效 return screenshot_image, element_info async def think(self, screenshot, elements, objective, history): 思考阶段询问LLM下一步动作 # 将截图转换为base64 buffered io.BytesIO() screenshot.save(buffered, formatPNG) screenshot_b64 base64.b64encode(buffered.getvalue()).decode(utf-8) # 构造Prompt这是最核心的部分 system_prompt 你是一个网页操作智能体。你的目标是通过观察网页截图和可交互元素列表决定下一步操作来完成任务。 你可以执行的操作类型有 1. click([‘元素描述’]) - 点击一个元素。描述应基于其文本、ID、placeholder或类型。 2. type([‘元素描述’], ‘要输入的文字’) - 向输入框输入文字。 3. scroll([‘up’|’down’|’left’|’right’]) - 向指定方向滚动页面。 4. goto(‘url’) - 导航到一个新URL。 5. wait(‘描述性原因’) - 等待一段时间通常用于加载。 6. done() - 任务完成。 请严格按以下格式回复只输出动作指令 动作类型(参数1, 参数2, ...) 例如click([搜索按钮]) 或 type([搜索框], agent-browser) user_prompt f 当前任务目标{objective} 已执行步骤{history[-3:]} 最近3步 当前页面可交互元素格式文本/ID/placeholder - 类型 {chr(10).join([f- {e[text] or e[id] or e[placeholder]} - {e[type]} for e in elements[:15]])} 还有更多元素未列出 请根据以上信息和截图决定下一步操作。只输出动作指令。 try: response client.chat.completions.create( modelgpt-4-vision-preview, # 使用视觉模型 messages[ {role: system, content: system_prompt}, {role: user, content: [ {type: text, text: user_prompt}, {type: image_url, image_url: {url: fdata:image/png;base64,{screenshot_b64}}} ]} ], max_tokens300, temperature0.1 # 低随机性确保指令稳定 ) action_str response.choices[0].message.content.strip() return action_str except Exception as e: print(fLLM调用失败: {e}) return wait(LLM调用失败等待重试) async def act(self, action_str): 执行阶段解析并执行LLM给出的动作 print(f执行动作: {action_str}) self.action_history.append(action_str) # 解析动作字符串这是一个简化的解析器 if action_str.startswith(click): # 提取描述例如从 click([搜索按钮]) 中提取 搜索按钮 import re match re.match(rclick\(\[(.?)\]\), action_str) if match: description match.group(1) # 这里需要实现一个函数根据描述在element_info中找到最匹配的元素并点击 # 这涉及到元素匹配算法是另一个技术难点下文会讲 await self._click_by_description(description) elif action_str.startswith(type): match re.match(rtype\(\[(.?)\], (.?)\), action_str) if match: description, text match.group(1), match.group(2) await self._type_by_description(description, text) elif action_str.startswith(goto): match re.match(rgoto\((.?)\), action_str) if match: url match.group(1) await self.page.goto(url) elif action_str.startswith(scroll): # 解析滚动方向 pass # 实现滚动逻辑 elif action_str done(): return DONE elif action_str.startswith(wait): await asyncio.sleep(3) # 简单等待 else: print(f无法解析的动作: {action_str}) return CONTINUE async def run(self, objective): 主运行循环 await self.start() await self.page.goto(https://github.com) for step in range(self.max_steps): print(f\n--- 步骤 {step1} ---) # 观察 screenshot, elements await self.observe() # 思考 action await self.think(screenshot, elements, objective, self.action_history) # 执行 status await self.act(action) if status DONE: print(任务完成) break await asyncio.sleep(1) # 步骤间短暂间隔 await self.browser.close() await self.playwright.stop() # 运行智能体 async def main(): agent BrowserAgent() await agent.run(在GitHub上搜索‘agent-browser’项目并打开第一个结果) if __name__ __main__: asyncio.run(main())4.2 元素匹配算法连接“思考”与“执行”的桥梁上面代码中留白的_click_by_description和_type_by_description是实现中最棘手也最关键的部分。LLM告诉我们“点击‘搜索按钮’”但Playwright需要的是一个具体的选择器或坐标。如何匹配策略一文本与属性模糊匹配这是最直接的方法。将LLM返回的描述如“搜索按钮”与之前observe()阶段收集到的每个元素的text、id、placeholder等字段进行模糊匹配如使用fuzzywuzzy库或计算Levenshtein距离。from fuzzywuzzy import fuzz async def _find_best_element(self, description, elements): best_score 0 best_element None for elem in elements: # 综合计算描述与元素各个字段的相似度 text_score fuzz.ratio(description, elem[text]) id_score fuzz.ratio(description, elem[id]) placeholder_score fuzz.ratio(description, elem[placeholder]) composite_score max(text_score, id_score * 0.8, placeholder_score * 0.7) # 赋予不同权重 if composite_score best_score and composite_score 60: # 设置阈值 best_score composite_score best_element elem return best_element找到最佳匹配元素后我们可以用其type和text等信息反向构造一个可能的选择器例如button:has-text(“搜索”)再用Playwright定位并操作。策略二利用视觉坐标进阶对于更复杂的场景可以让LLM在返回动作时直接输出要操作元素在截图中的大致坐标区域。这需要更复杂的Prompt设计和多模态模型的支持。例如让LLM以click(x500, y300)的格式回复。然后通过坐标与之前记录的元素位置进行匹配或者直接使用Playwright的page.mouse.click(x, y)进行坐标点击。这种方式更接近人类“指哪打哪”的直觉但对模型要求更高且坐标可能因窗口大小变化而不稳定。实操心得匹配算法的稳定性在实际测试中纯文本模糊匹配在描述准确时如“Sign in按钮”效果很好但对于“第一个结果”、“第三个标签页”这类相对位置描述则完全失效。混合策略往往是必要的优先尝试文本匹配如果失败则在Prompt中明确要求LLM在无法用文本描述时提供基于页面布局的相对位置描述如“左上角区域的蓝色按钮”我们再结合元素位置信息进行二次匹配。这需要大量的Prompt调优和异常处理。5. Prompt工程如何与LLM高效“对话”智能体的智商上限很大程度上取决于你如何设计Prompt。它不是简单的命令而是定义智能体角色、能力和思维模式的“宪法”。5.1 系统提示词System Prompt设计要点系统提示词是给LLM的“入职培训”。一个好的系统提示词应包含角色定义明确告诉LLM“你是谁”。例如“你是一个专业的网页操作自动化助手能够理解网页截图并生成精确的操作指令来完成用户任务。”能力范围清晰列出所有可用的动作类型及其格式就像我们之前代码中那样。这限定了LLM的输出空间使其行为可控。思考链Chain-of-Thought引导鼓励LLM在输出最终动作前先进行内部推理。虽然我们可能只取最终指令但在Prompt中要求它“先简要分析当前页面状态和任务进度再决定下一步”能显著提高决策质量。对于高级模型可以要求它以Thought: ... Action: ...的格式回复。约束与规范输出格式严格规定只输出指定格式的指令不能有任何解释性文字。安全边界明确禁止执行某些操作如导航到非任务相关网站、输入个人敏感信息等。错误处理指示当页面状态与预期不符如元素找不到、页面卡住时应优先尝试wait或scroll而不是盲目操作。5.2 用户提示词User Prompt的信息组织用户提示词是每次循环递给LLM的“当前情况简报”。它必须高效传递信息任务目标Objective始终清晰重申当前总目标。近期历史History提供最近几步动作让LLM知道进展到哪了避免重复或倒退。当前状态Current State以结构化文本形式列出关键元素信息。列表不宜过长应过滤掉无关或重复元素。可以按类型按钮、输入框、链接分组。截图Screenshot作为多模态输入的一部分提供最直观的视觉信息。一个优化的用户Prompt模板示例任务{objective} 上一步操作{last_action} 当前页面关键交互元素 - [按钮] “Search GitHub” (placeholder: “Search GitHub”) - [链接] “Sign in” - [输入框] “用户名或邮箱地址” (id: “login_field”) - [输入框] “密码” (id: “password”) - [按钮] “Sign in” (type: “submit”) 请根据截图和以上元素列表决定下一步操作以推进任务。只输出动作指令。5.3 针对复杂任务的Prompt进阶技巧对于“打开第一个结果”这类需要理解和排序的任务简单的元素列表就不够了。你需要引导LLM进行更复杂的推理。技巧要求LLM描述性识别在用户Prompt中可以加入“如果你需要操作一个列表中的特定项如‘第一个结果’请在动作指令的描述部分尽可能使用该项目的独特文本内容来指代它。例如如果你看到搜索结果第一个条目是‘agent-browser/Awesome-WebAutomation’请使用click([‘agent-browser/Awesome-WebAutomation’])而不是click([‘第一个结果’])。” 这迫使LLM先进行视觉识别和文本提取将相对位置转换为绝对标识从而方便下游的元素匹配。技巧分阶段任务分解对于非常长的任务如“注册账号并完成个人资料设置”不要指望一个智能体循环从头跑到尾。更好的做法是分层用一个“主控智能体”将大任务分解为“搜索项目”、“进入仓库”、“查看README”等子任务然后为每个子任务启动或切换到一个更专注的“子任务智能体”。这可以通过在系统Prompt中定义子任务调用机制来实现类似于AI Agent中的“工具调用”Function Calling。6. 常见问题、调试技巧与优化策略在实际搭建和运行过程中你会遇到各种各样的问题。以下是我踩过坑后总结的一些核心问题和解决方案。6.1 LLM相关问题问题现象可能原因排查与解决思路动作指令格式错误Prompt中对输出格式强调不够模型温度temperature参数过高。1. 在System Prompt中用更强烈的语言约束格式如“你必须且只能输出以下格式之一的指令...”。2. 将temperature降至0.1或0减少随机性。3. 在代码中添加指令格式校验若不符合则重新提问或使用默认安全动作如wait。LLM无法识别页面元素截图不清晰或关键区域未截取元素列表信息太少模型视觉能力不足。1. 确保截图清晰且截取了整个可视区域full_pageFalse有时会漏掉底部内容。2. 丰富元素列表信息加入aria-label、name等属性。3. 升级到更强的视觉模型如GPT-4V。4. 在Prompt中要求LLM先描述它看到的页面再输出动作这能激活其视觉分析能力。任务陷入循环或无关操作目标不明确缺乏足够的上下文记忆。1. 在每次User Prompt中都清晰重复最终目标。2. 增加action_history的长度提供更多历史步骤作为上下文。3. 引入“反思”机制当连续几步操作未改变页面关键状态时强制让LLM输出wait(似乎卡住了重新评估)或触发人工干预。API调用超时或限速网络问题免费额度用尽请求频率过高。1. 增加请求超时时间和重试逻辑。2. 监控Token使用量优化Prompt长度。3. 在步骤间添加await asyncio.sleep(1)降低请求频率。6.2 浏览器与执行相关问题问题现象可能原因排查与解决思路元素匹配失败点击错误模糊匹配阈值设置不当页面动态加载导致元素信息过时。1. 调试匹配算法打印出所有元素的匹配分数调整阈值和权重。2. 在执行动作前重新获取一次目标元素的实时状态element.is_visible()。3. 采用更稳健的定位策略优先使用id其次是text最后是placeholder和坐标。页面加载缓慢导致操作提前Playwright的自动等待对AI生成的操作无效。在act函数中在执行关键操作如click后跳转后强制等待页面进入一个稳定状态await self.page.wait_for_load_state(networkidle)。弹窗或验证码中断流程未预料到的页面状态变化。1. 在observe阶段增加对常见弹窗选择器如div[rolealert]的检测并将其信息加入元素列表让LLM决定是否关闭。2. 对于验证码目前纯视觉方案很难解决需要引入人工处理或第三方打码服务作为“后备工具”。6.3 性能与成本优化截图优化不一定每次都需要全分辨率截图。可以尝试压缩图片质量如85%、只截取屏幕部分区域、或先转换为灰度图以减少传递给LLM的数据量降低Token消耗和延迟。元素信息过滤在observe阶段只收集可见的、大概率可交互的元素。过滤掉display: none或尺寸为0的元素。这能缩短Prompt长度帮助LLM更聚焦。缓存与记忆对于在多步骤中重复出现的静态元素如导航栏可以缓存其定位信息避免每次循环都重新匹配。本地模型微调如果使用本地模型可以考虑用自己常见的网页操作数据对模型进行轻量级微调LoRA使其更擅长理解网页结构和生成操作指令。这能大幅提升在特定领域任务上的准确率。7. 超越基础智能体能力的扩展想象agent-browser的基本框架打通后它的潜力远不止于简单的线性任务。我们可以从以下几个方向扩展其能力1. 多智能体协作Multi-Agent Collaboration想象一个场景一个“导航智能体”负责在网站间跳转和寻找目标页面一个“表单填写智能体”专门处理各种输入框一个“数据提取智能体”负责从结果页中识别并结构化所需信息。它们通过一个“协调员”来共享状态和分配任务可以处理极其复杂的跨页面、多步骤工作流。2. 集成外部工具与知识Tool Augmentation让智能体不仅能操作浏览器还能调用外部API。例如在填写地址时调用地图API补全信息在遇到专业术语时查询内部知识库将抓取到的数据直接存入数据库或发送到消息队列。这可以通过在Prompt中定义“工具”并让LLM学会“调用”来实现类似于OpenAI的Function Calling。3. 强化学习与长期记忆Long-term Memory目前的智能体是“无状态”的每次交互都相对独立。我们可以为智能体引入记忆机制让它记住过去成功或失败的经验。例如将状态动作结果三元组存储下来当下次遇到类似状态时可以优先尝试历史上成功的动作或避免失败的动作。这为走向更自主的学习型智能体奠定了基础。4. 用于自动化测试与监控这是非常落地的应用场景。可以训练智能体模拟用户进行探索性测试Exploratory Testing随机或按一定策略浏览应用寻找界面错误、功能缺陷或性能问题。也可以让智能体定期执行关键业务流程如登录、下单进行生产环境的监控和告警。搭建agent-browser这样的项目最大的收获不是完成了一个自动化工具而是亲身实践了一种全新的、以“理解”而非“坐标”为核心的人机交互范式。它仍然不完美匹配算法会出错LLM的理解有时会“跑偏”处理复杂逻辑和异常情况的能力还很有限。但它的方向无疑是激动人心的。当你看到AI第一次独立地、像人一样在网页上完成任务时那种感觉就像在早期互联网时代第一次写出了一个能自动登录论坛的脚本一样充满了可能性。我个人的体会是现阶段它最适合作为“副驾驶”处理那些规则模糊、但模式相对固定的任务由人类进行高阶监督和兜底。随着多模态模型和Agent框架的快速发展这个“副驾驶”的能力边界正在以我们看得见的速度扩张。