OpenSearch Agent Skills让搜索基建AI原生化；Flink实时动态过滤为Smartsheet省下$40K/月；DuckDB Quack协议打破嵌入式边界
第二期聚焦DataInfra四条动态：AWS发布OpenSearch Agent Skills让搜索和可观测性基础设施获得AI代理原生能力、Smartsheet基于Amazon Managed Flink构建实时动态过滤系统实现$40K/月成本节省与1.8倍延迟改善、DuckDB推出Quack远程协议让嵌入式数据库具备C/S架构能力、a16z研判从System of Record到System of Intelligence的价值迁移正在重塑数据基建格局
第二期追踪到DataInfra领域四条重要动态：AWS发布OpenSearch Agent Skills，将搜索和可观测性基础设施的领域知识封装为AI代理技能，与Anyscale Agent Skills形成”基础设施AI代理化”的跨厂商共振；Smartsheet披露基于Amazon Managed Flink构建的实时动态过滤系统，用KeyedCoProcessFunction+RocksDB状态后端替代SNS过滤策略，实现$40K/月成本节省和1.8倍延迟改善，为Flink生产实践提供了教科书级参考；DuckDB推出Quack远程协议，让嵌入式数据库通过HTTP获得C/S架构能力——ATTACH远程实例后即可像本地表一样查询和写入，这打破了嵌入式与C/S的边界；a16z发布《From System of Record to System of Intelligence》研判，指出CRM等记录系统正在被AI编排层取代为价值中心，数据基建的竞争力从”存数据”转向”编排水据”。
OpenSearch Agent Skills：搜索与可观测性基础设施的AI代理原生能力
事件概述
5月18日，AWS发布OpenSearch Agent Skills——一套开放、可组合的AI代理技能仓库，让Claude Code、Cursor、Kiro等Agentic IDE直接获得OpenSearch的领域专业知识。Skills通过npx skills add一键安装，首批上线三个核心技能：Search Skill（自然语言构建搜索应用）、Logs Skill（PPL查询日志与分布式追踪根因分析）、Solr到OpenSearch迁移Skill（自动化Schema转换与数据迁移验证）。
这一发布与上周Anyscale的Agent Skills形成鲜明呼应——两大基础设施厂商在同一周内分别将搜索/可观测性和分布式计算的领域知识封装为AI代理技能，标志着”基础设施AI代理化”从单点实践走向行业共识。
技术解析
- 模块化Skill树结构：Skills按领域组织为SKILL.md文件树，而非单一巨型Skill。Search Skill下包含opensearch-launchpad（BM25/语义/混合搜索），Observability下包含log-analytics和trace-analytics，Cloud下包含aws-setup。每个Skill足够小以适配代理的上下文窗口，又足够完整以覆盖端到端工作流。
- 消除四个专业门槛：OpenSearch的DSL语法、排名逻辑与混合搜索调优、延迟与集群健康排查、Elasticsearch/Solr迁移——这四个需要资深工程师数周完成的工作，Agent Skills让通用AI代理也能执行。例如”为产品文档构建语义搜索应用”→自动生成索引映射、嵌入管道和工作UI。
- 按需加载与可扩展：Skills按需加载保持上下文窗口紧凑，同时支持社区贡献和自定义扩展。路线图包括高级相关性调优、成本感知性能优化、索引生命周期管理，以及跨搜索/日志/分析的统一工作流。
行业影响
OpenSearch Agent Skills的发布验证了一个趋势：复杂基础设施的操作知识正在从”人脑中”迁移到”AI代理中”。上周Anyscale Agent Skills解决了Ray分布式计算的复杂度问题，这周OpenSearch Agent Skills解决了搜索与可观测性的专业门槛问题——模式完全一致：将领域知识编码为Skill → AI代理按需加载 → 开发者用自然语言驱动。
对DataInfra团队而言，关键行动点是：如果你的基础设施产品面向开发者，现在是设计Agent Skills接口的时机。未来开发者与基础设施的交互方式可能不是读文档写配置，而是对AI代理说”帮我构建一个混合搜索应用”。
相关链接
Smartsheet的Flink实时动态过滤：$40K/月成本节省背后的架构设计
事件概述
5月18日，AWS博客披露了Smartsheet基于Amazon Managed Service for Apache Flink构建实时动态过滤（RDF）系统的完整案例。Smartsheet每秒处理数十万事件支持实时协作，但原有架构依赖SNS过滤策略（传播延迟高达15分钟），被迫订阅全部事件后在消费端丢弃90%以上——每月$45K的运营成本中有$40K被浪费。RDF系统用Flink的KeyedCoProcessFunction+RocksDB状态后端替代SNS过滤，将过滤策略传播延迟从15分钟压缩至亚秒级（p95 ≤ 1秒），同时砍掉$40K/月成本，实时协作延迟改善1.8倍。
技术解析
- 双流处理模型：Filter Policy Stream（来自DynamoDB Streams的CDC，捕获消费者对特定Sheet的订阅/取消订阅）与Data Stream（Sheet事件流）通过KeyedCoProcessFunction按SheetID关联处理。过滤策略存储在Flink的RocksDB状态后端中，消除热路径上的外部DynamoDB查询。
- 广播状态处理”订阅全部”：少量”监听所有Sheet事件”的订阅通过Flink Broadcast State分发到所有并行任务，避免每条事件的全量匹配。设计时有意将广播状态限定为少量策略，控制JVM堆内存压力。
- DynamoDB Streams作为控制面：每个消费者团队拥有独立DynamoDB表，通过客户端库（Golang/Java）抽象Flink复杂性，实现权限隔离和防噪音邻居。
- RocksDB持久化：内存充足时全内存访问，超出时自动溢写到磁盘——兼顾性能与扩展性，无需为状态管理引入外部依赖。
行业影响
这个案例为Flink生产实践提供了教科书级的参考。它解决的不是”能不能用Flink”的问题，而是”如何把Flink的状态管理能力用到极致”——用Flink状态后端替代外部KV查询，用双流关联替代批处理过滤策略同步，用广播状态处理特殊模式。
更深层的影响是：Flink正在从”流处理引擎”向”实时决策基础设施”演进。当过滤、路由、权限判断等逻辑从消息中间件的”慢路径”迁移到Flink的”快路径”时，Flink的价值定位从”处理数据”升级为”决策数据”。
相关链接
DuckDB Quack协议：嵌入式数据库的C/S架构突破
事件概述
5月12日，DuckDB团队发布Quack远程协议，将DuckDB从纯嵌入式数据库转变为支持C/S架构的远程数据库。通过Quack，DuckDB实例可以作为HTTP服务器运行，其他DuckDB客户端通过ATTACH 'quack:hostname:port' AS remote_db即可将远程数据库作为本地目录挂载，支持DDL、写入、事务等完整操作。这是DuckDB自诞生以来最大的架构扩展——在保持嵌入式轻量的同时，打开了远程协作和多实例协同的大门。
技术解析
- 零格式转换序列化：Quack使用DuckDB内部序列化格式（与WAL相同），而非Arrow/JSON等中间格式。这意味着嵌套结构、高精度小数、时间间隔等复杂类型在远程传输中零损失、零转换开销。查询在单次往返内完成（握手后），大结果集通过分块FETCH流式返回。
- SQL原生接口：启动服务端仅需
CALL quack_serve('quack:localhost')，客户端仅需ATTACH语句。远程表挂载后与本地表行为完全一致——SELECT、INSERT、CREATE TABLE、事务操作均透明支持。无需学习新的API或协议。 - Token认证与TLS：通过Token认证保护访问，支持反向代理TLS终止。本地连接默认HTTP，远程连接自动升级HTTPS，可通过
DISABLE_SSL配置覆盖。 - 节点身份与可观测性：内置
whoami()函数返回节点名称、提供商、主机名、区域、运行时间、DuckDB版本和平台信息，为多节点管理提供基础。
行业影响
Quack协议打破了嵌入式数据库与C/S数据库的传统边界。此前，SQLite和DuckDB这类嵌入式数据库的”远程访问”需要通过HTTP API或自定义协议，牺牲了SQL表达力和类型完整性。Quack让DuckDB在保持嵌入式部署简单性的同时，获得了C/S架构的协作能力——一个ATTACH语句即可让本地DuckDB查询远程实例的数据，无需ETL、无需数据搬迁。
对DataInfra从业者而言，Quack打开了几个新场景：边缘计算节点间的DuckDB数据共享、Notebook环境直连远端DuckDB数据源、以及轻量级数据服务的快速搭建。但需注意Quack目前仍为Beta，协议和API可能变更。
相关链接
a16z研判：从System of Record到System of Intelligence，数据基建价值正在迁移
事件概述
a16z发布《From “System of Record” to “System of Intelligence”》报告，指出企业软件正在经历根本性转变：CRM等记录系统（System of Record）的数据库锁定优势正在被AI编排层（System of Intelligence）取代为新的价值中心。Salesforce（$1400亿估值）和HubSpot（$90亿估值）过去通过拥有数据库获得粘性——所有销售上下文都积累在CRM中，迁移成本高到”用户是人质而非客户”。但AI代理正在成为销售团队的主要界面，CRM从”目的地”降格为”数据库后端”。
技术解析
- 编排层成为新的引力井：AI代理同时从CRM、日历、共享收件箱、通话录音、Slack、数据丰富API、计费系统、产品遥测中拉取信号，在推理层综合后再行动。竞争壁垒从”数据都在Salesforce”迁移到”工作流和推理都在AI层”。
- 新数据架构栈：基础模型位于核心但不足以独立支撑——真正的应用层由跨数十个连接系统的上下文编排、领域特定的销售/营销逻辑编码、权限与合规处理、企业IT环境集成构成。
- TAM扩张：GTM软件历史仅占GTM总支出的5-10%（其余为人力），AI代理正在创造新的高ROI用例而不减少人头——销售团队以更高比率完成配额，做大蛋糕而非缩小人力预算。
- 机构知识保存：System of Intelligence自动捕获和转移销售代表的机构上下文，当人员离职时自动向继任者传递知识。
行业影响
a16z这篇报告的核心信息对DataInfra从业者至关重要：数据基础设施的价值重心正在从”存储”迁移到”编排”。CRM不会消失——它仍然是被信任的数据库——但价值创造的位置上移到了推理和编排层。
这对数据基建的影响是双重的：一方面，“记录系统”的数据基础设施（数据仓库、数据湖、主数据管理）仍是必要基础，但溢价能力正在下降——就像CRM从”目的地”变为”后端”，数据存储也从”决策中心”变为”AI推理的输入源”。另一方面，“编排系统”的数据基础设施（数据集成平台、AI数据管道、实时特征工程）正在成为新的价值高地。如果你的数据产品还停留在”存得更多、查得更快”，需要认真思考是否要在编排层建立新的竞争力。
相关链接
编者评
第二期的四条动态，与创刊号的三条主线形成了有趣的延续与深化。创刊号提出的”AI原生基础设施”趋势，本期得到了跨厂商验证——Anyscale和OpenSearch在一周内分别推出Agent Skills，“基础设施AI代理化”已非孤例而是共识。Smartsheet的Flink实践则印证了创刊号”流批一体”方向的另一个维度：Flink不仅是流处理引擎，更在成为实时决策基础设施——当过滤、路由、权限判断从消息中间件的慢路径迁移到Flink的快路径，“处理数据”升级为”决策数据”。
DuckDB Quack协议和a16z的研判则指向了一个更深层的趋势：数据基建的边界正在消融。Quack让嵌入式和C/S不再是非此即彼的选择，a16z指出记录系统和智能系统不再是先后关系而是层级关系。数据基建的竞争维度正在从”存储效率”和”查询性能”扩展到”编排能力”和”AI原生性”——未来的数据基建，不只是让数据”存得住、查得快”，更要让AI代理”够得着、用得好”。