从 ReAct 循环到多智能体协作：Agent 工程化的完整落地路径

很多人一听到 Agent 就想到"能聊天的机器人"，但实际上真正能跑起来的 Agent，核心不是聊天，而是把大模型放进一条可控的"感知—决策—行动"链路里，让它自己去调用工具、查资料、做判断、验结果。这篇文章不铺开讲概念史，而是沿着我实际做项目时的完整路径来写：Agent 架构到底怎么拆、单 Agent 和多 Agent 各自怎么落地、记忆与安全这两块最容易被忽视的硬骨头怎么啃。

一、Agent 不是"会聊天的机器人"，而是一条可控的执行链路

先把 Agent 和普通的大模型应用分清楚。你现在调一个 chat API，本质上是"模型根据输入直接生成输出"，它没有行动能力，也没有验证能力。你问它"公司请假制度里超过 5 天需要谁审批"，它只能靠参数记忆里的碎片信息去编，编错了你也不知道。

Agent 不一样。Agent 的标准定义是：用大模型作为"大脑"，配合规划能力、工具调用能力、记忆能力和反思能力，去完成一个多步骤的目标。我们需要把大模型从"一个会说话的接口"升级成"一个会干活的执行者"，这才是 Agent 开发的核心课题。

一个典型的 Agent 系统至少包含五个部分：

• 大模型底座：负责理解任务、生成推理和决策，是"脑"。
• • 规划模块：把大目标拆成小步骤，决定先做什么后做什么。有隐式实现（ReAct 循环里模型自己一步步想）和显式实现（用独立的 Planner 生成任务清单）两种。
• • 工具集：模型不能直接操作外部世界，必须通过工具。工具可以是检索函数、数据库查询、API 调用、计算器、浏览器操作等等。
• • 记忆系统：短期记忆对应上下文窗口，长期记忆存向量库或结构化存储，让 Agent 具备"记得之前做过什么"的能力。
• • 反思与验证：Agent 执行完一步后检查结果是否符合预期，不符合就重试或切换策略。这个环节平时最少被提到，但在生产环境里恰恰最值钱。
    如果只把 Agent 理解成"多轮对话 + 工具"，那很容易做出一个 Demo，但很难做出一条稳定的执行链路。真正的 Agent 工程，核心工作都在"链路控制"上。

二、从 ReAct 循环出发：单 Agent 的最小实现

ReAct（Reasoning + Acting）是当前最有代表性的 Agent 执行范式，它把推理和行动交替进行：模型先思考下一步做什么，然后执行对应动作，观察结果后再继续思考，直到得出结论。

一个最小化的 ReAct 循环可以用几十行代码实现：

def react_loop(task: str, tools: dict, max_steps: int = 10):
    messages = [{"role": "system", "content": SYSTEM_PROMPT},
                    {"role": "user", "content": task}]
                        for _ in range(max_steps):
                                response = llm.chat(messages, tools=tools, tool_choice="auto")
                                        # 模型没有工具调用 → 输出最终答案
                                                if not response.tool_calls:
                                                            return response.content
                                                                    # 执行工具并反馈结果
                                                                            for call in response.tool_calls:
                                                                                        result = tools[call.name](**call.arguments)
                                                                                                    messages.append({"role": "tool", "name": call.name,
                                                                                                                                 "content": str(result)})
                                                                                                                                     return "达到最大步数，任务终止"
                                                                                                                                     ```
这段代码虽然朴素，但它包含了 ReAct 的全部要素：思考（模型决定调哪个工具）、行动（执行工具函数）、观察（把结果反馈给模型继续推理）。实际生产中，你需要在这个骨架之上补充三样东西：**循环上限**（防止模型陷入无限循环烧 token）、**错误捕获**（工具调用抛异常时要反馈给模型而不是让整个链路崩溃）、**结果校验**（最终答案要验证是否真实回答了任务）。

再进一步，就是显式的"计划—执行"（Plan-and-Execute）模式：先让模型把大任务拆成计划清单，再逐项执行。它和 ReAct 的区别是：ReAct 边想边做，适合探索性问题；Plan-and-Execute 先规划再执行，适合步骤明确、关系依赖清晰的长任务。两种模式可以组合：用 Plan-and-Execute 生成骨架，遇到意外情况再降级到 ReAct 式思考。

## 三、单 Agent 的能力上限与多 Agent 的引入时机

单 Agent 能处理很多任务，但它有三个天然上限：

**上限一：上下文窗口。** 所有信息都塞进一个上下文里，任务一复杂，上下文很快爆满。解决方式要么是压缩（摘要、选择性记忆），要么是分工（多个 Agent 各管一段）。

**上限二：角色冲突。** 同一个模型既要当"创意者"又要当"评审者"，两种思维方式互相干扰。把这两类角色拆成两个 Agent，各自用不同的系统提示词，效果往往显著更好。

**上限三：并行效率。** 单 Agent 只能串行思考，而很多任务存在相互独立的子问题，并行探索能节省大量时间。

什么时候该从单 Agent 升级到多 Agent？我的判断标准是：**当单 Agent 的上下文开始成为瓶颈，或者任务可以自然拆成多个独立角色时**。比如竞品分析任务——信息检索、数据提取、可视化生成、报告编排四个环节，用一个 Agent 串行做要手动搬运中间结果，拆成四个 Agent 分工协作就顺理成章了。

## 四、多 Agent 协作的三种架构模式

多 Agent 不是简单地把几个 Agent 堆在一起，架构模式决定了协作的效率和可控性。目前生产环境里最常用的有三种：

**模式一：Supervisor（主管—下属）模式。** 一个主管 Agent 负责拆解任务、分派给下属 Agent、汇总结果。这是最可控的模式，适合"任务可拆分成明确子任务"的场景。主管 Agent 是流程的核心，下属 Agent 各司其职。它的优点是职责清晰、易于监控；缺点是主管容易成为瓶颈，且所有信息都要经过主管汇聚。

**模式二：Peer-to-Peer（对等协商）模式。** 多个 Agent 地位平等，通过消息对话协作推进任务，像一支团队在开会。适合开放式的讨论型任务——比如多个角色协同审查方案。优点是灵活、能激发"讨论出真知"的效果；缺点是执行结果不可预测，需要设定收敛条件（最大轮次、共识判定规则），否则 Agent 会陷入无限讨论。

**模式三：Hierarchical（层级递归）模式。** 主管 Agent 下面还有子团队，每个子团队内部有自己的协作结构。这是前两种模式的组合，适合超大规模任务。代价是系统复杂度急剧上升，调试难度按指数增长——我在实践中通常建议：能两层解决的不要做三层。

选模式的另一个实用建议：**优先用"任务分解"而不是"自由讨论"**。自由讨论的多 Agent 系统很炫酷，但生产环境里 token 成本高、结果不稳定；任务分解式协作每个环节的输入输出都可控、可审计。先用 Supervisor 模式跑通，再根据业务需要引入讨论式环节。

## 五、记忆与安全：两块最容易被忽视的硬骨头

多 Agent 系统里，记忆问题比单 Agent 严重一个数量级：每个子 Agent 都有自己的上下文，信息在 Agent 之间传递时容易丢失或失真。三个实用方案：

**方案一：共享黑板（Blackboard）。** 所有 Agent 读写同一个共享状态对象，关键中间结果沉淀在"黑板"上，避免信息只在消息流里短暂存在。LangGraph 的 State 对象就是这种设计的体现。

**方案二：结果摘要化。** 子 Agent 的完整输出往往很长，传递时先让下游 Agent 对上游输出做摘要，只传精华。这一步能大幅节省 token，也防止无关细节污染下游判断。

**方案三：记忆分级。** 会话级记忆（当前任务的中间状态）、项目级记忆（任务间共享的背景知识）、组织级记忆（长期沉淀的业务知识），按生命周期分级存储，防止短期噪音污染长期记忆。

安全方面，多 Agent 放大了单 Agent 的风险——工具权限、数据访问、内容合规都要重新评估。三条底线原则：**最小权限**（每个 Agent 只拿到完成任务必需的权限）、**人工闸门**（有副作用的操作——写入、删除、付款、发消息——必须经过审批节点）、**全链路审计**（每个 Agent 的输入输出、工具调用都记录日志）。特别是最后一条，没有审计日志的多 Agent 系统，出了事故连定位都做不到。

## 六、一条可复制的落地路径

最后，把上面的内容浓缩成一条可复制的落地路径，供你直接照做：

第一步，从最小 ReAct 单 Agent 起步，跑通"规划—工具—验证"循环，先不要引入框架；
第二步，给单 Agent 补上循环上限、错误捕获、结果校验三件套，让它稳定可靠；
第三步，当上下文成为瓶颈或角色冲突明显时，引入 Supervisor 模式的简单多 Agent，主管拆任务、下属干活；
第四步，用共享黑板 + 结果摘要解决多 Agent 的信息传递问题，用最小权限 + 人工闸门 + 审计日志解决安全问题；
第五步，系统稳定后，再评估是否需要升级到 LangGraph 这类重型框架来提升可观测性和状态管理能力。

这套路径的核心思路是：**从小做起，按需升级**。不要第一天就上多 Agent + 重型框架，那只会让你陷入调试的泥潭。先把链路控制做到位，把执行可靠性提上来，Agent 系统才能真正从"演示品"变成"生产力工具"。