亚马逊AWS官方博客
企业级 Agentic AI 架构设计
摘要:本文围绕 Agentic AI 的演进趋势、架构设计、治理机制及价值评估,提供一套”可用、可控、可度量”的系统方法。将从 AI Agent 概念、行业应用、设计方法论、核心组件及部署等方面,帮助技术人员理解并设计可复用、可审计的 Agentic AI 工程实践。
目录
一、引言
生成式 AI 正从对话型工具迈向具备目标感、可调用工具、能自行规划并执行的 Agent,成为企业的”数字队友”。咨询机构将其列为 2025 年关键技术趋势,强调其将 GenAI 从被动生成推向”自主、以任务为中心的执行”。零售行业率先在消费者服务与一线运营的可度量场景中应用:亚马逊的 Rufus 购物助手、沃尔玛的员工协作工具、Shopify 的商家决策支持系统等,均展示了明确的业务价值与效率提升。
同时,监管框架如中国生成式人工智能服务管理办法、欧盟 AI 法律和风险管理指南正在成形,要求企业通过策略分层、审计追溯与人机共治来实现 Agent 的”可控自主”。本文将围绕 Agentic AI 的演进趋势、需求场景价值映射、架构设计要素、设计范式、治理机制、部署运维及价值评估,提供一套将”可用、可控、可度量”的 Agentic AI 架构落地为可复用与可审计工程实践的系统方法。
为了更加完整地让技术人员理解并设计 Agentic AI,下面将分别介绍 AI Agent、Agentic AI 在行业内的应用、如何设计 Agentic AI 以及核心的设计方法论、Agentic AI 的核心组件以及部署。
二、AI Agent 介绍
2.1 Agentic AI 和 AI Agent
Agentic AI 是一种具备目标感和自主性的智能框架,能够支持 AI Agents 在无需持续人工干预的情况下完成复杂任务。它强调“主动执行”,区别于传统软件的固定规则和传统 AI 的被动响应。
AI Agent 是运行在 Agentic AI 框架中的自主软件体,具备推理规划、记忆、工具调用和自主执行等核心能力,可以独立感知环境并采取行动。
两者关系可以理解为“城市与车辆”:
- Agentic AI 提供统一的基础设施和规则(任务编排、权限与风控、可观测与评测),确保系统整体可控、可度量、可演进;
- AI Agents 则在框架内承担具体角色(如商品上新、定价、补货、客服、风控),通过分工协作与外部系统交互,高效推动业务目标实现。
因此,Agentic AI 不仅是多个 AI Agents 的运行土壤和方法论框架,也使智能系统从“被动响应”进化到“主动执行”。
2.2 Agent 的发展可以简单分为下面几个阶段:
[图 1] |
Agentic AI 的核心概念
[图 2] |
Agentic AI 和传统的服务区别如下:
[图 3] |
2.3 发展趋势
根据市场数据,主动式 AI(Agentic AI)市场正经历爆发性增长,预计将从 2025 年的 138.1 亿美元增长至 2032 年的 1408 亿美元,年复合增长率高达 39.3%。企业采用方面呈现显著趋势:82%的大型企业计划在未来 3 年内大规模部署 AI 智能体;78%的跨国企业正用 AI 智能体替代传统 RPA(机器人流程自动化)固定脚本,实现工作流程的动态调整,提供更智能的自动化并显著减少人工干预。
到 2028 年,约 15%的日常工作决策将通过主动式 AI 自主完成,同时 33%的企业软件应用将集成主动式 AI 功能,相比之下 2024 年这一比例不到 1%。这些数据表明主动式 AI 正从概念阶段迅速转向实际应用,并将在企业自动化和决策过程中发挥越来越重要的作用
三、Agentic AI 在零售行业内的应用
这里以零售行业的典型业务流程举例:
[图 4] |
Agentic AI 几乎可以应用到各个业务流程中,如果以基于 Agentic AI 的“产品推荐”举例,则可以规划如下:
[图 5] |
图表展示了 Agentic AI 服务在产品推荐场景中的工作流程。左侧是用户查询示例,如”基于偏好推荐产品”、”了解品牌历史”、”寻找相似服装”等。从图中可以看到:
- 不同的查询会被路由到不同的 Agent 进行处理。
- Agent 之间也可以互相交互——例如,虚拟试穿和服装搭配师可能首先调用视觉搜索来识别用户上传图片中的产品。
- Agent 使用特征存储和向量数据库,并利用模型服务来获取知识。
- 在需要时,它们会调用外部第三方 API——例如,虚拟试穿可能会检查库存数据,以便只推荐有库存的产品。
同时,但并不是所有的场景都适合使用 Agentic AI。下面我们总结了 Agentic AI 的使用的决定因素:
[图 6] |
从这些决定因素,可以帮助我们有效地判断是否需要使用 Agentic AI。特别是对于大量的流程明确、需要解决的问题相对固定简单,那么使用传统的代码实现会更加有效。
四、架构设计
如果我们确定要使用 Agentic AI,那么如何设计合理的系统架构呢?下面将从设计方法论,设计系统组件,系统部署三个方面来说明:
4.1 设计方法论
根据大量的实践经验,设计 Agentic AI 首先需要有好的协作模型,它就像一个公司的组织结构一样,CEO 下面分了不同的部门,每个部门里面又不同的职能结构,这个组织结果决定了公司的所有业务如何开展;然后则需要定义好每个 Agent 的职责,就像企业的员工一样,两个员工即使在同一个部门或者领导下面,但是会有不同的分工,好的分工既能提高效率,又能减少浪费。其次是定义好的推理策略,就像定义每个员工的工作流程一样,每天的日常先做什么后做什么、有哪些工具可以使用。最后是好的控制和评估 Agent 的方法,就像员工的 KPI 监控和绩效考评一样,用于保证 Agent 按照既定的目标在工作。
基于这些原则,我们 Agent 的设计流程如下:
[图 7] |
针对上面的原则我们分别进行详细说明
4.1.1 清晰的协作模型
这里以供应链中的协同管理为例,这里假设存在供应链流程业务流程里面,先预测需求 → 决定库存补货 → 安排物流配送 → 制定营销活动 → 再反馈到预测,这些活动相互依赖和制约,比如库存想一次性大批补货,但物流容量/时段有限,可能运输瓶颈;库存紧张或物流受限时,营销却想大促销,会造成履约风险。
所以针对几个核心 Agent:销售预测,库存管理,物流管理,营销管理。我们设计协作模型的时候,主要分为三大类的架构类型:
[图 8] |
- 垂直协作架构:存在主 Agent(Leader)统筹全局决策,多个子 Agent 分工执行,各自向主 Agent 汇报结果(层级结构)
适用于需分解子任务且集中控制的场景,如供应链协同中一个 Agent 统管采购决策,其余 Agent 执行库存、物流等子任务;
- 水平协作架构:无固定主从关系,Agent 之间地位平等,通过共享记忆或通信协议进行协商,共同决策。
适用于需要集思广益或不同专家 Agent 共同决策的场景,如营销方案制定,由数个 Agent(顾客偏好、竞争情报等)讨论达成最优策略
- 混合架构:结合上面两种方式,在一个类业务流程中,根据具体情况,部分使用垂直架构,部分使用水平架构
适用于更加复杂的场景,即需要单一统筹决策,也需要多 Agent 共同协商的情况
4.1.2 明确定义的 Agent 边界
Agent 边界,定义了 Agent 能够做什么,不能够做什么,和其他 Agent 的职责划分是怎么样的。这里从为什么 Agent 需要定义明确的边界和如何定义 Agent 的边界进行说明
[图 9] |
4.1.3 可调整和可追踪的推理策略
这里列举了一些常见的规划和推理的策略。不同的策略适用于不同的场景,对于具体哪种场景使用哪种策略,我们需要根据场景的特性进行选择,并且进行充分的测试后得出结论。
[图 10] |
4.1.4 可控和可评测的能力
下面这张图展示了 AI 代理系统的四个关键评估维度:可观测性、策略与资源控制、故障恢复与弹性、目标驱动评估。每个维度都有相应的核心指标,如跟踪覆盖率、速率限制命中率、备用触发率和任务成功率等。图中橙色线条显示了系统在这些维度上的当前表现水平,形成了性能雷达图,用于全面评估和监控 AI 代理系统的运行状况和效能。
[图 11] |
4.2 核心技术组件
前面我们定义的流程中的第 3 步:“定义内部工作流”,那么这些内部的工作流涉及哪些组件呢?这里提供一个多 Agent 的概览图如下:
[图 12] |
针对图中的核心组件分层描述如下:
| 领域 | 组件 | 描述 |
| 服务域 | Agent 服务 | 执行业务逻辑,包括知识、推理与规划、行动、学习与适应 |
| 通信协议 | 实现服务间数据和消息流通 | |
| 服务发现 | 提供服务注册、查询和健康检查 | |
| 治理域 | 安全 | 处理访问控制和身份验证 |
| 护栏 | 确保 AI 安全和道德运行,护栏在预定义边界内约束 LLM 行为,防止有害行为同时保持预期功能 | |
| 弹性和可观测性域 | 容错 | 通过限速、重试、断路器确保稳定性 |
| 监控与可观测性 | 收集日志、跟踪和性能指标 |
4.2.1 Agent 服务
针对 Agent 所提供的服务,Agent 本身在其中扮演了核心的组织者的角色。
[图 13] |
4.2.2 治理
对于 Agent 的治理,需要核心关注以下几个必须的元素
- 公平性
- 应用程序在服务不同用户群体时必须保持公平和平等
- 必须避免偏见或歧视(例如,基于性别、种族等)
- 可解释性
- 产生最终结果的决策过程应当可解释且透明
- 这使得可以评估准确性(例如,通过提供引用或来源)
- 健壮性
- 必须有全面的机制确保应用系统能够可靠运行
- 系统应能够处理异常情况
- 隐私和安全
- 数据使用流程必须符合隐私保护法规
- 确保数据安全并防止盗窃和泄露
- 治理
- 组织应建立相关政策和程序
- 规范应用系统的开发和使用
- 透明度
- 关于系统能力和局限性的信息应对终端用户透明
- 使用户能够做出明智的决定
对于 Agent 访问控制,可以在以下三层安全架构体系进行考虑。在网络层,利用虚拟私有云/子网、网络安全组和网络访问控制列表,实现网络级别的访问控制;在传输层,采用授权、加密协议和委托授权机制保障数据传输安全;在内容层,通过角色验证、防护栏(Guardrail)和能力验证来确保内容安全。
这些核心的关键点里面的内容层,我们推荐对于 Agent 服务或者大语言模型的调用前和调用后,均需要使用护栏(Guardrail)进行安全检查
[图 14] |
4.2.3 服务发现和通信
常见的服务发现和通信协议如下:
| 协议 | 发布者 | 服务发现 | 通信协议 | 授权 | 应用场景 |
| MCP (Model Context Protocol) | Anthropic | 本地服务器工具/资源 | JSON-RPC 2.0; STDIO 和 HTTP; SSE 流 | OAuth 2.1 令牌传递 | IDE/聊天应用的统一插件、数据库和 API 集成 |
| A2A (Agent-to-Agent Protocol) | 单域/企业级代理注册表 | JSON-RPC 2.0 / gRPC / HTTP+REST; SSE 流和回调 | Bearer/API 密钥 | 跨供应商/跨平台代理编排与协作 | |
| ANP (Agent Network Protocol) | Agent Network Protocol 社区 | 全球发现(跨组织、多域) | WebSocket (计划 HTTP 支持); 自定义消息框架 | did:wba 身份签名和握手; 端到端加密(E2EE) | 跨平台身份、加密和发现; 构建开放代理网络 |
由于这些协议往往比较新,随着技术的发展,更新迭代也非常快,所以建议是将 Agent 之间通信的协议作为插件方式引入到系统中,自定义统一的接口和适配层,后续有新协议的时候可以随时替换。目前这些协议对于 Agent 权限控制的支持仍然不是太完善,还需要等待后续的更新。
同时在使用 Agent 服务发现的时候,需要注意:不要给单次的大语言模型请求里面,放入过多的 Agent 服务。大语言模型处理这类请求,对于超过 20 个 Agent 后,对于 Agent 的调用精准度会出现的急剧下降。所以,我们认为 Agent 也是需要进行分门别类整理,在不同的场景使用不同类别的 Agent,避免把所有 Agent 放到一起发送给大语言模型来处理调用。
4.2.4 弹性和可观测性
弹性:
对于 Agent 的弹性,我们核心要考虑如下要点:
[图 15] |
可观测性:
这里梳理了常见的可观测性的指标,从传统的系统或者微服务到 Agentic AI,在原有的基础上,还需要增加的新的指标:
| 维度 | 传统系统/微服务 | Agentic AI系统 |
| 监控粒度 | 端点、服务实例、基础设施、依赖关系 | 提示词与模型调用、工具/API 调用、检索上下文、规划器/执行器步骤(代理状态转换) |
| 指标框架 | 吞吐量(RPS/QPS)、延迟(p95/p99)、CPU/内存、错误率 | 增加成本(令牌数/$)、输出质量分数(准确性/相关性)、幻觉与有害内容率、安全/护栏命中率、工具使用成功率 |
| 偏移监控 | 罕见行为偏移;版本化发布 | 模型/数据/输入分布偏移;输出质量/行为偏移;监控分数变化和语义异常 |
| 故障类型 | 确定性:5xx 错误、超时、饱和、依赖故障 | 行为性:幻觉、不安全内容、违反策略行为、不相关回答;工具编排错误与护栏阻止 |
| 可解释性与审计 | 通过日志/追踪代码路径 | 决策溯源:提示词/参数/模型版本、检索来源、工具 I/O、中间步骤元数据、可重现的端到端追踪 |
| 反馈与优化循环 | 告警 → 修复/配置修正 | 监控驱动评估 → 提示词/策略/模型更新;人在循环审查、A/B 或金丝雀策略、持续改进 |
这里总结了一些可用的产品如下:
[图 16] |
4.3 部署
最后一部分是关于 Agentic AI 部署,基本流程和传统的系统的 CICD 基本相同,这里要特别注意的就是关于 guardrails 相关的合规检查,以及针对 Agent 增加的相应的测试指标。
[图 17] |
针对 Agent 的测试,我们对比了核心指标、测试方法、运营指标这几个点和传统系统的差异如下:
| 维度 | 传统测试 | Agentic AI测试的额外内容 |
| 核心指标 |
• 代码覆盖率 • 断言通过率 |
• 任务成功率 • 幻觉率 • 工具调用正确率 • 对抗性防御通过率和误报率 • 召回率和精确度(如果使用检索) |
| 测试方法 |
• 单元测试 • 集成测试 • 端到端测试 |
• 离线评估集 • 模拟/执行测试 • 对抗性测试/红队测试 • 混合 LLM+规则基础判断 |
| 运营指标 |
• 吞吐量 • 延迟 |
• 每任务 token 成本(LLM API 调用次数) • 回滚/自我修复成功率 • 漂移检测 |
五、总结
本文从 Agentic AI 的介绍出发,深入介绍了设计 Agentic AI 的核心概念以及和传统系统的区别。然后通过相关方法论(包括设计原则和设计流程),介绍了如何去设计一个好的 Agentic AI 系统。同时深入到 Agent 内部,通过 Agent 核心组件的介绍,为架构师的技术选型提供架构参考。最后对比了 Agentic AI 部署过程中需要核心注意的要点。
希望通过本文,帮助各位架构师在企业的 AI 建设过程中,提供重要的方法建议和参考。
参考资料:
agentic-ai-market-208190735,MarketsAndMarkets
Top strategic Technology Trends for 2025, Gartner, 2024
➡️ 下一步行动:
相关文章:
*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营,具体信息以中国区域官网为准。
















