TReNDS 如何用 Amazon Bedrock 将根因分析压缩至60秒以内

TReNDS 中心自2019年起将基础设施迁移至 AWS，所有应用运行在 Amazon EKS 集群上，并通过 FluentBit 将日志统一输送至 Amazon CloudWatch。随着研究工具和 API 数量增多，需要排查的错误量也随之上升。团队意识到，虽然监控告警能及时通知「出了什么问题」，但弄清楚「为什么出问题」仍然完全依赖工程师手动操作，这一环节成为事故响应中最耗时的瓶颈。

整套自动化架构的核心逻辑如下：CloudWatch 订阅过滤器持续监听 ERROR、Exception、FATAL、CRITICAL 等错误级别模式，一旦匹配即触发 Lambda 函数。Lambda 内运行由 Amazon Bedrock 驱动的 Strands 智能体，智能体完成调查后将结构化分析结果发布至 Amazon SNS 主题，最终推送给工程团队。整个链路无需人工介入，从错误发生到分析送达全程自动完成。

Strands Agents SDK 负责工具调用的编排逻辑。开发者只需定义可用工具，基础模型便会自主决定何时调用哪个工具。在所有工具中，源码获取工具最为关键：堆栈跟踪中包含文件路径和行号，但若没有实际源码，智能体只能停留在日志模式匹配层面。通过为智能体赋予读取 GitHub 仓库源文件的能力，它可以追踪执行路径、定位导致故障的具体代码段，从而生成真正有价值的根因分析。

在工具定义层面，Strands SDK 采用 Python 装饰器方式，开发者只需在函数上添加 @tool 注解，并通过规范的类型提示和文档字符串告知模型工具的用途与参数格式。模型会根据错误内容自主判断是否调用该工具。例如，面对一段堆栈跟踪，智能体可能先拉取相关源文件，发现需要更多上下文后再搜索相关错误处理逻辑，最终输出结构化分析，整个调查路径无需硬编码。

合规性是 TReNDS 在架构设计中的重要考量。由于研究数据可能涉及 HIPAA 要求，团队选择 Amazon Bedrock 的关键原因之一在于其在 AWS 账户内处理请求的机制——日志数据与源码始终留在既有的安全边界之内，不会发送至外部端点。这一特性使得 AI 分析能力与数据合规要求得以兼容，为处理健康相关研究数据的机构提供了可参考的落地路径。

尽管 TReNDS 的实现基于 EKS 与 FluentBit，但该架构模式同样适用于其他将日志输送至 CloudWatch 的应用场景，包括 ECS、Lambda、EC2 以及通过 CloudWatch Agent 接入的本地工作负载。对于希望降低事故响应人力成本、同时保持数据合规的工程团队而言，这套以智能体为核心的根因分析流水线提供了一个具有实际生产验证的参考架构。

要点

• TReNDS 将根因分析耗时从15至30分钟压缩至60秒以内，核心在于让 AI 智能体自动完成日志拉取、源码读取和路径追踪等原本由工程师手动执行的步骤。
• Strands Agents SDK 通过工具调用编排机制让基础模型自主决策调查路径，无需硬编码排障逻辑，显著降低了智能体系统的开发复杂度。
• Amazon Bedrock 在 AWS 账户内处理请求的特性，使该方案能够满足 HIPAA 等数据合规要求，适合处理健康研究数据的机构采用。
• 该架构不局限于 EKS 环境，凡是将日志输送至 CloudWatch 的应用均可复用这一模式，具备较强的通用性。
• 源码获取工具是整套系统中最关键的能力扩展，赋予智能体真正理解代码执行路径的能力，而非仅停留于日志文本分析。