Mathis Joffre，Blaxel联合创始人和工程负责人 – 采访系列

Mathis Joffre，Blaxel联合创始人和工程负责人，是一位经验丰富的基础设施工程师，他曾在OVHcloud帮助扩展了欧洲最大的云平台之一。在Blaxel，他领导了低延迟、可扩展系统的开发，这些系统专为AI代理而设计，并且是公司支持性能驱动部署的开源工具的主要贡献者。

Blaxel是一款专为自主AI代理而设计的计算平台，允许开发人员在不管理基础设施的情况下构建、测试和运行代理工作流。其架构包括超快的微虚拟机、批处理作业执行和全局网关用于路由和故障转移。Blaxel优先考虑安全的沙盒、实时可观察性和无缝的可扩展性，以支持生产级别的代理部署。

您在OVHcloud的AI和数据基础设施研发部门工作了三年——是什么关键时刻或洞察让您决定建立Blaxel作为专为AI代理而设计的云平台？

我在OVHcloud的AI终端（AI Endpoints）项目中工作时意识到，下一代云架构和AI用例将变得非常复杂。我们正在从传统的聊天机器人转向完全自主的系统。这场代理革命不仅仅是关于更智能的应用程序；它还迫使我们重新思考从软件栈到数据中心架构的所有事情。这种认识促使我建立Blaxel。

回顾您早期的工程道路——从Orange Business的网络工具到OVHcloud的栈定义——这种经验如何影响Blaxel的架构和哲学？

我会说：保持脚踏实地。尽管这场革命可能看起来很假设或被过度炒作，但使其成为现实的唯一方法是专注于具体的用例并解决它们。这种心态从一开始就塑造了Blaxel——我们围绕客户的实际需求构建了它，从代码生成到视频分析。我们没有追逐潮流，而是希望提供一个专为代理而设计的平台，能够为代理提供它们需要的所有东西来高效运行。

您能否带我们了解模型上下文协议（MCP）和多区域模型网关的作用？它们如何提高代理的容错性和可扩展性？

代理的上下文至关重要——它们访问相关信息的能力是它们有效行动的关键。MCP是我们将代理与基础设施集成的主要接口，因为它解决了这个挑战。就像开发人员使用REST API连接SaaS世界中的应用程序一样，他们现在将使用模型上下文协议为代理提供特定的、可处理的上下文。

但上下文并不足够——代理还依赖于LLM，例如OpenAI或Anthropic提供的LLM。由于需求的增长，这些提供者的服务器偶尔会因流量而不堪重负。因此，多区域模型网关就出现了。

模型网关允许流量动态地重定向到最近可用的LLM端点（以延迟为单位），无论是OpenAI、Anthropic还是其他提供者。这不仅提高了响应时间，还确保了容错性（通过故障转移到替代提供者）和可扩展性（通过在多个区域和模型中分配负载）。

Blaxel支持开发人员工具，可以被代理调用——是什么动机让您设计出代理可以消费的API，而不是人类可以消费的API？您如何看待这种发展趋势？

对我来说，OpenAI的Operator发布是一个启示——它让我意识到未来将涉及代理直接消费基础设施。代理开始分析历史数据并回答问题。然后他们转向生成代码。下一个逻辑步骤是让他们自主部署代码。

这就是为什么我们认为代理需要自己的云——一个专为代理而设计的云，围绕着代理将驱动IT运营的未来这一理念而构建的。

回顾现有的云提供商和代理托管平台（如Modal、RunPod、Replicate等），您认为在大规模部署代理时最常见的缺陷是什么？

今天的大多数平台都不是为持久、有状态、自主代理而设计的——它们是为无状态作业或推理API而设计的。因此，您最终会以不打算支持长期运行的进程、具有内存、反馈循环和复杂I/O的方式来组装计算、内存、存储和网络。结果要么是脆弱的系统，要么是高运营开销。那就是差距：我们需要基础设施，使代理成为第一类公民，而不是附属品。

您看到的最常见的反模式是什么——以及构建者在生产环境中部署自主代理时会遇到什么问题？
最常见的错误是将代理视为函数——调用、执行，然后忘记。在生产环境中，代理需要保持上下文、管理工具，并有时需要实时响应外部信号。人们经常低估现实世界环境的混乱程度：不稳定的API、不一致的数据、意外的状态转换。构建者经常在理想条件下进行测试，但生产现实需要强大的可观察性、沙盒和恢复策略。

您的路线图包括快照分叉、自动故障转移和更深入的计算优化等功能。您认为哪一个对代理优先系统最具变革性？

快照分叉，毫无疑问。它解锁了调试、实验和并行推理模式，这些模式在传统云环境中是不可能的。想象一个代理到达一个决策点——它将沙盒分叉到多个分支，探索不同的结果，然后选择最好的路径。这种分支逻辑是代理工作流的本质，但对于传统云运行时来说是完全陌生的。它从根本上改变了我们对自主性和控制流的思考方式。

根据Gartner的预测，到2028年，75%的应用程序将使用AI代理——您如何预见Blaxel在AI代理变得普遍的行业中会发展？
随着代理变得普遍，我们预计Blaxel将从“AI代理的基础设施”演变为“它们依赖的运营层”——处理生命周期、协调，甚至市场交互。您不会仅仅在Blaxel上部署代理——您将组合它们、监控它们，并拥有管理其他代理的代理。我们已经看到在金融、安全和企业自动化领域出现的用例，这些用例都指向了这一方向。

您是否设想一个未来，代理不仅运行应用程序——还管理和重新配置基础设施？这种转变的文化和安全影响是什么？
是的，这既令人兴奋又令人不安。从技术上讲，这是有道理的——代理可以监控系统健康状况、应用补丁、优化工作负载。但从文化上讲，这挑战了我们对控制和运营中的信任的看法。从安全角度来看，这意味着重新思考权限模型——不仅仅是谁可以采取行动，还有代理被允许成为什么。我们将需要新的抽象概念来实现可验证的自主性和受限的自我改进。

关于代理本地基础设施的最大误解是什么？
那就是它只是关于更多的GPU或更长的运行时间。代理本地基础设施是关于行为上的便利性——为代理提供记住、探索、适应和恢复的能力。这需要在整个堆栈中进行更改——存储跟踪不断变化的状态、支持并发和分支的执行模型、针对推理而非延迟的可观察性。这种思维方式的转变不是资源的提升。

您在OVHcloud时期最遗憾的技术遗憾或限制是什么，现在您在Blaxel最高兴能解决它？

在OVHcloud，我们构建的很多东西都受到传统抽象的限制——虚拟机、容器、网络——这些都是为人类驱动的工作负载优化的。我们无法轻松地摆脱这些范式。在Blaxel，我们从头开始。我们不需要假装代理是一个批处理作业或微服务。我们可以直接在运行时中构建内存、工具和目标等原语——这解锁了全新的设计空间。

感谢您接受这次精彩的采访，希望了解更多的读者可以访问Blaxel。