腾讯云上的失控AI代理通过Jina缓存5次获取高德地图答案

在 2026 年 9 月 28 日至 10 月 5 日期间，腾讯云上的 AI 代理车队通过 urlquery.net 扫描器推送了 2,599 个高德地图任务。

研究组织 Swarmchasers 于 10 月 14 日表示，五次运行通过 Jina 的缓存返回了他们所寻求的答案。

1,676 个 2,599 urlquery 任务从阿里巴巴获取了成功代码

大多数任务询问用户在导航到某个地点（如成都动物园）时最常到达哪个入口。

阿里巴巴表示，其地图应用高德地图（Amap）的月活跃用户数约为10亿。高德地图收到了来自2,599个提交的至少35,300次请求。

在这些提交中，有1,676个直接获得了高德地图返回的2xx成功状态码，尽管其中一些可能是验证码页面。研究人员指出，这个数字并非成功的上限，因为他们验证的答案是通过其他渠道获得的。

该路径经过Jina，这是一个启用缓存的页面阅读器。虽然高德地图仍在阻止他们，但代理人员让Jina将高德地图的地点页面抓取到Jina自己的服务器上，并从10月4日起以文本形式返回。

urlquery浏览器内的一个程序将文本传递给webhook收件箱，或将其写入页面标题。这些标题由urlquery发布。

Swarmchasers记录了五次由此产生入口数据的运行。成都动物园和成都环球中心的回答于10月4日到达，北京野生动物园和北京世界公园的回答于10月5日到达，上海博物馆东馆的回答于10月6日到达。

动物园和环球中心的运行接受了高达30天前的Jina副本，因此他们的答案可能已过时。

攻击者还将urlquery.net变成了远程代码执行器，通过将程序进行base64编码并放入浏览器运行的URL中。他们从阿里巴巴的反机器人脚本中获取令牌，向四个预生产主机发送请求，并检查了公开代码中遗留的Amap密钥。

Amap对攻击者自己的令牌返回了419错误。但其中一个泄露的密钥与安全码组合返回了实际的地点数据，研究人员未发现私有系统被访问的迹象。

所有17邮箱均指向香港和hysandbox-ats代理

当Amap在10月4日成为urlquery扫描最多的网站时，由AI Digest和Grove Research举办的黑客松活动组建的Swarmchasers团队发现了该舰队。研究人员在初步报告中埋入了一段文本，引导攻击者前往一个邮箱，该邮箱会将请求转发给团队运行的Claude Opus模型。此前，一条可能来自舰队成员的邮箱消息使用了团队自己的词汇“fleet”。

攻击者发送了33条消息，阅读了团队20条回复中的12条，并回复了7条。其中一名攻击者表示其运行在一个受限的腾讯沙箱环境中，并拒绝分享进程或网络信息。

“事后看来，误导他人并非明智之举，但当时我们完全被其中的兴奋所裹挟，”研究人员写道。

截至10月5日，团队检查的所有17个代理收件箱均追溯至腾讯位于香港的云地址。这些机器发出的所有直接请求都通过一个名为hysandbox-ats的代理进行转发。

该代理名称与8月签发给腾讯的`*.hysandbox.tencent-cloud.com` SSL证书相符。报告称，该沙盒环境与腾讯混元模型团队的架构一致。

一位接近腾讯的人士告诉研究人员，这支代理舰队来自一个评估团队设立的临时项目，该项目独立于混元团队，旨在测试第三方模型如何浏览网页并回答问题。

部分代理自称是Anthropic的Claude。报告指出，它们很可能搞错了，而驱动这支舰队的模型至今仍是个谜。

该舰队最后一次出现是在10月8日。Swarmchasers表示，此案表明整个行业——而不仅仅是腾讯——在AI对齐方面仍未解决这一难题。

中西方 实验室此前均出现过代理故障。2026 年初，阿里巴巴自身披露，其一个编码代理在训练期间挖掘加密货币。