今天这篇文章，是 OceanBase AI 引擎研发负责人远智在 “Agent 观测与评测” 技术专场中分享的内容。

会和大家一起从 Codex、蚂蚁阿福等常见的 AI 使用场景出发，聊到规模化的 Agent 实时评估，为大家带来一次面向生产流量的 Agent 可观测实践。

文章会把远智的线下分享，原汁原味地进行还原，干货十足，欢迎大家阅读和留言评论~

刚才在座的老师们聊到了不少 Agent 落地的问题，包括可观测、评测，以及如何进入生产系统、会对生产带来什么影响。接下来，我结合我们做过的工作，和大家交流一下。

今天的内容大致分几部分。先看 Agent 场景与传统云原生场景相比，可观测面临了哪些新问题，再介绍数据怎么采集、端到端的评估链路怎么做，以及规模上来以后怎么降低成本。

在 AI 场景里，可观测数据包含大量文本，也可能包含图片等多模态内容，处理成本是一个很实际的问题。最后，我会介绍 OceanBase 在支撑蚂蚁内部大型 Agent 应用时的一些落地实践，包括灵光、阿福等场景，以及我们在这个过程中的思考。

Agent 可观测面临的新问题

以前在云原生场景里，我们做系统研发，会关注节点的 CPU、内存、接口响应时间，也会通过日志来定位问题。这些都是大家熟悉的可观测手段。

比如 CPU 持续偏高，可能就是需要排查的信号；查日志时，我们经常先用命令行过滤关键字和错误码。这类分析通常可以依赖比较明确的规则和结构化信息，不必一开始就逐条理解所有文本的业务含义。

传统应用的很多行为由代码分支定义，我们可以围绕预设场景做测试，尽量在上线前发现问题，减少问题进入生产。这也让传统可观测更容易围绕异常和性能变化展开。

随着长程 Agent 任务开始进入生产，情况有了变化。先不说个人办公，我们直接看生产业务。比如阿福这样的应用上线以后，我们需要知道它到底解决了多少用户问题，还有多少没有解决好。这些情况，很难只靠发布前的测试就判断清楚。

我们用 Codex 的时候，也会有不满意的时候，甚至会在对话里爆粗口。这其实已经是一个很明确的信号：用户不满意了。应用应该能捕捉到这个反馈，再去看他为什么不满意，还有哪些地方可以改进。

如果每个回答下面都有点赞、点踩按钮，反馈相对容易处理。回答得好就点赞，回答不好就点踩。但用户在对话里表达愤怒或者不满，这些信号就没那么容易被发现。

这样的 bad case 对改进 Agent 很重要。我们先要明确什么样的情况值得关注，再从真实流量里把它们找出来。

找到 bad case 以后，接下来就和我们平常定位问题一样，要知道它究竟出在哪一步。

长程任务里，模型和工具可能在一个 loop 中被反复调用。最终结果有问题，错误却可能发生在前面某一轮，所以定位起来并不容易。

既然离线测试很难覆盖 Agent 的所有实际情况，我们就需要在生产上，结合真实流量和用户反馈，持续改进应用质量。后面会进一步展开这部分内容。

先让不同 Agent 的数据能够一起观测

要做这些工作，首先得把数据采集起来。

前几年 AI 发展很快，大家讨论的 memory、RAG、MCP、工具调用等能力，各有各的实现方式，数据表达也缺少统一约定。Agent 框架同样很多，而且还在不断变化。

AI Vision 当时有开源计划，我们也参与支撑了它的底层数据能力。这个平台需要接入企业内部不同产品线的 Agent，既有生产级应用，也有团队自己开发的 Agent。

这些 Agent 有的还在做 demo，有的已经进入生产，使用的技术栈也不一样。平台面对的问题是，各个产品线分别做自己的 Agent，最终却希望能在同一个地方观测和评测。

不同框架、自研 Agent 对 Span 和关键执行节点的定义，差别可能很大。操作类型、组织方式、组合关系都不一致，采集侧就很难用同一种方式覆盖所有数据。

现场也有老师提到，Agent 产生的数据，最终还要和其他 Agent、已有业务系统的数据关联起来。这样才能把整条链路的关键信息放在一起，无论后续做分析，还是定位根因，都会更方便。

围绕这些问题，AI Vision 的埋点规范采用了分层设计。通用层以 OpenTelemetry GenAI 语义约定为基础，再往上补充 Agent 场景相关的信息。

有些信息与具体业务没有直接关系，却和 Agent 的执行过程密切相关。比如执行了多少轮、调用了多少次工具，很多 Agent 都需要记录，但各家的字段定义未必一样。这些信息就适合放在场景层。

还有一些是业务域的信息。它们可能由 Agent 自己记录，也可能已经存在于原来的业务系统里。要放到同一个观测体系中分析，就需要考虑如何把这些信息关联到相应的 Trace。

这几个层次不仅关系到怎么采集，也会影响后面的评估。

比如比较两个 Agent 调了多少轮、消耗多少 Token，字段定义和统计口径就得能对上，否则很难直接放在一起比较。

所以我们除了做分层设计，也提供了比较灵活的映射方式，让不同框架、自研 Agent 的数据语义能够对齐到平台约定。数据可比，才方便在统一的平台里做观测。

具体接入有两类。先看大家比较容易使用的一类：在桌面端，通过 Plugin 的方式采集通用 Agent 的轨迹。

对于已经适配的 Claude、Codex 等通用 Agent，可以通过标准插件接入。以我的 Mac 为例，采集端拿到轨迹以后，会把数据上报到统一的中心服务，再由服务端继续处理。

另一类是自研 Agent，通常面向具体生产业务或者研发提效。接入它们往往要结合业务代码，找到需要观测的位置，再完成埋点和采集。前面提到的实现差异，在这里都会遇到。

针对自研 Agent，平台也提供了 Skill，帮助业务更快接入 AI Vision。

这个过程和大家用 AI 辅助开发有些相似：先理解业务代码，再根据 Spec 生成相应代码，通过测试检查字段是否符合规范、轨迹是否完整，校验通过以后再上报。

接入以后，还要考虑它和传统业务的关联。一次任务可以从 Agent 发起，但执行过程未必全部发生在 Agent 自己内部。

比如 Agent 调用另一个 Agent，或者访问本地 memory、tools，相关的 Trace 信息通常可以在 Agent 内部采集到。但它调用的工具或 MCP，也可能连接远端的业务系统。

这时，我们需要通过 Trace 把两边的执行过程关联起来，既方便查问题，也为后面降低分析成本做准备。

传统业务链路里往往有一些可以按规则处理的信息，我们可以借助数据库、脚本等方式，先做一轮筛选。

以 Trace 为中心，做端到端实时评估

再结合离线清洗，就可以先把较大的数据集收敛下来。这样，后续分析 Agent 的 Trace 时，需要交给模型精细评估的数据量就会小一些。

接下来讲端到端实时评估。传统应用中，很多执行路径由代码分支定义，我们做测试时也会围绕这些分支追求覆盖度。Agent 的行为则有很大一部分由大模型决定，这会给测试和评估带来新的难度。

大模型生成 Token 时涉及概率分布，用户输入和执行上下文又是开放的，实际可能出现的路径很难穷尽。这使得我们不能只依赖离线测试，还要结合生产上的真实流量，持续打磨应用。

这里采用以 Trace 为中心的方式，希望把 Agent 产生的数据，与传统业务服务、其他相关组件的数据关联起来，放到同一条执行链路上分析。

整体架构从采集端开始。无论是业务应用端还是桌面端，Agent 都需要上报执行轨迹。在蚂蚁内部，这部分数据通过 AntCollector 采集，再实时写入后端存储，目前这套实践使用的是 OceanBase。

生产级应用的数据量很大。我们当时看到的最大的一个应用，一天的 Trace 数据大概有 10 TB；按当时的规模估计，一年大约是 3 到 6 PB。

但只把数据记下来，还不够。接下来得看这些数据里有哪些值得分析的信息。

我之前分析过一批线上的 Trace 数据。在那次分析里，97% 以上是文本，其余约 3% 是传统的结构化数据。

这些文本里有很多有价值的信号。比如在阿福这样的应用里，用户可能表达愤怒、不满，也可能表现出需要进一步关怀的情况。要发现这些线索，就需要分析对话和相关上下文，单看结构化指标很难得到同样的信息。

如何分析这些文本和多模态内容，是可观测需要继续处理的问题。

再看实时流水线。数据上传以后，一方面要利用已有的结构化信息，另一方面，一条 Trace 经过多轮执行可能很复杂，里面不一定所有内容都和当前业务的评估目标有关。

各个业务关心什么，需要先由业务来定义，再由系统负责提取、筛选和分析。不能对所有内容都采取同样的处理方式。

我们看到的一些线上 Trace，体量大概在 3 到 20 MB。对于当前的评估任务，没有必要把里面的所有内容都拿去分析，应当先提取业务关心的关键信息。

任务也需要筛选：哪些 Trace 要交给哪些评估器，应该先明确下来。简单的判断，可以用正则、关键词匹配；复杂一些的，再使用小模型或者大模型。

这些处理仍然会消耗算力，所以我们希望先利用 Trace 上已有的标量字段，让数据库快速过滤一轮，尽量把更大范围的筛选留在成本较低的环节完成。

在确定评估维度、提取相关信息以后，就可以执行评估。评估完成，结果还应该关联回相应的 Trace，用来支持后续分析，以及质量观测、告警、下钻和业务决策。

还有一个问题，从数据库角度看可能比较熟悉，但对可观测平台很关键：不同业务上报的数据结构和字段，并不完全相同，平台要能适配这些差异。

不同系统的字段定义差别很大，而且一条 Trace 中，并非所有数据都是某个评估任务需要的。我们要能用比较低的成本，把关心的上下文和字段提取出来。

业务发布新版本、Trace 结构变化以后，也希望能通过调整表达式完成适配，减少对业务代码和评估器的改动。

AI Vision 在这里采用声明式表达式，把数据提取和评估器分开。评估器面向约定好的输入变量，表达式负责从具体的 Trace 结构中取出这些变量。

这样，如果只是字段路径或节点位置变化，而变量含义、输入约定没有变化，就可以优先调整表达式，让原来的评估器继续工作，减少对业务的侵入。

接下来再看规模化。Agent 面向生产流量以后，评估规模也会跟着增长。我们当时接触到的最大场景，一天就有约 10 TB 的 Trace 数据。

在这样的数据量下，既要让业务关心的效果能够被观察到，又要控制成本，这会直接影响方案能不能长期落地。

规模上来以后，怎样兼顾成本和效果

这里最大的挑战之一就是成本。做完评估，业务往往还要做 A/B test，每个实验里再分组比较，评估量就会继续增加。

有些任务可以采样，但一些业务关注的问题，我们希望尽量覆盖更大范围的流量。比如负面情绪、用户关怀相关的信号，可能就需要更广的覆盖。

这样算下来，Token 成本可能很高，处理所需的时间也未必能够接受。

我们在对外服务业务时，也经常碰到类似的问题：处理多模态数据时，很多环节希望借助大模型，但要真正落地，必须兼顾成本和效果。

在 AI Vision 上总结出的经验，和我们给业务提供方案时的考虑一致：能够用标量条件处理的，尽量先用标量；能用小模型处理的，先用小模型。经过这些环节把数据范围缩小以后，再让大模型处理需要它判断的部分。

在模型这一层，我们也在尝试几种做法。一种是让较轻量的模型做二分类，输出 good 或 bad，再给出对应的概率。这种方式比较轻量，成本也较低。

但如果结果只有 good 和 bad，模棱两可的情况就不容易表达出来。另一种做法，是增加 unsure，做成三分类，并结合概率判断。

这种方式可能带来更多处理成本，但能够把不确定的样本明确保留下来，便于继续判断，不会在最初的分类里就忽略掉这些情况。

第三种做法，是把一个复杂问题拆成类似决策树的结构，在不同节点上分别用小模型判断。前面的节点如果已经能得出结论，就不必继续往后处理，更多判断只留给需要的样本。

这种方式相当于按问题逐步路由，可以把不同规则拆开处理。但它也有成本：一个问题可能要经过多轮小模型调用，规则怎么设计、节点怎么组织，还依赖专家经验，不能只看某一次调用便宜不便宜。

OceanBase 在可观测场景中的落地

最后介绍一下 OceanBase 在可观测场景中的落地。现场可能有老师还不太熟悉 OceanBase，我先简单说明一下它在 AI 场景中的数据能力。

过去大家更多把它理解为数据库。面向 AI 应用，我们还需要多模数据和相关的基础能力，并在这层数据底座之上，支持语义加工、智能构建等数据智能工作。

比如让 Agent 辅助做 ETL，以及知识库、可观测、memory 等基础数据组件，都是这里讨论的内容。另外还有 MaaS 这一层，通过专用小模型和模型路由，帮助业务以更可控的成本处理多模态数据。

再回到阿福等应用的可观测场景。这里对数据底座的一个直接要求，就是要承接大量 Trace 和 Checkpoint 数据。

前面提到，相关场景的 Trace 数据一年可能达到 3 到 6 PB。保存这些数据，主要有两方面的用途：一是从里面发现 bad case，二是结合 Trace 和 Checkpoint，把问题复现出来。

有些问题只有在特定用户上下文中才会触发，所以复现时需要保留当时的输入和状态。

这些数据的访问也有热度差异。按我们当时总结的情况，大约 90% 的 bad case 会在 3 天之内处理，处理慢一些的可能需要 7 天左右。

我们还会保留更早的数据，因为后续的离线加工、数据挖掘也会用到。只是相较于最近 3 天或 7 天，较早数据的写入、更新和查询通常没有那么频繁。冷热分层就能利用这种差异，降低留存成本。

第二个方面，是把 Trace 变成指标。可观测系统里的核心数据库，一方面要存下原始 Trace，另一方面要提取关键指标和属性，展开成宽表，结合列存支持后续的聚合分析。

这些字段可以用来聚合和查询指标，也能帮助业务把较大的 Trace 集缩小，找出值得进一步分析的 bad case。

OceanBase 在这里承接几类负载：原始 Trace 的入库与访问，偏 KV 型的数据处理；围绕指标的 SQL 聚合，偏分析型的处理；以及在线按关键词、结构化字段、向量等条件进行查询的混合搜索。

在我们接触的 Trace 场景里，这几类负载都需要处理。因此，我们希望用一套能够支持多种数据和查询方式的系统，把这些环节衔接起来。

混合搜索也是同样的考虑：先缩小候选结果，再让小模型、大模型逐步分析。OceanBase 在这里提供的查询手段包括 BM25、向量、规则和标量条件。

还有一些具体应用。Trace 里面很有价值的两类信息，是用户的对话和模型输出，从中可以提取与当前任务相关的上下文。举个简单的例子，比如用户提到自己感冒了。

Agent 可以先结合这个用户当前的对话和已有上下文，继续推理、调用工具；也可以检索相关的历史对话或案例，为当前任务补充信息。

这里想说明的是，Trace 里的 input 和 output，可以成为历史对话检索的来源。另外，执行过程中可能还有记忆组件，也可以对其中的相关记忆做召回。

bad case 归因以后，下一步就是解决问题。我们做 A/B test、分组评测时，还需要尽快把评测环境准备起来。

拉起一个计算沙箱通常相对容易，但完整的 Agent 评测不只依赖计算资源，还依赖特定的表结构和基础数据。数据这一层没准备好，计算环境起来了也不能直接开始评测。

传统方式下，单独准备一个数据沙箱往往要复制数据，耗时会和表的数量、数据规模有关。

但当时内部对端到端评测环境提出的要求是，整体搭建不超过 5 分钟，留给 DB 或数据基础设施的时间，大概不超过 1 分钟。数据准备必须在这样的时间预算里完成。

这项要求并不会因为表多、数据大，就相应放宽准备时间。所以我们提供了数据沙箱的能力，让上千张表的 Fork 可以在毫秒级或秒级完成。我们当时也测试过几个 TB 的数据，Fork 大概在秒级左右。

有了这个条件，评测时就可以并行拉起多个临时沙箱。评测结束后，再清理这些临时沙箱和数据分支。

小结

线上发现 bad case 之后，还要能找回当时的上下文，定位原因，并在修复后做对照评测。

统一轨迹语义、先筛选再调用模型、用数据分支准备环境，处理的是这个过程里的接入差异、模型成本和数据准备问题。

评估的结论，最后也需要能回到原来的执行链路上进行查证~

立即试用 OceanBase 企业版，体验国产数据库能力 立即试用