Agent设计模式与热门框架

Agent 设计模式与热门框架（2026）

本篇讲两个"怎么选"的问题：① 用哪些设计模式来搭 Agent；② 用哪个框架落地。

一、总纲：Workflow 还是 Agent？

Anthropic 的经典文章 Building Effective Agents 提出最重要的设计判断：

不要把简单的事做成 Agent。

Workflow（工作流） Agent（代理）
控制流 代码决定（固定路径） LLM 决定（动态路径）
适合 任务步骤明确、可预测 步骤未知、需要探索
例子 固定三步：转写→总结→翻译 重构一个陌生代码库
调试 容易（确定性） 难（LLM 行为不确定）
成本 低 高（多轮循环）

经验法则：先 Workflow，再 Agent。能用固定流程解决的，就别上 Agent——
Agent 的灵活性是用延迟、成本、不可预测性换来的。

二、六大核心设计模式

按"LLM 对流程的控制程度"从低到高排列：

LLM 控制少 ←──────────────────────────────→ LLM 控制多
Workflow 模式                           Agent 模式
提示链 → 路由 → 并行 → 评估-优化 → 编排者-工人 → ReAct 循环

1. 提示链（Prompt Chaining）— 最常用

每一步的输出喂给下一步，串成固定流水线。

用户输入 → 生成大纲 → 写初稿 → 润色 → 输出

适合：任务可分解为固定顺序的子任务。
优点：每步职责单一，提示词简洁，容易逐段调试。
缺点：任何一步失败，整条链失败；延迟累加。

2. 路由（Routing）— 分类派发

先用一次 LLM 调用（或规则）把请求分类，再交给专用处理器。

用户输入 → 分类器 → ① 代码问题 → 代码专家
                  → ② 数学问题 → 计算器
                  → ③ 闲聊     → 通用对话

适合：输入类型差异大的场景（客服、多领域助手）。
优点：每个分支的提示词可以高度专用化。

3. 并行化（Parallelization）

把独立子任务同时跑，最后合并结果。

任务 → 扇出 ──▶ 摘要器A ──┐
          ──▶ 摘要器B ──┼──▶ 合并 → 输出
          ──▶ 摘要器C ──┘

适合：大任务可拆分为互不依赖的小任务。
注意：不是所有任务都可并行——共享状态的任务要考虑复制或分批。

4. 评估-优化（Evaluator-Optimizer）— 自检循环

一个生成器 + 一个评估器，循环直到输出达标。

生成器 → 输出 → 评估器 → 通过？→ 输出
   ↑                    │否
   └────── 反馈意见 ◀────┘

适合：写作、代码生成这类"质量可评判"的任务。与 ReAct 的区别：
评估器只评判质量，不执行外部动作。

5. 编排者-工人（Orchestrator-Workers）— 动态拆解

一个编排者动态分解任务，动态生成工人处理，再汇总。

                        ┌─ 工人1（搜索）
编排者 ── 分解任务 ──▶  ├─ 工人2（读代码）
    ▲                   └─ 工人3（跑测试）
    └──────── 汇总结果 ◀──┘

适合：无法预先确定子任务数量和类型的复杂任务。
这就是Claude Code 子代理（subagents）的模式：
主代理是编排者，explore / oracle 等子代理是工人。

6. ReAct（Reason + Act）— Agent 的核心

完整循环：思考（Reason）→ 行动（Act）→ 观察（Observe）→ 重复。

Thought: 我需要先看看项目结构
Action: list_dir(path=".")
Observation: [文件列表]
Thought: 找到了 main.py，读它
Action: read_file(path="main.py")
Observation: <文件内容>
Thought: 现在我可以改代码了……
Action: write_file(...)
...直到 Observation 不再需要行动，输出 Final Answer

这是现代 Agent 的事实标准（2022 年 Yao et al. 提出）。特别说明：

  • Auditable（可审计）：每一步"想了什么、调了什么工具、看到什么结果"都被记录，
    是天然的可观测性。
  • 风险：LLM 可能陷入"同一个工具调用 → 同一个结果 → 再调用"的死循环，
    必须有 max_steps 兜底。
  • 现代实现：早期 ReAct 靠解析文本格式（Action: tool\nAction Input: {...}），
    现在直接用 API 的 function calling，模型原生输出结构化 tool_calls，不需要解析。

模式对比速查

模式 工具访问 延迟 可解释性 最佳场景
提示链 无 低 高 固定流水线
路由 按分支 低 高 输入类型多样
并行化 有 中 中 独立子任务
评估-优化 无 高 中 质量优先于速度
编排者-工人 有 高 中 动态拆解大任务
ReAct 有 中 极高 绝大多数 Agent 任务

三、Plan-and-Execute：ReAct 的变体

先让 LLM 一次性制定完整计划，再逐步执行（执行时也可重新规划）。

计划：1. 调研需求 2. 设计接口 3. 实现 4. 测试 5. 文档
执行：逐条执行，遇到问题时 重新规划 回到计划列表

对比 ReAct：ReAct 走一步看一步，灵活但可能走偏；Plan-and-Execute 全局规划，
对长任务更稳，但环境变化时需要显式再规划。生产级 Agent 常两者结合：
先计划，执行中随时 ReAct 微调。

四、热门框架全景（2026 年中调研）

数据来源：GitHub 星星/下载量、Langfuse 框架对比报告、各家官方文档（2026 年核实）。

框架速查表

框架 心智模型 生产成熟度 模型绑定 适合场景
LangGraph 有状态图（State Graph） ★★★★★ 无关 复杂有状态工作流、生产系统
CrewAI 角色扮演团队 ★★★☆ 无关 快速原型、多代理演示
OpenAI Agents SDK Agent 循环 + 交接(handoff) ★★★★ OpenAI 系 快速上手、OpenAI 生态
Claude Agent SDK 工具丰富的 Agent 循环 ★★★★ Anthropic 系 编码 Agent、复用 Claude Code 运行时
AutoGen / Agent Framework 多代理对话 ★★☆ 无关 研究（已转维护模式）
Google ADK 多代理编排 ★★★ 谷歌系 Google 生态

逐个说

1. LangGraph —— 生产默认

  • 心智模型：把 Agent 画成状态图——节点(nodes) + 边(edges) + 共享状态(state)，
    条件边决定分支循环，检查点(checkpoint)支持持久化与"时间旅行"调试。
  • 数据：月下载 3450 万（是 OpenAI SDK 的 3.3 倍），生产用户包括 Klarna、Replit、
    Uber、LinkedIn、Cisco、BlackRock。
  • 优点：可控性最强、可观测性最好（LangSmith）、模型无关、状态可持久化。
  • 缺点：学习曲线陡，简单任务用它是杀鸡用牛刀。
  • LangChain 生态已经把 ReAct、并行化、编排者-工人 全部实现为可复用组件。

2. CrewAI —— 原型最快

  • 心智模型：定义"团队"——每个 Agent 有角色（role）、目标（goal）、背景故事，
    协作方式像公司开会（顺序或层级多代理对话）。
  • 数据：5.2 万+ 星。
  • 优点：20 分钟出第一个多代理 demo，心智模型最直观。
  • 缺点：生产可观测性仍在追赶，复杂可控性不如 LangGraph。
  • 常见路径：CrewAI 先原型验证 → 生产迁移 LangGraph。

3. OpenAI Agents SDK —— OpenAI 系最快

  • 心智模型：Agent + Runner，多代理通过 handoff（交接棒） 协作——
    一个 Agent 把任务转交给另一个更专业的 Agent，整体像一个调用链。
  • 优点：OpenAI 生态零摩擦、内置 tracing 与 guardrails、原生 MCP 支持。
  • 缺点：设计上绑定 OpenAI（可用 LiteLLM 换模型但会失去大部分 SDK 价值）；
    无内置持久状态。
from agents import Agent, Runner

manager = Agent(name="Manager", handoffs=[coder, reviewer])
result = Runner.run_sync(manager, "实现登录功能并让 reviewer 审查")

4. Claude Agent SDK —— 编码 Agent 的事实标准运行时

  • 心智模型：直接打包 Claude Code 运行时——同一个 Agent Loop、同一套内置工具
    （Read/Write/Edit/Bash/Glob/Grep/WebFetch/Task 等 20+）、同一套权限系统。
  • 你可以程序化控制工具集（allowed_tools / disallowed_tools）、审批模式、
    成本限制，还能 via MCP 在进程内挂自定义工具。
  • 对想学 Agent 的人，这是最值得研究的开源运行时——oh-my-opencode 就是在
    这个心智模型上做的自己的开源实现。
  • 子代理（Subagents）是其核心卖点：独立上下文窗口 + 受限工具 + 并行执行。

5. AutoGen —— 注意迁移

  • 微软研究院出身，多代理对话（群聊）心智模型，研究界用户多。
  • 2026 状态：已进入维护模式（maintenance mode），微软转向新的
    Microsoft Agent Framework。新项目不建议从这里起步。

选型决策树

你的需求是？
├─ 复杂有状态工作流 + 要生产级 → LangGraph
├─ 快速做多代理 demo / 验证想法 → CrewAI
├─ 深度绑定 OpenAI 生态 → OpenAI Agents SDK
├─ 做编码类 Agent / 研究编码运行时 → Claude Agent SDK（或直接看开源实现）
├─ 嵌进 JS/TS 项目 → Vercel AI SDK / Mastra
└─ 先学原理、不依赖任何框架 → 手写一个（下一篇就做这个）

为什么不直接推荐某个框架学习？框架天天变，Agent 的骨架——循环、工具、上下文、
权限——五年不变化。 先手写一个最小的，你再看任何框架都像看老朋友。

五、给初学者的四条建议

  1. 先别碰框架，手写一个最小 Agent（下一篇的 demo，~250 行零依赖）。
    骨架收益足够你理解 90% 的框架文档。
  2. 从单个 Agent + 工具开始，多代理是后期的优化手段，不是起点。
  3. 给一切加预算：max_steps、token 上限、工具超时。LLM 的"失控"不是 bug，
    是常态。
  4. 工具设计比提示词重要：工具的描述、参数 schema 直接影响 LLM 调用质量。
    一个好工具 = 明确的名字 + 清晰的描述 + 正确的参数。
posted @ 2026-09-11 22:58  LemHou  阅读(31)  评论(0)    收藏  举报