除了re-act和plan-and-execute 外还有没有可用的设计范式

有，而且实际做项目，不必只在 ReAct 和 Plan-and-Execute 之间选。比如客服退款：识别诉求 → 查订单 → 校验退款规则 → 用户确认 → 执行退款，通常更适合受控工作流，而不是让 Agent 自由决定所有步骤。 先区分一下层次：ReAct 更偏“执行过程中怎么根据反馈决定下一步”；Plan-and-Execute 更偏“先拆任务，再执行”。下面这些涉及流程组织、任务分配和质量控制，能与前两者组合，不是互斥选项。 一、Prompt Chaining：固定步骤串联 例子：面试录音 → 转写 → 提取问答 → 按主题分类 → 生成复盘。 路径由代码提前定义，每一步只完成一个较小任务，中间加校验：转写为空就停止，问答缺少上下文就标记待复核。 适合步骤稳定、输入输出容易定义的业务。相比动态规划，更容易调试和评估；缺点是遇到流程外的问题不够灵活。 二、Routing：按请求分流 例子：客服收到问题后，订单问题走订单查询，产品问题走知识库，投诉走人工处理。 重点是先分类，再交给专门的处理流程，而不是把所有工具和规则都塞进同一个提示词。分类可以用规则、模型，或两者结合。 适合业务类型差异明显的系统。需要考虑分错怎么办：低置信度时追问，或进入兜底流程。单纯分流到几个处理器，不必叫多 Agent。 三、Parallelization：并行处理后汇总 例子：审查一段代码，同时检查安全风险、性能问题和可维护性，最后汇总结果。 也可以让多个独立调用处理同一问题，再比较结果，但“多数同意”不代表一定正确，尤其模型可能犯相同的错。 适合子任务互不依赖的场景。优势是降低串行等待时间；代价是更多调用，以及结果去重、冲突处理的复杂度。 四、Orchestrator–Workers：动态分工 例子：修改一个跨模块功能，协调者先检查项目，再决定分出“接口修改”“数据库迁移”“测试补充”等任务，交给不同 worker，收集结果后协调后续修改。 与固定并行的区别是：任务数量和内容不是提前写死的，而是运行时决定。 适合任务范围不确定、又确实可以拆分的工作。它与 Plan-and-Execute 有重叠，侧重点是“如何委派与协调”；worker 内部仍然可以用 ReAct。工程上要处理上下文交接、依赖和修改冲突，不能只开几个窗口就算完成编排。 五、Evaluator–Optimizer：生成、评估、修改闭环 例子：Agent 写代码 → 运行测试和静态检查 → 把失败信息交回 Agent → 修改 → 再验证。 它与“再想一遍”不同，关键是有明确评价标准和有效反馈。代码测试、格式校验、引用是否支持结论，都比一句“请检查答案是否正确”更可操作。 适合结果可验证、值得花额外成本提升质量的任务。要设置最大轮数、预算和退出条件，避免一直改却没有改善；纯模型自评不能当作正确性保证。 六、状态机／受控图工作流 例子：退款流程分为“待核验、待确认、执行中、已完成、失败待处理”，只有满足条件才能进入下一状态。 LLM 可以识别用户意图、提取参数，但退款权限、金额限制和状态转换由业务代码控制。需要探索信息的局部节点，也可以嵌入 ReAct。 适合涉及支付、审批、写数据库等需要严格约束的业务。落地重点是持久化状态、失败恢复、幂等和人工确认，不是提示词写得多复杂。 怎么选？ 步骤固定，用串联；请求类型多，用路由；子任务独立，用并行；任务需要现场拆分，用协调者与 worker；结果有明确评价标准，用评估改进闭环；操作有严格业务约束，用状态机。 我的建议是：先把确定的部分写成工作流，只把真正不确定的部分交给 Agent。通常比从头到尾全自主更容易上线。 前五类可参考 Anthropic 的经典工程文章，发表于 2024 年，属于基础模式总结，不是最新框架排名： https://www.anthropic.com/engineering/building-effective-agents