OPENING30 秒开口版
Text2SQL 不是 prompt 写 SQL，而是一条受治理的 runtime contract。intake 绑定 actor、workspace、agent scope、policyVersion 和 runId；retrieve 召回授权后的 schema、glossary、examples、source_documents、graph evidence；assemble-context 形成 selected context；semantic-plan 锁定实体、指标、时间窗口、join path、routePlan、semanticVersion；generate-sql 只是把计划落成 SQL；validate 做 SQL AST、只读、权限、dry-run、成本和语义对齐；correct 只修 correctable error；execute 后 answer 输出 answer、artifact、delivery.evidence、data pack 和 runId。
理解与记忆 · 术语、解析、关联知识点
| 专业术语 | Text2SQL Runtime：从自然语言到 SQL 执行和交付的运行时链路 Selected Context：经过检索、权限过滤和重排后给生成阶段使用的上下文 SQL Artifact：可复查的 SQL、列、行数、预览结果和执行摘要 Correct Loop：SQL 校验失败后有预算的修复循环 |
| 为什么这样回答 | 开口先讲节点和治理，能避免被面试官误解成“调 LLM 写 SQL”。 |
| 小白解析 | 用户问一句话，系统不是马上写 SQL，而是先找相关业务知识和表结构，再写 SQL、检查 SQL、执行 SQL，最后把结果和证据一起交付。 |
| 关联知识点 | text2sql README 和架构文档都把 v2 主链固定为 Text2SQLWorkflowRunner -> RunV2LangGraphStage -> Text2SqlV2LangGraphRunnerService。 |
1 MIN一分钟口语版
如果展开讲，我会把每一步都讲成对象传递。intake 生成 run envelope，里面有 actor、workspaceId、policyVersion、agent scope、riskLevel 和 intentType。retrieve 不全量拿 schema，而是按权限召回 schema chunks、semantic terms、source evidence、historical SQL 和 graph evidence。assemble-context 会记录 permissionFilteredCount、retrievalStatus 和 degradeReasons。semantic-plan 输出 selectedTables、selectedColumns、metrics、filters、timeRange、joinPaths、routePlan、evidenceRequirements 和 semanticVersion。SQL 只是这个 plan 的执行形态。validate 阶段解析 AST，检查单语句、readonly、DDL/DML、危险函数、表字段权限、dry-run、limit、扫描成本，以及 SQL 是否满足 semantic-plan。权限失败、危险 SQL、AST 不完整是 terminal，不进入 correction。最后 delivery 不只是自然语言答案，而是 answer、SQL artifact、evidence、riskTags、data pack 和 runId。
理解与记忆 · 术语、解析、关联知识点
| 专业术语 | Route：把请求分流到 SQL、metadata、澄清、安全拒绝等路径 Semantic Plan：在 SQL 之前确定指标、实体、时间窗口和查询引擎 Dry-run：执行前检查 SQL 可行性、成本和字段权限 Fail-closed：不确定或越权时默认不执行 |
| 为什么这样回答 | 一分钟版要把主路径和分支都讲到，面试官会听出你知道 SQL 失败、权限不明和元数据问题怎么处理。 |
| 小白解析 | 像一个有质检的流水线：先分拣问题，再准备资料，再定查询计划，再写 SQL，再质检，最后交付。 |
| 关联知识点 | 架构文档说明 metadata 问题不一定走 SQL，semantic-plan 可以决定继续 SQL、直接回答、澄清或 fail-closed。 |
FLOW GOALS流程设计目标
不是裸 SQL 生成
Text2SQL 是 Agent Bot 的一个执行引擎，前面要有证据、语义计划和权限边界。
支持多入口
老板问数、投研查询、下游报告 Agent 调用都走同一条 runId 链路，但输出形态不同。
支持多执行计划
简单统计走 SQL，项目新闻走搜索，机构共投走图查询，趋势问题可能要组合执行。
安全先于执行
只读、表权限、字段权限、方言、dry-run 和成本控制都在 execute 前完成。
失败可解释
空结果、SQL 错误、低置信召回、权限不足都进入 evidence 和 riskTags。
交付可回放
每次运行有 runId，报告 Agent 引用数据时能回看当时的上下文、SQL 和结果。
DIAGRAMText2SQL 运行时主链路
从问题到可回放交付
Query Planner 如何选择执行引擎
TABLE关键节点和面试讲法
| 节点 | 职责 | 面试时要强调 |
|---|---|---|
| intake | 分类问题、识别风险、绑定身份和 workspace。 | 它决定后续是否进入 SQL，不能把所有问题都硬转 SQL。 |
| retrieve | 召回 schema、术语、语义资产、来源文档、样例和图谱。 | SQL 生成前要先有证据，不是让模型凭表名猜。 |
| assemble-context | 过滤权限、融合多路证据、形成 selected context。 | 模型看到的上下文应该已经是授权后的世界。 |
| semantic-plan | 确定实体、指标、维度、时间窗口、join path 和执行路由。 | 这是把业务问题变成可执行计划的关键。 |
| generate-sql | 基于 selected context 和 semantic plan 生成 SQL。 | SQL 是计划的落地，不是流程的起点。 |
| validate/correct | 做只读、安全、权限、方言、dry-run 和有限修复。 | 可修复错误有限重试，越权和危险 SQL 直接终止。 |
| execute/answer | 执行查询并映射为 answer、evidence、artifact、data pack。 | 交付同时服务人类界面和下游报告 Agent。 |
面试里要反复强调：Text2SQL 的难点不是“写出能跑的 SQL”，而是让 SQL 来自正确证据、使用正确口径、在正确权限内执行，并且结果可回放。
CONTRACT核心对象字段
| 对象 | 关键字段 | 高强度追问时的回答重点 |
|---|---|---|
| semanticPlan | intentType、entities、metrics、dimensions、filters、timeRange、joinPaths、routePlan、evidenceRequirements、semanticVersion、confidence、riskTags | 它不是 prompt 里的自由文本，而是 generate-sql 和 validate 都要遵守的结构化计划。 |
| selectedContext | schemaChunks、glossaryTerms、sourceEvidence、examples、graphEvidence、permissionFilteredCount、retrievalStatus、contextVersion | 模型只能看到授权后的上下文；无权、过期、低置信、冲突未说明的材料不能进入这里。 |
| sqlValidationResult | astParsed、statementType、readonly、tables、columns、deniedRefs、costEstimate、dryRunStatus、semanticPlanMatched、reasonCode、correctable | 把 pass、correctable、terminal 分清楚；权限、危险 SQL、AST 不完整不能让模型继续修。 |
| delivery.evidence | runId、semanticVersion、policyVersion、selectedEvidenceIds、selectedTables、selectedColumns、artifactRefs、sourceRefs、riskTags、degradeReasons、retrievalStatus、validationSummary | 可信不是模型语气，而是每个结论都能回到表、字段、来源、语义版本、权限版本和运行轨迹。 |
如果面试官追问“给我讲对象 schema”，不要只报字段名，要顺带解释字段如何约束下一步：semanticPlan 约束 SQL，selectedContext 约束模型可见世界，sqlValidationResult 决定能否修复，delivery.evidence 决定能否给报告 Agent 引用。
INTERVIEW MAP面试表达地图
- 先定定位Text2SQL 是系统 Agent 的结构化查询引擎，不等于整个 Agent Bot。
- 再讲主链intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
- 强调分支元数据、澄清、unsafe、unsupported、低置信召回、空结果都不是正常 SQL 路径。
- 落到 RootData项目、机构、融资、Token、解锁、评分、关系图谱这些 Web3 资产是查询对象。
- 收束价值结果以 data pack 和 runId 给人和下游报告 Agent 复用。
SUBAGENTS面试官和候选人模拟
本章继续沿用第一章的两个 subagent 视角：面试官 subagent 负责追问架构边界、失败模式、评测、治理和下游报告 Agent；候选人 subagent 负责把回答压成现场能讲出来的中文，并且把每个观点落到流程节点、数据对象、合同或工程权衡。
本章追问重点：Text2SQL 是不是只有 SQL？SQL 前的证据和语义从哪里来？SQL 后的治理和交付怎么保证可信？
Q&A20 组高强度追问
面试官：你说 Text2SQL 是流程，不是一个 prompt。那完整主链路到底怎么走？第二层追问：哪一步最容易出错？
我会按对象流讲，而不是只背节点名。intake 先生成带 actor、workspaceId、policyVersion、agent scope、riskLevel 的 run envelope；retrieve 召回授权后的 schema、glossary、source evidence 和 historical SQL；assemble-context 记录 permissionFilteredCount、retrievalStatus、degradeReasons；semantic-plan 输出 entities、metrics、filters、timeRange、joinPaths、routePlan、semanticVersion；generate-sql 只是把 plan 落成 SQL；validate 再看 AST、权限、dry-run、成本和 semanticPlanMatched。最容易出错的不是 SQL 语法，而是 schema linking、join path、时间窗口和业务口径，SQL 能跑但业务错比执行失败更危险。
运行时主链路与节点命名：流程章主讲当前 runtime 链路，架构和踩坑章只解释历史命名差异。
理解与记忆 · 背后工程点
背后工程点：回答 Text2SQL 流程时，要把自然语言问题拆到运行时节点，而不是只说“LLM 生成 SQL”。
专业术语：Intake 是识别问题类型、风险和调用方身份的入口阶段；Semantic Plan 是把检索到的证据转成可执行语义计划的阶段；Delivery Contract 是把答案、证据、SQL 工件和 runId 统一交付的结构。
为什么这样回答：这样回答能体现你理解了主链路、失败分支和交付边界。
小白解析：不是用户问一句就让模型写 SQL，而是先理解问题、找资料、定计划、校验 SQL，再执行和交付。
关联知识点：text2sql README 明确主链路为 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
面试官：用户问“最近哪些 AI x Crypto 项目融资热度最高”，你怎么拆成实体、指标、时间窗口和排序逻辑？
先在 intake 识别这是分析型问数，再通过 RAG 找 AI x Crypto 标签、项目实体、融资表、热度评分和时间窗口。semantic-plan 会把它拆成项目标签过滤、融资金额或轮次统计、score_snapshots 趋势、最近时间范围和排序规则，再决定是单 SQL 还是 SQL 加指标快照。
理解与记忆 · 背后工程点
背后工程点：回答 Text2SQL 流程时，要把自然语言问题拆到运行时节点，而不是只说“LLM 生成 SQL”。
专业术语：Intake 是识别问题类型、风险和调用方身份的入口阶段；Semantic Plan 是把检索到的证据转成可执行语义计划的阶段；Delivery Contract 是把答案、证据、SQL 工件和 runId 统一交付的结构。
为什么这样回答：这样回答能体现你理解了主链路、失败分支和交付边界。
小白解析：不是用户问一句就让模型写 SQL，而是先理解问题、找资料、定计划、校验 SQL，再执行和交付。
关联知识点：text2sql README 明确主链路为 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
面试官：Text2SQL 在 Agent Bot 里是主链路还是工具链路？什么时候不用 SQL？
它是结构化数据查询的主工具，但不是所有问题都走 SQL。查项目来源、新闻公告、白皮书引用时更适合 RAG/搜索；查共同投资网络或生态路径时更适合图查询；问“这个指标是什么意思”时可以走 metadata answer。
理解与记忆 · 背后工程点
背后工程点：回答 Text2SQL 流程时，要把自然语言问题拆到运行时节点，而不是只说“LLM 生成 SQL”。
专业术语：Intake 是识别问题类型、风险和调用方身份的入口阶段；Semantic Plan 是把检索到的证据转成可执行语义计划的阶段；Delivery Contract 是把答案、证据、SQL 工件和 runId 统一交付的结构。
为什么这样回答：这样回答能体现你理解了主链路、失败分支和交付边界。
小白解析：不是用户问一句就让模型写 SQL，而是先理解问题、找资料、定计划、校验 SQL，再执行和交付。
关联知识点：text2sql README 明确主链路为 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
面试官：SQL 生成前，如何限制模型只能使用被授权、被建模过的表和字段？
限制不靠 prompt 口头提醒，而是在 retrieve 和 assemble-context 阶段只给它授权后的 schema、字段、join path 和 semantic objects。validate 阶段还会再解析 SQL，检查表字段权限、只读、多语句、方言和 dry-run。
权限校验位置与 fail-closed：权限章主讲治理边界，流程、安全和踩坑章复用同一原则。
理解与记忆 · 背后工程点
背后工程点：回答 Text2SQL 流程时，要把自然语言问题拆到运行时节点，而不是只说“LLM 生成 SQL”。
专业术语：Intake 是识别问题类型、风险和调用方身份的入口阶段；Semantic Plan 是把检索到的证据转成可执行语义计划的阶段；Delivery Contract 是把答案、证据、SQL 工件和 runId 统一交付的结构。
为什么这样回答：这样回答能体现你理解了主链路、失败分支和交付边界。
小白解析：不是用户问一句就让模型写 SQL，而是先理解问题、找资料、定计划、校验 SQL，再执行和交付。
关联知识点：text2sql README 明确主链路为 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
面试官：Query Planner 怎么判断单 SQL、多 SQL、SQL + RAG，还是 SQL + Graph？
semantic-plan 会看问题是否只需要聚合统计，还是需要来源证据、关系路径或时间趋势。比如融资榜单可以单 SQL，项目尽调需要 SQL + RAG，机构共投需要 SQL + Graph，趋势报告可能多 SQL 加时序指标。
Query Planner 路由与避免全工具执行：流程章主讲路由判断，优化章主讲降本，复杂分析章主讲计划拆分。
理解与记忆 · 背后工程点
背后工程点：回答 Text2SQL 流程时，要把自然语言问题拆到运行时节点，而不是只说“LLM 生成 SQL”。
专业术语：Intake 是识别问题类型、风险和调用方身份的入口阶段；Semantic Plan 是把检索到的证据转成可执行语义计划的阶段；Delivery Contract 是把答案、证据、SQL 工件和 runId 统一交付的结构。
为什么这样回答：这样回答能体现你理解了主链路、失败分支和交付边界。
小白解析：不是用户问一句就让模型写 SQL，而是先理解问题、找资料、定计划、校验 SQL，再执行和交付。
关联知识点：text2sql README 明确主链路为 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
面试官：生成 SQL 后有哪些校验层？语法、权限、成本、语义分别放哪里？
validate 会先解析 AST，确认是单语句 readonly，拒绝 DDL/DML、多语句、危险函数、系统 schema、注释绕过；再抽取 tables、columns、joins、filters，和 policyVersion 下的 table/field permission 对齐；然后 dry-run 看方言、limit、扫描范围和 costEstimate；最后做 semantic alignment，比如 plan 要未 TGE，SQL 里必须有 token_status 或 tge_date 约束。validate 结果要带 reasonCode 和 correctable，决定是 pass、bounded correction，还是 terminal fail-closed。
SQL 校验、执行安全与 correct loop：架构章主讲 validate/correct/execute 是主链路，安全章主讲攻击面和终止条件。
理解与记忆 · 背后工程点
背后工程点：回答 Text2SQL 流程时，要把自然语言问题拆到运行时节点，而不是只说“LLM 生成 SQL”。
专业术语：Intake 是识别问题类型、风险和调用方身份的入口阶段；Semantic Plan 是把检索到的证据转成可执行语义计划的阶段；Delivery Contract 是把答案、证据、SQL 工件和 runId 统一交付的结构。
为什么这样回答：这样回答能体现你理解了主链路、失败分支和交付边界。
小白解析：不是用户问一句就让模型写 SQL，而是先理解问题、找资料、定计划、校验 SQL，再执行和交付。
关联知识点：text2sql README 明确主链路为 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
面试官：如果用户问题里有“头部机构”“优质项目”“近期热度”这种模糊词，流程里谁来解释？
不应该由 generate-sql 临场猜。glossary 和 semantic registry 定义这些词的口径，retrieve 找到相关定义，semantic-plan 把它们变成可执行条件，比如机构等级、lead 次数、投资组合质量、近 30 天热度变化。
业务语义、模糊词与默认口径：语义映射章主讲业务词如何落表，语义层和澄清章主讲默认与追问边界。
理解与记忆 · 背后工程点
背后工程点：回答 Text2SQL 流程时，要把自然语言问题拆到运行时节点，而不是只说“LLM 生成 SQL”。
专业术语：Intake 是识别问题类型、风险和调用方身份的入口阶段；Semantic Plan 是把检索到的证据转成可执行语义计划的阶段；Delivery Contract 是把答案、证据、SQL 工件和 runId 统一交付的结构。
为什么这样回答：这样回答能体现你理解了主链路、失败分支和交付边界。
小白解析：不是用户问一句就让模型写 SQL，而是先理解问题、找资料、定计划、校验 SQL，再执行和交付。
关联知识点：text2sql README 明确主链路为 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
面试官：下游报告 Agent 调用 Text2SQL 时，输出为什么不能只是 SQL 结果表？
报告 Agent 需要写可引用内容，所以它要的不只是 rows，还需要 evidence、artifact、chart spec、字段口径、来源和 runId。否则报告文字出了问题，无法判断是 SQL 错、证据错还是报告 Agent 叙事夸大。
证据链、data pack 与报告可追溯：可信结果章主讲 evidence/data pack 合同，其他章只补充报告 Agent 消费与复用场景。
理解与记忆 · 背后工程点
背后工程点：回答 Text2SQL 流程时，要把自然语言问题拆到运行时节点，而不是只说“LLM 生成 SQL”。
专业术语：Intake 是识别问题类型、风险和调用方身份的入口阶段；Semantic Plan 是把检索到的证据转成可执行语义计划的阶段；Delivery Contract 是把答案、证据、SQL 工件和 runId 统一交付的结构。
为什么这样回答：这样回答能体现你理解了主链路、失败分支和交付边界。
小白解析：不是用户问一句就让模型写 SQL，而是先理解问题、找资料、定计划、校验 SQL，再执行和交付。
关联知识点：text2sql README 明确主链路为 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
面试官：SQL 执行失败、空结果、结果异常偏大时，系统怎么降级？
可修复错误进入 bounded correction；权限、危险 SQL、解析不完整直接 fail-closed；空结果要区分真实无数据、时间窗口过窄、实体没解析对；结果过大则触发 limit、聚合建议或澄清。
空结果解释、评测与排查：可信结果章主讲空结果怎么可信解释，评测和可观测章分别处理验证与排查。
理解与记忆 · 背后工程点
背后工程点：回答 Text2SQL 流程时，要把自然语言问题拆到运行时节点，而不是只说“LLM 生成 SQL”。
专业术语：Intake 是识别问题类型、风险和调用方身份的入口阶段；Semantic Plan 是把检索到的证据转成可执行语义计划的阶段；Delivery Contract 是把答案、证据、SQL 工件和 runId 统一交付的结构。
为什么这样回答：这样回答能体现你理解了主链路、失败分支和交付边界。
小白解析：不是用户问一句就让模型写 SQL，而是先理解问题、找资料、定计划、校验 SQL，再执行和交付。
关联知识点：text2sql README 明确主链路为 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
面试官：怎么保证一次 Text2SQL 调用可以被 replay？
runId 贯穿 intake、retrieval bundle、selected context、semantic-plan、SQL、validation、execution summary 和 delivery。复盘时不重新猜当时发生了什么，而是按 runId 回看每一步的输入输出和降级原因。
runId、trace、replay 与回放：可信结果章主讲 runId 可回放，架构、流程、时效和可观测章只从各自链路补充。
- 07-trustworthy-results-evidence-chain · q01
- 01-business-architecture · q13
- 05-pitfalls-architecture-evolution · q08
- 07-trustworthy-results-evidence-chain · q12
- 10-complex-analysis-planning · q11
- 12-freshness-source-consistency · q08
- 13-observability-troubleshooting · q01
- 13-observability-troubleshooting · q02
理解与记忆 · 背后工程点
背后工程点：回答 Text2SQL 流程时，要把自然语言问题拆到运行时节点，而不是只说“LLM 生成 SQL”。
专业术语：Intake 是识别问题类型、风险和调用方身份的入口阶段；Semantic Plan 是把检索到的证据转成可执行语义计划的阶段；Delivery Contract 是把答案、证据、SQL 工件和 runId 统一交付的结构。
为什么这样回答：这样回答能体现你理解了主链路、失败分支和交付边界。
小白解析：不是用户问一句就让模型写 SQL，而是先理解问题、找资料、定计划、校验 SQL，再执行和交付。
关联知识点：text2sql README 明确主链路为 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
面试官：如果 RAG 检索没找到正确 schema，但 LLM 依然生成了一条能跑的 SQL，你怎么处理？
能跑不代表正确。selected context 如果缺少 must-have schema 或指标定义，semantic-plan 应该标记低置信或要求澄清；validate 也要检查 SQL 是否引用了计划外表字段，不能因为执行成功就放行。
RAG 召回为空、低置信与降级：RAG 章主讲搜不到时如何表现，架构和澄清章补充继续、澄清、fail-closed 的边界。
理解与记忆 · 背后工程点
背后工程点：回答 Text2SQL 流程时，要把自然语言问题拆到运行时节点，而不是只说“LLM 生成 SQL”。
专业术语：Intake 是识别问题类型、风险和调用方身份的入口阶段；Semantic Plan 是把检索到的证据转成可执行语义计划的阶段；Delivery Contract 是把答案、证据、SQL 工件和 runId 统一交付的结构。
为什么这样回答：这样回答能体现你理解了主链路、失败分支和交付边界。
小白解析：不是用户问一句就让模型写 SQL，而是先理解问题、找资料、定计划、校验 SQL，再执行和交付。
关联知识点：text2sql README 明确主链路为 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
面试官：metadata 问题为什么不一定进入 SQL？比如“融资强是怎么定义的？”
这是口径解释，不是数据查询。它可以走 retrieve -> assemble-context -> semantic-plan -> answer，直接基于 glossary 或 semantic registry 回答，并附上版本和来源，不需要生成 SQL。
理解与记忆 · 背后工程点
背后工程点：回答 Text2SQL 流程时，要把自然语言问题拆到运行时节点，而不是只说“LLM 生成 SQL”。
专业术语：Intake 是识别问题类型、风险和调用方身份的入口阶段；Semantic Plan 是把检索到的证据转成可执行语义计划的阶段；Delivery Contract 是把答案、证据、SQL 工件和 runId 统一交付的结构。
为什么这样回答：这样回答能体现你理解了主链路、失败分支和交付边界。
小白解析：不是用户问一句就让模型写 SQL，而是先理解问题、找资料、定计划、校验 SQL，再执行和交付。
关联知识点：text2sql README 明确主链路为 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
面试官：correct loop 为什么要有预算？为什么不能一直让模型修到成功？
correct loop 是为了修可执行性，不是给模型绕过治理。列名轻微错误、方言差异、limit 缺失、聚合写法问题可以带 validation reason 回到 generate-sql，但有 retry budget。越权字段、多语句、DDL/DML、危险函数、AST 无法确认表字段、must-have evidence 缺失、semantic-plan 不满足都属于 terminal，直接 fail-closed 或澄清。否则模型可能把“不能查”修成“换个字段偷偷查”。
SQL 校验、执行安全与 correct loop：架构章主讲 validate/correct/execute 是主链路，安全章主讲攻击面和终止条件。
理解与记忆 · 背后工程点
背后工程点：回答 Text2SQL 流程时，要把自然语言问题拆到运行时节点，而不是只说“LLM 生成 SQL”。
专业术语：Intake 是识别问题类型、风险和调用方身份的入口阶段；Semantic Plan 是把检索到的证据转成可执行语义计划的阶段；Delivery Contract 是把答案、证据、SQL 工件和 runId 统一交付的结构。
为什么这样回答：这样回答能体现你理解了主链路、失败分支和交付边界。
小白解析：不是用户问一句就让模型写 SQL，而是先理解问题、找资料、定计划、校验 SQL，再执行和交付。
关联知识点：text2sql README 明确主链路为 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
面试官：Text2SQL 如何处理时间窗口？Web3 里“最近”“本周”“下个月解锁”都很常见。
intake 会记录当前时间和用户时区，semantic-plan 把相对时间变成绝对窗口，并绑定到正确字段，比如 funding_rounds.announced_date、token_unlock_events.unlock_date、score_snapshots.date。delivery 里也要显示口径，避免报告引用时混淆。
理解与记忆 · 背后工程点
背后工程点：回答 Text2SQL 流程时，要把自然语言问题拆到运行时节点，而不是只说“LLM 生成 SQL”。
专业术语：Intake 是识别问题类型、风险和调用方身份的入口阶段；Semantic Plan 是把检索到的证据转成可执行语义计划的阶段；Delivery Contract 是把答案、证据、SQL 工件和 runId 统一交付的结构。
为什么这样回答：这样回答能体现你理解了主链路、失败分支和交付边界。
小白解析：不是用户问一句就让模型写 SQL，而是先理解问题、找资料、定计划、校验 SQL，再执行和交付。
关联知识点：text2sql README 明确主链路为 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
面试官：多租户或套餐权限对 Text2SQL 流程有什么影响？
权限不只影响 execute，还影响检索和上下文。不同 workspace、API key、套餐、agent scope 看到的 schema、字段、来源和数据包不同，模型只能基于授权后的 selected context 生成 SQL。
权限校验位置与 fail-closed：权限章主讲治理边界，流程、安全和踩坑章复用同一原则。
理解与记忆 · 背后工程点
背后工程点：回答 Text2SQL 流程时，要把自然语言问题拆到运行时节点，而不是只说“LLM 生成 SQL”。
专业术语：Intake 是识别问题类型、风险和调用方身份的入口阶段；Semantic Plan 是把检索到的证据转成可执行语义计划的阶段；Delivery Contract 是把答案、证据、SQL 工件和 runId 统一交付的结构。
为什么这样回答：这样回答能体现你理解了主链路、失败分支和交付边界。
小白解析：不是用户问一句就让模型写 SQL，而是先理解问题、找资料、定计划、校验 SQL，再执行和交付。
关联知识点：text2sql README 明确主链路为 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
面试官：如果老板问的是咨询问题，比如“这个项目基本面怎么样”，Text2SQL 在里面怎么发挥作用？
它会成为组合分析的一部分。项目基本面需要 SQL 查融资、团队、Token、评分和事件，也需要 RAG 查来源和新闻，还可能用图查询看投资人关系，最后由 delivery 合成有证据的投研解释。
理解与记忆 · 背后工程点
背后工程点：回答 Text2SQL 流程时，要把自然语言问题拆到运行时节点，而不是只说“LLM 生成 SQL”。
专业术语：Intake 是识别问题类型、风险和调用方身份的入口阶段；Semantic Plan 是把检索到的证据转成可执行语义计划的阶段；Delivery Contract 是把答案、证据、SQL 工件和 runId 统一交付的结构。
为什么这样回答：这样回答能体现你理解了主链路、失败分支和交付边界。
小白解析：不是用户问一句就让模型写 SQL，而是先理解问题、找资料、定计划、校验 SQL，再执行和交付。
关联知识点：text2sql README 明确主链路为 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
面试官：SQL 执行结果如何变成自然语言答案？
answer 阶段不是简单把 rows 贴给模型，而是把 execution summary、列含义、聚合口径、证据、风险标签和图表规格映射到 delivery contract。人看结论，分析师看 SQL artifact，报告 Agent 拿 data pack。
理解与记忆 · 背后工程点
背后工程点：回答 Text2SQL 流程时，要把自然语言问题拆到运行时节点，而不是只说“LLM 生成 SQL”。
专业术语：Intake 是识别问题类型、风险和调用方身份的入口阶段；Semantic Plan 是把检索到的证据转成可执行语义计划的阶段；Delivery Contract 是把答案、证据、SQL 工件和 runId 统一交付的结构。
为什么这样回答：这样回答能体现你理解了主链路、失败分支和交付边界。
小白解析：不是用户问一句就让模型写 SQL，而是先理解问题、找资料、定计划、校验 SQL，再执行和交付。
关联知识点：text2sql README 明确主链路为 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
面试官：怎样避免 Text2SQL 生成错误 join？
join path 不应该靠 LLM 猜。Modeling Layer 维护 relationships，RAG 召回相关关系，semantic-plan 锁定路径，SQL 生成只能在这些路径内组合，validate 阶段再检查引用是否符合授权关系。
Schema linking、schema 变更与 join path：语义映射章主讲 join path，流程和优化章只从生成稳定性角度补充。
理解与记忆 · 背后工程点
背后工程点：回答 Text2SQL 流程时，要把自然语言问题拆到运行时节点，而不是只说“LLM 生成 SQL”。
专业术语：Intake 是识别问题类型、风险和调用方身份的入口阶段；Semantic Plan 是把检索到的证据转成可执行语义计划的阶段；Delivery Contract 是把答案、证据、SQL 工件和 runId 统一交付的结构。
为什么这样回答：这样回答能体现你理解了主链路、失败分支和交付边界。
小白解析：不是用户问一句就让模型写 SQL，而是先理解问题、找资料、定计划、校验 SQL，再执行和交付。
关联知识点：text2sql README 明确主链路为 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
面试官：如果一个问题需要跨数据源，比如项目库加链上指标，Text2SQL 怎么办？
不能硬写一条 SQL。planner 要拆成多个 physical plan，分别走主库、时序或外部指标适配器，再在 delivery 阶段合并成 data pack，并标明来源、时间戳和置信度。
理解与记忆 · 背后工程点
背后工程点：回答 Text2SQL 流程时，要把自然语言问题拆到运行时节点，而不是只说“LLM 生成 SQL”。
专业术语：Intake 是识别问题类型、风险和调用方身份的入口阶段；Semantic Plan 是把检索到的证据转成可执行语义计划的阶段；Delivery Contract 是把答案、证据、SQL 工件和 runId 统一交付的结构。
为什么这样回答：这样回答能体现你理解了主链路、失败分支和交付边界。
小白解析：不是用户问一句就让模型写 SQL，而是先理解问题、找资料、定计划、校验 SQL，再执行和交付。
关联知识点：text2sql README 明确主链路为 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
面试官：面试官问“你这个流程和普通 ChatBI 有什么差别”，你怎么回答？
普通 ChatBI 往往关注自然语言到 SQL，而这里是系统 Agent 的结构化查询引擎。它要服务老板和报告 Agent，所以多了 RAG 证据、语义版本、权限治理、runId、artifact、data pack 和 replay。
理解与记忆 · 背后工程点
背后工程点：回答 Text2SQL 流程时，要把自然语言问题拆到运行时节点，而不是只说“LLM 生成 SQL”。
专业术语：Intake 是识别问题类型、风险和调用方身份的入口阶段；Semantic Plan 是把检索到的证据转成可执行语义计划的阶段；Delivery Contract 是把答案、证据、SQL 工件和 runId 统一交付的结构。
为什么这样回答：这样回答能体现你理解了主链路、失败分支和交付边界。
小白解析：不是用户问一句就让模型写 SQL，而是先理解问题、找资料、定计划、校验 SQL，再执行和交付。
关联知识点：text2sql README 明确主链路为 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
PRINCIPLE本章背诵原则
- 主链要完整：一定说出 intake、retrieve、assemble-context、semantic-plan、generate-sql、validate、correct、execute、answer。
- SQL 不是起点：SQL 来自 selected context 和 semantic-plan，不是模型凭空生成。
- 校验是主链：只读、安全、权限、方言、dry-run、成本控制都必须在 execute 前。
- 失败可解释：空结果、低置信、权限不足、不可修复错误要进入 evidence。
- 交付要复用：answer 给人看，artifact 给分析师查，data pack 给报告 Agent 用，runId 用于回放。