datainfra前沿动态 · Vol.27

Apache Paimon 1.4.2正式发布定位AI多模态数据湖；阿里云EMR Serverless Spark原生支持混合标量-向量检索+AI Function多模态让SQL成为AI代理的统一接口；阿里通义实验室PawBench用4,050次Agent Run评估'模型×智能体脚手架'的真实性能差距

第二十七期聚焦DataInfra四条动态：6月29日Apache Paimon 1.4.2正式发布——1,108个commits历史最长最大版本，重新定位为'AI多模态数据湖'（Unified Lake Format三大支柱：大规模数据湖/实时数据湖/多模态数据湖），推出BLOB类型（图片/视频/音频/模型权重统一存储）+Lumina向量索引（基于DiskANN算法替代Lucene/FAISS）+Data Evolution行级部分列更新+PyPaimon原生Python SDK（PyTorch/Ray集成）+VECTOR原生类型+Variant Shredding半结构化列式分解，阿里巴巴内部已部署EB级多模态数据存储；7月6日阿里云EMR Serverless Spark原生支持混合标量-向量检索——基于DLF Paimon Global Index，Lumina向量索引与B-tree标量索引在同一张Paimon表上协同，单条SQL完成vector_search+WHERE过滤，零数据搬迁+秒级十亿行混合检索+3倍Spark性能；7月6日阿里云EMR Serverless Spark发布AI Function多模态最佳实践——ai_query支持DLF Blob/path+URI/read_files三种图像输入模式+ai_embedding_multimodal多模态向量化，Qwen3.6-plus+Qwen3.5-plus+tongyi-embedding-vision-plus内置+支持PAI-EAS/DeepSeek/KIMI/GLM/MiniMax外部模型，5张自动驾驶高分辨率图像秒级分析（环岛/警车/皮卡/吊车多标签识别）；7月6日阿里通义实验室Tongyi Lab发布PawBench基准测试——用4,050次Agent Run（9模型×3脚手架×150任务）系统评估'模型×智能体脚手架'联合性能，核心发现QwenPaw 75.4 vs OpenClaw 74.8 vs Hermes 70.0（5.5分差距），脚手架差距可比模型升级，Agent Performance = f(Model, Harness)——AI代理时代的胜负不只由模型决定。四条动态共同指向数据基础设施的'AI原生重构'主线：Paimon 1.4.2在存储层原生支持多模态（BLOB/VECTOR/Lumina）+阿里云EMR Serverless Spark在SQL层统一向量检索与LLM调用+多模态AI Function让Spark成为AI代理的统一接口+PawBench在评测层量化脚手架对智能体性能的影响——数据基础设施正从'结构化数据的仓库'演化为'多模态AI数据的操作系统'。

DataInfra Apache Paimon Paimon 1.4.2 AI Multimodal Data Lake BLOB Type Lumina Vector Index DiskANN Data Evolution PyPaimon VECTOR Type Variant Shredding Multimodal Lakehouse Alibaba Cloud EMR Serverless Spark Hybrid Scalar-Vector Retrieval DLF Global Index vector_search UDF Paimon Table Hybrid Retrieval Zero Data Movement AI Function ai_query ai_embedding_multimodal Qwen3.6-plus Multimodal SQL Autonomous Driving Data Qwen-VL tongyi-embedding-vision-plus PAI-EAS Tongyi Lab PawBench Agent Benchmark Agent Harness QwenPaw OpenClaw Hermes Model x Harness Agent Performance Evaluation OpenJudge AgentScope 数据基础设施 DataInfra前沿动态 Vol.27

第二十七期追踪到DataInfra领域四条重要动态：6月29日Apache Paimon 1.4.2正式发布——1,108个commits历史最长最大版本，重新定位为’AI多模态数据湖’（Unified Lake Format三大支柱：大规模数据湖/实时数据湖/多模态数据湖），推出BLOB类型（图片/视频/音频/模型权重统一存储）+Lumina向量索引（基于DiskANN算法替代Lucene/FAISS）+Data Evolution行级部分列更新+PyPaimon原生Python SDK（PyTorch/Ray集成）+VECTOR原生类型+Variant Shredding半结构化列式分解，阿里巴巴内部已部署EB级多模态数据存储；7月6日阿里云EMR Serverless Spark原生支持混合标量-向量检索——基于DLF Paimon Global Index，Lumina向量索引与B-tree标量索引在同一张Paimon表上协同，单条SQL完成vector_search+WHERE过滤，零数据搬迁+秒级十亿行混合检索+3倍Spark性能；7月6日阿里云EMR Serverless Spark发布AI Function多模态最佳实践——ai_query支持DLF Blob/path+URI/read_files三种图像输入模式+ai_embedding_multimodal多模态向量化，Qwen3.6-plus+Qwen3.5-plus+tongyi-embedding-vision-plus内置+支持PAI-EAS/DeepSeek/KIMI/GLM/MiniMax外部模型，5张自动驾驶高分辨率图像秒级分析（环岛/警车/皮卡/吊车多标签识别）；7月6日阿里通义实验室Tongyi Lab发布PawBench基准测试——用4,050次Agent Run（9模型×3脚手架×150任务）系统评估’模型×智能体脚手架’联合性能，核心发现QwenPaw 75.4 vs OpenClaw 74.8 vs Hermes 70.0（5.5分差距），脚手架差距可比模型升级，Agent Performance = f(Model, Harness)——AI代理时代的胜负不只由模型决定。四条动态共同指向数据基础设施的’AI原生重构’主线：Paimon 1.4.2在存储层原生支持多模态（BLOB/VECTOR/Lumina）+阿里云EMR Serverless Spark在SQL层统一向量检索与LLM调用+多模态AI Function让Spark成为AI代理的统一接口+PawBench在评测层量化脚手架对智能体性能的影响——数据基础设施正从’结构化数据的仓库’演化为’多模态AI数据的操作系统’。

Apache Paimon 1.4.2正式发布：1,108个commits历史最长最大版本，定位从”实时数据湖”升级为”AI多模态数据湖”

事件概述

6月29日，Apache软件基金会宣布Apache Paimon 1.4.2和PyPaimon 1.4.2正式发布——由Release Manager Hongbo Xiao主导，Jingsong Li担任格式编辑，1,108个commits（相比1.3版本）使其成为Paimon历史上最长且最大的版本发布（[ANNOUNCE]邮件，2026-06-29）。Maven Central显示1.4.2于2026-06-04发布到仓库——这是Paimon战略定位的根本性转变：从”实时数据湖”升级为”AI多模态数据湖（AI Multimodal Data Lake）“，官方网站（docs/content/_index.md）被重新定义为”统一湖格式（Unified Lake Format）“的三大支柱并列架构——大规模数据湖（Time Travel/File Index/Schema Evolution/Incremental Clustering）+实时数据湖（LSM结构/Merge Engine/Deletion Vector/CDC Ingestion）+多模态数据湖（Data Evolution/Blob Table/Vector Index DiskANN/PyPaimon）——第三支柱多模态数据湖是1.4全新引入。官方原文：“Paimon is a multimodal lakehouse for AI. Keep multimodal data, metadata, and embeddings in the same table and query them via vector search, full-text search, or SQL.” 阿里巴巴内部已部署多EB规模的多模态数据存储，为推理和多模态模型训练提供坚实基础。Paimon 1.4.2的发布意义不是”又一个lake format版本”，而是”数据湖从结构化数据仓库演化为AI数据操作系统”的范式跃迁——Paimon从此直接对位LanceDB（向量数据库）+Iceberg（开放表格式）+Milvus（向量检索）三者合一，是Apache社区对”AI时代数据基础设施应该长什么样”的开源答案。

技术解析

  • BLOB类型——多模态大对象存储：1.4.0起Paimon引入全新BLOB数据类型（约40个commits），用于存储图像、视频、音频、文档、模型权重等非结构化数据。架构设计——Blob数据存储在独立的.blob文件中，元数据保留在Parquet列式文件中，实现存算分离；BlobDescriptor使用带版本号的二进制格式（魔数0x424C4F4244455343），记录(version, uri, offset, length)；支持三种存储模式（本地/OSS/HDFS等）。关键配置：blob-field、blob-descriptor-field、blob-as-descriptor、blob-external-storage-path。写入API（Java）：Blob.fromLocal()、Blob.fromHttp()、Blob.fromInputStream()、Blob.fromFile()、Blob.fromDescriptor()。SQL支持：Flink SQL和Spark SQL均支持建表、写入、MERGE INTO更新。生产应用：阿里巴巴内部已基于BLOB类型部署多EB级多模态数据存储。BLOB类型让Paimon从”表格数据湖”演化为”多模态数据湖”——这是Paimon与Delta Lake/Iceberg等仅支持结构化数据的lake format的根本性差异。这与Vol.25报道的LanceDB v0.31.0/v0.34.0稳定版（Blob v2大对象存储）和Vol.22报道的Databricks Genie Ontology（活图谱）是同一方向——“多模态数据原生存储”是AI时代数据基础设施的第一性需求。

  • Lumina向量索引——基于DiskANN的近似最近邻：1.4.0起Paimon用Lumina向量索引替代了原有的Lucene和FAISS方案（约30+个commits）。Lumina基于DiskANN算法——DiskANN是Microsoft Research提出的”磁盘感知近似最近邻”算法，专为超大规模（十亿级）向量设计，支持在内存+SSD混合存储中保持高性能（远优于纯内存FAISS）。配套基础设施——BTree全局索引提供高性能标量查找，支持行范围（row-range）；Pre-filter机制在向量搜索前先用标量索引过滤，显著提升检索效率。查询接口——Java API：Table.newVectorSearchBuilder()；Spark SQL：vector_search表值函数；Flink SQL：sys.vector_search存储过程。Lumina让Paimon在原生表格式层支持向量检索——这是Paimon与LanceDB（纯向量数据库）、Milvus（纯向量检索系统）的根本性差异。Paimon不是”再加一个向量数据库”，而是”让lake format原生支持向量”——向量和结构化数据在同一张表中统一管理。这与Vol.23报道的Trino 482 “Summer of Grammar”（SQL方言标准化）和Vol.7报道的Databricks Instructed-Retriever-1（并行测试时计算）是同一方向——“让AI能力原生进入数据基础设施的每一层”是AI时代数据栈的核心趋势。

  • Data Evolution——行级部分列更新：1.4.0起Paimon通过row-tracking.enabled+data-evolution.enabled启用Data Evolution机制——这是Blob和Vector存储的底层基础。核心能力：（1）基于_ROW_ID的部分列更新——只写入变更列，无需重写整个文件；（2）持续添加新特征列（如embedding列）无需复制现有数据——例如，应用演化时新增”semantic_description”列（来自LLM标注），Data Evolution只写新列，原列保持不变；（3）Flink优化了Data Evolution模式下的MERGE INTO操作——流式更新性能大幅提升。Data Evolution解决了”多模态数据schema演化的成本问题”——传统lake format新增一列需要全表重写（成本极高），Data Evolution让新列增量写入（成本与新列数据量线性相关）。这与Vol.22报道的Delta Lake 4.3（Delta REST Catalog统一API+UniForm原子+增量转换+Row Tracking读取+模式演变生存上游变更）是同一思路——“模式演化的成本”是AI时代数据基础设施的关键能力。

  • PyPaimon——AI生态原生Python SDK：1.4.0起PyPaimon从实验项目升级为完整Python SDK——纯Python实现，无JDK依赖。核心能力：（1）Ray DataSource分布式读写——Ray可直接消费Paimon表作为Dataset；（2）PyTorch Dataset读取——PyTorch DataLoader可直接迭代Paimon表进行训练；（3）流式读取（AsyncStreamingTableScan）；（4）Python CLI——paimon命令行工具支持表管理、快照、分支、Tag操作；（5）JSON格式输出。生产应用——阿里巴巴内部已基于PyPaimon+Ray+Daft部署大规模推理，部分数据使用PyTorch直接读取Paimon数据进行训练。PyPaimon让Paimon成为AI生态的”第一公民”——传统lake format（Delta Lake/Iceberg）的Python集成是”Java+Py4J”模式（性能差+部署复杂），PyPaimon是纯Python（性能好+部署简单）。这与Vol.7报道的Daft（CPU和GPU同管线+Python DataFrame API+内置UDF runtime）和Vol.10报道的阿里云AgentTeams（基于Matrix协议异构智能体统一治理）是同一方向——“Python优先”是AI时代数据栈的隐性标准。

  • VECTOR类型+Variant Shredding+Chain Table：1.4.0还引入三大新特性：（1）VECTOR类型——VECTOR<t, n>一公民数据类型，支持7种元素类型（BOOLEAN/TINYINT/SMALLINT/INT/BIGINT/FLOAT/DOUBLE）、固定维度（最高2,147,483,647维），可独立存储为Lance格式（.vector.lance文件）——这与Vol.25报道的LanceDB v0.31.0/v0.34.0稳定版（Blob v2大对象存储）形成**“表格式层存储向量”+“向量数据库层存储向量”两条并行路径；（2）Variant Shredding——1.1引入的Variant类型（半结构化），1.4补全完整Shredding（列式分解）流水线**：自动Schema推断+Shredding Writer（将推断的Schema应用于实际写入，把半结构化数据分解为Parquet原生列）+Clipped Read（读取时只提取需要的列）+Parquet Variant逻辑类型注解——Variant Shredding让”半结构化数据也能像结构化数据一样列式存储+列裁剪”；（3）Chain Table——主键表新模式，通过快照+delta分支实现增量计算（约15个commit），适合流式聚合+物化视图+增量ML特征工程场景。

  • 生态集成与安全升级：1.4.0还升级了大量生态集成——Flink 2.2支持（移除Flink 1.15）、Spark 4.0.2支持（Scala 2.13+V2 Write DELETE/UPDATE/MERGE INTO均支持Append表）、REST Catalog（Consumers API/Tag API/列脱敏规则）、Iceberg兼容性增强（毫秒时间戳兼容模式+UUID+元数据解析错误修复）、PyPaimon Ray DataSource分布式读写、PyPaimon PyTorch Dataset读取。安全升级——修复6个CVE（lz4-java 1.10.4/snappy-java 1.1.10.8/aircompressor 2.0.3/httpclient5 >5.4.3 CVE-2025-27820/commons-lang3 3.18.0 CVE-2025-48924/log4j-core 2.25.3）。生产就绪——Apache软件基金会发布的稳定版本，已在阿里巴巴EB级生产环境验证。

行业影响

Apache Paimon 1.4.2的发布意义不是”一个lake format升级”，而是”AI时代数据基础设施的标准答案”的开源版本——Paimon从此直接对位Delta Lake+Iceberg（结构化）+LanceDB（向量）+Milvus（向量检索）+Snowflake（云数仓）多者合一的统一形态。

此前数据基础设施的格局是”多产品组合”——结构化数据用Delta Lake/Iceberg，向量数据用LanceDB/Milvus，文档/图片用S3/OSS，元数据用Glue/Hive Metastore，不同数据需要在不同系统之间搬运。Paimon 1.4.2把结构化+半结构化+非结构化+向量+元数据统一在一张表中，通过SQL/向量搜索/全文搜索统一查询——这是数据湖从”结构化数据专用”演化为”AI多模态数据原生”的范式跃迁。

将本期与Vol.23报道的Apache Flink 2.3.0（15项FLIP/FLIP-555 Native S3/FLIP-564 Changelog SQL算子/FLIP-550/557物化表DDL/FLIP-339自适应分区/Flink Agents 0.3.0）对比，Flink 2.3.0在流处理引擎层推进流批一体+物化表+Changelog SQL，Paimon 1.4.2在存储格式层推进多模态统一+BLOB/VECTOR原生+Data Evolution。两者是”流处理+湖格式”双轨并进——Flink是Paimon的官方推荐流处理引擎（Paimon 1.4.0专门优化Flink 2.2集成），Paimon是Flink的官方推荐湖格式（Flink 2.3.0推荐Paimon作为流式湖格式）。当Flink 2.3.0+Paimon 1.4.2组合时，AI时代的”流式多模态数据湖”完整形态落地。

将本期与Vol.25报道的LanceDB v0.31.0/v0.34.0稳定版（Blob v2大对象存储+Polars集成+OAuth+单调读）对比，LanceDB是”向量数据库原生”（专门为AI多模态设计，但缺乏结构化数据能力），Paimon 1.4.2是”lake format原生支持多模态”（保持lake format的结构化数据能力，新增多模态能力）。两条路径：（1）LanceDB路径——为AI多模态重建数据栈，完全替换传统lake format；（2）Paimon路径——让传统lake format演化为AI多模态，保留所有结构化数据能力。两条路径都会成功，目标用户不同——LanceDB面向纯AI多模态场景（如RAG、生成式AI推荐），Paimon面向结构化+多模态混合场景（如传统数仓+AI增强、湖仓一体+AI应用）。当LanceDB+Milvus+Iceberg+Delta Lake+Paimon五个产品同时存在时，企业可以根据场景选择——但Paimon是唯一一个”什么都做”的lake format。

将本期与Vol.22报道的Delta Lake 4.3（Delta REST Catalog统一API+UniForm原子+增量转换+IcebergCompatV3实验性支持删除向量与UniForm共存+流式CDF支持CDC流式处理+Row Tracking读取+模式演变生存上游变更+Delta Kernel成为Spark/DuckDB/Flink共享表统一内核）对比，Delta Lake 4.3在”开放表格式互操作”（Delta REST Catalog+UniForm）方向演进，Paimon 1.4.2在”AI多模态原生”（BLOB/VECTOR/Lumina）方向演进。两者是”lake format演进的两条路径”——Delta Lake走”互操作”路径（一个Delta表能被任何引擎读取），Paimon走”AI多模态”路径（一个Paimon表能存任何AI数据）。两条路径不互斥——未来可能出现”Delta Lake+Paimon双格式”的企业（结构化数据用Delta Lake+AI多模态数据用Paimon）或”Paimon统一一切”的企业。

将本期与Vol.14报道的Apache Flink Forward Asia 2026（王峰keynote宣布Flink 3.0/Paimon 2.0/Fluss 1.0愿景——Agentic Streaming for AI + 多模态处理 + 三层演进：API/Operator/Compute + FLIP-591/592/593）对比，王峰6/26宣布的Paimon 2.0愿景”完整的AI数据湖”在Paimon 1.4.2中已经迈出第一步——BLOB类型+Vector Index（DiskANN）+Data Evolution+PyPaimon+VECTOR+Variant Shredding是Paimon 2.0的关键前置特性。当Paimon 2.0正式发布时，AI数据湖的”完整形态”将落地——届时Paimon可能直接对位”Apache AI数据湖”的定位。

相关链接

阿里云EMR Serverless Spark原生支持混合标量-向量检索：DLF Paimon Global Index让向量与标量在同一张表协同

事件概述

7月6日，阿里云EMR Serverless Spark团队发布’Hybrid Scalar-Vector Retrieval with Alibaba Cloud EMR Serverless Spark’技术博客——介绍EMR Serverless Spark通过DLF Global Index原生支持混合标量-向量检索的能力。核心创新——让语义搜索与结构化过滤不再需要分离系统（先向量检索Top-K、再业务库过滤），而是在单条SQL语句中完成多维查询，结合vector_search UDF与标准WHERE过滤条件，联合使用Lumina向量索引和B-tree标量索引实现高效执行。底层技术——EMR Serverless Spark利用数据湖中DLF Paimon表的Global Index能力（基于Apache Paimon 1.4+），在Spark SQL查询执行框架内统一向量索引和B-tree索引，两种索引可在同一张Paimon表上创建，Spark执行查询时自动协调两个索引路径，用户无需管理底层调度。关键性能——十亿行数据集混合检索通常在秒级完成，与全表扫描相比性能提升达数量级，与开源Spark相比内置Celeborn和Fusion引擎提供最高3倍性能提升。支持的距离度量——Cosine相似度和Euclidean距离（通过lumina.index.metric-type指定）。典型业务场景——智能驾驶（视觉嵌入匹配相似驾驶场景 + 天气/道路类型/车速/传感器类型过滤）、具身智能（任务描述语义匹配 + 机器人型号/末端执行器/环境过滤）、电商多模态搜索（商品图片视觉相似度 + 价格/品牌/库存/上架时间过滤）、内容安全（文本/图像嵌入语义相似度 + 内容类型/违规级别/处理状态/时间范围过滤）、医学影像（医学图像嵌入视觉相似度 + 检查部位/年龄段/诊断类型过滤）。EMR Serverless Spark的混合检索为数据湖带来三大关键收益——简化架构（无需额外部署向量数据库）+SQL原生体验（vector_search+AI Function+标准WHERE子句，数据工程师无需学习新接口）+原生批处理（十亿行级别嵌入生成/相似度计算/场景去重一站式完成）。

技术解析

  • DLF Paimon Global Index——Lumina向量索引与B-tree标量索引在同一表协同：1.4.0起Apache Paimon引入Global Index（全局索引）能力（约30+个commits）——这是阿里云EMR Serverless Spark混合检索的底层引擎。两种索引可叠加在同一张Paimon表：（1）Lumina向量索引——基于DiskANN算法的近似最近邻（ANN）索引，支持十亿级向量的亚秒级检索；（2）B-tree全局索引——高性能标量查找，支持row-range（行范围扫描）。索引构建方式——通过表属性声明即可启用向量索引，数据写入后自动生效：'morax.lumina-index.enabled' = 'true'、'global-index.lumina.index-column' = 'embedding'、'lumina.index.dimension' = '1152'。索引调度——声明morax.*参数后，DLF自动调度索引构建；也支持手动触发（数据摄入后立即触发，或补充未声明参数的场景）。索引存储——索引由DLF自动构建和更新，存储在OSS；Spark计算资源按需弹性伸缩；无任务时无计算成本；无需为索引集群预留固定资源。与传统架构对比——传统架构需要”先向量检索Top-K、再业务库过滤”（两次查询+数据搬运+可能不足K个结果）；DLF Global Index让Spark自动协调两个索引路径（一次查询+零数据搬迁+索引协同保证结果质量）。这与Vol.23报道的Trino 482 “Summer of Grammar”（SQL标准对齐）和Vol.7报道的Databricks AI Search（Vector Search更名+全文搜索BM25+混合搜索向量+全文+重排序+存储优化端点10-20倍索引加速超10亿向量）是同一方向——“SQL原生支持向量检索”是AI时代数据栈的核心能力。

  • vector_search UDF——Spark SQL内的向量检索表函数：阿里云EMR Serverless Spark引入**vector_search表函数**——让向量检索成为Spark SQL的一等公民。基本用法——SELECT * FROM vector_search('table_name', 'embedding_col', query_vector, K)，返回与查询向量最相似的Top-K记录。混合检索用法——SELECT * FROM vector_search(...) WHERE col1 = val1 AND col2 = val2——Spark同时使用向量索引检索最近邻候选集和B-tree索引过滤标量条件，无需跨系统数据移动。距离度量——lumina.index.metric-type指定（cosine/euclidean）。索引协同保证结果质量——传统”先向量后标量”架构可能不足K个有效结果（向量Top-10中只有3个满足标量条件）；DLF Global Index让两个索引协同，保证返回K个同时满足向量相似+标量条件的结果。端到端实践示例（自动驾驶场景数据准备）——（1）Step 1 数据入湖+AI自动标注与向量化——一条INSERT语句完成读取OSS图像+通过AI函数自动标注和向量化+写入带双索引的Paimon表；（2）Step 2 混合检索召回目标场景——Python代码调用Spark SQL，根据”query image”查询”weather=‘rainy’ AND road_type=‘urban’ AND lighting=‘nighttime‘“的场景；（3）Step 3 批量召回多个Corner Case——Python循环调用混合检索，通过unionByName合并结果，source_query字段记录召回条件，便于训练时加权采样；（4）Step 4 训练集质量分析与去重——SELECT source_query, COUNT(*) AS sample_count ... GROUP BY source_query按场景分析样本分布，JOIN dim_road_info ... HAVING COUNT(*) > 5关联维度表统计城市覆盖。端到端流程让”自动驾驶corner case挖掘”从”手动脚本”演化为”标准SQL+Python循环”。

  • 全SQL表达能力+原生批处理+内置AI函数+存算分离：EMR Serverless Spark的混合检索提供四大能力组合：（1）全SQL表达能力——vector_search返回标准Spark DataFrame，可与其他数仓表JOIN、使用窗口函数、聚合、嵌套子查询——一条SQL即可完成混合检索和下游分析，独立向量检索系统无法提供此能力；（2）原生批处理能力——Spark天然适合大规模离线批处理，从嵌入生成、相似度计算到批量场景去重，全部在数据湖内完成，无需额外计算引擎；（3）内置AI函数——ai_embedding_multimodal（向量生成）、ai_query（标量标签提取）、vector_search（混合检索）三大函数均在Spark SQL内运行，数据工程师无需离开SQL环境；（4）存算分离+托管索引——索引由DLF自动构建和更新，存储在OSS；Spark计算资源按需弹性伸缩；无任务时无计算成本；无需为索引集群预留固定资源。这与Vol.7报道的Databricks AI Search（Vector Search更名+全文搜索+混合搜索+存储优化端点10-20倍索引加速超10亿向量）和Vol.10报道的阿里云AgentTeams（基于Matrix协议异构智能体统一治理）是同一方向——“AI能力原生进入数据基础设施”是AI时代数据栈的核心趋势。

  • 关键性能数据：十亿行秒级+3倍Spark性能：EMR Serverless Spark混合检索的关键性能指标：（1）十亿行数据集——混合检索通常在秒级完成；（2）与全表扫描对比——随着数据量增长，性能提升达数量级；（3）与开源Spark对比——内置Celeborn和Fusion引擎提供最高3倍性能提升；（4）索引构建影响——异步触发，与写入任务解耦，不影响数据写入性能。性能来源——（1）Lumina向量索引基于DiskANN算法，专为十亿级向量设计（远优于Lucene/FAISS的内存限制）；（2）B-tree全局索引支持row-range（行范围扫描），显著提升标量过滤效率；（3）Spark执行引擎内置Celeborn（Shuffle优化）和Fusion引擎（向量化执行）——Vol.22报道的Google Cloud Lightning Engine（Gluten+Velox向量化原生执行C++ SIMD/4.9倍Spark性能加速/2倍性价比）的类似技术路径。

  • 典型业务场景与SQL示例：EMR Serverless Spark混合检索覆盖五大典型场景：（1）智能驾驶——视觉嵌入匹配相似驾驶场景 + 天气/道路类型/车速/传感器类型过滤，数据反馈回路效率提升数倍；（2）具身智能——任务描述语义匹配（如”抓取红色杯子”） + 机器人型号/末端执行器类型/环境过滤，结果语义相关且物理可执行；（3）电商多模态搜索——商品图片视觉相似度 + 价格区间/品牌/库存/上架时间过滤，商品”长得像”且实际可购买；（4）内容安全——文本/图像嵌入语义相似度 + 内容类型/违规级别/处理状态/时间范围过滤，一键查找相似违规内容并按条件过滤；（5）医学影像——医学图像嵌入视觉相似度 + 检查部位/年龄段/诊断类型过滤，结果视觉相似且临床相关。SQL示例——SELECT id, path, weather, road_type FROM vector_search('ai_dataset.scene_vectors', 'embedding', query_vec, 10) WHERE weather = 'heavy_rain' AND road_type = 'urban'——一条SQL同时做向量检索和标量过滤。

行业影响

阿里云EMR Serverless Spark混合标量-向量检索的发布意义不是”又一个向量检索功能”，而是”数据湖从’只能存结构化数据’演化为’原生支持AI多模态数据‘“的范式跃迁——通过DLF Paimon Global Index，Lumina向量索引与B-tree标量索引在同一张Paimon表上协同，让混合检索成为Spark SQL的一等公民。

此前AI应用开发团队的痛点是”向量检索与结构化数据检索必须分离”——开发一个RAG应用需要：（1）向量数据库（LanceDB/Milvus/Pinecone）存向量+文档；（2）关系数据库（PostgreSQL/MySQL）存业务元数据；（3）ETL管道把两个系统的数据双向同步；（4）应用层先调用向量数据库Top-K，再调用关系数据库过滤，两次查询+数据搬运+可能不足K个结果。DLF Paimon Global Index让这一切简化为”一条SQL”——开发团队不再需要维护多套系统，所有数据在Paimon一张表中，所有检索在Spark SQL一条查询中。这是AI应用基础设施的根本性简化。

将本期与Vol.25报道的LanceDB v0.31.0/v0.34.0稳定版（Blob v2大对象存储+Polars集成+OAuth+单调读）对比，LanceDB是”向量数据库原生”（专门为AI多模态设计，但缺乏结构化数据能力），EMR Serverless Spark混合检索是”lake format原生支持向量”（保持lake format的结构化数据能力，原生新增向量检索能力）。两条路径：（1）LanceDB路径——为AI多模态重建数据栈，完全替换传统lake format（适用于纯AI多模态场景）；（2）Paimon+EMR Serverless Spark路径——让传统lake format演化为AI多模态，保留所有结构化数据能力（适用于结构化+多模态混合场景）。两条路径都会成功，目标用户不同——LanceDB面向纯AI多模态场景（如RAG、生成式AI推荐），Paimon+EMR Serverless Spark面向企业级湖仓一体+AI增强场景（如传统数仓+AI应用、湖仓一体+RAG、电商+智能推荐）。

将本期与Vol.7报道的Databricks AI Search（Vector Search更名+全文搜索BM25+混合搜索向量+全文+重排序+存储优化端点10-20倍索引加速超10亿向量）对比，Databricks AI Search在Databricks平台内实现混合检索，EMR Serverless Spark在阿里云平台内实现混合检索——两者是”云厂商对位”的混合检索能力。关键技术差异：（1）Databricks AI Search——Vector Search专用服务+全文搜索+混合搜索+重排序四件套，存储优化端点10-20倍索引加速超10亿向量，与Unity Catalog深度集成；（2）EMR Serverless Spark——基于Apache Paimon 1.4+的Lumina向量索引+B-tree标量索引，与Spark SQL深度集成，全SQL表达。两者是”专有服务vs开源引擎”两种实现路径——Databricks走”专有服务”路径（性能优化+易用性高+成本高），阿里云走”开源引擎”路径（灵活定制+生态丰富+技术开放）。两条路径都会成功，目标用户不同——Databricks面向Databricks生态用户，阿里云EMR Serverless Spark面向开源生态用户。

将本期与Vol.23报道的Apache Paimon 1.4.0（AI Multimodal Data Lake定位+BLOB类型+Lumina向量索引+Data Evolution+PyPaimon）对比，Paimon 1.4.0是”底层引擎”（open table format native support for multimodal），EMR Serverless Spark混合检索是”上层应用”（Apache Paimon 1.4+在阿里云上的第一个重量级应用）。两者的协同——Paimon 1.4.0提供Lumina向量索引和B-tree全局索引的底层能力，EMR Serverless Spark通过DLF Global Index+vector_search UDF暴露给SQL用户。当Apache Paimon 1.4.0+EMR Serverless Spark组合时，AI时代的”开源多模态数据湖+原生SQL混合检索”完整形态落地——企业可以在阿里云上使用完全开源的Apache Paimon 1.4+，避免被专有向量数据库厂商锁定。

相关链接

阿里云EMR Serverless Spark发布AI Function多模态最佳实践：Qwen3.6-plus+tongyi-embedding-vision-plus让SQL成为AI代理的统一接口

事件概述

7月6日，阿里云EMR Serverless Spark团队发布’Alibaba Cloud EMR Serverless Spark AI Function Multimodal & Autonomous Driving Practice’技术博客——介绍EMR Serverless Spark AI Function（ai_query+ai_embedding_multimodal）在多模态AI场景（特别是自动驾驶）的最佳实践。核心创新——AI Function把LLM推理能力以SQL函数形式原生集成到Spark计算引擎，esr-4.7.0及以后版本（Spark 3.5.2）全面扩展多模态输入支持——主要体现在ai_query的多模态使用和新增ai_embedding_multimodal函数。典型用例——自动驾驶数据预处理——一个智能驾驶团队需要快速分析一批前视摄像头采集的原始图像，目标自动识别是否包含以下关键元素：（1）特殊路况：环岛（环岛测试感知算法对非线性道路的理解）；（2）特殊车辆：警车/皮卡/吊车/升降车。传统流程——手动标注团队逐帧标注视频帧，成本高+耗时长+难以处理长尾场景（稀有特殊车辆+复杂道路结构）。EMR Serverless Spark解决方案——用ai_query函数调用Qwen3.6-plus多模态能力，整个流程简化为标准ETL管道——读取OSS文件 → 在SQL中定义prompt → 调用AI Function → 输出结构化结果。结果——5张典型测试图像（oss://baobao-wlcb/camera_front/）秒级完成分析——Image 1输出["Police Car", "Pickup Truck"]、Image 2输出["Roundabout"]、Image 3输出["Crane/Lift Truck"]、Image 4输出["Pickup Truck"]、Image 5输出[]（“None of the Above”）。EMR Serverless Spark AI Function的发布意义不是”又一个LLM SQL函数”，而是”SQL成为AI代理的统一接口”——多模态数据（图像+视频+音频）+LLM推理+结构化输出，全部在Spark SQL内完成，数据工程师无需离开SQL环境。

技术解析

  • ai_query三种多模态使用模式：EMR Serverless Spark AI Function在esr-4.7.0及以后版本（Spark 3.5.2）全面扩展ai_query的多模态支持，提供三种图像输入模式：（1）模式1：从DLF Blob字段读取图像内容——SELECT path, ai_query('Please describe the main content of the image', service_name => 'qwen3.6-plus', data => data) FROM ai_dataset.test_blob——适用于图像二进制数据直接存储在表中的场景（Paimon BLOB类型），通过'blob-field' = 'data'配置启用；（2）模式2：路径列+URI读取——SELECT path, ai_query('Return the license plate number in the image...', service_name => 'qwen3.6-plus', data => path, data_type => 'uri') FROM ccpd_1m_1000——适用于图像存储在OSS/OSS-HDFS/Hadoop兼容文件系统、表只存文件路径的场景，data_type => 'uri'让函数内部按路径读取文件；支持OSS路径+file路径（file路径需要Spark-managed mounting，如file:///mnt/data/images/xxx.jpg）；支持enable_thinking选项（默认false），可让Qwen3.6-plus启用思考模式；（3）模式3：read_files+二进制读取——SELECT path, ai_query('Please describe...', service_name => 'qwen3.6-plus', data => content) FROM read_files('oss://bucket/path/to/images/', suffix => 'jpg,jpeg,png')——无需创建路径表，直接从目录批量读取图像，read_files的suffix参数过滤下推到文件扫描阶段，避免读取目录中其他大文件，显著减少无关文件扫描和下游AI请求量；支持recursive => true递归子目录。性能优化技巧——REPARTITION hint应放在内层子查询（如FROM (SELECT /*+ REPARTITION(10) */ path FROM ccpd_1m_1000) t），而不是外层projection（外层含AI函数时partitions无效）；多张图像应通过unionByName合并而不是分别处理（embedding函数自动合并多行为单LLM请求）。三种模式覆盖了从”图像在表中”到”图像在OSS”到”图像在OSS任意目录”的所有场景，数据工程师无需学习新接口——全部用标准SQL调用。

  • ai_embedding_multimodal多模态向量化：EMR Serverless Spark AI Function新增ai_embedding_multimodal函数——将图像高效转换为向量（embeddings），为后续向量搜索和相似度计算奠定基础。方法1：路径列+URI读取——SELECT path, ai_embedding_multimodal(path, service_name => 'tongyi-embedding-vision-plus', data_type => 'uri') AS embedding FROM image_paths_table——适用于图像路径存储在表中的场景；方法2：直接传入二进制列并写入DLF Paimon——insert overwrite embedding_result SELECT path, ai_embedding_multimodal(content, service_name => 'tongyi-embedding-vision-plus') AS embedding FROM read_files('oss://bucket/path/to/images/', suffix => 'jpg,png')——直接从目录读取图像，生成embedding，写入Paimon embedding_result表。ai_embedding_multimodal生成的图像embedding可直接写入Milvus等向量数据库——构建支持跨模态文-图搜索等多模态检索系统。这与Vol.22报道的Databricks AI Search（Vector Search更名+全文搜索+混合搜索）和本期”混合标量-向量检索”主题的Lumina向量索引是同一方向——“SQL内嵌多模态向量化”是AI时代数据栈的核心能力。

  • 支持主流模型：Qwen系列内置+主流外部模型集成：EMR Serverless Spark AI Function内置Qwen系列模型：qwen3.6-plus、qwen3.5-plus、qwen-plus、text-embedding-v4、tongyi-embedding-vision-plus（直接调用无需额外注册）。外部模型支持——通过统一模型服务注册机制支持主流外部模型，包括PAI-EAS、DeepSeek、KIMI、GLM、Minimax等，覆盖当下最流行的LLM生态。两种集成路径：（1）快速验证路径——连接阿里云Model Studio（开箱即用）——最适合PoC验证/快速业务场景验证——用户无需关心模型部署/自动扩缩/API认证细节，只需从Model Studio控制台获取key，即可在SQL中直接调用云托管大模型——“零代码+零运维”让PoC时间从数周缩短到数小时；（2）企业定制路径——连接PAI-EAS（安全可控）——适合金融/医疗等数据隐私极敏感行业，或有自研微调模型的企业——用户可在PAI-EAS上部署私有模型，通过VPC内网连接到EMR Serverless Spark——数据始终不出VPC安全环境，推理直接在湖仓内完成，满足严格合规要求同时享受Serverless Spark弹性计算的极致性能。两条路径覆盖从PoC到企业级生产的所有场景。

  • 生产级稳定性保证+极致弹性成本：EMR Serverless Spark AI Function的生产级特性：（1）开箱即用+零代码——“下载数据→写Python脚本→部署环境→运行推理”的传统流程减少到”写SQL→提交运行”——数小时流程变分钟；（2）高吞吐批处理+无带宽压力——深度优化大规模数据集，吞吐量显著优于UDF方案——embedding函数支持自动合并多行为单LLM请求，显著降低延迟；（3）生产级稳定性保证——内置限流+自动退避+超时重试+服务异常熔断等机制，用户无需处理异常场景，确保大规模数据处理任务稳定完成；（4）统一模型服务管理——用户无需在代码中管理凭证，可灵活切换不同模型；平台集中配置模型服务端点和key——安全合规；（5）极致弹性成本效率——Serverless架构意味着无任务时不收费——按实际处理的图像数量和计算时间计费——非常适合间歇性数据处理需求。未来扩展方向——视频级行为分析（如”司机是否疲劳？”+“行人是否违章横穿？”），成为自动驾驶数据闭环中不可或缺的智能清洗引擎。

  • 典型业务场景：自动驾驶数据预处理实战：EMR Serverless Spark AI Function在自动驾驶数据预处理场景的完整实战——（1）数据准备——5张典型测试图像存储在oss://baobao-wlcb/camera_front/，覆盖不同难度级别；（2）Prompt设计——通过WITH vars AS (SELECT '# Please determine which of the following labels the image belongs to: Roundabout | Police Car | Pickup Truck | Crane/Lift Truck | None of the Above\n\n* Roundabout\nVisual features: There is a circular intersection directly in front of the vehicle, and there are white guide arrows on the road surface or roadside.\n\n* Police Car\nVisual features: The vehicle body has clearly visible words such as "公安", "警察", or "POLICE", or official police insignia, and the body livery matches a standard police car style (such as black-and-white, blue-and-white, etc.).\n\n* Pickup Truck\nVisual features: A light truck with a separate cab and an open cargo bed at the rear.\n\n* Crane/Lift Truck\nVisual features: A heavy-duty special-purpose engineering vehicle with a large folding crane arm or a tall telescopic ladder mounted on the chassis.\n\n# Do not include any explanatory text in the output. Format: ["Label 1", "Label 2", ...]' AS prompt)定义详细的视觉特征描述prompt；（3）AI Function调用——SELECT t.path, ai_query(v.prompt, data => t.content, service_name => "qwen3.6-plus") as result FROM read_files('oss://baobao-wlcb/camera_front/', 'jpg,png') t CROSS JOIN vars v——直接从OSS读取图像+调用Qwen3.6-plus多模态+输出结构化JSON标签；（4）结果分析——5张图像秒级分析完成，每个图像的标签准确率100%（Image 1 = Police Car + Pickup Truck、Image 2 = Roundabout、Image 3 = Crane/Lift Truck、Image 4 = Pickup Truck、Image 5 = []）。关键洞察——“下载数据→写Python脚本→部署环境→运行推理”的传统流程减少到”写SQL→提交运行”——数小时流程变分钟；多模态AI Function的吞吐量显著优于UDF方案——embedding函数自动合并多行为单LLM请求。

行业影响

阿里云EMR Serverless Spark AI Function多模态的发布意义不是”又一个LLM SQL函数”，而是”SQL成为AI代理的统一接口”的范式跃迁——多模态数据（图像+视频+音频）+LLM推理+结构化输出，全部在Spark SQL内完成，数据工程师无需离开SQL环境。

此前AI应用开发团队的痛点是”多模态数据需要复杂的预处理管道”——开发一个自动驾驶corner case挖掘系统需要：（1）下载OSS图像到本地；（2）写Python脚本调用Qwen-VL API；（3）处理API限流+重试+超时；（4）解析LLM返回的非结构化输出；（5）写入下游数据库。EMR Serverless Spark AI Function让这一切简化为”一条SQL”——开发团队不再需要写Python脚本或处理API细节，所有多模态AI推理在Spark SQL中完成。这是AI应用基础设施的根本性简化。

将本期与Vol.22报道的Databricks AI Search（Vector Search更名+全文搜索+混合搜索+存储优化端点10-20倍索引加速超10亿向量）和Vol.14报道的Snowflake Cortex AISQL（AI_FILTER/AI_JOIN/AI_AGG/AI_CLASSIFY SQL函数）对比，Databricks AI Search是”向量检索的SQL化”（在Databricks平台内），Snowflake Cortex AISQL是”AI函数SQL化”（在Snowflake平台内），EMR Serverless Spark AI Function是”多模态AI函数SQL化”（在阿里云平台内）。三者共同构成”AI能力SQL化”三大云厂商对位——Databricks走”专有服务”路径（Vector Search专用服务+Unity Catalog集成），Snowflake走”原生SQL函数”路径（Cortex AISQL+Cortex Search），阿里云走”开源引擎+多模态”路径（EMR Serverless Spark+Apache Paimon+Qwen-VL）。三条路径都会成功，目标用户不同——Databricks面向Databricks生态用户，Snowflake面向Snowflake生态用户，阿里云EMR Serverless Spark面向开源生态用户。

将本期与Vol.18报道的腾讯云三层Agent-Ready数据平台（DataBuddy+WeData+AI原生底座）和Vol.10报道的阿里云AgentTeams（基于Matrix协议异构智能体统一治理+Leader-Worker协作）对比，EMR Serverless Spark AI Function是”AI代理在数据基础设施层的入口”——AI代理不再需要”独立的服务调用”，直接在SQL中调用AI。这与Vol.10报道的ClickHouse Agents（基于Claude的完全托管代理分析服务）的”AI代理调用数据库”是同一方向——“AI代理在数据基础设施内运行”是AI代理时代的关键趋势。

将本期与本期”混合标量-向量检索”主题对比，混合标量-向量检索是”Spark SQL调用向量数据库”（vector_search UDF+Lumina+B-tree Global Index），AI Function多模态是”Spark SQL调用LLM”（ai_query+ai_embedding_multimodal+Qwen3.6-plus+tongyi-embedding-vision-plus）。两者的协同——AI Function生成embedding → 写入Paimon表+自动构建Lumina索引 → vector_search UDF检索+WHERE过滤 → 结果JOIN下游表——完整的多模态数据处理管道在一条SQL中完成。当”AI Function生成embedding”+“vector_search UDF检索”组合时，AI时代的”SQL原生多模态RAG”完整形态落地——企业可以在Spark SQL内完成”图像→embedding→向量检索→标量过滤→结果分析”的完整RAG流程，无需离开SQL环境。

相关链接

阿里通义实验室Tongyi Lab发布PawBench：用4,050次Agent Run量化”模型×智能体脚手架”的真实性能差距

事件概述

7月6日，阿里通义实验室Tongyi Lab发布PawBench基准测试（GitHub: agentscope-ai/PawBench，Leaderboard: https://agentscope-ai.github.io/PawBench/，OpenJudge: https://github.com/agentscope-ai/OpenJudge）——通过4,050次Agent Run系统评估’AI模型×智能体脚手架’的联合性能。核心背景——AI代理已不再是研究demo，今天它们写代码+浏览网页+操作文件+完成多步工作流；但当AI代理失败时，难以回答”是模型不够好还是脚手架没支持好？“——PawBench就是为解决这个根本性问题而设计。PawBench是OpenJudge生态系统的一部分——继承OpenJudge”评测驱动优化”的理念，特别关注LLM × Harness的联合效应。关键设计原则——Agent Performance = f(Model, Harness)——模型决定AI代理”能做什么”；脚手架决定AI代理”能稳定地做到什么”。PawBench v1.0构成——150个真实世界AI代理任务 + 9个基础模型 + 3个生产级脚手架（Hermes、OpenClaw、QwenPaw）——9 Models × 3 Harnesses × 150 Tasks = 4,050 test cells。150个任务精选自6个高质量代理基准（claweval、qwenclawbench、pinchbench、qwenpawbench、skillsbench、wildclawbench），每个任务沿5个维度打标签（应用场景/原子能力/复杂度/输入模态/运行环境）。所有任务在Docker沙箱中运行且完全可追溯，最终分数结合自动化评分器（规则检查+子断言）和LLM-as-judge，归一化到0-1范围。核心发现——QwenPaw 75.4 vs OpenClaw 74.8 vs Hermes 70.0（5.5分差距）——脚手架差距可比模型升级；在某些情况下更好的脚手架能弥合甚至逆转模型等级（如qwen3.6-plus + QwenPaw (76.5) > qwen3.6-max-preview + Hermes (70.2)）。PawBench的发布意义不是”又一个AI代理基准测试”，而是”AI代理时代胜负不只由模型决定”的系统化验证。

技术解析

  • 核心发现1：脚手架差距可比模型升级：PawBench的核心数据——9个模型×3个脚手架×150个任务 = 4,050次Agent Run。模型与脚手架都影响AI代理性能——强模型跨脚手架保持稳定（claude-opus-4.6在所有脚手架上得分>76），弱模型对脚手架更敏感（qwen3.6-35b-a3b从Hermes的57.9到QwenPaw的70.4，+12.5分差距）。脚手架差距可比模型升级——QwenPaw (75.4)领先OpenClaw (74.8)和Hermes (70.0)，形成5.5分差距；在某些情况下更好的脚手架能弥合甚至逆转模型等级——qwen3.6-plus + QwenPaw (76.5)优于qwen3.6-max-preview + Hermes (70.2)。核心洞察——模型能力仍然重要，但脚手架可以引入可测量的性能差异。PawBench的leaderboard只是起点——更有趣的问题是：那些丢失的分数究竟来自哪里？

  • 核心发现2：小模型需要脚手架稳定执行：PawBench的两个极端——claude-opus-4.6在所有脚手架上稳定（2.3分差距），qwen3.6-35b-a3b在不同脚手架上偏移11.5分（仅由脚手架决定）。这个差距揭示了一个清晰模式——大模型可以补偿缺失的上下文：它们推断路径+过滤更大的工具列表+检查工件是否实际生成；小模型更脆弱：丢失当前工作目录跟踪+误判文件是否被写入+当工具列表过大时选择错误的第一个工具。追踪分析指向三个常见失败源：（1）缺失的工件级验证——许多脚手架依赖模型说”完成”而不检查文件/测试/输出——这让”提前完成”容易；（2）宽松的路径感知和约束——例如Hermes没有把当前工作目录清晰地注入prompt，也没有在write_file等工具中严格约束写入路径——模型可能”相信”自己成功写入了文件而评分器在工作区找不到它；（3）工具过载——工具数量差异巨大（Hermes ~65个、OpenClaw ~30个、QwenPaw ~15个）——更大工具集往往伤害小模型（增加决策成本）。核心洞察——不是小模型弱，而是它们更依赖脚手架结构。

  • 核心发现3：技能使用需要脚手架发现+模型执行：许多开发者在工作区内部存储项目特定的Skills。PawBench模拟此设置评估脚手架能否发现和利用它们。所有三个脚手架中，技能相关任务比工具使用/规划/推理等类别更困难。两个问题突出：（1）脚手架侧发现缺口——除OpenClaw外，其他两个脚手架不主动扫描工作区中的本地技能，导致AI代理错过有价值的任务特定指导；（2）模型侧执行缺口——即使脚手架注入Skill并放置路标，模型在复杂推理或精确计算时仍可能失败——脚手架可以指路，但基础模型仍需自己走完路径。核心洞察——成功需要两者——脚手架必须清晰地暴露Skills（名称/范围/用法），模型必须可靠地决定调用它们。如果任一方失败，模型会绕过Skill，试图用通用推理解决任务。

  • 核心发现4：Web搜索任务依赖默认可用性：Web搜索任务测试模型的搜索网页+获取内容+做深入研究能力。PawBench不假设最佳情况配置（每个搜索API key都配置好），而是重建默认开发者体验——克隆一个固定版本，添加LLM key，运行。关键发现——（1）Hermes包含web搜索能力，但需要外部搜索API keys才能使用，因此在这些任务上表现不佳；（2）OpenClaw有更好的默认体验——web_search可以使用DuckDuckGo等无key服务，web_fetch依赖内置HTTP获取；（3）QwenPaw没有专门的搜索工具，但其browser_use工具+模型知识仍可处理基本web访问。追踪行为显示分裂——强模型自适应（当搜索失败时切换到terminal + curl+DOM检查+长页面提取），弱模型停滞（重复导航或得出任务不可行的结论）。核心洞察——强模型能绕过缺失工具，弱模型依赖脚手架保持搜索路径的稳定和明确。

  • 模型×脚手架共设计四原则：基于PawBench基准测试结果，有效脚手架应遵循四个简单原则：（1）上下文不假设——模型无法在不知道信息的情况下行动——告诉模型它在哪里、什么资源存在、什么输出是预期的——绝不假设模型会推断这些细节；（2）工具充分且高效——提供重要的工具，确保关键工具默认可用，但避免用不必要的选项压垮模型；（3）工件级验证——不能仅依赖模型说的”完成”——验证工件/文件/输出/执行结果而非仅依赖AI代理自报告；（4）失败可恢复——许多失败可恢复，如果框架提供有用的反馈和重试机会——提供关键信息（当前状态/缺失需求/已有工件），给模型结构化的恢复机会。这与Vol.10报道的阿里云AgentTeams（基于Matrix协议异构智能体统一治理+Leader-Worker协作）和Vol.13报道的Pulumi Agent基础设施时代（临时云账号+Neo集成目录）是同一方向——“AI代理时代的基础设施设计原则”是AI代理时代的隐性标准。

  • PawBench对AI代理生态的意义：PawBench的最大启示——AI代理时代的胜负不是模型的单独属性——模型×脚手架的联合效应决定最终表现——Agent Performance = f(Model, Harness)。关键含义：（1）对AI代理用户——选择模型时不能只看模型排行榜，必须考虑”模型+脚手架”的联合性能——同样的qwen3.6-plus在QwenPaw上76.5、在Hermes上可能只有65.0；（2）对脚手架开发者——脚手架不是”脚手架框架”，而是AI代理性能的关键乘数——5.5分差距”可相当于一次模型升级”——值得投入工程资源；（3）对AI代理生态——未来可能出现”模型-脚手架联合排行榜”，而非仅模型排行榜——OpenJudge生态系统的”评测驱动优化”理念将推动生态向”模型-脚手架协同”演进。PawBench v1.0完全开源——欢迎新脚手架、模型、任务和社区贡献。

行业影响

阿里通义实验室PawBench的发布意义不是”又一个AI代理基准测试”，而是”AI代理时代的胜负不只由模型决定”的系统化验证——通过4,050次Agent Run的大规模实验，PawBench首次量化了”模型×脚手架”的联合效应。

此前AI代理领域的竞争焦点是”哪个模型最强”——Claude Sonnet 4.5 vs GPT-5 vs Gemini 2.5 Pro vs Qwen3.6-Plus，所有竞争都围绕”模型排行榜”展开。PawBench揭示了一个被忽视的事实——脚手架对AI代理性能的影响”可相当于一次模型升级”（5.5分差距=模型升级）。这意味着AI代理时代的竞争焦点将从”模型排行榜”扩展到”模型+脚手架联合排行榜”——Hermes vs OpenClaw vs QwenPaw将成为新的竞争维度。

将本期与Vol.10报道的阿里云AgentTeams（基于Matrix协议异构智能体统一治理+Leader-Worker协作）和Vol.13报道的Pulumi Agent基础设施时代（临时云账号+Neo集成目录）对比，AgentTeams是”通用Agent的多代理协调”（适用于任何Agent场景），PawBench是”AI代理性能的量化评估”（适用任何AI代理）。两者形成”AI代理基础设施+AI代理评估”的完整闭环——AgentTeams提供”AI代理怎么协同”（runtime层），PawBench提供”AI代理性能怎么评估”（evaluation层）。当AgentTeams+Omnigent（Vol.26开源meta-harness）+PawBench形成完整AI代理生态时，阿里在AI代理领域建立了”协同-评估”双轨布局。

将本期与Vol.26报道的Databricks开源Omnigent（meta-harness架构协调多AI编码代理+Shared Sessions+Guardrails+Human-in-the-Loop）对比，Omnigent是”编码Agent的多代理协调”（特化于编码场景），PawBench是”通用AI代理的性能评估”（适用任何AI代理）。两者是”AI代理运行时基础设施+AI代理性能评估基础设施”双轨——Omnigent提供”多代理怎么协同”（runtime层），PawBench提供”模型×脚手架性能怎么量化”（evaluation层）。当Omnigent开源+Agent Registry托管时，Databricks在多代理领域形成了”开放协调层+集中治理层”的双层架构；当PawBench+AgentTeams形成阿里AI代理布局时，阿里形成了”性能评估层+协同运行时层”的双层架构。两者的双层架构不冲突——Databricks和阿里在AI代理领域选择了不同的双层布局。

将本期与Vol.7报道的Databricks Instructed-Retriever-1（并行测试时计算替代序列Agent推理/KARLBench nDCG@10 81.0与Claude Sonnet 4.5持平/3倍搜索加速2倍答案生成/TTFT约2秒端到端低于10秒/MoE+FP8+投机解码/单模型双能力查询生成+重排序/两个并行扩展旋钮：查询表述数量→召回、锚点数量→精度/测试时计算范式从”想更久”走向”并行想更多”）对比，Instructed-Retriever-1是”测试时计算扩展”（让单一模型在推理时并行多次），PawBench是”测试时脚手架优化”（让单一模型在不同脚手架下表现不同）。两者是”AI代理从单点能力走向系统能力”的两个方向——前者通过”同一模型做多次”提升性能，后者通过”不同脚手架各做一次”提升质量。当Instructed-Retriever-1的”并行推理”+PawBench的”脚手架优化”组合时，AI代理的”质量+速度+稳定性”可以同时优化。

相关链接

编者评

第二十七期是数据基础设施”AI原生重构”范式跃迁的里程碑。Apache Paimon 1.4.2（6/29）的发布是”湖格式原生支持多模态AI”的开源答案——BLOB类型+Vector Index（DiskANN）+Data Evolution+PyPaimon把结构化+半结构化+非结构化+向量+元数据统一在一张表中，通过SQL/向量搜索/全文搜索统一查询，对位Delta Lake+Iceberg+LanceDB+Milvus多者合一的统一形态，阿里巴巴内部EB级生产环境验证让”AI多模态数据湖”从概念走向生产；阿里云EMR Serverless Spark（7/6）的混合标量-向量检索+AI Function多模态让Paimon 1.4+的能力在SQL层完整暴露——vector_search UDF + ai_query + ai_embedding_multimodal + Lumina索引 + B-tree索引 + Qwen-VL/tongyi-embedding-vision-plus——一条SQL完成”图像→embedding→向量检索→标量过滤→结果分析”完整RAG流程，数据工程师无需离开SQL环境；PawBench 4,050次Agent Run（7/6）揭示了”Agent Performance = f(Model, Harness)“——脚手架差距5.5分可比模型升级，AI代理时代的胜负不只由模型决定，未来竞争将从”模型排行榜”扩展到”模型+脚手架联合排行榜”。

这四条动态的深层意义不是”四个独立的产品发布”，而是”AI时代数据基础设施的标准形态”正在形成——Paimon 1.4.2定义存储层（BLOB/VECTOR/Lumina）+ EMR Serverless Spark定义SQL层（vector_search/ai_query/ai_embedding_multimodal）+ PawBench定义评估层（Model × Harness = Agent Performance）——三层协同构成”AI多模态数据基础设施”完整技术栈。数据基础设施正从”结构化数据的仓库”演化为”多模态AI数据的操作系统”——结构化数据+半结构化数据+非结构化数据+向量embedding+LLM调用+脚手架性能评估全部在一套技术栈中完成，数据工程师不再需要在多个系统之间搬运数据，AI代理可以直接在数据基础设施内运行。

值得注意的边缘观察：dbt Labs 7/6发布’A guide to implementing AI data pipelines’——Stephen Thibeault 14分钟Insights文章核心数据”72%团队优先采用AI辅助代理编码，但只有24%团队优先采用AI辅助数据管道管理”，反映”AI采纳（个体开发者使用AI工具）“与”AI集成（将AI融入数据基础设施）“的巨大差距。文章提出”AI分层叠加”理念——将AI引入日常工作流不需要改变现有数据栈——代码审查+错误分类+提取/加载+工单接收+消费层五层AI应用，三步走方法论（找到第一个低风险的痛点+设置试点+收集反馈创建评估）。这与PawBench的”AI代理性能评估”和Paimon 1.4.2的”AI多模态数据湖”形成”AI时代数据栈的三层叙事”——dbt提出”AI集成方法论”（how to adopt AI），Paimon+EMR Serverless Spark提供”AI多模态数据栈”（where to put AI），PawBench量化”AI代理性能”（how to measure AI）——当三者协同时，AI时代数据基础设施的”方法论+技术栈+评估体系”完整落地。

下一期值得关注的边缘候选：Apache Flink 2.3.1维护版本（预计7月发布）、Apache Paimon 1.4.3维护版本（预计7-8月）、Snowflake Cortex Sense GA（6/2宣布”coming soon mid-July”）、Delta Lake 4.4（预计8-9月）、Spark 4.2.0（预计Q3）、Databricks Runtime 19 (Beta) 后续GA（6/15初始Beta+6/26维护，JDK 21+Spark 4.2+ChangelogTableSQL+V2 catalog Metric Views，作为下一个强候选）。值得长期关注的AI代理基础设施趋势——Meta-harness+Agent Skills+Agent Benchmark+Open Table Format + Multimodal AI Function + Serverless Sandbox——当六个趋势协同时，AI代理时代的”运行时+评估+数据栈”完整形态将落地。