Agent 的几种范式：从 ReAct 到 Multi-Agent

「Agent」这个词被用滥了。但不同复杂度的任务，需要的 Agent 范式完全不同。选错范式，要么能力不足，要么成本爆炸。这篇按复杂度从低到高梳理。

1. ReAct：推理 + 行动循环

最经典的范式。模型交替进行 Thought（想）→ Action（调工具）→ Observation（看结果），直到能给出最终答案。适合单步工具调用就能解决的任务。

Thought: 用户问深圳天气，需要查天气工具
Action: get_weather(city="Shenzhen")
Observation: 28°C, 晴
Thought: 已拿到结果，可以回答
Final Answer: 深圳今天 28 度，晴。

2. Plan-and-Execute：先规划再执行

复杂任务别让模型边走边想。先让它生成完整计划（可人工确认），再逐步执行。好处是可控、可中断、可复盘。

3. Reflection：让 Agent 自我纠错

执行完一轮后，让另一个「评审视角」指出问题，再迭代。这是把「一次性输出」变成「带反馈的迭代」，质量提升明显。

4. Multi-Agent：角色分工协作

把大任务拆给多个专职 Agent（规划者、执行者、评审者、记忆管理者），通过消息传递协作。适合需要多视角、长流程的任务，但成本和编排复杂度也最高。

• Planner：拆解目标，生成步骤。
• Worker：调用工具执行单步。
• Critic：检查输出、指出错误。
• Memory：维护长期上下文与状态。

失败处理：Agent 的命门

工具超时、返回异常、陷入死循环——这些才是 Agent 上生产的真实难题。工程上要加：最大步数限制、失败重试、人工介入兜底、以及「卡住时主动求助」。

if step_count > MAX_STEPS:
    return handoff_to_human(trace)  # 主动移交，别让 Agent 空转烧钱

选 Agent 范式的原则：用最简单的那个能解决问题的。Multi-Agent 是奢侈品，不是默认项。