为何每个AI Agent不应重复学习你的数据模型

企业 AI 正在向多智能体架构演进。

不再是创建一个通用助手，组织开始为以下场景构建专用智能体：

这产生了一个容易被忽视的工程问题。

如果每个智能体都独立接收数据库 schema、检索元数据、学习指标定义、发现连接路径，并构建自己的业务理解，那么每个新智能体都变成了一个独立的数据建模项目。

结果不仅是重复的工程工作。

更是重复的企业认知。

更好的架构是将智能体推理与共享数据智能分离。

智能体本地数据知识的问题

一个简单的数据智能体通常长这样：

User
  ↓
Agent
  ├── System Prompt
  ├── Schema Retrieval
  ├── Metric Definitions
  ├── Join Instructions
  ├── SQL Tool
  └── LLM
        ↓
    Database

对于单个概念验证，这样做是合理的。

但想象一下五个团队构建五个智能体：

Sales Agent
Finance Agent
Supply Chain Agent
Support Agent
Analytics Agent

每个团队都要解决相同的问题：

哪些表是相关的？

"客户"是什么意思？

哪个 Revenue 定义是权威的？

客户如何连接到订单？

应该信任哪个数据源？

实现方式可能不同，但底层的企业知识在很大程度上是相同的。

如果这些知识存在于每个智能体内部，重复就开始了。

示例：五个智能体，三个 Revenue 定义

假设一个企业包含：

sales_order.total_amount
finance_invoice.invoice_amount
finance_revenue.recognized_amount
payment.received_amount

销售智能体可能会映射：

Revenue → sales_order.total_amount

财务智能体可能会使用：

Revenue → finance_revenue.recognized_amount

分析智能体可能会检索：

Revenue → finance_invoice.invoice_amount

三个智能体都可能生成语法正确的 SQL。

三个查询都可能成功执行。

但组织现在有了三个 AI 系统，对同一个业务问题给出不同的答案。

问题不在于 LLM 推理。

问题在于业务含义被实现在了每个智能体内部。

业务知识应该成为企业依赖

智能体专属知识与企业范围知识应该分离。

一个智能体可以合法地拥有：

但以下定义不应被重复：

Customer
Revenue
Active Customer
Inventory Balance
Gross Margin

数据关系同样适用：

Customer
   ↓
Order
   ↓
Invoice
   ↓
Payment

这些是企业数据资产。

它们应该是可复用的依赖。

厚智能体与薄智能体

厚智能体包含大量企业特定智能：

Agent
├── LLM
├── Business Semantics
├── Metrics
├── Schema Knowledge
├── Relationship Knowledge
├── Business Rules
├── Query Logic
└── Tools

这造成了耦合。

如果 Revenue 定义改变，多个智能体可能都需要改变。

如果一个可信的连接路径改变，多个 prompt 或工具可能都需要更新。

如果组织切换模型，重要的业务知识可能就被埋在了模型特定的实现中。

一个更薄的设计看起来不同：

Agent
├── LLM
├── Task Logic
├── Planning
└── Tools
      ↓
Shared Data Intelligence
├── Business Semantics
├── Metrics & Dimensions
├── Metadata
├── Trusted Relationships
└── Query Context
      ↓
Enterprise Data

现在智能体不需要每次回答问题时都重新发现企业。

共享数据层应该暴露什么？

共享层不一定是一个单一的庞大服务。

它可以暴露多个可复用能力。

1. 元数据检索

{
  "table": "sales_order",
  "columns": [
    "order_id",
    "customer_id",
    "order_date",
    "total_amount"
  ]
}

但原始元数据本身是不够的。

2. 业务语义

智能体应该能够解析：

"recognized revenue"

metric: revenue
definition: recognized revenue
aggregation: SUM
source:
  table: finance_revenue
  column: recognized_amount

这个定义随后可以被每个授权智能体复用。

3. 关系发现

假设智能体需要客户和支付数据。

它不应该从原始 schema 中猜测连接路径。

关系服务可以返回：

Customer
   ↓ customer_id
Order
   ↓ order_id
Invoice
   ↓ invoice_id
Payment

以及证据或置信度信息。

{
  "path": [
    "customer",
    "sales_order",
    "invoice",
    "payment"
  ],
  "status": "trusted"
}

智能体不是将整个数据仓库 schema 发送给 prompt，而是只接收相关上下文：

Question
   ↓
Resolve Business Concepts
   ↓
Retrieve Relevant Metadata
   ↓
Retrieve Trusted Relationships
   ↓
Generate Query Context
   ↓
LLM

这减少了不必要的上下文，让模型获得更精准的信息。

为什么仅有 Schema 检索是不够的

今天的一种常见模式是：

Question
   ↓
Embedding Search
   ↓
Relevant Tables
   ↓
LLM
   ↓
SQL

它解决了向模型发送数千张表的问题。

但它无法回答：

哪个指标定义是权威的？

哪个关系是可信的？

这张表代表哪个业务实体？

共享数据智能层还必须回答：

对于这个业务问题，什么是有效的？

随着智能体数量的增长，这个区别变得更加重要。

关系知识应该有证据支撑

企业关系通常不能完全用外键来表示。

关系引擎可以使用多种信号：

Database constraints
Naming similarity
Value overlap
Uniqueness
Inclusion relationships
Validated business mappings

A = order.customer_id
B = customer.customer_id

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

高包含率可以提供 A 引用 B 的证据。

但发现的关系不应该自动成为业务真相。

更安全的生命周期是：

Discovered
    ↓
Candidate
    ↓
Validated
    ↓
Trusted

智能体应该优先消费可信关系，而不是独立地发明连接。

MCP 适用于此，但它不是数据模型

MCP 为智能体提供了发现和调用工具的标准化方式。

这使其成为共享数据能力的天然接口。

例如，一个企业数据 MCP server 可以暴露如下工具：

get_metric_definition()

get_table_metadata()

discover_relationships()

get_query_context()

智能体可以这样调用：

Agent
  ↓
MCP
  ↓
Shared Data Intelligence Services

但 MCP 本身不决定：

Revenue 是什么意思

哪个客户定义是权威的

哪个连接路径是可信的

这些决策来自接口背后的数据智能。

一个有用的区分是：

MCP 标准化了访问。共享数据智能标准化了理解。

集中化不等于静态知识

将企业知识移入共享层解决了重复问题，但也产生了另一个责任：

共享知识必须保持最新。

企业系统持续变化：

New tables
New columns
New metrics
New business rules
New relationships

所以共享层需要自己的生命周期：

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

否则组织只是用一套陈旧的中央配置替换了多套陈旧的智能体配置。

当指标改变时会发生什么？

Revenue v1
=
SUM(invoice_amount)

Revenue v2
=
SUM(recognized_amount)

使用智能体本地知识：

Sales Agent → update
Finance Agent → update
Analytics Agent → update
Management Agent → update
Support Agent → maybe update

必须有人发现每个依赖。

使用共享语义：

Revenue Definition
       ↓
Version Update
       ↓
Shared Data Intelligence
       ↓
All Authorized Agents

企业只改变一次定义。

智能体消费更新后的版本。

这是一个更清晰的依赖模型。

共享数据智能也降低了智能体耦合

还有另一个好处。

智能体框架正在快速演进。

组织可能会在以下之间切换：

编排框架；

应用接口。

业务知识应该在这些变化中存活。

如果指标定义、数据关系和业务映射独立于智能体实现，智能体就更容易替换。

这揭示了一个架构原则：

Agents = 可替换的计算 / 推理

Enterprise Data Intelligence = 持久化知识

企业应该拥有对自身的理解。

而不是当前的智能体框架。

一个实用的多智能体数据架构

一个简化的架构可能长这样：

               Sales Agent
                    │
              Finance Agent
                    │
             Analytics Agent
                    │
             Operations Agent
                    │
                    ▼
        ┌──────────────────────┐
        │ Shared Data          │
        │ Intelligence Layer   │
        ├──────────────────────┤
        │ Business Semantics   │
        │ Metrics & Dimensions │
        │ Metadata            │
        │ Relationships        │
        │ Trusted Query Paths  │
        └──────────────────────┘
                    │
                    ▼
             Enterprise Data

共享层不替代智能体。

它让智能体变薄。

它不替代 LLM。

它为 LLM 提供了一致的 企业表示。

第一代企业智能体专注于让单个智能体更有能力。

多智能体时代产生了不同的工程问题：

许多智能体如何共享对企业数据的一个一致理解？

如果每个智能体都独立发现 schema、定义指标、猜测关系，组织将创建重复的逻辑和不一致的答案。

更好的模式是关注点分离：

智能体负责推理。

共享数据智能定义企业的含义。

框架会变。

你的企业不应该每次都重新发现自己的数据模型。