企业官网建设流程全解析

本文带你走进开源教学仓库engenharia-de-software-com-ia-aplicada（应用 AI 软件工程硕士课程的代码与参考资料库），围绕其中的 OpsPilot 值班副驾项目，拆解 AI Agent 的 3 大核心推理模式——ReAct、Plan-and-Execute 与 Reflection，并附上可运行的源码与规格文档路径，帮助新手快速上手 Agent 推理开发。

在 modulo04-criacao-de-agentes-autonomos-novo/ 模块中，OpsPilot 是为一家虚构电商 "Mercadinho" 打造的值班副驾（copiloto de plantão）：它能用自然语言查询活跃告警、开启并解决事故（incident）。整个项目的"大脑"正是三种推理策略共用一套接口 ReasoningStrategy：

run(input) → (answer, trace, metrics)

本单元说明见 UNIDADE.md。

为什么 AI Agent 需要"推理模式"？

单纯的大语言模型只会输出文字，无法真正"干活"。要让 LLM 查询数据库、调用工具、处理错误，就必须给它一套思考—行动—观察的推理循环。这正是 Agent 推理模式要解决的问题。

OpsPilot 所处的场景正是最典型的运维闭环：告警触发 → 调查根因 → 处置事故。下图展示了这类"在问题发生前就介入调查"的智能监控理念：

OpsPilot 就定位于此类场景：用自然语言驱动告警查询与事故处置

项目为此只提供了 3 个模拟工具——list_alerts、open_incident、resolve_incident，配合内存 store（种子数据含 5 个服务、6 条告警，见 seed-data.json）。工具越少、任务越清晰，三种模式的差异就越容易观察。

模式一：ReAct——"想一点、做一点、看一点"的循环

ReAct（Reasoning + Acting）是最经典的 Agent 推理循环，节奏非常直白：

💭Thought（思考）→ 🛠️Action（调用工具）→ 👀Observation（观察结果）→ 循环直到给出Answer

例如用户问"哪些服务有活跃告警？"，Agent 会先思考需要查询告警状态，再调用list_alerts({"status":"firing"})，看到 3 条告警后综合作答。

实现要点（源码：src/agents/react.ts）：

• 直接复用 LangGraph 预置的createReactAgent，无需手写循环；
• 执行完毕后，从消息数组重建推理轨迹：带tool_calls的 AI 消息 →thought+action事件，工具返回 →observation事件，由 buildTraceFromMessages 完成；
• 用recursionLimit兜底防止死循环，超限时优雅返回"达到迭代上限"，而不是挂起。

优点：结构简单、响应快，适合步骤少、工具明确的短任务。缺点：它没有全局视角，任务一长容易"走丢"，且每步都要调用模型，长任务成本线性上涨。

模式二：Plan-and-Execute——先规划，再执行

Plan-and-Execute 的思路像项目经理：先产出完整计划，再逐步执行，执行中随时修订计划。它在 src/strategies/plan-execute.ts 中实现为一个三节点状态图：

整张图由 LangGraph 的StateGraph条件边驱动（图构建代码），状态里累积plan、done、trace等通道。

优点：全局计划清晰、步骤上限可控、依赖关系可显式传递（"复用已获得的数据"），适合多步骤、有依赖的任务。缺点：多了一次规划调用；初始计划可能过时，必须靠 replanner 动态纠偏。

模式三：Reflection——让"批评家"复核答案

Reflection 是后两者之上的装饰器层：它不改变执行方式，而是在答案产出后让一个"严格批评家"（critic）复核，不满意就打回重做。

实现要点（源码：src/strategies/reflect.ts）：

1. withReflection(strategy)包裹任意基础策略，装饰后命名为reflect:react或reflect:plan-and-execute；
2. 批评家只依据 trace 中的观察结果和原始请求评判，不允许"编造事实"，输出结构化结果{ approved, feedback }（zod 校验）；
3. approved: false时，把批评意见注入输入（[Critique - Round N]）重新执行，默认最多 2 轮（maxReflections）；
4. fail-safe 设计：批评家输出解析失败时按"通过"处理，避免死循环和崩溃；
5. 每轮在 trace 中追加一条critique事件，并把批评与重做的 LLM 调用全部计入metrics。

优点：为答案质量加了一道"质检关"，且循环有上限、可观测。缺点：额外消耗 LLM 调用与延迟，需要纳入成本预算。

三模式共用的地基：类型化 Trace

三种模式都输出统一的 6 类推理事件（TraceEventType）：

thought | action | observation | plan | critique | answer

这让项目内置了两个"实验工具"：

• Arena（src/arena.ts）：同一输入下并排运行多种策略，打印各自的 trace、LLM 调用次数与延迟；
• Bench（src/bench.ts）：用预置场景跑基准，关键点在于以 store 的实际状态（而不是回答文本）来判定对错——这是评估 Agent 可靠性的好习惯。

当推理核走向生产时，trace 与指标正是企业 AI 架构中 Observability（可观测性）块的核心内容，可对照本项目 modulo08 的架构参考图

快速上手：三步跑通 3 种推理模式

进入快照目录即可运行（每个单元文件夹都是项目当时的完整快照）：

cd modulo04-criacao-de-agentes-autonomos-novo/02-padroes-de-raciocinio-e-execucao npm ci # 在 .env 中配置 OPENROUTER_API_KEY（免费模型零成本） npm run arena -- --strategies react,plan-and-execute npm run bench npm test

运行参数说明：

• --strategies：可选react、plan-and-execute、reflect:react、reflect:plan-and-execute（可组合）；
• --max-iterations：迭代上限，防止无限循环；
• 详细验证步骤见 quickstart.md。

如何选型：一张对照表看懂 3 大模式

实践中的"组合拳"是reflect:plan-and-execute：先规划再执行，最后让批评家把关。选型的理论依据可阅读规格文档 001-reasoning-nucleus/spec.md 与 research.md。

延伸学习：模块关键资料路径

• 单元导读：UNIDADE.md
• 推理核规格：specs/001-reasoning-nucleus/spec.md
• Reflection 层规格：specs/002-reflection-layer/spec.md
• ReAct 策略：src/agents/react.ts
• Plan-and-Execute 策略：src/strategies/plan-execute.ts
• Reflection 装饰器：src/strategies/reflect.ts
• Trace 构建器：src/trace/builder.ts
• 模块总览：modulo04 README

掌握这 3 大推理模式后，可以继续本模块的后续单元：04-memoria-e-reflexao-em-agentes-autonomos（记忆与学习式反思）和 05-gerenciamento-de-contextos（上下文预算管理），把 Agent 从"能推理"打磨到"又省又稳"。