阶跃星辰 Agent 可观测实践：为什么 Trace 数据底座选择 SelectDB？

随着 Agent 应用逐渐进入生产环境阶跃星辰内部也开始重新思考 AI 应用的可观测体系。在传统微服务架构中日志、指标、链路追踪已经形成了一套成熟方法论。但 Agent 的执行过程更复杂它不是一条固定代码路径而是由 prompt、上下文、模型输出、工具调用和运行环境共同决定。这意味着Agent 可观测不能只记录接口调用还要能还原一次任务中每一步模型推理、工具调用、输入输出、token 消耗和异常信息。在阶跃星辰的实践中Agent Trace 平台承担的就是这个角色。它需要帮助工程团队回答几个问题Agent 为什么给出这个结果哪一步推理或工具调用出现了偏差某次任务的 token 成本主要消耗在哪里不同模型版本、Agent 版本之间效果有什么变化这些问题背后本质上都是数据问题。Agent Trace 数据和普通日志不同。一次 Agent 调用会产生大量半结构化 JSON、高基数字段和长文本内容。既要支持 trace id 点查也要支持 prompt、response、错误信息中的关键词检索既要能看单条链路也要能按时间、模型版本、任务类型等维度做聚合分析。因此阶跃星辰在建设 Agent Trace 平台时对数据底座提出了几个要求第一能够承接复杂半结构化数据。Agent 执行过程中会产生 prompt、reasoning、tool call、模型参数、环境信息等字段结构变化较快。第二能够支持灵活检索。排障时既需要按 trace id、session id 点查也需要在输入输出文本中做全文检索。第三能够支持实时分析。AgentOps 是一个不断评估、反馈和优化的过程Trace 数据需要尽快可见才能支撑问题排查和效果分析。第四能够支持多维聚合。团队需要按模型版本、任务类型、环境、时间窗口等维度分析成功率、延迟和 token 成本。第五能够治理混合负载。线上排障查询和离线分析任务经常同时发生需要避免互相影响。基于这些要求阶跃星辰选择 SelectDB 作为 Agent Trace 的实时分析数据底座。SelectDB 的 VARIANT 类型用于承接半结构化 JSON 数据减少频繁变更 schema 的成本倒排索引用于 trace id 点查、高基数字段过滤和关键词检索Stream Load 用于高吞吐实时写入让 Trace 数据写入后尽快可查异步物化视图用于预聚合 token 成本、成功率、延迟等指标Workload Group 用于隔离在线排障和离线分析负载。从这个角度看SelectDB 在阶跃星辰 Agent 可观测平台中并不是一个简单的“日志仓库”而是支撑 Trace 明细检索、实时分析和评测闭环的数据底座。当 Agent 应用进入真实业务后最终结果已经不够了。只有把执行过程沉淀为可查询、可分析、可复用的数据团队才有可能持续优化 Agent 的效果、成本和稳定性。