随着 LLM 在近些年的发展，模型参数规模与多模态等能力同步提升，云厂商、芯片公司、数据标注、微调平台等各类基础设施的能力也不断提升。基于 LLM 研发的应用程序也变得越来越复杂，从一开始的简单对话问答，到加入向量检索召回能力的 RAG 模式，慢慢发展到开发者编排工作流并在关键节点用模型驱动，以及到当前最复杂的用模型自身规划流程的 Agent 模式。至此，AI 应用研发不再是一次性的模型调用，而是围绕数据飞轮、评估体系、持续产品迭代运营的综合范式。
在本文中，我们会基于在阿里巴巴内部 AI 应用研发的经验观察，同时结合业务相关研究和开源产品的进展，围绕 AI 应用研发这一主题分析一些已经逐渐浮现的模式。
首先我们会分析 AI 应用的架构，这里的核心是复杂度最高的 Agent 模式架构；然后我们会从应用交付的视角去看 AI 应用和传统应用在研发交付阶段的差异点，包括一些新的问题，如模型的切换升级，如何评测 AI 应用的能力等等。
随后本文会重点展开介绍支持 AI 应用研发的基础设施，包括围绕应用流量的 MaaS，MCP 工具，围绕运行时的 Sandbox 技术，以及围绕研发运维生命周期的 AI 应用观测和评测。
最后我们还将分析 AI 在应用程序中的引入给安全带来哪些新的挑战，包括提示词注入，工具使用安全，Sandbox 隔离，以及需要全新设计思考的身份和授权体系。
虽然 AI 应用研发是一个较新的技术方向，但本文的作者都已经在领域内积累了多年经验，包含 Agent 产品的架构、相关基础设施的核心研发等。同时我们也深入调研访谈了阿里巴巴内部众多研发 AI Agent 的业务，对他们的架构和遇到的挑战也有比较深入的分析，因此本文的描述也会包含很多最佳实践和深入洞见，相信这些内容能给读者们带来启发与价值。
AI 应用架构
回望 ChatGPT 刚发布，直至今天大家广泛使用的 AI App，AI 应用就是一种简单的对话模式，用户编写 prompt 提交给模型，从模型获取知识返回。但是由于模型训练方式的限制，它不可能包含大量实时和私有的数据，因此在对话模式的基础上产生了 RAG（Retrieval-Augmented Generation）模式，实时、私有的知识通过 query 的方式获取，然后通过上下文传递给模型做内容的整合。
以上两种模式都类似于信息的检索，相对比较简单。在企业中真正发挥更大价值的是第三种模式：AI 工作流模式。我们看到大量的工具产品，支持用户用拖拽的方式编排好固定的流程，这个流程通常是企业积累的专家知识，然后在这个工作流中的一些关键步骤用模型去实现，例如总结文本，分析图片/二维码等等，在模型的规划能力还不足的时候，这种模式为企业效率提升发挥了很大的作用，但显然它只适用于流程比较确定性的场景。
在更为不确定性的场景下，例如 AI Coding，开发者实现一个需求需要做大量的工作，包括需求分析、阅读代码、编码、测试、调试、阅读日志等等，这种时候一个固定的工作流无法解决问题，即便是人去实现也是需要不断循环制定规划，尝试执行，再根据反馈调整规划这个循环。这个时候 AI 应用逐渐发展到 Agent 模式，由 AI 来规划任务，执行任务，再通过观察和反思调整任务，循环多次后实现目标。
下图展示了几种模式的变化和差异：
<!---->Agent 模式的 AI 应用架构比较复杂，它需要实现用户请求解析，上下文收集，任务规划，任务执行，环境感知，以及相关的工具使用和记忆管理等功能。我们以一个单元测试生成的 AI Coding 任务来分析 Agent 系统的各个组成部分。
用户交互模块。这个模块负责接收用户的请求，并且围绕当前的上下文收集完整高质量的数据，然后转换成模型的请求。当用户在 IDE 中选择一个文件，告诉 Agent “生成单元测试” 的时候，这个模块就需要收集当前上下文中，代码的内容是什么，是什么语言，依赖的环境是什么（Python 还是 Java，具体什么版本），完整的代码仓库地址信息。
核心的 LLM 模块。这个模块负责核心的任务规划，并基于会话保存短期记忆。在收到完整上下文的“生成单元测试”任务后，该模块会生成一个计划，分析目标文件相关的多个文件内容，准备一个代码运行环境，生成目标单元测试代码文件，执行编译测试，验证测试结果等步骤。
环境模块。这个模块顾名思义是上述完整任务被执行的场所，它通常是一个隔离 sandbox 环境。“生成单元测试”的任务在这里被逐步执行。执行完毕后，LLM 模块需要通过感知模块收集环境信息，例如编译测试是否通过，是否出错，相关的日志信息等等。在环境模块中，任务执行往往还需要与外部工具交互，例如下载源代码，查询一些文档信息等等。
规划、任务执行、感知和反思是一个重复的过程，例如当编译失败的时候，LLM 可能需要根据错误日志调整自己的规划，可能是加入一个安装缺失依赖的步骤。
在任务过于复杂，上下文爆炸或者过长导致模型能力快速裂化的时候，记忆（长期）模块就需要被引入。Agent 系统需要基于业务特性精细地压缩记忆，保留关键的历史信息。
<!---->如上图所示的 Agent 系统架构决定了相关基础设施的建设方向。用户交互模块会更强调对用户当前上下文的理解，以厘清用户想做什么。环境模块会高度强调稳定性和任务执行的精确性，包括感知系统如何收集完整的环境信息，其实时性如何等等。MCP 相关的工具则围绕问题领域不断积累，让 Agent 系统能准确地执行越来越丰富的任务。这一架构也会决定安全设计的关注点，包括恶意注入的点在哪些地方，环境如何做到可靠的隔离等等，相关内容会在后面板块具体介绍。
AI 应用交付
AI 应用交付的特点
传统应用 CI/CD 主要围绕代码版本管理，采用确定性的功能测试，遵循线性的构建-测试-部署流程，监控重点在基础设施和应用性能指标。而 AI 应用 CI/CD 则面临多维度的供应链管理（代码、数据、模型），需要用概率性测试策略来验证模型性能和数据质量，采用包含数据验证、模型训练、持续反馈的复杂循环流程，并要求对模型性能变化、返回不一致等 AI 特有问题进行多层次监控。本质上，AI 应用 CI/CD 从传统的确定性软件交付演进为处理不确定性和动态变化的智能系统交付。
模型和框架选择
由于训练基础模型需要大量资源，大部分业务更倾向于从已有基础模型中进行选择，常见的如 GPT、Claude、Qwen、DeepSeek。在构建 AI 应用时应首先从多个维度，譬如质量、上手成本、费用、合规等进行基础模型和框架的选择。譬如按功能进行，通用对话场景可以选择 GPT-4，代码生成可以选择 Qwen-Coder；而如果企业考虑合规要求，往往选择 Qwen 系列等开源模型进行私有化部署。总之并不存在一个万能的模型。在 AI 应用更新迭代过程中，开发者也需要跟随业务变化进行模型的切换，在切换的过程中，往往需要进行新旧版本的评测、稳定性验证、prompt 调整等工作，以确保业务的稳定运行。
AI 应用交付核心流程
AI 应用相比传统应用具有更复杂的依赖关系，需要统筹代码、模型、数据三个核心维度的协同交付。为确保各组件的独立开发、部署和验证，我们建议采用环境隔离的方式，以保证各功能模块互不影响。通常我们将研发流程分为开发、集成、生产三阶段，每个环境具有不同的权限控制和稳定性要求。开发环境主要以进行编码为主，其权限、数据可信限制较低。集成环境以完成集测为主，用于验证产品功能，评测应用效果。生产环境则为权限要求最严格、服务稳定性要求最高的环境。
AI 应用研发基础设施
MaaS
MaaS（Model As A Service，模型即服务）是将包括 LLM、VLM、Diffusion/Flux、Embedding 等在内的具备不同任务处理能力的 AI 模型以服务形式提供给用户的技术模式，用户可通过 SDK/API 的方式快速应用 AI 模型强大的推理能力。其核心在于将复杂的模型训练、部署、运维、优化等底层专业性工作交给服务提供商，用户仅通过标准化接口就可以简单使用 AI 模型完成推理、自然语言处理、图像识别等任务，极大地降低了 AI 应用构建的复杂度。
记忆 (Memory)
根据现代汉语词典的定义，记忆是指对过去经验的保留与再现，简而言之，记忆就是对过去发生过的事情的描述。作为动词时，记和忆，分别对应把过去的经验或事件保留和再现的两个过程。在 AI 应用的整体架构中， 由于 AI 应用中的 LLM 不具备自我更新参数的能力，在多轮对话等应用中无法记住之前轮次的对话内容，因此无法具备和人类用户连贯的长期交互的能力。而应用了 memory 之后，AI 应用可以实现对先前交互内容的记忆，从而在长期交互的过程中保持更好的一致性和连贯性。
MCP
MCP 是模型上下文协议（Model Context Protocol）的简称，是一个开源协议，由 Anthropic 开发，旨在让大型语言模型（LLM）能够以标准化的方式连接到外部数据源和工具。AI 应用从简单的 Prompt 工程，到使用 RAG 模式，再演进到具备更丰富能力的 Agent 模式，其中工具的使用、环境的感知发挥了关键的作用，其中 MCP 是目前行业中应用最为广泛的技术。
如果 LLM 缺乏外部工具使用的能力，它被应用的场景会非常受限，仅能处理简单的问答、文本的情感分析、以及文本翻译等工作。为了让 LLM 发挥更大的价值，我们可以引入工具集成。提供诸如网络搜索、数据集和 API 等外部工具，能让大型语言模型的能力超越其训练数据的限制。
AI 网关
当今大模型以周为时间单位更新，AI 应用和组件以天为单位演进，企业须在安全、合规、成本、效率四重约束下交付稳定业务。传统网关解决了业务流量路由问题，但无法解决模型切换、Token 经济、语义缓存、内容风控新的等 AI 原生需求。AI 网关基于模型访问 + API 供应两个场景核心，通过抽象协议、统一治理、可观测、可插拔的设计原理，把“任何模型”和“任何业务 API”纳入统一控制平面，解决 MxN 重复建设问题，实现“周级迭代”与“企业级稳态”共存。
Sandbox
Agent 在规划和执行任务的时候，通常会涉及到代码的生成和运行。例如，当用户要求 Agent 去分析一家公司的运行状况时，Agent 就需要去使用工具抓取一些数据，生成一段 Python Pandas 代码，然后执行这段代码以绘制图表。除了代码运行之外，Agent 执行任务还会涉及到更广泛的 compute use 能力，其中比较典型的就是 browser-use，它可以让 Agent 在本地环境用拟人的方式使用浏览器，以及一些本地的 MCP Tool，例如很多软件支持私有化的部署并以 MCP Server 的方式提供服务（如：MasterGo Magic MCP）。无论是 Agent 运行代码，还是使用 browser-use 或者本地的 MCP Server 都需要一个可靠安全的环境，这就是 Agent Sandbox。
AI 可观测
AI 应用，尤其是基于大型语言模型（LLM）和多工具调用的 AI Agent 系统，其内部决策过程的复杂性与不透明性，使得传统的可观测手段（如 Trace、Metric）难以应对其模型推理波动、性能不可控及数据分布依赖等新挑战。Agent 全链路可观测能力正是解决这一“黑盒”问题的基石。它通过获取用户上报的 OpenTelemetry 数据，能清晰展示从用户输入、中间步骤（如 RAG 检索、工具调用、多轮对话历史）、Prompt 构造、模型生成到最终输出的全过程。所有关键节点的元数据，如延迟、Token 消耗、运行成本等，都会被精确记录并可视化。这不仅为开发者提供了无可替代的调试依据，更是所有后续评测、分析和优化的数据基础，让问题定位从猜想变为诊断。
AI 评测
在传统软件研发领域，软件测试是产品上线前不可或缺的“质量门”，我们可以通过单元测试、集成测试、UI 测试等多层次的测试手段来保障产品的“确定性”。在 AI 时代，尤其是大模型（LLM）驱动的 Agent 应用时代，这种“确定性”被打破了。AI 应用不再是简单的逻辑堆砌，它引入了“不确定性”和“智能涌现”：
输出不确定性：问同一个问题，模型可能给出略有不同的答案；调用同一个工具，结果可能因为外部环境变化而波动。
决策链路复杂：Agent 应用往往涉及多轮推理、外部工具调用（如搜索、API 集成）、RAG（检索增强生成）等复杂流程，其内部决策路径不再是固定不变的“代码分支”，而是动态变化的“思考路径”。
黑箱效应： 模型的内部工作原理对开发者而言是一个黑箱，我们无法像调试传统代码那样，一步步跟踪其“思考”过程。
安全风险： 传统软件的 Bug 可能导致功能失效，但 AI 的错误输出可能产生幻觉、泄露敏感信息，甚至在执行真实动作（如交易、控制物理设备）时造成巨大损失。
正因这些根本性差异，传统软件测试的那套“刀耕火种”的方法，在 AI 应用面前显得力不从心，甚至无效。对此，我们亟需一套全新的 AI 应用评测体系，最终确保我们构建的 AI 应用是可信赖的、高质量的、可持续进化的，将不确定性的 AI 转化为确定性的商业化价值。
AI 应用安全
应用安全风险及防护
Agent 应用在继承传统 Web 应用安全风险（如 SQL 注入、XSS、身份认证等）的基础上，还面临着由大模型和工具调用能力带来的新型安全挑战。与传统系统不同，Agent 不仅可以自动化执行复杂任务，还能通过提示词驱动跨系统操作，这使得其“攻击面”大幅扩展。例如，提示词注入可让攻击者远程操控 Agent 调用高危工具，间接访问或泄露敏感数据；Agent 本身的逻辑错误可能导致误操作或权限滥用；用户也可能主动发起有害请求，试图绕过合规限制或触发危险行为。随着 AI 驱动的自动化程度提升，Agent 应用的安全问题正从单点漏洞演变为系统性风险，亟需多层次的纵深防御和专门的安全治理体系。
Tools 使用安全
在 LLM 应用里，Tool 调用就像 Agent 的“手脚”：模型负责思考，Tool 负责与外部世界交互。一旦“手脚”被恶意指令劫持，伤害通常比回答错误更大——可能读写内网数据、泄露商业机密，甚至直接执行破坏性操作。因此，高危 Tool 必须运行在与宿主逻辑彻底隔离、可精细审计的受控环境中，以确保即便出现逃逸或资源滥用，影响也被限定在最小安全半径内。
身份与授权
由于 AI 场景的 VUCA 特征（易变性、不确定性、复杂性、模糊性）更加明显，这就需要 AI 应用场景下的安全协议，具备更高的灵活性和可靠性，从而实现对 AI 非预期性的兜底，防止出现权限泄露、访问越权、数据安全等相关风险。而 AI 场景下的认证（AuthN）和授权、鉴权（AuthZ），根据交互方的不同（如 Agent、MCP 等），针对不同的认证实体、授权主体以及被授权对象，会与传统 RPC/HTTP 的身份认证及权限管理存在一定差异，这些差异主要体现在交互方式、交互协议、授权流程、认证方案、鉴权协议、身份管理和令牌维护等方面。
大模型供应链安全防护
随着大模型在企业核心业务中的广泛应用，供应链面临的主要威胁就是大模型供应链投毒风险。其本质是：在训练数据集、模型权重、依赖组件、交付渠道等环节中，被恶意篡改或植入“后门”，导致模型携带潜在安全隐患。这类风险通常表现为两类：第一是模型投毒，模型权重或逻辑被恶意篡改。第二是数据集投毒，训练或微调过程中使用了被污染或恶意构造的数据。无论以何种形式出现，最终都会导致模型“带病上线”，对企业业务的稳定性与安全性构成威胁。
小结
阿里巴巴在历史上一直是以 Java 技术栈为主的公司，阿里巴巴中间件体系也主要是围绕 Java 技术栈构建。但是随着大模型的兴起，我们看到新的 AI 研发生态在这家公司的各个业务部门兴起，从数据上我们看到，在过去一年，相比较 Java 活跃开发者数量的略有下降，Python 活跃开发者数量有了 33% 的增长。这部分增长包含了 AI 研发生态中大量的数据处理、模型训练、以及 AI 应用研发等相关的工作。
在互联网爆发的时代，应用架构从单机的模式演进成了分布式架构，以支撑数亿级的用户量以及成千上万的研发协作。在这个发展的过程中，我们看到研发模式也随之演进到强调快速反馈的 DevOps 模式，而包括 RPC 通讯、服务发现、分布式缓存、分布式消息在内的中间件体系得到了蓬勃的发展。相对应地，2025 年可能就是 AI 应用发展的元年，在年初阿里巴巴宣布在未来三年投入 3800 亿元用于 AI 和云计算设施，同时我们也看到 AI 编程应用 Cursor 的开发商近来得到了 99 亿美金，以及 Meta 开价上亿美元从 OpenAI 挖人。
资本的投入以及相应催生的 AI 应用的快速发展，必然会加快相关的研发模式和应用架构的成熟，新的 AI 应用中间件（或者说在本文中的 AI 应用研发基础设施）也会逐渐成熟，它们通过友好的编程框架让开发者能够更专注于创新，而不需要关心那些被反复解决过的包括记忆管理、运行 sandbox 以及安全等问题。
在过去一年我们看到了无论是 Claude 还是国内的 Qwen、DeepSeek，大家在 AI coding 以及 Agent 规划的能力上在不断提升，作为 AI 应用的引擎，模型能力的不断提升必将不断拓宽 AI 应用的适用边界。同时，上下文工程（Context Engineering）也逐渐成为了行业的共识，在复杂的应用场景下，开发者围绕产品定位不断通过 MCP 等方式把更完整更高质量的上下文提供给模型，这也成为了 AI 应用能力提升的关键。
基于对这两个趋势的判断，我们认为在接下来的一两年时间，AI 应用研发的规模会进一步扩大和加速，这个时候，我们推出这一指南文章，希望能够帮助到广大的开发者快速地构建自己热爱的 AI 应用，实现自己创造的梦想！
下载《企业 AI 应用构建指南》 PDF 完整版：
https://sessiondffec7537dba43c8bc.dakou-hosting.iflow.cn/
作者介绍
许晓斌，阿里巴巴技术风险和效能部技术总监，负责研发和基础设施平台，有五年以上管理经验。《Maven 实战》作者，关注技术管理，在 DevOps、软件架构、云原生、Serverless 等技术领域也有丰富的经验。
