商业智能（BI）团队每天都在和海量数据打交道——查报表、写 SQL、解读趋势、回答业务方反复追问的"为什么"。传统 BI 工具把数据摆在你面前，但解读和行动仍然依赖人的经验。把 AI Agent 引入 BI 流程，不是让模型替你做决策，而是让它在数据检索、趋势归纳、异常定位这些重复性环节上提速，把人的注意力留在判断和决策上。
Amazon 最近推出了 Bedrock AgentCore，提供了一个面向 Agent 的托管运行环境。OPLOG 的实践给出了一个清晰的路径：用 Strands Agents SDK 定义 Agent 逻辑，部署到 AgentCore 运行，再通过 Bedrock Knowledge Base 做 RAG，让 Agent 能检索企业内部的知识和指标定义。下面拆解这条路径的关键环节。
三层架构：Agent 定义、托管运行、知识增强
OPLOG 构建了三个 BI Agent，分别覆盖不同职能。整体架构可以拆成三层：
- Agent 逻辑层：用 Strands Agents SDK 定义每个 Agent 的工具集、对话策略和路由逻辑。SDK 是 Amazon 开源的 Python 框架，核心思路是"Agent = Model + Tools + Instructions"，一个 Agent 的行为由你给它挂的工具和指令决定。
- 托管运行层：Bedrock AgentCore 提供了 Agent 的部署、版本管理、运行监控和自动扩缩容。你不再需要自己搭 API 网关、管理容器、处理并发——AgentCore 把这些包了。
- 知识增强层：Bedrock Knowledge Base 把企业内部的指标字典、报表说明、业务术语等文档做成向量索引，Agent 在回答时先检索再生成，避免凭模型"记忆"胡编。
模型侧，OPLOG 选了 Anthropic Claude Sonnet——在工具调用（tool use）和长上下文理解上表现稳定，适合需要多步推理的 BI 场景。
Strands Agents SDK：定义一个 BI Agent 的最小骨架
Strands 的设计哲学是轻量。一个 Agent 的核心定义就是三样东西：模型、工具列表、系统提示词。下面是一个可以直接改造运行的 BI 数据查询 Agent 示例：
from strands import Agent, tool
from strands.models.bedrock import BedrockModel
# 1. 定义模型 — 使用 Bedrock 上的 Claude Sonnet
model = BedrockModel(
model_id="anthropic.claude-3-5-sonnet-20241022-v2:0",
region="us-east-1",
)
# 2. 定义 Agent 可用的工具
@tool
def query_sales_database(sql: str) -> dict:
"""执行 SQL 查询，返回销售数据库的结果。
只允许 SELECT 语句，禁止 DELETE/UPDATE/DROP。
sql: 要执行的 SQL 查询语句
"""
# 实际部署时替换为你的数据库连接逻辑
# 这里用伪返回演示结构
if not sql.strip().upper().startswith("SELECT"):
return {"error": "只允许 SELECT 查询，禁止修改操作"}
# 示例：连接 Redshift / Athena 执行查询
# result = execute_query_against_warehouse(sql)
return {
"columns": ["month", "region", "revenue"],
"rows": [
["2025-01", "华东", 1280000],
["2025-01", "华南", 960000],
["2025-02", "华东", 1350000],
],
"row_count": 3,
}
@tool
def lookup_metric_definition(metric_name: str) -> str:
"""从知识库中查找指标的业务定义和计算口径。
metric_name: 指标名称，如 'GMV'、'客单价'
"""
# 实际部署时对接 Bedrock Knowledge Base 的 Retrieve API
# response = bedrock_kb_client.retrieve(
# knowledgeBaseId="KB_ID",
# retrievalQuery={"text": metric_name}
# )
return f"指标 '{metric_name}' 定义：订单金额总和（含退款前），统计口径为下单时间而非支付时间。"
# 3. 组装 Agent
bi_agent = Agent(
model=model,
tools=[query_sales_database, lookup_metric_definition],
system_prompt="""你是一个商业智能数据助手。
工作原则：
- 用户提到指标时，先用 lookup_metric_definition 确认口径，再查询数据。
- 生成 SQL 前先向用户确认查询意图，避免误查。
- 只执行 SELECT 查询，绝不修改数据。
- 回答时附带数据来源和查询时间范围。
""",
)
# 4. 运行对话
response = bi_agent("华东区最近两个月的营收趋势怎么样？")
print(response)
运行前需要确保：
- 已配置 AWS 凭证（
aws configure或环境变量），且有权调用 Bedrock 的 Claude Sonnet。 - 安装依赖：
pip install strands-agents strands-agents-tools。 query_sales_database和lookup_metric_definition的实际实现需要替换为你自己的数据源连接和 Knowledge Base 调用。
关键设计点：工具定义中的 docstring 不是注释，是 Agent 看到的工具说明。Claude Sonnet 会根据 docstring 决定何时调用哪个工具、传什么参数。写清楚入参含义和约束（比如"只允许 SELECT"），比在 system prompt 里反复强调更有效。
部署到 Bedrock AgentCore：从本地脚本到托管服务
本地跑通了 Agent 逻辑后，下一步是部署到 AgentCore，让它变成一个可被业务系统调用的 API 服务。AgentCore 目前通过 AWS CLI 和 CloudFormation 管理。一个最小部署配置如下：
# agentcore-deployment.yaml
AWSTemplateFormatVersion: "2010-09-09"
Description: "Deploy BI Agent to Bedrock AgentCore"
Resources:
BIAgent:
Type: AWS::Bedrock::AgentCoreAgent # 假设的资源类型，按实际 API 调整
Properties:
AgentName: "bi-data-assistant"
Description: "商业智能数据查询与指标解读助手"
ModelIdentifier: "anthropic.claude-3-5-sonnet-20241022-v2:0"
RuntimeRoleArn: !Ref AgentRuntimeRole
# 挂载工具定义
Tools:
- Name: "query_sales_database"
Description: "执行 SQL 查询销售数据库"
InputSchema:
type: object
properties:
sql:
type: string
description: "SELECT 查询语句"
required: ["sql"]
- Name: "lookup_metric_definition"
Description: "查找指标业务定义"
InputSchema:
type: object
properties:
metric_name:
type: string
required: ["metric_name"]
# 关联 Knowledge Base
KnowledgeBaseIds:
- !Ref MetricDictionaryKB
MetricDictionaryKB:
Type: AWS::Bedrock::KnowledgeBase
Properties:
Name: "bi-metric-dictionary"
Description: "指标定义与业务术语知识库"
KnowledgeBaseConfiguration:
Type: "VECTOR"
VectorKnowledgeBaseConfiguration:
EmbeddingModelArn: "arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-embed-text-v1"
StorageConfiguration:
Type: "OPENSEARCH_SERVERLESS"
OpensearchServerlessConfiguration:
CollectionArn: !GetAtt MetricKBCollection.Arn
VectorIndexName: "metric-index"
AgentRuntimeRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service: bedrock.amazonaws.com
Action: sts:AssumeRole
ManagedPolicyArns:
- arn:aws:iam::aws:policy/AmazonBedrockFullAccess
Policies:
- PolicyName: AllowDataQuery
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Action:
- athena:StartQueryExecution
- athena:GetQueryResults
- redshift-data:ExecuteStatement
- redshift-data:GetStatementResult
Resource: "*"
部署命令：
# 创建 Knowledge Base 的数据源（上传指标字典文档）
aws s3 cp ./metric_dictionary.pdf s3://my-bi-kb-docs/
# 部署 AgentCore Agent
aws cloudformation deploy \
--template-file agentcore-deployment.yaml \
--stack-name bi-agent-stack \
--capabilities CAPABILITY_IAM
# 验证 Agent 已上线
aws bedrock-agent list-agents --region us-east-1
注意：AgentCore 的资源类型和 API 名称可能随服务更新变化，部署前请对照最新 AWS 文档确认。上述 YAML 中的资源类型为示意结构，实际字段需按当前 API 规范调整。
AgentCore 的价值在于：你不再需要自己写 FastAPI/Flask 包装 Agent、处理并发限流、管理版本回滚。AgentCore 还内置了对话持久化，Agent 的多轮对话状态由平台维护，业务系统只需每次传入 session ID。
RAG 的实际作用：让 Agent 不瞎猜指标口径
BI 场景里，"GMV"在不同公司可能指下单金额、支付金额、还是扣退款后的净额。模型不知道这些内部定义，如果不做 RAG，Agent 就会用自己的通用理解回答——这在 BI 场景是致命的。
OPLOG 的做法是把指标字典、报表说明、数据口径文档全部灌入 Bedrock Knowledge Base。Agent 在回答涉及指标的问题时，先检索 Knowledge Base，拿到精确定义，再基于定义去查数据、做解读。
在 Strands SDK 中，你可以把 Knowledge Base 检索封装成一个工具（如上面示例中的 lookup_metric_definition），也可以直接用 Bedrock AgentCore 的内置 Knowledge Base 关联——AgentCore 会在每次推理时自动判断是否需要检索，不需要你手动编排调用顺序。
一个实用的建议：知识库文档不要只放 PDF。把指标定义做成结构化的 JSON 或 Markdown，每个指标一个独立段落，包含名称、口径、计算公式、适用场景。这样向量检索的命中率远高于把所有定义塞在一个大 PDF 里。
三个 Agent 的分工思路
OPLOG 构建了三个 Agent，而不是把所有功能塞进一个。这个拆分值得借鉴：
- 数据查询 Agent：负责理解用户意图、生成 SQL、执行查询、返回结构化结果。工具是数据库连接和 SQL 执行。
- 指标解读 Agent：负责指标定义检索、口径澄清、趋势归纳。工具是 Knowledge Base 检索和简单的统计计算。
- 异常分析 Agent：负责检测数据异常（环比骤降、同比偏离）、定位可能原因、生成分析摘要。工具是阈值检测和 Knowledge Base 中的业务事件时间线。
拆分的好处：每个 Agent 的 system prompt 和工具集更聚焦，模型调用工具的准确率更高。用户通过一个前端路由层，根据问题类型分发到对应 Agent。如果某个 Agent 出问题，不影响其他 Agent 的服务。
上手前的检查清单
在动手之前，确认这几项：
- Bedrock 模型访问已开通：在 AWS Console 的 Bedrock 页面确认 Claude Sonnet 的模型访问已启用，区域选对（Sonnet v2 目前在 us-east-1 和 us-west-2 可用）。
- IAM 权限最小化：Agent 的运行角色只给它需要的权限——Bedrock 调用、数据库查询、S3 读取。不要给
AdministratorAccess。 - SQL 安全边界：数据查询 Agent 的工具实现里，强制校验 SQL 语句类型，只允许 SELECT。更稳妥的做法是在数据库层面用只读账号连接。
- 知识库文档质量：RAG 的效果上限取决于文档质量。先花时间把指标定义写清楚、结构化，再灌入 Knowledge Base。
- 对话测试覆盖：上线前用典型问题集测试——模糊问题（"最近销售怎么样"）、精确问题（"华东区 1 月 GMV"）、口径问题（"你们说的客单价含不含退款"）。每个类型至少跑 5 轮。
AgentCore + Strands SDK 这条路径，把 Agent 的定义、运行、知识增强三层解耦了。你可以先在本地用 Strands 验证 Agent 逻辑，确认工具调用链路正确，再部署到 AgentCore 接入生产。起步成本不高，但安全边界和知识库质量是两个不能省的前期投入——这两项决定了 Agent 上线后是靠谱的助手还是会编数据的隐患。