亚马逊AWS官方博客

从0到1:联想基于Strands Agent SDK的资源智能巡检Agent创新

前言

数字化浪潮已推动企业从传统数据中心迁移至公有云平台，现在正经历着另一场巨大的技术变革，站在从数字化向智能化转型的巨浪上。这一转变不仅是技术升级，更是运维理念的根本变革。

AI技术的快速发展为运维转型提供了强大动力，使我们能够实现三个关键目标：从被动响应故障转向主动预测隐患；通过AI及时识别潜在风险；提升运维效率与准确性。对一线运维人员而言，这一转型意义重大。他们将从繁琐的日常巡检和例行维护等重复性工作中解放出来，转而专注于系统架构优化、性能调优等更具创造性和挑战性的任务。这使得他们能够充分发挥多年积累的专业经验，真正体现在处理复杂问题时的独特价值。

Lenovo运维巡检的挑战与智能化需求

在Lenovo的公有云运维团队，关注服务状态、预防潜在问题，这是确保系统稳定运行的关键日常工作之一。传统资源巡检方法依赖人工操作，存在明显局限性。这种方式不仅耗时费力，还容易出现疏漏，导致故障难以及时发现，严重时会影响业务连续性。随着云资源部署规模扩大，人工巡检也已经无法实现全面覆盖，而且公有云运维团队缺乏基于项目维度的巡检报告作为参考，这也使得难以评估各项目状态，智能化解决方案迫在眉睫。

AI Agent技术以及LLM能力的日渐成熟为解决这些挑战提供了新思路。Lenovo的创新中心团队需要发展智能化多Agent协作的智能运维系统来解决大量资源的日常巡检问题，基于私域知识和最佳实践处理复杂的业务报告生成需求，解决人工无法解决的问题。智能化转型既是技术升级，也是运维理念变革，这将确保Lenovo的公有云运维团队在云资源规模不断扩大的环境中保持高效可靠的IT运维能力https://staging.prod.website.marketing.aws.dev/cn/blogs/china/strands-agent-sdk-resource-intelligent-inspection-agent-innovation/，这也是开发智能巡检助手的初衷。

AI Agent开发的技术选型

在设计开发智能巡检Agent的最初，我们希望选择一种上手快，复杂度低且功能相对完善的开发工具。AWS最新开源的Strands Agent SDK进入了我们的视野。Strands Agent SDK是一个由AWS开源专注于Agent开发的轻量级框架，其核心理念是通过模型能力驱动的方法来构建Agent应用。Strands采用了一种更加务实的设计理念——Agent Loop。

这个概念简单而强大是Strands Agent 的功能核心，这种模式充分利用了 LLM 的原生推理、规划和选择工具的能力。这种设计不仅让代码结构变得清晰易懂，更重要的是它完美契合了我们对Agent行为的理解。在实际开发中，发现该框架基于Agent Loop构建的系统天然具有良好的可扩展性，新功能的添加变得更加流畅。新开发者也能快速掌握框架运作机制。Strands Agent SDK提供了丰富的工具，接口支持，除了Amazon Bedrock以外，Anthropic API，Llama API，Ollama，LiteLLM等形式的模型也可以支持。

基于AWS的AI Agent智能巡检Agent设计

系统架构

从系统层面看，我们采用了三层架构设计。

UI层/用户接入层

接入层是系统与用户的交互层，由Application Load Balancer (ALB) 作为流量入口，负责请求的分发与负载均衡，Nginx 服务器提供反向代理功能，基于 Vue.js 构建的前端 UI 为用户提供了与Agent的交互界面。

网关层

网关层承担着四项关键功能：用户鉴权模块严格把控访问权限，确保只有授权用户才能使用系统功能，并根据用户角色权限限制其访问数据类型。Agent路由组件则根据用户请求的内容，选择最适合处理该任务的Agent。用户会话管理系统维护着用户的session信息，保证多轮对话的连贯性和上下文理解的准确性，实现短期记忆功能。而 FastAPI为整个网关层提供了强大的 API 服务能力，处理前端发来的各类请求并与后端系统进行高效通信。

业务层

业务层主要包含两种Agent，一个公有云巡检助手专注于基于云资源的监控数据，配置情况，运维记录等，生成相应的巡检报告。知识库助手则擅长AWS相关信息检索与内部知识提取，针对资源情况以及一般指导类问题给出相应的优化建议。

基础设施架构

系统完全托管在AWS云平台上，深度整合其云服务，构建了高弹性、高可用的基础设施。整体架构包含以下核心组件：

容器化部署环境

系统的核心服务组件（前端服务、Agent服务等）部署在Amazon Elastic Kubernetes Service (Amazon EKS) ，MCP Server作为工具调用的接口服务，同样部署在Amazon EKS环境中，这种容器化部署方式显著提升了系统灵活性和运维效率。

数据存储层

Amazon Simple Storage Service (Amazon S3)：存储用户与Agent交互的session信息，实现Agent的短期记忆功能。

Amazon Aurora Serverless v2：提供高性能无服务器关系型数据服务，用于存储云资源监控数据、配置信息、源数据以及工单信息、维护人员信息等运维数据，支持生成运维巡检报告

基于AWS托管服务提供AI能力支持

Amazon Bedrock：为Agent提供大模型能力，支持复杂决策推理；Amazon Bedrock Guardrail：基于上下文内容检测模型幻觉，过滤不良主题和敏感词；Amazon OpenSearch：为Agent提供知识库RAG功能，结合Amazon Bedrock的embedding模型能力，将内部私域知识转化为向量存储并提供检索

可观测性平台

选择Langfuse作为监控平台。作为专为LLM应用设计的开源可观测性平台，它通过OpenTelemetry协议将Agent的观测数据通过Langfuse的endpoint存储到ClickHouse，并提供专业化分析展示，构建高效、可扩展的LLM性能可视化系统。对AWS用户而言，Amazon CloudWatch也提供了便捷替代路径，实现快速部署与现有监控体系的无缝集成。

系统流程

基于系统流程图，可以清晰地追踪一个用户请求是如何被处理的。

核心功能实现

Agent工作模式的选择

Strands Agent SDK主要支持四类型Agent的工作模式：

• Agent as Tools（编排模式）：由主导Agent负责任务分析和决策，动态调用专业辅助Agent完成特定任务。这种分工模式适用于需多领域知识协作的场景，实现复杂任务的高效分解与处理。
• Swarm（群体智能模式）：多个Agent共享信息并行协作，类似群体讨论。各Agent独立思考并贡献解决方案，系统整合形成集体智慧。适用于产品设计评估、市场分析等需多角度思考的复杂问题。
• Graph（网络拓扑模式）：构建Agent互联网络，节点代表单个Agent，边缘表示通信连接。信息在网络中灵活流动，支持复杂分布式决策。较Swarm模式，更适合复杂分布式和自适应学习场景。
• Workflow（工作流模式）：通过预设流程控制Agent间信息传递和执行顺序，形成链式处理系统。每个Agent专注特定步骤，输出作为下一环节输入。适合有明确处理阶段的任务，如内容生产流水线、数据处理管道等，确保过程可预测且一致。

在选择Agent as Tool还是Workflow工作模式时，我们经过多次权衡。也就是说，是给予Agent更大的发挥自由度？还是按照既有的流程按部就班的从抽取数据，分析到生成报告？在多次尝试之后依旧选择了workflow模式。Workflow模式的优势是：巡检报告生成本质上是线性、有序的过程——从数据提取、统计分析到可视化和报告撰写，每步都依赖前一步的完整输出。Agent as Tool模式的劣势是：在此场景下引入了不必要的复杂性，Agent需维护庞大的分析上下文并做出正确的工具调用决策。因此，我们最终选择了Workflow模式。

大量数据的处理

云资源或长时间状态数据以及运维数据生成运维巡检报告的场景，我们遇到了输入数据可能超出大模型token上限且可能导致模型注意力分散的挑战。由于LLM存在token上限，且一次输入过多数据会导致注意力分散，我们采用数据分片策略：将大量信息拆分成可管理的片段，由多个Agent并行处理，每个Agent只处理有限数据，从而规避token限制，减少注意力分散风险，最后通过汇总Agent输出的结果生成报告。这种分布式处理方法不仅有效规避了LLM的token限制，减少注意力分散，还保证了每个Agent聚焦于有限数据集进行分析。在基于大体量数据生成分析报告时，提升了生成运维巡检报告的效率和相对的准确性。

数据访问权限的管控

对于现代大型跨国制造企业，安全始终是首要任务且具有最高优先级。尽管我们的AI Agent系统仅供内部用户使用，数据安全仍需全面考量。在系统网关层，我们通过集成公司内部的LDAP实现了用户身份鉴权，确定用户可以访问哪些项目的数据。同时，我们着重解决了用户通过Agent访问数据的权限管控问题。

遵循AWS倡导的最小权限原则，确保用户只能访问完成任务所必需的最少数据。我们对数据进行了分类管理，按不同业务线和敏感度划分，结合用户可访问的项目类别进行授权。用户的身份与权限信息会作为上下文传递给Agent。在零信任架构下，Agent每次访问受限数据都必须重新验证身份。这种方式避免了依赖先前’可信’状态的风险，有效防止了用户通过已有权限进行的横向渗透。此外，我们建立了完善的审计日志系统记录所有访问行为，并计划未来通过AI Agent技术实时检测异常活动。

Text-to-SQL（Txt2SQL）功能的实现

系统中把Txt2SQL做成了MCP Server对外提供文本到SQL的转化。具体的实现受到OpenSearch-SQL的启发，结合智能巡检的特殊需求场景，进行了自研重构与优化。OpenSearch-SQL是一个在 2024 年 8 月 BIRD 比赛中获得第一名的全面文本到 SQL 框架。简单的说它是由 Preprocessing、Extraction、Generation、Refinement 以及 Alignment 模块组成，通过Schema Linking和Beam Search简化了答案的生成，通过Self-Consistency和voting提升了整个框架的性能。

OpenSearch-SQL架构

（https://github.com/OpenSearch-AI/OpenSearch-SQL/tree/main）

Agent流式数据的同异步处理

Agent在处理数据输出时主要有两种模式：Stream（同步流）和Async Stream（异步流）。

Stream模式适用于同步式输出场景，使Agent在执行过程中逐步展示增量结果，如Chatbot边思考边回应的交互方式，使用户能及时看到生成内容的进度。Async Stream模式则适用于异步执行环境，支持非阻塞I/O操作。当应用场景对响应时间有严格要求且需要并发处理资源时，这种模式尤为有效。典型场景包括AI Search中的研究过程，系统需要查询外部网站、关联多个数据源才能生成完整结果。在实际应用中，某些复杂场景可能会需要两种模式结合使用。

在巡检Agent系统中，根据不同场景选择了适当的模式：基于ChatBot简单搜索对话场景采用Stream模式；而生成运维巡检报告这类需要并发处理的复杂任务则采用Async Stream模式。

在Strands Agent SDK中如何实现异步数据流的输出呢？这部分异步数据处理功能的实现得益于 agent.stream_async() 方法的出现，这使得最终用户可以逐字查看Agent的答案生成过程，并观察正在使用哪些工具，而无需等待最终输出。以下是一个异步数据流输出的代码例子。

方法返回一个异步事件迭代器，每个事件都是一个字典并可以与FastAPI进行集成。Strands Agent SDK目前支持的事件 类型与属性如下，在未来SDK版本中会加入Tool调用过程中吐出数据流相关的事件类型：

基于以上的事件列表，当 Agent 调用 Tool 时，一个典型的数据事件流程可能是如下流程：

基于以上的分析，在智能巡检Agent中，在生成报告的过程中我们实现了类似AI Search的互动模式，这部分功能我们还加入了控制器来控制是否需要输出思考过程：

最终效果

基于终端业务人员给出的需求，智能体可以生成以下针对不同项目组的资源巡检业务报告。以下是针对摸个项目中过去一段时间的资源巡检报告内容包括：资源过去一段时间运行情况，并基于监控数据给出具体风险点，基于最佳实践的改善建议。运维团队过去一段时间处理的工单数量，等级以及负责人。

AI赋能运维的未来展望

智能巡检Agent的核心设计理念是”专职型Agent”模式——让每个Agent专注于处理特定任务。这一策略是基于当前大模型能力的实际限制和Agent系统扩展性的综合考量。在短短几年内，AI技术已经展现出惊人的进步速度，这无疑将为制造业企业带来前所未有的商业机遇与技术变革。随着技术的飞速发展，我们期待未来通用大模型能力的突破可能会催生真正的”通用型Agent”。

运维工程师常被称为系统稳定的”无名英雄”，他们的贡献往往隐藏在日复一日的系统维护工作中。AI技术的革新正在重塑运维工程师的传统角色——它将一线运维人员从繁琐但必要的系统保障工作中解放出来，使他们能够专注于那些真正需要人类独特思维和创造力的领域。AI不仅是工具也不仅仅是助手，它将持续引领联想智能运维体系的创新与重构，在提升效率的同时，也为运维团队创造更广阔的发展空间。这支被赋能的团队将能够承担更重要的使命，为业务创新提供更加稳定可靠的基础设施保障。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。