构建企业级高可靠 AI Agent 系统架构设计的关键要素 原创

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

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

1、AI Agent 到底是什么？

并没有一个一致的 AI Agent 定义，它们通常通过不同的视角来定义。

OpenAI 采用了一种更高层次、更思想引领式的方法来定义 AI Agent：

AI Agent 是独立为您完成任务的系统。

这是一个模糊的表述，它并没有真正帮助理解什么是 AI Agent。这只是一种思想引领，并不实用。

与之相比，Anthropic 的定义是这样的：

“AI Agent”可以有几种不同的定义方式。一些客户将 AI Agent 定义为能够在较长时间内独立运行的完全自主系统，使用各种工具来完成复杂任务。还有些人用这个词来描述更规范的实现，它们遵循预定义的工作流。在 Anthropic，我们将所有这些变体都归类为 AI Agent 系统，但我们在工作流和 AI Agent 之间画出了一个重要的架构区别：

工作流是通过预定义的代码路径编排 LLM 和工具的系统。

AI Agent 则是 LLM 动态指导自身流程和工具使用，控制它们完成任务的方式的系统。

Anthropic 对 AI Agent 的定义更加精确和具有技术性。

他们也提到了“AI Agent 系统”这个概念，并将工作流和 AI Agent 都归类为它的变体。我们看到的几乎所有生产中的“AI Agent 系统”都是“工作流”和“AI Agent”的组合。

Anthropic 将 AI Agent 定义为“本质上只是基于环境反馈在循环中使用工具的 LLM”。

这些类型的 AI Agent 由以下参数确定：

• 要使用的模型
• 要使用的指令（系统提示词）
• 要使用的工具

你在一个循环中调用模型。如果/当它决定调用一个工具时，你运行那个工具，获取一些观察/反馈，然后将其传回 LLM。你一直运行，直到 LLM 决定不调用工具（或者它调用一个触发停止条件的工具）。

OpenAI 和 Anthropic 都明确指出，工作流是一种与 AI Agent 不同的设计模式。在那里，LLM 的控制权更小，流程更具确定性。

OpenAI 和 Anthropic 也都明确指出，你并不总是需要 AI Agent。在许多情况下，工作流更简单、更可靠、更便宜、更快且性能更好。Anthropic 文章中有一句很棒的话：

在使用 LLM 构建应用程序时，我们建议寻找尽可能简单的解决方案，并且只有在需要时才增加复杂性。这可能意味着根本不需要构建 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 架构设计模式

根据我多年的架构设计经验，整理总结了一些针对 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 Agent 企业级落地还有哪些注意点？

本文转载自​​玄姐聊AGI​​  作者：玄姐