系列導讀與產品定位

一句話： 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 / Cloud folder / ODBC staged / MCP）內嵌 Built-in ReAct Agent runtime（依狀態過濾的工具矩陣 + UICommand）；並可選 External MCP Agent（Cursor 等 client 連入本機 host，共用同一工作區 artifact）。首次啟動 Setup Mode Choice 分流 Built-in BYOK 與 External MCP（見 USER_GUIDE §2.1）。跨對話口徑經 Queued Knowledge 審批 核准後才寫入知識檔，而非黑盒累積。

AI Settings： 除 active Profile 外，可指定 Secondary model 供對話命名、知識抽取等背景任務（見 USER_GUIDE §12.3）。

可攜性（.lantide）： 共享分析脈絡與結果用 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 架構、統一查詢層）回答上述問題；**本文（系列導讀與產品定位）**負責品類與閱讀地圖。

flowchart TB
  guide[系列導讀與產品定位]
  subgraph methodology [方法論]
    workflow[Agent 時代的數據分析工作流]
    memory[可治理的 Agent Memory]
  end
  subgraph engineering [工程配套]
    context[Prompt 與 Context 工程]
    agent[AI Agent 架構]
    query[統一查詢層]
  end
  ug[使用者指南_操作]
  guide --> workflow
  guide --> memory
  workflow --> context
  memory --> context
  context --> agent
  agent --> query
  ug -.->|操作細節| workflow

四、正文一覽

五、能力地圖

六、如何閱讀本系列

依角色與時間

依問題跳轉

各篇開頭均有「系列位置」表；完整導讀以本文為準。

七、與使用者指南的分工

重複時以使用者指南為準；本系列用「見使用者指南 §X」帶到操作細節，不重複長篇步驟說明。

八、系列維護約定

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

1. 先查下表定權威篇，再寫入該篇。
2. 其他篇僅加指向連結，不重複表格。
3. 操作步驟仍只寫在 USER_GUIDE。

附錄：術語速查