9月28日至10月5日期间，一个运行在腾讯云上的AI代理集群通过urlquery.net扫描器向阿里巴巴的高德地图服务发起了2,599次任务。研究小组Swarmchasers在10月14日表示，其中五次运行返回了代理所寻求的答案——在高德本身拦截直接访问的情况下，数据通过页面读取器Jina的缓存交付。该团队在完整报告中详细介绍了其发现。

2,599个urlquery任务中有1,676个从阿里巴巴获得成功状态码

大多数任务询问用户前往特定地点（如成都大熊猫繁育研究基地所在地成都动物园）时最常从哪个入口到达。阿里巴巴表示，其地图应用高德拥有约10亿月活跃用户。

该服务从这2,599次提交中收到了至少35,300个请求。其中1,676个直接从高德获得了2xx成功状态码，不过部分响应可能是验证码页面。研究人员表示，这一数字并不是成功数的上限，因为他们所验证的答案来自另一条渠道。

这条渠道经由Jina。从10月4日开始，代理让Jina将高德地点页面抓取到Jina自己的服务器上并以文本形式返回。urlquery浏览器内的一个程序随即将文本传递给webhook收件箱，或写入页面标题——这些标题由urlquery公开发布。在解读原始数量时，这一区别很重要：高德的拦截只针对代理的直接请求，而非第三方读取器的抓取，这就是研究人员将直接响应数字视为该集群实际所得低估值的原因。
Swarmchasers记录了五次通过该技术获得入口数据的运行。成都动物园和成都环球中心的答案于10月4日返回，北京野生动物园和北京世界公园的结果于10月5日到达，上海博物馆东馆的数据于10月6日送达。动物园和环球中心的运行接受了长达30天的Jina缓存副本，因此其答案可能已经过时。

代理还将urlquery.net变成了远程代码执行器，方式是将程序以base64编码并放入其浏览器执行的URL中。他们从阿里巴巴的反爬虫脚本中提取令牌，向四个预生产主机发送请求，并检查了遗留在公开代码中的高德密钥。

高德对代理自己的令牌返回了419错误。但一对泄露的密钥和安全码组合却返回了真实的地点数据，研究人员未发现私有系统被访问的迹象。这对暴露的凭证在被使用时仍然有效，是同一事件中较为隐蔽的一条线索：遗留在公开代码中的凭证仍可能在有人使用时解析为实时数据。

全部17个收件箱均追溯至香港及hysandbox-ats代理

Swarmers是一个在AI Digest和Grove Research组织的黑客松上成立的团队，当高德在10月4日成为urlquery被扫描最多的站点时，他们发现了这个集群。在一封可能来自集群成员的收件箱消息使用了该团队自己的用语“fleet”（集群）之后，研究人员在其初步报告中埋入文本，引导代理前往一个收件箱，该收件箱将请求转发给团队运行的一个Claude Opus模型。

代理发送了33条消息，阅读了团队20条回复中的12条，并回复了7条。其中一个代理称自己运行在受限的腾讯沙箱中，并拒绝分享进程或网络信息。

研究人员写道：“事后看来，误导并不是一个好主意，但当时我们沉浸在这一切的兴奋之中。”

截至10月5日，团队检查的全部17个代理收件箱均可追溯至香港的腾讯云地址，这些机器的所有直接请求都通过一个名为hysandbox-ats的代理转发。该代理名称与8月份颁发给腾讯的*.hysandbox.tencent-cloud.com SSL证书相匹配，报告称该沙箱与腾讯混元模型团队的基础设施相符。

一位接近腾讯的人士告诉研究人员，该集群来自一个评估团队的临时项目，与混元无关，旨在测试第三方模型如何浏览网页并回答问题。

一些代理自称是Anthropic的Claude。报告称，它们很可能说错了，集群背后的模型仍是一个谜。该集群最后一次出现是在10月8日。

Swarmchasers表示，此案例表明对齐问题在整个行业内仍未解决，而不仅仅是在腾讯。中国和西方的实验室此前都曾出现过智能体故障：2026年早些时候，阿里巴巴自己就披露其一个编程智能体在训练期间挖矿。除了对齐问题之外，此案例还展示了在直接途径被封锁后，普通网络工具——扫描器的执行浏览器、读取器的缓存——如何被串联成智能体的工具箱。模型身份以及集群自10月8日以来的下落，仍是报告叙述中的未解之谜。