👨💻 作者 ：某 AI 基础设施公司高级工程师
平时主要和数据平台、AI 工作负载以及云原生架构打交道，也在参与团队 Agent 数据基础设施建设。业余喜欢折腾开源项目，GitHub 活跃度比朋友圈高。
6 月 24 日，上海世博中心。
今年 AWS 中国峰会的主题是 「Agentic Now, Go Build」。
逛下来最大的感受是，大家已经不太讨论模型参数、排行榜或者谁家的模型更聪明了。无论是 Keynote 还是展区交流，讨论最多的话题其实是 Agent 如何真正进入生产环境。
过去一年，大模型能力提升很快，但真正开始做 Agent 项目之后会发现，很多问题最后都不是模型本身的问题。
- Trace 怎么存？
- Memory 怎么管理？
- 实时数据怎么接入？
- 向量检索和分析查询怎么协同？
- 系统规模上来以后成本怎么控制？
这些问题往往比 Prompt 调优更让人头疼。
我自己最近也在参与团队 Agent 数据底座建设，所以看到 Databend 展台的时候，特意停下来聊了一会儿。原因很简单，他们展示的几个场景，刚好和我们最近遇到的问题比较接近。
Agent 落地之后，数据层开始变得复杂
我过去的时候，Databend 展台周围已经围了不少人。
有做 AI 应用的，有做数据平台的，也有不少基础设施工程师。
大家关注点不一样，但提的问题很类似：
- Agent Trace 怎么长期存储？
- Memory 数据量大了以后怎么召回？
- 实时日志如何处理？
- 向量检索和分析查询能不能用同一套系统？
这些问题最终都会落到同一个方向：
当 Agent 工作负载真正开始规模化运行的时候，底层数据平台应该长什么样？
Databend 现场展示的内容，基本都围绕这个主题展开。
从架构上看，他们采用 Amazon S3 作为开放存储层，计算运行在 Amazon EC2 Graviton 实例上，上层由 Databend Cloud 提供数据处理能力。
让我比较关注的是，他们尝试把原本分散在多套系统中的能力放到同一个平台里。包括：
- SQL 分析
- JSON 处理
- 全文检索
- 向量检索
- 实时增量处理
- AI UDF 调用
这些能力单独拿出来都不算新鲜，但如果能够基于同一份数据协同工作，确实能减少不少数据搬运和系统维护成本。
对于做基础设施的人来说，这一点还是挺有吸引力的。
Agent 数据已经不只是 BI 数据
过去我们讨论数据平台，很多时候默认服务对象是 BI、报表或者离线分析。
但 Agent 场景不一样。现在的数据里除了业务数据，还有大量：
- Trace
- Memory
- Tool Call
- Prompt
- Embedding
- 日志
- 反馈数据
而且这些数据既要分析，又要搜索，还要参与实时推理过程。
这意味着结构化数据、半结构化数据和向量数据开始同时存在。
Databend 展示的思路是把这些数据统一放在对象存储上，通过同一套 SQL 引擎完成处理和查询。
从能力层面看，主要包括：
✅ SQL 分析与向量化执行
✅ VARIANT JSON 原生处理
✅ 全文检索与倒排索引
✅ 向量检索与向量索引
✅ Task + Stream 实时增量处理
✅ 基于 S3 的存算分离架构
这一点让我想到我们团队之前踩过的一个坑。
当时分析数据在数仓，向量数据在向量数据库，全文搜索又在另一套搜索系统里。
每次排查问题都需要跨系统查数据。
系统越来越多之后，数据同步和运维本身反而成为新的问题。
所以从工程角度来看，如果一份数据能够同时服务分析、检索和 AI 场景，确实有一定价值。
两个 Demo 比较有意思：Trace 和 Memory
现场重点演示了两个场景。
一个是 Agent Trace 分析。
另一个是 Agent Memory Recall。
这两个也是目前 Agent 系统最容易遇到瓶颈的地方。
Trace：Agent 出问题时到底发生了什么
做过 Agent 的团队应该都有类似经历。
Agent 能跑起来并不难。
真正困难的是出了问题以后不知道问题出在哪。
- 某一步为什么调用了工具？
- 为什么走了这条推理路径？
- 哪一次模型输出开始偏离预期？
- Token 消耗为什么突然上涨？
如果没有完整的轨迹数据，很多优化工作都只能靠猜。
Databend 展示的是一套基于 Trace 数据的分析方案。
据了解，他们已经在一些大型 AI 场景中承载大规模 Trace 数据写入。
对于 Trace 这种 JSON 嵌套层级深、Schema 经常变化的数据，他们采用 VARIANT 类型进行原生存储，通过 json_transform 在库内完成清洗，再结合索引和加速列提升查询效率。
比较有意思的是，他们把 Trace 数据同时用于：
- Evaluation
- Replay
- Root Cause Analysis
- RL 数据管道
也就是说，同一份数据服务多个场景。这个思路我比较认同。
毕竟真正进入生产以后，最大的成本往往不是存储，而是重复建设多套系统。
Memory：百亿级数据怎么查
另一个 Demo 是 Memory Recall。
随着 Agent 使用时间增长，Memory 数据会越来越大。
很多团队会把向量检索和全文检索拆开部署。
结果就是：
- 存两份数据
- 查两次系统
- 最后再自己合并结果
数据量不大的时候问题不明显，但规模上来以后运维复杂度增长很快。
Databend 展示的是把原文、向量和索引统一存储在一张表中，通过单次查询完成过滤和召回。
现场展示的数据看起来比较亮眼。
不过作为工程师，我更关心的是不同 workload 下的表现。
毕竟 Demo 环境和真实生产环境之间永远存在差距。
但从架构思路来看，把分析、检索和 Memory 放在统一的数据层里，确实值得继续关注。
一个比较接地气的客户案例
除了 Agent 场景，他们还展示了沉浸式翻译的案例。
这个案例我反而觉得更有参考价值。
因为很多团队面临的问题其实不是百亿级 Agent 数据，而是如何快速搭建一个低运维成本的数据平台。
按照现场介绍，他们通过 AWS Marketplace 部署 Databend Cloud，利用 Amazon S3 作为数据中转层，再通过 Task 和 COPY INTO 实现实时数据导入。
整个方案没有引入太多额外组件。
对于中小团队来说，这种方式确实比较容易落地。
一点个人感想
逛完整个 AWS Summit，我越来越觉得 Agent 基础设施正在进入新的阶段。
过去大家关注模型能力。
现在大家开始关注如何让 Agent 持续、稳定、低成本地运行。
Agent 要访问数据。
要检索记忆。
要分析轨迹。
要调用工具。
还要在反馈中不断优化。
这些需求最终都会落到数据层。
所以未来的数据平台不仅仅是分析平台，还会逐渐承担搜索、检索、上下文管理以及 AI 工作负载调度的职责。
Databend 在展台展示的方向，本质上也是在回应这些变化。
当然，现场 Demo 和生产环境之间还有距离。
性能、稳定性、多租户隔离、成本模型等问题，最终还要靠真实业务验证。
不过对于正在建设 Agent 数据基础设施的团队来说，这些思路值得研究。
回去之后，我准备拉一个测试环境跑一跑，重点看看 Trace 存储和 Memory Recall 两个场景，能不能解决我们目前遇到的一些问题。
如果后面有新的发现，再单独写篇文章聊聊。