新年假期，我们邀请到两位在GUI Agent领域前沿的探索者，展开了一场深度对话。他们分别是：
- X：大模型智能体和GUI智能体从业者/研究者。
- 谢天宝：香港大学博士生，专注NLP/LLM/Agent（OSWorld等项目的作者）。
我们广泛讨论了十余个关键话题，以下是本次对话的核心内容整理。
一、模型与 Benchmark 的发展现状
Tianbao（模型侧观察）
近一两年主要研究计算机使用智能体（computer use agent），涉及框架制定、基准测试（Benchmark）等。近期关注概念拓展与能力整合（coding、深度研究、计算机使用智能体合版），工作偏工程化。
国外的GUI模型，Claude在computer use领域表现最佳，其专门团队方案自成一体。Manus的成功也与此相关。OpenAI有些开局巅峰，后续进展不确定。
国内做得较好的是UI-TARS和AutoGLM。UI-TARS更偏computer use，AutoGLM更偏移动端使用。美团和通义千问也在布局。
国内目前仍处于堆数据阶段，部分团队已搭建强化学习（RL）基础设施并积累经验，但尚处于纯GUI状态，未完成合版。现状是：合版在做但未完成，RL在做但未完善，数据在续但未跟上。目前较少团队打通了全链路。
关于评估标准，半年前我们还在关注模型能否点准。现在这种情况已大幅减少。
现阶段我会通过中长程任务评估模型，如30步、50步、100步点击的任务。评估维度包括：第一，任务完成度——模型能否完成长任务且不迷失，犯错后能否恢复；第二，任务效率——我15步能完成的事，模型理想状态不应超过15步，但目前通常需要50步。
在Benchmark以外的任务上，任务完成度仍然不够，任务效率也仍然不够。这本质上是一个工程问题，应可通过扩大规模（scaling）和资源投入解决，预计约一年左右。
X（Benchmark 侧观察）
我们使用OSWorld较多，虽然部分任务标注存在问题，但过去一年整体是比较合适的Benchmark。
但OSWorld目前逐渐暴露出问题。当模型达到70-80分、接近人类性能（human performance）时，会发现其中很多任务与真实用户期待差距较大。
下一阶段的Benchmark需要更全面（comprehensive），更综合地体现模型利用综合工具解决问题的能力。关键是能做自动评估（automatic evaluation）。若无法自动评估，学术界和工业界都不愿使用，因为无法进行日常迭代。
目前较可行的方案是做类似深度研究（deep research）的任务，基于答案做验证较为直接，但任务设计上应是综合任务而非简单信息查找。
本质上我们是在做面向不同职业的Benchmark：AI能多大程度解决某职业普通级别员工的工作内容？若都能达到80%以上，可视为接近AGI。
接下来可能会有更专业（professional）的Benchmark，如SWE-bench本质上就面向程序员。建议选择3-5个未来最易被替代的职业，做能结合计算机使用智能体（CUA）、Coding、API和深度研究解决的Benchmark。
二、Comprehensive vs 垂直 Benchmark 怎么选？
Tianbao
与一些团队交流后发现，当我们想做通用数字智能体（UDA）时，最初想把coding、deep research、computer use、GUI都纳入。但反馈是：若一个Benchmark涉及过多要素，作为工业界指标时很难产生有效信号，在模型早期阶段这个信号缺乏意义。
我们曾考虑去招聘网站分析哪些行业薪资较高、哪些工作可被自动化，再分析哪些能被computer use建模。但发现绝大多数行业的自动化渗透率极低。这些工作包含大量隐式知识，碎片化程度高，难以用单一指令说明。不是数字化自动化状态，中间夹杂很多因素，不利于评估。
因此只能采用取巧的建模方式，但与真实情况存在差距。这种差距难以在benchmark中体现，最终仍只能选取纯GUI任务，存在以偏概全的问题。
X
这个担忧很有意义，说白了还是不够垂直，没办法针对性地构造训练数据、去训练模型。
当前做大模型也不是纯学术研究，最终都要在市场上产生价值。Coding算是成功案例，确实带来了数十亿美元的收入。而且这样做后续去优化才更有意义，顺手就能把监督能力提升了。
而且把一个有代表性的职业做好后，说不定是有泛化性的，能触类旁通。如以前对工具调用没有思路，但coding做好后，很多工具调用能力自然提升。投入大量资源构建综合性benchmark，效果可能仍不理想。
三、设备差异与合版挑战
X
首先，不同设备之间差别较大：
弹窗：手机上遇到弹窗的概率比电脑高，且手机屏幕小，弹窗影响大，不处理无法继续。
权限：手机权限比电脑严格，很多须厂商授权，自行申请困难。电脑相对容易获取。
信息呈现：电脑屏幕大、信息密度高。手机屏幕小但应用繁多。电脑上相对集中，比如国内用户主要使用微信、浏览器、Office，还有一些垂直应用（程序员会用IDE，设计师会用PS）。
用户耐心：手机用户追求快速响应，电脑用户知道在工作，对任务有预期，稍慢也可接受。
这些因素导致虽然技术上有较大相似性，但从模型到产品的设计差异很大。
Tianbao
Mobile和computer use在工程层面有区别，监督微调（SFT）和强化学习（RL）主要差异在数据收集和RL任务设计。
理想情况是组合泛化：学了coding又学了GUI，上电脑时就应该同时具备两种能力。Claude有时能做到，但其他团队的合版效果又都似乎在进步当中，这里面有很多技巧（tricks）。
我觉得这件事肯定没有那么简单。你不能指望只拿一堆SWE数据就把GUI的两类用例全部解决掉。但我们多少相信，模型在互联网上应该见过类似的解法，所以在方法论上是有参照的。
其实如果你真的去深入理解这个问题，会发现很多事情没那么神秘。比如你想做一个PPT、一个Excel，或者一个Word，本质上都是结构化的文本和代码文件。说白了，它和网页在结构上没有本质区别。既然我们已经可以直接合成网页，理论上也就可以直接合成PPT、Word、Excel。
真正的差别在于“质量”和“闭环”。如果你只是直接合成这些文件，效果可能是能用，但未必好。相比之下，如果你在合成之后再叠加GUI能力，就会完全不一样。例如，你生成了一个网页，如果你具备GUI能力，就可以自己去交互、去点、去测，看看哪里不对，再调整。这件事是传统开发很难做到的——你只能一次性生成，生成完就结束了，中间没有反馈，也不形成闭环。
所以这显然不是终极形态。真正要做到位，等于你得把一个前端工程师该做的事情全做了。理论上，我们当然希望GUI训练完成之后，一个“合版”的智能体能把这些事情全部覆盖，但从现实来看，真正能做到的团队非常少。
X
我觉得这块其实和我们做产品、做实际系统的经验是非常一致的。整体一定会经历一个冷启动阶段，以及之后在真实数据上的持续迭代。
冷启动阶段本身就是痛苦的。你首先得让系统“跑起来”，在这个过程中不可避免地会大量使用合成（synthetic）数据。大家其实都是在瞎猜——靠产品经理猜，靠工程师猜，猜用户会怎么想、会怎么用。
但你又不能一直停留在猜的阶段。只有真正跑完冷启动、把东西推上线之后，数据飞轮才会开始发挥一点作用。这里我也想补充一点：过去一两年大家可能对“数据飞轮”这件事有些夸大了。数据飞轮确实在某一个阶段非常有用，但过了那个阶段，很多关键突破还是要靠研究员从头来做。
因为用户行为其实很快就会收敛。很多解决方案会变得相对稳定。但在产品上线之前，你几乎不可能准确预判；一旦上线，各种意想不到的真实请求就会涌进来。而一旦你拿到了这些真实请求，后续的迭代反而会顺很多。因为你等于直接拿到了访问分布，你只需要围绕这个分布去优化就好。
所以整体来看，我还是比较坚定地认为，做智能体（Agent）这件事必须闭环来做。你一定要拿到真实的用户反馈，不管是通过API的形式，还是通过产品本身，否则你就很难进入下一个演化阶段。没有这些反馈，你做出来的东西最终就是一个“没法上桌”的系统。
四、Agent 的终局是什么？
关于Agent的最终形态，我们讨论了两种设想：
第一种是Agent能创建完全满足需求的独立APP，前后端就绪，随时可用。
第二种是Agent能在现存所有环境中执行命令，帮用户完成任务。
X
你问我俩我俩应该还是vote for the second（笑）。
用户其实是非常不愿意改变自己既有工作方式和工具体系的。AI的实际渗透率依然非常低。原因并不复杂：用户并不想为了新技术去重塑自己的工作习惯。
我经常有一个比较残酷的判断——很多新技术或新应用的真正普及，往往需要一代人。它并不是靠线性增长实现的，而是通过代际更替完成的。这个过程在AI身上，我觉得同样很可能会发生。所以即便技术进展得非常快，采用（adoption）这件事也未必像大家想象中那么乐观。
第二个判断，我觉得agent的路径，其实和自动驾驶非常像。回顾自动驾驶早期，当时大概有两条路线：一条是依赖高精地图，让环境适配车；另一条是端到端模型，让车自己去适应真实道路环境。最后哪条路赢了，其实已经很清楚了——一定是车去适应环境。对agent来说也是一样的逻辑。让agent去适应现实环境，一定比要求环境为agent做大规模改造要容易得多。 基础设施投资太重，而一个agent本身是可复制、可规模化的。
当然，agent也很可能会遇到类似自动驾驶的挑战。自动驾驶跑了十年，才算初见曙光。核心原因就是：真实环境极其复杂，你必须在真实环境中路测、采数据、在线训练，才可能真正有效。这本质上是一个强依赖在线数据（online data）的系统。agent其实也是一样的，只是相对来说，它的投入成本和风险比自动驾驶低得多。
技术成熟之后，产品成熟和采用的提升，可能又是另外好几年的事情。而一旦AI真能端到端完成第一类设想，那反过来说，我们今天讨论的这些工具本身也就不再值钱了，人类又会去追求更刺激、更新的东西。
所以我的整体判断是：这套东西大概率会对开发者极其有利，但它不太可能真正出圈，更不太可能成为一个ToC用户普遍采用的产品形态。欢迎对这类前沿技术讨论感兴趣的开发者，到 云栈社区 的开发者广场板块交流更多想法。
Tianbao
我觉得这里面第一个假设本身其实是比较抽象的：为什么要让AI去写一个新的App，然后再让AI去用这个App？这个目标本身并不清晰。如果你已经具备从头开发一个新App的能力，那你为什么一定要让AI来做这件事，而不是直接解决问题本身？
这件事其实可以和我们之前反复讨论的CLI versus GUI对应起来，本质上是等价的问题。只是相对来说，我会觉得CLI的逻辑更自洽一些。因为如果你的目标只是完成任务，比如订一份外卖，从“世界的本质”来看，这件事无非是几个数据库之间发生状态变化。
但现实世界并不是架空的。真正的约束在于：对方愿意暴露什么接口？社会整体能接受什么形态？你不能只盯着“本质正确”，而忽略现实世界当前是怎么运作的。这里面不仅有技术问题，还有规则、伦理、制度、路径依赖等等因素。
所以我们现在持有的一个基本判断是：事情本身可能是同一件事，但交互界面（interface）可以有很多种。过去几年你也看到过一些尝试，比如AI Pin、Rabbit R1，本质上都是在探索新的interface。结果是什么？科技圈里叫好，但你在大街上几乎看不到有人在用。
这其实影射了一个很现实的问题：让用户、让商家、让整个体系去接受一条“未曾设想过的道路”，把整套系统重新端一遍，是一件他们很难接受的事情。
所有人都会算账。只有当大家在权衡利弊之后，发现这个新形态更合理、更快、更爽，而且是那种前所未有的爽，他们才会真的跳进去。
那这种时刻什么时候会到来？如果我们完全不做GUI，只走CLI路线，也许在未来三到五年，或者五到十年，会出现一个真正的杀手级应用（killer app）。当然，这条路是有风险的，也可能根本走不通。
但一旦我们引入GUI，这个格局就发生变化了。事情就不再是“CLI是否能完全主导”的问题，而更可能走向CLI与GUI的混合形态，或者某种我们现在还没完全看清的中间状态。
五、CLI vs GUI，谁会胜出？
X
Vibe coding目前算不算普及呢？也可能算从来没有普及过，本质上仍然是程序员圈内的工具。全栈开发这件事，本质上和过去写App没有什么区别——真正有强需求的，永远还是开发者，只是他们未来能用更低成本、更高效率去生产应用，从而提升供给。
这点和视频创作工具的演进其实也很像。剪辑工具的简化，并没有让所有人都变成抖音创作者，真正持续创作的仍然是那一批人，只是他们的效率提高了。因为大多数人并不靠这个吃饭，也就没有那么强的动机。
所以短期来看，我对AI的“全民创作”是比较保守的。而一旦AI真能端到端完成这件事，那反过来说，我们今天讨论的这些工具本身也就不再值钱了。
Tianbao
我们的观念是事情本身不变，interface可能有多种。现在格局下谁会先胜利不好判断。我不敢说GUI阵营一定会胜利，但至少是共存状态。我最近其实有了一个新的判断：未来甚至有可能走向纯GUI。
这里背后有一个前提假设，很多人都在提——未来浮点运算（flops）可能会变得不值钱。所谓flops不值钱，意思是算力本身会极度廉价，相比之下，参数（parameter）反而更值钱。对应到模型使用上，就是token的成本会大幅下降。
如果这个前提成立，那我们现在对GUI的一个核心担忧就会被彻底削弱。今天大家之所以偏向CLI，很大程度上是因为效率问题：CLI可能用200个token就能完成的事，GUI可能要用2万个token，看起来极其浪费。但如果未来这两种token消耗在成本上几乎等价，那“浪费”这个指控本身就不成立了。
在这种情况下，就要重新回到一个更现实的问题：用户到底愿不愿意用？从普适性、接受度和“爽感”来看，真的有多少人愿意对着一个终端去coding？除了极少数人，绝大多数用户并不愿意。
所以这里面隐含的一个核心问题是：在当前这个格局下，谁会先赢？就当下来看，两边其实都没有赢——因为都没有跑出真正的killer app。原因也很现实：当前无论是性能、产品成熟度，还是生态能量，都还不够用。
但这个格局在未来一两年内一定会发生变化，这一点我觉得是可以确定的。至少在垂直领域，变化已经开始显现。
如果放在一个完全架空的世界观里，我可能会判断CLI或coding形态真正占据主导地位，大概需要三年左右；但在现实世界里，我更倾向于认为，两年左右会出现一个killer app，被大规模接受；三年左右，整体形态会基本定型。
其实你也能看到一些大厂的野心，比如Gemini、Claude Code，本质上都在试图成为一种“操作系统级”的存在。问题从来不是“要不要interface”，而是interface该长什么样。
interface可以是纯语言的，但现在看来大家并不买账；归根结底，大家都是在权衡利弊——只要它真的足够爽，人们就会用；不够爽，就一定会抗拒。
这也是为什么语音交互明明技术已经很成熟，但很多人仍然不愿意在公共场合使用。所以有时候，不管是产品经理、科学家还是工程师，其实都很难对这种事情下一个绝对判断。真正的问题永远是：到底有多少人，真的会去用你的CLI？
答案可能很残酷——绝大多数人一辈子都不会点开那个黑框。
六、Office等专业软件 Grounding 会是GUI的突破点吗？实现后会怎么样？
Tianbao
那我先把问题说得非常具体一点。假设我们站在一个架空的世界观里，所有技术条件都已经成熟，那么其实只有两个清晰的选项。
第一个选项是GUI agent：GUI做得极其丝滑，几乎是“所见即所得”。
第二个选项是coding / CLI路线：同样比现在丝滑得多，模型更强，工具链更完整。
在这个前提下，其实很多所谓“GUI vs coding”的争论会变得没那么本质。因为你仔细拆一下就会发现，不管是PPT还是Word，本质上都和网页、Markdown很像：它们都是结构化文本+多媒体文件的组合。
如果模型真的足够强，它完全可以“凭空吐XML、吃XML”，再把中间的图片、布局、结构组合好。这在模型能力上是完全成立的，只是今天还没做到足够稳定而已。
从用户视角来看，问题就变成了一个任务执行方式的选择。比如一个非常现实的任务：你有一个包含100个PDF的文件夹，你已经手工整理好了1个，现在希望AI按照同样的规则把剩下99个全部整理完。
这时其实有两条现实路径：
第一条是coding / 神经符号（neural-symbolic）路线。 你通过CLI或脚本把PDF读进来，清洗、解析、调用模型、输出结构化结果，然后循环执行。今天来看，这条路径的效果明显更好：流程清晰、标准作业程序（SOP）明确、循环可控，更稳、更鲁棒。
第二条是CUA / GUI路线。 你更像是在下指令：打开第一个PDF，看两眼；关掉；打开第二个，再看两眼……大量原本由代码完成的步骤，被图像token和界面操作取代。这条路在今天明显更容易出错，稳定性也更差。
所以在当前技术条件下，第一种方案几乎一定更优。但如果我们假设未来某一天，这两种方式都变得“足够爽”、足够稳定，那问题就不再是“哪条技术路线更好”，而是用户想要哪一种体验。而且这个答案很可能因人而异。
进一步拆，其实还可以按前台/后台、同步/异步来区分：
有些任务是后台、异步的，用户只关心最终交付物。那你是放在虚拟机里用GUI做，还是在服务器上用coding跑，真的无所谓。
但有些任务是前台、同步的。用户希望“看着它做”，获得一种掌控感和安全感。这时候很多人反而更倾向于CUA / GUI。
所以我们实际上面对的是一个极其宏大的可能性空间：不同任务、不同用户、不同时间尺度，对应的最优形态可能完全不同。
而我个人的判断是：未来极有可能是一个高度混合的状态。不是哪条路线彻底胜出，而是不同技术在不同场景下共存，各自发挥优势。
X
像文件系统管理这种事情，本来就非常适合用代码来做。比如最简单的例子——给100个文件重命名，这件事用code半秒钟就解决了。所以至少在短期内，我是明确投票给“把coding和GUI融合在一起”的路线。
但在这个过程中，我自己还有一个越来越强的感受：agent的长期发展一定离不开记忆（memory），以及围绕memory的一整套能力。
你会发现，现在的模型在第一次做某个任务时，往往需要大量探索。但问题在于——试过一次之后，它就不应该再重新试一遍。第二次遇到类似任务时，它应该能基于第一次的经验，直接选择更高效的路径。
而现在的大多数agent，本质上是“没有记忆的”。它更像一个标准化流程的服务员。但我们真正想要的，其实是一个个人助理——你跟我待得越久，对我越了解，协作就越顺。
这一点在GUI agent上尤其明显。在ToB场景里，你希望它能把经验固化成一個工作流（workflow）：动作更稳定、路径更明确、出错概率显著降低。
我觉得这一块，其实是现在大家相对比较忽略的一个话题。从用户角度来看，很多时候问题并不复杂：哪个快用哪个，哪个不打扰我用哪个。
而效率本身，又是高度场景相关的。所以我觉得，未来一定会出现大量我们现在根本无法完全预判的场景。但我会认为，一个比较理想的形态是：让agent自己具备判断和决策能力——基于历史经验、任务类型、上下文，去决定“这次该用code，还是该用GUI”。
这也意味着，在大家逐步解决agent “可用性”之后，下一个阶段的核心挑战，会是从可用走向好用。而这一步并不简单。
在我看来，这里面仍然有大量算法层面的未定义问题，尤其是围绕memory、在线学习（online learning）、经验固化这些方向。我自己最近也一直在思考这些问题。
但我会很确定地说：这就是agent的下一个阶段，而且是一个非常重要的阶段。
七、大模型厂为什么不像 Coding 那样砸钱做 GUI？
X
在做这件事的时候，一定要用商业和生产力视角来看，而不是只用算法视角。一旦第一个人把这条路跑通，并且真的用它赚到钱了，后面的事情就会变得非常简单——大家会迅速跟进。
但现在的问题在于：产品市场契合度（PMF）还没有被验证出来。这当然也和模型本身还不够成熟有关。即便是今天的模型，哪怕用在coding场景下，你也很难说“已经特别好用了”。
所以我会认为，这是当前的根本问题。只要这个问题被解决，后面的推进速度会非常快。
第二个判断，其实就回到一个非常现实的标的上：收入在哪里？在美国、尤其是硅谷，其实有一个非常清晰的参照物——UiPath。UiPath是RPA的典型代表，它一年能做到大概10亿到20亿美元级别的收入。那问题就很直接了：GUI agent能不能做到类似的规模？
如果未来最强的一家GUI公司，能够在硅谷靠这条路线做到一年10亿美元的收入，那这件事就“成了”。这也是很多一线基金在脑子里会自然摆出来的对标模型。
而且通过GUI agent，你有机会释放出大量原本RPA很难覆盖的场景。传统RPA最大的问题就是：难写、难维护、脆弱。GUI agent如果真的跑通，可以把原本不经济、不现实的自动化场景全部打开。
所以问题最终只剩一个：你能不能把这10亿美元的收入真正装进自己口袋里？
Tianbao
放在当下这个时间点来看，我觉得GUI方向还没有真正出现killer app。即便像Manus这样的产品里已经能看到一些GUI的影子。但整体上的“胜利”仍然主要来自coding路线。比如它最终能交付PPT、文档之类的结果，并不是因为GUI在里面起到了关键性的调试或修饰作用，而更多还是靠代码路径跑通的。
但这并不意味着GUI是不必要的。事实上，很多事情哪怕是在PPT这种场景下，也确实存在一些无法完全靠代码解决的最后一英里问题（last mile）。理想状态当然是：模型足够强，直接吐图、吐XML；但现实是，总有一些细节、一些审美或交互层面的东西，仍然需要GUI介入。
现在的问题在于，这些last mile在当前阶段更多只是概念验证（proof of concept）。很多用户暂时并不关心，但一旦产品真正开始对齐用户的真实痛点，这些问题迟早会被重新捡起来。
我还想再补一个更偏“研究层面”的判断：GUI agent可能是目前最简单、也最容易被评估的AGI等价物（AGI equivalence）之一。
你如果在机器人学（Robotics）里试图宣称AGI，会非常困难。系统里充满了各种“杂质”。你很难拿出一条清晰的“主线模型演进史”。
但GUI agent / 桌面智能体是可以做到这一点的。它天然是多模态的，又可以逐步扩展到更复杂的场景，比如游戏智能体——需要时间敏感、视频流输入、动作流输出。这种场景非常干净，也非常可控。
正因为如此，历史上我们才会对一些“等价物”产生强烈共识。比如AlphaGo打败李世石、柯洁，之所以能引发如此大的社会反响，是因为围棋本身是一个被高度认可的等价物。
同样地，如果未来有agent能在复杂游戏中打败顶级职业选手，或者一个computer-use agent能真实地接管大量白领工作的80%以上，那它作为AGI等价物的说服力会非常强，而且是切实可行、可评估、杂质极少的。
我甚至会认为，所有真正怀有AGI野心的公司，最后都会在某种意义上走到这一点。 因为对研究科学家和工程师来说，这是一条极其有吸引力、也极其“可证明”的路线。
而GUI agent不一样——没有视觉，它就不存在。这点和CLI有本质区别。正是这种“不可替代性”，让它成为一个极其独特、也极其重要的方向。关于AGI和智能体的更多深度技术探讨，可以在 云栈社区 的人工智能板块找到相关资源。
八、GUI Reward Hacking 和 Refusal 问题怎么解决？
X
我觉得奖励攻击（reward hacking）本身是非常普遍的现象，几乎不可避免。这个问题说实话也没什么“银弹”，最终还是靠不断地调训练方法、调数据分布，慢慢去压。
但拒绝（refusal）是另一类问题。在我看来，refusal与其说是技术问题，不如说更多是一个产品问题。原因在于：GUI agent在“算法上可用”和“产品上ready”之间，其实差得非常远。
从模型和算法角度看，你的agent已经能干很多事情了，权限也很大；但一旦你真的把它往产品形态上推，就会立刻遇到大量现实约束——有些动作不好拦截，有些行为风险很高。
这时候你会发现，要把产品铺开，是有很多前提条件的，而这些事情恰恰都不是算法团队愿意、也不擅长去做的。但如果你不把这些问题解决掉，产品又根本上不了线。结果就会变得非常尴尬：你不放开权限，用户说你“什么都干不了”；你一放开权限，又会带来各种风险和合规问题。
但从agent本身的角度来看，算法层面的refusal其实并不严重。因为agent面对任务，本质上总是可以先试一试的。所以对agent来说，“先做再说”本来就是合理行为，refusal并不是它的自然状态。真正复杂的是产品层面的控制与审查。
这一点我觉得Claude Code在权限管理上的设计就做得非常好。相比之下，很多工具在权限这块显得比较草率。它并不是假装系统“不危险”，而是明确承认系统本身是有风险的，然后通过一整套完整的权限管控、确认机制，把风险暴露给用户，并让用户参与决策。
我觉得这件事非常重要，而且是一个典型的产品级核心问题。它不是算法能单独解决的，但如果不解决，GUI agent就永远停留在“技术演示”，而走不到真正可用、可规模化的阶段。
Tianbao
我也从技术角度补充一下这个问题。
首先，reward hacking是一定会存在的，这一点几乎没有争议。原因在于RL训练本身就是一个高度复杂的系统工程：它不仅涉及算法本身，还涉及环境的设计、整个RL基础设施的稳定性、以及数据来源。
而一旦进入数据和奖励设计层面，就天然存在被攻击的空间。所以这本质上是一个系统性工程问题，需要非常严谨的组织能力和工程纪律。即便如此，你也很难保证模型在任何情况下都不绕规则。
举一个很具体的例子。之前在OSWorld里有一个case：我们让agent去点一个叫ThunderBird的图标——一个蓝色小鸟抱着白色信封；但它却经常点到Firefox，因为Firefox是一只橘色狐狸抱着一个蓝色地球。在经过视觉语言模型（VLM）处理之后，这两者在模型眼里可能并没有那么大的差异。某些训练数据的偏移，在这种情况下就会被放大。
这类问题如果发生在高风险操作上，后果会非常严重。比如你让它把文件整理到一个目录里，它却把所有文件拖进垃圾桶并清空。所以这里一定需要兜底机制（guardrail）。而且兜底机制不是只存在于训练阶段，而是要贯穿训练、产品设计和线上运行的整个生命周期。
这也是为什么像Claude Code这种产品在权限控制上做得非常谨慎：IP控制、内容控制、目录控制，这些并不是“保守”，而是工程上必须的安全边界。从工程角度看，这些能力其实并不新。早在GUI agent之前，云服务和虚拟化环境里就已经有类似需求。
但GUI agent这里会多出一些新的、非常现实的兜底需求：
第一类是法律和责任兜底。 如果agent在用户前台“乱点”，你必须在产品上明确：哪些内容是agent自主行为，哪些不归你负责。
第二类是技术层面的兜底。 最理想的状态，是agent能识别用户的关键文件，并在必要时将这些文件同步到一个云端沙盒里执行操作——沙盒是安全的、隔离的、私有的，权限是被严格封锁的。
这里其实可以遵循一个非常工程化的原则：最小改动原则（minimal change）。如果用户只关心最终交付物，那agent就不应该大规模动本地环境；只同步必要的上下文，在安全沙盒中完成计算，然后交付结果。
当然，也不能走到另一个极端——纯云端。纯云端会引入大量新的摩擦成本。所以比较现实的折中方案是：在minimal change的前提下，把风险选择权交还给用户——用户可以选择是否接受更高权限、更高风险的执行路径；系统在机制上允许把任务路由到云端沙盒；默认路径是安全、保守的，但不是完全“封死”。
现实中，大多数用户并不会真的去做极端破坏行为。所以总结来看，现在的状态有点像是两头堵：一头是完全放开，风险不可控；另一头是过度保守，体验完全跑不起来。真正难、也真正有价值的工作，是在中间找到一条工程上可落地、产品上可接受、法律上可兜底的路径。
X
我的整体感觉是这样：安全性这块，其实现在非常缺产品定义，也非常缺产品化，而且确实很难。即便到2026年，agent在技术上可能已经成熟了一年，但产品层面是否足够成熟，我其实是持相对保守态度的。技术成熟和产品成熟之间，差距还是很大的。
如果一定要判断，我会说：2026年agent在产品形态上做到“非常成熟”，难度还是挺高的。但与此同时，我觉得有一条路径是很现实、也很有可能跑通的。
这条路径，其实是coding给我的一个很大启发：你先把开发者服务好就够了。 先让开发者玩起来，让他们爽。开发者本身就已经有足够多的应用场景了。而且当我们谈AI要落地到“各行各业”时，我一直觉得一个常见的误区是：妄想由模型公司自己把所有行业的落地都干完。这既不现实，也不符合社会分工和资源分配的规律。
更合理、至少在短期内更有效的方案是：把能力做成一个对开发者极其友好的平台，然后让开发者自己去把它交付到各个行业。在这个前提下，很多问题反而会变得简单一些。
比如安全性：面向开发者的产品，可以不需要那么“极端严格”。开发者本身就是相对专业的人群，他们有能力规避很多风险，也愿意为复杂性买单。你只需要把基础安全边界做好，剩下的交给他们。所以从这个角度看，Anthropic的策略是非常聪明的：它明确选择了开发者优先。当然，这也意味着它放弃了成为一个ToC超级应用的机会。从现实成功概率和资源配置来看，这样的取舍是理性的。
九、工程和产品团队应该做什么？
X
原则一：做与模型能力提升正交的事。 有人比喻做AI产品像在电梯里做引体向上——费力上升后，模型进步可能使工作白费。若工程和产品化方向与模型进展平行，处境会很被动。Claude Code做的大部分事情与模型能力方向正交。
原则二：产品的PMF非常明显。 技术出身的人初做产品容易高估市场接受度，但实践后拿到产品的第一瞬间就能判断有无用户。
原则三：用户习惯难以改变。 AGI本身是颠覆性的事，但不一定在一两年内发生，更可能是十年尺度。产品越贴合用户现有习惯和工作流，越容易成功。
Manus代表另一种思路，过去一年持续筛选用户，最终留下高净值、学习能力强的专业用户，愿意接受新工作模式。这种可以尝试改变工作习惯，但需谨慎。
产品定义不清楚时，先做技术。有些问题可能随技术突破迎刃而解。
Tianbao
工程团队精力应放在RL环境和基础设施（Infra）上。若有富余人力，投入环境的扩展（scaling）收益最大。
当前数据非常缺乏多样性。可能每个前沿团队都曾设想多种路径，包括收购类似TeamViewer的公司获取远程遥控轨迹数据，但发现在合规层面行不通。
做RL需要专门的环境。否则需在公开网络采集数据，涉及IP池、账号池等灰色操作。想自给自足就要复制整个互联网和软件生态系统，做模拟版Gmail、B站等，不仅要做界面还要做数据库。若全过程合规，成本会非常高。
这需要大量人力，可借助前后端工程师和自由职业者（freelancer）。需要建立合理的组织架构，当前数据公司的交付物多样性和质量仍有不足。
十、Real-time 操作的前景如何？
X
GUI确定后可以先取得一些价值再做实时（real-time）操作。虽有挑战，但应该有办法，主要看收益大小。
Tianbao
传统意义上定义的computer use或mobile use不是时间敏感的（time-sensitive）。日常工作流里很多任务，5秒钟点和1秒钟点差别不大。
实时性在秒杀、抢单、游戏等场景下较为重要。
最近有一些相关工作，如字节团队、Google DeepMind持续推进的项目。打游戏是非常好的AGI等价物，是time-sensitive的，有视频流输入和输出。但当前VLM无法支撑游戏频率，可能要到5Hz或10Hz才可以。现在不太可能，推理引擎再快也得好几秒，用户体验也不佳。
十一、Online Learning 和 Memory 什么时候能落地？
结合工业界和学界的经验，像在线学习（online learning）、测试时训练（test time training），或者广义上的自我改进（self-improving）这些目前比较有希望的方向，实际前景如何？工业界如果要落地大概需要多久？
X
Online learning和memory是一体两面。Memory是架构（Architecture），涉及架构和框架；online learning是优化手段。 抛开任何一个单独讲都不合理，这两者必须同时做。
场景非常重要。有些场景这个能力可能作用有限。
2026年是适合在Benchmark上做定义的好时机。现有memory benchmark实际更接近长上下文（long context）benchmark，缺乏实际意义。
Memory可以基于上下文，但一定要可学习（learnable），否则无法用online learning优化。可能至少需要一个上下文管理（context management）agent来做上下文管理，这是可训练的（trainable），可以用函数调用、用RL来优化。再进一步做权重内学习（in-weight learning），把上下文内化成参数。
预计两三年落地。今年可能先有好的定义工作出来，明年开始做优化，2028年有好的应用跑出来。
Online learning不一定与agent绑定，如Cursor的Tab RL就与agent无关。非agent场景可能2026年底至2027年初落地，agent场景预计2027年下半年——因为2026年需先解决agent可用性问题。
对Transformer架构的专门优化还有点早，可以先在前两步推进。
Tianbao
按这个尺度评估，至少需要三四年。
关于memory的存储形式，过去主要是像Manus这种上下文管理机制。未来可能会更多转向参数内的连续化机制，因为离散化机制效率较低，且受制于flops问题。
目前大家对模型架构的改造还是偏保守，主要在改线性注意力（linear attention）和门控注意力（gate attention）这些方向。
结语（金句摘录）
- 若一个Benchmark涉及过多要素，作为工业界指标时很难产生有效信号，在模型早期阶段这个信号缺乏意义。
- 建议选择3-5个未来最易被替代的职业，做能结合CUA、Coding、API和deep research解决的Benchmark。
- 让agent去适应现实环境，一定比要求环境为agent做大规模改造要容易得多。
- 我还是比较坚定地认为，做agent这件事必须闭环来做。你一定要拿到真实的用户反馈，否则你做出来的东西最终就是一个“没法上桌”的系统。
- 自动驾驶早期有高精地图和端到端两套方案，最终端到端胜出——车适应环境比环境适应车容易。Agent同理。
- 硬盘 + 计算单元 + 一个interface。问题从来不是“要不要interface”，而是interface该长什么样。
- GUI agent可能是最“干净、可评估”的AGI等价物之一，具备长期研究吸引力。
- Online learning和memory是一体两面。Memory是Architecture；online learning是optimization手段。抛开任何一个单独讲都不合理。
- 我会很确定地说：这就是agent的下一个阶段，而且是一个非常重要的阶段。
- 那它作为AGI等价物的说服力会非常强，而且是切实可行、可评估、杂质极少的。我甚至会认为，所有真正怀有AGI野心的公司，最后都会在某种意义上走到这一点。
发表于 5 天前
|
查看: 18|
回复: 0
