AI Agent 工程化实践：从 ReAct 循环到多智能体编排

逻辑艺术家

46人浏览 · 2026-07-24 17:28:12

逻辑艺术家 · 2026-07-24 17:28:12 发布

AI Agent 工程化实践：从 ReAct 循环到多智能体编排

一、引言

2026 年，AI Agent 已经走过了"概念验证"的阶段。OpenAI、Anthropic、Google 相继推出原生推理模型，Agent 框架生态也从早期的混沌走向分层成熟。然而在实际的工程落地中，许多团队仍然面临着同一个问题：Demo 跑得很顺，上线就崩。

根本原因在于，Agent 系统的核心不是模型能力，而是工程架构。一个简单的 ReAct 循环只有 7 行代码，但一个能在生产环境中稳定运行的 Agent 系统，需要处理终止条件、工具治理、错误恢复、上下文管理、可观测性等一系列工程问题。本文试图从工程架构的视角，梳理 Agent 系统设计的核心模式与取舍。

二、Agent 核心循环的工程化

2.1 ReAct 范式：认知闭环的原型

ReAct（Reasoning + Acting）由 Yao 等人于 2022 年提出，核心思想是让 LLM 交替输出推理轨迹（Thought）和行动指令（Action），并将外部反馈（Observation）作为下一轮推理的输入。这个"思考→行动→观察"的闭环构成了所有 Agent 系统的认知原点。

用伪代码表达这个核心循环，极其简洁：

loop:
    response = llm.chat(messages, tools)
    if response has no tool_calls:
        return response.text           // 纯文本回复 → 结束

    for each tool_call in response:
        result = execute(tool_call)     // 执行工具
        append tool result to messages  // Observation 回到上下文

    // 进入下一轮推理

这段代码只有不到 10 行，却是 Agent 的"最小公倍数"——从 mini-swe-agent（100 行代码，SWE-bench 74%）到大规模的通用 Agent 系统，核心逻辑都是这个循环。不同系统的差异，体现在这个循环周围所添加的工程能力上。

2.2 生产级循环：从 Demo 到上线

将上述循环投入生产，需要回答一系列问题：

问题	工程方案
什么时候停止？	最大轮次限制、取消令牌、控制流 Break
工具调用失败怎么办？	重试策略（Retry）或终止策略（Stop）
上下文无限膨胀怎么办？	上下文窗口管理器按策略修剪
如何在不侵入循环的前提下控制行为？	三层中间件 Hook
出问题了怎么定位？	事件总线 + 检查点持久化

这些问题的答案构成了现代 Agent 运行时（Agent Runtime）的核心。以一个生产级实现为例，核心循环的工程结构通常是：

loop:
    turn_count += 1

    if cancelled → return Cancelled
    if turn_count > max_turns → return MaxTurnsExceeded

    // 1. 上下文管理
    messages = load_session_messages()
    context_manager.trim(messages)        // 防止上下文溢出

    // 2. Pre-LLM 中间件（可修改消息和工具列表）
    messages, tools = apply_pre_llm_middlewares(messages, tools)

    // 3. 调用 LLM 获取回复
    response = llm.chat(messages, tools)
    save_checkpoint()

    // 4. Post-LLM 中间件（行为控制、Nudge 机制）
    result = apply_post_llm_middlewares(response)

    // 5. 处理工具调用
    if result.has_tool_calls:
        save_checkpoint(with tool_calls)
        outputs = tool_engine.orchestrate(tool_calls)
        append_tool_results_to_session(outputs)
        continue                          // 回到 LLM

    // 6. 纯文本回复 → 完成
    append_assistant_response_to_session(response.text)
    return Completed

相比学术原型，生产版本增加了三个关键维度：中间件管道让行为控制可插拔，检查点机制让执行过程可恢复，错误恢复策略让系统具备鲁棒性。

三、工具调用的治理与执行管道

工具调用是 Agent 与外部世界交互的唯一通道，也是最容易出问题的环节。一个健壮的工具执行系统需要解决三个问题：能不能调（权限）、会不会超时（稳定性）、输出会不会撑爆上下文（安全性）。

3.1 执行管道（Execution Pipeline）

现代 Agent 系统将工具执行抽象为一个管道（Pipeline），在"调用工具"这个简单动作的前后插入治理逻辑：

execute(tool, args):
    1. before_call 钩子 → 策略检查（权限、频率、合规）
    2. 执行工具（带超时）
    3. 输出截断（防止撑爆上下文）
    4. after_call 钩子 → 审计记录

其中超时控制是生产环境中最容易被低估的问题。一个未设置超时的工具调用可能阻塞整个 Agent 循环数分钟。而输出截断对于支持多轮工具调用的场景尤为重要——一个返回数万字符的 API 响应，如果不加截断会迅速消耗上下文预算。

3.2 审批流程（Human-in-the-Loop）

高风险操作（文件删除、数据变更、支付调用）需要人在回路中审批。审批流程的设计需要平衡安全性与用户体验：

审批请求：包含工具名称、参数摘要、风险等级
审批决策：允许/拒绝/超时自动拒绝
结果处理：拒绝后推送拒绝消息，让 LLM 调整策略

3.3 错误恢复策略

工具调用的错误不可避免。关键设计决策是：发生错误后，是让 LLM 自己修正，还是立即终止？

两种策略各有适用场景：

Retry（重试策略）：将错误信息作为 User 消息推回，让 LLM 自行调整参数或换一种方式。适用于工具参数错误、临时性故障等可纠正的场景
Stop（终止策略）：立即停止本轮执行。适用于权限拒绝、严重系统错误等不可纠正的场景

选择哪种策略，本质上是由业务场景决定的——在编码 Agent 中，一次编译错误应该让 LLM 重试修复；在金融交易 Agent 中，一次执行失败可能意味着立即终止并通知人工介入。

四、多智能体协作与能力扩展

当单一 Agent 承担的职责越来越重，"把所有工具挂载到一个 LLM"的架构开始出现瓶颈——一个 Agent 管理 50 个工具，不仅 Prompt 迅速膨胀，工具选择也变得不精准。业界逐渐转向多智能体协作架构。

4.1 多智能体编排模式

目前主流的编排模式有三种：

单 Agent + 工具集群：最简单，但工具数增长后准确率下降。

分层编排（Orchestrator + Workers）：一个编排 Agent 负责意图识别和任务分发，多个 Worker Agent 各司其职。编排层通常使用更强（也更贵）的模型，执行层可以使用轻量模型降低成本。

对等群（Swarm）：多个对等 Agent 通过标准化协议通信，没有中心调度节点。适合需要容错和去中心化控制的场景。

4.2 能力扩展：Skill 与 MCP

Agent 的能力不是与生俱来的，而是通过外部扩展注入的。两种主流扩展方式：

Skill：将能力封装为声明式描述（YAML、Markdown 等），包含触发条件、执行步骤和参数定义。Agent 在运行时根据用户意图动态加载对应的 Skill，实现"按需注入"
MCP（Model Context Protocol）：由 Anthropic 推动的标准化工具协议。将工具发现、Schema 获取、调用执行标准化，让 Agent 可以动态发现和连接远程工具服务器。MCP 的普及使得工具接入不再是框架绑定的操作

4.3 Agent 通信层

在多 Agent 架构中，Agent 之间的通信协议与状态传递是关键设计点。一个常见的模式是使用 事件总线（EventBus） 进行异步通信——Agent 产生事件，订阅者消费事件。这种方式天然解耦，但也引入了事件顺序、消息丢失等分布式系统的经典问题。

更务实的做法是使用消息队列模式：每个 Agent 有一个独立的输入队列，通过一个统一的消息句柄（AgentHandle）进行收发，上层调用者（CLI / UI / API）通过这个句柄与 Agent 系统交互。这种模式在保持解耦的同时，简化了状态管理和错误处理。

五、可观测性与状态管理

Agent 系统有别于传统后端服务的一个重要特征是状态敏感性——一个 Agent 的推理过程可能跨越数十轮 LLM 调用和工具执行，中间任何一步出错都可能导致结果偏离。要让这种系统可运维，可观测性和状态管理不可或缺。

5.1 事件驱动的可观测性

将 Agent 运行过程中的关键节点（LLM 调用开始/结束、工具调用开始/结束、轮次切换、任务完成/取消）以结构化事件的形式广播。这种方式的好处是：消费端与生产端解耦。

同一个事件总线，CLI 用来打印进度，UI 用来渲染实时状态，日志系统用来持久化审计记录。每个消费者只关心自己需要的事件子集。

5.2 Session 与 Checkpoint

Agent 的一次对话（Session）包含完整的消息历史和执行状态。在生产系统中，Session 需要：

持久化：崩溃后恢复，支持多轮长对话
加载/保存：在每次 LLM 调用前后保存状态，确保可恢复
检查点续传（Checkpoint Resume）：在工具调用失败或系统重启后，从上一个检查点恢复执行，而不是从头开始

检查点的粒度是一个工程设计权衡：粒度过细则 I/O 开销大，粒度过粗则恢复时可能丢失状态。实践中，在 BeforeLlm、BeforeToolCalls、AfterToolCalls 等关键节点落盘是一个合理的选择。

5.3 上下文窗口管理

LLM 的上下文窗口有限，而 Agent 的对话轮次会不断增长。上下文窗口管理器（ContextWindowManager）负责在每次 LLM 调用前修剪消息列表，确保不超过窗口限制。

修剪策略本身也是一个系统工程问题——简单地从最早的消息开始丢弃会丢失关键上下文。更成熟的策略包括摘要压缩（将早期消息压缩成一段摘要）、滑动窗口（只保留最近的 N 轮）、以及基于重要性的选择性保留。

六、趋势与工程启示

6.1 从编排框架到原生推理

2025-2026 年最显著的变化是基础模型开始原生支持推理。OpenAI 的 o 系列、Anthropic 的 Claude 3.5 等模型内置了"思考"Token，在模型层实现了 ReAct 的核心逻辑。这意味着开发者不再需要借助 LangChain 等框架在应用层模拟推理——模型自己就能完成。

但这并不意味着编排框架变得可有可无。相反，工程重心从"如何让模型思考"转向了"如何为模型构建安全可靠的执行环境"。工具治理、状态管理、安全策略、可观测性——这些工程问题不会因为模型变聪明而消失。

6.2 多 Agent Swarm 的兴起

"一个 Agent 做所有事"的架构正被"多个专业 Agent 协同"取代。Triage Agent 负责分流，SQL Agent 负责数据库操作，Python Agent 负责数据分析，Browser Agent 负责网页交互——每个 Agent 只持有一小部分工具，能力边界清晰，便于独立测试和部署。

标准化通信协议（A2A、MCP）的成熟使这种架构的落地成本大幅降低。未来的 Agent 系统将更像微服务架构——不再是单体应用，而是由多个自治的服务单元通过标准化协议协作。