有些工作说出来一点都不高级填表、查审批、找文档、登记资产、在 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 停在聊天框里而是往那些老旧、繁琐、没人愿意改的界面里走了一步。那一步看起来不酷但很实用。