Lantide Data
此页已有简体中文译文，但尚待核对最新繁体中文原文的更新。

Agent 时代的数据分析工作流：可審閱的交付、協作与執行授权

方法論答卷 A：AI 不取代分析流程，而是把流程变成可審閱的 artifact 与明確的執行授权。知识治理見 可治理的 Agent Memory。操作見 使用者指南 §10–12。

系列位置

完整导读見 系列导读与产品定位。

順序 文章 本題
0 系列导读与产品定位 系列导读与产品定位
1 本文 工作流、交付物、Execute
2 可治理的 Agent Memory Agent Memory
3 Prompt 与 Context 工程 Prompt / Context
4 AI Agent 架構 Agent 架構
5 統一查詢层 查詢层

一、核心判断：AI 不会取代分析流程，只会重塑分析流程

数据分析的本質沒变：提出問題、理解资料、驗證假设、形成结論、对利害关系人負責。变的是介面——从「在聊天视窗里問一句答一句」，变成「在 IDE 里留下可查的 SQL、可改的 Plan、可簽核的 Report」。

Lantide Data 的产品假设是：

  • 分析不是单次回答，而是一组可討論、可版本化、可執行的交付物。
  • 人類保留節奏与授权；Agent 負責探索、起草与執行，但不能自行按下「开始跑正式分析」的开关。
  • 協作发生在文件上（批註、Plan 狀态），而不只是对話氣泡里。

二、Quick Analysis 与 Project Analysis

模式 觸发 典型路徑
Quick Analysis 未聚焦專案 直接建 SQL 分页、驗證与查詢、对話摘要；复杂时 Agent 建議升級專案
Project Analysis 已聚焦專案 Plan → 批註審閱 → Execute → Report；可选前台／后台／混合執行

簡单 SQL 問答（如语法怎麼写）不強制选模式。有分析意图时，Quick 模式下 Agent 会先問要快速分析还是建立專案。詳見 §12.5。

何时用哪種模式（決策要点）：

@@PROTECT0@@@@PROTECT1@@@@PROTECT2@@

管线階段映射（見 系列导读 §一「分析師的一天」）：

模式 管线階段 交付形态
Quick Analysis Bronze → Silver（探索、欄位／口徑驗證） 对話 + SQL 分页 + 快取
Project Analysis Silver → Gold／Insights Plan → Report／HTML

三、为何 SQL-first：分析、维护与協作

Lantide Data 把 SQL 作为分析工作的主交付语言——不是因为引擎碰巧支援 DuckDB，而是因为在现代分析实踐里，最值得被留下、被维护、被協作的部分，是口徑与取数。

下面从三个角度說明：分析时口徑即契約、维护时 SQL 可 diff 可重跑、協作时討論发生在可查的 artifact 上。

分析：口徑即契約

分析品質取決于「这个数是什麼意思」，而不取決于程式写得是否簡潔。活躍用戶怎麼定義？两个來源的 @@PROTECT3@@ 怎麼对齊？这个 JOIN 会不会 fan-out？这類問題用关系代数最直接：@@PROTECT4@@、@@PROTECT5@@、@@PROTECT6@@、@@PROTECT7@@ 就是在写口徑契約。

Plan 天然是 SQL 规格書——写的是查什麼、用哪些表、如何驗證——而不是一串 notebook cell 的執行順序。分析不是单次回答，而是一组可討論的假设与證据；SQL 让假设可被引用、可被反駁。

分析品質：先把数算对，再談管线形狀

SQL-first 不等于「把所有東西都拆成 DAG」。真正的优先順序是：

  1. 先講清楚問題、分母、时间窗与业务口徑。
  2. 確认资料粒度、欄位、JOIN key 与可能的 fan-out。
  3. 用最小可驗證 SQL 證明指标逻辑是对的。
  4. 檢查输出欄位与步驟名称是否一致，例如「商品類別分析」就应該产出類別欄位。
  5. 最后才判断是否需要 persist tab、快取或 Source Run。

因此，cache / DAG 是可重用与可審閱的优化能力，不是分析可信度的最低條件。若一个多表 JOIN 是一次性且口徑清楚，直接 SQL 也可以是正確选擇；若中间结果会被重用、需要同事審閱，或上游改動后需要重跑，才值得升級成 persist-tab DAG。

维护：可 diff、可重跑

维护分析，维护的是六个月后还能不能說清楚这个数怎麼來的。

  • 宣告式逻辑易審閱：改一條 @@PROTECT8@@ 或 @@PROTECT9@@ 條件，diff 直指口徑变更，而非沿 imperative 程式重建心智模型。
  • 依賴显式：@@PROTECT10@@ 把中间假设写在紙上；notebook 里的 @@PROTECT11@@、@@PROTECT12@@ 是隱式狀态。
  • 重跑语意乾淨：同一段 SQL、同一套表 → 结果可预期；較少 cell 執行順序造成的「为什麼我先跑第 7 格就不一樣」。
  • 接近團隊口徑语言：可復用的定義往往最終以 warehouse SQL / 语義层存在；在 SQL 里打磨的口徑，比藏在一次性 Python 里的更容易升格为團隊资产。

協作：发生在 SQL 分页与 Plan 上

協作型分析常敗在：结論在簡報里，逻辑在某人筆電里；图表能分享，口徑不能討論。下表說明 SQL-first 如何回应常見協作需求：

協作需求 SQL-first 如何回应
利害关系人質疑口徑 打开查詢，討論 @@PROTECT13@@ 与 @@PROTECT14@@
同事接手專案 看 SQL 分页 + Plan，不必重放对話
批註 「这段应排除退款单」→ 精准改 SQL 片段
正式簽核 Execute 前審的是 Plan + SQL，不是黑盒跑出來的图

图表可以分享；口徑必須可討論。这与 系列导读 §一 中 Julius 類 Harness（隱藏程式換速度）形成对照：我們选擇暴露 SQL 以換可治理。

与 Python 的分工

不是不用 Python，而是不让 Python 成为预设的、不可審閱的分析載体：

工作 載体
取数、对齊、聚合、口徑驗證 SQL（IDE 分页 + 快取）
假设檢定、回歸、时序、聚類等 @@PROTECT15@@ 工具 + @@PROTECT16@@ 確认参数

統計与 ML 在已審閱的乾淨表上執行，取数仍走 SQL——見 §十二。拒絕的是「模型在对話里隨手写 pandas、跑完即丟」的预设路徑。

邊界（我們不宣称取代一切）

  • 高度程式化、自訂演算法、重度探索性 notebook → Jupyter / Cursor 等仍合理；Lantide 補的是需治理与簽核的分析。
  • 非表格、NLP、深度学习 → 非主場景。
  • 我們不做企业級 Silver ETL 調度；工作区内中间结果的定位見 統一查詢层 §七。

工程落点（一筆帶过）

上述原则由 IDE 内 SQL 分页、Plan 契約与 統一查詢层（逻辑表名、物化、Source Run 血緣）承載；不在此展开 DuckDB / sqlglot 細節。

四、Plan / Report：Markdown 契約

專案内文件分 Plan（執行前契約）与 Report（執行后交付），通常以编号配对，例如 @@PROTECT17@@ / @@PROTECT18@@。

Plan 写的是查什麼、用哪些表、如何驗證——与 §三 SQL-first 一致：執行前的口徑契約，而非 notebook 執行順序。

设計目的：

  1. Plan 是執行前的契約 — 查什麼、用哪些表、如何驗證，須先写清楚再執行。
  2. Report 是執行后的交付物 — 结論与證据进文件，而非只留在聊天記录。
  3. 一对一配对 — 新分析应新 Plan，避免覆写旧 Report。
  4. Executed Plan 锁定 — 追溯历史；后續迭代开新 Plan。
  5. HTML 为第二種可交付物 — 見 §五；与 @@PROTECT19@@ 并存。

專案檔案、封存（Archived docs）、焦点模式見 §11。

Plan 三态（系統内部代碼如 @@PROTECT20@@ 等，此處用产品语言）：

狀态 文件 Agent 狀态指示
Planning 可编辑 Planning（可批註討論）
Executing 唯读 Executing
Executed 唯读；可改批註 回到 Project Focused
Stopped 唯读；保留停止原因、部分成果与替代 Plan 关系 回到 Project Focused

前端指示器与后端狀态同步，決定可用工具集（見 AI Agent 架構）。当数据条件或决策前提改变时，应使用 Stop & Replan，而不是将未完成的 Plan 标为 Executed，見 §11.6。

@@PROTECT21@@@@PROTECT22@@@@PROTECT23@@

Reference docs（与 Plan / Report 分流）

除 Plan / Report 外，專案可含 Reference 檔——存放欄位映射、狀态碼字典、join 說明等大型、少整份改写的参照本体。设計取捨：

层 角色
Reference 檔（@@PROTECT24@@） 可编辑正文；列在側邊欄 Reference docs 子樹，不与 Plan/Report 混列
@@PROTECT25@@ Rules（@@PROTECT26@@） 短索引：Purpose + When to read
@@PROTECT27@@ 任务符合 When to read 时按需載入全文，避免全文常駐 prompt
@@PROTECT28@@ 小範圍 find-replace 修正；建立新 Reference 仅 UI

建立路径： 可用 New Reference 建立空白壳、由 Agent 原生建立，或通过受治理的导入路径导入本机文件。原生建立只在 Project Focused／Plan Planning 可用，且需要一次提交确认。Update Intro 可经 Agent @@PROTECT29@@ 審批或使用者手動写入。封存 Reference 预设不觸发 @@PROTECT30@@。Project / Workspace 匯出含 Reference 与索引；Compare view 可唯读开启 Reference（无批註 sidecar）。操作見 §11.3.1；onboarding 見 Learn：Reference docs。

停止不等于完成： 正式执行时若数据条件或决策前提改变，应使用 Stop & Replan。旧 Plan 会保留停止原因、部分成果与正式 evidence；替代 Plan 必须重新满足品质与执行契约，再由使用者 Execute。Analysis Lineage 将 Plan、Markdown Report 与 HTML Report 连接起来，让审阅者追溯证据链，并看见缺失或含糊的关系，不必从聊天历史补猜。

五、HTML 報告：第二種可交付物

除 Markdown Report 外，可从 Report 产出獨立 @@PROTECT31@@，在瀏览器閱读、分享或匯出。

产品定位：

  • Generate / Re-generate：依版面（Standard / Presentation）、樣式预设、CDN／Chart.js 等配置，由 Agent 产出完整 HTML。
  • Open Report / Export HTML Report：本機瀏览或另存快照（Electron 匯出）。
  • 事后修改：在 Report 分页或透过 @@PROTECT32@@ 在非 Report 分页请 Agent 区块／樣式修補；整体改版面仍应 Re-generate。
  • Quick Edit HTML：使用者手動改单一区块，帶 content hash 防併发覆写；可开 Live Preview 熱重載。

契約要求（如 @@PROTECT33@@、单一 @@PROTECT34@@、@@PROTECT35@@ 区块）与工具行为在 AI Agent 架構 §七 說明。操作步驟見 使用者指南 §10。

六、Plan / Report 批註：把共识写进文件

批註让審閱意見綁在原文上，并成为 Agent 下一轮修改的输入。

儲存模型： Preview 选取文字 → 批註写入 @@PROTECT36@@ sidecar，并在 Markdown 正文写入 id-only @@PROTECT37@@；编辑器以正文 mark 与右側卡片双向对应。旧 @@PROTECT38@@ inline mark 开檔自動遷移至 sidecar（metadata 不含 @@PROTECT39@@；正文 id-only 保留仍规划中）。不支援巢狀批註。

Resolve Comments： 工具列一鍵请 Agent 依全部 open 批註更新文件（等同手動說「處理批註」）。Executing / Executed 等锁定狀态下正文唯读，批註 margin 仍可操作。

狀态与生命周期： Open → Agent Resolve → Resolved → 可 Archive（history 留于 sidecar @@PROTECT40@@）；Reopen 可恢復 Resolved。正文 mark 遺失时为 orphaned（主视窗 UI 标 Anchor outdated）——需 Re-anchor 重新反白；View changes 提供 Before/After 对照。

Compare view： 唯读显示 sidecar 批註与高亮、View changes Popover；不可编辑、刪除或 Re-anchor——協作编辑留在主视窗。見 §11.10.3。

Agent 透过 @@PROTECT41@@ / @@PROTECT42@@ 取得含 id-only mark 的磁碟正文与 sidecar @@PROTECT43@@；批量處理走 @@PROTECT44@@（原子写回 sidecar + 正文 mark）——实作見 Prompt 与 Context 工程 §十一。操作見 §11.6–11.9。

Report 表格另支援 Copy for Excel（TSV + BOM），与 SQL 结果 Export 不同，見 §11.4.1。

七、最重要的邊界：Agent 不能自己按 Execute

Execute 是使用者明確授权：将 Plan 切到 Executing，并觸发 Agent 依 Plan 執行。Agent 不得透过工具或对話自行等同于「使用者已按下 Execute」。

这條邊界区分：

  • 探索与起草（读表、驗證 SQL、改 Plan）
  • 正式執行分析（需 Executing 狀态与使用者已选的執行模式）

若 Agent 能自行开跑，利害关系人簽核就失去意義：Plan 上的假设可能尚未審完，批註可能还掛在原文上，正式統計卻已在背景产出 Report——分析師无法向團隊交代「这个数是誰、在什麼前提下核准的」。因此 Execute 必須是可观测的人類動作，而非模型自行推断的意图。

Planning 階段不得跑正式統計或 @@PROTECT45@@；方法論护欄写在 Prompt 层（Prompt 与 Context 工程）。

八、add_report：用交付物完成狀态转換

執行完成后，Agent 以 @@PROTECT46@@ 一次性产出 Report，并将对应 Plan 标記 Executed。这是狀态機上的交付事件，不是隨手改一篇 Markdown。

  • 新 Plan 執行 → 新 Report；不更新旧 Report。
  • 仅在使用者批註或明確要求时，才修訂已有 Report 段落（增量编辑优先）。

九、Foreground / Background / Hybrid

Plan 进入 Executing 后，Agent 透过 ask_user 詢問一次執行偏好：

模式 体驗
前台 建立持久 SQL 分页、写入 SQL、執行；使用者可見每一步
后台 以 @@PROTECT47@@ 等为主，结果在对話呈现，少動编辑器
混合 以后台为主，关鍵步驟切前台展示

同一对話内不重复詢問已表达的偏好。后台 @@PROTECT48@@ 的物化策略与 persist / agent 快取语意見 Prompt 与 Context 工程 §七（语意契約）与 統一查詢层 §8.1（策略表）；Data → Cached 右鍵 查看 SQL 可審閱任一快取來源。

十、ask_user：把人類決策变成協議

需要选模式、確认執行方式、探索配額用盡是否繼續等，Agent 呼叫 ask_user，前端显示选項或自由文字；后端暫停 ReAct 直至回覆或逾时（約 5 分钟）。探索配額續跑亦经此協議，見 AI Agent 架構 §4.2。

这把「产品流程」从 prompt 里的建議，变成可观测的互動事件。操作見 §12.7。

十一、分析品質护欄

分析品質护欄分三层協作：识別場景（A/B、漏斗、异常等，在 Plan 中加入檢查点、在 Report 中写限制）→ @@PROTECT49@@ 確认（統計参数、執行模式等人類必須拍板的決策）→ @@PROTECT50@@ 執行（在已審閱的乾淨表上跑内建統計／ML 工具）。Planning 階段不应跳过前两步直接跑統計；工具可用性由狀态矩陣过濾（見 AI Agent 架構 §三）。

对一般商业分析，最低品質线不是「有沒有 DAG」，而是報告是否可信。新建 Plan 与 Report 会验证面向读者的必要结构，并保留与 semantic section mapping 和内容 digest 绑定的 verification receipt。这不取代人工审阅，但能避免缺少决策、证据、范围或限制的交付物直接定稿。Release smoke 目前用下列讯号当 hard gate：

  • 是否先建立 Plan、再依 Plan 建 todo、最后产出 Report。
  • SQL / tool 是否沒有明显錯誤迴圈。
  • 報告是否講清楚場景必要内容，例如漏斗的 stage definition、denominator、最大流失環節。
  • 報告是否有具体数字与 limitations，而不是只留下聊天摘要。
  • 速率、漏斗、留存、財务等指标是否同时保留 numerator / denominator 与粒度說明。

DAG、Source Run、@@PROTECT51@@ 区块现在是 soft signal：用上很好，沒用上不应阻擋一份可信分析。

文件修訂优先段落級增量编辑，減少整份覆写与批註錯位。操作見 §12.9–12.10。

十二、反模式

反模式 对应设計
结論只在聊天里 Plan / Report / HTML 交付
Agent 自行开跑正式分析 仅使用者 Execute
改旧 Report 当新分析结果 新 Plan → 新 Report
无審閱直接執行 Planning + 批註 + Execute
知识自動进模型 見 可治理的 Agent Memory
中间清洗只在对話／沙箱里 persist 分页 + 快取血緣（統一查詢层 §八）
口徑逻辑埋在 Python cell、无法同事審閱 Plan + SQL 分页为協作单元（§三）
为了做 DAG 犧牲分母、粒度或分析维度 分析品質优先；DAG 是 soft signal
分页名称与输出欄位不一致（例如 category 分析输出 seller） 執行时檢查 step 名称、output dimension 与報告敘事

十三、能力总览

能力 本文 延伸
SQL-first 口徑契約 §三 統一查詢层
專案 / Plan 狀态 §四、§七–§八 AI Agent 架構 狀态路由
批註協作 §六 Prompt 与 Context 工程 Optimizer
HTML 交付 §五 AI Agent 架構 HTML 工具
分析护欄 / 統計工具 §十一 AI Agent 架構 工具矩陣
分析品質 hard gate §十一 Prompt 与 Context 工程 QEM、D3 analysis-quality smoke
知识 — 可治理的 Agent Memory、Prompt 与 Context 工程
SQL / 快取 / Source Run §九（一句） Prompt 与 Context 工程 §七、統一查詢层

十四、结语

Lantide Data 的分析工作流核心，是把「問 AI 一个問題」变成「留下一组可審閱、可授权、可重跑的交付物」。Execute 邊界与 SQL-first 口徑契約 是这套方法論的两根支柱——前者保證人類節奏，后者保證協作載体。

跨对話的口徑沉澱属于另一维度：見 可治理的 Agent Memory。若要理解模型如何看見 Plan、批註与知识，接著读 Prompt 与 Context 工程。

← 上一篇: 系列导读与产品定位下一篇: 可治理的 Agent Memory：分层、審批与 catalog 注入 →