AI 代理如何把数据分析从“数周”压到“数小时”

数据团队最常见的浪费，不是在建模，而是在“找数据、对字段、写样板代码”。在医疗这种数据密度极高的行业，这种浪费会被放大：一个临床问题（比如“糖尿病与高血压患者的共病模式有什么差异？”）往往要先经历表结构摸排、权限申请、代码拼装、数据质量核对，最后才进入真正的统计分析。

我越来越明确的一点是：很多组织并不是缺少数据科学能力，而是缺少“把分析动作自动化”的工作流。这也是我们在「人工智能在科研与创新平台」系列里反复谈的核心：科研与创新不是被算法卡住的，更多时候是被流程卡住的。

AWS 在 2025 年 11 月推出的 Amazon SageMaker Data Agent（SageMaker Unified Studio 内置数据代理），提供了一个很具代表性的“代理式（agentic）AI 自动化工作流”案例：它不只是生成代码，而是能把一个复杂分析请求拆成可执行计划、自动找表、选方法、写 SQL/Python/PySpark、逐步执行并设置人工检查点。医疗场景最难，但方法论却能外溢到任何数据密集型业务——包括很多中小团队。

一句话立场：如果你的分析要花两周才能产出第一个可复现的 notebook，那问题不是你不够聪明，是你的工作流没有自动化。

医疗数据分析为什么总是慢：两类“隐藏成本”

答案先说：慢不是因为计算慢，而是因为“认知导航”和“工程准备”太耗时。

1) 复杂临床数据的“导航成本”

医疗数据不是一张表能搞定。患者、诊断、就诊、用药、免疫、检查、手术……每一类都可能在不同表里，还涉及医学编码体系（ICD 等）、时间线关系（一次就诊前后的诊断、用药窗口）与队列定义规则。

传统方式下，研究人员经常要：

• 先从数据目录里找“可能相关”的表
• 询问数据工程师字段含义与关联方式
• 试错 join 逻辑
• 才能得到一个可信的 cohort（研究队列）

2) 技术准备的“样板代码成本”

即便你知道要做什么，仍然要写大量重复性代码：

• 抽取队列、去重、补缺失
• 计算基线特征（baseline characteristics）
• 选择统计比较方法
• 生成可视化
• 把过程写进可复现的 notebook

医疗研究者往往强在流行病学/生统（这才是关键能力），但不一定愿意花数周当“半个软件工程师”。这就是典型的流程错配。

代理式 AI（Agentic AI）到底替你做了什么？

答案先说：SageMaker Data Agent 的价值不在“写代码更快”，而在“把分析变成可审计的自动化流程”。

原始文章里提到的关键能力，其实可以抽象成三步：

1) 先做计划，再写代码

当你用自然语言提出任务（例如“比较两个队列的共病模式”），数据代理会先输出一个多步骤计划，常见结构很像资深分析师的思考路径：

1. 定义 cohort（纳入/排除标准、时间窗口）
2. 拉取并验证数据（字段检查、缺失值、分布）
3. 进行统计比较（方法选择与假设）
4. 可视化与汇总

这一步的意义是：把隐性的分析思路显性化，并且能在每一步设置人工审核点。

2) 根据你的真实数据环境“找路”

它不是对着模板表名瞎编，而是通过 AWS Glue Data Catalog 理解你账号里实际存在的表与关系。对医疗来说，这意味着它能在 patients、conditions、encounters、procedures 等表之间建立可用的分析路径，而你不需要背 schema。

3) 自动选择合适的执行语言与规模

SageMaker Data Agent 能在 SQL、Python、PySpark 之间切换：

• SQL：更适合高效筛队列、聚合统计
• Python：更适合统计检验、绘图、建模
• PySpark：更适合大规模分布式处理

很多团队慢就慢在“工具选型反复横跳”。代理把这部分决策自动化，你只需要审查结果是否符合业务/科研逻辑。

AWS 案例拆解：从“找表写脚本”到“自然语言驱动的分析工作流”

答案先说：这个案例最有启发的点，是它把一条完整研究路径（预览→建 notebook→队列→比较→生存分析）串成了可复现流水线。

原文用 Synthea 生成合成患者数据（不涉及真实患者隐私），并在 SageMaker Unified Studio 里建立项目与数据表（patients、conditions、immunizations 等）。流程大致如下：

1) 用 SQL 快速预览与校验数据

在正式分析前，先对 conditions 表做 limit 10 预览，确认字段、格式、样例值是否符合预期。看似简单，但这是避免“分析一小时，发现日期字段全是字符串”的关键步骤。

2) 在 notebook 里两种交互：内联提示 vs 代理面板

• 内联提示（Inline assistance）：适合你已经会写代码，只是想让它帮你补齐某个片段或修 bug。
• 代理面板（Agent panel）：适合端到端任务，它会分解步骤、逐步生成并执行。

这两种模式很像“自动驾驶的 L2 与 L3”：你可以随时接管。

3) 任务一：Top 20 条件 + 免疫人群分析

示例提示语类似：

• “Find top 20 conditions and perform a detailed analysis of patients with immunizations suffering from those conditions”

代理会识别涉及的表（conditions、immunizations、patients），生成计划，逐步写入 notebook，并输出可视化（人口学分布、条件流行度、发病时间趋势，最后形成 dashboard）。

更实用的一点是：当步骤执行失败时，可以用 Fix with AI 做纠错，然后继续流水线。这在真实企业里很重要，因为数据不干净、依赖版本不一致是常态。

4) 任务二：队列比较 + Kaplan-Meier 生存分析

当“viral sinusitis（病毒性鼻窦炎）”被识别为高频条件后，示例提示语要求构建男女两队列并做比较与生存分析。代理会输出 cohort demographics 对比图，以及 Kaplan-Meier 曲线等。

这里的启发是：代理不仅能做 ETL 和报表，也能把更偏研究范式的统计流程自动化。对科研平台、临床研究支持团队、以及有实验设计的产品分析都很适用。

把医疗案例迁移到中小团队：你可以直接照搬的 4 个自动化套路

答案先说：不要从“全自动”开始，从“可复现 + 可审计 + 可迭代”开始。

医疗是高难度样板，但同样的模式可以落到更常见的业务场景：增长分析、客服质检、供应链预测、财务对账、实验复盘。下面是我建议中小团队直接套用的 4 个套路。

1) 把“自然语言需求”变成“分步计划”

无论你用的是 SageMaker Data Agent 还是别的代理框架，第一件事都应该是：

• 让 AI 先输出计划（含数据源、口径、验证点）
• 你来确认口径
• 再执行

这一步能减少 80% 的返工，因为返工通常来自“理解偏差”。

2) 设置强制的“数据验证检查点”

建议每个自动化分析都至少包含：

• 行数/唯一键检查（例如用户数、订单数）
• 缺失值比例（尤其是关键指标字段）
• 时间范围与粒度确认（天/周/月）
• 异常值分布（极端值、重复值）

代理式工作流的优势在于：这些检查可以被模板化，变成固定步骤。

3) 让 AI 负责“样板代码”，人负责“口径与解释”

我见过最浪费的组合是：分析师把 70% 时间花在 join 与清洗，最后用 30% 时间写结论。

更合理的分工是：

• AI：抽取、清洗、聚合、绘图、生成可复现 notebook
• 人：定义队列规则、解释因果边界、确认统计方法是否适用、把洞察转成决策

4) 输出物要“可复现”，而不是“只截图”

原文强调把分析记录在 notebook 里，方便验证和审计。中小团队同样需要：

• 每次分析都能从原始数据重跑
• 每个指标口径在代码里有据可查
• 关键结论能被复核

这会直接降低交接成本，尤其适合人员变动频繁的小团队。

安全与合规：自动化越强，治理越要前置

答案先说：代理式 AI 真正能落地的前提，是它必须在既有权限边界内工作。

SageMaker Data Agent 的一个关键设计是：它在你的 AWS 环境内运行，并遵循 IAM 权限与组织的数据边界。这一点对医疗（以及金融、政务）特别关键：

• AI 不能“越权看数据”
• 不能把数据带出边界
• 过程需要可审计（谁运行了什么、读了哪些表）

如果你在搭建自己的 AI 语音助手与自动化工作流，也建议把“权限、日志、数据分级”作为第一期内容，而不是最后补。

你现在就能开始的下一步：用一个小问题做一次端到端自动化

如果你想把这种思路带回自己的团队，我推荐从一个具体、可衡量的任务开始：

• 选一个每周都会做的分析（例如：渠道转化漏斗、复购 cohort、工单分类）
• 用自然语言写清“你想要的结论”和“必须遵守的口径”
• 让代理先生成分步计划
• 每一步加上验证点
• 最终交付可复现 notebook + 一页结论

当你第一次体验到“从需求到可审计结果”的闭环速度，团队对自动化的接受度会明显提高。

医疗案例展示了一个事实：**当 AI 不再只是聊天或写段代码，而是能执行一个受控的分析工作流时，数据生产力会出现阶梯式变化。**接下来值得思考的是——在你的业务里，哪一段重复性数据流程最应该先交给代理？