AI 原生应用开发实战营
内容分析：
1. AI 原生应用趋势和实践
2. AIGC 趋势下的智能编码探索与企业侧实践
3. 掌控你的 Java 智能体应用
01. AI 原生应用趋势与实践
首先，让团队来探讨一下什么是 AI 原生应用。
近年来，“原生”一词频繁出现在团队的视野中，比如云原生、移动原生等。原生一词本意指的是土著居民，它传达了一种天然和与生俱来的感觉。当团队说某款产品或软件是原生的，团队想表达的是这款软件或产品是专门为某一平台量身定制的，经过精心设计，能够充分发挥该平台的特点和优势。
为了更深入地理解原生的概念，团队可以从以下几个例子入手。以新能源汽车为例，原生在这里指的是能源的转变，即从石油能源向电能的转变。在电能的基础上，传统汽车的三大件——发动机、变速箱——都需要重新设计，转变为电机和电池。这样的转变带来了显著的改进，例如更佳的线性加速性能和更快的零至百公里加速时间。即便是普通的新能源汽车，其加速性能也能达到百万豪车级别的油车水平。此外，在充足的电能支持下，新能源汽车可以实现许多智能化功能。例如，自动驾驶技术的发展得益于各种智能化软件的集成，而这些智能设备通常耗电量较大。因此，在新能源汽车领域，这些技术的应用更为广泛。
同时，团队还可以进一步探索将生活场景融入汽车设计中。目前流行的做法是在新能源汽车上配备冰箱、沙发、大屏幕电视等设施。这些在传统燃油汽车上难以实现，因为传统汽车的电池容量有限，无法支持大量耗电的智能设备。今年，团队有一个客户希望将传统燃油车转型为车联网车型。在这种情况下，他对资源消耗特别敏感，甚至考虑延长车辆与云端数据传输的长连接心跳时间，以降低耗电量。其次，移动互联网在过去几年催生了大量移动原生应用。这些应用的基础在于其移动性，因此许多应用都基于地理位置信息进行开发和构建。例如，打车软件 UBER、滴滴，以及共享单车服务，都利用了地理位置信息。
同时，用户界面也从传统的 PC 大屏幕转变为手机小屏幕，采用触摸屏交互和语音交互方式，这催生了许多针对移动设备特性的应用。例如，游戏“愤怒的小鸟”通过触摸屏拉伸的方式完成游戏设计。移动通讯设备也针对这一特点进行了优化。此外，移动应用还利用了用户使用时间的碎片化特点，如流行的短视频应用抖音和快手，以及专为碎片化时间设计的游戏。以团队的推塔游戏《王者荣耀》为例，为了适应快节奏的游戏体验，团队缩短了英雄购买商品的时间，使得玩家可以随时随地进行购买。
此外，团队还加入了能够加速游戏进程的抢龙功能，使得一局游戏仅需 15 分钟即可完成。这些功能都是为了适应移动平台而设计的。作为技术开发人员，过去几年团队听得最多的一个概念应该是“云原生”。这是过去几年最热门的技术理念，其核心在于团队已经进入云计算时代，应当充分利用公共云上的基础设施，例如弹性计算和弹性云存储，如对象存储 EBS，来构建团队的应用。在应用层面，团队会引入容器化和微服务，以提高应用的弹性，提升开发迭代的效率和敏捷性。云原生进一步发展，实现了研发人员无需关注底层技术实现细节，运维人员也不必关心机器容量规划和规格购买，从而屏蔽基础工作，让开发人员能够更专注于编写业务代码，创造业务价值。
通过这三个例子，团队可以更好地理解什么是 AI 原生应用。AI 原生应用的主要定义是充分利用 AI 技术。在今天这个语境下，AI 可能更多地被理解为大型模型，如何充分利用大型模型的能力来构建团队的应用，在应用的技术架构和应用场景上充分发挥 AI 的优势。目前，AI 原生应用具有几个显著特点：
首先，其交互方式全面采用自然语言交互，无论是文本还是语音，都类似于人与人之间的交流方式，非常适合移动场景。
其次，AI 应用支持多模态输入，与传统应用相比，后者可能更多依赖于文本输入或语音输入。然而，AI 能够支持更广泛的图片、音频和视频内容。它的视觉功能与人类相似，具备听觉、嗅觉和触觉等多种感官，能够综合这些感官数据来执行相应的动作。
第三个特点是在响应客户请求的过程中，AI 能够基于动态模型推理，而非仅依赖固定规则的判断。传统应用编写时，用户购买商品的过程需要通过一系列业务逻辑检查，例如检查用户是否登录、是否有优惠、商品库存是否充足等，所有这些业务逻辑都被固化在代码中，使用大量的 If-Else 判断规则。而 AI 的应用则具有更强的泛化和动态能力，它不需要将所有逻辑固化在代码中。第四个特点在于 AI 原生应用与传统应用的不同之处。传统应用中，每次点击都是无状态的单次请求响应，而 AI 原生应用能够完成声明式任务。你可以直接告诉它你的最终目标，它会通过自主规划的能力，自动完成中间过程。例如，如果你想为女朋友购买生日礼物，传统方式需要自己做攻略，搜索灵感，而 AI 原生应用则能够根据你的消费特点、购买记录、消费能力以及当前季节和时尚趋势，直接推荐几款最符合你需求的商品，让你做出最终决策。
又如，使用支付宝的云小宝你只需告诉他你想回家和家的位置，它会自动规划并调用打车软件，完成打车过程。这些就是 AI 原生应用的主要场景特点。
接下来，让团队看看 AI 原生应用的几个常见应用场景。在 AIGC 早期，许多应用都是基于 AI 大模型的扩展，例如使用 stable diffusion 技术，可以创造出各种有趣的图片应用，如老照片修复、个人图片的卡通化、模特照片或视频生成等。在此基础上，还有更多专业、高效的图片工具，如孔发 UI 的流程式 AI 绘图工程，它将图片 AI 生成过程分解为多个流程，每个流程都可以进行更专业的设置，从而提高效率。
接下来，团队探讨一个场景，即通过先进的语音大模型实现声音智能体的应用。这种应用更贴近团队人与人之间的交流方式，尤其适用于移动场景。在实际应用中，它常见于与特定行业的结合。
这是一个面向特定行业的应用，比如知识问答系统。
这是一个智能账单助手的示例。通过自然语言交互模式，团队可以轻松获取个人账单情况，并快速生成。正如团队所见，这种智能化的 AI 助手使得个人消费者能够轻松查询消费记录。
例如，支付宝推出的类似功能，你可以询问上个月的消费情况，系统会自动为你生成上个月的消费分布图、饼图、统计图，以及与去年同期的比较变化图，为你提供一份详尽的个人账单。同时，这种 AI 助手也可以作为企业或政务智能客服，帮助用户更高效地获取政务信息。此外，它还可以作为数据 BI 工具，帮助经营者快速分析商品销售数据，比如同比增长率等。与以往通过 APP 或网站层层点击菜单目录结构寻找信息的方式相比，AI 技术能够帮助个人消费者和经营者更快地获取所需信息，通常只需一两层交互即可。
在第二个场景中，团队将探讨一些与企业应用培训相关的案例。以汽车销售行业为例，培训师可以利用 AI 技术将培训资料上传至知识库，并利用 AI 的多引擎能力创建多个 AI 引擎以协助进行更高效的培训。例如，某些 AI 引擎可以模拟消费者与销售人员进行对话练习，而其他引擎则可以协助规划培训内容，甚至扮演教师角色。通过这种方式，企业培训的效率得以显著提升。培训师可以根据销售人员的能力特点，针对其薄弱环节提出更多问题，实现个性化教学。这种方法同样适用于在线教育行业，通过 AI 教育应用帮助学生提高学习效率。团队不再盲目进行题海战术，而是根据学生的需求提供有针对性的指导方案。这是 AI 应用场景的一个扩展和延伸。
接下来，让团队探讨 AI 应用场景对应用架构带来的变化。
以微服务应用为例，过去团队通过将业务划分为商品、购物车、交易、物流等不同领域来处理客户请求。这些微服务在处理请求时，会进行业务逻辑的检查和判断，或者通过中间件、消息队列或 RPC 调用其他微服务。业务逻辑处理完毕后，还需要执行持续化操作，如创建订单。在传统应用场景中，请求处理时间相对稳定，通常以毫秒计。
在 AI 原生应用中，团队引入了大型模型，并将算力从 CPU 转移到 GPU。团队围绕大型模型构建基础设施以支持 AI 应用。在过去的两年中，团队还发展出多种新的 AI 架构方式，如 rig 架构、引擎工作流以及推理行动架构。这些架构中经常使用向量技术，它已成为 AI 多模态统一语言的基础。向量技术能够将文本、语音、视频等通过统一语言表达，并进行相似度查询等操作。这也使得向量嵌入和向量数据库成为 AI 应用的关键存储技术。
除了引入新的架构范式外，AI 原生应用还使整个应用的异构性增强。在传统微服务场景中，每个调用的响应时间相对稳定通常以毫秒计。但现在，随着推理链路的引入，即使是较短的链路也可能需要几秒钟，而处理长文本、图像、音频、视频等复杂内容可能需要几分钟。这导致请求处理时间的方差增大，耗时更长。同时，由于请求已经跨越不同的算力模式，整个链路的观测变得更加复杂。连接模式已经从传统的短连接转变为以长连接为主，这主要是因为广泛采用的 cheat 模式应用。这种转变对团队的应用架构产生了一定的影响。
接下来，让团队探讨一下目前几个主流的 AI 架构范式。其中一种应用广泛的范式被称为检索增强生成。其核心在于，尽管团队的大型模型拥有丰富的业界常识和公开信息，但这些知识和信息可能已经过时，比如两年前的数据，因此不够新颖。这会导致团队在推理时产生许多幻觉。通过检索增强架构，团队可以将新鲜的企业专属数据通过向量化（embedding）技术存储到向量数据库或搜索引擎中。在用户向大型模型提问之前，团队先对问题进行查询，检索向量数据库或搜索引擎以获取相关上下文信息。然后，结合问题和上下文信息去查询大型模型，从而返回一个更准确的结果。这样，大型模型的落地应用将具有更好的可定制性，能够适应不同行业的需求。同时，它的准确性也更强，避免了不切实际的胡言乱语。此外，它还提高了可解释性，即在回答问题时，可以将问题依据的链接包含在回答内容中。与微调技术相比，检索增强架构具有更低的成本，更易于实施，资源消耗也更少。
接下来要介绍的是过去一年中最热门的架构方式之一，名为 Agent 。这是一种基于大型语言模型构建的智能体，它拥有环境感知、自主理解、决策执行以及行动的能力。以一个例子来说明：假设用户向机器人提出一个问题，如果明天天气不佳，请给我一把伞。在这种情况下，机器人需要进行推理，判断明天的天气状况。首先，它会通过多模态输入感知当前环境，包括空气状况、温度、湿度等。如果这些信息不足以作出判断，它还会利用工具从互联网上获取信息，比如查询天气预报。通过这些信息，机器人可以构建出推理的小前提。基于这些前提，它会做出判断。如果判断结果是明天天气不佳，机器人就需要调用相关的硬件设备，将伞送给用户。可以这样理解：原本团队的大型模型只是一个大脑，它更多地进行快速思考，例如回答明天天气如何、总统是谁等问题。而 Agent 架构的智能体则逐渐具备了类似人类的慢思考能力。当你向它提问时，它不会立即回答，而是经过类似人类的推理和规划过程，主动查询网站信息，综合各种前提条件，最后得出推理结果。通过 Agent ，大模型能够真正作用于物理世界，成为连接模型生产力与真实应用场景的桥梁。第三个范式是，随着 AI 应用的复杂性增加，通常会涉及多个智能体的协同工作，整个流程变得更加复杂。
因此，出现了 AI 工作流，它提供了一种流程式编排智能体的能力，能够动态地增强业务的扩展性。在 AI 应用开发和业务迭代的过程中，能够灵活地加入新的节点，例如，引入一个新的智能体来承担新的任务，或者调用外部工具来扩展 AI 应用的能力。这不仅提升了多智能体的协作性，而且通过流程编排和意图分类，使得整个 AI 应用的处理过程具备更好的可控性。它本身也是一种拖拉拽式的低代码开发方式，可以显著提高开发效率。这里展示了一个工作流的简单例子：一个家电导购应用。它由不同的智能体组成，包括电视导购员、冰箱导购员和手机导购员。当用户提出具体问题时，意图归类会将问题分发给相应的导购员。这些导购员拥有对各自类目最完整的知识，并且团队可能会为他们提供一些提示词，对类目进行优化，使其能够更专注于问题，为用户提供更专业的答案。这类似于人类世界的分工，随着协作越来越精细，每个人都能在其擅长的领域发挥专长，再通过全局的规划和组织，提高整体运作的效率。目前，大多数智能体构建平台都提供了类似的工作流引擎，这些工具能够快速构建 AI 应用。
接下来让团队深入了解阿里云中间件如何助力 AI 原生应用的演进。
阿里云中间件产品家族的核心目标是加速 AI 原生应用的工程化落地。首先，团队有 AI 增强型网关 Higress，它提供多种 AI 插件集，并针对大型模型服务进行增强，以实现 AI 大型模型与网关的便捷集成。其次，团队有 Nacos，众所周知， Nacos 是微服务配置管理工具，而 Nacos 能够为 AI 应用提供更高的灵活性。此外，阿里云的可观测性工具能够将 AI 大型模型推理电路的请求过程与传统应用请求过程串联起来，提供端到端的观测数据。
此外，团队的 Apache RocketMQ 为 AI 应用提供事件驱动架构的基础设施。至于中间件的核心，团队的 Spring Cloud Alibaba 与 Spring Boot 和 Spring Cloud 体系兼容，旨在帮助 Java 开发者。鉴于 Java 语言目前在中国是最主流的编程语言之一，而 Spring 框架是团队最广泛使用的编程框架，因此 Spring Cloud Alibaba 的目标是帮助这些 Java 开发者快速转型到 AI 应用开发，并使现有的 Java 应用能够平滑演进到 AI 应用，赋予它们 AI 能力，充分利用现有的代码资产。
目前，Spring Cloud Alibaba 还提供了面向 AI 编程的多种抽象层次的 API，包括一些基础的 API，如提示词模板函数的调用，以及一些高级的 API 抽象，例如 Cheat 的 Client 模板和 RSocket 架构等。总体而言，它与 Spring Cloud Alibaba 的其他云原生基础设施进行了整合，既包括团队原有的中间件系列，也包括团队阿里通用的大模型。可以认为，它是阿里云中间件与统一大模型结合后，为 Java 开发者提供的面向 AI 的最佳实践解决方案。
接下来，让团队逐一探讨这些不同中间件在 AI 场景中的具体演进。首先，团队来看看 Higress 的 AI 增强型网关。它主要为 AI 做了哪些工作？首先，它支持大模型的适配，可以作为各种不同大模型的前端网关。目前，团队已经支持了业界主流的大模型供应商，包括同为前文、OpenAI 等。此外，它还支持面向大模型的调度策略。由于不同大模型的请求可能耗时和资源消耗差异很大，团队提供了基于最小请求负载的均衡模式，以尽可能最大化每个模型实例的利用率。
另一方面，团队支持众多 AI 插件，典型的例子包括 AI 缓存插件，它能够在网关前端缓存 AI 结果，提高应用性能。团队支持同步缓存和流式输出缓存。还有提示词模板嵌入工具也包含在内。同时，团队还有一套面向 AI 的安全防护措施，例如揭露阿里云的安全检测，确保大模型的输入输出合法合规。团队揭露了过滤关键词的过滤机制，能够替换输入输出过程中的敏感词。此外，团队还支持基于请求的限流和基于 token 的限流，帮助应用更好地管理 token，避免账单出现不可控的情况，同时防止 AI 应用因请求过多而崩溃。
另一方面，正如之前提到的，AI 应用在数据链路连接模式上更倾向于长连接。因此，团队的 Higress 网关也支持长连接的热更新模式，以提升用户体验。
第二个是团队的阿里云可观测性中间件，包括阿里云的 ARMS 和链路追踪的 OpenTelemetry。团队遵循 OpenTelemetry 的规范，兼容各种业界主流的 AI 模型和框架，如 TensorFlow 和 PyTorch 等。团队可以监测整个 AI 推理链路，包括推理过程和资源消耗，实现全链路的呈现，帮助 AI 开发者更好地定位问题。
第三个是 Nacos，其核心是提升 AI 应用和 AI 引擎的灵活性。AI 应用通常涉及提示词工程，提示词模板在迭代过程中可能需要持续优化。 Nacos 可以为提示词模板提供动态更新的手段。AI 应用涉及内容的输入输出，因此经常会有新的法规政策和关键词出现。通过 Nacos 团队可以进行动态管理和替换，核心是提升 AI 群组的动态配置管理。
最后是团队的 Apache RocketMQ ，其核心是作为 AI 原生应用的事件驱动架构基础设施，可以提升吞吐量和实时性。如下图所示，消息队列通常是各种实时数据源的第一入口。通过一站式实时数据事件流处理，团队可以将交易事件、支付事件、智能物联网设备传感器事件、航班动态信息、车联网数据以及数据库变更事件等实时嵌入到搜索引擎或向量数据库中，使 AI 推理验证能够获取最新鲜、最准确、最具个性化的信息，从而提升 AI 应用的准确度。
第二个方面，AI 应用涉及异构系统，整个请求链路更加复杂，包含许多快慢服务的结合。在这种情况下，异步通信方式更能提升用户体验和系统吞吐量。通过引入消息队列进行异步解耦，可以提高业务敏捷度，降低代码依赖性。同时，它还可以使传统应用中更新的 AI 应用更好地协作。对于异构系统而言，消息队列可以实现经典应用与 AI 应用的有效解耦。
第三点，消息系统实际上具备负载均衡功能，包括生产者和消费者的负载均衡。AI 应用的一个显著特点是请求耗时差异大，且每次请求对资源的消耗也不均衡。在 RocketMQ 中，团队提供了一种主动的消费模式。在消费过程中，团队可以动态设置消费超时时间。通常，标准消息队列都有固定的消费超时设置，但在 RocketMQ 中，消费超时时间是动态调整的。如果你在请求某个推理链路时发现耗时过长，可以动态延长消费超时时间，避免消息被重新推送，从而减少重复推理。
此外，由于是主动消费模式，消费者可以根据模型实例的当前负载情况和推理请求的特点，实现自适应的负载均衡。未来，团队还计划支持优先级队列，以满足推理任务的优先级调度需求。
第四点，AI 应用场景特别需要弹性，因为它具有显著的潮汐效应和多模态特性。有时，面对低 QPS 的视频请求，有时面对高 QPS 的文本请求，团队的 RocketMQ 采用开源的存算分离架构。在此基础上，团队构建了类似消息服务，提供了多种全模式的消费能力。团队提供零门槛的按消息累计条数付费模式，例如 100 万条消息仅需两元。如果流量比较稳定，可以按规格预留并结合弹性模式使用。对于需要进行运营活动的 AI 应用，还可以通过定时弹性功能提前调整规格。总的来说，通过事件驱动架构，团队可以提升 AI 应用的吞吐量和效率。
接下来，让团队结合一个实际案例来讲解 AI 原生应用的实践。这是一个声音智能体应用，能帮我播放一下吗？在下面有一个按钮，点击即可。
这是一个结合事件驱动架构和声音智能体 Agent 的例子。应用系统通过发布事件来通知其他组件，实现实时对话和数据的实时更新。
“抱歉，我的数据尚未包含您提到的信息。我想提出一个最新的问题，集中在事件驱动的最新问题上回答。如果还是无法回答，可能涉及几个方面，但并未提及阿里云在人气大会上发布的具体支持 AI 原生应用的产品列表。如果您能提供更多关于大会的具体内容，或者有其他相关问题，我很乐意为您提供帮助。”
接下来，团队会向系统灌输一些实时数据，这样它就能了解当前的新品发布情况，提供更好的回答。这边模拟将数据上传到对象存储，它会自动更新到团队的向量数据库。
接下来，他将能够提供一个更加精确和实时的信息：“在云栖大会上，阿里云发布了哪些支持 AI 原生应用的产品。”“阿里云在云栖大会上推出的 AI 原生应用支持产品包括 ABSUR-ROUNDSERVERLESS 系列，其中包括但不限于 ABSUR for RocketMQ Serverless、ABSUR for CPCake Serverless 以及轻量级消息队列原 MNS。这些产品旨在通过创新的思维模式，提供弹性的消息处理能力，特别适合于快速开发和应对安全问题。”
实际上通过试验驱动，团队可以主动提问，以增强智能体的能力，使其更像一个人，并能够实时更新数据。另一方面，团队可以通过各种事件驱动的架构来扩展实时触发的场景，这是 VoiceAgent 的一个事件驱动架构图。
图中，一个 RTC Server 负责实施语音通信，能够进行声音到文字的转换，在其后端调用团队的 AI 中间层服务。在这个中间层服务中，团队会使用许多 AI 原生架构的范式，如规则推理范式和行动推理范式。背后是封装的 AI 大模型，包括统一的大模型和语音大模型，以及对数向量数据库的调用。底层则是团队的事件驱动架构服务，包括 LOCMQ 和事件总线，以及函数计算。接下来，团队可以有多个试验员来执行事件驱动架构的触发。例如，团队有一个数据触发器，可以定时更新一些数据；另一个是手动上传对象存储文件，通过事件驱动架构实时更新团队的知识库。还有一种情况是在应用过程中实时产生的事件，如航班延误事件，这些事件可能原本就在团队的业务系统中的某个微服务里发出，此时这些事件也可以触发更新团队的实时数据库。还有一种情况，例如团队利用事件触发机制来唤醒商机。当用户触发特定事件时，系统可以主动唤醒商机，比如询问用户是否需要安装服务或复购产品。此外，团队还可以手动触发事件，主动向用户提出问题。这正是团队实时事件流平台纽瑞格的设计理念。
基于 Locking Imp，团队实现了 Event Streaming 功能，通过连接 Source Connector，可以接入各种实时数据源，包括消息数据、对象存储数据或 Blog 数据。在数据转换和 Embedding 过程中，团队可以动态调用函数计算，用户能够灵活定义所需 Embedding 的字段。通过这些步骤，团队可以实时地将数据存入向量存储，完成实时事件流的架构。今天的分享就到这里，感谢大家的聆听。
02. AIGC 趋势下的智能编码探索与企业侧实践
尊敬的各位老师，大家好！我是通义灵码的产品解决方案架构师李婷玉。今天，我将与大家分享的主题是“AIGC 趋势下的智能密码探索以及企业实践的最佳案例”。
团队灵码的产品实际上是在去年 10 月份的云栖大会上推出的一款基于大模型的智能编码助手插件。
这款产品的宗旨是帮助工程师解决 70%的事务性工作，使他们能够将更多的精力投入到原本可能只占 30%的价值创造活动中去。
为什么会产生如此多的事务性工作？
这可能源于团队日常编码场景中的一些痛点。这些痛点包括编写大量相似类型的代码、编写单元测试、编写代码规范，以及在编写 API 脚本时需要到互联网上查找相关的 SDK 或 API 接口规范。遇到报错时，团队还需要根据报错内容到互联网上查找相关资料，而这些资料可能并不总是可靠，需要人工方式进行判断。这些场景都会大大降低团队日常编码的效率。
因此，团队将开发者的诉求总结为四大方面。首先是使用通用灵码来提高编码效率，例如在编写代码时可以根据注释自动完成代码补全，遇到问题时可以利用灵码的问答功能提供相应的报错优化或解决方案，从而提高问题解决的效率。
第二方面，由于团队日常的编码工作习惯于在 IDE 上进行，因此灵码也是一款基于 IDE 的编码助手插件。无论是代码补全还是问答，所有工作都可以在 IDE 上完成，实现沉浸式的编码体验。
第三方面，重复性代码编写、单元测试生成、代码注释生成等，许多企业都在采用多语言架构的应用。不同语言的转换工作可以借助灵码来辅助完成，这样工程师们就能将更多精力集中在更上层的技术优化工作或业务架构设计上，更加专注于技术设计本身。
针对这三大诉求，灵码的核心能力可以分为三个主要部分。首先是代码的智能生成，可以在代码文件中根据注释完成初级和高级的代码补全，并在问答面板中根据自然语言进行操作。团队还接入了千万级的 VR 模型，支持图片识别，实现图文代码的转换。团队可以利用圈学工具，一键生成代码文件中类或方法集的单元测试用例。此外，对于代码片段，团队也能一键生成代码注释并插入。面对复杂的代码，团队可以借助代码解释功能，将代码以自然语言的方式转换。最后，在编写完代码后，团队还可以利用代码优化功能，检测代码问题并提供优化建议。
第二部分是问答功能。在编码过程中遇到任何问题，都可以在问答面板中提问。它背后依托千亿级的问答模型理解，并结合互联网实时排名能力，将问答准确率提高到 90%以上。其次，团队有一个 At Work Space 命令，它可以根据你打开的工程进行提问，例如理解整个项目架构或进行方法查找。第三，结合企业级的 Rag 能力，团队可以在灵码企业后台创建知识库，上传相关文档或代码。之后，在问答面板中，团队可以使用井号键 Team DOS 的方式提问，回答时结合上传的文档进行回答。第四，团队可以在问答面板中使用 At Terminal，它是一个脚本命令生成器，可以生成例如 Git 脚本或运行在终端上的脚本命令，帮助团队进行代码服务。第五，在 Debug 场景下，特别是在 ID 上，团队可以进行一键智能排查。在终端上，如果有报错日志，点击灵码标识，可以一键唤醒面板，在面板中根据报错内容给出相关代码优化建议。最后，无论是问题还是报错截图，都可以在问答面板中输入，系统会进行识别并提供相应的解决方法。
第三部分主要介绍如何将灵码企业后台与团队的系统相结合，实现企业需求。首先，企业可以通过后台批量授权账号，并基于这些账号生成报表，以查看灵码在企业中的使用效果。其次，企业可以整合内部的个性化数据，如文档和代码片段，构建企业知识库。第三，针对企业的特定研发场景，企业可以自定义旁提示词，创建相关的问答任务。例如，灵码背后的单元测试、代码注入、代码解释和代码优化等功能，都是通过封装好的提示词实现的。同时，团队开放了提示词编写权限，允许客户进行自定义。最后，团队在公共云上推出了公共云的企业专属版，采用 VPC 技术实现物理层面的网络隔离，并支持通过私有网络访问灵码服务。
在核心能力方面，灵码的解决方案分为两个层次。底层是基于千万闭源模型的大模型，团队采用代码专项的语料，包括中英文技术文档、开源的 Github 代码数据库和通用研发知识，进行代码大模型的调优。背后有补全模型和问答模型，参数达到千亿级和千万 Max 级别。由于接入了 2.5 模型，上下文宽度已从 32K 提升至 128K，进一步放宽了限制。
上层则是插件技术，包括问答意图识别和用户使用习惯学习。在代码补全时，插件具备跨文件上下文感知技术，并采用缓存机制，不仅基于当前代码文件，还考虑整个工程中相关的代码片段，如 Java 中的 Import 语句和其他文件，作为上下文输入。最后，团队在插件中封装了 Prompt 提示词，使灵码更深入地理解编码场景。在安全方面，团队提供加密链路以确保用户数据和内容的安全。接下来，让我为您详细介绍灵码的核心功能。
首先，团队有一个代码补全功能。在编写注释后，只需按一下 Enter 键，系统便能根据注释和相关代码片段自动补全代码。如果您认为补全结果符合预期，可以按 Tab 键一键采纳。
其次，您可以在问答面板中提问，无论是自然语言描述还是上传设计图或错误截图，系统都能根据这些信息生成代码或提供解决方案。
第三，通过选择代码文件中的代码片段，您可以一键生成相应的代码注释。右上角的快捷键可以用来对比注释或一键插入。第四，对于复杂的代码，您可以使用代码解释功能，它能将代码转换为文字描述，并生成流程图和 UML 图。单元测试方面，通过选择代码文件中的类、方法或代码点右键，您可以一键生成相关的单元测试用例。右上角的快捷键还可以实现一键保存。
编写完代码后，您可以利用代码优化功能，它能检测代码中的问题，如语法错误、安全漏洞和风格问题，并提供优化后的代码示例。遇到问题时，您可以在问答面板中提问，系统将提供相应的解决方案和思路，从而提高问题排查的效率。
在 EDIT TERMINAL 中，团队能够生成终端运行所需的命令，并能够创建相应的 脚本或其他脚本代码。在进行代码提交时，团队会生成 Commit Message。使用灵码插件，它可以根据提交内容自动帮助生成相关的 Message。未来，团队将支持一系列模板，以便按照企业自有的提交模板来生成 message。
总的来说，灵码的产品亮点和优势首先体现在其交互性上，团队致力于适配各种 ID 的交互，并提供原创视觉体验。团队的目标是不干扰、不等待开发者的日常编码工作，让开发者能够沉浸在编码体验中。其次，补全是团队的重点之一。为了提高补全的准确性，团队进行了跨文件的查询和感知，从而生成更符合当前代码库工程场景的代码，进一步提升代码的可读性。第三，团队在底层模型调优时，会利用阿里云的一系列文档，包括 SDK 和 API 规范文档进行优化，因此团队的代码生成和问答对阿里云的云服务场景更加友好。第四，在安全层面，团队提供加密的链路传输，支持用户身份验证和安全防护网，以确保企业数据的安全。在整个推理过程中，代码数据不会存储在磁盘上，这进一步保证了企业数据的安全性。团队在官网上也有明确的隐私协议，对相关承诺进行了详细说明。
最后要介绍的双模引擎号，涵盖了团队所见的代码补全模型和研发问答模型，它们统称为云端大模型。这意味着团队的电脑需要联网才能使用这些功能。然而，当团队在电脑上安装灵码这个小插件时，它会自动在每台电脑上安装一个小模型，即本地模型。这是灵码自研的，其参数大约为零点 XSB，占用的内存大约在 300 到 500 兆之间。它主要解决的是单行场景下的代码补全问题，使得用户即使在离线状态下也能使用，以满足不同网络环境和补全强度的产品需求。
从技术层面来看，团队拥有整个工程的跨文件相似代码感知能力。在进行代码长度判断时，团队会基于语义理解进行自适应生成，六角色会根据当前的语法位置，例如我是一个大类、类中的一个方法，或是单行场景，来进行判断，从而自动控制生成代码的长度。这样的交互性更加符合团队的日常使用习惯。其次，团队结合了企业级的 RAG 能力，可以结合企业的个性化文档或代码进行相关回答。大部分问答功能背后是千亿级参数模型，结合互联网的时 Rap 能力，可以大幅度消除某些幻觉。从性能和兼容性来看，团队不仅提供公共云模式，还支持私有化和本地化部署，以适配各类英伟达卡，如 V100 A100、国产 CPU 卡如海关 AI100 卡，以及华为升腾 910B 和寒武纪系列卡等。以上就是灵码插件的一些功能介绍。
第二部分主要围绕企业个性化场景。团队有企业后台的几大核心能力，主要从企业个性化数据、企业研发场景、企业管理本身以及企业非常关注的安全合规方面进行适配。
首先，团队来看企业内部的一些个性化研发场景。企业中会有一些个性化数据，如个性化的代码规范文档、API 规范文档，以及企业沉淀下来的个性化代码框架或组件。通用模型在大模型调优时无法获取这类个性化语料，因此其回答效果往往不符合预期。因此，团队提供了一种外挂方式，即在企业后台创建对应的知识库，上传文档或代码片段，后台会自动进行向量化，形成文档向量或代码向量，并存放在外挂的向量数据库中。
在进行推理时，一方面，团队会从通用模型中进行相关语料的召回；另一方面，也会从外挂的向量数据库中进行文档或代码向量的召回，使得生成结果更加贴合企业的业务场景。场景主要分为两大部分：首先是问答场景。这包括结合企业内部的文档手册、个性化的 API 开发文档以及企业内部规范文档进行代码优化建议。还包括根据样例规范生成相应的代码示例。
这些主要在问答面板中使用井号键 Team DOS 方式进行提问。第二主要是在团队代码的补全时候就是在团队代码文件里面通过安测方式去做代码生成，团队主要负责上传相应的代码片段，他们可以仿照或改写现有的代码逻辑，以生成相关的业务逻辑代码。
此外，团队成员还可以利用我们自主研发的代码框架来实现代码的自动生成，并且按照团队既定的规范来执行代码编写工作。其背后的工作原理主要是基于注释的相似性来召回相关的代码向量。在企业内部以及团队自身的应用效果来看，首先是在团队自主研发的前端组件场景下，我们发现AI生成代码在企业中的占比可能达到30%，在监督学习方面甚至可能超过30%。
然而，在JavaScript和TypeScript这类前端语言的代码生成中，占比最高仅为20%。这是由于前端开发中常常会用到一些自研组件，因此团队必须通过外挂方式来实现这些组件的集成。团队通过使用自主研发的前端业务代码库，上传并生成代码文件后，能够结合上传的业务代码进行智能推理。例如，采用团队的 rag 技术，可以将前端语言如 Gsts 的采纳率提高八个百分点。
其次，在后端领域，团队主要关注代码的召回率，通过分析注释，实现代码向量的高效召回。目前，召回率已达到约 0.91。此外，在问答面板中，团队可以利用 @ work space 进行本地工程问答，或使用井号键，Team DOS 方式从企业知识库中上传的文档中进行文档召回。召回率约为 0.918，满足了团队的召回需求
同时，团队结合企业个性化数据，针对企业内部特定研发场景进行优化。例如，在代码优化时，团队可以依据企业内部特定团队或部门的代码规范进行优化任务。在生成代码注释时，团队可以使用部门内部的注释模板进行个性化生成。通过企业级别的定制任务，团队可以扩展其功能。
以 Java 为例，团队可以在提示词中编写规范要求，辅助模块化代码生成，帮助进行变量命名，以及上传第三方 API 接口规范，根据团队的接口规范生成相应的 API 脚本。最后，在进行代码优化时，团队可以根据特定行业或规范场景，在提示词中直接编写相关规范。在进行代码优化时，我们可以依据企业团队内部的自定义规范，执行相关的代码检测。在下一个版本中，团队的 Power 命令将支持脚本方式提供服务，脚本中可以利用 API 与团队知识库中上传的代码规范文档进行对接。由于这些规范文档可能内容庞大，我们可以通过脚本辅助进行细分。
这是团队在后台自定义指令的示意图，操作简单直观。创建后，直接在其中编写相应的提示词即可。首先，我们结合企业个性化场景进行优化，其次，从团队企业管理角度出发。
团队可以在灵码企业后台进行专属账号集成，该后台目前支持公共云上的企业专属版和私有化版。通过团队后台，我们可以与内部用户 SS 进行集成，例如实现 LDP 协议或奥斯协议的直接对接，以便使用企业内部账号登录灵码。其次，团队可以在灵码企业后台进行批量授权管理。
基于这些授权，团队提供可视化报表，以查看灵码的使用效果，主要指标包括 AI 代码生成函数的占比、团队补全场景下的采纳率以及各种问答任务的使用次数。报表支持企业维度和部门维度，并可通过 API 获取个人使用数据，以优化效果提升措施。
第三部分是企业非常关注的安全合规层面。首先，团队针对公共领域层面上的代码安全隐私进行保证。团队的推理电路分为两个端，在每个人的 ID 上插件，即本地客户端，进行补全或问答时，需要获取相关代码片段以提高补全代码的准确性。
这些片段会经过预处理和加密，通过 API 调用大模型层进行推理问答，并将结果返回给客户端。整个推理过程中的代码数据不会存储，确保了团队企业数据的隐私安全。结果产生后，相关的代码上传片段会立即销毁。此外，团队在官方上有一个明确的隐私协议，从法律层面进一步保障企业代码的隐私权益。在团队企业内部，对于敏感信息的处理，底层大模型集成了阿里云的滤网产品，能够有效过滤涉黄、涉政、社恐等通用敏感信息。然而，在编码场景下，例如将配置文件存放在代码库中，这些文件可能包含认证信息和密码，企业希望在本地就直接过滤掉这些敏感信息，这实际上反映了企业信息安全合规的要求。
在这种情况下，团队可以在企业后台设置正则表达式，根据这些表达式进行企业级敏感信息的拦截。此外，如果团队拥有安全平台，装饰板支持以自定义脚本的方式与团队企业内部的安全平台对接。这样，在安全平台上可以设置更复杂的过滤逻辑，以满足团队企业内部对敏感信息规则的需求。
在一些大型企业中，可能有安全内容审计的需求，需要了解每一次推理的问答和结果。同样地装饰板支持以自定义脚本的方式与团队企业内部的安全平台对接，实现对推理利用的监控，将每次对话记录发送到安全平台上，便于进行日审计等操作。企业可以自定义这些安全措施。第三，团队的公共人员方面，除了企业标准版，背后是 SARS 型产品的数据库逻辑隔离，还有企业的专属版。专属版的原理是在云上建立一块 APC 实例，实现企业专属阶段的物理层面上的网络隔离。同时，由于团队是基于云的 VPC，它可以通过 PFLINK 的方式与用户的 VPC 实现四网互联。用户在阿里云上的 VPC 可能已经与本地内网通过专线或 VPN 连接，从而可以通过内网方式访问灵码服务，进一步确保团队访问内容的安全。在团队背后，支持 SSO 集成，进一步保证企业内部自有认证体系的整合。同时，团队在进行 RAG 时，相关的向量存储可以放在团队自有的 VPC 实例上，也可以接入到团队企业内网中的 OSS、ES 服务上，将企业存储服务放在团队内网上，进一步确保对安全敏感的企业需求得到满足。在团队的公共推理集群背后，我们致力于结合百炼技术，开发出专属的 SFT 模型。通过 SFT 训练，企业可以拥有专属的调用模型，并将其部署在 VC 上，实现物理层面的网络隔离。
实际上，团队在企业公共网络上推出了专属的解决方案，以进一步确保企业内部的安全合规要求。以上所述，即为团队在企业特性上所展现的个性化能力。最后一页，我们将解答企业场景下极为关注的问题：我的 IOI（输入输出比）是怎样的？实际上，这是一个非常简单的换算公式：35%代表 AI 代码在企业版后台的上升占比。
这个指标在每个企业版后台都有直观的数字显示，一般保持在 30%左右，阿里云内部也是如此。我们采用 35% 这一较优指标进行计算。另一个数据 32% 来自官方统计，指的是开发者在工作时间中编码所占的比例。其他时间则用于开会、答疑等。将这两个数据相乘，即 32% 乘以 35%，我们得出团队成员的工作时间大约节省了 11%。团队认为，个人研发效率的提升与其工作时间的节省密切相关，因此个人工作效率大约可以提升 11.2%。在阿里内部，提交数据也大约是 10%。
通常，通过编码助手，效率提升大约在这个范围内。在实操环节，团队还将展示 AI 程序员的能力，这是团队最近上线的新功能。与灵码插件不同，AI 程序员可以从整个工程的角度出发，对多个文件进行代码生成。其背后是智能体的概念，能够组装多个步骤，以应对更复杂场景下的代码生成。在后续的实操环节，团队将向大家展示 VS Code 以及尚未上线的 AI 程序包。大家可以体验这些工具，并通过钉钉扫码加入团队的用户群。
在用户群中，团队的研发和产品人员将回答相关问题，日常疑问也可以直接在群里提出。在通信领域，个人版目前正处于限免阶段，只要拥有阿里云账号，大家就可以直接使用。团队和企业版的标准将提供一个月的免费试用期。如果大家感兴趣，也可以使用团队或个人的阿里云主账号去开通灵码企业版进行测试，体验团队和企业场景下的个性化功能。
03. 掌控你的Java智能体应用
今天非常荣幸能在这里与大家分享关于 Spring AI 阿里巴巴项目的一些细节，以及如何构建 Java 智能体应用和实现可观测性。
目前，我是 Spring AI 阿里巴巴项目的 PMC 成员，主要负责项目中的性能测试工作。同时，我也是阿里云 Java 和 Go 语言无侵入式探针的维护者。欢迎大家了解我今天要分享的主要内容。
首先，我想带大家回顾一下从 2022 年底团队发布 ChatGPT 3.5 到现在短短两年时间里，团队在 LM 应用落地范式上经历的变革。最初，当大模型刚刚问世时，许多人对其感到新奇，许多普通用户希望直接与大模型对话，进行互动。团队开发了 Check Bot，它能解决一些日常问题，用户可以通过简单的问答获得答案。然而，当这些应用部署到生产环境时，团队发现仅靠大模型无法解决生产中的复杂问题，因为大模型的精度有限，且随着需要传递给大模型的输入越来越长，团队需要提供更多的上下文信息，或者需要一步步引导模型进行操作。因此，团队开发了 Workflow 和 RAG 等技术，通过这些技术增强上下文，提高输出精度，并解决了一些幻觉问题。
实际上，直到第三个阶段，团队的许多在线应用已经采用了这一架构。例如，在金融和保险行业，专门的问答机器人可能就是采用这种架构构建的，它们可以解决一些简单的问答问题，但无法处理复杂的生产关系问题。因为团队希望尽可能多地将任务交给大模型应用处理，但如果要让大模型应用从头到尾完成一个需求，仅靠 RAG 和 Workflow 是不够的。这意味着我们需要将需求过程分解成多个流程，并进行编排。
于是，团队有了一个天才的想法：能否将我们已有的能力抽象为一个个原子能力，在与大模型交互时，告诉大模型我们具备这些能力，并由大模型指导我们何时调用这些能力。这就是我们正在探索的架构。正如团队目前所见，Agent 架构能够解决许多复杂任务的问题。对于一些更为复杂的场景，例如，可能会有一个工程师团队的维护，尽管这个团队是虚拟的，它是由众多 Agent 构成的。每个团队中的 Agent 都扮演着不同的角色，使得这种多 Agent 架构能够解决更加复杂的问题，甚至能够应对产品的整个生命周期，从评估、落地到最终的测试和运维等。
团队回顾这样的落地范式时会发现，对于真正的智能体开发者来说，底层模型的能力固然重要，但这并非首要任务。团队最关注的是如何获取一个高效、精准且成本低廉的 Prompt。这也是为什么许多人将团队的智能体应用开发者称为面向 Prompt 的开发工程师。如果团队观察大模型在这样的调用中，其实只是一个简单的 API 调用。抛开大模型不谈，团队会发现整个架构其实与过去在微服务时代面临的问题类似。团队实际上只是在组装各种数据，并将这些数据传递给用户或大模型。既然面临的问题与微服务时代相同，Python 能做的事情，Java 和 Go 现在同样可以做到。实际上，团队在今年年初与一些企业交流时发现，有些企业实际上在使用 Java 应用来构建他们自己的 Agent。但他们面临一个重要的痛点：Java 语言的生态系统相对落后。这意味着在进行提示词管理或对话记忆等方面，没有一个严谨的最佳实践或顶层抽象。这导致他们必须从头开始完全自行搭建这些组件，这个过程既复杂又痛苦。
因此，一个想法是，作为 Java 开发者，团队是否能有一个类似 Spring 的工具来构建 AI 应用，特别是 AI 智能体应用。答案是肯定的，团队的 Spring AI 阿里巴巴项目正是基于 Spring 构建的，它集成了阿里云通信系列模型及服务，并在 Java AI 应用开发领域提供了一些最佳实践。我们的团队不仅提供了众多高层次的 AI API 抽象，还整合了丰富的云原生基础设施，以助力开发者快速构建 AI 应用。实际上，这个项目的启动并非无的放矢；早在六年前，我们团队就与 Spring 社区建立了深厚的合作关系。基于 Spring Cloud，我们构建了 Spring Cloud Alibaba，并在六年的集成过程中积累了广泛的生态系统。在国内微服务领域，我们取得了显著的成功。今年 5 月，随着 Spring AI 的发布，我们团队迅速跟进，并在 9 月份推出了 Spring AI Alibaba。
迄今为止，我们已经为所有单位行政提供了全面的支持，并新增了 2020 余个大模型的 Agent 相关工具，以帮助大家更快速地调用 AI 资源和构建 AI 应用。我们团队将持续构建这些能力。现在，让我简单介绍 Spring AI Alibaba 的一些核心特性。
首先，它是一个专为 Spring 开发者设计的 AI 框架。无论你是希望为现有的 Java 应用增加智能化功能，还是想用 Spring 构建全新的应用，都可以基于 Spring AI Alibaba 框架快速为你的应用赋予智能化能力。
Spring Alibaba 还提供了许多关键过程的低层次和高层次抽象，并提供了丰富的预实现类。通过简短的代码，你就可以初始化一个 AI 级应用。稍后，团队的实践过程也将向大家展示。
第三块也是至关重要的部分，spring AI 阿里八八引入了大量阿里云大模型和云原生的最佳实践。这包括一系列完整的 AI 模型以及团队的云原生网关，Prompt 的管理在 NACOS 上的管理 Server Is 和日志观测等实践。
这里我将展示一个完整的 Spring 阿里巴巴从头到尾搭建的 Demo。大家可以看到，代码非常简洁，对于熟悉 Java 语言或 Spring 框架的朋友们来说，这与平时接触的 Spring Boot 代码并无二致。可能在座的许多同仁对 Spring 不太了解，但我会将团队微服务阶段常讨论的内容与之进行映射，将每个组件都进行一一对应。
首先，对于 Chat Client 这样的组件，它其实对应于团队微服务中常见的 Rest Template。它能快速帮助你编排输入输出，构建 HTTP 调用，在这里就是大模型的调用。model 层对应于 HP client SDK，是一个可插拔、随时可替换的实现。你可以调用到 Death Scope、open AI 或 AMA 等生态中的支持。Victor Store 更像一个大模型时代的数据持久化层。
Function Calling 在团队微服务时代难以找到一个完美的对应，它更像是团队在获得外部调用返回值后，根据返回值进行流程编排和分支判断。而在团队的 Agent 中，这个判断是由大模型完成的，而不是团队的业务代码。最后，Advisor 映射到微服务时代就是 Interceptor 或 Filter，这些是对输入输出进行增强的过程。稍后在代码实战中，大家可以留意这些组件的作用。
第二部分，我想重点简单介绍一下 Spring 阿里巴巴的一些可观测性特性。在介绍之前，我想先向大家展示一下我们团队正在部署的生成式 AI 应用系统的当前状态。
大致上，左边的图表展示了我们团队在线上经常遇到的一个智能体应用系统的架构图。从图中可以看出，整个调用过程相当复杂。团队中的每一步都可能超出我们的控制。如果团队想要将这样的系统部署到线上，却对系统内部发生的事情一无所知，心里难免会感到不安。对于每一个开发者或运维人员来说，一个无法理解的系统就像是一个黑盒，这是无法接受的。因此，团队需要解决的首要问题是如何提高系统的可观测性。
我将这个问题拆解为五个小问题，并在此列举出来。
首先，团队如何获取通用的数据采集能力。由于团队的应用可能使用多种编程语言，如 Python 或 Java，以及不同的技术框架，团队需要构建一种低成本且高质量的数据采集方法，并帮助团队发现和定位线上问题。
其次，团队在获得数据采集能力后，能否将采集到的数据标准化。团队关心的输入输出、Token 消耗以及关键执行动作和结果等环节的数据，需要统一标准来生成，否则团队将无法通过统一的可观测视图来分析整个系统的状态。
第三，团队可以看到关系复杂且漫长，可能伴随着各种反复的调用。在大模型应用上线后，团队是否拥有端到端的全链路性能和业务质量监控。并且，当性能下降或出现错误时，团队能否立即收到告警，第一时间保障用户体验。
第四，团队该如何定位问题的根源。今天，团队使用了 Spring 和阿里巴巴的技术后，虽然底层复杂度被框架所屏蔽，享受到了技术红利，但同时也面临着风险。当代码发生 Bug 时，团队应如何快速地进行定位。
最后，团队可能会面临语义化数据挖掘的问题。在进行业务时，团队常常需要可观测性数据来佐证或帮助判断当前业务状态。例如，团队的用户画像、用户群体关心的事情等，团队需要通过可观测性分析的数据来支持判断，并指导业务发展方向。
这五个问题，实际上是团队在部署生成式 AI 应用系统时遇到的挑战。那么，Spring 和阿里巴巴如何解决这些问题。
接下来简要介绍团队的可观测性是如何实现的。这里展示的是团队的 Spring AI 技术架构图。可以看到，中间的大框框代表了团队的 Spring AI 应用，包括 Chat Client、Victor Store 和 Model CORE 等关键调用。我们将这些关键调用拆分出来，并在左侧展示了应用的外部依赖，如大模型、中间件、云服务，甚至其他 AI 级应用。所有这些应用都会被集成在 Spring AI 阿里巴巴中的可观测性组件所采集，并存储在内存中。我接下来列出的几个组件，如 Micrometer、OpenTelemetry 和 SLF4J，会采集并保存数据到内存中，通过 OpenTelemetry 的 Java Instrumentation 和 Log Collector 将数据导出到本地或转换为 OpenTelemetry 格式的数据指标、链路和日志，并最终上报到团队的可观测性后端。通过这些可观测性数据，团队最终能够产生价值。
在这样的技术架构下，它具备三大特性。首先，它全面兼容 OpenTelemetry 协议，因为 Open Telemetry 是一个与供应商和工具无关的可观测性框架和工具包。目前，它也是 CNCF 非常热门的一个开源项目，并已成为可观测数据创建和管理的事实标准。它拥有非常丰富的开源和商业化的集成生态。你会发现，市面上大多数可观测性应用和客观性特性服务都已集成 Open Telemetry。选择 Open Telemetry 协议意味着在可观测性架构选型上拥有极高的自由度。你可以自由选择后端和前端来导出数据，实现无缝对接。其次，它支持多样化的可观测数据导出方案。例如，团队目前支持直连、通过 Java 代理转发、使用 Open Telemetry Collector 进行中间转发，以及将数据作为结构化数据导出到本地。这些多种导出策略允许你根据自己的可观测性需求、时效性以及网络和部署环境，自由选择导出方案。第三点团队与阿里云的应用实时监控服务（ARMS）进行了深度集成。团队支持通过阿里云的 Java 代理零代码接入阿里云服务，并快速解锁 ARMS 提供的模型评估、成本分析、故障预测等能力。那么，这些可观测性数据上报和采集架构到底能为团队带来哪些价值呢。
可观测性数据包括指标、追踪和日志这三大块。在数据上报到平台后，平台会提供一些基本能力。一方面，我可以将指标配置到相关的场景化大盘，快速直观地了解团队每个系统、每个应用的当前状态。我可以为这些指标配置告警，当出现问题，如电容量下降或错误量激增时，我可以第一时间通知相关研发人员进行线上修复和回滚。第三点，通过分析这些链路数据，我可以快速了解问题发生的现场以及问题出现在哪个关键调用环节。我还可以利用平台提供的 Trace 分析能力，通过对话的方式让大模型告诉我，我的调用链路中哪里出错、哪里慢，以及如何修复。第四点，团队的追踪和日志这些可观测性日志数据可以进行语义分析和数据加工，帮助团队产生更高阶、更有意义的业务数据，以帮助团队对业务目标进行判断。这五种平台能力可以衍生出许多应用场景。这里仅简单列举几条，如团队成本控制、性能分析、故障诊断、性能优化等，这些都是在开发 Agent 应用中经常讨论的问题。
关于可视化开发补充一点：团队目前正在与阿里巴巴合作打造一个名为 Studio 的平台。这是一个本地部署、轻量级、可视化的开发和调试工具。它允许你在启动 Spring Cloud Alibaba 应用后，通过访问一个端口来获取当前应用的运行情况以及产生的各种调用链路信息。当然，这个功能目前还在开发中，团队也希望它能尽快与大家见面。
接下来重点围绕三个方面详细阐述可观测性数据的价值。首先是线上问题诊断的典型场景。当团队遇到线上问题时，通常有两种途径：一是通过告警，如指标下跌或错误出现；二是客户反馈某个调用存在问题。团队收集到线索后，最终会获得一条调用链路，这条链路可能是错误的，也可能是慢的，总之是不符合预期的。团队可以从这条调用链路中看到许多关键调用环节，具体哪一步发生了什么错误。对于一些平台，团队还可以通过对话，让它们帮助分析，告诉团队慢调用和错误调用发生在哪里，以及具体内部发生了什么问题，有什么办法可以修复。
第二点，团队经常讨论的是 ATTENN 应用的评估。应用上线后，团队最关心的是其指标、成本、性能，以及是否会产生幻觉问题。通过持续收集指标和 Trace 数据，团队能够直观地感受到每次发布和回滚过程中的状态变化，快速地识别应用的当前状态。这些数据还帮助团队进行性能调优和架构调整。
第三部分是 Trace 和各种日志的语义分析及意图识别。团队可以将可观测性数据统一导出到日志分析平台，利用向量检索能力查询最近的调用主题，或通过编写语句对调用进行主题或意图聚类，以便更快地了解用户需求和关注点，从而对整体业务进行评估。
最后一部分主要介绍对 Spring for Alibaba 的开发实践。由于团队即将进行实战环节，这里简要介绍一个将要使用到的应用——智能机票助手。
它基于 Spring Alibaba 框架开发，能够自助帮助顾客完成机票预订、问题解答以及改签或取消等操作。它支持多轮连续对话，并具有对话记忆功能，必要时还能调用本地部署的函数来辅助任务完成。整个应用都是基于 Spring Alibaba 构建的。这里是一些代码解析，我将简要介绍如何创建一个 Chat Client。
代码结构相对简单，主要分为三部分：第一部分是系统的提示词初始化，你可以指定不同的提示词或将其托管在 Nacos 上；第二部分是 Advisor，即过滤器或 INTERCEPTOR，它对输入输出进行增强或内容补充，例如通过 Chat Memory 拼接历史对话，或通过 Rag 进行文档召回以辅助模型做出更准确的判断；第三部分是 Functions，即 Agent 的自定义能力，通过定义 Functions，我可以告知模型我具备的能力。例如，我将介绍三个关键能力：获取订单的详细信息、修改订单或取消订单。大模型将根据其推理结果有选择地调用这些环节。这些调用环节无需团队在代码中进行任何分支判断，只需定义好相应的 Functions 即可完成回调。
这里展示了团队所有回调函数的具体声明过程，实际上非常简单，只需创建一个 Spring Bean，并通过 Description 注解来告知大模型该 Spring Bean 具备何种能力。大众理解起来也很直接，就是简单地编写一个函数，没有复杂之处。
第三部分是关于对话时的记忆能力如何实现。右侧是其具体实现类，这个类相对复杂，它会将团队之前的对话内容拼接到团队的 Prompt 中。拼接方式是通过这个类，即阿里巴巴提供的一个已经模板化或预实现好的可配置类。你可以简单地通过创建此类的对象来调用使用，当然也可以通过接口化扩展来指定你想要的更丰富的能力。
最后，团队如何在应用中启用 Spring 阿里巴巴的可观测性信息。实际上只需简单三步：第一步是可选的，团队需要开启 Spring AI 中的一些默认关闭的功能。团队希望尽可能全面地统计信息，因此可以选择性地开启它们。第二步是引入额外的依赖，即开启 Spring Boot 的可观测性能力，并将其对接到 Open Telemetry 协议。第三步是团队可以在启动命令中添加阿里云提供的无侵入式 Java 代理。通过添加这些代码后，团队无需修改实际代码即可完成可观测性的集成。
接下来是未来的简单规划。
首先是Spring AI，阿里巴巴可观测性研究部分的研究计划。团队主要分为四个部分：最核心的部分是基于 springAI 和 Open Telemetry 的开源语义建设。由于 Open Telemetry 社区不断更新迭代，团队将持续兼容 Open Telemetry 规范，确保数据标准化，并支持 OTLP 协议导出，同时支持 Auto Telemetry 开源的 Java Agent 零代码介入。
再往上一层，针对特定场景，团队将制定更丰富的寓意，例如 RAP 过程、拓扑过程，或是一些特定的性能指标，如网络延迟、模型输出流畅度等。这些内容团队也将持续建设。
第三部分是团队插件卖点。团队将提供更丰富的商业插件，例如 Resual Rank 过程目前是空白，但团队未来会补足这一部分空白，并提供更多的开箱即用的自定义插件工具包。这允许你在代码中的任意位置随意创建你认为重要的关键调用，并为它们创建需要观测的数据。
最上面是对于可观测后端的支持，例如团队刚刚提到的可本地部署的轻量化可视化可观测面板，包括更多适配 Arms4 可观测平台的高级功能，如模型评估等。团队将持续迭代和适配这些功能。
这个大图主要展示了 Spring 阿里巴巴项目未来的发展目标或计划。大家可以看到，Spring 阿里巴巴只是在右下角和左下角占据了一个小位置。团队更希望做到的是一个生态，即 Flow 和 Studio。通过这两个平台，大家只需与 Flow 和 Studio 进行交互，通过可拖拽的方式、模板化编程以及各种可视化调试和观测来编排整个大模型和 Agent 的应用，包括它们之间发生的各种调用关系，都可以通过这种低代码的方式实现。帮助团队，尤其是今天的 Java 开发者，拥有像 Python 开发者一样丰富的生态和开发工具。
今天因为时间有限，团队的分享就到这里。我的分享就到这里，感谢大家。
我的花名是肯梦，主要负责 KBAI 领域的产品工作。本次分享的主题是“Serverless + AI，让应用开发更简单”。首先，团队将分为三个环节进行介绍。
第一个环节，我将介绍团队目前在 AI 应用开发中可能遇到的问题。第二个环节，团队将展示一个类似产品的发布平台，我们称之为营运开发平台。第三个环节，团队将介绍现有的一些客户案例，以及如何在我们的平台上实现应用落地。
首先，团队思考了一个问题：在 AI 领域，Service 究竟要解决哪些问题？可能大家对 SARS 有所了解，但对 Service 的理解可能还不够深入。因为 Service 实际上包括了灵活的算例和按量付费的调度。因此，在 AI 领域，Service 要解决的两个效率问题分别是：降低成本目标，即如何降低使用 AI 或 GPU 的成本；以及效率目标，即如何简化 AI 应用的部署过程。这两个问题是我们团队正在努力解决的关键和核心问题。
接下来，我们探讨了客户在构建 AI 应用时遇到的障碍。如果团队正在探索 AI 应用构建，会发现一个典型的问题是专业度不足。第二个问题是，面对众多模型，如千问包、Cloud 或 OpenAI 等，团队如何选择和应用。第三个问题是私有化部署时面临的卡型供需关系问题。例如，运行一个大型模型如欧拉玛 7B7B 在笔记本上会耗费大量时间。因此，在 GPU 领域，GPU 是关键资源。第四个问题是缺乏相关案例参考，比如团队想要进行纹身图或 A 镜创新时，缺乏可以直接参考的案例来帮助快速落地。
Service + AI 团队重点解决这些问题。首先是成本问题，如何减少企业的试错成本；其次是效率问题，如何提高 AI 领域的开发效率；第三是灵活定制，满足企业将智库应用于模型微调等需求；第四是快速部署和使用。
Serverless 实际上是围绕 AI 应用构建的障碍，扩展我们现有的产品能力。
团队收敛了四个产品能力：首先是如何降低模型服务的成本；其次是能否一键快速部署应用；第三是是否有先进工具帮助快速迭代；最后是企业如何进行二次开发，根据自身需求进行定制。这就是 Serverless。实际上，当前的产品开发也是围绕这四个核心点来构建团队的应用。
接下来介绍一个今年的云期团队发布的一个名为云原生应用开发平台的产品，我们通常称之为 CP 或 CAP。这个平台旨在解决团队在 AI 应用场景下与 Serverless结合的问题，帮助构建例如团队的 AI 应用或智能体应用。稍后，您将看到一个一分钟的视频，简要介绍 CAP 平台是什么。
简要解释一下：CAP 平台能够利用团队现有的模型、算力或组件来构建 AI 应用。它提供了许多解决方案，包括团队常用的纹身图、模型收敛等组件。这些组件可以帮助团队快速构建应用，通过简单配置即可一键启动强大的 AI 问答应用。该应用包括在线智能问答和离线数据处理功能。当您上传知识库至阿里云对象存储时，将自动触发离线数据处理流程，从对象存储中提取知识库数据，对文档执行分割操作，并利用 Map Reduce 技术对分割后的数据进行向量化处理，最后将处理结果存储至向量数据库中。流程的每个节点都可以灵活替换。例如，在模型选择上，您可以使用托管模型，也可以调用第三方模型 Api。您可以通过已部署的 Web5 来测试应用效果。当与机器人对话时，它会自动从知识库中检索相关信息作为上下文，帮助机器人进行回答。这是团队的 RAP 解决方案，旨在简化应用开发。实际上，团队的 CAP 平台分为几个层级，大约有五个。
第一个层级是模型层，它提供了模型托管、模型评测、模型封装以及模型服务化等关于模型的一系列功能。团队将其称为模型层。第二层级是服务层，它实际上是 Service GPU 和 Service CPU 的承载体，也就是团队的 Runtime 部分。第三层级是开发层，它包括视频中展示的 RAP 应用，这是开发层的一部分能力。当然，开发层的能力仍在演进中。例如，团队未来可能会推出专门针对 Agent 的开发层界面，包括专门针对纹身图的开发界面，以提供更好的服务。第四层级是部署层，它提供了整个应用开发的完整生命周期，包括 Matrix、Debug 以及 API 化等。这是团队部署层的能力。在最顶层，团队会提供一些开箱即用的模板。在第三个实验中，团队会让大家亲自体验如何部署一个 AI 绘本应用。左侧是团队可以自由绘画的画板，右侧是团队生成的相同效果。这实际上是团队 CAP AI 的整体产品架构。
接下来，我会分阶段向大家介绍每个模块的具体功能。在平台概览方面，团队在设计这个平台时，考虑了服务语义和执行层的封装。例如，团队将其分为三个应用：
第一个应用是团队传统的应用智能化，例如，团队可以基于这个平台简单部署一个 Web 应用，或者部署一些传统的应用框架，如数据库或类似于 Word、Excel 的框架。其核心运行时是团队函数计算和流程。
其次，第二个应用是团队纹身图的应用，意味着团队，包括 Sad Fusion 和 CONFILUI，可以在这一平台上进行更多扩展。团队未来也会针对纹身图场景，专门推出一种开发界面，以满足企业对纹身图的特定需求。
接下来是 AI agent，即团队通常所说的智能体。团队在这里抽象出许多服务，例如团队流程，这是团队产品中相当重要的一环。它能够满足团队对模型的控制需求，即团队对模型的管理。还有一部分是代码服务，团队可以通过代码完成对现有 agent 的封装模型服务，底层团队允许部署一些开源模型，而不仅仅是云上的模型。例如，SARS 化封装的 API 模型。不仅如此，团队可以训练特定领域的模型，通过一键部署进行管理。
第四部分是团队的向量服务，即团队的向量数据库。这大致是团队整体应用开发的一个概览。
下一部分，将介绍团队现有的开发范式。
第一部分，是团队针对接口的功能化封装。实际上，团队在使用 AI 时会发现一个典型问题：目前所有操作都是针对 API 的调用。无论是调用 CDAAPI、百炼 API 还是 the diffusion API，都是标准的 API 划分。因此，团队提倡的是对接口进行功能化封装。封装结束后，团队可以通过流程将这些 API 编排起来。例如，流程 A 可能用于意图识别，识别到今天要进行游泳活动，然后团队调用 API 来获取反馈，比如定义游泳场馆的时间段。这就是一个典型的流程化开发能力。
第二部分，团队将其定义为流程化编排和组装应用。
第三部分，团队称之为应用开发与调试。完成这些流程后，或者完成这些公共封装后，团队组装出一个应用，其调试和管理方式是怎样的。
因此，最后一部分定义为应用开发，包括调试。这实际上是团队目前经典的一种开发方式：首先，团队通过 API 封装；其次，团队通过流程调用 API；第三部分，团队进行管理。这部分简单介绍了团队目前的产品能力，现在，团队可以将其拆分来看每一步，究竟具体做些什么。
首先，团队提供了一个高质量的模板，意味着我们提供的都是即插即用的解决方案。例如，我们体验的类似纹身图的绘本，正是我们模板库中的一员。除此之外，团队还支持 LaTeX、Cha 等开源框架的托管模板，一键部署即可快速在平台上启动。因此，团队首先解决了部署能力的问题。
第二部分，假设我部署了一个应用，希望对提示词或特定部分进行修改。团队可以通过修改中间层函数来更新这些提示词。这实际上是团队二次开发的环节。
第三部分，即使在发布后，我仍然需要进行一键部署。团队为此提供了版本管理，帮助大家管理这些已经完成的能力。这实际上是团队所谓的应用开发模板。
第三部分，团队提供了一个类似于组装式开发的整体流程。这包括团队流程服务的开发、模型服务开发的调试，以及向量数据库开发的调试。团队针对这些能力进行了大量定制，包括更新，帮助团队实现组装式研发概念的落地。
第三部分是团队的 Serverless 运行时。如果大家熟悉都知道它是按量付费的。团队基于 GPU 场景提出了一个极速模式的概念，即通过预留资源来快速启动，降低 Serverless 场景下的冷启动能力。实际上，团队在这里做了一个简单的算术题，即使用 GPU 场景下按量付费的逻辑是怎样的。例如，以 A4 卡应用为例，团队每秒收取多少钱，其大致成本是多少。这是 Serverless运行时的底层能力，它可以帮助团队降低 GPU 的成本，因为 GPU 的持卡成本非常高。这部分实际上是团队的流程服务，提供了一种灵活组装的能力。团队允许开发人员通过拖拽的方式完成特定应用的开发。正如我们在讨论开发范式时定义的 EPI 层，流程服务实际上就是将这些 API 通过流程串联起来。因此，这部分是团队定义的流程开发应用，还包括团队的函数符。
团队的函数符实际上是底层支持的基础算力，也是团队最小的算子。正如我们之前提到的 Serverless GPU，它包括免运维、极致弹性以及高自用资源利用率等特性，以满足团队针对代码开发的业务需求。
这部分主要强调的是模型服务的降本能力。
首先，团队在产品层面上定义了许多关于模型导入到平台的 SOS 端点。换言之，团队模型如何被导入并运行在平台上是关键。当我们在本地或企业环境中部署应用时，一定会遇到如何让模型运行起来的问题。确实，模型运行起来之后的成本问题也是我们不得不考虑的。因此，团队的模拟服务正是为了解决这类问题而存在的。首先，团队在产品侧提供了多种导入功能。例如，团队可以直接从 Mos Scope 拉取模型，以帮助团队进行部署。此外，团队还支持通过输入 Hug Face 路径来下载模型到本地。当然，目前对 Hug Face 的支持是有限的，因为这可能会涉及到一些合规性的考量。团队还可以从存储产品中拉取微调过的模型，然后直接上传到 OSS，并通过拉取 OSS 文件来部署模型。在部署环节，用户是完全无感的。例如，用户可以选择一个框架，团队的模型框架和参数设置好后，可以快速帮助大家将模型运行起来。这是团队产品能力的一部分。
第二部分能力是针对团队的算力和成本。团队利用 Solos GPU 的能力，提供低延时、低成本以及保证交付的服务。团队围绕这三点提供 GPU 的灵活弹性能力。具体来说，团队的模型服务是如何让 GPU 变得更经济。
下一页，将介绍团队 cap 平台的一些客户案例。这里覆盖了多种客户类型。例如，团队的设计师，作为完全的 C 端用户，如何可以快速部署 SSSD 或 CONVEUI，并导出设计原型。团队为设计师和开发同学提供了 Cap 加 Web 全栈的能力，帮助他们提高基础开发的效率。对于初创公司，团队同样基于 CP 来处理大流量并发，确保团队的稳定性和效率。大型客户，包括团队的森马，也是团队的忠实客户之一。他们使用团队的整体解决方案，比如 Cap，来完成定制化的能力，如 SD（save defusion），因为他们可能需要进行临时调度和弹性扩展。因此，这部分介绍了团队目前的客户情况。今天的主题大概就是这些，感谢大家。
