摘要：随着技术与发展，编程范式不断演进。OpenAI 前创始人，特斯拉自动驾驶负责人 Andrej Karpathy 在提出过类似观点。在软件 1.0 时代，我们通过计算机的编程语言对计算机进行编程，大家熟悉的 Java、Python 等语言都在做这个事情。在 2.

随着技术与发展，编程范式不断演进。OpenAI 前创始人，特斯拉自动驾驶负责人 Andrej Karpathy 在提出过类似观点。在软件 1.0 时代，我们通过计算机的编程语言对计算机进行编程，大家熟悉的 Java、Python 等语言都在做这个事情。在 2.0 时代，我们通过神经网络参数权重的调整来对神经网络进行编程。

大模型时代出现以后，我们的编程范式发生了非常深刻的变化，软件 3.0 时代随之到来。它体现在我们的编程对象变成了大语言模型（LLM），LLM 是在 GPU 上运行的，而不是我们原来传统的在 CPU 上运行的计算机。而我们的编程语言不再是 Java、Go、Python 这样的一些语言，而是用提示词。编写的提示词运行在大语言模型上，所以我们是通过提示词对大语言模型进行编程，编程出来的应用我们叫做 AI 的原生应用。这种转变使我们对开发范式和应用开发的理解有非常多的思维转变。

对于这样一个全新概念，很多开发者对于 AI 原生应用的定义是模糊的，也不知道 AI 原生应用的架构是什么样的。为了解决这一疑问，阿里云定义了的一个 AI 原生应用开发全景图，帮助大家更好地理解与探索实践。接下来，我们分块进行解读。

AI Agent 想要运转起来，需要几个非常核心的能力，其中包括：

在了解上述基础概念之后，我们该怎么开始去开发 AI Agent 呢？

首先，我们需要一些称手的开发框架来生成 AI Agent 的核心部分，主流开发语言拥有非常多开发框架，来帮简化开发步骤。与此同时，随着 AI Coding 工具不断成熟，比如通义灵码、Cursor、Claude Code 等工具，让低代码也成为生成 Agent 的新方式、新可能。

AI Agent 生成后，需依赖计算资源执行任务，其运行时环境可基于 Kubernetes（K8s）或其他计算范式（如函数计算）。具体而言，任务执行所需的模型推理及 MCP 工具链的运作，均需依托底层运行时环境的资源调度能力。

构建运行时环境后，Agent 的底层架构需依赖通用中间件能力以支撑核心服务。比如通过 Nacos 实现 Prompt 提示词的统一管理及 MCP（模型控制器）的动态注册与发现；通过 AI 网关对多模型和 MCP 实施集中代理；同时借助消息队列完成长周期、多阶段任务的异步化改造

构建 AI Agent 时，其运行时的可观测性是确保系统稳定性与优化能力的关键环节。由于 Agent 的运行逻辑具有动态性与不确定性（如多轮推理、事件驱动行为等），需通过数据采集探针实时监控其内部状态。比如 LoongSuite 开源探针去采集 token 消耗、模型输入输出等等。有了这些东西，我们可以对 AI Agent 的性能、成本和质量进行分析。

以上就是我们的全景图。

讲解完基础概念之后，那么我们来聊聊 AI Agent 在开发过程中，需要关注的关键问题。

Workflow 模式 vs Agent 模式：搭建 Agent 的时候，我们该用哪种模式？

Workflow 模式其实很简单，我们在编排业务时把一些固定的流程，通过预定义的步骤，通过低代码或高代码平台的方式编排出来。好处就是确定性很高。传统的业务流程、一定不能出错或者确定性强的业务流程，我们可以通过这种模式进行。但在面对复杂场景或任务时，Workflow 就会显得捉襟见肘。比如需要完成非常高不确定性任务的 Agent，会不知道某环节的下一步该怎么走，在这种场景下，可以通过 Agentic 模式，通过大模型来告诉你下一步应该如何执行，完成规划和执行。好处就是灵活性会比较高。比如说现在常见的 Deep Research，还有 Coding Agent，使用的就是 Agentic 模式。

在业务实践中，技术选型往往需要在准确性与成本效率之间进行权衡。当业务对结果准确性有硬性要求（如图像识别中的关键字段提取、发票信息结构化等），需采用 Workflow，通过预定义规则链实现可验证的处理逻辑，以牺牲灵活性为代价换取可预期的准确率。与此同时，面对复杂文本信息提取等任务时，大模型虽具备更强的语义理解能力，但其计算成本显著高于传统方案。实测数据显示，GPU集群处理此类任务的成本可达CPU方案的10倍以上。这个时候我们需要去权衡到底用 workflow 模式还是 Agentic 模式，但最后也可能是通过混合架构设计实现平衡。

单 Agent vs 多 Agent：我们需要单 Agent 还是多 Agent?

第二个话题是单 Agent 和多 Agent，什么情况下应该用单 Agent，什么情况要做多 Agent。在目前实践中，针对简单、目标明确的场景，我们推荐使用单 Agent 方式。单 Agent 的好处是开发和维护相对简单，但也存在一些局限性，比如模型上下文窗口是有限的，当 Agent 越来越复杂，一步一步执行的时候，每次会带越来越多上下文。当上下文达到一定窗口的情况下，这个模型会出现一些幻觉，甚至出现一些不确定行为。这时候我们就要考虑是不是通过一个 Agent 就能够完成，因此我们要考虑做一些拆分。原则就是说在如无必要的情况下，勿增实体，也是奥卡姆剃刀原理，总的来说在正常情况下尽量使用单 Agent。

当然，在明确发现任务执行起来非常复杂，需要复杂协作的场景，建议用多 Agent 来完成。而且多 Agent 有个好处，在完成同样编码任务，用同样的模型时，如果使用多个 Agent 的协作，相比单 Agent 模式，可以大大提升复杂场景准确率。这是经过实验或者各方面的实践验证出来的效果。

比如示例的 Deep Research 就是多维性的典型场景，有一个 Leader 负责把任务进行拆解，把任务中具体的调研设计任务分配给子 Agent，然后再由他把子 Agent 结果进行汇总并返回给用户。

提示词工程 vs 上下文工程：提示词工程如何实现，还是选择流行的上下文工程？

第三个就是提示词工程和上下文工程。提示词工程是之前比较火的概念，主要解决怎样跟模型交互，提出正确问题，让模型能够准确地回答这个问题。核心关注点是提示词要包含比较清晰的上下文以及示例，另外还有一些关键词等等，构成我们的提示词。

但发现最近 Context Engineering 这个概念越来越流行。原因在于 Agent 越来越复杂，Agent 在执行过程中有很多不确定性，再加上模型的上下文又是有限的。因此，我们要解决如何在有限的上下文窗口里给模型最有效的信息。

在复杂场景中，模型输入需要整合多源信息，包括提示词、RAG 检索的文档、工具调用结果及当前上下文状态，这一过程被称为上下文工程。这些内容需精准筛选并组装相关信息，确保模型能基于完整且高效的上下文执行任务这就成为一门很讲究的艺术了：我们要怎么去把这些东西组装成在一起提供给模型。同时，推理效率与 KV 缓存密切相关：通过前置固定内容（如通用模板、常量参数）并后置动态数据（如实时输入），来提高缓存命中率，减少重复计算开销。这样的话，其实在前面很多的内容是固定的情况下，能够去命中 KV Cache 在推理的时候的缓存。这种对信息层级和缓存机制的精细化管理，已成为提升 AI 代理性能的核心方向。上下文工程也成为目前比较需要大家关注的方向。

在解读完上面的三个问题，接下来介绍一下 AI 原生应用的参考架构。以 AI Agent 为核心，其运行依赖于多种技术组件协同。Agent 本身可通过不同开发框架构建，并部署于计算实例中，通过调用数据库或向量数据库获取外部数据支持决策。用户请求首先经过 API 网关接入系统，随后转发至 Agent 模块，该模块通过统一 AI 网关与模型进行交互。AI 网关作为关键代理，承担多模型调用的协议转换、token限流等通用能力，尤其在多模型并存的场景下，有效协调不同模型接口的差异性。在模型交互过程中，它承担重要角色，通过 Nacos 实现对公有和私有服务的统一注册与动态提示词管理，确保模型调用的灵活性与可扩展性。对于涉及长周期处理的异步任务，系统依赖消息事件机制完成状态管理，通过事件驱动的方式解耦任务执行与响应流程。所有组件产生的可观测性数据（如性能指标、调用链路）均通过标准 OpenTelemetry 协议采集，由 LoongSuite 探针统一汇聚至可观测平台，用于实现系统诊断、模型效果评估及运行时优化。

接下来的话我会介绍一下这几个关键的组件。

Spring AI Alibaba

第一个 Spring AI Alibaba，它基于开源的 Spring AI 组件，封装了更多能力，比如支持 workflow、Agent 的模式，以及单 Agent 多 Agent 的一些抽象配置，帮助 Java 应用开发者去更好的开发 AI 原生应用。在此基础上，我们构建了更上层的业务场景，也就是通用的 Agent 叫 JManus，就是 Java 的 Manus 实现。还有一些典型垂直类的 Agent 场景，比如 Deep Research、Data Agent 等等。Spring Al Alibaba 对于 Java 开发者来说，是开发 AI 应用时，能立刻上手、功能相对完整的框架之一。

Nacos

在 AI 原生应用场景中，Nacos 作为动态配置管理与注册中心的角色进一步延伸至 MCP 服务治理领域。当 Agent 需要访问传统微服务或第三方工具时，可通过本地启动的 Local Server 将服务转换为 MCP 接口，或通过远程 MCP Server 调用传统服务。对于涉及企业敏感数据或内部业务逻辑的 MCP 服务，需通过私有化部署的 MCP 注册中心实现统一管理。既满足了 AI Agent 对异构服务的灵活调用需求，又保障了企业级服务治理的安全性与可控性。

Higress

Higress 是 AI 网关的核心角色。中间的这块东西就是我们的 AI 应用和模型之间有一个核心的 AI 网关的代理能力，它可以做到一些核心的 AI 能力，比如 LLM 缓存，向量的一些检索，还有像 token 的一些限流。在安全方面包括一些协议的适配，我可能要去适配多个 OpenAI 模型的协议，以及 API 的统一管理。然后最近在做的主要就是 MCP 代理的这块，就是怎么把一些私有化或者公共的 MCP 服务统一地暴露给 Agent，并且做一些细粒度的认证，以及动态发现等一些能力。另外，协议转换也是比较重要的一块能力，就是把一些传统的 OpenAPI 的协议转成标准的 MCP 协议，都是可以通过这个 AI 网关和 MCP 网关来承接的。

Apache RocketMQ

在 AI Agent 的复杂交互场景中，Apache RocketMQ 通过消息队列机制解决了多轮对话中的状态恢复与重试成本问题。当 Agent 与模型进行多阶段交互时，中间结果（如阶段性响应、流式输出）通常以临时状态形式存在，一旦网络中断或服务异常，传统架构需从头发起 GPU 计算的重试流程，其成本可能是 CPU 时代微服务场景的十倍以上。RocketMQ 创新性地将 AI 框架下的会话（session）映射为消息队列的 Topic，将所有中间状态实时写入队列存储。例如，网关作为消费者订阅该 Topic 并逐步将结果推送给客户端，若当前网关节点故障，系统可动态切换至备用消费者节点，新节点可通过订阅同一 Topic 获取已存储的中间数据，从而实现断点续传式的恢复能力。这种设计避免了 GPU 资源的重复消耗，同时通过消息队列的持久化特性保障了长周期任务的可靠性。

接下来是可观测性的一些介绍。在应用 AI 应用的开发过程中，总结下来可观测性有三大痛点。第一个怎么把它用起来，第二个是怎么用的省，第三个是怎么用的好。

第一个问题是，当我们把这些应用搭起来，调用模型的过程中发现，推理过程特别慢，特别卡，或者是有报错，不知道卡在哪里，它解决要怎么把它用起来的问题。然后第二个就是发现用了一段时间之后，怎么这个账单突然一下子就爆炸了，或者这个 token 怎么消耗这么多，到底消耗在哪了，不知道怎么把它用得更加经济节省。然后第三个就是模型回答的质量好不好，我们也不清楚，需要对它进行评估，就怎么把它用得更好，解决这三个问题。

解决这三个问题，首先要在整个 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）。TTFT 取决于什么呢？上下文 input 给到模型，到模型吐出第一个 token 的时间，这个叫做首包延迟时间，它决定了我们的模型推理的流畅度。TPOT就是从第一个首包出来以后，再到它把所有的包都出完，再除以它的耗时，得到的指标数据叫做 TPOT，就是说首包延迟以后，后续平均的每包的传输时间，这反映了模型在 decode 阶段的关键性能。所以这两个指标是一定要关注的。在一些模型推理的关键阶段，KV Cache 的缓存命中率以及 GPU 的一些利用率等等，包括一些吞吐的能力也是需要关注的。在评估的场景下，主要是要关注准确性、偏见、毒性等指标。

刚才说了指标，另外一个重要方面是 Trace。它能够帮我们非常清晰地看到模型推理调用内部一个实时的运行状况到底经过了哪些节点。在这里怎么看呢？比如说我们通过标准的 OpenTelemetry 的 Tracing 协议，可以采集到每个关键的环节。这个截图里面使用一个 Dify 构建起来的一个 workflow，去调用一个 vLLM 的一个模型。那么通过这个调用链，可以看到它的时间，总的 token 消耗以及它的 input 和 output 是什么。每一个 Dify 下面的 workflow 的关键节点信息，以及它的耗时分别是什么。因此我们可以看到耗时比较长的是在这个 LLM 调用这个阶段，在这个阶段它的 token 消耗是这么多，然后再到模型内部，通过全链路追踪的能力，把模型内部的调用过程也会反映出来。通过这个 trace 能够准确地看到每一次执行的情况。

最后就是评估，评估是在 AI Agent 这个场景下非常重要的概念。它相当于传统软件开发里的回归测试。这个流程是循环结构，而不是一次性行为。

我们在开发阶段开发出 Agent 之后，通过 tracing 记录模型的输入输出，对它进行初步评估。这个评估有两种类型，一种叫做人工评估，它比较适合在 AI 应用开发的前期去进行。需要人为核对 AI 应用的结果是不是符合预期。首先挑选一些固定的 case，我们明确知道这个模型的返回结果的那种 case，然后人为地去评估这个运行的结果是不是满足预期。当到达一定的稳态以后，我们可以把它转为 LLM 评估，就是用第三方的模型来帮我们进行评估，这样的话可以更好的提升扩展性和效率。这个流程从评估完成以后到线上部署，我们会线上持续地去追踪这个线上的数据，就刚才说的指标 tracing 以及日志等等一些能力，去反馈和优化我们的 Agent。然后再通过 Agent 的不断地去迭代，循环往复。

在评估的时，有哪些重点要关注的地方？分三个阶段，一个叫 Planning。Planning 就是模型在拆分任务，或者说 Agent 在拆分任务的时候，它到底拆分的准不准确，有没有重复的，或者有没有拆分的足够准确，是否绕了弯路等等。这些方向是我们在评估时需要重点考虑的一些要素。

还有一块是工具的调用。很多时候模型的输入不稳定，是因为 tools 调用有问题，没有选择正确的 tools。第二个是可能在 tools 参数识别的时候识别的不准确，传递了错误的信息。这些东西都是要在评估阶段关键考虑的。还有像 RAG 阶段，在召回的过程中，需要关注语料的一些召回是不是有相关性，是不是有重复等等。

有了这些以后，我们可以把这些数据送到可观测平台。这个平台里面我们可以去持续的自动化的定时地去抽取一些线上的运行的数据，然后对它进行评估。我们定义好了这些评估模板以后，就可以自动化的线上持续运行了。然后通过评估可以把这些结果打出分数，帮助我们数字化分析。

最近我们刚刚发布了开源项目 LoongSuite。Loong 是中文的龙的意思，Suite 是采集套件的意思，我们希望在开源的 OpenTelemetry 社区基础上，提供针对 AI Agent 开发所需要的各种框架的一些自动化采集探针能力。比如说有 Java 的，有 Go 的和 Python 的探针。这探针针对我们刚才说的用不同语言开发出来的 Agent，能够去自动捕获它的一些数据，包括指标 trace，还有日志 input、output 这些东西可以送到开源的一些存储，支持任何以 OTLP 协议，也就是标准的 OpenTelemetry 协议兼容的控制台，比如说 Jaeger 或者是 Elastic Search。这些也可以上报到云服务上面，通过云平台来帮你完成这些数据存储和展示以及托管。基于此来完成性能成本和质量分析与评估。

最后简单介绍一下刚才提到的几个开源项目的一些规划。

来源：阿里云云原生一点号