摘要：在分布式和云原生时代，中间件通过屏蔽底层复杂性、提供标准化接口，大幅提升了软件研发效率。如今，AI 中间件也正在扮演类似的角色。那么，如何从“云原生”平滑过渡到“智能原生”？又该如何解决当前 AI 应用开发的核心痛点？

作者 | QCon 全球软件开发大会

策划 | Kitty

编辑 | 宇琪

在分布式和云原生时代，中间件通过屏蔽底层复杂性、提供标准化接口，大幅提升了软件研发效率。如今，AI 中间件也正在扮演类似的角色。那么，如何从“云原生”平滑过渡到“智能原生”？又该如何解决当前 AI 应用开发的核心痛点？

近日 InfoQ《极客有约》X AICon 直播栏目特别邀请了蚂蚁集团 资深技术专家宋顺担任主持人，和蚂蚁集团 AI 中间件负责人章耿、记忆张量 CTO 李志宇博士一起，在QCon全球软件开发大会2025 上海站 即将召开之际， 探讨 AI 中间件的基建之战。

部分精彩观点如下：

AI 中间件的核心价值在于：降低开发门槛、提升系统可靠性、保障安全可控。未来，谁能更好地掌握中间件的能力，谁就能在智能应用中占据先机。

自研 AI 中间件不仅是“可以做”，而且是“必须做”的事情。它不是为了重复造轮子，而是为了打造一辆符合自己赛道规则、安全标准和成本要求的“超级赛车”。

对于非核心、创新探索型业务。大胆拥抱开源和云厂商服务，快速试错，验证想法；对于核心业务、规模化应用：必须走自研或在开源基础上深度定制的道路。

传统技术积累并没有过时，而是需要在新的框架下实现“重生”。

在 10 月 23-25 日将于上海举办的 QCon全球软件开发大会2025 上海站上，我们特别设置了 【AI 中间件：加速智能应用开发】 专题。该专题聚焦 AI 中间件的关键技术、行业实践与未来趋势，分享 Agent 架构设计、多模态智能协作、生产环境落地经验等方面的前沿探索。

查看大会日程解锁更多精彩内容：https://qcon.infoq.cn/2025/shanghai/schedule

以下内容基于直播速记整理，经 InfoQ 删减。

智能基建

宋顺：如果云原生基建的核心是调度和管理服务，那么在智能基建里，核心对象会变成 Agent、模型，还是记忆？这种对象层面的转变，会带来哪些新挑战？

章耿：云原生时代，围绕的核心是云环境，所以云原生的核心思想是让应用“生于云，长于云”，从一开始就为云环境而设计，从而能最大限度地利用云平台的优势。云原生的四个典型技术——微服务、容器化、持续交付、DevOps，这些技术主要就要做到两点：第一、帮助开发者把业务应用的服务，变成标准化的、无状态的服务单元，第二点就是通过 K8S 调度 /ServiceMesh 等基础设施做到自动化的运维，让成千上万个服务能够稳定、高效、确定性地运行。

而在智能原生时代，围绕的核心是 AI，要做的同样是让应用能最大限度地利用 AI 的优势，比如如何快速调用大模型，如何提供出大模型友好的服务、数据，如何找到好用的 Memory 服务，如何构建稳定可靠的 Agent 等等。另外，智能原生里面的服务载体从微服务变成了 Agent 智能体，它融合了模型、记忆、工具等要素，但 Agent 和微服务同样是需要稳定、高效运行的，还是会用到已有的云基础设施，所以说智能原生和云原生不是替代关系，而是进化的关系，现在业界也有人提 AI Cloud Native 的概念。

这些改变也带来了不少新的挑战：

首先，底层调度的维度更多，除了云原生时代考虑的 CPU、内存、网络外，智能基建还需要考虑 GPU、TPU 等。那如何做到算力异构、智能调度都个全新的命题。

其次，出现全新的基础服务：智能原生的应用其实就是 Agent，构建 Agent 会依赖众多的服务，比如推理服务、RAG、Memory 等等，这是是之前没有的中间件，对应用最友好的做法就是把这些服务端也作为云服务。这里就会出现新的研发范式、通信协议、协调机制等等。

第三个状态管理的复杂性：云原生推崇无状态这样更容易伸缩，而 Agent 往往是有上下文、有记忆的。你要解决记忆持久化、跨会话迁移、隐私保护等工程问题。

最后一个也是最大的挑战就是不确定性。传统微服务，输入相同，输出必然相同，所以调用拓扑是静态的，行为是可预测的。但 LLM 的输出是概率性的，同一个问题问两遍，答案可能不一样，这就导致智能体的执行链路可能是动态的。这对于金融级应用要求的稳定性和可预测性是致命的，我们需要提供基建把这种不确定性“框”在一个可接受的范围内，这就依赖上下文工程，更强的可观测，评测体系、SLA 保障体系等等。

宋顺：如果把 AI 应用比作“数字大脑”，记忆服务是否可以类比为‘海马体’？在智能基建蓝图中，它更像是数据库式的底层基础设施，还是像应用层类库一样的可选能力？

李志宇：人脑的海马体主要负责将短期记忆、感受和经历转化为可被提取和利用的长期记忆。如果海马体受损，人就难以将新的经验固化下来。即便在当下能够感知、理解并作出回应，过一段时间后也可能完全忘记刚刚发生的事情。对于人而言，缺失海马体意味着大脑无法完整发挥功能。从人工智能的角度来看，这一机制也有相似之处。

以 ChatGPT 为例，从 2023 年到 2024 年，它已经开始能够记住之前的一些对话内容。这个变化背后涉及一个关键机制——记忆机制。如果没有类似海马体的记忆机制，模型只能进行短期对话，每次提问都需要把之前的上下文完整复制粘贴给模型，才能得到合理回答。

我们在开发“MemOS”这一中间件时，一个核心目标就是模拟海马体的功能，将用户与大模型之间碎片化的对话沉淀为长期记忆。我们希望模型不仅能记住信息，还能在合适的时机调用过去的记忆和经验，并持续学习、动态适应未来的问题。从定位来看，它不仅仅是一个数据库。目前它可能还是一种增强型的可选工具，但随着 AI 原生应用以及可接入智能体的应用越来越多，记忆机制将从可选项逐渐变为必需组件。

正如人类缺失海马体会对生活造成巨大困扰，未来的 AI 也一样。如果不引入记忆机制，AI 只能解决当下的问题，无法满足人们对其更高层次的期望，如长期陪伴、持续进化、根据与用户的交互逐渐提升价值等。对企业而言，我们也希望用户在使用 AI 的过程中能逐步积累企业必需的经验，这些经验再被整合并用于提升后续服务的能力。这正是我们认为极其重要的一点。

宋顺：从我们的实践来看，AI 中间件正在成为智能时代的“连接器”和“加速器”。它不仅要解决模型与业务之间的接口问题，更要处理上下文管理、记忆持久化、工具调度、安全管控等一系列工程挑战。就像云原生时代的 K8S 标准化了应用的部署与管理，AI 中间件也在逐步形成一套标准化的智能应用开发范式。它的核心价值在于：降低开发门槛、提升系统可靠性、保障安全可控。未来，谁能更好地掌握中间件的能力，谁就能在智能应用中占据先机。

宋顺：既然开源和 API 如此方便，企业为何还要自研中间件？它的不可替代性，是主要体现在技术上，还是业务安全和成本控制上？

章耿：这是一个非常现实的问题，也是我们内部被反复挑战的问题。很多业务同学会问：“我用 LangChain 加上 OpenAI 的 API，几个小时就能搭个 Demo，为什么还要花大力气接你们的平台？”，我用 dify 就可以配置几个 Agent，你有什么差异的地方吗？我的回答是：一个能跑的 Demo 和一个能支撑千万级用户、满足金融级安全合规要求的企业级应用，中间隔着十万八千里，特别是安全、稳定性、成本等方面的考量，就像冰山在海平面下的部分。

对应蚂蚁这么大体量的研发群体来说，自研 AI 中间件存在不可替代性。首先是技术层面，不管是从公司统一的架构演进、还是研发效率的提升方面，都希望有统一的基础设施，我们不希望每个研发同学去关注很底层的一些技术实现，而是能够方便地获取基础服务（比如大模型服务、RAG 服务、网关等），更专注在业务创新上面，这些需要中间件去提供。另外蚂蚁的技术架构已经是高度定制化的，已经存在成千上万的 RPC 服务、消息队列、数据接口，让 AI 应用需要无缝地调用内部服务，都需要集成内部已有的基建，这种深度集成是任何外部方案都无法提供的。

其次就是安全和稳定性，这个是业务生命线，金融级应用对数据隐私和合规性有极高要求，开源方案难以满足，企业内部的数据安全合规、调用链路、业务流程是高度差异化的，需要中间件去适配和优化。

第三就是成本，这里包括研发效率提升，业务运行成本下降。比如通过统一的大模型云服务和服务，让开发者构建支持千万规模 Agent 的时间缩短一半，修复安全问题的时间缩短这些都是提升研发效率。另外通过默认的上下文工程、智能路由、请求合并等降低 token 消耗这些都算是降低运行成本。开源方案是无法满足企业内极致的成本优化与性能的需求，需要内部中间件去满足。

所以，自研中间件在蚂蚁不仅是“可以做”，而且是“必须做”的事情。它不是为了重复造轮子，而是为了打造一辆符合我们自己赛道规则、安全标准和成本要求的“超级赛车”。

宋顺：实现高效的“长期记忆”，最大的技术瓶颈是在数据的检索精度和速度上，还是在设计一个能让 AI 轻松理解和使用的记忆架构本身？当前向量数据库似乎是记忆存储的主流选择，这是终极方案吗？有没有其他更前沿的技术方向可能带来突破？

李志宇：在开发 MemOS 时，我们一直在思考这些问题。对于整个记忆框架而言，瓶颈不仅仅在检索的精度和准确性上。这两方面无论学术界还是产业界都在不断优化，真正的难点在于如何设计一套完整的记忆架构，使 AI 能像人一样理解、组织和使用记忆，提高其适人性。记忆管理是一项系统工程，并非简单地做一个最基础的 RAG 框架——把信息存进去、向量化再取出来就能完成。

要把记忆框架或系统做好，必须从入口到出口全面设计：包括记忆的读取、组织、存储、检索、更新，乃至记忆共享。每一步都涉及复杂机制，需要系统性思考，才能合理构建。例如，当用户完成一次对话后，哪些信息值得抽取为记忆？抽取出的记忆归属于哪些主体？这些记忆的优先级、时效性和版本如何管理？在需要时又如何高效检索、调用并准备好？在推理时，是采用明文记忆还是 KV 缓存记忆更好？这些问题远比“查得准、查得快”复杂得多，需要更深入地考虑记忆机制。

目前，很多看似具备记忆能力的框架都以向量数据库为主流选择，因为它能很好地解决语义相似性检索的问题。但在我看来，这只是相对快速的实现方式之一，并非完善的解决方案。举例来说，假设用户要去餐厅用餐，向大模型请求推荐菜品。如果只依赖向量数据库或语义相似性检索，大概率会召回用户历史偏好的菜式信息。但从更个性化、真实体感的角度出发，用户可能有过敏或健康相关信息，这些也应在推荐场景被召回。只有做到这一点，推荐才会更具拟人性和温度感。因此，单纯依赖向量数据库难以很好地解决问题，因为除了语义相似性，还需处理横向扩展、关联查询等更复杂的需求。

这也是我们在设计记忆整体存储时，调研大量框架并与 Nebula Graph 等团队合作的原因。它们是市面上少数能够同时支持图谱化检索和向量化检索的方案。我们希望把图谱和向量检索结合，在记忆场景下实现更完善的功能。从未来解决方案的角度看，我认为至少有三个方向值得重点关注。

第一，记忆的分层管理。不同类型的记忆，如模型参数化记忆、推理过程中形成的激活记忆、外部或内部的明文记忆，在不同场景下读写效率不同，需要面向应用场景进行精细管理。

第二，记忆的结构化、事件化、情景化组织和抽取。我们的目标不仅仅是把对话切分成 chunk、做 embedding 和相似性召回，更希望在相似度匹配之外，提供更可扩展的记忆检索因果链图谱，以提高模型召回和知识准确性。

第三，借鉴人脑记忆管理机制来优化系统。人脑在记忆管理上效率极高，同时具备如遗忘等特性以提高效率。我们是否可以吸收这些机制来反向优化记忆系统？记忆服务应当是一种类似操作系统的范式，能够对用户记忆进行全生命周期管理，具备记忆资产管理与治理特性，帮助用户在长期交互中让大模型真正理解用户、陪伴成长，并持续实现个性化与进化能力。

宋顺：我们在推进 AI 与中间件融合的过程中，也遇到不少实际问题。比如上下文长度限制带来的性能瓶颈，我们通过引入分层记忆机制来优化；再比如工具调用的安全性，我们设计了沙箱环境和权限审批流程来保障。还有一个典型问题是 Agent 行为的不可预测性，我们正在构建一套基于模拟环境的测试框架，逐步实现对 AI 行为的可观测、可评估、可控制。这些实践告诉我们，AI 中间件不是一蹴而就的，它需要持续迭代和生态共建。

宋顺：如果未来所有大模型的能力都变得极度强大且非常低价，那么今天我们在讨论的 AI 中间件的哪些能力会被替代？哪些能力仍然是必需的？

李志宇：假设未来模型既强大又便宜，这里的“强大”包括推理能力极强，单轮对话的上下文处理能力显著提升，同时通过极致的压缩与加速技术将成本大幅降低。就我看来，短期内要实现“强大、低价、通用”三者兼得极为困难。如果有团队能做到，他们必须同时具备训练基础模型的能力，才能在理解模型价格优化重点的前提下，明确在哪些部署环节进行针对性优化。除此之外，还需要结合特定应用场景，反向推动部署层面的策略优化，才能实现既强大又经济的效果。如果仅依靠应用场景反推部署和推理优化，就难以形成通用、高性能且低成本的服务。

假如未来真能实现，我认为中间件仍有切入点，尤其体现在行业专有知识与数据的接入，以及个性化交互方面。因为行业和个体层面的信息高度差异化，模型从通用角度难以覆盖这些需求。除此之外，中间件在安全、隐私、合规和审计层面也具有重要价值。当前大模型仍是概率模型，不可能百分之百保障安全与合规，因此需要通过中间件兜底。进一步来看，中间件还承担流程编排、工具调用、多系统集成以及多 GPU、多显卡调度等任务，而这些并非大模型能够直接完成。

整体而言，如果模型真的能做到极致强大和低价，我们需要重新思考中间件的角色——它将从过去弥补模型短板，转向承接行业和个体的复杂性与个性化需求。若能在这一方向上持续优化，并在差异化价值、安全合规等方面发挥作用，中间件在短期内仍然难以被替代。

章耿：我非常期待未来大模型能力极度强大、成本极低，像水电一样无处不在，就像如今的 5G 流量。如果真有那么一天，创新成本将大幅降低，应用规模会迎来爆发式增长。同时一些能力必然会被替代，比如提示词封装、简单的工作流编排和基础的智能体功能。我们已经看到趋势，例如 OpenAI 推出的 response API，就是在往这个方向演进。但无论模型多强大，它始终不是业务本身。即便是 AI Native，也无法完全替代现有业务。

因此，中间件的核心价值在于连接业务与大模型。大模型越强大、应用规模越大，中间件的价值就越凸显。它将更加专注于编排、治理和协同，而不是教应用如何使用模型，或教模型如何完成任务。届时，中间件将像中枢系统一样，负责传递信号、进行控制和维持秩序，帮助业务更好地使用 AI，创造价值。

搭建企业级 AI 中间件

宋顺：如果云厂商提供一站式全托管平台，会不会让独立中间件失去空间？对于团队来说，如何在‘直接用开源’与‘建设自有中间件’之间做权衡？企业的自研中间件如何守住自己的护城河？

章耿：首先，云厂商提供一站式平台是大势所趋，一定会挤压通用中间件的生存空间。对于很多中小型企业或者非核心业务场景，直接使用云厂商提供的 AI PaaS 平台，会是成本最低、效率最高的选择。这一点我们必须承认。

那么，如何权衡？我的建议是：对于非核心、创新探索型业务。大胆拥抱开源和云厂商服务，快速试错，验证想法；对于核心业务、规模化应用：必须走自研或在开源基础上深度定制的道路。但不是所有东西都自己造，我们的策略是“站在巨人的肩膀上”，积极拥抱开源，比如在底层使用 K8s、Istio 等云原生技术，在上层借鉴 LangChain 等框架的设计思想。我们的核心工作是把这些通用的技术，与蚂蚁的业务场景进行“淬炼”和“粘合”，打造出最适合我们自己的那一层“差异化价值”。

简而言之就是别人能做的我们用，但别人做不了的、跟我们业务命脉最相关的部分，我们必须自己牢牢掌握在手里，这就是护城河。那如何守住自研中间件的护城河呢？一是符合业务特性，跟业务深度集成绑定，让业务离不开你，比如蚂蚁业务要深度适配金融场景的安全合规能力，包括数据隐私、模型安全、供应链安全；二是极致性能优化带来的成本优势，不希望被任何一家云厂商或模型厂商绑定；三是与现有技术栈深度集成形成的生态壁垒，对系统的每一个环节都有绝对的控制力。第四个就是要开放，拥抱开源，预留扩展机制，跟业务、跟业界实践一起成长。

李志宇：如果云厂商能够提供一站式的托管平台，那么很多通用型或底层的中间件功能，如模型调用、基础的工作流编排、检索组件等，企业直接采购并使用即可，性价比更高。但在研发过程中也必须考虑另一个问题：如果企业将所有能力都完全托管给云厂商，那么灵活性和差异化将丧失，核心命脉交到别人手里。尤其是在数据安全和合规要求极高的行业，如金融领域，云厂商的标准化方案往往难以满足企业特定需求。

在这种情况下，企业应当有节奏地推进自研和深度改造，利用开源中间件并进行定制化开发。这不仅能守住企业发展的核心资产，还能逐步形成不可复制的差异化能力。换句话说，可以在通用中间件的基础上做分支，沉淀出属于企业自身的特色。

至于如何选择开源组件还是中间件托管，这不是非此即彼的二选一，而是要分层、分阶段、有节奏地推进。底层基础部分完全可以依赖开源组件，从而降低研发成本；而在上层业务层面，则需要结合企业自身能力和可控成本进行定制和控制层开发，把安全要求和行业规范固化在自有流程中。这部分才是真正能体现企业差异化的地方，并推动自有中间件逐渐走向强大。

宋顺：搭建企业级 AI 中间件的成本天花板有多高？它可能是一个‘成本中心’还是未来能反哺业务的‘利润中心’？通常需要多久才能看到正向的 ROI ？

章耿：如果你想从零开始，自研向量数据库、自研分布式训练 / 推理框架、自建 GPU 集群，那投入将是无底洞。一个成熟的 AI 基础设施团队，规模可能达到上百人，每年的研发和硬件成本可能是数千万甚至上亿。但如果我们把 AI 中间件的范围，还是聚焦在解决 AI 应用研发的“共性痛点”，那还是传统中间件的范围，这个成本还是可控的。

AI 中间件起步简单肯定是应该成本中心，你要投入同学去调用，去开发。但是它是可以迅速转变为“能力中心”或者“价值中心”，中间件的能力暂时不直接产生收入，但是可以跟公司的不同业务去复用，实现 N 倍的效率提升，比如前面提到的节约人力投入，节约 token 消耗，这些都是间接的价值。如果这些能力能够帮助在业务获得增长，或者打败对手，那这个价值就更大了。

至于长期看，AI 中间件能否能为利润中心，这个还是要看企业的策略，一般企业对内部中间件是没有利润的要求的。但像亚马逊、阿里云、蚂蚁数科，这些企业是有对外输出的需求的，如果 AI 中间件做得足够好、足够通用，那也会成为商业化产品。之前蚂蚁的 SOFAStack 就是从内部实践走向商业化的例子，所以这是可期的未来。

关于 ROI，这取决于你的切入点。如果你的策略是先建设、再推广，那可能需要 6-12 个月就能看到明显的 ROI。 但如果你的策略是深入业务解决实际问题，跟业务一起共建的话，一般 3 个月左右就能看到明显的 ROI。 但要追求更高的 ROI，还是需要 1 年甚至更长的时间去沉淀能力，沉淀产品的，毕竟在这个领域，大家都是新手。

跟所有的其它技术一样，只有足够低的开发成本，才能吸引到更多的开发者。你要提供配套的开源核心框架和组件、提供标准化的 SaaS 服务、同时还要建立开发者社区和生态。以蚂蚁目前的实践为例，对应低代码模式，提供了 Agent 平台上让业务同学去构建智能体；对于写代码的模式，我们同时建设 Java 和 Python 体系的框架和组件，配套文档、Demo、脚手架等等，提供通用的大模型服务、RAG、MCP、Memory 服务。也有丰富的文档、课程、Workshop、运营活动等等。总而言之就是就是让大家都可以低成本的 hands-on，亲自感受 AI 的魅力，只有当千千万万的开发者都能轻松参与进来，整个 AI 应用生态才能真正爆发。

宋顺：在优化 GPU 等昂贵算力资源上，AI 中间件有哪些‘独门秘籍’？是模型卸载、动态批处理，还是更智能的调度策略？

李志宇：从我们的角度，尤其是 MemOS 的视角来看，要做好这件事的核心方向在于调度。以 GPU 使用为例，我们希望在长时间内尽可能压榨 GPU 的占用和使用效率。具体思路是“化整为零”，将单次推理的开销分散到用户与模型的各个交互环节，通过这种细碎的分散与填充来提升 GPU 的利用率。

对于记忆框架而言，调度不仅涉及算力层面，还扩展到记忆的管理。我们将记忆划分为参数化记忆、激活记忆和明文记忆，并统一纳入调度体系，就像操作系统管理 CPU 或显存资源一样。我们会根据用户需求和场景优先级来决定记忆的加载、缓存、转移和压缩，以确保调度高效、平稳。

如果调度能够做到位，那么即便用户尚未完整输入查询，我们也能预测其意图，并提前准备好相关记忆，包括 KV cache、参数化记忆和明文记忆。当用户完成输入时，系统只需简单操作即可作答，从而显著降低首 token 延迟，让使用过程更加流畅。同时，这种调度方式也能最大化 GPU 推理过程中的 buffer 利用率。此外，我们在 KV cache 上进行了一些编码和前置优化，希望通过“以空间换算力”的方式提升性能。尤其是在如 4090 这样算力相对有限的显卡上，效果会更加显著。

展望未来

观众：未来会做能够持续更新权重的参数化记忆框架吗？

李志宇：我们对参数化记忆、激活记忆和明文记忆进行分层管理，原因在于它们的读写效率不同：参数化记忆写入效率低但读取效率高；明文记忆则相反，写入快但读取慢；激活记忆则介于两者之间。未来我们会重点推进参数化记忆。例如，对于单个用户或企业的一些高频偏好、规则，如果能通过数据增强和模型训练，将其固化到参数中，那么在日常高频使用场景中，读取效率将非常高，从而显著提升整体记忆管理效率。同时，参数化记忆的发展也会带来更多中间件层面的需求，例如如何灵活加载、缓存和管理参数记忆，如何设计调度和路由机制等，这些都将推动新的技术要求和功能衍生。

宋顺：未来 1–2 年，AI 中间件是否会出现类似 K8S 的“事实标准”？随着多模态和机器人技术的发展，对中间件会提出哪些新的要求？

李志宇：从我的判断来看，未来确实可能会出现类似的标准。K8S 的成功在于抓住了云原生的核心矛盾，即如何对算力资源进行高效抽象与调度。而在 AI 场景下，矛盾则转化为如何对不同模型、不同数据、不同算力以及不同应用场景进行一致性的调度与管理。如果能够有一个事实上的框架解决这些问题，例如统一接口、异构算力适配、可观察与可治理机制、安全可控保障以及场景的个性化抽象，并能将这些痛点整合并解决，那么它就有可能成为未来 AI 中间件层的标准。

从智能基建的角度来看，AI 的基础设施可能会越来越像人脑。在记忆、推理、感知和行动等层面，都会有相应的中间件进行支撑，从而为 AI 的上层应用提供开发与建设的基础。因此，未来的基建将不再是单点的推进，而是需要一个完整的框架或方案，将上述流程打通，并支持整个生态的可持续演化与发展。谁能率先提出并落实这样一套框架，就有可能形成标准，并在应用开发的中间件层面占据主导地位。

章耿：在 AI 中间件领域，我认为 1-2 年内出现一个像 K8s 那样大一统的“事实标准”是比较困难的。原因在于，AI 应用的范式本身还远未收敛。它比当年容器编排的战场要复杂得多。我倾向于认为，会涌现出一系列“子领域标准”或“事实标准”的组合，在智能体编排、工具调用、记忆管理、UI 交互等不同层面形成各自的标准分别统治不同的垂直层面。比如现在很火的 MCP 就有成为工具调用领域事实标准的趋势，还有其它的一些 A2A 的智能体编排协议。

然后多模态对于中间件来说，其实就是数据流处理的挑战比较大，面对的不再是之前的文本或者结构化的二进制数据，可能是来自摄像头、麦克风、激光雷达等传感器的高吞吐量、非结构化的数据流。我们需要像 Flink、Kafka 这样的流处理能力，但处理的对象是视频帧、音频波形，并且要在流上进行实时的 AI 推理。

机器人技术这个领域可能会有这些新的挑战：多模态数据的统一处理和协调，需要不同模态、不同算力平台之间的实时切换和编排；实时性要求的显著提升，不能是异步；安全冗余与失效恢复，会把对中间件的要求从“逻辑正确”推向“物理可靠”。这不仅仅是技术的演进，更是责任的升级。

宋顺：我认为 AI 中间件作为“智能基建”的形态或许还未完全定型，但它所代表的方向——通过工程化、标准化、组件化的方式，让 AI 应用开发从“手工作坊”走向“现代化工厂”——已经非常明确。AI 中间件有潜力成为组织智能的“神经中枢”，连接模型、数据与业务系统，实现真正的智能协同。

宋顺：想成为一名优秀的 AI 中间件工程师，应该深耕传统的分布式系统老本事，还是猛攻 LLM 和 Agent 的新知识？如何平衡这两者？

李志宇：“有节奏、有层次地开展”这一点在任何场景下都适用。在当前语境下，要回答这个问题，其实并不是一个非黑即白的选择，而是需要“两条腿一起走”。开发者需要结合自身的研发背景和技术栈，重新思考在新的环境下可能带来的变化。

以传统分布式系统的研发者为例，过去我们在做资源调度、容错机制、网络通信等方面的积累，如今在大模型或 Agent 的应用场景中，仍然可能焕发新的价值。这些基础能力就像地基一样，如果要在大模型时代真正把 AI 的建设做好，这些知识依旧必须掌握和打磨。

以我们在 MemOS 的实践为例，我们正在推进 SaaS 化的平台服务，并逐步面向更多 To D 用户。在扩展服务过程中，传统分布式系统中的稳定性、调度的灵活性和效率，依旧构成了重要挑战。这些挑战与大模型时代的关键基建、以及新出现的 Agent 技术相互交织，因此更需要思考如何让“旧知识”与“新范式”形成良好的衍生和融合。

如果完全不去学习传统知识，个人技术能力就容易被边缘化。真正的平衡点在于：既要尝试用旧的思维模式去思考能否做出新的事情，也要考虑新的范式是否能在旧的框架中带来新的突破。例如，在分布式系统中我们曾面临的难点问题，是否也会在 AI 框架下重现？如果能提前布局和准备，发展将会更顺畅。

在 MemOS 的实践中，我们过去关注的是整个系统算力的调度，包括 GPU 与 CPU。而现在，重点转变为如何做好模型记忆的调度管理。我们需要将参数化记忆、激活记忆和明文记忆视为新的“内存”或分布式存储要素，围绕压缩、更新与检索进行管理。这样一来，传统范式中沉淀下来的许多技术栈和方法，就能在新的场景下发挥作用并取得良好效果。传统技术积累并没有过时，而是需要在新的框架下实现“重生”。

云原生管理的是微服务，智能原生管理的是 Agent，但不管是微服务还是 Agent，都是一个大规模、高并发、高可用的分布式系统。你做的 Agent 应用，如果连基本的线程安全、高可用都保证不了，那下层的 AI 模型再智能，整个系统也是空中楼阁。我见过一些只懂 AI 的同学做的系统，逻辑很惊艳，但并发一高就宕机，或者出现数据不一致。所以，像 CAP 理论、Paxos/Raft 协议、服务治理、监控告警、性能优化这些基本功，在智能时代不仅没有过时，反而因为 AI 系统本身的复杂性和不确定性，变得更加重要，它们是作为一名优秀工程师的下限保障。

LLM 和 Agent 的“新知识”是你的增长引擎。 如果你只懂分布式系统，不懂 AI，那你最多只能为 AI 系统提供“水电煤”，但你无法设计和构建系统本身的核心价值，提升 Agent 的效果。你不知道用户的意图如何理解，不知道 RAG 的瓶颈在哪里，不知道 Agent 的工作模式。你无法和产品、算法同学在一个频道上对话，也就无法成为真正的架构师和技术负责人。上次我们内部一名同学分享 AI 应用的优化需要上下文工程 + 评测 + 数据 + 模型四位一体，那就代表这些技术都是需要了解的。这些新知识决定了你的上限和未来的可能性。

另外从学习路径这边看的化，我觉得首先是不用过度焦虑，现在有些同学感觉我现在没参与到 AI 中间件的建设，我就会落伍，跟不上时代，其实完全没有必要，现在还是很早期的一个阶段，大家保持跟进就可以了，甚至“后发”也可能有“后发”的优势。

不管是内功还是外功，我建议的学习路径都是一样的：

学习理论知识。

hands-on，不要光看文章和视频。用一些智能体平台低代码方式搭建 Agent，或者 LangChain + Deepseek API 去搭建下 Agent，亲手写一个最简单的 RAG 应用，比如一个能回答你上传的 PDF 文档内容的问答机器人。

实际业务解决问题，选择一个你最感兴趣的点，比如 Agent 的多工具协同、RAG 的评测和优化，去深入研究，同时，积极参与到相关的开源社区里去，看看大家都在讨论什么，遇到了什么问题，是怎么解决的。

尝试抽象公共服务，抽象通用组件，如记忆模块、模型路由、调度编排器，支撑不同场景应用复用。

新能力会过时，但学习方法、架构思想和工程方法论会伴随你一生。

宋顺：AI 中间件工程师是一个复合型角色：既需要理解分布式系统、数据库、网络等传统中间件技术，又要掌握提示工程、Agent 框架、RAG、多模态等 AI 新技术。我的建议是：“深耕老本事，拥抱新知识”。可以先从构建一个简单的 RAG 系统或工具调用 Agent 开始，逐步深入上下文管理、记忆模块、多 Agent 协作等复杂场景。同时，积极参与开源社区、关注行业动态，保持对技术趋势的敏感度。只有这样，才能在这个快速变化的领域中保持竞争力。

来源：极客邦科技