配套①：Prompt 是每輪重新組裝的分層結構，而非一段寫死的 system string。本篇面向工程師；方法論見 工作流、Memory。操作見 使用者指南 §12.11。
系列位置
完整導讀見 系列導讀與產品定位。
| 順序 | 文章 | 本題 |
|---|---|---|
| 0 | 系列導讀與產品定位 | 系列導讀與產品定位 |
| 1–2 | Agent 時代的數據分析工作流、可治理的 Agent Memory | 工作流、記憶 |
| 3 | 本文 | Context / Prompt |
| 4–5 | AI Agent 架構、統一查詢層 | Agent、查詢層 |
一、Prompt 是每輪重新組裝的分層結構
在 Lantide Data 裡，Prompt 指每輪 ReAct（推理—行動迴路）迭代時重新組裝的 system prompt（Core + State + 條件段 + 知識），並附上 Context Summary、工具 schemas、精簡後的 history，以及 active tab 的 Detail（含批註 Optimizer 產物）。這與「寫一段 system string 就定稿」的舊做法不同：目標是在有限 context window 內，讓模型知道自己在哪個產品狀態、能做什麼、不能做什麼。
二、整體資料流
使用者訊息
│
├─► Context Summary（每輪固定、偏小）
├─► get_app_context / 工具 ─► Detail（按需、可大）
├─► System: core_system + state_*.md + 知識注入
├─► Function schemas（依狀態過濾）
├─► History（截斷策略）
└─► Active tab payload（Markdown 含批註優化）
│
▼
LLM → tool calls → 觀察 → 下一輪（可能刷新 state）
三、Context Summary：每輪都注入，但刻意很小
Summary 以結構化文字列出：
- 當前時間（精簡一行：
YYYY-MM-DD HH:MM (UTC±N)，每輪注入） - Workspace、Focused Project（含 Plan/Report 檔名與狀態；略過已封存檔）
- Active Tab 類型與是否 dirty
- Open Tabs 數量、Cached Tables 數、外部庫與 MCP 摘要
不包含各分頁全文或完整 schema。模型若需細節，應呼叫 get_app_context 或 show_tables / read_schema。
四、Context Detail：完整內容透過工具按需取得
Detail 通道承載：
- 指定表的 ANSI DDL（
read_schema） - 應用上下文 JSON（開啟分頁列表、專案檔案 meta）
- Active Markdown tab：Plan/Report 全文（經批註 Optimizer）
當使用者說「處理當前 Plan 的批註」時，依賴的是 active tab Detail，而非把整個工作區塞進 Summary。
五、為什麼分 Summary 與 Detail 兩條通道
單通道把全文塞進每輪 prompt，在多分頁 IDE 裡很快 token 爆炸，且難以剔除過期內容。雙通道讓 Summary 保持穩定小巧，Detail 由工具按需拉取：
| 問題 | 單通道全文注入 | 雙通道 |
|---|---|---|
| Token 爆炸 | 每輪重送所有 tab | Summary 穩定小；Detail 按需 |
| 過期內容 | 難以剔除 | dirty tab 送編輯器即時內容 |
| 探索階段 | 浪費在無關文件 | 工具拉 schema |
六、System Prompt 的分層設計
- Core system — 產品角色、DuckDB 規則、工具使用通則、Query Execution Model、統計分析須
ask_user+activate_analysis。 - State prompt — 依
NoProject/ProjectFocused/Planning（PlanPlanning）/Executing（PlanExecuting）等切換 workflow 段落；不重複列舉工具名錄（以 schemas 為準）。 - 條件段 — 例如 catalog 模式下的 expand 提示；
html_report_active時拼接 HTML 編輯段。 - Knowledge — 見 §十。
- Recent Query Steps（Layer 3.5） — 有
conversation_id時注入 ledger 摘要；權威實作見 AI Agent 架構 §六。
State 檔只寫方法論與狀態限制（如 Planning 階段不得跑統計）；探索預算句數只在 core 定義，避免重複佔 token。
Assistant 協議： 每次 run_query / run_sql_tab 成功後，正文一行 [[QUERY_STEP]] 摘要（含 purpose 等）；解析與 patch_step 見 AI Agent 架構 §6.2。
Core 也承載一條跨狀態的分析操作循環：先確認問題、分母、粒度、欄位與 JOIN key，再跑最小可驗證 SQL，最後才考慮 cache、DAG 或 Source Run。這讓模型在不同 state 中都知道「分析可信度」優先於「管線形狀」。
七、Query Execution Model（查詢執行語意契約）
聊天型分析工具常把 Run、物化、多步依賴藏在生成的 Python／SQL 裡，使用者只見圖表。Lantide 的 Query Execution Model（QEM，查詢執行語意契約） 把 validate / run_query / run_sql_tab / Source Run 的語意寫進 prompt，使「隱藏的 DA」的工作在 IDE 狀態裡可見、可審計——與 工作流 §三 SQL-first 同一脈絡。
Core 內專章為跨狀態權威，定義：
| 概念 | 行為 |
|---|---|
| Persist tab + run_sql_tab | 物化為與分頁同名的快取表；可 Source Run、血緣 |
| run_query | 條件物化（策略表見 統一查詢層 §8.1）；探索性單表可僅預覽；每步 result_label + [[QUERY_STEP]] |
| Run vs Source Run | 本分頁 vs 依 DAG 重算上游鏈 |
Executing（PlanExecuting） |
run_query / run_sql_tab 須傳 purpose（≤40 字，寫入 Ledger） |
| 禁止 | SQL 內 DDL/DML；; 多語句；自 FROM 自己快取名 |
工具回傳中的 hint 分兩種：
| Hint | 語意 | Agent 應對 |
|---|---|---|
complexity_hint / COMPLEXITY_SPLIT_RECOMMENDED |
阻擋型；目前主要用於 3+ CTE 等過度複雜 SQL | 拆成更小步驟或上游 persist tab 後再跑 |
optimization_hint |
非阻擋型；例如純多實體表 JOIN 時提醒可考慮 cache | 視重用、審閱、Source Run 需求決定是否建 persist tab；不可把它當錯誤 |
State 檔以「見 Query Execution Model」引用，不重複長篇。物化 reason_code 與 API 細節見 統一查詢層 §8.1。
八、Core system：SQL 規則與安全邊界
除 QEM 外，Core 還承載下列安全與格式約束（不把 API Key 等敏感設定灌進 prompt；知識與 user 訊息仍受長度上限；System instruction 與 user 氣泡在 UI 區分，避免模型混淆角色）：
- 表名雙引號、Excel 兩段引用、MCP 表名格式。
- 探索階段：validate_query 僅回 ok/錯誤，無資料列；不得用於分析結論。SQL Server 大結果可回
warning_required。 - 正式取數：run_query（預覽上限 200 行）或 run_sql_tab；SQL Server 大結果須
large_remote_warning_id。 - 外部庫 ATTACH 由 UI 管理，不在聊天 SQL 裡寫 ATTACH。
- SQL Server ODBC staged：upstream 單源 → 物化 → 本地 JOIN；禁止透明跨源 single-statement JOIN（詳見 統一查詢層 §9.3）。
Secondary model： 對話命名、知識抽取等背景 LLM 呼叫可走 Secondary model Profile（與 active 主模型分離），降低主對話 token 成本（見 USER_GUIDE §12.3）。
九、State prompt：狀態決定「怎麼思考」
示例差異：
- NoProject：可 Quick 分析或引導
focus_project。 - ProjectFocused + Planning：修 Plan、處理批註；不 Execute。
- Executing：依前台/後台模式跑 SQL；可
source_run_sql_tab。 - html_report_active：追加 HTML 編輯 workflow（與 chunk 工具同現）。
ProjectFocused HTML： Generating 段常駐；Editing 段僅在 html_report_active 時注入，避免無工具卻 prompt 慫恿 patch。
十、Knowledge injection
治理敘事見 可治理的 Agent Memory。本文只述工程行為：
- 僅 Enabled 且已核准的 User / Project 檔注入。
- Queued 永不注入。
- 知識檔 mtime cache；變更後重讀（含舊版四區遷移）。
- flat（User < 2,500、Project < 5,000 字）：Rules + Info 全文。
- catalog（達閾值）：目錄索引 + 提示呼叫
expand_knowledge_catalog；超注入預算截斷。 - pre-inject Reorganize：catalog 字數但無目錄結構時，新 conversation 首次 run 前可能自動重組（見 可治理的 Agent Memory §6.3）。
十一、批註 Sidecar 與 AI 上下文
呼應 Agent 時代的數據分析工作流 §六 批註產品故事。
Plan / Report 批註存於 *.annotations.json sidecar；Markdown 正文含 id-only <mark data-annotation-id> 標籤。read_plan / read_report 與 Context Engine Active Tab 回傳：
- 磁碟正文
content（含 id-only<mark data-annotation-id>標籤） - 批註 sidecar
annotations（open / resolved 狀態、quote、history；忽略過期的anchor.span） open_annotation_count與annotation_summary（Action Required 任務清單）patch_guidance（resolve 模式 A/B、mark 邊界；Agent 忽略 stale sidecar span）
Resolve 路徑： 工具列 Resolve (N) 或對話指令 → resolve_annotations 原子更新 sidecar 與 Markdown mark → sync_tab_content 刷新編輯器；若 sidecar 在磁碟上已被外部更新，主視窗可能提示重載（dirty tab toast）。
操作見 §11.7–11.9。
十二、歷史訊息截斷
非「最後 N 則」，而是保留分析語境：近期 user/assistant、工具軌跡配對、關鍵系統事件。目標在長對話中仍可延續 Plan 執行上下文，同時控制 token。
十三、Mid-turn compaction
ReAct 迴圈內若 token 逼近上限，可對本輪已累積的 tool 結果等做 compaction，避免單輪多工具爆窗。與 §十二 的跨輪截斷互補。
run_query / query_result 壓縮時保留 step_id、cached_table_name、materialized、materialize_reason、warnings，並將 sql 截為 sql_preview（前 200 字元），避免多步鏈在長輪次中失憶。
十四、Context window discovery
多 Profile、多模型時，執行時探測可用 context 上限，務實決定截斷與是否 auto-continuation（見 AI Agent 架構）。避免硬編碼單一模型假設。
十五、工程決策總覽
| 決策 | 原因 |
|---|---|
| Summary + Detail | Token 與新鮮度 |
| State 不列工具 | schemas 為單一真相 |
| validate vs run | 探索便宜、結論有數據 |
| Sidecar + 正文 id mark | 可追溯批註 history；人機共用同一磁碟全文 |
| Query Execution 在 core | 跨狀態一致 |
optimization_hint 非阻擋 |
引導使用 cache，但不為了 lineage 破壞分析 |
十六、結語
Context 工程決定 Agent「以為的世界」是否與 IDE 真實狀態一致——Summary 要小、Detail 要新、State 要對、知識要經核准才注入。
這些 prompt 如何變成可串流的 tool 行為，是 AI Agent 架構 的主題；查詢語意則由 統一查詢層 在 DuckDB 管線上落地。