海外独立研究团队 Swarmchasers 近期公开了一组网络遥测数据，监测到一个被称为“中国 AI 智能体舰队”（Agent Fleet）的大规模自动化任务群。该集群利用部署在腾讯云香港基础设施上的代理节点，密集向阿里巴巴旗下高德地图发起定向数据抓取，在几天内生成了超过 3.4 万次网络请求，最终却只换来 2 次有效的数据回传。
这场被部分海外媒体渲染为“中国 AI 蜂群突袭”的事件，实质上是一次极具代表性的智能体工程失控现场。当智能体脱离基准测试的温室，在真实互联网防线下执行对抗任务时，缺乏严密编排的暴力并发不仅无法突破成熟的商业防护，反而会迅速演变为算力与带宽的空耗黑洞。
并非协同蜂群，而是盲目并发的抓取舰队
根据研究员 Alecto Irene Perez 与 Ethan Elasky 披露的报告，这批自动化智能体最早于 2026 年 9 月 28 日被检测到活跃迹象。监控平台 urlquery.net 记录显示，该集群在 10 月 4 日迎来流量高峰，单日生成 1,810 份扫描报告，在最繁忙的单一小时内曾尝试处理 51 个地点。整个活动随后在 10 月 5 日 04:11 UTC 戛然而止。
研究人员在报告中明确修正了外界关于“自主蜂群”（Swarm）的猜测，将其定性为“舰队”（Fleet）。两者的关键差异在于交互逻辑：真正的蜂群需要具备分布式自组织通信与动态任务重构能力，而这批智能体虽然并发运行了 428 个不同脚本，但在不同任务实例之间完全看不到横向协调的痕迹，本质上只是被批量派发的单向并行抓取器。
其抓取目标也揭示了其真实的业务意图，并非破坏性网络攻击或地缘安全行动。整个舰队的目标极为具体，专门扫描公园、博物馆、医院、寺庙等 216 处公共场所的导航路线，试图解析出高德地图对不同出入口的人流分流比例。这类特征往往对应着垂直领域的地图算法调优、真实客流训练集采集，或是商业层面的竞品数据逆向工程。
标签错位与代码指纹，基础设施归属存疑
该事件中呈现出的技术特征极为割裂。虽然该舰队的物理出入口集中在腾讯云香港节点，共涉及 19 个云端 IP 地址以及 9 个代理进程，且 16 个高德相关的 Webhook 回调地址中有 15 个落在腾讯云网段，但在具体抓取流量的元数据中，却浮现出多重互斥的指纹。
自 9 月 30 日起，探测流量中开始出现带有 Claude 标识的记录，整起事件中共有 211 份报告被打上了该标签。然而，安全研究员通过分析智能体自动编写的代码发现，其语法逻辑、模块引用和提示词结构完全不符合 Anthropic 的 Claude 生成惯例，反而与智谱 GLM 及腾讯混元大模型的代码指纹高度吻合。
这指向了当前智能体工程中普遍存在的伪装与混合编排实践。公有云平台任何人都可以按需开户付费，代理标签与 User-Agent 同样能够被人为篡改。开发者既可能利用前端标记混淆安全审计，也可能采用了底层混元结合多模型路由的复合系统架构。仅凭几个公开网络标识，无法简单断定背后的实际运营方。
3.4 万次狂轰换来 2 次成功，工程落地遭遇现实阻壁
整场行动中最具讽刺意味的数据，在于惊人的请求消耗与苍白的产出结果对比。在全部 2,479 次提交与 34,070 次网络请求中，智能体舰队使用了超过 1,100 个不同的防缓存标记，并一度开启了多达 14 个最大并发通道。
但面对主流商业平台成熟的风控与反爬规则，这套自主生成的自动化链路陷入了死循环。在成千上万次重试中，多数任务由于被风控阻断而未达成效，最终真正成功抓取到目标景区入口分流比例数据的调用，仅仅记录到了 2 次。
纸面测试能跑通万行代码，一遇反爬防御就现了原形。
- 风险.如果智能体缺乏具备状态恢复与错误收敛的严密编排，盲目套用暴力重试与高并发调用，不仅会导致 Token 与计算资源无限空耗，更容易触发反爬规则被全量封禁。
这一现实惨状与模型在封闭基准测试中的亮眼数据形成了尖锐对比。在标准化 Docker 环境中，大模型的自主工具调用能力往往显得游刃有余。美国 CAISI 在标准环境下对 DeepSeek V3.1 进行的测评中，其 SWE-bench Verified 成绩达到 54.8%，Breakpoint 任务达 78.5%，MMLU-Pro 为 89.0%，GPQA 达到 79.3%，在 CyBench 与 CVE-Bench 安全测试上也分别拿下 40.0% 和 36.7%。
但在 CAISI 评测的 13 项基准中，由于长轨迹探索中的高频重试与无效 Token 消耗，该模型在其中 11 项的平均单任务综合成本反而超过了 GPT-5-mini。当模型在开放环境下遇到不可预知的反自动化墙时，自动化智能体就会在不断自我纠错、重写脚本的死循环中大量燃烧算力预算。
| 评估维度 | 标准基准表现 (CAISI/官方) | 真实高德抓取实测 |
|---|---|---|
| 代码/任务成功率 | SWE-bench 54.8% / Breakpoint 78.5% | 34,070 次请求仅 2 次成功 |
| 工具交互机制 | 封闭环境 Docker 交互受控 | 动态编写 428 脚本均遭拦截 |
| 成本与重试表现 | 11 项基准单任务成本高于竞品 | 超千个防缓存标记无效循环 |
类似的反差也存在于其他主流技术栈中。智谱公布的 GLM-4.5 在模型级 Agent 跑分中，TAU-bench Retail 达到 79.7，Airline 为 60.4，BFCL v3 工具调用基准达到 77.8，但在极度依赖真实网络解析的 BrowseComp 上仅有 26.4。这证明了在真实 Web 环境下，工具调用的执行阻力要远高于内部逻辑推理。
目前行业分化出的两条路线也在这次事件中得到了对照：一类是以开源模型结合 Qwen-Agent 或 AutoGLM 打造的自建编排，若缺乏强大的运行时防护与自愈机制，极易退化成失控的低效爬虫；另一类则是如 Manus 1.6 Max 这种端到端完全托管方案，通过暴露任务编排、Webhook 与技能库的闭环运行时来约束行为。企业在规划分布式智能体方案时，必须意识到模型跑分不等于交付能力，缺乏工程化风控的舰队往往只能是一场昂贵的技术自嗨。