当AI代理轨迹成为应用数据
内容提要
该文探讨AI代理执行记录的数据存储问题。代理运行产生大量轨迹数据，兼具应用数据与遥测特性，需支持单次运行检索及跨运行分析。随着规模扩大，主数据库可能面临性能瓶颈，可迁移至分析型存储（如ClickHouse）并优化数据模型。关键在于依据产品需求选择架构，平衡点查询与批量扫描。
延伸解读
轨迹数据的两面性
代理轨迹既是应用数据又是遥测数据，这种双重身份决定了存储方案。作为应用数据，它需要支持单次运行的检索和展示，并遵循应用的访问控制；作为遥测数据，它需要支持跨运行的分析和聚合。这种组合使得存储决策变得复杂，不能简单归类为日志或业务记录。
规模增长的三阶段信号
当代理轨迹数据量增长时，会依次出现三个信号：首先是主数据库的I/O和CPU争用，影响事务操作；其次是分析查询变慢，无法满足延迟目标；最后是不得不强制采样，丢弃部分轨迹。这些信号提示需要将轨迹迁移到专门的存储系统，如ClickHouse。
数据模型与存储引擎同等重要
Langfuse的案例表明，仅更换存储引擎不够，还需优化数据模型。将分离的trace、observation和score表合并为宽表，减少连接操作，显著提升查询性能。因此，设计时应同时考虑存储引擎和数据模型，以应对点查询和批量扫描的双重需求。
Q&A
为什么AI代理的执行轨迹被视为应用数据而不是单纯的遥测数据？
当执行轨迹需要被产品检索、展示或长期保留，以帮助用户验证结果或作为审计记录时，它就变成了应用数据。例如，开发者需要查看代理检查了哪些文件，审查者需要确认运行了哪些命令和测试是否通过。此时，轨迹数据具有遥测形态的工作负载，但承担着应用数据的角色。
代理轨迹数据有哪些特点？
代理轨迹数据通常是写一次、不更新，包含高基数维度（如模型版本、提示模板、工具名、会话ID等），其价值体现在上下文和整体轨迹中。单个工具调用跨度本身意义不大，但完整轨迹可以解释失败原因，群体分析可以揭示回归。
代理轨迹数据量如何随任务规模变化？
代理轨迹数据量不直接与任务数量成正比，而是与每个任务内部的执行图相关。一个请求可能触发多次模型调用、文件读取、搜索、命令执行和重试，每个步骤都可能产生跨度或事件。添加新工具、重试策略或分支会增加数据量，即使完成任务数不变。
将代理轨迹存储在主数据库会遇到哪些问题？
随着规模扩大，主数据库可能面临性能瓶颈，表现为：1）争用：摄取或保留工作消耗大量I/O和CPU，影响事务操作；2）分析摩擦：评估和调试查询需要扫描长时间范围或连接大表，无法满足延迟目标；3）被迫采样：为保护主数据库而丢弃轨迹，但产品可能需要完整记录。
Langfuse是如何解决代理轨迹存储问题的？
Langfuse将追踪数据从Postgres迁移到ClickHouse，解决了摄取时的IOPS耗尽和提示API延迟问题。同时，它改进了数据模型，将原来的trace、observation、score表合并为宽表、基本不可变的observations表，每行对应一次模型调用、工具执行或代理步骤，从而减少了跨表连接，大幅提升了加载和仪表盘性能。
如何选择代理轨迹的存储架构？
应根据产品必须支持的读取需求来选择最简单的架构。在数据量不大时，可将轨迹保留在主数据库中，避免额外的运维边界。当分析争用增长时，可将轨迹事件发送到专用的分析存储（如ClickHouse），同时将可变业务记录保留在事务数据库中。如果两个系统需要共享数据，可以使用变更数据捕获（CDC）将相关数据复制到分析路径。关键是先映射点查询和跨运行扫描，如果两者都是产品需求，则从一开始就为两者设计。
