admin管理员组文章数量:1446760
Agentic AI在可观测领域的应用潜力与实践路径探讨
前言
从deepseek -> manus general AI agent
- 模型侧： 模型的训练成本、推理能力
- 应用侧： Agents带来的end-2-end 解决问题能力的曙光
Why: Agentic AI对于可观测、SRE带来的潜力思考
传统可观测/AIOps都偏向于解决单个场景问题
AIOps三板斧：异常检测--> 告警关联--> 根因诊断
传统可观测和AIOps往往侧重于解决单个场景问题，面对复杂多变的实际情况，显得有些力不从心。
LLM & Agentic AI 带来的反思规划、工具调用、多agent协作等能力日益提升
思考：构建SRE Agent数字分身， 实现对多个场景的串联、 协作， 助力SRE解决“日常琐事”
是否可以利用Agentic AI， 构建SRE数字分身，充分发挥出LLM的规划推理和总结能力， 同时结合AIOps 小模型作为工具来解决确定性的数据分析、RCA分析。 从而来解决日常高重复、高消耗SRE精力的场景和事项。
SRE 在哪些场景和事项上很疲惫？
工作内容分类 | 时间占比（示例） | 工作描述 | 是否为重复性工作 | 对 SRE 是消耗还是高价值 |
|---|---|---|---|---|
系统监控与告警管理 | 20% - 30% | 1. 配置和维护监控工具，确保对系统关键指标（如 CPU 使用率、内存占用、网络流量、请求延迟等）的实时监测。2. 设定合理的告警阈值，及时发现系统异常情况。3. 处理告警信息，判断告警的严重程度并采取相应措施。 | 部分是，如日常监控和告警处理 | 既是消耗（日常处理繁琐），也是高价值（及时发现问题保障系统稳定） |
故障排查与修复 | 15% - 25% | 1. 当系统出现故障时，迅速定位问题根源，可能涉及到对日志的分析、系统状态的检查等。2. 制定并实施故障修复方案，尽量减少系统停机时间。3. 对故障进行复盘，总结经验教训，提出改进措施以防止类似故障再次发生。 | 部分是，每次故障虽然情况不同， 但对于精力和经验很依赖 | 高价值（保障系统可用性，提升系统可靠性） |
性能优化 | 10% - 20% | 1. 分析系统性能瓶颈，例如通过性能测试工具找出响应缓慢的接口或模块。2. 优化系统架构、代码逻辑或配置参数，以提高系统的性能和响应速度。3. 评估优化效果，持续进行性能调优工作。 | 不是，不同阶段优化重点不同 | 高价值（提升用户体验，增强系统竞争力） |
容量规划与资源管理 | 5% - 15% | 1. 根据业务增长趋势和历史数据，预测系统未来的资源需求（如服务器数量、存储容量、带宽等）。2. 合理分配和管理资源，确保系统在满足业务需求的同时避免资源浪费。3. 监控资源使用情况，及时进行资源调整和扩容。 | 部分是，如定期资源监控 | 高价值（保障业务发展，控制成本） |
自动化脚本开发与维护 | 10% - 20% | 1. 开发自动化脚本，用于系统部署、配置管理、监控数据采集等重复性工作，提高工作效率。2. 对现有自动化脚本进行维护和更新，确保其稳定性和兼容性。3. 推广自动化工具和流程，提高团队整体的自动化水平。 | 部分是，如脚本维护 | 高价值（提高效率，减少人为错误） |
新功能上线支持 | 10% - 20% | 1. 在新功能开发阶段，参与设计评审，从可靠性角度提出建议和意见。2. 协助开发团队进行新功能的测试，包括性能测试、稳定性测试等。3. 在新功能上线时，提供现场支持，及时处理可能出现的问题。 | 不是，每次新功能不同 | 既是消耗（投入时间精力），也是高价值（保障新功能可靠性） |
文档编写与知识管理 | 5% - 10% | 1. 编写系统架构文档、操作手册、故障处理流程等技术文档。2. 整理和分享工作中的经验和知识，促进团队成员之间的学习和交流。3. 维护和更新知识库，确保信息的准确性和及时性。 | 部分是，如文档更新维护 | 既是消耗（花费时间精力），也是高价值（知识传承，提升团队能力） |
与其他团队协作 | 10% - 20% | 1. 与开发团队密切合作，共同解决技术问题，推动项目进展。2. 与运维团队协作，协调系统部署、变更等工作。3. 与业务团队沟通，了解业务需求，提供可靠的技术支持。 | 不是，每次协作场景和需求不同 | 高价值（促进团队合作，推动业务发展） |
变更值守 | 5% - 15% | 1. 在系统进行变更（如代码部署、配置修改、硬件更换等）期间，全程监控系统状态，密切关注各项关键指标的变化情况。2. 及时响应并处理变更过程中出现的任何异常情况，如告警信息、性能下降等，迅速采取措施进行故障排查和修复，确保变更顺利完成。3. 与变更实施团队保持紧密沟通，及时反馈系统状态和问题，协调各方资源解决变更过程中遇到的技术难题。4. 在变更完成后，对系统进行全面检查和验证，确保变更达到预期效果，且系统运行正常。 | 部分是，每次变更都可能需要值守，但变更内容和情况不同 | 既是消耗（值守期间需持续关注，耗费精力），也是高价值（保障变更顺利进行，降低变更对系统稳定性的影响 ） |
What: 介绍Agentic AI的概念、特点
What is Agentic AI
- Agentic AI 是一种完全自主性的 AI。这意味着它可以做出决策、采取行动，甚至自行学习以实现特定目标。这有点像拥有一个虚拟助手，它可以思考、推理和适应不断变化的环境，而无需不断的指导。 Agentic AI 分四个关键阶段运行：
- Perception: It gathers data from the world around it. 感知：它从周围的世界收集数据。
- Reasoning: It processes this data to understand what’s going on. 推理：它处理这些数据以了解发生了什么。
- Action: It decides what to do based on its understanding. 行动：它根据自己的理解来决定做什么。
- Learning: It improves and adapts over time, learning from feedback and experience. 学习：它会随着时间的推移而改进和适应，从反馈和经验中学习。
AI Agent --> Agentic AI的转变
两者的主要区别，主要在于以下几点：
- AI Agent更侧重于智能实体的基本功能和自主性，而Agentic AI则强调系统在更高层面上的自主决策、自我学习和问题解决能力。
- Agentic 需要突出学习能力， 可以从反馈和经验中学习
- AI Agent可以看作是实现Agentic AI的一种技术手段或组件，而Agentic AI则是AI Agent在特定工作流程和目标导向下的一种表现形式。
通信协议： 不同数据源和工具如何统一集成进Agent?
MCP 协议
MCP 是一种开放协议，对于AI应用如何提供context给到LLM， MCP提供了一套标准。 因此可以将 MCP 想象成 AI 应用的 USB-C 端口。正如 USB-C 提供了一种将设备连接到各种外围设备和配件的标准化方式一样，MCP 也提供了一种将 AI 模型连接到不同数据源和工具的标准化方式。
MCP 架构
At its core, MCP follows a client-server architecture where a host application can connect to multiple servers:
MCP 的核心遵循客户端-服务器架构，其中主机应用程序可以连接到多个服务器：
- MCP Hosts: Programs like Claude Desktop, IDEs, or AI tools that want to access data through MCP MCP 主机：希望通过 MCP 访问数据的 Claude Desktop、IDE 或 AI 工具等程序
- MCP Clients: Protocol clients that maintain 1:1 connections with servers MCP 客户端：与服务器保持 1：1 连接的协议客户端
- MCP Servers: Lightweight programs that each expose specific capabilities through the standardized Model Context Protocol MCP 服务器：轻量级程序，每个程序都通过标准化的 Model Context Protocol 公开特定功能
- Local Data Sources: Your computer’s files, databases, and services that MCP servers can securely access 本地数据源：MCP 服务器可以安全访问的计算机文件、数据库和服务
- Remote Services: External systems available over the internet (e.g., through APIs) that MCP servers can connect to 远程服务：MCP 服务器可以连接到的 Internet 上可用的外部系统（例如，通过 API）
业界 review：目前都在拿Agents在可观测/SRE等方向做什么及怎么做的？
产业界：Service Now
Paper works：
title | link | 类型 | code |
|---|---|---|---|
RCAgent: Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models | .16340 | RCA | |
Exploring LLM-based Agents for Root Cause Analysis | .04123 | RCA | |
mABC: multi-Agent Blockchain-Inspired Collaboration for root cause analysis in micro-services architecture | .12135 | RCA | |
Flow-of-Action: SOP Enhanced LLM-Based Multi-Agent System for Root Cause Analysis | .08224 | RCA | |
AI Agents for Cloud Reliability: Autonomous Threat Detection and Mitigation Aligned with Site Reliability Engineering Principles | .12165v1 | SRE | |
FlipAI： System of Intelligent Actors: The DevOps chapter | SRE | ||
Nissist: An Incident Mitigation Copilot based on Troubleshooting Guides | .17531 | SRE |
Flip AI
这个系统旨在通过自动化的方式来模拟传统的“war room”过程，以解决生产环境中的事故调试和根本原因分析问题。具体来说，该系统包括以下几个关键组件：
- Director：负责创建一个特定的运行手册来调试事故，并调用多个Actor来执行步骤。Director使用自定义的领域特定语言（DSL）来生成计划。
- Actors：是自给自足的模块，每个Actor使用一个或多个Agents来自动化运行手册中的一个步骤。Actors是工作流特定的，类似于API。
- Agents：是一组专门为完成特定任务（如日志摘要、生成可观测性平台的查询等）的工具包。Agents是模型与工具之间的接口层，负责利用一组工具来完成特定任务。
- CoMELT数据：指的是代码（Code）、指标（Metrics）、事件（Events）、日志（Logs）和跟踪（Traces）的结合。这些数据是系统分析和调试的基础。
- Flow-of-Action
智能体分工：
- MainAgent：主控全局流程，从动作集中选择最优动作。
- ActionAgent：根据流程规则生成候选动作集。
- JudgeAgent：判断是否已找到根因，避免冗余操作。
- ObAgent：从历史事件中提取故障类型，辅助缩小搜索范围。
- CodeAgent：负责SOP代码生成与执行。
How: 如何搭建一套Agentic AI系统
multi-Agents System的交互和架构长什么样？
- 整体的交互逻辑
多agents 架构扩展：
具体到每一个Agent A/B/C/D （Supervisor Agent）， 也可以采取多种不同策略的agent架构， 甚至上述的整体交互也可以有多种架构：
- Supervisor ：
- 多层级：
- network：
多agents 落地中的难点
- 效率 & 效果的tradeoff
- 多轮对话的存储、 以及不同agents存储内容的差异
- ...
本文标签： Agentic AI在可观测领域的应用潜力与实践路径探讨
版权声明：本文标题：Agentic AI在可观测领域的应用潜力与实践路径探讨 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.betaflare.com/biancheng/1748353243a2851337.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论