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

Prompt 与 Context 工程：模型看見什麼、如何思考

配套①：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 内，让模型知道自己在哪个产品狀态、能做什麼、不能做什麼。

二、整体资料流

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

三、Context Summary：每轮都注入，但刻意很小

Summary 以结構化文字列出：

  • 当前时间（精簡一行：@@PROTECT3@@，每轮注入）
  • Workspace、Focused Project（含 Plan/Report 檔名与狀态；略过已封存檔）
  • Active Tab 類型与是否 dirty
  • Open Tabs 数量、Cached Tables 数、外部庫与 MCP 摘要

不包含各分页全文或完整 schema。模型若需細節，应呼叫 @@PROTECT4@@ 或 @@PROTECT5@@ / @@PROTECT6@@。

四、Context Detail：完整内容透过工具按需取得

Detail 通道承載：

  • 指定表的 ANSI DDL（@@PROTECT7@@）
  • 应用上下文 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 的分层设計

  1. Core system — 产品角色、DuckDB 规则、工具使用通则、Query Execution Model、統計分析須 @@PROTECT8@@ + @@PROTECT9@@。
  2. State prompt — 依 @@PROTECT10@@ / @@PROTECT11@@ / @@PROTECT12@@（@@PROTECT13@@）/ @@PROTECT14@@（@@PROTECT15@@）等切換 workflow 段落；不重复列举工具名录（以 schemas 为准）。
  3. 條件段 — 例如 catalog 模式下的 expand 提示；@@PROTECT16@@ 时拼接 HTML 编辑段。
  4. Knowledge — 見 §十。
  5. Recent Query Steps（Layer 3.5） — 有 @@PROTECT17@@ 时注入 ledger 摘要；权威实作見 AI Agent 架構 §六。

State 檔只写方法論与狀态限制（如 Planning 階段不得跑統計）；探索预算句数只在 core 定義，避免重复佔 token。

Assistant 協議： 每次 @@PROTECT18@@ / @@PROTECT19@@ 成功后，正文一行 @@PROTECT20@@ 摘要（含 @@PROTECT21@@ 等）；解析与 @@PROTECT22@@ 見 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）；探索性单表可仅预览；每步 @@PROTECT23@@ + @@PROTECT24@@
Run vs Source Run 本分页 vs 依 DAG 重算上游链
Executing（@@PROTECT25@@） @@PROTECT26@@ / @@PROTECT27@@ 須传 @@PROTECT28@@（≤40 字，写入 Ledger）
禁止 SQL 内 DDL/DML；@@PROTECT29@@ 多语句；自 @@PROTECT30@@ 自己快取名

工具回传中的 hint 分两種：

Hint 语意 Agent 应对
@@PROTECT31@@ / @@PROTECT32@@ 阻擋型；目前主要用于 3+ CTE 等过度复杂 SQL 拆成更小步驟或上游 persist tab 后再跑
@@PROTECT33@@ 非阻擋型；例如純多实体表 JOIN 时提醒可考慮 cache 视重用、審閱、Source Run 需求決定是否建 persist tab；不可把它当錯誤

State 檔以「見 Query Execution Model」引用，不重复长篇。物化 @@PROTECT34@@ 与 API 細節見 統一查詢层 §8.1。

八、Core system：SQL 规则与安全邊界

除 QEM 外，Core 还承載下列安全与格式約束（不把 API Key 等敏感设定灌进 prompt；知识与 user 讯息仍受长度上限；System instruction 与 user 氣泡在 UI 区分，避免模型混淆角色）：

  • 表名双引号、Excel 两段引用、MCP 表名格式。
  • 探索階段：validate_query 仅回 ok/錯誤，无资料列；不得用于分析结論。
  • 正式取数：run_query（预览上限 200 行）或 run_sql_tab。
  • 外部庫 ATTACH 由 UI 管理，不在聊天 SQL 里写 ATTACH。

九、State prompt：狀态決定「怎麼思考」

示例差异：

  • NoProject：可 Quick 分析或引导 @@PROTECT35@@。
  • ProjectFocused + Planning：修 Plan、處理批註；不 Execute。
  • Executing：依前台/后台模式跑 SQL；可 @@PROTECT36@@。
  • html_report_active：追加 HTML 编辑 workflow（与 chunk 工具同现）。

ProjectFocused HTML： Generating 段常駐；Editing 段仅在 @@PROTECT37@@ 时注入，避免无工具卻 prompt 慫恿 patch。

十、Knowledge injection

治理敘事見 可治理的 Agent Memory。本文只述工程行为：

  • 仅 Enabled 且已核准的 User / Project 檔注入。
  • Queued 永不注入。
  • 知识檔 mtime cache；变更后重读（含旧版四区遷移）。
  • flat（User < 2,500、Project < 5,000 字）：Rules + Info 全文。
  • catalog（达閾值）：目录索引 + 提示呼叫 @@PROTECT38@@；超注入预算截断。
  • pre-inject Reorganize：catalog 字数但无目录结構时，新 conversation 首次 run 前可能自動重组（見 可治理的 Agent Memory §6.3）。

十一、批註 Sidecar 与 AI 上下文

呼应 Agent 时代的数据分析工作流 §六 批註产品故事。

Plan / Report 批註存于 @@PROTECT39@@ sidecar；Markdown 正文含 id-only @@PROTECT40@@ 标籤。@@PROTECT41@@ / @@PROTECT42@@ 与 Context Engine Active Tab 回传：

  1. 磁碟正文 @@PROTECT43@@（含 id-only @@PROTECT44@@ 标籤）
  2. 批註 sidecar @@PROTECT45@@（open / resolved 狀态、quote、history；忽略过期的 @@PROTECT46@@）
  3. @@PROTECT47@@ 与 @@PROTECT48@@（Action Required 任务清单）
  4. @@PROTECT49@@（resolve 模式 A/B、mark 邊界；Agent 忽略 stale sidecar span）

Resolve 路徑： 工具列 Resolve (N) 或对話指令 → @@PROTECT50@@ 原子更新 sidecar 与 Markdown mark → @@PROTECT51@@ 刷新编辑器；若 sidecar 在磁碟上已被外部更新，主视窗可能提示重載（dirty tab toast）。

操作見 §11.7–11.9。

十二、历史讯息截断

非「最后 N 则」，而是保留分析语境：近期 user/assistant、工具軌跡配对、关鍵系統事件。目标在长对話中仍可延續 Plan 執行上下文，同时控制 token。

十三、Mid-turn compaction

ReAct 迴圈内若 token 逼近上限，可对本轮已累積的 tool 结果等做 compaction，避免单轮多工具爆窗。与 §十二 的跨轮截断互補。

@@PROTECT52@@ / @@PROTECT53@@ 压缩时保留 @@PROTECT54@@、@@PROTECT55@@、@@PROTECT56@@、@@PROTECT57@@、@@PROTECT58@@，并将 @@PROTECT59@@ 截为 @@PROTECT60@@（前 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 跨狀态一致
@@PROTECT61@@ 非阻擋 引导使用 cache，但不为了 lineage 破坏分析

十六、结语

Context 工程決定 Agent「以为的世界」是否与 IDE 真实狀态一致——Summary 要小、Detail 要新、State 要对、知识要经核准才注入。

这些 prompt 如何变成可串流的 tool 行为，是 AI Agent 架構 的主題；查詢语意则由 統一查詢层 在 DuckDB 管线上落地。

← 上一篇: 可治理的 Agent Memory：分层、審批与 catalog 注入下一篇: AI Agent 架構：ReAct、狀态路由与 UICommand →