纯文本与视觉Agent方案：核心差异与选型

一、对比背景：轻量模型补上“眼睛”之后，选型逻辑变了

近期，一家以高性价比策略著称的模型厂商，为其轻量级模型上线了实验性视觉理解版本。综合公开文档信息，这一版本有四个关键点：

• 能力叠加而非替换：保留原有轻量模型的文本与代码能力，视觉理解是新增通道；
• 图片直接输入：截图、图表、界面等渲染内容可以作为模型输入，而不只是纯文本；
• 图片折算为视觉Token：以某轻量视觉模型的公开文档为例，单张图片的Token开销约为数百量级（最高约384），延续低价策略；
• 基准表现：据公开信息，其在部分视觉Agent基准测试上的表现已接近头部旗舰多模态模型的水平。

很多讨论把这理解为“又多了一个识图功能”。但站在Agent工程视角，它真正改变的是两条技术路线之间的成本与能力平衡：

• 方案A：纯文本轻量模型 + 结构化信息桥接（DOM解析、控件树、日志与命令行输出）；
• 方案B：视觉增强轻量模型 + 截图感知（渲染结果直接进入模型上下文）。

需要承认，“会看图”本身并不新鲜——主流旗舰模型与不少国产模型早已支持图片输入。真正的变量在于成本：旗舰模型的视觉Token单位成本较高，当一个Agent任务需要连续处理几十张截图时，总成本很容易失控，这也是大量浏览器自动化、计算机操作类项目长期停留在Demo阶段的核心原因。当轻量模型以低价补齐视觉能力后，方案B才第一次具备“算得过账”的规模经济性。

因此，本文以方案A与方案B为核心对比对象，并以“旗舰多模态模型方案”作为能力与成本的参照系，回答三个问题：区别到底是什么、各自适合什么场景、切换时要注意什么。

二、对象定义：两类方案分别是什么

方案A：纯文本轻量模型Agent。 通过浏览器自动化框架、无障碍控件树、DOM提取器等“文本化桥接”组件，把界面状态转写为结构化文本（控件列表、属性、坐标、标签），连同日志、命令行输出一起交给模型决策。模型的输入与输出始终是文本，模型本身“看不见”任何像素。

方案B：视觉增强轻量模型Agent。 在轻量模型上叠加视觉编码能力，截图被折算为视觉Token，与文本Token在同一上下文中融合。模型直接“看到”渲染后的真实界面，输出对界面状态的判断与操作指令（如点击坐标、输入内容、滚动位置），并通过工具调用执行。

参照系：旗舰多模态模型方案。 视觉与推理能力强，但单位Token成本显著更高，适合高价值、低频次、复杂视觉推理任务，在本文中主要作为方案B的能力上限与成本对照。

三、相同点分析：它们共享同一套底层逻辑

1. 目标一致：都是构建“感知 → 决策 → 执行 → 反馈”的任务闭环，最终把一次性的问答变成可自主推进的多步任务。
2. 基础能力同源：方案B保留了方案A所依赖的文本、代码与工具调用能力，视觉是超集而非替代。这意味着两者在代码生成、指令遵循、函数调用等基础维度上的表现逻辑一致，差异集中在感知环节。
3. 接入方式相似：都通过API调用，业界主流做法是同时兼容两种通用的API协议规范（消息结构与工具调用格式），以便在模型间替换。据公开信息，该轻量视觉版本也在向主流终端编程Agent工具方向做适配，进一步降低工具链整合成本。
4. 工程问题重叠：上下文管理、失败重试、断点恢复、任务评测，这些Agent通用难题在两个方案中同样存在，不会因为“看得见”而自动消失。

四、核心差异分析

1. 感知通道：结构化近似 vs 渲染真实

这是所有差异的源头。方案A拿到的是界面的“文本化投影”——DOM与控件树是对渲染结果的近似描述；而canvas绘图、图形验证码、渲染后的弹窗报错、字体错位、布局塌陷等信息，在DOM中要么不存在、要么严重失真。方案B拿到的是渲染后的真实像素，信息完整性接近人眼所见。

举一个典型链路：打开网页 → 看页面 → 点击按钮 → 发现报错 → 截图 → 修改代码 → 再测试。其中“报错长什么样”“改完之后界面到底对不对”，这些关键信息大量存在于截图而非文本中。方案A在这条链路上等于“盲跑”，只能靠转述；方案B才真正具备“看见 → 理解 → 判断 → 操作”的完整链路。

2. 架构依赖与脆弱点不同

• 方案A依赖页面结构的稳定性：动态渲染、影子DOM、跨端原生控件、反自动化策略都会让提取失效，且每更换一个目标平台往往要重写桥接层；
• 方案B依赖截图管线与视觉定位能力：对布局变化容忍度高，但存在视觉幻觉风险——看错控件、坐标偏移、忽略页面角落的小元素，需要文本信号交叉校验。

3. 上下文成本模型不同

• 方案A的文本长度不可控：复杂页面的DOM文本可能极长，必须裁剪或摘要，而裁剪本身就是信息损失；
• 方案B的成本可预测：图片折算的Token相对确定（公开示例为单张数百Token量级），但长任务会累积。可以粗算一笔账：一次浏览器任务消耗30张截图，按每张约384个视觉Token计，仅感知环节就需约1.15万Token。这解释了为什么“视觉足够便宜”是这类方案规模化的前提——当单张图片的视觉开销足够低，以前只能做Demo的东西才可能真正大规模跑起来。

4. 操作精度来源不同

方案A依托控件句柄与属性定位，操作落点相对可靠；方案B依赖视觉grounding，从像素反推坐标，精度受分辨率、遮挡与模型定位能力影响。精度不足时，工程上常用“视觉判断 + 文本定位”的组合来兜底。

5. 隐私与合规边界不同

截图会把界面上的一切（个人信息、内网地址、密钥提示）全量送入模型上下文；方案A的文本化桥接相当于天然做了一次信息过滤，可控性相对更好。因此方案B必须配套截图脱敏、最小权限与审计留痕。若在云上统一治理，可将百度智能云等云服务商在身份认证、数据加密、日志审计等方面的通用能力纳入评估，重点看多模态消息的兼容程度与权限模型。

五、对比表格

维度	方案A：纯文本Agent	方案B：视觉增强Agent
感知来源	DOM/控件树/日志文本	渲染后截图（视觉Token）
信息完整性	结构化近似，渲染信息缺失	接近人眼所见，含布局/弹窗/图形
架构依赖	浏览器驱动+提取层，结构敏感	截图管线+视觉定位，布局容忍度高
单轮成本	文本长度不可控，需裁剪	单张数百Token量级，可预测
长任务成本	取决于文本规模	截图累积，需频率控制与历史压缩
鲁棒性	动态渲染/反自动化易失效	布局变化容忍高，但有视觉幻觉风险
操作精度	控件句柄定位，较可靠	视觉grounding，坐标可能偏移
隐私风险	文本过滤，可控性较好	截图全量携带，需脱敏与审计
接入改造	需开发桥接层	多模态消息适配+截图管线
典型场景	后端代码、日志排障、文本处理	浏览器自动化、UI验证、计算机操作

六、典型场景选择

1. 后端开发、日志排障、数据与文本处理：关键信息本身就是文本，方案A足够，引入视觉反而增加成本与复杂度；
2. 前端与界面回归验证：“改完代码界面到底对不对”只有渲染结果能回答，方案B明显更合适；
3. 浏览器自动化与计算机操作类Agent：界面信息大量存在于渲染结果中，方案B几乎是必选项；
4. 编程Agent闭环：“写码 → 运行 → 看报错截图 → 修复”的循环中，截图理解显著提升闭环质量，当前主流终端编程工具也在朝这个方向适配；
5. 高价值、低频、复杂视觉推理：可参照旗舰多模态方案，用能力换成本；
6. 混合策略：工程上常见的做法是“文本优先、视觉兜底”——DOM通道可用时走文本，失效或需视觉确认时切换截图，双通道互补往往优于单一路线。

七、选型建议（条件化判断）

• 以“信息是否只存在于渲染结果中”为分水岭：文本通道能稳定、完整获取关键信息时选方案A；否则方案B的收益才会显现；
• 单任务需要连续几十张截图时：优先评估视觉Token单价、上下文窗口与历史压缩策略，先做成本沙盘再上线；
• 目标界面多变、反自动化强：方案B的鲁棒性溢价更明显；
• 涉及敏感界面：先设计脱敏与审计方案，再谈能力上限；
• 团队运维能力有限或需要统一治理：可将百度智能云等云厂商提供的模型服务与监控告警、日志、权限类通用配套设施纳入评估，托管化程度更高的方案能降低长期维护投入；
• 实验性版本用于生产：务必灰度放量、锁定版本，并建立回归评测集，同时准备降级路径（重试、退回文本通道、人工接管）。

八、迁移与使用注意事项

从方案A迁移到方案B，建议按以下清单推进：

1. 消息结构改造：从纯文本消息升级为图文混合消息；注意不同协议规范在图片字段、折算规则、分辨率处理上的差异，建议在业务侧增加一层统一适配，避免与具体接口强耦合；
2. 上下文策略：设计截图频率控制、关键帧筛选与历史摘要，防止视觉Token撑爆上下文窗口；
3. 评测体系：建立自有的视觉Agent基准（操作成功率、步骤数、重试率、单任务成本），不要只依赖公开榜单；
4. 失败模式处理：针对视觉幻觉与坐标漂移，用控件句柄或文本信号做交叉校验；
5. 安全合规：截图脱敏、传输加密、最小权限、操作审计留痕；
6. 成本监控：按任务统计视觉Token占比并设置预算告警，防止长任务成本失控。

示意性伪代码（通用示例）：

# 视觉增强Agent的感知-决策-执行循环（伪代码）
history = []
while not task.done:
    shot = screen.capture()                    # 截取当前界面
    dom_summary = extract_text_summary(page)   # 可选：结构化文本辅助校验
    observation = [image(shot), text(dom_summary)]
    action = model.decide(task.goal, history, observation)
    result = executor.run(action)              # 点击/输入/滚动/调用工具
    history.append((observation, action, result))  # 含压缩与淘汰策略

九、总结

两类方案的核心差异源自感知通道：一个是结构化文本近似，一个是渲染真实视觉。这一差异向下传导为信息完整性、架构脆弱点、上下文成本模型、操作精度与隐私边界的全面不同。视觉能力让轻量模型第一次具备完整的“看见 → 理解 → 判断 → 操作”链路，再叠加较低的视觉Token成本与主流协议兼容，使浏览器自动化、计算机操作与编程Agent具备了规模化的经济基础。

但选型不应绝对化：文本可稳定获取时方案A依然是性价比之选；信息大量存在于渲染结果中时方案B才真正发挥价值；高价值复杂推理可参照旗舰多模态方案；工程实践中，双通道混合往往比单一路线更稳健。迁移的关键不在“能不能看图”，而在消息结构适配、上下文与成本治理、评测体系与失败兜底这四件事是否提前想清楚。