阿里云为何要将数据采集开发套件开源

随着 Agent 的不断演进和供应链的持续繁荣，数据采集正从传统的运维工具进化成为决定 Agent 品质的核心基础设施。为什么这么说呢？以下我们从 Agent 的服务可用性、Agent 的输出可靠性，以及 Agent 成本三个维度来分析。

一个典型的 Agent 应用，远比传统应用复杂得多。

在用户终端之外，Agent 往往还包含认证与权限体系、会话与上下文管理、推理服务、大模型路由与降级策略、流程编排引擎等核心模块。同时，模型推理本身又高度依赖外部世界：它可能会调用多个模型服务，通过工具执行真实操作，借助向量数据库维护长期记忆，再通过缓存机制控制 LLM 的重复调用成本。

这些组件共同构成了一条高度动态、跨系统、跨语义的执行链路。数据类型更多、来源更分散、关联关系更复杂，这已经不是传统软件可以类比的应用形态了。

在这种背景下，孤立的数据几乎没有价值。

只有将模型、工具、流程与基础设施产生的信号统一关联起来，才能真正回答：系统到底哪里出了问题？这就要求数据采集具备三个能力：统一的数据语义、低成本且高质量的采集方式，以及端到端的全链路追踪能力。

Agent 与传统软件的根本差异，在于其自主决策特性。

它涉及多模态输入、大模型推理、工具调用和状态反馈等多层交互，本质上是一种非线性工作流。当这种工作流被投入真实业务场景后，任何一个节点的不确定性，都会被后续步骤不断放大，最终影响整体结果。

因此，AI 的非确定性，或者说没有标准答案，催生了评估经济。

评估开始从阶段性工作，演进为一种持续存在的工程实践。评估不再发生在系统上线之后，而是与开发过程并行展开。这背后逐渐形成了一种新的治理范式：由可观测性（包含数据采集）、度量框架（Benchmark）以及自动化评估共同构成的 Agent 治理体系。在这个体系中，高质量、可关联的数据，是一切评估与改进的前提。

当 Agent 与模型进行多轮交互时，Token 消耗往往呈指数级增长。在某些复杂场景下，系统甚至可能陷入无止境的推理循环，形成典型的“Token 黑洞”。

如果缺乏链路级的可观测能力，开发者既无法判断消耗发生在哪一环，也无法评估优化的真实收益。系统的成本控制，最终只能依赖经验与猜测。而一旦具备端到端的观测能力，决策就有了依据：哪些步骤值得保留，哪些推理可以裁剪，哪些工具调用正在制造不必要的消耗。

而统一的数据采集是建立端到端的观测能力的前提。

正是在这样的技术背景下，阿里云选择开源 LoongSuite 数据采集开发套件，希望在顺应 AI 工程演进趋势的同时，帮助更多企业以更低的成本、更高的效率，构建标准化、可持续演进的可观测体系。

• LoongCollector

• 核心数据采集引擎

LoongCollector 除了主机探针的能力，作为核心数据采集引擎，还实现了多维度观测数据的统一处理，从原始数据采集到结构化转换，再到智能路由分发，整个流程通过模块化架构实现灵活编排。这种架构使观测数据既可对接开源分析平台实现自主治理，也可无缝衔接托管服务构建云原生观测体系。

从工程实现角度看，LoongSuite 的设计目标非常明确：在不干扰业务的前提下，把该采的都采到，把不该付出的成本降到最低。

• 零侵入采集：通过进程级插桩与主机级探针结合，无需修改代码即可捕获全链路数据。
• 全栈支持：覆盖 Java、Go、Python 等主流语言，适配当前绝大多数 AI 应用形态。
• 生态兼容：LoongSuite 可以看做是 OpenTelemetry 的一个发行版^[1]，深度兼容 OT，遵循社区 GenAI 语义规范，并基于上游进行同步；此外，我们在 AI 场景下做创新功能的孵化器，会持续把新特性贡献给 OTel 社区。例如像 Go 探针，我们已经捐献给社区了。

在此基础之上，LoongSuite 内的 LoongCollector 进一步提供了三项关键能力。

在 Agent 场景中，单一视角已经无法解释系统行为。

一个看似简单的用户请求，背后往往同时涉及模型推理、工具调用、上下文检索和状态更新等多个步骤。日志只能回答“发生了什么”，指标只能反映“整体是否异常”，而 Trace 只能展示“调用顺序”。如果这些信号彼此割裂，工程师面对的永远是片段化的事实，既无法判断问题的根因，也难以评估一次优化是否真正生效。

LoongCollector 将 Logs、Metrics、Traces、Events、Profiles 统一纳入同一采集与关联体系，本质上是在还原 Agent 的真实执行过程，让问题不再停留在“感觉不对”，而是可以被完整描述、复现和分析。LoongCollector 采用 All-in-One 架构，支持包括 Logs、Metrics、Traces、Events、Profiles 的全类型数据采集，同时通过 eBPF 实现进程外采集，降低业务干扰。

极致的性能与稳定性是数据采集层不可妥协的前提。

采集系统位于业务系统的关键路径，一旦自身引入额外抖动，影响往往会被迅速放大。尤其是在 Agent 应用中，多轮推理和频繁的工具调用会带来突发性的数据洪峰，如果采集组件在高并发下出现锁竞争、阻塞或无序堆积，很容易将原本可控的性能波动升级为全链路问题。

LoongCollector 通过时间片调度、无锁化设计、高低水位反馈队列与持久化缓存，在高并发场景下实现低资源消耗与高吞吐，确保数据不丢失、系统不抖动，保障业务稳定性。

灵活部署与智能路由能力，决定了这套采集体系能否适应持续演进的 AI 工程实践。

可观测系统并非一次性建设完成，随着模型、框架和业务形态的变化，数据的价值密度和使用方式都会不断调整。如果采集层与下游存储、分析系统强耦合，每一次调整都意味着重构和风险累积。

LoongCollector 通过模块化架构，将采集、处理与分发解耦，使不同来源、不同语义的数据可以在采集层完成结构化转换，并根据策略被路由至不同的下游系统。这种设计让工程团队可以在不破坏既有体系的前提下，引入新的分析平台或评估系统，从而保证可观测能力能够伴随 Agent 应用一同演进，而不是成为制约创新的瓶颈。

在 AI 时代，数据采集早已不是一个“实现问题”，而是一个生态问题。

一方面，Agent 应用的复杂性正在快速外溢。无论是基于低代码平台快速拼装的 Agent，还是在高代码框架中精细打磨的复杂系统，其技术栈、运行形态和交互模式都高度多样化。如果数据采集能力被封装在单一厂商或封闭体系中，就不可避免地面临覆盖不足、语义割裂和适配成本指数级上升的问题。可观测性要真正成为 AI 的基础设施，前提是它必须先成为公共能力。

另一方面，AI 可观测正在形成事实上的行业共识和技术标准。从 OpenTelemetry 在可观测领域的成功经验可以看到：只有通过开源，才能在语义规范、数据模型和采集方式上形成最大公约数，避免重复造轮子，也避免各自为政。尤其在 Agent 场景下，函数调用、工具使用、推理链路、评估结果等新型信号层出不穷，任何一家厂商都不可能独立定义标准答案。开源，是对不确定性最务实的回应。

从工程视角看，开源也是对性能与成本的长期负责。数据采集位于系统最底层，运行在主机、容器和进程的关键路径上，任何额外开销都会被成倍放大。通过开源，LoongSuite 能够在更广泛的真实生产环境中被验证、被审视、被优化，让极致性能不再只是实验室指标，而是在社区共建中不断逼近的工程现实。

更重要的是，阿里云并不希望 LoongSuite 只是“另一个采集器”。将其开源，意味着它不只服务于某一个平台或产品，而是成为 AI 可观测体系中的一块通用拼图：既可以被集成进不同的 Agent 框架，也可以与多种存储、分析和评估系统自由组合，最终帮助开发者构建真正端到端、可演进的 Agent 治理体系。

因此，开源并非终点，而是一种选择：选择用开放换取标准，用共建对抗复杂，用工程理性推动 AI 应用走向规模化和可持续。LoongSuite 的开源，正是在这一判断之上的自然结果。