我们一直在讨论 AI Agent 会不会替人操作电脑。
但有一个更底层的问题，反而很少被认真讨论：Agent 看到一个登录页时，它真的知道哪个是输入框，哪个是按钮，哪个地方可以点吗？
对人来说，这个问题几乎不需要思考。看到一个页面，我们天然知道哪里是标题，哪里是输入框，哪里是验证码按钮，哪里是协议链接，哪里是登录按钮。
但对机器来说，这不是常识——它看到的是一张图。
过去，我们通常用 OCR 解决这件事。OCR 可以告诉机器：图上有“登录”“获取验证码”“手机号登录”这些文字。
问题是，按钮不是文字。按钮是行动入口。
AI Agent 如果要真正操作软件，光知道屏幕上写了什么远远不够。它必须知道：
- 哪些区域可以点击
- 哪些区域可以输入
- 哪些元素是标签页
- 哪些链接会跳转
- 哪些控件会改变下一步状态
这就是 TextIn GUI API 要解决的问题。
它不是给 OCR 多加一个参数，而是让 AI 从“读屏幕上的字”，进一步走向“理解屏幕上的界面”。
OCR 看到文字，TextIn GUI 看到界面
来看看常见的电脑和手机桌面。
Elements 与 JSON 解析结果展示
如果只做 OCR，机器能拿到一堆文字：
- “一个账号，玩转 TextIn 智能文档”
- “手机号登录”
- “账号密码登录”
- “请输入 11 位手机号”
- “获取验证码”
- “登录”
这些当然有用，但还不够。因为 Agent 真正需要的不是“这张图里有什么字”，而是“这个界面能怎么操作”。
TextIn GUI API 会进一步识别出：
- “手机号登录”是一个标签页
- “账号密码登录”也是一个标签页
- “请输入 11 位手机号”是输入框
- “请输入短信验证码”是输入框
- “获取验证码”是按钮
- 用户协议和隐私政策是链接
- “登录”是按钮
- 其中哪些元素可交互
- 每个元素在界面中的位置和语义
这就完全不是同一个层级的能力了。
OCR 解决的是：图上写了什么。
GUI Understanding 解决的是：这个界面能做什么。
给 Agent 一张机器可执行的界面地图
现在很多 Agent Demo 看起来很聪明，但一到真实软件界面就容易变脆。
原因很简单：真实界面不是纯文本。
它有按钮，有输入框，有 Tab，有弹窗，有勾选框，有禁用态，有可点击区域，也有看起来像文字但其实是控件的东西。如果 Agent 只能靠截图描述或 OCR 文本来猜，它就很容易“瞎点”。
TextIn GUI API 的关键价值，是把一张截图变成结构化的界面元素结果。这不是一段自然语言描述，而是一张机器可执行的界面地图。
Agent 可以基于这张地图判断：
- 我应该点击哪个按钮
- 我应该在哪个输入框里输入
- 当前页面有哪些可操作控件
- 哪些区域只是说明文字，不能点击
- 下一步动作应该落在哪个坐标区域
对 AI Agent 来说，这类能力会越来越像基础设施。当 AI 要离开聊天框，进入真实软件环境，它就必须先看懂 GUI。
为什么不是直接靠 DOM 或大模型看图？
有人可能会问：网页不是有 DOM 吗？多模态大模型不是也能看图吗？
这两个方向都有价值，但都不是完整答案。
DOM 很强，但它主要适合网页。一旦进入桌面软件、远程桌面、移动 App 截图、虚拟机画面、历史系统、无障碍信息不完整的页面，DOM 就不一定存在，也不一定可靠。
多模态大模型也很强，但如果只让它“看图说话”，输出往往更像描述，不像稳定的工程接口。
Agent 不只需要一句“这里有一个登录按钮”。它还需要这个按钮的类型、位置、是否可交互，以及可以被程序消费的结构化结果。
这正是 TextIn GUI API 的定位：把 GUI 理解做成稳定、可接入、可工程化的能力。
从文档智能到界面智能
TextIn 过去解决了大量文档智能问题：识别、解析、结构化、抽取。
而 GUI 其实是另一类“复杂文档”。它不是静态纸面，而是软件世界的操作入口。
一张 App 截图、一张后台系统页面、一张桌面软件界面，里面同样有结构、有层级、有语义。
只是过去我们更多把它当作图片处理。
TextIn GUI API 想做的是：把软件界面也结构化。让机器不只是看到一个页面，而是知道这个页面里有哪些可行动的对象。
TextIn GUI 解析引擎入口
在现有解析能力中，开发者可以选择 textin_gui 解析引擎，上传桌面、移动端或网页应用截图，获取元素级结构化结果。
前端展示中会聚焦 Elements 和 JSON 两个视图：一个给人看，一个给系统接。
它会最先在哪里产生价值？
最直接的场景有以下五类：
第一类是 GUI Agent。
Agent 要操作真实软件，不能只靠猜。它需要知道屏幕上有哪些控件，以及每个控件意味着什么。
第二类是 自动化测试。
很多测试不只是验证文字是否出现，而是要判断按钮、输入框、状态和操作入口是否符合预期。
第三类是 RPA 和流程自动化。
大量企业系统并没有理想的 API，也不一定有干净的前端结构。截图级 GUI 理解，可以成为自动化流程的感知层。
第四类是 远程桌面和虚拟机操作。
Agent 在远程环境里看到的常常就是一张屏幕图。能不能把这张图解析成可操作元素，会直接影响任务成功率。
第五类是 界面数据标注和模型训练。
如果要训练更强的 GUI Agent，结构化界面数据本身就是高价值资产。
这不是 OCR 升级，而是 Agent 时代的基础拼图
过去，OCR 把图片里的文字变成可读文本。
现在，GUI Understanding 要把软件界面变成可执行结构。
这两件事看起来相近，实际差了一个时代。
OCR 面向的是“读懂内容”。
GUI Understanding 面向的是“采取行动”。
当 AI 还停留在问答框里，读懂文字就够了。
当 AI 开始操作软件、跑流程、做测试、控制远程环境，它就必须理解界面。
未来的 Agent 不应该靠猜来点击按钮，它应该基于结构化的界面理解来行动。
这就是 TextIn GUI API 最值得关注的地方。
开放测试
TextIn GUI API 目前已进入测试阶段。欢迎扫描下方二维码，联系 TextIn 团队开通测试权限。
TextIn GUI 将持续迭代，以 Skill 形式便捷用户使用。如果你正在做 AI Agent、RPA、自动化测试、远程桌面控制、软件界面分析，或者任何需要“让 AI 看懂屏幕”的应用，这个能力值得尽早验证。
因为 Agent 真正进入软件世界之前，必须先补上一双能看懂 GUI 的眼睛。
