AWS代付、代实名
阿里云国际 | 腾讯云国际

Amazon Bedrock AgentCore Memory:亚马逊云科技的托管记忆解决方案

AWS账单代付阅读(61)

亚马逊云科技提供

开箱即用的托管服务,通过AI Agent构建平台Bedrock AgentCore中的记忆模块帮助开发者更快捷地为AI Agent赋能记忆功能。

概述

图1-Bedrock AgentCore中的记忆模块核心功能展示

Amazon Bedrock AgentCore 的 Memory 模块是一个由亚马逊云科技托管的持久化记忆系统,用于存储和管理 AI Agent 的对话和知识。它提供短期记忆(short-term memory)和长期记忆(long-term memory)两种模式。短期记忆负责在一次会话中记录最近的最近几轮对话,确保代理能够“记住”当前对话的上下文。长期记忆则从对话中提取结构化的关键信息,在多个会话之间保留知识,使Agent能够“学习”用户偏好、事实和摘要等信息。

Memory 模块在架构上采用分层存储策略:短期记忆层存储原始交互事件作为即时上下文,长期记忆层存储从事件提取的概要知识。Memory 服务背后实现了自动的信息处理流水线:当新的事件被存储时,如果 Memory 配置了长期记忆策略,服务会异步地对事件内容进行分析(例如调用基础模型)来提炼出可长期保存的知识片段。

所有数据由 亚马逊云科技以加密方式存储,并使用命名空间(namespace)进行隔离分区,确保不同应用或用户的记忆数据彼此分隔。这一完全托管的记忆基础设施让开发者无需自己搭建数据库或向量存储,就能方便地让 Agent 拥有记忆功能。

Memory系统工作流程

以下序列图展示了AgentCore Memory从初始化到记忆检索的完整工作流程:

图2 – Bedrock AgentCore Memory从初始化到记忆检索的完整工作流程序列图

在这个流程中,大语言模型主要起到两个作用:

记忆提取**和 **上下文注入

用LLM 进行记忆提取(Memory → LLM :Memory 的长期记忆依赖于对对话内容的自动分析和提炼,这由 LLM完成。AgentCore Memory 内置了多种记忆策略(Memory Strategy)来定义如何将原始对话转化为结构化长期记忆。例如:

SemanticMemoryStrategy(语义记忆策略):从对话中抽取出 事实和知识,以便日后查询。

SummaryMemoryStrategy(摘要策略):为每个会话生成 对话摘要,提炼主要内容。

UserPreferenceMemoryStrategy(用户偏好策略):捕获用户的偏好、风格和重复选择等信息。

使用内置策略时,无需额外配置模型,AgentCore Memory 服务会在后台使用预置的模型来完成提取和归纳。当开发者调用

CreateEvent 保存新事件后,这些策略会被自动触发,异步运行LLM分析内容并产生长期记忆记录(memory records)。长期记忆记录生成后存储于 Memory 中,对应特定的命名空间和类型(如事实、摘要、偏好),每条记录也有唯一ID以供检索。

此外,AgentCore 允许

自定义记忆策略( CustomMemoryStrategy ,开发者可提供自定义的提示词(prompt)和选择特定的基础模型来执行记忆提取,例如只提取某类domain知识。

上下文注入(Memory → Prompt :Memory 提供存储和检索API,供应用在调用LLM推理时提取相关记忆并注入对话上下文中。也就是说,大语言模型在生成回复时,可以通过 Memory 提供的内容获得额外的上下文信息。例如,开发者可以在每次生成回复前,调用

list_events 获取当前会话最近N条对话记录,将其附加到 LLM 的提示中,以维护对话连续性。对于跨会话的信息,可以使用

retrieve_memories 接口通过语义

查询长期记忆,例如查询某用户的偏好或某主题的事实知识,然后把检索到的内容纳入提示。这种机制确保LLM在回答新问题时,不仅有当前对话文本,还能利用 Memory 中沉淀的历史知识,提高响应的相关性和智能性。

Memory as tool Memory 模块还可以与Agent框架的推理流程集成,实现自动的上下文注入。AgentCore Memory 可被包装成一个工具(Tool)供 LLM 调用。以 Strands Agents 框架为例,开发者通过

AgentCoreMemoryToolProvider 将 Memory 注册为工具,使得当模型需要回忆信息时,可以自主调用如 “

agent_core_memory” 工具执行

retrieve 动作来查询记忆,或用 record 动作将新的信息存入记忆。这种工具调用方式也通过Model Context Protocol (MCP) 等标准,让 LLM 在推理中动态决定何时读写记忆,使Agent能够更加自主地管理上下文。

基于Strands Agents框架搭建agent:

from strands_tools.agent_core_memory import AgentCoreMemoryToolProvider

strands_provider = AgentCoreMemoryToolProvider(

memory_id=memory.get(“id”),

actor_id=”CaliforniaPerson”,

session_id=”TalkingAboutFood”,

namespace=”/users/CaliforniaPerson”,

region=”us-west-2″

)

agent = Agent(tools=strands_provider.tools)

Memory核心组件和储存方式

以下类图展示了AgentCore Memory的核心组件和它们之间的关系:

图3 – Bedrock AgentCore Memory的核心组件的Class Disgram

Memory 模块以记忆存储(Memory Store)的形式存在。开发者可通过 SDK 创建一个 Memory 实例来作为特定用途的记忆库,每个 Memory 实例都有唯一的 ID。记忆事件(Event)是 Memory 中基本的数据单元,用于存储一次交互的信息,包括参与者、会话标识和消息内容等。每个事件记录包含以下关键属性:

actorId:参与者ID,用于标识是谁的记忆。例如可以是终端用户ID,或特定Agent标识等。

sessionId:会话ID,用于将一系列相关交互归组为同一会话(对话)。

payload:承载实际内容的数据,可以是对话消息(包括角色和消息内容)、工具调用、系统事件等。Memory允许一次事件存储多个消息片段,方便批量写入多轮交互。

eventId:事件的唯一标识符,支持通过ID精确检索事件。

基于这些储存的Memory, SDK提供了很多API来和储存的memory交互,完成例如创建提取删除等。

API操作

记忆管理

CreateMemory: 创建记忆资源

GetMemory: 获取记忆详情

ListMemories: 列出所有记忆资源

UpdateMemory: 更新记忆配置

DeleteMemory: 删除记忆资源

短期记忆操作

CreateEvent: 创建事件

GetEvent: 获取特定事件

ListEvents: 列出会话中的事件

DeleteEvent: 删除特定事件

长期记忆操作

RetrieveMemoryRecords: 语义搜索记忆记录

ListMemoryRecords: 列出命名空间中的记忆记录

DeleteMemoryRecord: 删除特定记忆记录

基本步骤:

  • 安装SDK:

pip install bedrock-agentcore

  • 创建Memory客户端:

client = MemoryClient(region_name=”us-west-2″)

  • 创建记忆资源:

memory = client.create_memory(name=”MyMemory”)

基于不同记忆需求,完成流程:

短期记忆工作流程

事件创建: 使用

CreateEvent 操作捕获每个交互

会话管理: 通过

sessionId 维护对话上下文

历史检索: 使用

ListEvents 和

GetEvent 访问过往交互

长期记忆工作流程

策略配置: 在

CreateMemory 操作中添加记忆策略

异步提取: 后台自动从原始事件中提取洞察

记忆整合: 将新提取的信息与现有信息合并

语义检索: 使用

RetrieveMemoryRecords 进行智能搜索

API代码示例

基本步骤:

  • 安装SDK:

pip install bedrock-agentcore

  • 创建Memory客户端:

client = MemoryClient(region_name=”us-west-2″)

  • 创建记忆资源:

memory = client.create_memory(name=”MyMemory”)

  • 开始存储事件:

client.create_event(memory_id, actor_id, session_id, messages)

创建短期记忆

from bedrock_agentcore.memory import MemoryClient

client = MemoryClient(region_name=”us-west-2″)

memory = client.create_memory(

name=”CustomerSupportAgentMemory”,

description=”Memory for customer support conversations”

)

创建长期记忆

memory = client.create_memory_and_wait(

name=”MyAgentMemory”,

strategies=[{

“summaryMemoryStrategy”: {

“name”: “SessionSummarizer”,

“namespaces”: [“/summaries/{actorId}/{sessionId}”]

}

}]

)

创建事件

client.create_event(

memory_id=memory.get(“id”),

actor_id=”User84″,

session_id=”OrderSupportSession1″,

messages=[

(“Hi, I’m having trouble with my order #12345”, “USER”),

(“I’m sorry to hear that. Let me look up your order.”, “ASSISTANT”)

]

)

检索记忆

memories = client.retrieve_memories(

memory_id=memory.get(“id”),

namespace=”/summaries/User84/OrderSupportSession1″,

query=”can you summarize the support issue”

)

Memory策略处理逻辑

由上述内容,我们可以简单总结以下流程图展示记忆策略的处理逻辑:

图4 – Bedrock AgentCore Memory的记忆处理策略的流程图

单次会话的多轮对话中,短期记忆充当了“对话缓冲区”的角色。每当用户和Agent交互一个回合,Agent可以将本轮对话(包括用户消息、Agent回复,以及Agent调用工具的动作和结果)记录为一个Memory事件。这些事件按时间顺序累积在当前 session 下,Agent 随后可以通过调用 list_events 获取最近若干轮对话历史,将其提供给LLM作为上下文,从而让Agent的回复建立在完整的对话背景之上。通过Memory维护的对话历史,Agent无需依赖LLM自身的窗口去“记住”所有内容,而是可以在需要时检索相关内容并注入提示。这有效避免了长对话中上下文窗口溢出或遗忘的问题,使多回合对话更连贯。

Memory 对

用户状态的管理则依赖于长期记忆功能。随着用户在多次会话中的互动,Agent 可以逐步积累关于该用户的偏好、习惯和历史请求等信息。例如,AgentCore 内置的用户偏好策略会自动提炼用户经常提及的偏爱设置(如喜好的编程风格、常用品牌等)并存入长期记忆。当用户在未来的会话中与Agent互动时,Agent 可以查询这些长期记忆来 个性化当前对话。跨会话的记忆由 Memory 的 actorId 来区分不同用户:只要为同一用户使用相同的 actorId,AgentCore Memory 就能将该用户各次会话的长期记忆关联在一起。

Memory 的维护和历史数据管理

作为托管服务,Bedrock AgentCore Memory 提供了

持久化存储来保留对话历史和提取出的知识。短期记忆和长期记忆的数据都会持久保存于 Memory Store 中,除非被显式删除或设置了过期策略。

短期记忆一般用于会话实时上下文,但实际上事件数据会存储在服务端,即使同一会话暂时结束,下次仍可检索先前的事件记录,除非应用选择不再使用它们。

长期记忆则是明确为跨会话持久化设计的,提取出的偏好、事实、摘要等会长久保存,供未来的对话查询。尤其对于需要跨多个用户会话共享的知识,可以将多个Agent或会话指向同一个 Memory 实例,以实现知识的统一管理。

在创建事件时,开发者可以设置一个 eventExpiryDuration 参数,为该事件指定自动过期时间。一旦事件超过设定的保留时长,系统将自动删除它,从而避免长期保存无用的短期对话数据。这在隐私和成本考虑上非常实用:对于不需要长期保留的对话细节,可以让系统自动清理。同时,Memory 提供 DeleteEvent API,可用于手动删除特定事件。这些机制使开发者能够

按需控制历史数据的保留长度,确保 Memory 中的信息既不过期丢失重要知识,也不会无限增长占用资源。

需要注意的是,Memory

长期记忆记录的生成是异步的。当添加新的事件后,提取策略需要一些时间(通常1-2分钟)在后台将其处理为长期记忆。开发者应在提取过程完成后再检索长期记忆内容(例如通过轮询或适当的延迟)。长期记忆记录一旦生成,将存储于指定的 命名空间下。

命名空间是一种逻辑隔离/分类手段,通常采用类似路径的格式表示层次结构。例如,UserPreference 策略可以使用命名空间前缀/users/{actorId}来区分不同用户的偏好数据;Summary 策略可以用/summaries/{actorId}/{sessionId}来归档每次会话的摘要。开发者也可以自定义命名空间,以适合自己的数据组织需求。

/strategy/{strategyId}/actor/{actorId}/session/{sessionId}

这样就可以基于不同颗粒度进行存储和搜索了,从细到粗比如:按会话—按参与者—按策略组织—跨所有策略。

Memory案例展示

接下来的案例通过构建一个智能宠物管家系统,展示如何使用

Amazon Bedrock AgentCore Memory 的四种记忆策略来实现AI应用的长期记忆管理。

四种记忆策略详解

长期记忆可以应用如下四种记忆策略,使用的时候可以指定一个,也可以同时指定多个策略。

1. 语义记忆 (Semantic Memory)

存储事实性知识和基本信息

{

StrategyType.SEMANTIC.value: {

“name”: “PetKnowledgeBase”,

“description”: “存储宠物基本信息、品种特征、健康状况等事实性知识”,

“namespaces”: [“/pets/{actorId}/knowledge”]

}

}

存储示例:

  • “Max是一只3岁的金毛寻回犬,性格友好活泼”
  • “Max已完成狂犬病疫苗接种,体重28kg正常”
  • 2. 偏好记忆 (User Preference Memory)

跟踪个性化偏好和习惯

{

StrategyType.USER_PREFERENCE.value: {

“name”: “PetPreferences”,

“description”: “跟踪每个宠物的个性化偏好和习惯”,

“namespaces”: [“/pets/{actorId}/preferences”]

}

}

存储格式(JSON):

{

“context”: “Max特别喜欢鸡肉,每次都吃得很香”,

“preference”: “喜欢鸡肉食物”,

“categories”: [“饮食”, “偏好”]

}

3. 摘要记忆 (Summary Memory)

创建活动时间线摘要

{

StrategyType.SUMMARY.value: {

“name”: “PetActivitySummary”,

“description”: “创建和维护宠物日常活动的时间线摘要”,

“namespaces”: [“/pets/{actorId}/summaries/{sessionId}”]

}

}

存储格式(XML):

Max学会了握手技能,只用了3次练习就掌握了。

Max特别喜欢鸡肉,护理员Alice建议每天给200g。

4. 自定义记忆 (Custom Memory) – 核心特性

自定义记忆策略是AgentCore Memory的最强大特性,允许开发者自定义记忆提取逻辑。

配置结构

{

StrategyType.CUSTOM.value: {

“name”: “PetRoleSpecificMemory”,

“description”: “针对不同宠物护理角色的专业记忆提取和管理”,

“namespaces”: [“/pets/{actorId}/professional”],

“configuration”: {

“semanticOverride”: {

“extraction”: {

“appendToPrompt”: CUSTOM_EXTRACTION_PROMPT, # 自定义提取提示词

“modelId”: “anthropic.claude-3-sonnet-[已去除电话]-v1:0” # 指定提取模型

}

}

}

}

}

自定义提取Prompt设计

CUSTOM_EXTRACTION_PROMPT = “””

根据当前激活的角色,专门提取相关领域的信息并添加角色标签:

护理员角色:日常护理、饮食管理、清洁卫生、生活习惯

  • 提取格式:[护理员] 时间戳 | 活动类型 | 详细描述 | 重要性(1-10)

训练师角色:行为训练、技能培养、纪律管理、训练进度

  • 提取格式:[训练师] 时间戳 | 技能名称 | 掌握程度 | 重要性(1-10)

医疗助手角色:健康监测、疫苗提醒、医疗建议、症状记录

  • 提取格式:[医疗助手] 时间戳 | 健康项目 | 状态描述 | 重要性(1-10)

请仅提取与当前角色相关的专业信息,忽略无关内容。

“””

提取效果预期:

输入文本:

“训练师Bob专业训练报告:Max今天完成了高级服从性训练,坐下指令响应时间2秒,握手动作标准度95%。”

Custom Memory提取结果:

“[训练师] 2025-08-01 | 高级服从训练 | Max完成高级服从性训练,对于坐下指令的响应时间为2秒,握手动作的标准度为95% | 9”

核心实现代码与结果示例

1. 环境设置和Memory创建

可以同时应用以上4中策略。

from bedrock_agentcore.memory import MemoryClientfrom bedrock_agentcore.memory.constants import StrategyTypefrom datetime import datetime

Amazon Bedrock AgentCore Memory:亚马逊云科技的托管记忆解决方案

REGION = “us-west-2”

SESSION_ID = f”pet_butler_{datetime.now().strftime(‘%Y%m%d_%H%M%S’)}”

ACTOR_ID = “pet_max”

ROLE_ARN = “<>“

创建Memory客户端

client = MemoryClient(region_name=REGION)

创建Memory实例(包含四种策略)

memory = client.create_memory_and_wait(

name=”PetButler”,

strategies=strategies, # 上述四种策略配置

description=”智能宠物管家系统”,

event_expiry_days=90,

memory_execution_role_arn=ROLE_ARN

)

memory_id = memory[‘memoryId’]

2. 添加对话事件

创建对话事件

demo_events = [

训练相关事件

(“Max今天学会了握手,3次练习就掌握了!训练师Bob说这是个重要的技能。”, “USER”),

(“太棒了!Max学习能力很强,我会记录这个训练成果。”, “ASSISTANT”),

(“训练师Bob还教了Max坐下和跟随指令,但跟随还需要练习,有时会走神。”, “USER”),

(“了解,我会记录Max的训练进度,跟随指令需要加强练习。”, “ASSISTANT”),

护理相关事件

(“Max特别喜欢鸡肉,每次都吃得很香,护理员Alice建议每天给200g。”, “USER”),

(“好的,我会记住Max的饮食偏好和分量建议。”, “ASSISTANT”),

(“护理员Alice说Max每周需要洗澡两次,用温水,洗后要吹干毛发。他很乖,不抵触洗澡。”, “USER”),

(“记录了Max的洗澡需求和行为表现,他在清洁方面很配合。”, “ASSISTANT”),

医疗相关事件

(“疫苗接种:狂犬病疫苗已完成,体重28kg正常,医疗助手Dr.Chen说健康状况良好。”, “USER”),

(“很好,我会记录Max的疫苗接种和健康检查结果。”, “ASSISTANT”),

(“医疗助手Dr.Chen提醒下次体检时间是3个月后,需要检查心脏和关节。Max有轻微的关节炎家族史。”, “USER”),

(“了解,我会设置提醒并关注Max的关节健康。”, “ASSISTANT”),

社交和行为相关

(“Max社交能力很好,和其他狗狗玩得很开心,但看到松鼠会过度兴奋,需要训练师Bob继续训练。”, “USER”),

(“记录了Max的社交特点和需要改善的行为。”, “ASSISTANT”),

(“护理员Alice发现Max最近睡眠质量很好,每天晚上10点就会自己回窝休息,早上6点起床。”, “USER”),

(“很好,Max的作息规律很健康,这对他的整体健康很有益。”, “ASSISTANT”),

Custom Strategy专业报告事件

(“训练师Bob专业训练报告:Max今天完成了高级服从性训练,坐下指令响应时间2秒,握手动作标准度95%。”, “USER”),

(“护理员Alice日常护理检查:Max毛发光泽度评分8.5/10,皮肤无异常,体重28.2kg稳定。”, “USER”),

(“医疗助手Dr.Chen体检报告:Max心率72bpm正常,体温38.3°C正常范围,血压120mmHg。”, “USER”)

]

添加到记忆系统

client.create_event(

memory_id=memory_id,

actor_id=ACTOR_ID,

session_id=SESSION_ID,

messages=demo_events

)

将上述对话事件加入记忆系统后,我们可以查询到结果数量分布如下:

语义记忆: 10条记录(基本信息和事实知识)

偏好记忆: 6条记录(个性化偏好)

摘要记忆: 1条记录(活动摘要)

专业记忆: 9条记录(自定义提取的角色专业信息)

部分记忆结果可视化如下:

图5 – 基于Bedrock AgentCore Memory构建的智能宠物管家记忆结果可视化展示

3. 记忆检索

多策略记忆存储到长期之后,检索长期记忆的时候不需要指定具体的策略,而是基于相似度进行匹配。

查询记忆

memories = client.retrieve_memories(

memory_id=memory_id,

actor_id=ACTOR_ID,

namespace=f”/pets/{ACTOR_ID}/knowledge”,

query=”Max学会了什么技能?”,

top_k=5

)

处理结果

for memory in memories:

content = memory.get(‘content’, {}).get(‘text’, ”)

score = memory.get(‘score’, 0)

print(f”相关性: {score:.3f} | 内容: {content}”)

通过retrieve_memories方法,可以快速从记忆中提取相关记忆,多个queries的测试结果如下:

|

|测试场景

|召回时间

|结果

|召回结果相关性

|1

|Max学会了什么技能?

|0.321s

|Max在训练中学会了握手,只需要3次练习就掌握了这项技能…

|0.594

|2

|Max的饮食偏好?

|0.348s

|{“context”:”User mentioned that Max especially likes chicken meat and eats it very deliciously”,”preference”:”Likes chic…

|0.488

|3

|健康状况如何?

|0.343s

|医疗助手Dr.Chen体检报告显示Max心率72bpm、体温38.3°C、血压120mmHg均在正常范围…

|0.385

4. 与Agent集成

可通过如下代码,使用Stands Agents框架搭建agent,将上述记忆作为工具,快速构建宠物管家agent:

f

from strands import Agentfrom strands_tools.agent_core_memory import AgentCoreMemoryToolProvider

创建记忆工具提供者

memory_provider = AgentCoreMemoryToolProvider(

memory_id=memory_id,

actor_id=ACTOR_ID,

session_id=SESSION_ID,

namespace=f”/pets/{ACTOR_ID}/knowledge”

)

创建智能Agent

pet_agent = Agent(

tools=memory_provider.tools,

system_prompt=”””你是智能宠物管家,为宠物Max提供专业护理服务。

请充分利用记忆功能提供个性化服务。”””

)

对话示例

response = pet_agent(“Max最近学会了什么新技能?”)

接下来展示与agent的对话结果,以及随着对话进行记忆的更新情况。

第一轮对话:基本信息查询

用户: “请告诉我Max的基本信息和最近的活动情况”

Agent:

你好!我是Max的智能宠物管家,很高兴为你服务!

首先,让我为你介绍Max的基本信息:

  • **姓名**:Max
  • **品种**:Golden Retriever(金毛寻回犬)
  • **年龄**:3岁
  • **性格**:友好、活泼、聪明

现在让我查看一下Max最近的活动记录:

Tool #1: agent_core_memory

根据我的记录,Max最近的活动和状况非常不错!让我为你总结一下:

🏥 健康状况

  • **最新体检**:各项指标正常
  • 心率:72 bpm
  • 体温:38.3°C
  • 血压:120 mmHg
  • **体重**:28.2 kg
  • **疫苗接种**:已完成狂犬病疫苗接种
  • **毛发状况**:光泽度达到8.5/10,非常健康
  • **注意事项**:有轻微关节炎家族史,预计3个月后进行心脏和关节专项检查
  • 🎓 训练进度

Max在训练方面表现优秀:

  • **握手技能**:只用3次练习就掌握了,学习能力很强!
  • **高级服从性训练**:已完成
  • 坐下指令:响应时间2秒
  • 握手动作:标准度达95%
  • **跟随指令**:正在学习中,偶尔会走神(这很正常,需要耐心)
  • 🎯 社交能力

  • 社交能力良好
  • 对松鼠表现出过度兴奋,需要继续训练控制
  • 🛁 日常护理

  • **洗澡频率**:每周两次,使用温水
  • **洗澡表现**:完全不抵触,配合度很高
  • **睡眠作息**:非常规律,每晚10点自主回窝休息,早上6点起床
  • 🍖 饮食偏好

  • **最爱食物**:鸡肉
  • **建议摄入量**:每天200g

总的来说,Max是一只非常健康、聪明且训练有素的金毛!他的学习能力强,性格温顺,作息规律。继续保持现在的护理方式就很好了!

有什么特别想了解的方面,或者需要我为Max安排什么特别的护理吗?🐕✨

第二轮对话:添加新信息

用户: “Max今天表现很好,学会了新的捡球指令,而且很喜欢新买的玩具球。请记录这些信息。”

Agent:

太棒了!Max学会新技能了!🎾 让我为他记录这个重要的进步:

Tool #2: agent_core_memory

完美!已经成功记录了Max今天的优秀表现!🎉

📈 Max的训练进度更新:

  • ✅ 握手指令:已熟练掌握
  • ✅ 高级服从性训练:已完成
  • ✅ **捡球指令:今天新学会!** 🆕
  • 🔄 跟随指令:还在练习中
  • 🎾 玩具偏好:

  • 对新买的玩具球表现出很高的兴趣和喜爱

Max真的很聪明!金毛寻回犬本来就擅长捡拾游戏,看来他的天赋得到了很好的发挥。捡球不仅是很好的运动,还能:

  • 增强你们之间的互动和感情
  • 提供充足的体能训练
  • 锻炼他的专注力和反应能力

建议你可以:

1. 继续用玩具球进行捡球训练,巩固这个新技能

2. 逐渐增加难度,比如扔得更远或在不同环境中练习

3. 记得给Max充足的赞美和奖励,保持他的积极性

Max今天真是个好孩子!继续保持这样的训练节奏,他一定会越来越棒的!🐕⭐

第三轮对话:记忆召回测试

用户: “Max最近学会了什么新技能?他的训练进度如何?”

Agent:

让我为你查看Max最近的训练进度和技能学习情况:

Tool #3: agent_core_memory

现在让我再查看一下最新的捡球技能记录:

Tool #4: agent_core_memory

根据我的记录,让我为你整理Max最近学会的技能和训练进度:🎓

最近新掌握的技能:

  • **🎾 捡球指令** – 就在今天刚学会!而且对新买的玩具球表现出很高的兴趣和喜爱
  • ✅ 已熟练掌握的技能:

1. 握手指令

  • 学习速度:仅用3次练习就掌握
  • 熟练度:标准度达95%
  • 状态:完全掌握

2. 高级服从性训练

  • 坐下指令:响应时间仅2秒
  • 整体完成度:已完成全部课程

3. 捡球指令

  • 刚刚学会的新技能!🆕
  • 对玩具球表现出浓厚兴趣
  • 🔄 正在练习中的技能:

1. 跟随指令

  • 进度:学习中
  • 挑战:有时会走神
  • 建议:需要继续耐心训练,这很正常
  • 🎯 需要改善的行为:

1. 社交控制

  • 整体社交能力良好
  • 需要改善:对松鼠表现过度兴奋
  • 状态:需要继续训练

Max的训练进度非常优秀!他展现出了:

  • **快速学习能力**:握手技能仅用3次就掌握
  • **高度配合性**:各项指令响应积极
  • **持续进步**:今天又掌握了新的捡球技能
  • **天赋展现**:作为金毛寻回犬,在捡拾类游戏上表现出色
  • 建议下一步训练重点:

1. 继续巩固捡球技能,可以增加难度和变化

2. 专注改善跟随指令的专注度

3. 加强对小动物的自控训练

Max真是个学习能力超强的好孩子!🐕⭐ 他的进步让人印象深刻呢!

5.多agent协作

AgentCore Memory通过共享记忆实例和独立命名空间机制,实现了多Agent间的高效协作。每个Agent在保持专业独立性的同时,能够访问共享的记忆资源,形成协同工作的智能体系统。

from strands import Agentfrom strands_tools.agent_core_memory import AgentCoreMemoryToolProvider

定义三个专业Agent角色

AGENT_ROLES = {

‘chen’: {

‘name’: ‘医疗助手Dr.Chen’,

‘avatar’: ‘👨⚕️’,

‘actor_id’: ‘agent_chen’,

‘expertise’: ‘健康监测、疫苗提醒、医疗建议、症状记录’

},

‘alice’: {

‘name’: ‘护理员Alice’,

‘avatar’: ‘👩⚕️’,

‘actor_id’: ‘agent_alice’,

‘expertise’: ‘日常护理、饮食管理、清洁卫生、生活习惯’

},

‘bob’: {

‘name’: ‘训练师Bob’,

‘avatar’: ‘🏃♂️’,

‘actor_id’: ‘agent_bob’,

‘expertise’: ‘行为训练、技能培养、纪律管理、训练进度’

}

}

def create_multi_agent_system(memory_id, session_id):

“””创建多Agent协作系统”””

agents = {}

for role_key, role_info in AGENT_ROLES.items():

每个Agent使用独立的actor_id和命名空间

provider = AgentCoreMemoryToolProvider(

memory_id=memory_id,

actor_id=role_info[‘actor_id’],

session_id=session_id,

namespace=f”/pets/{role_info[‘actor_id’]}/knowledge”

)

创建专业化的Agent

agents[role_key] = Agent(

tools=provider.tools,

system_prompt=f”””

你是{role_info[‘name’]},专门负责宠物Max的{role_info[‘expertise’]}。

请根据你的专业领域提供建议,并与其他专业团队成员协作。

“””

)

return agents

用户: “我发现Max今天食欲不振,精神不佳,请专业团队帮忙检查和处理。”

Dr.Chen 医疗检查:

我是Dr.Chen,我会立即为Max的情况做记录并协助处理。让我先记录下Max今天的症状。

Tool #1: agent_core_memory

已记录Max的症状。针对Max出现的食欲不振和精神不佳症状,我建议采取以下专业处理措施:

立即关注要点:

1. 观察体温 – 检查是否发热

2. 检查口腔 – 查看牙龈颜色、口气异常

3. 观察排便情况 – 是否正常排便排尿

4. 活动能力 – 走路是否异常,是否愿意活动

建议处理方案:

1. 暂时提供易消化食物 – 如煮熟的鸡胸肉、白米饭

2. 确保充足饮水 – 监测饮水量

3. 提供安静舒适的休息环境

4. 密切观察症状变化

紧急情况指标:

如果Max出现以下情况,请立即就医:

  • 持续呕吐或腹泻
  • 体温异常(正常体温38-39°C)
  • 呼吸急促或困难
  • 完全拒食超过24小时
  • 明显疼痛表现

请问Max还有其他具体症状吗?比如呕吐、腹泻、体温变化等?这些信息有助于我提供更精确的建议。

Alice 护理建议:

我立即记录Max今天的状况,并为您提供护理建议。

Tool #1: agent_core_memory

根据Max今天的症状,作为专业护理员,我为您提供以下护理建议:

即时护理措施

1. 观察和监测

  • 密切观察Max的体温、呼吸频率和心率
  • 记录进食量、饮水量和排便情况
  • 注意是否有呕吐、腹泻等其他症状
  • 2. 环境调整

  • 为Max准备安静、温暖、舒适的休息环境
  • 减少噪音和干扰,让它充分休息
  • 保持室内空气流通但避免直吹
  • 3. 饮食护理

  • 暂时提供易消化的流质食物
  • 少量多次喂食,不强迫进食
  • 确保充足的清洁饮水供应
  • 可以尝试温热的鸡汤或专用营养液
  • 4. 基础护理

  • 轻柔按摩腹部,促进消化
  • 保持口腔和身体清洁
  • 避免剧烈运动,但可以适当的轻缓活动
  • 后续关注要点

  • 如症状持续超过24小时或恶化,立即联系Dr.Chen
  • 记录每日的食欲、精神状态变化
  • 定期测量体重,关注是否有明显下降

请问Dr.Chen的初步检查结果如何?这样我可以提供更针对性的护理方案。

Bob 训练调整:

我理解您对Max健康状况的担心。作为训练师,我会立即记录这个重要信息,并协调相关事宜。

Tool #1: agent_core_memory

我已经记录了Max的健康状况,并立即采取以下措施:

🚨 紧急处理方案

1. 健康检查优先

  • 我会立即联系专业兽医团队对Max进行全面健康检查
  • 暂停所有训练活动,避免给Max造成额外压力
  • 密切观察Max的症状变化
  • 2. 训练计划调整

  • **暂停期**:所有训练项目立即暂停,直到健康问题解决
  • **恢复期**:根据兽医建议,制定渐进式训练恢复计划
  • **强度调整**:恢复训练时将降低训练强度和时长
  • 3. 特别关注事项

  • 监控Max的食欲、精神状态和行为变化
  • 确保Max有充足的休息和舒适的环境
  • 配合兽医的治疗方案
  • 4. 后续安排

  • 等待专业团队的检查结果
  • 根据诊断结果调整长期训练策略
  • 制定适合Max当前状况的温和训练方案

Max的健康是第一位的!请您放心,我会与专业团队密切合作,确保Max得到最好的照护。有任何关于Max状况的更新,请及时告知我。

多Agent协作完成后,系统在各自的命名空间中存储了专业记忆:

INFO:bedrock_agentcore.memory.client:Retrieved 1 memories from namespace: /pets/agent_alice/knowledge

护理员Alice 的记忆:

📊 找到 1 条记忆

1. Max today experienced loss of appetite and poor spirits, and was examined by Dr….

INFO:bedrock_agentcore.memory.client:Retrieved 1 memories from namespace: /pets/agent_bob/knowledge

训练师Bob 的记忆:

📊 找到 1 条记忆

1. Max currently experiencing health issues including loss of appetite, poor mental…

INFO:bedrock_agentcore.memory.client:Retrieved 1 memories from namespace: /pets/agent_chen/knowledge

医疗助手Dr.Chen 的记忆:

📊 找到 1 条记忆

1. Max is experiencing symptoms of decreased appetite and low energy, which require…

使用Bedrock AgentCore Memory的最佳实践

最佳实践是为每个唯一用户使用固定的 actorId,这样 Memory 模块就能持续累积该用户的历史,并在需要时提供给Agent。

在多用户或者多Agent的复杂对话场景下,Memory 也支持灵活的上下文管理。由于 Memory 的事件记录包含 actorId 和 sessionId,系统可以区分“谁在说”(用户还是Agent)以及“哪个会话”。这意味着在一个群组对话(multiple actors)或者多个Agent协作的情境下,可以通过给不同参与方设定不同的 actorId 来分别跟踪各自的发言和状态。如果有多个Agent协同完成任务,他们也可以共享同一个 Memory Store 或各自拥有Memory,再通过某种协调机制交换必要的记忆。

AgentCore Memory 提供

命名空间来自定义长期记忆的隔离范围,因此甚至可以实现 部分共享:例如,让两个Agent共享某些公共知识(存在公共的namespace),但各自维护独立的用户偏好(存在各自用户命名空间)。

总的来说,在多回合、多主体的对话中,Memory 模块通过结构化地存储对话和提炼知识,成为维护上下文连续性和用户状态的关键组件,使Agent能够做到“记忆长期,理解当下”。

其他最佳实践

  • 性能优化,比如使用适当的命名空间颗粒度,合理设置事件保留期限,优化搜索查询的具体性;
  • 数据管理上定期清理过时的记忆记录,实施数据隐私保护措施,监控记忆存储使用情况;
  • 如果遇到报错,可以实施重试机制,监控异步处理状态,处理记忆提取失败情况。
  • 其他技术资料链接

    Strands Agent

https://aws.amazon.com/cn/blogs/china/practical-guide-to-building-agentic-ai-applications-for-aws-china-region/

AgentCore Memory** **官方文档

https://docs.aws.amazon.com/zh_cn/bedrock-agentcore/latest/devguide/memory.html

AgentCore** **代码样例

GitHub – awslabs/amazon-bedrock-agentcore-sample

相关博客:

《Agentic AI基础设施深度实践经验思考系列(三):Agent记忆模块的最佳实践》

本文将深入探讨 Agent应用中的记忆需求、记忆类型、技术组件和主流开源框架,并介绍基于亚马逊云科技的数据产品自行构建记忆模块,以及基于Agent构建平台Bedrock AgentCore的Agent memory的托管方案。

《相得益彰:Mem0 记忆框架与亚马逊云科技的企业级 AI 实践》

本文将详细探讨mem0记忆框架和亚马逊云科技服务的集成方案。

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

本篇作者


Agentic AI基础设施实践经验系列(一):Agent应用开发与落地实践思考

AWS账单代付阅读(62)

亚马逊AWS官方博客

Agentic AI基础设施实践经验系列(一):Agent应用开发与落地实践思考

在过去的短短几年内,基础模型(FMs)已经从直接用于响应用户提示创建内容,发展到现在为AI Agent提供动力。AI Agent是一类新型软件应用,它们使用基础模型来推理、规划、行动、学习和适应,以追求用户定义的任务目标,同时只需要有限的人工监督。AI Agent由基础模型驱动,其不确定性和非预定义逻辑的运行机制,为开发者带来了全新的应用开发和运维范式。基于在多个项目中积累的Agent应用构建经验,我们为您整理了一系列Agentic AI基础设施实践经验内容。这些内容详细介绍了构建Agent应用所需的沙盒、记忆、评估、可观测性和工具部署等多个维度的经验,帮助您全面深入地掌握Agent构建的基本环节。

在系列(一)中,我们将共同探讨Agent开发和运维Agent(AgentOps)的基本要素和实践思考。

1. 解构 Agent 开发

在深入探讨AgentOps之前,我们需要先理解Agent开发的本质。与传统应用开发不同,Agent开发是一个多维度、多层次的工程挑战,它不仅涉及代码逻辑的实现,更关乎如何构建一个具备推理、记忆和行动能力的智能体。

Agent 系统的架构可以抽象为四个核心模块的协同工作: (1 )推理引擎,推理引擎是Agent的“大脑”,通常基于大语言模型实现。它负责理解用户意图、制定执行计划、任务执行。在开发层面,这意味着我们需要精心设计提示词模板、优化推理链路、控制推理成本。推理引擎的质量直接决定了Agent的智能水平。 (2 )记忆系统,记忆系统赋予Agent“学习”和“成长”的能力。可以简单分为短期记忆和长期记忆两个大类:短期记忆维护当前会话的上下文状态,类似于人类的工作记忆;长期记忆存储用户偏好、历史交互、知识积累等信息,需要智能的信息抽取和压缩机制。在开发实践中,我们需要设计合理的存储架构、实现高效的检索算法、建立智能的信息更新策略。 (3 )编排模块,规划与执行模块负责协调其他三个组件的工作,管理Agent的整体执行流程。它承担任务分解、执行计划制定、工具调用编排等职责。在开发层面,这涉及到工作流设计、异常处理策略、并发控制、状态管理等技术挑战。不同的Agent框架对这一模块有不同的实现方式,如Strands Agents的任务编排器、LangGraph的图执行器等。 (4 )工具接口,工具接口是Agent与外部世界交互的“手脚”。一个Agent可能需要调用数十种不同的API、数据库、外部服务。开发挑战在于:如何标准化不同工具的接入方式、如何实现工具的智能选择和组合、如何处理工具调用的异常和重试、如何确保工具调用的安全性和权限控制。 为了保障 Agent 能顺利从原型转变到生产,我们还需要使用如下的支撑服务模块: 质量评估,Agent的智能行为需要专门的评估机制,包括推理质量评估、任务完成率统计、用户满意度收集等。例如可以基于LLM-as-a-Judge自动化评估结合人工审核,建立持续的质量保证体系。 身份认证与授权,Agent系统需要解决”谁可以访问Agent”和”Agent可以访问哪些资源”的双重身份问题。这包括用户身份验证、会话级身份隔离、细粒度权限控制、跨系统授权等。在多租户环境中,还需要确保不同用户的Agent会话在独立的安全沙箱中运行。 安全与隐私保护,基于OWASP Agentic AI威胁模型,Agent系统面临记忆投毒、工具滥用、权限滥用、身份欺骗等多种安全威胁。开发时需要实施分层防护策略,在用户输入、模型推理、工具调用、输出生成等各个环节建立独立的安全过滤机制。 可观测性,Agent的非确定性行为要求全新的监控方式。我们需要追踪推理链路、监控工具调用合理性、分析 记忆 使用情况、检测安全事件、收集用户体验指标。这种”思维过程”的可视化对于调试和优化Agent行为至关重要。

将上述开发和生产需求抽象出来,形成Agentic AI基础设施的单元,如图所示:

图1 – Agent系统架构与基础设施单元

1.1 统一的运行时

在实际部署中,Agent应用运行时和Agent工具运行时是整个系统的核心。它们需要提供兼容各种开发框架的服务接口,并在Agent业务价值尚未明确的情况下,能够动态调整资源以最大限度地节省成本。此外,我们需要考虑几个关键因素:

(1 )会话管理。Agent的会话隔离机制和鉴权方式实现身份管理和隔离确保了多用户环境下的安全性。每个用户的Agent会话都在独立的安全沙箱中运行,避免了数据泄露和交叉污染的风险。 (2 )生命周期管理。Agent的会话状态会因模型调用、服务等待等因素充满着不确定性,运行时能够根据业务需求来调整状态转换的策略。对于有状态的业务,需要将状态信息持久化,确保在系统重启或故障恢复时能够正确恢复Agent的工作状态。 (3 )接口标准化。通过脚手架,运行时被变成对外的HTTP服务,根据Agent类型分配不同端口和路径,支持健康检查。这种标准化的接口设计让Agent可以轻松地集成到现有的基础设施中。

1.2 统一的工具接入和管理

工具网关(Gateway)是解决工具生态管理问题的关键组件。它不仅需要支持已有的标准化API、MCP协议或轻量级服务集成等接入功能,还需要提供工具发现、删除、鉴权等相关能力,方便开发者更加便捷地管理和维护工具列表。

其中,工具的快速搜索功能至关重要。当Agent面对复杂的用户请求时,网关的检索能力使其无需列出和读取所有工具,而是能够根据问题动态地发现和筛选出最合适的工具子集。这种搜索功能不仅减少了返回的工具数量,还提升了上下文相关性和处理速度,同时降低了成本。这对于控制Agent的运行成本尤为重要。

1.3 统一的记忆单元

记忆模块是Agent智能化的核心要素。它能够通过收集用户对话信息,深入了解用户的偏好、兴趣、关注点以及历史事件等内容。这些信息作为当前会话的上下文,不仅提升了Agent回答的准确性,还使其能够更好地满足用户的个性化需求。

记忆的存储架构通常采用分层设计:短期记忆用于保存原始数据,以便在当前会话中查询历史消息;长期记忆则通过异步方式对对话历史进行加工,抽取语义事实、用户偏好和内容摘要等信息。这种设计不仅保证了实时性能,还提供了长期的智能化能力。在实际生产环境中,我们还需特别关注记忆的安全性和隔离性。每个用户的记忆数据应存储在独立的命名空间中,以防止数据泄露。此外,建立完善的数据备份和恢复机制,确保重要的用户偏好和历史信息不会丢失,也是至关重要的。

1.4 统一的通用基础工具

在构建 Agent 应用时,浏览器和代码解析器是两项不可或缺的工具。简单来说,浏览器工具让 Agent 能“看网页、操作网页”,实现对非 API 系统的直接操作;而代码解析器让 Agent 能“运行代码、算得更精”,胜任数据处理和复杂计算任务。

浏览器往往需要一个完全托管的浏览器沙箱环境(Sandbox),让Agent能够像人类那样“浏览网页”。点击按钮、填写表单、解析动态内容、抓取图像或执行页面导航等,这些往往是在隔离、安全、可监控的沙盒中进行。企业借此可绕过缺少 API 的系统,自动化处理诸如填报内部表单、跨系统数据抓取、网页内容监测等任务,同时还具备回放能力。 代码解析器则让 Agent 获得运行程序能力,它通过提供一个沙箱环境,可安全地让 Agent 调试并执行基础模型动态生成的代码,并能处理大规模数据、生成可视化分析、执行复杂计算任务。在企业场景中,这意味着 Agent 不再局限于文本推理,而可以亲自“动手”执行多步数据流程、处理 CSV/JSON/Excel 数据、绘制图表、执行机器学习分析等。

1.5 统一的认证与鉴权机制和安全防护

在构建Agent应用时,身份认证是整个安全体系的核心基石,直接影响系统在企业级场景下的稳定和安全运行。身份管理组件需要支持与多种身份提供商(IdP)集成,如GitHub、社交媒体账户以及遵循标准认证协议的企业级身份管理系统(如Okta)。此外,开发者应能配置多维度的认证规则,包括入站和出站的双向认证机制:入站认证确保只有合法授权的用户或系统能够访问Agent应用,而出站认证则保障Agent在调用外部工具或资源时能够通过安全的认证回调完成授权。这种双向认证机制不仅防止未授权访问,还确保了Agent在跨系统交互时的合规性与安全性。

在Agent输出内容的安全方面,仍需通过安全防护机制(如Guardrails)来确保大模型在引导Agent完成任务时,不受到严重的幻觉影响,也不提供非法或不合规的内容。这要求在模型本身的安全防控上,需要增加额外的规则和策略,以判断Agent的思考和执行是否合法,是否符合业务规则要求。

1.6 统一的可观测性

由于大语言模型会引入思考、执行和输出的多种不确定性,Agent应用在开发、调试和落地环节中,需要一个多层次的监控体系。在基础设施层,需要追踪Agent运行环境的资源使用情况;在应用层,重点监控Agent的性能表现和调用链路;在业务层,则需关注用户体验和任务完成情况。下一章节的AgentOps将重点展开这些方面的讨论。

有了以上架构支撑,Agent开发者可以更快速地将CI/CD流水线与Agentic AI基础设施单元集成,实现从应用逻辑开发到生产部署的快速上线和产品迭代。

图2 – Agentic AI 应用的CI/CD流程

Agent应用需要基于多种核心功能模块的协作,同时依赖多个支撑服务模块来提供生产级保障。Agent的非确定性行为和上下文依赖性等特性,对传统开发工具链带来了新的挑战。我们需要重新构建包括上下文工程、记忆管理、工具集成和行为调试在内的全新工具体系。这些范式转变也为接下来探讨的AgentOps体系奠定了基础。

2、从DevOps到AgentOps:运维复杂性的新挑战

2.1 生成式 AI 中有哪些 Ops

DevOps 实现了高效地管理

确定性系统,相同的输入通常会产生可预期的输出。其监控重点、部署流程也相对标准化,我们可以通过明确的错误堆栈和日志快速定位问题。在 MLOps 时代引入了不确定性,模型的性能会随时间衰减,需要持续的数据反馈,也要管理数据集、模型权重、超参数等。AI Agent 应用不仅具有非确定性体现在它们展现出的“智能行为”:Agent 能 自主决策、调用外部工具或 API 并持续演化,这对 可复现性、成本、合规性 提出了更高要求。

图3 – 生成式 AI 中的 Ops 及其关系

在生成式AI时代,根据业务场景的不同特点,我们可以将运维划分为两大主要方向:

1 )基础模型开发场景,主要聚焦于模型本身的生命周期管理,这里的核心是FMOps(Foundation Model Operations),其涵盖了从模型训练、优化到部署的全流程运维。LLMOps作为其中最重要的分支,专门处理大语言模型的特殊需求,如分布式训练、推理优化、模型版本管理等。 2 )生成式AI 应用开发场景,我们看到了几个专业化的实践领域正在快速迭代发展: PromptOps 专注于提示词工程的运维化,包括提示词模板的版本管理、A/B测试、效果评估和持续优化;RAGOps

AgentOps 是将 DevOps/MLOps 能力扩展到 Agent 系统的一套运维范式,旨在保证 Agent 在 开发、测试/预发布、生产等各阶段都可靠、安全、高效。核心支柱包括:设计/原型验证、与运行平台的集成以便于供应与扩缩、全面可观测性、严格测试/验证,以及持续的反馈回路。

2.2 AgentOps 的技术需求

这里我们聚焦 Agent 运维(AgentOps)层面的技术需求,把基础设施单元放进全生命周期(开发 / 测试 / 生产)管理、部署与自动化的角度来具体化,包括 Agent 及周边工具开发构建、测试、发布、监控、安全、回滚等关键运维要点。

在 Agent 及 MCP 服务构建阶段,我们需要考虑到:

运行环境兼容性及灵活性,可以将 Agent、工具打包为镜像或函数,以保证一致性与隔离性。运行时负责拉取镜像、注入配置、加载模型与工具; 会话隔离,在多租户环境中,我们需要确保每个会话都在独立的安全环境中运行,防止数据泄露和交叉污染; 标准化接口,将端口&路径配置、健康检查接口和API参数格式标准化,可以实现新Agent开发和已有Agent改造接入的一致性体验,提高接入效率; 部署自动化,通过IaC服务(如 CDK / Terraform / Helm),并结合 CI/CD 流水线自动化创建基础网络、运行时、密钥等资源,确保开发/测试/生成环境能被可重复地供应; 全周期的可观测性,每个实例启动时即注入日志/Tracing 埋点,保证会话从一开始就可追踪与回放。 标准化记忆生产流程:记忆系统在生产环境中面临的核心挑战是如何从非结构化的对话数据中稳定、准确地提取有价值的信息。在设计 AgentOps 平台时,需要考虑到 标准化的记忆生产模板,为了避免每个业务团队重复开发记忆抽取逻辑,需要建立标准化的记忆生产模板。这些模板基于 LLM 配合精心设计的提示词,能够自动识别和抽取特定类型的信息; 提供自定义抽取能力,不同业务场景对记忆内容有显著差异,需要允许不同的业务根据需求自定义记忆抽取及查询逻辑。

关注

版本化管理,代码、模型及使用的提示词、配置与工具映射、记忆抽取模块应统一纳入版本控制(Git),并为每个发布打标签; CI/CD 自动化,流水线负责构建镜像、运行单元/集成/安全测试、部署到预发布并执行烟雾测试;推向生产前支持金丝雀或蓝绿发布策略; 提示词与配置即代码,提示词也像代码一样支持 diff、回滚与审查,以便在发现逻辑/合规问题时能迅速恢复到已验证版本; 快速回滚能力,保持镜像与模型的历史版本,CI/CD 支持一键回滚并伴随会话回放供事后分析。

建立

多层次观测,基础设施层(如 CPU、内存、网络等);应用/运行时层(如请求/响应延迟、模型调用次数与成本);业务层(如推理链路、任务完成率、异常率等)。也要支持 细粒度轨迹与会话回放:记录每一步输入、中间状态(上下文)、外部工具/API输入输出、模型响应与最终输出,支持重放与根因分析; 统一语义与 Trace 标注:采用统一的 Trace/Span 约定(将 agent-id、session-id、operation-type 等嵌入到 trace),便于跨 Agent 的关联分析; 实时告警与自动化响应:基于阈值/异常检测触发告警,并可以触发自动限流、降级或重启策略。

要保证

最小权限与短期凭证,避免长期共享密钥,CI/CD 作为凭证下发与审计点,运维侧对凭证生命周期实施策略化管理;控制入站和出站访问,以实现控制 谁可以访问 Agent 、Agent 可以访问哪些资源。对于外部访问,可以通过网络规则或代理限制,例如仅允许受控 API并记录所有外呼以供审计。 安全护栏( Guardrails )与输出过滤,在模型与 Agent / 工具层加入护栏,避免记忆投毒、工具滥用、模型幻觉、敏感信息外泄或违法输出等; 流水线合规,在 CI/CD 中加入安全/合规扫描(提示词注入检测、依赖漏洞、配置泄露),并在发布前强制通过治理检查。 管理密钥,通过专用安全存储服务来提供运行时凭证,并仅在运行时注入到容器中并限定生命周期。

部署阶段考虑采用金丝雀、蓝绿或 A/B 流量切换,先在小流量或影子流量中验证新版本;并可以

基于指标的切换 / 回退:用可观测性指标与用户反馈驱动发布决策,若指标恶化则自动回滚; 提示词可回退,提示词变更要可审计,保持历史版本便于快速恢复。

接下来,我们讨论如何根据不同客户画像构建 AgentOps 平台。

3、构建 AgentOps 平台

在明确 AgentOps 与传统 DevOps/MLOps 的差异之后,企业在真正落地平台时往往面临两类典型需求:一是

具备成熟研发与运维体系的中大型组织,希望在安全合规、可观测性、版本治理等方面实现深度定制与长期演进;二是 初创或业务团队,更关注 快速验证价值与低成本上线

针对这两种诉求,我们提出两条建设路径:

以平台工程为核心的可扩展平台,强调统一治理、强可控性和深度集成,适合已有平台团队、需要长期演进和严格合规的企业; 轻量托管 / Serverless 快速落地方案,聚焦敏捷交付和弹性扩容,适合资源有限的小团队、PoC 项目或对基础设施依赖较低的业务单元。两种方案并无绝对优劣之分,而是面向 不同组织规模、治理需求的差异化选择。

3.1 以平台工程为核心的可扩展平台

平台工程(

Platform Engineering)是一门设计和构建工具链和工作流程的学科,其核心理念是通过抽象复杂性、标准化流程、提供自助服务能力来提升开发者体验和生产力。

图 4 – 平台工程的构成

可以借鉴内部开发者平台(IDP)理念,将 AgentOps 能力集成到一个统一平台中,提升开发者体验和运维效率。核心模块包括:

开发者门户与治理:提供自助式门户,统一管理 Agent 及其组件。实现提示词/模型/工具注册与版本管理、权限控制和合规审查。对常用模板、最佳实践进行封装,帮助开发者快速上手。 CI/CD 与交付流水线:集成持续集成/持续交付工具(如 Jenkins、GitLab CI、GitHub Actions),支持 Agent 代码和配置的自动化测试、打包、部署。流水线中包含注册容器到仓库、提示词校验、Agent 效果评估、单元测试、人工审核等步骤。 统一运行时环境:采用容器化技术(如 Docker、Kubernetes)提供可伸缩的执行环境。所有 Agent 以容器形式运行,实现资源隔离和弹性伸缩。 观测与日志系统:嵌入丰富的监控、日志和链路追踪能力。包括捕获模型调用日志、提示词、工具调用、内存上下文和推理中间步骤等。使用 Prometheus/Grafana、ELK/Fluentd 或商业监控平台集中采集与分析,实时监控延迟、错误率、成本、用户满意度等指标。 安全凭据与策略:提供集中化密钥和凭据管理(如 AWS Secrets Manager),对敏感数据和第三方 API 调用进行鉴权审计。配合统一的安全策略和合规扫描(如静态代码扫描、提示词注入检查)确保平台安全。模型安全护栏可以使用托管的服务,例如 Bedrock Guardrails 审核输入、输出,结合内部知识库避免模型幻觉的影响。

3.2 轻量托管服务/Serverless 快速落地

此方案面向小团队或 PoC,追求快速上线和低成本运营。思路是充分利用云服务托管服务,减少基础设施依赖。核心要点包括:

Serverless 运行环境:这里的环境选择较为多样。选择1)借助专门针对 Agent 场景优化的云托管服务(如 Amazon Bedrock AgentCore),将 Agent 打包为容器并通过托管服务快速构建;选择2)将 Agent 逻辑封装为云函数(如 AWS Lambda 服务)按事件触发执行;选择3)Amazon ECS Fargate 服务,同样是将 Agent 打包为容器,借助 ECS Fargate + ELB 对外提供服务。这几种选择都可以借助托管服务内置的扩缩容能力,避免自建集群,AgentCore 更适合 Agent 及 MCP 服务,后两个更适合需要更高自定义的场景。 托管模型服务与工具:直接调用 LLM API(如 Amazon Bedrock),工具则同样可以采用上述Serverless方式部署,其中,AgentCore 也专门提供 Gateway 模块快速将内部或者三方 API 转为 MCP 服务供 Agent 使用。 简易 CI/CD:通过 GitHub Actions、GitLab CI、AWS CodePipeline 等轻量流水线将代码部署到 Lambda / ECS Fargate,可快速迭代 Agent 功能。 监控和日志:使用云服务提供的监控(如 CloudWatch)和日志服务。配合第三方可观察性工具(Datadog、Sentry 等)抓取错误和性能数据,不必自建 ELK/Grafana。 安全与凭据:利用云平台的身份和访问管理(IAM)控制函数和服务权限。凭证存储可使用 Secrets Manager 等托管方案,即可实现企业级的安全保障。模型安全护栏的选型思路同上。

3.3 两种方案的适用建议与对比

对于

初创团队、小团队或 PoC,强调快速上线和成本控制,可在不投入大量基础设施前提下验证业务模型,可以优先采用托管服务或者 Serverless 的服务。对于已有成熟平台工程团队、追求高可定制性、需严格合规治理的企业,可以基于 IDP 的理念构建,优势在于高度可定制和治理能力强,适合大型企业或复杂业务场景,但前期投入和团队要求较高。通过平台工程思路,团队可以将 AgentOps 各类能力产品化,也建议结合业务GTM的时效性诉求选择复用托管服务已有能力快速构建。

表1 – 两种 AgentOps 方案对比

|

对比因素 |

平台工程式可扩展平台 |

轻量托管/Serverless 方案

|

架构模式 |自建内部开发者平台(IDP),高度定制化

|云托管服务、函数计算,模块化、即插即用

|

技术复杂度 |高:需要管理基础设施、集成 CI/CD、监控、安全等

|低:主要使用云函数、托管模型服务、托管数据库

|

部署速度 |慢:需设计和测试完整流水线

|快:托管服务、云函数秒级部署,快速上线

|

成本投入 |高:初期需投资平台建设,人员成本较高

|低:主要按量付费,无需自建基础设施

|

扩展能力 |强:可根据需求横向扩展平台组件和集群

|弹性:云服务自动扩容,适应负载波动

|

治理与合规 |完整:支持统一策略、版本审计、安全审查

|简化:基于云服务安全机制,需额外关注配置权限

|

自定义能力 |强:完全自主,满足特殊需求

|中:基于托管服务能力和配置

|

运维要求 |高:需专业团队维护平台稳定

|低:主要关注监控告警和成本优化

4、在亚马逊云上构建“生产就绪”的Agent应用

目前,构建能够可靠执行复杂任务的Agent应用变得日益便捷,这主要归功于多种开源Agent开发框架,如Strands Agents、CrewAI、LangGraph和LlamaIndex等。然而,基于这些框架开发的Agent距离“生产就绪”状态仍存在显著差距。正如前文所述,运行时环境、记忆模块、浏览器、代码解析器、安全防护机制、认证鉴权系统、工具管理平台、可观测性以及AgentOps平台构建等,对Agent开发者而言不直接创造业务价值,却是部署生产环境的“必需品”。因此,在竞争激烈的Agent市场中,越来越多开发者选择云端专业Agent基础设施提供的托管功能,加速开发进程,将精力集中在提升Agent业务价值上,以更好地满足用户需求。

亚马逊云科技在Agent开发领域提供了最全面而深入的产品支持,从包含各类底层算力的加速芯片、到托管的机器学习平台Amazon SageMaker,再到Agent基础模型调用和平台服务Amazon Bedrock、Agent开发SDK Strands Agents,以及面向垂类应用场景的Agent软件服务等,端到端地为各类开发者提供专业的服务。

图5 – 亚马逊云科技Agent技术栈

其中,Amazon Bedrock AgentCore是一款业界领先的专为Agent应用打造的基础设施服务。它依托亚马逊云科技多年沉淀的强大基础能力,提供安全、弹性、高可用和免运维等一系列Agent必备组件,使开发者能便捷构建完整的”生产就绪”Agent应用。

图6 – Amazon Bedrock AgentCore能力模块及架构

Amazon Bedrock AgentCore 包含了七大单元支撑Agent 应用由开发转生产: AgentCore 运行时:提供了低延迟的无服务器环境,用于部署Agent或MCP工具。该环境具备会话隔离功能,支持各类Agent框架,包括流行的开源框架(如Strands Agents、LangGraph、CrewAI等)。此外,它能够集成各种工具和模型,并有效处理多模态工作负载及长时间运行的Agent应用。 AgentCore 记忆:管理短期和长期记忆,为模型提供相关上下文,同时帮助Agent从过去的交互中学习历史知识。 AgentCore 浏览器:提供完全托管的Web浏览器工具,以扩展Agent基于Web的自动化工作流程。 AgentCore 代码解释器:提供一个隔离环境来运行Agent生成的代码,即需即用。 AgentCore 身份管理:使Agent应用能够安全访问AWS服务和第三方工具及服务,如GitHub、Salesforce和Slack,可以代表用户或在预授权用户同意的情况下自行操作。 AgentCore 工具网关:将现有API和Amazon Lambda函数转换为Agent随时可用的工具,提供跨协议的统一访问,包括MCP,以及工具快速检索等功能。 AgentCore 可观测性:提供Agent执行过程的逐步可视化功能,包括元数据标记、自定义评分、轨迹检查以及故障排除/调试过滤器等。

这七大单元共同构成了Agent应用生产的支撑体系,通过提供全面的企业级服务,使Agent开发者能够利用任意框架和模型,快速、安全地部署和运营大规模Agent应用。关于每个模块的更多细节,请参见本博客系列中的相应文章。

基于Bedrock AgentCore进行AgentOps实践时,可以很方便地实现CI/CD、运行时治理、可观测性、工具接入与记忆管理及隔离等模块的协作。具体来说,可以将CodePipeline作为流水线骨架:Agent代码提交后触发镜像构建,基于运行时的镜像版本与AgentCore的版本策略自动生成可回溯的部署单元,避免“模型升级”或“镜像漂移”带来的环境不一致问题。部署的 Agent 实例可选择接入 CloudWatch,或结合 LangSmith 等三方工具,让每一次调用的延迟、错误率、上下文链路都能被实时捕捉与回放。这种全链路观测能力为后续迭代提供了可靠的反馈回路,使 Agent 性能优化不再仅仅依靠临时的线下排查。

此外,记忆可以采用基于AgentCore记忆模块命名空间(Namespace)的隔离策略,每个环境、租户或会话拥有独立命名空间,既保证隐私合规,又方便按环境维度进行调试和回滚。所有记忆访问行为均被打点写入观测平台,既可追责也可做趋势分析。工具生态通过AgentCore Gateway统一管理,开发者只需注册OpenAPI或第三方API(如Jira、Brave等),即可被Agent发现和调用,无需在代码中硬编码接口地址。Gateway同时支持权限分级与调用审计,使工具治理与安全防护自然融入平台主干。

结语

随着基础模型能力的快速提升和Agent开发框架的日趋成熟,构建智能Agent的技术门槛正在快速降低。然而,真正的挑战不在于Agent本身的开发,而在于如何让这些智能体在生产环境中稳定、安全、可靠地运行。企业和开发者应该将宝贵的时间和精力投入到核心业务逻辑的创新上:理解用户需求、优化业务流程、提升服务体验,而不是被基础设施的复杂性所困扰。这也是Amazon Bedrock AgentCore 平台存在的价值所在:通过提供标准化的运行时环境、统一的工具管理、智能的记忆系统和全面的安全防护,让Agent应用开发变得像传统应用开发一样简单和可预期。在运维自动化上,结合自身当前的业务诉求、状态选择合适的 AgentOps 平台落地的路线,让 Agent 获得全生命周期的可靠、安全及高效保障。

关于Agentic AI** **基础设施的更多实践经验参考,欢迎点击:

Agentic AI基础设施实践经验系列(一):Agent应用开发与落地实践思考

Agentic AI基础设施实践经验系列(二):专用沙盒环境的必要性与实践方案

Agentic AI基础设施实践经验系列(三):Agent记忆模块的最佳实践

Agentic AI基础设施实践经验系列(四):MCP服务器从本地到云端的部署演进

Agentic AI基础设施实践经验系列(五):Agent应用系统中的身份认证与授权管理

Agentic AI基础设施实践经验系列(六):Agent质量评估

Agentic AI基础设施实践经验系列(七):可观测性在Agent应用的挑战与实践

Agentic AI基础设施实践经验系列(八):Agent应用的隐私和安全

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


阿尔特携手 Amazon AgentCore ,打造懂你的AI,智能搜索成本降低34%

AWS账单代付阅读(61)

亚马逊AWS官方博客

阿尔特携手 Amazon AgentCore ,打造懂你的AI,智能搜索成本降低34%

关于** **Monus AI

Monus AI是由南京阿尔特科技推出的一款专注于消费决策的AI搜索应用,在搜索垂类工具中表现领先。该产品核心功能包括规格级比价、虚假软广识别、商品对比和智能对话,致力于在购物前为用户提供高效、可信的决策支持。通过6大智能体体系和返利体系,Monus AI不仅帮助用户省钱,还能让用户在消费过程中“赚钱”。无论是搜索“程序员AI开发电脑”还是查询“Pampers湿纸巾最低价”,它都始终围绕“信任+效率”重塑消费搜索体验。

什么是** ** Amazon Bedrock AgentCore** **?

Amazon Bedrock AgentCore 提供专为Agent工作负载构建的基础设施、可增强Agent功能的强大工具,以及适用于现实部署场景的基础组件。AgentCore 服务可以组合使用,也可以单独使用。该服务兼容多种Agent框架(包括 CrewAI、LangGraph、LlamaIndex 和 Strands Agents 等),并支持 Amazon Bedrock提供的多种模型,为 Agent 带来极大的灵活性。AgentCore 消除了构建专用Agent基础设施时千篇一律的繁重工作,可以加快 Agent 从研发进入生产的过程。

场景挑战

在电商AI搜索领域,用户和系统面临多重核心挑战,特别是需求表达与匹配的断层。具体挑战包括:

(1)用户不同购买决策时期的识别

用户在购物过程中,处于不同的购买决策期,需求和关注点差异显著。多模态输入(文字、语音、图片)的准确理解及决策时期判别至关重要。需求萌芽期的用户更需要全面的指导和信息,帮助形成购买意向;而决策后期的用户则更加关注优惠促销和售后保障。对这些时期的精准识别能够实现针对性服务和优化用户体验。

(2)多平台商品规格同义不同名问题

跨平台商品信息孤立,用户需在不同电商平台间切换对比价格和评价,且常遭遇虚假软广和冗余信息扰乱,筛选有效信息耗时且低效。更复杂的是,不同平台采用各自独特的商品规格命名规则,导致“同义不同名”现象普遍存在,严重阻碍了规格级颗粒度的实时比价和精准匹配,给系统带来了极大挑战。

(3)用户画像与商品推理匹配度不足

传统推荐系统主要依赖用户的行为数据进行相似商品推荐,泛化能力和关联推理能力有限,难以有效捕获用户日常生活中的跨品类兴趣和潜在需求。这导致推荐结果同质化严重,无法做到用户需求的深度理解和精准满足,影响用户满意度和转化率。

针对上述挑战,电商AI搜索系统需具备精准的决策期识别能力,高效处理跨平台异构商品数据,并强化用户画像与商品间的智能推理匹配能力,才能提供真正个性化、连贯且高效的消费决策支持。

解决方案

Monus AI采用自研的多模态融合输入技术,可同时高效处理文字、语音、图片三种类型的用户输入,打破传统搜索的输入局限。更具创新性的是,系统引入 “消费决策时期判断” 机制,通过深度学习模型分析用户输入的语义特征与情感倾向,能准确识别用户当前处于需求萌芽、信息收集还是购买决策阶段,该判断的匹配度高达 94%,为后续精准服务奠定基础。

第一级:决策洞察智能体体系– 深度结合 AgentCore Memory 基于 *UserPreferenceMemory* *策略*存储的用户偏好数据,实时分析用户搜索请求的复杂度,同时判断用户决策的紧迫性,为后续处理流程设定优先级。 第二级:智能匹配智能体体系– 基于用户历史购物偏好、浏览记录等数据,动态调整商品与搜索内容的匹配权重,确保优先呈现与用户需求高度契合的信息。 第三级:语义压缩智能体体系– 采用先进的语义编码算法,在保留 98% 核心商品信息完整性的前提下,将数据处理速度提升 3 倍,同时使整体处理成本降低 80%,实现效率与成本的双重优化。 第四级:数据融合智能体体系– 运用自研的多源数据清洗算法,对来自不同电商平台的商品数据进行处理,噪音过滤率达到 87%,有效解决了跨平台商品信息孤岛问题,为用户提供统一、准确的信息视图。 第五级:个性推荐智能体体系– 深度融合 AgentCore Memory 的用户数据,摒弃传统机械的推荐方式,采用拟人化导购的交互形式,进行情感化推荐排序,让推荐结果更贴合用户个性化需求与购物习惯。

多级智能体体系通过用户偏好分析、精准匹配、效率优化等维度构建了核心能力,在这一体系运行框架下,通过以下关键技术点,实现效率与质量的双重提升:

智能分解– AI 自动将用户提出的复杂需求(如 “推荐一款适合大学生用、预算 5000 元以内、能运行设计软件的笔记本”)拆解为多个可并行处理的子任务,如 “大学生使用场景分析”“预算筛选”“软件运行需求匹配” 等。 并行路由– 多个 Agent 同时针对不同维度的子任务进行处理,避免串行处理的等待时间,使系统响应时间缩短 60%,大幅提升用户体验。 记忆融合– 基于 Strands Agents 调用 AgentCore Memory 中的用户历史数据,对各 Agent 处理后的结果进行个性化答案整合,确保最终呈现给用户的搜索结果完全符合其独特偏好与需求。

通过上述技术架构与流程设计,Monus AI 实现了从 “单一搜索工具” 到 “专属购物伙伴” 的根本性转变。如今,用户无需在重复搜索中反复描述需求,AI 能够精准理解需求的上下文演进过程,为用户提供具备连续性的个性化服务体验。这一技术架构不仅彻底解决了传统 AI 搜索存在的记忆缺失、推荐同质化等问题,更开创了电商 AI 领域的全新服务范式,为行业树立了技术与体验双重领先的标杆。

效果评估

基于AgentCore Memory和Strands Agent协同架构,Monus AI实现了跨越式提升,AI 搜索优化 具体表现如下:

|

维度 |

指标定义 |

基线表现 |

优化后表现 |

性能提升

|输入输出比

|输入与输出Token的比值

|12:1

|15:1

|提升 25%

|单次查询Token消耗量

|每次请求的总Token开销

|22,000

|15,000

|减少 31.8%

|单次搜索成本

|单用户的每次搜索成本

|$0.09

|0.056

|降低34.8%

|搜索准确率

|基于AgentCore Memory用户画像,增强匹配精准度

|约 57%

|92%

|提升35%

依托 AgentCore Memory 长期记忆的技术优势,不仅显著加快 Agent 开发进程,更在实际应用中实现多重价值:基于用户画像的智能搜索 Token 用量大幅减少,同时搜索结果准确率有效提升,为 Monus AI 在技术竞争力与成本效益层面提供了跨越式突破。

总结

阿尔特科技与亚马逊云科技的技术合作,不仅是 “任务编排框架 + 记忆服务” 与电商场景的深度融合,更给出了 “AI 如何真正懂用户、服务用户” 的清晰答案。其以 Strands Agents能力为 “骨架”,以 AgentCore Memory 的记忆功能为 “大脑”,搭配大小模型协同、语义共识引擎等技术,找到了当前电商 AI 搜索的最优实现路径,体现对 AI 技术本质的深刻理解与实践智慧。正如阿尔特科技团队所言:“创业不是一份工作,是热爱、坚持与智慧成长的过程。” 此次通过技术创新,不仅验证了 AI 在电商领域的巨大商业潜力,更为行业提供了 “框架 + 记忆” 双核心驱动的可复制、可扩展实践范式,为电商 AI 搜索的发展注入新动能。

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


AMI产品在亚马逊云科技 Marketplace 上的定价模式及系统集成

AWS账单代付阅读(67)

亚马逊AWS官方博客

AMI产品在亚马逊云科技 Marketplace 上的定价模式及系统集成

引言

随着云计算的普及,越来越多的软件供应商选择通过亚马逊云科技 Marketplace(AWS Marketplace)来分发和销售他们的产品。作为一个全球性的数字目录,AWS Marketplace 使客户能够轻松地查找、购买、部署和管理第三方软件和服务。对于软件供应商而言,AWS Marketplace 提供了接触全球客户的机会,同时简化了计费和收款流程。

在 AWS Marketplace 上,Amazon Machine Image (AMI) 是一种常见的产品交付形式。AMI 是一种预配置的虚拟机镜像,包含操作系统和预装的软件,可用于启动 Amazon EC2 实例。本文将深入探讨 AMI 产品在 AWS Marketplace 上的各种定价模式以及系统集成方案,帮助软件供应商更好地理解如何在 AWS Marketplace 上优化其产品策略。

AMI 产品概述

什么是 AMI 产品?

AMI(Amazon Machine Image)产品是在 AWS Marketplace 上提供的一种软件交付方式,它允许卖家将其软件预装在虚拟机镜像中,买家可以直接在 Amazon EC2 上启动这些镜像。AMI 产品可以是单一 AMI 产品,也可以是包含CloudFormation模板的单一 AMI 产品。

*备注:如果您的解决方案需要从多个不同的源 AMI 部署实例,则必须将所有功能打包到单个 AMI 中。当您的买家部署 AMI 时,无论是在部署说明还是部署模板中,请将实例配置为作为不同的组件运行。

AMI 产品的优势

对于卖家而言,AMI 产品提供了以下优势:

  • 简化部署:客户可以快速启动预配置的实例,无需复杂的安装和配置步骤
  • 灵活的定价模式:支持多种定价策略,包括按小时计费、按年计费、自定义计量等
  • 广泛的客户覆盖:通过 AWS Marketplace 接触全球客户群体
  • 自动化计费:AWS 处理计费和收款,简化财务管理
  • 安全合规:利用 AWS 的安全基础设施和合规认证

对于买家而言,AMI 产品的优势包括:

  • 快速部署:一键启动预配置的软件环境
  • 简化采购:通过现有的 AWS 账单支付软件费用
  • 可靠性:软件运行在 AWS 基础设施上,享受高可用性和可扩展性
  • 集成性:与其他 AWS 服务无缝集成
  • AMI产品发布流程

上架前准备清单

  • 产品信息:
  • 详细准确的产品描述
  • 高质量的产品图片和图标
  • 清晰的使用说明和文档
  • 支持联系信息
  • 技术要求:
  • AMI 必须能在所有支持的 AWS 区域正常工作
  • 软件必须能在指定的实例类型上运行
  • 必须支持 AWS Marketplace 的计量和许可机制
  • 合规性要求:
  • 遵守 AWS Marketplace 的条款和条件
  • 符合适用的法律法规
  • 实施适当的数据保护措施
  • 提供明确的隐私政策和服务条款

选择定价模式

选择合适的定价模式时,请考虑以下因素:

  • 客户使用模式:客户是持续使用还是间歇性使用?
  • 持续使用:考虑月度固定价格或年度订阅
  • 间歇性使用:考虑按小时计费或自定义计量
  • 价值衡量标准:产品价值是基于什么?
  • 基于时间:按小时或月度计费
  • 基于资源使用量:自定义计量定价
  • 基于功能:合同定价或BYOL
  • 目标客户群体:
  • 企业客户:合同定价、BYOL或年度订阅
  • 小型用户:按小时计费或月度固定价格
  • 多样化客户群:混合定价模式
  • 现有客户基础:
  • 有大量现有许可客户:优先考虑BYOL
  • 新市场拓展:考虑免费模式或按小时计费
  • 竞争环境:
  • 分析竞争对手的定价策略
  • 考虑如何通过定价创造竞争优势
  • 运营复杂性:
  • 评估技术能力和资源
  • 自定义计量和合同定价需要更多的技术集成

发布流程

AMI产品在AWS Marketplace上的发布遵循一个结构化的流程,从准备阶段到最终上线。以下是一个通用的AMI产品发布流程概述:

  • 准备AMI (Prepare AMI):在AWS卖家账户中创建符合AWS Marketplace要求的亚马逊机器映像,包含产品软件和必要配置。

步骤:选择基础AMI(Amazon Linux 2或Ubuntu等) → 启动EC2实例 → 安装和配置产品软件 → 安装AWS CloudFormation helper脚本和SSM Agent → 实施产品计量机制(如适用) → 移除SSH密钥和授权文件 → 清理历史记录和日志 → 创建AMI → 设置AMI共享权限 → 使用AMI Copy验证跨区域可用性

  • 扫描AMI (Scan AMI):提交AMI进行自动安全扫描,确保符合AWS安全标准和最佳实践。

步骤:在AWS Marketplace管理控制台选择”AMI扫描” → 输入AMI ID和AWS区域 → 提交扫描请求 → 系统检查常见漏洞和暴露(CVE) → 验证操作系统补丁级别 → 等待扫描结果(通常24小时内) → 解决任何发现的问题 → 必要时重新扫描

  • 提交元数据 (Submits metadata):根据产品定价模型(按小时、自定义计量单位或预付费)提供详细产品信息。

步骤:在AWS Marketplace管理控制台创建产品 → 选择适当的定价模型(按小时、自定义单位或预付费) → 填写产品名称和详细描述 → 上传产品徽标和截图 → 设置定价信息(小时费率/自定义单位/预付金额) → 定义实例类型支持 → 配置区域可用性 → 提供使用说明和支持信息

  • 审核 (Review):AWS Marketplace团队审核所有提交的内容,确保符合技术和内容标准。
  • 受限发布 (Limited Listing):产品进入受限发布状态,仅对卖家账户和指定测试账户可见。
  • 卖家测试 (Test by Seller):卖家验证产品在Marketplace环境中的完整功能、计费和用户体验。

步骤:访问限制性产品页面 → 测试订阅流程 → 启动产品实例 → 验证软件功能 → 测试特定定价模型(按小时计费/自定义单位计量/预付费功能) → 确认使用报告正确生成 → 向AWS报告任何问题

  • AWS测试 (Test by AWS Marketplace):AWS团队进行独立测试,验证产品功能、计费集成和用户体验。
  • 正式上线 (Live Listing):产品获得最终批准后,正式发布到AWS Marketplace公开目录。
  • AMI 产品的定价模式

AWS Marketplace 为 AMI 产品提供了多种灵活的定价模式,卖家可以根据自己的业务模式选择最适合的定价策略。

以下是完整的定价模式对比表:

|定价模式

|计费方式

|客户价值

|适用场景

|关键特点

|免费模式

(Free)

|仅收取 AWS 基础设施费用

|无软件费用

|• 开源软件

• 入门级产品

• 社区版本

|• 扩大用户群体

• 可作为获客策略

• 后续可通过增值服务变现

|按小时计费

(Hourly)

|按实例运行时间计费

|按需付费,灵活性高

|• 临时数据处理

• 测试环境

• 使用模式不规律的应用

|• 无长期承诺

• 可随时停止计费

• 适合短期或不规律使用

|按小时带年度选项

(Hourly with Annual)

|提供按小时和年度两种选择

|灵活性与折扣兼顾

|• 混合使用场景

• 同时服务临时和长期用户

|• 长期用户可获折扣

• 临时用户保持灵活性

• 适合多样化客户群体

|月度固定价格

(Monthly)

|固定月费,不限使用时间

|可预测的月度成本

|• 全天候运行的应用

• 监控系统

• 数据库服务

|• 简化计费

• 不受使用时间波动影响

• 适合持续运行的工作负载

|月度带按小时

(Monthly with Hourly)

|基本月费+额外使用按小时计费

|基础保障+弹性扩展

|• 有基准使用量但可能波动的应用

|• 基本使用量固定费用

• 峰值使用按需付费

• 平衡成本和灵活性

|自带许可

(BYOL)

|客户使用已购买的许可证

|保护现有投资

|• 已有大量现有客户的企业软件

|• 简化向云迁移

• 利用现有许可

• 仅支付基础设施费用

|自定义计量

(Custom Metering)

|基于自定义指标计费

|费用与实际价值直接相关

|• 数据处理服务

• API服务

• 基于用户的应用

|• 按实际使用的资源计费

• 与客户获得的价值挂钩

• 需集成计量服务

|合同定价

(Contract)

|预付固定期限的许可费用

|长期使用权利保障

|• 企业级解决方案

• 需要稳定预算的客户

|• 可配置合同:客户可定制权利

• 分层合同:预定义功能包

• 通常提供更多企业级支持

典型场景产品定价示例

  • 企业级业务系统

产品特性:长期稳定运行的企业管理软件环境

推荐定价:分层固定期限合同 + 存储容量扩展计费

适用场景:需要持续可用性保障的ERP/CRM等关键业务系统,适合中大型企业客户

  • 弹性计算平台

产品特性:预装分析工具的计算密集型环境

推荐定价:管理节点固定期限合同 + 工作节点按小时弹性计费

适用场景:周期性数据处理、临时性批量作业等波动负载场景

  • 安全运维系统

产品特性:全天候运行的威胁监控防护体系

推荐定价:按受保护节点数阶梯式自定义计价

适用场景:需要实时安全监控的云上业务系统

主要定价模式的实施流程

不同的定价模式有其特定的实施步骤和技术要求。以下是主要定价模式的实施流程概述:

  • 按小时计费模式实施流程

  • 创建并优化AMI:准备符合AWS Marketplace要求的AMI,确保软件正常运行
  • 创建产品页面:在AWS Marketplace管理门户中创建新产品
  • 选择按小时定价:在定价选项中选择”按小时”模式
  • 设置实例类型和费率:为不同EC2实例类型设置每小时费率
  • 提交产品审核:提交产品以供AWS审核和发布
  • 自定义计量定价实施流程

  • 创建支持计量的AMI:开发能够跟踪和报告使用量的AMI
  • 集成Marketplace Metering API:在软件中集成AWS Marketplace Metering Service
  • 定义计量维度和价格:设置计量维度(如数据处理量、API调用次数)及其价格
  • 实现使用量报告逻辑:开发定期向AWS报告使用量的机制
  • 提交产品审核:提交产品以供AWS审核和发布
  • 合同定价实施流程

  • 确定合同类型:选择可配置合同或分层合同模式
  • 定义权利和期限:设置合同包含的权利(如用户数、功能访问)和有效期限
  • 设置价格结构:为不同权利级别和期限设置价格
  • 集成License Manager:实现与AWS License Manager的集成,以验证客户权利
  • 提交产品审核:提交产品以供AWS审核和发布
  • BYOL模式实施流程

  • 创建并优化AMI:准备符合AWS Marketplace要求的AMI
  • 创建产品页面:在AWS Marketplace管理门户中创建新产品
  • 选择BYOL选项:在定价选项中选择”自带许可”模式
  • 实现许可验证机制:开发验证客户现有许可的机制
  • 提交产品审核:提交产品以供AWS审核和发布
  • AMI 产品的系统集成

为了充分利用 AWS Marketplace 的功能,卖家需要将其 AMI 产品与各种 AWS 服务进行集成。以下是主要的集成点:

AWS Marketplace Metering Service 集成

对于采用自定义计量定价的产品,需要集成 AWS Marketplace Metering Service 来报告使用量。

集成步骤:

  • 在 AMI 中安装 AWS SDK
  • 实现定期收集使用指标的逻辑
  • 调用 MeterUsage API 向 AWS 报告使用量
  • 实现错误处理和重试机制

代码示例:

最佳实践:

  • 实现本地缓存机制,防止网络问题导致计量数据丢失
  • 设置适当的报告频率,避免过于频繁的 API 调用
  • 实现详细的日志记录,便于故障排查
  • 考虑实现使用量预警机制,帮助客户管理成本

AWS License Manager 集成

对于基于许可的产品,集成 AWS License Manager 可以实现许可验证和管理。

集成步骤:

  • 创建许可模型和权利
  • 在软件中实现许可检查逻辑
  • 使用 License Manager API 验证客户许可
  • 根据许可状态启用或禁用功能

代码示例:

CloudFormation 集成

通过提供 CloudFormation 模板,卖家可以简化客户的部署过程,实现更复杂的多资源部署。

集成步骤:

  • 创建 CloudFormation 模板,定义所需的 AWS 资源
  • 包含参数以允许客户自定义部署
  • 实现初始化脚本以配置软件
  • 在 AWS Marketplace 产品页面提供模板链接

模板示例:

系统通知集成

AMI 产品可以集成 AWS Marketplace 的通知系统,接收订阅变更、续订和其他重要事件的通知。

集成步骤:

  • 创建 SNS 主题接收通知
  • 配置通知目标(如 Lambda 函数、SQS 队列等)
  • 实现处理通知的逻辑
  • 在 AWS Marketplace 管理门户中配置通知设置

通知处理示例:

AMI 产品开发最佳实践

创建高质量的 AMI 是成功的关键,以下是一些最佳实践:

  • 安全性:
  • 使用最新的操作系统补丁
  • 移除不必要的软件包和服务
  • 禁用默认密码和密钥
  • 实施最小权限原则
  • 加密敏感数据
  • 性能优化:
  • 优化操作系统设置
  • 预配置应用程序以获得最佳性能
  • 考虑不同实例类型的性能特性
  • 实施自动扩展机制
  • 用户体验:
  • 提供清晰的初始登录说明
  • 实现自动化配置
  • 提供详细的文档和帮助资源
  • 设计直观的用户界面
  • 可维护性:
  • 实现日志记录和监控
  • 提供自动更新机制
  • 设计模块化架构便于维护
  • 考虑数据备份和恢复机制
  • 结论

AMI 产品在 AWS Marketplace 上提供了灵活的分发和变现途径,通过选择合适的定价模式和实施正确的系统集成,软件供应商可以显著扩大其客户群并简化运营流程。

成功的 AMI 产品策略需要考虑多个因素,包括目标客户需求、产品特性、竞争格局以及技术实现。通过遵循本文介绍的最佳实践和集成方法,软件供应商可以充分利用 AWS Marketplace 的优势,实现业务增长和客户满意度的提升。

随着云市场的不断发展,AMI 产品的定价和集成策略也将继续演进。软件供应商应保持灵活性,根据市场反馈和技术进步不断调整其策略,以保持竞争优势。

参考资源

  • AWS Marketplace 卖家指南 – AMI 产品
  • AMI 产品定价
  • 自定义计量定价
  • AWS License Manager 集成
  • AMI 产品最佳实践
  • AWS Marketplace 卖家 workshop
  • *前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营,具体信息以中国区域官网为准。


使用智能代理在AWS无服务器架构上进行源代码分析

AWS账单代付阅读(59)

亚马逊AWS官方博客

使用智能代理在AWS无服务器架构上进行源代码分析

摘要

随着软件开发规模的不断扩大和代码复杂性的增加,传统的代码分析方法已经无法满足现代开发团队的需求。本文探讨了如何利用生成式人工智能代理(GenAI Agent)结合AWS无服务器架构来构建高效、可扩展的源代码分析平台。我们通过多个基于生成式AI智能体的代码分析项目实施案例总结了在AWS云环境中部署智能代码分析解决方案的最佳实践和通用设计模式。

背景

为什么需要使用智能代理进行代码分析?

在现代软件开发过程中,代码分析已成为保障软件质量、提升开发效率的关键环节。传统的静态代码分析工具虽然能够发现语法错误和基本的代码质量问题,但在以下方面存在明显不足:

  • 理解上下文的局限性:传统工具难以理解代码的业务逻辑和设计意图,无法提供深层次的架构建议。
  • 跨文件关联分析能力不足:现代应用通常由数百甚至数千个文件组成,文件间的依赖关系复杂,传统工具难以进行全局性的影响分析。
  • 缺乏智能化建议:传统工具主要基于预定义规则,无法根据具体场景提供个性化的优化建议。
  • 无法进行跨项目对比:传统工具无法实现项目之间的异同分析对比,无法判断项目抄袭。

智能代理的引入为解决这些问题提供了新的思路,基于大语言模型的AI代理具备以下优势:

  • 自然语言理解能力:能够理解代码注释、变量命名等语义信息
  • 上下文推理能力:可以分析代码间的逻辑关系和业务关联
  • 知识迁移能力:能够应用已有的编程最佳实践和设计模式理解代码架构和模式
  • 多模态分析能力:可以同时处理代码、文档、配置、图片文件等多种类型的信息
  • 代码总结分析分类能力:可以理解代码,快速代码实现进行总结,模块分类
  • 代码分析的主要类型

根据分析目标和应用场景,代码分析可以分为以下几种类型:

  • 相似性分析:检测代码重复、抄袭或功能相似的模块,常用于知识产权保护和代码去重。
  • 质量评估:评估代码的可读性、可维护性、性能等质量指标,帮助开发团队提升代码标准。
  • 架构分析:分析系统架构的合理性,识别设计缺陷和优化机会。
  • 影响分析:评估代码变更对系统其他部分的潜在影响,降低变更风险。
  • 技术挑战

构建智能代码分析平台面临以下主要技术挑战:

  • 计算资源需求:大型代码库的分析需要大量的计算资源,特别是使用大语言模型进行深度分析时。
  • 存储和访问:需要高效地存储和访问大量的源代码文件,同时保证数据安全性。
  • 并发处理:多个分析任务需要并发执行,要求系统具备良好的可扩展性。
  • 成本控制:代码分析属于低频异步场景,需要在保证并发扩展性时减少不必要的计算资源驻留。
  • 准确性保证:AI模型存在不确定性,需要建立有效的质量控制机制。
  • 可观测性:多数代码分析流程较长,需要保证有效的可观测机制和日志追踪。
  • 通用代码分析平台设计

基于多个实际项目的经验,我们总结出了一套通用的代码分析平台设计模式。该设计充分利用了AWS无服务器架构的优势,实现了高可用、高扩展性和成本优化的目标。

分析任务触发机制

代码分析平台支持多种触发方式,以适应不同的使用场景:

API触发:通过RESTful API接口主动发起分析任务,适用于集成到现有的开发工具链中。这种方式为用户提供了最大的灵活性,可以根据具体需求定制分析参数:如项目名称,版本,源代码地址等等。

Git Webhook触发:与Git仓库深度集成,在代码提交、合并请求或分支创建时自动触发分析。这种集成方式能够实现真正的CI/CD流水线自动化。

触发器架构设计:

  • 使用Amazon API Gateway作为统一的入口点
  • AWS Lambda函数处理不同类型的触发请求
  • 使用Amazon DynamoDB记录触发历史和任务状态

此外,根据场景不同,还可以选择:

  • 定时触发:使用Amazon EventBridge定期执行代码分析任务,适用于周期性的代码质量检查和合规性审计。
  • 事件驱动触发:当代码文件上传到Amazon S3时自动触发分析流程,支持批量处理和增量分析。
  • 代码存储

代码存储采用分层架构,兼顾性能、成本和安全性。这种设计模式在两个项目中都得到了验证,能够有效支持大规模代码分析的需求。

Amazon S3对象存储层:

  • 原始代码存储:存储从GitLab下载或用户上传的ZIP格式代码包
  • 分析结果归档:存储HTML报告、JSON数据文件和可视化图表
  • 版本管理:利用S3的版本控制功能管理代码历史,支持回溯分析
  • 生命周期管理:配置自动归档策略,将超过30天的数据转移到IA存储类别,90天后转移到Glacier

Amazon EFS共享文件系统层:

  • 高性能访问:为Lambda函数提供低延迟的文件I/O操作
  • 并发支持:支持多个Lambda函数同时访问同一代码库,实现真正的并行分析
  • 动态扩展:根据实际使用量自动扩展存储容量,无需预先规划
  • POSIX兼容:提供标准的文件系统接口,简化代码迁移和工具集成

代码存储工作流:

  • 代码获取阶段:

  • 从GitLab仓库克隆代码或从Amazon S3下载ZIP包
  • 解压到Amazon EFS的临时工作目录(/mnt/efs/tasks/{task_id}/)
  • 验证文件完整性和格式合规性
  • 预处理阶段:
  • 过滤不需要分析的文件(如二进制文件、依赖库)
  • 按文件类型和模块进行分类组织
  • 生成文件清单和依赖关系图
  • 分析阶段:

  • 多个AWS Lambda函数并发访问EFS中的代码文件
  • 每个函数处理特定的代码模块或文件类型
  • 实时写入中间结果到EFS临时目录
  • 结果存储阶段:
  • 将最终分析结果上传到Amazon S3进行持久化存储
  • 清理Amazon EFS中的临时文件释放存储空间
  • 更新Amazon DynamoDB中的任务状态和文件路径

Amazon DynamoDB元数据管理:

  • 任务状态跟踪:记录每个分析任务的详细状态信息
  • 文件路径索引:存储S3中分析结果的完整路径,便于快速检索
  • 性能指标:记录分析耗时、文件数量等关键指标用于优化
  • 错误日志:详细记录分析过程中的异常和错误信息

存储架构设计:

分析流程:Step Functions状态机编排

分析流程采用AWS Step Functions状态机进行编排,实现复杂业务逻辑的可视化管理,除了每个步骤自己的日志,状态机也会保存所有的步骤的执行日志,可以清楚的看到每个步骤的输入输出,所用时间,错误等,方便后续追踪。每个分析步骤都有明确的任务定义和输出产物,确保整个流程的可追溯性和可维护性。以下阶段只是示例,需要根据实际需求进行调整。

阶段一:预处理(Pre-process)

  • 代码获取:从GitLab仓库克隆或从S3下载代码包
  • 解压和验证:解压ZIP文件到EFS工作目录,验证文件完整性

输出产物:

  • json:文件清单和基本信息
  • json:项目基本元数据(包括 EFS 文件路径等信息)

阶段二:特征提取(Feature Extraction)

  • 特征分析:读取特征文件(如 Android app 中的xml 文件)了解项目的基本信息,如 package name,权限,第三方依赖,重要图片,表单等。
  • 代码结构:扫描代码结构,代码文件路径,资源文件路径,配置文件路径。
  • 模块分析:将主要代码文件按照模块分类,如登陆模块,广告模块,游戏引擎,第三方集成模块等。
  • 模式识别:识别设计模式和架构模式。

输出产物:

  • json:整个项目的特征文件
  • json:整个项目的模块化分析

阶段三(代码review):智能分析(Intelligent Analysis)

  • 并行分析:多个Lambda函数并行处理不同更改
  • 深度理解:AI代理分析代码逻辑找到关联文件
  • 问题识别:识别修改潜在的质量问题和安全风险已经修改对关联文件的影响

输出产物:

  • json:详细分析结果
  • json:发现的问题和建议
  • json:质量评分

阶段三(应用对比):对比分析(Similarity Analysis)

  • 并行分析:多个Lambda函数并行处理不同模块代码相似度详细对比
  • 深度理解:基于两个项目的特征文件进行架构,功能,权限,重要图片之间的对比
  • 抄袭识别:识别同模块下的相似代码片段,进行相似度打分

输出产物:

  • md:基于项目的特征信息对比结果
  • md:按照模块进行代码对比的结果

阶段四:结果整合(Summary)

  • 数据汇总:整合各模块的分析结果
  • 报告生成:生成HTML格式的可视化报告
  • 评分计算:计算综合质量评分
  • 建议生成:基于分析结果生成改进建议

输出产物:

  • html:完整的分析报告
  • json:分析摘要
  • json:改进建议

流程控制特性:

  • 错误处理:每个步骤都配置了重试机制和错误捕获
  • 并发控制:Map状态限制最大并发数避免资源过载
  • 状态传递:使用ResultPath精确控制状态数据的传递
  • 超时保护:为每个Lambda函数设置合理的超时时间

监控和日志:

  • 使用CloudWatch监控状态机执行情况
  • 记录每个步骤的执行时间和资源消耗
  • 在DynamoDB中存储详细的执行日志
  • 支持实时查询任务进度和状态
  • 智能代理:Lambda部署与Strands Agent SDK

智能代理是整个平台的核心组件,部署在AWS Lambda上,使用Strands Agent SDK进行开发。

AWS Lambda 是一种无服务器的计算资源,Lambda 可以进行快速纵向扩展并且在不需要时缩减至零,适合代码分析的低频使用场景。

Strands Agent 是一个简单易用且可用于生产环境,代码优先的生成式AI代理(GenAI Agent)构建框架。其主要特点包括:

  • 简单的代理循环系统(agent loop),运行稳定且完全可定制。
  • 完整的可观测性、追踪功能,以及支持大规模运行代理的部署选项。
  • 支持来自多个提供商的多种不同模型。
  • 支持对话式、非对话式、流式和非流式:支持各种工作负载的所有类型代理。
  • 提供强大的工具,覆盖广泛的功能。

这种部署架构设计充分利用了无服务器计算的优势,实现了自动扩展和成本优化。

Lambda部署架构:

函数配置:

  • 运行时:Python 3.13(或者选择最新的版本)
  • 超时时间:15分钟(Lambda最大限制)
  • 环境变量:模型配置、S3桶名、DynamoDB表名等
  • 网络配置:需部署在 VPC 内以访问 EFS
  • 文件系统:挂载 EFS
  • 权限:
  • AWSLambdaBasicExecutionRole (managed policy)
  • AWSLambdaVPCAccessExecutionRole (managed policy)
  • s3 读写权限 (从 S3 上读取之前的生成物,上传新的生成物到 S3 上面)
  • dynamodb 读写权限(读取生成物路径,更新任务状态)
  • EFS 挂载和读写权限
  • bedrock 模型 invoke 权限

Strands Agent SDK集成:

在代码分析的不同阶段中,我们会配置不同的 Strands agent,这些 agent 的主要区别是:

  • 模型:我们推荐对于不同的任务使用不同的模型,这样可以在一定程度上节省成本。
  • 提示词:对于不同的分析任务,我们会编写不同的提示词,此外我们建议将提示词保存成模版放在 S3 上(不要写死在Lambda 代码中),方便后面编辑更新。
  • 工具:我们可以使用 Strands agent 内置的 file_read, file_write, shell 等强大功能帮助我们读取文件,甚至编写代码分析文件。

提示词:

对于生成式AI agent来说,提示词(Prompt)的重要性可以说是决定性的。提示词的质量直接决定了你的智能代码分析平台能否真正发挥AI的优势,实现从传统规则驱动向智能理解驱动的转变。

提示词工程的最佳实践:

系统级提示词(角色定义)

任务级提示词(具体分析目标)

上下文级提示词(项目特定信息)

输出级提示词(格式和结构要求)

示例:

作为一个资深的Java代码审查专家,先阅读项目特征文件,了解项目的基本信息,然后分析以项目代码。

重点关注:

1. 安全漏洞(SQL注入、XSS等)

2. 性能问题(N+1查询、内存泄漏)

3. 架构设计缺陷(违反SOLID原则)

4. 代码可维护性问题

Sprint Boot项目代码目录:/abc/project/

项目特征文件路径:/abc/feature.json

把分析结果保存成 /abc/report.md ,报告中每个发现的问题提供:

– 问题描述和风险等级

– 具体的代码位置

– 修复建议和最佳实践

– 相关的代码示例

此外,提示词不是一成不变的,随着项目的演进,大模型能力的增强,需要不断收集用户反馈,分析报告中的误报和漏报信息,不断的调整提示词的表述和结构。

通知机制:SES邮件与API状态查询

代码分析通常所需要的时间较长,应该设计为一个异步流程,即开启任务之后,用户不会一直等待,而需要任务结束之后主动通知用户。完善的通知机制确保用户及时了解分析进度和结果,支持多种通知方式以适应不同的使用场景。

Amazon SES邮件通知:

SES(Simple Email Service)是我们主要的通知渠道,具有以下优势:

  • 高可靠性:9%的邮件送达率保证
  • 成本效益:按发送量付费,无需维护邮件服务器
  • 模板化支持:支持HTML和文本格式的邮件模板
  • 多语言支持:根据用户偏好发送中英文通知

邮件通知触发时机:

  • 分析任务开始时发送确认邮件
  • 分析过程中的关键节点更新
  • 分析完成时发送详细报告
  • 分析失败时发送错误通知
  • 分析流程中需要人工介入/审批的时候

API状态查询接口:

由于我们已经把代码分析过程中的状态和各种生成物路径持久化在了 DynamoDB中,除了邮件通知,我们还可以设计 RESTful API 供用户主动查询任务状态:

如API端点设计

GET /api/v1/analysis/tasks/{task_id}/status

响应格式示例

结论

通过构建基于AWS无服务器架构的智能代码分析平台,我们成功解决了以下核心问题:

可扩展性问题:

  • 利用Lambda的自动扩展能力,系统可以根据负载自动调整计算资源
  • Step Functions提供了可靠的工作流编排,支持复杂的并行处理逻辑
  • EFS和S3的组合使用实现了存储的弹性扩展

成本优化:

  • 按需付费的模式显著降低了运营成本
  • 智能的资源调度减少了空闲资源的浪费
  • 通过缓存和增量分析进一步优化了计算成本

分析质量:

  • AI代理的引入大幅提升了分析的深度和准确性
  • 上下文感知的分析能力解决了传统工具的局限性

开发效率:

  • 自动化的分析流程减少了人工干预
  • 实时的反馈机制加速了问题发现和修复
  • 标准化的报告格式便于团队协作

最终架构示例:

通过持续的技术创新和实践优化,智能代码分析平台将成为现代软件开发不可或缺的基础设施,为提升软件质量和开发效率发挥更大的价值。随着AI技术的不断发展和云计算成本的持续下降,我们相信这种基于无服务器架构的智能分析平台将会得到更广泛的应用和[已去除[已去除推广语]语]。

本文基于AWS无服务器架构的实际项目经验总结而成,文中提出的通用设计模式和最佳实践,旨在为构建类似的智能代码分析解决方案提供参考和指导。随着技术的不断发展,相关的架构设计和实施方法也将持续演进和完善。

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


降本增效的制胜之道:亚马逊云科技 Static BGP 助力IPC行业客户突破公网流量成本困境

AWS账单代付阅读(54)

亚马逊AWS官方博客

降本增效的制胜之道:亚马逊云科技 Static BGP 助力IPC行业客户突破公网流量成本困境

前言

随着智能家居和智慧安防的快速发展,智能摄像头(IPC)行业迎来了前所未有的机遇与挑战。一方面,市场需求持续增长,应用场景不断丰富;另一方面,实时视频传输所产生的巨大公网流量也给企业带来了显著的成本压力。在这样的背景下,如何在确保服务质量的同时实现成本的优化,成为了 IPC 企业面临的关键课题。

本文将深入分析 IPC 行业的典型应用场景和技术特点,重点探讨在 AWS 云平台上,如何通过Static BGP(S-BGP)这一创新网络方案来应对行业挑战。我们将通过详实的数据和实践案例,展示 S-BGP 如何帮助IPC企业在保持卓越网络性能的同时,显著降低数据传输成本,为业务发展提供更强有力的支撑。无论您是正在寻求成本优化方案的IPC企业,还是对云端视频传输架构感兴趣的技术从业者,相信这篇文章都能为您提供有价值的参考。

产品介绍

亚马逊云科技推出的Static BGP(S-BGP)服务是专为中国区域(北京和宁夏)设计的一种成本优化型数据传输服务。通过这项服务,我们致力于帮助客户在保证网络性能的同时显著降低数据传输成本。

主要优势

显著的成本效益: S-BGP 可为符合条件的客户提供高达20%~70%的数据传输费用节省。 卓越的网络性能: 采用多运营商链路部署,实现灵活的流量调度,提供与标准BGP相当的网络性能表现。 企业级可用性: 配备全面的运营工具和监控系统,包括接口状态和链路可用性等关键指标的实时监控。 广泛的实践验证: 已在汽车、电商、游戏、航空、ISV等对网络性能要求较高的行业得到充分验证。

适用场景:S-BGP 特别适合具有以下特点的客户:

  • 月度数据传输量较大的工作负载。
  • 对网络服务质量和成本优化都有较高要求。
  • 愿意通过优化架构来实现长期的成本收益。
  • 服务特性

  • 支持EC2实例、NAT网关和弹性负载均衡器(ALB/NLB)。
  • 提供专用弹性公网IP(EIP)资源池。
  • 可实现与全球互联网用户的可靠连接。
  • 具备完善的容灾和故障转移机制。
  • 场景分析

智能摄像头(IPC)行业的核心应用场景是实时视频监控和设备控制&交互。在这一场景中,终端用户通过手机、电脑等设备查看摄像头的实时视频流或者进行通话。行业普遍采用 P2P 技术来实现终端设备与摄像头之间的直连(原因: 因为基于公网进行直连,并采用 UDP 协议进行数据传输, 相比于 TCP 的延迟会低很多,在摄像头或者通话等音视频场景的体验会更流畅&延迟低)。当P2P连接成功时,视频流直接从摄像头传输到终端设备,不会产生云端流量;但当P2P连接失败时,视频流需要经由云端转发,这就产生了大量的数据传出(DTO)费用。目前业内P2P的连接成功率在50%-80%之间,受网络环境、摄像头规格、应用场景等多重因素影响。对IPC厂商而言,P2P传输能力是其产品的重要技术指标,而云平台则在其中扮演着连接前端设备与后端客户端的桥梁角色。

音视频整体架构** **核心步骤

  • 低功耗设备需要通过 IOT管理平台进行唤醒,长电类型设备不需要额外唤醒动作。
  • 用户侧通过向后台发起请求,获取设备端的连接信息。
  • 用户侧和设备侧通过 P2P服务集群基于公网进行P2P 直连。
  • 连接成功,则设备和用户侧直接进行点对点的数据传输。
  • 连接失败,则双方的流量需要使用中继服务器进行流量转发。海外穿透成功率在7成左右,国内穿透率在6成左右,剩下3~4成流量需要走转发,这部分流量成本不可避免。
  • 业务面临挑战

IPC行业面临着几个关键性的挑战:首先是P2P接入的局限性。由于摄像头硬件性能和家用宽带上行带宽的限制,单个设备同时在线访问用户数往往会受到严格限制(通常不超过3个用户),这直接影响了产品的实用性。其次是P2P连接的不确定性。当P2P穿透失败时,只能采用云端转发方案,这不可避免地带来了显著的公网流量成本。在这样的场景下,选择合适的网络方案就显得尤为重要。基于多运营商线路的S-BGP方案,能够很好地满足IPC行业的需求:一方面,它继承了标准BGP多线路的优势,能够适应复杂的网络环境,保证低时延、低丢包率的网络性能;另一方面,相比标准BGP方案,S-BGP能够显著降低数据传输成本,帮助客户更好地应对公网流量带来的成本压力。

架构演进

为了降低改造成本和风险,IPC客户可以采用渐进式的方案来部署S-BGP。对于存量业务,可以继续使用原有的标准BGP方案;

而针对新增业务产生的流量(如新产品线投放、新区域拓展等),则可以通过S-BGP来承载。这种演进方案的实施非常简单:客户只需提前申请开通S-BGP白名单,在部署新的工作负载时,通过AWS控制台或API创建的EC2实例将自动获得S-BGP专用的弹性IP地址(EIP),而无需对现有架构做任何改造。这种平滑过渡的方式既确保了业务的连续性,也最大程度地降低了迁移风险。随着新业务的不断扩展,客户将逐步获得更多来自S-BGP的成本优势,同时保持了与标准BGP一致的网络服务质量。这种演进策略特别适合那些业务持续增长,但又不希望对现有架构做大规模改造的IPC企业。

传统架构** **架构待优化点

  • 由于业务特性, P2P的穿透率在6~7成,最终会有3~4成的流量需要通过云上服务器进行转发,这里面会带来标准的流量费用。
  • 在复杂网络环境下会遇到网络丢包率高的情况,缺少网络路径优化。
  • 推荐架构** **核心优势

  • 大幅度降低网络流量成本。
  • 通过底层采用网络路径优化,提高网络质量,提升网络稳定性,最终对于用户侧的体验也会更好,在音视频场景下延迟也会降低,画面也会更流畅。
  • 必要配置

客户只需要在EIP分配界面选择S-BGP即可(如下图)。后续按需将S-BGP EIP关联到EC2, NATGW和ELB。

业务收益

显著的成本优化

  • 在保持与标准BGP同等网络性能的前提下,S-BGP能够帮助客户实现高达20%-70%的数据传输成本节省。
  • 由于视频转发场景下的公网流量占比较大(通常在总账单的30%以上),这种成本优化对企业整体运营支出的改善具有实质性影响。
  • 卓越的网络性能

  • 得益于多运营商线路的优势,S-BGP为终端用户提供低时延、低丢包率的稳定访问体验。
  • 在全国主要城市(北京、杭州、上海、成都、深圳、兰州、重庆、南京、厦门、济南)的测试数据显示,S-BGP与标准BGP相比(图中红色:亚马逊云科技S-BGP;黄色:亚马逊云科技标准BGP;蓝色:友商标准BGP),时延差异不超过2ms,丢包率差异低于0.1%,完全满足视频传输的性能要求。
  • 运维便捷性

  • 只需要为每台用于流量转发的EC2实例配置一个S-BGP EIP。S-BGP会根据终端用户所使用的运营商网络,自动选择最优路径,显著降低了运维复杂度。
  • 与标准BGP共用相同的API接口,降低了技术团队的学习成本。
  • 支持EC2、NAT网关和负载均衡器(ELB)等核心服务,满足各类部署架构的需求。
  • 对于新增业务,只需完成一次性的S-BGP白名单申请,后续使用与标准BGP完全一致,无需额外的运维工作。
  • 业务连续性保障

  • 支持灵活的渐进式迁移策略,新老业务可以同时运行,避免了全量切换带来的风险。
  • 多运营商线路互为备份,确保业务的高可用性,为终端用户提供稳定可靠的视频访问服务。
  • 总结

在数字化转型的浪潮下,IPC行业正经历着前所未有的机遇与挑战。一方面,智能家居和智慧安防的蓬勃发展带来了巨大的市场空间;另一方面,视频传输所产生的公网流量成本也给企业的可持续发展带来了考验。作为亚马逊云科技在中国持续创新的体现, S-BGP不仅为IPC企业提供了显著的成本优化空间,更通过其卓越的网络性能和便捷的运维特性,完美解决了行业面临的方案与成本挑战。在保证服务质量的前提下,最高可实现70%的数据传输成本节省,这对视频流量占比较大的IPC企业而言具有重要价值。通过灵活的部署策略和完善的技术架构,S-BGP正在成为推动IPC行业持续健康发展的重要技术支撑。

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


强化学习优化消除类游戏关卡设计的实践

AWS账单代付阅读(56)

亚马逊AWS官方博客

强化学习优化消除类游戏关卡设计的实践

关于Magic Tavern

Magic Tavern(中文名“麦吉太文”)是一家全球化的游戏研发与发行公司,成立于2013年,总部位于北京,并在上海和旧金山设有办事处。公司专注于移动休闲游戏的开发,致力于打造适合各年龄段玩家的娱乐体验,旗下多款游戏在全球市场表现优异,常年位列多个国家的畅销榜前列,并多次获得苹果、谷歌等平台的官方推荐。

截至目前,Magic Tavern拥有超过亿级的总用户和千万级的日活跃玩家,员工规模约400余人,团队成员包括来自清华、纽约大学、新加坡国立大学、Google、EA等知名机构的资深游戏开发人才。其代表作品包括《Matchington Mansion》《Project Makeover》《Modern Community》等。

前言

消除类游戏作为休闲游戏品类中的常青树,具有非常广阔的市场空间和玩家群体。目前,消除类游戏的玩法逐渐从以闯关刷分导向发展到结合任务、剧情的收集导向。无论是哪种玩法,都要求游戏开发商对于关卡的设计和难度评估具有快速和准确的结果,尤其是对于收集导向型的消除类游戏,其主线剧情任务的通关高度依赖于关卡更新迭代。如何快速准确的得到关卡的难度值,从而优化关卡排布,对于游戏长期运营和优化玩家体验具有重要意义。

一般来说,游戏的新关卡上线之前,会首先经过内部一系列的机测和策划内部交叉测试流程,再根据统计数据确定关卡的难度估计。但由于测试规模和样本量的限制,偶尔会出现新关卡上线后与预期难度偏差过大的情况,一定程度上会影响真实玩家体验。这时就需要召回关卡重做,或更正难度后重新排布关卡分布。内部测试流程需要消耗大量人力且难度评估不一定准确,如果有更好的自动化测试方法,将能大幅度提高新关卡的生产效率。

消除类游戏关卡中的关键元素

消除类游戏的关卡一般会设定有通关元素、限制条件、道具、奖励等。通关元素指通关所需要消除或收集的元素,一般会在棋盘上表示为障碍物、特殊物品等。限制条件指达成通关条件前的操作约束,比如可操作步数、倒计时、不可消除障碍等。道具指除了基本操作之外,通过额外购买或活动赠送获取的强力物品,一般能够影响关卡平衡性,降低通关难度。但这些道具物品的获取一般通过充值,对于难度预测的影响不大。奖励指通过凑成特殊消除范式获得的奖励元素,比如炸弹、火箭等,这些奖励元素能够在棋盘上消除特定范围内的普通元素,组合应用奖励元素具有更大的威力。奖励使用技巧体现了玩家水平,并且是难度预测中的一个重要部分。

上图是Magic Tavern的消除类游戏《Project Makeover》的第84关截图,可以看到图中具有非常多的元素。此关的通关元素显示在左侧,需要收集31个相机和28件衬衫。限制条件是20步。道具如右侧显示,目前此玩家具有6个梳子道具和6个香水道具,这些道具的使用与关卡设计无关,充值即可获得。奖励在棋盘上显示为火箭,不同方向的火箭可以消除对应一行或一列的所有元素,火箭可以通过消除一行或一列4个相同元素获取。

强化学习如何应用于消除类游戏

强化学习的核心组成元素是Agent、Environment,通过Agent与Environment的交互(Action),获取奖励(Reward)和新的状态(State)。

在消除类游戏的通关过程中,Agent是自行游玩的主体,扮演玩家。研发人员需要给出具体的动作空间,一般是棋盘上可以造成消除的所有有效动作。当Agent进行了一步操作,游戏后端计算此操作对通关元素、限制条件、奖励的影响,并返回当前状态和奖励值给Agent。Agent反复执行动作,直到达成通关条件或限制条件用尽游戏结束,记录获取的奖励值。循环往复进行训练,Agent便会向着获取最大奖励值的方向学习,即为学会了游玩游戏的逻辑。

难度预测

通过强化学习训练Agent,我们拥有了测试关卡的玩家主体。接下来,我们还需要收集Agent游玩关卡时的特征数据,如获取的奖励值、是否通关,通关时剩余限制条件等。通过这些特征数据,结合历史关卡的准确难度值,拟合一个机器学习模型,用于新关卡的难度预测。整体流程是:当新关卡需要测试难度时,首先使用强化学习模型微调Agent,再游玩新的关卡得到这些特征数据,然后通过历史难度预测模型推理得到新关卡的难度。

与现有关卡设计流程的结合

到目前,我们理清了使用强化学习进行关卡难度预测的核心算法和工作流程。接下来,为了在实际的关卡设计中应用难度预测的流程,我们还需要进行一些工程化的工作。

并行训练推理

一般来说,策划组产出新关卡数量每批次为十几关甚至几十关,每一关还有不同的初始状态和掉落次序,因此在强化学习训练时需要进行并行化来提高难度预测速度。

强化学习Agent的训练是重计算任务,需要高CPU计算资源。在Agent与游戏后端服务器通信时,每个Agent占用一个CPU核心,以c7i.4xlarge类型的EC2实例为例,每台实例具有16核,可以同时运行16个Agent。同时,需要关注游戏后端服务器的压力状况,资源不足时要及时扩容。当使用Agent获取到足够多的特征数据时,需要拟合MLP模型。此类模型使用GPU训练能有效提升训练速度。

并行训练可以使用Ray框架来部署,Ray框架专门用于分布式训练和模型微调。它能够让用户轻松地将模型训练代码从单机扩展到云端的多机器集群,极大简化了分布式计算的复杂性。此外Ray还支持kubernetes,能够轻松在EKS上部署。

模型管理

在整个工作流程中,有基于历史关卡训练的基准Agent模型,也有新关卡时微调的新Agent模型。随着关卡设计的增多,模型数量也会随之变大。我们需要一套模型管理系统来存储和管理这些模型,考虑到这些模型都有各自的生命周期,一般使用过的模型短期内不会再进行访问,将这些模型保存在S3并启用生命周期是具有性价比的选择。

回放系统

在Agent训练时,为了最大程度提升训练速度,我们建议客户封装无头游戏客户端。无头游戏客户端中不包含游戏前端,仅通过API交互,这样就避免每次动作后发生的前端动画造成的时延。然而,在测试过程中,我们有时希望能看到Agent的游玩过程。这部分有两个选择:一是使用包含前端的有头客户端测试,这样能够看到Agent的动作过程,缺点是使用有头客户端的交互过程存在动画,会导致耗时增加;二是通过Agent的操作日志,结合客户自己的回放系统,定向回放想要监控的关卡,缺点是需要进行操作日志和回放系统的步骤转译,且需要客户侧有回放机制。如下图所示,为Magic Tavern使用回放系统监控Agent的行为记录。

基于以上三点工程化需求,亚马逊云科技游戏行业解决方案团队设计了GameAIbot的解决方案,整体架构可参考如下架构图。

总结

消除类游戏的关卡难度预测是指导关卡排布,从而决定玩家体验的重要因素。传统基于人工的测试方法偶发预测难度失准,测试不够充分等问题。Magic Tavern的消除类游戏需要通关关卡来获取金币和素材来支持主线任务进行,尤其需要高质量和快速的关卡更新,基于强化学习的难度预测方式能够解放策划组人员的繁重测试任务,提高关卡设计效率,进而优化玩家的游戏体验。


通过AWS Site-to-Site VPN和AWS Directory Service对Amazon WorkSpaces进行私有访问和策略控制

AWS账单代付阅读(60)

亚马逊AWS官方博客

通过AWS Site-to-Site VPN和AWS Directory Service对Amazon WorkSpaces进行私有访问和策略控制

一. 前言

Amazon WorkSpaces为客户提供快速安全的全托管Windows远程桌面服务,并且可以通过可信设备设置和IP 访问控制组来管理workspaces的访问。本文将介绍利用AWS Site-to-Site VPN,为没有公网访问权限和没有固定IP网段的实际场景,使用RDP协议提供对Amazon WorkSpaces进行私有访问并通过AWS Managed Microsoft Active Directory组策略进行统一控制和提升安全姿态的方案。

AWS Site-to-Site VPN 是一种完全托管式服务,它使用 IP 安全(IPSec)隧道可以在企业内网与 AWS 资源之间创建安全连接。

AWS Directory Service for Microsoft Active Directory 又称为 AWS Managed Microsoft AD,提供完全托管的原生Microsoft AD。

二. 方案

架构设计

架构详细介绍

  • 用户在公司内网环境通过RDP连接workspace私有IP,通过AWS Site-to-Site VPN连接到部署在VPC私有子网的个人workspace
  • 内控部门通过管理WorkSpaces安全组控制入站和出站流量,同时还可以使用AWS Network Firewall实现 4 层之上的网络安全控制,参考link
  • 内控部门通过Microsoft AD组策略统一管理用户行为,如禁止上传、禁止复制、禁止远程磁盘挂载等
  • 三. 详细配置

  • 在Workspaces控制台“目录“中“访问控制选项“和“其他平台“选项下拒绝所有设备类型的访问权限。这样用户无法通过Workspaces客户端应用程序从公网访问:
  • 在Workspaces安全组入站规则中允许来自JumpServer的RDP访问:
  • 在Microsoft AD控制台上创建一个目录管理EC2实例,通过AWS Systems Manager Fleet Manager连接远程桌面,使用AD Admin账号登陆后配置组策略。下图以禁用剪切板重定向为例展示通过Group Policy Management工具来管理目录服务,创建Group Policy Object (GPO):
  • 默认情况下,所有workspaces共有一个安全组,命名规则为目录ID加_workspacesMembers后缀 (比如, d-123456fc11_workspacesMembers)。不同的个人workspace之间默认不能通信保证workspace之间的隔离。通过修改安全组的出入站规则可以自定义流量控制。
  • 使用RDP同时也可以让域里面的其他用户登陆到个人workspace。需要有两个权限:
  • 四. 总结

Amazon WorkSpaces 是一种完全托管的桌面即服务(DaaS),以安全性和简单性为优先考虑。客户可以通过多种方式保护其 Amazon WorkSpaces 部署的安全性。本文介绍了一些提升安全的实用方法来满足客户对于网络层的安全需求。


Agentic AI基础设施实践经验系列(二):专用沙盒环境的必要性与实践方案

AWS账单代付阅读(73)

亚马逊AWS官方博客

Agentic AI基础设施实践经验系列(二):专用沙盒环境的必要性与实践方案

一、Agent沙盒环境的业务需求、场景与技术解析

1. 为什么Agent需要专门的沙盒环境

Agent应用作为新一代人工智能应用形态,能够自主理解用户意图、制定执行计划并调用各种工具完成复杂任务,正在重塑我们与AI系统的交互方式。这类智能代理不仅能够处理自然语言对话,更能够主动执行代码、操作应用程序、分析数据,真正实现从“对话式AI”向”行动式AI”的跃升。

随着Agent技术的快速发展,一个关键问题浮现:为什么这些应用需要专门的沙盒执行环境?答案在于Agent独特的工作模式和业务特性带来的全新挑战。

2. Agent对沙盒环境的应用场景

在实际应用中,对于沙盒环境有两大核心应用场景:代码执行环境和可视化操作环境。

2.1 代码执行环境

Agent应用需要单独的代码执行环境来执行特定任务。以企业数据分析Agent为例,业务分析师可以直接上传一个1GB的销售数据文件到应用平台,然后通过自然语言告诉Agent:”分析过去一年的销售趋势,找出表现最好的产品类别,并生成可视化报表”。Agent能够自动解析用户意图,并调用大型语言模型生成数据读取、处理及分析代码。它会多次启动沙盒环境执行这些代码,最终生成包含图表和统计分析的完整报告。尽管整个流程可能需要数小时的连续计算,但用户只需通过自然语言描述需求并进行必要的修正即可。所有复杂工作均由Agent、大型语言模型和沙盒工具协同完成,无需用户直接参与技术操作。

除单一功能的Agent应用外,更为复杂的场景是AI Bot生态平台。这类平台同时服务两类用户群体:开发者(生产者)和终端用户(消费者)。开发者可在沙盒环境中利用Claude Code、Amazon Q CLI等AI编程助手快速构建各类Agent应用。完成后,他们能在同一环境中一键将应用部署为Web服务,实现AI Bot的无缝托管。终端用户则可直接访问和调用这些已部署的AI Bot服务,无需了解任何技术实现细节。这种模式以沙盒为基础,构建了从”AI辅助开发”到”一键部署”再到”即用即取”的完整生态闭环,有效连接了生产者与消费者两端。

针对多样化的应用场景,沙盒环境需提供灵活的代码执行方式,从执行模式看,系统需同时支持命令行直接执行以满足基础脚本运行需求,以及具备高阶代码解析能力的安全执行环境,确保代码在完全隔离的容器中运行;而在运行时环境方面,不同应用对技术栈的要求各异,如数据分析Agent需要Python Runtime来处理科学计算,代码编辑类Agent则依赖VSCode Server提供完整的开发体验,这种多元化的执行能力设计使沙盒能够适应不同复杂度和技术需求的应用场景,为各类Agent提供最适合的运行基础。

2.2 可视化操作环境

除了代码执行,Agent应用的另一个重要应用场景是Computer Use(计算机使用)和Browser Use(浏览器使用)。Computer Use是指AI Agent能够像人类用户一样操作计算机界面,包括点击按钮、输入文本、拖拽文件等各种GUI操作。Browser Use则是Computer Use的重要场景,专门指Agent在浏览器环境中的自动化操作能力,如网页浏览、表单填写、数据抓取等。

以某社区媒体营销文案生成Agent为例,营销人员只需输入”收集某某竞品在该平台上的营销策略”,Agent就能像真实用户一样操作浏览器:自动打开多个网页标签,浏览不同的产品页面和用户评论,收集关键的市场数据和用户反馈信息,然后基于收集到的数据进行分析,最终实现精准的内容推荐和广告投放策略。整个过程中,Agent通过Browser Use功能模拟人类的点击、滚动、输入等操作,完成复杂的数据收集任务。

类似的应用还包括游戏AI测试、软件自动化测试、在线订票等场景。这些应用的共同特点是需要Agent能够精确控制鼠标和键盘操作,与图形界面进行自然交互,处理那些没有API接口、只能通过视觉操作的应用程序。

这些Computer Use应用要求沙盒系统提供一个最小化的系统环境,实现完整的人机交互模拟功能并支持执行过程的可视化。系统需要提供完整的桌面环境或浏览器环境,让Agent能够像人类用户一样进行可视化操作,同时确保所有操作都在安全隔离的环境中执行。这种可视化操作能力让Agent真正实现了从”理解指令”到”执行操作”的完整闭环,为用户带来了前所未有的自动化体验。

3. Agent沙盒环境的核心技术诉求

从上述应用场景可以看出,Agent应用对沙盒环境提出了独特的技术要求,我们一起来分析具体的技术诉求点。

3.1 便捷的接入

Agent沙盒环境需要提供简洁易用的SDK和API接口,让开发者能够轻松接入而无需关心底层的部署、路由等复杂问题。系统应支持一键启动和发布功能,例如AI PPT生成应用只需选择模板就能直接启动服务。如果沙盒内运行Web服务,用户应能方便地连接访问,整个过程不应因为技术复杂性而阻碍业务开发进度。良好的接口设计不仅提升了开发效率,也为Agent应用的快速迭代和规模化部署奠定了基础。

3.2 简化的管理

系统需要提供简化的管理机制,支持弹性扩展和运行时(Runtime)环境切换。开发者应该能够通过创建标准化模板,然后仅用一个template ID就能启动新的运行环境,大大简化部署流程。平台需要提供灵活的模板化管理能力,支持用户自定义代码运行环境模板,这种”先创建模板,再启动运行时”的标准化流程,不仅能提高部署效率,也能确保环境的一致性和可重复性。同时,系统应支持多沙盒并行运行,能够高效监控各个沙盒的运行状态,并在新物理机加入时自动实现负载均衡和资源调度。

3.3 完善的生命周期管理

沙盒环境应具备完善的数据生命周期管理与毫秒级环境启停能力。在数据层面,系统需支持执行过程中临时数据的持久化存储,确保故障后数据依然存在,同时提供自动快照、恢复及pause/resume等核心功能,这对Agent多阶段推理和多分支探索等复杂任务流程尤为关键。随着用户规模增长,需要原生数据管理架构来解决状态信息存储与访问的性能瓶颈。在操作层面,环境必须实现毫秒级的启动、停止和销毁能力,这直接影响用户等待时间和并发处理能力,例如当用户发起数据分析请求时,环境需快速响应,集成、处理和分析数据并完成最终的结果输出。结合增量快照与快速克隆技术,系统能够支持复杂任务的断点续传和多路径探索,进一步提升灵活性与运行效率,为大规模并发任务处理提供坚实基础。

3.4 完备的安全保障

由于Agent需要执行外部生成的代码并访问第三方数据,安全风险显著增加。系统必须提供严格的安全隔离和故障隔离能力,确保有害代码不会在不同用户之间产生影响。现代Agent要求沙盒环境具备硬件级隔离、系统调用最小化、网络和文件系统的精细权限控制等多层安全防护机制。每个沙盒环境必须完全独立运行,实现真正的故障边界隔离,即使Agent生成的代码存在问题,也不应影响其他沙盒节点的正常运行。系统需要确保不同沙盒之间不会相互影响,同时支持高密度部署以充分利用物理机资源,在安全性和性能之间找到最佳平衡点。

这些技术诉求共同构成了Agent对独立运行环境的完整要求体系,只有满足这些严格标准的技术方案,才能真正支撑起新一代Agent应用的大规模商业化部署。

二、Agent沙盒环境的技术细节

1. 安全性

Agent沙盒环境的核心在于创建一个严格隔离且受控的执行环境,使AI系统能够安全地运行代码和访问资源。这种解决方案依赖于多层次的安全隔离机制。首先,通过虚拟化技术实现硬件级别的执行环境隔离,确保沙盒内的代码无法突破边界影响宿主系统或其他实例。其次,实施严格的网络访问控制,为每个代理分配独立的网络资源,并根据需求配置从完全断网到精细访问权限的策略。在数据安全方面,系统为每个代理提供基于只读模板的独立临时文件系统,会话结束后自动清理所有数据,防止信息泄露和持久化攻击。同时,动态资源管理机制严格限制CPU、内存等资源的使用,设定最大执行时间,并通过实时监控系统检测异常行为。

这种安全沙盒架构遵循最小权限原则,确保AI代理只能访问完成任务所需的最低限度资源。整个系统设计强调可审计性、可扩展性和运行时透明性,在保障安全的同时提供近似真实的执行环境。这一平衡使AI代理能够执行复杂任务而不会带来安全风险,为AI系统的安全部署提供了关键基础设施支持。

(1) 虚拟化隔离: 如亚马逊云科技开源主导的 Firecracker 微虚拟机技术提供了硬件级别的隔离。每个沙盒运行在独立的虚拟机中,与宿主机和其他沙盒完全隔离,防止代码突破容器边界,实现真正的安全执行环境。 (2) 网络隔离:在一个实例中,为每个沙盒分配独立的网络槽位和 IP 地址空间。通过网络池管理防止网络冲突,支持可控制的网络访问权限,可配置完全断网或受限网络访问策略。 (3) 文件系统隔离:每个沙盒使用独立的、基于模板创建的根文件系统,以防止恶意修改和影响其他实例。临时文件系统在执行完毕后会自动清理,确保数据不会泄露或残留。 (4) 资源限制与监控:每个沙盒严格限制CPU和内存使用量,以防止资源耗尽攻击。可以设置沙盒最大生存时间以阻止长时间运行的恶意代码,同时周期性(如30秒)进行健康检查,实时监控异常并自动处理。

2. 快速启动

Agent沙盒系统的高性能实现依赖于多层次的优化策略,形成了一套通用的性能加速方案。首先,通过智能缓存机制将常用模板保持在内存中,有效消除了传统I/O延迟,确保资源获取的即时性。同时,采用预分配资源池设计理念,系统提前准备网络和计算资源,实现零配置延迟的资源分配,使沙盒创建过程不再受资源初始化阻塞,大幅提升了高并发场景下的性能表现。

在资源管理层面,沙盒系统需要引入按需加载技术,实现资源的懒加载机制,只在实际需要时才分配必要的系统资源,显著降低了初始化阶段的消耗。这与轻量级虚拟化技术相结合,在提供必要隔离的同时,实现了接近原生速度的启动性能,平衡了安全性与效率的双重需求。

架构设计需要充分利用异步并发处理能力,通过并行初始化关键组件,使网络配置、内存初始化和文件系统准备等操作同步展开,有效避免了串行处理带来的时间损耗。性能优化的核心突破来自状态保存与快速恢复机制,系统能够从预先创建的环境状态直接恢复运行环境,跳过繁琐的初始化流程,实现接近即时的环境准备速度。

这些通用优化策略的综合应用,使Agent沙盒在保持安全隔离的同时,实现了极速启动性能,为各类AI系统提供了高效且安全的执行基础设施。如下图所示:

(1) 模板缓存系统: 需要支持预加载常用模板至内存以避免磁盘I/O延迟。可以通过API接口实现即时模板获取,基于内存缓存机制消除模板加载时间;同时支持多模板的并发访问与管理。 (2) 网络资源池:需要支持预分配网络槽位池,以实现零配置延迟分配。支持异步获取网络资源,避免运行时网络配置阻塞沙盒创建;同时支持高并发网络资源的分配与回收。 (3) UFFD 内存虚拟化:需要支持按需内存页面加载机制,以大幅减少启动时的内存占用。通过提供懒加载机制,使内存页面仅在被访问时才从模板加载,显著降低了初始化内存需求和启动时间。 (4) 微虚拟机(如Firecracker ):轻量级虚拟化技术实现了VM的快速启动。支持创建微虚拟机来替代传统容器,既提供了硬件级隔离,又保持了极快的启动速度,支持毫秒级的VM创建和销毁。 (5) 异步并发处理:支持多组件并发初始化来有效减少总体启动时间。通过异步机制,使网络分配、内存初始化和文件系统准备能够并行执行,避免了串行等待造成的时间浪费。 (6) 快照恢复机制:支持从预创建快照直接恢复,这样可跳过完整初始化流程。通过API支持实现状态恢复,结合增量快照和脏页面(Dirty Page)跟踪技术,实现比新建速度快数十倍的恢复效率。

3. 状态转换

Agent沙盒状态管理系统通常通过四项关键策略实现高效运行:首先,动态资源分配使沙盒能在活动与暂停状态间灵活切换,避免资源长期占用,提高整体利用率;其次,基于状态快照的快速恢复机制实现亚秒级扩缩容,比传统创建流程快10-100倍,有效应对负载波动;第三,增量差异算法仅保存变更数据而非完整状态,大幅降低内存和存储需求;第四,原子性状态转换确保系统可靠性,支持零停机维护和快速故障恢复。尤为重要的是,状态转换后(特别是在暂停和恢复操作中)通过快照技术完整保留原有运行环境,确保上下文连续性,使Agent能无缝继续之前的任务处理,避免因上下文丢失导致的重复计算和用户体验断层。

(1) 资源利用效率: 传统容器/虚拟机持续占用资源容易造成浪费,而通过暂停机制可实现按需资源分配。处于PAUSED状态时,系统能释放CPU和大部分内存资源,并可根据需求快速恢复,有效避免资源的长期占用,从而支持高密度沙盒部署。 (2) 快速扩缩容: 新建沙盒存在启动延迟高的问题,而通过快照恢复可实现亚秒级响应。从快照直接恢复能够跳过完整的初始化流程,预热机制则预先创建处于暂停状态的沙盒,需要时可快速激活。总体而言,恢复速度比重新创建快10-100倍。 (3) 内存占用优化: 大量沙盒同时运行会消耗巨大内存,通过增量快照技术可以大幅减少存储需求。脏页面跟踪机制只保存被修改过的内存页面,增量差异算法仅存储变化部分,而链式快照技术则进一步优化了存储效率。 (4) 服务可用性: 沙盒故障或维护可能影响服务连续性,但通过状态一致性保证可实现零停机运维。原子性状态转换确保操作要么全部成功,要么全部回滚。完整状态快照保存系统的所有状态信息,支持在故障发生时从任意保存点快速恢复系统。

4. 常见虚拟化技术的定性对比

以下是不同虚拟化技术能力的对比,可以看到以Firecracker为代表的微虚拟化技术提供了强隔离和快速启动时间,非常适合临时启用沙盒的场景:

|

标准 |

虚拟机 |

容器 |

Firecracker

|安全隔离

|★★★★★

|★★☆☆☆

|★★★★★

|启动时间

|★☆☆☆☆

|★★★★★¹

|★★★★★¹

|资源效率

|★☆☆☆☆

|★★★★★

|★★★★☆

|灵活性

|★★★★★

|★★★★☆

|★★☆☆☆²

注:当镜像已在本地存储时,容器通常能够快速启动。拉取镜像则需要额外时间。如果Sandbox模板存在于本地缓存中,启动速度会非常快,一般在100-800毫秒级别。

三、在亚马逊云构建和应用Agent沙盒环境

1. E2B on AWS方案

E2B on AWS 是一个企业级的AI智能体沙盒解决方案,它将开源E2B的沙盒技术部署在企业自有的AWS账户中。该方案基于Firecracker microVM技术,为AI智能体提供安全、可扩展且完全可控的代码执行环境,特别适合对数据主权和安全合规有严格要求的企业客户。

(1) E2B on AWS企业级部署的核心优势

  • 数据主权保障:所有沙盒执行环境部署在企业自有AWS账户内,满足数据本地化要求;
  • 安全合规增强:更容易满足各行业的严格合规标准;
  • 成本透明可控:基于AWS原生服务的精细化成本管理和预算控制;
  • 技术支持专业:AWS作为Firecracker开源项目的维护者,提供更专业的技术支持。

|

对比项 |

E2B 商业版本 |

E2B on AWS

|

数据可控 |第三方托管

|完全自主控制

|

合规 |依赖供应商

|自主合规管理

|

定制化 |标准配置

|深度定制,支持中国区,支持Graviton部署

|

成本 |按使用量付费

|基础设施成本

|

运维难易 |零运维

|自主运维

|

地域限制 |受限于E2B数据中心

|支持所有AWS区域

(2) E2B on AWS基础设施架构

E2B on AWS采用分布式微服务架构,集群示意图如下:

Server Cluster (服务集群):E2B集群的控制面,底层基于Consul和Nomad管理整个集群的基础设施和服务组件。负责服务发现、配置管理和集群协调,确保整个系统的高可用性和一致性。 API Cluster (API 集群):接收来自E2B CLI、E2B SDK等客户端的请求,并将请求转发给E2B的其他组件。提供RESTful API接口,支持沙盒的创建、管理、监控等操作,是整个系统的入口网关。 Builder Cluster (构建集群):专门负责构建E2B沙盒模板的集群。支持从Dockerfile、ECR镜像等多种方式创建自定义沙盒模板,为不同的AI应用场景提供定制化的执行环境。 Client Cluster (客户端集群):创建和管理E2B沙盒实例的集群,此集群下的服务器必须是 裸金属实例,以确保Firecracker microVM的最佳性能和安全隔离效果。

(3) E2B on AWS部署架构

为了简化E2B官方的复杂部署流程,我们将E2B on AWS的部署重构为下述3大核心部分:

E2B Landingzone(基础设施层):通过CloudFormation和Terraform脚本自动化拉起亚马逊云科技上所需的基础资源,包括VPC网络、安全组、负载均衡器、RDS数据库、ECR容器仓库等。支持多可用区部署,确保高可用性和容灾能力。 E2B Infra(组件部署层):通过自动化Bash脚本实现E2B各个组件的编译、打包和部署。包括API服务、构建服务、监控组件等的容器化部署,支持滚动更新和版本回滚。 E2B Runtime(运行时层):基于Nomad调度器管理沙盒实例的生命周期,支持动态扩缩容、资源调度和故障恢复。集成AWS CloudWatch进行监控告警,支持Grafana可视化监控面板。

这种分层架构设计不仅简化了部署复杂度,还提供了良好的可维护性和扩展性,使企业能够根据自身需求灵活调整和优化E2B环境。

2. Amazon Bedrock AgentCore Code Interpreter

Amazon Bedrock AgentCore Code Interpreter是亚马逊云科技推出的企业级

代码执行沙盒解决方案,专为AI智能体的安全代码执行而设计。该服务基于microVM技术,为每个会话提供完全隔离的执行环境,确保代码执行的安全性和可靠性。下图展示了AI Agent通过Tool Use能力使用Code Interpreter的调用过程。

核心特性

安全隔离架构:AgentCore Code Interpreter采用容器化microVM技术,每个会话运行在独立的微虚拟机中,具备独立的CPU、内存和文件系统资源。会话结束时,microVM完全终止并进行内存清理,确保零数据泄露风险。 企业级配置支持:支持多种网络模式配置,包括完全隔离的沙盒模式和支持外部API访问的公网模式。提供灵活的执行角色配置,可精确控制代码对亚马逊云科技资源的访问权限。 多语言运行时支持:内置Python、JavaScript、TypeScript等多种编程语言的预构建运行时环境,支持大文件处理(内联上传最大100MB,S3上传最大5GB)和互联网访问功能。 智能资源管理:提供自动会话超时机制(默认15分钟,可配置最长8小时),支持手动会话停止,确保资源的高效利用和成本控制。

计费模式

AgentCore Code Interpreter采用基于消费的精确计费模式:

CPU 费用:按vCPU实际使用时间计费,仅对活跃处理时间收费 内存费用:按内存实际使用时间计费 按秒计费:不包括I/O等待时间,确保成本效率

这种计费模式确保用户只为实际的代码执行时间付费,相比传统的按实例运行时间计费的方案具有显著的成本优势。资源在代码执行结束后会自动释放(通过超时机制),用户也可以主动停止会话来精确控制成本。

3. Amazon Bedrock AgentCore Browser Tool

Amazon Bedrock AgentCore Browser Tool是亚马逊云科技推出的企业级Web自动化解决方案,为AI智能体提供安全、托管的浏览器交互能力。该工具使AI智能体能够像人类一样与网站进行交互,包括导航网页、填写表单、点击按钮等复杂操作,而无需开发者编写和维护自定义自动化脚本。

核心特性

安全托管的Web 交互:AgentCore Browser Tool在完全托管的环境中提供安全的浏览器交互能力。每个浏览器会话运行在隔离的容器化环境中,确保Web活动与本地系统完全隔离,最大化安全性。 企业级安全特性:提供VM级别的隔离,实现用户会话与浏览器会话的1:1映射,满足企业级安全需求。每个浏览器会话都在独立的沙盒环境中运行,防止跨会话数据泄露和未授权系统访问。 模型无关集成:支持各种AI模型和框架,通过interact()、parse()、discover()等自然语言抽象接口简化浏览器操作。兼容Playwright、Puppeteer等多种自动化框架,为企业环境提供灵活的集成选择。 可视化理解能力:通过截图功能使智能体能够像人类一样理解网站内容,支持动态内容解析和复杂Web应用导航。提供实时可视化监控和会话回放功能,便于调试和审计。 无服务器架构:基于无服务器基础设施自动扩缩容,无需管理底层基础设施。支持低延迟的Web交互,确保良好的用户体验。

工作原理

AgentCore Browser Tool的调用的主要过程如下:

请求处理:当用户发起请求时,大语言模型选择合适的工具并将命令转换为可执行指令 安全执行:命令在受控的沙盒环境中执行,该环境包含无头浏览器和托管库服务器 隔离保护:沙盒提供完整的隔离和安全保护,将Web交互限制在受限空间内 反馈机制:智能体通过截图和执行结果获得反馈,支持自动化任务执行

安全特性

会话隔离:每个浏览器会话运行在独立的容器化环境中,与本地系统完全隔离,确保安全性。 临时会话:浏览器会话是临时的,每次使用后自动重置,防止数据残留和跨会话污染。 会话超时:支持客户端主动终止或TTL自动过期机制,确保资源及时释放。 审计能力:集成CloudTrail日志记录和会话回放功能,提供完整的操作审计轨迹。

计费模式

AgentCore Browser Tool采用基于消费的计费模式:

CPU 费用:按vCPU实际使用时间计费 内存费用:按内存实际使用时间计费 按秒计费:精确计费,仅对活跃处理时间收费

这种计费模式确保用户只为实际的浏览器交互时间付费。

典型应用场景

Web 导航与交互:自动化网站导航、信息提取、内容搜索等任务,支持复杂的多步骤Web操作流程。 工作流自动化:包括表单填写、数据录入、报告生成等重复性Web操作的自动化,大幅提升工作效率。

AgentCore Browser Tool为企业提供了一个安全、可靠、易于集成的Web自动化解决方案,使AI智能体能够高效地处理各种Web相关任务,同时确保企业级的安全性和合规性要求。

四、沙盒方案选型对比建议

基于不同的业务需求和技术要求,我们将常见的沙盒方案对比如下:

|

Sandbox 方案 |

快速 启动/ 暂停/ 恢复/ 销毁 Sandbox |

Sandbox 的易用性 |

安全隔离度 |

简单易用的Sandbox runtime 内存状态管理 |

Sandbox 运维的复杂性 |

Sandbox 最大运行时间 |

计费方式

|

基于AWS lambda 的方案 |对于非冷启动,启动速度快, 10ms级别。

不支持暂停和恢复操作。

不需要销毁操作。

|高

|高

|不支持

|低

|15分钟

|按请求次数+执行时间计费

|

基于普通容器的方案(AWS EKS/ECS) |如果docker image缓存在本地,启动速度快,秒级别启动;否则启动速度慢。

不支持暂停和恢复操作。

|低

|低

|不支持

|高

|没有限制

|按实例运行时间计费

|

基于AWS Bedrock AgentCore 的方案 |启动速度快,100ms级别。

不支持暂停和恢复操作。

|高

|高

|不支持

|低

|8个小时

|按CPU/内存实际使用时间计费

|

基于E2B on AWS 的方案 |如果Sandbox template在local cache中,启动速度很快,100ms级别;否则,启动速度慢。

支持暂停和恢复操作。

|高

|高

|支持(增量快照)

|高

|没有限制

|按沙盒运行时间计费

基于以上对比,对于考虑使用沙盒方案的客户,我们建议根据以下标准进行选择:

选择基于容器的沙盒方案的情况:

  • 仅用于执行大模型生成的简单代码
  • 能够接受极少发生的容器导致底层Linux kernel crash/hung的风险
  • 可以承受潜在的跨容器攻击风险
  • 对成本敏感,需要最经济的解决方案
  • 选择基于MicroVM** **的沙盒方案(如Bedrock AgentCore** **或E2B** **)的情况:

  • 不能接受容器导致的邻居效应和系统级影响
  • 对安全隔离有严格要求,不能容忍跨容器攻击
  • 需要进行复杂的可视化操作(如Computer Use应用)
  • 企业级应用,对稳定性和安全性要求极高

特殊场景建议: 可视化和交互式应用:如果需要实现炫酷的Computer use功能,建议使用E2B方案。E2B提供丰富的Desktop SDK,大大简化了可视化应用的开发工作。自建基于容器的类似方案需要投入大量开发资源。对于浏览器操作Browser Use,建议选择Bedrock AgentCore Browser Tool,可以一键集成云端托管、稳定、安全的浏览器环境,完成信息Agent交互操作。 企业级AI 应用:对于需要企业级安全保障、合规要求和亚马逊云科技生态集成的客户,强烈推荐Amazon Bedrock AgentCore Code Interpreter和Browser Tool。其托管特性、安全隔离能力和与亚马逊云科技服务的深度集成,为企业级AI应用提供了最佳的平衡点。 成本敏感型应用:对于预算有限但仍需要基本安全隔离的场景,可以考虑AWS Lambda方案,特别适合短时间、轻量级的代码执行任务。

总体来说,选择沙盒方案应该基于具体的安全要求、性能需求、运维能力和成本预算进行综合考虑。亚马逊云科技提供的托管服务通常是企业客户的首选,既能满足安全合规要求,又能降低运维复杂性。

本文提到的技术资料链接:

E2B on AWS

https://github.com/aws-samples/sample-e2b-on-aws/blob/main/README.md

Amazon Bedrock AgentCore

https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html

关于Agentic AI** **基础设施的更多实践经验参考,欢迎点击:

Agentic AI基础设施实践经验系列(一):Agent应用开发与落地实践思考

Agentic AI基础设施实践经验系列(二):专用沙盒环境的必要性与实践方案

Agentic AI基础设施实践经验系列(三):Agent记忆模块的最佳实践

Agentic AI基础设施实践经验系列(四):MCP服务器从本地到云端的部署演进

Agentic AI基础设施实践经验系列(五):Agent应用系统中的身份认证与授权管理

Agentic AI基础设施实践经验系列(六):Agent质量评估

Agentic AI基础设施实践经验系列(七):可观测性在Agent应用的挑战与实践

Agentic AI基础设施实践经验系列(八):Agent应用的隐私和安全


云原生游戏网关架构:EKS + APISIX + Graviton 构建高性能游戏服务网关

AWS账单代付阅读(69)

亚马逊AWS官方博客

云原生游戏网关架构:EKS + APISIX + Graviton 构建高性能游戏服务网关

前言

在现代游戏运营环境中,随着游戏服务器规模的不断扩大,传统的服务器代理方案面临着诸多挑战。本文将介绍如何使用 API Six 这一高性能网关来解决大规模游戏服务器代理的问题,特别是针对需要使用多个 Network Load Balancer (NLB) 的场景,提供一个更加优雅和高效的解决方案。

在游戏服务架构中,我们经常遇到以下几个关键挑战:

  • 服务器规模问题
  • 随着游戏的成功运营,服务器数量可能从最初的几台扩展到成百上千台
  • 传统的使用多个 NLB 进行代理的方案在管理和维护上变得越来越复杂
  • 成本问题:每增加一个 NLB 都会带来额外的费用支出
  • 安全性考虑
  • 游戏服务器需要防护各种网络攻击
  • 传统的 TCP 协议缺乏足够的安全保护机制
  • 需要在不影响性能的前提下提供安全保障
  • 运维复杂性
  • 多个 NLB 的配置管理较为繁琐
  • 服务器扩缩容时需要频繁调整负载均衡配置
  • 监控和故障排查的难度随着规模增加而增加

面对这些挑战,我们需要一个更现代化的解决方案。API Six 作为一个高性能、可扩展的网关,结合 TLS 加密,能够很好地解决这些问题。在接下来的内容中,我们将详细介绍如何使用 API Six 构建一个高效、安全、易于管理的游戏服务网关系统。

架构介绍

1. 架构整体说明

APIsix核心组件运行于 Amazon EKS(Elastic Kubernetes Service)集群内部。整个系统主要分为两大访问入口:运维(Ops)和玩家(Players),分别通过独立的 ELB(Elastic Load Balancer)接入.(在此建议咱们在部署环境前可以先手动创建ELB, 在EKS中通过TargetGroupBinding的方式来进行绑定服务,这样可以保证后续服务变更时前端接入ELB为同一个.)

2. 流量入口

  • Ops(运维)入口

运维人员通过 ELB 访问 EKS 集群中的 Admin API,实现对平台的管理和监控。

  • Players(玩家)入口

玩家流量同样通过独立的 ELB 进入 EKS 集群,主要访问 API Gateway,进而路由到具体的游戏服务(Game Server)或平台服务(Platform Service)。

3. EKS 集群内部结构

  • Admin API 层

提供管理接口,供运维人员操作和管理整个系统。

  • etcd 层

作为分布式键值存储,负责服务发现、配置管理等核心功能。Admin API 会将变更写入 etcd,API Gateway 通过 watch 机制实时感知服务变化。

  • API Gateway 层

这一层是玩家访问的主要入口,API Gateway 负责根据 etcd 的服务发现信息,将玩家请求路由到后端的具体服务(如 Platform Service 或 Game Server)。

  • 业务服务层

包含平台服务(Platform Service)和多个游戏服(Game Server1、Game Server2 等),这些服务是最终处理玩家请求的核心业务组件。

方案部署

下面我们将逐步来验证整个方案, 方案中我们将采用模拟TCP协议的游戏服务,通过ELB来实现不同游戏服的路由功能.首先我们需要创建一个实验EKS集群, 参考 EKS文档 创建EKS.

创建好EKS后, 添加用户权限

然后创建Access Entry

使用Helm来安装部署APISix

本文采用的部署目标服务器为亚马逊云科技Graviton机型,可以帮助我们发挥APISix的最大性能. 参考步骤如下:

  • 添加相关helm库

helm repo add apisix https://charts.apiseven.com

helm repo update

  • 整理apisix-values.yaml

service:

type: LoadBalancer

annotations:

service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing

service.beta.kubernetes.io/aws-load-balancer-type: nlb

service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip

service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp

Stream proxy configuration (L4 proxy TCP/UDP)

stream:

enabled: true

only: true # Disable HTTP proxy and only enable stream proxy

tcp:

  • addr: 8888

tls: true

udp: []

Enable APISIX Ingress Controller

ingress-controller:

enabled: false

Enable APISIX Dashboard

dashboard:

enabled: true

config:

conf:

etcd:

endpoints:

  • apisix-etcd:2379

prefix: “/apisix”

authentication:

secret: Admin@2025

expire_time: 3600

users:

  • username: admin # dashboard 用户名

password: Admin@2025 # dashboard 密码

ingress:

enabled: true

className: “alb”

annotations:

alb.ingress.kubernetes.io/scheme: internet-facing

alb.ingress.kubernetes.io/target-type: ip

alb.ingress.kubernetes.io/listen-ports: ‘[{“HTTP”: 80}]’

alb.ingress.kubernetes.io/healthcheck-path: “/dashboard”

alb.ingress.kubernetes.io/healthcheck-protocol: HTTP

alb.ingress.kubernetes.io/healthcheck-port: traffic-port

alb.ingress.kubernetes.io/healthcheck-interval-seconds: ’10’

alb.ingress.kubernetes.io/healthcheck-timeout-seconds: ‘5’

alb.ingress.kubernetes.io/success-codes: ‘200’

alb.ingress.kubernetes.io/healthy-threshold-count: ‘2’

alb.ingress.kubernetes.io/unhealthy-threshold-count: ‘2’

hosts:

  • host: “”

paths:

  • “/*”
  • Basic APISIX configuration

apisix:

image:

repository: apache/apisix

tag: 3.7.0-debian

pullPolicy: IfNotPresent

replicaCount: 2

admin:

enabled: true

service:

type: ClusterIP

etcd configuration

etcd:

image:

repository: bitnami/etcd

tag: 3.5.9

pullPolicy: IfNotPresent

persistence:

storageClass: efs-sc

replicaCount: 3

service:

port: 2379

prefix: “/apisix”

timeout: 30

Resource settings

resources:

limits:

cpu: 1000m

memory: 2Gi

requests:

cpu: 500m

memory: 1Gi

Timezone setting

timezone: “UTC”

AWS EKS specific settings

nodeSelector:

kubernetes.io/os: linux

kubernetes.io/arch: arm64

Tolerations for Graviton nodes (if needed)

tolerations:

  • key: “kubernetes.io/arch”

operator: “Equal”

value: “arm64”

effect: “NoSchedule”

Affinity to prefer Graviton nodes

affinity:

nodeAffinity:

preferredDuringSchedulingIgnoredDuringExecution:

  • weight: 100

preference:

matchExpressions:

  • key: kubernetes.io/arch

operator: In

values:

  • arm64
  • 执行命令更新服务

helm install apisix apisix/apisix –create-namespace –namespace ingress-apisix \

–values apisix-values.yaml

  • 如果此处部署有问题,一定要关注一下当前的storageclass是否存在.

etcd:

persistence:

storageClass: efs-sc # 请格外注意此处,否则可能方案部署失败.

另推荐一个小技巧,如果部署出现问题,可以使用Amazon Q CLI来做诊断,整个过程完全自动化,下面是我的步骤截图.

部署 游戏服务

模拟游戏服代码

!/usr/bin/env python3

import socket

import sys

import threading

Get server name from command line argument

server_name = sys.argv[1] if len(sys.argv) > 1 else “Unknown Server”

def handle_client(client_socket, addr):

print(f”[{server_name}] Connection from {addr}”)

try:

Keep connection alive and echo back data

while True:

data = client_socket.recv(1024)

if not data:

break

print(f”[{server_name}] Received: {data}”)

Echo back the data with server name prefix

response = f”[{server_name}] {data.decode(‘utf-8′, errors=’ignore’)}”.encode()

client_socket.send(response)

except Exception as e:

print(f”[{server_name}] Error handling client: {e}”)

finally:

print(f”[{server_name}] Connection closed: {addr}”)

client_socket.close()

def start_server(port=9000):

server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

Bind to all interfaces

server.bind((‘0.0.0.0’, port))

server.listen(5)

print(f”[*] {server_name} listening on 0.0.0.0:{port}”)

try:

while True:

client, addr = server.accept()

client_handler = threading.Thread(target=handle_client, args=(client, addr))

client_handler.daemon = True

client_handler.start()

except KeyboardInterrupt:

print(f”[{server_name}] Shutting down server”)

server.close()

if __name__ == “__main__”:

start_server(9000)

模拟EKS中的服务部署代码: test-server-1.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

name: test-server-1

namespace: game

labels:

app: test-server-1

spec:

replicas: 1

selector:

matchLabels:

app: test-server-1

template:

metadata:

labels:

app: test-server-1

spec:

containers:

  • name: tcp-server

image: python:3.9-slim

command: [“python”]

args: [“-u”, “/app/tcp-echo-server.py”, “test-server-1”]

ports:

  • containerPort: 9000

volumeMounts:

  • name: script-volume

mountPath: /app

volumes:

  • name: script-volume

configMap:

name: tcp-echo-server

defaultMode: 0777

apiVersion: v1

kind: Service

metadata:

name: gs-1

namespace: game

labels:

app: test-server-1

spec:

selector:

app: test-server-1

ports:

  • port: 9000

targetPort: 9000

protocol: TCP

type: ClusterIP

test-server-2.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

name: test-server-2

namespace: game

labels:

app: test-server-2

spec:

replicas: 1

selector:

matchLabels:

app: test-server-2

template:

metadata:

labels:

app: test-server-2

spec:

containers:

  • name: tcp-server

image: python:3.9-slim

command: [“python”]

args: [“-u”, “/app/tcp-echo-server.py”, “test-server-2”]

ports:

  • containerPort: 9000

volumeMounts:

  • name: script-volume

mountPath: /app

volumes:

  • name: script-volume

configMap:

name: tcp-echo-server

defaultMode: 0777

apiVersion: v1

kind: Service

metadata:

name: gs-2

namespace: game

labels:

app: test-server-2

spec:

selector:

app: test-server-2

ports:

  • port: 9000

targetPort: 9000

protocol: TCP

type: ClusterIP

部署服务

kubectl create namespace game

kubectl create configmap tcp-echo-server –from-file=tcp-echo-server.py –namespace game

kubectl apply -f test-server-1.yaml

kubectl apply -f test-server-2.yaml

配置证书

当使用TLS的SNI功能时,每个你想要使用SNI的域名或主机名都需要一个有效的证书。这是因为SNI允许从同一个IP地址和端口提供多个主机名服务,而证书用于验证服务器的身份并与客户端建立加密连接。使用OpenSSL为2个Game Server服务生成证书文件和密钥文件。

  • 生成证书

openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout gs-1.key -out gs-1.crt -subj “/CN=gs-1.com” openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout gs-2.key -out gs-2.crt -subj “/CN=gs-2.com”

  • 上传证书到apisix

kubectl port-forward -n ingress-apisix svc/apisix-admin 9180:9180 & sleep 3 curl -X POST http://127.0.0.1:9180/apisix/admin/ssls -H ‘X-API-KEY: edd1c9f034335f136f87ad84b625c8f1’ -d ‘ { “cert”: “‘”$(cat gs-1.crt)”‘”, “key”: “‘”$(cat gs-1.key)”‘”, “snis”: [“gs-1.com”] }’ # Create SSL certificate for gs-2.com curl -X POST http://127.0.0.1:9180/apisix/admin/ssls -H ‘X-API-KEY: edd1c9f034335f136f87ad84b625c8f1’ -d ‘ { “cert”: “‘”$(cat gs-2.crt)”‘”, “key”: “‘”$(cat gs-2.key)”‘”, “snis”: [“gs-2.com”] }’ kill %1

  • 验证证书上传

curl -X GET http://127.0.0.1:9180/apisix/admin/ssls -H ‘X-API-KEY: edd1c9f034335f136f87ad84b625c8f1’

配置路由

下面我们基于已经配置好的证书来配置相关的路由信息, 也就是通常我们在平台服配置好证书后,可以调用相关API来配置路由,命令信息如下:

kubectl port-forward -n ingress-apisix svc/apisix-admin 9180:9180 &

sleep 3

curl -i -X POST http://127.0.0.1:9180/apisix/admin/stream_routes -H ‘X-API-KEY: edd1c9f034335f136f87ad84b625c8f1’ -d ‘{

“upstream”: {

“nodes”: {

“gs-1.game.svc.cluster.local:9000”: 1

},

“type”: “roundrobin”

},

“sni”: “gs-1.com”

}’

curl -i -X POST http://127.0.0.1:9180/apisix/admin/stream_routes -H ‘X-API-KEY: edd1c9f034335f136f87ad84b625c8f1’ -d ‘{

“upstream”: {

“nodes”: {

“gs-2.game.svc.cluster.local:9000”: 1

},

“type”: “roundrobin”

},

“sni”: “gs-2.com”

}’

测试基于SNI的访问

首先获取对应APIsix服务的ALB地址

> kubectl get svc -n ingress-apisix apisix-gateway

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

apisix-gateway LoadBalancer 10.100.xxxx.12 k8s-ingressa-apisixga-xxxxxxx-xxx.elb.us-east-1.amazonaws.com 80:30496/TCP,8888:30694/TCP 3d2h

通过上面返回获取的ALB的地址

openssl s_client -connect k8s-ingressa-apisixga-xxxxx.xxxx.elb.ap-northeast-1.amazonaws.com:8888 \

-servername gs-1.com -quiet

openssl s_client -connect k8s-ingressa-apisixga-xxxx.xxxx.elb.ap-northeast-1.amazonaws.com:8888 \

-servername gs-2.com -quiet

至此可以看到通过不同的SNI我就可以访问到不同的游戏服了,也就解决了使用同一个NLB+APIsix的访问不同的游戏服了.

APISix dashboard访问 (Optional)

我们也可以通过Dashboard来访问当前的APIsix系统,查看相关的配置数据. 不过这里需要我们确认一下ALB的certificate ARN 是不是正确.

kubectl get ingress -n ingress-apisix

APISix 部署亚马逊云科技最佳实践

在生产环境中部署 Apache APISIX 时的关键最佳实践,帮助提升稳定性、性能与可维护性。

核心架构与组件分离

为了保证系统可扩展与高可用,推荐将 APISIX 各核心组件解耦部署:

  • 控制平面(etcd):使用单独部署的 etcd 集群存储路由与插件配置,建议在部署APISix的时候直接指向预先部署好的etcd,至少部署 3 节点,开启数据持久化与快照备份,防止单点故障。
  • 数据平面(APISIX 节点):外部请求由多个 APISIX 实例处理,按需水平扩容。每个实例仅负责流量转发与插件执行,配置从 etcd 动态拉取。
  • 运维监控(Prometheus & Grafana):部署专用的监控系统,采集 APISIX 及 etcd 的指标与日志,实时告警与可视化。
  • 部署模式与扩展策略

  • 无状态部署

APISIX 实例本身应保持无状态,所有动态配置均存储在 etcd。容器化或虚拟机化均可,借助 Kubernetes 等平台实现自动伸缩与滚动升级。

  • 水平扩展

根据 QPS 与响应延迟指标,动态扩缩容。建议在 Kubernetes 中配置 HPA(Horizontal Pod Autoscaler),结合自定义指标(如 CPU、内存或请求速率)自动调整实例数。

  • 灰度发布与回滚

配合 Kubernetes Deployment 或其它发布工具,利用 canary 发布策略逐步下发新版本。在出现问题时,可快速回滚至稳定版本,且不中断大部分流量。

  • 优雅退出, 需要保证apisix pod退出时请求都已经处理完毕

lifecycle:

preStop:

exec:

command: [“sh”, “-c”, “sleep 15 && apisix quit”]

网络与安全

  • 高性能网络

采用 L4 负载均衡(如 Nginx Stream、LVS)将流量分发至 APISIX,避免在 L7 层引入过多额外延迟。

  • TLS 终端

如需 HTTPS 支持,推荐在边缘层(L4)终端 TLS,再以 HTTP 通信至 APISIX;或直接在 APISIX 上使用 ssl 插件终端 TLS,并结合 Cert-Manager 自动续签证书。

  • 访问控制与认证

启用 IP 黑白名单、ACL 插件,并根据业务需求接入 JWT、OAuth2 等认证插件,确保后端服务安全。

配置管理与版本控制

  • 基础配置与热更新

把路由、上游服务、插件配置以 YAML/JSON 格式存储于代码仓库,结合 CI/CD 流水线自动同步至 etcd,实现配置即代码(Configuration as Code)。

  • 版本管理

每次配置变更都需打 tag 并在流水线中校验(lint、单元测试、灰度发布),确保变更可追溯、可回滚。

  • 选择稳定版本,并及时跟进社区的更新.
  • 升级版本时需要进行完整的回归测试,保证新版本的兼容性问题.
  • 性能优化与插件治理

  • 实例选择

优先选择Graviton类型主机,经过多轮测试发现Graviton的机型相对于x86机型可以提供至少2两倍的性能提升,具体请参考社区 Benchmark 链接:.

  • 插件开关粒度

仅在需要的路由上启用插件,避免全局加载过多插件导致请求路径冗余执行。

  • 缓存与限流

利用 proxy-cache 插件对静态或可缓存响应进行本地缓存,减轻后端压力;结合 limit-req、limit-count 插件防止流量突发与恶意攻击。

  • 日志与追踪

启用 skywalking、zipkin 或 opentelemetry 插件,将请求链路与指标上报至分布式追踪系统,快速定位性能瓶颈。

监控告警与健康检查

  • 健康探针

在 Kubernetes 中配置 LivenessProbe 与 ReadinessProbe,APISIX 节点异常时可自动剔除。

  • 关键指标

重点监控请求速率、响应延迟、错误率,以及 etcd 的延迟与 leader 选举状态。根据阈值配置告警规则,保证故障可被及时发现与响应

  • 在实际生产中,如果service数量比较多以及并发大的情况下,需要对netfilter.nf_conntrack_max进行调整。建议结合prometheus和grafana进行告警,及时发现问题并优化相关参数。我们也可以通过采用类似C7gn的机型来提升网络吞吐。
  • 灾备与高可用设计

  • 跨可用区部署

将 etcd 和 APISIX 实例分布在多个可用区或机房,保证单区故障时仍有服务可用。

  • 定期备份

对 etcd 数据进行周期性全量与增量备份,并在异地存储;同时验证备份可用性与恢复流程。

通过上述最佳实践,可以构建一套 高可用、可扩展、易运维 的 APISIX 服务部署体系,满足业务在复杂流量下的稳定运行与快速迭代需求。

总结

借助以上方案通过将所有玩家和运维流量先汇聚到单个NLB,再由部署在 EKS 集群内的 Apache APISIX 按 TLS SNI 把请求精准分发到各游戏服,从而用最少的负载均衡实例实现统一路由、动态服务发现和全链路加密,不仅显著降低 NLB 成本和配置复杂度,还能在服务器扩缩容时保持流量无感知切换,成为高并发游戏场景下经济、高效且易维护的网关架构,同时,借助Graviton,APISix能够实现极高的性价比。

参考内容

https://api7.ai/blog/api7-latency

https://apisix.apache.org/blog/2022/08/12/arm-performance-google-aws-azure-with-apisix/


AWS代付、代充值免实名

联系我们阿里云国际免实名