为什么“模式”比“框架”更重要
框架会换，模式不会。你掌握模式后，LangGraph/AutoGen/CrewAI 只是实现细节。
一个好的编排模式要解决：
- 多步决策怎么产生（planning）
- 工具怎么调用（tool use）
- 失败怎么处理（retry/fallback/human-in-the-loop）
- 状态怎么保存（state/memory）
模式 1：Planner-Executor（计划-执行）
适合：目标明确但步骤可能变化的任务，例如排障、调研、生成报告。
最小流程：
- Planner：产出步骤列表（带依赖与停止条件）
- Executor：逐步执行，每步工具调用/生成都可观测
伪代码：
plan = planner(input)
for step in plan:
result = execute(step)
if result.failed:
plan = replan(plan, result)
工程建议：
- 每步都落盘 state（方便恢复）
- plan 有预算（最多 N 步、最多调用次数）
模式 2：ReAct（推理-行动-观察循环）
适合：需要边看边做、不断获取证据的任务。
关键是“观察”必须来自工具真实输出，而不是模型想象。
伪代码：
while not done:
thought = model.think(state)
action = model.propose_tool_call(state)
observation = tools.execute(action)
state = update(state, observation)
工程建议：
- 记录每次 action 与 observation（可审计）
- 设定停止条件（避免无限循环）
模式 3：Router（路由/分流）
适合：你有多个子 Skill，输入不同就走不同路径。
典型例子：
- 代码问题 -> 走 code review skill
- 数据问题 -> 走 sql skill
- 运维问题 -> 走 logs skill
工程建议：
- Router 也要可评测（路由准确率）
- 允许“兜底路径”（unknown -> human/ask-clarify）
模式 4：Graph（有向图编排）
适合：复杂工作流、多分支、多回路、可视化、可维护。
Graph 的价值在于：
- 状态显式
- 节点可替换
- 路径可测试
工程建议：
- 节点输入输出契约固定（像函数一样）
- 图结构可版本化（变更可审计）
动手做：把工作流写成“节点契约”
无论你用什么框架，建议把每个节点写成：
- name
- input schema
- output schema
- failure types
- side effects（是否写外部系统）
这会显著降低后续维护成本。
工程化清单
- 明确停止条件与预算（步数、成本、时间）
- 每步 state 可恢复，可回放
- 工具调用与观察可审计
- 路由/图结构可评测、可版本化
常见坑
- “没有停止条件”的 ReAct：最终变成死循环
- Router 只靠直觉：没有路由回归集
- Graph 节点无契约：图越大越难维护
下一篇：记忆与上下文管理：长期记忆不是把所有东西都塞进去。