单 Agent 能解决很多问题,但一旦任务涉及并行推理、上下文共享和执行可追溯,单线程的调用链就撑不住了。AWS 近期发布的集成方案把三个组件拼成了一条完整链路:Strands Agents 负责多 Agent 无服务器编排,NVIDIA NIM 提供 GPU 加速推理端点,Amazon Bedrock AgentCore 托管运行时、共享记忆和可观测性。本文拆解这套架构,并给出一个可直接改造的多 Agent 营销内容审查系统示例。
三层架构各自解决什么问题
先看每个组件的职责边界,再看它们怎么串起来。
Strands Agents——编排层
Strands 是 AWS 开源的多 Agent SDK,核心思路是把每个 Agent 定义为一个具备工具集和提示词的独立单元,然后通过"工具调用另一个 Agent"的方式实现协作。它不依赖固定拓扑,Agent 之间是动态调用关系,编排逻辑写在 Agent 的工具定义里,而不是写在中央调度器里。这种设计让新增 Agent 只需要注册一个新工具,不需要改编排引擎。
NVIDIA NIM——推理层
NIM 把 NVIDIA 的模型(Llama、Mixtral 等)打包成容器化推理端点,暴露 OpenAI 兼容 API。关键优势是 GPU 加速:在同等模型下,NIM 端点的吞吐和首 token 延迟明显优于通用 CPU 推理服务。对于多 Agent 场景,这意味着并行调用多个 Agent 时推理不会成为瓶颈。
Bedrock AgentCore——运行与治理层
AgentCore 提供三个能力: - 托管运行时:Agent 以无服务器函数形式运行,自动扩缩容,不用管基础设施。 - 共享记忆:跨 Agent 的上下文持久化,Agent A 写入的审查结论 Agent B 可以直接读取,不需要在提示词里手动拼接。 - 内置可观测性:每次 Agent 调用的 trace、token 用量、工具调用链路自动记录,不需要自己埋点。
三层合在一起的效果:Strands 定义"谁做什么",NIM 保证"做得快",AgentCore 保证"做得稳、看得见"。
并行推理 + 上下文共享:营销审查系统的设计
原始示例是一个营销内容审查系统,任务是对一条营销文案同时做品牌合规、事实准确性和受众匹配度三项审查,最后汇总结论。三项审查可以并行执行,但汇总 Agent 需要读取三个审查 Agent 的结果——这正是共享记忆发挥作用的地方。
流程如下:
营销文案输入
│
├─→ 品牌合规审查 Agent ──→ 写入共享记忆
├─→ 事实准确性审查 Agent ──→ 写入共享记忆
└→ 受众匹配度审查 Agent ──→ 写入共享记忆
│
└─→ 汇总 Agent ←── 从共享记忆读取三项结论
│
└─→ 输出最终审查报告
三个审查 Agent 并行调用 NIM 端点推理,各自独立运行;汇总 Agent 在三个审查完成后从 AgentCore 的共享记忆中拉取结果,不需要把三个 Agent 的输出塞进一条超长提示词里。
可改造的代码示例
下面是一个最小可运行的 Strands Agents 多 Agent 定义,展示审查 Agent 和汇总 Agent 的编排方式。你需要先安装 Strands SDK 并配置 NIM 端点。
# 安装依赖
# pip install strands-agents strands-agents-tools
from strands import Agent
from strands.tools.agent_tool import agent_tool
# ---- 定义审查 Agent ----
# 品牌合规审查 Agent
brand_reviewer = Agent(
model="nim", # 指向 NVIDIA NIM 端点,需在环境变量中配置 NIM_BASE_URL 和 NIM_API_KEY
system_prompt="""你是一个品牌合规审查专家。
对输入的营销文案检查以下问题:
- 是否包含未经授权的品牌引用
- 是否有误导性比较
- 是否违反广告法常见禁用词
输出格式:JSON,包含 verdict(pass/fail) 和 details 字段。""",
tools=[], # 审查 Agent 不需要额外工具,纯推理
)
# 事实准确性审查 Agent
fact_reviewer = Agent(
model="nim",
system_prompt="""你是一个事实准确性审查专家。
对输入的营销文案检查:
- 数据引用是否有来源
- 技术声明是否可验证
- 是否存在夸大或虚假陈述
输出格式:JSON,包含 verdict 和 details 字段。""",
tools=[],
)
# 受众匹配度审查 Agent
audience_reviewer = Agent(
model="nim",
system_prompt="""你是一个受众匹配度审查专家。
对输入的营销文案检查:
- 语气是否匹配目标受众(如开发者、企业决策者)
- 术语使用是否恰当
- 是否有文化或地域敏感问题
输出格式:JSON,包含 verdict 和 details 字段。""",
tools=[],
)
# ---- 把审查 Agent 注册为汇总 Agent 的工具 ----
@agent_tool(agent=brand_reviewer, name="brand_review", description="调用品牌合规审查 Agent")
def brand_review_tool(content: str) -> str:
"""将营销文案交给品牌合规审查 Agent 处理"""
return brand_reviewer(content)
@agent_tool(agent=fact_reviewer, name="fact_review", description="调用事实准确性审查 Agent")
def fact_review_tool(content: str) -> str:
"""将营销文案交给事实准确性审查 Agent 处理"""
return fact_reviewer(content)
@agent_tool(agent=audience_reviewer, name="audience_review", description="调用受众匹配度审查 Agent")
def audience_reviewer_tool(content: str) -> str:
"""将营销文案交给受众匹配度审查 Agent 处理"""
return audience_reviewer(content)
# ---- 定义汇总 Agent ----
coordinator = Agent(
model="nim",
system_prompt="""你是营销内容审查汇总 Agent。
收到营销文案后,你需要同时调用三个审查工具:
1. brand_review —— 品牌合规
2. fact_review —— 事实准确性
3. audience_review —— 受众匹配度
收到三个审查结果后,汇总成一份最终报告,包含:
- 总体结论(全部 pass 才算通过)
- 各项审查摘要
- 改进建议(如有 fail 项)""",
tools=[brand_review_tool, fact_review_tool, audience_reviewer_tool],
)
# ---- 运行 ----
campaign_text = """
CloudDB Pro 是全球最快的云数据库,性能比 AWS Aurora 快 10 倍。
已服务 500 万开发者,零宕机记录。
适合所有企业,从初创到跨国集团。
"""
result = coordinator(campaign_text)
print(result)
运行前需要配置的环境变量:
# NVIDIA NIM 端点配置(替换为你的实际端点)
export NIM_BASE_URL="https://integrate.api.nvidia.com/v1"
export NIM_API_KEY="nvapi-xxxx"
# 如果部署在 Bedrock AgentCore 上,还需要配置 AWS 凭证
export AWS_REGION="us-east-1"
export AWS_ACCESS_KEY_ID="AKIAxxxx"
export AWS_SECRET_ACCESS_KEY="xxxx"
这段代码展示了 Strands 的核心编排模式:汇总 Agent 把三个审查 Agent 当作工具调用。Strands SDK 会自动处理工具调用协议,不需要你手动管理消息传递。当汇总 Agent 的提示词要求"同时调用三个审查工具"时,Strands 会在一次推理循环中发起三个并行工具调用。
部署到 Bedrock AgentCore:从本地到生产
本地跑通后,下一步是把 Agent 部署到 AgentCore 托管运行时。AgentCore 用 Lambda 风格的无服务器函数运行 Agent,自动处理扩缩容和冷启动。
部署配置示例(YAML):
# agentcore-deploy.yaml
agents:
brand_reviewer:
runtime: python3.12
model_endpoint: nim # 指向 NIM 端点
memory: shared # 启用 AgentCore 共享记忆
trace: enabled # 启用内置 trace
fact_reviewer:
runtime: python3.12
model_endpoint: nim
memory: shared
trace: enabled
audience_reviewer:
runtime: python3.12
model_endpoint: nim
memory: shared
trace: enabled
coordinator:
runtime: python3.12
model_endpoint: nim
memory: shared
trace: enabled
tools:
- brand_reviewer
- fact_reviewer
- audience_reviewer
部署后,AgentCore 自动提供: - Trace 可视化:每次审查调用的 token 用量、延迟、工具调用链路在 AgentCore 控制台可查。 - 共享记忆持久化:审查 Agent 的结论写入共享记忆后,即使汇总 Agent 在另一次调用中才读取,数据也不会丢失。 - 自动扩缩容:三个审查 Agent 并行运行时,AgentCore 按请求量独立扩缩每个 Agent 的实例。
可观测性:不只是看日志
多 Agent 系统最头疼的问题是"出了错不知道是哪个 Agent 的责任"。AgentCore 的内置 trace 解决了这个问题。
每次协调器调用会生成一条完整 trace,结构如下:
trace_id: abc-123
├── coordinator.invoke (token: 150, latency: 1.2s)
│ ├── brand_review_tool.invoke (token: 800, latency: 3.1s)
│ ├── fact_review_tool.invoke (token: 900, latency: 3.4s)
│ ├── audience_review_tool.invoke (token: 700, latency: 2.8s)
│ └── coordinator.summarize (token: 200, latency: 0.8s)
你可以直接看到哪个审查 Agent 响应最慢、哪个 token 消耗最高。如果事实准确性审查延迟异常,trace 会定位到 fact_review_tool.invoke,不需要翻日志猜测。
适用场景与边界
这套架构不限于营销审查。同样的并行推理 + 共享记忆模式适用于:
- 数字助手:多个专业 Agent(日程、邮件、文档)并行处理用户请求,汇总 Agent 整合回复。
- 审查自动化:代码审查、合规审查、安全审查并行执行,汇总输出审查报告。
- RAG 管道:多个检索 Agent 从不同知识库并行检索,汇总 Agent 合并去重后生成回答。
但有几个边界需要注意:
| 关注点 | 说明 |
|---|---|
| NIM 端点可用性 | NIM 目前支持的模型列表有限,如果你的业务需要特定微调模型,可能需要自部署 NIM 容器 |
| 共享记忆一致性 | 并行写入共享记忆时,AgentCore 保证写入持久化但不保证强一致性——汇总 Agent 读取时可能遇到某个审查 Agent 尚未写入完成的情况,需要在汇总提示词中加重试逻辑 |
| 成本控制 | 三个审查 Agent 并行推理意味着三倍 token 消耗,对于高频场景需要评估 NIM 推理成本和 AgentCore 运行时成本 |
| 冷启动 | AgentCore 无服务器函数有冷启动延迟,首次调用可能比后续调用慢 2-5 秒 |
上手清单
如果你准备尝试这套架构,按这个顺序推进:
- 本地验证:用上面的 Python 代码在本地跑通多 Agent 编排,确认 Strands SDK 的工具调用协议正常工作。
- 配置 NIM 端点:在 NVIDIA API Catalog 注册,获取 API Key,测试端点可达性。
- 部署到 AgentCore:把本地 Agent 定义打包为 Lambda 部署包,用 AgentCore CLI 或控制台部署。
- 验证 trace:发起一次完整审查调用,在 AgentCore 控制台确认 trace 链路完整。
- 压测并行:用 10-20 条文案并发调用,观察三个审查 Agent 是否真正并行、扩缩容是否生效。
- 加共享记忆重试:在汇总 Agent 提示词中加入"如果某项审查结果缺失,重新调用对应工具"的逻辑,兜住并行写入的时序问题。
这套组合的核心价值不是某个单一组件,而是编排、推理、治理三层解耦——你可以替换 NIM 端点为其他推理服务,也可以替换 Strands 为其他编排框架,AgentCore 的共享记忆和 trace 仍然有效。先跑通最小链路,再按业务需要替换组件,是更稳妥的路径。