随着 Agent 应用逐步进入生产环境，一个全新的难题逐渐浮现：如何才能清晰掌握 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、模型参数、环境信息等字段，且字段结构变化频繁，不能频繁改动 schema。
第二，支持灵活检索。 排障时既要能按 trace id、session id 快速点查，也要能在输入输出文本中执行全文检索。
第三，支持实时分析。 AgentOps 的核心是“评估—反馈—优化”闭环，Trace 数据越快可见，问题排查与效果分析就越及时。
第四，支持多维聚合。 团队需能按模型版本、任务类型、环境、时间窗口等维度，快速分析成功率、延迟、token 成本等关键指标。
第五，治理混合负载。 线上排障查询与离线分析任务经常同时运行，必须避免相互干扰。
正是基于这五项要求，阶跃星辰最终选择 SelectDB 作为 Agent Trace 的实时分析数据底座。具体使用方式包括几个关键点：VARIANT 类型用于承接半结构化 JSON 数据，省去频繁修改 schema 的麻烦；倒排索引支持 trace id 点查、高基数字段过滤以及关键词检索；Stream Load 支撑高吞吐实时写入，数据落库即可查询；异步物化视图预聚合 token 成本、成功率、延迟等常用指标；Workload Group 则负责隔离在线排障与离线分析两类负载。
从这个角度看，SelectDB 在阶跃星辰 Agent 可观测平台中，并非简单的“日志仓库”角色——它同时支撑了 Trace 明细检索、实时分析以及评测闭环，是真正意义上的数据底座。
当 Agent 应用进入真实业务后，仅看最终结果远远不够。只有将执行过程中的每一步都沉淀为可查询、可分析、可复用的数据，团队才能持续优化 Agent 的效果、成本与稳定性。这一点，无论从哪个角度而言，都是核心关键。
