让业务人员自己跑报表：金融数据分析 AI 代理

数据团队最常被“打断”的工作，不是建模，也不是治理，而是重复回答同一类问题：上季度投诉最多的产品是什么？高净值客户的投资趋势怎么走？某个合规指标这周有没有异常？

Anthropic 在《2026 State of AI Agents Report》中给了一个很直白的数字：60% 的组织认为“数据分析与报告生成”是最有影响力的 AI 代理应用，65% 的企业把它列为优先事项。我认同这个方向，但也想说得更尖锐一点：大多数公司做自助分析失败，不是模型不够强，而是把“数据平台该做的事”塞给了模型。

这篇文章属于「人工智能在金融服务与金融科技」系列，我们用 AWS 博客里 BGL 的真实案例当蓝本，拆解他们如何把自然语言分析做成可上线、可审计、可扩展的系统：Claude Agent SDK + Amazon Bedrock AgentCore。更重要的是，我们会把它翻译成中小团队也能落地的做法——尤其适用于金融科技、保险、会计 SaaS、财富管理等对权限和合规极其敏感的场景。

真正的瓶颈：不是不会写 SQL，而是“排队”

结论先说：自助分析的核心价值，是把“排队成本”降到接近 0。

在金融服务与金融科技公司，业务侧对数据的依赖比很多行业更强：风控、反欺诈、合规、客户成功、产品，都需要频繁查询指标。但现实往往是：

• 业务人员不会 SQL（或不熟悉你们内部的表结构），只能提工单
• 数据团队既要保证正确性，又要扛住“临时需求”
• 传统 text-to-SQL 工具常常join 错表、漏过滤条件、聚合口径漂移，越用越不敢信

BGL 的背景很典型：他们为自主管理养老金（SMSF）提供合规与管理解决方案，服务覆盖 15 个国家、12,700+ 家企业。内部分析数据规模很大，400+ 张分析表覆盖反馈、投资表现、合规追踪、财报等域。

这里有一个行业共性：金融数据不是“查出来就行”，而是“查出来还能解释、能复现、能审计”。

先把数据打造成“可问”的样子：别让 AI 去理解你的烂表

最关键的工程取舍：让数据系统处理复杂逻辑，让 AI 代理只负责“翻译问题”。

BGL 明确避开了一个常见反模式：让代理承担全部工作——理解 schema、拼 joins、处理业务口径、算指标、解释结果。这样做的结果通常是：

• 口径不一致（同一个问题每次答案不同）
• 边界条件漏掉（比如时间区间、币种、账户类型）
• join 路径不稳定（尤其是多域数据）

他们的做法是走“数据平台先行”：用 Amazon Athena + dbt 把原始数据做成面向业务的分析表（聚合、去范式、口径固化），形成单一可信源（single source of truth）。AI 代理的工作被限定为：

1. 识别问题属于哪个业务域
2. 对准相应的分析表
3. 生成以 SELECT 为主的查询
4. 必要时用 Python 做二次分析和可视化

这会带来三个直接收益（而且都和“能不能上线”强相关）：

• 一致性：joins 与业务规则在 dbt 层被验证，代理不会临场“自创口径”
• 性能：预聚合表让查询更快，交互体验才像“对话式 BI”
• 治理：口径在数据系统中可版本化、可评审，代理只是消费者

BGL 的 Head of Data & AI James Luo 说得很直白：

“很多人以为 AI 代理很强，所以可以跳过数据平台，让代理做一切。但这样不可能得到稳定且准确的结果。”

我会再补一句：如果你希望业务人员“敢用”，你就必须让答案“可复现”。这不是提示词能解决的。

代理怎么做到“能分析大结果集”：别把数据塞进上下文

结论：对话式分析要可扩展，必须把“大数据处理”从 LLM 上下文窗口移走。

传统 function calling 或 MCP 工具调用常见做法，是把查询结果直接塞回模型上下文。对于金融分析，这几乎必爆：一次查询上千行、几 MB 数据很常见，很快就超过上下文限制，成本也会飙升。

BGL 用 Claude Agent SDK 的“代码执行”能力改变路径：

• 代理先写 SQL 去 Athena 跑
• Athena 把结果落到 S3（通常是 CSV）
• 代理把 CSV 下载到 AgentCore 的会话文件系统
• 代理写 Python 脚本在本地文件上做过滤、聚合、画图

这条链路有个很实用的优势：模型只需要“理解问题 + 生成代码/SQL”，不需要“吞下数据”。

如果你正在做“AI 语音助手与自动化工作流”，这点尤其重要：语音交互要求更短的响应节奏。把重活交给代码执行，语音助手只负责解释与呈现，体验会好很多。

一个可迁移的模式：SQL 取数 + Python 解释 + 图表输出

中小团队可以从最简单的“三段式”开始：

1. 标准化指标表：把核心 KPI 做成可直接查询的宽表
2. 查询安全层：只允许 SELECT，禁止 UPDATE/DELETE/DROP
3. Python 模板库：常用图表与统计（环比、同比、分位数、异常检测）做成可复用脚本

这比“让模型自己分析一坨 JSON”可靠得多，也更省 token。

让知识可维护：用 CLAUDE.md + SKILL.md 把“会问”变成资产

结论：企业级分析代理的知识不是写在 prompt 里，而是像代码一样分层、可更新。

BGL 的设计很像“可运营的知识系统”，核心是两类文件：

CLAUDE.md：全局项目上下文（项目规范）

CLAUDE.md 放的是全局规则，比如：

• 数据目录结构在哪里
• 如何执行 SQL
• 中间结果、最终输出必须存到哪条路径
• 测试/生产环境差异

它的价值在于“让代理的工作方式一致”，尤其当你把代理接到 Slack、Teams 或未来的语音助手时，一致性决定可控性。

SKILL.md：按业务线拆分的领域技能（领域映射）

BGL 按产品线把知识拆成多个技能包（例如 CAS 360、Simple Fund 360 等）。每个 SKILL.md 会定义：

• 何时触发（什么问题属于这个域）
• 用哪些表（表映射与元数据引用）
• 复杂场景怎么做（多表查询步骤、特殊口径）

这套方式有两个非常现实的好处：

• 渐进加载：只加载当前需要的技能，控制上下文占用
• 人机闭环：业务提问暴露知识缺口，数据/产品团队可以迭代补齐技能文件

在金融科技场景里，我建议你把 SKILL.md 的组织方式再“合规化”一点：

• 每个技能标注适用的数据级别（如 PII、账户级、汇总级）
• 每个技能列出“允许回答的粒度”与“禁止输出字段”
• 把常见审计口径（例如时间窗口、币种换算、去重规则）写成硬约束

为什么 AgentCore 这种“有状态、隔离会话”的托管很关键

结论：只要你的代理会执行代码，就必须把隔离与权限当成一等公民。

BGL 把 Claude Agent SDK 运行在 Amazon Bedrock AgentCore 上，核心原因不是“方便”，而是“能上线”。AgentCore 提供：

• 有状态会话：单会话可维持最长 8 小时，上下文连续，适合“追问式分析”
• 会话级隔离 microVM：CPU/内存/文件系统隔离，会话结束后清理，减少跨会话数据残留风险
• 身份与访问控制：支持 IAM / OAuth，能做基于身份的授权
• 框架灵活：不绑死某个 agent 框架（对长期演进很重要）

对金融服务尤其关键的是：同一个代理要服务很多人，但每个人能看的数据不一样。

如果你计划把它接入语音助手（电话坐席、内部语音查询、移动端语音 BI），也一样需要：

• 会话隔离（避免 A 客户的内容在 B 客户会话出现）
• 细粒度授权（基于角色、区域、产品线、客户归属）
• 审计（谁问了什么、跑了什么 SQL、返回了什么结果）

把案例落到中小团队：一份 30 天实施清单

结论：别从“全自动 BI”开始，从“把最耗时的 20% 查询自动化”开始。

这里是一份更贴近中小金融团队的路线图：

第 1-7 天：选场景 + 定口径

• 选 3 类高频问题：投诉/工单、产品转化、合规监控（任选其一也行）
• 把指标口径写下来：时间窗口、去重规则、汇总粒度
• 明确哪些字段绝不能返回（PII、证件号、完整交易流水等）

第 8-15 天：做“可问的分析表”

• 用 dbt（或你们现有 ETL）做 1-3 张宽表/汇总表
• 把表的 schema、样例数据、统计信息放进统一目录
• 用数据质量测试锁住关键口径（避免代理回答漂移）

第 16-23 天：搭代理最小闭环

• 只允许 SELECT
• 查询结果落盘（S3/对象存储）
• 代理用 Python 脚本生成 2-3 种固定输出：TopN、趋势图、异常点列表

第 24-30 天：接入工作流 + 做反馈闭环

• 接 Slack/企业微信/Teams；如果你做语音助手，就接语音转写后的文本入口
• 记录每次问答：问题、SQL、执行耗时、是否命中技能、用户是否满意
• 每周更新一次 SKILL.md（这一步会让效果越来越稳）

你会发现：真正的 ROI 不在“替代分析师”，而在“减少打断、减少等待、减少重复解释”。

面向未来：从文字对话到“语音 BI + 自动化工作流”

BGL 的案例表面上是 Slack 里的自然语言查询，但它指向的更大趋势是：BI 正在变成可编排的自动化工作流。

当你把“问数—取数—分析—出图—发给相关人”串起来，下一步就是：

• 语音助手说一句“把上周异常交易 Top 10 发给风控群”，系统自动完成
• 合规指标触发阈值，代理自动生成解释材料与可视化，进入审批流程
• 客户经理通话中实时拉取客户汇总画像（只在授权范围内）

金融服务的胜负手，从来不是“有没有数据”，而是“有没有把数据变成行动的速度”。

如果你正在评估对话式 BI、text-to-SQL、或想把语音助手接到内部数据系统，我的建议很明确：**先把数据平台和权限边界做好，再谈智能。**不然你会得到一个“很会说、但不敢用”的系统。

你最想让业务同事“自己问”的那三个问题是什么？把它们写下来，你的第一版分析代理就有了起点。