TrajectoryDB: A New Database for Agent Trajectories [Vision]TrajectoryDB：一种用于智能体轨迹的新型数据库 [愿景]

Yunjia Zheng Affiliation: Harvard University, Cambridge, United States email: yunjia_zheng@g.harvard.edu and Juncheng Yang Affiliation: Harvard University, Cambridge, United States email: juncheng@seas.harvard.edu

Abstract.摘要。

AI agents generate rich execution trajectories that capture their interactions with large language models, tools, and external environments. These trajectories are increasingly valuable for downstream tasks such as memory extraction, model fine-tuning, runtime optimization, and security and cost monitoring. Yet trajectory data today is fragmented across files, databases, and observability systems, with no persistent data management system designed around its unique structure and access patterns.人工智能体（AI agents）会生成丰富的执行轨迹，记录它们与大语言模型、工具以及外部环境的交互。这些轨迹对于记忆提取、模型微调、运行时优化以及安全和成本监控等下游任务而言，价值日益凸显。然而，目前的轨迹数据分散在各种文件、数据库和可观测性系统中，缺乏一种围绕其独特结构和访问模式设计的持久化数据管理系统。

We argue that trajectories should be treated as a distinct data type. A trajectory combines hierarchical execution structure, large volumes of text whose analysis often requires semantic reasoning, and rich dependencies and lineage among events, intermediate states, and derived artifacts. These properties introduce new requirements throughout the data lifecycle. Ingestion must reconstruct and preserve execution structure and lineage; storage must efficiently organize large but highly redundant contexts while maintaining relationships among records; and query processing must jointly reason over structure, temporal order, semantics, and lineage.我们认为轨迹应被视为一种独立的数据类型。轨迹结合了分层的执行结构、大量通常需要语义推理分析的文本，以及事件、中间状态和衍生制品之间丰富的依赖关系和血缘关系。这些特性在整个数据生命周期中提出了新的要求。数据摄入必须能够重构并保留执行结构和血缘；存储必须在保持记录间关系的同时，高效地组织庞大且高度冗余的上下文；查询处理则必须能够联合对结构、时间顺序、语义和血缘进行推理。

We therefore envision TrajectoryDB, a trajectory-native data management system that co-designs ingestion, storage, and query processing to efficiently manage and analyze agent execution trajectories.因此，我们构想了 TrajectoryDB，这是一种轨迹原生数据管理系统，它通过协同设计摄入、存储和查询处理，来高效管理和分析智能体执行轨迹。

^†^†authors: 作者：.†作者：。††作者：。

PVLDB Reference Format:
PVLDB, 20(1): XXX-XXX, 2027.
doi:XX.XX/XXX.XX ^†^† This work is licensed under the Creative Commons BY-NC-ND 4.0 International License. Visit https://creativecommons.org/licenses/by-nc-nd/4.0/ to view a copy of this license. For any use beyond those covered by this license, obtain permission by emailing info@vldb.org. Copyright is held by the owner/author(s). Publication rights licensed to the VLDB Endowment.
Proceedings of the VLDB Endowment, Vol. 20, No. 1 ISSN 2150-8097.
doi:XX.XX/XXX.XX
PVLDB 引用格式： PVLDB, 20(1): XXX-XXX, 2027. doi:XX.XX/XXX.XX †† 本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。访问 https://creativecommons.org/licenses/by-nc-nd/4.0/ 查看该许可协议的副本。对于超出此许可范围的任何使用，请发送电子邮件至 info@vldb.org 获取许可。版权归所有者/作者所有。出版权授权给 VLDB 基金会。 Proceedings of the VLDB Endowment, Vol. 20, No. 1 ISSN 2150-8097。 doi:XX.XX/XXX.XX

PVLDB Artifact Availability:
The source code, data, and/or other artifacts have been made available at URL_TO_YOUR_ARTIFACTS.PVLDB 构件可用性：源代码、数据和/或其他构件已在 URL_TO_YOUR_ARTIFACTS 提供。

1. Introduction1. 引言

Large language models (LLMs) generate text from an input sequence. An agent places an LLM in a runtime loop: when the model response contains a tool call, the runtime executes it in the environment and feeds the result into the next model invocation (Yao et al., 2023). This loop turns model outputs into actions and allows tasks to unfold over many rounds of reasoning, interaction, and execution. Agents are now used for repository-level software engineering (Yang et al., 2024), end-to-end data analysis (Hong et al., 2025), and customer-service workflows combining user interaction with domain-specific APIs (Yao et al., 2025). Their adoption is also moving rapidly into production. On OpenRouter, agent-driven token consumption grew roughly $14\times$ from February to August 2026 and reached nearly $5\times$ that of human-driven usage (Andreessen Horowitz, 2026).大语言模型（LLM）根据输入序列生成文本。智能体将 LLM 置于一个运行时循环中：当模型响应包含工具调用时，运行时会在环境中执行该调用，并将结果反馈给下一次模型调用（Yao 等人，2023）。这个循环将模型输出转化为行动，并允许任务在多轮推理、交互和执行中展开。智能体目前已被用于代码仓库级别的软件工程（Yang 等人，2024）、端到端数据分析（Hong 等人，2025）以及结合用户交互与特定领域 API 的客户服务工作流（Yao 等人，2025）。它们的采用也正在迅速进入生产环境。在 OpenRouter 上，智能体驱动的 Token 消耗量从 2026 年 2 月到 8 月增长了约 14 倍，达到人类驱动使用量的近 5 倍（Andreessen Horowitz, 2026）。

As agents interact with models and their environments, they generate a rich execution history, or trajectory. A trajectory records the messages sent to the LLM, model responses, tool calls, tool results, and associated runtime state. These trajectories are increasingly treated as persistent datasets rather than ephemeral logs. They can be mined for reusable memories that guide future behavior, reused as training data for model fine-tuning, and analyzed for failure diagnosis and safety control (Deshpande et al., 2025; Barke et al., 2026; OpenAI, 2026a). By connecting agent behavior with the underlying runtime, trajectories also support performance diagnosis, cost attribution, and resource-aware scheduling (Lin et al., 2024; Luo et al., 2026; Wang et al., 2026).随着智能体与模型及其环境交互，它们会生成丰富的执行历史，即轨迹。轨迹记录了发送给 LLM 的消息、模型响应、工具调用、工具结果以及相关的运行时状态。这些轨迹正日益被视为持久化数据集，而非短暂的日志。它们可以被挖掘以获取指导未来行为的可重用记忆，作为模型微调的训练数据进行复用，并用于故障诊断和安全控制分析（Deshpande 等人，2025；Barke 等人，2026；OpenAI, 2026a）。通过将智能体行为与底层运行时连接起来，轨迹还支持性能诊断、成本归因和资源感知调度（Lin 等人，2024；Luo 等人，2026；Wang 等人，2026）。

Yet existing systems manage only fragments of the trajectory lifecycle. Research systems commonly store trajectories as JSONL files and process them using task-specific Python pipelines (Zhao et al., 2024; Fu et al., 2024; Ouyang et al., 2026; Zhang et al., 2026; Yang et al., 2025). Such pipelines preserve the raw trajectory but provide little support for persistent, reusable derived state or declarative queries. Production memory systems such as Mem0 (Chhikara et al., 2025) and Letta (Letta, 2026) take the opposite approach: they persist extracted memories using structured storage, similarity search, and graph retrieval, but typically expose only task-specific derived state rather than the complete relationship between that state and its source trajectory. Security and observability systems ingest agent activity into mature log stores (OpenTelemetry, 2026), but their data models are designed around individual events. Reconstructing the context visible to a model invocation, traversing a subtrajectory, or tracing a semantic judgment back to the exact messages and tool results that support it therefore requires application-specific processing. Across these approaches, raw trajectories, derived state, runtime telemetry, and processing logic remain fragmented across files, databases, and scripts.然而，现有系统仅管理轨迹生命周期中的片段。研究系统通常将轨迹存储为 JSONL 文件，并使用特定任务的 Python 流水线进行处理（Zhao 等人，2024；Fu 等人，2024；Ouyang 等人，2026；Zhang 等人，2026；Yang 等人，2025）。此类流水线保留了原始轨迹，但对持久化、可重用的衍生状态或声明式查询几乎没有支持。生产环境中的记忆系统（如 Mem0（Chhikara 等人，2025）和 Letta（Letta, 2026））采取了相反的方法：它们使用结构化存储、相似性搜索和图检索来持久化提取出的记忆，但通常只暴露特定任务的衍生状态，而非该状态与其源轨迹之间的完整关系。安全和可观测性系统将智能体活动摄入到成熟的日志存储中（OpenTelemetry, 2026），但它们的数据模型是围绕单个事件设计的。因此，重构模型调用可见的上下文、遍历子轨迹，或将语义判断追溯到支持它的确切消息和工具结果，需要特定于应用程序的处理。在这些方法中，原始轨迹、衍生状态、运行时遥测和处理逻辑仍然分散在文件、数据库和脚本中。

We argue that trajectories constitute a distinct data-management workload because several challenging properties appear together. First, trajectories have nested and ordered execution structure: a session contains turns, model invocations, tool calls, messages, and potentially branches, retries, and subagents. Second, their dominant payload is free-form text, so many important predicates require semantic evaluation rather than exact matching. Third, trajectories are highly redundant: successive model invocations often repeat much of the same context, causing large volumes of duplicated text to be stored and processed. Finally, trajectory processing creates rich derived state and lineage. A memory may depend on several messages, a failure judgment on a particular tool result and model response, and a training label on the context evaluated by a specific judge model and criterion. Efficiently managing such data therefore requires reasoning jointly over structure, order, semantics, redundancy, and provenance.我们认为，由于多个具有挑战性的属性同时出现，轨迹构成了一种独特的数据管理工作负载。首先，轨迹具有嵌套和有序的执行结构：一个会话包含轮次、模型调用、工具调用、消息，以及潜在的分支、重试和子智能体。其次，它们的主要有效载荷是自由格式的文本，因此许多重要的谓词需要语义评估而非精确匹配。第三，轨迹具有高度冗余性：连续的模型调用往往重复大部分相同的上下文，导致大量重复文本被存储和处理。最后，轨迹处理会产生丰富的衍生状态和血缘关系。记忆可能依赖于多条消息，失败判断可能依赖于特定的工具结果和模型响应，训练标签则可能依赖于由特定评判模型和标准评估的上下文。因此，高效管理此类数据需要联合对结构、顺序、语义、冗余和来源进行推理。

These properties create opportunities for cross-layer optimization that are difficult to realize when trajectories are split across log stores, vector databases, and task-specific pipelines. For example, a trajectory system should support queries such as: finding tool calls preceded by unsupported model claims; retrieving failures semantically similar to a given case together with the evidence used to classify them; or identifying model invocations that repeatedly process redundant context and correlating them with runtime cost. Such queries combine structural traversal, semantic predicates, temporal ordering, and provenance in a single analysis.这些属性创造了跨层优化的机会，而当轨迹被分散在日志存储、向量数据库和特定任务流水线中时，这些机会很难实现。例如，轨迹系统应支持如下查询：查找包含不受支持的模型声明的工具调用；检索与给定案例语义相似的失败案例，并连同用于对其进行分类的证据一起返回；或者识别反复处理冗余上下文的模型调用，并将它们与运行时成本关联起来。此类查询在单次分析中结合了结构遍历、语义谓词、时间顺序和来源信息。

We therefore envision TrajectoryDB, a trajectory-native data management system that treats raw trajectories and their derived data as first-class citizens.因此，我们构想了 TrajectoryDB，这是一种轨迹原生数据管理系统，将原始轨迹及其衍生数据视为一等公民。

TrajectoryDB provides a unified data model for execution records, their structural and temporal relationships, semantic annotations, and derived state, together with query operators that jointly reason over structure, order, semantics, and lineage. Rather than layering independent document, vector, graph, and log systems, TrajectoryDB co-designs ingestion, storage, and query processing around trajectory-specific access patterns and redundancies. Our goal is to make agent trajectories as natural to store, query, and optimize as documents are in document databases or time-series data are in time-series databases.TrajectoryDB 为执行记录、它们的结构和时间关系、语义注释以及衍生状态提供了一个统一的数据模型，并配有能够联合对结构、顺序、语义和血缘进行推理的查询算子。TrajectoryDB 没有采用分层堆叠独立的文档、向量、图和日志系统的方式，而是围绕轨迹特定的访问模式和冗余，对摄入、存储和查询处理进行了协同设计。我们的目标是使智能体轨迹在存储、查询和优化方面变得像文档数据库中的文档或时序数据库中的时序数据一样自然。

2. Trajectory as a New Data Type2. 作为新数据类型的轨迹

2.1. Agent Trajectory2.1. 智能体轨迹

Agent trajectory. An agent can be viewed as a runtime loop that orchestrates interactions between a model and its environment. The basic unit of communication between an agent and the model is a message, which contains a role and its associated content. There are typically four roles: system refers to the system prompt, which specifies instructions that always apply, user provides user input, assistant records model responses, and tool captures results returned by external tools. To decide what to do next, the agent sends the model a request containing the current context, i.e., the accumulated messages till now and other relevant states, and receives a response that it may then execute. We refer to one such model request and its resulting execution as a step. A user input can trigger multiple steps before the agent returns a response to the user, which forms a turn. A task often spans multiple turns, and the resulting sequence of turns forms a session. We call the sequence of requests ¹¹ 1 Each request carries an accumulative context., messages, and tool executions produced while completing a task as an agent trajectory.智能体轨迹。智能体可以被视为一个编排模型与环境之间交互的运行时循环。智能体与模型之间通信的基本单位是消息，其中包含角色及其相关内容。通常有四种角色：system 指系统提示词，指定始终适用的指令；user 提供用户输入；assistant 记录模型响应；tool 捕获外部工具返回的结果。为了决定下一步做什么，智能体向模型发送一个包含当前上下文（即迄今为止累积的消息和其他相关状态）的请求，并接收一个它随后可能执行的响应。我们将这样的一次模型请求及其产生的执行称为一个步骤（step）。一个用户输入可以在智能体向用户返回响应之前触发多个步骤，这构成了一个轮次（turn）。一个任务通常跨越多个轮次，由此产生的轮次序列形成一个会话（session）。我们将智能体在完成任务时产生的请求、消息和工具执行序列称为智能体轨迹。

Execution configuration. Beyond the trajectory itself, agent execution also produces information often queried alongside it, including the configuration used to instantiate the agent and telemetry from the underlying system. A trajectory often also records the components and settings that shaped its execution, including the model, available tools and their versions, and sampling parameters such as temperature and random seed. Together, this metadata describes the environment in which the agent interacted and supports reproducibility, debugging, and comparison across runs.执行配置。除了轨迹本身，智能体执行还会产生通常与其一同查询的信息，包括用于实例化智能体的配置以及来自底层系统的遥测数据。轨迹通常还会记录影响其执行的组件和设置，包括模型、可用工具及其版本，以及温度（temperature）和随机种子等采样参数。这些元数据共同描述了智能体进行交互的环境，并支持可重复性、调试以及跨运行的比较。

Operational telemetry. A trajectory may also include system-level measurements associated with its execution. Time to first token (TTFT) and per-step latency can support service-level agreement (SLA) and user-experience (UX) monitoring. Input and output token counts, together with cache-hit ratios, can inform cost and resource optimization. Retries, rate-limit events, timeouts, and error codes provide signals for diagnosing failures and triggering operational alerts. Tool call resource usage helps identify opportunities to improve agent execution.运行遥测。轨迹还可以包含与其执行相关的系统级测量数据。首字延迟（TTFT）和每步延迟可以支持服务等级协议（SLA）和用户体验（UX）监控。输入和输出的 Token 计数以及缓存命中率可以为成本和资源优化提供参考。重试、速率限制事件、超时和错误代码为诊断失败和触发操作警报提供了信号。工具调用的资源使用情况有助于识别改进智能体执行的机会。

Refer to caption — Figure 1. Agent trajectories can branch through subagents and forks, forming a tree of sessions. Within each session, execution follows a session-turn-step-message hierarchy. Trajectories are not just logs; they are evolving, structured execution records with semantic content, repeated context, and derived data whose provenance matters. Existing systems each handle only part of this. Alongside the trajectory, configuration metadata records the model and settings that produced it, while telemetry captures runtime performance.图 1. 智能体轨迹可以通过子智能体和分支进行分叉，形成一个会话树。在每个会话内，执行遵循“会话-轮次-步骤-消息”的层级结构。轨迹不仅仅是日志；它们是不断演变的、结构化的执行记录，包含语义内容、重复的上下文以及来源至关重要的数据。现有系统各自仅处理其中的一部分。除了轨迹之外，配置元数据记录了产生它的模型和设置，而遥测数据则捕获了运行时性能。

2.2. Diverse Use Cases2.2. 多样化的用例

Trajectories support a range of downstream tasks. We group six representative use cases into three categories: (A) learning from past experience, (B) analyzing and controlling agent behavior, and (C) monitoring and optimizing runtime execution. 轨迹支持一系列下游任务。我们将六个代表性用例分为三类： (A) 从过往经验中学习， (B) 分析和控制智能体行为，以及 (C) 监控和优化运行时执行。

A.1 Extracting reusable memory. Agents frequently extract memory from past trajectories (Zhao et al., 2024; Fu et al., 2024; Ouyang et al., 2026; Zhang et al., 2026). These methods distill lessons from reasoning, tool calls, observations, and final task artifacts such as a markdown-formatted webpage. The resulting memory can guide future tasks without replaying the full trajectory.A.1 提取可重用记忆。智能体经常从过去的轨迹中提取记忆（Zhao 等人，2024；Fu 等人，2024；Ouyang 等人，2026；Zhang 等人，2026）。这些方法从推理、工具调用、观察结果以及最终任务制品（如 Markdown 格式的网页）中提炼经验。产生的记忆可以在不重放完整轨迹的情况下指导未来的任务。

A.2 Fine-tuning from successful trajectories. Trajectories also serve as training data. In rejection-sampling fine-tuning (RFT) (Yuan et al., 2023), as used by SWE-Gym (Pan et al., 2025), SWE-smith (Yang et al., 2025), and R2E-Gym (Jain et al., 2025), successful trajectories are rendered into the student model’s chat template. By autoregressive optimization, successful multi-step behavior is transferred into the model.A.2 从成功轨迹中进行微调。轨迹也可以作为训练数据。在 SWE-Gym（Pan 等人，2025）、SWE-smith（Yang 等人，2025）和 R2E-Gym（Jain 等人，2025）所使用的拒绝采样微调（RFT）（Yuan 等人，2023）中，成功的轨迹被渲染为学生模型的聊天模板。通过自回归优化，成功的多步行为被迁移到模型中。

B.1 Root-cause analysis. Trajectories support failure diagnosis and anomaly detection. For example, TRAIL (Deshpande et al., 2025) identifies reasoning, planning, and system-execution errors in the trajectory; AgentRx (Barke et al., 2026) checks each step against constraints derived from tool schemas and domain policies, then uses the resulting violations to localize the first unrecoverable failure.B.1 根本原因分析。轨迹支持故障诊断和异常检测。例如，TRAIL（Deshpande 等人，2025）识别轨迹中的推理、规划和系统执行错误；AgentRx（Barke 等人，2026）根据工具模式和领域策略衍生的约束检查每一步，然后利用由此产生的违规情况来定位首次不可恢复的故障。

B.2 Enforcing safety and security. Trajectories help to reveal unsafe behavior. Tool-level checks inspect allowed actions, arguments, and anomalous call sequences (FINOS, 2026; Wiz, 2026), while LLM monitors inspect an agent’s reasoning for signs of test subversion or deception (Baker et al., 2025). Importantly, a sequence can be unsafe even when each action appears acceptable in isolation. OpenAI observed this behavior in long-running agents and introduced monitoring over the entire evolving trajectory rather than individual actions (OpenAI, 2026a).B.2 强制执行安全和保障。轨迹有助于揭示不安全行为。工具级检查会审查允许的操作、参数和异常的调用序列（FINOS, 2026; Wiz, 2026），而 LLM 监控器则会检查智能体的推理，以寻找测试颠覆或欺骗的迹象（Baker 等人，2025）。重要的是，即使每个操作单独看起来都是可接受的，序列也可能是不安全的。OpenAI 在长期运行的智能体中观察到了这种行为，并引入了针对整个演变轨迹而非单个操作的监控（OpenAI, 2026a）。

C.1 Monitoring runtime health. Operational telemetry supports performance and cost monitoring. Systems such as LangSmith, Langfuse, and Datadog record model and tool executions together with latency, token usage, cost, and errors (LangChain, 2026; Langfuse, 2026; Datadog, 2026). Persisting this telemetry enables both longitudinal analysis and post-hoc diagnosis: operators can detect regressions or cost spikes across runs and then trace an anomaly back to the model or tool call that caused it.C.1 监控运行时健康状况。操作遥测支持性能和成本监控。LangSmith、Langfuse 和 Datadog 等系统记录模型和工具执行情况，以及延迟、Token 使用量、成本和错误（LangChain, 2026; Langfuse, 2026; Datadog, 2026）。持久化这些遥测数据既能进行纵向分析，也能进行事后诊断：操作员可以检测跨运行的回归或成本激增，然后将异常追溯到导致它的模型或工具调用。

C.2 System resource usage and scheduling optimizations. Agents frequently block on LLM inference and tool execution, making the scheduling order of LLM requests and tool calls a key determinant of end-to-end performance. Effective scheduling therefore requires exposing agent-level dependency and critical-path information to both LLM serving engines and operating-system schedulers, enabling them to prioritize latency-critical work and allocate resources accordingly (Lin et al., 2024; Luo et al., 2026; Wang et al., 2026).C.2 系统资源使用和调度优化。智能体经常在 LLM 推理和工具执行上阻塞，使得 LLM 请求和工具调用的调度顺序成为端到端性能的关键决定因素。因此，有效的调度需要将智能体级的依赖关系和关键路径信息暴露给 LLM 服务引擎和操作系统调度器，使它们能够优先处理延迟敏感的工作并相应地分配资源（Lin 等人，2024；Luo 等人，2026；Wang 等人，2026）。

3. Trajectory-DB Requirements3. Trajectory-DB 的需求

Despite the diverse use cases, these workloads repeatedly access, filter, and aggregate overlapping parts of a trajectory. We next summarize common data operations into three requirements that a database engine should support.尽管用例各异，但这些工作负载会反复访问、过滤和聚合轨迹中重叠的部分。接下来，我们将常见的操作总结为数据库引擎应支持的三项需求。

3.1. Structure-aware Retrieval3.1. 结构感知检索

3.1.1. Session-structure retrieval.3.1.1. 会话结构检索。

Agent trajectories are naturally hierarchical: a session contains multiple turns, each turn contains multiple agent steps, and each step contains model requests and role-specific messages. Different workloads access this hierarchy at different granularities, from entire sessions to individual steps or messages. A trajectory database should therefore expose this structure explicitly, instead of treating each trajectory as an opaque blob, to support efficient fine-grained retrieval and processing.智能体轨迹本质上是分层的：一个会话包含多个轮次，每个轮次包含多个智能体步骤，每个步骤包含模型请求和特定于角色的消息。不同的工作负载以不同的粒度访问此层级结构，从整个会话到单个步骤或消息。因此，轨迹数据库应明确暴露此结构，而不是将每个轨迹视为一个不透明的二进制大对象（blob），以支持高效的细粒度检索和处理。

Table 1. Mapping trajectory requirements to system challenges.表 1. 轨迹需求与系统挑战的映射。

Requirements	C1	C2	C3	C4	C5	C6	C7
3.1.1 Session-structure retrieval	✓	✓	✓	✓	✓
3.1.2 Sequence retrieval			✓		✓	✓
3.2.1 Composing semantic and relational operators				✓	✓	✓	✓
3.2.2 Incremental semantic evaluation	✓			✓			✓
3.3.1 Context reconstruction	✓	✓		✓	✓
3.3.2 Preserving lineage for semantic judgments		✓	✓			✓	✓

Challenges:挑战：

C1: Reconstructing request hierarchies.C1：重构请求层级。

C2: Supporting graph structures over relational data.C2：支持关系数据上的图结构。

C3: Reconciling conflicting physical layouts.C3：协调冲突的物理布局。

C4: Storing large text payloads efficiently.C4：高效存储大型文本负载。

C5: Enabling order-sensitive query processing.C5：启用顺序敏感的查询处理。

C6: Co-optimizing relational and semantic operators.C6：协同优化关系算子和语义算子。

C7: Caching semantic judgments.C7：缓存语义判断。

Session retrieval. Some workloads consume complete sessions. For example, ExpeL (Zhao et al., 2024) and AutoGuide (Fu et al., 2024) compare successful and failed sessions on similar tasks to identify reusable lessons. A session, however, is not always a linear sequence when an agent spawns subagents, as shown in Figure 1. Each subagent creates a branch rooted at the step that spawned it, so session retrieval must preserve this parent-child structure.会话检索。有些工作负载会消耗完整的会话。例如，ExpeL（Zhao 等人，2024）和 AutoGuide（Fu 等人，2024）会比较相似任务上成功和失败的会话，以识别可重用的经验。然而，如图 1 所示，当智能体生成子智能体时，会话并不总是一个线性序列。每个子智能体都会在生成它的步骤处创建一个分支，因此会话检索必须保留这种父子结构。

Step retrieval. Failure diagnosis often operates at the granularity of a step. For example, AgentRx (Barke et al., 2026) derives execution rules from policies and tool definitions, then retrieves each step and checks it against those rules. Some checks depend on multiple steps. For example, detecting whether an agent asks again for information it already obtained requires comparing the current step with prior tool results in the session.步骤检索。故障诊断通常在步骤粒度上进行。例如，AgentRx（Barke 等人，2026）从策略和工具定义中派生执行规则，然后检索每一步并根据这些规则进行检查。有些检查依赖于多个步骤。例如，检测智能体是否再次询问已获得的信息，需要将当前步骤与会话中先前的工具结果进行比较。

Role retrieval. Fine-tuning has to distinguish the messages based on roles. The full conversation is used as input for training, but the loss is typically computed only over tokens generated by the assistant. The roles must therefore be stored as an explicit attribute so that only assistant messages are selected efficiently.角色检索。微调必须根据角色区分消息。完整的对话被用作训练输入，但损失通常仅针对由助手（assistant）生成的 Token 进行计算。因此，必须将角色存储为显式属性，以便能够高效地仅选择助手消息。

3.1.2. Sequence retrieval.3.1.2. 序列检索。

Many trajectory workloads identify patterns over ordered events rather than individual records. Memory extraction, for example, identifies recurring tool-use sequences and turns them into reusable lessons (Fu et al., 2024; Ouyang et al., 2026): edit $\rightarrow$ failed test $\rightarrow$ edit the same file may indicate an ineffective strategy, while search $\rightarrow$ read $\rightarrow$ edit $\rightarrow$ passing test suggests a successful one. Sequence patterns can also span different message roles and actions. A safety policy may, for example, require assistant describes action $\rightarrow$ user confirms $\rightarrow$ action, making the presence and order of the confirmation part of the check. Operational analysis introduces yet another event sequence: LLM requests, retries, tool executions, and their telemetry can be matched in sequence to identify recovery behavior, repeated failures, or latency-critical paths. Sequence detection must therefore operate over heterogeneous trajectory events while preserving their execution order.许多轨迹工作负载是在有序事件而非单个记录上识别模式。例如，记忆提取会识别反复出现的工具使用序列，并将其转化为可重用的经验（Fu 等人，2024；Ouyang 等人，2026）：编辑 → 失败测试 → 编辑同一个文件可能表示一种无效策略，而搜索 → 读取 → 编辑 → 通过测试则暗示了一种成功策略。序列模式还可以跨越不同的消息角色和操作。例如，安全策略可能要求“助手描述操作 → 用户确认 → 操作”，使得确认的存在和顺序成为检查的一部分。操作分析引入了另一种事件序列：LLM 请求、重试、工具执行及其遥测数据可以按顺序匹配，以识别恢复行为、重复失败或延迟关键路径。因此，序列检测必须在异构轨迹事件上运行，同时保留其执行顺序。

3.2. LLMs as UDFs3.2. LLM 作为用户定义函数（UDF）

Trajectory analysis often requires predicates over the meaning of free-form text rather than exact matches over literals. Exposing LLM-based analysis as a general UDF allows the same semantic primitive to be reused across workloads and composed with other query operators.轨迹分析通常需要对自由格式文本的含义进行谓词判断，而不是对字面量进行精确匹配。将基于 LLM 的分析作为通用 UDF 暴露出来，允许相同的语义原语在不同工作负载中重用，并与其他查询算子组合使用。

3.2.1. Composing semantic and relational operators.3.2.1. 组合语义算子和关系算子。

Semantic evaluation in trajectory queries is often embedded within a larger relational plan: its inputs are assembled from multiple records, and its output may feed downstream joins, ordering, or aggregation (Patel et al., 2025; Mang et al., 2026). For example, consider a root-cause query that asks for the first step whose tool call violates a constraint, as in step-level failure diagnosis (Barke et al., 2026). The engine must group records by session, assemble the context needed to judge each step, apply the semantic predicate, and then use trajectory order to select the first violating step. Other queries compose semantic judgments with telemetry. To determine whether latency spikes are associated with recovery attempts after tool failures, for example, the engine first uses semantic evaluation to identify failures and then joins those judgments with runtime measurements (LangChain, 2026; Langfuse, 2026; Datadog, 2026). In these cases, semantic operators need to compose with relational and order-sensitive operators throughout the query plan.轨迹查询中的语义评估通常嵌入在更大的关系计划中：其输入由多条记录组装而成，其输出可能馈送到下游的连接、排序或聚合中（Patel 等人，2025；Mang 等人，2026）。例如，考虑一个根本原因查询，它要求找出工具调用违反约束的第一个步骤，如步骤级故障诊断（Barke 等人，2026）。引擎必须按会话对记录进行分组，组装判断每一步所需的上下文，应用语义谓词，然后利用轨迹顺序选择第一个违规步骤。其他查询将语义判断与遥测数据结合。例如，为了确定延迟激增是否与工具失败后的恢复尝试相关，引擎首先使用语义评估来识别失败，然后将这些判断与运行时测量数据进行连接（LangChain, 2026; Langfuse, 2026; Datadog, 2026）。在这些情况下，语义算子需要在整个查询计划中与关系算子和顺序敏感算子进行组合。

3.2.2. Incremental semantic evaluation over growing trajectories.3.2.2. 对不断增长的轨迹进行增量语义评估。

Semantic predicates often operate on growing inputs, so their results must be updated statefully to remain valid as new evidence arrives. For example, as new sessions apply a memory, each outcome provides new evidence about whether that memory remains valid. The judge updates its prior assessment with the new outcome, and accumulated conflicts may trigger revision or invalidation of the memory. Safety monitoring follows the same pattern: as new actions arrive, the judge updates its assessment of whether the agent is drifting toward unsafe or off-plan behavior. Runtime-health analysis also compares a newly observed failure with recent failures to determine whether they share the same underlying fault. In each case, semantic evaluation must build on previous state and incorporate new evidence as the trajectory grows.语义谓词通常在不断增长的输入上运行，因此其结果必须以有状态的方式进行更新，以便在有新证据到达时保持有效。例如，随着新会话应用某种记忆，每个结果都会提供关于该记忆是否仍然有效的新证据。评判者会利用新结果更新其先前的评估，累积的冲突可能会触发记忆的修订或失效。安全监控遵循相同的模式：随着新操作的到来，评判者会更新其关于智能体是否正在偏向不安全或偏离计划行为的评估。运行时健康分析也会将新观察到的失败与最近的失败进行比较，以确定它们是否共享相同的潜在故障。在每种情况下，语义评估都必须建立在先前的状态之上，并随着轨迹的增长纳入新证据。

3.3. Lineage Query3.3. 血缘查询

3.3.1. Context reconstruction.3.3.1. 上下文重构。

Long-running agents often compact their context by replacing earlier messages with summaries (Anthropic, 2025; Li et al., 2026). After compaction, a model request contains summaries together with recent messages rather than the full original history. Several workloads still need to recover that history. A failure mode in root-cause analysis is that an agent violates a constraint because the relevant message was summarized away. Diagnosing such failure requires reconstructing the pre-compaction context to identify which compaction removed the information needed. Memory verification similarly requires the original trajectory to locate the evidence to support the memory (Ouyang et al., 2026). Evaluating a different compaction strategy also requires the original history so that an alternative compacted context can be constructed and replayed (Li et al., 2026).长期运行的智能体通常通过用摘要替换早期消息来压缩其上下文（Anthropic, 2025; Li 等人，2026）。压缩后，模型请求包含摘要以及最近的消息，而不是完整的原始历史记录。一些工作负载仍然需要恢复该历史记录。根本原因分析中的一种失败模式是，智能体违反了约束，因为相关消息被摘要掉了。诊断此类失败需要重构压缩前的上下文，以确定是哪次压缩移除了所需的信息。记忆验证同样需要原始轨迹来定位支持记忆的证据（Ouyang 等人，2026）。评估不同的压缩策略也需要原始历史记录，以便可以构建和重放替代的压缩上下文（Li 等人，2026）。

3.3.2. Preserving lineage for semantic operator.3.3.2. 为语义算子保留血缘。

TrajectoryDB should preserve not only each semantic operator result, but also its provenance: the evaluated input, supporting trajectory records, judge model, evaluation criterion, and other information needed to reconstruct how the result was derived. For fine-tuning, an LLM judge may label whether a message is supported by its context, and the resulting label can be reused across subsequent training runs. Other use cases require finer-grained lineage. For example, linking each extracted memory or failure judgment to the specific trajectory evidence that supports it (Fu et al., 2024; Ouyang et al., 2026; Barke et al., 2026). This lineage serves two purposes. First, it enables invalidation: if the source trajectory changes, the memory becomes stale, or the judge model or criterion is updated, the system can identify which judgments need to be reevaluated. Second, it supports provenance queries that ask what produced a judgment and which trajectory evidence supports it. Semantic judgments therefore become reusable derived data rather than outputs of one-time LLM calls.TrajectoryDB 不仅应保留每个语义算子的结果，还应保留其来源：被评估的输入、支持性的轨迹记录、评判模型、评估标准以及重构结果推导过程所需的其他信息。对于微调，LLM 评判者可能会标记一条消息是否得到其上下文的支持，由此产生的标签可以在后续训练运行中重用。其他用例需要更细粒度的血缘。例如，将每个提取的记忆或失败判断与支持它的特定轨迹证据联系起来（Fu 等人，2024；Ouyang 等人，2026；Barke 等人，2026）。这种血缘有两个目的。首先，它实现了失效机制：如果源轨迹发生变化、记忆变得过时，或者评判模型或标准被更新，系统可以识别出哪些判断需要重新评估。其次，它支持血缘查询，询问是什么产生了某个判断以及哪些轨迹证据支持它。因此，语义判断变成了可重用的衍生数据，而不是一次性 LLM 调用的输出。

4. Challenges and Opportunities4. 挑战与机遇

In this section, we map the requirements above to the key challenges as shown in Table 1, and discuss where existing database systems fall short. We collect a one-month trace from our production system (FreeInference, 2026) and use it to characterize agent trajectory behavior in this section.在本节中，我们将上述需求映射到表 1 所示的关键挑战，并讨论现有数据库系统的不足之处。我们收集了来自生产系统（FreeInference, 2026）的一个月跟踪数据，并在本节中使用它来刻画智能体轨迹行为。

4.1. Structure Reconstruction and Maintenance4.1. 结构重构与维护

Trajectory structure is scattered across timestamped requests. Therefore, TrajectoryDB should reconstruct this structure and organize it both logically and physically.轨迹结构分散在带时间戳的请求中。因此，TrajectoryDB 应重构此结构，并在逻辑和物理上对其进行组织。

4.1.1. Reconstructing Request Hierarchy4.1.1. 重构请求层级

When agent activity is stored as generic records, relationships among sessions, turns, steps, and messages are often implicit. Without session identifiers, requests may need to be associated through shared context. Turn and step boundaries may likewise need to be inferred from events such as user messages and completed tool calls. Recovering the execution hierarchy therefore requires nontrivial reconstruction.当智能体活动作为通用记录存储时，会话、轮次、步骤和消息之间的关系通常是隐式的。如果没有会话标识符，请求可能需要通过共享上下文进行关联。轮次和步骤边界同样可能需要从用户消息和已完成的工具调用等事件中推断出来。因此，恢复执行层级需要非平凡的重构。

Design question: Which structures should be reconstructed eagerly? Eager reconstruction simplifies downstream queries but adds work to the ingestion path. OpenTelemetry notes that complex filtering and transformation can significantly reduce Collector performance (OpenTelemetry, 2025); ClickHouse similarly found that parsing and transformation in its OTel pipeline consumed substantial CPU, and replacing this path enabled $20\times$ higher throughput with less than $10\%$ of the previous CPU footprint (Crispin and McDiarmid, 2025). Conversely, retaining only timestamped records shifts reconstruction cost to every query. TrajectoryDB must therefore determine which structural relationships to materialize during ingestion and which to derive lazily.设计问题：哪些结构应该被急切地（eagerly）重构？急切重构简化了下游查询，但增加了摄入路径的工作量。OpenTelemetry 指出，复杂的过滤和转换会显著降低收集器性能（OpenTelemetry, 2025）；ClickHouse 同样发现，其 OTel 流水线中的解析和转换消耗了大量 CPU，而替换该路径使其吞吐量提高了 20 倍，CPU 占用率不到原来的 10%（Crispin and McDiarmid, 2025）。相反，仅保留带时间戳的记录会将重构成本转移到每次查询中。因此，TrajectoryDB 必须确定在摄入期间物化哪些结构关系，以及懒惰地（lazily）派生哪些结构关系。

Requests belonging to the same long-running agent trajectory may arrive far apart in time. In fact, consecutive requests from the same workflow can be separated by hours or days, as shown in footnote 3. Moreover, while most sessions are short-lived, the tail can last weeks. The ingestion layer must therefore associate each new request with a trajectory state that may have been created much earlier.属于同一个长期运行的智能体轨迹的请求在时间上可能相隔很远。事实上，来自同一工作流的连续请求可能相隔数小时或数天，如脚注 3 所示。此外，虽然大多数会话寿命较短，但长尾会话可能持续数周。因此，摄入层必须将每个新请求与可能在很久之前创建的轨迹状态相关联。

Design question: How to maintain state for long-lived streaming trajectories? To correlate each incoming request with earlier requests from the same session, the ingestion layer must retain per-session state, such as accumulated context and trajectory metadata. Stateful stream-processing systems (Apache Flink, 2026; Apache Kafka, 2026; Apache Spark, 2026) support such cross-record correlation, but typically rely on a notion of when retained state can safely be finalized or discarded, using mechanisms such as watermarks or grace periods. Agent trajectories provide no natural cutoff: a seemingly inactive session may resume hours or even days later. Setting a short inactivity bound risks prematurely splitting a single trajectory, whereas setting a long bound leaves many inactive sessions open and increases state overhead. Existing stream-processing abstractions therefore do not naturally support incremental reconstruction of long-lived agent trajectories without assuming a bounded or predictable completion window.设计问题：如何为长期运行的流式轨迹维护状态？为了将每个传入请求与同一会话中较早的请求关联起来，摄入层必须保留会话级状态，例如累积的上下文和轨迹元数据。有状态流处理系统（Apache Flink, 2026; Apache Kafka, 2026; Apache Spark, 2026）支持此类跨记录关联，但通常依赖于何时可以安全地终结或丢弃保留状态的概念，使用水印（watermarks）或宽限期等机制。智能体轨迹没有自然的截止点：看似不活跃的会话可能会在数小时甚至数天后恢复。设置较短的不活跃界限可能会过早地拆分单个轨迹，而设置较长的界限则会使许多不活跃的会话保持打开状态并增加状态开销。因此，现有的流处理抽象在不假设有界或可预测完成窗口的情况下，无法自然地支持长期智能体轨迹的增量重构。

4.1.2. Maintaining Graph Structure over Relational Data4.1.2. 在关系数据上维护图结构

Agent trajectories contain graph-structured relationships. Subagent execution creates tree-shaped branches, while lineage introduces labeled many-to-many edges: memories are derived from evidence, judgments are supported by or inconsistent with earlier records, and failures may be caused by or repeat earlier failures. Together, these relationships form DAGs over trajectory records.智能体轨迹包含图结构关系。子智能体执行创建树状分支，而血缘引入了带标签的多对多边：记忆源于证据，判断由先前记录支持或与之矛盾，失败可能由先前失败引起或重复先前失败。总之，这些关系在轨迹记录上形成了有向无环图（DAG）。

Design question: How to efficiently support both graph traversal and relational analytics? Relational engines can encode edges using fields such as parent_id, but traversal then requires recursive queries such as PostgreSQL recursive CTEs (PostgreSQL Global Development Group, 2026e). These queries can be expensive for deep or branching graphs and do not inherently preserve traversal order (PostgreSQL Global Development Group, 2026b; PostgreSQL Global Development Group, 2026e). Downstream sequence or window analytics must therefore reconstruct that order explicitly (PostgreSQL Global Development Group, 2026d). Native graph engines support traversal directly, but storing large trajectory payloads can increase I/O and deserialization cost. Separating graph topology from relational payloads avoids this overhead but introduces costly cross-system coordination. SQL/PGQ integrates graph patterns with SQL (Deutsch et al., 2021), while Chimera (Lee et al., 2025) combines relational storage with native adjacency structures. However, traversal may still require joins or pointer chasing between topology and payloads. Agent trajectories are more specialized: they are append-only, mostly forest-shaped, and naturally clustered by session. Exploiting these properties may enable tighter integration of graph traversal with relational and ordered access.设计问题：如何高效支持图遍历和关系分析？关系引擎可以使用 parent_id 等字段对边进行编码，但遍历需要递归查询，如 PostgreSQL 的递归 CTE（PostgreSQL Global Development Group, 2026e）。对于深度或分支图，这些查询可能非常昂贵，且本身并不保留遍历顺序（PostgreSQL Global Development Group, 2026b; PostgreSQL Global Development Group, 2026e）。因此，下游序列或窗口分析必须显式重构该顺序（PostgreSQL Global Development Group, 2026d）。原生图引擎直接支持遍历，但存储大型轨迹负载会增加 I/O 和反序列化成本。将图拓扑与关系负载分离避免了这种开销，但引入了昂贵的跨系统协调。SQL/PGQ 将图模式与 SQL 集成（Deutsch 等人，2021），而 Chimera（Lee 等人，2025）将关系存储与原生邻接结构相结合。然而，遍历可能仍然需要在拓扑和负载之间进行连接或指针追踪。智能体轨迹更专业：它们是仅追加的、主要是森林状的，并且自然地按会话聚类。利用这些属性可能实现图遍历与关系及顺序访问的更紧密集成。

4.2. Data Layout and Storage4.2. 数据布局与存储

4.2.1. Reconciling Conflicting Physical Layouts4.2.1. 协调冲突的物理布局

Trajectory workloads impose different locality requirements on the same data. Replay and context reconstruction scan full requests in session order, while sequence matching searches ordered requests for particular subsequences; both favor session-contiguous layouts. In contrast, role filtering, tool-pattern mining, and telemetry analysis access only a few fields across many sessions, favoring columnar layouts. Lineage queries introduce a third pattern, where locality follows graph links among records rather than their session or field organization.轨迹工作负载对相同数据施加了不同的局部性要求。重放和上下文重构按会话顺序扫描完整请求，而序列匹配在有序请求中搜索特定子序列；两者都倾向于会话连续布局。相比之下，角色过滤、工具模式挖掘和遥测分析跨多个会话访问少数几个字段，倾向于列式布局。血缘查询引入了第三种模式，其局部性遵循记录间的图链接，而非其会话或字段组织。

Design question: How should trajectories be physically organized for diverse access patterns? No single layout naturally serves all three. Transactional databases such as PostgreSQL are attractive primary stores because trajectory recording often occurs alongside application state such as users, authentication, and billing. However, large analytical scans over growing trajectory volumes can become expensive.设计问题：轨迹应如何为多样化的访问模式进行物理组织？没有单一布局能自然地服务于所有三种模式。事务性数据库（如 PostgreSQL）是极具吸引力的主要存储，因为轨迹记录通常与用户、身份验证和计费等应用程序状态同时发生。然而，对不断增长的轨迹容量进行大型分析扫描可能会变得非常昂贵。

TrajectoryDB must therefore determine the primary representation, which auxiliary layouts or indexes to maintain, and how to keep them consistent as trajectories continuously grow.因此，TrajectoryDB 必须确定主要表示形式、要维护哪些辅助布局或索引，以及如何在轨迹持续增长时保持它们的一致性。

4.2.2. Storing Large but Redundant Text Payload4.2.2. 存储大型但冗余的文本负载

(a) (a)

(b) (b)

Figure 2. (a) CDF of request inter-arrival time (IAT); (b) 80% of the sessions mutate the prefix during lifetime, and the figure shows a CDF of divergence position, normalized by the total session length. Data from production³³ 3 We operate https://freeinference.org, which serves half a trillion tokens every month..图 2. (a) 请求到达间隔时间（IAT）的累积分布函数（CDF）；(b) 80% 的会话在生命周期内会改变前缀，图中显示了发散位置的 CDF，并按总会话长度进行了归一化。数据来自生产环境3。

Each turn sends the full context with all the previous turns: the $n^{th}$ request in the trajectory contains all the messages in the previous $n-1$ turns. Continuously recording agent inputs and outputs can generate enormous amounts of text. Assuming a conservative throughput of 2,000 output tokens/s per H100 (NVIDIA, 2025) and a 50:1 input-to-output ratio (Angus et al., 2026), a 1 GW AI facility with 1,000,000 fully utilized H100s would generate roughly 102 billion logged tokens/s. At approximately four bytes per token (OpenAI, 2026b), naively storing all input and output tokens would require about 35 PB/day. Such large amount of text becomes the payload of the prompt column if storing the request in a table.每一轮都会发送包含所有先前轮次的完整上下文：轨迹中的第 n 个请求包含了前 n-1 轮中的所有消息。持续记录智能体输入和输出会产生海量的文本。假设每张 H100 的保守吞吐量为 2,000 输出 Token/s（NVIDIA, 2025），且输入输出比为 50:1（Angus 等人，2026），一个拥有 100 万张充分利用的 H100 的 1 GW AI 设施每秒将产生约 1,020 亿个记录的 Token。按每个 Token 大约 4 字节计算（OpenAI, 2026b），天真地存储所有输入和输出 Token 每天将需要约 35 PB。如果将请求存储在表中，如此大量的文本将成为 prompt 列的有效载荷。

Design question: Should the text payload be stored inline or separately? Large payloads are often stored outside of the table. PostgreSQL, for example, splits oversized values into chunks in a separate TOAST table and accesses them through pointers (PostgreSQL Global Development Group, 2026c). This avoids filling the main table with large messages, but breaks the contiguous layout preferred by session-oriented scans. Keeping the payloads inline has the opposite problem: a page may hold only a few messages, causing unnecessary I/O and cache pollution. TrajectoryDB therefore needs a layout that keeps large text efficient to scan without letting it dominate the record storage.设计问题：文本负载应该内联（inline）存储还是分开存储？大型负载通常存储在表外。例如，PostgreSQL 将超大值拆分为块存储在单独的 TOAST 表中，并通过指针访问它们（PostgreSQL Global Development Group, 2026c）。这避免了用大型消息填满主表，但破坏了会话导向扫描所偏好的连续布局。保持负载内联则有相反的问题：一个页面可能只能容纳几条消息，导致不必要的 I/O 和缓存污染。因此，TrajectoryDB 需要一种布局，既能保持大型文本的高效扫描，又不会让它主导记录存储。

Each request typically carries all the messages from the same session as accumulated context, often referred to as a prefix, so storing requests independently duplicates the same prefix many times. The challenge is that context sharing is not always a clean prefix. In production, we observe that 80% of the sessions have context mutation: compaction, truncation of tool results, or edits to earlier context break prefix sharing. This makes it impossible to store only the newly appended turn. For clean sessions, 2(b) shows where sessions diverge, with each fork creating a new instance. A sample of 5,951 sessions from our production systems, 3,794 never fork and therefore contribute only one instance each. The remaining sessions fork into multiple instances and account for over 80% of all instances. These forks occur throughout the sessions without concentrating at a particular stage, while non-forking sessions account for less than 20% of all instances.每个请求通常携带来自同一会话的所有消息作为累积上下文（通常称为前缀），因此独立存储请求会多次重复相同的上下文。挑战在于上下文共享并不总是干净的前缀。在生产环境中，我们观察到 80% 的会话存在上下文变异：压缩、工具结果的截断或对早期上下文的编辑打破了前缀共享。这使得仅存储新追加的轮次变得不可能。对于干净的会话，2(b) 显示了会话在何处发散，每个分叉创建一个新实例。在我们生产系统的 5,951 个会话样本中，3,794 个从未分叉，因此每个贡献一个实例。其余会话分叉成多个实例，占所有实例的 80% 以上。这些分叉发生在会话的整个过程中，而不是集中在某个特定阶段，而非分叉会话占所有实例的比例不到 20%。

Design question: How to support prefix-aware text compression and deduplication? Existing compression is unaware of request-level sharing. Database compression usually works within a page or block. If the same message appears in requests stored in different blocks, that redundancy is not shared (Oracle, 2025; Oracle, 2026; ClickHouse, 2026). Dictionary encoding reuses identical values across rows, but trajectory payloads are long and mostly distinct. The dictionary therefore grows to the size of the data itself without exploiting redundancy across different chunks (Apache Parquet, 2026). Data exported from our production PostgreSQL instance achieves a 20 $\times$ compression ratio with Zstandard, compared with less than 2 $\times$ using PostgreSQL’s built-in compression. For trajectories, a new request extends an earlier context until compaction, truncation, or another update causes the histories to diverge. The storage engine should exploit this known sharing directly rather than rediscovering redundancy from raw bytes or literals within physical data blocks.设计问题：如何支持前缀感知的文本压缩和去重？现有的压缩技术并不了解请求级的共享。数据库压缩通常在页面或块内工作。如果相同的消息出现在存储在不同块中的请求中，该冗余就不会被共享（Oracle, 2025; Oracle, 2026; ClickHouse, 2026）。字典编码在行间重用相同的值，但轨迹负载很长且大多不同。因此，字典会增长到数据本身的大小，而无法利用跨不同块的冗余（Apache Parquet, 2026）。从我们的生产 PostgreSQL 实例导出的数据使用 Zstandard 实现了 20 倍的压缩比，而使用 PostgreSQL 内置压缩的压缩比不到 2 倍。对于轨迹，新请求会扩展先前的上下文，直到压缩、截断或其他更新导致历史记录发散。存储引擎应直接利用这种已知的共享，而不是从物理数据块内的原始字节或字面量中重新发现冗余。

4.3. Query Language and Optimization4.3. 查询语言与优化

4.3.1. Enabling Order-Sensitive Query Processing4.3.1. 启用顺序敏感的查询处理

For trajectory queries, order can determine the answer rather than merely its presentation. Sequence matching, for example, must distinguish edit $\rightarrow$ failed test $\rightarrow$ edit from edit $\rightarrow$ edit $\rightarrow$ failed test, despite containing the same events. Likewise, a rolling reward delta is meaningful only when records are partitioned by session and ordered by request arrival (PostgreSQL Global Development Group, 2026d). The relevant order depends on query scope. Within a subagent branch, events follow a natural execution order. Across subagents, however, branches may execute concurrently, so no single total order exists. A trajectory query model must therefore support both branch-local order and partial order across branches.对于轨迹查询，顺序可以决定结果本身，而不仅仅是其呈现方式。例如，序列匹配必须区分“编辑 → 失败测试 → 编辑”与“编辑 → 编辑 → 失败测试”，尽管它们包含相同的事件。同样，滚动奖励增量仅在记录按会话分区并按请求到达顺序排列时才有意义（PostgreSQL Global Development Group, 2026d）。相关顺序取决于查询范围。在子智能体分支内，事件遵循自然的执行顺序。然而，在子智能体之间，分支可能并发执行，因此不存在单一的总顺序。因此，轨迹查询模型必须同时支持分支局部顺序和跨分支的偏序。

Design question: How to preserve order and optimize the query plan? Current engines treat order as a local property rather than a first-class property of the query plan, while some document stores provide limited native support for ordered analytics (MongoDB, Inc., [n.d.]; Amazon Web Services, [n.d.]). Indexes can produce records in the desired order and avoid explicit sorting (PostgreSQL Global Development Group, 2026a), but subsequent joins, aggregation, or parallel execution may destroy that order. A trajectory-aware engine should therefore track order through operators, reuse existing order rather than recompute it, propagate it through lineage traversal, and explicitly represent partial order across concurrent branches.设计问题：如何保留顺序并优化查询计划？当前的引擎将顺序视为一种局部属性，而非查询计划的一等属性，而一些文档存储对顺序分析提供的原生支持有限（MongoDB, Inc., [n.d.]; Amazon Web Services, [n.d.]）。索引可以按期望的顺序生成记录并避免显式排序（PostgreSQL Global Development Group, 2026a），但随后的连接、聚合或并行执行可能会破坏该顺序。因此，轨迹感知引擎应通过算子跟踪顺序，重用现有顺序而非重新计算它，通过血缘遍历传播它，并显式表示跨并发分支的偏序。

4.3.2. Co-optimization Across Relational and Semantic Operators4.3.2. 跨关系算子和语义算子的协同优化

Trajectory queries often require semantic evaluation because key information is embedded in free-form text, while the resulting judgments are further processed by relational operators. The optimizer must therefore choose an execution order across conventional operators and expensive LLM calls. Pushing a cheap telemetry filter before a semantic judge can reduce LLM invocations, whereas an early, highly selective semantic filter may avoid an expensive traversal. Choosing between these plans requires estimating both the cost and selectivity of relational and semantic operators.轨迹查询通常需要进行语义评估，因为关键信息嵌入在自由文本中，而由此得出的判断结果会进一步由关系运算符处理。因此，优化器必须在传统运算符与高昂的 LLM 调用之间选择执行顺序。在语义判断之前执行低成本的遥测过滤可以减少 LLM 的调用次数，而尽早进行高选择性的语义过滤则可以避免代价高昂的遍历。在这些计划之间进行选择，需要估算关系运算符和语义运算符的成本与选择性。

Design question: How to define a declarative framework to integrate semantic operators into the relational plan? Existing semantic-query systems typically fix the input shape of each LLM operator. LOTUS, for example, defines semantic filters over individual tuples, joins over tuple pairs, and aggregations over a declared relation (Patel et al., 2025). Trajectory queries may instead require an LLM to consume dynamically constructed inputs—such as an ordered subsequence, a lineage neighborhood, or accumulated session context—and then feed its judgment into subsequent relational processing. Supporting such queries requires semantic operators that compose naturally with traversal, ordering, filtering, and aggregation, while remaining visible to the optimizer for joint planning.设计问题：如何定义一个声明式框架，将语义运算符集成到关系计划中？现有的语义查询系统通常会固定每个 LLM 运算符的输入形式。例如，LOTUS 定义了针对单个元组的语义过滤器、针对元组对的连接以及针对已声明关系进行的聚合（Patel 等人，2025）。相比之下，轨迹查询可能需要 LLM 处理动态构建的输入——例如有序子序列、谱系邻域或累积的会话上下文——然后将其判断结果馈送到后续的关系处理中。支持此类查询需要语义运算符，这些运算符既能与遍历、排序、过滤和聚合自然组合，又能对优化器保持可见，以便进行联合规划。

4.3.3. Caching Semantic Results4.3.3. 缓存语义结果

Semantic evaluation is expensive, but can be reused between queries. A memory verifier, safety monitor, and failure-analysis query may ask the same question of whether a session fails. Caching intermediate semantic results avoids such repeated LLM calls. However, these results are fragile: changes to the query, trajectory state, judge model, or evaluation criterion may invalidate them.语义评估成本高昂，但可以在查询之间重用。内存验证器、安全监控器和故障分析查询可能会询问同一个问题：会话是否失败。缓存中间语义结果可以避免此类重复的 LLM 调用。然而，这些结果非常脆弱：对查询、轨迹状态、判断模型或评估标准的更改都可能导致它们失效。

Design question: When can a cached semantic result be safely reused? Existing semantic caches such as GPTCache (Bang, 2023) and MeanCache (Gill et al., 2025) reuse LLM outputs by matching semantically similar inputs. This is insufficient for trajectory queries, where validity depends not only on input similarity but also on the underlying trajectory state. As new steps arrive, previously cached judgments may become stale. Semantic caching for trajectories must therefore be lineage-aware: each cached result should record the trajectory state, query semantics, and model configuration on which it depends, so the system can identify and refresh only results affected by subsequent changes.设计问题：何时可以安全地重用缓存的语义结果？现有的语义缓存（如 GPTCache (Bang, 2023) 和 MeanCache (Gill 等人, 2025)）通过匹配语义相似的输入来重用 LLM 输出。这对于轨迹查询来说是不够的，因为其有效性不仅取决于输入相似度，还取决于底层的轨迹状态。随着新步骤的到来，之前缓存的判断结果可能会过时。因此，针对轨迹的语义缓存必须具备谱系感知能力：每个缓存结果都应记录其所依赖的轨迹状态、查询语义和模型配置，以便系统能够识别并仅刷新受后续更改影响的结果。

5. Related Work5. 相关工作

Semantic operators. LOTUS (Patel et al., 2025) and Palimpzest (Liu et al., 2025) provide declarative frameworks with LLM-powered operators over relational data. Building on Palimpzest’s optimizations for filters and joins, Abacus (Russo et al., 2026) formalizes cost-based optimization for semantic operator systems, searching over model choice, prompting strategy, and cost–quality trade-offs. PLOP (Mang et al., 2026) further optimizes the placement of semantic operators, while UQE (Dai et al., 2024) uses a small model and classifier to identify candidate rows for a semantic predicate and avoid invoking an LLM on every row. Semantic operators are also used for data discovery and preprocessing. DocETL (Shankar et al., 2025) uses LLM-powered operators to discover schemas and structure documents into tables, while EVAPORATE (Arora et al., 2023) uses LLMs to generate extraction code for document processing.语义运算符。LOTUS (Patel 等人, 2025) 和 Palimpzest (Liu 等人, 2025) 提供了声明式框架，支持在关系数据上使用基于 LLM 的运算符。在 Palimpzest 对过滤器和连接进行优化的基础上，Abacus (Russo 等人, 2026) 将语义运算符系统的基于成本的优化形式化，在模型选择、提示策略以及成本与质量的权衡之间进行搜索。PLOP (Mang 等人, 2026) 进一步优化了语义运算符的放置位置，而 UQE (Dai 等人, 2024) 则使用小型模型和分类器来识别语义谓词的候选行，从而避免对每一行都调用 LLM。语义运算符也被用于数据发现和预处理。DocETL (Shankar 等人, 2025) 使用基于 LLM 的运算符来发现模式并将文档结构化为表格，而 EVAPORATE (Arora 等人, 2023) 则使用 LLM 为文档处理生成提取代码。

Data lineage. Data lineage traces which input tuples contribute to each output tuple, supporting view maintenance and source-level explanation (Cui et al., 2000). Titian (Interlandi et al., 2015) captures record-level lineage in distributed dataflow jobs. Smoke (Psallidas and Wu, 2018) co-designs lineage capture with physical operators to achieve low capture overhead and interactive lineage queries. In contrast, GProM (Arab et al., 2018) avoids materializing lineage by rewriting queries to compute provenance on demand, trading query-time cost for zero capture overhead.数据谱系。数据谱系追踪哪些输入元组对每个输出元组有贡献，从而支持视图维护和源级解释 (Cui 等人, 2000)。Titian (Interlandi 等人, 2015) 在分布式数据流作业中捕获记录级谱系。Smoke (Psallidas and Wu, 2018) 将谱系捕获与物理运算符共同设计，以实现较低的捕获开销和交互式谱系查询。相比之下，GProM (Arab 等人, 2018) 通过重写查询以按需计算来源，避免了谱系的物化，以查询时成本换取了零捕获开销。

6. Conclusion6. 结论

Agent trajectories are emerging as a distinct data type. They combine hierarchical execution structure, large volumes of text, and complex lineage relationships among trajectory records and derived state. Existing database systems are not designed to support these properties together. We therefore envision TrajectoryDB that co-designs ingestion, storage, and query processing to optimize the full trajectory data lifecycle.智能体轨迹正在成为一种独特的数据类型。它们结合了分层执行结构、海量文本以及轨迹记录与衍生状态之间复杂的谱系关系。现有的数据库系统并未被设计为同时支持这些属性。因此，我们设想了 TrajectoryDB，通过共同设计摄取、存储和查询处理，以优化整个轨迹数据生命周期。

References参考文献

Amazon Web Services ([n.d.]) Amazon Web Services. [n.d.]. Amazon DocumentDB (with MongoDB compatibility). https://aws.amazon.com/documentdb/. Accessed: 2026-08-31. Amazon Web Services ([n.d.])。Amazon DocumentDB (with MongoDB compatibility)。https://aws.amazon.com/documentdb/。访问日期：2026-08-31。
Andreessen Horowitz (2026) Andreessen Horowitz. 2026. Charts of the Week: Winds of Thematic Change. https://www.a16z.news/p/charts-of-the-week-winds-of-thematic. OpenRouter usage data; chart by Peter Walker. Andreessen Horowitz (2026)。Charts of the Week: Winds of Thematic Change。https://www.a16z.news/p/charts-of-the-week-winds-of-thematic。OpenRouter 使用数据；图表由 Peter Walker 制作。
Angus et al. (2026) Alex Angus, Will Van Eaton, and Dan Fu. 2026. Benchmarking Inference at Scale: Coding Agents. Together AI Blog. https://www.together.ai/blog/coding-agent-benchmarks Alex Angus, Will Van Eaton, and Dan Fu (2026)。Benchmarking Inference at Scale: Coding Agents。Together AI Blog。https://www.together.ai/blog/coding-agent-benchmarks
Anthropic (2025) Anthropic. 2025. Effective Context Engineering for AI Agents. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents Anthropic (2025)。Effective Context Engineering for AI Agents。https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
Apache Flink (2026) Apache Flink. 2026. Windows: Allowed Lateness. Apache Flink Documentation. https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream-v2/builtin-funcs/windows/ Apache Flink (2026)。Windows: Allowed Lateness。Apache Flink Documentation。https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream-v2/builtin-funcs/windows/
Apache Kafka (2026) Apache Kafka. 2026. Kafka Streams Core Concepts. Apache Kafka Documentation. https://kafka.apache.org/25/streams/core-concepts/ Apache Kafka (2026)。Kafka Streams Core Concepts。Apache Kafka Documentation。https://kafka.apache.org/25/streams/core-concepts/
Apache Parquet (2026) Apache Parquet. 2026. Parquet Encoding Definitions. Apache Parquet Documentation. https://parquet.apache.org/docs/file-format/data-pages/encodings/ Apache Parquet (2026)。Parquet Encoding Definitions。Apache Parquet Documentation。https://parquet.apache.org/docs/file-format/data-pages/encodings/
Apache Spark (2026) Apache Spark. 2026. Structured Streaming Programming Guide. Apache Spark Documentation. https://spark.apache.org/docs/3.5.8/structured-streaming-programming-guide.html Apache Spark (2026)。Structured Streaming Programming Guide。Apache Spark Documentation。https://spark.apache.org/docs/3.5.8/structured-streaming-programming-guide.html
Arab et al. (2018) Bahareh Sadat Arab, Su Feng, Boris Glavic, Seokki Lee, Xing Niu, and Qitian Zeng. 2018. GProM: A Swiss Army Knife for Your Provenance Needs. IEEE Data Engineering Bulletin 41, 1 (2018). Bahareh Sadat Arab, Su Feng, Boris Glavic, Seokki Lee, Xing Niu, and Qitian Zeng (2018)。GProM: A Swiss Army Knife for Your Provenance Needs。IEEE Data Engineering Bulletin 41, 1 (2018)。
Arora et al. (2023) Simran Arora, Brandon Yang, Sabri Eyuboglu, Avanika Narayan, Andrew Hojel, Immanuel Trummer, and Christopher Ré. 2023. Language Models Enable Simple Systems for Generating Structured Views of Heterogeneous Data Lakes. Proceedings of the VLDB Endowment 17, 2 (2023), 92–105. Simran Arora, Brandon Yang, Sabri Eyuboglu, Avanika Narayan, Andrew Hojel, Immanuel Trummer, and Christopher Ré (2023)。Language Models Enable Simple Systems for Generating Structured Views of Heterogeneous Data Lakes。Proceedings of the VLDB Endowment 17, 2 (2023), 92–105。
Baker et al. (2025) Bowen Baker, Joost Huizinga, Leo Gao, Zehao Dou, Melody Y. Guan, Aleksander Madry, Wojciech Zaremba, Jakub Pachocki, and David Farhi. 2025. Monitoring Reasoning Models for Misbehavior and the Risks of Promoting Obfuscation. arXiv:2503.11926 [cs.LG] https://arxiv.org/abs/2503.11926 Bowen Baker, Joost Huizinga, Leo Gao, Zehao Dou, Melody Y. Guan, Aleksander Madry, Wojciech Zaremba, Jakub Pachocki, and David Farhi (2025)。Monitoring Reasoning Models for Misbehavior and the Risks of Promoting Obfuscation。arXiv:2503.11926 [cs.LG]。https://arxiv.org/abs/2503.11926
Bang (2023) Fu Bang. 2023. GPTCache: An Open-Source Semantic Cache for LLM Applications Enabling Faster Answers and Cost Savings. In Proceedings of the 3rd Workshop for Natural Language Processing Open Source Software (NLP-OSS 2023). Association for Computational Linguistics, Singapore, 212–218. https://doi.org/10.18653/v1/2023.nlposs-1.24 Fu Bang (2023)。GPTCache: An Open-Source Semantic Cache for LLM Applications Enabling Faster Answers and Cost Savings。In Proceedings of the 3rd Workshop for Natural Language Processing Open Source Software (NLP-OSS 2023)。Association for Computational Linguistics, Singapore, 212–218。https://doi.org/10.18653/v1/2023.nlposs-1.24
Barke et al. (2026) Shraddha Barke, Arnav Goyal, Alind Khare, Avaljot Singh, Suman Nath, and Chetan Bansal. 2026. AgentRx: Diagnosing AI Agent Failures from Execution Trajectories. arXiv preprint arXiv:2602.02475 (2026). Shraddha Barke, Arnav Goyal, Alind Khare, Avaljot Singh, Suman Nath, and Chetan Bansal (2026)。AgentRx: Diagnosing AI Agent Failures from Execution Trajectories。arXiv preprint arXiv:2602.02475 (2026)。
Chhikara et al. (2025) Prateek Chhikara, Dev Khant, Saket Aryan, Taranjeet Singh, and Deshraj Yadav. 2025. Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory. arXiv preprint arXiv:2504.19413 (2025). Prateek Chhikara, Dev Khant, Saket Aryan, Taranjeet Singh, and Deshraj Yadav (2025)。Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory。arXiv preprint arXiv:2504.19413 (2025)。
ClickHouse (2026) ClickHouse. 2026. Database Compression: Encodings, Codecs and Ratios. ClickHouse Engineering. https://clickhouse.com/resources/engineering/database-compression ClickHouse (2026)。Database Compression: Encodings, Codecs and Ratios。ClickHouse Engineering。https://clickhouse.com/resources/engineering/database-compression
Crispin and McDiarmid (2025) Rory Crispin and Dale McDiarmid. 2025. Scaling Our Observability Platform Beyond 100 Petabytes by Embracing Wide Events and Replacing OTel. ClickHouse Blog. https://clickhouse.com/blog/scaling-observability-beyond-100pb-wide-events-replacing-otel Rory Crispin and Dale McDiarmid (2025)。Scaling Our Observability Platform Beyond 100 Petabytes by Embracing Wide Events and Replacing OTel。ClickHouse Blog。https://clickhouse.com/blog/scaling-observability-beyond-100pb-wide-events-replacing-otel
Cui et al. (2000) Yingwei Cui, Jennifer Widom, and Janet L. Wiener. 2000. Tracing the Lineage of View Data in a Warehousing Environment. ACM Transactions on Database Systems 25, 2 (2000), 179–227. Yingwei Cui, Jennifer Widom, and Janet L. Wiener (2000)。Tracing the Lineage of View Data in a Warehousing Environment。ACM Transactions on Database Systems 25, 2 (2000), 179–227。
Dai et al. (2024) Hanjun Dai, Bethany Yixin Wang, Xingchen Wan, Bo Dai, Sherry Yang, Azade Nova, Pengcheng Yin, Phitchaya Mangpo Phothilimthana, Charles Sutton, and Dale Schuurmans. 2024. UQE: A Query Engine for Unstructured Databases. In Advances in Neural Information Processing Systems. Hanjun Dai, Bethany Yixin Wang, Xingchen Wan, Bo Dai, Sherry Yang, Azade Nova, Pengcheng Yin, Phitchaya Mangpo Phothilimthana, Charles Sutton, and Dale Schuurmans (2024)。UQE: A Query Engine for Unstructured Databases。In Advances in Neural Information Processing Systems。
Datadog (2026) Datadog. 2026. Agent Observability. Datadog Documentation. https://docs.datadoghq.com/llm_observability/ Datadog (2026)。Agent Observability。Datadog Documentation。https://docs.datadoghq.com/llm_observability/
Deshpande et al. (2025) Darshan Deshpande, Varun Gangal, Hersh Mehta, et al. 2025. TRAIL: Trace Reasoning and Agentic Issue Localization. arXiv preprint arXiv:2505.08638 (2025). Darshan Deshpande, Varun Gangal, Hersh Mehta, et al. (2025)。TRAIL: Trace Reasoning and Agentic Issue Localization。arXiv preprint arXiv:2505.08638 (2025)。
Deutsch et al. (2021) Alin Deutsch, Nadime Francis, Alastair Green, Keith W. Hare, Bei Li, Leonid Libkin, Tobias Lindaaker, Victor Marsault, Wim Martens, Jan Michels, Filip Murlak, Stefan Plantikow, Petra Selmer, Hannes Voigt, Oskar van Rest, Domagoj Vrgoč, Mingxi Wu, and Fred Zemke. 2021. Graph Pattern Matching in GQL and SQL/PGQ. CoRR abs/2112.06217 (2021). arXiv:2112.06217 Alin Deutsch, Nadime Francis, Alastair Green, Keith W. Hare, Bei Li, Leonid Libkin, Tobias Lindaaker, Victor Marsault, Wim Martens, Jan Michels, Filip Murlak, Stefan Plantikow, Petra Selmer, Hannes Voigt, Oskar van Rest, Domagoj Vrgoč, Mingxi Wu, and Fred Zemke (2021)。Graph Pattern Matching in GQL and SQL/PGQ。CoRR abs/2112.06217 (2021)。arXiv:2112.06217
FINOS (2026) FINOS. 2026. FINOS AI Governance Framework (AIR). https://air-governance-framework.finos.org/. Open-source AI governance framework for financial services; v2.0 introduces a dedicated agentic-AI risk and mitigation catalogue. Accessed August 2026. FINOS (2026)。FINOS AI Governance Framework (AIR)。https://air-governance-framework.finos.org/。金融服务开源 AI 治理框架；v2.0 引入了专门的智能体 AI 风险与缓解目录。访问日期：2026 年 8 月。
FreeInference (2026) FreeInference. 2026. FreeInference. Harvard SEAS. https://freeinference.org/ FreeInference (2026)。FreeInference。Harvard SEAS。https://freeinference.org/
Fu et al. (2024) Yao Fu, Dong-Ki Kim, Jaekyeom Kim, Sungryull Sohn, Lajanugen Logeswaran, Kyunghoon Bae, and Honglak Lee. 2024. AutoGuide: Automated Generation and Selection of Context-Aware Guidelines for Large Language Model Agents. In Advances in Neural Information Processing Systems, Vol. 37. 119919–119948. Yao Fu, Dong-Ki Kim, Jaekyeom Kim, Sungryull Sohn, Lajanugen Logeswaran, Kyunghoon Bae, and Honglak Lee (2024)。AutoGuide: Automated Generation and Selection of Context-Aware Guidelines for Large Language Model Agents。In Advances in Neural Information Processing Systems, Vol. 37. 119919–119948。
Gill et al. (2025) Waris Gill, Mohamed Elidrisi, Pallavi Kalapatapu, Ammar Ahmed, Ali Anwar, and Muhammad Ali Gulzar. 2025. MeanCache: User-Centric Semantic Caching for LLM Web Services. In 2025 IEEE International Parallel and Distributed Processing Symposium (IPDPS). IEEE, 1298–1310. https://doi.org/10.1109/IPDPS64566.2025.00117 Waris Gill, Mohamed Elidrisi, Pallavi Kalapatapu, Ammar Ahmed, Ali Anwar, and Muhammad Ali Gulzar (2025)。MeanCache: User-Centric Semantic Caching for LLM Web Services。In 2025 IEEE International Parallel and Distributed Processing Symposium (IPDPS)。IEEE, 1298–1310。https://doi.org/10.1109/IPDPS64566.2025.00117
Hong et al. (2025) Sirui Hong, Yizhang Lin, Bang Liu, Bangbang Liu, Binhao Wu, Ceyao Zhang, Danyang Li, Jiaqi Chen, Jiayi Zhang, Jinlin Wang, Li Zhang, Lingyao Zhang, Min Yang, Mingchen Zhuge, Taicheng Guo, Tuo Zhou, Wei Tao, Robert Tang, Xiangtao Lu, Xiawu Zheng, Xinbing Liang, Yaying Fei, Yuheng Cheng, Yongxin Ni, Zhibin Gou, Zongze Xu, Yuyu Luo, and Chenglin Wu. 2025. Data Interpreter: An LLM Agent for Data Science. In Findings of the Association for Computational Linguistics: ACL 2025. 19796–19821. Sirui Hong, Yizhang Lin, Bang Liu, Bangbang Liu, Binhao Wu, Ceyao Zhang, Danyang Li, Jiaqi Chen, Jiayi Zhang, Jinlin Wang, Li Zhang, Lingyao Zhang, Min Yang, Mingchen Zhuge, Taicheng Guo, Tuo Zhou, Wei Tao, Robert Tang, Xiangtao Lu, Xiawu Zheng, Xinbing Liang, Yaying Fei, Yuheng Cheng, Yongxin Ni, Zhibin Gou, Zongze Xu, Yuyu Luo, and Chenglin Wu (2025)。Data Interpreter: An LLM Agent for Data Science。In Findings of the Association for Computational Linguistics: ACL 2025. 19796–19821。
Interlandi et al. (2015) Matteo Interlandi, Kshitij Shah, Sai Deep Tetali, Muhammad Ali Gulzar, Seunghyun Yoo, Miryung Kim, Todd D. Millstein, and Tyson Condie. 2015. Titian: Data Provenance Support in Spark. Proceedings of the VLDB Endowment 9, 3 (2015), 216–227. Matteo Interlandi, Kshitij Shah, Sai Deep Tetali, Muhammad Ali Gulzar, Seunghyun Yoo, Miryung Kim, Todd D. Millstein, and Tyson Condie (2015)。Titian: Data Provenance Support in Spark。Proceedings of the VLDB Endowment 9, 3 (2015), 216–227。
Jain et al. (2025) Naman Jain, Jaskirat Singh, Manish Shetty, et al. 2025. R2E-Gym: Procedural Environments and Hybrid Verifiers for Scaling Open-Weights SWE Agents. arXiv preprint arXiv:2504.07164 (2025). Naman Jain, Jaskirat Singh, Manish Shetty, et al. (2025)。R2E-Gym: Procedural Environments and Hybrid Verifiers for Scaling Open-Weights SWE Agents。arXiv preprint arXiv:2504.07164 (2025)。
LangChain (2026) LangChain. 2026. LangSmith Observability. LangSmith Documentation. https://docs.langchain.com/langsmith/observability LangChain (2026)。LangSmith Observability。LangSmith Documentation。https://docs.langchain.com/langsmith/observability
Langfuse (2026) Langfuse. 2026. Observability & Application Tracing. Langfuse Documentation. https://langfuse.com/docs/observability/overview Langfuse (2026)。Observability & Application Tracing。Langfuse Documentation。https://langfuse.com/docs/observability/overview
Lee et al. (2025) Geonho Lee, Jeongho Park, and Min-Soo Kim. 2025. Chimera: A System Design of Dual Storage and Traversal-Join Unified Query Processing for SQL/PGQ. Proceedings of the VLDB Endowment 18, 2 (2025), 279–292. https://doi.org/10.14778/3705829.3705845 Geonho Lee, Jeongho Park, and Min-Soo Kim (2025)。Chimera: A System Design of Dual Storage and Traversal-Join Unified Query Processing for SQL/PGQ。Proceedings of the VLDB Endowment 18, 2 (2025), 279–292。https://doi.org/10.14778/3705829.3705845
Letta (2026) Letta. 2026. Memory Architecture. https://docs.letta.com/. Letta documentation. Letta (2026)。Memory Architecture。https://docs.letta.com/。Letta 文档。
Li et al. (2026) Yujiang Li, Zhenyu Hou, Yi Jing, Jie Tang, and Yuxiao Dong. 2026. CompactionRL: Reinforcement Learning with Context Compaction for Long-Horizon Agents. arXiv preprint arXiv:2607.05378 (2026). Yujiang Li, Zhenyu Hou, Yi Jing, Jie Tang, and Yuxiao Dong (2026)。CompactionRL: Reinforcement Learning with Context Compaction for Long-Horizon Agents。arXiv preprint arXiv:2607.05378 (2026)。
Lin et al. (2024) Chaofan Lin, Zhenhua Han, Chengruidong Zhang, Yuqing Yang, Fan Yang, Chen Chen, and Lili Qiu. 2024. Parrot: Efficient Serving of LLM-based Applications with Semantic Variable. In 18th USENIX Symposium on Operating Systems Design and Implementation (OSDI 24). USENIX Association, Santa Clara, CA, 929–945. https://www.usenix.org/conference/osdi24/presentation/lin-chaofan Chaofan Lin, Zhenhua Han, Chengruidong Zhang, Yuqing Yang, Fan Yang, Chen Chen, and Lili Qiu (2024)。Parrot: Efficient Serving of LLM-based Applications with Semantic Variable。In 18th USENIX Symposium on Operating Systems Design and Implementation (OSDI 24)。USENIX Association, Santa Clara, CA, 929–945。https://www.usenix.org/conference/osdi24/presentation/lin-chaofan
Liu et al. (2025) Chunwei Liu, Matthew Russo, Michael Cafarella, Lei Cao, Peter Baile Chen, Zui Chen, Michael Franklin, Tim Kraska, Samuel Madden, Rana Shahout, and Gerardo Vitagliano. 2025. Palimpzest: Optimizing AI-Powered Analytics with Declarative Query Processing. In CIDR. Chunwei Liu, Matthew Russo, Michael Cafarella, Lei Cao, Peter Baile Chen, Zui Chen, Michael Franklin, Tim Kraska, Samuel Madden, Rana Shahout, and Gerardo Vitagliano (2025)。Palimpzest: Optimizing AI-Powered Analytics with Declarative Query Processing。In CIDR。
Luo et al. (2026) Michael Luo, Xiaoxiang Shi, Colin Cai, Tianjun Zhang, Justin Wong, Yichuan Wang, Chi Wang, Yanping Huang, Zhifeng Chen, Joseph E. Gonzalez, and Ion Stoica. 2026. Agentix: An Efficient Serving Engine for LLM Agents as General Programs. In 23rd USENIX Symposium on Networked Systems Design and Implementation (NSDI 26). USENIX Association, Renton, WA, 2443–2459. https://www.usenix.org/conference/nsdi26/presentation/luo Michael Luo, Xiaoxiang Shi, Colin Cai, Tianjun Zhang, Justin Wong, Yichuan Wang, Chi Wang, Yanping Huang, Zhifeng Chen, Joseph E. Gonzalez, and Ion Stoica (2026)。Agentix: An Efficient Serving Engine for LLM Agents as General Programs。In 23rd USENIX Symposium on Networked Systems Design and Implementation (NSDI 26)。USENIX Association, Renton, WA, 2443–2459。https://www.usenix.org/conference/nsdi26/presentation/luo
Mang et al. (2026) Qiuyang Mang, Yufan Xiang, Hangrui Zhou, Runyuan He, Jiaxiang Yu, Hanchen Li, Aditya Parameswaran, and Alvin Cheung. 2026. PLOP: Cost-Based Placement of Semantic Operators in Hybrid Query Plans. arXiv preprint arXiv:2604.09944 (2026). Qiuyang Mang, Yufan Xiang, Hangrui Zhou, Runyuan He, Jiaxiang Yu, Hanchen Li, Aditya Parameswaran, and Alvin Cheung (2026)。PLOP: Cost-Based Placement of Semantic Operators in Hybrid Query Plans。arXiv preprint arXiv:2604.09944 (2026)。
MongoDB, Inc. ([n.d.]) MongoDB, Inc. [n.d.]. MongoDB. https://www.mongodb.com/. Accessed: 2026-08-31. MongoDB, Inc. ([n.d.])。MongoDB。https://www.mongodb.com/。访问日期：2026-08-31。
NVIDIA (2025) NVIDIA. 2025. Inference Performance for Data Center Deep Learning. NVIDIA Developer. https://developer.nvidia.com/deep-learning-performance-training-inference/ai-inference NVIDIA (2025)。Inference Performance for Data Center Deep Learning。NVIDIA Developer。https://developer.nvidia.com/deep-learning-performance-training-inference/ai-inference
OpenAI (2026a) OpenAI. 2026a. Safety and Alignment in an Era of Long-Horizon Models. OpenAI. OpenAI (2026a)。Safety and Alignment in an Era of Long-Horizon Models。OpenAI。
OpenAI (2026b) OpenAI. 2026b. Understanding and Counting Tokens. OpenAI Help Center. https://help.openai.com/en/articles/4936856-understanding-and-counting-tokens OpenAI (2026b)。Understanding and Counting Tokens。OpenAI Help Center。https://help.openai.com/en/articles/4936856-understanding-and-counting-tokens
OpenTelemetry (2025) OpenTelemetry. 2025. Transforming Telemetry. OpenTelemetry Documentation. https://opentelemetry.io/docs/collector/transforming-telemetry/ OpenTelemetry (2025)。Transforming Telemetry。OpenTelemetry Documentation。https://opentelemetry.io/docs/collector/transforming-telemetry/
OpenTelemetry (2026) OpenTelemetry. 2026. Logs Data Model. https://opentelemetry.io/docs/specs/otel/logs/data-model/. OpenTelemetry (2026)。Logs Data Model。https://opentelemetry.io/docs/specs/otel/logs/data-model/。
Oracle (2025) Oracle. 2025. Oracle Database Concepts: Data Block Compression. Oracle Database Documentation. https://docs.oracle.com/en/database/oracle/oracle-database/23/cncpt/database-concepts.pdf Oracle (2025)。Oracle Database Concepts: Data Block Compression。Oracle Database Documentation。https://docs.oracle.com/en/database/oracle/oracle-database/23/cncpt/database-concepts.pdf
Oracle (2026) Oracle. 2026. InnoDB Page Compression. MySQL Reference Manual. https://dev.mysql.com/doc/refman/8.4/en/innodb-page-compression.html Oracle (2026)。InnoDB Page Compression。MySQL Reference Manual。https://dev.mysql.com/doc/refman/8.4/en/innodb-page-compression.html
Ouyang et al. (2026) Siru Ouyang, Jun Yan, I-Hung Hsu, Yanfei Chen, Ke Jiang, Zifeng Wang, Rujun Han, Long T. Le, Samira Daruki, Xiangru Tang, Vishy Tirumalashetty, George Lee, Mahsan Rofouei, Hangfei Lin, Jiawei Han, Chen-Yu Lee, and Tomas Pfister. 2026. ReasoningBank: Scaling Agent Self-Evolving with Reasoning Memory. In International Conference on Learning Representations. arXiv:2509.25140 Siru Ouyang, Jun Yan, I-Hung Hsu, Yanfei Chen, Ke Jiang, Zifeng Wang, Rujun Han, Long T. Le, Samira Daruki, Xiangru Tang, Vishy Tirumalashetty, George Lee, Mahsan Rofouei, Hangfei Lin, Jiawei Han, Chen-Yu Lee, and Tomas Pfister (2026)。ReasoningBank: Scaling Agent Self-Evolving with Reasoning Memory。In International Conference on Learning Representations。arXiv:2509.25140
Pan et al. (2025) Jiayi Pan, Xingyao Wang, Graham Neubig, Navdeep Jaitly, Heng Ji, Alane Suhr, and Yizhe Zhang. 2025. Training Software Engineering Agents and Verifiers with SWE-Gym. In International Conference on Machine Learning (ICML). arXiv:2412.21139. Jiayi Pan, Xingyao Wang, Graham Neubig, Navdeep Jaitly, Heng Ji, Alane Suhr, and Yizhe Zhang (2025)。Training Software Engineering Agents and Verifiers with SWE-Gym。In International Conference on Machine Learning (ICML)。arXiv:2412.21139。
Patel et al. (2025) Liana Patel, Siddharth Jha, Melissa Z. Pan, Harshit Gupta, Parth Asawa, Carlos Guestrin, and Matei Zaharia. 2025. Semantic Operators and Their Optimization: Enabling LLM-Based Data Processing with Accuracy Guarantees in LOTUS. Proceedings of the VLDB Endowment 18, 11 (2025), 4171–4184. Liana Patel, Siddharth Jha, Melissa Z. Pan, Harshit Gupta, Parth Asawa, Carlos Guestrin, and Matei Zaharia (2025)。Semantic Operators and Their Optimization: Enabling LLM-Based Data Processing with Accuracy Guarantees in LOTUS。Proceedings of the VLDB Endowment 18, 11 (2025), 4171–4184。
PostgreSQL Global Development Group (2026a) PostgreSQL Global Development Group. 2026a. Indexes and ORDER BY. PostgreSQL Documentation. https://www.postgresql.org/docs/14/indexes-ordering.html PostgreSQL Global Development Group (2026a)。Indexes and ORDER BY。PostgreSQL Documentation。https://www.postgresql.org/docs/14/indexes-ordering.html
PostgreSQL Global Development Group (2026b) PostgreSQL Global Development Group. 2026b. Query Planning. PostgreSQL Documentation. https://www.postgresql.org/docs/17/runtime-config-query.html PostgreSQL Global Development Group (2026b)。Query Planning。PostgreSQL Documentation。https://www.postgresql.org/docs/17/runtime-config-query.html
PostgreSQL Global Development Group (2026c) PostgreSQL Global Development Group. 2026c. TOAST: The Oversized-Attribute Storage Technique. PostgreSQL Documentation. https://www.postgresql.org/docs/current/storage-toast.html PostgreSQL Global Development Group (2026c)。TOAST: The Oversized-Attribute Storage Technique。PostgreSQL Documentation。https://www.postgresql.org/docs/current/storage-toast.html
PostgreSQL Global Development Group (2026d) PostgreSQL Global Development Group. 2026d. Window Functions. PostgreSQL Documentation. https://www.postgresql.org/docs/current/functions-window.html PostgreSQL Global Development Group (2026d)。Window Functions。PostgreSQL Documentation。https://www.postgresql.org/docs/current/functions-window.html
PostgreSQL Global Development Group (2026e) PostgreSQL Global Development Group. 2026e. WITH Queries (Common Table Expressions). PostgreSQL 18 Documentation. https://www.postgresql.org/docs/18/queries-with.html PostgreSQL Global Development Group (2026e)。WITH Queries (Common Table Expressions)。PostgreSQL 18 Documentation。https://www.postgresql.org/docs/18/queries-with.html
Psallidas and Wu (2018) Fotis Psallidas and Eugene Wu. 2018. Smoke: Fine-grained Lineage at Interactive Speed. Proceedings of the VLDB Endowment 11, 6 (2018), 719–732. Fotis Psallidas and Eugene Wu (2018)。Smoke: Fine-grained Lineage at Interactive Speed。Proceedings of the VLDB Endowment 11, 6 (2018), 719–732。
Russo et al. (2026) Matthew Russo, Chunwei Liu, Sivaprasad Sudhir, Gerardo Vitagliano, Michael Cafarella, Tim Kraska, and Samuel Madden. 2026. Abacus: A Cost-Based Optimizer for Semantic Operator Systems. Proceedings of the VLDB Endowment 19, 5 (2026), 1060–1073. https://doi.org/10.14778/3796195.3796215 Matthew Russo, Chunwei Liu, Sivaprasad Sudhir, Gerardo Vitagliano, Michael Cafarella, Tim Kraska, and Samuel Madden (2026)。Abacus: A Cost-Based Optimizer for Semantic Operator Systems。Proceedings of the VLDB Endowment 19, 5 (2026), 1060–1073。https://doi.org/10.14778/3796195.3796215
Shankar et al. (2025) Shreya Shankar, Tristan Chambers, Tarak Shah, Aditya G. Parameswaran, and Eugene Wu. 2025. DocETL: Agentic Query Rewriting and Evaluation for Complex Document Processing. Proceedings of the VLDB Endowment 18, 9 (2025), 3035–3048. Shreya Shankar, Tristan Chambers, Tarak Shah, Aditya G. Parameswaran, and Eugene Wu (2025)。DocETL: Agentic Query Rewriting and Evaluation for Complex Document Processing。Proceedings of the VLDB Endowment 18, 9 (2025), 3035–3048。
Wang et al. (2026) Yifei Wang, Hancheng Ye, Yechen Xu, Cong Guo, Chiyue Wei, Qinsi Wang, Dongting Li, Tingjun Chen, Hai Helen Li, Danyang Zhuo, and Yiran Chen. 2026. MARS: Efficient, Adaptive Co-Scheduling for Heterogeneous Agentic Systems. arXiv preprint arXiv:2604.26963 (2026). https://arxiv.org/abs/2604.26963 Yifei Wang, Hancheng Ye, Yechen Xu, Cong Guo, Chiyue Wei, Qinsi Wang, Dongting Li, Tingjun Chen, Hai Helen Li, Danyang Zhuo, and Yiran Chen (2026)。MARS: Efficient, Adaptive Co-Scheduling for Heterogeneous Agentic Systems。arXiv preprint arXiv:2604.26963 (2026)。https://arxiv.org/abs/2604.26963
Wiz (2026) Wiz. 2026. AI Guardrails: Safety Controls for Responsible AI Use. https://www.wiz.io/academy/ai-security/ai-guardrails. Wiz Academy. Accessed August 2026. Wiz (2026)。AI Guardrails: Safety Controls for Responsible AI Use。https://www.wiz.io/academy/ai-security/ai-guardrails。Wiz Academy。访问日期：2026 年 8 月。
Yang et al. (2024) John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. 2024. SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. In Advances in Neural Information Processing Systems, Vol. 37. 50528–50652. John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press (2024)。SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering。In Advances in Neural Information Processing Systems, Vol. 37. 50528–50652。
Yang et al. (2025) John Yang, Kilian Lieret, Carlos E. Jimenez, et al. 2025. SWE-smith: Scaling Data for Software Engineering Agents. arXiv preprint arXiv:2504.21798 (2025). John Yang, Kilian Lieret, Carlos E. Jimenez, et al. (2025)。SWE-smith: Scaling Data for Software Engineering Agents。arXiv preprint arXiv:2504.21798 (2025)。
Yao et al. (2025) Shunyu Yao, Noah Shinn, Pedram Razavi, and Karthik R. Narasimhan. 2025. $\tau$ -bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. In The Thirteenth International Conference on Learning Representations. Shunyu Yao, Noah Shinn, Pedram Razavi, and Karthik R. Narasimhan (2025)。τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains。In The Thirteenth International Conference on Learning Representations。
Yao et al. (2023) Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik R. Narasimhan, and Yuan Cao. 2023. ReAct: Synergizing Reasoning and Acting in Language Models. In The Eleventh International Conference on Learning Representations. Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik R. Narasimhan, and Yuan Cao (2023)。ReAct: Synergizing Reasoning and Acting in Language Models。In The Eleventh International Conference on Learning Representations。
Yuan et al. (2023) Zheng Yuan, Hongyi Yuan, Chengpeng Li, Guanting Dong, Keming Lu, Chuanqi Tan, Chang Zhou, and Jingren Zhou. 2023. Scaling Relationship on Learning Mathematical Reasoning with Large Language Models. arXiv preprint arXiv:2308.01825 (2023). Zheng Yuan, Hongyi Yuan, Chengpeng Li, Guanting Dong, Keming Lu, Chuanqi Tan, Chang Zhou, and Jingren Zhou (2023)。Scaling Relationship on Learning Mathematical Reasoning with Large Language Models。arXiv preprint arXiv:2308.01825 (2023)。
Zhang et al. (2026) Qizheng Zhang, Changran Hu, Shubhangi Upasani, Boyuan Ma, Fenglu Hong, Vamsidhar Kamanuru, Jay Rainton, Chen Wu, Mengmeng Ji, Hanchen Li, Urmish Thakker, James Zou, and Kunle Olukotun. 2026. Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models. In International Conference on Learning Representations. arXiv:2510.04618 Qizheng Zhang, Changran Hu, Shubhangi Upasani, Boyuan Ma, Fenglu Hong, Vamsidhar Kamanuru, Jay Rainton, Chen Wu, Mengmeng Ji, Hanchen Li, Urmish Thakker, James Zou, and Kunle Olukotun (2026)。Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models。In International Conference on Learning Representations。arXiv:2510.04618
Zhao et al. (2024) Andrew Zhao, Daniel Huang, Quentin Xu, Matthieu Lin, Yong-Jin Liu, and Gao Huang. 2024. ExpeL: LLM Agents Are Experiential Learners. In Proceedings of the AAAI Conference on Artificial Intelligence, Vol. 38. 19632–19642. https://doi.org/10.1609/aaai.v38i17.29936 Andrew Zhao, Daniel Huang, Quentin Xu, Matthieu Lin, Yong-Jin Liu, and Gao Huang (2024)。ExpeL: LLM Agents Are Experiential Learners。In Proceedings of the AAAI Conference on Artificial Intelligence, Vol. 38. 19632–19642。https://doi.org/10.1609/aaai.v38i17.29936