代码解析代码地址. ├── main.py └── data_sources.pymain.pyReAct agent 主流程负责让大模型思考、选择工具、接收观察结果data_sources.py工具层负责模拟告警平台、nginx 日志、业务日志、prometheus 查询所谓 ReAct就是Reasoning Acting 先想一下 → 决定查什么 → 调工具查数据 → 根据结果继续想 → 最后给结论在代码里它被明确约束成下面这个格式Thought: 当前思考 Action: 要调用哪个工具 Observation: 工具返回结果 Final Answer: 最终排查报告这就是典型的 ReAct 执行链路关键提示词约束模型的关键提示词:你必须严格按照以下格式输出 Thought: 你的思考过程分析当前情况并决定下一步做什么 Action: 要调用的工具和参数例如check_alarm_platform(serviceorder-service) Observation: 工具返回的结果不需要你输出 或者当你认为已经收集到足够信息时 Thought: 我已经收集到足够的信息可以得出结论了 Final Answer: 完整的故障排查报告包括故障现象、根因定位、解决方案告诉模型的角色线上故障排查专家告诉模型它有哪些工具可以用强制模型按 ReAct 格式输出这就是显式 ReAct 的特点用 prompt 规范输出格式循环约束ReAct 模式天然是循环结构如果没有最大轮次限制模型一旦陷入“继续查询、继续分析、继续查询”的死循环必须加上最大轮次的限制max_rounds 8max_rounds 8 round_count 0 while round_count max_rounds: round_count 1 print(f--- [第 {round_count} 轮] ---) response client.chat.completions.create( modelMODEL, messagesmessages, temperature0.1 )action 解析与工具调用当模型输出action:后代码会解析 action 内容然后调用对应工具if check_alarm_platform in action_part: service order-service if service in action_part: start action_part.find(service) 9 end action_part.find(, start) service action_part[start:end] observation check_alarm_platform(service)Nginx 日志elif nginx_log_query in action_part: status: str if status in action_part: start action_part.find(status) 8 end action_part.find(, start) status action_part[start:end] observation nginx_log_query(statusstatus)业务日志elif get_business_logs in action_part: service order-service keyword error ... observation get_business_logs(serviceservice, keywordkeyword)ReAct 里action的落地点。模型不负责获取数据它不能直接连数据库不能直接 SSH 到机器不能直接改配置。它应该先提出动作意图然后由程 序层做白名单校验、参数解析、权限控制和工具调用这部分可以后面改造到mcp中去observation工具执行完以后代码会把结果打印出来并继续塞回对话历史print(fObservation: {observation}\n) messages.append({role: assistant, content: reply}) messages.append({role: user, content: fObservation: {observation}})这一步就是 ReAct 的闭环模型上一轮说Thought: 我应该先查一下告警平台 Action: check_alarm_platform(serviceorder-service)程序执行工具获取数据后把结果作为 Observation 回给模型Observation: [CRITICAL] 订单服务 5xx 错误率过高...下一轮模型就可以基于这个事实继续推理不断循环直至大模型已经得出排查完成或者达到最大轮次demo的执行链路用户输入告警订单服务接口超时部分用户报错 504main.py把告警信息发给大模型大模型输出Thought: 需要先查告警平台Action: check_alarm_platform(serviceorder-service)程序解析 Action调用 check_alarm_platform工具返回 Observation5xx 高、P99 高、实例数正常大模型继续输出下一步 Action例如查 Nginx 504 日志程序调用 nginx_log_query(status504)工具返回大量 /api/orders 504 日志大模型继续查业务日志程序调用 get_business_logs(serviceorder-service, keyworderror)工具返回 DB timeout、连接池满、SQL 查询超时大模型输出 Final Answer根因、影响面、处理建议ReAct 注意事项ReAct 本质就是Thought / Action / Observation但是真正落地时至少要注意下面这些点工具必须白名单化不要让模型随便执行任意命令模型只能从这几个工具里选check_alarm_platform(service) nginx_log_query(status, path, limit) get_business_logs(service, keyword)当然还可以更加的精细化当然这是工程化的项目了工具白名单参数白名单只读工具优先高危动作必须人工确认所有调用要有审计日志...observation 必须是真实反应线上状态。ReAct 的价值在于模型能基于 observation 继续推理。如果工具返回的数据本身就是错的、脏的、过期的那 模型分析得再漂亮也没用敏感数据加密这就不多解释了非常重要。发给外部llm的数据必须经过脱敏、加密等步骤每一轮只能做一个 actionprompt 里有一个约束非常关键每轮只输出一个 Thought Action 或 Thought Final Answer要限制最大轮次和成本max_rounds 8低温度更适合排障temperature0.1工具结果要控制长度nginx_log_query里有个参数limit: int 10这也是好习惯不要把几万行日志直接塞给模型。更合理的做法是先用程序侧过滤、聚合、排序把关键片段给模型让模型基于摘要做判断必要时再继续下钻final answer 要包含证据链prompt 里要求最终报告包含故障现象、根因定位、解决方案或者1故障现象 2影响范围 3关键证据 4根因判断 5临时止血方案 6长期修复建议