企业级 AI Agent 系统落地架构设计剖析

小天才学习机打游戏

于 2025-05-17 10:45:00 发布

阅读量884

点赞数 15

文章标签：人工智能数据库算法语言模型 chatgpt

本文链接：https://blog.csdn.net/m0_59164520/article/details/148007119

版权

MCP构建AI大模型技术架构新体系

本文从以下4个方面详细剖析：

AI Agent 系统到底是什么？
构建 AI Agent 系统的难点是什么？
AI Agent 框架种类和选型
AI Agent 6种架构设计模式

1.AI Agent 系统到底是什么？

可以将智能 AI Agent 系统简单地理解为一个接收用户输入，然后交替调用以下两个组件的系统：

一个大语言模型（我们称之为“推理模型”）：根据输入、可能附加的自动检索上下文和历史对话来决定采取什么行动。推理模型将输出（a）推理下一步应该采取什么行动的文本，以及（b）指定行动的结构化信息（哪个行动，行动输入参数的值等）。输出的“行动”也可能是没有剩余行动可采取。
工具：这些工具不一定与大语言模型有关，可以执行推理模型指定的各种行动，以生成将被纳入下一次调用推理模型的信息的结果。推理模型本质上是在提示词中选择系统可以访问的工具和行动集。

这就创建了一个基本的智能 AI Agent 系统循环：

一个基本的智能循环是根据这个智能循环如何向用户展示，智能 AI Agent 系统有不同的风格，这些大语言模型不是作为纯粹的内容生成器，而是更多地作为工具选择推理组件的功能。

“推理”这个词也被过度使用了——在智能领域，它有一个非常特定的含义。它意味着使用大语言模型来选择下一步应该采取什么行动，即应该调用哪个工具以及使用什么参数。

“推理”这个词也被像 OpenAI 的 o1 这样的模型使用过，在推理中，它意味着完全不同的事情。对于这些大语言模型，“推理”指的是思维链提示词。大模型首先输出中间步骤，然后尝试提供查询的最终响应，试图模仿人类如何解决问题，而不是依赖纯粹的模式匹配算法。

“智能”的另一个误用是所谓的“AI 工作流程”。比如：有人可能会构建一个自动化或工作流程，该工作流程接收原始文档，使用大语言模型进行对象识别，然后清理提取的元素，然后使用另一个大语言模型总结元素，然后将总结添加到数据库中。有多个大语言模型调用，但大语言模型不是作为工具调用推理引擎使用的。我们提前指定应该调用哪些大语言模型以及如何调用，而不是让大语言模型实时决定应该调用哪些工具。这只是自动化，不是智能。

超级简单的智能与非智能示例：假设你向 AI Agent 系统请求制作披萨的食谱。在非智能世界中，你只需将该提示词传递给大语言模型并让它生成结果。

在智能世界中，AI Agent 可能拥有的工具之一是从食谱书中检索食谱，其中一个食谱是披萨。在这个智能世界中，系统将使用大语言模型（推理模型）来确定，鉴于提示词，我们应该使用“食谱工具”并输入“披萨”来检索正确的食谱。然后调用该工具，输出该食谱的文本，然后推理模型将使用此工具调用的输出来确定没有更多的工作要做，并完成其“循环”。下图显示非智能系统与智能 AI Agent 系统流程的区别。

2.构建 AI Agent 系统的难点是什么？

我想大多数人都会同意构建 AI Agent 是困难的。或者更准确地说–构建 AI Agent 的原型很容易，但可靠的和企业级的 AI Agent，能够支持关键业务应用的 AI Agent，这是很难的！

棘手的部分正是这个–使其可靠。你可以轻松制作一个看起来不错的 Demo 演示。但你能用它来支持关键业务应用吗？没有大量工程架构设计和优化工作是不行的。

几个月前，LangChain 对 AI Agent 构建者做了一项调查，问他们：“将更多 AI Agent 投入生产使用的最大限制是什么？”远远超过其他答案的第一位回答是“性能质量”——让这些 AI Agent 正常工作仍然非常困难。

第一、是什么导致 AI Agent 有时表现不佳？

LLM 搞砸了。

第二、为什么 LLM 会搞砸？

两个原因：（1）模型不够好；（2）传递给模型的上下文错误（或不完整）。

从我们的经验来看，通常是第（2）种情况。是什么导致了这种情况？

系统提示词不完整或简短
用户输入模糊
无法访问正确的工具
工具描述不佳
没有传入正确的上下文
工具响应格式不佳

构建可靠的 AI Agent 系统的难点是确保在每一步中，LLM 都有合适的上下文。这包括控制输入到 LLM 的确切内容，以及运行适当的步骤来生成相关内容。

在我们讨论 AI Agent 框架时，记住这一点很有帮助。任何使控制确切传入 LLM 的内容变得更困难的框架，只是在给你添麻烦。

3.AI Agent 框架种类和选型

AI Agent 框架在几个维度上有所不同。理解这些维度是正确选型 AI Agent 框架的关键。

第一、工作流与 AI Agent

大多数框架包含更高层次的 AI Agent 抽象。一些框架包含了常见工作流的某种抽象。LangGraph 是一个用于构建 AI Agent 系统的低层次编排框架。LangGraph 支持工作流、AI Agent 以及两者之间的任何东西。我们认为这是至关重要的。如上所述，大多数生产中的 AI Agent 系统是工作流和 AI Agent 的组合。一个生产就绪的框架需要同时支持两者。

让我们记住构建可靠 AI Agent 的难点–确保 LLM 有正确的上下文。工作流有用的部分原因是它们使向 LLM 传递正确上下文变得容易。你决定数据流动的确切方式。

当你思考要在 AI 应用中使用“工作流”还是“AI Agent”，需要考虑两件事：

可预测性与代理性
低门槛，高上限

第二、可预测性与代理性

随着你的系统变得更加具有代理性，它将变得不那么可预测。

有时你希望或需要你的系统是可预测的——为了用户信任、监管原因或其他原因。

可靠性并不完全与可预测性一致，但在实践中它们可以密切相关。

你希望在这条曲线上的位置相当具体于你的 AI 应用程序。LangGraph 可以用于构建位于这条曲线任何位置的应用程序，允许你移动到你想要的位置。

第三、低门槛，高上限

当思考框架时，考虑它们的门槛和上限是有帮助的：

低门槛：一个低门槛框架对初学者友好，易于上手。
高门槛：一个有高门槛的框架意味着它有陡峭的学习曲线，需要相当多的知识或专业知识才能有效地开始使用。
低上限：一个有低上限的框架意味着它在能做的事情上有局限性（你会很快超出它的能力）。
高上限：一个高上限框架为高级用例提供广泛的能力和灵活性（它会随着你一起成长）。

工作流框架提供了高上限，但也带来了高门槛–你需要自己编写大量的代理逻辑。

AI Agent 框架低门槛，但上限低–易于上手，但对于非平凡的用例则不够用。

LangGraph 旨在具有易于上手（内置的 AI Agent 抽象使上手变得容易）和高上限（底层功能以实现高级用例）的特点。

第四、声明式与非声明式

声明式框架有其好处。也有缺点。这是程序员之间看似无休止的辩论，每个人都有自己的偏好。

当人们说非声明式时，他们通常暗示命令式是替代品。

大多数人会将 LangGraph 描述为一个声明式框架。这只部分正确。

首先，尽管节点和边之间的连接是以声明式的方式完成的，但实际的节点和边无非是 Python 或 TypeScript 函数。因此，LangGraph 是一种介于声明式和命令式之间的混合体。

其次，实际上支持除了推荐的声明式 API 之外的其他 API。具体来说，支持函数式和事件驱动 API。虽然我们认为声明式 API 是一个有用的思维模型，但我们认识到它并不适合每个人。

关于 LangGraph 的一个常见评论是它类似于 Tensorflow（一个声明式深度学习框架），而像 Agents SDK 这样的框架则类似于 Pytorch（一个命令式深度学习框架）。

这是不正确的。像 Agents SDK（以及原始 LangChain、CrewAI 等）这样的框架既不是声明式的，也不是命令式的——它们只是抽象。它们有一个 AI Agent 抽象（一个 Python 类），它包含运行 AI Agent 的大量内部逻辑。它们不是真正的编排框架。它们只是抽象。

第五、AI Agent 抽象

大多数 AI Agent 框架包含一个 AI Agent 抽象。它们通常从一个涉及提示词、模型和工具的类开始。然后它们添加一些更多的参数……然后更多……然后甚至更多。最终，你得到了一长串参数，这些参数控制着多种行为，所有这些都抽象在一个类后面。如果你想查看发生了什么，或者改变逻辑，你必须进入类并修改源代码。

这些抽象最终使得很难理解或控制在所有步骤中到底有什么进入 LLM。这很重要–拥有这种控制对于构建可靠 AI Agent 至关重要（如上所述）。这是 AI Agent 抽象的危险。

我们在这方面吃了不少苦头。这是原始 LangChain 链和 AI Agent 的问题。它们提供了阻碍的抽象。两年前的一个原始抽象是一个 AI Agent 类，它接受模型、提示词和工具。这不是一个新概念。当时它没有提供足够的控制，现在也没有。

说清楚，这些 AI Agent 抽象确实有一些价值。它们使上手变得容易。但我不认为这些 AI Agent 抽象足以构建可靠的 AI Agent（也许永远不够）。

我们认为，最好将这些 AI Agent 抽象视为 Keras。它们提供了更高层次的抽象，以便轻松上手。但至关重要的是要确保它们是建立在更低层次的框架之上的，这样你就不会超出它的能力。

这就是为什么在 LangGraph 之上构建了 AI Agent 抽象。这提供了一种轻松上手 AI Agent 的方式，但如果你需要逃脱到底层 LangGraph，你可以轻松做到。

第六、多 AI Agent

通常，AI Agent 系统不会只包含一个 AI Agent，它们会包含多个。OpenAI 在他们的报告中说：

对于许多复杂的工作流，将提示词和工具分配到多个 AI Agent 中可以提高性能和可扩展性。当你的 AI Agent 无法遵循复杂指令或始终选择错误的工具时，你可能需要进一步分解你的系统并引入更多的不同 AI Agent。

多 AI Agent 系统的关键部分是它们如何通信。同样，构建 AI Agent 的难点是将正确的上下文传递给 LLM。这些 AI Agent 之间的通信很重要。

有很多方法可以做到这一点！交接是一种方式。这是 Agents SDK 的一个 AI Agent 抽象。

但这些 AI Agent 之间通信的最佳方式有时可能是工作流。这种工作流和 AI Agent 的混合通常能提供最佳的可靠性。

同样 AI Agent 系统不仅仅是工作流，或者只是一个 AI Agent。它们可以是而且通常是两者的组合。

总之，以上 AI Agent 的6个种类，在实际的业务场景中可以自由组合，正如 Anthropic 在他们的博客文章中指出的：

组合和定制这些模式

这些构建块并不是规定性的。它们是开发者可以根据不同用例塑造和组合的常见模式。

4.AI Agent 6种架构设计模式

根据我多年的架构设计经验，整理总结了一些针对 AI Agent 6种架构模式，以下详细剖析。

第一、 AI Agent 路由分发架构模式

当用户输入一个 Prompt 查询时，该查询会被发送到路由转发模块，而路由转发模块则扮演着对输入 Prompt 进行分类的角色。

如果 Prompt 查询是可以识别的，那么它会被路由到小模型进行处理，这通常是一个更准确、响应更快且成本更低的操作。然而，如果 Prompt 查询无法被识别，那么它将由大模型来处理。尽管大模型的运行成本较高，但它能够成功返回更多种类型查询的答案。通过这种方式，大模型应用产品可以在成本、性能和用户体验之间实现平衡。

第二、AI Agent 代理架构模式

在任何一个生态系统中，都会有多个针对特定任务领域的专家，并行工作以处理特定类型的查询，然后将这些响应整合在一起，形成一个全面的答案。

这样的架构模式非常适合复杂的问题解决场景，在这种场景中，问题的不同方面需要不同的专业知识，就像一个由专家组成的小组，每个专家负责处理更大问题的一个方面。

更大的模型（比如：Qwen3-235B）负责理解上下文，并将其分解为特定的任务或信息请求，这些任务或信息请求被传递给更小的代理模型。这些代理模型可能是较小模型，它们已经接受过特定任务的训练，或者是具有特定功能的通用模型，比如：BERT、Qwen3-7B、上下文提示和函数调用。

第三、基于缓存的微调 AI Agent 架构模式

我们将缓存和微调引入到 AI Agent 应用架构中，可以解决成本高、推理速度慢以及幻觉等组合问题。

通过缓存初始结果，能够在后续查询中迅速提供答案，从而显著提高了效率。

当我们累积了足够的数据后，微调层将启动，利用早期交互的反馈，进一步完善一个更为专业化的私有大模型。

专有私有大模型不仅简化了操作流程，也使专业知识更好地适应特定任务，使其在需要高度精确性和适应性的环境中，比如：客户服务或个性化内容创建，表现得更为高效。

对于刚入门的用户，可以选择使用预先构建的服务，比如：GPTCache，或者使用常见的缓存数据库：Redis、Cassandra、Memcached 来运行自己的服务。

第四、面向目标的 AI Agent 架构模式

对于用户的 Prompt 提示词，AI Agent 会基于大模型先做规划（Planning），拆解成若干子任务，然后对每个子任务分别执行（Action），同时对每一步的执行结果进行观测（Observation），如果观测结果合格，就直接返回给用户最终答案，如果观测结果不合格或者执行出错，会重新进行规划（Replanning）。

这种面向目标的 AI Agent 架构模式非常常见，也是 AGI 大模型时代，每一个程序员同学都需要掌握的架构设计模式。

第五、AI Agent 智能体组合架构模式

该架构设计模式强调了灵活性，通过模块化 AI 系统，能自我重新配置以优化任务性能。这就像一个多功能工具，可以根据需求选择和激活不同的功能模块，对于需要为各种客户需求或产品需求定制解决方案的企业来说，这是非常有效的。

我们可以通过使用各种自主代理框架和体系结构来开发每个 AI Agent，比如：CrewAI、Langchain、LLamaIndex、Microsoft Autogen 和 superAGI等。

通过组合不同的模块，一个 AI Agent 可以专注于预测，一个处理预约查询，一个专注于生成消息，一个 AI Agent 来更新数据库。将来，随着专业 AI 公司提供的特定服务的增多，我们可以将一个模块替换为外部或第三方服务，以处理特定的任务或领域的问题。

第六、AI Agent 双重安全架构设计模式

围绕大模型的核心安全性至少包含两个关键组件：一是用户组件，我们将其称为用户 Proxy 代理；二是防火墙，它为大模型提供了保护层。

用户 Proxy 代理在查询发出和返回的过程中对用户的 Prompt 查询进行拦截。该代理负责清除个人身份信息和知识产权信息，记录查询的内容，并优化成本。

防火墙则保护大模型及其所使用的基础设施。尽管我们对人们如何操纵大模型以揭示其潜在的训练数据、潜在功能以及当今恶意行为知之甚少，但我们知道这些强大的大模型是脆弱的。

在安全性相关的技术栈中，可能还存在其他安全层，但对于用户的查询路径来说，Proxy 代理和防火墙是最关键的。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

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

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

在这里插入图片描述