随着 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 的效果、成本和稳定性。