我们是由枫哥组建的IT技术团队，成立于2017年，致力于帮助IT从业者提供实力，成功入职理想企业，我们提供一对一学习辅导，由知名大厂导师指导，分享Java技术、参与项目实战等服务，并为学员定制职业规划，全面提升竞争力，过去8年，我们已成功帮助数千名求职者拿到满意的Offer：IT枫斗者、IT枫斗者-Java面试突击。

---

前言

现在 AI Agent 开发如火如荼，绝大多数实用型智能 Agent（自动排查、智能问答、自动化运维），底层核心全部依赖 ReAct 模式。

很多同学只听过 ReAct 名词，但完全不知道实际项目中怎么落地、怎么约束模型、怎么实现循环推理、怎么对接工具。

本文通过一个可直接运行的线上故障排查 Agent Demo，手把手带你吃透 ReAct 核心原理 + 工程落地细节，学完即可上手开发企业级智能 Agent。

话不多说，直接进入实战！

一、什么是 ReAct 模式？

ReAct 是当前 Agent 开发的最主流、最基础、最通用的执行模式，核心就是两个单词组合：

ReAct = Reasoning（推理思考） + Acting（工具行动）

1.1 核心执行链路

完全模拟人类排查问题的思维：

先思考 → 决定下一步动作 → 调用工具获取数据 → 基于结果继续思考 → 循环迭代 → 得出最终结论

1.2 标准化固定格式（ReAct 精髓）

工程落地中，我们会通过 Prompt 强制约束大模型输出固定格式，这是 ReAct 能自动化运行的核心：

• Thought：当前模型的思考过程，分析现状、制定下一步计划
• Action：需要调用的工具名称 + 执行参数
• Observation：工具执行后的真实返回结果（程序回填，模型不输出）
• Final Answer：信息收集完毕后，输出最终结论报告

这一套闭环，就是所有 ReAct Agent 的底层运行逻辑。

二、项目整体结构

本次 Demo 实现自动化线上故障排查 Agent，项目结构极简，分为两层：

.
├── main.py        # ReAct Agent 核心主流程（推理、循环、工具调度）
└── data_sources.py # 工具层（模拟各类线上数据查询能力）

文件职责说明

• data_sources.py（工具层）：模拟线上运维工具，包含告警平台查询、Nginx日志查询、业务日志查询等能力，纯数据返回，无业务逻辑
• main.py（核心层）：控制 ReAct 循环、约束模型输出、解析工具指令、回填观测结果、终止判断、输出最终报告

三、工具层能力（data_sources.py）

我们模拟线上运维常用的 3 类排查工具，所有工具均为只读查询，安全无风险：

1. check_alarm_platform：查询告警平台，获取服务异常指标、错误率、P99、实例状态
2. nginx_log_query：查询 Nginx 网关日志，筛选状态码、接口路径、异常请求
3. get_business_logs：查询服务业务日志，定位代码异常、SQL超时、连接池耗尽等问题

工具层设计原则：只负责拿真实数据，不做任何分析、决策，决策全权交给大模型。

四、ReAct 核心落地实现（main.py）

4.1 关键约束 Prompt（Agent 的灵魂）

想要模型稳定运行 ReAct 循环，必须通过 Prompt 强约束，不能让模型自由输出。核心提示词模板如下：

你是一名资深线上故障排查专家，你拥有以下工具：
1. check_alarm_platform(service)：查询服务告警指标
2. nginx_log_query(status, path, limit)：查询网关日志
3. get_business_logs(service, keyword)：查询业务报错日志

你必须严格按照固定格式输出：
1. 未收集完信息时：
Thought: 你的思考过程，分析当前情况并决定下一步做什么
Action: 工具名(参数名="参数值")

2. 收集完所有信息后：
Thought: 我已经收集到足够的信息，可以得出结论了
Final Answer: 输出完整故障报告，包含故障现象、影响范围、关键证据、根因、止血方案、长期优化建议

约束：每轮只能输出一个 Thought + Action，禁止多动作并行，最大推理轮次为8轮

4.2 ReAct 循环核心代码

ReAct 本质是有限次数的死循环，必须设置最大轮次，防止模型死循环卡死：

MAX_ROUNDS = 8
round_count = 0

# ReAct 循环主体
while round_count < MAX_ROUNDS:
    round_count += 1
    print(f"--- [ReAct 第 {round_count} 轮推理] ---")

    # 调用大模型，获取思考与动作
    response = client.chat.completions.create(
        model=MODEL,
        messages=messages,
        temperature=0.1  # 低温度，保证推理稳定、确定性高
    )

    reply = response.choices[0].message.content
    print(f"模型输出：\n{reply}\n")

    # 命中最终结论，终止循环
    if "Final Answer" in reply:
        print("✅ 排查完成，输出最终报告")
        break

    # 解析 Action，执行工具调用
    action_part = reply.split("Action:")[-1].strip()
    observation = parse_and_run_action(action_part)

    # 核心闭环：将工具结果回填对话历史
    messages.append({"role": "assistant", "content": reply})
    messages.append({"role": "user", "content": f"Observation: {observation}"})

4.3 Action 解析与工具调度

模型只负责输出动作意图，参数解析、工具校验、方法调用全部由程序层完成，这是工程化安全的关键：

def parse_and_run_action(action_part: str):
    # 1. 查询告警平台
    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]
        return check_alarm_platform(service)

    # 2. 查询 Nginx 日志
    elif "nginx_log_query" in action_part:
        status = ""
        if 'status="' in action_part:
            start = action_part.find('status="') + 8
            end = action_part.find('"', start)
            status = action_part[start:end]
        return nginx_log_query(status=status, limit=10)

    # 3. 查询业务日志
    elif "get_business_logs" in action_part:
        service = "order-service"
        keyword = "error"
        if 'service="' in action_part:
            start = action_part.find('service="') + 9
            end = action_part.find('"', start)
            service = action_part[start:end]
        return get_business_logs(service=service, keyword=keyword)

    return "未识别的工具指令"

4.4 Observation 闭环回填

工具执行结果不会直接展示给用户，而是作为观测结果回填对话上下文，让模型基于最新事实继续推理，形成闭环：

# 打印观测结果，回填对话历史
print(f"Observation: {observation}\n")
messages.append({"role": "assistant", "content": reply})
messages.append({"role": "user", "content": f"Observation: {observation}"})

核心逻辑：模型上一轮的动作产出 → 程序真实执行 → 数据反馈给模型 → 下一轮继续深度推理。

五、完整 Demo 执行链路演示

用户输入问题：订单服务接口超时，部分用户报错 504

第一轮推理

Thought：业务出现504超时错误，首先需要查询告警平台，确认服务整体异常指标

Action：check_alarm_platform(service=“order-service”)

Observation：[CRITICAL] 订单服务5xx错误率飙升、P99响应时间超时、服务实例数正常、无宕机

第二轮推理

Thought：确认存在5xx异常，需要查询Nginx网关日志，定位报错接口路径

Action：nginx_log_query(status=“504”)

Observation：大量 /api/orders 接口504超时请求，集中在高并发时段

第三轮推理

Thought：网关确认接口超时，需要查询业务日志，定位代码/数据库层根因

Action：get_business_logs(service=“order-service”, keyword=“error”)

Observation：数据库连接池耗尽、大量SQL查询超时、事务执行卡顿

最终输出 Final Answer

模型收集全部信息后，自动终止循环，输出完整结构化故障报告（含现象、影响、证据、根因、解决方案）。

六、ReAct 工程落地核心注意事项（避坑重点）

本地 Demo 很简单，但想要落地生产级 Agent，必须做好以下约束，否则极易出问题。

1. 工具必须白名单管控

绝对禁止模型随意执行系统命令、脚本、高危操作，所有工具必须固定白名单：

• 工具白名单
• 参数白名单校验
• 优先只读工具
• 高危操作强制人工确认
• 全流程调用审计日志

2. Observation 必须真实有效

ReAct 的核心价值是基于真实数据迭代推理。如果工具返回脏数据、过期数据、错误数据，模型推理逻辑再完美也无意义。

3. 数据脱敏与加密

线上日志、告警数据包含大量敏感信息，调用外部LLM必须做脱敏、过滤、加密，杜绝数据泄露。

4. 单轮单次 Action 约束

Prompt 必须强制：每轮只做一个动作，多动作并行会导致解析混乱、推理链路不可追溯。

5. 最大轮次 + 成本控制

必须配置 max_rounds（本文配置8轮），防止模型无限循环推理，造成 Token 浪费、接口卡死。

6. 低温度适配运维场景

故障排查、数据分析类 Agent，必须使用 temperature=0.1，保证推理严谨、稳定、无随机发散。

7. 工具结果裁剪，控制上下文长度

禁止直接推送几禁止直接推送几万行原始日志给模型，正确做法：

• 程序层先过滤、聚合、排序、截断
• 只推送关键异常片段
• 支持模型按需下钻查询

8. Final Answer 必须结构化带证据链

生产级 Agent 输出报告必须包含完整链路，杜绝空话结论：

1. 故障现象
2. 影响范围
3. 关键排查证据
4. 根因精准定位
5. 临时止血方案
6. 长期修复优化建议
7. 待确认不确定项

七、核心总结

1. ReAct 模式的本质：Thought推理 + Action行动 + Observation观测的无限循环，模拟人类解决复杂问题的思维
2. Agent 开发核心不是模型调用，而是流程约束、工具治理、循环控制、成本控制、安全管控
3. 落地关键：固定 Prompt 格式、白名单工具、最大轮次限制、结构化输出、数据脱敏审计
4. 本文 Demo 可直接改造为：智能运维排障、自动化数据分析、业务问题自查、知识库问答等各类 Agent

---

⭐️推荐:

• Offer训练营介绍
• Java 面试 & 后端通用面试八股文
• Java后端企业级实战面试
• Java后端校招算法学习