\n\nYugabyte 推出开源智能体原生数据基础设施 Meko，旨在解决多智能体 AI 系统中约 37% 的“状态失效”问题。通过提供共享内存、决策追踪和数据包功能，Meko 致力于消除数据层瓶颈，实现高效的智能体协同。
译自：With the launch of Meko, Yugabyte targets the data layer that's breaking multi-agent AI systems
作者：Carly Page
大约 37% 的多智能体系统故障并非推理故障，而是状态故障。智能体在工作时，对于已经发生的事情、当前的现状以及已经做出的决定有着不一致的看法。来自 Cemri 等人的 MAST 分类法首次对此进行了系统性研究，这个数字敲响了警钟：智能体系的瓶颈不在于模型，而在于其底层的内存层。
这就是 Yugabyte 试图通过发布 Meko 来解决的矛盾点。Meko 是一款开源的、智能体原生的数据基础设施，旨在解决现代智能体 AI 系统中最乏味但也最棘手的问题之一：状态。
“关键在于状态。管理状态并保持其准确性，且实际传输所有内容是非常困难的。”
尽管围绕模型、提示词和编排框架有很多喧嚣，但 Karthik Ranganathan（Yugabyte 的联合创始人兼联合 CEO）告诉 The New Stack，大多数构建 AI 智能体的团队都在一些更为平凡的事情上栽了跟头。
“关键在于状态，”他说，“管理状态并保持其准确性，且实际传输所有内容是非常困难的。”
这不是人们会感到兴奋的部分。但一旦你真正运行这些东西，裂痕往往会出现在数据层，而不是模型中。
当 DIY 技术栈不再好用时
目前大多数从事智能体 AI 工作的团队都在做开发者通常会做的事情，即利用他们已经熟悉的工具拼凑出一个技术栈：一个关系型数据库、一个向量库和一些对象存储。这在一段时间内有效，直到它不再奏效。
“结果是，你的实验循环完全被背后的实现所拖慢和干扰，”Ranganathan 说，“更糟糕的是，还要为了实现而去进行研究。”
开始时，一切都是为了快速移动和尝试。但随着系统的增长，越来越多的时间被消耗在将这些东西连接在一起，并防止数据基础设施崩溃。不久之后，旨在构建智能系统的团队却陷入了追踪管道问题的困境。
此外，还有一个悄然发生的转变。不久前，大多数团队只需要考虑一个数据系统。如今，情况已不再如此。“以前，我们只是拿一个 Postgres 数据库，试图找出布局数据的最佳方式，”Ranganathan 说，“现在我们有一个 Postgres 数据库、一个图数据库和一个向量数据库……问题的复杂度已经上升了几个数量级。”
DIY 方法不仅变得混乱，而且已经成了一团糟。
智能体的失败方式不同于应用
智能体系统表现得不像传统的应用程序。
一个应用有定义的输入和输出。AI 智能体，尤其是在多智能体设置中，要松散得多。它们不断生成和消耗上下文，随时间构建记忆，并在工具和用户之间进行协作。
这引入了一类新问题。
“多智能体系统……就像团队一样，”Ranganathan 说，“最终，无论你是智能体还是人类，你都必须作为一个团队来工作。”
团队合作中最难的部分不是计算，而是协作。是达成共识。是了解已经做了什么以及为什么这么做。
在当今的技术栈中，这种上下文是脆弱的。它在步骤之间丢失。而当出现故障时，重建发生的过程非常困难。
这使得决定保留什么以及丢弃什么，比听起来要难。
记忆、知识以及其中的混乱
Meko 的大部分设计都围绕着记忆和知识展开。
智能体遇到的并非所有事情都有用。有些信息是相关的，有些具有广泛的帮助，而有些只是噪音。挑战在于过滤和结构化这些数据，使其在长时间内保持有用。
系统的任务是提取重要的内容，并使其可以在智能体和人类之间重用。
这就是 Meko 倾向于集体记忆的地方。
在大多数设置中，智能体在孤岛中运行。上下文不容易共享，因此团队会重复工作并丢失学习成果。Meko 引入了“数据包（datapacks）”——这是针对特定项目的范围容器，用于直接数据（对话、决策和输出）以及间接提取的数据（驱动集体记忆和共享知识的学习成果）。
“你将能够共享这个数据包并说，‘你自己看看我做了什么吧，’”Ranganathan 说。
团队可以从共享记录中工作，而不是传递上下文片段。
从日志到决策追踪
Meko 将这个问题——不仅是决定什么重要，而且是以可用的方式保存它——视为核心挑战。
它不只是记录事件，而是捕获 Ranganathan 所说的“决策追踪”——智能体计划做什么、如何执行以及发生了什么。
“如果你不同意这个计划，那么做整件事还有什么意义？”他说。
这也关系到成本和问责。如果一个工作流消耗了大量资源，团队需要了解原因。“有人会跑来问，‘为什么你昨天花了 1000 美元？’”他说。如果没有上下文，就没有明确的答案。
对于首席技术官（CTO）来说，这种级别的可见性不是可选的，而是必需的。
虽然还处于早期，但模式正在显现
Ranganathan 坦诚地谈到了目前的现状。
“我认为他们还在摸索中，”他说，“我们需要可重复的使用案例，才能将其成熟为一种通用的智能体数据基础设施。”
当今的大部分智能体工作仍处于实验阶段。尽管如此，Ranganathan 已经看到了几种模式，例如跨运行的集体学习、可审计的学习记录，以及长周期运行智能体的可恢复性。
例如，在集体学习模式中，当智能体 A 更新了一个共享事实，而智能体 B 读取了过时的状态时，问题就变成了：你想要什么样的 consistency 模型？Yugabyte 认为这是计算机架构意义上的内存一致性问题，并围绕其进行了构建。
在内部，Yugabyte 已经将智能体用于问题分类和代码分析等任务。共同的主线是持久性——让智能体运行更长时间，积累上下文，并产生有用的输出。
“我能让我的智能体在没有我的情况下工作更长时间吗？”他问道。这就是状态再次变得至关重要的地方。
从模型到基础设施的转变
Meko 建立在 Yugabyte 在分布式 PostgreSQL 领域的根基之上，将该基础扩展到 AI 智能体的开源、智能体原生架构中。
在未来的一年里，每个智能体框架都将拥有一个内存层——其有效性将取决于该内存基础设施是否能够通过持续学习使智能体和人类作为一个团队发挥作用。
这预示着一个更广泛的转变。焦点正在从模型转向基础设施——特别是决定系统是否可用和可扩展的数据层。
Yugabyte 押注这个层需要为智能体重新设计，而不是从现有工具中适配。
正如 Ranganathan 所说：“重点不在于模型能做什么……不在于编排……而在于状态。在未来的一年里，每个智能体框架都将拥有一个内存层——其有效性将取决于该内存基础设施是否能够通过持续学习使智能体和人类作为一个团队发挥作用。这需要从第一天起就为此设计的专用智能体原生基础设施。”
而现在，这正是事情开始出问题的地方。工智能
