SRE On-Call Agent 实战用 Plan-and-Solve、ReAct 与 Reflection 三阶段流水线构建 AI 值班助手【免费下载链接】hello-agents 《从零开始构建智能体》——从零开始的智能体原理与实践教程项目地址: https://gitcode.com/GitHub_Trending/he/hello-agents本文以 Hello-Agents 社区共创项目 SRE On-Call Agent 为主体系统拆解一个面向真实运维场景的 AI 值班助手如何把「凌晨三点告警」转化为「有序调查计划 → 工具驱动的根因定位 → 结构化故障复盘报告」的完整自动化流程。读完本文你将掌握第四章三种经典智能体范式Plan-and-Solve、ReAct、Reflection在单一系统中的串联设计、三个可插拔运维工具的实现细节以及如何通过 FastAPI 把整套流水线暴露为 REST API 供前端集成。一、为什么需要一个 AI 驱动的 SRE 值班助手生产环境一旦发生告警值班工程师On-Call SRE必须在高压下完成一系列动作对告警进行分诊triage、跨日志与指标定位根因、查阅运维手册runbook获取处置步骤最后还要撰写复盘报告post-mortem。这是一个步骤固定、知识密集、且极易受疲劳与时间压力影响的流程——恰好是智能体Agent擅长处理的场景。SRE On-Call Agent 正是围绕这一痛点构建的项目它用三阶段智能体流水线把上述工作流自动化并以此为载体把《从零开始构建智能体》第四章中的三种经典范式放进同一套连贯系统里落地。按项目 README 的说法这是 Hello-Agents 社区首个 SRE/运维领域的共创项目。三阶段流水线的职责划分非常清晰阶段Agent对应范式核心职责Stage 1TriageAgentPlan-and-Solve把原始告警 JSON 转化为有序调查计划Stage 2InvestigationAgentReAct循环执行日志检索、指标查询、runbook 查询定位根因Stage 3PostmortemAgentReflection起草结构化 RCA 报告依据质量准则自我评审并修订流水线的编排入口在 pipeline.py 的run_pipeline()函数中先由TriageAgent产出计划再由InvestigationAgent带着计划和真实数据执行调查最后PostmortemAgent基于调查发现生成复盘报告最终返回包含incident_id、service、severity、plan、findings、report的完整结果字典。二、Stage 1TriageAgent——用 Plan-and-Solve 把告警变成调查计划值班工程师拿到告警后的第一反应不是立刻查日志而是先想清楚「先查什么、再查什么」。TriageAgent 就是这个「先思考再行动」的阶段对应 Plan-and-Solve 范式先让 LLM 生成完整方案再交由后续阶段逐步执行。2.1 提示词设计限定工具与输出格式TriageAgent 的提示词把一个资深 SRE 的身份、可用的三类工具以及输出格式约束同时注入上下文身份设定You are a senior Site Reliability Engineer (SRE) responding to a production incident.工具约束计划中的每一步必须且只能使用三种工具之一——log_search按关键字/正则搜日志、metric_query按名称查询时序指标、runbook_lookup按错误模式查处置步骤输出格式要求返回 46 步的 Python 列表每步为{tool: 工具名, query: 查询串, reason: 为什么做这一步}且必须包裹在python代码块中。提示词里还给出了示例计划引导模型产出结构一致的输出。这种「强约束输出格式」是后续阶段能可靠解析计划的关键设计。2.2 结构化解析与兜底计划模型输出并不总是完美因此run()方法在拿到响应后调用_parse_plan()做结构化解析见 triage_agent.pydef _parse_plan(self, response: str) - List[Dict[str, str]]: try: block response.split(python)[1].split()[0].strip() plan ast.literal_eval(block) if isinstance(plan, list) and all(isinstance(s, dict) for s in plan): return plan except (IndexError, ValueError, SyntaxError): pass return []解析失败时不会让流水线中断而是回退到_fallback_plan()triage_agent.py提供的通用四步兜底计划先搜ERROR、再搜CRITICAL、再查错误率指标、最后查 runbook。这一「结构化优先、兜底保底」的设计保证了流水线在模型输出不规范时依然可用。三、Stage 2InvestigationAgent——用 ReAct 循环驱动真实工具调查阶段是整个系统的核心对应 ReActReason Act范式模型在「思考」与「行动」之间交替行动的结果Observation再喂回上下文形成闭环。3.1 三个可插拔的运维工具InvestigationAgent 在初始化时根据事故数据装配三个工具统一暴露为name → tool字典log_search日志检索——实现在 log_search_tool.py。它对事故数据中的日志条目按关键字或正则做不区分大小写的匹配返回带时间戳与级别的命中的日志行。若用户传入非法正则会优雅回退为纯子串匹配。metric_query指标查询——实现在 metric_query_tool.py。按指标名子串做模糊匹配返回该指标在时间轴上的取值序列例如db_pool_active_connections: [14:00: 3 | 14:01: 8 | 14:02: 10 | 14:03: 10]。无匹配时会列出全部可用指标引导模型换一个查询词。runbook_lookup运维手册查询——实现在 runbook_tool.py。按服务名加载对应的 YAML runbook再按错误模式如DB pool exhausted匹配处置规程无精确匹配时返回该服务的全部规程。三个工具都不依赖任何外部服务——数据来自本地 JSON fixture 与 YAML runbook因此项目开箱即可运行这也是「无外部依赖」技术选型的落地体现。3.2 ReAct 主循环Thought → Action → Observationrun()方法investigation_agent.py执行一个最多max_steps12步的循环每轮把「事故上下文 调查计划 工具清单 已有历史」拼装进提示词要求模型严格按以下格式输出Thought: 推理 Action: tool_name[query]循环内部有几个值得借鉴的健壮性设计去重保护同一tool_name[query]只允许调用一次重复调用会被跳过并提示模型「请用Finish[结论]陈述根因」防止模型陷入死循环行动解析_parse_react_output()用正则分别提取Thought与Actioninvestigation_agent.py_parse_tool_call()用(\w)\[(.*)\]解析工具名与查询串L182-L186结束信号当Action以finish开头时提取Finish[...]括号内的结论作为根因写入findings[root_cause]并终止循环证据累积_execute_tool()会把日志与指标的查询结果追加到findings[evidence]把 runbook 步骤追加到findings[runbook_steps]为第三阶段的复盘报告准备素材。以 README 中的示例输出为例一次典型的调查过程是先log_search[pool exhausted]找到 3 条连接池报错日志再metric_query[db_pool]确认连接池从 14:01 起 10/10 打满再runbook_lookup[DB pool exhausted]取回处置步骤最终得出根因——orders.user_id缺少索引导致全表扫描。四、Stage 3PostmortemAgent——用 Reflection 生成可用的故障复盘调查出根因只是完成了「救火」写出一份高质量的复盘报告才是闭环。PostmortemAgent 对应 Reflection 范式执行 draft → critique → revise 的自我迭代循环postmortem_agent.py。4.1 起草强制七段式结构DRAFT_PROMPT 要求报告必须包含以下七个章节## Executive Summary摘要发生了什么、影响、如何解决## Incident Timeline带时间戳的事件时间线## Root Cause Analysis5-Whys从症状出发连续追问五次为什么## Impact Assessment严重级别、受影响用户、持续时间、业务影响## Immediate Remediation Steps当下立即执行的处置步骤## Action Items表格Action | Owner | Due Date | Priority## Lessons Learned24 条经验教训起草时会把事故 JSON、根因结论、已收集证据和 runbook 步骤全部注入提示词并要求「引用日志中真实的消息、指标值和时间戳」确保报告不是空话套话。4.2 评审五个质量准则打分CRITIQUE_PROMPT 让模型扮演「复盘评审委员会成员」按五个准则给草稿打分110 分根因是否明确具体、时间线是否完整准确、行动项是否可量化且有人认领、5-Whys 是否抵达系统性根因而非停留在症状、经验教训是否可执行。评审结果要求输出 JSON{score: 1-10, issues: [...], suggestions: [...]}。4.3 修订低于阈值自动重写run()循环中评分通过_extract_score()从评审 JSON 里用正则提取L152-L156阈值设为 8 分分数 ≥ 8 直接定稿否则把草稿与评审反馈一并交给 REVISE_PROMPT让模型「应用所有建议、修复所有问题」后输出完整修订版。max_revisions参数默认 1 次防止无限自我迭代消耗 token。README 示例中一次评审得到 9/10无需修订即定稿。五、数据设计生产级事故 fixture 与 runbook项目之所以「开箱即用」关键在于把真实运维事故的形态沉淀成了本地数据。5.1 事故数据JSONdata/incidents 下内置三个事故 fixture数据库连接池耗尽db_pool_exhaustion.json、内存泄漏 OOMmemory_leak_oom.json、外部 API 限流级联external_api_ratelimit.json。以db_pool_exhaustion.json为例其结构覆盖了告警、日志与指标三部分alert触发告警的指标、阈值与描述如 P99 延迟 8.3s 远超 1.0s 的 SLO 阈值logs16 条带时间戳与级别INFO/WARN/ERROR/CRITICAL/ALERT的日志完整还原了从发布、连接池吃紧到最终 P1 告警的演变过程metricshttp_request_duration_p99、db_pool_active_connections、db_query_duration_p99_ms、request_queue_depth四组时间序列精确到分钟root_cause标准答案字段用于评估 Agent 是否定位正确如「orders.user_id 缺索引导致全表扫描高负载下每次扫描占用连接池 30s耗尽 10 个连接」affected_users受影响用户数供复盘报告评估影响面。5.2 运维手册YAMLdata/runbooks 下的checkout-service.yaml、payment-service.yaml按服务组织处置规程每条规程包含pattern匹配模式、severity与steps有序处置步骤。例如「DB pool exhausted」P1 规程就包含SHOW PROCESSLIST找慢查询 →EXPLAIN定位全表扫描 → 热更新把连接池从 10 扩到 20 临时缓解 →CREATE INDEX idx_orders_user_id永久修复 → 验证索引生效 → 滚动重启 Pod → 监控指标确认恢复完整覆盖了 SRE 处置的真实动作链。六、LLM 客户端与配置HelloAgentsLLM 是贯穿三个 Agent 的统一大模型客户端基于 OpenAI 兼容接口实现因此可以无缝对接 AIHubmix、ModelScope/Qwen、OpenAI 等任意 OpenAI 兼容 API。环境变量通过python-dotenv从项目根目录的.env文件加载需要配置的变量源码 llm_client.py 确认环境变量含义备注LLM_MODEL_ID模型标识必填缺少会抛ValueErrorLLM_API_KEYAPI 密钥必填LLM_BASE_URLAPI 基础地址必填LLM_TIMEOUT请求超时秒数可选默认60README 中的启动步骤是cp .env.example .env后编辑配置若当前仓库快照中未包含.env.example文件可直接在项目根目录新建.env按上表写入四个变量即可效果相同。think()方法L34-L52使用temperature0最大化确定性适合工具调用场景并开启流式streamTrue逐 chunk 收集输出verboseTrue时会在控制台实时打印模型推理内容这也是运行 demo 时能看到思考过程的原因。README 提到免费 LLM 选项AIHubmixhttps://aihubmix.com/v1免费额度、OpenAI 兼容与 ModelScope/Qwenhttps://api-inference.modelscope.cn/v1每日 2000 次免费调用均为 README 中给出的配置前提。七、FastAPI 后端把流水线暴露为 REST API除 Jupyter Notebook 外项目还提供了可直接启动的 API 服务src/api/main.py启动命令uvicorn src.api.main:app --reload --port 8000API 层在启动时添加了 CORS 中间件allow_origins[*]源码注释提示接入特定前端时应收紧为后续前端集成铺路。四个端点与职责MethodEndpoint说明GET/health存活探针返回{status: ok}GET/incidents/fixtures列出内置事故 ID来自list_incidents()POST/incidents/investigate同步运行完整三阶段流水线入参{incident_id: ...}GET/incidents/{id}/report取回已生成的事故复盘报告几个实现细节值得注意POST /incidents/investigate会先用load_incident()做早期校验事故不存在时返回 404流水线异常时返回 500运行耗时以elapsed_seconds字段返回报告暂存于内存字典_report_store源码注释明确提示生产环境应替换为 Redis/DB。当前实现为同步调用注释中给出了升级方向——后台任务 SSE 流式推送。八、快速开始与三种使用方式8.1 环境准备Python 3.10安装依赖pip install -r requirements.txt依赖清单见 requirements.txt含openai、fastapi、uvicorn、pyyaml、pydantic、python-dotenv配置.env中的LLM_API_KEY/LLM_BASE_URL/LLM_MODEL_ID8.2 方式一Jupyter Notebookjupyter lab # 打开 main.ipynb依次运行所有 cellNotebookmain.ipynb适合逐步观察三个阶段的运行过程与中间输出。8.3 方式二Python 脚本调用流水线from src.agents.pipeline import run_pipeline result run_pipeline(db_pool_exhaustion) print(result[report]) # Markdown 格式的 RCA 复盘报告 print(result[findings]) # 根因结论 证据字典8.4 方式三curl 调用 REST API# 列出可用事故 curl http://localhost:8000/incidents/fixtures # 运行完整流水线 curl -X POST http://localhost:8000/incidents/investigate \ -H Content-Type: application/json \ -d {incident_id: db_pool_exhaustion} # 获取生成的复盘报告 curl http://localhost:8000/incidents/db_pool_exhaustion/report8.5 一次完整的运行输出示例 STAGE 1: TRIAGE — Generating investigation plan 1. [log_search] pool exhausted — Find DB pool error log entries 2. [metric_query] db_pool — Check connection pool saturation over time 3. [metric_query] latency — Quantify request latency degradation 4. [runbook_lookup] DB pool exhausted — Get remediation steps STAGE 2: INVESTIGATION — ReAct tool loop Step 1 — log_search[pool exhausted] → 3 matching entries found Step 2 — metric_query[db_pool] → pool maxed at 10/10 from 14:01 onward Step 3 — runbook_lookup[DB pool exhausted] → runbook steps retrieved ✅ Root cause: Missing index on orders.user_id causing full table scan... STAGE 3: POST-MORTEM — Reflection (draft → critique → revise) Quality score: 9/10 — no revision needed. ✅ Final post-mortem ready.九、评估结果与扩展路线9.1 性能评估README 记录的实验结果项目在三个内置事故 fixture 上做了评估README 注明使用 Llama-3.3-70b via Groq兼容任意 OpenAI 兼容 API事故识别出的根因流水线耗时DB pool exhaustion✅orders.user_id缺少索引~30sMemory leak OOM✅ 无 TTL/淘汰策略的 Session 缓存~25sExternal API rate limit✅ 无指数退避导致的重试风暴~28sREADME 报告在样例 fixture 上的根因识别准确率为3/3 (100%)。需要说明的是这一结果是项目在自带三个固定 fixture 上的自测数据并非对任意生产事故的泛化能力声明。9.2 未来规划README 列出的升级路径SSE 流式输出把 Agent 推理步骤实时推送到前端Vue/React 前端事故选择器 实时轨迹 Markdown 查看器真实日志接入对接 Loki / CloudWatch / Datadog向量记忆对历史 RCA 报告做向量化加速后续调查安全的 runbook 执行让 Agent 执行低风险处置命令。这些方向都与现有代码结构兼容——Agent 层与 API 层解耦接入前端或数据源无需改动三阶段 Agent 本身。十、小结三种范式的串联要点回看整个项目SRE On-Call Agent 的价值不仅是「一个运维 Demo」更是三种范式如何协作的范本Plan-and-Solve 负责全局规划把不确定的开放问题拆解成确定步骤ReAct 负责与环境互动用真实工具输出取代模型猜测Reflection 负责质量闭环让产出经过自我评审与迭代。三者各司其职正好对应告警处理中「想清楚 → 查清楚 → 写清楚」三个阶段。如果你正在学习《从零开始构建智能体》第四章或正在为自己的领域设计多阶段 Agent 流水线这个项目的源码pipeline.py、三个 Agent 实现、三个工具实现都是可直接对照研读的完整样例。项目遵循 MIT 协议更多贡献与协作规范可参阅仓库根目录的 README.md 与 LICENSE.txt。【免费下载链接】hello-agents 《从零开始构建智能体》——从零开始的智能体原理与实践教程项目地址: https://gitcode.com/GitHub_Trending/he/hello-agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 SRE On-Call Agent 实战：用 Plan-and-Solve、ReAct 与 Reflection 三阶段流水线构建 AI 值班助手
SRE On-Call Agent 实战用 Plan-and-Solve、ReAct 与 Reflection 三阶段流水线构建 AI 值班助手【免费下载链接】hello-agents 《从零开始构建智能体》——从零开始的智能体原理与实践教程项目地址: https://gitcode.com/GitHub_Trending/he/hello-agents本文以 Hello-Agents 社区共创项目 SRE On-Call Agent 为主体系统拆解一个面向真实运维场景的 AI 值班助手如何把「凌晨三点告警」转化为「有序调查计划 → 工具驱动的根因定位 → 结构化故障复盘报告」的完整自动化流程。读完本文你将掌握第四章三种经典智能体范式Plan-and-Solve、ReAct、Reflection在单一系统中的串联设计、三个可插拔运维工具的实现细节以及如何通过 FastAPI 把整套流水线暴露为 REST API 供前端集成。一、为什么需要一个 AI 驱动的 SRE 值班助手生产环境一旦发生告警值班工程师On-Call SRE必须在高压下完成一系列动作对告警进行分诊triage、跨日志与指标定位根因、查阅运维手册runbook获取处置步骤最后还要撰写复盘报告post-mortem。这是一个步骤固定、知识密集、且极易受疲劳与时间压力影响的流程——恰好是智能体Agent擅长处理的场景。SRE On-Call Agent 正是围绕这一痛点构建的项目它用三阶段智能体流水线把上述工作流自动化并以此为载体把《从零开始构建智能体》第四章中的三种经典范式放进同一套连贯系统里落地。按项目 README 的说法这是 Hello-Agents 社区首个 SRE/运维领域的共创项目。三阶段流水线的职责划分非常清晰阶段Agent对应范式核心职责Stage 1TriageAgentPlan-and-Solve把原始告警 JSON 转化为有序调查计划Stage 2InvestigationAgentReAct循环执行日志检索、指标查询、runbook 查询定位根因Stage 3PostmortemAgentReflection起草结构化 RCA 报告依据质量准则自我评审并修订流水线的编排入口在 pipeline.py 的run_pipeline()函数中先由TriageAgent产出计划再由InvestigationAgent带着计划和真实数据执行调查最后PostmortemAgent基于调查发现生成复盘报告最终返回包含incident_id、service、severity、plan、findings、report的完整结果字典。二、Stage 1TriageAgent——用 Plan-and-Solve 把告警变成调查计划值班工程师拿到告警后的第一反应不是立刻查日志而是先想清楚「先查什么、再查什么」。TriageAgent 就是这个「先思考再行动」的阶段对应 Plan-and-Solve 范式先让 LLM 生成完整方案再交由后续阶段逐步执行。2.1 提示词设计限定工具与输出格式TriageAgent 的提示词把一个资深 SRE 的身份、可用的三类工具以及输出格式约束同时注入上下文身份设定You are a senior Site Reliability Engineer (SRE) responding to a production incident.工具约束计划中的每一步必须且只能使用三种工具之一——log_search按关键字/正则搜日志、metric_query按名称查询时序指标、runbook_lookup按错误模式查处置步骤输出格式要求返回 46 步的 Python 列表每步为{tool: 工具名, query: 查询串, reason: 为什么做这一步}且必须包裹在python代码块中。提示词里还给出了示例计划引导模型产出结构一致的输出。这种「强约束输出格式」是后续阶段能可靠解析计划的关键设计。2.2 结构化解析与兜底计划模型输出并不总是完美因此run()方法在拿到响应后调用_parse_plan()做结构化解析见 triage_agent.pydef _parse_plan(self, response: str) - List[Dict[str, str]]: try: block response.split(python)[1].split()[0].strip() plan ast.literal_eval(block) if isinstance(plan, list) and all(isinstance(s, dict) for s in plan): return plan except (IndexError, ValueError, SyntaxError): pass return []解析失败时不会让流水线中断而是回退到_fallback_plan()triage_agent.py提供的通用四步兜底计划先搜ERROR、再搜CRITICAL、再查错误率指标、最后查 runbook。这一「结构化优先、兜底保底」的设计保证了流水线在模型输出不规范时依然可用。三、Stage 2InvestigationAgent——用 ReAct 循环驱动真实工具调查阶段是整个系统的核心对应 ReActReason Act范式模型在「思考」与「行动」之间交替行动的结果Observation再喂回上下文形成闭环。3.1 三个可插拔的运维工具InvestigationAgent 在初始化时根据事故数据装配三个工具统一暴露为name → tool字典log_search日志检索——实现在 log_search_tool.py。它对事故数据中的日志条目按关键字或正则做不区分大小写的匹配返回带时间戳与级别的命中的日志行。若用户传入非法正则会优雅回退为纯子串匹配。metric_query指标查询——实现在 metric_query_tool.py。按指标名子串做模糊匹配返回该指标在时间轴上的取值序列例如db_pool_active_connections: [14:00: 3 | 14:01: 8 | 14:02: 10 | 14:03: 10]。无匹配时会列出全部可用指标引导模型换一个查询词。runbook_lookup运维手册查询——实现在 runbook_tool.py。按服务名加载对应的 YAML runbook再按错误模式如DB pool exhausted匹配处置规程无精确匹配时返回该服务的全部规程。三个工具都不依赖任何外部服务——数据来自本地 JSON fixture 与 YAML runbook因此项目开箱即可运行这也是「无外部依赖」技术选型的落地体现。3.2 ReAct 主循环Thought → Action → Observationrun()方法investigation_agent.py执行一个最多max_steps12步的循环每轮把「事故上下文 调查计划 工具清单 已有历史」拼装进提示词要求模型严格按以下格式输出Thought: 推理 Action: tool_name[query]循环内部有几个值得借鉴的健壮性设计去重保护同一tool_name[query]只允许调用一次重复调用会被跳过并提示模型「请用Finish[结论]陈述根因」防止模型陷入死循环行动解析_parse_react_output()用正则分别提取Thought与Actioninvestigation_agent.py_parse_tool_call()用(\w)\[(.*)\]解析工具名与查询串L182-L186结束信号当Action以finish开头时提取Finish[...]括号内的结论作为根因写入findings[root_cause]并终止循环证据累积_execute_tool()会把日志与指标的查询结果追加到findings[evidence]把 runbook 步骤追加到findings[runbook_steps]为第三阶段的复盘报告准备素材。以 README 中的示例输出为例一次典型的调查过程是先log_search[pool exhausted]找到 3 条连接池报错日志再metric_query[db_pool]确认连接池从 14:01 起 10/10 打满再runbook_lookup[DB pool exhausted]取回处置步骤最终得出根因——orders.user_id缺少索引导致全表扫描。四、Stage 3PostmortemAgent——用 Reflection 生成可用的故障复盘调查出根因只是完成了「救火」写出一份高质量的复盘报告才是闭环。PostmortemAgent 对应 Reflection 范式执行 draft → critique → revise 的自我迭代循环postmortem_agent.py。4.1 起草强制七段式结构DRAFT_PROMPT 要求报告必须包含以下七个章节## Executive Summary摘要发生了什么、影响、如何解决## Incident Timeline带时间戳的事件时间线## Root Cause Analysis5-Whys从症状出发连续追问五次为什么## Impact Assessment严重级别、受影响用户、持续时间、业务影响## Immediate Remediation Steps当下立即执行的处置步骤## Action Items表格Action | Owner | Due Date | Priority## Lessons Learned24 条经验教训起草时会把事故 JSON、根因结论、已收集证据和 runbook 步骤全部注入提示词并要求「引用日志中真实的消息、指标值和时间戳」确保报告不是空话套话。4.2 评审五个质量准则打分CRITIQUE_PROMPT 让模型扮演「复盘评审委员会成员」按五个准则给草稿打分110 分根因是否明确具体、时间线是否完整准确、行动项是否可量化且有人认领、5-Whys 是否抵达系统性根因而非停留在症状、经验教训是否可执行。评审结果要求输出 JSON{score: 1-10, issues: [...], suggestions: [...]}。4.3 修订低于阈值自动重写run()循环中评分通过_extract_score()从评审 JSON 里用正则提取L152-L156阈值设为 8 分分数 ≥ 8 直接定稿否则把草稿与评审反馈一并交给 REVISE_PROMPT让模型「应用所有建议、修复所有问题」后输出完整修订版。max_revisions参数默认 1 次防止无限自我迭代消耗 token。README 示例中一次评审得到 9/10无需修订即定稿。五、数据设计生产级事故 fixture 与 runbook项目之所以「开箱即用」关键在于把真实运维事故的形态沉淀成了本地数据。5.1 事故数据JSONdata/incidents 下内置三个事故 fixture数据库连接池耗尽db_pool_exhaustion.json、内存泄漏 OOMmemory_leak_oom.json、外部 API 限流级联external_api_ratelimit.json。以db_pool_exhaustion.json为例其结构覆盖了告警、日志与指标三部分alert触发告警的指标、阈值与描述如 P99 延迟 8.3s 远超 1.0s 的 SLO 阈值logs16 条带时间戳与级别INFO/WARN/ERROR/CRITICAL/ALERT的日志完整还原了从发布、连接池吃紧到最终 P1 告警的演变过程metricshttp_request_duration_p99、db_pool_active_connections、db_query_duration_p99_ms、request_queue_depth四组时间序列精确到分钟root_cause标准答案字段用于评估 Agent 是否定位正确如「orders.user_id 缺索引导致全表扫描高负载下每次扫描占用连接池 30s耗尽 10 个连接」affected_users受影响用户数供复盘报告评估影响面。5.2 运维手册YAMLdata/runbooks 下的checkout-service.yaml、payment-service.yaml按服务组织处置规程每条规程包含pattern匹配模式、severity与steps有序处置步骤。例如「DB pool exhausted」P1 规程就包含SHOW PROCESSLIST找慢查询 →EXPLAIN定位全表扫描 → 热更新把连接池从 10 扩到 20 临时缓解 →CREATE INDEX idx_orders_user_id永久修复 → 验证索引生效 → 滚动重启 Pod → 监控指标确认恢复完整覆盖了 SRE 处置的真实动作链。六、LLM 客户端与配置HelloAgentsLLM 是贯穿三个 Agent 的统一大模型客户端基于 OpenAI 兼容接口实现因此可以无缝对接 AIHubmix、ModelScope/Qwen、OpenAI 等任意 OpenAI 兼容 API。环境变量通过python-dotenv从项目根目录的.env文件加载需要配置的变量源码 llm_client.py 确认环境变量含义备注LLM_MODEL_ID模型标识必填缺少会抛ValueErrorLLM_API_KEYAPI 密钥必填LLM_BASE_URLAPI 基础地址必填LLM_TIMEOUT请求超时秒数可选默认60README 中的启动步骤是cp .env.example .env后编辑配置若当前仓库快照中未包含.env.example文件可直接在项目根目录新建.env按上表写入四个变量即可效果相同。think()方法L34-L52使用temperature0最大化确定性适合工具调用场景并开启流式streamTrue逐 chunk 收集输出verboseTrue时会在控制台实时打印模型推理内容这也是运行 demo 时能看到思考过程的原因。README 提到免费 LLM 选项AIHubmixhttps://aihubmix.com/v1免费额度、OpenAI 兼容与 ModelScope/Qwenhttps://api-inference.modelscope.cn/v1每日 2000 次免费调用均为 README 中给出的配置前提。七、FastAPI 后端把流水线暴露为 REST API除 Jupyter Notebook 外项目还提供了可直接启动的 API 服务src/api/main.py启动命令uvicorn src.api.main:app --reload --port 8000API 层在启动时添加了 CORS 中间件allow_origins[*]源码注释提示接入特定前端时应收紧为后续前端集成铺路。四个端点与职责MethodEndpoint说明GET/health存活探针返回{status: ok}GET/incidents/fixtures列出内置事故 ID来自list_incidents()POST/incidents/investigate同步运行完整三阶段流水线入参{incident_id: ...}GET/incidents/{id}/report取回已生成的事故复盘报告几个实现细节值得注意POST /incidents/investigate会先用load_incident()做早期校验事故不存在时返回 404流水线异常时返回 500运行耗时以elapsed_seconds字段返回报告暂存于内存字典_report_store源码注释明确提示生产环境应替换为 Redis/DB。当前实现为同步调用注释中给出了升级方向——后台任务 SSE 流式推送。八、快速开始与三种使用方式8.1 环境准备Python 3.10安装依赖pip install -r requirements.txt依赖清单见 requirements.txt含openai、fastapi、uvicorn、pyyaml、pydantic、python-dotenv配置.env中的LLM_API_KEY/LLM_BASE_URL/LLM_MODEL_ID8.2 方式一Jupyter Notebookjupyter lab # 打开 main.ipynb依次运行所有 cellNotebookmain.ipynb适合逐步观察三个阶段的运行过程与中间输出。8.3 方式二Python 脚本调用流水线from src.agents.pipeline import run_pipeline result run_pipeline(db_pool_exhaustion) print(result[report]) # Markdown 格式的 RCA 复盘报告 print(result[findings]) # 根因结论 证据字典8.4 方式三curl 调用 REST API# 列出可用事故 curl http://localhost:8000/incidents/fixtures # 运行完整流水线 curl -X POST http://localhost:8000/incidents/investigate \ -H Content-Type: application/json \ -d {incident_id: db_pool_exhaustion} # 获取生成的复盘报告 curl http://localhost:8000/incidents/db_pool_exhaustion/report8.5 一次完整的运行输出示例 STAGE 1: TRIAGE — Generating investigation plan 1. [log_search] pool exhausted — Find DB pool error log entries 2. [metric_query] db_pool — Check connection pool saturation over time 3. [metric_query] latency — Quantify request latency degradation 4. [runbook_lookup] DB pool exhausted — Get remediation steps STAGE 2: INVESTIGATION — ReAct tool loop Step 1 — log_search[pool exhausted] → 3 matching entries found Step 2 — metric_query[db_pool] → pool maxed at 10/10 from 14:01 onward Step 3 — runbook_lookup[DB pool exhausted] → runbook steps retrieved ✅ Root cause: Missing index on orders.user_id causing full table scan... STAGE 3: POST-MORTEM — Reflection (draft → critique → revise) Quality score: 9/10 — no revision needed. ✅ Final post-mortem ready.九、评估结果与扩展路线9.1 性能评估README 记录的实验结果项目在三个内置事故 fixture 上做了评估README 注明使用 Llama-3.3-70b via Groq兼容任意 OpenAI 兼容 API事故识别出的根因流水线耗时DB pool exhaustion✅orders.user_id缺少索引~30sMemory leak OOM✅ 无 TTL/淘汰策略的 Session 缓存~25sExternal API rate limit✅ 无指数退避导致的重试风暴~28sREADME 报告在样例 fixture 上的根因识别准确率为3/3 (100%)。需要说明的是这一结果是项目在自带三个固定 fixture 上的自测数据并非对任意生产事故的泛化能力声明。9.2 未来规划README 列出的升级路径SSE 流式输出把 Agent 推理步骤实时推送到前端Vue/React 前端事故选择器 实时轨迹 Markdown 查看器真实日志接入对接 Loki / CloudWatch / Datadog向量记忆对历史 RCA 报告做向量化加速后续调查安全的 runbook 执行让 Agent 执行低风险处置命令。这些方向都与现有代码结构兼容——Agent 层与 API 层解耦接入前端或数据源无需改动三阶段 Agent 本身。十、小结三种范式的串联要点回看整个项目SRE On-Call Agent 的价值不仅是「一个运维 Demo」更是三种范式如何协作的范本Plan-and-Solve 负责全局规划把不确定的开放问题拆解成确定步骤ReAct 负责与环境互动用真实工具输出取代模型猜测Reflection 负责质量闭环让产出经过自我评审与迭代。三者各司其职正好对应告警处理中「想清楚 → 查清楚 → 写清楚」三个阶段。如果你正在学习《从零开始构建智能体》第四章或正在为自己的领域设计多阶段 Agent 流水线这个项目的源码pipeline.py、三个 Agent 实现、三个工具实现都是可直接对照研读的完整样例。项目遵循 MIT 协议更多贡献与协作规范可参阅仓库根目录的 README.md 与 LICENSE.txt。【免费下载链接】hello-agents 《从零开始构建智能体》——从零开始的智能体原理与实践教程项目地址: https://gitcode.com/GitHub_Trending/he/hello-agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考