How AgentFlo built AI sales agents with Amazon Bedrock AgentCore – Part 1

TL;DR · AI 摘要
AgentFlo利用Amazon Bedrock AgentCore构建AI销售代理,有效提升电商转化率,解决客户意图识别和购物车弃用问题。
核心要点
- 购物车弃用率高达70%,代表每年数万亿美元的潜在收入损失。
- AgentFlo通过AI代理解决多语言、跨时区的客服扩展问题。
- 使用Amazon Bedrock AgentCore和Strands SDK提升代理的标准化和可扩展性。
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- AgentFlo AI销售代理构建
- 核心挑战
- 购物车弃用率70%
- 多语言客服扩展
- 架构组件
- 模型与意图识别
- 工具与知识库集成
- 实施成果
- 3000亿美元年交易额
- 10-50倍流量峰值处理
金句 / Highlights
值得收藏与分享的关键句。
购物车弃用率高达70%,代表每年数万亿美元的潜在收入损失。
AgentFlo通过AI代理解决多语言、跨时区的客服扩展问题。
使用Amazon Bedrock AgentCore和Strands SDK提升代理的标准化和可扩展性。
AgentFlo如何使用Amazon Bedrock AgentCore构建AI销售代理 – 第1部分 | AWS架构博客
AgentFlo如何使用Amazon Bedrock AgentCore构建AI销售代理 – 第1部分
在本文中,您将了解AgentFlo如何构建智能销售代理,将对话转化为完成的购买。我们将展示AgentFlo如何通过Amazon Bedrock AgentCore和Strands Agents SDK在早期部署中提升营收表现。
作为Salesflo推出的智能商业服务,AgentFlo帮助商家在WhatsApp等渠道部署全天候运行的AI销售、客服和订购代理。这些代理能够理解用户意图,连接商业系统,推荐产品,创建购物车,并将对话转化为完成的交易。根据Salesflo的数据,目前AgentFlo服务于管理着每年超过3000亿美元交易价值的电子商务商家,覆盖Shopify、WooCommerce、Magento和SAP等平台。
本文是两部分系列文章的第一部分,涵盖生产级AI代理的五大支柱。第一部分涉及速度、标准化和可扩展性。第二部分将探讨信任、可靠性和商业成果。
挑战:缺乏协助的客户意图
行业数据显示,购物车弃购率徘徊在70%左右,每年造成数万亿美元的潜在收入损失。对于在WhatsApp等消息平台运营的商家而言,这一问题更加严峻:
- 购物车弃购:客户因一个问题未得到解答而放弃购物车
- 通用产品发现:排名列表取代了针对每位客户的个性化推荐
- 错失对话机会:不同时区和语言的客服需求超出人员配置能力
- 缺乏个性化指导:大多数商家无法为每次互动提供一对一协助
- 有限的主动沟通:团队缺乏开展主动销售的带宽
- 流量高峰冲击:闪购和季节性活动可能导致流量激增至正常水平的10-50倍
基于规则的聊天机器人无法处理复杂的销售对话,人工代理难以跨地域、语言和时区扩展。商家需要能够理解客户上下文、执行复杂工作流并实现全天候自主运行的专用AI销售代理。
什么是代理?
从最基础的层面来看,代理由模型、指令、工具、上下文和记忆组成。模型用于分析用户请求,指令定义代理的角色和行为边界,工具使代理能够在现实世界中采取行动,上下文为代理提供业务相关数据支撑,记忆则用于保持对话连贯性。
在AgentFlo平台中,这些抽象组件对应着具体的平台模块:
| 组件 | 在AgentFlo中的功能 | |------------------|----------------------------------------------| | 模型 | 理解用户意图并决定下一步行动 | | 系统提示/角色设定 | 定义代理是扮演销售代理、餐厅代理、客服代理还是接待员 | | 工具 | 允许代理搜索产品、检查库存、创建购物车、下单、创建工单或触发后续跟进 | | 知识库 | 以商户特定数据(如产品目录、菜单、政策、促销和FAQ)为响应提供依据 | | 记忆/状态 | 保持对话历史、购物车状态、客户偏好和先前操作 | | 渠道 | 将代理连接到WhatsApp、短信、RCS、网页聊天和语音 | | 安全防护/策略 | 防止不安全、未经授权或错误的操作 | | 可观测性 | 跟踪成本、性能、转化率和对话质量 |
构建演示代理非常简单。但要构建一个能够安全、可靠且大规模运行的商业代理,则需要不同的方法。AgentFlo围绕五个支柱组织了这一方法。
生产级AI代理的五大支柱
AgentFlo的架构围绕五大支柱展开:速度(Velocity)、标准化(Standardization)、可扩展性(Scalability)、信任(Trust)和可靠性(Reliable)。每个支柱都针对特定的生产挑战。这些挑战影响了团队选择AWS服务的方式,包括Strands Agents SDK、Amazon Bedrock AgentCore、Amazon Bedrock、AWS Fargate、Amazon DynamoDB、Amazon Aurora、Amazon Kinesis以及Amazon Simple Storage Service(Amazon S3)。
架构概览
图1:AWS上AgentFlo的生产架构。
客户消息通过WhatsApp Graph API或网页/移动端渠道到达,经过应用负载均衡器进入AWS Fargate消息层。该层处理身份验证、图像光学字符识别(OCR)、语音转文本/文本转语音、预对话防护措施以及提示注入检测。经过验证的请求流入AgentCore运行时(Amazon Bedrock AgentCore的一项功能),Strands Agents SDK在此协调代理,将模型推理流式传输到外部大型语言模型(LLM)。AgentCore网关(Amazon Bedrock AgentCore的一项功能)通过基于IAM的授权,将工具调用代理到AWS Lambda函数的API层(购物车、产品和知识库)。它通过包含Amazon DynamoDB会话和购物车表、Amazon Aurora订单表以及由Amazon S3支持的Amazon Bedrock知识库的数据层持久化状态。Amazon Bedrock AgentCore中的策略独立于模型推理,强制实施确定性访问控制。Amazon Bedrock Guardrails也可嵌入策略中,用于过滤请求和响应中的提示攻击、有害内容和敏感信息。在可观测性方面,日志和跟踪信息输入AgentCore Observability(Amazon Bedrock AgentCore的一项功能),而Amazon Data Firehose会将每次交互捕获到Amazon S3中,用于成本和收入分析。
在选择Amazon Bedrock AgentCore之前,AgentFlo评估了多种托管选项。三个关键功能使其脱颖而出:
- 支持长期商业对话的状态会话。
- 代理运行时:每个代理会话都在自己的轻量级虚拟机中运行,在租户之间提供硬件级安全边界。
- 原生MCP集成:模型上下文协议(MCP)是一项开放标准,允许AI代理通过统一接口安全连接到外部数据源和工具。AgentCore网关原生支持MCP,实现标准化的工具连接。
支柱1:速度:从商户构想到实时代理只需数分钟
市场速度决定了商户能否抓住新兴机会。AgentFlo通过简化的部署模型来应对这一挑战。
挑战
商户希望快速推出代理,但每个商户都有独特的流程、语气、工具、语言、产品和业务规则。通用的聊天机器人模板过于浅显。而为每个代理进行定制开发又无法扩展。
基于配方的部署
AgentFlo采用基于配方的代理部署模型。商户可从预配置的配方中选择,每个配方都包含角色设定、语言、语气、工具集、提示模板、知识来源、响应包和业务规则。可用配方包括:
- 销售代理。
- 餐厅点餐代理。
- 诊所接待员。
- 客服代理。
- B2B 重购代理。
- 购物车恢复代理。
商户通过 AgentFlo 门户微调少量选项,其余流程均由系统自动完成。
实现方式
AgentFlo 选择 Strands Agents SDK 作为其代理框架。Strands Agents SDK 采用模型驱动架构:您将工具定义为 Python 函数,编写系统提示,由模型负责调度。无需僵化的流程图或手动编码的状态机。
从商户视角来看,代理创建完全无需编码。以下是代理定制流程示例:
图 2:代理定制工作流
这种方案使配方模型得以有效运行。新增功能(如会员计划注册)只需编写新工具函数并更新系统提示,无需重新设计调度层。
后台流程中,一次选择会触发自动化流水线:
- 门户根据配方模板生成 Strands 代理配置。
- GitHub Actions 将代理(工具、提示、上下文)打包为容器。
- 容器部署到 AgentCore 运行时并配置相应的网关策略。
- 代理在几分钟内即可通过 WhatsApp 上线。
图 3:在钩子工作流下构建定制化代理的步骤
每个代理都是 Strands Agent 实例,其工具定义映射到 AgentCore 网关端点。扩展代理功能只需代码修改,而非架构调整。
成果
这种基于配方的方法实现了更快的商户入驻流程、对新代理行为的快速实验以及平台范围内的快速功能扩展。同时意味着每次部署的工程工作量更低,客户对话与产品迭代之间的反馈循环更紧密。
支柱 2:标准化:可复用的配方、工具和商业流程
部署间的统一性可加速迭代并减少维护负担。AgentFlo 通过共享构建模块实现这一点。
随着 AgentFlo 跨行业扩展,碎片化威胁着团队效率。每个商户都有独特的目录结构、ERP 设置、系统配置(Shopify、WooCommerce、Magento)、定价规则、语言、促销活动和支持流程。缺乏标准化会导致每次部署都成为定制项目,而定制项目无法扩展到数百家商户。
可复用的构建模块
AgentFlo 围绕几个核心组件实现标准化:代理配方(领域特定模板)、工具市场(可复用能力)、基于 MCP 的连接器(标准化集成)、集成合同(一致接口)。其他组件包括提示和上下文包(可复用模板)、对话评审循环(持续改进)以及共享语义层(统一的产品理解)。商户特定的复杂性被推至系统边缘,核心部分保持一致。
具备领域专业知识的单代理架构
我们早期发现,对于大多数客户交互,一个具备领域知识和精选工具集的单代理架构优于多代理架构。每个 AgentFlo 部署配置一个独特的角色、语气、语言和针对业务领域的专用工具集(销售代理、餐厅代理、诊所接待员)。它预装了精选上下文、提示模板和响应包。商户通过自助服务门户部署这些领域专用代理。
单一专注代理通过统一上下文管理比多个通用代理之间的协作表现更优。多代理功能在有价值场景下依然可用。例如,当对话从销售转向支持时,上下文能干净地传递给专业代理。
通过 AgentCore 网关的工具路由
集中式工具管理将代理请求路由到专用 AWS Lambda 函数。当客户询问产品库存时,代理查询产品目录。当客户准备购买时,代理处理购物车操作。对于个性化推荐,代理从 Amazon Bedrock 知识库获取数据,该知识库是完全托管的检索增强生成(RAG)功能,依托存储在 Amazon S3 中的商户数据。销售情报 API 为每次交互提供额外上下文。
OAuth 令牌和平台凭证存储在网关而非代理会话中。AgentCore 的策略与网关并行运行,强制执行基于 Cedar 的细粒度访问控制规则,这些规则独立于模型推理运行。Cedar 是 AWS 开发的开源策略语言,支持细粒度、可验证的授权决策。
策略定义哪些代理会话可以调用哪些工具。例如,销售代理无法调用仅限客户支持的 API。
从标准化角度看,这意味着平台新增的每个工具(支付集成、物流提供商、忠诚度系统)都会通过相同机制向所有适用配方开放。工具不会按商户重复实现。
AgentCore 网关作为集成骨干
AgentFlo 与数十个电子商务服务集成:Shopify、WooCommerce、Magento、SAP、支付处理器、物流提供商和忠诚度系统。每个集成都定义为 MCP 服务器连接器,网关处理发现、认证和路由。此外,AgentFlo 有多种不同代理配方,每种配方都有自己的专用工具包来实现特定功能。为使这些连接模块化且高效,AgentFlo 使用 AgentCore 网关。
从代理视角看,只需几行代码即可访问网关完整工具接口:
from strands import Agent
from strands.models import BedrockModel
from strands.tools.mcp.mcp_client import MCPClient
from mcp.client.streamable_http import streamablehttp_client
def create_transport():
return streamablehttp_client(
GATEWAY_URL,
headers={"Authorization": f"Bearer {access_token}"},
)
mcp_client = MCPClient(create_transport)
with mcp_client:
# 一次调用即可发现网关注册的所有工具
# 购物车、产品目录、知识库、物流、忠诚度等
tools = mcp_client.list_tools_sync()
agent = Agent(
model=BedrockModel(model_id="us.anthropic.claude-sonnet-5-20260630"),
tools=tools,
system_prompt=SALES_AGENT_PROMPT,
)
response = agent("Do you have the red leather wallet in stock?")将 Strands 代理连接到 AgentCore 网关。单次 list_tools_sync() 调用即可让代理访问网关注册的所有集成:购物车、产品目录、知识库、物流、忠诚度。为商户新增服务只需修改网关,无需更改代理。
关键能力:
原生 MCP 工具连接:每个平台或工具集集成都是标准 MCP 服务器连接器。
OAuth 和凭证管理:平台 API 密钥和 OAuth 令牌在网关中集中管理,从不暴露给单个代理会话。
代码简洁性:代码更简洁、更短小、更模块化,简化了规模化配置。另一种方式是为每个连接或工具集编写大量本地代码。
由于每个新服务集成和特定配方的工具集都在 AgentCore 网关中定义为 MCP 服务器连接器,扩展是模块化且快速的。添加新服务或工具集只需连接器定义,而无需重构架构。
对话审查作为标准化循环
标准化也来自学习。AgentFlo 持续审查真实对话,以理解客户如何询问产品、在哪些环节流失、哪些推荐有效、何时需要交接,以及本地语言如何影响购买行为。
这些审查反馈到配方、提示和工具定义中。标准化是平台随着时间积累获得的能力,而非发布时声明的特性。
每次部署都会改善未来的部署,新的集成可以在商户群体中重复使用。代理行为在不同配方和商户间保持一致,工作流程在不同行业中变得可复用。服务变得更难复制,因为它从真实的商业行为中学习,而非依赖通用模板。
第三支柱:可扩展性:弹性、有状态的商业对话
商业对话在流量和持续时间上都难以预测。AgentFlo 的架构无需人工干预即可处理这两个维度。
在闪购、产品发布或餐厅高峰时段,客户对话量可能激增 10-50 倍。人工团队无法如此快速扩展。AgentFlo 必须同时支持大量商户和并发客户会话。一个商户的流量高峰不应影响其他商户的体验。
AgentFlo 的无服务器架构
AgentFlo 采用无服务器架构。消息摄入、代理执行、工具执行、状态、分析和计费各自独立扩展。每一层都能自主吸收流量高峰,无需系统其他部分过度配置。
AgentCore 的可扩展运行时属性
AgentCore 的多个运行时属性专门支持可扩展性:
隔离的微虚拟机执行:每个代理会话在独立环境中运行,拥有专用的 CPU、内存和文件系统。环境在终止时会被清理。一个商户的会话永远不会影响另一个商户。
最长八小时的有状态会话:长时间对话不会丢失上下文。客户上午浏览的商品,晚上可以继续相同的辅助会话。
框架无关性:AgentCore 本机支持 Strands 代理,同时也兼容任何容器化代理框架,使 AgentFlo 能够随时间灵活演进代理架构。
架构端到端基于 AWS:
消息层(AWS Fargate):应用负载均衡器将传入的 WhatsApp 消息路由到 Fargate 应用程序,该程序处理身份验证、语音消息转换(Opus OGG 转 MP3 语音识别,结合产品名称模糊匹配)。应用程序还运行预回合安全防护。AWS 终端用户消息提供另一种渠道选项,以实现更广泛的覆盖。
代理编排(Amazon Bedrock AgentCore 运行时):每个客户会话都会生成一个独立的代理实例,运行 Strands Agents SDK。会话最多保持八小时状态,并通过微虚拟机架构实现隔离,每个会话在自己的轻量级虚拟机中运行。它们是持久化的,支持文件系统访问以存储中间结果和缓存的商品目录。微虚拟机隔离确保商户之间完全分离。
这是 Strands SDK 代理代码与 AWS 生产就绪端点之间的完整桥梁:
from strands import Agent
from bedrock_agentcore.runtime import BedrockAgentCoreApp
app = BedrockAgentCoreApp()
agent = Agent(
tools=tools, # 来自网关,如上文代码片段所示
system_prompt=SALES_AGENT_PROMPT,
)
@app.entrypoint
def invoke(payload, context):
"""每个客户对话对应一个 AgentCore 会话。"""
user_message = payload.get("prompt")
session_id = getattr(context, "session_id", None) # 最多保持 8 小时稳定
result = agent(user_message)
return {"result": result.message}
if __name__ == "__main__":
app.run()这就是 Strands 代理与 AgentCore 运行时之间的全部连接。BedrockAgentCoreApp 将代理封装在标准的 /invocations 协议中,AgentCore 负责微虚拟机分配、会话隔离、扩展以及最多八小时的状态会话。两个 CLI 命令即可将本地文件部署为 AWS 上的实时端点。无需 Dockerfile,无需 API 路由,无需维护 Web 框架。
agentcore configure --entrypoint agent.py
agentcore launch工具执行(Amazon Bedrock AgentCore 网关):工具调用与代理推理独立扩展,因此购物车操作的突发高峰不会影响代理循环本身的性能。
该架构无需预分配容量即可处理峰值流量,并支持跨多次访问持续进行的长期对话。相比传统持续运行的基础设施,它通过更强的多商户隔离和更低的运维开销,显著提升了客户在产品发布或限时促销等高意图时刻的体验。
下一步
在本系列的第二部分中,我们将探讨:
支柱 4:信任。自主商业行为的防护机制以及对代理操作的实时可见性。
支柱 5:可靠。确保代理基于可靠、最新信息执行任务的数据基础。
商业成果:贯穿客户生命周期的可衡量影响。
未来路线图:语音代理、服务器端工具执行以及集成扩展。
总结
在本文中,我们探讨了构建生产级 AI 代理的五个支柱中的三个:
速度:基于配方的部署如何使商户通过 Strands Agents SDK 的模型驱动架构在几分钟内启动 AI 销售代理。
标准化:如何通过 Amazon Bedrock AgentCore 的可复用构建模块和集中式工具管理,在数百次部署中实现一致性。
可扩展性:如何通过 Amazon Bedrock AgentCore 和 AWS Fargate,AgentFlo 在大规模场景中处理弹性、有状态的电商对话。
下一步行动
- 立即使用 Strands Agents SDK 开始
- 探索 Amazon Bedrock AgentCore 的能力
- 阅读第二部分了解信任、可靠性和商业成果
我们很期待了解您如何构建自主 AI 系统。欢迎在评论区分享您的经验。
作者简介
'"`