8.0
热点
AI SCORE
编程提效2026-08-11 00:30
nOps 用 Bedrock AgentCore 将 FinOps Agent 上线周期缩短 75%
AWS ML Blog#AWS#Agent#LangChain
Editor brief · 编辑速览
用 AgentCore 替换自建 EKS + LangChain/LangGraph 架构，上线周期从 10-12 个月压缩到 4 个月，响应质量提升，运维开销下降。
nOps 是款 AI 云成本优化解决方案，最近通过迁移到 Amazon Bedrock AgentCore 重构了其财务运营（FinOps）分析能力。Amazon Bedrock AgentCore 是一项用于大规模构建、连接和优化 AI Agent 的服务，支持任意框架或模型。这套新基础架构帮助 nOps 更好地服务客户——这些客户需要管理跨 Amazon Web Services（AWS）、Google Cloud Platform（GCP）和 Microsoft Azure 的承诺式成本优化。通过持续优化 Reserved Instances 和 AWS Savings Plans 等承诺式资源，nOps 帮助团队最大化节省、降低风险，并将人工 FinOps 的运营负担自动化。如今，nOps 服务的客户管理的云支出已超过 40 亿美元。
在本文中，我们介绍 nOps 如何迁移到 Amazon Bedrock AgentCore、Databricks Lakehouse Metric Views、Databricks Lakebase、Amazon DynamoDB 和 Vercel，以加速产品交付、提升响应质量并降低运营复杂度。
随着产品组合和客户群的扩大，前端和后端团队需要在维持高可靠性和多租户隔离的同时，支持日益复杂的分析工作流。现有基础设施模式带来了摩擦：
响应延迟和不一致：来自 API 数据访问的长上下文消息增加了延迟，降低了响应一致性。
系统复杂性：多层编排和可观测性层增加了系统复杂度。
创新拖累：工程时间越来越多地消耗在基础设施维护而非产品创新上。
"我们试图在并非为分析驱动型 Agent 设计的基础设施上构建高级 AI 能力，这使得迭代缓慢、复杂且容易出现不准确。"
在迁移之前，我们在现有基础设施组件之上推出了 Clara（我们的 FinOps AI Agent），这些组件包括 Kubernetes、Amazon Bedrock 模型调用、LangChain/LangGraph 编排以及围绕 Web API 的工具封装层。
这实现了快速的初始交付，但也暴露了结构性限制：
洞察时间变慢：API 形式的数据和大上下文窗口增加了轮次延迟。
运营开销：多层非专用构建的层使迭代和调试更加困难。
数据路径不匹配：Agent 回答与 API 响应绑定，而非来自专用语义分析层。
为此，我们转向了专为构建而设计的架构，以 Amazon Bedrock AgentCore 为运行时/编排核心，Databricks Metric Views 提供受治理的分析语义，Databricks Lakebase 存储持久化应用状态。我们选择 Bedrock AgentCore 是因为其托管式 Agent 运行时、内置内存和编排能力，以及使用任意框架或模型的自由度。凭借这种自由度，我们基于 Strands 构建，并在不切换服务的情况下演进模型选择，使团队能够专注于领域逻辑而非基础设施。
我们设计新架构以随需扩展、产生准确答案，并让开发者更快交付。
下图说明了在 Amazon Bedrock AgentCore 上构建的 nOps Clara 解决方案的端到端架构：
Figure 1: nOps Clara 解决方案在 Amazon Bedrock AgentCore 上的端到端架构
该解决方案由以下部分组成：
交互层：托管在 Vercel 上的 Next.js Web 应用，客户通过对话界面与 Clara 交互，后端由流式 Server-Sent Events 支撑。
Agent 运行时层：Amazon Bedrock AgentCore 运行单个基于 Strands 的 Agent，直接访问画布操作、查询执行、数据源发现和工作流编排的工具，减轻了多 Agent 路由开销。
数据层：Databricks Lakehouse Metric Views 提供受治理的语义分析层，Databricks Lakebase（无服务器 PostgreSQL）存储持久化应用状态，如会话、画布和组件规范。
异步工作流层：事件驱动的执行路径，使用 Amazon DynamoDB 作业跟踪、Amazon Simple Notification Service（Amazon SNS）和 Amazon Simple Queue Service（Amazon SQS）通知，以及 Amazon API Gateway WebSocket 推送，用于更新 UI 的长时间运行的分析任务。
在交互层，客户通过托管在 Vercel 上的 Web 应用使用 Clara。请求通过 Next.js Backend for Frontend（BFF）流动，调用 Amazon Bedrock AgentCore。Clara 作为基于 Strands 的 Agent 运行时运行，支持流式响应和工具调用。用户可以手动调用 Clara 通过 Strands 工具调用的相同工作流。这是 Clara 的重要需求和构建块，因为它要求 Agent 执行遵循与产品在需求中人类相同的程序的任务。
运行时部署为 Amazon Bedrock AgentCore 上的 Docker 容器，全部基础设施（运行时、内存、护栏、队列和工作函数）在单个 AWS Cloud Development Kit（AWS CDK）堆栈中定义。Clara 使用单 Agent 架构而非多 Agent 路由器：一个 Strands Agent，直接访问以下工具：画布操作、查询执行、数据源发现和工作流编排。这避免了 Agent 间交接的延迟和错误传播开销，同时保持工具调度确定性。
流式是体验的核心。一个自定义合并层位于 Strands 异步流和 Server-Sent Event 输出之间，在一个通道中处理三个关注点：
心跳在长时间工具执行期间保持连接活跃。
带词边界感知的文本缓冲区刷新将小型模型增量合并为可读块，有助于防止用户界面（UI）闪烁。
组件轮询工作器将实时画布更新事件交织到同一流中。
Clara 使用 AgentCore 内存和三种策略（语义事实、用户偏好和画布摘要），因此它了解每个用户如何随时间与数据交互。偏好影响布局选择、默认聚合和图表类型。事实捕获组织上下文，如账户结构和成本分配约定。画布摘要跨会话保留分析线索，使用户能够在不重新解释上下文的情况下从上次中断处继续。会话以画布为单位作用域（而非临时 HTTP 会话），因此对话上下文在浏览器刷新和重新连接后仍然存在。
对于租户隔离，Amazon Bedrock Guardrails 作为独立预检在调用 Agent 前对原始用户提示词运行，执行跨租户数据访问策略和提示词攻击检测。然后租户策略层清理出站流块和组件事件，在到达前端前 redact 内部标识符。
在数据层，Clara 不再依赖通用产品 API 获取分析上下文。相反，它使用精调的工具对 Databricks SQL Warehouse（由 Databricks Lakehouse Metric Views 支撑）执行结构化查询语言（SQL）。这提供了针对度量和维度的受治理语义层，提高了对话回答与仪表板输出之间的一致性。
用户提问：显示我过去 30 天的真实 AWS 成本，按账户细分。
原始 SQL MCP 方式：工具每次必须跨各种 AWS 定价程序和基于承诺的折扣重新计算业务逻辑，然后加入并规范化这些值，再按账户分组。
-- Raw SQL MCP approach
-- User asks: "True Customer Cost for last 30 days by account"
SELECT
a.account_name,
SUM(
-- Base amortized cost
COALESCE(c.amortized_cost, 0)
-- Apply EDP discount
- COALESCE(c.edp_discount_amount, 0)
-- Apply PPA credits
- COALESCE(c.ppa_credit_amount, 0)
-- Add RI effective amortized component
+ COALESCE(c.ri_effective_cost, 0)
-- Add Savings Plan effective amortized component
+ COALESCE(c.sp_effective_cost, 0)
) AS true_customer_cost
FROM raw_cost_and_usage c
JOIN account_dim a
ON c.account_id = a.account_id
LEFT JOIN pricing_adjustments p
ON c.account_id = p.account_id
AND c.usage_day = p.usage_day
WHERE c.usage_day >= date_sub(current_date(), 30)
AND c.usage_day < current_date()
AND c.charge_type NOT IN ('Credit', 'Refund')
GROUP BY a.account_name
ORDER BY true_customer_cost DESC;
Metric View MCP 方式：工具查询预定义度量，利用详细注释和同义词（例如 true_customer_cost）以及维度（account_name）和时间范围（过去 30 天）。
-- Metric View MCP approach
-- Same user ask, but financial logic is pre-modeled in metric view measure
SELECT
account_name,
SUM(true_customer_cost) AS true_customer_cost
FROM mv_true_customer_cost
WHERE usage_day >= date_sub(current_date(), 30)
AND usage_day < current_date()
GROUP BY account_name
ORDER BY true_customer_cost DESC;
结果：True Customer Cost 的一个受治理定义、更简单的 MCP 逻辑，以及聊天和仪表板之间一致的输出。
ID：true_customer_cost 显示名称：True Customer Cost 注释：客户在获得信用、退款、承诺和折扣（如 Enterprise Discount Program（EDP）和 Private Pricing Agreements（PPA））后的真实成本。
同义词：用于 LLM 分析的自定义字段。我们将同义词改造用于 key:value 对，以向前端发送额外元数据。
在状态层，Databricks Lakebase（无服务器 PostgreSQL）存储持久化产品对象、会话、画布、组件和查询/图表规范，因此聊天中生成的洞察可以提升为持久的、可共享的分析制品。
对于长时间运行的分析工作流，我们引入了异步执行路径，使用工作流工作器、Amazon DynamoDB 作业跟踪、Amazon SNS 和 Amazon SQS 通知，以及 Amazon API Gateway WebSocket 推送。Clara 然后可以提供响应式用户交互，而重型处理在后台完成并实时更新 UI。
Together, these components form a single, managed architecture where:
通过围绕 Amazon Bedrock AgentCore 和 Lakehouse 优先的分析模型重构 Clara，我们为 AI 驱动的 FinOps 工作流建立了更具可扩展性的基础。
生产时间缩短 75%，将自管理的 Amazon Elastic Kubernetes Service（Amazon EKS）堆栈替换为单一托管服务后，从 10-12 个月缩短到 4 个月。
现在有 4-6 个生产就绪的 Agent 在共享运行时上提供分析服务。
正确性得分达到 81.7%（相比上一周期提升 145%），而 v1 约为 65%。
有用性得分达到 79.4%（相比上一周期提升 138%）。
在采用 Amazon Bedrock AgentCore 和新工具调用方法后，工具失败率从 7.49% 降至 0.92%。
人工分析时间减少 75%，Customer Success Managers 和 Solutions Architects 从约 2 小时缩短到 30 分钟。
通过流式响应和基于推送的工作流完成，减少了客户成功、解决方案架构和销售团队的手动日常工作。
完全移除了 LangGraph/LangChain 编排层，由 AgentCore 运行时和 AgentCore 内存以及内置请求路由和可观测性替代。这解放了工程团队，使其能够专注于产品差异化。
我们将 Clara 从一个分层的、API 驱动的 AI 助手转变为统一的、Agent 原生的分析系统。通过将 Amazon Bedrock AgentCore 与 Databricks Lakehouse Metric Views 和 Lakebase 相结合，我们创建了一种可重复的模式，用于构建在规模下保持准确且无需繁重运营开销的企业级 AI 分析体验。
要了解更多关于构建 Agent 原生应用的信息，请访问 Amazon Bedrock AgentCore 文档。要了解我们在生产环境中如何使用这些能力，请访问 nops.io。