本文探讨了在AI技术应用方面的战略布局与实践，指出“人人都是AI工程师”的时代已经到来。文章从AI应用的三种模式——Embedding模式、Copilot模式和Agents模式入手，详细解析了不同模式的技术实现思路与业务场景适配情况，并通过具体案例展示了如何利用AI技术提升业务效率和用户体验。此外，文章还分享了提示词工程、模型选型与评测、Function Calling与RAG等关键技术点，并展望了未来AI工程师的发展方向。

01.前言

“今天，传统互联网模式严重同质化已走向存量竞争，AI人工智能为代表的新技术正成为全球商业发展的新动能。”

“下一个十年，最大的变量毫无疑问是AI带来的全行业深刻变革。我们各业务有大量用户场景，我们必须让这些场景都变成AI技术最佳的应用场，通过技术创新带来突破性用户体验和商业模式。”

“面向未来，阿里确立两大战略重心：用户为先、AI驱动。”

在所有产品都值得用大模型重新升级的今天，如何通过AI技术的最佳实践让我们大量的用户场景都变成AI的最佳应用场，已然变成了全员的必修课。

本篇文章不会讲AI的底层原理和技术架构，也不会基于某个特定的业务场景讲解AI是如何落地的，附带太强技术和业务属性的AI实践，或多或少都有一些壁垒和学习成本，没有深入了解的同学很难融会贯通。而授人以鱼不如授人以渔，笔者将会结合近一年来在不同业务场景的探索，来分享下现阶段AI的最佳应用和实践的思路。希望能够通过这次分享，在你也想要探索或接到AI应用相关工作时，可以知道：嗯，我可以按照这个思路、从这个方面入手来做。

02.AI应用的三种模式

先来看下AI应用的三种模式：

• Embedding模式：AI仅提供建议，最简单的AI应用形态；

• Copilot模式：AI辅助完成任务，其中一个典型的实现就是WorkFlow，将业务流程抽象成自动化流程来辅助完成任务；

• Agents模式：AI自主规划、完成任务；

这三种模式其实也对应着不同业务的三种AI产品形态，每个模式都有典型的业务应用场景。

这里需要强调的是，三种模式更多的是交互上的差异，具体实现也可能会用到同样的技术，简而言之：

• Agents模式更强调自主性和独立完成任务， Embedding模式和Copilot 模式更侧重于作为人类的助手，协助完成特定任务；

• Agents模式中也可以有通过WorkFlow能力实现的子Agent，Copilot 模式也可以具备规划能力；

读者不必纠结于具体的概念，在日常沟通当中大部分同学还都会将这三种模式统一称为“Agent”，这其实也没什么问题，AI技术和应用本就在高速发展中，概念层出不穷会导致大家存在理解偏差，相信随着AI技术和应用的不断成熟，大家也会像理解商品、类目概念一样理解AI。

接下来，我将结合一些业务和技术场景，来讲解现阶段这三种AI模式典型的实现思路。

03.AI初级实践：Embedding模式实现

其实大家日常与AI的交互就是Embedding模式，通常我们为了解决问题会先询问大模型，再根据大模型输出去解决问题，而询问的问题基本也都是比较原子的问题点，复杂的问题这种模式也很难解决，想必大家在应用过程中也都体验过。

所以Embedding模式的实现，本质上是在做提示词工程，我们甚至可以不需要让大模型能够访问外部实时数据，仅凭其训练的静态数据来让大模型提供建议或解决特定领域的小型问题。通常通过调试提示词并加入一定的业务知识库即可以实现该模式。

举个

商品低价引流：

商品低价引流是指商家在推荐、搜索结果页、频道等场域，通过展示与主图不相符的低价，吸引消费者点击商品链接，典型的示例如：主图展示“3提装”，消费者在外面看到的价格以为是“3提装”的价格，但购买时锚定到“1提装”的SKU。

此类问题如果想要通过AI来代替人审，只需要上传商品主图和锚定SKU，来让大模型判断主图规格和SKU规格是否一致即可，本质上是让大模型来做阅读理解，不需要复杂的流程和任务拆解，也不依赖于外部动态数据。可以看得出来，这种业务形态下的AI产品，就是一个很原子化的能力点，产品效果的好坏十分依赖于提示词工程及大模型本身的能力。

▐  提示词工程

提示词工程其实就是对提示词进行管理和应用，其中也会包含使用提示词的艺术和经验。

还是以上述业务为例，如果你接到了这个AI审核的任务，要怎么实现呢？很简单，工程里组装提示词直接调用大模型API即可：

但如果再考虑一些其他业务快速接入和复用的情况，那就可能会再抽象出一些：业务身份构建、提示词模版、版本管理等能力，最终可能会演变成这个样子：

上述架构其实就是笔者刚刚接触大模型时设计的一套提示词工程框架，在AI基建能力不够完善的当时，支持了多个业务AI审核能力的构建，至今也仍在使用。

当然，作为本篇文章的读者自然不需要了解该框架的运行原理，这也不是今天文章要讨论的重点。回到现在，在AI技术发展如此快速的今天，有没有更方便、更快速的途径构建一个Embedding模式的AI应用呢？有的兄弟，有很多：

1. 基于AI开发框架。如SpringAI、LangChain、LangEngine等；

2. 基于AI开发平台。

方案1和方案2均可以通过简单的配置来实现一个Embedding模式的AI应用，但方案1通常会结合更深入的提示词工程来实现Agents模式，方案2通常会基于平台能力快速搭建WorkFlow来实现Copilot模式，所以这两种方式在下面将要讲解的另外两种AI应用模式中会详细展开，大家可以先有个概念。

• 提示词的使用艺术

提示词的技巧是一门经验学科，细究起来也有很大的学问，相信大家也都看过或用过一些优秀的提示词模版，比如按角色、按流程等方式编写。

提示词的常见要素：

#角色：给大模型定义一个匹配目标任务的角色。用一句话就可以明确它的角色（比如“你是一位淘宝客服”），从而有效的收窄问题域，减少二义性，让“通用”瞬间变得“专业”。
#指示：对具体任务进行详细描述。
#上下文：给出与任务相关的其它背景信息（如历史对话、情境等）。
#例子：举例很重要，就像是师傅教学之后，需要给徒弟（大模型）演示一下如何操作，这个手把手的操作，是大模型生成输出时的一个重要参考，对输出结果有很大帮助。
#输入：任务的输入信息，最好在提示词中有明确的“输入”标识。
#输出：输出的格式描述，比如输出不超过十个字、以JSON格式返回结果等。

不过这里笔者不会具体阐述如何书写高质量提示词，因为我始终相信，当前提示词的各种使用经验实际上是在弥补大模型能力的不足，当大模型能力越来越强大时，一个简单的指令和描述就可以完成任务，但如果有想学习提示词技巧的同学，也可以参考这篇文章：Prompt engineering：https://platform.openai.com/docs/guides/prompt-engineering。

这里想要分享的，是我在提示词使用过程中遇到的一些有趣的案例，有些甚至可以立竿见影提升你的使用体验。

Magic Prompt 提示词中的魔法

在提示词领域，有一些类词被称为“魔法词”，使用后可以立竿见影的提升大模型的输出质量，让人直呼玄学的力量。通常是因为这些提示词会让大模型联想或使用到一些高质量的数据，所以才会产生较好的输出结果。笔者在实际使用中经常会用到两种“魔法词”，分别是：

• Let's think step by step.

• Read the question again

• Re-Reading重读：Re-Reading Improves Reasoning in Large Language Models（https://arxiv.org/pdf/2309.06275）

有趣的小游戏：

让大模型的输出听命于你

https://modelscope.cn/studios/LLMRiddles/LLMRiddles/summary

• 提示词工程的深入应用

上面提到的都只是最基础的提示词应用，包括还有一些常见的使用技巧，如：COT(Chain-of-thought,思维链)、Few-shot(少样本学习)，目的其实是让大模型更清晰的了解我们的指令。

但更深层次的提示词工程是可以赋予大模型更智能的表现，例如通过设计巧妙的提示词，经过多步反馈交互来实现大模型的“自主规划和解决问题”能力。这些更深入的提示词工程在Agents模式的讲解中也会有所体现，也是提示词工程的核心，不妨先留个悬念。

▐  模型选型与评测

Embedding模式下的产品效果，会强依赖于模型本身的能力，所以做好模型选型和评测是至关重要的。

• 模型选型

按照不同业务的特点，笔者通常喜欢基于不同的应用场景将模型分为三类：

• 基础模型/预训练模型：如GPT-4、DeepSeekV3

• 多模态模型：如QwenVL、GPT-4o

• 推理模型：如Qwen3、DeepSeekR1

当然，分类方式不一而足，也可以分为文本模型、视觉模型、语言模型等，这里就不一一展开了。

预训练模型与推理模型的区别：

GPT = Generative Pre-trained Transformer，意思是：生成式、预训练、Transformer架构。

GPT-2、GPT-3、GPT-3.5、GPT-4都是OpenAI训练出来的预训练模型，这些模型都是通过在互联网资料上进行无监督学习训练出来的。虽然具有很强的泛化能力，但是并没有针对具体的任务做优化。chatGPT就是OpenAI在GPT的预训练模型基础上，进一步通过监督学习和强化学习，微调出来的针对“对话”的模型。

同理，DeepSeek-V3就是DeepSeek训练出来的预训练模型，R1就是在V3的基础上，通过纯强化学习训练出来的推理模型。

推理模型适用场景：

这里想要强调一点，推理模型能力固然强，但并不是所有的业务都适用于推理模型。

1、用对模型、用对场景：推理模型专门用于应对那些需要复杂中间推理步骤的问题，比如解谜、高级数学题、具有挑战性的编程任务等。然而，对于诸如摘要、翻译、或者依靠知识检索的问答等更简单的任务，就未必需要推理模型了。如果把推理模型用在所有场景，往往既低效又昂贵。因为推理模型通常更耗资源、输出也更冗长，有时还可能因为“过度思考”而出现错误。最简单的原则依然是：用对工具、用对类型的 LLM。

例如，“中国的首都是哪里？”这类事实问答不涉及推理；但如果是“列车以每小时 60 英里的速度行驶，行驶 3 小时后会走多远？”就需要一些简单的推理，比如把速度、时间和距离关联起来，然后得出答案。

2、推理模型提示词，简单才是王道：推理模型和传统的生成式语言模型的差别在于，传统的生成式语言模型在收到 Prompt 后就会马上生成，如果生成出现错误或者质量不好，是没机会纠正的，只能继续生成下去或者后续纠正继续生成，但是推理模型可以在向用户输出内容之前，会先输出思维链（Chain of Thought），对输入的 Prompt 思考验证完成后，再开始生成。这意味着以前在提示词中加入COT的方式已经没必要了，也不需要复杂的角色扮演、示例，因为COT的存在，推理模型的“智能”程度高了很多，不需要角色设置、示例也能很好的理解和跟随指令。

所以到了推理模型，已经不需要太复杂的提示词模板，大多数时候简单的提示词就可以很好的效果，但上下文（背景信息）依旧很重要。

• 评测

评测不仅是对模型能力的评测，也是对提示词效果的评测。评测最重要的前提是沉淀业务本身的Badcase和Goodcase，这个需要业务之初就有意识的沉淀，而评测本身，既可以在自己工程里实现，也可以使用平台能力。

评测需要关心的维度：

• 准确率、RT、Total Token等智能、性能指标；

• 不同提示词的对比效果；

• 不同模型的对比效果；

但无论使用工程还是平台能力，最终还是需要人为介入查看结果，并对效果进行预估。

而对于业务复杂度相对简单的场景，可以基于Judge模型来实现自动评测和提示词自动优化，本质上是通过训练或微调专业的Judge模型来让AI评测AI，不需要人为介入。目前这套方案我们已经实现并且应用在了AI审核业务上，也取得了一定的成效。

04.AI进阶实践：Copilot模式实现

Copilot模式和Embedding模式的边界其实并没有特别清晰，二者本质上都是AI辅助完成任务，但通常而言，Copilot模式可以帮助我们解决一些相对复杂的问题。Copilot模式其中一个典型而简单的实现就是基于WorkFlow来做，所以这里就重点讲下WorkFlow的概念和实现过程：

▐  AI WorkFlow

WorkFLow通常指的是业务流程的抽象和自动化。如果想根据业务流程搭建一个WorkFlow，首先推荐的是基于AI开发平台来做，优点是简单易操作，和低代码平台一样拖、拉、拽即可实现。除此之外，还可以通过工程的形式搭建WorkFlow，比较推荐的是通过LangGraph框架来实现，但相应的学习成本也较高，不过可以很方便的结合更多工程能力。

LangGraph中的state、node、edge概念：

而相对复杂问题的解决能力，通常还需要让大模型能够使用工具和感知外部数据，这也是Copilot模式与Embedding模式的最大差异，自然而然就需要引入Function Calling 和 RAG能力：

• Function Calling

Function Calling即工具调用，能够让大模型获取到某个外部工具的执行结果。

这里要强调的一点是，大模型本身是不具备任何工具调用能力的。所有的工具调用实际上都是工程执行的，比如你有一个查询天气的工具，你告诉大模型说：写个代码调用下这个工具告诉我结果；或者你告诉大模型说：访问下谷歌网站告诉我今天天气；No，大模型都是做不到的，大模型只能和Token进行交互。

当大模型想要调用工具时，实际上输出的是一份结构化的文本，以Qwen为例：

<|im_start|>assistant<tool_call>{"name": "get_current_temperature", "arguments": {"location": "San Francisco, CA, USA"}}</tool_call><tool_call>{"name": "get_temperature_date", "arguments": {"location": "San Francisco, CA, USA", "date": "2024-10-01"}}</tool_call><|im_end|>

大模型会输出 <tool_call></tool_call> 标签包含要使用的工具名称和参数，由工程识别大模型输出中的标签后，执行对应工具后使用 <tool_response></tool_response> 标签将结果放在上下文返回给大模型。

看的这儿你可能会说：让大模型能够获取工具结果这么麻烦吗？我没有工程应用怎么办？不要慌，上述讲解的流程，大模型厂商已经帮我们实现好了。在模型训练的时候，就已经加入了工具调用的训练数据，能够确保大模型稳定输出和理解相关格式，并且封装好了相应的SDK给我们使用。而现在的AI开发平台和AI开发框架也已经对接好这些SDK，我们只需定义工具，告诉大模型可以使用的工具有哪些就可以了。

AI开发框架Function Calling使用示例(基于Spring AI)：

chatClient.prompt(prompt)          .toolCallbacks(toolCallbacks) //工具列表          .call()          .chatResponse();

最后需要提的一点是：我们可以配置的只有工具列表和工具描述，需要使用哪些工具是大模型自行决定的。所以当你遇到工具调用不符合预期的情况，可以考虑重新优化工具描述或者换个大模型，当然，提示词也是很重要的一环。

• RAG

RAG相信大家都比较熟悉，它能够让大模型基于当前Query通过向量检索的方式获取外部关联知识，然后放在上下文中作为大模型回答的参考，链路相对简单，这里就不详细介绍了。

在使用过程当中需要注意的是，知识库文档创建索引时的分段效果会直接影响RAG检索知识的效果，从而影响大模型的输出质量，所以在使用RAG时，一定要确认下分段的效果，确保关联知识可以完整的分到一个索引段中。例如：

像#0、1、4、8、9这种按章分块，模块清晰的分段检索效果就会比较好；但像#5这种脱离章节单独成段的分块，实际检索效果就会略打折扣，可以通过调整文档结构或者更改向量模型来优化。

▐  适配业务场景

最后总结下基于WorkFlow实现的Copilot模式所适配的业务场景。相信大家看到WorkFlow时就已经略知一二了，该模式适用于：需要结合大模型执行高确定性业务逻辑的流程型应用。

这么说可能也还会有些难以理解，实际上目前80%以上业务的AI场景都可以WorkFlow来实现，只有当你的业务流程是动态的，WorkFlow才没有办法承接。比如完成一个任务需要先让大模型生成计划，然后按照计划再去执行，这个计划是动态生成并需要动态反馈，WorkFlow就没办法做到，此时就需要用到下面要讲的Agents模式。

05.AI深入实践：Agents模式实现

在讲解Agents模式之前，有必要先来解释下Agent的概念：

Agent并非LLM时代的专属名词，在LLM（大语言模型）火爆之前，计算机和AI领域早已存在Agent的概念。此时Agent通常被称为“代理”，通常是由小模型、规则引擎、硬编码逻辑等技术组合成的一个“自动化的任务代理”，其适配的业务场景和上述讲解的Copilot模式很相似，所以有很多同学会将该模式的AI应用也称为Agent，在某种程度上也是合理的。

而在LLM时代，我们所称的Agent，更多是指代“智能体(Intelligent Agent)”的概念，是能够听懂自然语言指令，自主规划、分解、执行任务的计算机系统，所以是否具备“自主规划”能力，是Agent和Copilot的核心区别。

▐  计划-推理能力

目前业内对于大模型的“自主规划”能力已经有过不少探索，方向也大致可以分为两个：

• 一个是：大模型厂商从能力维度来增强大模型本身的推理能力，譬如DeepSeek R1、Qwen3、GPT-o3这些推理模型，已经初步具备了拆解任务，自主推理的能力；

• 另一个是：基于prompt的新范式，通过多步反馈的方式让LLMs交替完成任务推理轨迹的生成和具体行动的执行，从而使模型能够进行动态推理，即上文提到的，提示词工程的深入应用。

二者是相辅相成的，即便日后推理模型的能力强大到可以进行完全自主推理，但仍需要多步反馈来支持其完成整体计划。所以这里重点讲一下如何基于提示词工程来实现大模型的“计划-推理”能力，让即便是普通的基模也可以具备“自主规划”的能力。

• ReAct推理范式

ReAct范式是22年的一篇论文提出来的思想，核心是让大模型将推理(Reasoning)和动作(Acting)相结合，通过在内部进行多轮思考、行动及观察（Thought, Action, Observation），实现复杂问题的迭代解决过程。

ReAct示例：

关键概念：

Thought：由LLM模型生成，是LLM产生行为的依据。

Act：Act是指LLM判断本次需要执行的具体行为。可以根据LLM的思考，来衡量它要采取的行为是否合理。Act一般由两部分组成：行为和对象，用编程的说法就是API名称和对应的入参。

Obs：外界的反馈信息，通常是Act的执行结果，返回给LLM协助其做进一步分析或者决策。

一个完整的ReAct的行为，包含以下几个流程：

1.输入目标：任务的起点。

2.LOOP：LLM模型开始分析问题需要的步骤（Thought），按步骤执行Act，根据观察到的信息（Obs），循环执行这个过程。直到判断任务目标达成。

3.Finish：任务最终执行成功，返回最终结果。

其中LOOP即上文提到的多步反馈，需要靠工程来实现。每一步的提示词示例：

System Prompt：​​​​​​​

You are an all-capable AI assistant, aimed at solving any question presented by the user. You have various tools at your disposal that you can call upon to efficiently complete complex requests.
Question:%sRead the question again:%s
重要说明：1. 使用中文回答!

Next Prompt：​​​​​​​

为了回答问题，下一步应该做什么？
重要说明：1. 在调用工具前提供推理或思考过程！ 2. 在每一步反思：当前信息能否回答问题？是否需要调用其他工具获取更多信息？3. 当问题已经可以回答时，使用"terminate"工具结束对话！

以上即LOOP循环中每一步最简单的提示词样例，实际情况还需要根据大模型的反馈来执行Act和Obs流程，以及终止流程的执行条件。因为涉及到比较复杂的工程框架链路，这里就不详细讲解了。

读者只需要理解，我们通过提示词的不同应用范式，就可以实现譬如“推理”的高级能力。所以“自主规划”能力并没有很神秘的面纱，通过提示词工程即可实现。

这里也提供一个可以自己尝试ReAct过程的Prompt例子，感受一下最初级的ReAct交互的体验：读者自己充当一个ReAct框架，去执行Act和Obs过程。​​​​​​​

You are an assistant, please fully understand the user's question, choose the appropriate tool, and help the user solve the problem step by step.
### CONSTRAINTS ####1. The tool selected must be one of the tools in the tool list.2. When unable to find the input for the tool, please adjust immediately and use the AskHumanHelpTool to ask the user for additional parameters.3. When you believe that you have the final answer and can respond to the user, please use the TaskCompleteTool.5. You must response in Chinese;
### Tool List ###
[    Search: 如果需要搜索请用它.paramDescription ： [{"name": "searchKey", "description": "搜索参数","type":"String"}]    AskHumanHelpTool: 如果需要人类帮助，请使用它。paramDescription ： [{"name": "question", "description": "问题","type":"String"}]    TaskCompleteTool：如果你认为你已经有了最终答案，请使用它。paramDescription ： [{"name": "answer", "description": "答案","type":"String"}]]
You should only respond in JSON format as described below
### RESPONSE FORMAT ###{  {"thought": "为什么选择这个工具的思考","tool_names": "工具名","args_list": {“工具名1”:{"参数名1": "参数值1","参数名2": "参数值2"}}}}Make sure that the response content you return is all in JSON format and does not contain any extra content.

• Plan计划范式

Plan计划范式思想相对来说就比较简单，该范式要求大模型在执行任务之前，先将任务拆解成一个一个的小步骤，并在执行过程当中根据反馈不断调整计划，直到任务完成。

创建计划的Prompt示例：​​​​​​​

## 介绍你是一个AI助手，旨在帮助用户完成各种任务。你的设计目标是提供帮助、信息和多方面的支持。
## 目标你的主要目标是通过提供信息、执行任务和提供指导来帮助用户实现他们的目标。你致力于成为问题解决和任务完成的可靠伙伴。
## 你的任务处理方法当面对任务时，你通常会：1. 分析请求以理解需求2. 将复杂问题分解为可管理的步骤3. 为每个步骤使用合适的工具4. 以有帮助和有组织的方式交付结果
## 当前主要目标：创建一个合理的计划，包含清晰的步骤来完成任务。	
## 可用工具信息：%s	
你可以使用 planning 工具的 create 命令来创建计划，使用 %s 作为planId。
重要提示：1、计划中的每个步骤都必须以[Tool Name]开头，Tool Name 必须是上述列出的可用工具之一。例如："[TOOL_secKillOnDuty] 查询今日值班人员" 或 "[AGENT_summary] 总结查询结果"；2、每个工具仅能使用一次，请合理分解任务，制定步骤。如果步骤执行失败，允许重复使用当前步骤的工具；

更新计划的Prompt示例：​​​​​​​

## 全局任务:%s
## 全局计划信息:%s                               
根据当前计划的执行信息，判断是否需要更新计划来更好的完成任务？
你可以使用 planning 工具的 update 命令来更新计划，也可以使用 nothing 命令保持原有计划，使用 %s 作为planId。
重要提示：1、update 命令为全量更新，更新计划时需要传入完整的步骤；2、计划中的每个步骤都必须以[Tool Name]开头，Tool Name 必须是上述列出的可用工具之一。例如："[TOOL_secKillOnDuty] 查询今日值班人员" 或 "[AGENT_summary] 总结查询结果"2、每个工具仅能使用一次，请合理分解任务，制定步骤。如果步骤执行失败，允许重复使用当前步骤的工具； 

同样的，这也只是Plan范式中最简单的提示词样例，屏蔽掉了复杂的工程链路。

可以看得出来，Plan范式和ReAct范式在思考过程上呈现出比较大的差异：

• Plan范式是先列全局计划，然后再按照计划执行每一步；

• ReAct范式则是先往前走一步，再根据结果推理下一步要怎么走；

二者不同的思考过程决定了其擅长领域也是不同的：

• Plan范式擅长解决主观类问题，例如前段时间爆火的Manus，也是基于Plan范式实现的；

• ReAct范式擅长解决理性类问题，基于当前信息推理下一步的最佳行动。例如排查一个商品为什么不能报名；

虽然二者擅长领域不同，但目前的探索的最佳实践是可以将Plan范式和ReAct范式的优势结合起来，共同组成大模型的计划-推理能力，即：由Plan范式提供全局计划，每一步通过ReAct范式来执行，并将每一步的结果进行反馈至判断是否需要更新计划：

• 由于Plan可以先产出全局计划，所以可以通过沉淀优秀的计划模版来解决可能出现的低质量计划问题；

• 而ReAct优秀的推理能力则可以让其在细分领域表现出更好的效果；

• Multi-Agent实现

对于Multi-Agent而言，“计划-推理能力”只是其核心能力。每个域实际上都应用“计划-推理能力”构建成了每个域专属的Agent，并由上层大模型统一做意图识别与任务分发，并接受各域Agent的结果反馈推进任务执行，形成“MOE(混合专家)”形态的Multi-Agent：

这里其实有一个核心问题，就是如何让上层感知到各域Agent，以此作为计划-推理的依据，并且能够接收到各域Agent的结果反馈推进任务执行？看起来这个问题似乎很大，但解法其实很简单，就是把各域Agent也看做工具，交由大模型通过Function Calling调用，仅仅通过一个小技巧，就轻松实现了“MOE”形态的“Multi-Agent”。

当然这只是现阶段Multi-Agent的简单实现方案，如果想要做去中心化的Multi-Agent，或者想要使用别人的Agent，该做法都是不支持的。究其根本是目前还没有成熟的A2A协议，虽然目前已经有了业界比较认可的MCP协议，但该协议也只是解决了大模型远程工具调用的问题，应用在A2A上和FunctionCalling没有本质区别。相信不久的将来，随着A2A协议的完善，AI应用也会如雨后春笋般涌出。

如何学习AI大模型？

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的籽料得到学习提升，故此将并将重要的AI大模型籽料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频分享出来。

1.AI大模型学习路线图
2.100套AI大模型商业化落地方案
3.100集大模型视频教程
4.200本大模型PDF书籍
5.LLM面试题合集
6.AI产品经理资源合集

【点击领取】点击领取AI大模型2025最新学习资料、视频教程、学习路线，存下吧很难找全的！