编程范式的演进
首先我们来看一个引用，来自一位大牛 Andrej Karpathy 的分享。他是特斯拉的自动驾驶负责人，也是 OpenAI 的前创始人，著名的 "Vibe Coding" 这个词就是由他创造出来的。
他在一篇分享中提到了我们编程范式的一个演进。在软件 1.0 时代，我们通过计算机的编程语言对计算机进行编程，大家熟悉的 Java、Python 等语言都在做这个事情。在 2.0 时代，我们通过神经网络参数权重的调整来对神经网络进行编程。
在大模型时代出现以后，我们的编程范式发生了非常深刻的变化。它体现在我们的编程对象变成了大语言模型（LLM），LLM 是在 GPU 上运行的，而不是我们原来传统的在 CPU 上运行的计算机。而我们的编程语言不再是 Java、Go、Python 这样的一些语言，而是用提示词。编写的提示词运行在大语言模型上，所以我们是通过提示词对大语言模型进行编程，编程出来的应用我们叫做 AI 的原生应用。这种转变对我们的开发范式和应用开发的理解都有非常多的思维转变。
AI 原生应用的核心概念
我们来看一下 AI 原生应用到底有哪些概念，或者它的架构是什么样的。我们看一个全景图，这是我们定义的一个开发全景图。
首先我们从中间开始，一个 AI Agent 有几个非常核心的概念：
- 感知：它需要去感知内部外部的环境，能够去做一些输入和输出
- 大脑：也就是通过大模型去帮我们做决策
- 工具：去调用外面的工具，包括使用一些 MCP 的工具来执行一些必要的动作
- 记忆：这个记忆包括长期和短期的记忆，在模型应用执行中的上下文是非常关键的
这几个要素构成 AI Agent 的核心。Agent 之间也可能会有一些通讯的手段，例如通过 A2A 协议去做通讯。
那么我们怎么去开发一个 Agent 呢？首先我们上面有一些开发框架，不同的语言现在有非常多的开发框架，通过高代码和低代码简单做一个区分。然后通过不同语言可以看到，我们有非常多的框架能够帮我们简化这个开发的步骤。我们也可以通过一些工具，包括现在比较流行的通义灵码、Cursor、Claude Code 这样的工具，帮我们去生成这样的 Agent。
生成出来以后，这个 Agent 需要一些计算的资源来帮他去执行，需要一个 runtime。这个 runtime 可以是现在我们的 K8S 上面运行的，也可以是跑在一些运行时，比如函数计算这样的一些运行时里面。它依赖的一些模型当然是在 GPU 上运行的，这个 MCP 的工具也是需要一个 runtime，所以 MCP 的 server 它也需要在这样的一些计算的环境里面去运行。
有了这个运行的环境，它还会底层依赖一些我们的通用的中间件能力去提供一些通用的服务。比如说我们可以通过 Nacos 这样的中间件去完成 Prompt 提示词的管理，以及 MCP 的注册动态和发现。后面会讲通过 AI 网关去对于多个模型和 MCP 进行一个统一的代理。通过消息队列去完成我们一些长任务多周期的这种任务的异步化改造。
当然还有一部分很关键的是我们的可观测性。这个 Agent 运行起来是不太确定的，很多时候我们都要知道它内部的运行情况，怎么样帮助我们去更好地评估我们的运行行为。所以需要对它的数据进行采集。我们有一些采集的探针，比如说 LoongSuite 这样的探针，开源的探针去采集这些包括 token 的消耗以及模型的输入和输出等等。有了这些东西，我们可以对 Agent 的行为进行分析，包括对它性能、成本和质量进行分析。这是我们的一个全景图。
AI Agent 开发的关键问题
Agent 在开发的时候有哪几个关键问题？我这里列了几个关键问题，我们今天可以跟大家分享和讨论的就是：
1.搭建 Agent 的时候，我们是用哪种模式？到底是 workflow 的模式还是 Agent 的模式?
2.我们需要单 Agent 还是多 Agent?
3.在提示词工程方面如何实现的，还是说用现在比较流行的上下文工程。
这三个话题我们一个一个来讲一下。
Workflow 模式 vs Agent 模式
Workflow 模式的话其实很简单，我们在编排业务的时候会把一些固定的流程，比如说我们传统的业务流程，通过一些预定义好的步骤，通过这样的一些低代码或者高代码的平台的方式能够帮他去编排出来。它的好处就是确定性很高，我们知道有些东西是我们一定不能出错的，比较确定的这种流程，我们可以通过这种模式来进行。
但是在一些复杂的场景或者任务的时候，它就会显得捉襟见肘了。比如说我们有一些 Agent，它需要完成非常不确定的，因为我不知道这个流程下一步该往下走，很多时候是这样的。在这种场景下，我们其实有一种叫 Agent 的模式。其实它是一种通过大模型来告诉你下一步应该如何执行，它帮助你做规划，做执行的这样一种模式。它的好处就是灵活性会比较高。一些典型的场景，比如说我们现在常见的 Deep Research，还有这个 Coding Agent，就是我们现在在编程的助手 Cursor、GitHub Copilot 做的事情。还有 Manus 这样一些 Agent，他们基本上就是用 Agent 的模式。
在真实场景实践下来，我们发现其实并不是说二选一，但实际上我们有很多的场景是要做一些妥协的。这里妥协点主要是有两个，一个是准确性，一个是成本。
准确性是一个很确定的事情，因为我们有很多的流程，比如说我要去做一个东西的识别，比如图片的识别或者是发票的识别这样的一个场景，我们明确地知道必须是要准确地识别出来某一个特定的字段。这种时候我们可以完全用 workflow 的方式去帮我们提升这个准确性。
但是还有一个要考虑的点，比如说我们要去从一些复杂的文本的一些提取字段的时候，我们可以通过大模型。但是大模型的成本比较贵，我们完成同样的事情，可能用 GPU 的这个成本可能是我们用 CPU 成本的十倍或者甚至以上。那这个时候我们也需要去权衡到底用哪种方式，所以它是一个混合的模式。
单 Agent vs 多 Agent
第二个话题就是说单 Agent 和多 Agent，就是什么样的情况下我们应该用单 Agent，什么样的情况下要做多 Agent。其实在我们目前实践下来，就是在大多数场景下，针对简单的目标明确的场景，我们其实推荐还是用单 Agent 的这种方式。单 Agent 的好处，它是比如说我们开发各方面维护时比较简单一些，但是它也有一些局限性，就是当这个任务我们知道模型的上下文的窗口是有限的，当我们的 Agent 越来越复杂，它一步一步执行的时候，它每次会带越来越多的上下文。这样的话我们上下文达到一定窗口的情况下，这个模型会出现一些幻觉，甚至一些不确定的行为。这时候我们就要考虑是不是一个 Agent 就能够完成，所以我们做一些拆分。原则就是说我们在如无必要的情况下，勿增实体，也是奥卡姆剃刀原理，就是我们在正常情况下我们尽量使用单 Agent。
当然，但是在一些场景我们明确地发现这个任务执行非常复杂，然后需要复杂的协作的情况下，我们建议是用多 Agent 来完成。而且多 Agent 有个好处，就是我们发现通过完成同样的编码任务，用同样的模型，如果使用多个 Agent 的协作，相比单 Agent 模式，可以大大提升我们在复杂场景下的准确率。这是经过实验或者各方面的实践验证出来的效果。
比如说这个例子里面的 Deep Research 的场景，但它是一个多维性的典型场景，就是他有一个 Leader，这个 Leader 会去负责把任务进行拆解，把这些任务具体的一些调研的设计的任务分给一些子 Agent，然后再由他子 Agent 的结果进行汇总，再返回给这个用户。这个时候多 Agent 的处理，就会更加的优雅一些。
提示词工程 vs 上下文工程
第三个就是我们的提示词工程和上下文工程。其实这个提示词工程是最之前比较火的一个概念，就是它解决的是一个要怎么样去跟模型交互，问出一个正确的问题，让模型能够准确的回答我的这个问题。它的关注点就是这个提示词要包含一个比较清晰的上下文以及一些例子，另外还有一些关键词等等，它构成了我们的这个提示词。
但是发现最近 Context Engineering 这个概念越来越流行了。原因在于说我们的 Agent 越来越复杂，这个 Agent 在执行的过程中它有很多的不确定性，再加上我们的对模型的上下文又是有限的。其实我们要解决这个问题是在有限的一个上下文窗口里面，怎么去给模型最有效的信息。
这里面就发现我们这个上下文里面，在复杂的一些场景下，它需要有的不光是提示词，它还需要我们可能做一些 RAG 检索回来的一些文档，然后可能会去调用一些 tools 返回的结果，然后还有当前上下文的一些状态。这些东西都要作为一个上下文传递给模型。那这个时候我们要去挑选最合适的这个内容传递给模型。这个时候就是有一门很讲究的艺术了，就是我们要怎么去把这些东西组装成一个上下文喂给模型。
还有一个点就是说我们的模型的推理，它其实是有缓存的，比如说在模型推理阶段有 KV Cache。那我们的上下文其实的内容的重复程度，很大程度上决定了我们推理的效率有没有命中那个上下文。所以我们在构建上下文的时候，通常是希望能够尽量的复用我们一些确定性的一些数据，然后再把一些变化的内容尽量的往往那个模型的后面，就是上下文的后面去放。这样的话其实让前面更多的内容是固定的情况下，能够去命中 KV Cache 在推理的时候也缓存。所以上下文工程也是一个目前比较需要大家去关注的一个方向。
AI 原生应用参考架构
有了上面三个议题，接下来是给大家介绍一下，就是现在这个 AI 原生应用的一个参考架构。我们可以看到中间的这个是我们的 AI Agent。Agent 它可以用各种开发框架开发出来，运行在一些运行实例上。并且它可能会去调用一些数据库或者向量数据库去获取额外的数据。
流量是从用户发进来以后，经过 API 网关，然后到达 Agent 以后，他会去跟模型进行交互。因为跟模型交互的过程中，需要有一个统一的 AI 网关作为代理。这个代理可以解决通用的一些问题能力，比如说 token 的限流，模型调用的协议的转换等等一些东西。因为我们后面调用的模型可能是有不一定是只有一个的，有多个。然后同时它可以做作为一个工具的一个代理，就是我们的 MCP Server。MCP Server 它其实也可以，因为有很多的 MCP 服务在后面，比如说我们有公有的服务，也有私有的服务，我们可以通过 Nacos 来完成统一的 MCP 的注册和动态的提示词管理。然后通过消息事件消息去实现这种异步长周期下面的状态管理。当然所有的这些东西都会通过可观测性来进行统一的采集，标准的 OpenTelemetry 协议。通过 LoongSuite 这个采集器，把它统一送到我们的一个可观测的平台上，做统一的监控和诊断以及模型的评估，这是我们一个参考的架构。
接下来的话我会介绍一下这几个关键的组件。
Spring AI Alibaba
第一个 Spring AI Alibaba，它其实解决的就是帮助 Java 应用开发者去更好的开发 AI 原生应用，它基于开源的 Spring AI 的组件，在上面其实又封装了更多的能力，比如说支持 workflow、Agent 的模式，以及单 Agent 多 Agent 的一些抽象和配置。还有在基于上面，我们基于更上层的业务场景有构建的通用的 Agent 叫 JManus，就是 Java 的 Manus 实现。然后还有像一些典型垂直类的 Agent 的场景，比如说 Deep Research，以及 Data Agent 等等。对，就是目前 Java 开发者来说的话，开发一个应用，比较完整的功能的一个框架。当然 Python 也有一些非常优秀的框架，今天由于时间关系没有提及。
Nacos
Nacos 的职责，其实在这个 AI 原生应用的场景下，它的职责也很明确。原来在微服务时代，它是一个动态的配置管理和注册的中心。那现在我们知道 Agent 在去访问各种 tools 的时候，他可以在本地起一个 local 的 server 去访问我们的一些传统的微服务应用，这些就是以前构建的微服务，把它转成了 MCP 接口暴露给 Agent。那我们也有一些可以通过一些远端的这种 MCP 的 server 去访问这些传统的服务，当然也有一些三方的 MCP 的，比如说在公共很多的 MCP 市场上，如高德地图等各种 tools。这里面势必有一些 MCP 的服务是要在企业内部去落地，而不适合在公共的那个市场上去暴露的。所以说我们需要一个有私有化的 MCP 的注册中心，帮助我们统一在企业内部去管理和运维这些 MCP 的服务。还有做一些健康检查，动态管理，版本管理的能力，这个是目前的一个能力。
Higress
Higress 的话，其实刚才说到它是一个 AI 网关的一个核心角色。在中间的这块东西就是我们的 AI 应用和模型之间有一个核心的 AI 网关的一个代理的能力，就是它可以做到我们的一些核心的 AI 的一些能力，比如说 LLM 的缓存，向量的一些检索，还有像 token 的一些限流。在安全方面包括一些协议的适配，我可能要去适配多个 OpenAI 那个模型的协议，以及 API 的统一管理。然后这最近在做的这块，就是 MCP 的代理的这块东西，就是怎么把一些私有化的公共的服务统一地暴露给 Agent，并且做一些细粒度的一些认证，还有我们的动态的发现等一些能力。另外，包括协议转换，就是把一些传统的 OpenAPI 的协议转成这个标准的 MCP 协议，都是可以通过这个 AI 网关和 MCP 网关来承接的。
Apache RocketMQ
Apache RocketMQ 在这里面解决了一个是什么问题？就是 AI Agent 的我们发现在复杂场景下，它会进行多轮的交互和对话，那其实在这个过程中可能有很多临时或者中间的一些状态。比如说这个模型给你的返回值，它可能是一个阶段性的，它可能是流式返回的。但是如果中间任何的一个场景出现了中断，这个时候就要进行一些重试了，因为这个流程就完全断掉了。这个是其实我们发现重试的成本是相当高的，因为重试的你要去重新发起一次 GPU 的计算，它的计算成本是远高于原来的微服务的场景下 CPU 时代的计算，可能是刚才说的十倍以上的成本。
这个场景有点像什么呢？就是下载文件的时候那个断点续传能力。我们可能这个文件下载到一半突然中断了，这个时候我们在这个场景下就得重头再下载。但是我们希望解决的一个问题就是说我们能够去中间从中间的这个阶段去恢复过来。通过消息队列，可以做这样一件事情，Apache RocketMQ 提出了一种新的模式，就是说把 AI 的框架下的 session 作为一个消息的 topic 进行管理。那一个智能体应用，它会跟模型交互以后，在返回给用户的过程中，把所有的中间的结果都丢给这个消息队列来存储。
有一个消费者去消费这个队列这个数据，比如说这里的网关，正常的话他会把这些内容送给我们的前端的客户端。当然如果当一个网关或者是一个消费节点出现了问题，挂掉了的情况下，其实我们可以动态地把他切换到另外一个消费者，他接着可以接着订阅这些还在存储在队列里面的中间的数据，可以接着往那个客户端去反馈。这样就解决了我们前面说的他在中断的过程中需要去重试，重新去耗费 GPU 的这样的一个问题。
可观测性解决方案
接下来就是可观测性的一些介绍。就是我们在应用 AI 应用的开发过程中，其实总结下来的可观测性上就有三大痛点。第一个我怎么把它用起来，第二个就是怎么用的省，第三个是怎么用的好。
第一个问题就是当我们把这些应用搭起来，调用模型的过程中发现，推理过程特别慢，特别卡，或者是有报错，不知道卡在哪里，是一个要把它怎么把它用起来的问题。然后第二个就是发现用了一段时间之后，怎么这个账单突然一下子就爆炸了，或者这个 token 怎么消耗这么多，到底消耗在哪了，不知道怎么把它用得更加经济节省。然后第三个就是这个模型或者 Agent 的回答的质量好不好，我们也不清楚，需要对他进行一个评估，就怎么把它用得更好，解决这三个问题。
解决这三个问题的话，就是首先在我们整个 Agent 的运行的整条链路中，去通过一些可观测的数据的采集探针，把这些可观测数据给采上来。这些数据包含什么呢？包含我们的所有的链路的信息，就是从头到尾这里从端侧到 API 网关，到 AI Agent，再到 AI 网关，再到我们的模型内部，它的每一个环节到底发生了什么，我们都希望能把它记录下来。这里面包括调用的输入输出，token 的消耗，然后 tools 的使用等等。第二个就是一些关键的指标把它收集上来，能够去反映当前的运行的行为。第三个就是模型的通过刚才采集的数据，对我们的这个 Agent 的行为进行一个质量的分析和评估。
这里我们通过 OpenTelemetry 开源的标准，它这里面开源的 SDK ，也有提供的探针的方案。就是说把一些探针动态地挂载到这个 AI 应用里面。它可以比如说是 Java、Python 构建的这些 AI 应用，都可以通过探针挂载到这个应用里面去，它能够动态地采集上述的数据。然后同时在模型内部我们发现很多模型它都是 vLLM、SGLang 这种推理加速框架去拉起来的模型，它其实也是个 Python 应用，我们可以把探针挂载进去采集在模型内部的推理的一些流程，能够去采集它的细节的信息。同时在 GPU 层面也可以去采集这些 GPU 的一些使用率的一些信息。有了这些数据的话，我们可以进行上述的三个处理。
我们应该要关注哪些关键指标，这里可以简单介绍一下。首先在应用里面，在 Agent 里面，原来的微服务时代，我们可能的黄金三指标是 RED，就是 Request、Error、Duration。但是现在我们发现在 AI 应用里面，更关键的是我们的 Token 消耗。新的黄金三指标是 TED，有 Token、Error 和 Duration 是最关键的三个指标。
那在模型推理加速的时候，有两个非常关键的指标需要关注。一个叫 TTFT（Time to First Token），一个叫 TPOT（Time Per Output Token）。第一个指标它取决于什么呢？就是我们的上下文 input 给到模型，到模型吐出第一个 token 的时间，这个叫做首包延迟时间，它决定了我们的模型推理的流畅度。然后第二个就是从第一个首包出来以后，再到他把所有的包都出完，再除以它的耗时，得到一个数叫做 TPOT，就是说我首包延迟以后，后续平均的每包的传输时间，这反映了模型在 decode 阶段的一个关键性能。所以这两个指标是一定要关注的。然后像关键的一些模型推理的阶段，像 KV Cache 的缓存命中率以及 GPU 的一些利用率等等，包括一些吞吐的能力。在评估的场景下，主要是要关注像准确性、偏见、毒性等指标。
刚才说了指标，还有一个重要的方面是 Trace。它能够帮我们去非常清晰地看到这一次的模型推理调用内部它的一个实时的运行状况到底经过了哪些节点。在这里怎么看呢？就是比如说我们通过标准的 OpenTelemetry 的 Tracing 协议，可以采集到每一个关键的环节。这个截图里面就是使用一个 Dify 构建起来的一个 workflow，去调用一个 vLLM 的一个模型。那么通过这个调用链，首先可以看到它的时间，然后总的 token 消耗以及它的 input 和 output 是什么。然后每一个 Dify 下面的 workflow 的关键的那个节点的信息，以及它的耗时分别是什么。就看到耗时比较长的是在这个 LLM 调用，在这里他 token 消耗是这么多，然后再到模型内部，通过我们的全链路的 tracing 的能力，把模型内部的一些消耗也会反映出来。通过这个 trace 能够去准确地看到我们每一次执行的情况。
然后就是评估，评估也是在 AI Agent 这个场景下非常重要的一个概念。就是它相当于我们传统的软件开发里面的一个回归测试。这个流程它是一个循环的样一个结构，而不是一次性的行为。
首先我们在开发阶段开发出一个 Agent 之后，通过 tracing 记录模型的输入输出，能够对它进行一个初步的一个评估。然后这个评估的话会有两种类型，一种叫做人工的评估，但它比较适合在前期 AI 应用开发的前期去进行。它需要去人为地核对我们的这个 AI 应用的结果是不是符合预期。首先挑选一些固定的 case，我们明确地知道这个模型的返回是结果的那种 case，然后去人为地去评估这个运行的结果是不是在满足预期的。当它到达一定的稳态以后，我们可以把它转为 LLM 评估，就是用第三方的模型来帮我们进行评估，这样的话可以提升更好的一个扩展性和效率。但这个流程的话，到了评估完成以后，到了线上部署，我们会线上持续地去追踪这个线上的数据，就刚才说的指标 tracing 以及日志等等一些能力，去反馈和优化我们的 Agent。然后再通过 Agent 的不断地去迭代，循环往复。
在评估的时候，有哪些重点要关注的地方？就是我分了三个阶段，一个叫 Planning。Planning 就是在我在模型在拆分任务，或者说 Agent 在拆分任务的时候，它到底拆分的准不准确，有没有重复的，或者有没有准确的最短路径，或者说是他绕了弯路等等。这些方向是我们需要去评估的重点要考虑的一些要素。
还有一块是工具的调用。因为很多时候模型的输入不稳定，很多时候是因为那个 tools 调用是有问题，他没有选择正确的 tools。第二个是他可能在 tools 参数识别的时候识别的不准确，传递给了错误的信息。这些东西都是要在评估阶段关键要考虑的。还有像 RAG 的阶段，就是在召回的过程中，需要去关注他的语料的一些召回是不是有相关性，是不是有重复等等。
有了这些以后，我们可以通过这些数据送到一个可观测平台。这个平台里面我们可以去持续的自动化的定时地去抽取一些线上的运行的数据，然后对它进行一些。因为这些数据都是一些评估的模板，我们定义好了这些模板以后，就可以自动化的线上持续运行了。然后他可以把这些东西打成一个分数，比如说这个是不是一分就是做得非常好，0.1 分就是做得不好。那可能最后就变成一个 0 到 1 的一个数字，能够帮助我们去数字化的去分析。
开源项目规划
这里跟大家介绍一下，最近我们刚刚发布了一个开源项目，就是叫做 LoongSuite。Loong 就是中文的那个龙的意思，然后这个 Suite 就是采集套件的意思，我们希望在开源的 OpenTelemetry 社区基础上，提供针对 AI Agent 开发所需要的各种框架的一些自动化采集探针能力。比如说有 Java 的，有 Go 的和 Python 的探针。这探针针对我们刚才说的用不同语言开发出来的 Agent，能够去自动捕获它的一些数据，包括指标 trace，还有日志 input、output 这些东西可以送到开源的一些存储，支持任何的以 OTLP 就是标准的 OpenTelemetry 协议兼容的一个控制台，比如说 Jaeger 或者是 Elastic Search。这些也可以上报到云服务上面，通过云平台来帮你去完成这些数据的存储和展示和托管。基于此来完成刚才说的性能成本和质量的一个分析和评估。
最后简单介绍一下刚才提到的几个开源项目的一些规划。
● Spring AI Alibaba 的话，后面会去做一些包括 A2A 协议的支持，还有会做一个评估控制台来提升我们整体的开发调试和评估的一个效率。https://github.com/alibaba/spring-ai-alibaba
● Higress 的话，会去增强我们的一些 AI 插件，还有一些 RAG 的一些插件。https://github.com/alibaba/higress
● Nacos 3.x 版本里面会提供这个动态 prompt 还有 A2A 协议的一些支持能力。https://github.com/alibaba/nacos
● 关于提到的 Apache RocketMQ 的一些能力，也会在近期一两个月内把它发布到开源社区。https://github.com/apache/rocketmq更多信息参考：https://mp.weixin.qq.com/s/A2goRPqwgFNkO3UhH1Apzw
● LoongSuite 的话，会去针对更多的主流的开源框架，比如说那个 Python 的很多的一些框架提供完善的支持。最近刚刚在做这个 Dify 的可观测性的支持，很快就会发布。然后 A2A 协议，还有端到端的可观测性的一些支持。https://github.com/alibaba/loongsuite-python-agent
谢谢大家！
