用 Amazon Bedrock AgentCore 搭一个 AWS 支持助手

预计阅读时间：10 分钟

AWS 支持排障经常卡在几个系统之间：CloudWatch 里看日志，文档站里查限制和配置，re:Post 里找相似案例，必要时再去创建 Support Case。这个方案把这些动作收进一个对话入口：用 Amazon Bedrock AgentCore 承载智能体，用 Strands Agents 做编排，通过 Model Context Protocol，也就是 MCP，连接 AWS 服务和知识源。

这个助手解决的不是“聊天”，而是排障链路

这类支持助手的关键价值不在于让模型回答得更像人，而在于把上下文拉齐。一个真实问题通常长这样：

某个 Lambda 或 ECS 服务出现错误率升高。
工程师需要从 CloudWatch Logs 找异常片段。
再去 AWS 文档确认错误码、服务配额或推荐配置。
如果内部无法处理，还要整理现象并创建 AWS Support Case。

来源方案把这些步骤放进一个会话界面。AgentCore 提供运行智能体的基础能力，Strands Agents 负责工具调用和流程编排，MCP 则把 CloudWatch、AWS 文档、AWS re:Post、Support Case 等能力包装成模型可以调用的上下文工具。

这意味着开发者问的不是“CloudWatch 是什么”，而可以是：

请检查过去 30 分钟 /aws/lambda/payment-api 的 ERROR 日志，找出最可能的根因；如果需要，请搜索 AWS 文档和 re:Post，并给出是否应创建支持案例的建议。

AgentCore、Strands Agents 和 MCP 的分工

可以把这套架构拆成三层：

Amazon Bedrock AgentCore：承载和运行智能体，让它具备对话、工具调用和服务集成的执行环境。
Strands Agents：作为智能体编排框架，决定什么时候调用哪个工具，如何把工具结果继续交给模型推理。
MCP：定义工具接口，让日志查询、文档搜索、社区知识检索、创建支持案例这些能力以统一方式暴露给智能体。

这个分工很重要。没有 MCP 时，你往往会把每个工具调用硬编码进某个 Agent 实现里；工具越多，耦合越重。用 MCP 之后，日志、文档、re:Post、Support Case 可以作为独立工具服务演进，Agent 侧只关注“何时调用、如何综合结果”。

可以这样实践：用一条脚本部署基础环境

来源方案提到整体通过单个脚本和 AWS CloudFormation 部署，并包含一个基于 AWS Amplify 的 Web 前端。下面是一个可改造的部署脚本骨架，适合放在 deploy.sh 中。它不声称等同于原方案的完整模板，而是展示这种部署方式应该如何组织参数、栈名和前端输出。

运行前需要替换：

AWS_REGION：你的目标区域。
STACK_NAME：CloudFormation 栈名。
TEMPLATE_FILE：你的 CloudFormation 模板路径。
AMPLIFY_APP_NAME：前端应用名。

#!/usr/bin/env bash
set -euo pipefail

AWS_REGION="us-east-1"
STACK_NAME="bedrock-support-companion"
TEMPLATE_FILE="cloudformation/template.yaml"
AMPLIFY_APP_NAME="aws-support-companion-ui"

aws cloudformation deploy \
  --region "$AWS_REGION" \
  --stack-name "$STACK_NAME" \
  --template-file "$TEMPLATE_FILE" \
  --capabilities CAPABILITY_NAMED_IAM \
  --parameter-overrides \
    AmplifyAppName="$AMPLIFY_APP_NAME"

aws cloudformation describe-stacks \
  --region "$AWS_REGION" \
  --stack-name "$STACK_NAME" \
  --query 'Stacks[0].Outputs' \
  --output table

如果你把它保存为 deploy.sh，可以这样执行：

chmod +x deploy.sh
./deploy.sh

CloudFormation 模板里通常会包含 IAM Role、AgentCore 相关资源、MCP 工具服务、Amplify 前端配置等。权限要尽量收窄，特别是 CloudWatch Logs 查询和 Support Case 创建能力，不应该给成宽泛的管理员权限。

可以这样实践：把 MCP 工具声明成清晰的能力边界

MCP 的价值是把工具能力“显式化”。下面是一个最小化的 MCP 工具清单示例，用 YAML 表达工具边界。它是概念性配置，字段名需要按你实际使用的 MCP 服务器或 Strands Agents 集成方式调整。

mcpServers:
  cloudwatchLogs:
    command: "python"
    args:
      - "mcp_servers/cloudwatch_logs.py"
    tools:
      - name: "query_logs"
        description: "Query CloudWatch Logs for a log group and time window"
        inputSchema:
          type: "object"
          required:
            - "logGroupName"
            - "startTime"
            - "endTime"
          properties:
            logGroupName:
              type: "string"
            startTime:
              type: "string"
              description: "ISO-8601 timestamp"
            endTime:
              type: "string"
              description: "ISO-8601 timestamp"
            filterPattern:
              type: "string"

  awsDocs:
    command: "python"
    args:
      - "mcp_servers/aws_docs.py"
    tools:
      - name: "search_docs"
        description: "Search AWS documentation for service guidance"
        inputSchema:
          type: "object"
          required:
            - "query"
          properties:
            query:
              type: "string"

  supportCases:
    command: "python"
    args:
      - "mcp_servers/support_cases.py"
    tools:
      - name: "create_support_case"
        description: "Create an AWS Support case after user confirmation"
        inputSchema:
          type: "object"
          required:
            - "subject"
            - "description"
            - "serviceCode"
            - "severityCode"
          properties:
            subject:
              type: "string"
            description:
              type: "string"
            serviceCode:
              type: "string"
            severityCode:
              type: "string"

注意 create_support_case 的描述里写了 “after user confirmation”。这是生产环境里非常重要的一条边界：查询日志和搜索文档可以自动执行，但创建支持案例会产生正式工单，最好要求用户确认。

对话入口应该给模型足够明确的任务

这种支持助手不是万能问答框。要让它稳定工作，提示词应该包含目标、范围、时间窗口和可执行动作。例如：

你是 AWS 支持排障助手。

任务：分析 CloudWatch Logs 中的错误，并给出下一步处理建议。
范围：只检查 /aws/lambda/payment-api。
时间窗口：过去 30 分钟。
允许动作：
1. 查询 CloudWatch Logs。
2. 搜索 AWS 官方文档。
3. 查询 AWS re:Post 社区知识。
4. 在我明确确认后，创建 AWS Support Case。

输出要求：
- 用三句话总结最可能的根因。
- 列出你检查过的日志模式或错误码。
- 给出下一步操作。
- 如果建议创建 Support Case，先生成草稿，不要直接提交。

这类提示词比“帮我看看 AWS 问题”更可靠，因为它限制了工具范围，也明确了高风险动作必须等待确认。

上线前要盯住四个风险

日志访问是第一道边界。CloudWatch Logs 里可能包含用户标识、请求参数、内部错误栈，Agent 的 IAM 权限和日志脱敏策略要一起设计。

工具调用是第二道边界。搜索文档和 re:Post 属于低风险动作，但创建 Support Case 属于外部副作用，应该加入确认步骤、审计记录和最小权限。

成本是第三道边界。长日志窗口、频繁文档检索、多轮模型推理都会叠加成本。建议给日志查询设置默认时间范围，比如 15 分钟或 30 分钟，并要求用户显式扩大范围。

准确性是第四道边界。智能体可以汇总证据、生成排障路径，但不能替代工程判断。输出里应保留“证据来自哪里”，比如日志组、时间窗口、文档条目或 re:Post 线索。

采用建议

适合先从一个高频服务开始试点，比如支付、登录、订单这类值班压力大的系统。第一版只开放 CloudWatch 日志分析和文档搜索，跑通后再接 re:Post 和 Support Case。等团队确认提示词、权限、审计和成本控制都稳定，再把它作为统一支持入口推广。

一个实用的验收清单：

Agent 能根据时间窗口查询指定 CloudWatch Log Group。
每次工具调用都有可追踪记录。
创建 Support Case 前必须用户确认。
IAM 权限按工具拆分，不使用管理员权限。
前端会显示模型结论，也显示关键证据来源。
默认限制日志查询范围，避免一次会话扫过大量日志。

把这些边界打牢，AI 支持助手就不只是一个新聊天窗口，而是一个能把排障动作串起来的工程工具。