聊天框装不下真实工作

过去一年，很多 Agent 产品都被做成聊天框。用户把任务说清楚，模型在旁边规划、调用工具、返回结果。这种形态适合问答、写作、代码和一部分 API 化任务，但它离多数人的日常工作还有一层距离。

真实工作不是只发生在对话里。它发生在浏览器标签页、办公文档、邮件、表格、后台系统、CRM、ERP、设计工具和本地文件夹里。很多流程没有干净 API，也不会为了 Agent 重新设计。人类每天靠眼睛看界面、靠鼠标键盘推进状态、靠经验判断下一步能不能点。

所以 GUI Agent 的问题不是「模型会不会点按钮」。点按钮只是最表层的动作。问题是：Agent 能不能理解屏幕里的状态，知道这个状态意味着什么，能不能在复杂界面里稳定推进任务，失败时能不能回退，完成后能不能留下可检查的轨迹。

如果这件事成立，Agent 的主战场就会从聊天窗口移到屏幕本身。那是入口变化。

Google I/O 的信号，是把 Agent 放进日常应用

Google I/O 2026 的一组发布，最值得看的是 Gemini 被放进了更多日常入口。官方汇总里提到 Search、Gemini app、购物、开发者工具等多个方向的 agentic experience；Gemini app 的官方文章则把 Gemini Spark 描述成可以在用户指挥下帮忙处理数字生活的个人 Agent。

大厂对 Agent 的想象，已经不满足于「用户问一句，助手答一句」。它们想进入用户正在工作的地方：邮件、日历、文档、购物车、搜索结果、移动设备和云端环境。

这个变化很重要。聊天框里的 Agent 需要用户把上下文搬进来；应用里的 Agent 可以直接看见上下文。前者像一个外部顾问，后者更像嵌在工作台里的助手。用户不需要把 Gmail 里的线索、Docs 里的草稿、Slides 里的版本关系重新讲一遍，Agent 才有机会继续做事。

但这也把难度抬高了。Agent 一旦进入真实应用，就不只是生成文本。它要面对账号权限、私人数据、业务记录、文件版本、协作者状态和不可轻易撤销的动作。一个总结写错了可以改，一个邮件误发、订单误下、表格误改，成本会高很多。

所以 GUI Agent 不能只靠「更聪明的模型」。它需要运行环境。

开源 GUI Agent 把门槛拉低了

ByteDance 的 UI-TARS Desktop 代表另一条信号：电脑操作 Agent 正在被开源社区快速拆解。它把多模态模型、屏幕观察、鼠标键盘动作、任务执行界面放在一起，让开发者可以直接试验「让模型使用电脑」这件事。

这类项目的价值，不只在于它自己能不能立刻变成生产工具。更重要的是，它把过去只有少数实验室或平台公司能做的能力，拆成了普通开发者可以观察、修改和复用的工程对象。OpenAI 的 Operator 研究预览也给了同一个方向的产品样本：Agent 不只是回答网页里的问题，而是进入浏览器环境执行任务。

这会加速三件事。

  • 更多人会发现 GUI Agent 的真实瓶颈不在单次演示，而在稳定性。
  • 更多开发者会把任务拆成可测试的动作序列，而不是只追求自然语言规划。
  • 更多产品会开始思考：哪些工作应该走 API，哪些工作只能先走屏幕，哪些工作必须让人确认。

这类项目很容易让人高估进度。一边是「这类能力会不会很快商品化」，另一边是「它到底能不能可靠完成真实任务」。这两个问题都对。GUI Agent 的能力会扩散，但可靠执行不会自动到来。

屏幕不是 API，屏幕更脆

API 的好处是结构清楚。字段、权限、错误码、版本变化都可以被机器处理。屏幕不是这样。按钮可能改名，弹窗可能遮挡，用户状态不同，页面加载慢一点，A/B 测试换一版布局，Agent 的动作就可能失效。

这也是 GUI Agent 比普通工具调用更难的地方。工具调用像走一条标好路的接口，GUI 操作更像在人类工作环境里临场行动。它必须同时处理视觉理解、操作选择、状态追踪和异常恢复。

Microsoft Research 的 ActionEngine 论文正好切中这个问题。它不满足于让 Agent 对界面做一步一步的反应，而是让一个 Crawling Agent 先探索 GUI，构建可更新的状态机记忆，再让 Execution Agent 根据这些记忆合成可执行程序。这里的关键变化是：从「看一眼、点一下」转向「理解界面状态，再程序化执行」。

这个思路说明，GUI Agent 的成熟方向不会是无限堆 prompt。它会越来越像一套自动化系统：有探索，有状态模型，有执行计划，有失败恢复，有可复用的界面知识。

真正有价值的 GUI Agent，也许先把屏幕工作流转译成更稳定的中间表示。能 API 化的地方走 API，必须看屏幕的地方看屏幕，重复任务变成脚本或状态机。

浏览器会先成为中间地带

如果桌面和手机太复杂，浏览器会是更现实的过渡地带。

原因很简单。浏览器里已经承载了大量真实工作：后台系统、SaaS、CRM、数据看板、内容管理、采购系统、报销系统、银行后台、开发控制台。它比完整桌面更容易沙箱化，也比纯 API 更接近用户真实流程。

浏览器 Agent 可以观察 DOM、截图、网络请求和页面状态，也可以用 Playwright 这类工具执行动作。它既不完全依赖视觉，也不完全依赖官方 API。对许多企业内部系统来说，这可能是 Agent 落地的第一条路。

但浏览器也不会自动安全。Agent 能进浏览器，就可能碰到登录态、客户数据、支付页面、内部系统和生产操作。过去浏览器自动化多用于测试，测试环境错了还能重跑；Agent 面向真实用户和真实业务时，权限边界要重新设计。

这也是为什么「电脑使用能力」不能只看演示。演示里完成一次订票、填表、查资料很吸引人，生产里更重要的是：哪些步骤允许自动执行，哪些步骤必须暂停确认，哪些字段只能读不能写，哪些系统永远不该交给 Agent 自己碰。

GUI Agent 会重写产品入口

如果 Agent 能可靠操作屏幕，软件产品的入口会被改变。

过去 SaaS 产品靠界面组织功能。用户进入页面、筛选数据、点菜单、改字段、导出报表。AI 助手出现后，很多产品加了一个聊天入口，但底层还是原来的页面和按钮。

GUI Agent 更进一步。它不要求软件先开放一个完美 API，也不要求用户知道功能在哪里。用户只说任务，Agent 自己在界面里找入口、读状态、执行动作、产出结果。这样一来，产品界面的价值会变化：它不只服务人，也服务 Agent。

这会带来一个很现实的设计问题：未来的界面到底是给人看的，还是给 Agent 操作的？

答案大概率是两者都要。人需要可理解、可检查、可介入的界面；Agent 需要稳定、可解析、少歧义的界面。那些结构清楚、状态明确、动作可回放的软件，会更容易被 Agent 使用。那些靠隐藏菜单、模糊状态和临时弹窗堆起来的软件，会更难自动化。

这可能反过来影响软件设计。过去可访问性是为了让更多人能用软件；未来「Agent 可操作性」也会变成一种工程质量。按钮是否有明确语义，状态是否可读，错误是否可恢复，任务是否有可验证完成条件，都会影响 Agent 能不能稳定工作。

不是每个屏幕任务都值得自动化

这条路线也容易被写过头。不是所有屏幕操作都值得交给 Agent。很多任务如果有 API，就应该走 API；很多高风险任务如果需要判断，就应该让人做最后确认；很多一次性任务如果流程不稳定，硬做 Agent 反而更贵。

GUI Agent 最适合的，可能是三类工作。

  • 高频、低风险、界面稳定，但没有好 API 的流程。
  • 需要跨多个应用搬运上下文的流程，比如邮件、表格、文档和后台系统之间的整理。
  • 人类负责判断，Agent 负责搜集、预填、核对和生成初稿的流程。

反过来，涉及付款、交易、合规批准、客户承诺、生产变更的动作，不能因为 Agent 能点按钮就放手。GUI Agent 越接近真实工作，越需要「可暂停、可解释、可追责」的执行框架。

这也是它和普通聊天助手最大的区别。聊天助手错了，用户可以不采纳。GUI Agent 错了，系统状态可能已经变了。

竞争会落到运行环境

未来一两年，GUI Agent 的竞争不会只在模型榜单上。模型当然重要，视觉理解、长上下文、规划能力和动作生成都会影响上限。但拉开差距的，可能是运行环境。

好的运行环境要解决几件无聊但关键的事。

  • 它要隔离账号、文件、网络和高风险系统。
  • 它要记录 Agent 看到了什么、做了什么、为什么这么做。
  • 它要支持人类在关键节点确认、撤销和接管。
  • 它要把成功的流程变成可复用步骤，而不是每次重新试错。
  • 它要让企业能设置策略：哪些应用可读，哪些字段可写，哪些动作禁止自动执行。

这会把 GUI Agent 从「模型功能」推向「工作流基础设施」。屏幕只是入口，背后是权限、状态、审计、记忆和自动化编排。

Google 把 Agent 放进自己的应用，开源社区把电脑操作能力拆出来，研究侧把 GUI 状态建模成可执行程序，这三条线指向同一件事：Agent 正在从会说话，走向会使用软件。

分水岭，重点是它能不能在真实屏幕、真实账号、真实数据、真实失败里持续工作。聊天框里的 Agent 解决的是表达问题；屏幕上的 Agent 要解决的是执行问题。

这也是为什么下一块战场会在屏幕上。那里有用户的工作流，也有软件公司的入口。