系列导读与产品定位

一句話： Lantide Data 是本機数据分析 IDE，内建为分析師设計的 Agent runtime（Harness）——可審閱的交付物、受控的執行授权、与 DuckDB 工作区一体的查詢与工具，而不是「貼上 CSV 的聊天视窗」。

操作步驟見 使用者指南。本系列說明为什麼这樣设計，以及背后的产品与工程取捨。術语見文末 附录：術语速查。

系列位置

建議順序：系列导读与产品定位 → Agent 时代的数据分析工作流 → 可治理的 Agent Memory → Prompt 与 Context 工程 → AI Agent 架構 → 統一查詢层。

一、我們在填什麼空位

「AI 能做数据分析」已不新鮮；痛点在于缺少專为分析工作设計的 Agent 執行環境（Harness）。

許多人仍用通用聊天模型 + Excel / SQL 客戶端「湊」出一條分析链：工具碎、中间结果難追溯、AI 产出的 SQL 不敢直接当正式交付。若要把「專用分析環境」說清楚，可把市場粗分三层（便于对照，非完整競品地图）：

C 层里的強代表：Julius AI

Julius AI 是 C 层里成熟度很高的一類：上传 CSV/Excel 或連接 Snowflake / BigQuery → 自然语言問答 → 图表、統計、Notebook、定时報告。产品敘事強調「不用写 SQL」。

背后由模型在会話沙箱内生成并執行 Python / R / SQL，可称 analysis abstraction layer（隱藏的 DA，Data Analyst 執行层被藏起來）：用隱藏程式換速度，強項在 Insights 終端——快速从资料到图表与结論。

这類 Harness 的常見缺口

同属 C 层，并不代表上游与治理已经足夠。Julius 類产品常見的 trade-off 是：

• 上游准备多在会話内完成：清洗与对齊難追溯、難当正式中间成果重跑。
• 交付偏图表与结論：能分享，但口徑逻辑難像文件一樣審閱、批註、簽核。
• 工作流偏对話驅動：即使有 Notebook，仍少「先写契約、人類按下才正式跑」的邊界。

这些缺口不否认 C 层的价值，而是說明：Harness 已经存在，但还有一種更偏重可追溯的中间结果、可協作口徑、可授权 Execute 的路线（下文 Medallion 的 Silver／Insights 階段）——Lantide Data 要做的是这條路。

因此：Lantide Data 要補什麼

我們的立場是：分析不是单次回答，而是一组可討論、可版本化、可重跑的工作成果；Agent 应在同一个 IDE里探索、起草、執行，且人類保留節奏与授权。不是再造一个「会出图的聊天 Harness」，而是在 C 层内把到达洞察前的路徑做成可治理的 artifact。

与 Julius 類 Harness 的差异

便于读者定位品類与取捨，非功能評测或市場排名。SQL-first 方法論全文見 Agent 时代的数据分析工作流 §三。

分析師的一天：管线階段与工作成果

借 Medallion 術语标出管线階段（非宣称 Lantide 是倉内 ETL）。下表把典型一天对齊各階段——亦說明 Lantide 主場在可追溯的 Silver 与可簽核的 Insights，而非只搶終端图表：

全程在同一 IDE 完成，而非散落在聊天视窗与试算表之间。

产品邊界（收束）： 我們亦不是与工作区脫鉤的通用 coding agent（改 repo 很強，但不管 Plan、Report、快取血緣），也不是预设把对話自動灌进向量庫的記憶产品。形态上是 Local-first 桌面分析 IDE（本機 DuckDB 承載 CSV / ATTACH / MCP）内嵌 ReAct Agent runtime（依狀态过濾的工具矩陣 + UICommand）；跨对話口徑经 Queued Knowledge 審批 核准后才写入知识檔，而非黑盒累積。

可攜性（@@PROTECT1@@）： 共享分析脈絡与结果用 Project 匯出；協作接續工作或換機用 Workspace（Full backup 为多工作区 + Application 一次搬）。Workspace / Full backup 预设不帶本機 CSV／Parquet，可 opt-in 打包 physical data（換機 Extract 或 Rebind 本機目录二选一）；四種匯出均可选 passphrase 加密外层。选型与操作見 USER_GUIDE §11.1.0。

二、系列结構

正文五篇：两篇方法論（工作流、Memory）+ 三篇工程配套（Context、Agent 架構、查詢层）。它們共同說明上文 C 层（分析 Agent Harness） 如何被设計与实作；缺任一環都会退化成「聰明的聊天機器人」。各篇核心問題見 §四。

三、这套文章在回答什麼

Lantide Data 把「用 SQL 查本機檔案」与「用 AI 做分析」放在同一个桌面 IDE 里。读者真正关心的往往不只是模型会不会写 SQL，而是：

• 分析过程能否被看見、被審閱、被追溯？
• 人類与 Agent 的分工邊界在哪里（誰能 Execute、誰能改 Plan）？
• 記憶与上下文如何可控，而不是黑盒越堆越多？
• 为什麼要自研 Agent 迴路，而不是套用通用 Agent 框架？

本系列用两篇方法論（Agent 时代的数据分析工作流、可治理的 Agent Memory）与三篇工程配套（Prompt 与 Context 工程、AI Agent 架構、統一查詢层）回答上述問題；**本文（系列导读与产品定位）**負責品類与閱读地图。

@@PROTECT2@@@@PROTECT3@@@@PROTECT4@@

四、正文一览

五、能力地图

六、如何閱读本系列

依角色与时间

依問題跳转

各篇开頭均有「系列位置」表；完整导读以本文为准。

七、与使用者指南的分工

重复时以使用者指南为准；本系列用「見使用者指南 §X」帶到操作細節，不重复长篇步驟說明。

八、系列维护約定

跨篇主題只在一篇写完整版（SSOT），其餘 1–2 句 + 連结。新功能補丁时：

1. 先查下表定权威篇，再写入該篇。
2. 其他篇仅加指向連结，不重复表格。
3. 操作步驟仍只写在 USER_GUIDE。

附录：術语速查