1. 项目概述为什么我们需要一个韩语广度搜索基准最近在跟几个做Web智能体Web Agents和自动化测试的朋友聊天大家普遍反映一个痛点评估一个智能体在真实网页上“找东西”的能力尤其是那种需要穷举式、地毯式搜索的场景非常困难。现有的基准测试比如WebArena、Mind2Web更多是聚焦在任务完成度、导航步骤优化上但对于“在一个结构复杂、信息量巨大的韩语网站上不遗漏任何一个目标项”这种需求缺乏一个专门的、高标准的“考场”。这就是“Ko-WideSearch”这个基准诞生的背景。简单来说它就是一个专门为Web智能体设计的“韩语广度搜索能力测试”。它的核心任务不是完成一个具体的下单或填表操作而是执行“集合枚举”——比如给定一个韩国电商网站要求智能体找出所有“价格在10万韩元以下的蓝牙耳机”或者在一个韩国新闻门户中找出所有“今日发布的、含有‘AI’关键词的科技类报道”。智能体需要像一位最有耐心的调查员遍历所有可能的筛选条件、翻页、分类标签确保没有一个符合条件的项目被遗漏。这个基准之所以重要是因为它直击了智能体在实际应用中的一个关键能力维度完备性。在信息检索、竞品分析、数据抓取合规化如公开信息聚合等场景下漏掉一个关键条目可能导致决策失误。而韩语网站因其独特的语言特性如复杂的敬语体系、空格使用规则、大量合成词、页面布局习惯例如Naver、Daum等门户的密集信息流以及常见的动态加载技术对智能体的鲁棒性和理解力提出了更特殊的挑战。Ko-WideSearch正是为了量化并提升智能体在这种特定环境下的“搜刮”能力而设计的。2. 核心设计思路如何构建一个“穷举”的考场构建一个有效的广度搜索基准远比构建一个任务完成基准要复杂。你不能只是扔给智能体一个网站和一句指令然后看结果。因为“是否穷尽”这个标准本身就需要一个绝对正确的“答案集”来对照。Ko-WideSearch的设计思路体现了对这个问题系统性的思考。2.1 任务定义与评估指标首先它明确定义了“集合枚举”任务给定一个起始URL、一个自然语言描述的目标集合定义智能体需要与网页交互最终输出一个目标项的列表。例如“从这个化妆品品牌官网的产品列表页开始找出所有适用于‘干性皮肤’的‘精华液’产品。”评估的核心指标围绕“完备性”和“效率”展开召回率这是最重要的指标。召回率 (智能体找到的正确项数) / (基准中存在的总正确项数)。目标是让这个比例尽可能接近100%。任何遗漏都会直接导致扣分。精确率精确率 (智能体找到的正确项数) / (智能体找到的总项数)。这防止智能体通过“滥竽充数”比如把乳液也当成精华液来刷高召回率。F1分数召回率和精确率的调和平均数是一个综合性的单一指标。交互步骤数完成搜索所执行的操作点击、输入、滚动等总数。在保证召回率和精确率的前提下步骤越少说明智能体的搜索策略越高效。耗时从任务开始到输出列表的总时间。这是一个辅助性的效率指标。注意与导航任务不同这里不强调“任务是否完成”因为任务本身就是“找到所有”。关键在于“找到的有多全”和“找的过程有多聪明”。2.2 环境构建与“黄金答案”获取这是构建基准最耗时、也最需要技巧的部分。Ko-WideSearch没有使用完全虚拟的模拟环境而是基于真实的韩语网站快照构建了一个可控的离线环境。这样做的好处是保留了真实网页的复杂性和“噪音”包括那些让智能体头疼的动态元素、非标准组件和韩语特有的文本布局。网站选择覆盖多种类型如电商Coupang, Gmarket、门户新闻Naver News, Daum、社区论坛DC Inside, Nate Pann、政府公开信息网站等。每种类型对搜索模式的要求不同。快照与容器化将目标网站的特定部分如某个品类的产品列表、某个论坛版块完整爬取下来包括HTML、CSS、JavaScript和图片资源然后封装成一个本地的、可交互的Web服务。智能体与这个本地服务交互避免了因网络波动或网站改版带来的测试不稳定问题。“黄金答案”标注这是基准的“标准答案”。研究人员需要手动或通过可靠的自动化脚本在快照环境中彻底地找出所有符合任务描述的目标项并记录下每一项的唯一标识如产品ID、文章链接、数据行索引。这个过程必须极其严谨因为它是评估智能体的唯一准绳。通常一个任务会由多人交叉验证以确保答案集的绝对正确。2.3 任务难度分级为了让基准更具区分度Ko-WideSearch将任务分为多个难度等级简单级目标项集中在同一页面无需翻页或只需简单点击“下一页”。例如“在本页面列出所有红色封面的书籍”。中级需要结合筛选条件如下拉菜单选择“品牌”、滑动条选择“价格区间”并进行多页遍历。韩语网站的表单控件和筛选逻辑是测试重点。困难级目标项可能分布在网站的不同分区或需要通过搜索框进行关键词组合查询才能触达。需要智能体理解韩语同义词、相关词并制定复杂的探索策略。例如“找出所有关于‘元宇宙’和‘数字资产’的研讨会信息”智能体可能需要先尝试‘메타버스’元宇宙再尝试‘가상자산’数字资产并理解两者间的关联。3. 关键技术挑战与智能体能力要求要在Ko-WideSearch上取得好成绩一个Web智能体需要跨越以下几座大山这些也正是该基准希望引导技术发展的方向。3.1 韩语自然语言理解与指令跟随任务指令是自然语言描述的智能体必须准确理解韩语指令的细微之处。形态学复杂性韩语是黏着语动词和形容词的词尾变化极其丰富。一个“找”的动作根据语境和尊敬程度可能有多种表达。智能体需要理解指令的核心意图而不被表面形式迷惑。空格与分词韩语书写中空格规则比较灵活有时复合词连写有时分开写。例如“人工智能”可以是“인공지능”连写也可能是“인공 지능”分写。这直接影响搜索关键词的输入。同义词与上下文例如指令中的“휴대폰”手机可能在网页上被标记为“스마트폰”智能手机或特定品牌名。智能体需要具备一定的领域常识或从页面上下文中推断等价关系。实操心得在训练或提示Prompting智能体时融入韩语语言模型如KoGPT、KULLM进行指令解析和关键词扩展是有效的策略。不要仅仅依赖简单的关键词匹配。3.2 对复杂网页结构的鲁棒性探索韩语网站尤其是大型门户和电商页面结构可能非常复杂且动态。动态加载无限滚动、点击“更多”按钮加载、选项卡Tab切换内容等非常普遍。智能体不能只解析初始HTML必须能够触发并等待这些动态内容加载。非标准UI组件很多网站使用自定义的UI库其DOM结构可能不遵循常见的ARIA标签或标准HTML元素语义。智能体需要能够基于视觉特征、类名模式或相对位置来识别可交互元素。多层级导航目标项可能藏在很深的目录层级下。智能体需要有一种“探索意识”当在当前层级找不到足够项或感觉未穷尽时应尝试点击可能的分类链接、面包屑导航或侧边栏菜单。常见问题与排查智能体经常卡在“认为已经到底”但实际上还有“加载更多”按钮的情况。一个实用的技巧是在智能体的动作循环中加入“滚动到底部并等待2-3秒”的例行检查并检测页面高度或元素数量的变化以此判断是否有新内容加载。3.3 状态跟踪与去重策略这是实现“穷举”和保证“精确率”的核心。已访问状态管理智能体必须记录哪些页面、哪些筛选条件组合已经尝试过避免陷入循环比如在“价格从低到高”和“价格从高到低”之间来回切换。项级去重同一个目标项可能因为网站推荐逻辑或缓存问题在不同页面或不同排序下重复出现。智能体在收集项时必须基于一个稳定的唯一标识如>import asyncio from playwright.async_api import async_playwright from typing import Set, List import hashlib class WideSearchAgent: def __init__(self, task_instruction: str, start_url: str): self.task task_instruction self.start_url start_url self.visited_urls: Set[str] set() # 已访问URL self.collected_items: Set[str] set() # 已收集项ID/指纹 self.item_data: List[dict] [] # 收集的完整项数据 self.action_queue [] # 待执行动作队列 # 初始化浏览器 self.playwright await async_playwright().start() self.browser await self.playwright.chromium.launch(headlessFalse) # 调试时可设为True self.context await self.browser.new_context(viewport{width: 1280, height: 720}) self.page await self.context.new_page()指令解析与初始规划利用LLM这里简化展示思路实际中需要设计详细的Prompt来引导LLM输出结构化动作。async def plan_initial_actions(self): # 构建一个Prompt让LLM根据任务和起始URL给出初步策略 prompt f 你是一个网页浏览智能体。你的任务是{self.task} 起始页面是{self.start_url} 请给出为了完成这个“找出所有符合条件项”的任务你打算采取的前3个具体动作步骤。 输出格式为JSON列表每个动作包含 action_type (如 navigate, click, type, scroll) 和 selector 或 value。 # 调用LLM API (例如OpenAI GPT, Claude) # response await call_llm_api(prompt) # initial_actions parse_json(response) # self.action_queue.extend(initial_actions) # 示例性手动添加初始动作 self.action_queue.append({action_type: navigate, url: self.start_url})页面感知与项提取基于已知结构的规则提取假设我们测试的是一个电商网站产品卡有固定的CSS类名.product-item。async def extract_items_from_page(self): # 等待页面主要内容稳定 await self.page.wait_for_load_state(networkidle) # 方法1使用Playwright内置选择器快速获取所有产品卡元素 product_cards await self.page.query_selector_all(.product-item) extracted [] for card in product_cards: # 提取关键信息 title await card.inner_text(.product-title) or price await card.inner_text(.product-price) or item_link await card.get_attribute(href) # 假设链接在产品卡上 # 生成唯一指纹使用标题和链接的组合哈希 item_fingerprint hashlib.md5(f{title}_{item_link}.encode()).hexdigest() if item_fingerprint not in self.collected_items: # 这里可以加入更复杂的逻辑用LLM判断此产品是否完全符合任务描述 # 例如任务要求“红色口红”需要判断title或图片是否包含红色信息 # is_target await self.llm_judge_if_target(title, price, ...) # if is_target: self.collected_items.add(item_fingerprint) extracted.append({ fingerprint: item_fingerprint, title: title, price: price, link: item_link }) return extracted探索链接发现与队列管理async def discover_new_actions(self): 从当前页面发现新的可探索动作如翻页、筛选按钮并加入队列 # 1. 查找“下一页”按钮 next_page_buttons await self.page.query_selector_all(a:has-text(다음), button:has-text()) for btn in next_page_buttons: href await btn.get_attribute(href) action_url urljoin(self.page.url, href) if href else None if action_url and action_url not in self.visited_urls: self.action_queue.append({action_type: navigate, url: action_url}) # 2. 查找可能的筛选器例如按品牌、价格筛选 # 这需要更复杂的逻辑可能基于常见的筛选器类名或文本模式 filter_buttons await self.page.query_selector_all([roletab], .filter-option, .sort-option) for filter_btn in filter_buttons: btn_text await filter_btn.inner_text() # 判断这个筛选器是否与任务相关例如任务关于“品牌A”按钮文本是“品牌A” # 这里可以集成LLM进行简单判断 if self.is_filter_relevant(btn_text): action_id fclick_filter_{btn_text} if action_id not in self.visited_actions: # 记录已尝试的筛选组合 self.action_queue.append({action_type: click, selector: self._get_selector(filter_btn)}) self.visited_actions.add(action_id)主控制循环async def run_search(self): await self.page.goto(self.start_url) self.visited_urls.add(self.start_url) no_new_item_rounds 0 MAX_NO_NEW_ROUNDS 3 # 连续3轮无新项则终止 while no_new_item_rounds MAX_NO_NEW_ROUNDS: if not self.action_queue: # 尝试从当前页面发现新动作 await self.discover_new_actions() if not self.action_queue: break # 无新动作可探索终止 # 执行队列中的一个动作 action self.action_queue.pop(0) executed await self.execute_action(action) if executed: # 提取当前页面的项 new_items await self.extract_items_from_page() if new_items: self.item_data.extend(new_items) no_new_item_rounds 0 # 重置计数器 print(f发现 {len(new_items)} 个新项) else: no_new_item_rounds 1 # 执行后再次发现当前页面的潜在新动作 await self.discover_new_actions() print(f搜索终止。共找到 {len(self.item_data)} 个唯一项。) return self.item_data4.3 参数调优与性能考量等待策略page.wait_for_load_state(networkidle)是一个好的起点但对于重度依赖JavaScript渲染的网站可能需要结合page.wait_for_selector等待特定内容区域出现。并发与速度广度搜索可能涉及大量页面。需要平衡浏览器实例数量、系统资源和网站反爬策略。通常单个智能体顺序执行足够用于基准测试。在生产环境可能需要分布式队列。错误处理与重试网络超时、元素定位失败是常事。必须在关键动作如点击翻页周围添加重试机制和超时处理避免因单次失败导致整个任务中断。资源清理及时关闭不再使用的页面和浏览器上下文防止内存泄漏。5. 在Ko-WideSearch上评估与改进智能体当你按照上述方案实现了一个基础智能体后就可以在Ko-WideSearch基准上运行测试了。基准通常会提供一个标准化的评估脚本和一组任务定义文件。5.1 评估流程获取基准从指定仓库下载Ko-WideSearch基准里面包含了各个任务的环境快照可能是Docker镜像或本地HTML文件和对应的“黄金答案”文件。配置智能体接口你的智能体需要实现一个标准的接口例如一个run(task_instruction, start_url)函数它最终返回一个目标项列表。运行评估脚本基准的评估脚本会依次加载每个任务环境调用你的智能体并将智能体输出的列表与“黄金答案”进行比较计算召回率、精确率、F1、步骤数等指标。分析结果查看详细的评估报告不仅看总分更要看分任务、分难度等级的表现。这能帮你定位智能体的薄弱环节。5.2 典型问题分析与调优方向根据在类似基准上的经验智能体常出现以下问题及对策问题现象可能原因调优方向召回率低漏项多1. 动态内容未加载。2. 筛选条件未尝试完全。3. 对“目标项”的定义理解偏差NLP问题。4. 分页逻辑识别错误提前终止。1. 强化动态加载检测滚动监听、网络请求监控。2. 实现更系统的筛选空间探索算法如BFS遍历筛选组合。3. 改进指令解析Prompt或引入少量样本进行In-context Learning。4. 改进翻页终止判断结合“下一页”按钮状态和页面内容变化。精确率低错项多1. 项提取规则过于宽泛抓取了相似但非目标项。2. 去重逻辑不完善同一项因信息微调被重复计算。1. 在规则提取后增加一个LLM过滤层对每个候选项进行二分类判断。2. 优化指纹生成算法聚焦于更稳定的标识如数据库ID或使用语义相似度进行模糊去重。步骤数/耗时过高1. 探索策略低效重复访问相同状态。2. 动作执行后等待时间过长。3. 进行了大量无关的探索。1. 加强visited_urls和visited_actions的状态管理使用更细粒度的状态哈希。2. 根据页面类型动态调整等待超时列表页可稍短详情页需保证加载完整。3. 让规划模块LLM在更高层次指导探索方向减少盲目点击。在特定网站类型失败对该类网站的UI模式、交互习惯不熟悉。引入网站特定适配器。例如为电商、新闻、论坛分别编写一套常用的元素定位模式和探索策略模板。这属于“领域知识”的注入。5.3 进阶技巧利用视觉与混合信号纯基于DOM的方法在面对高度定制化UI时可能失效。一个强大的智能体应该能利用视觉信息。视觉元素定位使用基于CV的模型如Grounding DINO或Playwright的截图功能结合LLM的视觉理解能力来定位和识别那些没有清晰语义标签的按钮比如一个图标表示的“筛选”按钮。布局理解通过页面截图让LLM-Vision模型理解整体布局“哪里是侧边栏哪里是主内容区哪里是分页控件”从而生成更合理的探索计划。混合信号决策结合DOM文本、元素属性和视觉位置信息共同判断一个元素是否可点击、是否是一个产品卡片。这能极大提升对“非标准”网站的鲁棒性。我个人在实际操作中的体会是构建一个在Ko-WideSearch这类基准上表现优异的智能体是一个典型的“系统工程”。它不仅仅是调用一个强大的LLM API那么简单更需要精心设计状态管理、探索策略、错误恢复等传统软件工程和算法逻辑。LLM更像是一个“大脑”负责高层的理解和规划而一个健壮的“神经系统”交互、感知、控制循环同样至关重要。从简单的规则提取器开始逐步引入LLM增强理解再结合视觉信息是一个稳妥的迭代路径。每次在基准上测试后仔细分析失败案例往往能发现智能体逻辑中那些意想不到的盲点这才是提升的关键。 构建韩语网站广度搜索智能体：从原理到工程实践
1. 项目概述为什么我们需要一个韩语广度搜索基准最近在跟几个做Web智能体Web Agents和自动化测试的朋友聊天大家普遍反映一个痛点评估一个智能体在真实网页上“找东西”的能力尤其是那种需要穷举式、地毯式搜索的场景非常困难。现有的基准测试比如WebArena、Mind2Web更多是聚焦在任务完成度、导航步骤优化上但对于“在一个结构复杂、信息量巨大的韩语网站上不遗漏任何一个目标项”这种需求缺乏一个专门的、高标准的“考场”。这就是“Ko-WideSearch”这个基准诞生的背景。简单来说它就是一个专门为Web智能体设计的“韩语广度搜索能力测试”。它的核心任务不是完成一个具体的下单或填表操作而是执行“集合枚举”——比如给定一个韩国电商网站要求智能体找出所有“价格在10万韩元以下的蓝牙耳机”或者在一个韩国新闻门户中找出所有“今日发布的、含有‘AI’关键词的科技类报道”。智能体需要像一位最有耐心的调查员遍历所有可能的筛选条件、翻页、分类标签确保没有一个符合条件的项目被遗漏。这个基准之所以重要是因为它直击了智能体在实际应用中的一个关键能力维度完备性。在信息检索、竞品分析、数据抓取合规化如公开信息聚合等场景下漏掉一个关键条目可能导致决策失误。而韩语网站因其独特的语言特性如复杂的敬语体系、空格使用规则、大量合成词、页面布局习惯例如Naver、Daum等门户的密集信息流以及常见的动态加载技术对智能体的鲁棒性和理解力提出了更特殊的挑战。Ko-WideSearch正是为了量化并提升智能体在这种特定环境下的“搜刮”能力而设计的。2. 核心设计思路如何构建一个“穷举”的考场构建一个有效的广度搜索基准远比构建一个任务完成基准要复杂。你不能只是扔给智能体一个网站和一句指令然后看结果。因为“是否穷尽”这个标准本身就需要一个绝对正确的“答案集”来对照。Ko-WideSearch的设计思路体现了对这个问题系统性的思考。2.1 任务定义与评估指标首先它明确定义了“集合枚举”任务给定一个起始URL、一个自然语言描述的目标集合定义智能体需要与网页交互最终输出一个目标项的列表。例如“从这个化妆品品牌官网的产品列表页开始找出所有适用于‘干性皮肤’的‘精华液’产品。”评估的核心指标围绕“完备性”和“效率”展开召回率这是最重要的指标。召回率 (智能体找到的正确项数) / (基准中存在的总正确项数)。目标是让这个比例尽可能接近100%。任何遗漏都会直接导致扣分。精确率精确率 (智能体找到的正确项数) / (智能体找到的总项数)。这防止智能体通过“滥竽充数”比如把乳液也当成精华液来刷高召回率。F1分数召回率和精确率的调和平均数是一个综合性的单一指标。交互步骤数完成搜索所执行的操作点击、输入、滚动等总数。在保证召回率和精确率的前提下步骤越少说明智能体的搜索策略越高效。耗时从任务开始到输出列表的总时间。这是一个辅助性的效率指标。注意与导航任务不同这里不强调“任务是否完成”因为任务本身就是“找到所有”。关键在于“找到的有多全”和“找的过程有多聪明”。2.2 环境构建与“黄金答案”获取这是构建基准最耗时、也最需要技巧的部分。Ko-WideSearch没有使用完全虚拟的模拟环境而是基于真实的韩语网站快照构建了一个可控的离线环境。这样做的好处是保留了真实网页的复杂性和“噪音”包括那些让智能体头疼的动态元素、非标准组件和韩语特有的文本布局。网站选择覆盖多种类型如电商Coupang, Gmarket、门户新闻Naver News, Daum、社区论坛DC Inside, Nate Pann、政府公开信息网站等。每种类型对搜索模式的要求不同。快照与容器化将目标网站的特定部分如某个品类的产品列表、某个论坛版块完整爬取下来包括HTML、CSS、JavaScript和图片资源然后封装成一个本地的、可交互的Web服务。智能体与这个本地服务交互避免了因网络波动或网站改版带来的测试不稳定问题。“黄金答案”标注这是基准的“标准答案”。研究人员需要手动或通过可靠的自动化脚本在快照环境中彻底地找出所有符合任务描述的目标项并记录下每一项的唯一标识如产品ID、文章链接、数据行索引。这个过程必须极其严谨因为它是评估智能体的唯一准绳。通常一个任务会由多人交叉验证以确保答案集的绝对正确。2.3 任务难度分级为了让基准更具区分度Ko-WideSearch将任务分为多个难度等级简单级目标项集中在同一页面无需翻页或只需简单点击“下一页”。例如“在本页面列出所有红色封面的书籍”。中级需要结合筛选条件如下拉菜单选择“品牌”、滑动条选择“价格区间”并进行多页遍历。韩语网站的表单控件和筛选逻辑是测试重点。困难级目标项可能分布在网站的不同分区或需要通过搜索框进行关键词组合查询才能触达。需要智能体理解韩语同义词、相关词并制定复杂的探索策略。例如“找出所有关于‘元宇宙’和‘数字资产’的研讨会信息”智能体可能需要先尝试‘메타버스’元宇宙再尝试‘가상자산’数字资产并理解两者间的关联。3. 关键技术挑战与智能体能力要求要在Ko-WideSearch上取得好成绩一个Web智能体需要跨越以下几座大山这些也正是该基准希望引导技术发展的方向。3.1 韩语自然语言理解与指令跟随任务指令是自然语言描述的智能体必须准确理解韩语指令的细微之处。形态学复杂性韩语是黏着语动词和形容词的词尾变化极其丰富。一个“找”的动作根据语境和尊敬程度可能有多种表达。智能体需要理解指令的核心意图而不被表面形式迷惑。空格与分词韩语书写中空格规则比较灵活有时复合词连写有时分开写。例如“人工智能”可以是“인공지능”连写也可能是“인공 지능”分写。这直接影响搜索关键词的输入。同义词与上下文例如指令中的“휴대폰”手机可能在网页上被标记为“스마트폰”智能手机或特定品牌名。智能体需要具备一定的领域常识或从页面上下文中推断等价关系。实操心得在训练或提示Prompting智能体时融入韩语语言模型如KoGPT、KULLM进行指令解析和关键词扩展是有效的策略。不要仅仅依赖简单的关键词匹配。3.2 对复杂网页结构的鲁棒性探索韩语网站尤其是大型门户和电商页面结构可能非常复杂且动态。动态加载无限滚动、点击“更多”按钮加载、选项卡Tab切换内容等非常普遍。智能体不能只解析初始HTML必须能够触发并等待这些动态内容加载。非标准UI组件很多网站使用自定义的UI库其DOM结构可能不遵循常见的ARIA标签或标准HTML元素语义。智能体需要能够基于视觉特征、类名模式或相对位置来识别可交互元素。多层级导航目标项可能藏在很深的目录层级下。智能体需要有一种“探索意识”当在当前层级找不到足够项或感觉未穷尽时应尝试点击可能的分类链接、面包屑导航或侧边栏菜单。常见问题与排查智能体经常卡在“认为已经到底”但实际上还有“加载更多”按钮的情况。一个实用的技巧是在智能体的动作循环中加入“滚动到底部并等待2-3秒”的例行检查并检测页面高度或元素数量的变化以此判断是否有新内容加载。3.3 状态跟踪与去重策略这是实现“穷举”和保证“精确率”的核心。已访问状态管理智能体必须记录哪些页面、哪些筛选条件组合已经尝试过避免陷入循环比如在“价格从低到高”和“价格从高到低”之间来回切换。项级去重同一个目标项可能因为网站推荐逻辑或缓存问题在不同页面或不同排序下重复出现。智能体在收集项时必须基于一个稳定的唯一标识如>import asyncio from playwright.async_api import async_playwright from typing import Set, List import hashlib class WideSearchAgent: def __init__(self, task_instruction: str, start_url: str): self.task task_instruction self.start_url start_url self.visited_urls: Set[str] set() # 已访问URL self.collected_items: Set[str] set() # 已收集项ID/指纹 self.item_data: List[dict] [] # 收集的完整项数据 self.action_queue [] # 待执行动作队列 # 初始化浏览器 self.playwright await async_playwright().start() self.browser await self.playwright.chromium.launch(headlessFalse) # 调试时可设为True self.context await self.browser.new_context(viewport{width: 1280, height: 720}) self.page await self.context.new_page()指令解析与初始规划利用LLM这里简化展示思路实际中需要设计详细的Prompt来引导LLM输出结构化动作。async def plan_initial_actions(self): # 构建一个Prompt让LLM根据任务和起始URL给出初步策略 prompt f 你是一个网页浏览智能体。你的任务是{self.task} 起始页面是{self.start_url} 请给出为了完成这个“找出所有符合条件项”的任务你打算采取的前3个具体动作步骤。 输出格式为JSON列表每个动作包含 action_type (如 navigate, click, type, scroll) 和 selector 或 value。 # 调用LLM API (例如OpenAI GPT, Claude) # response await call_llm_api(prompt) # initial_actions parse_json(response) # self.action_queue.extend(initial_actions) # 示例性手动添加初始动作 self.action_queue.append({action_type: navigate, url: self.start_url})页面感知与项提取基于已知结构的规则提取假设我们测试的是一个电商网站产品卡有固定的CSS类名.product-item。async def extract_items_from_page(self): # 等待页面主要内容稳定 await self.page.wait_for_load_state(networkidle) # 方法1使用Playwright内置选择器快速获取所有产品卡元素 product_cards await self.page.query_selector_all(.product-item) extracted [] for card in product_cards: # 提取关键信息 title await card.inner_text(.product-title) or price await card.inner_text(.product-price) or item_link await card.get_attribute(href) # 假设链接在产品卡上 # 生成唯一指纹使用标题和链接的组合哈希 item_fingerprint hashlib.md5(f{title}_{item_link}.encode()).hexdigest() if item_fingerprint not in self.collected_items: # 这里可以加入更复杂的逻辑用LLM判断此产品是否完全符合任务描述 # 例如任务要求“红色口红”需要判断title或图片是否包含红色信息 # is_target await self.llm_judge_if_target(title, price, ...) # if is_target: self.collected_items.add(item_fingerprint) extracted.append({ fingerprint: item_fingerprint, title: title, price: price, link: item_link }) return extracted探索链接发现与队列管理async def discover_new_actions(self): 从当前页面发现新的可探索动作如翻页、筛选按钮并加入队列 # 1. 查找“下一页”按钮 next_page_buttons await self.page.query_selector_all(a:has-text(다음), button:has-text()) for btn in next_page_buttons: href await btn.get_attribute(href) action_url urljoin(self.page.url, href) if href else None if action_url and action_url not in self.visited_urls: self.action_queue.append({action_type: navigate, url: action_url}) # 2. 查找可能的筛选器例如按品牌、价格筛选 # 这需要更复杂的逻辑可能基于常见的筛选器类名或文本模式 filter_buttons await self.page.query_selector_all([roletab], .filter-option, .sort-option) for filter_btn in filter_buttons: btn_text await filter_btn.inner_text() # 判断这个筛选器是否与任务相关例如任务关于“品牌A”按钮文本是“品牌A” # 这里可以集成LLM进行简单判断 if self.is_filter_relevant(btn_text): action_id fclick_filter_{btn_text} if action_id not in self.visited_actions: # 记录已尝试的筛选组合 self.action_queue.append({action_type: click, selector: self._get_selector(filter_btn)}) self.visited_actions.add(action_id)主控制循环async def run_search(self): await self.page.goto(self.start_url) self.visited_urls.add(self.start_url) no_new_item_rounds 0 MAX_NO_NEW_ROUNDS 3 # 连续3轮无新项则终止 while no_new_item_rounds MAX_NO_NEW_ROUNDS: if not self.action_queue: # 尝试从当前页面发现新动作 await self.discover_new_actions() if not self.action_queue: break # 无新动作可探索终止 # 执行队列中的一个动作 action self.action_queue.pop(0) executed await self.execute_action(action) if executed: # 提取当前页面的项 new_items await self.extract_items_from_page() if new_items: self.item_data.extend(new_items) no_new_item_rounds 0 # 重置计数器 print(f发现 {len(new_items)} 个新项) else: no_new_item_rounds 1 # 执行后再次发现当前页面的潜在新动作 await self.discover_new_actions() print(f搜索终止。共找到 {len(self.item_data)} 个唯一项。) return self.item_data4.3 参数调优与性能考量等待策略page.wait_for_load_state(networkidle)是一个好的起点但对于重度依赖JavaScript渲染的网站可能需要结合page.wait_for_selector等待特定内容区域出现。并发与速度广度搜索可能涉及大量页面。需要平衡浏览器实例数量、系统资源和网站反爬策略。通常单个智能体顺序执行足够用于基准测试。在生产环境可能需要分布式队列。错误处理与重试网络超时、元素定位失败是常事。必须在关键动作如点击翻页周围添加重试机制和超时处理避免因单次失败导致整个任务中断。资源清理及时关闭不再使用的页面和浏览器上下文防止内存泄漏。5. 在Ko-WideSearch上评估与改进智能体当你按照上述方案实现了一个基础智能体后就可以在Ko-WideSearch基准上运行测试了。基准通常会提供一个标准化的评估脚本和一组任务定义文件。5.1 评估流程获取基准从指定仓库下载Ko-WideSearch基准里面包含了各个任务的环境快照可能是Docker镜像或本地HTML文件和对应的“黄金答案”文件。配置智能体接口你的智能体需要实现一个标准的接口例如一个run(task_instruction, start_url)函数它最终返回一个目标项列表。运行评估脚本基准的评估脚本会依次加载每个任务环境调用你的智能体并将智能体输出的列表与“黄金答案”进行比较计算召回率、精确率、F1、步骤数等指标。分析结果查看详细的评估报告不仅看总分更要看分任务、分难度等级的表现。这能帮你定位智能体的薄弱环节。5.2 典型问题分析与调优方向根据在类似基准上的经验智能体常出现以下问题及对策问题现象可能原因调优方向召回率低漏项多1. 动态内容未加载。2. 筛选条件未尝试完全。3. 对“目标项”的定义理解偏差NLP问题。4. 分页逻辑识别错误提前终止。1. 强化动态加载检测滚动监听、网络请求监控。2. 实现更系统的筛选空间探索算法如BFS遍历筛选组合。3. 改进指令解析Prompt或引入少量样本进行In-context Learning。4. 改进翻页终止判断结合“下一页”按钮状态和页面内容变化。精确率低错项多1. 项提取规则过于宽泛抓取了相似但非目标项。2. 去重逻辑不完善同一项因信息微调被重复计算。1. 在规则提取后增加一个LLM过滤层对每个候选项进行二分类判断。2. 优化指纹生成算法聚焦于更稳定的标识如数据库ID或使用语义相似度进行模糊去重。步骤数/耗时过高1. 探索策略低效重复访问相同状态。2. 动作执行后等待时间过长。3. 进行了大量无关的探索。1. 加强visited_urls和visited_actions的状态管理使用更细粒度的状态哈希。2. 根据页面类型动态调整等待超时列表页可稍短详情页需保证加载完整。3. 让规划模块LLM在更高层次指导探索方向减少盲目点击。在特定网站类型失败对该类网站的UI模式、交互习惯不熟悉。引入网站特定适配器。例如为电商、新闻、论坛分别编写一套常用的元素定位模式和探索策略模板。这属于“领域知识”的注入。5.3 进阶技巧利用视觉与混合信号纯基于DOM的方法在面对高度定制化UI时可能失效。一个强大的智能体应该能利用视觉信息。视觉元素定位使用基于CV的模型如Grounding DINO或Playwright的截图功能结合LLM的视觉理解能力来定位和识别那些没有清晰语义标签的按钮比如一个图标表示的“筛选”按钮。布局理解通过页面截图让LLM-Vision模型理解整体布局“哪里是侧边栏哪里是主内容区哪里是分页控件”从而生成更合理的探索计划。混合信号决策结合DOM文本、元素属性和视觉位置信息共同判断一个元素是否可点击、是否是一个产品卡片。这能极大提升对“非标准”网站的鲁棒性。我个人在实际操作中的体会是构建一个在Ko-WideSearch这类基准上表现优异的智能体是一个典型的“系统工程”。它不仅仅是调用一个强大的LLM API那么简单更需要精心设计状态管理、探索策略、错误恢复等传统软件工程和算法逻辑。LLM更像是一个“大脑”负责高层的理解和规划而一个健壮的“神经系统”交互、感知、控制循环同样至关重要。从简单的规则提取器开始逐步引入LLM增强理解再结合视觉信息是一个稳妥的迭代路径。每次在基准上测试后仔细分析失败案例往往能发现智能体逻辑中那些意想不到的盲点这才是提升的关键。