亚马逊AWS官方博客

企业级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介绍

1.Agentic AI 和AI Agent

Agentic AI 是一种具备目标感和自主性的智能框架,能够支持 AI Agents 在无需持续人工干预的情况下完成复杂任务。它强调“主动执行”,区别于传统软件的固定规则和传统 AI 的被动响应。

AI Agent 是运行在 Agentic AI 框架中的自主软件体,具备推理规划、记忆、工具调用和自主执行等核心能力,可以独立感知环境并采取行动。

两者关系可以理解为“城市与车辆”:

  • Agentic AI 提供统一的基础设施和规则(任务编排、权限与风控、可观测与评测),确保系统整体可控、可度量、可演进;
  • AI Agents 则在框架内承担具体角色(如商品上新、定价、补货、客服、风控),通过分工协作与外部系统交互,高效推动业务目标实现。

因此,Agentic AI 不仅是多个 AI Agents 的运行土壤和方法论框架,也使智能系统从“被动响应”进化到“主动执行”。

2.Agent的发展可以简单分为下面几个阶段:

Agentic AI的核心概念

Agentic AI和传统的服务区别如下:

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在零售行业内的应用

这里以零售行业的典型业务流程举例:

Agentic AI几乎可以应用到各个业务流程中,如果以基于Agentic AI的“产品推荐”举例,则可以规划如下:

图表展示了Agentic AI服务在产品推荐场景中的工作流程。左侧是用户查询示例,如”基于偏好推荐产品”、”了解品牌历史”、”寻找相似服装”等。从图中可以看到:

  • 不同的查询会被路由到不同的Agent进行处理。
  • Agent之间也可以互相交互——例如,虚拟试穿和服装搭配师可能首先调用视觉搜索来识别用户上传图片中的产品。
  • Agent使用特征存储和向量数据库,并利用模型服务来获取知识。
  • 在需要时,它们会调用外部第三方API——例如,虚拟试穿可能会检查库存数据,以便只推荐有库存的产品。

同时,但并不是所有的场景都适合使用Agentic AI。下面我们总结了Agentic AI的使用的决定因素:

从这些决定因素,可以帮助我们有效地判断是否需要使用Agentic AI。特别是对于大量的流程明确、需要解决的问题相对固定简单,那么使用传统的代码实现会更加有效。

架构设计

如果我们确定要使用Agentic AI,那么如何设计合理的系统架构呢?下面将从设计方法论,设计系统组件,系统部署三个方面来说明:

1.设计方法论

根据大量的实践经验,设计Agentic AI首先需要有好的协作模型,它就像一个公司的组织结构一样,CEO下面分了不同的部门,每个部门里面又不同的职能结构,这个组织结果决定了公司的所有业务如何开展;然后则需要定义好每个Agent的职责,就像企业的员工一样,两个员工即使在同一个部门或者领导下面,但是会有不同的分工,好的分工既能提高效率,又能减少浪费。其次是定义好的推理策略,就像定义每个员工的工作流程一样,每天的日常先做什么后做什么、有哪些工具可以使用。最后是好的控制和评估Agent的方法,就像员工的KPI监控和绩效考评一样,用于保证Agent按照既定的目标在工作。

基于这些原则,我们Agent的设计流程如下:

针对上面的原则我们分别进行详细说明

1.1 清晰的协作模型

这里以供应链中的协同管理为例,这里假设存在供应链流程业务流程里面,先预测需求 → 决定库存补货 → 安排物流配送 → 制定营销活动 →  再反馈到预测,这些活动相互依赖和制约,比如库存想一次性大批补货,但物流容量/时段有限,可能运输瓶颈;库存紧张或物流受限时,营销却想大促销,会造成履约风险。

所以针对几个核心Agent:销售预测,库存管理,物流管理,营销管理。我们设计协作模型的时候,主要分为三大类的架构类型:

  • 垂直协作架构:存在主Agent(Leader)统筹全局决策,多个子Agent分工执行,各自向主Agent汇报结果(层级结构)

适用于需分解子任务且集中控制的场景,如供应链协同中一个Agent统管采购决策,其余Agent执行库存、物流等子任务;

  • 水平协作架构:无固定主从关系,Agent之间地位平等,通过共享记忆或通信协议进行协商,共同决策。

适用于需要集思广益或不同专家Agent共同决策的场景,如营销方案制定,由数个Agent(顾客偏好、竞争情报等)讨论达成最优策略

  • 混合架构:结合上面两种方式,在一个类业务流程中,根据具体情况,部分使用垂直架构,部分使用水平架构

适用于更加复杂的场景,即需要单一统筹决策,也需要多Agent共同协商的情况

1.2 明确定义的Agent边界

Agent边界,定义了Agent能够做什么,不能够做什么,和其他Agent的职责划分是怎么样的。这里从为什么Agent需要定义明确的边界和如何定义Agent的边界进行说明

1.3 可调整和可追踪的推理策略

这里列举了一些常见的规划和推理的策略。不同的策略适用于不同的场景,对于具体哪种场景使用哪种策略,我们需要根据场景的特性进行选择,并且进行充分的测试后得出结论。

1.4 可控和可评测的能力

下面这张图展示了AI代理系统的四个关键评估维度:可观测性、策略与资源控制、故障恢复与弹性、目标驱动评估。每个维度都有相应的核心指标,如跟踪覆盖率、速率限制命中率、备用触发率和任务成功率等。图中橙色线条显示了系统在这些维度上的当前表现水平,形成了性能雷达图,用于全面评估和监控AI代理系统的运行状况和效能。

2.核心技术组件

前面我们定义的流程中的第3步:“定义内部工作流”,那么这些内部的工作流涉及哪些组件呢?这里提供一个多Agent的概览图如下:

针对图中的核心组件分层描述如下:

领域 组件 描述
服务域 Agent服务 执行业务逻辑,包括知识、推理与规划、行动、学习与适应
通信协议 实现服务间数据和消息流通
服务发现 提供服务注册、查询和健康检查
治理域 安全 处理访问控制和身份验证
护栏 确保AI安全和道德运行,护栏在预定义边界内约束LLM行为,防止有害行为同时保持预期功能
弹性和可观测性域 容错 通过限速、重试、断路器确保稳定性
监控与可观测性 收集日志、跟踪和性能指标

2.1 Agent 服务

针对Agent所提供的服务,Agent本身在其中扮演了核心的组织者的角色。

2.2 治理

对于Agent的治理,需要核心关注以下几个必须的元素

  • 公平性

应用程序在服务不同用户群体时必须保持公平和平等
必须避免偏见或歧视(例如,基于性别、种族等)

  • 可解释性

产生最终结果的决策过程应当可解释且透明
这使得可以评估准确性(例如,通过提供引用或来源)

  • 健壮性

必须有全面的机制确保应用系统能够可靠运行
系统应能够处理异常情况

  • 隐私和安全

数据使用流程必须符合隐私保护法规
确保数据安全并防止盗窃和泄露

  • 治理

组织应建立相关政策和程序
规范应用系统的开发和使用

  • 透明度

关于系统能力和局限性的信息应对终端用户透明
使用户能够做出明智的决定

对于Agent访问控制,可以在以下三层安全架构体系进行考虑。在网络层,利用虚拟私有云/子网、网络安全组和网络访问控制列表,实现网络级别的访问控制;在传输层,采用授权、加密协议和委托授权机制保障数据传输安全;在内容层,通过角色验证、防护栏(Guardrail)和能力验证来确保内容安全。

这些核心的关键点里面的内容层,我们推荐对于Agent服务或者大语言模型的调用前和调用后,均需要使用护栏(Guardrail)进行安全检查

2.3 服务发现和通信

常见的服务发现和通信协议如下:

协议 发布者 服务发现 通信协议 授权 应用场景
MCP (Model Context Protocol) Anthropic 本地服务器工具/资源 JSON-RPC 2.0; STDIO和HTTP; SSE流 OAuth 2.1 令牌传递 IDE/聊天应用的统一插件、数据库和API集成
A2A (Agent-to-Agent Protocol) Google 单域/企业级代理注册表 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放到一起发送给大语言模型来处理调用。

2.4. 弹性和可观测性

弹性:

对于Agent的弹性,我们核心要考虑如下要点:

可观测性:

这里梳理了常见的可观测性的指标,从传统的系统或者微服务到Agentic AI,在原有的基础上,还需要增加的新的指标:

维度 传统系统/微服务 Agentic AI系统
监控粒度 端点、服务实例、基础设施、依赖关系 提示词与模型调用、工具/API调用、检索上下文、规划器/执行器步骤(代理状态转换)
指标框架 吞吐量(RPS/QPS)、延迟(p95/p99)、CPU/内存、错误率 增加成本(令牌数/$)、输出质量分数(准确性/相关性)、幻觉与有害内容率、安全/护栏命中率、工具使用成功率
偏移监控 罕见行为偏移;版本化发布 模型/数据/输入分布偏移;输出质量/行为偏移;监控分数变化和语义异常
故障类型 确定性:5xx错误、超时、饱和、依赖故障 行为性:幻觉、不安全内容、违反策略行为、不相关回答;工具编排错误与护栏阻止
可解释性与审计 通过日志/追踪代码路径 决策溯源:提示词/参数/模型版本、检索来源、工具I/O、中间步骤元数据、可重现的端到端追踪
反馈与优化循环 告警 → 修复/配置修正 监控驱动评估 → 提示词/策略/模型更新;人在循环审查、A/B或金丝雀策略、持续改进

这里总结了一些可用的产品如下:

  1. 部署

最后一部分是关于Agentic AI部署,基本流程和传统的系统的CICD基本相同,这里要特别注意的就是关于guardrails相关的合规检查,以及针对Agent增加的相应的测试指标。

针对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

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营,具体信息以中国区域官网为准。

本篇作者

江炳坤

亚马逊云科技资深解决方案架构师。拥有十余年系统架构设计经验。曾任职高级架构师、企业架构师等岗位,涉及移动互联网、金融、政府等行业。在AI应用,营销系统,微服务,高并发高可靠的系统设计方面具有丰富的实战经验。目前专注于将亚马逊云科技的技术应用于实际解决方案,为客户实现技术创新和成功的技术落地。

叶骏

亚马逊云科技资深解决方案架构师。拥有超过 18 年的零售行业、制造行业以及数字营销领域的技术产品研发和解决方案架构经验。目前专注于将 AWS 云平台技术应用于实际解决方案,为客户实现技术创新和成功的技术落地。

华成

亚马逊云科技客户解决方案经理,目前在亚马逊云科技主要支持泛零售行业的客户。通过运用云相关解决方案等帮助客户在迁移到亚马逊云和云上运维期间实现自身的业务价值,帮助客户成功。