你有没有遇到过：AI Agent 用 15 分钟重做完一份分析，你却花了两个小时确认，它是不是用了错误的数据表、错误的分母，或一条上周就已经被排除的分析路径？
Agent 会找字段、写 SQL、运行 Notebook、画图，也能把结果整理得很有说服力。但当你追问：“这个结论到底怎么来的？”答案往往散落在聊天记录、被改写过的查询、几个 Notebook cell，以及分析师自己的记忆里。
AI 加快了分析，也让上下文丢失的代价更高。
问题在于，我们仍用为“人一次操作一步”设计的记录方式，管理一个能自主探索、执行、修正和分支的工作者。执行越快，缺少上下文造成的返工也越快。
AI Agent 的工作早已超过写 SQL
早期的分析 AI 更像补全工具：你描述需求，它返回一段 SQL；你自己粘贴到编辑器、执行、查看错误，再回去问下一题。每一步都经过人的手，所以人自然记得刚才发生了什么。
现在的分析 Agent 可以接下一个目标后，自行完成一连串动作：
业务问题
→ 寻找可能的数据表与字段
→ 生成 SQL 或 Python
→ 执行并读取结果
→ 根据错误或异常自动修改
→ 制作图表、摘要与报告
Databricks 的 Genie Code 会规划任务、查找相关资产、执行 Notebook code，并根据 cell output 修正错误。Microsoft Fabric Data Agent 会根据问题、schema、示例和指令生成 SQL、DAX 或 KQL，并显示中间步骤。分析师的角色也随之转变，从逐步操作改为设定目标与审核结果。
dbt Labs 2025 State of Analytics Engineering 的调查也显示，AI 已广泛进入分析开发、代码与文档工作。问题因此从“AI 能不能写”逐渐变成“我们能不能确认它做了什么”。
真正让分析师疲惫的，是重新建立上下文
日常协作最花时间的往往是这些追问：
- 哪一段 SQL 才是最后采用的版本？
- 这张图来自哪一次执行，而不是当前画面上的查询？
- Agent 为什么从数据表 A 改用 B？A 是暂时无法连接，还是已确认不适用？
- 报告中的“活跃用户”使用哪个定义、时间窗和时区？
- 新对话里的 Agent 是否知道某个数据源上周已被排除？
- 一个 JOIN、分母或筛选条件何时被修改，又影响了哪些下游结论？
聊天记录可以证明“讨论过”，却很难标示哪个决定仍然有效。文件版本可以告诉你“文字改过”，却不一定说得出改动对证据链的意义。Notebook 保留 cell，也可能以非线性顺序执行。
研究者在 Data Analysis in the Era of Generative AI 中把分析描述为在问题定义、数据收集、探索、可视化、验证与沟通之间反复迭代的过程。这类工作本来就不是一条直线。Agent 让迭代加快、分支增加，也更容易超出一个人的短期记忆。
为什么软件开发的 Plan → Result 逻辑还不够
软件开发和数据分析都会先规划、执行、产生成果，也都需要版本控制。但两者判断“这条路是否可行”的信号不同。
软件工作当然也有隐藏风险，不过许多失败会留下直接信号：程序无法编译、测试失败、类型不匹配、API 返回错误，或 diff 明确显示行为被改变。当实现成功且验收通过，一条从需求、改动到结果的版本链，通常能保存相当多关键信息。
数据分析最危险的情况，则是技术上成功、分析上错误：
- SQL 正常执行，但 JOIN 把每笔订单重复了三次。
- 图表正常生成，但分母混入不符合条件的用户。
- 替代数据表有同名字段，却没有原方法需要的历史覆盖。
- Notebook 没有报错，但 cells 的执行顺序让结果无法复现。
- 数字与前一版一致，只是两个错误恰好相互抵消。
程序成功执行，不代表分析成立。
因此，只记录“Plan 产生 Result，新的 Plan 再产生新 Result”会漏掉真正重要的信息：前一条路径为什么停止、哪些假设已被否决、哪些部分结果仍可沿用，以及新路径是替代、延伸，还是重新开始。
AI 会让“安静的错误”一起规模化
一位分析师手动尝试三段查询，通常还记得自己为什么放弃第一段。但 Agent 可以在几分钟内查看十张表、改写多轮查询、建立中间结果，再把其中一版数字写进图表与文字。
这种速度有真实价值，也让四件事更容易丢失：
- 被否决的路径：为什么数据 A 不可用，而不是单纯没有选择它。
- 转换的理由：查询从 A 改成 B，是修正 bug、改变口径，还是更换假设。
- 证据的身份：报告引用的是哪次实际执行结果。
- 当前的权威版本：多个看似完成的产物中，哪一个才是正式结论。
如果这些信息只存在对话里，更换 Agent、压缩 context 或隔周重开项目，就可能把已经排除的路径当成新发现，再走一次。
失败的分析路径不该被删除，也不该被假装完成
分析走不下去，不一定代表前面的工作没有价值。
假设团队原本计划用事件数据评估某项功能对 30 日留存的影响，检查后才发现历史数据只保留 14 天。这条路径不能支持原问题，但过程可能已经确认了事件定义、数据质量和可用期间。合理的处理不是删除整段记录，也不是把它标成“完成”。
它应该被清楚标记为：
- 已停止，尚未成功完成。
- 停止原因是历史覆盖不足。
- 已完成哪些检查，哪些部分结果仍然有效。
- 后续用什么新方法或新范围取代它。
这个差异看似只是状态名称，实际上是在保护未来的人和 Agent：不要再把一条已被证明不可行的路，误认为尚未尝试的路。
Data Lineage 不够，我们还需要 Analysis Lineage
Data Lineage 回答的是数据如何流动：
原始数据 → 清洗 → JOIN → 聚合 → Dashboard
它能帮助团队判断上游改动会影响哪些数据表和报表，但它通常不会回答：为什么选择这张表？哪个指标定义被否决？这份结论引用哪次执行？前一个方法为什么停止？
Analysis Lineage 要追踪的是结论如何成立：
业务问题
→ 分析路径、假设与口径
→ 实际执行的 SQL / Notebook
→ 验证、部分结果与停止原因
→ 图表、报告与最终结论
两者回答不同的问题：
Data Lineage 追踪数据如何流动。Analysis Lineage 追踪结论如何成立。
一条实用的 Analysis Lineage 不必保存 Agent 的每个思考片段。它应记下能帮助人和 Agent 回答下列五个问题的信息：
- 当前讨论的结论来自哪个正式产物与哪次执行？
- 它使用哪些数据、查询、定义、筛选与时间范围？
- 上游有哪些被停止或被替代的分析路径，原因是什么？
- 哪些内容是正式证据，哪些只是历史背景或部分成果？
- 证据链是否完整？若不完整，缺少哪一环？
这条上下文必须活在聊天之外
如果 Analysis Lineage 只有当前这个 Agent 看得到，它就不是团队资产。内置 Agent、外部 Agent 和人工审核者都应读取同一套关系，而且这些关系要和分析产物一起保存，不依赖某段对话仍在 context 中。
在 Lantide Data 中，我们用这个原则连接分析的 Plan、被停止或替代的路径、实际结果与 Report。用户可以直接查看 Analysis Lineage。Agent 也能沿着同一条上下文，从当前报告追溯到上游计划与证据。下次追问、交接或重新分析时，就不必靠猜测拼回历史。
无论使用哪套工具，都可以先从一条最低限度的规则开始：每个正式结论都要能指回实际执行证据。每条被放弃的路径都要保留停止原因与替代关系。
结语
AI Agent 让分析师不必亲手完成每一个操作，也让“我记得自己做过什么”不再足以支撑可信度。未来的分析工作流除了保存最后一版 SQL 和最后一份报告，还要保留问题、选择、失败、验证与结论之间的关系。
AI Agent 让分析更快。Analysis Lineage 让团队仍能说清楚结论是怎么得出的。