亚马逊AWS官方博客

(上篇)基于 AWS Bedrock AgentCore 构建企业级航空客服智能体 —— 基于AIDLC方法从需求分析到生产部署的完整实践

摘要:本文以航空客服高重复咨询、策略控制复杂、服务一致性差等痛点为切入点,结合AIDLC 方法论,完整呈现基于 AWS Bedrock AgentCore 搭建可生产部署航空客服智能体的实践方案,解决 AI Agent 在企业级场景的上下文管理、策略执行、工具集成等技术难题。


一、引言

航空客服领域正面临着前所未有的挑战。以某大型航空公司为例,每天接收超过 10 万次客户咨询,其中 80% 是重复性问题——航班查询、退改签、里程兑换等。传统的 IVR 语音树和知识库检索系统虽然能处理简单咨询,但在面对复杂场景时力不从心:高额退款需要人工审批,会员特权规则复杂多变,航班异常情况(IROP)下的补偿政策需要灵活执行。更棘手的是,不同客服人员的答案可能不一致,直接影响客户体验。

随着大语言模型(LLM)和 AI Agent 技术的成熟,行业内开始尝试智能化改造。但实践中发现,简单的 Chatbot 无法满足企业级需求:缺乏记忆能力导致用户需要重复验证身份,缺少策略控制导致高风险操作无法拦截,工具集成不规范导致维护成本居高不下。本文基于 AWS Bedrock AgentCore 平台,结合 AIDLC (AI-Driven Development Life Cycle) 方法论,构建了一套可生产部署的航空客服智能体系统,在实际应用中取得了显著效果。

二、需求分析

2.1 业务痛点

在深入分析了某航空公司的客服场景后,我们将核心痛点归纳为三类:

  • 高重复性咨询:大量咨询集中在航班查询、订单状态、退改签流程等标准化问题,但仍需人工逐一处理,导致人力成本高企。
  • 策略控制复杂:退款金额超过 $1000 需要主管审批,金卡会员享有改签费豁免,IROP 政策下的全额退款自动放行——这些业务规则必须强制执行,不能依赖 Agent 的”理解”。
  • 服务一致性差:不同客服对同一问题的回答可能不同,特别是在处理航班延误补偿等复杂场景时,答案的差异直接影响客户满意度和公司声誉。

2.2 技术挑战

使用 AI Agent 实现自动化时,我们面临以下技术挑战:

  • 上下文管理:用户验证身份后,后续对话应该记住其会员等级、历史偏好(如靠窗座位),甚至跨会话保留这些信息。单纯依赖 Prompt 无法稳定实现这种长期记忆。
  • 策略执行保障:如果将”高额退款需审批”写在 System Prompt 中,Agent 可能因为用户的”特殊请求”而绕过规则。我们需要在 Agent 外部强制拦截高风险操作。
  • 工具集成规范化:客服 Agent 需要调用 16 个业务工具(verify_identity、get_flight_status、process_refund…),如果每个工具都用不同方式集成,后期维护将成为噩梦。
  • 快速迭代需求:航空业务政策变化频繁(如促销活动、补偿标准调整),系统必须支持快速更新而不影响现有功能。

三、整体方案设计

3.1 系统架构设计

基于 AWS Bedrock AgentCore 平台,我们设计了一个四层无服务器架构。整体设计思路是关注点分离:用户交互、智能推理、策略控制、业务工具各司其职,通过标准化接口协作。这种架构既保证了系统的可扩展性,又降低了维护复杂度。

系统架构图

[图1:系统整体架构]

系统采用分层架构设计。用户通过 Cognito 认证后,请求经过 AgentCore Identity 验证和提取 actor_id,然后进入 AgentCore Runtime 执行 Agent 推理。Runtime 与Identity(身份验证)、 Memory(对话历史)、Gateway(网关)、Policy(策略控制)紧密配合工作。底层的 AgentCore Observability 收集所有组件的运行指标和调用链路,推送到 CloudWatch 进行监控和告警。

Agent 主体设计

Agent 是整个系统的核心,采用 Strands Framework 构建,基于 Claude 模型。我们将 Agent 设计为”专家客服”角色,通过精心设计的 System Prompt 定义其工作流程:先验证身份 → 理解需求 → 选择工具 → 执行操作 → 返回结果。Agent 不直接执行策略判断(如”是否需要审批”),而是依赖 AgentCore Policy 强制拦截,确保完全按照业务规则执行。

我们选择将策略控制放在 AgentCore Policy 而非 System Prompt 中。原因是 LLM 可能因为用户的”特殊请求”而”灵活处理”规则,但航空业务处理(如退款审批)不能有例外。通过AgentCore Policy 外部拦截,我们实现了策略的强制执行和完整审计追溯。

MCP Tools(业务工具集)

Agent 需要调用 16 个业务工具来完成各类客服任务。所有工具遵循 MCP 协议实现,包括身份验证、航班查询、订单处理、改签退款等核心功能。MCP 协议提供标准化的工具描述格式(函数签名、参数说明、返回值类型),让 Agent 能够准确理解工具用途并正确调用。

工具部署在独立的 ECS Fargate 服务中,通过 MCP Server 统一对外提供服务。这种部署模式支持工具的独立更新和热插拔,无需重启 Agent。通过 AgentCore Gateway,工具调用会经过策略检查和审计日志记录,确保操作的安全性。

AgentCore 组件介绍

1. Memory(对话历史管理)

AgentCore Memory 采用 STM/LTM 双层架构:短期记忆(STM)存储当前会话内容,长期记忆(LTM)通过语义提取保留用户偏好(如”喜欢靠窗座位”),并支持跨会话检索。Memory 按 actor_id + session_id 隔离,确保多租户场景下的数据安全。

在本Demo中,采用Memory A+B 双Memory架构设计。其中,Memory A 负责存储对话上下文和用户偏好,Memory B存储用户满意处理方案。本文主要围绕Memory A展开,Memory A+B 双Memory架构设计会在下一篇博客中展开。

2. Gateway(网关)

AgentCore Gateway 集成了 MCP (Model Context Protocol) 协议支持,实现对 Agent 工具调用的拦截和策略检查。我们开发的 16 个业务工具遵循 MCP 规范,通过 MCP Server 对外提供服务。当 Agent 调用工具时,请求首先经过 AgentCore Gateway,Gateway 根据策略配置进行检查(ALLOW/BLOCK),然后再转发给 MCP Tools Server 执行。这种架构确保所有工具调用都经过策略审计。

3. Runtime(执行环境)

AgentCore Runtime 是全托管的 Agent 执行环境,为开发者提供生产就绪的托管基础设施。Runtime 的核心是 BedrockAgentCoreApp,它将 Python 函数封装为标准化的 HTTP 服务(/invocations、/ping、/ws 三个端点),并内置会话管理能力——通过请求头中的 session_id 实现跨调用的会话持久化,默认 15 分钟空闲超时。结合 AgentCore Memory,开发者可以通过 Hook 机制实现请求前自动加载历史上下文、响应后自动保存对话记录的完整会话生命周期管理。Runtime 还提供会话级隔离、SSE/WebSocket 双模式流式输出、异步任务管理、健康检查等企业级特性,开发者无需手动管理容器、负载均衡等基础设施。

4. Identity(身份认证)

AgentCore Identity 集成 AWS Cognito,提供用户身份认证和多租户隔离能力。每个请求携带 JWT Token,Identity 组件验证 Token 有效性并提取 actor_id(用户唯一标识)。actor_id 贯穿整个调用链路:Memory 按 actor_id 隔离数据,Gateway 按 actor_id 应用策略,确保多租户场景下的数据安全和策略隔离。

5. Observability(可观测性)

AgentCore Observability 基于 OpenTelemetry 标准,自动收集 Agent 运行的全链路指标和日志。包括:请求延迟(P50/P90/P99)、工具调用成功率、Gateway 拦截次数、Memory 读写延迟等关键指标。所有指标推送到 CloudWatch,支持告警配置。Observability 还提供分布式追踪能力,记录每个请求的完整调用链路(Agent → Gateway → MCP Tools),方便问题排查和性能优化。

6. Policy(策略引擎)

Gateway 是独立的策略执行引擎,在 Agent 调用工具前进行拦截检查。所有策略以 JSON 配置文件定义(如”退款 > $1000 需审批”、”金卡会员改签费豁免”),支持热更新而无需修改 Agent 代码。Gateway 基于 Cedar 语言实现细粒度访问控制,每次拦截都生成审计日志,满足合规要求。

业务工具清单

[图2]

3.2 核心工作流程时序图

我们设计了5个典型场景的完整时序图,展示系统如何处理不同类型的用户请求:

场景1:航班查询场景

[图3]

流程说明:场景1 展示了查询类工具的标准调用流程。用户查询航班状态时,Agent 从 Memory A 加载对话历史后,调用 get_flight_status 工具。该工具请求经过Policy Engine 进行策略检查。Policy Engine 匹配到 query_allow 策略(查询类工具默认放行),返回 ALLOW 决策。Gateway 随后通过 MCP 协议将请求转发到 MCP Tools Server 执行,获取航班状态后原路返回给 Agent。整个流程体现了”所有工具调用必经 Gateway+Policy Engine”的架构原则,即使是低风险的查询操作也不例外。

场景2:改签场景(金卡会员)

[图4]

流程说明:场景2展示了策略敏感型工具与 Policy Engine 的配合。流程包含两个工具调用:首先 Agent 调用 verify_identity 验证用户身份并获取会员等级(GOLD),该调用经过 Gateway+Policy Engine 后正常放行。关键在第二个工具调用 change_flight:当 Agent 请求改签时,Gateway 将请求转发给 Policy Engine,Policy Engine 检测到用户为金卡会员,匹配到 gold_member_fee_waiver 策略(金卡会员改签费豁免),返回 MODIFY_PARAMS 决策并将 fee 参数修改为 0。Gateway 随后将修改后的请求(fee=0)转发给 MCP Tools Server 执行。这种设计实现了策略与业务逻辑的完全解耦:工具本身不做会员权益判断,所有策略由 Policy Engine 强制执行。

场景3:IROP 退款场景

[图5]

流程说明:场景3展示了基于业务规则的自动化决策流程。用户申请航班取消退款时,Agent 依次调用三个工具:verify_identity(验证身份)、get_flight_status(查询航班状态,返回 is_irop:true)、process_refund(处理退款)。前两个工具调用正常经过 Gateway+Policy Engine 放行。关键在第三个退款调用:当 Agent 请求退款并传入 reason=IROP 时,Policy Engine 匹配到 irop_auto_approval 策略(航班取消或严重延误属于 IROP,自动全额退款),直接返回 ALLOW 决策。整个流程无需人工介入即可完成退款审批,体现了通过策略引擎实现业务规则自动化执行的能力。与场景4的高额退款拦截形成对比。

场景4:高额退款审批场景

[图6]

流程说明:场景4展示了 Policy Engine 的强制拦截能力,确保高风险操作必须经过人工审批。当用户申请 $1500 退款时,Agent 调用 process_refund 工具,请求经过 Gateway 转发给 Policy Engine 进行策略检查。Policy Engine 匹配到 high_amount_refund_block 策略(退款金额超过 $1000 需人工审批),返回 BLOCK 决策并拒绝该工具调用。Gateway 将拦截结果返回给 Agent,Agent 随即调用 submit_manual_approval 工具提交人工审批请求(该工具本身不受策略限制),并向用户返回审批单号。整个流程确保了 Agent 无法绕过策略直接执行高风险操作,所有高额退款必须走人工审批流程,满足金融级业务的合规要求。

场景5:多轮对话订票场景

[图7]

流程说明:场景5展示了 Memory A 的自动化多轮对话管理能力。整个订票流程跨越三轮对话:第1轮用户表达订票意图,Agent 通过 Memory A 发现是空会话,要求提供更多信息;第2轮用户提供出发地、目的地和日期,Agent 从 Memory A 加载到”订票”意图,调用 search_flights 工具(经过 Gateway+Policy Engine 放行)返回航班列表;第3轮用户选择”第一个”航班,Agent 从 Memory A 加载到上一轮的航班列表(理解”第一个”指 UA1234),依次调用 verify_identity(验证身份)和 book_ticket(预订机票)工具完成订票。关键在于 Agent 还从 Memory A 的 LTM(长期记忆)中检索到用户偏好(靠窗+早班+素食),自动应用到订票请求中。整个流程展示了 Memory A 的 STM(对话历史)和 LTM(用户偏好)两层存储的协同工作,以及 AgentCore Runtime 的 SessionManager 自动管理会话状态的能力。

5个场景总结

  • 场景1:查询类工具,Gateway+Policy Engine 检查后 ALLOW,展示所有工具调用统一流程
  • 场景2:策略敏感工具,Policy Engine 修改参数(金卡会员改签费豁免)
  • 场景3:IROP 退款,Policy Engine 根据业务规则自动 ALLOW,无需人工审批
  • 场景4:高额退款,Policy Engine 拦截 BLOCK,强制人工审批
  • 场景5:多轮对话,所有工具调用都经过 Gateway+Policy Engine,Memory 自动管理上下文

3.3 AWS 部署架构

系统采用无服务器架构部署在AWS AgentCore服务上,充分利用托管服务降低运维成本:

[图8]

架构特点

  • 全托管服务:AgentCore 提供 Identity(身份认证)、Runtime(执行环境)、Observability(监控)的全托管能力
  • 自动化会话管理:AgentCore Runtime 自动处理会话隔离、状态持久化、资源调度等复杂任务
  • 弹性伸缩:通过 Auto Scaling 自动扩缩容,在业务高峰期(如节假日)自动增加计算资源,平时则缩减到最小规模
  • 全链路监控:Observability 通过 OpenTelemetry 自动收集指标,推送到 CloudWatch 进行监控和告警

四、技术选型与应用

4.1 AIDLC 方法论:从需求到上线的全流程指导

AIDLC (AI-Driven Development Life Cycle) 是 AWS 推出的智能化软件开发方法论,专为 AI 时代的软件工程设计。它提供了三个阶段的完整流程框架:Inception(规划) → Construction(构建) → Operations(运维),以及五大核心原则确保项目质量。

五大核心原则(5 Tenets)

1. Human in the Loop:关键决策需人工确认(如高额退款审批)

2. No Duplication:单一真相来源(避免数据冗余)

3. Reproducible:流程可复现(确保一致性)

4. Agnostic:技术栈无关(避免供应商锁定)

5. Methodology First:方法论优先于工具(先设计流程再选技术)

在本项目中的应用中,我们严格按照 AIDLC 三阶段完成项目开发:

Inception 阶段(需求 → 设计)

  • 业务需求分析:识别三大痛点(高重复性、策略复杂、一致性差)
  • 技术需求分解:明确四大挑战(上下文管理、策略保障、工具规范、快速迭代)
  • 架构设计:采用四层架构(交互层、Runtime、Gateway、工具层)
  • Decision Log:记录关键决策(为什么 Policy 放 Gateway?为什么双 Memory?)

Construction 阶段(开发 → 测试)

  • Agent 开发:使用 Strands 框架搭建主体 Agent,编写 System Prompt
  • 工具开发:实现 16 个 MCP 工具(verify_identity、get_flight_status、change_flight…)
  • Gateway 配置:定义 Policy 规则(JSON 格式,支持热更新)
  • Memory 集成:接入 AgentCore Memory,实现 STM/LTM 管理
  • 单元测试:验证每个工具和 Policy 规则的正确性

Operations 阶段(部署 → 监控)

  • 场景测试:执行 A-E 五个测试场景,验证端到端流程
  • 监控配置:CloudWatch 指标(延迟、成功率、Policy 拦截次数)
  • 上线运行:2 周内完成从 0 到生产部署

AIDLC 带来的价值:系统化方法确保无遗漏(Methodology First),Decision Log 方便审计(Reproducible),Gateway 独立部署支持快速更新(Agnostic)。

4.2 Strands Agent:搭建主体 Agent 的框架选择

Strands Agent 框架介绍

Strands Agent 提供简洁的 API 和强大的工具调用能力。其核心特性包括:

  • 强大推理能力:Claude 4.6 Sonnet 在工具调用场景准确率 >95%
  • 灵活工具集成:支持任意 Python 函数作为工具
  • 流式输出:实时返回推理过程,提升用户体验

在本项目中的应用包括

1. 主体 Agent 搭建

我们使用 Strands 构建航空客服 Agent,定义了”专家客服”角色:先验证身份 → 理解需求 → 选择工具 → 执行操作 → 返回结果。System Prompt 中明确列出 16 个可用工具及其用途,确保 Agent 能够准确选择和调用工具。

2. 工具调用流程

Strands 的工具调用机制支持多步推理:Agent 分析用户意图后,可能先调用 verify_identity 验证身份,再根据会员等级调用 change_flight 处理改签,最后生成自然语言响应。整个过程对用户透明,用户只看到最终结果。

3. 与 AgentCore 集成

Strands Agent 部署在 AgentCore Runtime 中,自动享受 Memory、Gateway、Observability 等托管能力。AgentCore 的 SessionManager 自动管理会话状态,无需手动处理上下文传递。

4.3 AgentCore:企业级 Agent 基础设施

AWS Bedrock AgentCore 是生产级 AI Agent 基础设施服务,提供 8 大核心组件:Runtime、Memory、Gateway(Policy)、Identity、Built-in Tools、Observability、Evaluations、MCP Server。其核心优势是框架和模型无关(Agnostic),支持 Strands、LangGraph、CrewAI 等任意框架,也支持 Claude、GPT、Llama 等任意模型。

本项目使用的组件:在本航空客服系统中,我们使用了其中 5 个核心组件:Runtime(执行环境)、Policy(策略引擎)、Memory(对话历史)、Gateway(网关)、Identity(身份认证)、Observability(可观测性)。Built-in Tools 替换为自定义的 16 个 MCP Tools,Evaluations 用于后期效果评估。

在本项目中的应用

1. Gateway 集成 MCP 工具调用

AgentCore Gateway 集成了 MCP (Model Context Protocol) 协议支持,实现对 Agent 工具调用的拦截和策略检查。我们开发的 16 个业务工具遵循 MCP 规范,通过 MCP Server 对外提供服务。当 Agent 调用工具时,请求首先经过 AgentCore Gateway,Gateway 根据策略配置进行检查(ALLOW/BLOCK),然后再转发给 MCP Tools Server 执行。这种架构确保所有工具调用都经过策略审计,同时工具可以独立部署、热更新。

2. Memory 能力:对话历史管理与多轮对话

AgentCore Memory 负责对话历史存储和多轮对话状态管理,采用 STM/LTM 双层架构和 SessionManager 自动化机制,提供开箱即用的记忆能力。

双层记忆架构

  • STM (Short-Term Memory):存储当前会话内容(用户消息、Agent 响应、工具调用记录),会话结束后保留 90 天
  • LTM (Long-Term Memory):通过语义提取保留用户偏好和关键信息(如”喜欢靠窗座位”、会员等级),支持跨会话检索

自动化多轮对话管理

AgentCore Runtime 的 SessionManager 自动处理多轮对话流程:

1. 请求前:根据 session_id + actor_id 从 Memory 加载历史上下文

2. 调用中:Agent 基于历史上下文进行推理和工具调用

3. 响应后:SessionManager 自动将本轮对话写入 STM

4. 后台:AgentCore 异步提取语义摘要写入 LTM

这种机制让开发者无需手动管理会话状态,极大降低了开发复杂度。在本项目中,Memory A 负责对话历史和用户偏好存储,按 actor_id + session_id 隔离,确保多租户数据安全。

3. Policy 策略控制

Policy 是独立的策略引擎,在 Agent 调用工具前进行拦截检查。所有策略以 JSON 配置文件定义(如”退款 > $1000 需审批”、”金卡会员改签费豁免”),支持热更新而无需修改 Agent 代码。Gateway 基于 Cedar 语言实现细粒度访问控制,每次拦截都生成审计日志。我们将策略控制放在 Gateway 而非 System Prompt 中,确保策略 100% 执行,不受 LLM “灵活处理”的影响。

4. Runtime 全托管执行环境

AgentCore Runtime 为 Agent 提供无服务器执行环境,核心特性是 SessionManager 自动化会话管理。在本项目中,Runtime 自动处理每个请求的完整生命周期:解析 session_id + actor_id → 从 Memory 加载上下文 → 执行 Agent 推理 → 保存对话历史。Runtime 还提供流式输出能力,让用户实时看到 Agent 的推理过程,提升交互体验。开发者只需实现 @app.entrypoint 入口函数,无需管理容器、负载均衡、超时控制等基础设施细节。

5. Identity 多租户身份认证

AgentCore Identity 集成 Cognito 实现用户身份认证。在本项目中,每个请求携带 JWT Token(由 Cognito 签发),Identity 组件验证 Token 并提取 actor_idactor_id 作为用户唯一标识,贯穿整个调用链路:Memory 按 actor_id 隔离数据(确保用户A看不到用户B的对话),Gateway 按 actor_id 应用策略(不同用户可能有不同权限),实现真正的多租户数据隔离。

6. Observability 全链路监控

AgentCore Observability 基于 OpenTelemetry 自动收集运行指标。在本项目中,我们在 CloudWatch 中配置了以下监控指标:

  • 性能指标:Agent 响应延迟(P50/P90/P99)、工具调用延迟
  • 业务指标:Gateway 拦截次数、拦截原因分布、人工审批比例
  • 可靠性指标:工具调用成功率、Memory 读写失败率、异常堆栈
  • 分布式追踪:记录每个请求的完整调用链路(Agent → Gateway → MCP Tools),支持性能瓶颈分析

五、核心技术实现

5.1 Agent 主体设计与实现

Agent 是整个系统的大脑,负责理解用户意图、选择合适工具、协调多个工具调用、生成自然语言响应。我们采用 Strands Agents SDK 构建 Agent,通过精心设计的 System Prompt 定义其行为模式。

关键设计原则是:Agent 专注于推理和对话生成,策略控制交给 Gateway Policy。这种职责分离确保了 Agent 的灵活性,同时通过 Gateway 保证策略的强制执行。

System Prompt 包含五个核心部分:

  • 角色定义:明确 Agent 身份(”Senior Customer Service Representative”)、专业领域、权限范围
  • 沟通风格:专业但温暖、富有同理心、高效解决问题
  • 强制行为:必须先验证身份、必须检查航班状态、必须提供交易参考号
  • 工作流程:针对不同场景(IROP退款、常规退款、改签、审批查询、偏好预订)的标准处理流程
  • 工具使用指南:16 个工具的分类说明和调用规范
  • 通过明确的工作流程指导,Agent 能够稳定地处理各类咨询场景。值得注意的是,System Prompt 中不包含任何策略规则(如”金额超过1000需审批”),这些规则完全由 Gateway Policy 控制,实现了策略与 Agent 逻辑的彻底解耦。

部分核心代码

# 初始化 Bedrock 模型
model = BedrockModel(
    model_id=os.getenv("MODEL_ID", "us.anthropic.claude-3-5-sonnet-20241022-v2:0"),
    temperature=0.7,
    max_tokens=2048
)

# 创建 AgentCore App
app = BedrockAgentCoreApp()

def create_agent_with_memory(session_id: str, actor_id: str, previous_session_history: str = ""):
    """创建带 Memory 的 Agent"""

    # 创建 Session Manager(自动管理 Memory 读写)
    session_manager = None
    if MEMORY_ID:
        retrieval_config = {
            f"/summaries/{actor_id}/{session_id}": RetrievalConfig(top_k=5, relevance_score=0.5),
            f"/preferences/{actor_id}": RetrievalConfig(top_k=5, relevance_score=0.7),
            f"/facts/{actor_id}": RetrievalConfig(top_k=10, relevance_score=0.3)
        }

        config = AgentCoreMemoryConfig(
            memory_id=MEMORY_ID,
            session_id=session_id,
            actor_id=actor_id,
            retrieval_config=retrieval_config
        )
        session_manager = AgentCoreMemorySessionManager(
            agentcore_memory_config=config,
            region_name=os.getenv("AWS_REGION", "us-east-1")
        )

    # 获取 Gateway MCP client(通过 OAuth2 认证)
    tools = []
    mcp_client = get_gateway_mcp_client()
    if mcp_client:
        tools = [mcp_client]

    # 构建增强的 system prompt(注入历史对话上下文)
    enhanced_system_prompt = AIRLINE_AGENT_SYSTEM_PROMPT
    if previous_session_history:
        enhanced_system_prompt = f"{AIRLINE_AGENT_SYSTEM_PROMPT}\n\n{previous_session_history}"

    # 创建 Agent
    agent = Agent(
        model=model,
        system_prompt=enhanced_system_prompt,
        tools=tools,
        session_manager=session_manager,
        name="AirlineCustomerServiceAgent",
        description="Professional airline customer service agent"
    )

    return agent


@app.entrypoint
def invoke(payload: dict, context=None):
    """AgentCore Runtime 调用入口"""
    prompt = payload.get("prompt", "")

    # 获取 session_id(优先从 context 获取,支持多种来源)
    session_id = (
        getattr(context, 'session_id', None) or
        BedrockAgentCoreContext.get_session_id() or
        payload.get("session_id") or
        f"session_{datetime.now().strftime('%Y%m%d%H%M%S%f')}"
    )

    # 从 JWT token 中提取 actor_id(用户唯一标识)
    actor_id = extract_actor_id_from_context(context)

    # 获取前一个 session 的对话历史(跨会话连续性)
    previous_session_history = ""
    if LOAD_PREVIOUS_SESSION and actor_id != "default_user":
        previous_session_history = get_previous_session_history(actor_id, session_id)

    # 创建 Agent 并处理请求
    agent = create_agent_with_memory(
        session_id=session_id, 
        actor_id=actor_id,
        previous_session_history=previous_session_history
    )

    result = agent(prompt)

    return {"response": str(result.output), "session_id": session_id}

System Prompt 设计要点

src/agent/system_prompt.py
AIRLINE_AGENT_SYSTEM_PROMPT = """You are a professional customer service agent for a major airline.

IDENTITY:
- Role: Senior Customer Service Representative
- Expertise: Flight reservations, refunds, changes, and loyalty programs
- Authority: Can process refunds, changes, and fee waivers
- Memory: You have access to customer history and preferences through AgentCore Memory

MANDATORY BEHAVIORS:
1. ALWAYS verify customer identity before accessing bookings
   - Ask for: PNR (booking reference) and Last Name
   - Use verify_customer tool first

2. ALWAYS check real-time flight status for refund requests
   - Use get_flight_status tool to verify cancellations/delays

3. ALWAYS provide reference numbers for transactions
   - Transaction IDs for refunds
   - Ticket IDs for approvals
   - Confirmation numbers for changes

WORKFLOW FOR COMMON SCENARIOS:

Scenario A: Flight Cancellation Refund (IROP)
1. Greet and understand the request
2. Verify customer identity (PNR + Last Name)
3. Check flight status using get_flight_status tool
4. If flight is CANCELLED, use full_refund tool
5. Confirm transaction and timeline

Scenario B: Regular Refund Request
1. Verify customer identity
2. Get reservation details
3. Calculate refund amount
4. Use process_refund tool
5. Handle the tool response accordingly (Gateway may block high-value refunds)

Scenario C: Flight Change Request
1. Verify customer identity
2. Check loyalty tier using get_loyalty_tier tool
3. Search available flights
4. Calculate change costs
5. Use waive_change_fee tool if applicable (Gateway checks eligibility)
6. Execute booking change

AVAILABLE TOOLS (16 total):

Identity & Loyalty (2):
1. verify_customer - Verify customer identity with PNR and last name
2. get_loyalty_tier - Get customer loyalty tier and points

Flight Query (2):
3. get_flight_status - Check real-time flight status
4. search_flights - Search available flights by route and date

Refund (3):
5. calculate_refund - Calculate refund amount for a reservation
6. process_refund - Execute regular refund
7. full_refund - Execute IROP full refund for cancelled/delayed flights

Reservation & Change (5):
8. get_reservation_details - Get full reservation information
9. calculate_change_cost - Calculate change fees and fare difference
10. waive_change_fee - Waive change fee for eligible loyalty members
11. update_booking - Execute flight change
12. process_change_payment - Process payment for change fees

Approval (3):
13. submit_manual_approval - Submit refund for manual approval
14. check_approval_status - Check status of approval request
15. approve_ticket - Approve a pending ticket (demo only)

Booking (1):
16. book_flight - Book a new flight with seat and meal preferences

IMPORTANT RULES:
- Do NOT make up information or reference numbers
- Do parse JSON responses from tools carefully
- When a tool returns policy-related status, explain it to the customer appropriately
"""

5.2  工具举例:改签流程(多工具协作)

改签是一个典型的多工具协作场景,展示了工具与 Gateway Policy 的配合。完整的改签流程涉及 5 个工具的协调调用:

  • verify_customer – 验证客户身份
  • get_loyalty_tier – 获取会员等级(Gateway 据此判断是否豁免费用)
  • calculate_change_cost – 计算改签费用(基础费 + 票价差)
  • waive_change_fee – 豁免改签费(仅 Gold/Platinum 会员可用,Gateway 控制)
  • update_booking – 执行改签操作

工具本身不做权益判断(职责单一),会员等级检查交给Policy 完成。waive_change_fee 工具只负责执行豁免操作, Policy 决定该工具是否允许被调用。这种设计实现了策略与业务逻辑的解耦,策略更新无需修改工具代码。

核心代码

# mcp-tools-server/mcp_server.py

@mcp.tool()
def calculate_change_cost(old_flight: str, new_flight: str) -> str:
    """计算改签费用"""
    old_flight_data = FLIGHTS.get(old_flight.upper())
    new_flight_data = FLIGHTS.get(new_flight.upper())

    if not old_flight_data or not new_flight_data:
        return json.dumps({"error": "Flight not found"})

    base_change_fee = 200.00  # 基础改签费
    old_fare = old_flight_data.get("fare", 180.00)
    new_fare = new_flight_data.get("fare", 180.00)
    fare_difference = max(0, new_fare - old_fare)  # 票价差(只补不退)

    return json.dumps({
        "base_change_fee": base_change_fee,
        "fare_difference": fare_difference,
        "total_without_waiver": base_change_fee + fare_difference
    })


@mcp.tool()
def waive_change_fee(pnr: str, loyalty_tier: str) -> str:
    """
    豁免改签费(仅限 Gold/Platinum 会员)

    注意:此工具的调用受 Gateway Policy 控制
    - Gateway 会验证 loyalty_tier 是否为 gold 或 platinum
    - 如果会员等级不符,Gateway 会拦截调用
    """
    reservation = RESERVATIONS.get(pnr.upper())

    if not reservation:
        return json.dumps({"error": "Reservation not found"})

    return json.dumps({
        "fee_waived": True,
        "waived_amount": 200.00,
        "reason": f"{loyalty_tier.capitalize()} member privilege",
        "pnr": pnr.upper()
    })


@mcp.tool()
def update_booking(pnr: str, new_flight: str) -> str:
    """执行改签操作"""
    reservation = RESERVATIONS.get(pnr.upper())

    if not reservation:
        return json.dumps({"error": "Reservation not found"})

    new_confirmation = f"{pnr.upper()}-{random.randint(10, 99)}"

    return json.dumps({
        "success": True,
        "new_confirmation": new_confirmation,
        "new_flight": new_flight.upper(),
        "old_flight": reservation["flight_number"]
    })

5.3  Policy 引擎实现

Policy 是 Gateway 的独立策略执行引擎,在 Agent 调用工具前进行拦截检查。所有策略以声明式配置定义,支持两种操作:

  • PERMIT:放行(如 IROP 全额退款)
  • BLOCK:拦截并要求人工审批(如高额退款)

核心价值在于策略与代码解耦:策略更新只需修改配置,无需重新部署 Agent 或工具服务器。AgentCore Policy Engine 使用 Cedar 语言定义策略。Cedar 是 AWS 开发的授权策略语言,提供细粒度访问控制能力。

Policy 配置示例

示例1:高额退款拦截策略:

// 低于$1000的退款:允许
permit(
  principal,
  action == Action::"process_refund",
  resource
) when {
  resource.amount <= 1000
};

// 超过$1000的退款:拦截,需要人工审批
forbid(
  principal,
  action == Action::"process_refund",
  resource
) when {
  resource.amount > 1000
};

示例2:金卡会员改签费豁免策略:

// 金卡会员改签:豁免改签费
permit(
  principal,
  action == Action::"change_flight",
  resource
) when {
  principal.member_tier == "GOLD"
};

// 普通会员改签:需要支付改签费
permit(
  principal,
  action == Action::"change_flight",
  resource
) when {
  principal.member_tier == "REGULAR" &&
  resource.fee == 50.0
};

示例3:IROP 自动退款策略:

// IROP场景(航班取消或严重延误):自动全额退款
permit(
  principal,
  action == Action::"process_refund",
  resource
) when {
  resource.reason == "IROP" &&
  (resource.flight_status == "CANCELLED" ||
   resource.delay_minutes > 240)
};

三条策略的业务场景

[图9]

5.5 AgentCore Memory 集成

AgentCore Memory 负责对话历史和用户偏好的存储与检索。Memory 采用 STM/LTM 双层架构:

  • STM(短期记忆):存储当前会话的对话内容
  • LTM(长期记忆):通过语义提取保留用户偏好(如”喜欢靠窗座位”、”偏好上午航班”)

关键特性是自动化管理:AgentCore 的 SessionManager 自动加载和保存 Memory,开发者无需手动管理。Memory 按 actor_id + session_id 隔离,确保多租户场景下的数据安全。

LTM 的语义提取功能支持跨会话检索:用户在第一次会话说”我喜欢靠窗座位”,几天后的新会话中 Agent 能自动记住这个偏好并主动应用。

Memory Namespace 设计

# 三个 Namespace 分别存储不同类型的记忆
retrieval_config = {
    # 会话摘要:当前会话的对话总结
    f"/summaries/{actor_id}/{session_id}": RetrievalConfig(top_k=5, relevance_score=0.5),

    # 用户偏好:跨会话的长期偏好(如座位、餐食、时间偏好)
    f"/preferences/{actor_id}": RetrievalConfig(top_k=5, relevance_score=0.7),

    # 用户事实:客观信息(如常用航线、会员等级)
    f"/facts/{actor_id}": RetrievalConfig(top_k=10, relevance_score=0.3)
}

跨会话历史加载

# agent_with_gateway.py

def get_previous_session_history(actor_id: str, current_session_id: str) -> str:
    """
    获取用户前几个 session 的对话历史,注入到 System Prompt
    实现跨会话的对话连续性
    """
    client = boto3.client('bedrock-agentcore', region_name=os.getenv("AWS_REGION"))

    # 获取用户的历史 session 列表
    sessions_response = client.list_sessions(
        memoryId=MEMORY_ID,
        actorId=actor_id,
        maxResults=MAX_PREVIOUS_SESSIONS + 1
    )

    sessions = sessions_response.get('sessionSummaries', [])

    # 排除当前 session,获取前 N 个 session
    previous_sessions = [s['sessionId'] for s in sessions 
                         if s['sessionId'] != current_session_id][:MAX_PREVIOUS_SESSIONS]

    # 加载历史对话事件
    history_lines = ["<previous_session_history>"]
    history_lines.append("The following is the conversation history from the user's previous session(s):")

    for previous_session_id in previous_sessions:
        events_response = client.list_events(
            memoryId=MEMORY_ID,
            actorId=actor_id,
            sessionId=previous_session_id,
            maxResults=MAX_PREVIOUS_EVENTS
        )

        for event in events_response.get('events', []):
            for payload_item in event.get('payload', []):
                if 'conversational' in payload_item:
                    conv = payload_item['conversational']
                    role = conv.get('role', 'unknown')
                    text = conv.get('content', {}).get('text', '')

                    if role == 'USER':
                        history_lines.append(f"User: {text}")
                    elif role == 'ASSISTANT':
                        history_lines.append(f"Agent: {text}")

    history_lines.append("Use this history to provide continuity if the user refers to previous conversations.")
    history_lines.append("</previous_session_history>")

    return "\n".join(history_lines)

System Prompt 中的 Memory 使用

# src/agent/system_prompt.py(Memory 相关部分)

"""
MEMORY CAPABILITIES:

The system has AgentCore Memory integration that provides:
- Short-term Memory (STM): Conversation history within the same session
- Long-term Memory (LTM): Customer preferences and facts across sessions

**How Memory Works:**
- Memory is automatically managed by AgentCore Memory Session Manager
- Previous session history may be provided in <previous_session_history> tags
- Customer preferences may be provided in <user_context> tags
- You do NOT need to call any special tools - memory is automatic

**How to use <previous_session_history>:**
1. If you see <previous_session_history> tags, this contains the user's conversation from their last session
2. Use this to provide continuity: "I see from our last conversation that you were asking about..."
3. Reference specific details: "Last time you mentioned booking XYZ789..."
4. Proactively offer follow-up: "Would you like to continue where we left off?"
5. Example: "Welcome back! I see from our previous conversation that you had a pending refund request for $5,150. Would you like me to check the status?"

**How to use <user_context> preferences:**
1. Read the preferences at the start of the conversation
2. Proactively mention them: "I see you prefer morning flights around 10 AM and window seats"
3. Apply them when searching/recommending: "Based on your preferences, I recommend UA100 at 08:00"
4. Highlight matching options: "UA100 has window seats available (2A, 4A)"
"""

5.6 Gateway MCP 客户端

Agent 通过 Gateway 访问 MCP 工具服务器,Gateway 负责 OAuth2 认证和 Policy 执行。客户端实现了 Token 缓存机制,避免频繁请求 Cognito。

# src/gateway/client.py

from mcp.client.streamable_http import streamablehttp_client
from strands.tools.mcp import MCPClient

# Gateway 配置(全部从环境变量读取)
GATEWAY_MCP_URL = os.environ.get("GATEWAY_MCP_URL", "")
GATEWAY_CLIENT_ID = os.environ.get("GATEWAY_CLIENT_ID", "")
GATEWAY_CLIENT_SECRET = os.environ.get("GATEWAY_CLIENT_SECRET", "")
GATEWAY_TOKEN_ENDPOINT = os.environ.get("GATEWAY_TOKEN_ENDPOINT", "")

# Token 缓存
_token_cache = {"token": None, "expires_at": None}


def get_oauth_token() -> str:
    """获取 OAuth2 访问令牌(带缓存)"""

    # 检查缓存的 token 是否有效
    if (_token_cache["token"] and 
        _token_cache["expires_at"] and 
        datetime.now() < _token_cache["expires_at"]):
        return _token_cache["token"]

    # 请求新 token
    response = httpx.post(
        GATEWAY_TOKEN_ENDPOINT,
        data={
            "grant_type": "client_credentials",
            "client_id": GATEWAY_CLIENT_ID,
            "client_secret": GATEWAY_CLIENT_SECRET,
            "scope": GATEWAY_SCOPE
        },
        headers={"Content-Type": "application/x-www-form-urlencoded"},
        timeout=30.0
    )

    data = response.json()
    token = data["access_token"]

    # 缓存 token,提前 5 分钟过期
    expires_in = data.get("expires_in", 3600) - 300
    _token_cache["token"] = token
    _token_cache["expires_at"] = datetime.now() + timedelta(seconds=expires_in)

    return token


def get_gateway_mcp_client() -> MCPClient:
    """获取配置好的 Gateway MCP 客户端"""
    access_token = get_oauth_token()

    return MCPClient(
        lambda: streamablehttp_client(
            GATEWAY_MCP_URL,
            headers={"Authorization": f"Bearer {access_token}"}
        )
    )

六、测试验证

6.1 测试场景验证

我们设计了 5 个端到端测试场景(A-E),覆盖系统的核心功能路径:

[图10]

6.2 场景验证详情

场景 A:航班取消全额退款(Policy 自动放行)

验证点:IROP 策略自动执行,无需人工干预,符合 DOT 合规要求

用户: "My flight was cancelled, I need a refund. ABC123, Smith"

Agent 执行流程:
  [1] verify_customer(pnr="ABC123", last_name="Smith")
      → {"verified": true, "user_id": "U001", "passenger_name": "John Smith"}

  [2] get_flight_status(flight_number="UA1234")
      → {"status": "CANCELLED", "cancellation_reason": "WEATHER"}

  [3] full_refund(pnr="ABC123", flight_status="CANCELLED")
      → Gateway Policy 检查: status="CANCELLED" 匹配 irop_full_refund_permit
      → Policy 决策: PERMIT(DOT 合规要求)
      → {"status": "success", "amount": 450.00, "transaction_id": "TXN-20260125-0001",
         "refund_type": "IROP_FULL_REFUND", "reason": "Flight CANCELLED - DOT compliance"}

Agent 响应:
  "I'm very sorry to hear about your flight cancellation, Mr. Smith. I've processed 
   a full refund of $450.00 to your Visa-4321. Transaction ID: TXN-20260125-0001. 
   The refund will be reflected in 3-5 business days."

场景 B:高额退款人工审批(Policy 拦截)

验证点:高风险操作强制人工审批,Human in the Loop 机制生效

用户: "I need to cancel my international business class ticket and get a refund. 
       XYZ789, Johnson"

Agent 执行流程:
  [1] verify_customer(pnr="XYZ789", last_name="Johnson")
      → {"verified": true, "user_id": "U002", "passenger_name": "Jane Johnson"}

  [2] get_reservation_details(pnr="XYZ789")
      → {"amount_paid": 5500.00, "cabin": "Business", "route": "JFK-LHR"}

  [3] calculate_refund(pnr="XYZ789")
      → {"gross_amount": 5500.00, "cancellation_fee": 350.00, "net_refund": 5150.00}

  [4] process_refund(pnr="XYZ789", amount=5150)
      → Gateway Policy 检查: amount=5150 > threshold=1000
      → Policy 决策: BLOCK(high_value_refund_protection)
      → 返回 policy_violation,Agent 自动转入审批流程

  [5] submit_manual_approval(pnr="XYZ789", amount=5150, reason="Customer requested cancellation")
      → {"ticket_id": "APPR-20260125-001", "status": "PENDING", 
         "estimated_time": "2 hours", "priority": "high"}

Agent 响应:
  "Ms. Johnson, your refund request for $5,150.00 exceeds our automatic approval 
   threshold. I've submitted it for supervisor review. Your approval ticket ID is 
   APPR-20260125-001, and you should receive a decision within 2 hours. Is there 
   anything else I can help you with?"

场景 C:金卡会员改签费豁免(多工具协作)

验证点:会员权益自动识别,Policy 控制费用豁免,7 个工具协调完成改签

用户: "I need to change my flight from Monday to Tuesday. DEF456, Williams"

Agent 执行流程:
  [1] verify_customer(pnr="DEF456", last_name="Williams")
      → {"verified": true, "user_id": "U003", "passenger_name": "Sarah Williams"}

  [2] get_loyalty_tier(user_id="U003")
      → {"loyalty_tier": "gold", "tier_points": 50000}

  [3] get_reservation_details(pnr="DEF456")
      → {"flight_number": "UA5679", "route": "SFO-LAX", "departure_date": "2026-01-27"}

  [4] search_flights(origin="SFO", destination="LAX", date="2026-01-28")
      → {"flights": [
           {"flight_number": "UA5680", "time": "10:00", "fare": 180.00},
           {"flight_number": "UA5682", "time": "14:00", "fare": 180.00},
           {"flight_number": "UA5684", "time": "18:00", "fare": 210.00}
         ]}

用户: "I'll take the 10:00 AM flight."

  [5] calculate_change_cost(old_flight="UA5679", new_flight="UA5680")
      → {"base_change_fee": 200.00, "fare_difference": 0, "total_without_waiver": 200.00}

  [6] waive_change_fee(pnr="DEF456", loyalty_tier="gold")
      → Gateway Policy 检查: loyalty_tier="gold" ∈ eligible_tiers
      → Policy 决策: PERMIT(loyalty_change_fee_waiver)
      → {"fee_waived": true, "waived_amount": 200.00, "reason": "Gold member privilege"}

  [7] update_booking(pnr="DEF456", new_flight="UA5680")
      → {"success": true, "new_confirmation": "DEF456-42", "new_flight": "UA5680"}

Agent 响应:
  "Great choice, Ms. Williams! As a valued Gold member, I've waived the $200 change 
   fee for you. Your flight has been changed to UA5680 departing at 10:00 AM on 
   Tuesday. Your new confirmation number is DEF456-42."

场景 E:偏好记忆(LTM 跨会话)

[第 1 次会话]
用户: "我喜欢靠窗座位"
Agent: [写入 Memory A LTM] → 存储用户偏好

[第 2 次会话,3 天后]
用户: "帮我订张票"
Agent: [从 Memory A LTM 读取] → 检索到"喜欢靠窗"
       响应: "为您选择了靠窗座位"

AIDLC 验证: ✓ No Duplication(Memory A 是唯一数据源)

场景 D:审批状态查询(STM 会话内记忆)

验证点:Agent 无需用户重复提供 ticket_id,STM 自动保持会话上下文

[延续场景 B 的会话]

用户: "What's the status of my refund approval?"

Agent 执行流程:
  → Memory STM 检索: 当前会话中存在 ticket_id="APPR-20260125-001"

  [1] check_approval_status(ticket_id="APPR-20260125-001")
      → {"ticket_id": "APPR-20260125-001", "status": "PENDING", 
         "submitted_at": "2026-01-25T10:30:00", "estimated_time": "2 hours"}

Agent 响应:
  "Your refund approval (APPR-20260125-001) is still pending review. It was 
   submitted about 30 minutes ago, and you should hear back within the next 
   1.5 hours. I'll make sure to notify you once it's approved."

场景 E:偏好记忆预订(LTM 跨会话记忆)

验证点:LTM 跨会话保留用户偏好,Agent 主动应用偏好推荐,实现个性化服务

[Session 1 - 首次预订]
用户: "I'd like to book a business class ticket from SFO to NYC for Feb 4th. 
       I prefer morning flights around 10 AM and window seats."

Agent 执行流程:
  [1] search_flights(origin="SFO", destination="NYC", date="2026-02-04")
  [2] book_flight(user_id="U005", flight_number="UA100", cabin="Business", seat="2A")
      → {"pnr": "EMI001", "seat": "2A", "fare": 1200.00}

  → Memory LTM 自动提取并存储用户偏好:
    - /preferences/U005: "prefers morning flights around 10 AM"
    - /preferences/U005: "prefers window seats"

---

[Session 2 - 3 天后的新会话]
用户: "I need to book another flight, NYC to LA on Feb 10th"

Agent 执行流程:
  → Memory LTM 检索: /preferences/U005
  → 检索结果注入 <user_context>:
    "User preferences: morning flights around 10 AM, window seats"

  [1] search_flights(origin="NYC", destination="LAX", date="2026-02-10")
      → {"flights": [
           {"flight_number": "UA401", "time": "08:00", "fare": 320.00},
           {"flight_number": "UA403", "time": "10:15", "fare": 350.00},  ← 最匹配偏好
           {"flight_number": "UA405", "time": "14:30", "fare": 380.00},
           {"flight_number": "UA407", "time": "18:00", "fare": 290.00}
         ]}

Agent 响应:
  "Welcome back, Ms. Davis! I see you prefer morning flights around 10 AM and 
   window seats. Based on your preferences, I recommend UA403 departing at 10:15 AM 
   - it's closest to your preferred time and has window seats available (10A, 11A). 
   Would you like me to book this flight for you?"

6.3 测试数据说明

项目提供了完整的测试数据集,支持上述所有场景的验证:

[图11]

测试用户:

[图12]

七、总结与下篇预告

7.1 本文回顾

本文介绍了如何基于 AWS Bedrock AgentCore 构建企业级航空客服智能体,完整实现了从需求分析到功能验证的全流程:

  • Agent 层:基于 Strands Agents SDK 构建,通过精心设计的 System Prompt 定义 16 个工具的使用规范和 5 类场景的标准工作流程
  • Runtime 层:AgentCore Runtime 提供托管运行环境,支持容器化部署、自动扩缩容、会话管理,通过 @app.entrypoint 装饰器定义统一入口
  • Gateway 层:AgentCore Gateway 作为工具调用的统一入口,每个 MCP 工具对应一条 Policy 规则(共 16 条),实现细粒度的访问控制和参数校验,将业务规则与 Agent 逻辑彻底解耦
  • Identity 层:集成 Amazon Cognito 实现双重认证——用户认证(JWT Token)确保终端用户身份,Gateway OAuth2(Client Credentials)确保服务间调用安全;从 JWT 中提取 actor_id 实现多租户数据隔离
  • Memory 层:AgentCore Memory 提供 STM/LTM 双层架构,STM 保持会话上下文,LTM 实现跨会话偏好记忆;SessionManager 自动管理读写,按 actor_id + session_id 隔离数据
  • 工具层:16 个 MCP 工具部署在独立的 ECS 服务上,覆盖身份验证、航班查询、退款处理、改签操作、审批流程、预订服务六大类业务能力
  • Observability 层:结构化日志,关键操作全程可追踪,支持与 CloudWatch 集成实现集中监控

系统架构遵循关键设计原则:

  • Human in the Loop:高风险操作(如高额退款 >$1000)强制人工审批,Gateway Policy 自动拦截并引导进入审批流程
  • 策略与逻辑分离:16 条 Policy 规则以声明式配置定义,独立于 Agent 代码,支持热更新无需重新部署
  • 单一数据源:Memory 作为对话历史和用户偏好的唯一存储,避免数据冗余和一致性问题
  • 零信任安全:所有敏感配置通过环境变量注入,Token 缓存机制减少认证开销,JWT 解析提取用户身份

7.2 下篇预告 — 双Solutions Memory 方案

虽然本文的系统已经可以稳定运行,但在实际使用中我们发现了一个关键痛点:复杂场景的处理一致性问题。

以航班延误补偿场景为例:同样是”延误 4 小时”的投诉,Agent 每次给出的补偿方案可能不同——有时只提供改签选项,有时会额外赠送里程积分,有时还会提供餐食券。这种不一致性导致客户体验参差不齐,也给客服团队带来管理困难。

问题的根源在于:Agent 没有记住过去成功的处理案例。当前的 Memory 只存储对话历史和用户偏好,缺少”最佳实践”的积累机制。

下篇将详细介绍 Solutions Memory(成功案例库) 的设计与实现,包括:

  • 双 Memory 架构:Memory A(对话历史)+ Memory B(成功案例)
  • 案例积累机制:通过用户点赞触发案例入库
  • 智能检索策略:处理新问题时自动检索相似案例作为参考
  • 持续优化闭环:越用越智能的自我进化能力

本博客完整代码参见:https://github.com/Anya2089/Airline-booking-demo-strandsagent-agentcore

下篇博客:(下篇)Solutions Memory:让 AI Agent 从成功案例中持续学习 —— 双 Memory 架构实践

➡️ 下一步行动:

相关产品:

相关文章:

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

本篇作者

延诤

亚马逊云科技Agentic AI 资深产品专家。曾经在联想、58 同城、京东等知名企业担任产研负责人,积累了深厚的行业经验与前沿视野。自加入亚马逊云科技后,致力于生成式 AI 技术领域,专注于推动 AI 在国内及全球企业客户中的实际应用、高效落地与广泛推广。

姬军翔

亚马逊云科技资深解决方案架构师,负责AI Agent相关的产品和技术咨询,超过10年的机器学习系统构建经验。

Raymond Lai

亚马逊云科技解决方案架构师,有超过 10 年的研发及架构设计经验。目前致力于推广 AWS 的技术和各种解决方案。侧重于Agentic/大数据领域的方案。

Fortune Hui

亚马逊云科技解决方案架构师,主要负责服务大型企业客户。致力协助客户及合作伙伴建立大数据平台与生成式人工智慧应用。


AWS 架构师中心:云端创新的引领者

探索 AWS 架构师中心,获取经实战验证的最佳实践与架构指南,助您高效构建安全、可靠的云上应用