Agent轨迹分析与归因的数据工程实践方法详解

AI Agent 的落地，正在从“能不能做”进入“做得好不好”的阶段。而“做得好不好”，其实是一个很模糊的判断。一个 Agent 跑了三个小时，花了 12 美元，最后失败了，没人知道是哪一步开始跑偏；反过来，就算成功了，也不知道是哪一步做对了。下一次换个模型、改个 Prompt、加个 Tool，效果到底是变好还是变坏，很难量化评估。这已经不是 Prompt Engineering 能解决的问题，而是迈入了 Harness Engineering 的范畴。

这篇文章整理自张雁飞在 Databend 社区活动中的分享，围绕“Trace 即 Evals”这一核心理念，梳理了 AI Agent 从 Prompt Engineering、Context Engineering 到 Harness Engineering 的演进路径，并通过 Claude Code、Evot、Pi 等 Agent 的对比案例，解释了为什么 Agent Trace 不同于传统 Trace。同时，也展示了 Databend 如何用对象存储、VARIANT、加速列、全文检索和 Stream/Task，搭建了一套极简的 Trace 存储与分析底座。全文阅读时间约 12 分钟。

一份新的角色：数据基础设施不只是“存得下、查得出”

伴随着大模型和 AI Agent 的跨越式发展，技术范式的改变是显而易见的。很多人在这波变化中感到焦虑，也在拼命寻找突破口。与此同时，底层数据基础设施的角色也在悄然转变。过去，大家对数据系统的核心要求无非两点：存得下，查得出。但现在，我们希望它能真正支撑智能系统的运转，参与到智能决策和持续优化的闭环中去。

Databend 本质上是一个云原生数仓。大模型爆发之后，业界对数仓提出了全新需求。Databend 近期和国内几家头部大模型厂商合作了一些项目，在这个过程中，围绕 Agent 轨迹分析与归因做了不少实践和总结。

三个必须解决的核心问题

今天的分享，想解答一个朴素但核心的问题：怎样才能把 AI 用得比别人更好？具体可以分为三点。

第一是降低 Token 浪费。Agent 在哪个环节在烧钱、绕路、重复调用，这些必须能看清楚。AI 有幻觉，幻觉会让它在任务执行中“迷路”。对人来说，一个任务可能很简单，几步就能走通；但对 AI 而言，它没有人类那样的意识，看到的上下文本质上是在一个 Token 接一个 Token 地预测。路径一旦偏了，代价就会飞速增长。

第二是让 Agent 更稳定。同一个 Agent 产品，失败、幻觉和质量波动到底是从哪一步开始的？找到根因，才有办法做得比别人更好。

第三，也是大家最困惑的一点：如果要做一个 Agent 产品，改了一个 Prompt、加了一个 Tool，或者换了一个模型，怎么量化这次修改的效果？结果变好了还是变坏了？如果只能凭感觉拍脑袋，迭代就没法稳定进行。

Databend 在和头部模型厂商协作中，总结出一个核心方法：记录 Agent 每一步的执行轨迹，用数据而不是感觉来驱动优化。这，也是模型厂商正在重点关注的趋势。

从 Prompt 到 Harness：Agent 工程的三个演化阶段

在聊具体实践之前，有必要先理清 Agent 工程演进的三个阶段。

第一阶段是 Prompt Engineering。ChatGPT 刚火的时候，大家做的事情本质上是调指令、加示例、写思维链，优化的是单次模型调用的输入文本。典型场景就是一次检索、翻译、摘要。

第二阶段是 Context Engineering。进入 2025 年，大家发现大模型基于通用知识，不可能理解公司内部的文档和知识，于是 RAG 技术开始流行。模型可以检索公司知识库，客服助手、知识库问答类 Agent 应运而生。这个阶段的核心是管理模型每一步能看到什么——包括 RAG 检索、记忆压缩、窗口调度，优化的是多轮交互的信息流。

第三阶段是 Harness Engineering。到了 2026 年，随着 OpenClaw 这类项目爆火，人们发现只要给 Agent 一个工具，它就能主动操作本地电脑、自主执行任务。Claude Code、Codex、Coze 这类 Coding Agent 开始大行其道，Agent 形态从单轮问答发展到自主任务执行和多 Agent 协作。

所谓的 Harness，就是脚手架工程：我们如何约束 Agent 和模型，让它们做得更好。从我们的观察来看，Harness 包含两部分。对于做产品的人来说，Harness 是产品框架，目标是让 Agent 跑得更顺畅；对于训练模型的人来说，Harness 是考场，目标则是让模型在里面练得更好。

从应用侧看 Harness：可控、可观测、可归因

从应用侧看，Harness 的目标是把模型变成一个可控的产品。早期大家直接对接 API，做单轮交互——比如让模型发一封邮件，发送完返回结果。现在，Agent 已经进化到可以执行复杂的多轮任务，任务可能持续几个小时，还涉及权限和成本控制。要把 Agent 给公司内部使用，就必须能观测到每一步的执行过程，并且能评估每一次改动的效果。因此，Harness 在设计上就需要做到可控、可观测、可归因，同时支持持续的改进。而“改进是否真的生效”，就是 Eval 要回答的问题。

从模型侧看 Harness：把工具和流程“练”进模型

从模型侧看，Harness 的目标是把工具和流程“练”进模型内部。以前，外部 Harness 会告诉模型该怎么做：工具用法靠 Prompt 描述，上下文压缩靠外部逻辑，执行策略靠脚手架约束。而现在，模型开始在真实的 Harness 上 Rollout，用 Trace 和 Reward 学习工具调用，逐步把上下文管理和执行策略内化到模型权重中。从大模型厂商的合作实践中看，仅仅是改动 Harness，就能带来 10 倍级别的性能提升。

举个例子，Cursor 是早期做 Coding Agent 的产品。近期发布的 Composer 2.5 基于 Kimi 训练，以接近 Opus 十分之一的价格实现了接近的效果。为什么能做到？因为 Cursor 让模型学会了如何使用 Cursor 本身。Cursor 保留了海量用户使用数据，模型可以学到用户每一步调用了什么工具、执行了什么操作，这些行为模式被“练”进了模型里，相当于给模型注入了很强的泛化能力。所以，如果在 Cursor 里调用 Composer，效果会很好；但如果用 Claude Code 或开源的 OpenCode 去调用同一个模型，效果就可能差很多。原因很简单：Composer 学的是 Cursor 的行为，它已经专门针对 Cursor 的 Harness 训练好了。

这样一来，Harness 能力正在逐步下沉到模型里。模型厂商也明白，这才是它们的真正壁垒。不是 Harness 消失了，而是模型开始在 Harness 里学习，逐步内化工具使用、上下文管理和长期任务执行。而 Rollout 质量如何判断，同样要看 Trace。

工具名称大小写的“蝴蝶效应”

只要按照模型偏好的工具行为设计，上层 Agent 产品甚至不需要过于复杂的 Harness，Prompt 也能写得非常简洁。比如 Claude Code 里大约有 20 多个工具。想让模型表现得像在 Claude Code 中一样，工具名称必须准确，大小写也要保持一致，工具描述也需要尽量一致。这样在调用 Opus 时，效果才会尽可能接近 Claude Code 自身的水准。

工具名称的大小写，真的会影响效果。原因在于，Opus 训练时是基于 Claude Code 的。如果某个 Tool 的名称在训练中就是固定的大小写，你给它一个全小写版本，模型在预测下一个 Token 时就可能出现偏差。这个偏差看起来微小，但在多步 Agent 的执行过程中，会被不断放大。

为什么要展开 Trace？一个案例就能说清楚

从做 Agent 产品的角度看，所有人最终都会遇到同一个问题：改动到底是变好了还是变差了？这个问题的难点在于，Agent 是一个不确定性系统。大模型有幻觉，同样的任务、同样的软件，不同时间执行，结果可能截然不同。

要说得清楚，核心就是可观测性。必须把 Agent 和大模型交互的每一步轨迹都记录下来，用明确的数据支撑每一步的判断：Agent 从哪一步开始变坏，或者为什么变好；还要能按步骤对比两次执行的差异，把“哪一步”定位到成本和质量上。

无论从 Agent 产品视角，还是从模型训练视角来看，Trace 都是必须的。Trace 既是 Agent 产品的评测证据，也是模型训练的燃料。只有铺开完整的轨迹，才能把“变好还是变差”这件事讲明白。

来看一个具体的对比案例。三个 Agent 分别是 Claude Code、Evot 和 Pi，调用的都是 DeepSeek V4 Pro。Claude Code 跑了 15 分钟，Evot 跑了 5 分钟，开源的 Pi 跑了 4 分钟。这里的 Claude Code 调用 DeepSeek V4 Pro 只是一个对照参考。很多人可能会想，Claude Code 本身做得很强，为什么执行时间这么长？是 DeepSeek V4 Pro 太弱吗？并不是。如果 Claude Code 调用自己的模型 Opus 4.6，同样的任务 3 分钟就能完成。

这说明，Claude Code 的 Harness 能力和它自己的模型是高度绑定的。换成其他模型，Prompt、Tool 或其他系统设置就可能让模型在执行中“迷路”。

再看 Evot 和 Pi，它们在调用 DeepSeek V4 Pro 和 Opus 4.6 时，执行时间差距不大。这两个 Agent 更偏通用，没有专门针对某款模型做深度适配。而 Claude Code 对 Opus 模型有效，对第三方模型不一定有效。

所以，当用 Claude Code 调用第三方模型时，效果差并不一定是模型差，很可能是 Agent 和模型之间没有配合好。从模型厂商的视角看，它们会致力于把 Agent 和模型训练成一套高度匹配的系统。这也意味着，第三方 Agent 和应用想充分发挥模型的能力，难度会越来越大。只看最终结果，不看内部的执行轨迹，很容易得出“模型太差”的结论。但实际上，只有展开 Trace，才能知道 Token 烧在哪里、时间慢在哪里、哪一步开始绕路。

路径依赖与分叉点：Agent 的“蝴蝶效应”

Agent 之间的差异，本质上来自路径依赖。一次工具调用的选择、一次上下文裁剪、一次错误恢复，都会改变后续所有步骤。展开 Trace 之后会发现，差异从 Tool Call 序列就开始了。在三个 Agent 的路径图中，每个色块代表一次工具调用；有的步骤里上下两个色块，说明大模型返回了两个并行调用。

Agent 会对模型进行引导，告诉模型下一步要做什么。模型如果经过强化训练，就知道如何配合，执行起来会非常顺畅。在这个过程中，系统会采集大量 Trace，比如用户如何使用、每一步如何拆解，然后让模型学习这些行为。

再看一个分叉点的例子。上面一条路径配合得很好：第 4 步选择 Edit，精准修改目标文件，然后一步一步完成任务。下面一条路径在第 4 步选择了 Bash，输出过多，导致后面绕了 17 步，耗费了更多时间和资源，虽然最后也完成了任务，但过程明显更低效。

大模型本身没有状态，它不会天然维护完整的任务状态。所以，只要某一步走错了，把错误结果作为下一轮的输入交给它，后续路径就会不断分叉。知道分叉发生在第 4 步之后，停下来分析：为什么会在那一步分叉？是不是 Prompt 的引导出了问题？分叉点隐藏在完整的执行轨迹中，每一步的 Tool、Context、Token 和耗时都必须被存储、查询和对比。

LLM 请求里的 JSON 到底装了什么

很多人看到的只是一个 IDE：给 Agent 一句话、一个任务，它就开始来回执行。但底层和大模型的交互，其实并不直观。在量化分析时，这个过程必须始终被观测。

一次发给 LLM 的请求，通常包含系统指令、Agent 具备的工具和描述、Agent 与大模型之间来回交互的历史，以及每次交互产生的结果。以前面的 Demo 为例，Claude Code 调用 DeepSeek 模型的每一步都能被观测到。Claude Code 运行时，会先连续发送三个 System 指令，返回当前任务名称。这一步并不是在真正干活，而是拿到任务标题。第二步，会把大约 26 个工具，加上发出的 Fix Bug 任务，一起交给大模型，大模型返回的是更新后的进度计划。第三步，仍然没有真正干活，而是在继续更新计划，类似于先规划要做什么。直到第四步，大模型才开始正式干活，比如返回要先查看哪个文件。

通过这个过程可以看到 Claude Code Harness 的行为：它会先规划任务、明确要做什么，然后引导后续步骤，避免模型跑偏。但这种行为在 DeepSeek V4 Pro 这类模型上，并不一定能生效。模型不熟悉这个 Harness，可能就不知道该如何配合。

如果 Claude Code 调用自己的 Opus 模型，模型已经经过强化训练，会更遵循这个 Harness，知道怎么做，也更“听话”。双方训练过，配合自然顺畅。这也是为什么同样一套 Harness，调用 DeepSeek V4 Pro 效果差，调用 Opus 效果好的原因。

不记录这些 Trace，不观测每一步，就很难发现执行过程到底为何跑偏。这个 Demo 里大约跑了 69 步，每一步都可以被观测。可视化之后，人可以看清路径差异；如果让 AI 去跟踪每一步，分析速度就会更快。Pi 这个 Agent 用了 32 步完成任务，把 Pi 的 Trace 和 Claude Code 的 Trace 一起交给大模型，大模型很快就能分析出差距和原因。前提是，已经按各个维度把详细的 Trace 数据存下来了——包括系统指令、工具描述、调用结果等。

Pi 使用的工具较少，底层的 Agent 框架 OpenCode 里，Pi 主要用读、Bash、编辑和写这四类工具。Pi 有自己的 Harness，系统指令非常简洁，面向通用模型，不特别针对 Opus 或 GPT。因此，Pi 调用 Opus 或 GPT 时，差距不会特别大。相比之下，Claude Code 的系统组件非常庞大，每个组件都针对自身模型做了大量定制。比如 System Reminder 就是专门给 Opus 这类模型的指令，模型经过训练，知道如何遵循这些指令。由此可见，Harness 是不同 Agent 产品针对不同模型需要长期打磨的部分。

Agent Trace 为什么不同于传统 Trace

一次发给 LLM 的请求，本质上是一个巨大的 JSON。在之前的 Demo 中，Claude Code 的 JSON 非常大，而 Pi 给大模型的 JSON 很简短：System 指令告诉模型“你是一个编程专家”，加上四个工具和当前任务，整体非常直接。

但到了第二步，JSON 就变得很长了。因为系统必须把第一步的完整 JSON 也带上，再加上第一步的执行结果。第三步，又要把第二步的结果继续塞进新的 JSON，拼成一个完整状态。因此，每一次给大模型的输入，都是前面的内容加上新内容，窗口会越来越大。到最后，就需要做上下文压缩。压缩之后再交给大模型继续执行。这就是 Agent 执行的基本机制。所以，需要保存整个 Session 过程中的 JSON，因为它们反映了每一步执行的不同结果。

传统 Trace 记录的是服务调用链，一次请求通常是秒级到分钟级，字段来自 SDK 或 Instrumentation，Schema 相对稳定，分析重点就是 Latency、Status 和 Error，非常固定而明确。但 Agent Trace 完全不同。一个任务可能持续几十分钟到几小时，Span 会持续追加，状态会跨步骤演化。内容来自 Prompt、Messages、Tool Call 和 Tool Result。大模型返回的结果经常不是合法 JSON，字段类型会漂移。分析重点也不再只是延迟和错误，而是 Token、Cost、Tool Choice 以及关键分叉点。

Agent Trace 和传统 Trace 不是一一对应的关系。并不是传统 Trace 做得好的厂商，就一定能做好 Agent Trace。Agent Trace 的真正挑战在于长跨度、大 JSON 和脏数据。真正麻烦的不是“存一条链路”，而是要处理长生命周期任务里的增量事件，把脏的、嵌套的、不断变化的大 JSON 清理、拆解、索引、聚合，并用于归因。

一条真实 Agent Trace 的规模

一条真实轨迹的规模可能非常惊人：单条 Trace 可以从 500KB 到 500MB，嵌套 3 到 8 层。比如一个 Agent Swarm 是集群式的：先分工，分工之后并行执行，执行完之后再由统一的 Agent 调度和汇总。这样一次任务可能产生约 500MB 数据，执行十几个小时，包含 10 万多个 Span。这种量级的 Trace，靠人来处理根本顾不过来。像 500MB 这样复杂的 Trace，对存储架构提出了很高要求。当脏 JSON 进来时，系统需要回答：怎么清理？怎么拆解？怎么建索引？最重要的一步，是先把它存下来。但 Trace 不是存下来就有价值的，只有清理、拆解、索引、聚合之后，才能支撑归因、回放和评测。

Agent Trace 数据层需要哪些数据库能力

要做好 Agent Trace，数据库需要具备几类核心能力。

第一，数据库要天然支持 JSON 原生存取。第二，要有 JSON 清洗与变换能力，因为真实 Trace 里会有脏 JSON，必须有强大的函数处理能力。第三，JSON 索引要足够快。对于几百兆的 JSON，即使能存下来，查询时也不能每次都完整读出来，效率太低。系统需要通过常用索引实现快速检索，比如 trace_id、model 等字段可以被抽取出来，建立索引，形成单独的 JSON 加速列。第四，要支持 JSON 内的全文索引。全文索引非常重要——比如用户吐槽某个任务执行得差，系统需要根据关键词找到对应对话，把 Trace 拉出来分析，判断是否有改进空间。第五，要满足合规要求，支持 JSON Path RBAC。Trace 中可能包含用户密码等敏感信息，需要按路径进行授权或脱敏。第六，Agent Trace 数据巨大，每天可能产生几百 TB 数据，需要长期存储，因此数据库必须支持低成本对象存储。第七，海量用户和 Agent Swarm 会并发产生 Trace，数据库还需要支持高吞吐写入。

Databend 的极简 Trace 存储与分析路线

大量用户持续使用 Agent，每个人都在不断生产数据，不断写入大 JSON，这对系统是很大的挑战。Databend 选择了一条极简的 Trace 存储与分析路线。传统路线可能需要源数据、事务型数据库和数仓分别独立建设。而 Databend 的路径是：Trace 生产数据持续写入对象存储 S3，Databend 内部的 Task 从 S3 上完成入库和清洗，清洗后写入 events 表。

整个 JSON 可以写在一张表的一个字段里。这张表可以做全文索引、JSON 加速、脏 JSON 清洗，都在同一张表里完成。清洗完之后，Stream 捕获新增 events，驱动后续增量计算。Aggregate Task 自动刷新 traces，全流程无需外部调度器。

最核心的是这张表本身需要具备很多能力。例如 JSON 部分会有物化字段，需要建立物化表；脏数据清洗需要完善的函数能力，并且这些能力都可以通过 SQL 表达。Databend 面向这种场景做了很多增强。

第一，先把数据沉下来，不要只看最终 Pass/Fail，原始 Trace 需要长期保留。第二，计算能力要跟上。数据存下来之后，还要查得动、算得快。Databend 提供加速列、全文检索和增量聚合能力。第三，上层按需构建。Eval、Replay、RL 不再各存一套，而是基于同一份 Trace 数据提供多种上层能力。

总结：Trace 是 Agent 可靠性的基础设施

说到底，要做好 Agent 轨迹分析与归因，需要一套扎实的 Trace 存储和计算底座。Databend 基于对象存储、VARIANT、加速列、Stream/Task 构建了这样的底座，帮助团队在同一份数据上构建上层评测、回放、归因和训练数据。

Agent 的可靠性不会只来自更大的模型，也不会只来自更复杂的 Prompt。真正要把 Agent 从 Demo 推向生产，必须先把每一步 Trace 存下来、查得动、算得快，并且能用数据回答：哪一步开始跑偏，哪一步消耗了 Token，哪一次改动真的让系统变好了。这，就是“Trace 即 Evals”的核心。