数据看板的搭建和运维一直是件体力活——选指标、配图表、调筛选器、写 SQL,每个环节都离不开人工介入。Amazon 近期推出的 Bedrock AgentCore + Strands Agents + QuickSight Quick Transforms 组合方案,试图把这条链路缩短到一句话:你用自然语言描述需求,Agent 自动完成看板的生成、数据转换和持续运维。
这套方案的核心思路并不神秘,但落地细节值得拆开看。
从一句话到一个看板:架构怎么跑通
整体架构分三层:
- 交互层:用户通过自然语言发出指令,比如"给我看华东区上季度退货率趋势"。Strands Agents 作为编排框架,接收指令后拆解为多个子任务。
- Agent 运行层:Amazon Bedrock AgentCore 提供 Agent 的托管运行环境——身份认证、工具调用权限、会话状态管理、日志审计都在这里完成。Agent 不再是裸跑的脚本,而是有完整生命周期管理的服务单元。
- 数据与可视化层:Amazon QuickSight 的 Quick Transforms 负责"数据→图表"的最后一跳。它接收 Agent 传来的结构化查询意图,自动选择合适的可视化类型并生成看板。
关键点在于:AgentCore 不是只跑一个 LLM 调用,而是让 Agent 在受控环境中反复调用工具、维护上下文、处理异常。这意味着当用户说"再按品类拆一下",Agent 能记住前一轮的上下文,而不是从零开始。
Strands Agents:编排不是简单的 prompt chaining
Strands Agents 是 Amazon 开源的 Agent 编排框架(GitHub 上已公开),它的设计哲学是"工具驱动而非纯 prompt 驱动"。每个 Agent 的行为由它被赋予的工具集决定,LLM 只负责决策调用哪个工具、传什么参数。
一个典型的 Dashboard Agent 会配备这些工具:
| 工具 | 职责 |
|---|---|
query_data_source |
连接 Athena / Redshift,执行生成的 SQL |
quick_transform |
调用 QuickSight Quick Transforms API,生成可视化 |
validate_schema |
检查用户提到的字段是否存在于数据模型中 |
publish_dashboard |
将生成的看板发布到 QuickSight 并设置权限 |
这种设计的好处是可审计——每一步工具调用都有明确的输入输出,不像纯 prompt 方案那样是个黑盒。在 AgentCore 的托管环境中,这些调用记录自动写入 CloudTrail。
AgentCore 的安全边界:不是所有 Agent 都该有全部权限
企业场景下,数据看板往往涉及敏感指标。AgentCore 的权限模型值得注意:
- Agent 的每个工具调用都走 IAM 策略校验,不是"Agent 拿到一把万能钥匙"。
- 会话级隔离:不同用户的 Agent 会话互不可见,上下文不串。
- 数据访问范围可限定到特定 VPC / 数据源,Agent 无法越界查询。
这意味着你可以放心让销售团队用自然语言生成自己区域的看板,而不担心他们触碰到财务底表。
实践:搭建一个最小可用的 Dashboard Agent
下面给出一个可改造运行的示例,展示如何用 Strands Agents 定义一个 Dashboard Agent,并在本地先跑通逻辑,再部署到 AgentCore。
1. 安装依赖
pip install strands-agents boto3
# 如果要本地测试 QuickSight 调用,还需要配置 AWS CLI
aws configure set region us-east-1
2. 定义 Agent 和工具
from strands import Agent, Tool
import boto3
import json
# --- 工具定义 ---
@Tool(name="query_athena", description="在 Athena 中执行 SQL 查询,返回结果集")
def query_athena(sql: str, database: str = "sales_db") -> dict:
"""执行 Athena 查询,返回结果。生产环境应加结果大小限制和超时控制。"""
athena = boto3.client("athena")
# 启动查询
response = athena.start_query_execution(
QueryString=sql,
QueryExecutionContext={"Database": database},
ResultConfiguration={"OutputLocation": "s3://my-athena-results/"},
)
query_id = response["QueryExecutionId"]
# 等待完成(简化版,生产环境应加轮询间隔和超时)
import time
while True:
status = athena.get_query_execution(QueryExecutionId=query_id)
state = status["QueryExecution"]["Status"]["State"]
if state in ("SUCCEEDED", "FAILED", "CANCELLED"):
break
time.sleep(1)
if state != "SUCCEEDED":
return {"error": f"查询失败: {state}"}
# 获取结果
results = athena.get_query_results(QueryExecutionId=query_id)
rows = []
for row in results["ResultSet"]["Rows"][1:]: # 跳过表头
rows.append([col.get("VarCharValue", "") for col in row["Data"]])
return {"columns": [col["VarCharValue"] for col in results["ResultSet"]["Rows"][0]["Data"]],
"rows": rows}
@Tool(name="create_quicksight_dashboard",
description="根据查询结果和用户意图,调用 QuickSight 创建或更新看板")
def create_quicksight_dashboard(intent: str, data: dict, dashboard_id: str = "auto-generated") -> dict:
"""将数据包装为 QuickSight 数据集并生成分析。
实际生产中会调用 quicksight.create_data_set + create_analysis。
这里展示核心调用逻辑。"""
quicksight = boto3.client("quicksight", region_name="us-east-1")
aws_account_id = boto3.client("sts").get_caller_identity()["Account"]
# 根据意图选择可视化类型(简化逻辑)
viz_map = {
"趋势": "LINE_CHART",
"对比": "BAR_CHART",
"占比": "PIE_CHART",
"分布": "SCATTER_CHART",
}
viz_type = "LINE_CHART" # 默认
for keyword, chart in viz_map.items():
if keyword in intent:
viz_type = chart
break
# 创建数据集(简化:用 Athena 结果 S3 位置作为源)
dataset_response = quicksight.create_data_set(
AwsAccountId=aws_account_id,
DataSetId=f"ds-{dashboard_id}",
Name=f"Agent 生成数据集 - {intent[:30]}",
PhysicalTableMap={
"athena-source": {
"RelationalTable": {
"DataSourceArn": "arn:aws:quicksight:us-east-1:aws:datasource/Athena",
"Schema": "sales_db",
"Name": "regional_sales",
"InputColumns": [
{"Name": col, "Type": "STRING"} for col in data.get("columns", [])
],
}
}
},
LogicalTableMap={
"lt-1": {
"Alias": "AgentQueryResult",
"Source": {"PhysicalTableId": "athena-source"},
}
},
)
return {
"status": "created",
"dataset_id": dataset_response["DataSetId"],
"viz_type": viz_type,
"intent": intent,
}
# --- Agent 定义 ---
dashboard_agent = Agent(
name="dashboard-automation-agent",
description="根据用户的自然语言需求,查询数据并生成 QuickSight 看板",
tools=[query_athena, create_quicksight_dashboard],
model="us.anthropic.claude-3-5-sonnet-20241022-v2:0", # Bedrock 模型 ID
)
# --- 运行 ---
if __name__ == "__main__":
result = dashboard_agent.invoke(
"帮我看看华东区过去三个季度的退货率趋势,生成一个看板"
)
print(json.dumps(result, indent=2, ensure_ascii=False))
运行前需要确保:
- AWS CLI 已配置,且有 Athena / QuickSight 的 IAM 权限。
- Athena 数据库
sales_db和对应 S3 输出桶已存在。 - 如无真实数据源,可将
query_athena替换为返回模拟数据的函数来先验证编排逻辑。
3. 部署到 AgentCore(YAML 配置)
本地验证通过后,将 Agent 注册到 Bedrock AgentCore 托管环境:
# agentcore-deployment.yaml
apiVersion: agentcore.aws/v1
kind: Agent
metadata:
name: dashboard-automation-agent
description: 自然语言驱动的数据看板生成与运维 Agent
spec:
runtime:
type: strands
version: "0.5"
model:
provider: anthropic
modelId: claude-3-5-sonnet
tools:
- name: query_athena
type: custom
iamRole: arn:aws:iam::123456789012:role/AgentCore-AthenaQueryRole
config:
database: sales_db
outputLocation: s3://my-athena-results/
resultSizeLimit: 1000
- name: create_quicksight_dashboard
type: custom
iamRole: arn:aws:iam::123456789012:role/AgentCore-QuickSightRole
config:
allowedVizTypes: [LINE_CHART, BAR_CHART, PIE_CHART, SCATTER_CHART]
security:
sessionIsolation: true
dataAccessScope:
athenaWorkgroups: [primary]
quickSightNamespace: default
auditLog:
cloudTrail: true
s3Archive: s3://agentcore-audit-logs/
部署命令:
# 使用 AgentCore CLI 部署(假设已安装)
agentcore deploy --config agentcore-deployment.yaml --region us-east-1
# 验证 Agent 状态
agentcore describe-agent --name dashboard-automation-agent --region us-east-1
上述 YAML 结构和 CLI 命令基于 AgentCore 公开文档的通用模式整理。具体字段名和版本号请以 AWS 官方最新文档为准,部署前务必对照更新。
落地前要想清楚的几件事
数据模型必须先梳理好。 Agent 能自动生成 SQL,但前提是它知道有哪些表、哪些字段、字段含义是什么。建议在 Athena 中维护一份 GLUE Data Catalog 的完整描述,包括字段注释和表关系。这是 Agent 不猜错的基础。
可视化选择不能完全交给 LLM。 当前方案中,LLM 根据意图关键词选择图表类型,这在大方向上可行("趋势"→折线图),但细节场景容易出错(多维度对比该用堆叠柱状图还是分组柱状图)。建议在 create_quicksight_dashboard 工具中加入业务规则校验层,LLM 给出候选,规则层做最终裁决。
成本控制要前置。 Athena 按扫描数据量计费,QuickSight 按会话计费。如果 Agent 被高频调用,务必在工具配置中加 resultSizeLimit 和查询超时,避免一条模糊的"帮我看看所有数据"触发全表扫描。
迭代比一次性完美更重要。 先让 Agent 能跑通"单指标单维度"的简单场景,再逐步叠加多维度、筛选器、联动分析。Agent 的工具集和权限也应该从最小集开始,验证稳定后再扩展。
这套方案的价值不在"用 AI 替代人做看板"——那是个过度承诺。它的真正意义是:把看板搭建中重复性最高的环节(查数据、选图表、配格式)交给 Agent,让人专注于指标定义和业务解读。如果你已经在用 QuickSight 且数据源在 Athena / Redshift 上,这是目前最直接可试的路径。