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

AgentFlo如何使用Amazon Bedrock AgentCore构建AI销售代理 – 第2部分 | AWS架构博客

AgentFlo如何使用Amazon Bedrock AgentCore构建AI销售代理 – 第2部分

如果你需要大规模构建AI代理来处理商业场景，将面临两个关键挑战：应对不可预测的流量激增，以及确保代理能够安全处理真实客户交易。

本文将展示AgentFlo如何通过Amazon Bedrock AgentCore和AWS无服务器架构解决这些挑战。你将了解其可靠性与信任框架背后的技术架构模式，看到可衡量的商业成果（包括基于早期部署数据的+12%净收入提升），并探索其语音代理和服务器端工具执行的未来规划。

这是由两部分组成的系列文章的第2部分。第1部分涵盖速度、标准化和可扩展性。

支柱4：信任：自主商业操作的防护措施和对代理操作的实时可见性

AgentFlo在堆栈的每一层都强制实施信任机制，从预请求过滤到响应后的隐私控制，使商家能够放心部署自主代理。

挑战

除非企业客户能够信任自主代理，否则不会部署它们。生产环境中的代理不能暴露敏感数据、提供未经授权的折扣或访问其他客户的信息。系统还防止价格幻觉、未经授权的工具调用、退出违规和凭证泄露。

商家还需要对谁可以与AI代理交互以及每个用户群体可以访问哪些数据进行细粒度控制。企业客户需要受限访问权限；B2C业务则需要开放访问权限以实现更广泛的覆盖。没有基于身份的控制，部署面向客户的AI将无从谈起。

多层防御

在AgentFlo，信任不仅仅是安全响应的问题。它关乎安全操作。代理可以创建购物车、下单、应用折扣、访问客户数据并交互后端系统，因此策略执行必须位于模型推理循环之外。模型提出建议，确定性策略做出决策。

AgentFlo在整个代理生命周期中实施信任控制：在模型看到请求之前、工具执行期间以及模型生成响应之后。

三层防护机制

当用户从AgentFlo门户部署代理时，安全执行发生在三个阶段。

首先，AWS Fargate层检测提示注入并在请求到达代理之前处理退出操作。WhatsApp消息通过电话号码作为唯一标识进行身份验证。像EBM这样的企业客户限制访问授权用户，而餐厅部署则保持开放以实现更广泛的覆盖。

接下来，AgentCore层在工具执行期间验证身份并实施订单锁定。AgentCore网关（Amazon Bedrock AgentCore的一项功能）实施防止销售代理访问客户支持工具的策略。Cedar策略独立于模型推理实施业务规则，如最大折扣百分比限制。Cedar是由AWS开发的开源策略语言，用于细粒度、可验证的授权决策。此外，Amazon Bedrock AgentCore中的策略与Amazon Bedrock Guardrails集成，因此Cedar策略可以直接在网关边界调用可配置的安全防护，用于提示攻击检测、内容过滤和敏感信息阻止。

最后，通过会话后隐私过滤器对输出进行筛选，防止客户看到响应前出现无意的令牌泄露和未经验证的价格声明。密钥通过AWS Secrets Manager进行管理，结合OIDC（OpenID Connect）认证的持续集成和持续交付（CI/CD）流水线。代理代码中不存储任何凭证。

基础设施安全

应用层的信任需要坚实的基础架构支撑。AgentFlo将AgentCore内置的隔离能力与应用层控制结合：

• 会话隔离：通过AgentCore运行时实现会话隔离（Amazon Bedrock AgentCore的功能），利用专用微虚拟机（microVM）为商户的代理会话提供完全隔离。
• AgentCore网关策略：通过细粒度的Cedar策略控制哪些代理可以访问哪些工具和数据，无论模型推理如何，策略均以确定性方式执行。
• 基于AWS Identity and Access Management（IAM）的访问控制：为代理与服务之间的通信提供细粒度权限。
• Amazon Virtual Private Cloud（Amazon VPC）集成：代理会话在AgentFlo的VPC内运行，具有域级网络限制，确保代理仅与授权端点通信。
• 合规性：通过多司法管辖区的数据驻留控制和审计追踪满足监管要求。

可观测性

信任需要可见性。商户需要实时了解代理的行为，而不仅仅是在出现问题后。AgentFlo利用Amazon Bedrock AgentCore的功能AgentCore Observability，为每个代理交互提供端到端追踪，从初始请求到工具执行直至最终响应。

AgentCore Observability为每个代理会话捕获结构化追踪，包括模型延迟、工具调用序列、令牌使用情况和错误率。这些追踪数据流入Amazon CloudWatch，AgentFlo在此基础上构建仪表板，展示活跃会话、响应时间和工具调用模式。完整的请求到响应追踪支持追踪级别的调试。系统跟踪不同代理类型的P50/P95延迟和吞吐量，当行为偏离基线时向商户发出警报。成本归因功能提供按商户、按代理划分的分析，与具体对话关联。

成果

可观测性与信任的结合，使企业能够放心地大规模部署自主代理。商户可享受更安全的执行环境、跨司法管辖区更强的合规性，以及在会话级别对工具和数据的受控访问。

第五支柱：可靠性：确保代理基于可靠数据运行的数据基础

可靠的代理需要可靠的数据。AgentFlo通过有状态会话、商户知识库和语义产品发现，将每个代理操作都建立在经过验证的实时信息基础上。

企业客户不会信任那些忘记上下文、编造产品细节或基于过时数据运行的AI代理。一个报错价格、忘记客户先前请求或推荐已下架产品的代理会瞬间摧毁信任。系统必须确保每个代理操作都基于经过验证的实时信息，从产品目录和定价到对话历史和业务规则。

商户还需要代理在长客户旅程中保持连续性，访问最新业务相关知识，并通过自然语言发现产品，所有操作均无需人工干预或提示工程。

数据架构概览

在 AgentFlo 中，可靠性不仅仅体现在准确的响应上，更体现在基于经过验证的数据执行准确操作的能力。代理从数据源中检索产品信息、管理购物车并完成交易，因此每个数据源都必须具有权威性和时效性。模型进行推理，结构化数据做出决策。

AgentFlo 在三个层面应用数据可靠性控制：通过 Amazon DynamoDB 实现有状态的对话管理，通过 Amazon Bedrock 知识库实现商户特定知识管理，以及通过 Amazon S3 Vector 中的向量嵌入实现语义化产品发现。

状态管理架构

真实的销售旅程可能持续 8 小时或 3 天。客户可能在上午询问产品，午餐时比较选项，晚上完成购买。代理必须在所有对话轮次中记住上下文并保持状态，这样客户无需重复开始。

AgentCore 运行时和 Amazon DynamoDB 负责管理此上下文存储。代理会重放相关历史记录，根据意图加载上下文，并安全地继续交易。

每个代理需要具备三个特性：有状态（记住之前的交互）、自主性（无需人工干预即可决定下一步操作）和安全性（在业务规则范围内运行且不暴露敏感数据）。

双表 DynamoDB 设计满足所有三个需求：通过对话重放实现会话连续性，通过检测到的意图自动加载上下文，以及通过结构化的真实数据存储确保数据完整性，防止模型产生错误信息。

图 1：按消息的对话流程。AgentCore 运行时在每轮对话开始时从 DynamoDB 会话表中加载最近的 15 条消息。购物车表仅在意图检测标记请求与购物车相关时按需加载，防止模型生成错误的价格和数量。

知识库系统

商户将业务特定数据（餐厅菜单、诊所政策、产品规格、促销日历）上传到由 Amazon Simple Storage Service（Amazon S3）支持的 Amazon Bedrock 知识库中。代理会自动检索并推理这些商户特定内容。响应始终基于准确且最新的业务信息，无需商户编写任何提示词。

语义搜索和向量检索

AgentFlo 通过为 Amazon Aurora 数据库中的每个产品生成轻量级向量嵌入来提升产品发现能力。客户可以通过名称或描述查找产品。

AgentFlo 还会自动生成每个产品的额外可搜索标签，商户也可以添加自己的标签。结果是像“粉色的那个”、“最小的那个”、“最新款”或“带有金色包装的巧克力”这样的短语都能正确映射到对应产品。客户自然地提出需求，平台就能找到他们想要的商品。

可观测性与计费

系统通过 Amazon Data Firehose 将所有消息交互捕获到 Amazon S3，使商户能够跟踪每场对话的成本并将其与销售收益进行比较。该管道向商户展示了代理部署的投资回报率（ROI），并为持续优化代理提供了数据基础。

数据架构有助于在跨多日客户旅程的对话中最小化上下文丢失，通过基于事实的响应消除价格和产品幻觉。商家可享受无需关键词依赖的自然语言产品发现，以及无需提示工程即可实现的商家特定知识检索。每项代理部署的完整成本可见性和投资回报率归因，使商家能够清晰衡量平台价值。

业务影响：客户生命周期各阶段的可衡量结果

Salesflo 的解决方案通过 Strands Agents SDK 和 Amazon Bedrock AgentCore 实现，在客户生命周期各阶段均取得可衡量的改进：

| 指标 | 改进 | |------------------|--------------| | 净收入增长 | +12% | | 客户参与度 | +40% | | 转化率 | +15% | | 平均订单价值 | +8% | | 客户重新激活率 | +20% |

AgentFlo 通过在 90 天的早期部署期间，将代理协助的客户旅程与对照组进行比较，实现了这些结果。

注意：本文提到的基础模型仅在部分 AWS 区域可用。有关模型可用性的最新信息，请参阅 Amazon Bedrock 的支持区域和模型。

规模化后的复利效应

在 AgentFlo 的规模下，影响尤为显著。根据平台交易数据，每年有 3000 亿美元的交易价值通过 Salesflo 解决方案流动，即使单数百分比的改进也能为商家带来数十亿美元的额外收入。

运营改进

除了这些指标外，商家还能看到运营层面的改进：

• 全天候覆盖 — AI 代理可在任何时间、任何时区、任何渠道与客户互动。
• 质量一致 — 每次客户互动均遵循最佳销售实践方法，避免人工代理的变量影响。
• 可扩展的个性化 — 数千个并发代理会话，每个会话都能为每位客户维护独特的上下文。
• 快速商家上线 — 新商家可通过自助配置平台在数天内而非数月内启动定制化 AI 代理。

未来方向：语音、服务器端执行和集成扩展

AgentFlo 正在沿三个方向积极扩展平台，每个方向的成熟度不同。

实时语音代理（试点中）

AgentFlo 已经在 WhatsApp 中支持语音功能。传入的语音留言会经过两轮转录流程：首先进行原始初步转录，随后进行领域感知修正，通过模糊匹配将文本与实时产品目录进行比对。第二轮转录即使在部分听错的情况下，也能识别品牌名称和 SKU，支持超过 90 种语言。对于出站音频，商家可根据部署情况从多个文本转语音（TTS）提供商中选择。

由于语音转文本（STT）、AgentCore 运行时的推理以及 TTS 是完全独立的组件，任何一部分都可以替换而不会影响整个流程的其余部分。

下一步是 BidiAgent。下一步演进是基于 Strands SDK BidiAgent 和 Amazon Bedrock AgentCore WebRTC 支持的实时语音代理。BidiAgent 支持双向音频流传输、自然中断以及并发工具执行。代理可以在同一通电话中继续监听并回应客户的同时，检查库存或应用折扣。

AgentCore WebRTC 协议和 Amazon Kinesis Video Streams 能够在无需中继基础设施的情况下处理移动端和浏览器交互的点对点传输。这使 AgentFlo 能够突破传统短信的局限，拓展至主动外呼和高价值 B2B 销售场景，其中实时对话对于建立信任至关重要。

服务器端工具执行（开发中）

AgentFlo 正在亚马逊 Bedrock 中尝试服务器端工具执行，这完全消除了客户端的编排需求。

传统模型与工具之间的编排循环会反复进行（模型 → 执行 → 发送结果 → 重复）。通过服务器端执行，代理只需向 Amazon Bedrock Responses API 发起一次 API 调用，使用 AgentCore Gateway 的 Amazon 资源名称（ARN）。模型随后通过 Gateway Model Context Protocol（MCP）接口自主发现、调用并处理工具，所有操作均在 AWS 基础设施内完成，无需返回客户端的往返通信。

该 API 调用示例如下：

from openai import OpenAI

# OPENAI_BASE_URL = https://bedrock-mantle.us-west-2.api.aws/v1
# OPENAI_API_KEY = <Amazon Bedrock API key>
client = OpenAI()

response = client.responses.create(
    model="openai.gpt-oss-120b",
    stream=True,
    background=False,
    store=False,
    input=[
        {
            "type": "message",
            "role": "user",
            "content": [{"type": "input_text", "text": user_message}],
        }
    ],
    tools=[
        {
            "type": "mcp",
            "server_label": "agentflo_gateway",
            "connector_id": GATEWAY_ARN,  # arn:aws:bedrock-agentcore:...:gateway/...
            "server_description": "AgentFlo 商业工具（购物车、商品目录、知识库）",
            "require_approval": "never",
        },
    ],
)

注意：模型的可用性因 AWS 区域而异。本示例中显示的模型和端点可能并非所有区域都可用。请参阅 Amazon Bedrock 的支持区域和模型列表以获取最新信息。

一次请求即可完成整个流程。将 Gateway ARN 作为 MCP 连接器传入后，Bedrock 会自动拉取工具列表、选择合适的工具、调用并返回结果给模型，整个过程无需离开 AWS。客户端永远看不到凭证、工具模式或中间交互。更多细节请参阅 ShopAssist：电商代理演示。

初步成果：对于具有短而专注工具循环的专业代理，早期测量显示延迟降低了约 30%。一个销售代理按顺序调用三个工具（检查库存、应用折扣、更新购物车）可将 50 多行编排逻辑压缩为一次 API 调用。所有凭证均保留在服务器端，简化的架构使新代理开发者的入职流程更快。

集成生态系统扩展（进行中）

AgentFlo 根据商户需求添加集成。每个新平台（支付处理器、物流提供商、忠诚度系统或垂直专用 ERP）都会成为 AgentCore Gateway 中的另一个 MCP 服务器连接器。这种模式使扩展保持模块化和快速。

关键要点

• 首先确定核心支柱。正确的 AWS 堆栈将随之而来。AgentFlo 首先定义了生产系统中速度、标准化、可扩展性和信任的含义。有了明确的需求，AWS 堆栈的选择变得显而易见：Strands 用于代理层，AgentCore 运行时用于有状态会话，AgentCore Gateway 用于工具路由和策略，AWS Fargate 用于消息摄入。

• 专用代理配方胜过多代理复杂性。部署一个配置良好的单一代理，配备领域特定的工具和知识，对于大多数客户交互来说优于多代理编排。多代理交接仅用于跨领域过渡，且上下文边界明确界定的场景。

• 电商是有状态的。从第一天起就应该考虑这一点。真实的销售旅程可能持续8小时或3天。无状态聊天机器人无法维持如此长时间的上下文。AgentCore运行时的有状态会话和DynamoDB支持的上下文正是出于这个原因在第一天就被选中。后期将状态添加到无状态代理上会比一开始就设计状态更加痛苦。

• 三层安全体系建立信任。Fargate的预回合防护、通过AgentCore网关策略（使用Cedar）的按工具防护，以及回合后的输出过滤器协同工作，支持自主代理处理商业交易的安全部署。

• 系统设计支持扩展。通过将代理定制构建为AgentCore基础设施上的软件即服务（SaaS）层，AgentFlo能够在共享基础设施上为数百家商户提供服务，同时仍为每个商户提供个性化的代理行为。

• 无服务器架构 + AgentCore = 弹性电商。Fargate用于消息处理，AgentCore用于代理执行，这种组合使AgentFlo能够在无需预配置或容量规划的情况下，从正常流量扩展到50倍的闪购流量高峰。

• 反馈循环即产品。真实的客户对话教会代理如何促成交易。客户犹豫的地方、有效的语言、何时需要人工交接——所有这些都会反馈到配方、提示和工具定义中。新的商户部署将从平台之前所有对话中获益。这种复利循环比架构中的任何单一组件都更难复制。

结论

构建用于电商的生产级AI代理需要从第一天起就具备可扩展性和信任度。通过将Amazon Bedrock AgentCore的有状态会话和微虚拟机隔离与AWS无服务器基础设施结合，AgentFlo实现了能够处理不可预测流量并保持企业所需安全控制的自主代理。

下一步

• 通过Strands Agents SDK入门。

• 探索Amazon Bedrock AgentCore功能。

• 查阅Amazon Bedrock定价。

• 阅读第1部分了解速度和标准化模式。

有关实现类似架构的问题，请访问AWS架构中心或联系您的AWS账户团队。要开始构建，请打开Amazon Bedrock控制台或查看Amazon Bedrock服务详情页面。

我们很乐意了解您如何构建自主AI系统。在评论中分享您的经验。