问数 Agent 整体架构、意图识别、历史上下文与 NL2SQL

第48题：问数 Agent 整体架构、意图识别、历史上下文与 NL2SQL

1. 来源边界

原表明确标注：

本题属于 T5 技术扩展题，可以用于备考，不能表述为已经核验的相关真实面试题。

同时需要注意一个来源边界。

题目虽然写了：

整体架构；
意图识别；
历史上下文；
NL2SQL；

但原表参考回答实际详细展开的主要内容是：

历史上下文与任务状态管理。

原表直接支持的内容包括：

不要把全部 Conversation 当作任务状态；
建立 Task / Subtask ID；
区分 Active / Suspended / Cancelled；
保存不可丢失约束；
保存关键 Decision；
保存 Artifact Reference；
Summary 必须可重建并保留 Provenance；
用户切换话题时显式确认挂起或取消；
撤销旧子任务的 Worker Lease；
忽略取消任务的 Late Result；
通过 Constraint Replay 和 Regression Sample 检测 Context Compression Loss；
验收要覆盖越权、注入、重复执行、依赖故障、人工接管和回滚。

下面"整体架构、Intent Routing、NL2SQL"部分属于基于题目措辞和外部技术资料进行的扩展。

2. 核心回答

如果让我设计一个企业问数 Agent，我会把它拆成六层：

text 复制代码

User
↓
Conversation / Task State
↓
Intent Router
↓
Business Semantic Layer
↓
NL2SQL Planning & Validation
↓
Read-only Data Execution
↓
Result Validation & Explanation

进一步展开：

text 复制代码

用户问题
   ↓
Session / Task Manager
   ↓
Intent Classification
   ↓
Entity / Metric / Time Extraction
   ↓
Business Glossary Retrieval
   ↓
Schema Linking
   ↓
SQL Generation
   ↓
SQL AST / Permission / Cost Validation
   ↓
Read-only Execution
   ↓
Result Validation
   ↓
Natural Language Answer
   ↓
Trace / Audit / State Update

系统成功的标准应同时满足：

BusinessCorrect∧SQLCorrect∧Authorized∧ResultCorrect BusinessCorrect \land SQLCorrect \land Authorized \land ResultCorrect BusinessCorrect∧SQLCorrect∧Authorized∧ResultCorrect

只生成语法合法的 SQL 远远不够。

3. 整体架构可以怎么设计

一个比较完整的问数 Agent 可以包含：

text 复制代码

┌────────────────────────────┐
│ User / BI Frontend         │
└──────────────┬─────────────┘
               ↓
┌────────────────────────────┐
│ Session & Task State       │
│ Task / Subtask / Context   │
└──────────────┬─────────────┘
               ↓
┌────────────────────────────┐
│ Intent Router              │
│ Intent + Slots + Confidence│
└──────────────┬─────────────┘
               ↓
┌────────────────────────────┐
│ Semantic Layer             │
│ Metric / Dimension / Rule  │
└──────────────┬─────────────┘
               ↓
┌────────────────────────────┐
│ Schema Retrieval           │
│ Table / Column / Join      │
└──────────────┬─────────────┘
               ↓
┌────────────────────────────┐
│ NL2SQL Planner             │
└──────────────┬─────────────┘
               ↓
┌────────────────────────────┐
│ SQL Guard                  │
│ AST / ACL / Cost / Limit   │
└──────────────┬─────────────┘
               ↓
┌────────────────────────────┐
│ Query Executor             │
│ Read-only DB Credential    │
└──────────────┬─────────────┘
               ↓
┌────────────────────────────┐
│ Result Validator           │
└──────────────┬─────────────┘
               ↓
┌────────────────────────────┐
│ Answer Generator           │
│ Result + Metric Definition │
└────────────────────────────┘

4. 为什么要先做 Intent Recognition

用户问数并不总是在请求 SQL。

例如：

text 复制代码

销售额是多少？

属于：

text 复制代码

Metric Query

用户问：

text 复制代码

销售额这个指标怎么算？

属于：

text 复制代码

Metric Definition

用户问：

text 复制代码

为什么华东地区下降了？

可能属于：

text 复制代码

Drill-down / Diagnostic Analysis

用户说：

text 复制代码

把刚才那个改成按月份看。

属于：

text 复制代码

Follow-up Transformation

用户说：

text 复制代码

把这些数据导出成 CSV。

属于：

text 复制代码

Action / Export

因此第一阶段需要判断：

Intent(x) Intent(x) Intent(x)

再选择对应执行路径。

5. Intent 可以怎样分类

一个基础分类可以包括：

Intent	说明
`metric_query`	查询一个指标
`trend_query`	时间趋势
`comparison_query`	维度比较
`drilldown_query`	下钻分析
`metric_definition`	询问业务口径
`nl2sql_query`	需要执行数据库查询
`followup_modify`	修改上轮分析条件
`export`	导出结果
`clarification`	信息不足，需要澄清
`unsupported`	当前系统无法处理

真正实现时，分类数量应由具体业务决定。

6. Intent Router 最好输出结构化结果

例如用户：

text 复制代码

帮我看今年华东地区各季度的净收入。

Router 可以输出：

json 复制代码

{
  "intent": "trend_query",
  "metric": "net_revenue",
  "dimensions": ["region"],
  "filters": {
    "region": "华东"
  },
  "time_range": "current_year",
  "time_granularity": "quarter",
  "confidence": 0.94,
  "need_clarification": false
}

然后由代码判断：

text 复制代码

intent == trend_query
↓
进入 Data Query Pipeline

这种设计更容易进行：

Test；
Trace；
Debug；
权限判断；
回归测试。

7. Intent Confidence 低时应该怎么办

例如用户问：

text 复制代码

看一下增长情况。

缺少：

什么指标；
什么时间；
什么对象。

此时 Agent 不应该强行生成 SQL。

可以输出：

json 复制代码

{
  "intent": "clarification",
  "missing": [
    "metric",
    "time_range"
  ]
}

然后询问：

text 复制代码

你希望看哪个指标，以及哪个时间范围？

这样可以降低：

WrongAssumption→WrongSQL WrongAssumption \rightarrow WrongSQL WrongAssumption→WrongSQL

的风险。

8. 为什么企业问数需要 Business Semantic Layer

这是 NL2SQL 中非常关键的一层。

例如用户问：

text 复制代码

GMV 是多少？

数据库中可能没有：

text 复制代码

gmv

这个字段。

业务定义可能是：

$$

GMV

\sum order_amount

ConstraintRetentionRate

\frac{

N_{\text{retained constraints}}

}{

N_{\text{required constraints}}

}

### 31. NL2SQL 应该怎么评估 我会分四层评测。 #### 31.1 Intent 层 例如： ```text Intent Accuracy Macro-F1 Confusion Matrix ``` 同时评估： * Metric Extraction； * Dimension Extraction； * Time Range Extraction。 #### 31.2 SQL 层 评估： * Parse Success； * Execution Success； * Execution Accuracy； * Forbidden SQL Rate。 例如： ##

ExecutionAccuracy

\frac{

N_{\text{queries producing expected result}}

}{

N_{\text{test}}

}

SQL Exact Match 可以作为辅助指标。 两个 SQL 字符串不同，仍可能产生相同正确结果。 #### 31.3 Business 层 测试： * Metric Definition Correctness； * Filter Correctness； * Time Grain Correctness； * Join Correctness； * Unit Correctness； * Join Cardinality Correctness； * Aggregation Grain Correctness。 对于涉及一对多关系的指标，需要加入专门回归样例。 例如净收入： ```text Case 1: 100 元订单，无退款 Expected = 100 元 Case 2: 100 元订单，退款 10 元 Expected = 90 元 Case 3: 100 元订单，退款 10 元和 20 元 Expected = 70 元 ``` 这类测试可以直接检查： ```text 一对多 Join ↓ 订单金额是否重复 ↓ 退款是否先按订单聚合 ↓ 最终业务指标是否正确 ``` #### 31.4 End-to-End 层 最终看： ```text 用户问题 ↓ 正确结果 ↓ 正确解释 ``` 可以定义： ##

TaskSuccessRate

\frac{

N_{\text{correct end-to-end answers}}

}{

}

### 32. 为什么传统 Text-to-SQL Benchmark 不足以代表企业问数 Spider 2.0 的公开研究已经表明，真实企业 Text-to-SQL 通常需要： * 大型 Schema； * 多种数据库； * SQL Dialect； * Metadata Search； * 多条 SQL； * 数据转换； * 项目代码； * 长上下文。 Spider 2.0 中很多数据库拥有超过： ```text 1000 columns ``` 其任务复杂度明显高于传统单条 Text-to-SQL。 2026 年 EntSQL 又进一步研究： **企业 SQL 经常依赖内部业务文档和指标定义。** 这与问数 Agent 的实际问题高度一致。 系统需要同时完成： ```text 理解数据库 ``` 以及： ```text 理解企业业务语义 ``` ### 33. NL2SQL 安全测试应该覆盖什么 #### 33.1 Unauthorized Table 用户没有权限的表： ```text 必须拒绝。 ``` #### 33.2 Sensitive Column 例如： ```text salary phone id_card ``` 未经授权不能查询。 #### 33.3 Write SQL 模型生成： ```text DELETE / UPDATE ``` 必须阻断。 #### 33.4 Expensive Query 超大扫描： ```text Reject / Require Approval ``` #### 33.5 Prompt Injection 数据库 Metadata 中出现恶意自然语言时： ```text 不能改变系统权限。 ``` #### 33.6 Cross-Tenant Tenant A： ```text 无法读取 Tenant B。 ``` ### 34. 整个系统需要记录什么 Trace 建议记录： ```text trace_id session_id task_id subtask_id intent intent_confidence metric business_rule_version schema_version selected_tables sql sql_ast_hash permission_decision query_plan execution_time rows_returned result_artifact answer state_transition ``` 这样出现错误时可以判断： ```text Intent 错了？ Metric 错了？ Schema Linking 错了？ SQL 错了？ 权限错了？ 数据库数据错了？ Answer 解释错了？ ``` ### 35. 一个典型执行例子 用户： ```text 今年华东地区净收入同比增长多少？ ``` #### 35.1 Intent ```json { "intent": "comparison_query", "metric": "net_revenue", "region": "华东", "time_range": "current_year", "comparison": "YoY" } ``` #### 35.2 Business Semantic Retrieval 得到： ```text net_revenue = paid_amount - refund_amount ``` 并读取其： ```text version owner time_column ``` #### 35.3 Schema Linking 找到： ```text orders refunds customers ``` 同时需要检查： ```text orders : refunds = 1 : N ``` 如果退款表允许一笔订单对应多条退款记录，则应先将退款聚合到： ```text order_id ``` 粒度，再与订单表关联。 #### 35.4 SQL Planning 分别计算： ```text Current Year Previous Year ``` 并保证净收入的计算遵循： ```text Refunds ↓ GROUP BY order_id ↓ Orders LEFT JOIN Aggregated Refunds ↓ Order-level Net Revenue ↓ Time / Region Aggregation ``` #### 35.5 SQL Guard 检查： ```text SELECT only Authorized tables Authorized columns Query cost ``` #### 35.6 Execution 使用： ```text Read-only Credential ``` #### 35.7 Result 假设： ```text 2026 = 120M 2025 = 100M ``` 计算： ##

YoY

\frac{120-100}{100}

20%

35.8 Final Answer

text 复制代码

2026 年至今华东地区净收入同比增长 20%。

口径：
净收入 = 已支付金额 - 已退款金额。

比较区间：
2026 年至今 vs 2025 年同期。

并提供：

text 复制代码

SQL / Metric Definition / Data Freshness

供用户复核。

36. 面试官如果问"为什么不直接把历史都塞进去"

可以回答：

全量历史适合保留审计和重放，但不适合直接等同于当前业务状态。长期对话中会同时存在旧话题、已取消任务、历史 Tool Result 和过期业务约束，如果全部直接交给模型，容易产生状态污染和 Token 成本。

我会单独维护 Task State，包括 task/subtask ID、当前 Intent、Metric、Time Range、Active/Suspended/Cancelled 状态、不可丢失约束和 Artifact Reference。Conversation History 仍保留，但当前执行主要读取结构化 Task State。

Summary 可以用于压缩上下文，但必须保留 Provenance，并通过 Constraint Replay 和 Regression Case 验证关键条件没有在压缩过程中丢失。

这一部分最贴近原表参考答案。

37. 面试官如果问"NL2SQL 最难的地方是什么"

可以回答：

企业 NL2SQL 最难的部分通常包含业务语义、Schema Linking、权限、数据粒度和结果正确性几个方面。

例如"净收入"可能不是数据库字段，而是公司定义的指标公式。所以系统需要先从 Metric Glossary 找到业务定义，再检索相关表、字段和 Join Path。

Schema Linking 还需要处理关联基数。例如一笔订单可能对应多条退款记录。直接关联后再汇总订单金额会产生重复计数，因此需要先把退款聚合到订单粒度，再计算净收入。

SQL 生成以后还要经过 AST、ACL、Cost 和 Read-only 校验。执行成功以后还要检查结果口径、单位、时间范围、聚合粒度和异常值。

所以我的验收标准是最终业务结果正确，同时满足权限和资源约束。

38. 面试时可以压缩成下面这段

问数 Agent 我会拆成 Session/Task State、Intent Router、Business Semantic Layer、Schema Retrieval、NL2SQL、SQL Guard、Read-only Executor 和 Result Validator 几层。

首先对用户问题做结构化 Intent Recognition，识别 Intent、Metric、Dimension、Filter、Time Range 和 Confidence。信息不足就先 Clarification。

NL2SQL 之前需要先做 Business Semantic Resolution，因为企业里的"GMV、净收入、活跃用户"通常都有具体业务口径，单靠数据库 Schema 不一定能确定。确定指标后再做 Schema Linking，找到相关表、字段和 Join Path。

Schema Linking 还需要判断数据粒度和 Join Cardinality。例如一笔 100 元订单存在 10 元和 20 元两次退款，正确净收入是 70 元。直接连接订单和退款后汇总可能重复计算订单金额，所以应先按 order_id 聚合退款，再与订单表关联，并用未退款、部分退款、多次退款三类样例做回归验证。

SQL 不能直接执行。我会先 Parse AST，限制为允许的只读语句，再检查表列权限、Tenant、查询 Cost 和 Row Limit，最后使用最小权限的 Read-only Database Credential 执行。执行成功后还需要验证结果范围、单位、时间口径、关联基数和业务规则。

历史上下文方面，我不会直接把全部 Conversation 当成状态。我会维护 task/subtask ID、Active/Suspended/Cancelled、不可丢失约束、Decision 和 Artifact Reference。用户换话题时显式挂起或取消旧任务，并撤销旧 Worker Lease，Late Result 不再写入新任务。Summary 必须可重建并保留 Provenance，还要用 Constraint Replay 验证压缩没有丢关键信息。

评测时分别看 Intent Accuracy、Slot Extraction、SQL Execution Accuracy、Business Correctness、Unauthorized Query Rate 和 End-to-End Task Success。

一句话总结：

问数 Agent 的关键链路是"理解业务问题 → 解析业务口径 → 找到正确 Schema 和数据粒度 → 安全地产生并执行 SQL → 验证结果 → 管理好多轮任务状态"。

39. 当前资料能够确定到什么程度

39.1 原表直接支持

原表明确支持：

Conversation 不能直接等同 Task State；
Task / Subtask ID；
Active / Suspended / Cancelled；
不可丢失 Constraint；
Decision；
Artifact Reference；
Summary 可重建；
Provenance；
话题切换时确认 Cancel / Suspend；
撤销旧 Worker Lease；
Late Result 丢弃；
Constraint Replay；
Regression Sample；
Context Compression Loss；
越权测试；
Prompt Injection 测试；
Duplicate Execution；
Dependency Failure；
Human Takeover；
Rollback；
Trace；
Audit。

39.2 原表未提供、由外部资料扩展

原表没有具体给出：

问数 Agent 完整模块架构；
Intent Taxonomy；
Intent Confidence；
Metric Semantic Layer；
Schema Linking；
NL2SQL Prompt；
SQL AST Validator；
Read-only Transaction；
EXPLAIN Cost Gate；
Execution Accuracy 指标；
一对多 Join 的聚合粒度校验。

这些内容属于本次外部研究后的技术扩展，不能归因于原始面经答案。

40. 来源

原始题目表，第 48 题（T5）：问数 Agent 整体架构、意图识别、历史上下文与 NL2SQL。
OpenAI Agents SDK --- Agent Orchestration / Handoffs / Running Agents：当前文档提供结构化分类后由代码路由、Handoff，以及 Session/Conversation State 管理模式。
LangGraph Documentation --- Memory Overview：说明短期 Memory 可以包含 Conversation History 和其他 Agent State，并指出长历史可能增加成本、延迟和旧信息干扰。
Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows：说明真实企业 Text-to-SQL 涉及大型 Schema、元数据检索、SQL 方言和复杂多步工作流。
EntSQL: A Benchmark for Grounding Text-to-SQL in Long-Context Enterprise Knowledge, 2026：说明企业 NL2SQL 经常依赖私有业务指标、报表规则和企业内部知识。
OWASP SQL Injection Prevention Cheat Sheet：强调数据库账号最小权限，并可使用 View 等机制限制数据访问范围。
PostgreSQL Documentation --- SET TRANSACTION / Read-only Transaction：说明 Read-only Transaction 会禁止多种数据修改和 DDL 操作。
PostgreSQL Documentation --- EXPLAIN：说明可在执行前查看 Query Plan 与估计执行 Cost。