Chrome Auto Browse 的测试显示：AI代理能做事但不够自动。借此对照 Tesla 与中国车企AI战略差异，给内容团队可落地的代理使用方法。
AI代理还不够“自动”：从Chrome到车企的两条路线
2026-02-12，Ars Technica 做了一组挺“残酷”的测试：让 Chrome 里的 Auto Browse 浏览器AI代理替人完成一堆网页任务，结果平均分只有 6.5/10，中位数 7/10。它能把电价方案筛得又快又准，也能在网页里替你把 2048 玩上 20 分钟；但一碰到 Gmail 归类、Google Sheets 填表、YouTube Music 按钮识别这种“自家地盘”，反而翻车。
我更愿意把这件事理解为：AI代理的真实能力边界，正在被现实的UI、权限、时间与责任机制一点点“磨”出来。而这条边界，恰好能用来对照另一个更大的赛道——车企的人工智能战略。
在「人工智能在媒体与内容产业」这个系列里，我们经常讨论推荐、画像、审核与智能创作。但到了 2026 年，一个更接近“生产力”的方向正浮出水面：AI代理替你跑流程、跨系统取数、做决策。浏览器代理是最直观的入口；汽车行业则是最昂贵、最复杂、最难出错的入口。
Chrome Auto Browse 的启示：AI代理真正的难点不在“会说”，在“会做”
直接结论：浏览器AI代理的上限由三件事决定——可操作性（UI/控件）、可持续性（等待/监控）、可验证性（结果可追溯）。Ars 的测试把这三点暴露得很清楚。
1）可操作性：UI一变，代理就“迷路”
Auto Browse 在 PlayStation 商店里能改排序、能翻页、能逐个打开商品页，还会在“加入愿望单/库”前请求确认，说明它的网页操作链路已经相当成熟。
但它在 YouTube Music 上“找不到按钮”，在 NeoCities 的悬浮菜单上卡死，甚至在 Google Sheets 里把字段覆盖、把日期塞进无标题列。这里面没有玄学：
- 网页控件缺少稳定的可识别锚点（按钮样式、层级、动态加载、悬浮触发）
- 代理的动作规划依赖“看起来像什么”，而不是“语义上是什么”
- UI一旦偏离常见模式，代理就会进入循环、反复试错，最后求救
一句话很适合放在企业内部做共识：
AI代理不是“懂业务的人”，它更像“手脚很勤快但容易分心的实习生”。
2）可持续性：超过几分钟的等待，基本都会失败
测试中最典型的是“听一小时直播并记录歌曲”。Auto Browse 和 OpenAI 的同类产品都不愿意长期停留页面监控——成本、资源占用与失败风险都太高。
这对内容行业尤其关键：很多媒体与内容运营流程本质上是 长时任务，比如：
- 舆情/热搜监控与摘要
- 竞品频道更新追踪
- 直播切片与字幕校对
- 广告投放与转化漏斗的定时巡检
如果代理做不到稳定“守候”，那它就只能做 一次性的抓取，而不是“真正替你跑一条工作流”。
3）可验证性：你必须能知道它做了什么、为什么这么做
Gmail 扫描 PR 邮件那个任务被打了 1/10，原因之一是：它用了“后台工具”抓取，你看不到它到底搜到了哪些邮件、过滤条件是什么、漏了什么。
对于企业来说，这叫 不可审计。在内容审核、品牌安全、商业情报这种场景里，不可审计基本等于不可用。
把浏览器代理当“沙盘”：为什么这和车企AI路线有关？
直接结论：Chrome 代理暴露的问题，正是自动驾驶与智能座舱里最难的部分：在开放环境中执行动作，并对结果负责。
浏览器是一个“低风险的开放世界”：页面各不相同、按钮层出不穷、还经常改版。汽车是“高风险的开放世界”：道路情况更复杂、代价更高、责任更重。
所以我常用一个对照来解释：
- 浏览器AI代理 = 在互联网里“执行动作”的通用机器人
- 车企AI系统 = 在物理世界里“执行动作”的通用机器人（难度高几个数量级）
在这个背景下，Tesla 与中国汽车品牌的AI战略差异就更清晰了。
Tesla 的AI主线：用端到端与规模化数据，把“会做”做成系统能力
先给结论：Tesla 更像是在用一条主干（自动驾驶/车端感知-决策-控制）贯穿数据、训练、部署与迭代，核心目标是把动作执行做成可持续的工程体系。
这种路线的关键点通常包括：
- 数据闭环：车队持续回传“困难样本”，驱动训练集更新
- 统一的模型与栈：从感知到决策尽量减少拼接，提高一致性
- 快速迭代：通过 OTA 把模型能力推到车端，再从反馈中修正
把它映射回 Auto Browse 的问题：Tesla 的优势不在于“它会不会某个功能”，而在于它把失败变成可学习的样本，把样本变成迭代速度。
对内容产业读者来说，这个思路很有启发：真正能拉开差距的不是你接了哪个大模型，而是你有没有数据闭环与可复盘的工作流。
中国汽车品牌更常见的AI打法：多供应链、多场景、快落地，但系统一致性更难
同样先给结论：中国品牌更像“场景驱动 + 供应链整合”的打法：座舱先把体验做出来，智驾分层推进，商业化节奏更紧。
这条路线的优势非常现实：
- 座舱体验升级快：语音、导航、娱乐、生态联动能迅速可见
- 成本与配置弹性大：不同车型可以采用不同方案
- 与本地应用生态融合更深：地图、支付、内容平台、车机应用
但挑战也明显：
- 系统一致性与统一数据标准更难（多供应商、多代际并存）
- 跨域协同难：座舱的“会说”与智驾的“会做”往往是两套体系
- 可审计与责任链条更复杂：一旦出问题，很难快速定位责任与证据
把 Auto Browse 的“在 Google 自家产品里反而翻车”对照一下：当系统由多个团队、多个界面、多个权限体系拼在一起时，AI代理/AI系统最容易出问题的，恰恰是“最后一公里”的执行与对齐。
给媒体与内容团队的落地建议：把AI代理用在“高收益、低风险、可验证”的环节
如果你正在评估 AI代理（浏览器代理、办公代理、内容运营代理），我建议按下面三条筛选场景：
1）优先选择“可结构化验收”的任务
比如：电价方案筛选那种任务能拿到 fact sheet；电商比价能导出清单；竞品文章监控能输出时间戳与抓取源。
可操作的验收清单：
- 输出必须包含来源页面标题/时间
- 关键字段必须结构化（表格/JSON）
- 允许失败，但必须给出失败步骤与截图/日志
2）避免让代理做“长时守候”与“强实时”任务
把“监控一小时”改成“读取过去一小时的列表页”，这是 Ars 测试里成功的关键。
对应到内容运营：
- 把“盯直播”改成“基于节目单/回放切片”
- 把“实时舆情”改成“定时抓取 + 阈值告警”
3）把“确认”设计成产品能力，而不是把人拖进无尽对话
Auto Browse 在加入愿望单时每次都要确认，安全上合理，但体验很差。
企业落地时可以用更工程化的方式：
- 设置预算/权限边界（比如“允许每天自动处理 20 条”）
- 对高风险动作使用批量确认（一次确认多条）
- 对关键动作做双轨：先草稿、再提交
这也是汽车行业给内容行业的一个反向启示：能自动执行的前提，是责任与权限先被产品化。
未来 12 个月我们该看什么：AI代理会在哪些点真正变“可用”？
我更看重三类指标，而不是模型参数：
- 跨站点稳定性：UI变化后的鲁棒性是否提升（按钮语义识别、DOM理解）
- 可审计性：是否提供可导出的操作日志、证据链与回滚机制
- 长时任务能力：是否支持“低成本守候”（事件触发、定时器、后台队列）
如果这些指标不提升，AI代理就会一直停留在“能看、能演示、但需要盯着”的阶段。
对比 Tesla 与中国车企的路线差异，你会发现一个更本质的结论：
真正的AI护城河不是“会生成”，而是“会执行、可复盘、能持续迭代”。
内容行业下一轮竞争也会越来越像这样：不是谁写得更快，而是谁能把选题、抓取、剪辑、分发、复盘做成一条可自动化的系统。
如果你正在规划内容团队的AI代理落地（选型、流程改造、权限与审计设计），更有效的起点不是“先接入一个代理看看”，而是先回答一句话：哪些动作必须自动、哪些必须可控、哪些必须可追责？
你希望 AI代理先替你接管哪一段内容工作流——选题监控、素材整理、标题A/B、还是投放复盘？