1. 项目概述从“计划-执行”到混合PEV的必然之路在运维自动化的世界里诊断问题一直是个“脏活累活”。想象一下半夜三点线上服务突然告警CPU飙升内存泄漏日志刷屏。传统的脚本化工具要么太死板只能按预设路径走遇到新问题就傻眼要么太“聪明”像早期的AI诊断Agent试图用一个复杂的模型包打天下结果推理慢、成本高还经常“一本正经地胡说八道”。我们团队过去两年就深陷在这种“计划-执行”Plan-Execute模式的泥潭里。这个模式听起来很美Agent像一个深思熟虑的专家先制定一个完整的诊断计划然后一步步执行。但现实是线上故障千奇百怪等你“计划”完业务可能已经挂了半小时了。更别提那些计划中的步骤可能第一步执行完发现预设条件不成立整个计划就得推倒重来效率极其低下。正是这些切肤之痛迫使我们开始思考架构的演进。我们需要的不是一个只会照本宣科的“实习生”而是一个能像资深运维专家一样思考的“搭档”它能快速反应用最直接的经验Verification去试探当经验失效时它能灵活地规划Plan新的排查路径并且在每一步执行Execute后都能即时验证Verify结果动态调整策略。这就是我们最终走向“混合PEV”架构的核心驱动力——它不是一个凭空想象的理论而是被无数个深夜告警“逼”出来的实战解决方案。今天我就把这套架构的演进历程、核心设计以及我们踩过的坑毫无保留地分享出来。无论你是在构建自己的运维Agent还是对AI智能体在复杂决策场景的应用感兴趣相信这些从一线实战中总结的经验都能给你带来直接的启发。2. 架构演进的核心驱动力与设计哲学2.1 初代架构Plan-Execute模式的理想与现实我们最初的运维诊断Agent架构非常经典也非常的“教科书”。它的核心工作流就是一个严格的串行过程感知Perceive- 规划Plan- 执行Execute。Agent接收到一个告警事件或诊断请求后会调用一个大语言模型LLM结合历史工单、知识库生成一个完整的、步骤化的诊断计划。这个计划可能长这样“1. 登录目标服务器2. 执行top命令查看CPU负载3. 如果CPU高则执行jstack分析Java线程4. 如果线程阻塞则检查数据库连接池...” 然后Agent再严格地、一步一步地去执行这个计划。这个架构的优势很明显逻辑清晰可解释性强。整个诊断过程像一份详细的报告每一步都有据可查。在问题符合预期路径时它确实能解决问题。但它的致命缺陷在复杂的生产环境中被无限放大僵化与脆弱计划是静态的但线上环境是动态的。如果计划的第一步“登录服务器”就失败了比如网络抖动、密钥问题整个计划就卡住了Agent不会尝试备用登录方式或跳过此步去收集其他信息。反馈延迟规划阶段耗费大量时间和计算资源尤其是调用大模型。等计划生成完再开始执行黄花菜都凉了。而且执行过程中的中间结果无法实时反哺给规划器无法做到“边做边想”。成本高昂每一次诊断无论问题简单复杂都需要启动一次完整的“规划-执行”循环。对于“磁盘空间不足”这种一目了然的问题动用大模型来规划无异于用高射炮打蚊子。我们曾遇到一个典型案例一个API延迟飙升的告警。Agent规划了从网络、到中间件、再到应用代码的完整排查路径。但实际原因仅仅是某个宿主机上的邻居容器疯狂占用CPU。Agent按部就班地检查完网络配置和Redis连接池浪费了十分钟后才执行到top命令一眼就发现了真凶。这十分钟的“规划”和“错误执行”完全是无效成本。注意纯粹的Plan-Execute模式适用于环境稳定、问题域边界清晰、决策路径长的场景如下棋。但在运维诊断这种高实时性、强不确定性、状态瞬息万变的领域它先天的延迟和僵化就成了无法忍受的短板。2.2 演进转折点引入“验证”形成PEV闭环吃了足够多的亏之后我们意识到必须让Agent具备“即时验证”和“快速反应”的能力。诊断不像下棋不能想好所有步再落子它更像急诊医生需要“检查-判断-再检查”的快速循环。于是我们在架构中引入了“验证”Verification环节形成了Plan-Execute-Verify (PEV)的雏形。这里的“验证”不是事后的结果检查而是贯穿始终的质量控制和决策开关。它的核心作用是验证执行结果判断一个命令或操作是否成功输出是否包含预期或异常信息。验证当前状态根据收集到的信息判断是否已达到诊断目标或者是否需要触发新的规划。验证计划可行性在规划阶段后快速预判计划的第一步是否可能成功避免无效执行。例如针对“服务无法连接”的问题新的流程可能是Plan生成计划[探测端口检查进程查看日志]。Execute执行nc -zv host port。Verify验证结果。如果端口通则跳过检查进程的后续计划直接判断为网络层面正常进入更细粒度的应用层检查规划如果端口不通则立即触发一个针对“网络连通性”的子规划。引入Verify后最大的改变是“执行”有了话语权可以反过来影响“规划”。架构从“单向流水线”变成了“带反馈的循环”。但这时的PEV仍然是“顺序混合”即P-E-V作为一个整体单元循环。我们很快发现了新问题对于大量简单、模式化的问题如“磁盘空间告警”、“进程不存在”每次循环都从“规划”开始仍然太重了。能不能让Agent“不假思索”地先做点什么呢2.3 混合PEV架构条件触发与分层决策这引出了我们最终的架构形态混合PEVHybrid PEV。其核心设计哲学是根据问题的实时上下文动态选择最经济、最快捷的决策路径而非固定执行某一种模式。在这个架构中Agent被设计成拥有两套并行的决策系统反射弧系统基于Verification的快速通道这是一套高度优化、规则驱动的模式匹配器。它内置了大量“症状-动作”对我们称之为“诊断片段”。当Agent感知到事件后首先进入这个快速通道。例如事件信息中包含“DiskUsage 90%”。反射弧系统立刻匹配到“磁盘空间检查”片段跳过Plan阶段直接Execute一系列命令df -h,du -sh /*,lsof | grep deleted。然后Verify命令输出如果找到大文件或未释放句柄直接给出结论和建议。整个过程可能在毫秒到秒级完成无需调用大模型。深思系统完整的PEV循环当反射弧系统无法匹配问题复杂、症状新颖或者快速通道的验证结果指示需要更深层分析时例如df显示磁盘未满但应用仍报磁盘IO错误才会激活这个系统。此时才启用完整的、基于大模型的Plan-Execute-Verify循环进行深度推理和探索式诊断。关键在于两个系统之间的“握手”机制这是混合架构的精华Verify作为调度器反射弧的Verify模块不仅验证结果更负责判断“我是否搞定了”。如果搞定了流程结束如果没搞定或超出能力范围它会生成一个高质量的“上下文摘要”作为深思系统的输入。Plan作为补充器深思系统的Plan模块接收的不是原始告警而是已经过初步梳理、排除了简单可能性的“精炼问题”这使得它的规划效率和质量大大提高。这种混合模式完美解决了成本、速度和复杂度的三角难题。简单问题走反射弧廉价且飞速复杂问题走深思系统精准且深入。根据我们的线上统计超过70%的常见告警如资源类、进程状态类被反射弧系统在5秒内解决只有不到30%的疑难杂症需要动用“大模型”这个重型武器整体诊断成本下降了60%平均诊断时间从分钟级降至秒级。3. 混合PEV架构的核心组件深度解析3.1 反射弧系统基于“诊断片段”的规则引擎不要把反射弧系统想象成一个简单的if-else规则链那会很快陷入维护地狱。我们将其设计为一个可扩展、可学习、带权重的模式匹配引擎。核心构件“诊断片段”Diagnosis Fragment一个诊断片段是一个独立可执行的最小诊断单元结构如下fragment_id: disk_usage_high trigger_condition: - metric_name: disk.usage.percent operator: threshold: 90 - log_pattern: No space left on device verification_before: # 执行前验证可选 - check: host_connectivity expect: success actions: - execute: command command: df -h parser: parse_df_output # 解析函数提取挂载点、使用率 - execute: command command: du -sh /* 2/dev/null | sort -hr | head -5 parser: parse_du_output - execute: command command: lsof | grep -i deleted parser: parse_lsof_deleted verification_after: # 执行后验证 - check: output_contains target: action[0].parsed key: use_percent operator: value: 90 on_true: mark_as_confirmed # 确认问题 on_false: trigger_deep_plan # 触发深度规划 conclusion_template: 检测到磁盘空间使用率过高。主要占用路径{{.top_paths}}。发现未释放文件句柄{{.deleted_files}}。建议清理{{.top_paths}}或重启相关进程。触发条件Trigger Condition支持多条件组合指标、日志、事件标签这是匹配的入口。前后验证Verification Before/After这是混合架构的纽带。verification_before确保执行环境就绪verification_after分析结果并决定下一步走向是直接得出结论还是将问题升级。动作Actions一系列有序的执行操作可以是Shell命令、调用API、查询数据库等。结论模板将解析后的数据填充到模板生成人类可读的诊断报告。引擎的工作流事件流入引擎对所有片段的trigger_condition进行匹配评分。选取分数最高的片段或多个相关片段顺序执行其actions。执行每个动作后进行verification_after检查。如果某个验证触发on_false: trigger_deep_plan引擎会打包当前所有执行结果、上下文和失败原因生成一个“增强上下文”发送给深思系统。实操心得片段的维护技巧初期我们试图穷举所有规则后来发现这是不可能的。我们的策略是从历史工单中挖掘分析过去3个月的处理成功的工单将运维工程师的标准操作沉淀为片段。实现片段的“冷热”分离高频、稳定的片段用代码硬编码热片段低频、易变的片段用配置化描述甚至可以从知识库动态加载冷片段。为片段添加“置信度”和“功耗”标签高置信度、低功耗的片段优先匹配。这为后续的智能调度打下了基础。3.2 深思系统基于LLM的规划与推理引擎当反射弧系统“举手投降”时深思系统登场。它的核心是一个强化了工具使用Tool Use和批判性验证Critical Verification能力的LLM智能体。其工作流程是一个增强的PEV循环Plan (规划)输入反射弧系统提供的“增强上下文” 全局知识库历史案例、架构图、运维手册。过程LLM根据当前问题状态规划下一步的单个或少数几个最有可能的探索动作。我们放弃了生成冗长计划改为“小步快跑”的增量式规划。输出例如[{action: execute_shell, command: grep -r ConnectionTimeout /app/logs/ --max-count5}, {action: query_metrics, query: app_http_request_duration_seconds{handler\api_v1\}[5m]}]。Execute (执行)系统调用对应的工具命令执行器、指标查询接口、日志平台API来执行规划的动作。这里的关键是工具集的抽象。我们将所有可操作对象服务器、K8s集群、数据库、中间件都封装成统一的工具接口让LLM无需关心底层实现。Verify (验证)这是深思系统的“大脑皮层”。它不仅仅判断命令是否成功更重要的是对结果进行批判性分析。技术实现我们使用一个轻量级的“验证LLM”比规划LLM小成本低或者一套规则与模型结合的混合验证器。验证内容相关性执行结果是否与问题相关是否包含了关键错误信息充分性当前收集的信息是否足够做出判断是否需要更多维度数据矛盾性新结果是否与之前收集的证据矛盾是否暴露了之前假设的错误下一步决策基于分析决定是继续规划当前路径有望、回溯当前路径错误尝试其他分支还是得出结论。一个典型的复杂诊断案例 问题微服务A调用微服务B超时。反射弧快速检查网络连通性通、B服务进程存在、基础资源正常未解决触发深思。深思循环1P规划查询A服务调用B的链路追踪Trace。E从链路系统获取Trace数据。V验证发现Trace在B服务入口处中断。决策需要深入B服务内部。深思循环2P规划查询B服务当时的线程堆栈和GC日志。E执行命令获取线程Dump和GC日志。V验证发现大量线程阻塞在数据库连接池上。决策问题可能指向数据库或连接池配置。深思循环3P规划检查数据库当前连接数和慢查询。E查询数据库监控。V验证发现数据库连接数爆满且有死锁。得出结论根本原因是数据库死锁导致连接池耗尽。这个过程中Verify环节像是一个严格的评审不断评估每一步探索的价值防止LLM在错误的方向上越走越远这也是控制大模型使用成本的关键。3.3 上下文管理与记忆模块Agent的“工作记忆”无论是反射弧还是深思系统都需要一个强大的上下文管理器来保存诊断状态。这是Agent具备“连续性”和“逻辑性”的基础。我们设计的上下文结构分为三层会话层Session Context一次诊断会话的全局信息包括问题初始描述、会话ID、开始时间、最终状态进行中、已解决、失败等。证据层Evidence Context所有收集到的原始数据及其元数据。这是一个时序列表每条记录包括[时间戳 来源反射弧/深思 动作 原始结果 解析后的结构化数据 验证状态]。这是Agent进行推理的“事实依据”。假设层Hypothesis Context深思系统在推理过程中产生的各种假设和当前最有可能的根因推测。例如[假设1: 网络问题 置信度: 0.2 被证据X反驳] [假设2: 数据库死锁 置信度: 0.8 被证据Y支持]。记忆模块的关键作用避免循环记录已经执行过的检查防止Agent在同一个问题上重复打转。支持回溯当深思系统决定“回溯”时需要知道之前走过哪些分支哪些证据否定了哪些假设。生成最终报告诊断结束时证据层和假设层的数据可以直接用于生成结构清晰、证据链完整的诊断报告。踩坑实录上下文的爆炸与遗忘初期我们简单地将所有对话历史扔给LLM作为上下文很快触发了Token长度限制且无关信息干扰了推理。我们的解决方案是摘要压缩每经过几个PEV循环就用一个小模型对之前的证据和假设进行摘要保留核心结论丢弃冗余细节将摘要作为新的上下文起点。向量检索将历史证据和案例存入向量数据库。当遇到新问题时先进行相似案例检索将检索到的相关片段作为“先验知识”注入上下文而不是全部历史。这大大提升了上下文的针对性和效率。4. 关键实现细节与性能优化实战4.1 诊断片段的动态加载与热更新反射弧系统的片段不能是死代码。我们实现了一个片段注册中心支持动态加载。架构设计片段仓库使用Git仓库管理片段定义文件YAML格式。注册中心一个轻量级服务监听Git仓库变更。它负责解析YAML验证语法并将片段加载到内存中的规则引擎。规则引擎支持片段的增删改查并在匹配时实时生效。热更新流程运维工程师在Git中提交一个新的片段YAML例如针对新上线的Redis Cluster的故障片段。Git Webhook触发注册中心的更新接口。注册中心拉取最新代码解析并验证新片段。验证通过后通过消息总线或配置中心通知所有运行中的Agent实例。Agent实例动态更新其内存中的规则匹配树无需重启。性能优化片段索引不要顺序遍历所有片段。我们根据触发条件中的关键词如metric_name,log_pattern建立倒排索引。当事件到来时先通过索引快速筛选出一批候选片段再进行精细匹配。片段优先级队列为片段设置静态优先级和动态权重。高频触发且成功率高的片段权重高优先匹配。4.2 LLM的效能优化与成本控制深思系统的最大成本来自LLM API调用。我们采用了多层策略进行控制1. 规划阶段优化提示词工程精心设计System Prompt和Few-Shot示例将运维领域的专业知识和推理框架“固化”进提示词引导LLM输出结构化、精准的动作规划。例如明确要求输出JSON格式且必须包含actioncommandexpected_verification字段。思维链CoT压缩要求LLM在输出最终规划前先输出简短的思考过程。我们并不完全使用这个思考过程但它的存在能显著提高规划动作的质量和相关性。分层规划模型并非所有规划都需要最强大的模型如GPT-4。我们根据问题的复杂度和反射弧提供的上下文质量选择不同的模型简单探索使用小型/廉价模型如ChatGLM-6B API。复杂推理使用中型模型如GPT-3.5-Turbo。终极难题才动用重型模型如GPT-4。2. 验证阶段优化轻量级验证器大量验证逻辑可以用规则或小模型完成。例如“命令是否执行成功”可以用退出码判断“输出是否包含某错误码”可以用正则表达式。我们训练了一个基于BERT的小型分类模型专门用于判断文本片段是否属于“错误信息”或“关键线索”用于替代部分LLM验证调用。验证结果缓存对于相同的命令和输出其验证结论如“该输出表明数据库连接正常”是确定的。我们将命令 输出 - 验证结论的映射进行缓存有效期设为几分钟可以大幅减少重复的LLM调用。3. 执行流程优化并行执行当Plan阶段输出多个独立的探索动作时如同时查询CPU、内存、网络三个指标系统会并行执行它们缩短整体等待时间。超时与熔断为每一个LLM调用、工具调用设置严格的超时时间。如果深思系统在预定时间内如2分钟无法推进到下一步或连续多次验证失败会触发熔断终止当前循环并尝试回退到更保守的检查路径或直接请求人工介入。4.3 验证器的实现模式规则、模型与混合策略验证器是PEV循环中的“裁判”我们实现了三种模式根据场景选用1. 基于规则的验证器适用场景结果有明确、结构化标准的检查。如命令退出码是否为0JSON输出中某个字段是否在正常范围字符串是否匹配某个正则模式。实现我们开发了一个简单的DSL领域特定语言让运维人员可以方便地编写验证规则。verifier: type: rule rules: - field: exit_code operator: value: 0 on_fail: command_failed - field: parsed_output.cpu_usage operator: value: 80 on_success: high_cpu_detected on_fail: cpu_normal优点速度快零成本确定性高。2. 基于模型的验证器适用场景需要对非结构化文本进行语义理解、相关性判断、矛盾性分析的复杂验证。实现我们微调了一个百亿参数以下的中文模型专门用于运维领域的文本分类和自然语言推理NLI任务。输入是“当前假设”和“新证据文本”输出是支持、反驳或不相关。优点灵活能处理复杂语义。3. 混合验证器这是我们的主流方案。采用“规则优先模型兜底”的策略。工作流首先尝试所有预定义的规则进行验证。如果所有规则都无法给出明确结论或规则命中“不确定”分支则触发模型验证。模型验证的结果有时会被用来生成新的规则补充到规则库中实现“自我增强”。例如验证“kubectl get pods的输出是否表示服务异常”。规则可以先检查STATUS字段是否为RunningREADY字段是否为1/1。如果都是则通过。如果状态是CrashLoopBackOff则失败。但如果状态是Pending规则可能无法判断原因这时就调用模型分析下方的Events描述文本判断是“镜像拉取失败”还是“资源不足”并据此给出验证结论。5. 落地挑战、常见问题与效能评估5.1 实施过程中的四大挑战挑战一诊断片段的覆盖度与维护成本问题初期片段少覆盖率低大量问题仍要走昂贵的深思路径。后期片段增多维护、更新、避免冲突成为难题。解决方案闭环学习建立反馈机制。每当深思系统成功解决一个新问题就自动分析其动作序列尝试将其模式化、抽象成一个新的候选诊断片段经运维专家审核后入库。片段血缘与冲突检测建立片段之间的依赖和互斥关系。当新增片段与旧片段触发条件重叠时系统给出警告由人工决策合并或调整优先级。挑战二LLM输出的不稳定与安全风险问题LLM可能生成不合规、危险或无效的命令如rm -rf /。解决方案命令白名单与沙箱所有通过LLM规划生成的命令必须经过一个“安全过滤器”。过滤器基于白名单和正则表达式只允许执行预审核过的安全命令模式。同时首次执行未知命令模式时必须在隔离的沙箱环境中试运行。输出结构化约束强制要求LLM以指定JSON Schema输出解析失败则视为规划失败触发重试或降级。挑战三多环境适配与配置管理问题生产、预发、测试环境配置不同片段中的命令、参数可能需要变化。解决方案参数化片段片段定义支持变量。如command: ssh {{.host}} df -h。变量值在运行时从环境特定的配置中心注入。环境标签为每个片段打上环境标签如prod-only,all-env。Agent根据自身所在环境加载对应的片段集。挑战四与现有监控告警体系的融合问题Agent是独立的如何与Zabbix、Prometheus、ELK等现有系统联动解决方案统一适配层开发一个适配层将各类监控系统的告警格式、数据查询API封装成Agent内部统一的“事件源”和“工具”。Agent无需关心底层是PromQL还是ES查询。事件标准化定义统一的内部事件格式所有外部告警都转换为此格式后再流入Agent的决策引擎。5.2 典型问题排查实录问题1Agent陷入无限循环不断执行相同检查。现象诊断日志显示Agent反复查询同一个指标或执行同一个命令。根因记忆模块失效或Verify逻辑有缺陷无法识别出该检查已执行过或已无效。排查检查证据层上下文是否记录了重复的动作。检查Verify逻辑对于重复性结果如连续三次CPU使用率都是90%是否应该触发“状态未变化尝试其他路径”的规则。检查深思系统的Prompt是否缺少“避免重复已有操作”的指令。修复在Verify环节增加“结果去重”和“状态停滞检测”。如果连续N次循环获取的证据没有提供新信息则强制深思系统进行回溯或尝试截然不同的假设。问题2反射弧系统误匹配将复杂问题简单化处理。现象一个复杂的数据库死锁问题被反射弧匹配到“磁盘IO高”的片段执行了一通iostat命令后草草给出错误结论。根因片段触发条件过于宽泛或片段优先级设置不合理。排查分析该次诊断的原始事件看触发了哪些条件。检查“磁盘IO高”片段的触发条件是否包含了与数据库死锁相关的噪声指标如系统负载。修复收紧片段触发条件采用“与”逻辑组合更多特征提高特异性。引入条件权重。例如“disk_io_util 80”权重为1“database_connection_error日志出现”权重为5。只有当总权重超过阈值时才触发防止单一指标误判。在片段的verification_after中设置更严格的确认条件。如果快速检查不能确认问题必须触发深思。问题3LLM响应慢导致整体诊断超时。现象处理复杂问题时Agent经常超时如默认5分钟超时未能给出结果。根因LLM API网络延迟高或深思循环次数过多。排查查看链路追踪确定时间消耗在哪个环节是Plan慢还是Verify慢。统计不同复杂度问题的平均循环次数。修复为LLM调用设置渐进式超时第一次调用超时设为15秒失败后重试超时延长至30秒但总尝试次数限制为3次。实现规划缓存对经过标准化的问题描述如“服务A调用B超时网络通进程在”进行哈希缓存其首次成功的规划结果。短期内遇到相似问题可直接使用缓存的规划跳过LLM调用。在深思流程中设置最大循环次数如10次。达到上限后强制退出并汇总当前所有证据给出“最可能根因”的推断而不是无限循环。5.3 效能评估与业务价值经过半年多的演进和优化混合PEV架构的运维诊断Agent在我们生产环境的表现如下核心指标对比与传统脚本/纯Plan-Execute Agent对比指标传统脚本初代 Plan-Execute Agent混合PEV Agent (当前)平均诊断时间(MTTD)15-30分钟8-15分钟 2分钟常见问题解决率60% (覆盖范围内)75%95%疑难问题介入率100%需人工仍需大量人工分析 30%需人工深度介入误报/漏报率低 (但覆盖窄)较高 (LLM幻觉)低(反射弧稳定深思有验证)单次诊断平均成本低非常高 (LLM调用)中低(70%走廉价反射弧)可维护性差 (脚本散落)中 (逻辑集中在Prompt)高(片段化可动态更新)带来的业务价值运维效率革命性提升将运维工程师从大量重复、低级的“看监控-查日志-试命令”劳动中解放出来专注于架构优化和真正复杂的难题。故障恢复时间(MTTR)大幅降低平均诊断时间从分钟级降至秒级意味着故障定位更快业务恢复更及时。知识沉淀与传承诊断片段和成功案例不断沉淀到知识库新员工也能通过Agent快速处理以往需要专家经验的问题降低了团队对人的依赖。7x24小时无人值守能力Agent能够处理夜间和节假日的大部分常见告警实现初级故障的自治愈保障了业务的连续性。从僵化的Plan-Execute到引入验证的PEV再到最终的条件触发式混合PEV这条演进路径本质上是让AI智能体在运维领域从“纸上谈兵”走向“实战练兵”的过程。它告诉我们在追求通用人工智能的星辰大海之前在垂直领域里将经典的符号化规则引擎与现代的神经网络大模型有机结合往往能更快地产生实实在在的业务价值。这套架构不是一个终点而是一个起点。我们正在探索将更复杂的决策算法如强化学习用于片段调度和路径选择让Agent的“反射”和“深思”都变得更加智能。