1. 项目概述这不是一场概念宣讲而是一次真实交付现场的复盘“企业AI项目实战交付FDE实训工作坊CodexWorkBuddyHarnessRAGSkillsMCP”——这个标题里没有一个词是虚的。它不是某家培训机构包装出来的“AI速成班”也不是高校实验室里跑通demo就收工的学术项目而是某公司内部面向一线交付工程师组织的一场为期五天、全程带真实客户环境、带生产级数据、带SOP流程的封闭式实战拉练。我作为其中一名主带教导师全程参与从第一天环境初始化到最后一天客户验收签字所有环节都按真实项目节奏推进。核心关键词里的Codex不是指GitHub那个代码模型而是指一套内嵌于交付流水线中的上下文感知型代码生成引擎WorkBuddy不是聊天机器人而是部署在工程师本地IDE里的轻量级协同代理能自动抓取Jira任务、解析Confluence文档、同步Git分支状态Harness是整套CI/CD管道的可视化编排中枢但它的特别之处在于把AI能力直接注入到每个Stage的决策点RAG在这里不只用于问答而是作为服务治理层的数据编织器把散落在API网关、数据库日志、K8s事件流里的非结构化信号实时构建成可推理的知识图谱Skills是一套可注册、可组合、可灰度发布的原子能力单元比如“识别Spring Boot启动失败日志并推荐修复方案”就是一个Skill而MCPModel Control Plane则是整个AI能力调度的“交通指挥中心”它不训练模型只管模型版本、流量路由、A/B测试策略、异常熔断和成本核算。这个工作坊的目标非常明确让参训工程师在5天内独立完成一个客户侧AI增强型运维平台的最小可行交付MVP Delivery包括需求对齐、技能封装、RAG知识库构建、Harness流水线配置、MCP策略下发、WorkBuddy本地集成以及最终向客户演示“从告警产生到根因定位再到修复建议生成”的端到端闭环。它解决的不是“会不会用大模型”的问题而是“如何把大模型稳稳地焊进现有ITSM系统里且不被运维团队当累赘踢出生产环境”的现实难题。适合三类人深度参考一是正在推进AI落地的交付团队技术负责人需要看清能力拼图如何组装二是资深DevOps/SRE工程师想了解AI如何真正嵌入日常工具链三是AI工程化方向的技术布道师需要一手的、非PPT式的落地细节。下面我将完全基于这五天的真实操作记录一层层拆解每个模块为什么这么设计、怎么实操、踩过哪些坑、又如何绕开。2. 整体架构设计与技术选型逻辑为什么是这六块拼图而不是别的2.1 不是堆砌热点而是补全交付断点很多团队做AI项目一上来就猛攻RAG或微调模型结果交付时发现模型回答很准但没人知道它用了哪份文档、哪个API、哪条日志工程师想复用一段推理逻辑得重写整个服务客户说“这个功能挺好但能不能加个按钮让它只查我们自己的CMDB”——然后所有人卡住。FDE工作坊的六块拼图每一块都对应一个真实的交付断点Codex解决的是“业务语义到代码实现”的最后一公里断点。客户说“我要一个能自动分析Zabbix告警日志并关联CMDB拓扑的脚本”传统方式要花半天写Python正则requestsCodex则基于预置的领域DSL如log:zabbixaction:parsetarget:cmdb自动生成可审计、带注释、含错误处理的Go代码片段并直接推送到GitLab MR。它不替代工程师而是把工程师从“翻译官”变成“审核员”。WorkBuddy解决的是“AI能力与工程师工作流”的割裂断点。工程师不会为了问一个问题专门打开一个网页端AI助手。WorkBuddy以VS Code插件形式存在当工程师在编辑alert_rules.yml时右键选择“分析此规则影响面”它会自动拉取该规则关联的Prometheus指标、最近3小时告警历史、相关Pod的CPU Memory趋势图并用RAG检索过往类似规则变更引发的故障案例生成一份带截图和链接的PDF简报——所有动作都在IDE内完成不打断专注流。Harness解决的是“AI模型上线即失控”的运维断点。传统CI/CD只管代码是否编译通过、测试是否跑过。Harness在此基础上增加了AI Stage比如在模型镜像构建后自动触发一个“可信度探针”——用一组已知bad case的样本集运行模型若准确率低于阈值则自动阻断发布并生成根因报告如“模型在处理‘Connection refused’类日志时因RAG检索到过期的KB文章导致误判”。这相当于给AI流水线装上了刹车片。RAG在这里不是问答引擎而是服务治理的数据胶水。它不索引维基百科而是持续监听Kafka Topic里的三类消息API网关的慢请求日志含traceID、ELK中匹配ERROR.*timeout模式的应用日志、K8s Event中FailedScheduling事件。RAG引擎将这些异构信号按时间窗口默认5分钟聚合用LLM提取实体服务名、节点IP、错误码和关系A服务调用B服务超时B服务所在节点磁盘满动态构建轻量级知识图谱。当新告警进来系统不是去“搜索答案”而是“查询图谱中当前时刻的关联路径”从而给出比单纯关键词匹配更鲁棒的根因建议。Skills解决的是“AI能力无法沉淀、复用、计量”的组织断点。每个Skill是一个Docker容器暴露标准gRPC接口输入为{context: {service: auth-service, timestamp: 2024-06-15T10:23:45Z}, payload: {...}}输出为{result: high_risk, explanation: ..., actions: [...]}。它被注册到MCP后其他模块如WorkBuddy、Harness只需声明依赖skill://log-analyzer-v2无需关心其内部是用BERT还是Llama3也不用管它跑在K8s还是Lambda。客户后续想替换为自家模型只需重新打包一个符合接口的容器MCP自动完成灰度切换。MCPModel Control Plane是整个系统的“神经中枢”但它不做模型训练只做四件事①版本管理为每个Skill、每个RAG索引、每个Codex DSL模板分配语义化版本号②流量调度支持按请求头X-Customer-ID将5%流量路由到新版本Skill做A/B测试③异常熔断当某Skill连续3次响应超时5s自动降级到上一稳定版本并发邮件通知Owner④成本核算精确统计每个Skill每次调用消耗的GPU秒、Token数、RAG检索次数生成部门级AI使用账单。这六块拼图之所以必须同时出现是因为它们形成了一个闭环Codex生成的代码被WorkBuddy调用WorkBuddy的请求经Harness流水线进入MCP调度MCP调用Skills执行Skills内部触发RAG检索RAG的输出又反哺Codex的DSL模板优化。少任何一块这个闭环就会断裂AI就只能停留在演示阶段。2.2 为什么放弃LangChain/LlamaIndex等主流框架工作坊技术栈刻意避开了LangChain、LlamaIndex、Haystack等流行框架原因很实际LangChain的抽象层太厚它假设你从零开始构建应用但企业已有成熟的监控、配置、日志系统。强行套用LangChain的Chain、Agent概念反而要把Zabbix API封装成Tool把CMDB查询封装成Tool再写一堆PromptTemplate去协调它们——这增加了3倍以上的胶水代码且调试困难。而FDE采用“协议优先”所有外部系统Zabbix、CMDB、ELK都通过预定义的gRPC或HTTP协议接入Skills只认协议不认框架。LlamaIndex的RAG过于静态它擅长离线构建索引但企业环境里CMDB每天变更、日志格式每周迭代、告警规则每月更新。LlamaIndex的VectorStore重建一次要数小时无法满足“新规则上线后10分钟内生效”的要求。FDE的RAG引擎采用增量式流式索引Kafka Consumer实时消费日志流每条消息经过轻量NLP仅NER关键词提取后直接写入RedisGraph图谱节点带TTL默认72小时旧节点自动过期。查询时用Cypher语句MATCH (a:Log)-[r:TRIGGERED]-(b:Alert) WHERE a.timestamp $window_start RETURN b.service, count(*)毫秒级返回。框架绑定导致交付风险某次客户现场客户安全团队禁止所有Python进程访问外网因LangChain默认会调用HuggingFace Hub下载模型。我们不得不临时改用Ollama本地模型结果LangChain的HuggingFaceEmbeddings类因缺少trust_remote_codeTrue参数报错排查耗时2小时。FDE所有模块都遵循“零外部依赖”原则Codex的DSL解析器用Rust编写编译为WASMWorkBuddy插件用TypeScript所有模型调用走本地MCP代理RAG索引器用Go二进制直接部署。交付包就是一个tar.gz解压即用无pip install无docker pull。选型的核心逻辑就一条宁可多写100行代码也要少引入一个不可控的第三方依赖。因为交付现场没有“pip install -r requirements.txt”的时间只有“客户经理在会议室等你演示”的倒计时。2.3 环境与基础设施为什么必须用K8sArgoCDGrafana而不是纯云服务工作坊所有环境均基于客户真实IT基础设施搭建而非公有云托管服务。原因在于K8s是企业事实标准90%以上参训客户的生产环境已运行K8s。用EKS/AKS虽然省事但客户工程师看到“AWS Load Balancer”图标会本能质疑“这能在我们自建K8s上跑吗”而FDE所有YAML清单都经过OpenShift 4.12、Rancher 2.7、K3s 1.28实测确保kubectl apply -f即可部署。ArgoCD是交付确定性的保障客户最怕“上次能跑这次不行”。FDE所有组件Codex Backend、WorkBuddy Gateway、RAG Indexer、MCP Core的部署清单、ConfigMap、Secret都存放在Git仓库由ArgoCD监听。工程师修改一行RAG检索阈值Git提交后ArgoCD自动同步到集群Grafana面板立刻显示新旧版本对比曲线。整个过程可审计、可回滚、可复现彻底消灭“在我机器上是好的”这类交付黑话。Grafana不是看板而是诊断入口每个模块都暴露标准Prometheus指标如mcp_skill_invocation_total{skilllog-analyzer, statussuccess}并在Grafana预置Dashboard。当客户说“WorkBuddy响应慢”工程师不查日志而是打开Grafana切到“MCP Latency by Skill”面板发现log-analyzerP95延迟从200ms飙升至2s再下钻到“RAG Query Time by KB Source”定位到CMDB同步Job卡在某个废弃API上——诊断时间从2小时缩短至2分钟。这套基础设施选择本质是把交付过程本身变成了可观察、可度量、可验证的产品。它传递给客户一个明确信号我们交付的不是代码而是一套能融入你们现有运维体系的、有呼吸感的AI能力。3. 核心模块实操详解从零构建一个可交付的AI运维助手3.1 Codex让业务需求直接生成可审计的运维代码Codex不是ChatGPT for DevOps它的核心是领域特定语言DSL驱动的代码生成。工作坊第一天下午我们就让工程师面对一个真实需求“客户要求当Zabbix检测到mysql_slow_queries告警时自动执行以下操作① 查询该MySQL实例关联的K8s Pod名称② 获取该Pod最近1小时的CPU/Memory使用率③ 将结果以Markdown表格形式发送到企业微信。” 传统做法是写一个Python脚本但Codex要求用DSL描述# mysql-slow-alert-handler.dsl on alert: zabbix where metric mysql_slow_queries and value 5 do: - step: get_pod_name from: cmdb query: SELECT pod_name FROM services WHERE service_name {{alert.host}} - step: get_metrics from: prometheus query: sum(rate(container_cpu_usage_seconds_total{pod~{{step.get_pod_name.output}}}[1h])) by (pod) - step: format_report template: | ## MySQL慢查询告警分析 - **告警主机**: {{alert.host}} - **Pod名称**: {{step.get_pod_name.output}} - **CPU使用率**: {{step.get_metrics.output}} | 指标 | 值 | |------|----| | CPU | {{step.get_metrics.output}} |Codex引擎用Rust编写会解析此DSL生成带完整错误处理、日志埋点、超时控制的Go代码func HandleZabbixAlert(alert ZabbixAlert) error { if alert.Metric ! mysql_slow_queries || alert.Value 5 { return nil // not match } ctx, cancel : context.WithTimeout(context.Background(), 10*time.Second) defer cancel() // Step 1: Get pod name from CMDB podName, err : cmdbClient.Query(ctx, fmt.Sprintf(SELECT pod_name FROM services WHERE service_name %s, alert.Host)) if err ! nil { log.Error(CMDB query failed, err, err) return err } // Step 2: Get metrics from Prometheus metrics, err : promClient.Query(ctx, fmt.Sprintf(sum(rate(container_cpu_usage_seconds_total{pod~%s}[1h])) by (pod), podName)) if err ! nil { log.Error(Prometheus query failed, err, err) return err } // Step 3: Format report report : fmt.Sprintf(## MySQL慢查询告警分析\n- **告警主机**: %s\n- **Pod名称**: %s\n- **CPU使用率**: %s\n| 指标 | 值 |\n|------|----|\n| CPU | %s |, alert.Host, podName, metrics, metrics) // Send to WeCom return wecomClient.Send(report) }关键实操要点DSL语法必须严格校验{{alert.host}}中的host字段必须存在于预定义的ZabbixAlert结构体中否则编译时报错不生成代码。所有from:声明的外部系统cmdb、prometheus、wecom必须已在Codex配置中心注册包含连接参数、认证方式、健康检查Endpoint。生成的Go代码会自动注入OpenTelemetry Trace ID所有步骤调用都会出现在Jaeger中方便追踪。提示Codex不生成“完美代码”而是生成“可维护的起点”。工程师拿到代码后通常只需修改wecomClient.Send()为适配客户内部IM的SDK其余逻辑开箱即用。这大幅降低了AI生成代码的“信任成本”。3.2 WorkBuddy把AI能力无缝缝进工程师的IDEWorkBuddy是VS Code插件但它的灵魂不在前端而在后端的Context Broker。当工程师在IDE中打开一个文件如k8s/deploy.yamlWorkBuddy前端会收集以下上下文当前文件路径、语言类型、光标位置Git仓库URL、当前分支、最近一次commit hashJira插件获取的当前打开的Issue Key如OPS-1234Confluence插件获取的与该Issue关联的Design Doc URL这些信息被打包成ContextPayload通过WebSocket发送到本地运行的WorkBuddy Gateway一个轻量Go服务。Gateway不做任何AI推理只做两件事Context Enrichment根据ContextPayload调用MCP的/v1/context/enrich接口获取增强后的上下文。例如OPS-1234可能关联到一个RAG知识库IDkb-ops-mysql-2024Gateway会把这个ID加入请求头。Skill Dispatch根据当前场景如“右键点击YAML文件选择Analyze Deployment”构造Skill调用请求发往MCP。MCP收到请求后根据Header中的X-KB-ID: kb-ops-mysql-2024将请求路由到注册了该知识库的skill://deployment-analyzer-v1并注入X-Context-Trace-ID用于全链路追踪。实操部署关键WorkBuddy Gateway必须与VS Code在同一台机器运行localhost:8080这是为了绕过浏览器CORS限制也是为了保证上下文如本地Git状态的实时性。Gateway的配置文件config.yaml需指定MCP地址、Jira/Confluence的OAuth Token由工程师首次登录时授权获取Token存储在系统Keychain不落盘。插件UI采用Webview所有交互逻辑如点击“生成修复建议”按钮都通过postMessage与Gateway通信确保前端零AI计算纯展示。注意WorkBuddy绝不存储任何客户代码或日志。所有敏感数据如YAML内容、Jira Issue描述在Gateway收到后立即脱敏如将IP地址替换为ip将密码字段替换为redacted再转发给Skill。这是客户安全审计的硬性要求。3.3 Harness为AI流水线装上刹车片和仪表盘Harness流水线不是替代Jenkins而是作为其“AI增强层”。工作坊中我们改造了客户现有的Jenkins Pipeline将其Stage嵌入Harness的AI Stage# harness-pipeline.yaml stages: - name: Build Test type: Jenkins config: jenkinsUrl: https://jenkins.internal jobName: auth-service-build - name: AI Model Validation type: MCP config: skill: model-validator-v2 input: | { model_uri: s3://models/auth-service/bert-finetuned-v3.onnx, test_dataset: s3://datasets/auth-service/test-bad-cases.jsonl } success_criteria: - metric: accuracy threshold: 0.92 operator: gte - metric: latency_p95_ms threshold: 150 operator: lte - name: Deploy to Staging type: Jenkins config: jenkinsUrl: https://jenkins.internal jobName: auth-service-deploy-staging当流水线执行到AI Model ValidationStage时Harness Controller会从S3下载模型和测试集调用MCP的/v1/skill/invoke接口传入skillmodel-validator-v2和测试数据model-validator-v2Skill会加载ONNX模型在CPU上运行测试集计算accuracy和P95延迟Harness Controller解析Skill返回的JSON比对success_criteria若全部达标继续下一Stage若任一不达标标记Stage为FAILED并将Skill的完整日志含每条bad case的预测详情上传到Jenkins Artifacts供工程师下载分析。Harness的独特价值在于“可解释的失败”。传统AI测试失败日志只有一行Accuracy: 0.89 0.92。而Harness失败报告会附带哪12条测试样本预测错误每条样本的原始输入、模型输出、预期输出、置信度错误模式聚类如“所有错误样本都包含‘token expired’字样”建议的修复动作如“请检查训练数据中‘token expired’类样本的标注一致性”。这直接把AI模型的质量问题转化成了工程师熟悉的“测试用例失败”问题极大降低了沟通成本。3.4 RAG构建动态演化的运维知识图谱FDE的RAG引擎名为SignalGraph它不索引文档而是索引“信号流”。工作坊第二天我们用真实数据源构建了一个最小图谱信号源Kafka Topic提取规则图谱节点/关系Zabbix告警zabbix.alertsmetricmysql_connection_refused→LogNode{type:zabbix, host:db01, timestamp:1718452800}(LogNode)-[:TRIGGERED]-(AlertNode{severity:high})ELK日志app.logsmessage~Connection refused.*db01→LogNode{type:app, service:auth-service, timestamp:1718452805}(LogNode)-[:CAUSED_BY]-(LogNode)K8s Eventk8s.eventsreasonFailedScheduling→EventNode{type:k8s, node:node-05, timestamp:1718452810}(EventNode)-[:AFFECTS]-(LogNode)SignalGraph的Consumer用Go编写每秒处理5000消息关键设计无状态设计Consumer不保存任何状态所有图谱数据写入RedisGraph。即使Consumer崩溃重启Kafka Offset会自动回拨确保不丢消息。TTL自动清理每个节点设置ttl2592003天过期后RedisGraph自动删除避免图谱无限膨胀。Cypher即服务对外提供/v1/graph/queryHTTP接口接收Cypher语句返回JSON。例如curl -X POST http://signalgraph:8080/v1/graph/query \ -H Content-Type: application/json \ -d {query:MATCH (a:LogNode)-[r:TRIGGERED]-(b:AlertNode) WHERE a.timestamp $t RETURN b.severity, count(*), params:{t:1718452800}}实操中最大的认知颠覆RAG不再是一个“问答模块”而是整个AI系统的“实时数据总线”。WorkBuddy发起的每一次查询背后都是对SignalGraph的一次Cypher调用Codex生成的DSL中from: cmdb其底层实现也是SignalGraph的一个子图查询CMDB数据也通过Kafka同步到cmdb.updatesTopic。这彻底打破了“RAG只用于聊天”的思维定式。3.5 Skills可注册、可组合、可计量的AI原子能力每个Skill是一个独立的Docker容器遵循统一接口规范// skill.proto service SkillService { rpc Invoke(InvokeRequest) returns (InvokeResponse); } message InvokeRequest { string skill_id 1; // e.g., log-analyzer-v2 mapstring, string context 2; // e.g., {service: auth-service, timestamp: 2024-06-15T10:23:45Z} bytes payload 3; // raw bytes, format defined by skill } message InvokeResponse { bool success 1; string result 2; // JSON string, format defined by skill string explanation 3; repeated string actions 4; int64 cost_tokens 5; int64 cost_gpu_seconds 6; }工作坊中我们构建了三个核心Skilllog-analyzer-v2输入为Zabbix告警JSON输出为根因概率分布如{mysql_disk_full: 0.72, network_latency: 0.28}和修复建议。cmdb-enricher-v1输入为服务名输出为该服务关联的所有K8s资源、API网关路由、SLA协议。report-generator-v1输入为多个Skill的输出输出为格式化的Markdown报告。Skills的注册与发现工程师构建Skill Docker镜像推送至内部Harbor编写skill.yaml描述文件id: log-analyzer-v2 version: 2.1.0 image: harbor.internal/ai-skills/log-analyzer:v2.1.0 endpoints: - protocol: grpc port: 8080 dependencies: - kb-id: kb-ops-mysql-2024 - skill-id: cmdb-enricher-v1执行mcpctl register -f skill.yamlMCP将Skill元数据写入etcd并向所有Harness Controller、WorkBuddy Gateway推送更新。MCP的调度逻辑当WorkBuddy请求log-analyzer-v2时MCP检查其dependencies发现需要kb-ops-mysql-2024于是先调用SignalGraph的/v1/kb/load接口加载该知识库到内存同时MCP发现log-analyzer-v2依赖cmdb-enricher-v1会将cmdb-enricher-v1的调用结果作为log-analyzer-v2的输入的一部分所有调用都记录cost_tokens和cost_gpu_seconds汇总到/v1/metrics/cost接口供财务部门核算AI使用成本。实操心得Skills的版本管理必须严格。我们曾因log-analyzer-v2的v2.1.0镜像未更新而v2.0.0镜像被意外删除导致MCP找不到可用版本整个WorkBuddy瘫痪。此后强制规定mcpctl register必须带--force参数且注册前需docker pull验证镜像存在。3.6 MCP模型控制平面AI交付的“交通指挥中心”MCP是FDE的“大脑”但它的API设计极度克制。工作坊中工程师每天接触最多的三个APIPOST /v1/skill/invoke最常用所有模块调用Skill的入口。请求体必须包含X-MCP-Request-ID用于追踪和X-KB-ID用于RAG上下文。GET /v1/metrics/skill?skill_idlog-analyzer-v2start2024-06-15T00:00:00Zend2024-06-15T23:59:59Z查看某Skill的调用量、成功率、平均延迟、成本。返回JSON可直接喂给Grafana。PUT /v1/skill/routing灰度发布核心。请求体{ skill_id: log-analyzer, rules: [ { version: v2.1.0, weight: 5, conditions: [header.X-Customer-ID cust-a] }, { version: v2.0.0, weight: 95 } ] }这表示对客户cust-a的请求5%流量打到v2.1.095%打到v2.0.0其他客户100%打到v2.0.0。MCP的熔断机制实操 MCP内置一个CircuitBreaker模块监听/v1/metrics/skill的实时流。当检测到log-analyzer-v2的error_rate_5m 0.35分钟错误率超30%且p95_latency_ms 2000P95延迟超2秒时自动触发熔断将所有对该Skill的请求重定向到v2.0.0上一稳定版本发送告警到Slack #ai-ops-channel创建Jira IssueAssignee为Skill OwnerSummary为[MCP] log-analyzer-v2熔断已降级至v2.0.0记录熔断事件到/v1/events/circuit-breaker供审计。这使得AI能力的稳定性达到了与传统微服务同等的运维水准。客户工程师看到“MCP熔断”告警第一反应不是“AI又抽风了”而是“快去看log-analyzer-v2的监控是不是模型加载失败了”4. 全流程交付实操从需求接收到客户签字的五天4.1 第一天环境初始化与需求对齐不是写代码是画地图工作坊第一天上午不碰键盘只做三件事客户环境勘察工程师分组用预置的env-scan.sh脚本扫描客户K8s集群输出报告K8s版本、节点数、可用GPU资源已安装的监控栈Prometheus、Grafana、Zabbix版本CMDB API可达性测试curl -I https://cmdb.internal/api/v1/servicesKafka Topic列表及权限kafka-topics.sh --list --bootstrap-server ...需求卡片化将客户口头需求如“我们要能快速定位慢SQL”拆解为可验证的用户故事作为DBA当我收到mysql_slow_queries告警时我希望WorkBuddy能自动告诉我该SQL在哪个Pod执行、该Pod的磁盘使用率、以及过去一周同类告警的处理方案以便我5分钟内做出决策。能力映射表将用户故事映射到FDE六块拼图“收到告警” → Zabbix告警接入Harness配置“告诉我Pod” →cmdb-enricher-v1Skill调用MCP路由“磁盘使用率” → Prometheus查询Codex DSL or SignalGraph Cypher“过去一周处理方案” → SignalGraph图谱查询MATCH (a:LogNode)-[r:RESOLVED]-(b:Solution) WHERE a.timestamp $week_ago注意第一天结束前必须产出一份《环境就绪确认书》由客户方SRE签字。上面明确列出“已验证”的项如“Zabbix API可访问”、“Kafka topic zabbix.alerts 存在且可消费”和“待确认”的项如“CMDB API返回的service_name字段是否与Zabbix告警host字段完全一致”。这份文档是后续所有工作的基石避免“我以为你知道”的交付陷阱。4.2 第二天RAG知识库构建与Skills开发不是调API是织网第二天聚焦数据层。我们不从零训练模型而是用客户现有数据构建SignalGraph步骤1编写Kafka Consumer从zabbix.alertsTopic消费过滤出mysql_*相关告警写入SignalGraph的LogNode。步骤2编写Logstash Pipeline从ELK的app-*索引读取mysql相关日志提取connection refused、timeout等关键词写入LogNode并建立CAUSED_BY关系。步骤3编写K8s Controller监听Events当FailedScheduling事件发生且involvedObject.name匹配某个Pod建立AFFECTS关系。同时工程师开始开发log-analyzer-v2Skill输入Zabbix告警JSON含host,item,value输出调用SignalGraph查询该host最近1小时内的所有CAUSED_BY关系聚合错误类型disk_full,network_latency,cpu_overload返回概率分布和修复建议如“请检查/var/lib/mysql磁盘空间”。关键技巧SignalGraph的Cypher查询必须带LIMIT 100否则一个复杂查询可能拖垮Redis。我们约定所有Skill的查询都必须有LIMIT并在MCP的/v1/metrics/skill中监控query_count指标超过阈值自动告警。4.3 第三天Codex DSL编写与Harness流水线集成不是写脚本是定义契约第三天工程师将第二天的成果“产品化”为log-analyzer-v2编写Codex DSL模板命名为mysql-root-cause.dsl内容为on alert: zabbix where metric ~ mysql_.* and value 3 do: - step: analyze_root_cause from: mcp skill: log-analyzer-v2 input: {{alert}} - step: generate_report template: | ## MySQL告警分析 - **根因**: {{step.analyze_root_cause.result}} - **建议**: {{step.analyze_root_cause.explanation}}将此DSL注册到Codex配置中心。修改Harness流水线在Deploy to Staging后增加AI ValidationStage调用log-analyzer-v2对新部署的MySQL Exporter进行健康检查。此时整个链条已打通Zabbix告警 → Codex生成代码 → 代码调用MCP → MCP调度SignalGraph → SignalGraph返回根因 → Codex生成报告。4.4 第四天WorkBuddy