有些工作说出来一点都不高级：填表、查审批、找文档、登记资产、在 OA 里把一个文件转来转去。它们通常不难，真正烦的是流程长、入口深、按钮多，还特别容易被打断。上午刚把一个表单填到一半，消息弹出来；回来以后忘了刚才选的是哪个部门，重新点一遍。这样的活儿不太配得上一句“智能化转型”，但它确实占用了很多人的注意力。
所以我最近看 GUI Agent 这个方向时，反而没有先想到那些很酷的演示。真正让我有感觉的是一个很朴素的问题：如果一个人每天都要在浏览器里重复走十几步、二十几步流程，AI 能不能不只是告诉我“你应该怎么做”，而是直接把这件事做掉？
图示：360集团《这也叫AI》科技播客，这期播客里最值得展开的，也正是这种落差。360 人工智能研究院负责人冷大炜博士和 AI 冷科长聊 GUI Agent，没有把它包装成一个无所不能的新概念，反而把它放回了最普通、最磨人的办公界面里：ERP、OA、审批后台、企业邮箱、飞书文档、报销系统。听完整期内容后，我对 GUI Agent 的印象更清楚了一点：它不一定是最会说话的 AI，但倒是挺适合干那些没人愿意反复干的小活。播客相关内容如下，大家可以去看下：拆AI共识：大模型正在“吞掉”App？聊透GUI-Agent、流量入口与人机共识｜50分钟深度对谈
GUI Agent 到底和普通 Agent 差在哪
很多人第一次听 GUI Agent，会把它和 Manus、OpenClaw、MCP、Skill 这些词混在一起。它们确实都在解决“让 AI 做事”的问题，但路径不一样。
OpenClaw、MCP、Skill 这类方式更像是给 AI 配工具。系统要提前暴露接口，或者有人专门把某个能力封装成工具，模型再调用这些工具完成任务。这个路线的好处很明显：一旦接好了，效率高、动作稳定、返回结果也更结构化。比如查数据库、调接口、生成文件、跑脚本，这些事情就非常适合走工具路线。
GUI Agent 的出发点要笨一点，也更接近人。它看屏幕，理解界面，再决定点哪里、输入什么、下一步该怎么办。换句话说，它不要求系统提前为 AI 改造。只要这个网站、桌面软件、企业系统是人能操作的，它理论上就可以模仿人的操作路径。
如果说工具路线像是在系统旁边接了一排规范插口，GUI Agent 更像是站在屏幕前重新学一遍人的动作。它不一定最快，也不一定最稳，但遇到没有插口的旧系统时，这种“看得懂界面再动手”的能力就有了意义。很多时候，企业缺的不是一个更会聊天的模型，而是一个能把页面里的下一步先走下去的执行者。
这个区别放在企业里会变得很现实。很多公司都有一堆历史系统，接口文档不完整，权限复杂，改造成本高。有些系统不是不能接 API，而是排期、预算、安全审查、数据权限一层层下来，最后大家还是继续手工点。GUI Agent 的价值就卡在这里：它不是最高效的路径，但它可能是最容易跨过旧系统的一条路。
播客里有一句话挺关键：GUI Agent 不依赖系统主动适配。这个“不依赖”不是说它更优雅，而是说它有保底价值。有 API、有 MCP、有 Skill 的地方，当然应该走更高效的路径；没有这些条件的时候，视觉方案至少还能模仿人往前走。
为什么现在大家又开始认真看“点界面”这件事
过去一两年，大模型最热闹的场景还是聊天框。问问题、写文案、总结材料、生成代码，都挺好用，但它们大多停在“给答案”这一层。真正进入工作流以后，问题会变成另一种样子：答案我知道，可系统还是要我自己打开；流程我懂，可字段还是要我自己填；审批我已经判断完了，可按钮还是要我一个个点。
聊天框解决的是认知问题，GUI Agent 想碰的是执行问题。
这几年 AI 从“回答问题”往“完成任务”走，背后其实就是这个变化。模型能力变强之后，大家不会只满足于让它说得更像人，而是会追问：能不能替我把这件事办完？如果办不完，卡在哪里？是不会看界面，还是不懂流程，还是没有权限，还是企业知识不够？
GUI Agent 的“不性感”恰恰来自这里。它不会让人一眼觉得惊艳。自动填报表、自动查飞书文档、自动处理审批，听起来都不如写一首诗、生成一段视频酷。但对办公场景来说，这些重复动作更接近真实成本。一个流程 27 步，人工跑一次也许只要几分钟，可一天跑十次、一个月跑几百次，就不是小事了。
播客里提到 360 内部研发时有两个挺有画面感的时刻。第一个是内部 ERP 申请 IT 资产，一个标准流程要走 27 步，模型驱动浏览器自动跑通了。第二个更夸张一些，实验里 Agent 自动提交了 600 多个资产申请，把审批后台堆满了，团队又能一键把这些申请驳回。这个场景听起来有点好笑，但它说明一个问题：当系统流程足够稳定，GUI Agent 确实有机会把一类重复劳动批量化。
C 端热闹，B 端更容易先疼起来
如果只看 C 端，GUI Agent 很容易被理解成“帮我点奶茶”“帮我买票”“帮我订酒店”。这些当然是需求，但普通用户对这类场景的感受未必稳定。有时候自己点两下也不麻烦，交给 Agent 反而还要担心它选错口味、点错地址、漏看优惠券。
B 端的逻辑不太一样。企业里的很多流程不是临时兴起，而是每天、每周、每月固定发生。行政要登记资产，财务要处理报销，销售要维护客户系统，运营要查数据、发通知、做汇总。这些任务有清晰入口、固定字段、明确规则，也有大量重复动作。它们未必复杂，却很吃耐心。
我对这类场景很有代入感。不是因为每个系统都难用，而是企业系统常常有一种共同特点：它们是为流程正确性设计的，不是为人的连续注意力设计的。字段不能少，附件要按规则传，审批人要选对，页面跳转还经常把上下文打断。一个熟练员工能做得很快，但这不代表这件事值得一直由人做。
GUI Agent 在这里的吸引力不是“替代人”，而是把人从重复流程里往外拉一点。人仍然决定规则、判断异常、处理例外，但那些机械点击和信息搬运，确实可以被重新分配。
当然，B 端也不是 GUI Agent 的舒适区。播客里把难点讲得比较直：速度慢、执行不够稳、通用模型不懂企业内部知识。尤其是最后一点，几乎是所有企业 Agent 都绕不开的问题。
一个通用大模型再聪明，也不可能天然知道某家公司内部的报销制度、资产分类、审批层级、系统字段含义。外部模型可以学到公开知识，却看不到企业内部数据；企业又不可能把全部业务数据丢到外部环境里随便训练。于是 GUI Agent 看得见按钮，却不一定知道业务上应该怎么选。
我理解的“水土不服”大概就在这里。不是模型完全不会操作，而是它缺少一个老员工脑子里的经验。
360 的解法：不急着训大模型，先让老员工带一遍
这期播客里最值得开发者细看的是 360 提到的样例知识注入。这个方案不玄，甚至有点工程直觉：既然通用模型不懂企业流程，那就让懂流程的人先演示一遍，把演示记录成样例。后面 Agent 遇到相似任务时，从知识库里召回相关样例，作为上下文参考。
用人的话说，就是给 AI 找个老员工带路。
这个思路很适合企业现实。训练一个专属大模型成本太高，数据敏感，周期也长；但录制一个任务样例，把流程轨迹、界面状态、关键字段、操作顺序沉淀下来，成本相对可控。它不要求企业先完成大规模系统改造，也不要求把所有数据拿出去训练。知识留在本地，模型执行时按需参考。
这个方法和提示工程、RAG 有相似的地方，但它更贴近 GUI 任务。普通 RAG 更多召回文本知识，告诉模型“制度是什么”；样例知识注入不仅告诉模型制度，还给它看“这个系统里一般怎么走”。界面路径、按钮位置、字段顺序、异常提示，这些东西很难只靠一段制度说明讲清楚。
企业邮箱自动发送邮件的 demo 也能对应上这个逻辑。没有录制样例前，Agent 反复尝试还是无法完成；人工录制轨迹后，再执行一个相似但不同的任务，就能更快完成。这个前后对比比单纯展示成功更有说服力。因为真实工作里最常见的情况不是 Agent 第一次就跑顺，而是它先卡住，然后通过补充上下文、补充样例、补充业务知识，逐渐变得可用。
这也是我觉得“样例知识注入”比单纯喊智能体更落地的地方。它承认通用模型有盲区，也承认企业知识很难一次性标准化。先把高频流程录下来，让 Agent 按样例工作，再逐步扩展覆盖范围，这比一开始就追求全自动、全场景、零干预要可信得多。
有 API 时走高速路，没 API 时走视觉兜底
GUI Agent 容易引发路线争论：既然 API 更稳定，为什么还要看界面？既然 MCP 和 Skill 能把能力封装好，为什么还要让模型像人一样慢慢点？
这个问题不能只从技术洁癖出发。现实系统不是一张白纸。
对新系统来说，接口化、工具化当然更好。AI 调 API 比模拟点击更快，错误更少，也更容易审计。开发者如果能把业务能力封成 MCP、Skill 或内部工具，GUI Agent 没必要抢这部分工作。
但大量企业系统不是为 Agent 时代准备的。有些系统只有网页入口，有些系统接口不开放，有些系统牵涉供应商，有些系统能改但改不起。这个时候，GUI Agent 像一条绕路方案。它不漂亮，却能穿过那些暂时改不了的地方。
我更愿意把后面的形态理解成多种路径混合：能调接口就调接口，能用 Skill 就用 Skill，必须面对旧界面时再让 GUI Agent 接手。对最终用户来说，他并不关心底层到底是哪种 Agent。他只关心任务有没有完成，过程是不是可控，出错时能不能停下来让人接管。
这种混合路线也解释了为什么 GUI Agent 和 Coding Agent 不冲突。Coding Agent 更擅长处理代码、脚本、工程文件和开发流程；GUI Agent 更贴近浏览器、桌面和遗留系统。一个偏数字世界的“脑力工程”，一个偏图形界面的“手上动作”。后面如果它们出现在同一个入口里，我不会意外。
产品预告：浏览器插件形态，比桌面全局录屏更容易让人接受
播客里还透露了 360 GUI Agent 的产品节奏。计划是 6 月底先在 360 集团内部开放，打磨成熟后，下半年面向 C 端开放。形态上会以浏览器插件为主，在用户自己的浏览器上执行任务。对外体验预计会放在 research.360.cn，时间大致是 7、8 月份。
我比较在意的是它对隐私边界的处理。GUI Agent 如果要“看屏幕”，天然会让人紧张。桌面上有什么、聊天窗口里有什么、浏览器其他标签页里有什么，这些都可能涉及隐私。播客里提到的方案是把录屏限制在当前浏览器工作窗口内，这个边界比全局桌面接管更容易被接受。
另一个细节是用户可以自定义后台模型，选择自己购买的 API，产品也会内置一些免费模型。这对开发者挺重要。因为 GUI Agent 的体验很大程度受模型能力影响，不同任务对模型成本、速度、稳定性的要求也不同。把模型选择权留出来，至少给后续调优留下空间。
从开放路径看，先 B 后 C 也合理。B 端流程稳定、价值密度高，更适合先打磨成功率；C 端需求太散，场景变化大，一上来就追求普通用户的万能助手，反而容易把预期拉得过高。
我更期待它处理“低价值但高频”的工作
看完这期内容，我对 GUI Agent 的期待没有变得更夸张，反而更具体了。
我不太期待它马上替我做所有决定，也不期待它在复杂任务里完全不出错。至少现阶段，企业内的 GUI Agent 更像一个需要带教的新员工。你要告诉它背景，给它样例，让它先处理标准任务；碰到异常、权限、模糊判断，再回到人这里。
但这已经足够有价值。很多办公场景不缺判断力，缺的是耐心。比如查指定作者和内容的飞书文档，人工当然会查，但每次切换搜索条件、打开文档、确认内容、复制摘要，都在消耗注意力。再比如 SSC 审批自动处理，规则明确时，让 Agent 先跑一遍，人只看异常项，体验会完全不一样。
我也能理解为什么播客里反复提 B 端。C 端用户会为了体验挑剔很多细节：速度慢一点、点错一步、没有优惠，都会觉得“不如我自己来”。但在企业里，只要一个流程每天重复发生，自动化的容错空间就会变大。哪怕一开始只能覆盖 60 分的标准场景，也能先把最烦的一部分拿走。
当然，这里有一个前提：它必须能被监督。GUI Agent 不是后台脚本，它操作的是活界面，点错按钮可能真的提交申请、发送邮件、修改数据。好的产品形态应该让用户知道它正在做什么，关键步骤能确认，出错能回放，必要时能中止。否则它越能干，风险也越明显。
视频观后感：最打动我的不是“智能”，是它承认自己还需要被教
这期视频看下来，我最有感触的地方不是某个炫技 demo，而是它没有回避 GUI Agent 现在的问题。
它慢，它会不理解企业语境，它需要人干预，它不一定比 API 路线优雅。播客里把这些都说出来了。对一个还在产品化路上的方向来说，这种表达比单纯讲愿景更可信。因为做过企业系统的人都知道，真正难的往往不是让 AI 点一下按钮，而是让它知道为什么要点这个按钮、什么时候不能点、点完以后有没有达到业务目的。
“老员工带新员工”这个比喻也挺准。新员工第一天进公司，哪怕能力再强，也不可能自己摸清所有系统和制度。有人演示一遍，告诉他哪个入口是真的入口，哪个字段容易填错，哪个提示可以忽略，哪个页面提交后不能撤回，他才会慢慢进入状态。GUI Agent 现在也处在这个阶段。
所以我看完后的判断是：GUI Agent 短期内不会变成万能电脑管家，但它很可能先在企业办公里撕开一个口子。这个口子不会发生在最复杂、最需要判断的任务上，而会发生在那些大家都嫌烦、流程又相对固定的地方。
如果 360 这套浏览器插件后面开放体验，我会优先试三类任务：找文档、填系统、走审批。它们都不是特别惊艳的场景，但最接近每天真实发生的工作。一个 Agent 能不能进入工作流，不是看它演示时有多聪明，而是看它能不能在这些小事里稳定少添乱。
我愿意继续关注 GUI Agent，也正是因为这一点。它没有把 AI 停在聊天框里，而是往那些老旧、繁琐、没人愿意改的界面里走了一步。那一步看起来不酷，但很实用。
