AI 代理让金融团队自助取数：BGL 的实战路径

企业里最昂贵的“等待”，往往不是算力或云账单，而是业务团队等数据团队排队跑数。Anthropic 在《2026 State of AI Agents Report》里给了一个很直白的数字：60% 的组织把“数据分析与报表生成”评为最有影响力的 AI 代理应用，65% 的企业把它列为优先事项（2026）。这两组数字之所以扎眼，是因为它们戳中了同一个痛点：分析需求持续增长，但数据团队的人力永远跟不上。

在“人工智能在金融服务与金融科技”这条主线里，这个问题更尖锐。金融服务天然重合规、重权限、重审计。你想让非技术同事自助查询数据，又不能让他们随便碰生产库；你想上一个“text-to-SQL”，又担心它把表连错、口径算错，最后给业务一个看似合理但实际错误的答案。

BGL（服务覆盖 15 个国家、12,700+ 家企业客户的 SMSF 退休金合规与管理软件提供商）给出了一条值得中小企业借鉴的路线：用“强数据底座 + 可执行代码的 AI 代理 + 生产级隔离会话”把自助 BI 做到可控、可用、可扩展。他们用 Claude Agent SDK 构建分析代理，并托管在 Amazon Bedrock AgentCore 上，把自然语言问题变成对“业务就绪的分析表”的安全查询，再用 Python 在隔离环境里做二次分析与可视化。

先把一个误区说清：别指望代理替你建数据平台

最常见的反模式是：把所有复杂性都塞给 AI 代理——让它理解原始库的表结构、猜业务逻辑、决定 join 关系、处理口径、再解释结果。这样做的结局通常是两种：

• 结果不一致：同一个问题，问两次答案不一样；
• 答案看起来对，但口径错：join 错了、过滤条件漏了、聚合维度混了。

BGL 走的是更“笨”但更稳的路：他们已经有成熟的大数据分析体系，用 Amazon Athena + dbt 每天把多源数据做 ETL，沉淀成 400+ 张分析表。这些表不是给工程师“拼 SQL”的原始明细，而是面向业务域的聚合、去范式、带指标与摘要的数据集，专门回答一类业务问题（客户反馈、投资表现、合规跟踪、财报分析等）。

把复杂业务逻辑（口径、join、边界条件）留在 dbt 和数据流水线里，让代理只做一件事：

把自然语言翻译成对“单一可信源（single source of truth）”分析表的 SELECT 查询。

这背后的收益非常现实：

1. 一致性：口径由数据团队提前验证，代理不再“临场发挥”。
2. 性能：查预聚合分析表比在原始明细表上做多表 join 快得多。
3. 可治理：业务规则变更只改 dbt；代理天然吃到新表口径，不需要到处改提示词。

我很认同 BGL 数据负责人 James Luo 的那句判断：“每一层解决各自该解决的复杂性。” 想要稳定的自助分析，捷径往往是最远的路。

让 AI 代理真正能“干活”的关键：代码执行，而不是把数据塞进上下文

很多团队做分析代理时，会沿用“工具调用/函数调用”的套路：SQL 查完把结果（甚至整张表）直接塞回模型上下文，让模型继续做聚合、对比、画图。问题是：

• 分析查询动辄成千上万行，结果文件可能是 MB 级；
• 上下文窗口会被迅速吃光；
• 模型在“读表”这件事上并不高效，成本高且不稳定。

BGL 选了更工程化的方法：

1. 代理生成 SQL 在 Athena 执行；
2. Athena 把结果落到 S3（CSV）；
3. 代理在自己的执行环境里下载 CSV 到文件系统；
4. 代理写 Python 脚本在本地做聚合、分组、分位数、趋势分析、可视化；
5. 把图表和结论发回 Slack。

这件事看起来“多绕一步”，但其实是把 LLM 从不擅长的任务里解放出来：

• LLM 负责推理与编排（理解问题、选择表、生成查询、决定分析方法）
• 代码负责确定性计算（过滤、统计、画图）

一句话概括：别让模型用 token 做计算，让 CPU 做。

模块化知识：用 CLAUDE.md + SKILL.md 把复杂业务拆开管

金融与金融科技场景的难点不只是数据量，还有“语义碎片化”：同样叫“客户”，在不同产品线/国家/实体下口径不同；同样叫“合规风险”，指标体系也不一样。

BGL 用了两层配置把知识结构化：

CLAUDE.md：全局项目上下文（让代理别走错路）

它相当于“项目运行手册”，包含：

• 环境信息（测试/生产）
• 查询执行方式（如何跑 Athena SQL）
• 文件路径规范（中间结果、最终输出存哪）
• 每张分析表的元信息组织方式（如 schema.md、sample_data.csv、statistics.md）

这能显著减少生产环境里最常见的一类事故：代理生成了结果，但落盘路径乱、权限不对、用户拿不到文件。

SKILL.md：按产品线封装领域能力（让代理懂业务）

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

• CAS 360：公司/信托管理 + ASIC 合规相关分析
• Simple Fund 360：SMSF 管理与合规相关分析

每个 SKILL.md 明确三件事：

• 何时触发（看到哪些问题类型就启用这个 skill）
• 用哪些表（把自然语言映射到相关分析表）
• 复杂场景怎么做（多表分析的步骤与注意事项）

这种“模块化知识”有两个好处特别适合中小企业：

• 渐进式加载：不需要一次把所有知识塞给模型，节省上下文，降低幻觉面。
• 可迭代维护：业务同事用着用着发现缺口，就用 human-in-the-loop 把新规则补进对应 skill，而不是改一堆 prompt。

把它放进真实工作流：Slack 里问一句，就能出图出结论

BGL 的用户入口很务实：Slack。这点对“AI 语音助手与自动化工作流”也很有启发：你不一定要先做一个很完整的新前端，把代理接入团队每天在用的渠道， adoption 会快很多。

他们的端到端流程可以总结为 7 步：

1. 用户在 Slack 提问（例如“上季度负面反馈最多的产品有哪些？”）
2. 代理根据 skill 做表与字段的发现与映射
3. SQL 安全校验：只允许 SELECT，拦截 DELETE/UPDATE/DROP
4. Athena 执行查询，结果落 S3
5. 代理下载 CSV 到 AgentCore 会话文件系统（避开上下文限制）
6. 代理用 Python 做分析/图表
7. 结果回传 Slack

把这个模式迁移到金融团队很顺：

• 风控同事要看某类账户的异常趋势
• 合规同事要追踪规则触发与处理时延
• 客服/客户成功要在通话中即时拉取客户画像指标

你会发现，真正提升效率的不是“能问 SQL”，而是从提问到可行动结论的链路缩短了。

为什么生产级托管很关键：AgentCore 的“隔离会话”解决合规焦虑

只要代理能执行 Python，你就必须认真对待基础设施：

• 会话之间不能互相看到文件和数据
• 凭证不能泄露
• 权限要跟用户身份绑定
• 审计与网络边界要清晰

Amazon Bedrock AgentCore 的价值在于它提供完全托管的、带状态的执行会话：每个会话在独立的 microVM 里运行，CPU/内存/文件系统隔离；会话结束会终止并清理内存，降低残留风险。并且会话状态可持续 最长 8 小时，适合“对话式分析”（同一条分析链路里不断追问、对比、修正）。

对金融服务来说，我认为这里最可贵的是两点：

1. 身份与权限更容易落地：可以基于 IAM 或 OAuth 做身份控制，把“谁能看什么数据”落到系统层，而不是寄希望于提示词约束。
2. 更像一个可治理的平台，而不是脚本玩具：当使用人群从数据团队扩展到全员时，隔离与审计不是加分项，是门槛。

中小企业要抄作业：从 0 到 1 的落地清单

如果你也在做金融数据分析自动化（或计划把 AI 语音助手接入分析链路），我建议按这个优先级推进：

1）先做“可回答的问题清单”，再做模型

别从“选哪个大模型”开始。先列出 20–50 个高频问题类型（按部门分组）：

• 合规：规则触发、整改时效、异常原因归因
• 风控：欺诈/异常交易趋势、分群差异
• 产品：功能使用漏斗、负反馈主题
• 客服：客户分层指标、近期交互与风险提示

然后为每类问题指定对应的分析表或指标集。

2）把口径前置到数据层：分析表要“业务就绪”

你不需要一夜之间建完数仓，但至少做到：

• 关键指标有明确计算口径
• 维度与时间粒度一致
• join 关系尽量少、尽量稳定

代理越“简单”，结果越稳定。

3）强制只读 + 结果落盘 + 可复现

生产里建议三条硬规则：

• 只允许 SELECT
• 所有查询结果落到指定路径（方便审计与复盘）
• 分析代码与产物可复现（同样输入应得到同样输出）

4）用技能化知识做治理，而不是堆提示词

把“表怎么选、指标怎么解释、边界条件是什么”写进 SKILL.md，并建立反馈闭环：

• 记录失败问题与修正方式
• 每周迭代 1–2 次技能库
• 给每条规则标注负责人（业务 + 数据）

你真正买到的不是自助 BI，而是团队产能

BGL 的结果很直观：200+ 员工的分析方式被重塑。产品经理不用等排期就能验证假设；合规团队不用学 SQL 也能发现风险趋势；客户成功能在通话中实时拉取账户分析。这类“民主化数据访问”在金融服务里尤其有意义——它让风险、合规、客服这些本来就节奏很快的岗位，少掉了大量来回沟通和等待。

如果你正在规划 AI 语音助手或自动化工作流，我的判断是：最值得优先做的落地点之一，就是“对话式自助分析 + 可审计的自动报表”。 先把高频分析问题自动化，团队释放出来的时间会非常具体：少开会、少排队、少返工。

下一步你可以做一个小试点：选一个部门（比如合规或客服运营）、一组固定指标、一个沟通入口（Slack/企业微信/语音助手），用 2–4 周验证“提问到产出”的闭环。等你把权限、口径、隔离这些地基打牢，再扩到更多问题域。

你更想先从哪个场景切入——合规报表自动化、风控趋势分析，还是客服通话中的实时经营指标？