编程 DataBuff 深度拆解：当 APM 学会「多智能体协作」——用 OpenTelemetry + AI 原生架构重写可观测性的心智模型

2026-07-15 15:15:44 +0800 CST views 23

DataBuff 深度拆解：当 APM 学会「多智能体协作」——用 OpenTelemetry + AI 原生架构重写可观测性的心智模型

背景：传统 APM 为什么越来越不够用了

如果你是一名 SRE 或后端工程师，你大概率用过 Jaeger、Zipkin 或者商业 APM 工具。它们的核心能力很清晰：把请求链路追踪出来，把性能指标聚合起来，然后在 Dashboard 上告诉你哪个服务慢了、哪个接口抖了。

这套体系运转了快十年，支撑了无数公司的微服务治理。但进入 2024 年之后，事情开始变得微妙起来——AI Agent 时代来了，而传统 APM 对 AI 工作负载几乎是盲的。

问题出在哪里？

第一，LLM 调用不是 HTTP 请求。 传统 APM 的 Span 模型是基于 RPC 调用的：客户端发请求 → 服务端处理 → 返回响应。但当你调用 gpt-4o-mini 生成一段文案时，这个「调用」的内部发生了什么——Token 怎么流动、模型内部推理了多少步、KV Cache 命中了多少——你从标准的 APM 数据里完全看不到。

第二，多 Agent 协作的调用图是动态的。 一个 AI Workflow 可能涉及 5-10 个 Agent，每个 Agent 调用不同的工具、访问不同的知识库。这种动态生成的工作流，用传统的「预先定义服务拓扑」方式是没办法自动发现的。

第三，根因分析靠人工经验积累。 当告警触发时，SRE 工程师还是要手动去翻 Trace、拼指标、查日志，整个过程高度依赖个人经验，且平均耗时以小时计。

这三个问题，催生了一个全新的赛道：AI 原生可观测性（AI-Native Observability）。而今天要深度拆解的主角——DataBuff，正是这个赛道上一颗正在快速崛起的新星。

什么是 DataBuff：一个 AI 原生的 OpenTelemetry APM

DataBuff（GitHub: databufflabs/databuff，~309 Stars，AGPL-3.0 开源协议）是一款面向 AI 智能体、微服务和云原生场景的AI 原生开源 APM 软件。它的定位非常明确——不是给 APM 加一个 AI 聊天框，而是让 AI 从架构层面接管整个可观测性工作流。

从功能维度来看，DataBuff 包含以下几个核心层次：

1. OpenTelemetry APM 底座

DataBuff 的数据接入层完整遵循 OpenTelemetry（OTel）标准，支持 OTLP 协议接入。这意味着任何已经接入 OpenTelemetry SDK 的服务——无论用 Go、Java、Python 还是 Node.js 编写——无需修改代码，直接往 DataBuff 推数据即可。

支持的采集数据类型包括：

分布式链路追踪（Traces）：完整的请求生命周期，以 Span 为粒度记录每个处理节点的时间与上下文
服务指标（Metrics）：RED 指标体系（Rate / Error / Duration），以及自定义业务指标
服务拓扑（Topology）：基于 Trace 数据自动绘制服务间的依赖关系图，无需手动配置

这是 DataBuff 的「地基」，保证了它作为 APM 工具的通用性。

2. AI 原生分析层（不是外挂）

DataBuff 区别于传统 APM 的核心在于它的 AI 工作台。这里的「AI 原生」不是指在 Dashboard 右上角加一个 ChatGPT 输入框，而是指 AI 深度融入了整个可观测性闭环。

具体能力包括：

自然语言查询（智能问数）：用户可以直接用自然语言提问——「过去一小时里订单服务的 P99 延迟是多少？」、「今天有哪些服务的错误率超过 1%？」——DataBuff 的 AI 层会将其转换为底层的查询语句，在真实的 Trace 和 Metrics 数据中检索，返回基于真实数据的回答。

多智能体协同根因分析：这是 DataBuff 最具工程含量的部分。当系统发生异常时，DataBuff 不是简单地列出相关指标，而是启动一个多 Agent 协作流程——不同职责的 Agent 分别分析 Trace、Metrics、拓扑结构，最后汇总证据链，输出一个结构化的根因结论。这比人类工程师逐个翻 Dashboard 要高效得多。

Skill + Tool 可扩展框架：DataBuff 内置了一组基础数字专家（Skills），用户也可以通过 Skill 框架接入自定义专家，无需修改核心代码。这与当前 AI Agent 领域的 Skill 运动（mattpocock/skills、addyosmani/agent-skills）一脉相承——将最佳实践封装为可复用、可组合的技能单元。

3. MCP 双向开放架构

DataBuff 在集成层面有一个非常前瞻的设计：完整支持 Model Context Protocol（MCP），且是双向的。

平台暴露 MCP：DataBuff 自身作为一个 MCP Server，对外暴露可观测性能力。Cursor、Claude Code 等 AI 编程工具可以直接调用 DataBuff，获取真实系统数据，让 AI 在写代码时就能参考生产环境的实际性能特征。
接入外部 MCP：DataBuff 自身也可以作为 MCP Client，接入外部 MCP Server——例如 Prometheus MCP、SkyWalking MCP——实现多数据源的统一聚合。

这种双向 MCP 架构意味着 DataBuff 不仅仅是一个「被监控的工具」，更是一个可观测性能力平台，可以被其他 AI 系统调用和编排。

4. LLM 可观测性（Roadmap）

根据 DataBuff 的 Roadmap，项目正在规划 AI 应用监控能力，包括：

LLM 调用链追踪：记录每次 LLM 调用的输入 Prompt、输出 Response、Token 消耗和延迟
Token 分析：按服务、按时间维度聚合 Token 消耗，辅助成本分析
Agent 拓扑：自动绘制多 Agent 协作中的调用关系图
技能/工具/模型调用追踪：追踪 Agent 具体调用了哪些工具、加载了哪些技能，帮助团队理解 Agent 的实际行为模式

这些能力一旦成熟，将填补 AI Agent 领域可观测性工具的空白。

5. eBPF 无侵入 APM（Roadmap）

DataBuff 还在规划基于 eBPF 的内核级无侵入采集能力。如果这一特性落地，意味着零代码修改、零 SDK 接入，即可获得微服务的调用链和性能数据。这将极大地降低 APM 的接入门槛——尤其适合那些历史遗留系统或者不方便修改代码的场景。

架构拆解：极简三组件背后的工程哲学

DataBuff 官方将自身架构描述为「极简三组件」：Ingest + Doris + Web。这个描述看似简单，背后却是一套经过仔细权衡的工程选择。

架构概览

┌─────────────────────────────────────────────────────┐
│                   DataBuff 架构                      │
├─────────────────────────────────────────────────────┤
│                                                     │
│  ┌──────────────┐  ┌─────────────┐  ┌───────────┐  │
│  │  数据接入层   │  │  存储分析层  │  │  前端展示  │  │
│  │   (Ingest)   │  │   (Doris)   │  │   (Web)   │  │
│  └──────┬───────┘  └──────┬──────┘  └─────┬─────┘  │
│         │                 │                │        │
│         ▼                 ▼                │        │
│  ┌──────────────┐  ┌─────────────┐         │        │
│  │  OTLP 接收器  │  │  向量+OLAP  │◄────────┘        │
│  │  Trace/      │  │  混合存储    │                  │
│  │  Metrics     │  │             │                  │
│  └──────────────┘  └─────────────┘                  │
│                                                     │
│  ┌──────────────┐  ┌─────────────────────────────┐  │
│  │  AI Agent    │  │  多智能体根因分析引擎         │  │
│  │  工作台      │  │  Skill Framework            │  │
│  └──────────────┘  └─────────────────────────────┘  │
│                                                     │
│  ┌──────────────────────────────────────────────┐   │
│  │         MCP Server / MCP Client              │   │
│  │    Cursor / Claude Code ←→ DataBuff          │   │
│  └──────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────┘

数据接入层（Ingest）

Ingest 层负责接收来自各种数据源的 OpenTelemetry 数据。CNCF 的 OpenTelemetry 生态已经非常成熟，几乎所有主流语言都有对应的 SDK，且支持多种传输协议（gRPC、HTTP/OTLP）。

DataBuff Ingest 层的设计目标很明确：做宽不做深——尽可能多地接收符合 OTel 标准的数据，而不是为每一种特殊场景定制接入方式。

从仓库结构来看，Ingest 模块采用了 Java 语言编写（项目整体 42.4% Java），这与其定位为「企业级可观测性平台」是一致的——Java 在大规模数据接收和处理的生态上非常成熟。

存储分析层（Doris）

DataBuff 使用 Apache Doris 作为底层存储和查询引擎。这是一个值得深入分析的选择。

Doris（前身是百度 Palo，现属 Apache 顶级项目）是一款MPP 架构的分析型数据库，擅长以下场景：

高并发点查询：单表高并发 Key-Value 类型的查询，例如根据 Trace ID 查询某次请求的完整链路
OLAP 分析：多维度聚合分析，例如按服务、按时间窗口聚合 P99 延迟
向量化执行：列式存储 + SIMD 向量化，查询性能远优于传统行式数据库

在 DataBuff 的使用场景中，Doris 需要同时应对两类截然不同的查询模式：实时告警场景下的低延迟点查询（Trace 详情、单个 Span 数据），以及分析场景下的大范围聚合查询（过去 24 小时各服务错误率趋势）。Doris 的统一存储引擎恰好能同时支撑这两类负载，无需引入额外的存储系统——这正是 Doris 在 AP + TP 融合方向上的优势所在。

前端展示层（Web）

DataBuff 的前端采用 Vue（41.4%）+ TypeScript（8.8%）构建，这是一个现代前端技术栈选择。Vue 的组件化开发模式与 DataBuff 需要展示的多维度数据（Screenshots、拓扑图、时序数据）非常契合。

值得注意的是，DataBuff 的前端同时包含了AI 交互界面和传统 APM 监控界面两个部分。AI 交互界面需要支持流式输出（LLM 的响应是一段一段返回的），传统监控界面需要高性能的图表渲染——Vue 的生态中有丰富的图表库和流式组件可以支撑这两个需求。

多智能体根因分析：核心原理与实现路径

这是整篇文章最值得深入拆解的部分。DataBuff 的多智能体根因分析引擎，是如何把「哪个服务有问题」这个模糊问题，转化成一个结构化的根因报告的？

问题建模

在工程实践中，一次生产故障通常表现为多个维度的异常信号同时出现：延迟升高、错误率上升、吞吐量下降。这些信号之间往往存在因果关系——例如，数据库慢查询导致下游 API 响应变慢，进而导致上游服务超时。

传统的告警系统只能告诉你「A 指标异常了」，而 DataBuff 的多智能体系统要做的事情是：从多个角度并行分析这些异常信号，最终合成一条因果链。

Agent 职责设计

从 DataBuff 的架构描述和 GitHub 仓库结构来看，其多 Agent 系统至少包含以下几种角色：

协调 Agent（Orchestrator）：作为整个分析流程的「大总管」，负责任务分解和 Agent 调度。当收到一个告警事件时，协调 Agent 会分析问题的性质，然后并行调度多个专项 Agent，同时启动分析任务。

Trace 分析 Agent：负责深入分析 Trace 数据。它的任务是找出哪一段 Span 的耗时异常，以及这个异常 Span 的上下游是谁。具体来说，它会：

根据告警时间窗口查询相关 Trace
计算每个 Span 的 P50/P95/P99 耗时
识别耗时异常的 Span，记录其 Trace ID 和时间戳
向上下游回溯，找到这条调用链上最可能的「瓶颈节点」

Metrics 分析 Agent：负责分析指标数据。它的任务是判断异常的严重程度和影响范围。它会：

查询 RED 指标：Rate（请求量）、Error（错误率）、Duration（延迟）
将当前值与历史基线对比，判断是否为突发异常
按服务维度聚合，找出影响最大的服务

拓扑分析 Agent：负责分析服务间的依赖关系。它的任务是理解故障的扩散路径。它会：

基于 Trace 数据构建实时的服务拓扑图
识别当前故障服务的上下游依赖
分析是否存在「单点故障」——即某个服务的故障会导致多个下游服务同时受影响

证据合成 Agent：作为最后一棒，负责汇总所有 Agent 的分析结果，生成结构化的根因报告。一份典型的根因报告包含：根因描述（Root Cause）、影响范围（Impact）、证据链（Evidence Chain）、建议的修复措施（Recommendation）。

多 Agent 通信机制

DataBuff 的多 Agent 之间通过结构化消息传递进行协作。每个 Agent 的输出都是一个结构化的「分析单元」，包含：

{
  "agent": "trace-analyzer",
  "confidence": 0.85,
  "findings": [
    {
      "span_id": "abc123",
      "service": "order-service",
      "anomaly_type": "high_latency",
      "duration_p99_ms": 4820,
      "baseline_p99_ms": 320,
      "deviation_ratio": 15.06
    }
  ],
  "next_hop": ["topology-analyzer"],
  "evidence": "..."
}

这种结构化输出设计使得证据合成 Agent 可以方便地聚合多个 Agent 的结果，按照置信度排序，最终生成一份逻辑严密的分析报告。

与传统 AIOps 的本质区别

说到这里，你可能会问：传统的 AIOps 产品（如 Datadog AI、iBM Watson AIOps）也在做类似的事情，DataBuff 的差异在哪里？

核心差异在于架构理念：

传统 AIOps：是一个封闭的智能系统，用户只能消费它输出的结论，无法干预它的分析过程，也很难理解它为什么得出这个结论
DataBuff：将多 Agent 框架完全开放，用户可以查看每个 Agent 的分析过程，理解结论是如何一步步推导出来的；同时，通过 Skill 框架，用户可以定制自己的专家 Agent，注入业务特有的分析逻辑

这种「可解释 + 可扩展」的设计，让 DataBuff 的多 Agent 系统不仅仅是一个生产工具，更是一个可观测性领域的 AI Agent 开发框架。

实战：从零部署 DataBuff 到生产级监控

快速安装（Docker 单机部署）

DataBuff 的部署哲学是「五分钟出效果」。官方提供了一条命令的安装脚本，自动识别 amd64/arm64 架构：

# 安装 DataBuff 平台
curl -fsSL https://databuff.ai/databuff/ai-apm-install.sh | bash

# 安装 Demo 应用（可选，用于验证）
curl -fsSL https://databuff.ai/databuff/ai-apm-demo-install.sh | bash

安装完成后，访问 http://YOUR_HOST:27403，使用默认账号 admin / Databuff@123 登录，然后配置 LLM API Key 启用 AI 功能。

Kubernetes 部署

对于生产环境，DataBuff 支持通过 K8s Manifest 直接安装：

# 安装平台
curl -fsSL https://databuff.ai/databuff/ai-apm-k8s-install.sh | bash

# 安装 Demo 应用
curl -fsSL https://databuff.ai/databuff/ai-apm-demo-k8s-install.sh | bash

如果网络受限无法拉取镜像，官方也提供了离线安装包：

# 下载离线镜像包
curl -fsSL https://databuff.ai/databuff/ai-apm-k8s-download-images.sh | bash

OpenTelemetry 数据接入

以一个 Java Spring Boot 服务为例，接入 DataBuff 仅需引入 OpenTelemetry SDK：

Maven 依赖（pom.xml）：

<dependency>
    <groupId>io.opentelemetry</groupId>
    <artifactId>opentelemetry-api</artifactId>
    <version>1.40.0</version>
</dependency>
<dependency>
    <groupId>io.opentelemetry</groupId>
    <artifactId>opentelemetry-sdk</artifactId>
    <version>1.40.0</version>
</dependency>
<dependency>
    <groupId>io.opentelemetry</groupId>
    <artifactId>opentelemetry-exporter-otlp</artifactId>
    <version>1.40.0</version>
</dependency>

初始化 OpenTelemetry SDK（Java）：

import io.opentelemetry.api.OpenTelemetry;
import io.opentelemetry.api.trace.Tracer;
import io.opentelemetry.api.trace.propagation.W3CTraceContextPropagator;
import io.opentelemetry.context.propagation.ContextPropagators;
import io.opentelemetry.exporter.otlp.trace.OtlpGrpcSpanExporter;
import io.opentelemetry.sdk.OpenTelemetrySdk;
import io.opentelemetry.sdk.resources.Resource;
import io.opentelemetry.sdk.trace.SdkTracerProvider;
import io.opentelemetry.sdk.trace.export.BatchSpanProcessor;
import io.opentelemetry.api.common.Attributes;
import io.opentelemetry.semconv.ResourceAttributes;

public class OpenTelemetryConfig {

    private static final String DATABUFF_OTLP_ENDPOINT = 
        "http://your-databuff-host:4317";

    public static OpenTelemetry initOpenTelemetry() {
        // 配置 OTLP gRPC 导出器
        OtlpGrpcSpanExporter spanExporter = OtlpGrpcSpanExporter.builder()
            .setEndpoint(DATABUFF_OTLP_ENDPOINT)
            .build();

        // 创建 SDK Tracer Provider
        SdkTracerProvider tracerProvider = SdkTracerProvider.builder()
            .addSpanProcessor(
                BatchSpanProcessor.builder(spanExporter)
                    .setMaxQueueSize(2048)
                    .setScheduleDelayMillis(5000)
                    .build()
            )
            .setResource(Resource.create(Attributes.of(
                ResourceAttributes.SERVICE_NAME, "order-service",
                ResourceAttributes.SERVICE_VERSION, "1.0.0",
                ResourceAttributes.DEPLOYMENT_ENVIRONMENT, "production"
            )))
            .build();

        // 构建 OpenTelemetry 实例
        OpenTelemetrySdk openTelemetry = OpenTelemetrySdk.builder()
            .setTracerProvider(tracerProvider)
            .setPropagators(ContextPropagators.create(
                W3CTraceContextPropagator.getInstance()
            ))
            .build();

        // 注册全局实例
        OpenTelemetry.setGlobalOpenTelemetry(openTelemetry);

        return openTelemetry;
    }
}

在业务代码中埋点：

import io.opentelemetry.api.trace.Tracer;
import io.opentelemetry.api.trace.Span;
import io.opentelemetry.api.trace.SpanKind;

public class OrderService {

    private final Tracer tracer;

    public OrderService(OpenTelemetry openTelemetry) {
        this.tracer = openTelemetry.getTracer("order-service");
    }

    public Order createOrder(Long userId, List<OrderItem> items) {
        // 创建一个 Server Span，表示当前服务的处理
        Span span = tracer.spanBuilder("OrderService.createOrder")
            .setSpanKind(SpanKind.SERVER)
            .setAttribute("user.id", userId)
            .setAttribute("order.item_count", items.size())
            .startSpan();

        try (Scope scope = span.makeCurrent()) {
            // 验证订单
            validateOrder(userId, items);

            // 扣减库存
            inventoryService.deductStock(items);

            // 创建订单
            Order order = orderRepository.save(new Order(userId, items));

            // 发送消息通知
            messagePublisher.publish("order.created", order);

            span.setAttribute("order.id", order.getId());
            span.setAttribute("order.total_amount", order.getTotalAmount());
            
            return order;
        } catch (Exception e) {
            span.recordException(e);
            span.setStatus(StatusCode.ERROR, e.getMessage());
            throw e;
        } finally {
            span.end();
        }
    }
}

对于已经在使用 OpenTelemetry 的团队，这个接入过程基本上只需要改一个 OTLP 导出地址即可，零代码改动。

配置 AI 模型

DataBuff 支持多种 LLM 后端，包括 OpenAI 兼容接口和 Anthropic。用户可以根据自己的需求选择：

# config.yaml（DataBuff 模型配置）
model:
  provider: openai  # openai | anthropic | custom
  api_key: ${OPENAI_API_KEY}
  base_url: https://api.openai.com/v1
  model: gpt-4o-mini
  # 或者使用国产模型
  # provider: custom
  # base_url: https://api.deepseek.com/v1
  # model: deepseek-chat

验证接入

完成上述配置后，访问 DataBuff Web 界面，你应该能看到：

服务列表：所有已接入的服务，显示红绿灯状态（正常/警告/异常）
全局拓扑：基于 Trace 数据自动绘制的服务依赖图
AI 工作台：输入自然语言查询，验证 AI 能否正确访问真实监控数据

与主流方案的横向对比

为了帮助你判断 DataBuff 是否适合你的场景，我们从多个维度将它与当前主流的可观测性方案进行对比：

维度	DataBuff	Jaeger	Grafana + Tempo	Datadog AI	SigNoz
定位	AI 原生 APM	链路追踪	可观测性平台	商业 APM + AI	开源 OTel 平台
接入成本	低（OTLP 直推）	中（需部署 Agent）	中	低（Auto-Instrument）	低
AI 能力	多 Agent 原生集成	无	有限（GPT 插件）	有（封闭）	有（OpenAI）
多 Agent 分析	✅ 原生支持	❌	❌	❌	❌
MCP 双向	✅ 支持	❌	❌	❌	❌
LLM 可观测性	✅ Roadmap	❌	❌	✅ 有限	❌
部署复杂度	低（Docker 一键）	中	高	高（云服务）	中
开源协议	AGPL-3.0	Apache 2.0	AGPL-3.0	商业	AGPL-3.0
存储后端	Doris（内置）	Cassandra/ES	S3 + Tempo	托管	ClickHouse

结论：如果你正在构建AI Agent 系统（Multi-Agent Workflow），DataBuff 是目前最贴合这个场景的开源 APM 方案。它的多 Agent 分析能力和 MCP 双向开放架构，是传统 APM 工具完全缺失的能力。如果你只需要基础的链路追踪，Grafana + Tempo 或 Jaeger 依然是最成熟的选择。

性能与生产部署考量

数据量估算

以一个日均请求量 1000 万次的中型微服务集群为例：

每个请求生成约 5-10 个 Span（日均 5000-10000 万 Span）
每个 Span 平均大小 1-2 KB
每天原始数据量约 50-200 GB

DataBuff 使用 Doris 作为存储，Doris 的列式存储和压缩比通常在 1:5 到 1:10 之间，最终存储需求约为 5-40 GB/天。考虑到数据保留策略（通常 7-30 天），总存储需求在 35 GB - 1.2 TB 之间，对于现代服务器来说完全可控。

水平扩展策略

DataBuff 的三个组件可以独立扩展：

Ingest 层：在请求高峰期可以通过增加 Ingest 实例数量来提高接收吞吐。Doris 的 FE（Frontend）和 BE（Backend）节点也支持横向扩展。
Doris：FE 节点负责查询协调和元数据管理，通常 1-3 个即可；BE 节点负责数据存储和查询执行，根据数据量和查询并发按需扩展。
Web 前端：无状态，水平扩展最简单。

告警配置最佳实践

DataBuff 支持两种告警模式：

# 阈值告警：指标超过固定阈值时触发
alerts:
  - name: high_error_rate
    metric: error_rate
    condition: ">"
    threshold: 0.01  # 1%
    evaluation_interval: 1m
    for: 2m  # 持续 2 分钟才触发
    severity: critical

# 突变告警：指标较历史基线发生剧烈变化时触发
alerts:
  - name: latency_spike
    metric: p99_latency
    condition: "baseline_deviation"
    deviation_ratio: 3.0  # 超过基线 3 倍标准差
    evaluation_interval: 5m
    severity: warning

总结：可观测性赛道的范式转移

DataBuff 的出现，标志着可观测性领域正在经历一次从「监控工具」到「智能协作平台」的范式转移。

传统的 APM 工具解决的是「我看到了什么」的问题——把数据收集起来，用图表展示出来。而 DataBuff 正在试图回答一个更深刻的问题：「我理解了为什么，以及我应该做什么」。

这背后的技术驱动力有两个：

第一，多 Agent 架构的成熟。 将 AI 系统分解为多个专业化 Agent，Agent 之间通过结构化消息协作——这个模式在软件工程领域已经被验证是有效的。DataBuff 将这个模式引入可观测性领域，让 AI 不再是一个「答案输出机」，而是一个「分析团队」。

第二，OpenTelemetry 的统一。 OTel 的普及让数据接入成本大幅降低，DataBuff 无需为每种语言、每种框架单独做接入适配。所有遵循 OTel 标准的数据源，都可以无缝接入 DataBuff——这大大加速了 DataBuff 的生态建设。

对于工程师来说，DataBuff 带来的启示是：AI 可观测性不再是一个「未来愿景」，而是一个可以在今天落地的工程实践。如果你正在构建 AI Agent 系统，DataBuff 提供了一套完整的可观测性基础设施，让你的 AI 系统真正变得「可观测、可解释、可干预」。

项目地址：https://github.com/databufflabs/databuff
官网：https://www.databuff.ai
在线 Demo：demo.databuff.ai（需加入交流群获取账号）

参考资料

DataBuff GitHub 仓库：https://github.com/databufflabs/databuff
OpenTelemetry 官方文档：https://opentelemetry.io/docs/
Apache Doris 官方文档：https://doris.apache.org/docs/
Model Context Protocol 规范：https://modelcontextprotocol.io/
多智能体系统可观测性：CSDN 《Multi-Agent系统可观测性》2026-07