AutoGLM 2.0：标准化环境中 AI 智能体的实践 —— 云端设备、实测表现及能力边界与未来发展方向探析

在人工智能与现实世界交互的探索进程中，智谱推出的 AutoGLM 2.0 无疑是一次颇具争议却又引人深思的尝试。当去年 AutoGLM 在发布会上展现出 “操控手机” 的能力 —— 从面对面建群、修改群名到在群里发出百个红包，总额达两万元时，观众的惊叹声似乎预示着 AI 智能体已然能突破虚拟与现实的壁垒。但当舞台切换到真实世界，诸多问题便立刻暴露：不同用户的微信版本各异，UI 布局存在明显差异，有人使用折叠屏，有人则是小屏手机，甚至突如其来的广告弹窗都可能让任务中断。对大模型而言，这些现实世界中的不确定性，都是难以完全掌控的变量。

面对这样的困境，智谱选择的答案并非一味提高模型的 “认知力”，而是另辟蹊径：直接绕开现实世界的不确定性，打造一个 “标准化” 的世界。于是，AutoGLM 2.0 应运而生，它的核心并非算法上的重大突破，而是一台云手机 —— 尺寸统一、软件版本统一、功能范围统一。在这个虚拟世界里，Agent 的操作才有了被保证的可能。换句话说，AutoGLM 2.0 所体现的思路，不是去驯服手机，而是通过建立一个自己能掌控的环境来驯服混乱的现实。

AutoGLM 构建的 “标准化” 世界主要依托于两台云端设备：一台智能体手机和一台智能体电脑。手机主要承担生活助手的功能，负责出行、点餐等日常事务，而电脑则承担办公研究的功能。我们不妨先深入看看这两台设备，智谱为了让 Agent 稳定运行，在这个定制的世界里保留了哪些功能，又牺牲了哪些。

先看 AutoGLM 云手机，除去系统自带的相机、时钟等 APP，额外预装了 30 款 APP，基本能覆盖生活和娱乐的主要场景。社交资讯类有微博、小红书、今日头条；长短视频类包含红果、抖音、快手、B 站、爱奇艺、腾讯视频、芒果 TV；音乐广播类有 QQ 音乐、汽水音乐、喜马拉雅；小说阅读类有番茄小说；消费购物类有同花顺、淘宝、京东、拼多多；本地生活类有美团、饿了么、大众点评、支付宝、KFC、Keep；出行与旅行类有滴滴打车、携程、去哪儿、高德；租房类则有贝壳找房。

但想要通过浏览器下载新的软件，几乎是不可能的事情。有测试者尝试安装盒马和知乎，系统直接禁止，提示软件包无效，甚至连知乎的官方下载网页都被设置成了 404。再看配置，云手机是一台基于安卓 14 的设备，型号为 SM-F900F，通过搜索可知，这台设备竟是三星第一代折叠手机 Galaxy Fold。若云手机使用的是完整设备，而非仅仅采用 Fold 的系统，那么其配置便是骁龙 855 处理器，12GB RAM + 512GB 存储。要知道，骁龙 855 是 2018 年底发布的处理器，放在如今，应对一些复杂的应用操作或许已有些吃力，与当下主流的骁龙 8 Gen2、天玑 9300 等处理器相比，在运算速度和多任务处理能力上都存在明显差距，这难免会对 Agent 的操作流畅性产生一定影响。

再看 AutoGLM 云电脑，它是一款基于 Ubuntu 系统的设备。从软件生态来看，除了浏览器外，云电脑只安装了 Libre 办公软件，或许在 AutoGLM 的定义里，所谓的办公就仅限于 Word、Excel、PPT 这三件套。同样，AutoGLM 云电脑删除了 Ubuntu Softstore，禁止用户下载新软件，这就使得用户无法根据自身办公需求添加专业的设计软件、编程工具或是数据分析工具等，极大地限制了其在复杂办公场景中的应用。

了解了 AutoGLM 云手机和云电脑的大致情况后，我们对其能力边界有了一定认知，接下来不妨看看在限定的环境中，AutoGLM 的实际表现究竟如何，而测试过程中，广告与登录成了最大的障碍。

先看云手机任务中的淘宝购物测试，测试的 prompt 是 “帮我清空淘宝购物车再购买官方店铺的 iphone16 pro 1t 版本”。在这个测试中，AutoGLM 展现出了较为完整的流程：从网页搜索、需求澄清到应用操作都能按部就班地进行。但问题出在了账号登录环节 —— 如今国内的应用几乎都要求登录才能使用。AutoGLM 会在检测到登录需求时提示用户 “接管”，由人手动输入账号密码，之后退出接管继续任务。

然而，国内 APP 对于账号的 “安全意识” 极高，很多应用的安全验证远比输入账号复杂。比如登录小红书时，可能会提示需要用旧设备扫码才能登录，而测试者的旧设备可能正在使用 AutoGLM；登录抖音时，可能需要扫脸进行身份验证，但 AutoGLM 常常会显示加载摄像头资源，好不容易加载完成，镜头中的人像也可能因画面扭曲导致识别错误，最终登录失败。小红书登录失败也直接导致了一些联动功能无法使用，比如在去年的 AutoGLM 版本中，可以实现在小红书搜索红烧肉做法及食材，然后在小象超市购买，如今却因登录问题难以实现。当然，这或许不能完全归咎于 AutoGLM，国内手机应用生态的复杂安全机制可能确实不适合 AutoGLM 当下的发展模式。

更糟糕的是，AutoGLM 不会记住用户的账号密码，这在安全性上有保障，但每次使用需要登录的 APP 时，过程都十分煎熬。此外，在使用抖音人脸识别登录时还发现，当 AutoGLM 调用摄像头资源后，即便在 AutoGLM 云手机中退出抖音并清理后台，也不会结束 AutoGLM 对摄像头的调用，除非将 AutoGLM 整个关闭，这一细节也反映出其在资源管理上的不足。不过回到任务本身，除去登录等问题，AutoGLM 还是可以轻松完成清空购物车等任务的，并且在执行删除、购买等关键动作时，会提醒用户是否要继续，这一设计在一定程度上降低了误操作的风险。

再看另一个云手机任务 —— 购买机票，prompt 为 “上去哪儿网买一张后天 11 点到 14 点，从上海飞北京的机票，不要波音飞机”。这个任务本身并不复杂，但测试者特意选择在 23 点接近凌晨的时间进行测试。任务有几个关键点需要 AI 识别，分别是 “后天”“11 点到 14 点”“上海飞北京”“不要波音”。然而，尝试了两次都失败了。

先看航班选择，AutoGLM 第一次在机票时间上出错，第二次在日期上出错，但航程起点和终点是正确的，并且都没有选择波音飞机。至于出错的原因，通过观察 AutoGLM 的操作逻辑能发现一些端倪。首先是日期选择的 bug：进入日历页面再退出后，“后天” 常常会莫名变成 “大后天”，这种问题虽不稳定复现，但足以说明它在基础交互上还不够可靠。时间选择的问题更明显，AutoGLM 并非真正理解 “11 点到 14 点” 这个条件，而是机械地依赖去哪儿网的预设选项，而平台上只有 “9–12 点” 和 “12–15 点” 这两个区间，它会随便挑选一个，若刚好有符合的航班，那便是 “歪打正着”，一旦没有，就直接出错，换句话说，这并非真正的智能，更多是一种巧合。

在测试该任务时，还发现了和会员登录同样麻烦的东西 —— 弹出广告。一旦有广告弹出，AutoGLM 会愣在那里，等几秒后，若广告有自动消失的设计，AutoGLM 就会继续执行任务，而遇到那些不会自动消失的广告，就需要用户接管，这严重影响了任务进程的流畅性。

再看云电脑任务 —— 制作 PPT 并发小红书。与 AutoGLM 云手机不同，云电脑只能操控浏览器，因此，让其生成 PPT、表格等内容时，它都会用智谱 CodeX 编程来完成。从页面功能来看，AutoGLM（云电脑）可以看作是一个增加了浏览器控制功能的 Agent。测试的 prompt 是 “搜索特斯拉最新发售的 Model YL 信息，并做成 ppt 发布到小红书”。在执行时，AutoGLM 会先通过浏览器搜索，打开汽车之家等页面收集信息，再整理成 Markdown 文档，最终生成 PPT 供用户下载。这一步其实并不特别，kimi、元宝、豆包等工具也都能做到。AutoGLM 最大的特点在于调用浏览器完成任务的最后一步 “发布到小红书”，但遗憾的是，AutoGLM 失败了，它成功打开了小红书发布网页，却卡在了 “上传” 页面，原因可能是 AutoGLM 没有完成它已规划好的将 PPT 转换成图片这一任务。

为了验证 AutoGLM 操控浏览器的能力，测试者选择官方建议的 DEMO 尝试了一遍：“帮我生成一个视频，一个小狗半夜偷偷地去蹦床上跳，监控视角。然后把这个视频发到小红书上，和大家分享”。结果依然相同，内容生成没问题，但到了上传页面，AutoGLM 只能提示 “请手动上传”。测试者接管电脑后发现，更尴尬的是：云电脑似乎无法保存生成的视频文件，只能找到前几个任务遗留的 PPT 和.py 文件。其实从 AutoGLM 的介绍页面也能看出，其主要功能就是 AI PPT、AI 视频、AI 播客、AI 研报、AI 编程等，单独为这些功能配置一个云电脑，其必要性确实值得商榷。

从实测中暴露的能力边界，其实也能折射出 AutoGLM 背后的技术路径选择。AutoGLM 的技术演进路径体现了智谱的独特策略，其沉思模型（GLM-Z1-Rumination）通过强化学习实现自我批评和动态验证，能在未被明确教导的情况下自主访问巨潮资讯网等平台。这种 “边想边干” 的能力突破了传统 Agent 的被动响应模式，让它在处理一些需要主动获取信息的任务时更具优势，但受限于标准化环境，其自主性仍存在明显局限，比如无法根据新的应用场景自主扩展功能，也难以应对超出预设范围的交互情况。

与国际竞品相比，AutoGLM 在本地化部署和成本控制上有一定优势。例如，其推理速度是 DeepSeek R1 的 8 倍，成本仅为 1/30，且支持消费级显卡运行，这使得它在一些对成本敏感且不需要过于复杂功能的场景中更具吸引力。然而，在多智能体协同和复杂任务处理上，它与部分竞品仍有差距，比如百度 GenFlow2.0 等产品已支持超 100 个 Agent 并行工作，而 AutoGLM 仍停留在单设备操作层面，这在处理需要多工具协作的复杂任务时，效率会大打折扣。

而这种技术路径的选择，也自然引发了关于智能体本质的讨论：如果一个 Agent 只能用固定的功能，那它还是 Agent 吗？答案或许并不重要，但这个问题背后涉及对智能体核心能力的界定。从技术层面看，Agent 的本质在于自主决策和环境交互能力。AutoGLM 虽能在限定环境中执行任务，但其操作依赖预设流程，缺乏对未知情境的适应性。比如前面提到的日期选择的偶发性错误和广告处理的机械性，都暴露了其 “智能” 的局限性，它无法像真正的智能体那样，根据新出现的问题灵活调整策略，更多是在预设的框架内机械地执行步骤。

行业标准的发展也为这一问题提供了参考。中国信通院发布的软件开发智能体标准强调感知、记忆、规划、执行能力的全面性。AutoGLM 在执行能力上表现突出，能按照指令完成既定的操作流程，但在感知能力上存在不足，比如对广告弹窗这种突发情况的识别和处理能力较弱；在规划能力上也有欠缺，面对 “11 点到 14 点” 这种超出预设选项的时间要求时，无法自主规划更合理的筛选方式，尚未完全满足行业标准对智能体的全面要求。

尽管存在诸多不足，智谱对于 AutoGLM 的未来已有明确的规划，下一步计划包括开源核心技术、推出虚拟机版本和开放 API。这些举措旨在吸引开发者，扩展应用场景。例如，通过 API 接入，AutoGLM 可赋能智能眼镜、家电等设备，实现跨硬件操作，这在一定程度上能弥补其当前功能固定的短板，让它能在更多的设备场景中发挥作用。

但要真正提升 AutoGLM 的实用性，还需解决两大核心问题：验证机制适配和广告干扰处理。在验证机制方面，智谱可探索与应用厂商合作，简化登录流程，比如为 AutoGLM 开辟专门的验证通道，减少复杂的扫码、人脸识别等步骤，让登录过程更顺畅；在广告干扰处理上，开发专门的广告识别算法，让 AutoGLM 能自动识别并关闭广告弹窗，避免因广告导致任务中断。此外，引入多智能体协同机制也很关键，将复杂任务拆解为子任务并行执行，比如让一个 Agent 负责信息搜索，一个 Agent 负责内容生成，一个 Agent 负责发布操作，可能是突破单设备局限、提升任务处理效率的关键。

AutoGLM 2.0 作为 AI Agent 发展中的一次重要尝试，其标准化思路在特定场景下证明了可行性，它通过构建统一的虚拟环境，在一定程度上解决了现实世界中设备差异、软件版本不兼容等问题，让 Agent 的操作有了稳定的基础。但同时，它也揭示了封闭系统的天然缺陷 —— 功能固定、灵活性不足，难以应对现实世界中复杂多变的情况。

未来，Agent 的进化需要在确定性与开放性之间找到平衡：既要通过技术手段降低现实世界的不确定性，比如进一步优化标准化环境的适配能力，让它能兼容更多的应用场景；又要保持对复杂环境的适应性，通过技术创新提升自身的感知、规划能力，让它能灵活应对各种突发情况。正如智谱 CEO 张鹏所言，人机协作的未来在于 “自身能力 + N 个 AI 智能体”，而这一愿景的实现，离不开技术创新与生态共建的双重驱动。智谱需要持续优化 AutoGLM 的技术能力，同时联合更多的开发者、厂商构建完善的生态，让 AutoGLM 能在保持操作稳定性的同时，拥有更强的适应性和扩展性，真正成为人机协作中可靠的智能伙伴。