构建智能体AI数据科学团队

这篇文章是几个月前开始的旅程中的最新一步。

在我之前的文章中，我探讨了构建智能AI团队而非单个AI智能体的想法；我的智能AI研究团队如下图1所示。我没有要求一个大型语言模型（LLM）解决整个问题，而是创建了具有明确定义职责的专业智能体：项目经理、研究员、技术作家、编辑和评估员协作产生比单个提示所能达到的更高质量的工作。

这些项目教会了我关于智能体协作、结构化输出、智能体契约和可观测性的宝贵经验。每次迭代都使团队更可靠、更容易理解。

但存在一个根本限制。研究团队的输出本质上是主观的。

即使有评估智能体和结构化标准，也很难确定一份报告是否比另一份更好。改进通常依赖于人类判断，这使得了解架构变更是否实际改进了系统或产生了不同结果变得具有挑战性。

我想转向一个每个架构决策都能被客观衡量的领域。

数据科学被证明是完美的环境。

与撰写研究报告不同，机器学习提供了清晰、量化的反馈。每个特征工程决策、每个模型选择、每个参数配置和每个实验都可以使用可重复的指标进行评估，如交叉验证准确率、F1分数、ROC AUC，以及最终的Kaggle排行榜表现。

这完全改变了项目的性质。

在构建了一个生成研究报告的团队之后，我构建了一个智能AI数据科学团队，它可以推理机器学习问题、执行确定性工作流、比较竞争模型、执行超参数调优、分析特征重要性、运行消融实验、评估集成方法、跟踪实验，并最终生成可用于生产的Kaggle提交。

更重要的是，系统的每一次改进现在都可以被衡量。

当我改变架构时，我可以观察交叉验证是否改善。当我引入超参数调优时，我可以衡量对排行榜表现的影响。当我测试特征消融或集成方法时，结果是可重复的而不是主观的。

在本文中，我将介绍系统的架构，解释每个专业智能体和确定性执行器背后的设计决策，并分享我在构建能够解决端到端机器学习问题的自主数据科学团队过程中学到的工程经验。

1、系统架构

从高层次来看，智能AI数据科学团队围绕一个简单的设计原则组织：

推理和执行应该分离。

大型语言模型擅长推理、规划、比较替代方案和提供建议。我在智能AI项目中看到的最大错误之一是要求语言模型做所有事情。LLM被期望分析数据、决定下一步做什么、编写代码、执行代码、评估结果、决定结果是否足够好，并继续迭代直到任务完成。

虽然这对于简单的演示有效，但随着系统的增长，它很快变得难以重现、调试和扩展。相反，我选择了不同的架构。

大型语言模型擅长推理。它们非常擅长理解上下文、比较替代方案、评估权衡和提供建议。它们不负责确定性计算。

训练机器学习模型、计算评估指标、执行交叉验证、生成Kaggle提交文件以及存储实验历史都是确定性任务，给定相同的输入应该总是产生相同的结果。

对于这些确定性任务，我依赖传统的Python执行器。

这导致了简单的职责划分：

• 推理智能体使用LLM分析信息并做出决策。
• 执行执行器执行确定性的机器学习操作。
• 共享记录允许每个组件通过结构化契约而非自由文本进行通信。

最后一个设计决策被证明是项目中最重要的决策之一。

每个阶段不是在组件之间传递自然语言，而是产生一个结构化记录，成为下一个组件的输入。这些记录构成了组件之间的显式契约，使工作流可重现、模块化且易于扩展。

完整架构如下图2所示。

请注意，工作流在推理和执行之间交替。推理智能体决定下一步应该发生什么。执行器决定实际发生什么。

这种分离允许LLM专注于决策，同时将数值计算、模型训练、实验跟踪和可重复性留给确定性Python代码。

随着工作流的发展，出现了另一个有用的抽象：集中的模型工厂。每个组件不是在多个执行器内嵌入模型构建逻辑，而是通过共享工厂请求模型。这确保了超参数、预处理管道和模型定义在整个工作流中保持一致，同时使得引入新算法而无需修改现有执行器变得简单。

随着项目的发展，这种架构使得引入新功能变得非常容易——包括超参数调优、特征重要性分析、特征消融研究、集成学习、实验持久化、仪表板和集中的模型工厂——而无需更改整体工作流。

2、可观测性作为一等设计原则

从之前的智能AI项目中直接吸取的一个教训是，可观测性不能是事后才考虑的事情。下图3显示了智能AI数据科学团队跟踪的一部分。

随着专业智能体数量的增加，理解每个智能体在做什么与最终的机器学习结果同样重要。

系统中的每个推理智能体和执行器都使用Langfuse进行检测。每次执行都会产生完整的跟踪，显示调用了哪些组件、它们之间交换的提示和结构化输出、令牌使用情况、执行顺序和整体工作流成本。

这提供了两个重要能力：

• 首先，它使调试变得极其容易。如果智能体做出错误的建议或产生意外的结构化记录，我可以检查产生此结果的确切推理路径。
• 其次，它允许我衡量整个工作流的操作成本。每次运行记录输入令牌、输出令牌、估计的API成本和每个智能体的使用统计，使得不仅可以评估模型性能，还可以评估达到该结果的计算成本。

实际上，我同时优化了两个不同的系统：

• 机器学习管道，通过验证指标和Kaggle分数衡量。
• 智能AI工作本身，通过跟踪、延迟、令牌消耗和执行成本衡量。

可观测性将项目从一组AI提示转变为可以监控、分析和持续改进的工程系统。

3、从研究团队到数据科学团队

尽管应用程序完全改变，但大部分原始架构保持不变。

我在之前文章中介绍的研究团队和数据科学团队共享相同的基本理念：

• 专业的推理智能体
• 结构化输出
• 组件之间的显式契约
• 确定性执行
• 端到端的可观测性

改变的不是架构。而是领域。

原始研究团队旨在通过协调多个专业智能体来回答开放性问题。项目经理将问题分解为更小的研究任务，研究员使用外部工具收集信息，技术作家将发现组装成报告，编辑提高清晰度和一致性，评估智能体评估最终结果的质量。

该架构对于知识工作非常有效。

然而，它也暴露了一个重要限制。

研究质量本质上是主观的。

即使有结构化标准和评估智能体，也很少有单一的"正确"答案。一份报告可能更全面，另一份可能更简洁，还有一份可能更有说服力。架构改进通常难以验证，因为评估本身依赖于人类判断。

机器学习呈现了一个根本不同的优化问题。

我们不是问一份报告是否比另一份更好，而是可以问客观的问题：

• 交叉验证准确率是否提高？
• 模型是否更好地泛化？
• 超参数调优是否优于基线？
• 移除特征是否提高了预测性能？
• 集成方法是否优于最佳单个模型？
• Kaggle排行榜分数是否增加？

每个架构决策现在都有可衡量的后果。

这改变了智能体的角色。

每个智能体不是协调研究活动，而是负责推理机器学习生命周期的一个阶段：

这种转变不仅仅是重命名智能体。输出变得更加结构化。

每个智能体不再为另一个智能体现在生成段落文本，而是现在产生一个定义明确的记录来描述其建议。这些记录充当推理智能体和确定性执行器之间的契约，使整个工作流可重现且明显更容易调试。

这种演变也改变了我对大型语言模型角色的看法。在研究团队中，LLM生成主要工件：最终报告。在数据科学团队中，LLM不再生成最终交付物。

相反，它充当工程顾问。它分析问题、推荐特征工程策略、提出候选模型、评估竞争方法，并决定接下来执行哪些实验。然后传统Python代码确定性地执行这些决策。

这一区别被证明是项目中最重要的架构经验之一。

语言模型进行推理。

软件系统执行。

通过分离这些职责，我获得了在早期研究项目中难以实现的能力：使用客观证据而非主观判断来衡量、重现和持续改进工作流的每个部分。

4、端到端工作流

有了架构，让我们跟踪一个机器学习问题如何通过智能AI数据科学团队。

工作流在机器学习模型训练之前很久就开始了。系统的第一个责任是理解问题本身。

问题构架智能体接收竞赛描述并确定任务的基本特征：

• 预测目标是什么？
• 这是分类还是回归问题？
• 应该优化哪个评估指标？
• 成功的解决方案是什么？

系统不是立即编写Python代码，而是首先开发对其试图解决的问题的理解。下图4显示了问题构架记录。

这种结构化理解成为数据分析智能体的输入。

使用数据集元数据和探索性统计，此智能体识别潜在问题和机会，包括缺失值、分类变量、特征分布、可能的数据泄露以及特征工程的机会。

特征工程智能体然后推理如何改进数据集。

它不是直接修改数据，而是产生一个结构化规范来描述应执行的转换。这些转换和其他字段如下图5所示。相应的执行器确定性地应用这些转换，确保每次运行保持可重现。

创建工程数据集后，工作流进入模型开发阶段。

建模智能体推荐适合该问题的候选算法集合。系统不是立即选择单个模型，而是训练几个竞争方法，包括逻辑回归、随机森林、梯度提升和额外树。

每个候选模型都使用验证分割和分层交叉验证进行评估。下图6显示了部分交叉验证排行榜。

此时，另一个推理智能体进入工作流。

模型评估智能体审查定量结果并确定哪个模型应该继续。智能体不是选择最高的单个验证分数，而是考虑跨折的一致性、模型稳定性和泛化的可能性。其输出的部分视图如下图7所示。

选择模型后，执行一系列确定性优化阶段。

工作流执行：

• 使用网格搜索进行超参数调优
• 特征重要性分析
• 特征消融研究
• 集成评估

每个实验都自动记录，允许系统使用客观性能指标而非直觉来比较架构决策。

最后，使用完整标记数据集重新训练最佳性能模型，然后为Kaggle测试集生成预测。

工作流通过创建格式正确的提交文件、在持久历史中记录实验、更新结果仪表板以及捕获整个运行的完整可观测性跟踪、令牌使用情况和执行成本来结束。

当管道完成时，系统不仅生成了预测——它还记录了导致这些预测的每个重要工程决策。这种能力最终成为项目最大的优势之一。

5、组件之间的结构化契约

从我之前的智能AI项目中最重要的架构经验之一是结构化契约的价值。

在研究团队的最早版本中，智能体主要通过自然语言进行通信。虽然这种方法对于简单的工作流有效，但随着系统的增长，可观测性很快揭示了这些交互变得多么脆弱。智能体输出中的微小变化可能使下游组件更难解释、调试和评估。

正如我在之前文章中描述的，引入结构化输出和智能体之间的显式契约使工作流明显更可靠。每个智能体不是交换自由格式文本，而是产生一个定义明确的记录，以一致格式描述其建议。

智能AI数据科学团队直接建立在该架构演变之上。

每个推理智能体产生一个结构化记录作为其主要输出，允许下游组件使用结构化数据而不是解释自由格式文本。此记录充当智能体和确定性执行器之间的显式契约。工作流的每个阶段不是要求下游组件解释段落文本，而是接收定义明确的输入并产生同样定义明确的输出。

例如，不是要求特征工程执行器解释描述可能转换的段落，而是特征工程智能体返回一个结构化对象，指定应应用哪些转换。

同样，模型评估智能体不只是解释为什么一个模型似乎比另一个更好。它产生一个评估记录，包括推荐的模型、该推荐的理由以及模型是否准备好进行超参数调优。

简化的版本如下：

问题构架智能体
        │
        ▼
问题构架记录
        │
        ▼
数据分析智能体
        │
        ▼
数据分析记录
        │
        ▼
特征工程智能体
        │
        ▼
特征工程记录
        │
        ▼
特征工程执行器
        │
        ▼
工程数据集
        │
        ▼
模型训练执行器
        │
        ▼
模型训练记录
        │
        ▼
交叉验证执行器
        │
        ▼
交叉验证记录
        │
        ▼
模型评估智能体
        │
        ▼
评估记录

每个组件确切知道它应该接收什么信息以及它应该产生什么信息。例如，问题构架记录包含：

{'competition_name': 'titanic',
  'problem_type': 'binary_classification',
  'prediction_target': 'Survived',
  'evaluation_metric': 'accuracy',
  'submission_columns': ['PassengerId', 'Survived'],
  'success_criteria': 'Maximize accuracy of survival predictions on test set',
}

这个看似简单的决定有几个重要后果。

首先，工作流变得更容易调试。如果执行器产生意外结果，我可以检查相应的记录，而不是搜索提示或对话历史。

其次，架构变得高度模块化。因为每个组件通过定义明确的契约进行通信，可以在不更改系统其余部分的情况下添加新的智能体和执行器。

第三，工作流明显变得更可重现。每个智能体执行的推理保存为结构化数据，支持检查、重放和比较跨实验的决策。

最后，结构化契约大大简化了可观测性。每个记录都成为工作流中的自然检查点，使得跟踪机器学习项目从问题定义到最终Kaggle提交的演变变得简单。

回顾过去，这个架构决策的影响比任何单个提示改进都要大得多。提示总是可以改进的，但组件之间的清晰接口才是使复杂智能体系统在持续增长时可维护的关键。

6、实验和持续改进

构建智能AI数据科学团队的第一版本只是开始。

真正的目标是创建一个能够通过系统实验而非临时试验和错误来自我改进的系统。

工作流的每次执行都会生成完整的实验记录，包含：

• 评估智能体选择的模型
• 验证和交叉验证指标
• 超参数调优结果
• 特征重要性分析（如下图8所示）

• 特征消融结果（如下图9所示）

• 集成评估
• Kaggle提交信息
• 公共排行榜分数
• 时间戳和实验元数据

系统不是将每次Kaggle提交视为孤立的尝试，而是维护持久的实验历史，记录每个架构变更及其验证指标、排行榜表现和实验上下文。这允许工作流的每次迭代被客观评估并与之前的方法进行比较。对于泰坦尼克号竞赛，进展如下：

每个实验回答了一个特定的工程问题：

• 梯度提升是否比逻辑回归泛化更好？
• 超参数调优是否改善了交叉验证表现？
• 移除工程特征是否改善了模型？
• 集成方法是否优于最强的单个模型？

有些实验提高了性能。

其他实验表明，看似合理的想法——比如用软投票集成替换调优后的梯度提升模型——实际上降低了预测准确性。

这些"负面"结果与成功的实验一样有价值。

每个架构决策都成为具有可衡量结果的实验，而不是依赖直觉。

这个架构的一个有趣方面是，它自然创造了许多人现在称为循环工程的东西。系统不是执行一次工作流然后停止，而是持续将每次实验的结果反馈到工程过程的下一次迭代中。验证指标、交叉验证结果、特征消融研究、超参数搜索、排行榜分数和实验历史都成为指导未来决策的输入。

换句话说，工作流不只是自动化机器学习任务——它创建了一个可衡量的反馈循环，允许架构本身随时间演变。

虽然当前实现仍然依赖人类审查结果并启动下一个实验，但底层循环已经存在。扩展系统以便智能体根据先前结果自动提出和执行下一个实验是自然的下一步。

这种哲学从根本上改变了我构建智能体系统的方法。

我不会问提示是否"感觉更好"，而是可以问新功能是否可衡量地提高了模型性能、降低了执行成本或增加了可重现性。

这个项目的一个意外结果是意识到软件架构本身变得可衡量。对智能体、执行器或工作流的每次更改都可以使用验证指标、实验历史、执行跟踪和操作成本客观评估，而不仅仅是直觉。

该项目成为了由证据驱动而非由直觉迭代驱动的工程过程。

7、衡量AI团队

这个项目最有趣的教训之一是意识到智能AI系统引入了第二个优化问题。

在传统机器学习中，工程师主要关注提高预测性能。模型使用验证准确率、交叉验证分数、F1、ROC AUC等指标进行评估，最终是排行榜表现。

智能AI工作流需要另一层衡量。仅仅问模型是否改进已经不够了。我们还应该问AI团队本身是否变得更高效、更可靠且更易操作。

这意味着在机器学习结果之外衡量工程过程。

智能AI数据科学团队在每次工作流执行期间捕获操作指标，包括：

• 输入、输出和总令牌消耗
• 估计的API成本
• 每个智能体的令牌使用
• 智能体调用次数
• 完整执行跟踪
• 持久实验历史

这些指标共同使得不仅可以优化预测质量，还可以优化AI工作流本身的效率。

仪表板（如下图10所示）将这些不同维度汇总到单一视图中。

一方面，它总结了机器学习性能，包括验证准确率、超参数调优结果、特征重要性分析、特征消融实验、集成评估、实验历史和Kaggle排行榜表现。另一方面，它报告操作指标，如总令牌消耗、每个智能体使用统计和估计执行成本（图11）。

虽然仪表板提供了每次工作流执行的高级摘要，但可观测性使得工程过程本身可以详细检查。图12显示了智能AI数据科学团队的部分Langfuse跟踪，包括执行顺序、智能体交互、令牌使用情况以及特征工程智能体在工作流一个阶段产生的推理。

这种架构的一个有趣结果是系统的三个不同层变得可衡量。

机器学习性能

• 验证准确率
• 交叉验证
• F1分数
• ROC AUC
• Kaggle排行榜分数

AI工作流性能

• 令牌使用
• API成本
• 执行时间线
• 智能体交互
• Langfuse跟踪

架构演进

• 实验历史
• 结构化契约
• 特征工程实验
• 超参数调优
• 循环工程

这被证明是项目最有价值的结果之一。

我们不是依靠直觉来判断系统是否在改进，而是工作流的几乎每个方面都变得可衡量。模型质量、操作效率甚至架构决策都可以使用客观证据进行评估。

回顾过去，我认为这就是智能AI开始类似传统软件工程的地方。我们不再构建提示。我们正在工程化能够推理、执行、衡量自身性能并通过证据持续改进的系统。

8、学到的工程经验

构建智能AI数据科学团队改变了我对设计AI系统的几个假设。

一些最有价值的经验与提示语言模型关系不大。相反，它们来自将熟悉的软件工程原则应用于智能AI。

8.1 专业化比泛化扩展性更好

早期的智能AI示例通常依赖于负责解决整个问题的单个智能体。

这种方法对于简单的演示有效，但随着工作流变得更复杂，维护变得越来越困难。

在专业智能体之间划分职责使系统更容易推理、更容易测试，并且明显更容易扩展。每个智能体可以专注于一个决策，而确定性执行器处理底层计算。

8.2 推理和执行应该保持分离

这成为了项目的核心架构原则。

大型语言模型擅长分析信息、比较替代方案和提供建议。

传统软件更擅长确定性计算。

保持这些职责分离产生了既智能又可重现的工作流。

8.3 结构化契约比更长的提示更有价值

与我早期项目相比，最大的改进之一来自将组件之间的每次交互视为显式软件契约。

智能体不是交换段落文本，而是交换结构化记录。

这个单一决定简化了调试、支持模块化开发，并使工作流更容易随时间演变。

8.4 可观测性是必需品，不是增强功能

随着智能体数量的增加，可观测性变得至关重要。

没有执行跟踪、令牌使用、结构化记录和工作流指标，理解系统为何如此行为将极其困难。

可观测性将项目从AI演示转变为工程系统。

8.5 客观反馈加速架构改进

也许最重要的教训是选择了一个可以客观衡量改进的领域。

与研究报告不同，机器学习提供了即时的量化反馈。

每个架构更改都可以使用交叉验证指标、Kaggle排行榜分数、实验历史和操作测量进行评估。

这个反馈循环允许架构本身通过证据而非直觉进行改进。

回顾过去，我认为这个项目产生的最重要工件不是Kaggle提交。

而是架构。

机器学习竞赛只是提供了一个环境，让该架构可以被测试、衡量和完善。

9、下一步发展方向

虽然智能AI数据科学团队已经可以解决端到端的机器学习问题，但我将此项目视为开始而非最终版本。

构建系统揭示了在保持相同专业化、结构化契约、确定性执行和可观测性设计原则的同时扩展架构的几个机会。

我特别感兴趣的一个领域是扩展团队的推理能力。

目前，模型评估智能体根据验证和交叉验证结果推荐哪个模型应该继续。未来的版本可以推理可解释性、公平性、推理延迟、模型复杂性或操作成本，将模型选择转变为真正的多目标优化问题。

另一个有前途的方向是用贝叶斯优化或Optuna等更高效的优化技术替代详尽的网格搜索。团队可以智能地探索搜索空间，同时减少计算成本，而不是评估每个参数组合。

特征工程是另一个有显著增长空间的领域。当前工作流依赖于特征工程智能体提出转换，但未来的版本可以结合自动特征生成、特征选择和SHAP等可解释性工具，以更好地理解为什么特定模型优于其他模型。

这种架构的另一个自然演变是完全关闭工程循环。目前，每个实验与其推理、评估和结果一起记录。未来的版本可以允许智能体自身分析该历史、制定新假设、提出下一个实验、执行它并自主评估结果。那时，系统将超越执行机器学习工作流，开始参与自身的持续改进。

因为每个实验都与其推理、评估和结果一起存储，实验历史可以成为未来智能体在提出建议之前咨询的知识库。团队可以检索类似实验、比较以前的架构决策并将成功的策略适应到新数据集，而不是为每个竞赛从头开始。

当前工作流在很大程度上也是顺序的。许多阶段最终可以并行执行。在模型评估智能体比较结果并选择最佳性能方法之前，可以同时探索多种特征工程策略、候选模型或超参数搜索。

最后，我相信这种架构远远超出了Kaggle竞赛。

相同的专业推理智能体、确定性执行器、结构化契约、可观测性和实验跟踪模式可以应用于推荐系统、预测、异常检测、MLOps管道、科学计算甚至自主软件工程工作流。

对我来说，这是这个项目最令人兴奋的结果。目标从来不是构建更好的泰坦尼克号分类器。目标是探索如何设计、衡量和持续改进自主工程团队。泰坦尼克号竞赛只是这些想法可以被测试的实验室。

随着智能AI的持续发展，我怀疑最强大的系统不会围绕单个越来越强大的模型构建。它们将由通过明确定义的接口协作、从客观反馈中持续学习并结合语言模型优势与传统软件工程可靠性的专业组件集合构建。

这是我兴奋地继续探索的方向。

10、结束语

这个项目始于一个简单的问题：

如果我们不是构建执行具有主观结果任务的智能AI团队，而是构建整个AI工程团队会怎样？

在四篇文章的过程中，这个问题从研究原型演变为能够解决端到端机器学习问题的自主数据科学系统。

在这个过程中，我了解到最重要的改进不是来自编写更长的提示或切换到更大的模型。

它们来自将永恒的软件工程原则应用于智能AI：

• 专业化优于泛化
• 显式契约优于隐式假设
• 确定性执行优于概率计算
• 可观测性优于黑盒工作流
• 客观反馈优于主观评估

这些原则使系统能够逐步变得更强，同时保持可理解、可重现且易于扩展。

虽然当前实现专注于Kaggle竞赛，但我相信底层架构具有更广泛的适用性。

随着AI系统变得越来越自主，我希望我们将花更少时间问*"如何构建更好的提示？"，花更多时间问"如何工程化更好的AI系统？"*

对我来说，这是这个项目的真正目的。Kaggle竞赛不是目的地。它是试验场。真正的目标是探索自主工程团队如何推理、协作、执行、衡量自身性能并通过客观反馈持续改进。

原文链接：Building an Agentic AI Data Science Team with LLMs: A Multi-Agent Machine Learning Workflow

汇智网翻译整理，转载请标明出处