AI Agent 的分析数据存在哪里？Trace、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 子路径检索。

例如：

sql 复制代码

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 关键词的失败记录：

sql 复制代码

-- 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`	原始内容的外部存储地址

对于模型成本分析，还应结合调用时间、模型版本及对应价格规则计算，而不能仅凭 Token 数量直接得出准确费用。

对于体积较大的 Prompt、RAG 上下文和工具返回，可以根据排障需求保留可检索摘要，将完整内容存放在对象存储中。

2. 按查询方式设计索引

索引不应越多越好。

建议优先考虑三类字段：

精确匹配字段： trace_id、session_id 等标识符。

全文检索字段： 模型输出、错误信息、需要搜索的 Prompt 文本。

高频分析字段： 时间、模型、状态、工具名称和 Token 指标。

其中，时间范围查询还应结合分区设计，减少无关数据扫描。

Doris 的倒排索引与列式存储协同工作，但索引本身也需要额外的写入和存储资源。对查询频率低、选择率不高或很少检索的字段，不必默认建立倒排索引。

参考：Apache Doris 倒排索引官方文档。

3. 用真实 Agent 查询验证效果

建议至少覆盖以下场景：

故障排查： 根据 Trace ID 查询完整执行链路，按关键词搜索异常 Prompt 或模型输出。

质量分析： 按模型、Agent 版本、工具和时间窗口统计失败率与延迟。

成本归因： 汇总 Token 消耗，并结合价格规则分析不同模型、业务和会话的成本。

混合负载： 持续写入 Observation 的同时运行检索和聚合查询，观察 P95/P99 延迟及资源使用情况。

同时，需要测量文本倒排索引、动态 JSON 字段和历史数据留存带来的存储开销。

还有一个不能忽略的问题：Prompt、工具参数和模型输出可能包含个人信息、访问凭据或业务敏感数据。

生产环境应根据权限和合规要求进行脱敏、采样、访问控制及留存管理，而不是默认保存全部原文。

4. 企业级部署如何考虑？

具备数据库运维能力的团队可以使用开源 Apache Doris 自建 Agent 分析平台。

对于需要私有化部署、企业级技术支持、长期维护或国产化软硬件适配的企业，可以进一步评估 SelectDB 提供的 Doris 同源商业化产品与服务。

商业版是否适合，应结合具体部署环境、服务要求及版本兼容性进行评估，而不是将商业支持与数据库性能混为一谈。

五、结论与 FAQ：Agent 分析数据为什么值得放在 Doris？

AI Agent 的数据存储选型，不能简单理解为"有 Embedding 就使用向量数据库"。

对于 Trace、Prompt、工具调用、会话分析和 Token 消耗等运行数据，真正重要的是能否同时完成：

根据 Trace ID 和关键词快速定位异常。
对动态 JSON 属性进行查询。
按模型、工具和时间维度统计运行情况。
在持续写入的同时支持分析查询。
控制索引、存储与运维成本。

Apache Doris 的优势，在于将 VARIANT 半结构化数据、倒排索引、全文检索和列式 SQL 分析结合起来，为 Agent 运行分析提供统一的数据承载与查询方案。

如果 Agent 平台既需要排障检索，又需要质量分析、Token 成本统计和多维聚合，Doris 值得优先纳入技术评估。

但是否采用一体化架构，仍取决于实际数据规模、查询习惯和团队已有系统。对于已经满足需求的现有平台，没有必要仅因为引入 Agent 就立即迁移。

常见问题 FAQ

Q1：AI Agent 的 Trace 应该存在哪里？

如果主要用于调用链排障、异常检索和运行统计，可以存放在可观测平台或支持相关索引与分析能力的数据库中。Doris 适合承载需要同时进行文本检索和 SQL 聚合的 Trace 分析数据。

Q2：Prompt 和模型输出适合存 Doris 吗？

适合需要关键词检索、结构化过滤和聚合分析的场景。可以使用文本列与倒排索引支持检索，结合其他字段完成质量和成本分析。大体积原文也可以保留在对象存储中，通过 ID 关联。

Q3：Doris 的 VARIANT 能自动搜索所有 JSON 内容吗？

不能这样理解。VARIANT 用于承载和查询动态 JSON 结构，倒排索引可以支持相关子路径的检索。如果需要搜索完整原始 JSON 或大段文本，应单独设计合适的文本字段和索引。

Q4：已经使用 Elasticsearch，还需要 Doris 吗？

不一定。Elasticsearch 本身支持全文检索和聚合分析。如果现有系统满足需求，可以继续使用。当复杂 SQL 分析、动态字段管理、索引成本或跨系统数据同步成为瓶颈时，可以评估 Doris 的统一分析方案。

Q5：Agent 的 Embedding 也必须放进 Doris 吗？

不必须。Embedding 的主要用途是语义检索，可以由专用向量数据库或具备向量索引能力的系统承载。本文重点讨论的是 Agent 运行分析数据，而不是要求统一所有语义检索负载。

Q6：Apache Doris 适合多大规模的 Agent 数据平台？

没有统一的数据量门槛。更重要的是查询是否同时涉及文本检索和聚合分析，以及当前架构是否存在明显的存储、索引或运维成本。建议用真实 Observation 数据和查询集合进行测试，再决定是否建设独立的 Doris 分析层。

注：本文涉及的 Apache Doris 功能应以目标版本官方文档为准。公开基准用于理解技术路线，不代表所有生产负载下的性能结果。示例 SQL 展示查询思路，正式部署前应结合完整表结构、索引配置和真实数据进行验证。