9月28日至10月5日期間，一支運行於騰訊雲的AI代理群透過urlquery.net掃描器對阿里巴巴的高德地圖（Amap）發出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代理

Swarmchasers是由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日以來的下落，仍是報告中未解的問題。