Agent 设计范式指南

多步任务里，Agent 到底该走一步看一步，还是先排计划再动手

写一个能干活的 LLM Agent，并不难：给模型一个工具列表，让它自己决定调什么。真正麻烦的是任务一长，这种"边想边做"的策略就开始暴露问题：可能在某个循环里反复打转，可能做到第十步发现方向早就偏了，也可能因为每一步都要等工具返回而把延迟拉到不可接受。

@user_fa4109f3/agent-frameworks 处理的就是这个问题。它把目前主流的两种 Agent 架构收敛成一套可落地的实现指南，而不是泛泛的概念综述。

两种范式，一套决策依据

ReAct（推理 + 行动）走的是交替循环路线：

• Thought：模型分析当前状态，决定下一步
• Action：模型选择工具并生成参数
• Observation：系统执行动作并回传真实结果
• 把结果塞进上下文，继续下一轮循环

Plan-and-Execute 则拆成两个阶段：先由 Planner 生成结构化的子任务列表，再由 Executor 按序执行，Replanner 在失败时介入重规划。计划内部支持占位符引用，比如 {{2}} 表示"引用第 2 步的结果"，步骤之间可以建立显式依赖。

指南里提供了一个快速选择决策树：任务超过 5 步、或需要全局协调，就倾向 Plan-and-Execute；反之 ReAct 更轻、更快上手。

工程细节都写到了

• ReAct 侧：max_iterations 建议限制在 5–10，实现循环检测，Prompt 里给 Few-Shot 示例
• Plan-and-Execute 侧：计划用 JSON 结构化以便校验，失败步骤重试 2–3 次，无依赖子任务用 asyncio 并行
• 工具设计原则：单一职责、描述清晰、异常要捕获并返回友好错误
• 常见陷阱单独列出：Observation 过长导致 Token 溢出、计划过于僵化无法适应环境变化、未校验计划合理性导致执行失败

适用边界

ReAct 适合实时信息查询、探索性任务和快速原型，不适合超过 10 步的长链条任务。Plan-and-Execute 适合出差安排这类需要全局视野的场景，但在高度动态、需要实时调整的环境里，僵化的初始计划反而会拖后腿。

两种范式各有代价：ReAct 的 Token 消耗和延迟不可忽视，Plan-and-Execute 的多角色 LLM 调用同样会放大开销。指南的价值在于把这些权衡摆到台面上，而不是替你做选择。