AI 数据 Agent 的「推理税」：每次都在重复学习 Schema

如果你的数据 Agent 每次请求都要重新发现度量定义、表关系和可信查询路径，那你就是在把 LLM 的推理能力浪费在本来就应该已知的事情上。

AI 数据 Agent 正在变得越来越强大。

它们可以解释业务术语、识别候选表、生成 SQL。这看起来像是进步。但从工程视角来看，有一个令人不安的问题：这些工作有多少是真正的新推理，又有多少是 Agent 在重复重新发现企业早已知道的事实？

这种重复工作产生了一个隐藏的成本：推理税（reasoning tax）。

典型的数据 Agent 在查询时做了太多事

思考这个问题：

上季度各客户的收入是多少？

一个典型的 Agent 流水线可能是这样的：

User Question
      ↓
Intent Detection
      ↓
Schema Retrieval
      ↓
Business Term Resolution
      ↓
Candidate Table Selection
      ↓
Relationship Discovery
      ↓
Join Path Selection
      ↓
Metric Construction
      ↓
SQL Generation
      ↓
SQL Validation
      ↓
Execution

另一个问题：

显示 Q2 的客户收入。

分析意图几乎相同。但许多实现会重复大部分流水线。Agent 可能再次检索模式、解析 Revenue、识别 Customer、比较连接路径、选择报表日期。这是浪费的，因为很多信息并不是查询特定的。

将查询时推理与可复用知识分离

一个有用的工程区分是：

Reusable Enterprise Knowledge
vs.
Query-Specific Reasoning

可复用的企业知识

Revenue = Recognized Revenue

Customer = canonical customer entity

Revenue Date = recognition_date

Customer → Order = trusted relationship

Order → Revenue = validated query path

这些不应该在每次请求时都被概率性地重建。

查询特定推理

用户在问什么？

"上季度"指的是财季还是日历季度？

结果应该按客户还是客户细分分组？

用户在问对比吗？

接下来应该调查什么？

这些确实取决于当前请求。设计原则是：

获取已知的。推理未知的。

为什么推理税很重要

有三个直接的工程后果。假设模式检索返回 30 张表，每张有 50 列。Agent 可能在推理开始前就接收了数千个 Token。如果每个查询都重复包含相同的结构信息，Token 消耗会随查询量增长。

Total Token Cost
≈
Requests
×
(Context Tokens + Reasoning Tokens + Output Tokens)

减少重复上下文会直接影响成本。Agent 工作流通常涉及多个模型或工具调用：

Retrieve
→ Classify
→ Resolve
→ Plan
→ Generate
→ Validate

即使每步只花费少量时间，总延迟也会累积。如果一个可信的度量定义可以从确定性服务在毫秒级返回，让 LLM 再次推断它几乎没有价值。重复推理还会引入可变性。一次请求可能产生：

Revenue → invoice_amount

另一次产生：

Revenue → recognized_revenue

再一次产生：

Revenue → order_amount

模型在所有三种情况下可能都表现得合理。架构只是在让它重复解决一个模棱两可的问题。在源头治理定义一次，之后一致地获取它。

模式检索是必要的，但光靠它还不够

一个常见的 NL2SQL 架构是：

Question
   ↓
Embedding Search
   ↓
Relevant Tables
   ↓
LLM
   ↓
SQL

这比发送整个仓库模式要好。但表检索仍然留下未解决的问题：

哪个度量是权威的？

哪个实体是规范的？

哪个关系是可信的？

应该使用哪个日期字段？

哪个连接路径是安全的？

只返回模式的检索仍然在强迫 LLM 重建业务知识。更丰富的查询上下文应该返回更接近这样的内容：

question: "revenue by customer last quarter"

metric:
  name: revenue
  definition: recognized_revenue
  aggregation: SUM

dimensions:
  - customer

time:
  field: recognition_date

tables:
  - customer
  - sales_order
  - finance_revenue

trusted_path:
  - customer
  - sales_order
  - finance_revenue

现在 LLM 不是在发现数据模型。

预计算关系知识

关系推理是查询时不必要推理的主要来源。假设 Agent 需要连接：

Customer

和

Payment

它可能发现几个候选路径：

Customer → Order → Invoice → Payment

Customer → Account → Payment

Customer → Contract → Invoice → Payment

如果组织已经为这个分析场景验证了第一条路径，就没有理由再次比较所有三条路径。关系知识可以使用以下证据提前发现：

Primary / Foreign Keys
Column Naming
Value Overlap
Uniqueness
Inclusion Ratio
Historical Query Patterns
Business Validation

例如：

A = order.customer_id
B = customer.customer_id

Inclusion(A → B)
=
|distinct(A) ∩ distinct(B)|
---------------------------
|distinct(A)|

关系候选可以经历以下流程：

Discovered
    ↓
Candidate
    ↓
Validated
    ↓
Trusted

查询时 Agent 应该优先获取可信结果。

将度量解析移出提示词

度量定义是另一个常见的重复推理来源。不要在每个系统提示词中嵌入：

When the user says revenue, use recognized_amount
from finance_revenue unless...

而是维护一个被治理的度量对象：

{
  "metric": "revenue",
  "version": "2.1",
  "aggregation": "SUM",
  "table": "finance_revenue",
  "column": "recognized_amount",
  "time_field": "recognition_date",
  "status": "active"
}

当需要 revenue 时，Agent 调用：

get_metric_definition("revenue")

并接收当前定义。这有几个优点：一个定义跨 Agent 可用；提示词复杂度降低；LLM 推理更少出错。

在调用 LLM 之前构建查询上下文

一个有用的架构是：

                User Question
                     │
                     ▼
          ┌────────────────────┐
          │ Context Resolver   │
          ├────────────────────┤
          │ Business Terms     │
          │ Metrics            │
          │ Metadata           │
          │ Relationships      │
          │ Trusted Paths      │
          └─────────┬──────────┘
                    │
                    ▼
             Trusted Context
                    │
                    ▼
                  LLM
                    │
             Reason / Generate
                    │
                    ▼
                   SQL

LLM 只接收相关内容。这改变了模型的角色。

原来：

LLM = Data Discovery + Business Interpretation + Reasoning + SQL

改进后：

Data Layer = Known Enterprise Facts

LLM = Intent + Reasoning + SQL / Analysis

一个简单的上下文解析器

从概念上讲，解析器可以这样工作：

def build_query_context(question):
    concepts = resolve_business_terms(question)

    metrics = get_metric_definitions(concepts)
    entities = get_business_entities(concepts)

    metadata = get_relevant_metadata(
        metrics=metrics,
        entities=entities
    )

    relationships = get_trusted_relationships(
        metadata.tables
    )

    return {
        "metrics": metrics,
        "entities": entities,
        "metadata": metadata,
        "relationships": relationships
    }

然后：

context = build_query_context(question)

sql = llm.generate_sql(
    question=question,
    context=context
)

确切实现会各有不同。架构要点是模型不必自己推断每一层企业知识。

在正确的层级缓存稳定知识

并非所有知识的变更频率都相同。

Table Schema
→ 偶尔变化

Metric Definition
→ 偶尔变化

Trusted Relationship
→ 偶尔变化

User Question
→ 每次请求都变化

这意味着需要不同的缓存和刷新策略。系统可以维护：

Metadata Cache
Semantic Cache
Relationship Cache
Query Context Cache

失效由以下触发：

Schema Change
Metric Version Change
Relationship Update
Governance Update

这比把每次查询都当作全新的推理问题来对待要高效得多。

MCP 可以暴露已知层

对于基于 Agent 的架构，MCP可以为可复用企业知识提供干净的接口。

get_metric_definition

get_business_entity

get_table_metadata

get_trusted_relationships

get_query_context

Agent 工作流变为：

Question
   ↓
Agent
   ↓
MCP Tools
   ↓
Enterprise Data Intelligence
   ↓
Trusted Context
   ↓
LLM Reasoning

MCP 不会消除对语义或关系智能的需求。它给了 Agent 一种标准化的访问方式。

不要混淆预计算与硬编码

将知识从查询时推理中移出并不意味着冻结数据模型。企业知识会变化。关系会变化。因此可复用层需要：

Discover
   ↓
Detect Change
   ↓
Evaluate Impact
   ↓
Validate
   ↓
Version
   ↓
Publish
   ↓
Invalidate Cache

目标不是：

再也不推理数据模型。

而是不必在每次请求时都推理相同的既定数据知识。

测量推理税

团队可以让这个问题变得可观测。有用的指标可能包括：

每查询上下文 Token 数

生成前发送的平均 Token 数

每查询推理调用数

SQL 执行前所需的平均 LLM 调用次数

每查询模式候选数

模型必须评估多少表/列？

关系解析率

使用预验证关系的查询百分比

度量解析率

无需 LLM 推断即可解析的业务度量百分比

到首条 SQL 的时间

收到问题
→
生成可执行 SQL

这些指标可以揭示 Agent 是在花大部分时间解决分析问题，还是在重建企业数据模型。

优化目标变了

一个常见的优化问题是：

哪个模型给出最准确的 SQL？

但生产系统还应该问：

我们正在强迫模型执行多少不必要的推理？

一个更强大的模型可能通过成功推理大量噪声上下文来掩盖糟糕的架构。但这不会让架构变得高效。更好的系统可能是给模型更少需要理解的东西。

AI Agent 擅长推理。但推理也是概率性的、昂贵的、比确定性查找更慢的。所以把 LLM 用在它真正创造价值的地方。

如果 Revenue 已经有了一个被治理的定义：

如果 Customer 已经有了一个规范实体：

如果一条连接路径已经被信任：

那么让模型解决真正的新问题：用户在问什么以及如何分析它。

下一代企业数据 Agent 可能不会通过更努力地思考来获胜。它们可能通过知道自己不再需要思考什么来获胜。