Strands Agents：AWS 模型驱动工具使用 Agent

为什么需要 Strands Agents：硬编码调度 → 模型自主决策

传统上，把订单、库存、物流等多个外部系统接入聊天机器人，靠 if-else 或状态机硬编码「用户说 A 就调 A 接口」。问题有两个：分支组合爆炸——「查订单 + 查物流」这种组合请求需要额外代码路径，意图一变规则就失效；维护成本高，且永远无法覆盖未预枚举的开放式请求。每接入一个新接口，都要改一遍流程代码并重新发布。

Strands Agents 把编排从代码搬到模型推理：每个外部能力注册为工具（Action Group），模型根据用户输入与工具描述（Schema）自主输出「调用哪个函数、传什么参数」；运行时执行工具后把结果回填给模型，模型再决定下一步或给出最终回答。新增一个工具不需要改流程代码，只需注册 Schema 并准备 Agent 版本。用户的开放式提问（「库存不足的话帮我推荐同价位商品」）由模型在推理中拆解为连续多次工具调用。

与 LangChain 的显式图编排、AutoGen 的多 Agent 协商不同，Strands Agents 的差异点在于「模型驱动 + AWS 原生」：工具即 Lambda 函数，会话与别名由 Bedrock Agent Runtime 管理，权限边界用 IAM 控制，适合已有 AWS 存量的企业直接落地生产。

安装与环境配置：3 步就绪（CLI、凭证、SDK）

步骤一：安装 AWS CLI v2。 Strands Agents 的所有管理操作（创建 Agent、查看列表）都通过 AWS CLI 或控制台完成，本地至少需要 CLI 客户端。Linux/macOS 使用官方安装脚本，Windows 使用 MSI 安装包；安装后执行 aws --version 确认版本不低于 2.x。

步骤二：配置 IAM 凭证。 运行 aws configure 依次输入 Access Key ID、Secret Access Key、默认区域（如 us-east-1，Bedrock 在该区域可用）与输出格式。生产环境建议改用 IAM Identity Center 短时凭证，避免把长期密钥写入环境变量。

步骤三：安装 Python SDK 并验证服务可达。 pip install boto3 后，用 aws bedrock-agent list-agents 验证凭证有效、Agent 服务可访问。若返回 AccessDeniedException，检查 IAM 角色是否附加 AmazonBedrockFullAccess 策略。

# 安装 AWS CLI v2（Linux / macOS）curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"unzip awscliv2.zipsudo ./aws/installaws --version # 配置凭证（交互输入 Access Key / Secret / 区域 / 输出格式）aws configure # 安装 Python SDKpip install boto3 --upgrade # 验证：列出已有 Agent，确认服务与凭证可用aws bedrock-agent list-agents --region us-east-1

快速上手：30 分钟跑通第一个工具调用 Agent

最小可用流程 = 一个 Lambda 工具函数 + 一个 Agent + 一次 invoke_agent 调用。工具函数返回库存 JSON；Agent 通过 Action Group 感知该工具；用户提问触发模型输出函数调用，运行时执行并把结果拼进回复。全程在控制台点选 + 一段 Python 客户端代码即可。

1. 创建 Lambda 工具函数：AWS 控制台 → Lambda → 创建函数 → 运行时选 Python 3.12 → 粘贴下方 handler 代码 → Deploy。函数按 product_id 返回值，响应体使用 Bedrock Agent 规定的 messageVersion 1.0 结构。

2. 创建 Agent：Amazon Bedrock 控制台 → Agents → Create Agent → 名称填 inventory-agent → 模型选 Claude 3.5 Sonnet（或控制台可用的最新 Claude 系列）→ IAM 权限选「创建新角色」→ 创建。

3. 添加 Action Group：Agent 详情页 → Action groups → 添加 → 类型选「Define with API schemas」→ Lambda 函数选刚创建的函数 → Schema 选内联 JSON 并粘贴下方 OpenAPI schema → 保存。

4. 准备并测试：点击 Prepare 生成 Agent 版本，记下 Agent ID；测试环境别名直接填 TSTALIASID；运行下方客户端代码发起第一次调用。

结果说明：控制台输出应包含库存 JSON（42 件 / 199 元）。进阶技巧：在 schema 的 description 里写清「何时该调用此函数 + 参数示例」，能显著提升模型选对工具的比例；将测试用的 TSTALIASID 换成正式 Alias 即可做灰度发布。

# 工具函数（Lambda · Python 3.12）import json def lambda_handler(event, context):    params = {p["name"]: p["value"] for p in event.get("parameters", [])}    inventory = {"SKU-001": {"stock": 42, "price": 199.0},                 "SKU-002": {"stock": 0, "price": 89.0}}    data = inventory.get(params.get("product_id", "SKU-001"), {"stock": -1, "price": 0})    return {"messageVersion": "1.0", "response": {        "actionGroup": event.get("actionGroup"),        "function": event.get("function"),        "functionResponse": {"responseBody": {"TEXT": {"body": json.dumps(data)}}}}}

{  "openapi": "3.0.0",  "info": {"title": "Inventory API", "version": "1.0.0"},  "paths": {"/inventory": {"get": {"parameters": [    {"name": "product_id", "in": "query", "required": true,     "schema": {"type": "string", "description": "商品 SKU 编号"}}  ], "responses": {"200": {"description": "ok"}}}}}}

# 客户端：调用 Agent（需替换 AGENT_ID）import boto3 client = boto3.client("bedrock-agent-runtime", region_name="us-east-1")resp = client.invoke_agent(    agentId="AGENT_ID",    agentAliasId="TSTALIASID",    sessionId="session-001",    inputText="查询 SKU-001 的库存和价格",)for event in resp["completion"]:    if "chunk" in event:        print(event["chunk"]["bytes"].decode())

核心能力详解：4 大支柱

支柱一：模型驱动的工具决策。 模型在每轮推理中输出结构化 function call；Agent Runtime 解析后调用注册的 Lambda 函数并回填结果。模型选择工具的依据是函数名、描述与参数 schema 的语义匹配，因此工具的可发现性完全取决于注册信息质量，注册表就是 Agent 的能力边界。

支柱二：多轮会话与状态管理。 客户端以 sessionId 关联会话，Runtime 持久化对话历史，模型能引用前文工具结果决定下一步。「先查库存、再算总价、最后下预订单」这类递进任务靠的就是会话上下文跨轮累积，而不是每轮独立推理。

支柱三：安全护栏（Guardrails）。 Bedrock Guardrails 提供输入输出过滤：敏感词拦截、PII 识别、拒绝主题。Agent 在工具调用前后都会经过护栏过滤，可拦截模型试图调用越权工具或输出敏感内容的场景，是生产上线前的强制层。

支柱四：AWS 原生集成。 Action Group 直接绑定 Lambda 作为工具；知识检索接 Bedrock Knowledge Base（数据源支持 S3）；权限走 IAM Service Role；模型推理走 Bedrock 的 Foundation Models。统一在 AWS 内完成计费、审计与监控，不需要额外组装第三方组件。

生产部署与监控：从上线到运维

部署方式一：工具函数生产化。 Lambda 工具要设计为无状态、幂等，同一请求重复执行结果一致；在 Schema 描述中写明超时语义与重试策略。高频路径开启 Provisioned Concurrency 消除冷启动，并把函数超时从 3 秒调整为与业务耗时匹配的值，避免慢查询工具频繁失败。

部署方式二：接入层封装。 客户端不要直连 Bedrock（避免密钥下放），而是用 API Gateway + 代理 Lambda 封装 invoke_agent，统一做身份认证、限流与请求日志；Agent 版本通过 Alias 管理，用「准备新版本 → 切 Alias → 观察指标 → 回滚」的流程完成灰度发布。

可观测性。 CloudWatch 记录每次 invoke_agent 的 token 消耗与延迟；按 sessionId 维度统计单会话成本与工具调用次数；对工具失败率、Guardrail 命中次数设置 SNS 告警。定期抽查日志中「模型选错工具」的轮次，把高频错误反哺回 schema 描述迭代，形成质量闭环。

<p class="para-label">避坑清单：</p>

<ul class="dash-list"><li>给 Agent 角色挂 AdministratorAccess，模型一旦被引导就可能调用高危工具；应按每个工具拆分 Lambda 独立执行角色，只授予所需的最小权限。</li><li>函数名与描述含糊会导致模型选错工具：相似工具没有「适用场景」说明时，选择准确率明显下降；上线前用典型问句做命中率回归。</li><li>Lambda 默认超时与裸异常：慢查询工具容易超时，抛出的裸异常模型无法理解失败原因；把超时调大，并将错误结构化为 JSON 回传。</li><li>直接编辑线上 Agent 不做版本管理：最新版无法回滚；正式环境应 Prepare 生成版本，用 Alias 指向稳定版本做灰度。</li></ul>

AI 应用场景

常见误区

面试题

参考来源

• webpageAmazon Bedrock 产品介绍页服务能力、定价与开通说明