万字长文，深度拆解 阿里156页、20w字《AI应用白皮书》（附资料下载）

关注公众号，回复666，获取资料

今天来读一篇阿里云的报告《AI原生应用架构白皮书》：

之前我也收到过某些大厂的邀请，这种报告报酬在1-3万左右，会由很多人参与，然后阿里这个报告好像全是花名，可能是阿里在职人员编写：

这类报告主要为了秀肌肉，读者可能是各个公司技术负责人，最终目标肯定是云服务业务种草，所以质量不会差的。

只不过如果全部大公司同学来写，可能会有视角不足的问题，他们可能看不到一些中小公司的视角，为了打消我们这个疑虑，他们首先给出了一轮数据洞见：

数据洞见

因为我最近去年在做AI+管理侧创业，接触了不少公司，已经实施的和准备实施的确实是五五开的情况，只不过在落地场景这里，我觉得报告的分类需要更有条理一些，如果按我的习惯我会分为：

工作流AI、简单知识库、复杂数字分身，我这边的比例是这样的（70%是工作流业务）：

再看第二张数据：

从描述来说，报告认为难点在于：多轮对话过程的记忆衔接、基本的数据处理逻辑，以及一些性能稳定性问题。

数据这块部分有些启示但是缺少明确的定义，这块在后续的内容全部做了补足，所以直接上目录：

目录结构

从目录来说，报告是比较细致的涵盖了AI应用层几乎所有常见名词，我们接下来来简单过下报告，并且我会在重要的地方提出我的见解：

AI原生应用及其架构

注意，这里图片可以滑动：

<<< 左右滑动见更多 >>>

只说这一章节，报告写的和我看到的其实就有一些差异，或者我们的关注点可能不太一样：

第一，大模型技术发展回顾这块感觉没展得太开；

第二，AI时代架构演进这块在强调IT架构演进，里面尤以微服务为例，几乎被我身边很多技术负责人（中小公司）认为是云服务给的坑，极大的增加了云服务成本！

然后就是他提出的AI原生应用架构：

看着挺全，就是没什么实际意义，这种图一般都不会有人会细看，我们实际工作肯定要重新画架构图，比如其中的编排，很可能就是不被需要的部分，AI技术迭代很快，这个东西看看就好，搞不好明年就过时了。

最后就是其中比较重要的AI原生应用架构成熟度评估框架了：

这个框架本身是很不错的，对每个某块提出了具体的要求：

一、自然语言交互能力

衡量应用以自然语言为媒介，实现高拟人化、无障碍人机沟通与任务执行的能力。其核心在于深度理解用户指令的语义、上下文及意图，并生成符合人类交流习惯的回应。

这其实是复杂数字分身AI应用的要求，其核心是：数据工程。

二、多模态理解与生成能力

衡量应用对文本、图像、语音、视频等多源异构信息的综合感知、融合理解与跨模态生成的能力。其功能在于突破单一数据模态的局限，实现对现实世界复杂信息的综合处理与表达。

这里除了数据工程之外，还需要各种插件及模型本身图文、语音、视频能力的进步。

三、动态推理与自主决策能力

衡量应用在复杂、动态且不确定的环境中，进行多步逻辑推理、态势研判并生成最优决策方案的能力。其功能超越了基于固定规则的自动化，实现了对未知情境的主动应对闺多与策略规划。

任何AI应用都有不能穷举的或者漏掉的SOP，对于这部分如何处理的能力，也就是AI已经完成了你要求70分后，另外30分的表现如何？

四、持续学习与迭代能力

衡量应用在全生命周期内，通过反馈数据、新知识注入和环境交互，实现性能自我优化、知识库持续扩展以及功能迭代升级的能力。其功能确保了应用能长期适应需求变化，避免性能衰减。

这里的重点依旧是数据工程，尤其是飞轮系统部分的实现。

安全部分问题就不赘述了，初期要什么安全...

3年回顾：1.0-3.0

怎么说呢，第一部分内容除了AI原生应用架构成熟度评估框架，我认为没必要细看，他的回顾和架构演进都与事实上的AI发展关系不大，具体看此图：

2022年年底，ChatGPT3.5发布，标志着我们正式进入以大模型为主的AI时代。

经过近3年的发展，模型的基础能力得到了大幅的增强，比如：基础理解能力、推理能力、上下文长度、响应速度、API调用成本、多模态能力等几个关键维度都有了长足的进步。

对国内来说，2025以DeepSeek发布开始，几乎标志着AI应用环境达到成熟状态了。

于是乎，在今年整个AI世界的发展可以用乱花渐欲迷人眼来形容了，今天发布了一个Manus，明天就要来一个Lovart；

Cursor还没被捂热，Claude Code就变成了AI编程事实上的王者了；

前脚还在聊提示词怎么写，后脚大佬就说RAG已经过时，并丢出了上下文工程；

而正当我们感叹Coze居然开源了，一个Google Nano Banana又刷爆了朋友圈；

然后飞书发布会才浓墨重彩的介绍了多维表格，钉钉马上就跟进，强势推出AI表格......

以上这种持续混乱无章又各种关联的喷射状，才是这3年AI的真实情况。

配合上述混乱的AI技术架构是经过了三轮迭代：

AI1.0 训练时代

第一次是以堆数据、堆算力做训练为主的1.0时代，各个企业的核心点在于，基座模型的能力不足，我们要训练一个比他好的模型出来！

这是一个盲目的时代，大家对于模型的特性其实是不太了解的；但这也是一个疯狂的时代，因为不了解，所以很多公司期待马上训练一个模型出来，打响企业品牌，顺便融一波资，岂不美哉？

从现在的视角来看，那时候多数的公司都在瞎折腾，事实上的结果90%的公司的技术路径也确实在打水漂。

最终做出一点东西的公司，都不是靠微调，而是想清楚了产品逻辑，用最小化AI路径打造了个可控的产品出来。

最后钱都不是白花的，过程中大家几乎达成了一个共识，滚你妈的微调，直接上RAG就好，在这个基础下我们才进入了AI2.0时代。

AI2.0 提示词时代

2.0属于提示词时代，时间大概从2024年就开始了。

这个时代正常公司已经比较务实了，绝口不提模型训练几个字，开始老老实实上RAG。

在这个时代也诞生了很多切实解决问题的应用，其中最典型的应用是简单AI客服。并且大家都发现了一个问题：稍微复杂点的场景AI就玩不了。

因为AI客服的背后其实又回到了数据工程，复杂的AI场景对各方面能力的要求一下就提起来了，多数想玩一玩的公司根本走不深。

然后，去年市场行情也不好，数据工程也不是一朝一夕的事情，观望着、观望着很快就年底了。

这里特别有提一句的是，虽然AI应用没有太大的发展，但基座模型一直在演进，我记得去年年底的时候，主流框架都迎来了一波大升级，具体体现出来的是推理能力、响应速度、token成本。

紧接着，黑天鹅事件发生：卷王DeepSeek发布了。

AI3.0 CoT 时代

DeepSeek的发布不止是振奋了国内AI行业，并且为AI应用指明了一条新的路线：思维链是可行的。

事实上在AI1.0时代思维链的技术架构雏形我们就形成了，但是具体是没能很好的执行下去的，原因无他：正确的参数产生不了正确的答案，那个时候的模型太弱智不吃这一套。

PS：正确的输入拿不到正确的输出，说实话这个问题把曾经的我坑惨了！！！

但DeepSeek发布后，标志着模型推理能力达到一定高度，他吃得了细糠了，所以我认为AI正式进入3.0时代，而未来很长一段时间都会围绕CoT展开，其本质是围绕数据工程展开。

值得一提的是，DeepSeek带来推理能力增强后，又爆发了一种Manus的玩法，大概逻辑是你什么都别管，全部丢给模型处理就好，你执行将工具接口准备好，模型自己知道什么时候用什么，并且一定会达成最优解的。

暂时看来，阿里云这个白皮书主技术框架也是围绕这Agent做展开

这里我直说了吧，短期来说，Manus只能是噱头，除非工作流类数据已经积累到一个巨大的量，比如AI编程确实可以自己阅读并修改需求文档，但这一天还很早，依旧需要积累数据。

以上是我视角里面真正看到的AI3年发展及技术架构演进，对比起来和白皮书就不太一致了，大家可下来再思考思考。

接下来我们进入第二章：AI原生应用的关键要素。

AI原生应用的关键要素

注意，这里图片可以左右滑动：

<<< 左右滑动见更多 >>>

这一章不知道是谁写的，也不管人家接不接受就一股脑的堆积名词解释：

要说对初学者不好吧，这东西又说得很细；但你要说他对初学者友好吧，整体又没个逻辑性，总之难度没掌握好，技术负责人嫌多，小白又看着吃力。但无论如何都需要了解，大家硬着头皮看看吧：

模型

他好像说了什么是微调，又好像什么都没说，这就让人很蛋疼了，我们前面说AI1.0框架时候就说过：

现在大家都很少微调、都会极力避免微调，如果非要微调都是因为响应速度、token成本等不得不为的情况，白皮书这里的描述显然不够精准。

模型选择这里中规中矩，在模型能力差距不大的情况下，大家肯定是算账看成本的。

框架/提示词

框架这里提了一些名词，同样属于初学者看不懂，会的人不会看的部分，他这个其实更像是一个提示词框架目录，大家可以看这个文章：

从“有手就行”到“头皮发麻”，你真的会提示词吗？

真正的初学者不建议在这块瞎折腾，直接上手Coze或Dify就行，这个做完了接下来要搞Langchain什么的都很轻松。

RAG

这块说的很简单，但除了工作流AI，其实多数知识库AI都是在用简单的RAG技术，以最常见、最经典的AI客服来说，其实重点是整理一张全局表：

我们需要根据实际业务需求，整理数据，重点需要关注：（（典型的用户QA问答；

这里说白了就一个事情确定AI到底要回答哪些问题，严格情况下数据要包括：不同问题的可接受错误率和响应时长，可接受成本。这里是需要做出一张表的，比如我之前做的AI训练营售前客服：

这里的场景是很简单的，全部可以由AI完成，如果是稍微复杂点的客服系统，一定要注意这张表里面要为每个问题做分级，有明确的策略，AI能做哪几步、做不了的移交给谁，要设计清晰。

比如涉及用户重大利益(投诉、纠纷)、高敏感信息(账户隐私)、强烈情绪等场景，应直接转人工，避免让AI硬撑。

从这块可以看出，数据处理才是RAG的核心，RAG本身并没什么可说的。

记忆

记忆这个也不多说了，其本质也是数据工程的一部分，因为模型是不存在记忆的，他只有提示词，记忆的关键是如何组织数据与提示词。

可观测性（重要）

后面的部分都没什么好说的了，因为都聊得挺浅的，我们特别说下这里的可观测性，他很重要但白皮书这里说得很少（貌似后面有章节完整说明，我们直接跳过去）：

AI应用的可观测性

注意，这里图片可以左右滑动：

<<< 左右滑动见更多 >>>

AI可观测性是AI项目过程中对技术架构/路径尤为关键的衡量指标，可以说是深水区AI应用的基础。

只不过，AI可观测性其实不是一个工具，严格来说他应该是一种设计，涵盖了提示词的单一原则性的良好设计：

AI可观测性表面是监控，对所以错误的监控，其实是设计，对每个可能出错/幻觉的地方进行原子设计/作业，一旦发生错误，能够很快定位到哪里错了，从而可以提出局部优化方案，不会影响整体架构

要特别注意的是：可观测性核心关注点是提示词，但提示词背后涉及的数据才是整体优化的核心。

至于白皮书这里提到的，有点带货的嫌疑，我估计云服务商有些服务（比如这里的Opentelemetry，一个对云供应商中立的可观测性的框架和工具包，用于创建和管理遥测数据），只不过就我过往的经验，这块是设计、数据工程和客服层面的事情，底层服务商可做的有限，初期没必要接入（也许后期也不会接入）：

所以，我这里从设计思路角度进行部分还原：

再说可观测性

最近在给学员上课的时候，最常说的一句话是：做AI应用一定要了解模型边界！这里所谓模型边界涉及了AI应用的两个流派：

1. 能用AI就用AI；
2. 能不用AI就不用AI；

就简单的三句话还涉及了很多隐性知识，包括RAG 技术的最初开创者之一Douwe Kiela的一些观点：关注可观测性，而非仅仅准确性。

在AI项目中，达到100%的准确性几乎是不可能的。即使能达到90%或95%的准确率，企业现在更关心的是如何处理那缺失的5%或10%——即不准确的部分。当出现错误时该如何应对？

除了基本的准确性要求外，关键在于如何处理不准确性，这就需要可观测性。需要仔细评估系统表现，并确保有适当的审计追踪，尤其是在受监管行业。

而这里所谓的可观测性，只在能不用AI就不用AI的模式下可行，他的背后体现的是模型的边界认知：追求完美准确率不现实，关键是要知道错在哪、为什么错、怎么改！并且能证明技术框架是闭环可重复的！

今天我们就用一个简单案例来解释解释什么是能用AI就用AI，什么是能不用AI就不用AI，什么又是AI项目的可观测性。

案例说明

之前AI课的时候学员过多，需要一个排班系统，大概的需求是：

学员在微信群打出自己每天的空余时间，AI会主动统计大家都有空的时间，如果满足条件就预约会议，学员在群里的聊天信息如下：

A：20.00-22.00有空
B：18-20点没空，其他都可以
C：二十点后可以；
D：下午4点前没空；
E：我随便了，都行；

当然，实际功能会有很多提醒、少数服从多数、协调学员调整时间等功能，但主体需求就是一个时间算法。

非常简单的需求，但就是这么一个简单的系统就能聊清楚什么是模型边界。

首先是能用AI Max的技术路径：

一、能用AI就AI

全部用AI就很简单了，直接一股脑丢给模型加一句“请问今天我该安排什么时间上课”就行：

GPT的回答：

DeepSeek的回答：

如果在简单场景下，能用AI就AI其实是最优解，包括很多智能体如Manus在简单任务里面的表现是非常不错的。

随后就是AI Min：

最小化AI应用

所谓最小化AI应用，就是只在不得不使用AI的地方使用，比如这里不得不使用的地方就是提取关键词，也就是语义识别每个学员的空闲时间：

1. A：空闲时间段为 20:00 - 22:00（即晚上8点到10点）。
2. B：18:00 - 20:00 没空，其他时间空闲（即 00:00 - 18:00 和 20:00 - 24:00）。
3. C：二十点后可以，即 20:00 - 24:00 空闲。
4. D：下午4点前没空，即 16:00 - 24:00 空闲（下午4点为16:00）。
5. E：所有时间都空闲（即 00:00 - 24:00）。

拿到空闲时间后，再自己用算法去做实现，这里马上就涉及了另一个问题了：在最小化AI应用的场景里，什么时候需要用AI？

泛化能力

答案很简单，在充满泛化场景的时候需要，比如上面ABCDE的回答，你很难用正则的方法给他匹配出来，类似这种关键词（关键知识）的提取只能依靠AI；

相同的场景是，我要求学员的昵称必须是学号-昵称-城市的格式，但学员一定会做得五花八门，比如就有学号_昵称_城市、城市_学号_昵称、学号昵称@城市等等莫名其妙的排布方式。

这种在学员自己设置后，也只有AI能快速帮他们做更正。

所有类似这种泛化要求较高的往往都必须AI出场，并且AI在这个领域做得挺好的！

那么，什么又是模型能力可观测性呢？

可观测性

答案也非常简单：如果出现了AI识别不了的情况，能很快识别并解决！

比如现在出现一个F，他给的答案比较另类：戌亥之时，余有暇。

类似于这种回答，模型很可能识别不了，那么排班系统就会出问题，这个在能不用AI就不用AI的模式下就可以被识别并优化。

这里的可以被识别且优化就是我们所谓的模型能力可观测。

最后一个问题：如何优化？

如何优化？

如果发现问题要优化就很简单了，最简单的做法是将戌亥之时，余有暇。对应的时间当放到提示词，做一个古文时间与现在时间的映射。

如果要泛化能力强一点就可以启动后训练，可以是微调也可以是RL，都一样。

以上整个就是所谓模型边界最简单的描述，真实场景当然会复杂太多，比如此图：

综上，就是设计层面的模型可观测性，希望这里大家有更深刻的理解，这个概念可太重要了！

接下来我们返回应用开发框架章节：

AI应用开发框架

注意，这里图片可以左右滑动：

<<< 左右滑动见更多 >>>

这一章描述了智能体的定义，依旧是Manus后流行起来的经典结构：

只不过这里需要进行进一步解读，这里再次来到这个经典图示：

大模型解决规划与调度问题，Manus能爆发的核心原因就是模型能力大幅增强；

工具链解决多模态问题，包括最近很火的MCP、Computer Use其实都算是AI多模态能力的延伸，要的就是解决AI各种“不行”的问题，这里包括了听觉、视觉、触觉等；

所谓的记忆和反馈迭代全部是数据工程的事情，我们一直叫RAG，可能最近还多了个称呼上下文工程。数据工程做得好，也可以有效降低模型幻觉。

记忆体系之前不可行，现在可行的核心原因是模型上下文大大扩展，从现在来看破百万是早晚的事，如何让模型聊得像人，体验好的AI分身这类应用，将在这两年诞生。

以上就是智能体的介绍：一个具备自主理解、规划记忆和工具使用能力的数字分身，只不过懂行的同学才知道这背后有多少心酸，至少现在证明Manus类AI Max架构的系统还只是玩具。

接下来是开发范式：

智能体主流开发范式

白皮书将智能体分为了四个类型：简单LLM应用、单体只能、工作流、多智能体系统：

所谓简单LLM应用，就是直接调用模型API，完成最简单功能，比如翻译、简单名词解释等；

单体智能，是一种 Augmented LLM 应用它的核心理念是为普通 LLM 应用增加 RAG、Tool、Memory等，让模型具备与特定环境交互的能力，这个图比较直观：

工作流AI大家应该比较熟悉，我们之前聊得很多了：详解工作流AI

多智能体系统与工作流AI类似，只不过一个依赖于我们梳理SOP，一个模型自己搞定。然后从具体实践来说，所有依赖模型本身的智能体稳定性都不怎么样：

这里后面又有点带货嫌疑在聊Spring AI Alibaba框架，我们这里就不继续跟进，因为也没什么东西，还是那句话：先直接用Coze搭建就好，到复杂度过高搞不定的时候自己上代码，不需要用框架。

抛开框架来说想进一步学习的，可以移步至此篇文章：实现多智能体。这里也简单实现了一套多智能体系统：

上下文工程

注意，这里图片可以左右滑动：

<<< 左右滑动见更多 >>>

首先看此图：

事实上这里对提示词工程的定义是不对的，至少我们之前对提示词工程的理解会远远超出他所描述的范围而更加接近这里对上下文工程的描述，这也是我的一个观点，没必要为了捧一个新概念就一定要淘汰某个贴切的名称，因为现阶段跟大模型的交付方式有且只有提示词，所以把上下文工程称作提示词工程也是没问题的。

这里继续回归经典的Agent技术架构：

记忆功能是智能体的基础，之前一般是配合RAG生成提示词达到要求，并形成了一套不错的方法论就给他取了个高级的名字叫：上下文工程。

上下文工程的核心在于给模型提供恰到好处的“上下文”，让他能更好地理解任务，完成复杂的工作。

白皮书这里也是匆匆介绍了以下基本定义就进入了RAG环节，明眼人都知道这个是核心：

而接下来就是RAG的基础知识，我之前写了文章这里就不展开了：

1. 向量库已死、RAG永存：模型进步再次干死过时技术
2. RAG实践技巧：将向量库降级为“语义路由器”，让答案更合理
3. 使用RAG构建高质量知识库
4. 简聊聊GraphRAG，图谱+模型=聪明的AI分身
5. 知识图谱

最后给个简单案例：

上下文工程案例

下面这7个部分是一个上下文工程的基本组成：

1. 系统指令。AI的基础设定，给模型以“身份”＋“基本规则”。偶尔还会给一些示例，比如：你是一名资深旅行顾问，回答必须符合 JSON 模版；
2. 用户请求。本轮要办的事儿，比如：帮我写一封向客户解释延期交付的邮件。
3. 短期记忆（对话上下文）。记录刚刚发生了什么，避免“失忆式”回答。内容包括你和 AI 的往来消息、最新操作反馈。
4. 长期记忆。跨会话的常识与偏好仓库。内容包括用户常用邮箱、口味偏好、历史项目笔记等，其实就是个人知识库了。
5. 外部检索层（RAG）。实时补充“书到用时”的资料。内容包括数据库查询、企业文档、网络搜索结果等。
6. 可调用工具。让 AI 不只会“说”，还会“动手”。这里可以跟各种MCP工具联动。
7. 输出规范。规定答案长什么样，方便下游直接消费，一般是JSON格式。

把这些元素想成电脑的 RAM：容量有限，却直接决定运行效率。

上下文工程的核心，就是在正确的时机把最关键的“原料”送进模型，让 AI 既不遗漏关键信息，也不被无关噪声拖慢，最终把任务高质量交付。

然后是关于上下文的操作，这里有张图大家先感受下：

我们这里做一张表：

基本概念了解清楚后就是具体案例了：供应链危机下的智能决策支持。这是一个去年客户的救火项目，之前有人给他们做了个AI客服助手（20万预算），只不过是对内的，当时突发的问题是：

某跨境电商客服凌晨收到警报：爆款商品因港口罢工面临断货风险，需2小时内决定应急方案。

这个时候客服直接就询问供应链AI：如何处理XX商品供应链中断？模型反馈也很简单：

1. 启用备用供应商；
2. 调整营销策略；
3. 通知客户延迟；

对此回答：客服表达了不满，然后CEO也不满，最后找到了我去解决，而这就是个典型的上下文工程的问题，其实不叫他上下文工程也行，就是个常规AI知识库工程的事。

该问题的处理逻辑也很简单，为部署的AI系统自动构建以下上下文（当时其实没这么全，这里做案例加上一些）：

然后再加上一些简单代码，AI就会重新生成应对策略：

{
"优先方案": [
    {
"行动": "立即空运2000件至XXX分仓",
"逻辑": "覆盖未来7天VIP订单(占营收65%)",
"成本": "????",
"损失规避": "防止客户流失风险"
    },
    {
"行动": "对普通客户启动预售",
"逻辑": "利用长期记忆：该品类客户等待容忍度21天",
"成本": "营销投入XX",
"预期收益": "锁定XX订单"
    }
  ],
"风险评级": "高"
}

真实策略会比上述更复杂，大概是这个意思，大家理解理解，总之这就是所谓的上下文工程，他的本质仍是Prompt工程...

工具介绍

这里开始感觉有含金量的东西不多了，大家看看这个图就好，因为他重点是要接受MCP：

Model Context Protocol (MCP) 是Anthropic开发一种开放标准协议，它可以让AI模型能够安全地访问和交互外部数据和工具。

与http协议类似，就是一个约定俗成的标准，只要大家遵守即可。

MCP出现的缘由很简单，大模型要真正的解决问题，一定需要与各种外部接口做交互，包括浏览器、数据库、文件系统...

在MCP提出之前，我们如果需要外部信息是怎么玩的呢？答案是定制化。

写一个中间程序，直接去调用大模型（获取请求），拿到大模型请求后、再调用API进行数据库读写、或者通过大模型返回的一些参数，再进行API调用，总而言之，用户访问的其实是中间程序，中间程序完成了大模型能力扩展的弥合。

但是有个人不爽：觉得不应该存在中间程序这种奇葩存在，于是他先在模型底层实现了固定格式的API调用，于是后续用户便可以直接访问大模型，而大模型可以自动调用该API进行数据库读写。

后续又衍生出文件读写、浏览器读写等需求，为了提升效率就沿用了之前的标准，最后发现挺好用，就形成了协议。

有了MCP后，AI与外部世界的交互有了统一标准，使 AI 应用能够无缝集成外部数据源和工具。

在没有 MCP之前，每个开发者都需要创建自己的方法让 AI 与外部世界交互，这导致了大量不兼容的系统和安全漏洞。

以上就是非常粗暴的描述，大家自己理解吧，没什么好说的...

具体案例

为加深理解，这里还是随便补充点内容，其实MCP没什么好说的，按照要求写即可...

用户 → 中间程序 → 大模型 → 中间程序 → API → 返回结果

实际技术演进：

# 传统适配层伪代码
user_input = "查北京天气"
model_response = llm(user_input)  # 模型可能输出 "需要调用天气API，城市=北京"
if"天气API"in model_response:
    city = extract_city(model_response)  # 开发者自行编写解析逻辑
    result = call_weather_api(city)      # 手动调用API

MCP 阶段：

并非完全消除中间程序，而是将其标准化为协议层。流程变为：

用户 → 模型 → MCP客户端（结构化请求）→ MCP服务器（协议转换）→ API → 返回结果

- **关键升级**：模型直接输出标准化指令（如 JSON 格式），MCP 协议层替代了定制化代码

---

### 二、核心差异：协议层 vs 模型能力
| **维度**       | **传统模式**                  | **MCP 模式**                     |
|----------------|-----------------------------|---------------------------------|
| **调用发起方**  | 开发者代码触发 API 调用         | 模型自主生成 MCP 指令             |
| **接口规范**    | 每个 API 需独立对接            | 统一遵循 MCP 协议格式             |
| **安全控制**    | 依赖开发者实现权限管理          | 协议层内置沙箱与权限策略           |

**典型案例对比**：  
- **无 MCP**：模型输出 "请调用天气API查北京"，需开发者写正则表达式提取参数  
- **有 MCP**：模型直接输出结构化指令：
```json
{
"action": "query_weather",
"params": {"location": "北京"},
"auth_scope": "user_weather"
}

结语

白皮书其他部分内容我读了后感觉不大重要，大家自己去看看吧，文章已经很长了我们做下简单总结：

首先，整体白皮书质量较高，非常建议初学者好好研读

其次，通过本次解读，我们可得出两个核心判断：

第一，实现Manus类产品的技术门槛正在降低，但打造真正可用的智能体仍需攻克三大难关：精准的意图识别、完善的工具生态和深厚的领域知识，这些都指向数据工程与可观测性设计这一本质。

对应文章的内容就是：上下文工程和可观测性，这里需要反复阅读；

第二，是文章里面没太提到的部分，当前技术演进路径开始有些变化，正从依赖Computer Use的“模拟操作”，迈向以AI编程为核心的自主进化。

这让智能体从“使用工具”进阶到“创造工具”，可能代表了更根本的解决方案。

总而言之，从最开始数据洞察来说，市场上至少还有一半的公司需要切入AI赛道，机会还多，你我共勉！

点击上方卡片关注叶小钗公众号，查看下方二维码，添加我个人微信：