用 Bedrock AgentCore 做 FinOps 语音助手：省 10 小时/周

月底对账最耗人的不是“算”，而是“找”。同一家公司、多个 AWS 账户、不同部门各自开着控制台：财务想知道本月前五大费用来源，工程想查某个服务突然飙升，老板只关心“下个月会不会超预算”。你会发现大家做的事高度重复：打开 Cost Explorer、翻 Budgets、再去 Compute Optimizer 截图，最后把结果拼成一段话。

我越来越不喜欢这种工作方式。不是因为这些工具不好，而是因为查询成本太高：人要记得去哪点、要会选维度、要会解释数据，还要能在追问时保持上下文。更好的答案是把“控制台导航”变成“对话”，把“手动拼数据”变成“自动化工作流”。

这篇文章是「人工智能在金融服务与金融科技」系列的一篇，聚焦一个非常务实的场景：用 Amazon Bedrock AgentCore 搭一个 FinOps 代理，把 AWS Cost Explorer、AWS Budgets、AWS Compute Optimizer（再加上 AWS Pricing）汇总到一个可对话的入口里。把它想成企业里的FinOps 语音助手/聊天助手：你说“这个月谁最烧钱？”，它直接回你答案；你再问“第二个服务怎么降？”，它记得上下文并给出可执行建议。

为什么 FinOps 需要“语音助手式”的自然语言入口

结论先说：FinOps 的瓶颈不是缺数据，而是缺“低摩擦的取数与解释能力”。 小企业尤其明显：没有专职 FinOps 团队，财务和工程往往是“兼职”在做成本优化。

把自然语言交互引入 FinOps，有三个直接收益：

1. 把查询门槛降到最低：不要求每个人都懂 Cost Explorer 的分组/过滤/粒度。
2. 把重复查询变成可复用的对话：同一条线索可以连续追问，避免每次从头描述背景。
3. 把“分析”与“动作”连接起来：不仅回答“花在哪”，还能回答“怎么省”，并指向具体资源与建议。

在金融服务与金融科技语境里，这种能力很像“智能客服 + 风控分析助手”的组合：前台用自然语言接收问题，后台自动触发数据检索与规则/模型判断。区别只是这里的“账”是云成本。

这类 FinOps 代理怎么工作：AgentCore + MCP 的组合

一句话概括架构：前端负责身份认证与提问，AgentCore Runtime 负责对话编排与工具调用，MCP 服务器把 AWS 成本与定价能力封装成可调用工具。

这套方案在 AWS 的参考实现里，核心组件分两层：

• 认证与前端层：

  • 用 Amazon Cognito 做用户登录与临时凭证下发（Identity Pool）。
  • 用 AWS Amplify 托管一个简单 Web 界面（你也可以接 Slack/Teams/呼叫中心系统，做成“语音助手”的前端）。

• AgentCore 智能体层：

  • AgentCore Runtime：运行你的 FinOps agent（对话逻辑、工具选择、结果汇总）。
  • AgentCore Gateway：统一的工具发现与调用入口，负责把请求路由到后端工具服务。
  • AgentCore Identity：管理 Gateway 到 MCP Runtime 的 OAuth 2.0 凭证生命周期。
  • AgentCore Memory：保留最长 30 天对话上下文，让你能连续追问。

更关键的是工具层：

• MCP（Model Context Protocol）服务器把“查询成本、预算、异常、优化、定价”等动作标准化成工具（tool）。参考实现里包含两个 MCP Server：
  • Billing & Cost Management MCP Server（偏历史与优化：Cost Explorer、Budgets、Compute Optimizer 等）
  • AWS Pricing MCP Server（偏未来与估算：Price List API）

一次典型提问会发生什么（用“问成本”为例）

你问：“我 2026 年 1 月 AWS 花了多少？”

1. 前端拿到 Cognito 身份，带临时 AWS 凭证调用 InvokeAgentRuntime。
2. Runtime 把你的问题 + 可用工具列表交给大模型（例如 Claude Sonnet 4.5）。
3. 模型判断需要调用某个工具（例如 billingMcp__cost_explorer）。
4. Agent 通过 Gateway 发起工具调用（SigV4）。
5. Gateway 通过 Identity 获取 OAuth token，去调用 MCP Runtime。
6. MCP Runtime 用自身执行角色去打 Cost Explorer API，拿到数据。
7. 数据返回模型，由模型生成自然语言解释与结构化摘要。

这条链路的意义是：人不需要知道“数据在哪”，只需要提出“我想知道什么”。

把它当作“小企业自动化工作流”：你应该怎么设计对话与权限

很多团队第一反应是“赶紧把 agent 部署起来”。我建议先把下面两件事想清楚：

1) 先定义 5 类高频问题（它们会决定你的工具与输出格式）

对小企业来说，最常见的不是复杂建模，而是这些“反复出现的管理问题”：

• 本月费用分布：Top services、按账户/区域/标签拆分
• 异常与解释：是否有成本异常？异常来自哪个账户/哪个服务？
• 预算与预测：预算是否将超支？未来 3 个月预测
• 优化清单：rightsizing、Savings Plans、闲置资源
• 新项目估算：某个实例/存储/函数在指定区域的价格，用于立项或 IaC 评审

把这 5 类问题做成“对话模板”，输出就会更稳定，例如：

• 先给一句结论（可被老板转发）
• 再给三条证据（数据点/环比）
• 最后给行动项（按影响金额排序）

2) 权限要按“财务可见性”来分层，而不是按技术组件来分

FinOps agent 最大的风险不是模型“说错话”，而是越权读到了不该读的数据。正确做法是从组织管理出发：

• 按账号/OU/成本中心限制 Cost Explorer 的访问范围
• 按角色区分“只能读”与“可触发优化建议/工单”的能力
• 对敏感字段做脱敏（例如资源命名可能包含客户信息）

在 AWS 的参考方案里，IAM 权限主要由 MCP Runtime 的执行角色承载；前端用户的临时凭证只用于调用 AgentCore API，并不直接访问 Cost Explorer 数据。这种隔离思路值得保留。

真正能省时间的地方：让 agent 输出“可执行的 FinOps 例行流程”

我的立场很明确：如果你的 FinOps 代理只能聊天，价值会很快见顶。 想做到“每周省 10 小时”，关键是把输出对接到团队的固定流程里。

下面是 3 个我见过最有效的做法：

1) 把“月度成本复盘”拆成可自动完成的 4 步

• Step A：自动生成“本月 Top 5 成本服务 + 环比变化”
• Step B：对每个 Top 服务给出 1-2 条优化建议（来自 Compute Optimizer、rightsizing、Savings Plans）
• Step C：标记异常（cost anomalies）并给出可能原因
• Step D：产出一段可直接发群的总结（含数字、含行动项）

你可以把这套步骤做成 agent 的固定指令（prompt + 工具调用策略），让财务每月只需要说一句：“生成 3 月成本复盘”。

2) 用“追问式对话”替代来回发截图

AgentCore Memory 能保留 30 天上下文，这对真实协作很重要。典型场景：

• 你：“列出本月成本最高的 5 个服务。”
• 你：“第二个服务拆到各账号。”
• 你：“找出其中最可疑的增长项，给我 3 个排查建议。”

这比“发一张图—再要一张图—再解释一遍背景”省太多时间。

3) 把“定价估算”变成产品与财务对齐的共同语言

很多 FinTech 或金融业务团队在上新功能时，预算争议常来自“成本估算口径不一致”。引入 Pricing MCP Server 后，你可以让 agent 统一口径：

• 对同一地区同一规格，给出实时单价与计费维度
• 对比两种实例规格（例如 t3.micro vs t3.small）
• 把估算写成“假设清单”（运行小时数、数据传输、存储类型）

这种“假设清单”比单纯报价格更能避免后续扯皮。

部署路径：先跑通参考实现，再做“语音助手化”改造

答案很直接：先用 AWS CDK 部署参考栈跑通端到端，再把前端替换成你公司的沟通入口。 参考实现的关键点包括：

• 用 CDK 一次性部署：Auth、Image Build、MCP Runtime、Gateway、Agent Runtime
• MCP Server 容器镜像通过 CodeBuild 构建并推到 ECR
• 主 Agent Runtime 通过 Gateway 发现并调用来自两个 MCP Server 的工具（示例里是 24 个工具）

如果你目标是“AI 语音助手与自动化工作流”，我建议按这个顺序演进：

1. Web chat 先落地（验证工具调用与权限边界）
2. 接入 Slack/Teams（把对话放到业务协作现场）
3. 加语音入口（呼叫中心或移动端语音转文本）
4. 加工作流出口（把行动项写入工单系统、Notion/Jira、或邮件周报）

一条可执行的原则：先让 agent “把报表说清楚”，再让它“把动作发出去”。

常见问题（团队往往会卡在这里）

FinOps 代理会不会把成本数据“喂给模型”，造成泄露？

正确的工程做法是：只把回答问题所需的数据片段传给模型，并在工具层控制返回字段。你还需要配合组织策略（最小权限、日志审计、敏感字段脱敏）。

它适合小企业吗？会不会太重？

我认为适合，但前提是你把目标定对：不是追求“全自动省钱”，而是把每周固定的查询与解释自动化。 小企业最缺的是“能稳定跑起来的流程”，而不是更多仪表盘。

如何衡量 ROI？

用三个指标就够了：

• 每周节省的人工查询与整理时间（小时）
• 从发现异常到定位归因的平均时间（MTTI）
• 优化建议的落地金额（按月跟踪）

只要你能把“10 小时/周”的节省落到台账上，这类项目就站得住。

你可以从一个“最小可用 FinOps 语音助手”开始

把 AWS 费用管理做成对话式入口，本质上是在做金融科技里熟悉的那件事：把复杂系统的操作，变成一句话的意图表达，再由自动化工作流完成检索、校验与解释。 FinOps 代理只是一个非常适合落地的起点。

如果你准备动手，我建议你从三句指令开始设计：

1. “本月前五大成本服务是什么？环比多少？”
2. “有哪些明确的节省机会？按预计金额排序。”
3. “下个月会不会超预算？给出原因和应对动作。”

当你的团队开始用“说一句话”替代“发三张截图”，你就已经把 FinOps 从工具使用，推进到了流程自动化。

接下来你想把这个 agent 接到哪里——Slack、Teams，还是语音呼叫中心？