AI Infra 的一致性架构至关重要，API 网关、消息队列、可观测是 AI Infra 的重要组成。
各人好，我是阿里云云原生微服务技术负责人李艳林，我所在的团队是做云原生应用的架构、开发和运维的，并以开源和云产品的方式服务广大开发者和企业客户。随着大模型的流行，我们看到了越来越多 AI 原生的应用，因此做了非常多的实践。本日我将分享一些实践中的感悟。
AI 给业务带来了哪些变化？
AI 给应用和架构带来了哪些变化？
我们正在探索的实践场景。
AI 到底给我们带来了哪些变化？
工业化时代，我们利用工具解放了手脚，从忙碌的体力劳动中开释出来。大模型时代，我们利用 AI 开释了部分脑力劳动，从忙碌的重复劳动中开释出来。比方程序员群体利用通义灵码等智能编码助手，就可以搞定代码注释、单元测试，乃至一些简单的程序。
如今一些早期的程序员，包罗我在内，上大学的时候学的都是自动化，那时候的编程范式是面临机器进行汇编。我不知道本日来现场的人是否写过汇编，应该许多年轻人是没写过汇编的。
汇编就是人类用盘算机能辨认的语言和盘算机进行对话，但如今我们已经开始用天然语言和盘算机对话了，这给人机对话效率带来了革命性的改变，同时对程序员的思维模式也是一种改变。各人都知道，用盘算机语言和盘算机对话多了，本身的思考方式也会很盘算机，失去了生活的灵性，各人肯定听过不少吐槽程序员思维方式的段子。
以本身为例，我上大学的时候，讲成语是信手拈来，但工作了十年，如今连说个成语都费劲了。就是因为天天跟机器打交道，整个人都变得很机器了。但如果是通过天然语言进行编程，那就是驱动机器像人一样思考，机器会越来越靠近人的思维方式。比方我们对微服务进行拆解，拆解成订单服务、会员服务，是指令性编程，AI 时代就是声明式编程，只必要告诉盘算机你的最终诉求，而不必要思量过程指令。
前阵子参加了InfoQ 组织的 AI Agent 的小型交流会，各人讨论的焦点之一是我们当前是高估了 AI 的本领，还是低估了 AI 的本领。按我的实践来看，短期是高估了，长期是低估了。未来，AI 会进一步把我们从重复的工作解放出来，想象力真的是无穷的。
但是，为什么本日各人所期待的和当时 APP Store 出现时那样，AIGC 应用的蓬勃发展并没有出现？本质是 AI 的拐点还没有到。 第一个原因是大模型的理论研究还不敷透彻，深度学习网络仍是一个黑盒。 各人只是信仰 Scaling Law 会实现 AGI，不过这并不影响应用场景的落地。举个例子，汗青上我们在没有研究透火的原理之前，其实已经用火来推动了人类的发展历程了。大模型发展至今，已经在代码工程、客服、信息搜索、计划等范畴落地了大量生产场景。 第二个原因是算力限制和投入产出的考量。 我不知道本日在场的多少家公司买了 GPU，在大模型上投入了多少费用，但是产出是否能带来足够的经济效益。好消息是各个云厂商大幅低落了大模型的训练和推理成本，许多公司的 ROI 就立马转正了。另外，AI Infra 在资源利用率、研发效率、业务稳固性上的成熟度远不如云原生的这套底子设施，也缺少开源、商业产品等带来的最佳实践。比方用 GPU 每次调用做一次搜索区间的成本更高，这些都对拐点的到来会产生影响。 第三个原因是合规性、代价观对齐、算法偏见和公平性等的约束。 没有这些约束，大模型就会衍生出大量的社会问题、道德问题等。我们和做大模型落地的企业聊，好奇为什么你们在 AI 上落地了这么多场景，为啥外边看不到呢？原因就是要保证合规，放慢了应用上线的节奏。
GPU 和 CPU 正在相互融合，摩尔定律决定了 CPU 性能每两年提升1倍，但 GPU 的性能每两年能增加10倍。未来10年，GPU 性能能提升100倍，成本持续下降，如果每个手机都内置一个 GPU，在端上进行推理，那对 AI 的落地会是非常大的推进。在座的各位都见证了 CPU 给我们生活带来的变化，我信赖演进速度更快的 GPU ，会给我们这个时代带来更大的变化。
AI 给应用和架构带来了哪些变化？
有人会问，AI 时代，应用和应用架构发生了哪些变化，我们从下方这个图来看下演进过程。
左边是以容器、微服务、声明式 API 构成的云原生应用架构，这是当下构建在线应用的主流架构，好比电商业务、金融业务、SaaS 服务、社交应用、交通物流等，我想大部分企业都已经接纳了这套架构，或者至少已经有一部分业务跑在这套架构上。右边是以大模型、AI Agent、面临天然语言编程构成的 AI 原生应用架构，更大的概念是 AI Infra，接纳 GPU 资源进行模型的训练和推理，并以模型和天然语言为焦点，驱动业务发展，而承接端侧的流量，不再是一个个微服务，而是一个个 Agent，以后人手一个 Agent 的时代信赖离我们不会太远。整体上，我们以为基于大模型的 AI 原生应用将越来越多，容器和微服务技术为代表的云原生技术会加速渗透传统业务，并引入更多流量，催生企业新的生命力和想象空间。
那么 AI 原生应用架构有什么特点呢？ 以模型为焦点、Agent 进行驱动、面临天然语言编程为 AI 原生应用架构的焦点要素，“API First”、“Agent 编排” 、“消息解耦”、“AIOps”是架构 AI 原生应用的核生理念。
API First
第一是 API First，API 成为 AI 原生应用的一等公民。如今每家企业都做降本增效，降本很好衡量，就是用 IT 支出，减少盘算装备、提升算力利用率，优化数据存储，但是效率提升要用数字来做显性化衡量就比力难。我们实施敏捷开发的时候，会引入 DevOps、低代码、AI 编程，提效是提效了，但是怎样用标准化的方式来衡量呢？人均产出么？盘算方式过于复杂，口径不一，影响因子太多。
API First 在国外其实已经非常火、市场接受度也很高，因为以往在线应用都是通过 Service 对外暴露提供服务本领，但是基于大模型的 AI 原生应用将会通过 API 对外提供服务本领，因此，企业的数字化资产管理和上卑鄙生态，均会基于 API 标准来构建。但国内仍处于布道期，我们都是 Code First，前后端各自把代码写好，然后怼在一起，反复修改调试，协作效率不高，业务规模越大，技术债越重。API First 则是先界说好 API 规范，再 code，并能借助 AI 来自动生产代码、自动化单元测试，乃至包罗攻防演练的代码、前端代码等，都能自动搞定。API 界说世界，AI 生成世界，API 会成为企业的焦点资产，并作为衡量效率的标准化方式。
别的，大量的非 AIGC 应用比方物流系统、体育赛事、娱乐运动、气候信息等，作为 Agent 编排的被调用方，将加速把规范 API 计划提上日程，避免接口调用的兼容性问题，改变 Code First 的开发习惯、提升开发效率，融入 AIGC 大生态。
Agent 编排
OpenAI 的 API 日调用量已经超过国内一线互联网公司的日活用户数，但是本日围绕 API First 的后端协同还未发生变化。大部分企业仍然是用信息聚拢的方式，来提供搜索结果。当 API 成为企业服务用户不可或缺的方式后，将会产生大量的 AI 原生应用，对各家的 API 进行智能编排，提供更加智能的服务。因此，Agent 编排将成为 AI Engineering 范畴必不可缺的一环。
简单的场景只必要单 Agent，结合提示词优化和提示词模版就可以办理，但是比方 AI 工程师的场景，就必要多个 Agent 做编排和协同，以便于办理复杂问题。 从 Agent 角色上看，必要 PD Agent、研发 Agent、测试 Agent 等组合，才能做好协调，末了得到整体结果的提升。再举一个生活中的例子，我们要做一个团建筹划，如今的做法是小红书找旅游攻略，然后同飞猪去看火车票和机票，再找符合的酒店，还要去点评找饭店。以后可能只必要做好提示词工程，比方输入团建的时间、所在、人数，以及其他定制化需求（团建额度、表格对比输出…），就能直接给出团建方案了，乃至由 AI 以一问一答的方式来引导我们输入提示词，进一步低落天然语言对话的门槛。
Langchain 已经提供了面向 Python 开发者非常友好的 Agent 的编排本领，对于国内占比 65% 的 Java 开发者群体，我们将基于 Spring AI 帮助 Java 程序员快速把握 AI 编程本领。
消息解耦
以模型应用的故障排查的场景睁开为例，目前大部分 LLM 应用都是单体架构，提供独立的交互入口，虽然应用架构相比微服务简单许多，但是入口应用到后端应用和模型，失败率较高，排查代价非常大，缺少成熟的可观测技术和实践。 之前我拜访过一家大模型企业，他的报文非常大，日记经常打不起来。这里要是用 Java 那一套可观测体系肯定是搞不定的，因此我们正在开发 Go 和 Python 的 Agent 技术，去完善 LLM 应用的可观测生态。
API 网关
AI 原生应用，对网关的需求已经逾越了传统的路由和负载平衡功能，还必要为 AI 应用开发者提供便利，比方统一不同 LLM 提供商的 API 协议，并提供 API 编排、安全、稳固性和成本控制等扩展功能。因此 AI 时代，网关承载了更大的工程化使命，必要在网关侧做好 AI 场景的深度扩展和集成。
阿里云网关开源项目 Higress 升级为 AI 原生的 API 网关，提供了丰富的 AI 插件扩展 和 生态集成， 让开发者一键构建 AI 应用。Higress 在支撑通义、云产品 PAI 和百炼的过程中，积累了大量 AI 应用工程话的本领，下面我们将详细介绍。
上面我们讲了网关的 4 个典型场景，接着我们来看下 AI Proxy。本日搞大模型的公司毕竟是少数，更多的企业是基于大模型做应用的落地，去对接多个大模型，比方通义GPT、通义、另有 Google 的羊驼等。但是不同模型的通信协议是不一致，身份体系也不同。
第一类需求，以 Sealos 为例，他优先调用的是 GPT，次选是通义，利用 Higress 网关就可以在 GPT 调用失败的时候实现容错，来调用通义。第二个需求，许多大型企业主账号接入了大模型，给每个员工开通一个利用的子账号，并可以对每个子账号开放或屏蔽模型类型进行自由选择，同时提供体验一致、高可用的服务，这个就是通过 Higress 网关的统一身份的本领来实现的。
Spring AI
在中国，差不多 65% 的后端程序员都是搞 Java 的，我们在 Java 范畴也有比力深厚的积累。这里介绍下我们在 AI Agent 开发框架上的进展。左边是 Spring AI 最底子的模仿模型的对接部分，右边是 RAG 本领，最上面是 Spring AI 和 Langchain 的对比和差异，并通过 Langchain 组装不同的 Agent 进行协调，这些都已经开发完成，建议各人去 sca.aliyun.com 来体验下。
许多公司基于 Langchain 的链式本领已经可以做些拖拖拽拽、低代码的事变，像包罗阿里云的百炼，对于模型的训练、部署都是非常简单的。后续我们会把 AI 相干的更多工程化本领，通过 Spring AI 对接起来，方便广大 Java 开发者。
以上只是 AI 应用的应用架构视角，若从 AI Infra 的视角看，另有盘算、存储、网络、操纵系统等，这些构成了完整的 AI Infra，而 AI Infra 的一致性架构至关重要， 这里暂不睁开，网关、消息队列、可观测是 AI Infra 的重要组成。
我们正在探索的实践场景
基于 AI 的实践场景许多，选择哪个先落地的商业判定很重要。一类是只办理 50% 的问题，但是可用性 100%。另一类是办理 80% 的问题，但是可用性只有 60%，这是不同的选择。
举个例子，我们让 AI 把网关的插件全部写了，如果网关层出问题，这个锅是谁的？网关的容错性很低，现在这个阶段，显然是不能靠 AI 办理的。这就像汽车的自动驾驶本领，我明白很长一段时间内，都是起到辅助驾驶的功能。因此，我们更倾向于用 AI 办理的是结构性强、容错性高的场景。
所以我们优先上线的场景是在 Spring Cloud Alibaba 的官网，和通义深度集成，构建了一个 AI 答疑工程师。利用 Spring Cloud Alibaba 过程中遇到的开发问题或难题，都可以向这个 AI 答疑工程师进行提问，我们如今每天有几百个 ID 在和 AI 答疑工程师进行交互，问题的办理率可以达到 90% 以上。 然后，我们有一个后台能持续的去完善答案。有数据、有场景、能根据实际的反馈去完善答案，形成正循环。这就是一个真正管用的 AI 工具的基本三要素。
开发者 AI 答疑工程师，我们经历了 3 种选型。
