---
title: "别再死磕 Prompt 了，高手都在设计循环：7 种 Agent 架构 + Loop Engineering 中文主流视角"
source_url: https://mp.weixin.qq.com/s/d-bV-dxEEl6PHL1b-S8_DQ
source: 前端Q (winty 原创)
author: winty
ingested: 2026-06-18
sha256: ff1a4b256ef7b579842c19bcd995e1ac359f1bfb7f139000745dbdab13705508
publisher: 前端Q (winty)
type: raw-article
tags: [loop-engineering, agent-architecture, react, planning, multi-agent, blackboard, router-skill, graph-workflow, winty, chinese-mainstream, harness, prompt-engineering, cost-control, langgraph, temporal]
---

# 原文：别再死磕 Prompt 了，高手都在设计循环

> 作者：winty（前端Q，2026年6月18日 12:27）
> URL：https://mp.weixin.qq.com/s/d-bV-dxEEl6PHL1b-S8_DQ

## 核心立论

最近跟几个做 AI 产品的朋友聊天，发现大家卡的点惊人地一致：模型选好了、Prompt 也调了，但一上真实业务就翻车——要么 Agent 跑着跑着死循环，要么多个 Agent 互相甩锅，要么流程长一点就完全失控。

聊到最后我发现，问题基本都不在模型，而在**架构**。说白了，同样一个 GPT，你把它塞进什么样的"骨架"里，决定了它是个能用的产品还是个 Demo 玩具。

正好刷到一张把 Agent 架构归纳成 7 种的图，整理得挺到位。我把它彻底拆开，结合最近很火的 **loop engineering（循环工程）** 这个概念，一种一种讲清楚：每种架构到底是怎么运转的、适合什么场景、坑在哪。

读完你应该能回答一个问题：**我手头这个需求，到底该用哪种 Agent 架构？**

## 7 种 Agent 架构：演进路径而非选项

**核心论断**：这 7 种架构不是 7 个并列的选项，让你挑一个最强的用。它更像是一条从简单到复杂的演进路径。

- **左边（单 Agent、ReAct）**：一个人干活，灵活、便宜、上手快
- **中间（Plan & Execute、多 Agent）**：开始分工，能扛复杂任务，但协调成本上来了
- **右边（Router、Blackboard、Graph）**：变成系统，追求稳定、可控、可观测，是企业级生产环境的主流

**关键提醒**：别一上来就奔着最右边的"最强架构"去。杀鸡用牛刀，不光浪费钱，还把简单问题搞复杂了。

## 架构 1：单 Agent

**一句话**：一个 LLM，配上几个工具，问一句答一句，一步到位。

**核心三块**：一个大模型负责决策、几个 tools 让它能查数据库 / 调 API、再加一点 memory 记住对话上下文。

**适用场景**：ChatGPT/Copilot 通用对话、单步任务（查天气、翻译）、对响应速度敏感场景。

**天花板**：一旦任务需要"多步推理"或"中间结果要拿来决定下一步"，单 Agent 就吃力了。它没有一个反复思考的循环机制，上下文一长就容易顾此失彼。

## 架构 2：ReAct —— 边想边做

**一句话**：让 LLM 把"想"和"做"交替进行，走一步看一步，直到搞定。

**ReAct = Reasoning + Acting**（2022 普林斯顿论文），给单 Agent 加了一个关键东西：**一个反复转的循环**。

**核心三步循环**：
1. **Thought（思考）**：分析现在的情况，决定下一步干啥
2. **Action（行动）**：调用某个工具去执行
3. **Observation（观察）**：看看工具返回了什么

**例子**：用户问"北京和东京今天哪个更热"——Agent 先想"得分别查两个城市"，查北京（25°C），再想"接着查东京"，查到东京（31°C），最后想"够了，东京更热"。每一步都基于上一步的结果来决策。

**底层实现**：本质就是个 `while` 循环——问 LLM 下一步干啥 → 要用工具就执行 → 把结果喂回去 → 再问。聪明的部分全在 LLM 自己。

**适用场景**：探索性任务、复杂问答、目前 **90% 的生产级 Agent 都默认用它做内核**。

**最大坑：死循环**。Agent 反复调同一个工具、得到同样的结果、但就是不停。解法：让工具返回清晰简洁的文本、给 Agent 兜底策略、一定要设 `maxIterations`（一般 5~10 次）。

## 架构 3：Plan & Execute —— 先列计划再照着做

**一句话**：先让一个"规划器"把整件事拆成步骤清单，再让"执行器"照着清单一步步做。

**两个角色**：
- **Planner（规划器）**：先通盘看一遍任务，输出一个明确的步骤清单
- **Executor（执行器）**：拿着这份清单，一步一步执行，做完一个勾一个

**比喻**：ReAct 是"边住边改"，想到哪改到哪；Plan & Execute 是"先出设计图，再按图施工"。

**适用场景**：步骤多且有依赖关系的复杂任务、代码生成、长流程数据处理、需要"先有全局规划"才不容易跑偏的任务。

**软肋**：成也规划，败也规划。如果 Planner 一开始就把计划列错了，后面执行得再认真也是错的。**实践中常见做法**：Plan & Execute 套个 ReAct——大方向按计划走，每一步内部再用 ReAct 灵活处理。

## 架构 4：多 Agent —— 让一群专家分工协作

**一句话**：不再靠一个全能选手硬扛，而是拆成多个专家 Agent，各管一摊，由一个编排者统一调度。

**经典结构**：一个 Orchestrator（编排者）在上面分活，下面挂着一堆专家 Agent：
- Planner Agent：负责拆解任务
- Coder Agent：负责写代码
- Reviewer Agent：负责审查质量
- Tool Agent：负责调各种外部工具

每个 Agent 有自己独立的"上下文窗口"和专属的 system prompt，相当于一个只懂自己那行的专家。最大好处：专业度高 + 避免单个 Agent 上下文被塞爆（对付"上下文腐烂/context rot"）。

**适用场景**：任务能清晰拆分成几个相对独立的子任务、团队协作型工作流、企业级需要专业分工的系统。

**坑很现实（多 Agent 是放大器不是默认选项）**：
- **通信成本高**：Agent 之间反复交接、汇报，token 消耗能比单 Agent 多出近一倍
- **协调容易出问题**：**有研究审计了 7 个主流多 Agent 框架的 1600 多条执行轨迹，失败率在 41% 到 86.7% 之间**。最常见的失败：没按任务要求做、角色搞混了、活还没干完就宣布成功

**作者建议**：先用单个循环跑通，确实自己搞不定了再加一个审查角色，实在要并行处理多条任务了再上编排者。别一上来就堆一堆 Agent。

## 架构 5：Router + Skill（⭐ 性价比最高）

**一句话**：不用复杂模型，就用一个"意图路由器"判断用户想干嘛，然后转给对应的技能模块处理。

**逻辑**：
1. 用户问题进来，先过一个 Intent Router（意图识别），判断"这属于哪一类需求"
2. 根据分类，把请求转给对应的 Skill（技能模块）去处理

**比喻**：公司前台——你说要办什么事，前台不自己处理，而是告诉你"财务在 3 楼、人事在 5 楼"，直接把你导到对的部门。

**与多 Agent 的核心区别**：多 Agent 是"模型在选"，Router 是"规则/轻量分类在选"。所以它更轻、更快、更省钱，新增能力也简单——再挂一个 Skill 就行。

**适用场景**：Copilot、AI Coding 工具（不同指令路由到不同能力）、知识库问答系统（按问题类型路由到不同知识域）、需要不断扩展能力又控制成本的产品。

**优点**：轻量、可扩展、低成本。技能模块之间互相独立，加一个、改一个都不影响别的。

## 架构 6：Blackboard —— 共享黑板

**一句话**：多个 Agent 不直接对话，而是都往一块共享的"黑板"上读写信息，靠这块黑板间接协作。

**想象**：会议室墙上挂着一块大白板。每个专家（Agent）进来后：
- 看一眼白板上现在有什么信息
- 如果自己能基于这些信息做点贡献，就把结果写上去
- 写完接着看别人有没有补充

整个协作过程不靠"谁命令谁"，而靠这块共享状态（黑板）来驱动。

**与多 Agent 的关键区别（耦合度）**：多 Agent 往往是编排者点名指派，Agent 之间有明确的调用关系；Blackboard 是松耦合的——Agent 之间不直接认识对方，只认黑板。

**适用场景**：复杂协作场景、参与方多且谁该出手不好提前定死、需要共享中间状态多方逐步推进的任务。

**代价**：灵活的另一面是不好预测、不好调试。因为没有明确的控制流，出了问题你得回看黑板的整个读写历史才知道哪一步出了岔子。**工业界用得不如 Graph 普遍**。

## 架构 7：Graph / Workflow —— 企业级主流

**一句话**：把整个流程建模成一张有向图（DAG），每个节点是一步操作，节点之间用边连起来，可视化、可回溯、可重试。

**核心思想**：把 Agent 的执行流程从"模型临场发挥"变成"按图施工"。
- 每个**节点（Node）** 是一步明确的操作（可以是一个 Agent、一次工具调用、一个判断）
- 节点之间用**边（Edge）** 连接，规定了流转关系
- 整张图是 DAG（有向无环图），流程清清楚楚画在那

**代表工具**：LangGraph、Temporal、Airflow、Prefect。

**vs Plan & Execute**：Plan & Execute 的计划是临时生成的，Graph 的流程是预先设计固定下来的骨架，Agent 只在节点内部发挥。

**为什么企业爱它**：
- **可视化**：整个流程画成图，一眼看懂哪一步在干嘛
- **可回溯**：哪一步出错了，能精确定位、甚至从那一步重跑
- **可控**：流程是固定的，不会因为模型"突发奇想"而失控

**适用场景**：企业级需要长期稳定运行的生产系统、流程相对固定对可靠性和可观测性要求高的业务、需要重试/回滚/人工介入等"工程级"能力的场景。

**代价**：灵活性最低。流程写死在图里，需求一变就得改图。**适合"流程相对稳定"的成熟业务，不适合还在快速探索、天天改需求的早期阶段**。

## 7 种架构的本质：都在"设计循环"

**串起来的线**：loop engineering（循环工程）。

**2026 年 6 月，前端圈很熟的 Addy Osmani，加上 Claude Code 的作者 Boris Cherny 等人，把这个概念彻底带火了**。Boris 有句话特别戳：

> "我现在已经不亲自给 Claude 写提示了。我有一堆循环在跑，是它们在提示 Claude、在决定下一步做什么。我的工作就是写这些循环。"

**三层楼演进（看图左边）**：
- **1 层：Prompt 工程**——你亲自写好每一句提问。你是引擎，离开键盘 Agent 就停了
- **2 层：Harness 工程**——你设计单个 Agent 运行的环境：给它什么工具、什么权限、什么上下文
- **3 层：Loop 工程**——你设计一个系统，由这个系统去提示 Agent、检查结果、决定要不要再来一轮

**关键洞察**：所有循环的内核都是同一个四步——**行动 → 观察 → 推理 → 重复**。这就是 ReAct！

- **ReAct 是"内循环"（inner loop）**——模型每一步在想什么、做什么
- **loop engineering 关心的是"外循环"（outer loop）**——什么时候启动、跑几轮、什么条件下停、状态存在哪、出错了怎么续上

7 种架构本质都是回答"外循环怎么设计"：
- 单 Agent：几乎没有外循环
- ReAct：最朴素的外循环（while 转到模型说"够了"）
- Plan & Execute：先规划，再循环执行每一步
- 多 Agent：把循环拆给多个角色，编排者管总循环
- Router + Skill：在循环入口先做一次路由
- Blackboard：靠共享状态驱动循环
- Graph / Workflow：把整个外循环画成一张固定的图

**为什么 loop engineering 现在才火？** 因为业界终于想明白了一件事：**长任务不能全靠模型记在脑子里**。模型上下文一长就会"中间记忆塌陷"（lost in the middle）、性能下降（context rot）。所以靠谱的做法是——把状态从模型脑子里挪到外面：进度写进 `progress.txt`、需求写进 `prd.json`、真相留在 git 里。每一轮让模型读一遍文件、干一件事、跑一遍测试、提交一次。哪怕模型这轮"失忆"了，系统的状态还在。

这其实就是把架构 7（Graph/Workflow）那套"可回溯、可重试"的工程思想，推到了极致。

**loop engineering 的要命之处**：**循环最难的不是让它跑起来，而是让它停下来**。网上已经有一堆人晒账单——一个没设上限的循环，一夜之间烧掉几百美元。所以任何循环都得配三道硬闸：**迭代次数上限、"没进展就停"的检查、花费上限（token 或美元）**。这三样缺一个，你跑的就不是循环，是一张无限额账单。

这和 ReAct 里那个"必须设 maxIterations"的坑，是**同一个问题在更大尺度上的重演**。架构的演进，本质上就是人类一步步学会怎么驯服这个循环。

## 选型对号入座表

| 你的情况 | 推荐架构 | 为什么 |
|---------|---------|--------|
| 单步就能答、要快 | 单 Agent | 简单、便宜、低延迟 |
| 要多步推理、走一步看一步 | ReAct | 灵活通用，生产级默认内核 |
| 步骤多且有依赖、怕跑偏 | Plan & Execute | 先有全局计划，不容易迷路 |
| 任务能拆成几个专业子任务 | 多 Agent | 专业分工，但记得控制成本 |
| 要不断扩能力、又想省钱 | Router + Skill | 轻量、可扩展、低成本 |
| 多方灵活协作、共享中间状态 | Blackboard | 松耦合，加减模块不影响别人 |
| 企业级、要稳定可控可观测 | Graph / Workflow | 可视化、可回溯、可重试 |
| 长任务、要 AI 自己跑很久 | Graph + Loop 工程 | 状态外置，配好停机闸 |

**作者三条经验**：
1. **从左往右选，能用简单的就别上复杂的**。大部分需求一个 ReAct 或 Router + Skill 就够了
2. **复杂度是有成本的**。多 Agent、Graph 这些不是"更高级所以更好"，而是用工程复杂度换稳定性，只在真正需要时上
3. **越往长任务走，越要把"状态"和"停机条件"当成一等公民**

## 收尾：架构演进是"驯服 AI 循环"的历史

> 研究完这一圈，我最大的感受是：Agent 架构的演进史，其实是一部"人类如何学会信任又约束 AI 循环"的历史。
>
> 最早我们不敢让它循环，所以有了单 Agent（问一句答一句）。后来发现循环很强，于是有了 ReAct。再后来发现循环会失控、会跑偏、会烧钱，于是一路加规划、加分工、加路由、加共享状态、加固定流程图——每一种新架构，都是在给这个循环加一道新的护栏。
>
> 到了 loop engineering 这一层，我们终于不再纠结"要不要让它循环"，而是大方承认"循环就是产品本身"，然后把全部精力放在怎么把循环设计好、验证好、停得住上。
>
> 所以如果你问我前端/全栈同学该从哪入手，我的建议是：**别一上来研究最复杂的 Graph 架构，先把 ReAct 这个内循环吃透**——它是所有架构的地基。理解了"行动→观察→推理→重复"这个最小单元，再往上看任何一种架构，你都会有种"哦，原来它只是在循环外面又包了一层"的通透感。
>
> 毕竟正如那句被反复引用的话所说：**模型只会越来越强，到时候真正卡住产出的，不是模型，而是设计循环那个人的判断力**。