ReAct Agent 原理：推理、行动、观察与工具调用

上一节，咱们留下了一个问题。

payment-service 从 15:10 开始出现大量支付失败，Agent 到底应该先查什么？

这个问题并没有唯一答案。

因为在真正开始排查以前，Agent 并不知道问题来自代码、数据库、服务器资源，还是某一次发布。

它只能先执行一个动作，拿到一些真实数据，再根据这些数据决定下一步。

比如，Agent 先去查看监控指标，得到下面这个结果：

• CPU 使用率：43%
• 内存使用率：58%
• 数据库连接池使用率：46%
• 支付接口 5xx 错误率：31.8%

CPU、内存和数据库连接池都没有明显异常。

这个时候，继续检查数据库连接池的意义就不大了。Agent 更应该去看错误日志，确定这些 5xx 到底是什么错误。

但是，如果监控返回的是另一份结果：

• CPU 使用率：39%
• 内存使用率：61%
• 数据库连接池使用率：100%
• 支付接口 5xx 错误率：26.4%

排查方向就变了。

数据库连接池已经达到 100%，Agent 接下来就应该检查活跃连接、等待请求和长时间运行的 SQL。

大家看，同样的用户目标、同样一组工具，只是监控数据发生了变化，下一步就可能完全不同。

这就是这一节要讲的 ReAct。

ReAct 到底是什么

ReAct 不是一个框架，也不是一个需要安装的 npm 包。

它来自 2022 年发布的论文《ReAct: Synergizing Reasoning and Acting in Language Models》，后来发表于 ICLR 2023。原文地址在这里：https://react-lm.github.io/

这个名字由两个单词组合而来：Reasoning + Acting = ReAct

原始论文想解决的问题是：模型不能只坐在那里推理，也不能只会机械执行动作。

它需要 一边判断当前情况，一边与外部环境交互。环境返回新的信息以后，模型再更新判断，继续执行。

整个过程可以先理解成下面这样：

这里出现了两个新的单词：Action 和 Observation

• Action 表示 Agent 当前决定执行的动作。在故障排查的时候，下面这些都可以算作 Action：

查询服务状态
查询监控指标
查询错误日志
查询最近发布记录
检查数据库连接池

• Observation 表示 Action 执行以后，外部环境返回的真实结果。比如：

Action：查询 payment-service 的监控指标

Observation：数据库连接池使用率 100%，当前有大量请求等待连接

Agent 看完这份 Observation，才决定下一步去检查数据库连接池。

所以，Observation 的结果应该来自监控平台、日志系统、数据库、浏览器、文件系统或者其他真实工具的检测结果

实现一个最小故障排查 Agent

课程源码：https://github.com/lgd8981289/Agent--Code

本小节完整代码位于：Code/Node/第四章/02-react-incident-agent

这个案例会准备两套不同的故障数据。

• 第一套是新版本发布引起的代码错误
• 第二套是数据库连接池耗尽的错误场景

Agent 收到的用户目标完全相同，可用工具也完全相同。咱们要观察的是：工具返回不同的 Observation 以后，Agent 会不会进入不同的排查路线。

创建项目

进入第四章代码目录，创建项目：

mkdir 02-react-incident