配套①：Prompt 是每轮重新组装的分层结构，而非一段写死的 system string。本篇面向工程师；方法论见 工作流、Memory。操作见 使用者指南 §12.11。
目前实作补充（0.3.3）
工作区分析脉络不等于聊天视窗。Agent 可透过 read_workspace_manifest 取得分页索引与正文／关系／历史导航，再用 read_workspace_changes、read_workspace_change 读取增量与理由。cursor 需绑定原读取范围；snapshot 后的 resume cursor 不代表更早历史已读。Reader 的内容指纹、未完成分页与缺口警告用来提示重新读取，不能把摘要当成完整证据。
系列位置
完整导读见 系列导读与产品定位。
| 顺序 | 文章 | 本题 |
|---|---|---|
| 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 管线上落地。