nOps借助Amazon Bedrock AgentCore将FinOps代理交付速度提升75%

一句话看懂

nOps用Amazon Bedrock AgentCore替换自建EKS+LangChain栈，将FinOps代理Clara的交付时间缩短75%，从10-12个月降至4个月，同时提升响应质量并降低运维负担。

详细发生了什么

nOps是一家AI驱动的云优化方案提供商，管理着超过40亿美元的云支出。其FinOps代理Clara原本构建在自管理的Amazon EKS集群上，使用LangChain/LangGraph编排，并依赖API工具包装器。这种架构带来了三大问题：响应延迟高且不一致（长上下文消息拖慢速度）、系统复杂度高（多层编排和可观测性）、创新受阻（工程时间被基础设施维护占据）。

为此，nOps转向以Amazon Bedrock AgentCore为核心的目标架构，结合Databricks Lakehouse Metric Views提供治理的语义分析层，以及Databricks Lakebase（serverless PostgreSQL）存储应用状态。新架构采用单代理设计，一个基于Strands的代理直接访问画布操作、查询执行、数据源发现和工作流编排等工具，避免了多代理路由的开销。流式输出通过自定义合并层处理心跳、文本缓冲和widget轮询，确保UI流畅。AgentCore内存支持三种策略（语义事实、用户偏好、画布摘要），实现跨会话的上下文持久化。租户隔离通过Amazon Bedrock Guardrails预检查原始提示词，并在输出流中脱敏内部标识符。

迁移后，交付时间从10-12个月缩短至4个月，响应质量提升，运维复杂度显著降低。

中文圈视角

对国内用户来说，这个案例有几个值得关注的盲点。首先，Amazon Bedrock AgentCore目前在中国区不可用，国内用户若想复现类似架构，需考虑替代方案，如阿里云的百炼平台或百度智能云的千帆，它们也提供托管代理运行时和工具调用能力，但生态和成熟度仍有差距。其次，nOps的架构核心在于“语义分析层”而非API直连，这提醒国内FinOps工具（如阿里云成本管家、腾讯云计费分析）在AI化时，应优先构建治理的指标层，避免让代理直接对接原始API导致延迟和准确性差。最后，对于使用AWS中国区或通过海外账号使用Bedrock的用户，AgentCore的托管特性确实能减少自建Kubernetes的运维负担，但需注意数据出境合规，确保客户数据不违反《数据安全法》。

几条值得记住的细节

迁移后交付时间从10-12个月降至4个月，提速75%。
新架构使用单代理（Strands）而非多代理路由器，减少延迟和错误传播。
数据层使用Databricks Metric Views，确保对话答案与仪表盘输出一致。
AgentCore内存支持语义事实、用户偏好和画布摘要，实现跨会话上下文。
租户隔离通过Guardrails预检查和输出流脱敏实现。

一句话总结

对云成本管理工具而言，托管代理运行时加语义层是提升交付速度和响应质量的关键，国内用户需关注替代方案与合规。