AI 智能体让 BI 不再卡在数据团队手里

把“想看个报表”变成一周的排期，这事儿在金融服务与金融科技团队里太常见了：合规要追踪风险趋势，产品要验证假设，客服要在电话里回答客户的账户表现——但 SQL 只会少数人写，数据团队永远在排队。

更扎心的是，很多公司以为上一个“文本转 SQL”的工具就能解决问题，结果经常出现表 join 错、口径不一致、聚合逻辑跑偏。最后大家又回到老路：发工单、开会澄清、反复改口径。

来自 AWS 的一篇案例给了一个更务实的答案：BGL（做自管养老金 SMSF 管理与合规软件的金融科技公司）用 Claude Agent SDK + Amazon Bedrock AgentCore 做了一个可上线的分析型 AI 智能体，让非技术同事在 Slack 里用自然语言拿到洞察，同时把金融行业最在意的权限、隔离、审计与安全边界落到基础设施层面。这篇文章我想把它拆开讲清楚：它到底解决了什么、为什么比“让模型直接查库”靠谱，以及你在自己的自动化工作流里该怎么复用。

Anthropic 的《2026 State of AI Agents Report》提到：60% 的组织认为“数据分析与报告生成”是最有影响力的智能体应用，65% 的企业把它列为优先事项。这不是热闹，而是刚需。

1) 真正的瓶颈不是“不会写 SQL”，而是“口径不可控”

想让 AI 直接对着生产库“理解全部 schema 并生成正确查询”，大概率会翻车。原因不玄学：

• 业务口径往往藏在 ETL 和指标层：比如“活跃客户”“风险暴露”“负反馈”背后可能包含排除条件、时间窗口、分群规则。
• 原始表高度规范化：模型一旦 join 错或漏掉条件，就会得出看似合理、实则错误的结论。
• 文本转 SQL 天生难以稳定：同一句话在不同上下文下可能生成不同 SQL；而金融团队需要的是可复现、可解释。

BGL 的做法很明确：把复杂性放回它该在的地方。

把“复杂业务逻辑”前置到数据平台层

BGL 已经有成熟的数据平台：用 Amazon Athena + dbt 处理多来源的海量数据，产出 400+ 张分析宽表/主题表，每张表回答一类清晰的业务问题（例如客户反馈、投资表现、合规追踪、财务报告）。这些表是预聚合、去范式化后的“业务可读单一事实来源”（single source of truth）。

然后才轮到 AI 智能体上场——它只需要做三件事：

1. 理解自然语言问题
2. 在“业务就绪”的分析表上生成 SELECT 查询（而不是跨一堆原始表做复杂 join）
3. 必要时用代码对查询结果做二次处理与可视化

这套分工带来的收益非常实在：

• 一致性：口径由数据团队在 dbt 中验证并沉淀，智能体不需要“临时发明规则”。
• 性能：查预聚合分析表比扫原始明细快得多，响应更接近“对话式分析”的体验。
• 治理与可维护性：业务规则改了，只改 dbt；智能体天然跟着新表、新指标走。

我很赞同 BGL Head of Data & AI James Luo 的那句话（原文意思）：很多人觉得智能体很强就可以跳过数据平台，但那样根本得不到稳定准确的结果。每一层解决各自的复杂度，才是能长期跑下去的架构。

2) 分析型 AI 智能体要“会算”，别把大数据塞进上下文

做 BI 的人都知道：一个问题返回几千行很正常；合规排查或分群分析，甚至会到 MB 级。

常见的失败模式是：工具把查询结果直接塞回大模型上下文窗口，让模型“读表做分析”。这会触发两个问题：

• 上下文爆炸：很快触顶 token 限制。
• 分析不可靠：模型在长表格里容易漏行、误读、算错。

BGL 的关键选择是：用 Claude Agent SDK 的 code execution 把“计算”交给 Python，而不是交给上下文。

一条更稳的链路：SQL → CSV 落盘 → Python 分析 → 输出图表

典型流程是：

1. 智能体生成 SQL（只允许 SELECT）
2. Athena 执行，把结果落到 S3
3. 智能体下载 CSV 到运行环境文件系统
4. 智能体写 Python 脚本做过滤、聚合、画图
5. 返回 Slack：结论 + 关键图表/表格

这条链路有个好处经常被低估：可审计、可复现。CSV 文件、生成的图、Python 脚本路径都可以固化（至少在会话期内），你能追溯“这次结论是怎么算出来的”。对金融服务与金融科技团队来说，这比“模型说了算”重要得多。

3) 让智能体像“多产品线分析师”一样工作：CLAUDE.md + SKILL.md

很多企业的 BI 不难在“第一天”做出 demo，难在“第 90 天”还能稳定扩展：产品线多、指标多、表多，靠把所有知识一股脑塞进提示词只会越来越乱。

BGL 用了一个很工程化的办法：

CLAUDE.md：全局项目上下文（统一规矩）

它提供项目结构、环境信息、怎么执行 SQL、结果存放路径等“统一标准”。这能避免智能体在执行层面各自为政，比如输出文件到处乱放、查询方式不一致。

SKILL.md：按产品线拆分的领域技能（局部专家）

每个产品线一个 skill，比如：

• CAS 360：偏公司/信托管理与 ASIC 合规
• Simple Fund 360：偏 SMSF 管理与合规

每个 SKILL.md 里定义：

• 何时触发（哪些问题属于这个产品域）
• 表映射（该查哪些分析表）
• 复杂场景处理步骤（多表组合、特殊口径的做法）

这套“模块化知识架构”的价值在于：

• 上下文更干净：按需加载 skill，不是全量灌进 prompt。
• 更易维护：发现新问题不会时，就把知识补到对应 skill，形成可迭代的“人类在环”更新机制。
• 更贴近业务组织方式：产品线负责自己的指标与语义，数据平台负责通用标准与表资产。

如果你在做“AI 语音助手与自动化工作流”，这个设计也很容易迁移：把“通用对话规范”放在全局文件，把“不同部门/业务线 SOP”做成技能包，按意图触发。

4) 金融场景最容易被忽视的点：会话隔离与权限边界

分析型智能体一旦具备执行代码、读写文件、访问数据的能力，安全问题就不再是“加个 API Key”那么简单。

BGL 选择把 Claude Agent SDK 部署在 Amazon Bedrock AgentCore 上，核心原因是它提供托管的、有状态、隔离的执行会话：

• 每个会话一个隔离的 microVM（CPU、内存、文件系统都隔离）
• 会话结束 microVM 终止并清理内存，减少残留风险
• 会话可持续长达 8 小时，适合“连续追问”的对话式分析
• 支持 VPC、IAM/OAuth 等企业身份与网络控制

我特别喜欢这一点：很多团队把精力都放在“模型选哪个”，但金融行业最后卡住的往往是运行时——你怎么保证 A 用户不会看到 B 用户的缓存结果？怎么防止某次会话留下的临时文件被下一次读取？怎么把权限与身份体系打通？

额外一层“SQL 安全阀”非常必要

BGL 在链路里加了 SQL 安全校验：只放行 SELECT，阻断 DELETE/UPDATE/DROP。这不是多此一举，而是把“最坏情况”前置处理。哪怕智能体出错，也不至于把库改坏。

如果你要在小企业或中型团队落地，我的建议是：先从只读分析做起。一旦写入和自动化执行掺进来，合规与审计成本会直线上升。

5) 给小团队的落地路线：把“自动化报表”做成可复制的工作流

BGL 的规模和行业很典型：数据复杂、合规敏感、跨部门要自助分析。即使你不是做 SMSF，只要是金融服务、保险、支付、借贷、财富管理，问题都类似。

下面是一条我认为最稳、也最适合“以 leads 为目标”的落地路径（从 0 到 1、再到规模化）：

第一步：先把 20 个最常问的问题固化成“指标表”

别急着让智能体理解所有库。先让数据团队用 dbt 或类似方式把口径固化，产出 10–30 张主题表，覆盖：

• 风险与合规模块（异常交易、逾期、投诉、负反馈）
• 产品与增长模块（转化、留存、分层）
• 客户成功模块（工单、响应、账户健康度）

第二步：用“技能包”把部门语言翻译成表语言

每个部门一个 SKILL.md：触发条件 + 表映射 + 特殊口径。你会发现这比写一堆 prompt 模板更耐用。

第三步：把结果落盘 + 用 Python 计算

把“数据处理”从对话上下文里挪出去，至少做到：

• 所有查询结果落到文件
• 关键计算用脚本完成
• 输出包含：结论、数字、图表、口径说明

第四步：把权限做成“身份驱动的数据访问”

金融服务里最常见的翻车是：一个看似无害的自助查询，让不该看的人看到了不该看的数据。用 IAM/OAuth 做身份映射，并把表/列级权限落到数据访问层，是能否扩展的分水岭。

常见问题（团队通常会追问这些）

文本转 SQL 还能用吗？

能用，但前提是：查询对象是业务就绪的分析表，而不是原始明细表；同时要有口径治理与安全阀。

为什么一定要“有状态会话”？

对话式分析的价值在连续追问：上一轮筛选条件、时间范围、分群逻辑要能延续。无状态架构也能做，但你得自己搭“记忆层”和会话管理，成本高、风险也更高。

小公司没有 400 张分析表怎么办？

不需要。BGL 的规模大才会有 400+。小团队抓住 20–50 张高频主题表，效果就已经很明显。

写在最后：自动化报表不是“把人换成 AI”，而是把排队换成对话

在“人工智能在金融服务与金融科技”这个系列里，我最想强调的一点是：真正的自动化，不是让 AI 变聪明，而是让系统变可控。BGL 这套做法之所以值得学，不在于它用了哪个模型，而在于它把复杂性拆对了位置：数据平台负责口径与真相，智能体负责交互与编排，运行时负责隔离与权限。

如果你的团队正被“报表排期、临时分析、重复拉数”拖住，下一步可以很具体：选一个部门（比如合规或客服），挑 5 个最常见问题，做一条端到端的对话式分析工作流，严格只读、可追溯、可复现。跑通后再扩到更多技能包与主题表。

你更想先自动化哪一类金融分析工作流——合规风控、客户运营，还是产品增长？