Sign in Subscribe
Deep Research

数据科学中的 Agentic AI：实践模式、趋势与应用落地（以及它最常坏在哪里）

Kaizhi Tang

• 7 min read

执行摘要（3–5 条）

  • “Agentic” 不是某个模型的名字，而是一种系统形态：把模型放进“观察 → 规划 → 行动 → 验证 → 记忆”的闭环里。
  • 在数据科学里，最有价值的不是“更会写”，而是**“分析 + 可执行 + 有护栏”**：能跑 SQL/代码、能产出可复现的结果，并且强制验证。
  • 工程实现正在收敛到几类原语：结构化工具调用、图/状态机编排（而不是线性链）、检索式记忆、以及评估与回放。
  • 失败模式高度可预测：隐性数据泄露、可复现性漂移、成本/延迟失控、以及“看起来像成功”的自嗨式结论。
  • 未来 12–24 个月的胜负手是 AgentOps（生产化运营）：权限、审计、离线评估、Human-in-the-loop 作为默认而不是补丁。

1) 在数据科学工作流里，“代理化”到底意味着什么

数据科学本来就是多步程序：找数据、清洗、探索、建模、评估、解释、交付（有时还要上线与监控）。Agentic AI 的关键是：系统能够自主决定下一步做什么，并调用工具把任务推进下去。

一个可操作的区分方式：

  • 非代理助手：你问它才写一段代码/解释。
  • 代理系统：它会拆解目标、调用 SQL/Python/BI/API/工单系统等工具、检查结果并迭代；遇到不确定性时能安全失败。

落地时，“agent” 几乎从来不是一次模型调用，而是由多个角色/模块组成：

  • 规划器（Planner）：把目标拆成步骤
  • 执行器（Executor）：运行工具（SQL、Python、Notebook、API）
  • 验证器（Critic/Verifier）：测试、数据校验、常识检查
  • 记忆/检索（Memory/Retrieval）：项目上下文、schema、历史决策
  • 策略/权限层（Policy）：允许做什么、写入需要谁批准

这也是为什么代理落地更像“生产工程问题”，而不是“提示词问题”。

2) 真正在团队里出现的核心架构模式

模式 A：ReAct 风格的“思考 + 行动”循环

ReAct 的核心思想很朴素也很耐用：边推理边行动，而不是“想完一次性输出”。映射到 DS 就是：

  • 看 schema → 跑 sample query → 修正 query → 做 transform → 算指标 → 画图 → 写结论

这是最小代理闭环，很多探索型任务到这里就够用了。

模式 B：图/状态机编排，而不是线性链

真实分析充满分支：

  • 缺失值超阈值 → 插补 or 丢弃
  • 怀疑泄露 → 改 split 方案
  • 指标不达标 → 做特征工程或换模型

因此越来越多团队用**图（状态 + 转移）**来表达流程。好处是可调试、可回放：你能追踪“为什么走了这条分支”。

模式 C：Notebook / 代码的“执行优先”代理

对 DS 来说，最大价值不是把 Notebook 写得像样，而是：真的跑起来。

能写 cell、执行、看异常、修补、再跑的代理，价值远高于只会生成代码但不执行的助手。

前提是：必须做沙箱与权限隔离（文件系统、网络、密钥）。

模式 D：检索式长期记忆（而不是无限加上下文）

项目一长，你不可能把所有内容塞进 prompt。可行做法是把：

  • 数据集文档与 schema
  • 决策记录（为何排除某特征/为何否决某实验）
  • 可复用代码模式

以可版本化形式存储，并在运行时检索相关片段。

3) Agentic AI 今天最能帮到哪几块

3.1 数据发现与抽取

代理可以：

  • 搜索数据目录与内部文档
  • 提议候选表与 join
  • 生成带约束的 SQL（limit、禁止 PII 列）
  • 从观察到的列生成数据字典

最佳实践：把代理当“草稿引擎”，并强制验证（行数、唯一性、join 基数常识检查）。

3.2 清洗与校验

清洗最重复，但也最危险。更成熟的代理会：

  • 提议 transform
  • 跑数据校验（如 Great Expectations/dbt tests/自定义断言）
  • 输出 before/after 的量化差异（缺失率、分布变化）

如果不能量化差异，就不该让代理应用改动。

3.3 基线建模与实验脚手架

代理可以快速搭建：

  • split
  • baseline 模型
  • 指标计算
  • 实验记录元数据

但不该让代理“自己决定最终建模策略”。正确交互是：代理提案、人类选择，然后代理执行并写清假设与限制。

3.4 报告与叙事包装

代理在末端产物上常常更稳：

  • 总结结果
  • 写 executive brief
  • 补齐“风险与假设”
  • 生成 slide bullet

依然需要审核，但相较于直接改数据/改系统，风险更可控。

3.5 MLOps 监控（意外地契合）

监控是连续、规则驱动的，非常适合代理：

  • 监听漂移告警
  • 按 runbook 做初步排查
  • 自动开工单并附上下文
  • 提议缓解方案

成熟组织会把这类代理限制在预定义剧本内运行。

4) 正在发生的趋势：哪些值得在 2026 重点盯

趋势 1：从“框架”到“平台”

越来越多能力从 demo 走向平台化：权限、审计、评估、工具注册表……模型变成一个组件，而不是全部。

趋势 2：多代理分工开始可用

用小团队替代一个全能代理：

  • 数据代理（SQL + catalog）
  • 建模代理（训练 + 指标）
  • QA 代理（测试 + 校验）
  • 写作代理（报告包装）

分工能降低上下文拥塞，也更容易评估。

趋势 3：评估与回放成为硬需求

必须回答：

  • 能否复现一个已知 notebook？
  • 是否通过不变量/断言？
  • 乱编列名的概率是多少？

否则你是在做 show，而不是在做系统。

5) 最常见的失败模式（以及怎么避免）

5.1 可复现性漂移

代理“顺手修”代码，很容易导致：随机种子变了、数据快照变了、预处理版本变了。

对策：确定性配置、环境锁定、产物可追踪。

5.2 隐性数据泄露与隐私违规

代理很擅长“把能 join 的都 join 了”，这正是 PII 泄露的常见起点。

对策：列级白名单、SQL lint、脱敏层、写入/敏感操作审批门。

5.3 伪自信：把“看起来对”当“真的对”

对策：成功必须是机器可验证的（测试通过、指标可复算、链接到可追溯的 artifacts）。

5.4 成本与延迟失控

代理闭环会自我发散。

对策：预算、step limit、缓存、以及不确定性高时及时停。

6) 给数据科学团队的务实落地路线

  1. 先做 agent-assisted，不要一上来 agent-owned；写入必须审批。
  2. 工具调用必须结构化并记录日志（每条查询、每次写文件、每次 API）。
  3. 强制验证：没有测试/校验就不允许交付。
  4. 做一个小型离线评估：每周回放 10–20 个 canonical 任务，追踪成功率与成本。
  5. 把它当生产系统：权限、可观测性、事故响应。

References