开篇
Cloud Native
4 月初，我和大家分享了阿里云云原生团队在MCP 范式构建新一代 AI 应用架构" data-itemshowtype="0" linktype="text" data-linktype="2">基于 MCP 范式构建新一代 AI 应用架构的整体思路，这段时间我们与很多客户进行了交流，也一直在讨论。虽然这个思路大家普遍认可，但之前的核心还是围绕着网关在构建。如果站在 AI 应用的角度，其实缺失了运行时部分，也就是 AI Agent 的构建方案。
经过 3 个月的产品打磨和众多客户真实需求及场景的了解，我们发现，企业希望自己的业务被 AI 赋能的诉求是强烈的，但是在构建企业级 AI 应用，或者使用 AI 赋能现有业务方面，大多数企业是不知道从哪里下手的，都是只有一些碎片的知识点，尤其是对现存业务、Agent、LLM、MCP 服务、AI 可观测这几者之间如何有机协作是模糊的。
所以我基于当前阿里云云原生产品的能力、解决方案、和客户共建汲取的经验、企业的实际使用情况等，尝试理清楚完整的企业级 AI 应用构建的最佳实践，希望能带给有需要的企业一些帮助。
由于整体内容比较庞杂，我们将从 AI 应用的定义、AI 运行时、AI 网关、MCP、AI 观测等维度，通过系列文章的方式与大家交流。系列文章我们都将首发在阿里云云原生公众号，欢迎大家关注。
下面，就让我们从什么是 AI 应用开始聊聊。
什么是AI应用
Cloud Native
我们先来尝试定义什么是 AI 应用。
从“工具”到“智能伙伴”的进化
对于应用而言，我们早已不陌生，从桌面软件到手机 App，它们是帮助我们处理特定任务的工具。然而，当我们谈论“AI 应用”时，我们所指的已不再是简单的工具，而是一种全新的、能够模拟甚至超越人类部分认知能力的智能实体。
传统的软件应用遵循着一套预设的、固定的逻辑。它们是被动的执行者，严格按照人类编写的规则运行。你点击“保存”，它就执行保存操作；你输入公式，它就计算出结果。其本质是一个高效的指令处理器。
而企业级的 AI 应用，则标志着一场根本性的范式转移。它不再仅仅被动地“听令”，而是能够主动地“理解”、“思考”和“行动”。想象一下：
你不再需要手动在 CRM 系统中翻找客户资料、分析销售数据、然后撰写跟进邮件。你只需对 AI 销售助手说：“帮我总结一下 A 客户上季度的所有互动，并起草一封关于我们新产品线的跟进邮件。”
财务总监不再需要整合来自多个部门的 Excel 报表来预测现金流。他可以向 AI 财务分析师提问：“根据当前的销售趋势和供应链风险，预测公司未来六个月的现金流状况，并高亮潜在的风险点。”
在这些场景中，AI 应用扮演的不再是冰冷的工具，而更像一个不知疲倦、知识渊博、反应迅速的“智能伙伴”或“数字员工”。这便是 AI 应用的魅力所在，也是其核心价值——将人类从重复性、流程化的工作中解放出来，聚焦于更高层次的创造、决策和战略规划。
那么，是什么赋予了 AI 应用如此强大的“智能”？
AI Agent + LLM 的双引擎模式
在 AI 应用中，LLM 扮演着认知核心，也就是“大脑”的角色。它负责处理所有与“思考”相关的任务：
理解意图：当用户用自然语言提出复杂需求时，LLM 负责精准地理解其背后的真实意图。
规划任务：它能将一个模糊的目标（如“分析销售数据”）分解成一系列清晰、有序的步骤。
简而言之，LLM 为 AI 应用提供了“智商”。然而，仅有“思考”能力是远远不够的。一个只能在“脑中”规划万千大事却无法付诸行动的大脑，在商业世界中价值有限。所以要让智慧落地，就需要 AI Agent 这个“执行官”的登场。
AI Agent 赋予了 LLM “手和脚”，让“思考”得以转化为“行动”。如果说 LLM 负责“思考做什么”，那么 AI Agent 则负责“如何去完成”。它的核心职责包括：
工具调用：这是 AI Agent 最关键的能力。它可以根据 LLM 的规划，去调用各种外部工具来执行任务，例如查询数据库、调用公司内部系统的 API、访问互联网、读写文件等。
任务执行与编排：Agent 负责管理整个任务流程，确保 LLM 规划的步骤被逐一、准确地执行。
与环境交互：它能将执行结果（如数据库查询返回的数据）反馈给 LLM，供其进行下一步的思考和决策，形成一个“思考-行动-观察-再思考”的闭环。
AI Agent + LLM的组合，创造了一个既能深思熟虑又能高效行动的完整体。LLM 的智慧通过 Agent 的执行力在真实世界中产生了切实的业务价值。这正是现代 AI 应用区别于过去所有软件的根本所在。
企业能力的核心 - MCP 服务
AI Agent 的强大，并不在于其自身，而在于它能调动多少“资源”和“能力”。一个无法连接任何真实业务系统的 Agent，就像一个被关在“信息茧房”里的天才，空有智慧却无处施展。因此，为了让 AI Agent 能够真正在企业环境中大展拳脚，我们需要让其学习和成长。
我们构建 Agent，就好比我们玩角色扮演游戏，比如在博得之门里创建的角色，他/她有种族、职业、背景、属性点、技能和初始能力。但只有这些基础的初始能力是无法立足在充满危险的被遗忘的国度的。所以角色需要成长和学习新的技能，而同样是一名初始法师，随着学习的技能不同，会成长为不同能力的法师，比如学习了严酷收割、亡灵仆役等技能的死灵法师。学习了造水术、蛛网术的咒术法师。学习了火球术、闪电束的元素法师等等。
在大多数的角色扮演游戏中，都有着完善的技能系统。在今年年初，若想要给 AI Agent 构建技能系统和体系是有着很高成本的，AI Agent 要学习一项新技能（即使用一个新工具），开发者可能需要做两件成本很高的事：
改造该技能或工具背后服务的代码，做 API 协议适配、定制等集成方案。
相当于我要教你一个技能，先得改造这个技能，改造为你能听懂的方式。
改造 AI Agent 自己的代码。
相当于改造你的基因，要么使你与生俱来就会这个技能，要么让你知道如何学习这个技能。
然而一家客户的沉淀短则几年，长则十几年，内部已经有茫茫多的系统、服务、接口，也就是这些技能都是现成的，且都是上古秘法，没法改，也没人会改。那么就得改 AI Agent，带来的后果就是几乎没有复用性、没有扩展性、开发成本非常高。
所以 MCP 的出现，很好的解决了构建 AI Agent 技能系统的痛点问题：
规范化了多者的协同关系：MCP 协议规范约束了用户、AI Agent、LLM、后端服务四者之间的系统关系。
AI Agent 和后端服务快速对接：无需后端服务改造，也无需 AI Agent 改造，无需了解和解析后端服务接口的返回格式。
所以，MCP 服务是企业 AI 应用的基石。它将企业零散的 IT 资产和服务，转化为 AI 可以理解和调用的标准化能力，从而为上层的 AI Agent 源源不断地输送技能。
构建 AI 应用的两种路径：全新开发 vs. 存量改造
在理解了 AI 应用的内在构成后，我们面临一个实际问题：如何将它构建出来？从逻辑上看，企业构建 AI 应用的路径主要有两条：
1. 全新开发：开创业务新大陆
这指的是从零开始，为一个全新的业务场景或颠覆性的产品构想，原生设计和开发 AI 应用。这种模式不受历史技术债务的束缚，可以采用最先进的架构，最大化地发挥 AI Agent 的能力，是实现颠覆式创新的最佳路径。例如，打造一个面向金融行业的 AI 研究分析师，或者开发一个企业内部的“超级知识入口”。
2. 改造现有业务：为核心引擎注入 AI 动力
这是绝大多数企业会选择的路径。它指的是在企业现有的、成熟的核心业务系统（如 ERP、CRM、SCM）中，嵌入 AI Agent 的能力，对其进行“智能化升级”。这种方式能直接作用于核心业务流程，价值释放路径更短、更明确。
在 CRM 中嵌入 AI，它可以自动分析客户，并推荐下一步跟进动作。
在 ERP 中嵌入 AI，它可以基于实时数据进行需求预测，动态优化库存水平。
在 OA 中嵌入 AI，它可以辅助员工起草公文、智能填单、优化审批流程。
在我们和众多客户的交流中来看，改造现有业务，本质上是将业务入口从请求到传统服务改为请求到 AI Agent。
AI 应用基本架构
一个真正的企业级 AI 应用，是一个由“LLM 大脑”提供智慧，由“AI Agent 执行官”负责行动的智能系统。它的能力边界，取决于企业为其打造的 MCP 服务有多强大，数量有多少。而它的落地形式，既可以是开疆拓土的全新创造，也可以是为现有核心业务的深度赋能。理解这一全景，是开启企业 AI 转型之旅的第一步。
如我上文所说，大多数客户的诉求都是 AI 赋能现有业务，也就是将业务入口从请求到传统服务改为请求到 AI Agent，现存的传统服务都可以转为为 AI Agent 赋能的技能库。
所以将 AI 应用架构拆开来看，整体架构及调用链路如下图所示：
一个 AI 网关三种角色，具备统一的管控底座，同时又实现各角色的协同调度。
微服务引擎MSE Nacos 发挥注册中心优势，增加 MCP Registry 能力，实现普通服务和 MCP 服务的统一管理，结合网关实现现存业务 0 改造转换为 MCP 服务。
AIStudio 为阿里云自研的低代码构建 AI Agent 的产品，解决开源 dify 高可用、稳定性、性能问题，使 AI Agent 的运行引擎更稳定。
函数计算 FC 具备丰富的触发器和各语言运行环境，基于 Serverless 计算自身的特性，完美适配 AI Agent 自身运行环境和 Agent Sandbox 的基础组件。
图中的8 步核心调用链路解析：
第一步：用户向 AI 应用发起请求，请求流量进入 AI 网关，使用 Agent API 代理 AI Agent。
第二步：AI 网关侧维护管理了不同类型的 AI Agent 的 API 或路由规则，将用户请求转发至对应的 AI Agent。
第三步：AI Agent 无论以哪种方式实现，只要它需要使用工具解决用户的问题，便向 AI 网关管理的 MCP 服务请求获取可用的 MCP 服务及工具的信息。
第四步（可选，目前需要用户自行实现）：因为 AI 网关处可能维护了很多 MCP 信息，可以借助 LLM 缩小 MCP 范围，减少 Token 消耗，所以可以通过 AI 网关代理的小参数 LLM，做意图识别，进一步缩小 MCP 服务范围。
第五步：AI 网关将确定好范围的 MCP 服务及工具的信息 List 返回给 AI Agent。
第六步：AI Agent 将用户的请求信息及从 AI 网关拿到的所有 MCP 信息再通过 AI 网关发送给 LLM。
第七步：经过 LLM 推理后，返回解决问题的一个或多个 MCP 服务和工具的信息。
第八步：AI Agent 拿到确定的 MCP 服务和工具的信息后通过 AI 网关对该 MCP 工具做请求。
实际生产中 ③ - ⑧ 步会多次循环交互。
所以从组成结构来看，AI 应用的核心有四点，AI Agent、LLM、MCP 服务、AI 观测体系。并且核心中的核心是 AI Agent，因为用户、LLM、MCP 服务都是靠 AI Agent 连接的，AI 观测体系也是会以 Agent 为枢纽。本文后续也是持续围绕这四个核心的要素，和大家探讨如何实践落地上述架构。
AI Agent 概述
Cloud Native
同样，我们先来定义什么是 AI Agent，所谓“一千个人眼中就有一千个哈姆雷特”，大家对 AI Agent 的认知都不一样。Agent 可大可小，比如一套复杂的系统可以认为是一个 Agent，一个流程也可以认为是一个 Agent，甚至一行代码也可能被认为是一个 Agent。那么 AI Agent 到底有没有定义呢？
其实 AI 御三家（Google，Anthropic，OpenAI）在 AI Agent 白皮书里都有定义，并且都有共性，我们可以从三个白皮书中抽象出 AI Agent 的定义。
Google AI Agent 白皮书【1】
Anthropic AI Agent 白皮书【2】
OpenAI AI Agent 白皮书【3】
什么是 AI Agent
Cloud Native
一个 AI Agent 其实是一个系统，包括以下三个核心内容：
使用大语言模型（LLM）来推理。
可以通过工具执行各类行动。
执行思考（Think） -> 执行（Action）-> 自省（Observe） -> 纠错（既重复思考到自省的持续改进）这样一个循环。
AI Agent 和 Chatbot 的最大区别是前者可以解决需要通过不同领域的知识和能力协同才可以解决的问题，通俗地说就是复合的、复杂的、多步骤的问题。
来看看 Google AI Agent 白皮书对 AI Agent 的定义：
来看看 Anthropic AI Agent 白皮书对 AI Agent 的定义：
来看看 OpenAI AI Agent 白皮书对 AI Agent 的定义：
所以 AI Agent 断然不可能是几行代码写的程序，而是一个相对复杂的系统。
AI Agent 核心组件
一个 AI Agent 的构成有 4 个核心组件：
大脑，即大语言模型（LLM）
作用：识别自然语言，然后进行推理并做出决策。
原则：选择最合适的大语言模型。（不同的大语言模型有自己擅长的领域和业务场景）
手，即各类工具（MCP Server）
作用：为 Agent 提供外部能力、各类业务服务、数据库服务、存储服务等等，即执行 LLM 做出的决策。
指令，即系统提示词（System Prompt）
作用：定义 Agent 的目标和行为。
记忆，即存储服务（NoSQL 或向量数据库实现）
作用：让 Agent 记得目标、偏好，以及过往的交互信息，从而实现多步骤执行、自省等能力。记忆也分长期记忆和短期记忆。
Google 定义的 AI Agent 架构：
Anthropic 定义的 AI Agent 架构：
OpenAI 定义的 AI Agent 的核心组件：
AI Agent 推理模式
目前 AI Agent 的推理模式大体分为三类：
ReAct（Reason Act）：该模式是目前典型的，使用比较多的模式。即推理->行动->自省的循环。
链路思考（Chain of Thought）：这种模式类似流程，即一步接一步的执行逻辑。
树状思考（Tree of Thought）：更为复杂的推理模式，涉及到多计划、多任务的推理。同时探索不同的可能性和结果。
ReAct 模式
ReAct 是目前被验证最通用的 AI Agent 模式。需要具备以下四个要素：
推理（Reason）：分析、理解上下文，明确用户任务目标。
行动（Act）：基于推理的结果，执行对应的行动。
观察（Observe）：评估执行行动后得到的结果。
自省（Reflect）：评估是否需要继续推理->行动->观察以得到更趋近于用户目标的结果。
Google 对 ReAct 的定义：
AI Agent 通用推理模式
ReAct 模式是目前从效果、通用性方面来说比较好的模式，基于该模式，我们可以抽象出 AI Agent 的通用模式，或者说构建 AI Agent 能力需要具备的核心要素。也许不同的领域，不同的业务场景可能需要基于 ReAct 模式做微调，但无论如何，都需要考虑 AI Agent 通用模式里的 6 大核心要素。
提示词链路（Prompt Chaining）：本质上是 Agent 内部的工作流。
路由（Routing）：问题分类，针对不同分类，有不同的后续执行链路。
使用工具（Tool Use）：当前这部分的实现基本都会使用 MCP 范式。
评估循环（Evaluator Loops）：做自我修正，甚至会使用不同的 LLM 协助做修正。
协调器（Orchestrator）：可选，适用于一个 AI Agent 管理其他 AI Agent 的场景。
自主循环（Autonomous Loops）：可选，可以使用于让 AI Agent 自主决定一切的场景。
提示词链路（Prompt Chaining）
AI Agent 里的提示词链路其实本质上就是 Agent 内部的工作流，它将一个任务分解为一系列步骤，上一个任务的输出是下一个任务的输入，每个任务可能都会和 LLM 进行交互。
这种方式比较适合可以将任务清晰地分解为固定子任务的场景。比如市场营销、广告活动、CRM/ERP 中的问数流程等等。
Anthropic AI Agent 白皮书中对 Prompt Chaining 的定义：
Google AI Agent 白皮书中有编排层的概念：
路由（Routing）
AI Agent 里路由的作用是对输入进行分类，并将其导向一个专门的后续任务。这种模式可以使关注点分离，并构建更专业的提示词。
路由非常适用于那些具有明显不同类别、可以更好地分开处理的复杂任务（无论是通过 LLM 还是更传统的分类模型/算法）。最常见的场景就是智能客服，将不同类型的客户服务查询（一般问题、退款请求、技术支持）引导到不同的下游流程、提示和工具。
Anthropic AI Agent 白皮书中对 Routing 的定义：
使用工具（Tool Use）
工具是 AI Agent 与外部系统（例如 API）交互的关键。尽管基础模型在文本和图像生成方面表现出色，但目前它们依然无法与外部世界直接交互，或者说快速、低成本的交互（LLM Function Calling 受限 LLM 厂商的迭代）。工具弥补了这一差距，使 Agent 能够访问外部数据和服务，并执行超越底层模型自身能力的各种操作。而 MCP 的出现使得这个环节的能力、便利性、扩展性等有了质的提升。
Anthropic 在增强型 LLM 的构建块中强调了工具的使用，以及工具开发的最佳实践：
OpenAI 对工具做了专门的定义：
Google 详细介绍了工具（Extensions, Functions, Data Stores）及其在 Agent 架构中的作用：
评估循环（Evaluator Loops）
评估循环指的是一个 LLM 调用生成响应，而另一个 LLM 在循环中提供评估和反馈。这种循环可以使 AI Agent 进行自我修正，甚至可能使用不同的 LLM 来协助修正。这种方式适用于具有明确评估标准，并且迭代改进能够带来可衡量价值的场景。
在翻译场景会常用到这种评估的模式，因为用来翻译的主 LLM 最初可能无法捕捉到细微差别，但评估 LLM 可以辅助提供评估信息，然后翻译 LLM 做修正。还有联网搜索或深度研究这类需要多轮搜索和分析的场景，也会用到这种评估模式，其中的评估 LLM 决定是否需要进一步搜索等。
Anthropic AI Agent 白皮书中专门介绍了评估循环这个模式：
OpenAI AI Agent 白皮书里虽然没有明确说明评估循环这个模式，但是提出了护栏（Guardrails）概念，这部分也体现了类似的思想，例如通过批评节点评估 Agent 输出是否符合预期并进行重试。
协调器（Orchestrator）
AI Agent 协调器的作用是一个负责协调的 LLM 接收复杂任务，将其委托给工作器 LLM，并综合它们的结果。这适用于一个 AI Agent 管理其他 AI Agent 的场景。
这个场景和并行执行任务在拓扑结构上有点类似，但也有区别，这种模式更加灵活，因为子任务不是预先定义的，而是由协调器根据特定输入确定的。这种模式适合无法预测所需子任务数量的复杂任务。
Anthropic AI Agent 白皮书中详细介绍了“协调器”：
OpenAI 的“管理器模式”也描述了类似的架构，其中一个中心“管理器” Agent 通过工具调用协调多个专业 Agent：
自主循环（Autonomous Loops）
AI Agent 系统是由 LLM 动态指导其行为和工具使用，保持对如何完成任务的控制的系统。自主循环指的是 AI Agent 初始接受人类的指令，会明确任务，一旦任务明确，Agent 会独立规划和执行行动，直到返回人类最终的答案。
这种模式用于难以或不可能预测所需步骤数量，且无法硬编码固定路径的开放式问题。比较典型的就是 Chat 场景里的深度研究（DeepSearch）和 AI 编码场景。以及像 Manus 这种 Planning 的方式也是类似自主循环的模式。
但这种 AI Agent 的自主性有两个最大的问题：
返回结果的不确定性。一自主起来就容易发散。
对整体环境的影响。一自主起来产生的数据，占用的计算资源等容易对整体环境产生影响。
解决这两个问题，业界也已经有较为成熟的方案，用一句话来总结：使用资源/数据隔离的沙箱环境来运行/训练/强化学习 AI Agent 的特定能力。
Anthropic AI Agent 白皮书里讨论了自主 Agent 的适用性和风险：
AI Agent 安全与防护
最后我们来看在任何时代，任何领域都非常核心的安全与防护，在 AI 时代同样不例外。大体可以抽象为四个方面：
限制 Agent 执行行动的次数，也就是限制迭代循环测试：AI Agent 在执行任务时，通常会以循环的形式进行推理、行动和观察，直到达到目标或满足某个停止条件。为了防止 AI Agent 陷入无限循环、耗费过多资源或产生累积错误，需要对其迭代次数和行动设置限制。
在关键步骤需要人工审核：人工审核是一种重要的安全防护措施，它在 Agent 的决策或执行流程中的关键点引入人类干预，以验证 Agent 的判断、纠正潜在错误或处理高风险操作。
输入输出内容审核：对 Agent 的输入和输出内容进行严格审核，是防止不当、不安全或不相关信息进入系统或被生成的核心防护。这包括检测有害内容、个人身份信息（PII）泄露、离题查询以及试图绕过 Agent 指令的“越狱”攻击等。
沙箱运行环境：沙箱环境是一种隔离的运行环境，其背后的本质是资源隔离、数据隔离，从而实现多租户隔离。在资源隔离、数据隔离的前提下更有利于做 AI Agent 的自身的运行环境，或者训练/强化学习。
AI Agent 的构建模式
与 AI Agent 类型
Cloud Native
目前构建 AI Agent 的方式大体可分为两类：
编码构建类：编码类构建 AI Agent 又可以分为两类。
基于上文中 AI Agent 的核心要素和通用推理模式纯手撸代码实现。
基于市面上主流的 AI Agent 综合框架快速实现。但这些综合框架不一定能实现上述所有的推理模式，所以还是需要基于客户的真实业务场景，额外自行编码做辅助优化。比如以下这些框架：
LangChain
LangGraph
OpenAI Agents SDK
Vertex AI Agents
Crew AI
Pydantic AI
Spring AI Alibaba
低代码构建类：这一类就是通过可视化的流程编辑器，通过拖拖拽拽的方式构建 AI Agent。比如阿里云 AIStudio、阿里云百炼、字节扣子、Dify、N8N 等。
基于不同的客户类型和业务场景，AI Agent 的类型又可以大体分为三类：
辅助基模（基础大语言模型）的 AI Agent：当今基模的联网搜索、深度研究（DeepSearch）、编码能力都是需要 AI Agent 辅助的，这类 AI Agent 并不直接对用户透出。我们的实践中像 Qwen3、智谱 GLM 等都属于这一类，通常都是做基模的公司会涉及到，并且以编码方式构建为主。
作为独立产品的 AI Agent（通用 AI Agent）：这类 AI Agent 大都还是基于主流的 Chat 模式，帮用户解答问题，规划任务等。我们的实践中像 OpenManus、JManus、MiniMax Agent、昆仑万维等都属于这一类，通常都是做基模或者专门做通用 AI Agent 产品的公司会涉及到，并且以编码方式构建为主。
辅助现存业务的 AI Agent：这类 AI Agent 就是目前广大互联网客户、泛企业客户期望构建或正在构建中的 AI Agent，和客户自身的业务耦合比较紧密。我们的实践中像知乎、运满满、义乌小百货等都属于这一类，并且以低代码构建方式为主。
总结
Cloud Native
至此，我们基本上了解了 AI 应用的定义，AI 应用的核心是什么，以及 AI Agent 的定义和推理模式。在如何构建 AI Agent 方面，在这个系列中，我们不会详细聚焦在本文中提到的如何通过编码的方式实现上述的六类推理模式，因为每个客户使用的开发语言不同、每个构建 AI Agent 的综合框架的使用方式不同。更重要的是这些推理模式的实现往往和客户的业务场景，客户的运维研发体系是强相关的。
另外，现如今，LLM 的 Coding 能力都是不弱的，Vibe Coding 的概念目前也是如火如荼，开发程序的门槛几乎已经触底。所以现在最简单的事反而就是写代码，但最难的事是让这坨代码能真真正正的承载业务并运行在线上。
所以本文核心聚焦在当客户想要实现某一类型的 AI Agent 时，该如何选择和使用 AI Agent 最合适的运行时，这一类的 AI Agent 都应该注意哪些核心问题，构建 AI Agent 的核心组件时该如何将上下游产品有机结合起来配合使用。