随着 Agent 应用陆续进入生产环境，一个新的难题浮出水面：怎么才能看清楚 Agent 到底在干什么？

阶跃星辰内部最近就在重新琢磨这件事——AI 应用的可观测，和传统微服务那套玩法，其实不太一样。

传统微服务 vs Agent：可观测的差异

传统微服务架构下，日志、指标、链路追踪已经形成了一套相当成熟的方法论。但 Agent 的执行链条远没有这么规整——它不是一条写死的代码路径，而是由 prompt、上下文、模型输出、工具调用以及运行时环境共同“拼”出来的结果。

换句话说，Agent 可观测不能只盯着接口层面的调用记录。它得能完整还原一次任务中每一步的模型推理、工具调用、输入输出、token 消耗、异常信息……信息量级完全不一样。

Agent Trace 平台要回答的现实问题

在阶跃星辰的实践中，Agent Trace 平台扮演的正是这个角色。它要帮工程团队回答几个很现实的问题：

• Agent 为什么给出了这个结果？
• 哪一步推理或者工具调用跑偏了？
• 某次任务的 token 成本到底花在了哪里？
• 不同模型版本、Agent 版本之间，效果有什么变化？

这些问题拆到底，本质都是数据问题。

Agent Trace 数据的特点

Agent Trace 数据跟普通日志差别很大。一次 Agent 调用就会产生大量半结构化的 JSON、高基数字段、还有长文本内容。

既要支持按 trace id 点查，又要能对 prompt、response、错误信息里的关键词做检索；既要能看单条链路的完整过程，也要能按时间、模型版本、任务类型等维度做聚合分析。

对数据底座的五个硬性要求

综合这些需求，阶跃星辰在搭建 Agent Trace 平台时，对数据底座提了五个硬性要求：

第一，能承接复杂半结构化数据。 Agent 执行过程中会不断产生 prompt、reasoning、tool call、模型参数、环境信息等字段，而且字段结构变化很快，不能动不动就改 schema。

第二，支持灵活检索。 排障时既要能按 trace id、session id 快速点查，也要能在输入输出文本里做全文检索。

第三，支持实时分析。 AgentOps 的本质是“评估—反馈—优化”的闭环，Trace 数据越快可见，问题排查和效果分析就越及时。

第四，支持多维聚合。 团队得能按模型版本、任务类型、环境、时间窗口等维度，快速分析成功率、延迟、token 成本这些核心指标。

第五，治理混合负载。 线上排障查询和离线分析任务经常同时进行，必须避免互相干扰。

为什么选择 SelectDB？

正是基于这五条，阶跃星辰最终选择了 SelectDB 作为 Agent Trace 的实时分析数据底座。具体怎么用？几个关键点：

• VARIANT 类型用来承接半结构化 JSON 数据，省去频繁改 schema 的麻烦。
• 倒排索引搞定 trace id 点查、高基数字段过滤和关键词检索。
• Stream Load支撑高吞吐实时写入，数据落库就能查。
• 异步物化视图预聚合 token 成本、成功率、延迟等常用指标。
• Workload Group则负责隔离在线排障和离线分析两类负载。

从这个角度看，SelectDB 在阶跃星辰 Agent 可观测平台里，绝不是简单的“日志仓库”位置——它同时支撑了 Trace 明细检索、实时分析以及评测闭环，是真正意义上的数据底座。

核心结论

当 Agent 应用进入真实业务后，光是看最终结果是远远不够的。只有把执行过程中的每一步都沉淀为可查询、可分析、可复用的数据，团队才有可能持续优化 Agent 的效果、成本和稳定性。

这一点，无论从哪个角度说，都是核心关键。

《夸克》非常好用的免费AI浏览器

下载APP查看