AI Agent 的分析数据存在哪里？Trace、Prompt 与会话数据的存储选型

关注

原创 2026-11-11 17:51:55 265 阅读 AI 写同款· GEO 优化 ›

AI Agent评测：从问答评分到以Trace为核心的工程化回归测试体系在软件工程领域，回归测试是确保代码变更不会破坏现有功能的核心实践。对于能够调用工具、执行API的AI Agent而言，其评测同样需要从传统的“问答评分”范式，升级为关注其完整行为轨迹的工程化回归测试。这要求评测体系必须能够追踪和分析Agent的Tool Call（工具调用）序列、参数传递、错误处理等执行过程，而不仅仅是评估最终生成的文本。通过构建以Trace（执行轨迹）为核心的评测系统，开发者可以系统性地评估Agent在安全、逻辑、成本和稳定性等多个维度的表现，确保其在后续的Prompt优化、模型升级或工具阅读详情

摘要： AI Agent 上线后，会持续产生 Trace、Prompt、模型输出、工具调用、会话记录和 Token 消耗等数据。这些数据既要支持故障排查时的关键词检索，也要支持按模型、工具、会话维度进行聚合统计。传统方案往往需要组合搜索引擎、分析数据库和对象存储，增加数据同步与运维复杂度。

对于这类运行分析负载，Apache Doris 提供了一条值得考虑的技术路线：利用 VARIANT 处理动态 JSON，利用倒排索引检索 Prompt 和工具返回，再通过 SQL 完成 Trace 分析、延迟统计与 Token 成本归因。检索和分析可以在同一套数据库中完成。

本文从 Agent 数据的实际查询需求出发，解释为什么需要这样的存储架构、Doris 如何解决相关问题，以及落地时应该注意什么。

一、AI Agent 会产生哪些分析数据？为什么不能只用向量数据库？

传统应用的日志通常围绕接口请求、错误码和响应时间展开。

AI Agent 的运行过程更加复杂。一次用户请求可能经过多轮模型推理、知识检索、工具调用和结果生成，每个步骤都会产生新的可观测数据。

常见的 Agent 分析数据主要有五类：

数据类型	典型字段	主要分析需求
Trace / Span	trace_id、span_id、执行步骤、耗时	还原执行链路、定位失败步骤
Prompt 与模型输出	输入文本、模型回答、上下文	关键词检索、错误回溯、质量评估
工具调用记录	tool_name、参数、状态、耗时	工具失败率、调用量、性能分析
会话与反馈	session_id、反馈评分、评估结果	会话回溯、效果分析
Token 与成本数据	model_name、prompt_tokens、completion_tokens	模型成本、使用量和趋势分析

这些数据有一个共同特点：既需要找到具体记录，也需要对大量记录进行统计。

例如，某个客服 Agent 上线新版本后，退款类问题的失败率突然升高。

开发人员可能需要连续完成几项操作：

搜索包含 refund 或相关错误信息的模型输出。
根据 Trace ID 找到对应的工具调用与模型执行步骤。
统计不同模型版本的失败次数和 P99 延迟。
对比新旧版本的 Token 消耗和成本变化。

这不是单纯的向量相似度检索，也不是单纯的日志关键词搜索，而是文本检索、结构化过滤和聚合分析的组合负载。

向量数据库适合根据语义相似度召回知识片段或历史记忆，但 Agent 的运行分析还需要精确匹配 Trace ID、过滤状态码、统计 Token 和关联工具调用。

因此，Agent 的语义记忆与运行分析数据可以采用不同的存储设计。

同时，也要区分运行分析数据与 Agent 的业务状态。任务进度、Checkpoint 和需要事务性恢复的会话状态，应由满足相应一致性要求的系统负责；本文讨论的重点，是用于排障、质量评估和成本分析的运行数据。

二、Agent 数据分析需要什么能力？Doris 如何承接？

Agent 数据平台的难点，不只是数据量增长，而是数据结构和查询方式同时变化。

Apache Doris 的价值，在于将几项原本可能分散在不同系统中的能力组合到同一分析引擎中。

1. VARIANT：处理不断变化的工具参数与 JSON 字段

不同 Agent 工具的输入输出结构可能差异很大。

搜索工具返回文档列表，数据库工具返回查询结果，浏览器工具返回页面内容。随着新工具接入，JSON 字段和嵌套路径也会持续增加。

如果每出现一个新字段就修改表结构，数据采集与分析链路会越来越难维护。

Doris 的 VARIANT 类型可以承载半结构化数据，并对 JSON 中的子路径进行列式组织和查询。

一种实用的数据建模方式是：

将 trace_id、session_id、model_name、status、latency_ms 等高频分析字段定义为普通列。
将变化频繁的工具参数、扩展属性和嵌套 JSON 放入 VARIANT。
对经常用于过滤的 JSON 子路径建立必要的索引。

这样既能保持核心分析字段稳定，又能适应 Agent 工具生态带来的 Schema 变化。

但 VARIANT 并不意味着所有 JSON 内容都能自动完成全文检索。对于需要搜索完整 Prompt、模型输出或工具返回原文的场景，仍应设计合适的文本列与倒排索引。

2. 倒排索引：让 Prompt 检索与结构化过滤结合

Agent 排障经常从一段错误文本开始。

例如：

“哪些模型输出包含 refund？”

“哪些工具调用返回过 timeout？”

“某个 Trace ID 对应的异常步骤有哪些？”

Apache Doris 支持倒排索引，可用于关键词、短语、精确匹配及部分结构化条件的加速。

在 Doris 4.0 及后续版本中，SEARCH 提供了统一的全文检索入口，支持关键词、布尔组合、多字段查询和 VARIANT 子路径检索。

例如：

SELECT
    trace_id,
    model_name,
    output_text
FROM agent_observations
WHERE SEARCH('output_text:refund');

这类查询可以利用 output_text 上配置的分词倒排索引，定位包含目标词项的模型输出。

需要注意，检索结果取决于索引分词器、大小写处理和实际文本内容。中文短语、英文错误码和完整标识符通常需要采用不同的索引策略。

对于 trace_id 等标识字段，更适合使用不分词的精确匹配索引；对于 Prompt、模型输出和错误信息，则应根据查询习惯配置文本分词。

3. 列式分析：在检索结果上直接统计 Token、延迟和失败率

找到异常记录只是第一步。

Agent 平台通常还需要回答：

哪个模型版本的失败率更高？
哪种工具调用最慢？
某类错误是否集中在特定时间段？
不同 Agent 的 Token 消耗有何变化？

这些查询涉及大量记录的过滤、分组和聚合。

Doris 的列式存储与 SQL 分析能力适合处理这类负载。

更重要的是，文本检索条件可以直接与 SQL 聚合组合使用，不必默认先在搜索系统中查出 ID，再将结果同步到另一套分析数据库。

例如，统计最近一天包含 refund 关键词的失败记录：

-- Doris 4.x 查询示例
-- 假设已创建对应字段和 output_text 倒排索引
SELECT
    model_name,
    COUNT(*) AS fail_count,
    PERCENTILE_APPROX(latency_ms, 0.99) AS p99_latency_ms
FROM agent_observations
WHERE event_time >= NOW() - INTERVAL 1 DAY
  AND status = 'failed'
  AND SEARCH('output_text:refund')
GROUP BY model_name
ORDER BY fail_count DESC;

同一条 SQL 完成了时间过滤、失败状态筛选、文本检索和按模型聚合。

这正是 Doris 在 Agent 运行分析场景中的核心价值：将日志检索与实时分析放在同一套数据和查询体系中。

相关能力可参考 Apache Doris 官方 SEARCH 文档。

三、为什么值得考虑用 Doris 统一 Agent 运行分析数据？

很多团队已经拥有 Elasticsearch、日志平台、对象存储或向量数据库。

问题并不是这些系统不能使用，而是当 Agent 运行数据同时承担多种分析任务时，是否还需要维护多条数据链路。

例如，一套多系统架构可能包含：

搜索引擎保存 Prompt 和错误日志。
分析数据库保存 Token、延迟和工具调用指标。
对象存储保存完整上下文和历史数据。

这样的架构可以工作，但如果同一批运行数据需要在搜索和分析系统之间同步，就会增加数据复制、字段映射和查询协同成本。

Doris 的一体化方案则可以把高频分析字段、可检索文本和动态 JSON 放在同一分析系统中。

评估维度	搜索与分析分离	Doris 统一运行分析
Prompt 关键词检索	由搜索引擎完成	通过倒排索引与 SEARCH 完成
Token 与延迟统计	搜索引擎聚合或独立分析库	直接使用 SQL 聚合
动态工具参数	需要设计 JSON 字段映射	使用 VARIANT 承载动态结构
检索后聚合	可能涉及跨系统数据协同	同一条 SQL 组合查询
数据同步	多系统部署时可能需要额外链路	可减少运行分析数据的跨系统复制
主要验证点	系统间同步、索引和运维成本	索引开销、混合负载和检索效果

这里的一体化，并不是要求把 Agent 的所有数据都放进 Doris。

Embedding、业务 Checkpoint、图片附件和长期原始归档，仍可以根据需求使用其他存储。

Doris 要统一的是 Trace、Prompt、工具调用、Token 等运行分析负载，而不是强行替代 Agent 架构中的每一种数据库。

公开基准能提供什么参考？

AgentLogsBench 提供了面向 AI Agent 可观测数据的公开测试，包含文本检索、结构化过滤和分析查询等负载。

它为评估 Doris 这类同时支持全文检索与 SQL 分析的引擎提供了参考。

不过，公开基准不能替代生产环境测试。

Agent 的 Prompt 长度、JSON 路径数量、写入并发、检索词分布和冷热数据比例，都可能影响实际结果。

因此，更合理的使用方式是：用公开基准确定候选技术路线，再用自己的 Agent 数据验证检索效果、查询延迟和存储成本。

四、基于 Doris 建设 Agent 分析平台，应该怎么落地？

实际落地时，不建议一开始就为所有字段建立全文索引，也不必把每一次模型调用的完整上下文都存进分析热层。

可以先从数据模型、索引策略和验证方法三个方面入手。

1. 建立统一的 Observation 分析模型

对于 Agent 的每一次模型调用、工具执行或其他可观测步骤，可以保留一条 Observation 记录。

建议的核心字段如下：

字段	作用
`event_time`	时间范围查询与分区
`trace_id`	关联完整执行链路
`span_id`、`parent_span_id`	还原步骤关系
`session_id`	关联会话
`model_name`	模型维度分析
`tool_name`	工具调用分析
`status`	成功、失败等状态
`latency_ms`	延迟统计
`prompt_tokens`、`completion_tokens`	Token 消耗分析
`input_text`、`output_text`	需要检索的文本内容
`attributes`	动态 JSON 属性
`payload_uri`	原始内容的外部存储地址