agents 仓库 operating-kit 插件实战用 prod-logs-health-check Agent 做生产日志健康检查【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents生产事故排查中最常见的错误不是找不到日志而是在没看日志的情况下就下了结论。本篇技术指南围绕 agents 仓库中 operating-kit 插件提供的prod-logs-health-checkAgent 展开讲解它如何把生产日志健康检查固化为一条可重复执行的规则化流程先拉取真实日志、再按错误与告警特征过滤信号、最后区分唯一失败与重试噪音并以可审计的格式汇报。读完你既能直接上手定制并使用这个 Agent也能理解它背后的设计原则——日志才是事故分析的唯一第一手证据源。一、这个 Agent 是什么定位与触发时机prod-logs-health-check是 operating-kit 插件下的一名专项 Agent完整定义见 prod-logs-health-check.md。它的角色是生产日志健康检查员拉取真实日志报告实际正在发生什么而不是某个仪表盘声称发生了什么。从该文件开头的 frontmatter 可以直接读出它的运行契约字段值含义nameprod-logs-health-checkAgent 标识用于在插件内引用description拉取生产日志并按错误、告警与异常过滤触发条件任何部署之后、压测之后、或任何怀疑出问题的时候modelhaiku使用 Claude Haiku 模型执行toolsBash, Read只授予执行命令与读取文件两类能力不涉及编辑按 architecture.md 的模型分层策略Haiku 承担的是快速执行与确定性任务典型场景包括执行基础设施操作管理部署流水线。日志抓取与过滤正是这类确定性强、不依赖复杂架构推理的操作因此被分配为haiku是符合仓库整体模型配置策略的更多模型分层见 agents.md 的 Model Configuration 一节。该 Agent 的description明确给出了三个标准触发时机理解这点对编排工作流至关重要任何一次部署之后——配合 operating-kit 中的deploy-with-verification使用用于验证上线后是否引入了新错误一次压测之后——确认负载测试在真实日志上没有留下异常任何你怀疑出问题的时候——替代凭感觉猜先拿证据。二、核心规则日志是唯一可接受的第一手证据源这是整个 Agent 的灵魂也是它的第一原则永远不要仅凭 UI 数据或脚本 stdout 来分析生产事故。仪表盘是分页的你看到的是最近 N 条事件而不是全部测试工具对异步任务的计时也常常不准。这条规则背后是两个具体的工程事实原文给出了明确解释仪表盘分页Dashboards paginate你从监控面板上看到的是最近 N 条天然有截断无法代表完整事实而日志可以按时间窗口完整拉取。测试工具对异步任务计时不准Test harness timing is often wrong for async work脚本 stdout 里的成功退出码、耗时数据在异步场景下不可靠。因此 Agent 被要求严格执行两条纪律如果日志不可用或你根本没检查日志必须在给出任何结论前明确说出来。绝不把推断当作事实呈现Do not present inference as fact。这两条纪律与同插件其他 Agent 的证据优先哲学一脉相承deploy-with-verification要求Exited 0和live and serving the new code是两个不同的声明必须确认第二个见 deploy-with-verification.mdsession-start要求不要只信状态文档要核验真实状态见 session-start.md。prod-logs-health-check则是把同样的信任模型应用到了故障分析上。三、三步执行流程从原始日志到可汇报的结论Agent 把整个检查过程压缩为三个可重复的步骤任何环境下都能照搬。第 1 步拉取最近日志{{LOG_QUERY}}{{LOG_QUERY}}是模板占位符原文档明确要求把它指向项目真实的日志源包括但不限于云日志服务cloud loggingjournald系统日志日志文件kubectl logsKubernetes Pod 日志。按模板替换后常见的落地形态举例这些是填写占位符的示范具体以项目真实环境为准# Kubernetes拉取最近 30 分钟、全部命名空间的错误日志 kubectl logs --all-namespaces --since30m --tail10000 # journald拉取最近 1 小时的全部日志 journalctl --since 1 hour ago --no-pager # 日志文件拉取今天的应用日志 grep -h $(date %F) /var/log/myapp/app.log关键点在于这一步要尽量完整地拿到时间窗口内的日志而不是只看面板上的最后几屏——这正对应核心规则中对分页截断的警惕。第 2 步过滤信号拉回原始日志后用 grep 类过滤操作聚焦三类信号错误、异常、堆栈跟踪Errors, exceptions, stack traces超时与重试Timeouts, retries项目特定的失败标记{{PROJECT_SPECIFIC_MARKERS}}。其中{{PROJECT_SPECIFIC_MARKERS}}是第二个模板占位符需要你根据项目实际填上独有的失败特征——例如支付网关错误码、数据库连接字符串片段、业务特有的异常关键词等。这样过滤才不会淹没在泛化的ERROR关键词里。# 示范聚焦错误特征 项目特有标记 grep -E ERROR|Exception|Traceback|timeout|retry {{LOG_FILE}} grep -E {{PROJECT_SPECIFIC_MARKERS}}第 3 步区分唯一失败与重试这是 Agent 最有价值的一个步骤原文用一句话点破同一个 job id 出现 5 次是一个失败被重试了 5 次而不是 5 个失败。在报告计数之前先交叉核对 id。实操上这意味着过滤出的错误行不能直接按行数统计而要先提取其中的业务标识job id、request id、task id、trace id 等做去重。例如# 示范提取 job id 并统计唯一失败数 grep -oE job[_-]?id[: ][a-zA-Z0-9-] {{LOG_FILE}} | sort -u | wc -l去重后的唯一失败数与总出现次数两个数字要分开汇报——前者反映问题面后者反映影响范围与重试放大效应。四、汇报格式让结论可审计、可追溯原文档对该汇报什么给出了明确清单共四条时间窗口与拉取到的日志行数——让截断可见so truncation is visible。汇报时必须给出你分析的是哪段时间、基于多少行日志读者才能判断结论的覆盖度按根因分组的错误每组附一段代表性摘录——同类错误归并到根因并给出原文摘录作为证据而不是罗列几十条同质日志唯一失败数 vs 总出现次数——两个数字分开报告避免把重试放大成多次失败无法从日志确认的任何事项明确列为开放缺口stated as an open gap——延续核心规则没有证据支撑的推断必须显式标注不得混入结论。这四条合在一起本质上定义了一份证据驱动的事故报告的结构有范围时间行数、有归因按根因分组、有量级去重计数、有边界开放缺口。任何读者拿到这份报告都能立刻判断结论覆盖了哪些范围、漏掉了哪些未知。五、模板定制指南把 Agent 接到你的项目上该 Agent 设计为模板 占位符结构接入项目需要完成两处替换占位符用途示例取值{{LOG_QUERY}}指向项目真实日志源的拉取命令kubectl logs --since30m、journalctl --since 1 hour ago、日志文件路径{{PROJECT_SPECIFIC_MARKERS}}项目特有的失败特征关键词错误码、业务异常关键词、特定服务名的报错前缀由于 frontmatter 只授予了Bash, Read工具Agent 的执行边界被严格限制在拉日志 读文件 分析汇报不会越权修改任何生产状态——这是它与deploy-with-verification拥有Edit工具、会更新状态文档的明确分工。六、在 operating-kit 中的位置与部署、会话 Agent 的协同prod-logs-health-check不是孤立的它属于 operating-kit 插件运维工具箱中的一环。docs 中的 plugins.md 对 operating-kit 的定位概括为会话生命周期、上线前评审、带实时验证的部署 状态文档更新、生产日志健康检查/plugin install operating-kit可安装。将它与同插件其他 Agent 放在一起看能拼出完整的运维闭环上线前code-review-preshipment对自上次部署以来的全部变更做十项检查并给出 SHIP / SHIP WITH FIXES / DO NOT SHIP 结论见 code-review-preshipment.md上线中deploy-with-verification执行 test build deploy verify-live 更新状态文档强调确认线上正在服务新构建见 deploy-with-verification.md上线后prod-logs-health-check登场拉取真实日志确认没有引入错误、告警与异常——这正是其 description 中after any deploy的标准触发场景日常会话session-start读取状态文档并核验线上真实状态、对账漂移session-end收尾记录经验与未解决问题分别见 session-start.md 与 session-end.md。这套编排体现了 architecture.md 强调的单一职责 可组合插件设计原则每个 Agent 只做一件事通过编排组合成完整流程。prod-logs-health-check的职责边界非常清晰——只负责以日志为准的健康检查与报告不承担修复、不更新文档、不修改状态。七、实践建议与注意事项基于对 Agent 定义与仓库设计意图的分析落地使用时值得注意以下几点把先查日志固化为前置条件Agent 的核心规则要求任何结论前置日志证据。在实践中若日志源不可达应让 Agent 先明确声明未检查日志/日志不可用再讨论其余推断避免把猜测包装成事实。重视去重统计的准确性第 3 步的去重质量取决于日志中业务标识的规范程度。如果项目日志没有统一的 job/request id建议先在日志规范上补齐 trace id否则唯一失败数的统计会失真。控制拉取范围防止误判{{LOG_QUERY}}应显式限定时间窗口如--since、--tail、日期过滤并在报告中同步该窗口——既避免分析范围过大造成噪音也保证报告的时间边界可审计。与模型成本策略匹配Agent 被固定为haiku适合高频、确定性的快速检查如果排查中需要深入架构推理如跨服务根因链分析可以参考 agents.md 中的混合编排思路将该 Agent 作为拉证据的执行环节与更重推理的排查 Agent 配合使用。总结prod-logs-health-check以不到五十行的 Agent 定义浓缩了一套值得任何生产团队复用的故障分析纪律日志是第一证据源、仪表盘会分页、stdout 会骗人、重试不是多次失败、无法确认就明说。它既是 operating-kit 中部署闭环的收尾验证环节也是一份可以直接照抄进自己运维 Agent 的日志健康检查方法论。结合仓库中 prod-logs-health-check.md 的完整原文、同插件的配套 Agent 定义以及 docs/architecture.md 的模型与插件设计说明你可以快速把它定制到自己的项目上让每次排查都从看证据开始。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 agents 仓库 operating-kit 插件实战：用 prod-logs-health-check Agent 做生产日志健康检查
agents 仓库 operating-kit 插件实战用 prod-logs-health-check Agent 做生产日志健康检查【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents生产事故排查中最常见的错误不是找不到日志而是在没看日志的情况下就下了结论。本篇技术指南围绕 agents 仓库中 operating-kit 插件提供的prod-logs-health-checkAgent 展开讲解它如何把生产日志健康检查固化为一条可重复执行的规则化流程先拉取真实日志、再按错误与告警特征过滤信号、最后区分唯一失败与重试噪音并以可审计的格式汇报。读完你既能直接上手定制并使用这个 Agent也能理解它背后的设计原则——日志才是事故分析的唯一第一手证据源。一、这个 Agent 是什么定位与触发时机prod-logs-health-check是 operating-kit 插件下的一名专项 Agent完整定义见 prod-logs-health-check.md。它的角色是生产日志健康检查员拉取真实日志报告实际正在发生什么而不是某个仪表盘声称发生了什么。从该文件开头的 frontmatter 可以直接读出它的运行契约字段值含义nameprod-logs-health-checkAgent 标识用于在插件内引用description拉取生产日志并按错误、告警与异常过滤触发条件任何部署之后、压测之后、或任何怀疑出问题的时候modelhaiku使用 Claude Haiku 模型执行toolsBash, Read只授予执行命令与读取文件两类能力不涉及编辑按 architecture.md 的模型分层策略Haiku 承担的是快速执行与确定性任务典型场景包括执行基础设施操作管理部署流水线。日志抓取与过滤正是这类确定性强、不依赖复杂架构推理的操作因此被分配为haiku是符合仓库整体模型配置策略的更多模型分层见 agents.md 的 Model Configuration 一节。该 Agent 的description明确给出了三个标准触发时机理解这点对编排工作流至关重要任何一次部署之后——配合 operating-kit 中的deploy-with-verification使用用于验证上线后是否引入了新错误一次压测之后——确认负载测试在真实日志上没有留下异常任何你怀疑出问题的时候——替代凭感觉猜先拿证据。二、核心规则日志是唯一可接受的第一手证据源这是整个 Agent 的灵魂也是它的第一原则永远不要仅凭 UI 数据或脚本 stdout 来分析生产事故。仪表盘是分页的你看到的是最近 N 条事件而不是全部测试工具对异步任务的计时也常常不准。这条规则背后是两个具体的工程事实原文给出了明确解释仪表盘分页Dashboards paginate你从监控面板上看到的是最近 N 条天然有截断无法代表完整事实而日志可以按时间窗口完整拉取。测试工具对异步任务计时不准Test harness timing is often wrong for async work脚本 stdout 里的成功退出码、耗时数据在异步场景下不可靠。因此 Agent 被要求严格执行两条纪律如果日志不可用或你根本没检查日志必须在给出任何结论前明确说出来。绝不把推断当作事实呈现Do not present inference as fact。这两条纪律与同插件其他 Agent 的证据优先哲学一脉相承deploy-with-verification要求Exited 0和live and serving the new code是两个不同的声明必须确认第二个见 deploy-with-verification.mdsession-start要求不要只信状态文档要核验真实状态见 session-start.md。prod-logs-health-check则是把同样的信任模型应用到了故障分析上。三、三步执行流程从原始日志到可汇报的结论Agent 把整个检查过程压缩为三个可重复的步骤任何环境下都能照搬。第 1 步拉取最近日志{{LOG_QUERY}}{{LOG_QUERY}}是模板占位符原文档明确要求把它指向项目真实的日志源包括但不限于云日志服务cloud loggingjournald系统日志日志文件kubectl logsKubernetes Pod 日志。按模板替换后常见的落地形态举例这些是填写占位符的示范具体以项目真实环境为准# Kubernetes拉取最近 30 分钟、全部命名空间的错误日志 kubectl logs --all-namespaces --since30m --tail10000 # journald拉取最近 1 小时的全部日志 journalctl --since 1 hour ago --no-pager # 日志文件拉取今天的应用日志 grep -h $(date %F) /var/log/myapp/app.log关键点在于这一步要尽量完整地拿到时间窗口内的日志而不是只看面板上的最后几屏——这正对应核心规则中对分页截断的警惕。第 2 步过滤信号拉回原始日志后用 grep 类过滤操作聚焦三类信号错误、异常、堆栈跟踪Errors, exceptions, stack traces超时与重试Timeouts, retries项目特定的失败标记{{PROJECT_SPECIFIC_MARKERS}}。其中{{PROJECT_SPECIFIC_MARKERS}}是第二个模板占位符需要你根据项目实际填上独有的失败特征——例如支付网关错误码、数据库连接字符串片段、业务特有的异常关键词等。这样过滤才不会淹没在泛化的ERROR关键词里。# 示范聚焦错误特征 项目特有标记 grep -E ERROR|Exception|Traceback|timeout|retry {{LOG_FILE}} grep -E {{PROJECT_SPECIFIC_MARKERS}}第 3 步区分唯一失败与重试这是 Agent 最有价值的一个步骤原文用一句话点破同一个 job id 出现 5 次是一个失败被重试了 5 次而不是 5 个失败。在报告计数之前先交叉核对 id。实操上这意味着过滤出的错误行不能直接按行数统计而要先提取其中的业务标识job id、request id、task id、trace id 等做去重。例如# 示范提取 job id 并统计唯一失败数 grep -oE job[_-]?id[: ][a-zA-Z0-9-] {{LOG_FILE}} | sort -u | wc -l去重后的唯一失败数与总出现次数两个数字要分开汇报——前者反映问题面后者反映影响范围与重试放大效应。四、汇报格式让结论可审计、可追溯原文档对该汇报什么给出了明确清单共四条时间窗口与拉取到的日志行数——让截断可见so truncation is visible。汇报时必须给出你分析的是哪段时间、基于多少行日志读者才能判断结论的覆盖度按根因分组的错误每组附一段代表性摘录——同类错误归并到根因并给出原文摘录作为证据而不是罗列几十条同质日志唯一失败数 vs 总出现次数——两个数字分开报告避免把重试放大成多次失败无法从日志确认的任何事项明确列为开放缺口stated as an open gap——延续核心规则没有证据支撑的推断必须显式标注不得混入结论。这四条合在一起本质上定义了一份证据驱动的事故报告的结构有范围时间行数、有归因按根因分组、有量级去重计数、有边界开放缺口。任何读者拿到这份报告都能立刻判断结论覆盖了哪些范围、漏掉了哪些未知。五、模板定制指南把 Agent 接到你的项目上该 Agent 设计为模板 占位符结构接入项目需要完成两处替换占位符用途示例取值{{LOG_QUERY}}指向项目真实日志源的拉取命令kubectl logs --since30m、journalctl --since 1 hour ago、日志文件路径{{PROJECT_SPECIFIC_MARKERS}}项目特有的失败特征关键词错误码、业务异常关键词、特定服务名的报错前缀由于 frontmatter 只授予了Bash, Read工具Agent 的执行边界被严格限制在拉日志 读文件 分析汇报不会越权修改任何生产状态——这是它与deploy-with-verification拥有Edit工具、会更新状态文档的明确分工。六、在 operating-kit 中的位置与部署、会话 Agent 的协同prod-logs-health-check不是孤立的它属于 operating-kit 插件运维工具箱中的一环。docs 中的 plugins.md 对 operating-kit 的定位概括为会话生命周期、上线前评审、带实时验证的部署 状态文档更新、生产日志健康检查/plugin install operating-kit可安装。将它与同插件其他 Agent 放在一起看能拼出完整的运维闭环上线前code-review-preshipment对自上次部署以来的全部变更做十项检查并给出 SHIP / SHIP WITH FIXES / DO NOT SHIP 结论见 code-review-preshipment.md上线中deploy-with-verification执行 test build deploy verify-live 更新状态文档强调确认线上正在服务新构建见 deploy-with-verification.md上线后prod-logs-health-check登场拉取真实日志确认没有引入错误、告警与异常——这正是其 description 中after any deploy的标准触发场景日常会话session-start读取状态文档并核验线上真实状态、对账漂移session-end收尾记录经验与未解决问题分别见 session-start.md 与 session-end.md。这套编排体现了 architecture.md 强调的单一职责 可组合插件设计原则每个 Agent 只做一件事通过编排组合成完整流程。prod-logs-health-check的职责边界非常清晰——只负责以日志为准的健康检查与报告不承担修复、不更新文档、不修改状态。七、实践建议与注意事项基于对 Agent 定义与仓库设计意图的分析落地使用时值得注意以下几点把先查日志固化为前置条件Agent 的核心规则要求任何结论前置日志证据。在实践中若日志源不可达应让 Agent 先明确声明未检查日志/日志不可用再讨论其余推断避免把猜测包装成事实。重视去重统计的准确性第 3 步的去重质量取决于日志中业务标识的规范程度。如果项目日志没有统一的 job/request id建议先在日志规范上补齐 trace id否则唯一失败数的统计会失真。控制拉取范围防止误判{{LOG_QUERY}}应显式限定时间窗口如--since、--tail、日期过滤并在报告中同步该窗口——既避免分析范围过大造成噪音也保证报告的时间边界可审计。与模型成本策略匹配Agent 被固定为haiku适合高频、确定性的快速检查如果排查中需要深入架构推理如跨服务根因链分析可以参考 agents.md 中的混合编排思路将该 Agent 作为拉证据的执行环节与更重推理的排查 Agent 配合使用。总结prod-logs-health-check以不到五十行的 Agent 定义浓缩了一套值得任何生产团队复用的故障分析纪律日志是第一证据源、仪表盘会分页、stdout 会骗人、重试不是多次失败、无法确认就明说。它既是 operating-kit 中部署闭环的收尾验证环节也是一份可以直接照抄进自己运维 Agent 的日志健康检查方法论。结合仓库中 prod-logs-health-check.md 的完整原文、同插件的配套 Agent 定义以及 docs/architecture.md 的模型与插件设计说明你可以快速把它定制到自己的项目上让每次排查都从看证据开始。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考