客户证言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以及一套类似 WB 的高性能训练指标系统。SelectDB 对阶跃星辰来说不只是一个 Agent Trace 的存储而是整个 AI 基础设施的数据底座。下一步一体化 Agent 数据分析平台阶跃星辰的最终目标是围绕 SelectDB 构建一体化的 Agent 数据分析平台。基础设施打通——生产级 Agent 运行链路复杂从模型决策、沙箱执行、推理调度到引擎层面的优化都需要统一观测才能定位问题。比如有一个用户报障怎么确定问题出在基础设施的哪个环节可能是非预期的结果导致整个效果不好。具体来说vLLM 层的 prefill/decode 性能、沙箱中如何做 eBPF 无侵入观测、安全拦截的效果验证这些基础设施层面的可观测目前还是分散的。数据闭环——把 trace 数据直接对接 ATIFAgent 运行轨迹格式打通 ATIF 格式后才能直接对接 OpenHands、SWE-Bench、Gemini CLI 等评测框架。打通 Trace 数据应用的最后一公里才能全面赋能 SFT、RL、Evaluation 的数据底座。数据开放——接入企业级数据平台对接公司内部的大数据组件构建基于 Trace 的完整数仓体系。阶跃星辰基于 SelectDB 构建 Agent 可观测平台 StepTrace 的实践表明Agent 可观测也是一个实时数据分析问题。它面临的实时写入、超长 Trace 检索分析、成本控制等挑战SelectDB 的列式存储和聚合物化视图、倒排索引、VARIANT 半结构化数据类型、存算分离架构等能力可以很好地应对解决是经得起生产规模检验的 Agent 可观测数据底座。了解更多产品文档什么是 AI 可观测-云数据库 SelectDB 版(SelectDB)-阿里云帮助中心