你的AI是一个罐子里的“大脑”。一种新架构赋予了它“双手”。

我在Abbot Kinney的Intelligentsia Coffee，小酌着一杯价格高得离谱的单一产地手冲咖啡，欣赏着整个过程犹如一场戏剧。咖啡师，一个专注于执行的典范，精确到十分之一克地称量咖啡豆。他用数字PID控制器监测水温。他用细嘴壶精确地螺旋式注水，让咖啡粉“闷蒸”。这是一个完美的手工数据管道，将原始输入（咖啡豆、水）转化为精炼的输出（带有佛手柑和一丝“后悔”味道的咖啡）。整个过程耗时四分钟。

对于一杯咖啡来说，这是一个美妙的系统。但如果你需要在接下来的一小时内测试10,000种不同的手冲技术呢？略微不同的水温、研磨粒度、注水模式、闷蒸时间——对一杯全球最优化咖啡进行详尽的搜索。咖啡师，尽管技艺高超，却无法扩展。他的工作流本质上是单线程的。他无法批量编译他的动作，也无法在并行化的Rust后端上运行它们。

这正是我与每个商业品牌交流时面临的精确问题。你雇佣了数据科学家。你让他们访问强大的LLM（大型语言模型），这些模型可以充当自主代理（autonomous agents）。这些代理非常出色；它们就像一千名技艺精湛的咖啡师，不断生成预测客户流失、优化库存和个性化用户体验的新颖想法。但你的基础设施却是那个单一的咖啡师，一次只执行一项任务。你的AI是一个罐子里的“大脑”（brain in a jar），拥有令人难以置信的构思能力，却没有“双手”来大规模地实际完成工作。

本周刚刚发布在arXiv上的一篇新论文《Stratum: A System Infrastructure for Massive Agent-Centric ML》，是我见过的第一个真正解决这一危机的架构蓝图 [3, 8]。它并非旨在构建一个更智能的代理；而是要为代理提供一个工作工厂。它报告称，对于复杂的机器学习任务，速度提升了惊人的16.6倍，这是通过解决所有人都在忽视的、不那么光鲜的基础系统问题来实现的 [10]。对于商业架构师而言，这是今年最重要的论文。

什么是“代理式管道搜索”（Agentic Pipeline Search）？

要理解Stratum为何如此重要，你首先必须理解它所构建的新工作负载：代理式管道搜索 [3]。这并非你的团队目前正在进行的机器学习。你当前的过程可能是线性的，且由人工门控。数据科学家提出假设，提取数据，在Jupyter notebook中清理数据，构建模型，测试并部署。这个过程可能耗时数周，甚至数月。这就是“单一手冲咖啡”。

代理式管道搜索根本不同。它描述了一种情境，其中一个自主或半自主的“MLE Agent”（机器学习工程代理）驱动整个过程 [8]。Stratum论文使用了一个例子：从一个充满CSV文件、交易日志、非结构化文本和图像的杂乱数据湖中构建客户流失模型——这对于任何DTC品牌来说，都是一个令人痛苦的熟悉场景 [8, 9]。

在这个新范式中，代理执行大规模的探索性搜索，并行执行数千个管道：

1. 数据画像（Data Profiling）： 代理首先自动对源数据进行画像。它不仅查看列类型；它还会对数据进行采样，以了解分布、基数、文本字段中词汇的多样性，以及看似不相关数据源之间的关联 [9]。
2. 假设生成（Hypothesis Generation）： armed with this profile, the agent (likely an LLM) searches the web, academic papers, and internal documentation for promising modeling approaches. It might decide to try a simple logistic regression, a gradient-boosted tree, and a more complex multimodal model that combines tabular transaction data with features extracted from product images [3].
3. 管道合成（Pipeline Synthesis）： 对于每个假设，代理生成数百甚至数千种管道变体。它使用Pandas和scikit-learn等标准库编写Python代码，处理特征工程、缩放、模型训练和超参数调优 [9]。它尝试不同的方式来处理缺失值、编码分类变量和构建交叉验证过程。
4. 迭代优化与集成（Iterative Refinement & Ensembling）： 代理评估这数千个管道的性能，识别最有希望的管道，然后进行迭代。它可能会将表现最佳的模型组合成一个集成模型，并根据经验结果不断优化其方法 [8]。

这不仅仅是自动化；它是一种有导向的、大规模并行搜索，覆盖了所有可能的解决方案空间。“智能”的部分不仅仅是最终模型；它是在寻找模型的过程。问题在于，我们提供给数据科学家的工具是为单次、人驱动的工作流程而构建的。运行单个Python脚本很慢。运行一万个脚本是不可能的。这造成了一个执行瓶颈，完全扼杀了AI代理的创造潜力。大脑在梦想，但身体无法行动。

16.6倍的速度提升：解构Stratum的架构

Stratum论文的精妙之处不在于新的LLM或神奇的算法。它是一个系统架构的洞察力，事后看来似乎显而易见：将代理的推理与管道的执行解耦。LLM擅长规划（编写Python代码），但在高效执行方面表现不佳。Python解释器本身，特别是对于数据任务，与低级语言相比，速度是出了名的慢 [9]。

Stratum引入了一个系统，充当中介，一个针对代理工作订单的高效工厂经理。其过程如下：

我们来分解一下这里发生了什么。

1. 解耦生成（Decoupled Generation）： MLE Agent，它可能是一个像GPT-4这样的复杂LLM，或者是专门模型，做它最擅长的事情：思考和编写代码。它使用每个人都熟悉的Pandas和scikit-learn等库生成数千个潜在的ML管道作为Python脚本。它不执行它们 [3]。

2. 批量编译到执行图（Batch Compilation to Execution Graphs）： Stratum并非逐个运行这些脚本，而是将它们作为批次提交给Stratum系统。Stratum然后解析所有这些管道，并将它们编译成一个单一的、优化的执行图。它识别不同管道中的常见操作（例如，加载相同的CSV文件，应用相同的特征转换），并确保它们只运行一次。这是与典型Python执行的隔离的、解释性的本质的根本性背离 [9]。

3. 在异构后端上优化执行（Optimized Execution on Heterogeneous Backends）： 这就是主要速度提升的来源。编译后的图在各种后端上执行。简单任务可以在标准Python工作器上运行。但对于性能关键的操作，Stratum可以将工作分派给一个新颖的、高性能的Rust运行时，该运行时专为处理这类数据密集型ML任务而设计 [8]。这使得系统能够规避Python在数值计算和数据操作方面的限制，从而在初步实验中实现了报告的16.6倍加速 [10]。

关键在于系统能预先了解整个工作负载，从而实现全局优化，这在孤立执行脚本时是不可能的。这就像1,000个厨师各自在自己的厨房里做一道菜，对比一个高效运转的餐厅厨房，在那里准备工作是集中的，并且各个工位都针对特定任务进行了优化。

为什么你当前的ML堆栈是一个负债

阅读Stratum论文后，很明显，大多数商业技术堆栈对于这种新现实来说是多么力不从心。它们几乎都是围绕“单一手冲咖啡”的执行模型设计的。

考虑一下典型的企业ML工作流程。它可能涉及Airflow或dbt用于编排，Databricks或Snowflake环境用于数据仓库，以及数据科学家用于模型原型设计的Jupyter notebooks集合。这些组件中的每一个，虽然对其预期目的而言功能强大，但在代理式世界中都成为了瓶颈。

• Jupyter Notebooks： 数据探索的默认工具是一个交互式的、单用户环境。它非常适合原型设计，但对于运行数千个自动化、高吞吐量的实验来说，它绝对糟糕透顶。它鼓励一种人工参与（human-in-the-loop）的过程，这种过程根本无法扩展。
• 编排工具（例如 Airflow）： 这些工具旨在按计划运行定义明确的有向无环图（DAG），例如每日ETL作业或每周重新训练生产模型。它们并非为“高度探索性行为”和“对结构和超参数的引导式搜索”而设计，而这正是代理式管道搜索的特征 [9]。代理的工作流程不是静态的DAG；它是一个动态的、分支的可能性之树。
• Text2SQL和关系优化器： 许多研究都集中在使用LLM生成SQL查询（Text2SQL） [9]。虽然有用，但这解决了一个完全不同的问题。关系数据库针对结构化查询进行了优化，而不是涉及特征工程、模型训练和验证的复杂、多阶段管道，这些定义了现代机器学习。正如Stratum的作者所指出的，来自关系世界的优化无法很好地转移到ML工作负载 [9]。

你的堆栈是为可预测的、计划性作业的世界而构建的。代理式商务（Agentic commerce）是一个大规模、不可预测、探索性搜索的世界。如果没有像Stratum这样的系统来弥合差距，你就像试图用城市公交时刻表来导航F1赛车。 “高级Python API与低级优化潜力之间日益增长的不匹配”不再是一个理论上的学术问题；它是任何希望通过AI竞争的品牌的主要架构负债 [9]。

正面对决：Stratum vs. 现有方案

Stratum的架构愿景，通过与现有和竞争方法的直接比较，能得到最好的理解。这不仅仅是增量改进；它是我们思考机器学习基础设施方式上的一个根本性转变。

这个比较清楚地表明了核心观点：Stratum是唯一明确解决大规模代理式ML所需的系统基础设施的方法。其他方法要么专注于让代理更智能（例如SEA-TS，它非常出色但解决了不同的问题），要么专注于优化问题的狭窄部分（例如Text2SQL）。传统的MLOps堆栈根本不是为这种工作负载而构建的。

Stratum的作者正确地指出，LLM在代理行为方面能力的爆发，已经创造了一个“根本性的系统挑战”[8]。你可以拥有世界上最智能的ML代理，但如果其执行环境迫使它一次运行一个Python脚本，那么它的智能就会被浪费。

这对你的品牌意味着什么：建立一个AI体验实验室

Stratum是一篇具有“早期原型”[10]的研究论文。你今天无法下载并部署它。很容易将其视为学术上的故弄玄虚。但那将是一个灾难性的错误。它所描述的架构模式预示着未来。现在就开始理解这种转变并重新架构的品牌，将在未来两到三年内获得不可逾越的竞争优势。

即时行动并非要拆毁并替换你整个数据堆栈。可操作的步骤是建立一个AI体验实验室。这是一个小而专注的跨职能团队——几位工程师、一位数据科学家、一位产品经理——他们的全部工作就是为未来代理式员工队伍构建沙盒。他们的任务不是下个季度交付一个生产级的客户流失模型。他们的任务是构建Stratum架构的小规模版本，并证明其价值。

你的AI体验实验室蓝图

1. 隔离用例： 从一个有界但有价值的问题开始。不要试图一口吃成个胖子。像论文中提到的客户流失预测是一个完美的例子。特定产品类别的需求预测也是一个不错的选择。目标是一个具有复杂、多模态数据且能从大规模实验中受益的问题。

2. 拥抱解耦原则： 实验室工作的核心应该是构建一个将代理规划与执行分离的系统。让LLM代理生成Python管道作为文本文件或JSON对象。然后，构建一个独立的服务——你的迷你Stratum——来解析这些输出并运行它们。即使没有自定义的Rust后端，仅仅批量并行执行这些脚本，也将比基于notebook的工作流程带来显著的提升。

3. 构建结果数据库： 当你的系统运行这些数千个管道实验时，将结果——代码、超参数和性能指标——存储在一个结构化数据库中。这会创建一个反馈循环。你的代理可以查询这个数据库，以指导其下一批实验，从而创建论文中描述的迭代优化循环 [8]。这就是系统如何随时间学习和改进的方式。

4. 衡量一切： 实验室

• agentic commerce
• commerce AI architecture
• AI experience lab
• agentic pipeline search
• structured data for AI search
• agentic commerce architect