CIDR 2026 · Data Agents · Query Collaboration Protocol

QCP-DB：从“先集成数据再查询”转向“数据 Agent 协作查询”

这篇论文提出一个面向未来数据系统的架构愿景：不再要求所有数据先被搬进统一数仓和全局 schema，而是让每个数据源背后有自治 Data Agent，按协议协作完成查询。

论文：Eckmann & Binnig · CIDR 2026 官方 PDF 已本地保存核心概念：QCP / QCP-DB 适用主题：智能问数、数仓、多源数据 Agent

核心结论

做了什么

论文提出 Query Collaboration Protocol，即 QCP。它定义数据 Agent 如何声明自己的数据能力、如何接收自然语言子问题、如何返回局部结果、如何继续提出新的信息需求。

为什么重要

传统数仓依赖全局 schema、ETL、统一建模。数据源增长很快时，先集成再查询成本高。QCP 的目标是让数据留在原处，由 Agent 临时协作。

原型验证

作者实现了 QCP-DB：每个 Agent 包装一个小型关系库，Coordinator 负责任务拆分和路由，Result Agent 负责综合结果。

一句话：MCP 让 Agent 能声明和调用工具；QCP 想让 Data Agent 能声明和协作查询数据源。

它反对的不是数仓，而是“所有问题都必须先集成”

传统 query-by-integration 的前提是：先把数据接入、清洗、统一 schema，再让用户查询。这个方式在稳定核心业务数仓里仍然有效，但在开放数据、多部门临时数据、外部数据源、跨系统探索式问数中会变重。

Data integration vs query collaboration — 图 1：左边是传统数据集成，右边是查询协作。QCP 的目标是让多个自治 Data Agent 通过协作产生答案，而不是先固定一个全局集成 schema。

传统方式

需要预先设计全局 schema、ETL、主外键关系、语义对齐。优点是稳定，缺点是新增源或临时问题成本高。

QCP 方式

每个数据源只声明自己知道什么、能做什么。查询到来时，Coordinator 动态找 Agent，拆分任务，收集中间结果，合成最终答案。

QCP 架构

QCP system sketch — 图 2：QCP-based Query Processing。核心流程是能力注册、协作查询、结果合成。

Capability Registration

Data Agent 向 Coordinator 注册自己有什么数据、支持什么查询能力，例如 SQL、SPARQL、图查询或其他接口。

Query Coordinator

接收用户自然语言问题，选择可能相关的 Agent，把大问题拆成子问题，并安排执行顺序。

Autonomous Data Agent

每个 Agent 在自己的本地数据源上解释子问题，生成局部 SQL 或局部查询，并返回局部结果。

Result Agent

收集 partial results，做字段语义对齐、值标准化、必要 join/union/aggregation，形成最终回答。

关键点：QCP 不是简单“广播给所有 Agent”。论文明确指出全广播成本高且不准，所以需要 Agent selection、query routing、query stack。

QCP-DB 原型怎么跑

QCP-DB prototype — 图 3：QCP-DB 原型。包含 Agent Registry、参与判断、Query Stack、Data Agent 本地 generate-feedback loop、Result Agent 合成。

组件	具体职责	工程含义
Agent Registry	保存每个 Agent 的自然语言能力描述、schema 摘要、可查询能力	类似 MCP tool registry，但对象是数据源 Agent
Agent Selection	Coordinator 先问一批候选 Agent 是否能贡献答案	把数据源发现做成动态过程
Query Stack	用 NeedNode 管理子问题、目标 Agent、依赖关系和执行顺序	智能问数里的任务栈/查询计划
Generate-feedback loop	Agent 本地生成 SQL，执行后检查结果是否满足需求，不满足就修正或提出新 Need	本地 Text-to-SQL + 执行反馈 + 自修复
Scratchpad	共享中间结果，让后续 Agent 使用前序 Agent 的输出	跨数据源 join/映射/补充信息的载体
Result Agent	对齐字段和值，合成最终结果	处理异构数据源语义不一致

{
  "user_query": "哪些欧洲科技公司在 2024 年举办过超过 5000 人的会议？",
  "need_stack": [
    {
      "need": "找出 2024 年欧洲且参会人数超过 5000 的会议",
      "target_agents": ["conference_agent", "geography_agent"]
    },
    {
      "need": "判断会议地点是否在欧洲",
      "target_agents": ["geography_agent"],
      "created_by": "conference_agent"
    },
    {
      "need": "找出会议 host 对应的科技公司",
      "target_agents": ["tech_company_agent"]
    }
  ],
  "result_agent_tasks": ["schema_alignment", "value_normalization", "join", "final_answer"]
}

实验结果

QCP-DB evaluation — 图 4：实验结果。QCP-DB 在水平、垂直、随机拆分数据源的情况下，与完整集成数据库上的 Text-to-SQL baseline 相比保持可比性能；Agent 数量增加时性能下降但不崩。

评测样本

作者从 BIRD dev 中人工选择 50 个更适合多 Agent 协作的查询。

54% → 44%

扩展到更多 Agent

随机拆分下从 4 个 Agent 增加到 7 个 Agent，性能从 54% 降到 44%。协作变难，但下降不是灾难性的。

噪声影响

在强模型设置下，加入数据/字段噪声后准确率只下降约 4%，主要错误来自 SQL 生成、结果不完整和 schema alignment。

注意：这不是成熟 benchmark。样本只有 50 个，且是 proof-of-concept。它证明方向可行，但不能直接说明生产可用。

对智能问数/数仓项目的落地启发

如果你的系统已经用 skill + MCP 连接数据库，可以把 QCP 看作更高一层的数据协作协议：MCP 负责“怎么调用工具/数据源”，QCP 负责“多个数据源 Agent 如何协作回答一个问题”。

QCP 概念	项目映射	建议实现
Data Agent	一个业务域/数据源/数仓主题域的问数代理	每个 Agent 维护 schema 描述、字段口径、样例值、权限和查询能力
Capability Registry	资源目录/字段目录/Agent 能力目录	用自然语言描述 + 结构化 metadata 同时注册
Query Coordinator	总控 skill / planner	先做意图识别，再选择 Agent，拆分 NeedNode
Query Stack	查询任务栈	显式记录子问题、依赖、目标 Agent、输入输出
Scratchpad	中间结果区	保存跨 Agent 映射表、候选 join key、局部结果摘要
Result Agent	答案合成器	负责 schema alignment、value normalization、最终聚合和解释

工程建议：不要一开始就做完全自治网络。先做 3 类 Agent：业务目录 Agent、字段/Schema Agent、SQL 执行 Agent。Coordinator 先用固定策略路由，等日志足够后再做动态路由优化。

评价

创新点

它把数据集成问题重新表述为 Agent 协作问题，并提出 QCP 作为数据查询层协议。这个角度比单纯 Text-to-SQL 更接近复杂企业数据环境。

局限

目前 QCP-DB 仍是原型：数据源规模小、评测样本少、模型依赖强，生产场景还需要权限、安全、事务、一致性、成本控制和可观测性。

结论：这篇适合用来设计“智能问数多 Agent 协作层”。它不是告诉你某个 SQL prompt 怎么写，而是在定义一个更上层的协作执行框架。

资料来源

官方 PDF：https://www.vldb.org/cidrdb/papers/2026/p19-eckmann.pdf

代码仓库：https://github.com/DataManagementLab/A-Vision-for-Autonomous-Data-Agent-Collaboration

本页面根据 CIDR 官方 PDF 本地抽取正文与图表生成。当前环境未暴露 paper2html skill，因此使用等价本地流程完成。