7.0
热点
AI SCORE
技术实践2025-12-09 07:00
AI Agent 架构规范化讨论：框架与最佳实践
DEV Community · Morgan Willis#Agent架构#工程实践
Editor brief · 编辑速览
总结 Agent 开发框架和云托管方案的权衡，讨论不同架构的优劣。对新的 Agent 项目的技术决策有实际指导意义。
AI 智能体正变得越来越容易构建和托管。借助智能体框架和云端托管环境，你可以在一个下午内将智能体部署到云端。如今，无须编写大量代码或进行繁重的基础设施工作，就能搭建一套具备记忆、可观测性以及 MCP 工具连接能力的多智能体系统。
这种便利性，再加上 AI 编程助手让软件交付变得前所未有地容易，共同催生了一种值得讨论的趋势。许多开发者直接将 UI 连接到智能体，仿佛智能体运行时就是整个后端。这种方式看起来简洁，感觉也很高效。而且，大多数演示展示的正是这种模式，因此团队沿用并推广它也完全可以理解。
该图展示了一种客户端直接连接智能体的架构：系统只有一个入口点，由智能体运行时取代整个后端。
在探索想法时，这种方式很有效。但一旦从演示迈向真实应用，这种客户端到智能体的模式就可能开始暴露问题。这并不是因为某个特定的智能体运行时本身存在局限，而是因为真实的生产系统仍然需要那些一直以来必不可少的架构层。
Web 应用仍然需要输入清理。API 仍然需要速率限制。业务逻辑仍然需要有合适的归属。服务仍然需要与其他系统协同。当这些部分开始进入系统时，架构就会变得熟悉得多。
AI 智能体扩展了应用能够实现的功能，但并不会抹去优秀系统设计的基本原则。智能体本身并不是整个系统，而是系统内部的一项能力。
下面我们来谈谈这意味着什么，以及它为何重要。
术语说明：在本文中，运行时是指一种在服务端执行智能体逻辑的托管环境。全文使用 Amazon Bedrock AgentCore Runtime 作为示例，但相同的概念也适用于其他托管环境。智能体或智能体服务是你所部署的代码，其中包含智能体框架、提示词和工具集成。
上游服务或模块，是指请求到达智能体之前负责处理请求的所有组件（UI、网关、路由器和后端）。
下游服务或模块，是指智能体调用的工具和资源（MCP 工具、API、数据库和内部服务）。
当客户端直接与智能体运行时通信时，通常应由其他组件承担的职责，可能会完全缺失，也可能被塞进并不适合承载这些职责的智能体代码中。
如果缺少 Web 架构中的典型组件，智能体就需要负责处理：
请求和安全边界，包括输入清理、API 层级的授权规则、Web 流量过滤、速率限制、节流和安全检查。
输入清理、API 层级的授权规则、Web 流量过滤、速率限制、节流和安全检查。
应用与系统编排，包括协调服务、执行跨越多个系统的业务规则，以及管理需要在智能体会话之外具备持久性的工作流转换。
协调服务、执行跨越多个系统的业务规则，以及管理需要在智能体会话之外具备持久性的工作流转换。
弹性与运维相关事项，包括重试、退避行为、事件缓冲，以及保护下游系统的各种机制。
重试、退避行为、事件缓冲，以及保护下游系统的各种机制。
智能体或托管运行时或许能够处理其中一部分任务，但它们从来就不是为充当整个后端、中间层或 Web 服务器而设计的。这与大多数生产系统不会在缺少保护层的情况下让客户端直接调用 AWS Lambda 函数的原因相同。同样，在大多数使用场景中，智能体并不适合作为直接面向前端的服务。
以下是“客户端直接连接智能体”模式在生产环境中可能失效的三种情况：
流量、成本和负载模式会变得难以控制。当 UI 在没有上游边界的情况下直接与单个智能体服务通信时，系统就缺少一个适合执行速率限制、处理高噪声客户端或限制单个用户用量的位置。一个小缺陷、一段重试循环或一次使用量激增，都可能转化为大量 LLM 调用；在没有结构化节流或负载削减机制的情况下，这会带来难以预测的延迟和推理成本。
当 UI 在没有上游边界的情况下直接与单个智能体服务通信时，系统就缺少一个适合执行速率限制、处理高噪声客户端或限制单个用户用量的位置。一个小缺陷、一段重试循环或一次使用量激增，都可能转化为大量 LLM 调用；在没有结构化节流或负载削减机制的情况下，这会带来难以预测的延迟和推理成本。
由于所有内容都在同一个部署单元中交付，每次变更都会具有相同的影响范围。当验证逻辑、业务规则、集成代码和智能体行为全部位于同一个服务中时，每一个微小的变更都需要修改并重新部署整个智能体应用。调整一条业务规则、修复一个简单缺陷或修改提示词，都会具有相同的影响范围和回滚路径，这不仅会减慢迭代速度，也会让故障更难定位。
当验证逻辑、业务规则、集成代码和智能体行为全部位于同一个服务中时，每一个微小的变更都需要修改并重新部署整个智能体应用。调整一条业务规则、修复一个简单缺陷或修改提示词，都会具有相同的影响范围和回滚路径，这不仅会减慢迭代速度，也会让故障更难定位。
随着系统增长，重构会变得脆弱。当智能体服务充当整个后端时，系统的每个方面都会融合到同一个部署单元中。此外，许多智能体运行时只暴露一个类似 POST /invoke 的入口点，这意味着所有功能、工作流和行为都要通过同一个不加区分的入口点进入。
不同操作之间没有任何区分，因此你失去了那些通常用于执行权限控制、验证输入或应用业务规则的天然位置。在这种结构下，扩展架构会变得困难。以后添加新功能、队列或工作流编排，就意味着必须拆解紧密耦合的逻辑。增加功能甚至可能需要重写智能体，因为系统从未建立起能够支持其清晰演进的职责分离。
当智能体服务充当整个后端时，系统的每个方面都会融合到同一个部署单元中。此外，许多智能体运行时只暴露一个类似 POST /invoke 的入口点，这意味着所有功能、工作流和行为都要通过同一个不加区分的入口点进入。
不同操作之间没有任何区分，因此你失去了那些通常用于执行权限控制、验证输入或应用业务规则的天然位置。
在这种结构下，扩展架构会变得困难。以后添加新功能、队列或工作流编排，就意味着必须拆解紧密耦合的逻辑。增加功能甚至可能需要重写智能体，因为系统从未建立起能够支持其清晰演进的职责分离。
我们将系统拆分为多个模块，是因为每个部分都负责处理特定类型的复杂性，从而让系统的其他部分无须承担这些复杂性。这种关注点分离能够将职责限制在各自范围内，避免逻辑跨越边界泄漏，支持解耦，并使系统在规模扩大时更加可预测。
当所有内容都运行在单一边界内时，可测试性也会受到影响。如果将关注点分离成清晰的模块，那么隔离组件、模拟依赖和执行有针对性的回归测试都会容易得多。
经验丰富的开发者和系统工程师对此有着直观的认识，但 AI 工具的快速进步大幅降低了部署智能体的门槛，以至于人们可能在尚未具备支撑智能体所需的架构背景之前，就已经将其交付上线。
作为一个技术社区，我们应该更多地传播真实世界中的模式和经验教训。在简化教程之外提供更多高级使用场景的示例，将使我们能够共同学习，并逐步形成一套适用于良好架构智能体的指导原则。
与其他任何解决方案一样，当你引入更多活动部件时，也就需要负责它们的运行和维护。
额外的组件增加复杂性，就像拥有负载均衡器、API 网关和数据库连接池增加复杂性一样。这些组件之所以存在，是因为它们吸收或抽象特定风险或责任类别的处理，这样你的核心应用代码就不必处理。它们使整个系统更加可靠。
这并不意味着你必须构建大规模的、高度分布式的微服务架构才能正确使用智能体。
你可以在智能体前面运行一个简单、清洁的设置，包括负载均衡器和路由器组件，或者添加一个 API 网关进行基本的流量整形和保护，然后停止。这种模式对许多团队来说完全有效，特别是在早期。
同时，全球运营的公司或具有复杂需求的项目自然需要更多的组件。它们可能引入额外的服务用于编排、工作流持久性、消息缓冲、网络连接或跨系统协调。这些架构更复杂，因为需求和流量模式需要这种复杂性。
这个范围的两端都是合理的。重要的是为你的用例和约束选择正确的架构。目标不是为了追求复杂性而追求复杂性，也不是把一切都展平到单个模块中。而是引入最少数量的组件，这些组件能够有意义地减少风险、改进安全性，并在系统增长和变化时实现灵活性。
这种平衡是帮助你从简单开始，而不会在后期把自己逼入困境的关键。
考虑到以上所有因素，什么应该属于智能体，什么应该属于其他组件？
AI 智能体框架使模糊这些边界变得容易，但保持清晰的边界是防止系统崩溃成一个昂贵混乱的关键。你决定如何构建智能体的方式在很大程度上取决于你的用例和技术选择。智能体框架在其实现方式上各不相同，不同情况下的需求也各不相同。没有一个通用的答案。以下是开始使用的一些高级指南。
将这些关注点分离，可以将安全性、验证和业务规则与核心智能体代码分开，减少更改的影响范围，并让你可以更改智能体行为，而无需不断重写保持系统基本运行的逻辑。
智能体通常负责解释目标、选择行动和对上下文进行推理。决策可能来自模型、图级别编排或确定性路由，具体取决于框架和用例。
工具封装操作。模型可能确定何时需要工具，工具控制如何执行底层操作。
智能体就像任何其他功能一样融入系统。你可以保持简洁的设计，也可以随着规模和需求的变化扩展到更分布式的设计。
下面突出显示的模式有意忽略了 AI 智能体系统的其他部分，如内存、MCP 服务器、RAG 和多智能体通信。这些是重要的话题，但这些组件位于智能体运行时内部或其下游，而不是我们这里重点关注的上游架构组件中。
你可以根据你的用例扩展或调整这些模式。我将使用 AWS 服务作为示例，以 Amazon Bedrock AgentCore Runtime 作为智能体运行时，尽管你可以用其他提供商的服务替换这些组件并保持相同的模式。
由于以下示例使用 AWS 服务，这里是基础知识。AgentCore Runtime 是一个用于托管 AI 智能体的托管无服务器环境。它处理部署、扩展和会话管理，并与 AWS 内外的许多工具和服务集成。它支持基于 IAM 和 OAuth 的身份验证，因此你可以将其插入现有的安全模型中。要了解更多关于 AgentCore Runtime 的信息，请点击这里。
客户端 → Amazon API 网关 + AWS Web 应用防火墙 (WAF) → Amazon Bedrock AgentCore Runtime → 下游服务
何时使用：
工作方式：
API 网关和 AWS WAF 提供身份验证、速率限制、路由、web 流量过滤和调用智能体前的受控边界。
你可以选择在 API 网关和智能体运行时之间包含 AWS Lambda 函数，这允许你在调用智能体时编写自定义逻辑，包括确定性输入验证或其他逻辑。
AgentCore Runtime 使用 OAuth 或 IAM 处理入站身份验证。
如果你稍后需要为传入消息进行队列处理，你可以在 API 网关和智能体之间包含 Amazon SQS，并使用处理消息并调用 AgentCore Runtime 的 Lambda 函数。这让你可以处理尖峰流量或有序消息处理，而无需更改智能体本身的工作方式。
客户端 → 应用负载均衡器 + AWS WAF → Web 服务器，例如，在 Amazon EC2、Amazon ECS 或 AWS Lambda 上 → Amazon Bedrock AgentCore Runtime → 下游服务
何时使用：
工作方式：
许多生产工作负载仍然运行传统 web 后端。当你添加 AI 智能体时，这些架构不会消失或需要大规模改造。你扩展它们。
客户端通过应用负载均衡器发送请求，该均衡器可以与 AWS WAF 集成进行 web 过滤。从那里，请求被发送到 Amazon EC2、容器或 Lambda 上的 web 后端。
后端处理业务逻辑和系统协调。智能体是它使用的一个功能，通过 VPC 端点调用，以保持流量隐私。
来自 Amazon EventBridge 的事件 → AWS Step Functions → AWS Lambda → Amazon Bedrock AgentCore Runtime → 下游系统
何时使用：
工作方式：
在这里，智能体是更大工作流程、管道或自动化任务的一部分。智能体可能异步运行，完全没有面向用户的 UI。
来自 Amazon EventBridge 的事件或计划运行可以使用 IAM 作为身份验证方法直接在 AgentCore Runtime 中调用智能体。你可以选择引入 AWS Step Functions 作为协调长时间运行或多阶段工作流步骤的方式，这些工作流混合确定性和非确定性步骤。
Step Functions 提供了工作流控制机制，因此智能体不需要管理重试、分支或整体工作流状态。
智能体执行其工作并根据需要调用下游服务或工具，而步骤之间的协调由 Step Functions 处理。这允许你在之前使用 AWS Lambda 等服务运行确定性步骤，在之后使用 Amazon Simple Notification Service 通知相关方，或与你的智能体并行调用各种服务。同样，你可以用另一个工作流编排器替换 Step Functions，概念仍然适用。
这些模式让你从简单开始，仅在需要时引入组件，并逐步发展为更分布式或成熟的架构。
如果你从这篇文章中只记住一件事，请记住这一点：问题不在于你是否可以将客户端直接连接到智能体。从技术上讲，你可以。问题是你是否应该这样做。
从短期来看，这可能感觉快速且简单。从长期来看，它导致一个脆弱的系统，难以扩展、难以理解，并且维护成本高。
一个结构良好的架构让智能体成为你系统中的一等公民，而不会被属于其他地方的关注点所累。这样你可以获得两全其美的结果：AI 智能体推理的强大功能与经过验证的分布式系统设计的可靠性相结合。
当然，client→AI 智能体教程仍然很有用。它们的存在是为了讲授一个专注的概念，不会让你陷入特定用例和复杂细节之中。它们向你展示了如何让 AI 智能体运行，而不是如何围绕它设计完整的应用程序。
但一旦你朝着生产环境迈进，问题就变成了：我们是构建了一个完整的系统，还是只停留在 AI 智能体？
AI 智能体是大脑。架构是身体。你需要两者。
如果你想了解更多关于 AWS 上的 AI 智能体设计模式，请访问 AWS 上的 Agentic AI 模式和工作流，并继续关注 AWS 团队的更多博客文章，我们将在其中探索针对 AI 智能体用例和高级设计模式的特定架构。
某些评论可能仅对已登录的访问者可见。登录以查看所有评论。
如果需要进一步操作，你可以考虑阻止此用户和/或举报滥用。