从万亿级大模型到全线应用：Databend Cloud 助力头部 AI 企业构建全链路 Trace 数据管道

某中国头部 AI 大模型企业，以突破性的长文本处理能力与高阶推理技术著称，同时也是推动万亿级大模型开源的行业领跑者。随着其开源万亿级强化推理大模型投入应用，模型需要处理百万级超长上下文与 Agent 级复杂任务。一次长任务可能包含数千次工具调用，累计处理数百万 context tokens。随任务一起快速增长的，还有记录模型决策、工具调用与执行过程的 Agent Trace。

这款模型上线后，在线 Trace 写入吞吐达到每小时 TB 级。这些 Trace 不只是用于排查问题的日志，更是开展 Evals（评测）和归因分析的重要数据资产。该企业选择 Databend Cloud 承载其万亿级强化推理大模型及相关应用的全链路 Trace，构建一条贯穿数据接入、增量处理与评测分析的统一数据管道。

---

当 Agent 开始处理百万级上下文

一次普通对话往往在几轮交互后结束。一次复杂的 Agent 任务却可能持续数小时：模型不断制定计划、调用工具、接收结果，再根据新的上下文决定下一步行动。

当上下文窗口扩展到 1M tokens，这个过程的规模也发生了变化。单次长任务可能发起数千次工具调用，累计处理数百万 context tokens。模型的输入与输出、工具返回结果、执行状态和中间产物，会不断形成新的 Span，并最终汇聚成一条庞大而复杂的 Trace。

对于工程团队来说，问题不再只是“如何保存日志”。他们需要知道一次任务为什么成功、在哪一步偏离预期，以及模型、Prompt、工具或 Harness 的变化是否真正改善了结果。

换句话说，Trace 的终点不应只是可观测性平台。它还需要继续流向 Evals 和归因分析，成为下一轮模型与 Agent 迭代的依据。

---

Trace 数据管道的新要求

传统可观测性 Trace 主要围绕服务调用展开，Schema 相对稳定，分析重点通常是延迟、错误率和调用链。Agent Trace 则更加动态。

每一次模型或工具升级，都可能带来新的 JSON 字段。长任务产生的 Span 跨越更长的时间窗口，同一条执行链路也可能分散在大量数据之中。如果接入时就把所有字段固化为固定 Schema，上游的一次变化就可能牵动 Consumer、表结构与处理链路；如果只保留原始 JSON，后续查询和评测又会承担更高的处理成本。

此外，原始 Span 并不天然等于可使用的评测数据。工程团队还需要持续清洗数据、抽取关键字段，并将新增事件加工成适合分析的结构。与此同时，Trace 中可能包含用户输入、工具返回结果等敏感信息，不同分析任务只能访问完成工作所必需的字段。

在这样的数据规模下，摄取链路必须持续跟上业务增长，同时避免 JSON 处理、增量建模和分析查询反过来阻塞实时写入。这个场景真正需要的，不只是能够存下 Trace 的系统，而是一条连接数据接入、原始数据留存、增量处理、Eval 数据集生产、查询与历史回放的完整数据管道。

Databend Cloud 通过 Stage、VARIANT、Stream 和 Task 形成这套数据管道能力：Stage 承接来自对象存储的数据，VARIANT 原样保留结构不断变化的 Prompt、Tool Call、Span、延迟、Token 消耗和 Eval 结果，Stream 跟踪新增数据，Task 自动完成清洗、转换和增量建模。结合列式分析、数据剪枝和 Time Travel，工程团队可以进一步完成聚合分析、问题排查与历史数据回放，让持续产生的 Agent Trace 持续转化为可用的分析与评测数据。

---

Agent Trace 全链路架构

该企业将 Web/App 端行为轨迹与 Agent 执行轨迹以 Trace/Span 的形式实时汇聚到 Kafka，再接入 Databend Cloud。

原始数据首先以追加方式写入 kafka_raw。完整 Span 通过 VARIANT 保存，即使 JSON 结构随着模型和工具快速演进，接入层也不必频繁修改表结构，未来需要的新字段仍可从原始数据中提取。

Stream 持续跟踪新增数据，Task 自动完成 JSON 清洗、字段抽取和增量建模，再将结果写入面向分析的 traces 表。整个过程只处理新产生的变化，不需要重复扫描已经完成清洗的历史数据。

这样一来，原始数据留存与面向分析的建模不再彼此冲突：kafka_raw 保存完整、可回溯的事实记录，traces 则为 Evals、链路分析和问题归因提供更适合查询的数据结构。

---

Databend Cloud 如何承载 Agent Trace 生产负载

每小时 TB 级的 Agent Trace 链路需要同时处理三类负载：数据持续写入，Stream 与 Task 不断完成增量加工，工程师则随时可能发起链路查询或评测分析。如果这些任务争抢同一组资源，一次复杂查询就可能影响实时接入。

Databend Cloud 将持久化数据保存在客户自有的对象存储中，并允许写入、处理和分析分别使用独立 Warehouse。不同阶段可以根据实际负载单独扩缩容，在保障数据链路持续运行的同时，无需长期为峰值预留整套计算资源。

面向长链路分析，查询表按照时间和链路标识组织，帮助查询缩小需要扫描的数据范围。数据接入、增量处理、建模和分析也无需分散到多套独立系统，从而减少额外的数据搬运与调度链路。

数据安全与合规治理同样被纳入这条链路。Masking Policy 可以针对 VARIANT 子路径配置细粒度脱敏规则，限制敏感字段的可见范围，让评测和分析任务只看到所需字段，原始数据则继续保留在客户控制的对象存储中。

---

数日接入，把工程时间留给 Evals 与模型迭代

Databend Cloud 在数日内完成生产接入，并开始持续承载该开源万亿级强化推理大模型及相关应用产生的 Agent Trace。

作为全托管服务，Databend Cloud 将数据接入、增量处理、计算资源和日常运维集中在同一平台中。客户无需自行搭建和维护多套存储、调度与分析组件，也不必投入大量时间学习不同系统、反复配置集群或排查跨系统数据链路。

这不仅缩短了 Trace 数据平台从接入到生产运行的周期，也降低了后续维护成本。工程师可以把更多时间投入真正影响 Agent 质量的工作：完善 Evals、优化 Harness，并验证模型、Prompt 与工具的每一次变化。

随着 Trace 从原始事件进入可分析的数据集，模型运行、问题定位和效果评测之间形成了更短的反馈链路。Databend Cloud 帮助该企业的工程团队，将持续增长的 Agent 运行数据转化为可用于分析和评测的数据资产，并持续支持模型与 Agent 产品迭代。

---

Agent 走得越远，越需要看清它走过的路

百万级上下文和复杂工具调用，让 Agent 有能力完成更长、更开放的任务，也让每次运行产生的数据变得前所未有地重要。

对于正在推进 Agent 生产化的团队，数据平台需要回答的不只是“能否存下这些 Trace”，还包括能否持续接入、增量处理、安全分析，并将其转化为稳定的评测反馈。

这家头部 AI 大模型企业的实践提供了一条清晰路径：以 Databend Cloud 统一连接 Trace 与 Evals，让每一次 Agent 运行都能沉淀为下一次模型和产品进化的依据。