Tarsier项目中的无OCR纯DOM元素标记方案解析

在自动化测试和网页交互领域，Tarsier项目提供了一个创新的解决方案。近期社区讨论中，开发者提出了一个关键需求：如何在不依赖OCR技术的情况下，仅通过DOM元素信息实现网页元素的标记和交互。本文将深入解析这一技术方案及其实现原理。

需求背景

传统网页自动化工具通常需要结合视觉识别（OCR）和DOM分析两种技术。但在某些场景下，开发者只需要：

1. 获取页面DOM结构
2. 标记可交互元素
3. 通过LLM模型决策交互流程

这种纯DOM方案的优势在于：

• 避免OCR服务依赖
• 减少计算资源消耗
• 提高执行速度

技术实现演进

项目维护者通过issue讨论明确了两种实现路径：

1. 初始解决方案
   开发者通过创建虚拟的OCR服务凭证（fake service_account.json）来绕过强制OCR校验，但这属于临时方案。

2. 正式解决方案
   在v0.6.33版本中引入了DummyOCRService：

from tarsier import Tarsier, DummyOCRService
tarsier = Tarsier(DummyOCRService())
screenshot, tag_to_xpath = await tarsier.page_to_image(page)

核心工作机制

该方案的技术实现包含以下关键点：

1. 元素标记系统

• 自动为DOM元素生成唯一标签
• 建立标签与XPath的映射关系
• 保留元素层级结构和交互属性

2. 轻量化处理

• 跳过图像处理和文字识别环节
• 直接输出空白截图占位符
• 专注于DOM结构分析

3. LLM集成接口
   生成的tag_to_xpath映射可直接提供给大语言模型：

• 模型根据任务描述选择操作目标
• 通过标签反查具体DOM元素
• 执行点击、输入等交互指令

应用场景建议

这种方案特别适合以下场景：

1. 结构化页面测试
   对元素位置固定的管理系统、后台页面等，DOM结构比视觉特征更可靠。

2. 低代码自动化
   结合LLM实现自然语言驱动的自动化流程，如"点击登录按钮"等简单指令。

3. 资源受限环境
   在无法使用OCR服务或需要快速执行的场景下提供替代方案。

注意事项

开发者需要注意：

• 动态生成的内容可能导致XPath不稳定
• 纯DOM方案无法处理Canvas等非标准元素
• 需要确保页面完全加载后再执行标记

这种技术方案为Tarsier项目提供了更灵活的使用方式，体现了开源项目响应社区需求的敏捷性。通过分离OCR和DOM处理逻辑，项目架构变得更加清晰和可扩展。