Databricks Instructed-Retriever-1以并行测试时计算替代序列Agent推理实现3倍检索加速；阿里云AliSQL DuckDB开源将OLAP嵌入MySQL开辟轻量HTAP路径；Databricks AI Search从纯向量走向全文+向量混合；阿里云LoongSuite GenAI SemConv与SkillClaw×Nacos构建AI代理可观测与技能治理闭环

第十七期追踪到DataInfra领域四条重要动态：Databricks 6月4日发布Instructed-Retriever-1博客——检索专用模型以并行测试时计算替代序列化Agent推理链，单模型承担查询/过滤器生成（提升召回）与多锚点分组重排序（提升精度），两个测试时扩展旋钮（查询表述数量→召回、锚点数量→精度）均可并行化，MoE+FP8+投机解码将TTFT压至约2秒、端到端延迟低于10秒，KARLBench上nDCG@10达81.0与Claude Sonnet 4.5持平但搜索3倍、答案生成2倍加速——此前测试时计算的研究方向（如DeepSeek/OpenAI o1）集中在”让模型想更久”（序列化推理链），Instructed-Retriever-1开辟了新方向”让模型并行想更多”（并行测试时扩展），对于检索场景延迟敏感的特性尤为适合；阿里云AliSQL DuckDB正式开源——DuckDB以MySQL内置存储引擎形式嵌入（而非外部进程或独立服务），通过MySQL标准数据字典管理元数据确保与主实例事务语义完全兼容，binlog原生复制同步数据，代理层根据SQL预估执行代价自动行列分流（OLTP→InnoDB/OLAP→DuckDB），两种产品形态：DuckDB只读实例（HTAP场景——一份数据同时服务交易与分析）和DuckDB分析主实例（数据汇聚场景——多个MySQL实例汇聚到单一DuckDB实例统一分析），复杂分析查询相比InnoDB提升100倍以上、列式存储压缩率提升50%以上、99.9% MySQL语法和函数兼容原查询零修改直接执行，小红书生产验证——这不是再造一个TiDB式重型HTAP，而是让MySQL自己长出DuckDB分析能力的轻量路径，OLAP不是替代OLTP而是嵌入OLTP；Databricks 6月产品更新中Vector Search更名为AI Search——新增全文搜索索引无需向量/嵌入（BM25评分，Beta），支持在存储优化端点上创建纯全文索引，混合搜索同时使用全文和向量再经原生重排序器排序，存储优化端点10-20倍索引加速、超10亿向量容量（768维度），AI Search产品页面定义”AI原生检索平台”定位（搜索+排序+评估+持续学习），DAIS 2026专题演讲”From Vector Search to AI Search: Rebuilding Retrieval for the AI Era”预告后续路线图（点击日志/持续质量监控/学习排序）——与Instructed-Retriever-1形成Databricks检索能力栈的模型层+基础设施层互补；阿里云6月发布LoongSuite GenAI SemConv和SkillClaw×Nacos——LoongSuite GenAI SemConv作为OTel GenAI语义规范的厂商增强标准（后续将贡献社区上游），三个核心扩展：Entry Span还原Agent入口原始输入输出（不受System Prompt/框架Prompt污染）、Step Span层次化表达每次ReAct循环（gen_ai.react.round标识轮次）、Skill语义归因让业务功能域可观测（解决现有规范缺少Skill业务功能聚合层抽象的问题），已在阿里巴巴和蚂蚁集团多核心场景落地；SkillClaw×Nacos构建从Agent会话到可治理技能注册表的自动演化闭环——SkillClaw从多用户交互轨迹中自动提炼可复用技能（发现重复→合并去重/发现缺陷→优化补充/发现相似→提炼通用方法），候选Skill经Nacos draft→review→online治理流程后发布，skill-scanner安全扫描插件检查敏感信息/危险命令/越权工具，Pipeline可扩展治理机制支持团队自定义规则，HiClaw（Agent执行层）+HiMarket（私有市场层）+Nacos（管理层）构成企业私有能力管理平台——四条动态共同指向DataInfra各层的效率跃迁：检索从序列化走向并行（Instructed-Retriever-1），查询从分离走向嵌入（AliSQL DuckDB），搜索从纯向量走向混合（AI Search），AI代理从不可观测走向可观测可治理（LoongSuite+SkillClaw×Nacos）。每个层面都在消除效率税——Agent推理链的延迟税、OLAP独立部署的运维税、向量搜索对精确匹配的遗漏税、AI代理缺乏可观测性的调试税。

Instructed-Retriever-1：并行测试时计算替代序列Agent推理，检索效率的范式跃迁

事件概述

6月4日，Databricks AI Research Team发布Instructed-Retriever-1博客，宣布Agent Bricks Knowledge Assistant的检索效率重大升级：搜索速度提升3倍以上、答案生成速度提升2倍，TTFT压至约2秒、端到端延迟低于10秒。这些提升由Instructed-Retriever-1驱动——一个专为并行测试时扩展（parallel test-time scaling）设计的检索专用模型。与当前主流的序列化Agent检索（Agent逐步推理、每步依赖上一步结果决定下一步）不同，Instructed-Retriever-1将检索工作并行展开：同时生成多个查询/过滤器表述以提升召回，同时执行多锚点分组重排序以提升精度。在KARLBench上，Instructed-Retriever-1的nDCG@10达到81.0，与Claude Sonnet 4.5的检索质量持平，但延迟大幅降低。该更新已自动上线所有Knowledge Assistant用户，无需重新配置。

技术解析

• 并行测试时扩展 vs. 序列化Agent推理：当前主流的Agent检索系统（如ReAct循环、工具调用链、思维链推理）将测试时计算花在序列操作上——每一步依赖上一步结果，质量提升但延迟和成本线性增长。Instructed-Retriever-1走不同路径：在初始搜索阶段并行化测试时计算——通过同时探索同一请求的多种表述和维度来拓宽检索证据范围，预先选择最相关的上下文。两个并行化的测试时扩展旋钮：①查询/过滤器表述数量（提升召回）——同时生成多种查询表述搜索更广范围；②锚点数量（提升精度）——多锚点分组重排序，每个锚点锚定一组候选块，组内排序后合并为最终排序。两者均可并行执行，用更多测试时计算换更高质量上下文但保持低延迟。
• 单模型双能力：Instructed-Retriever-1是一个模型同时支持查询/过滤器生成和重排序——而非分离的查询生成模型+重排序模型。两阶段训练：第一阶段学习查询和过滤器生成能力，第二阶段学习验证式检索能力（verification-style retrieval）。数据准备方面，从广泛预训练语料中合成企业风格检索环境（独立于评估基准KARLBench），包括事实查找、摘要、推荐、问题解决和决策支持等任务类型。
• 推理服务优化：MoE（混合专家）架构降低推理计算量，FP8量化减少显存占用和带宽需求，投机解码（speculative decoding）加速自回归生成。三者组合将TTFT压至约2秒——此前序列化Agent检索的TTFT通常在5-10秒量级。
• 企业约束传播：Instructed-Retriever-1继承此前Instructed Retriever架构的核心设计——搜索线束（search harness）将用户指令和底层检索索引的精确schema传播到查询生成、过滤器生成、重排序和答案生成的所有阶段。这对企业场景至关重要——企业查询通常涉及时间范围、组织部门、文档类型、产品领域等领域特定约束，纯向量搜索无法表达这些硬约束。
• 与Vol.14-16的检索/搜索主线：Vol.14报道Cortex AISQL将AI操作符注入SQL引擎（“AI如何查询数据”），Vol.15报道Horizon Context从数据目录走向AI理解层（“AI如何理解数据”），Vol.16报道Cross-Engine ABAC（“AI如何被授权访问数据”）。Instructed-Retriever-1解决的是更基础的一层——“AI如何高效地检索数据”。当检索从序列化Agent推理（高延迟、高成本）走向并行测试时扩展（低延迟、高质量）时，RAG从”可用”走向”好用”——此前企业RAG的常见抱怨是”太慢”和”不够准”，Instructed-Retriever-1同时解决了这两个问题。

行业影响

Instructed-Retriever-1的深层意义不是”又一个RAG优化”，而是测试时计算在检索场景的范式选择：从序列化走向并行。此前的测试时计算研究（DeepSeek R1、OpenAI o1/o3、Anthropic extended thinking）集中在”让模型想更久”——通过更长的推理链提升质量，但延迟线性增长。这对数学推理、代码生成等延迟不敏感场景可行，但对检索场景不可接受——用户等待搜索结果的耐心以秒计，不以分钟计。

Instructed-Retriever-1开辟了”让模型并行想更多”的路径——多个查询表述并行生成（广度扩展），多个锚点并行重排序（精度扩展），用并行计算换质量而非用序列时间换质量。这个范式选择对检索场景尤为重要：检索的核心矛盾不是”想得不够深”（序列推理可解决），而是”搜得不够广+排得不够准”（并行扩展更适合）。

更深远的影响在于：当检索模型的专用化程度足够高时，小模型可以在特定任务上匹配大模型的检索质量。Instructed-Retriever-1在KARLBench上与Claude Sonnet 4.5持平，但推理成本和延迟远低于通用大模型。这验证了一个趋势：检索不需要通用推理能力，需要的是查询理解和证据排序的专用能力——专用模型在检索场景可以”以小博大”。

相关链接

• 3x Faster Search: Parallel Test-Time Scaling with Instructed-Retriever-1
• Instructed Retriever: Unlocking System-Level Reasoning in Search Agents

---

AliSQL DuckDB开源：OLAP嵌入MySQL的轻量HTAP路径

事件概述

阿里云AliSQL DuckDB正式开源，DuckDB以MySQL内置存储引擎形式嵌入AliSQL内核——所有SQL请求通过MySQL Connection接入，SQL Planner进行智能路由：事务型SQL由InnoDB处理，分析型SQL路由到DuckDB列存引擎，两个引擎通过Binlog进行数据同步。两种产品形态：DuckDB只读实例（HTAP场景——代理层根据SQL预估执行代价自动行列分流）和DuckDB分析主实例（数据汇聚场景——多个MySQL实例的binlog汇聚到单一DuckDB实例统一分析）。相比InnoDB，复杂分析查询性能提升100倍以上，列式存储压缩率节省50%以上存储空间，99.9% MySQL语法和函数兼容原查询零修改直接执行。小红书已在生产环境验证。阿里云同步开源AliSQL向量化引擎和AliSQL-CLI，形成”最短链路的AI就绪数据底座”。AliSQL与RDS MySQL将”双轨并进”——开源技术栈选AliSQL，云上定制化需求选RDS。

技术解析

• DuckDB作为MySQL存储引擎——不是外部进程，是内置引擎：DuckDB以内置存储引擎形式集成到MySQL中（而非独立进程或外部服务），天然具备MySQL Server层提供的各项能力——数据字典管理、binlog复制、权限控制等。DuckDB节点作为数据副本，接受来自主库的binlog日志回放，独立对外提供读请求服务。这种”嵌入式”架构与TiDB/PolarDB的”独立分布式系统”架构形成根本差异——前者是MySQL自己的能力扩展，后者是替换MySQL的独立系统。
• HTAP行列自动分流：代理层根据SQL的预估执行代价自动将OLAP和OLTP请求分流——OLAP查询路由至DuckDB列存实例，OLTP查询路由至InnoDB行存实例（主实例或普通只读实例）。也支持通过HINT语法手动分流。分流逻辑对应用透明——应用无需修改代码即可获得HTAP能力。
• DuckDB分析主实例——数据汇聚场景：除DuckDB只读实例（从主库binlog同步、只提供分析读）外，新推出DuckDB分析主实例——允许用户使用SQL直接进行数据写入，或作为多个源实例的汇聚实例。典型场景：1024个分片MySQL实例的数据汇聚到单一DuckDB实例进行统一分析。多源binlog复制引入攒批机制（batch optimization），同步性能提升100倍——此前大事务复制延迟是核心痛点，攒批机制基本消除大事务产生的复制延迟。
• 兼容性工程：实现MySQL与DuckDB深度融合的最大挑战是兼容性，集中在四方面——数据类型差异、SQL语法不同、函数语义差异、结果集表达方式不一致。AliSQL的解法是：SQL解析器改造适配DuckDB执行语义、结果格式自动转换对接应用逻辑。最终达到99.9%的MySQL语法和函数兼容，原有查询零修改即可执行。DuckDB引擎升级至1.5.2版本（内核小版本20260511），支持json_objectagg函数、自增值、后台异步Checkpoint线程等。
• 与Vol.7/13的DuckDB主线演进：Vol.7报道Spark 4.1中的DuckDB相关集成，Vol.13报道DuckDB-Iceberg扩展v1.5.3（从”能读Iceberg”走向”完整操作Iceberg”），Vol.16报道DuckDB即将支持Cross-Engine ABAC（从”无管控操作”走向”受管控操作”）。本期AliSQL DuckDB代表DuckDB的又一个角色转变——从”独立的嵌入式分析引擎”走向”MySQL的分析能力扩展”——DuckDB不再是需要单独部署使用的分析工具，而是MySQL生态内生的分析能力。

行业影响

AliSQL DuckDB开源的深层意义不是”又一个HTAP数据库”，而是轻量HTAP路径的可行性验证——不需要替换MySQL、不需要引入独立分布式系统、不需要重写应用，只需在MySQL内部嵌入DuckDB引擎即可获得分析能力。

这与TiDB/PolarDB的重型HTAP路径形成鲜明对比。TiDB的路径是”替换MySQL”——独立的分布式系统，TiFlash列存节点+TiKV行存节点，需要迁移应用和运维体系。PolarDB的路径是”云原生重写”——存储计算分离架构，需要云平台深度绑定。AliSQL DuckDB的路径是”原地增强”——MySQL还是MySQL，DuckDB是MySQL的一个存储引擎选项，应用零修改、运维零学习成本。

这个轻量路径的可行性建立在一个关键前提上：DuckDB的单机分析性能已经足够覆盖大多数MySQL用户的分析需求。当100倍以上性能提升（相比InnoDB）将”分钟级分析查询”变为”秒级”，大多数场景不需要分布式分析引擎——DuckDB的单机列式存储+向量化执行已经够用。这正是DuckDB”嵌入式OLAP”哲学在HTAP场景的延伸。

小红书的生产验证尤其值得关注——作为中国头部内容社区，小红书的数据规模和分析需求具有代表性。当一个千万级日活产品的分析查询可以由嵌入MySQL的DuckDB承载时，“轻量HTAP”从理论可行性变为实践可行性。

相关链接

• AliSQL GitHub
• HTAP行列分流 - Alibaba Cloud
• AliSQL: 开源共生，创新进化

---

Databricks AI Search：从Vector Search到全文+向量混合搜索

事件概述

6月1日，Databricks将Vector Search正式更名为AI Search，并新增三项核心能力：①全文搜索索引（Beta）——无需向量或嵌入即可创建BM25评分的关键词搜索索引，仅在存储优化端点上可用；②混合搜索——在单次API调用中同时使用语义向量搜索和关键词全文搜索，再经原生重排序器排序；③存储优化端点——10-20倍索引加速，超10亿向量容量（768维度），延迟略有增加（约250ms）。AI Search产品定位从”向量搜索服务”升级为”AI原生检索平台”——统一搜索、排序、评估和持续学习。DAIS 2026专题演讲”From Vector Search to AI Search: Rebuilding Retrieval for the AI Era”预告后续路线图：点击日志、持续质量监控、学习排序。同期Databricks 6月产品更新包括：Catalog Explorer列热度分析、Delta Sharing表更新触发器（Beta）、Genie Code自动批准和全页面模式、Supervisor Agent网络搜索能力、新增Lakeflow Connect连接器（Pendo/Zoom Logs/RabbitMQ/Slack）。

技术解析

• 全文搜索索引——BM25无需嵌入：在存储优化端点上创建Delta Sync Index但不指定嵌入列，索引使用BM25评分进行关键词搜索。这是对”检索=向量搜索”假设的直接突破——并非所有搜索场景都需要语义理解，精确关键词匹配（如产品编号、状态代码、专有名词）在BM25上表现更好。此前Databricks Vector Search只能创建向量索引，关键词匹配需要外部Elasticsearch/OpenSearch补充。AI Search的全文索引消除了这一双系统运维负担——一个引擎同时服务语义搜索和关键词搜索。
• 混合搜索——向量+全文+重排序：单次API调用同时执行语义向量搜索和关键词BM25搜索，结果经原生重排序器（native reranker）排序后返回。混合搜索结合了两者的优势——向量搜索擅长语义相似性（“和X相关的内容”），全文搜索擅长精确匹配（“包含关键词Y的文档”），重排序器解决两者的结果重叠和排序融合问题。这与本期的Instructed-Retriever-1形成互补：Instructed-Retriever-1在模型层优化检索质量（并行查询生成+多锚点重排序），AI Search在基础设施层提供更丰富的检索模式（向量+全文+混合+重排序）。
• 存储优化端点：标准端点3.2亿向量容量（768维度），存储优化端点超10亿向量容量、10-20倍索引加速，但查询延迟略增（约250ms）。存储优化端点同时是全文搜索索引的唯一可用端点——大容量+快索引+BM25关键词搜索的组合面向的是企业级检索场景（海量文档+精确匹配+快速索引更新）。
• AI Search产品定位升级：从”向量搜索”到”AI原生检索平台”——统一搜索（向量/全文/混合）、排序（原生重排序器）、评估（LLM评判质量评估）和持续学习（预告中的点击日志+学习排序）。DAIS 2026演讲预告的路线图表明Databricks正在构建一个完整的检索工程平台——不仅是搜索基础设施，还包括质量度量和自动优化。
• 与Instructed-Retriever-1的检索能力栈互补：Instructed-Retriever-1在模型层做并行测试时扩展（查询生成+重排序），AI Search在基础设施层做混合索引+重排序。Knowledge Assistant的用户同时受益于两者——Instructed-Retriever-1决定”怎么搜”（搜索策略优化），AI Search决定”用什么搜”（搜索基础设施丰富度）。

行业影响

Vector Search更名AI Search并加入全文搜索，标志着行业对”向量为王”检索范式的反思和修正。过去两年，向量搜索几乎等同于AI检索——所有RAG教程都从”创建向量索引”开始。但在企业实践中，纯向量搜索的局限性日益明显：精确关键词匹配能力弱（产品ID、状态码、专有名词的精确搜索不如BM25）、对领域术语的语义理解依赖嵌入模型质量、无法表达硬约束（“必须包含关键词X”vs.”语义上与X相关”）。

AI Search的混合搜索模式直接回应了这些局限——向量搜索负责语义理解，BM25负责精确匹配，重排序器融合两者结果。这不是”向量搜索的失败”，而是”向量搜索的补完”——向量搜索是AI检索的必要条件但非充分条件。

从更广的视角看，本期三条动态（Instructed-Retriever-1 + AliSQL DuckDB + AI Search）构成了一个效率跃迁的三层图谱：模型层（Instructed-Retriever-1的并行测试时扩展提升检索质量/延迟比）、数据库层（AliSQL DuckDB的OLAP嵌入OLTP消除分析查询运维负担）、检索基础设施层（AI Search的全文+向量混合消除精确匹配盲区）。三层共同指向同一个方向——消除各层的效率税，让正确的数据以正确的方式在最短时间内到达正确的位置。

相关链接

• Databricks AI Search
• Databricks AI Search Documentation
• June 2026 Product Updates
• From Vector Search to AI Search: DAIS 2026 Session

---

LoongSuite GenAI SemConv与SkillClaw×Nacos：AI代理的可观测性与技能治理闭环

事件概述

阿里云6月发布两篇AI代理基础设施相关博客。LoongSuite GenAI SemConv由阿里巴巴和蚂蚁集团联合推出，作为OpenTelemetry GenAI语义规范的厂商增强标准——在OTel社区标准基础上深度扩展了Agent观测（Entry Span/Step Span）、Skill语义归因和Token级推理观测三个维度，提供统一数据语言支撑性能/成本/安全治理，已通过GenAI Utils工具链（Python/Go/Java）大幅降低接入成本，已在阿里巴巴和蚂蚁集团多核心场景落地，后续将逐步贡献至OTel社区上游。SkillClaw×Nacos构建从Agent会话轨迹到可治理技能注册表的自动演化闭环——SkillClaw从多用户交互轨迹中自动提炼可复用技能（发现重复技能→合并去重、发现缺陷→优化补充、发现相似流程→提炼通用方法），候选Skill经Nacos draft→review→online治理流程发布，skill-scanner安全扫描插件检查敏感信息/危险命令/越权工具，Pipeline可扩展治理机制支持团队自定义规则，HiClaw（Agent执行层）+HiMarket（私有市场层）+Nacos（统一管理层）构成企业私有能力管理平台。

技术解析

• LoongSuite GenAI SemConv三个核心扩展：
  • Entry Span与Step Span——让复杂Agent调用链可读：当Agent执行长程任务时，单个Trace中可能包含成百上千个Span，原生OTel标准无法区分业务层级。Entry Span（gen_ai.span.kind = ENTRY）在Agent调用入口处创建，还原模型和用户的原始输入输出（不受System Prompt或框架Prompt污染）；Step Span（gen_ai.operation.name = react）代表每次ReAct过程的层次化表达，通过gen_ai.react.round标识轮次。两者组合让复杂Agent调用链从”扁平的Span列表”变为”层次化的调用树”。
  • Skill语义归因——让业务功能域可观测：在电商购物助手等Agent场景中，用户指令由Agent理解意图后路由到对应Skill（技能）完成执行，但现有语义规范缺少对Skill这一业务功能聚合层的抽象。LoongSuite扩展了Skill语义维度，让”哪个Skill被调用、执行了什么、消耗了多少Token”可以在统一框架下追踪——这解决了Agent系统中”功能域可观测性”的空白。
  • Token级推理观测——支撑性能/成本/安全治理：细粒度的Token消耗追踪（输入/输出/推理Token分别统计）支撑三大治理场景——性能分析（哪个环节Token消耗异常）、成本治理（哪个Skill/Agent消耗最多Token）、安全审计（是否有异常的大量输出）。统一审计链路满足安全备案刚性要求。
• SkillClaw——Agent技能的自动进化：传统Agent技能（Skill）体系是静态的——开发者写好Skill后Agent调用执行，但Skill用得好不好、哪些场景失败、有没有更好执行路径不会自动反馈到Skill本身。SkillClaw给Agent增加”进化回路”——Client Proxy代理模型请求并记录交互轨迹（任务输入/工具调用/执行反馈/最终结果），可选Evolve Server读取多会话数据，分析Skill使用情况并智能更新。与普通记忆系统的区别：记忆系统偏向”记住发生过什么”，SkillClaw关注”从发生过的事情中提炼可复用的行动方法”。一个Skill不只告诉Agent某件事，而是告诉它在某类任务中如何规划、如何调用工具、如何验证结果、如何避免常见错误。
• Nacos Skill Registry——企业级技能治理：Nacos 3.2推出Skill Registry能力，作为企业自主可控的AI Skill注册中心。核心治理能力：draft→review→online三阶段发布流程、skill-scanner安全扫描插件（检查敏感信息/潜在危险指令/外链、不符合团队规范内容）、命名空间隔离、Skill级可见性（public/private/scoped）、端到端审计追踪（上传记录/审核日志/发布记录/调用溯源）、Pipeline可扩展治理机制。Agent运行时只读取Skill，不持有发布和删除权限——权限分离确保安全。
• HiClaw+HiMarket+Nacos企业AI管理平台：HiClaw作为Agent执行层消费Skill/Prompt/AgentSpec资源，HiMarket作为私有Skill市场+Worker市场，Nacos统一管理AI资源（Prompt/Skill/MCP/AgentCard）并提供治理和插件扩展。三者构成从执行到市场到治理的完整闭环。
• 与Vol.6/9/10的AI代理主线：Vol.6报道Databricks OTel+Unity Catalog集成（可观测性采集），Vol.9报道阿里云AgentLoop MemoryStore（记忆飞轮），Vol.10报道Hologres CLI & Skills（Agent-Ready数据仓库）和Agent Infra（AgentTeams/STAROps）。本期LoongSuite GenAI SemConv是OTel可观测性在GenAI场景的深度扩展（从”采集”到”语义标准化”），SkillClaw×Nacos是Agent技能从”静态使用”到”自动进化+治理”的闭环。

行业影响

LoongSuite GenAI SemConv和SkillClaw×Nacos共同指向AI代理基础设施的一个根本性缺失——可观测性和治理能力。当企业将AI代理部署到生产环境时，“能不能跑起来”只是第一步，“跑得对不对”、“花了多少钱”、“有没有安全风险”才是持续运营的核心问题。

LoongSuite GenAI SemConv解决的是”如何让AI代理可观测”——通过标准化语义规范让不同框架、不同平台、不同观测后端用同一套数据语言描述Agent行为。Entry/Step Span解决调用链可读性（从扁平到层次化），Skill语义归因解决功能域可观测性（从”哪个模型被调用”到”哪个业务能力被使用”），Token级观测解决成本/安全治理（从”Agent花了多少时间”到”Agent花了多少Token”）。这三个扩展填补了OTel GenAI标准在Agent场景的空白——OTel社区标准仍处于Development状态，很多新概念在收敛中，LoongSuite作为厂商增强标准先落地实践再贡献上游的模式是标准演进的有效路径。

SkillClaw×Nacos解决的是”如何让AI代理的技能可治理”——从Agent会话中自动进化技能，经过治理流程后发布到受控注册表。这回应了OpenClaw/ClawHub生态的治理缺失——Koi Security 2026年1月披露的ClawHavoc事件显示审计的2857个Skill中341个（约11.9%）含恶意代码。Nacos Skill Registry的draft→review→online流程和skill-scanner安全扫描直接回应了这一治理需求——企业不能将AI代理的技能来源交给不受控的公共仓库。

相关链接

• Alibaba & Ant Group LoongSuite GenAI Observability Semantics Specification
• SkillClaw × Nacos: 从一次Agent会话到可治理Skill Registry的自动演化闭环
• Nacos 3.2 Skill Registry
• 让Coding Agent从黑盒到透明

---

编者评

第十七期的四条动态，将Vol.12以来追踪的”效率跃迁”主线推进到检索、数据库、搜索和AI代理基础设施四个层面。

第一个维度是检索效率的范式跃迁：从序列化Agent推理到并行测试时扩展。 Instructed-Retriever-1的核心创新不是”更好的检索模型”，而是”不同的测试时计算使用方式”——此前的Agent检索将测试时计算花在序列推理上（每步依赖上一步结果），Instructed-Retriever-1将测试时计算花在并行扩展上（同时生成多种查询表述+多锚点重排序）。这个范式选择对检索场景尤为关键：检索的核心矛盾不是”想得不够深”而是”搜得不够广+排得不够准”，并行扩展比序列推理更适合解决这个矛盾。当nDCG@10达81.0与Claude Sonnet 4.5持平但搜索3倍快时，专用模型在检索场景”以小博大”的可行性得到验证——检索不需要通用推理能力，需要的是查询理解和证据排序的专用能力。

第二个维度是查询效率的架构跃迁：从OLTP/OLAP分离部署到OLAP嵌入OLTP。 AliSQL DuckDB的”轻量HTAP”路径与TiDB/PolarDB的”重型HTAP”路径形成鲜明对比——不是替换MySQL而是增强MySQL，不是引入独立分布式系统而是嵌入内置存储引擎，不需要重写应用而是零修改直接执行。这个路径的可行性建立在DuckDB的单机分析性能已经足够覆盖大多数MySQL用户分析需求的前提上——100倍以上InnoDB性能提升让”分钟级分析查询”变为”秒级”，大多数场景不需要分布式分析引擎。当OLAP不再需要独立部署和运维时，HTAP的采纳门槛从”引入新系统”降为”开启新存储引擎”。

第三个维度是搜索效率的能力跃迁：从纯向量到向量+全文混合。 AI Search的更名和全文索引新增标志着行业对”向量为王”检索范式的反思——向量搜索是AI检索的必要条件但非充分条件，精确关键词匹配在BM25上表现更好，混合搜索融合两者优势。结合Instructed-Retriever-1的模型层优化，Databricks构建了完整的检索能力栈——模型层决定”怎么搜”（搜索策略优化），基础设施层决定”用什么搜”（搜索模式丰富度）。两层互补而非替代：Instructed-Retriever-1在向量搜索+全文搜索+混合搜索的所有模式下都能提升检索质量。

第四个维度是AI代理基础设施的治理跃迁：从不可观测到可观测可治理。 LoongSuite GenAI SemConv解决”AI代理如何可观测”——通过标准化语义规范让不同系统用同一套数据语言描述Agent行为，三个核心扩展（Entry/Step Span、Skill归因、Token级观测）填补OTel标准在Agent场景的空白。SkillClaw×Nacos解决”AI代理的技能如何可治理”——从会话轨迹自动进化技能，经治理流程后发布到受控注册表，回应公共Skill仓库的治理缺失（ClawHavoc事件11.9%恶意代码率）。当AI代理从”能跑起来”到”跑得可控”时，企业部署AI代理的信心从技术验证走向运营保障。

将十七期主线串联，一个完整的效率跃迁图谱正在收拢： Vol.12判断”格式层功能差距已弥合，竞争转向目录层”；Vol.14-16看到目录层竞争从”注册发现”深化到”治理执行”和”语义理解”；本期看到效率跃迁从”架构层”下沉到”模型层和基础设施层”——Instructed-Retriever-1在模型层并行化测试时计算，AliSQL DuckDB在数据库层嵌入OLAP能力，AI Search在检索基础设施层混合向量与全文，LoongSuite+SkillClaw×Nacos在AI代理层提供可观测与治理。每个层面的效率跃迁都在消除一种”税”：Agent推理链的延迟税、OLAP独立部署的运维税、向量搜索对精确匹配的遗漏税、AI代理缺乏可观测性的调试税。 当这些”税”被逐一消除时，数据从存储到检索到分析到AI代理的每一步流动都更高效、更完整、更可控。