Claude Code

应用日志监控擅长发现异常，却很少覆盖异常发生后的诊断与处置。关键词命中次数、错误率和响应时间一旦超过阈值，监控系统可以迅速发出告警；但错误是否来自同一根因、影响了哪些服务、是否需要立即控制影响，通常仍要由工程师接手判断。 墨天轮原有的日志监控也是如此。2026 年 7 月 10 日，外部监控只告诉我后端程序出现了 74 条 ERROR。我根据这条告警手工创建了 issue_49，初始信息只有报错数量和日志目录： 接到告警说后端程序 ERROR 报错 74 个， 请看看是什么报错。 issue_49 随后通过 Agent 连接两台应用节点，重新统计完整日志：一个节点有 113 条 ERROR，另一个节点有 80 条，合计 193 条。因此，Issue 标题中的 74 和分析结果中的 193 属于不同统计口径：74 是外部监控传来的初始告警值，193 是 Agent 扫描两台服务器后得到的完整 ERROR 总量。分析过程中又识别出 74 条短信验证码高频请求，但这是错误分类结果，不能代替完整日志总量。Opsx 继续完成错误分类和根因分析，但触发链路仍然存在断层：第三方平台发现异常，人把告警数量转述给 Opsx，再手工创建 Issue。只要人没有及时转述，后续分析和处理就不会开始。 单一的报错数量也不足以回答生产处置真正关心的问题： 74 条 ERROR 是 74 个不同问题，还是同一个问题重复了 74 次？ 错误来自哪个应用副本、哪个接口和哪个用户或 IP？ 是程序 Bug、数据库故障、外部依赖异常，还是攻击流量？ 服务是否已经恢复，是否需要立即介入？ 如果属于已知问题，能否直接复用历史结论和处置方法？ 因此，这次实践不只是增强告警后的分析，而是替换这条依赖第三方监控和人工转述的入口：由 Opsx 的 Shell Schedule 每 10 分钟直接扫描两台应用服务器的增量日志；ERROR 超过阈值后自动创建资产关联 Issue，对满足明确规则的已知问题先执行处置，再由 Agent 分析根因、验证结果，并把发现、动作和结论保存在同一个运维上下文中。 ...

Opsx 支持将代码仓库作为 Repo Asset 管理，并让 Agent 在指定仓库中读取和修改代码。整个过程不依赖开发者本地 IDE，代码差异、提交记录和恢复路径仍由 Git 管理。 MES Workspace 下的 issue_50 和 issue_77 分别验证了仓库查询与代码修改能力。 从 Repo Asset 定位代码 Repo Asset 保存仓库的稳定身份和执行上下文，包括： 仓库类型、技术栈和默认分支； Runtime 中的工作目录； 源码仓库与应用服务的关联关系； 能够访问该仓库的 Runtime。 创建 Issue 时只需绑定目标 Repo Asset。Opsx 根据资产与 Runtime 的映射，将任务交给具备仓库访问能力的 Agent，无需在 Prompt 中重复提供主机、路径和分支信息。 issue_50 绑定 Java 后端仓库 repo-enmo-support。Claude Runner 读取 Asset Metadata 后，在对应 Runtime 中执行 Git 查询，确认仓库包含四个远端分支：dev、master、report 和 word，默认分支为 dev。 Execution 先执行 git fetch --all --prune 更新远端引用，再通过 git branch -r 返回分支清单。 ...