客户证言
"SelectDB 对阶跃星辰来说不只是 Agent Trace 的存储，而是整个 AI 基础设施的数据底座。存算分离架构让运维成本大幅降低，扩容升级不用像 ClickHouse 手动搬数据。Stream Load p99 延迟在 1 秒以内，一次请求可以达到 500MB 大批次，GB/s 级高吞吐下数据秒级可见。"
——阶跃星辰可观测性负责人 Ric
从确定性到概率性：Agent 让可观测变了
阶跃星辰是国内大模型领域的头部企业，Agent 产品化推进迅速，业务覆盖 SWE-Bench 代码评测、智能座舱等多个生产级场景。但随着 Agent 从内部工具走向对外生产业务，一个根本性问题浮现出来：传统可观测的方法论，在 Agent 面前几乎失效了。
在传统微服务场景下，排障靠几条日志加上对代码和系统架构的理解，通常就能有效定位问题——排障的决策树直接体现在代码中。
但 Agent 场景完全不同。观测对象从确定性程序变成了概率行为系统，每一步的决策过程和结果都无法收敛成确定流程。阶跃星辰在构建 Agent Trace 系统时，梳理出了六个必须覆盖的能力维度：
数据模型要原生支持 prompt、reasoning、tool call 等 Agent 特有属性，这些在设计之初就应该考虑进去。会话级分析——用户使用 Agent 往往需要多轮对话才能达成目标，会话级别的还原和复盘分析成为关键能力。成本分析——Agent 每一步的 token 消耗都需要体现在 trace 中，trace 从一开始就要为成本统计和成本治理提供支持。Trace 检索——包括用户、标签、环境等元数据检索，也包括输入输出中的文本检索，对于找到待分析的 Trace 至关重要。评测闭环——Agent Trace 必须具备可分析、可回放的能力，能够为 Agent 的持续迭代优化提供测试数据或样本集。基础设施关联——Agent 的效果由模型和 harness 共同决定，Infra 在这个过程中也扮演了重要角色。一次 Agent 调用中，trace 需要关联到底层的沙箱、KV Cache、调度等基础设施。
数据底座的四个硬要求
上面这些能力要求，对支撑 Agent Trace 的数据底座也提出了新的挑战。
一方面，需要复杂数据的实时存储和查询能力——很多字段天然是高基数的，大量灵活的半结构化 JSON 数据，对元数据检索、文本检索和点查的要求很高，数据写入还必须实时可见。另一方面，需要很强的实时数据分析能力——AgentOps 是一个 EDD 驱动的流程，天生需要对数据回流做评估和多维度分析来提升 Agent 效果。
基于这两个特点，阶跃星辰总结了四点关键要求：能支撑宽表建模，很多 Trace 属性能在宽表中建模和分析；灵活检索，除了 trace ID 点查，还要支持关键字全文检索和 metadata 嵌套 JSON 检索；多维指标聚合，从 trace 底表支持各种灵活的 rollup，比如聚合出成功率、质量、token 成本等多维派生数据；混合负载治理，离在线一体的查询需要数据底座来支撑，隔离和管理不同场景的查询负载。
评估下来，能同时满足的方案不多。关系型数据库在灵活检索上力不从心；ClickHouse 分析性能确实强，但扩容时需要手动搬迁数据，在业务快速迭代阶段运维成本太高；Elasticsearch 检索是强项，但多维聚合和 rollup 能力不足；时序数据库天然不适合半结构化数据。阶跃星辰需要的不是某一个维度的极致，而是综合能力的平衡点——这四点要求叠加起来，筛选范围其实很窄。
选 SelectDB 的五个理由
阶跃星辰最终选择了 SelectDB（基于 Apache Doris 内核构建），原因很具体：
VARIANT 类型能够很好地支撑 JSON 半结构化数据。写入时自动识别 JSON 数据中的字段名和类型，将它们拆分成子列，采用列式存储，提升存储压缩率和查询性能。倒排索引能够支持高效的点查以及关键词的过滤。SelectDB 早在 2023 年就开始支持倒排索引，被很多公司大规模应用，经过了多年 PB 级生产环境的打磨和验证。异步物化视图提供了灵活、轻量的 rollup 能力，能够让团队做多维度的聚合以及透明改写。
实际落地中最大的惊喜是 Stream Load 的实时导入能力——能够很好地承接大批量数据写入的吞吐，p99 延迟在 1 秒以内，一次请求甚至可以达到 500MB 的大批次。Workload Group 能够隔离开在线和离线的负载。
还有一个关键点是 SelectDB 的 FE/BE 元数据和数据分离的架构，扩展更灵活，运维成本大幅降低。扩容、升级等操作非常方便，不用像 ClickHouse 手动搬迁数据。
StepTrace 落地：两个生产级场景
选型确定后，阶跃星辰基于 SelectDB 构建了 Agent 可观测平台 StepTrace。整体搭建过程比较顺利，SelectDB 的运维门槛确实低，存算分离架构让扩容升级不用搬数据，这一点让团队省了不少心。
StepTrace 在传输协议上兼容 Langfuse 和 OpenTelemetry 协议，在 trace 上下文中使用 W3C 协议，复用了 OpenTelemetry 的 gRPC、collector 等技术栈。数据采集后通过 Stream Load 写入 SelectDB，在 GB/s 高吞吐写入的负载下达到秒级实时可见的效果。写入之后，通过物化视图来实现预聚合和预计算——每个 span 或 Agent 的每一步都会产生 token 消耗，最终需要计算某条 trace 或某个会话具体消耗了多少 token，这种预计算能力通过物化视图来实现。
SWE-Agent 代码评测是 StepTrace 的一个重要应用。SWE-Bench 是 coding 能力的重要评测集，团队通过对 SWE-Agent 做 SDK 埋点，实现各个环节的观测——镜像拉取、沙盒创建、沙盒执行、多轮模型调用以及工具调用——来保障 SWE-Agent 的稳定性。通过 trace 能清楚看到 rollup 链路上有哪些环节，在 evaluation 的评测链路上有哪些环节。过去算法工程师的工作模式，往往是通过日志或轨迹文件，没有统一的高性能存储，限制了很多分析，比如 Agent 多版本的横向比较、时序上的性能变化、成功率等高级分析。现在在 StepTrace 上都能够统一地支持。
智能座舱 Agent 是另一个落地场景。智能座舱是当前比较前沿的产品，得益于端侧算力的提升和车机 OTA 以及云端协同的能力，现在很多先进的座舱也引入了 Agent 来提高驾乘体验，同时也带来了安全、成本等方面的挑战。座舱 Agent 的观测，是它能够高效、安全、稳定运转的基石，尤其是安全。座舱 Agent 对安全做了很多约束，这些约束的生效情况到底如何？在测试场景下闭环率到底如何？这些都是 Agent 可观测要服务的重点。
在智能座舱场景下，用户的输入往往是零散的语音片段，意图在最开始可能是相对发散的，经过多轮对话之后才会体现出最终目的。这就导致获得最后结果的时候不确定性很高，要保证 Agent 的效果，就必须通过 trace 的方法去观测链路的每一次推理过程，分析为什么没有得到用户预期的结果，再针对性提升效果。
在此之上还需要构建优秀的评测集，能够让 Agent 在替换新模型或更新新架构时进行量化效果评估，确保用户真的能感受到优化，而不是一个拍脑袋的优化。
除了以上两个核心场景，阶跃星辰内部还围绕 SelectDB 构建了更多 Agent 相关的系统，比如 OpenClaw 的 trace 和 log，以及一套类似 W&B 的高性能训练指标系统。SelectDB 对阶跃星辰来说不只是一个 Agent Trace 的存储，而是整个 AI 基础设施的数据底座。
下一步：一体化 Agent 数据分析平台
阶跃星辰的最终目标是围绕 SelectDB 构建一体化的 Agent 数据分析平台。
基础设施打通——生产级 Agent 运行链路复杂，从模型决策、沙箱执行、推理调度到引擎层面的优化，都需要统一观测才能定位问题。比如有一个用户报障，怎么确定问题出在基础设施的哪个环节？可能是非预期的结果导致整个效果不好。具体来说，vLLM 层的 prefill/decode 性能、沙箱中如何做 eBPF 无侵入观测、安全拦截的效果验证，这些基础设施层面的可观测目前还是分散的。数据闭环——把 trace 数据直接对接 ATIF（Agent 运行轨迹格式），打通 ATIF 格式后才能直接对接 OpenHands、SWE-Bench、Gemini CLI 等评测框架。打通 Trace 数据应用的最后一公里，才能全面赋能 SFT、RL、Evaluation 的数据底座。数据开放——接入企业级数据平台，对接公司内部的大数据组件，构建基于 Trace 的完整数仓体系。
阶跃星辰基于 SelectDB 构建 Agent 可观测平台 StepTrace 的实践表明，Agent 可观测也是一个实时数据分析问题。它面临的实时写入、超长 Trace 检索分析、成本控制等挑战，SelectDB 的列式存储和聚合物化视图、倒排索引、VARIANT 半结构化数据类型、存算分离架构等能力可以很好地应对解决，是经得起生产规模检验的 Agent 可观测数据底座。
了解更多
产品文档：https://help.aliyun.com/zh/selectdb/what-is-datalens-ai
钉钉搜索“ 161125047304”加入钉群获更多资讯
