阿里云智能云原生应用平台放出一份 126 页的技术文档《AI 应用（AI+Agent）开发新范式》。它不是一份"怎么调 API"的教程，而是试图回答一个更底层的问题：当 AI 应用从"套壳写个 chatbot"走向"让 AI 真正接进业务系统干活"，底层架构到底该怎么变。

文档给出一个朴素但到位的公式：AI 应用 = LLM（大脑）+ AI Agent（手脚）+ MCP（技能池）。但真正值得反复琢磨的，是公式之外它花了最多篇幅去讲的那部分——网关、运行时、可观测。这些"基础设施"才是决定一个 AI 应用能不能从 Demo 走到生产的胜负手。

一、双引擎：LLM 思考，Agent 干活

文档开篇把这次范式转向概括成一句话：AI 应用正从"被动的命令处理工具"进化成"智能伙伴"。

具体拆成双引擎：LLM 扮演认知核心，负责理解意图、规划任务；AI Agent 赋予 LLM"手和脚"，负责工具调用、任务编排、与环境交互。前者想"做什么"，后者管"怎么完成"，两者之间通过"思考 → 行动 → 观察 → 再思考"的闭环反复交互。

这个框架本身不新鲜，但文档把它讲得足够清楚：Agent 和 Chatbot 的根本区别，在于前者能解决"需要跨领域能力协同才能完成"的复合、多步骤问题。 一句话，Agent 是"会干活的"，chatbot 只是"会说话的"。

二、最反直觉的一页：MCP 的本质是提示词工程

全篇最值得拎出来的一句话，藏在第八章：

MCP 没有一个确定的数据结构。它的核心是通过自然语言描述清楚有哪些 MCP Server、有哪些 MCP Tool，然后让大语言模型通过推理去选择最合适的那个。所以它的核心本质上还是提示词工程。

这跟很多人对 MCP 的第一印象不一样。MCP 常被类比成"AI 领域的 USB-C 接口"，听起来像定义了一套严格的通信格式。但实际上，真正让 Agent 知道"有哪些工具、每个工具能干什么、该传什么参数"的，是塞进上下文里的那一大段自然语言描述——也就是提示词。

顺着这个结论，文档抛出一连串很现实、却没什么标准答案的问题：系统提示词被污染了怎么办？提示词怎么管理、安全性怎么保障？MCP Server 一多，系统提示词会非常长，Token 消耗怎么办？

指出这些问题，本身就点破了一件事：MCP 的工程挑战不在"协议实现"，而在"提示词的编写、治理和安全"。

三、LLM 上生产的六个坎，交给网关来填

这是文档最"干货"的一章。它把企业部署 LLM 时必然撞上的问题列成六条：

1. 成本平衡——满血 DeepSeek R1 671B 至少 2 台 8 卡 H20，年度列表价超百万，但 TPS 有限，扛不住多用户并发；
2. 模型幻觉——不开联网搜索，671B 的 R1 照样幻觉严重；
3. 多模型切换——单一模型有稳定性风险，也没有开源组件能"按业务选最优模型"；
4. 安全合规——问答过程要审计、要合规；
5. 模型高可用——主模型挂了得有兜底；
6. 配额限制——闭源大模型都按 API Key 卡 QPS/Token 配额，升配麻烦。

解法高度集中在一个东西上：AI 网关。它站在 Agent 和所有模型服务之间，负责消费者认证、多模型路由、多 API Key 轮转、结果缓存、Fallback、Token 维度限流、内容安全、联网搜索、可观测。

几个具体招数值得单拎出来：

• 多 API Key 破 QPS：一个 key 有 1000 QPS 上限，那维护 N 个 key、网关自动轮转，上限就变 1000×N。把"脏活"下沉到网关层。
• 联网搜索治幻觉：文档说得相当直白——"真正意义上的满血版 DeepSeek R1，应该是开了联网搜索的 671B R1"，而市面上各平台托管的"满血版"其实大多不支持联网搜索。网关在推理前先做意图识别、检索、把结果融进 Prompt，幻觉能大幅下降。
• Token 维度限流：传统网关限 QPS，但 LLM 的成本是按 Token 算的，所以限流也得按 Token 来，还能顺便做消费者分层和成本管理。

这部分的核心思想一句话概括：把模型当"资源"管起来，而不是当"接口"调一下。 这是企业 AI 从"能用"跨到"规模化用"的分界线。

四、0 代码，把存量业务变成 MCP Server

MCP 落地最大的障碍之一，是改造存量系统成本太高。文档点了个很具体的痛点：目前 MCP SDK 支持的开发语言有限，Go、PHP 都没有对应的 SDK，很多企业"想拥抱 MCP 却无从下手"。

它的解法是让网关干协议转换的活：注册在 Nacos 里的存量微服务（SpringCloud、Dubbo、Go 服务），只要加一个 [服务名]-mcp-tools.json 配置文件、用 MCP 规范把接口描述清楚，就能被网关动态发现、0 代码转换成 MCP Server。

这背后是"MCP Registry"这个概念。官方 Registry 只解决"统一公共数据源"和"元数据规范"两件事，私有化、Prompt 安全管控、高级检索这些明确不做。文档里 Nacos 3.0 就是拿这个缺口做文章：在官方 Registry 之上补齐 Prompt 版本/灰度管理、敏感信息加密、服务健康检查这些企业级能力。

五、Agent 也要有自己的运行时和沙箱

很多人默认 Agent 就是一段跑在服务器上的代码，文档用了整整两章纠正这个认知：Agent 需要 Runtime（运行环境），也需要 Sandbox（沙箱）。

沙箱被分成四类：

• Code Sandbox：隔离执行 LLM 生成的代码，支持多语言、多线程；
• Browser Use Sandbox：做需要登录的网页采集、联网搜索，依赖 Session/Cookie 亲和；
• RL Sandbox：强化学习训练时，让 Agent 在隔离环境里海量试错——错一次不会造成真实损失；
• Sim Sandbox：具身智能的仿真训练（Isaac Sim / Isaac Lab）。

文档把这一切压在 Serverless（函数计算）上，理由是：按请求扩缩、毫秒级弹性、多语言运行时、Session 亲和、生命周期管理（用 prestop 钩子做优雅下线）。核心诉求就一条——让 Agent 想跑就能跑、想隔离就隔离，还不心疼钱。

六、可观测：降低"熵增"的唯一办法

文档最后落在一个有点哲学味的判断上：

MCP 解决了"N×M"的集成问题，但 LLM、宿主环境、各种 MCP Server 之间的相互连接，会导致链路复杂性提升、性能瓶颈诊断困难、SLA 难以保障。可观测是降低"熵增"最有效的办法。

对应的是一整套 LLM 可观测方案：基于 OpenTelemetry 的全链路 Trace（记录 Prompt、Input/Output、Token、TTFT 首字延迟）、Python 无侵入探针、面向流式场景的 Span 分段采集与合并，以及"用 LLM 评估 LLM 生成结果"的自动化评估。

当 Agent 开始在多轮"思考-行动-观察"里反复调用工具，一次请求会在 Agent、网关、模型、MCP Server 之间来回穿行很多次。这时候，没有可观测，出了问题就只能干瞪眼。

结语

这份文档本质上是阿里云给自己那套云产品（函数计算、API 网关、Nacos、可观测）画的一张"AI 应用架构全景图"，立场摆得很清楚。但抛开厂商立场，它抓住的那个趋势是对的：

AI 应用的下一个阶段，胜负手不在"哪个模型更强"，而在你能不能把模型、Agent、工具、网关、运行时、可观测这六样东西，捏成一个能稳定扛住真实流量的整体。

模型是大脑，Agent 是手脚，MCP 是技能——但真正决定这套系统能不能上生产的，是那块最不起眼、也最容易被小团队忽略的地基：网关和基础设施。

本文基于阿里云智能云原生应用平台技术文档《AI 应用（AI+Agent）开发新范式》整理，文中观点与数据均出自该文档，仅作技术解读。