AI Agent 模式：先把边界、状态和评估目标讲清楚，再谈 ReAct 与 Planning
谈 Agent 模式最容易变成 ReAct、Reflexion、Planning 的概念列表，但真正影响工程落地的，是每种模式需要什么状态、工具边界和评估目标。
01.Agent 模式最容易被误写成“几个高级名词的合集”
很多关于 Agent 模式的文章，常见写法是列几个术语：
- •ReAct
- •Reflexion
- •Planning
- •Multi-agent
这些名字本身没有问题，但如果只停留在术语层，它们对工程落地的帮助其实很有限。真实团队更需要知道的是：
- •这个模式适合哪类任务
- •需要哪些状态和工具边界
- •会带来什么新的复杂度
- •应该用什么指标评估它值不值得上
所以 Agent 模式更适合被理解成“任务编排策略”，而不是几种看起来更聪明的思考姿势。
02.先问任务复杂度，再选模式
一个很常见的误区，是一开始就想上最复杂的 Agent 模式。更稳妥的顺序通常是：
- •先看是不是普通检索问答就够了
- •再看是否真的需要工具调用
- •再决定要不要上计划执行
- •最后才考虑多 Agent 协作
很多系统其实不需要“更强模式”，只是需要更清楚的边界和更稳定的输入。
03.一条更实用的模式谱系，通常从四层开始
1. 直接回答模式
适合：
- •问答简单
- •不涉及外部动作
- •不需要长状态
它的优点是简单、快、成本低；缺点是上限明显。
2. 检索与工具路由模式
适合：
- •需要引用知识库
- •需要调用少量受限工具
- •需要结构化输出
这通常是很多“AI 应用”真正的第一代稳定形态。
3. 计划执行模式
适合：
- •任务需要多步完成
- •中间状态需要保存
- •工具调用顺序会影响结果
- •允许中途暂停、重试或人工接管
这时 Planning 的价值，往往不是“显得更聪明”，而是让任务变得更可追踪。
4. 多 Agent 协作模式
适合：
- •任务天然分角色
- •不同子任务的上下文差异很大
- •单 Agent 已经难以稳定覆盖全链路
但多 Agent 也会明显增加：
- •状态同步成本
- •传递性错误
- •观测和评估难度
所以它应该是后手，而不是默认方案。
04.模式的关键不在“思考方式”，而在系统边界
在工程上，一个更稳的理解方式通常是：
直接回答模式需要什么
- •稳定输入
- •明确输出格式
- •最小上下文
工具路由模式需要什么
- •结构化参数
- •工具权限边界
- •可回放的调用日志
计划执行模式需要什么
- •状态持久化
- •节点级失败恢复
- •中间步骤观测
多 Agent 模式需要什么
- •角色边界
- •共享状态约定
- •冲突和接力机制
如果这些基础没准备好，模式再先进，系统也很难稳定。
05.先让任务类型结构化，再决定选哪种模式
更稳的方式，是在系统入口先给任务分类。
from typing import Literal
from pydantic import BaseModel
class PatternProfile(BaseModel):
task_type: Literal["qa", "retrieval", "tool_use", "planning", "multi_agent"]
requires_state: bool = False
requires_external_actions: bool = False
needs_human_review: bool = False
def choose_pattern(profile: PatternProfile):
if profile.task_type == "qa":
return "direct_answer"
if profile.task_type in {"retrieval", "tool_use"}:
return "tool_routing"
if profile.task_type == "planning":
return "planner_executor"
return "multi_agent"这个模式的价值在于：
- •模式选择可以和任务边界绑定
- •团队更容易解释为什么用了某种模式
- •评估也能和任务类型对齐
06.ReAct、Planning 和多 Agent 的差异，最终会落到评估方式上
很多文章喜欢讲这些模式“更强”，但更关键的问题其实是：你到底怎么知道它更好？
更合理的评估通常包括：
- •直接回答模式：正确率、拒答质量、延迟
- •工具路由模式：工具命中率、参数正确率、越权率
- •计划执行模式：任务完成率、步数、恢复成功率
- •多 Agent 模式：交接质量、重复劳动率、总体成本
如果没有和模式对应的评估指标，模式讨论就很容易停留在概念层。
07.评估不要只看“是不是更智能”，还要看系统复杂度值不值
Agent 模式的评估，更应该围绕这些问题：
- •任务完成率是否真的提升
- •延迟和成本是否可接受
- •状态和观测复杂度是否显著上升
- •运维和排障是否比原来更难
- •人工接管是否变得更顺畅
这些问题比“模型看起来更会思考了”更接近真实价值。
08.三个常见误区
1. 一开始就默认上最复杂的模式
很多问题用检索、结构化输出和少量工具路由就能解决，不需要直接上计划或多 Agent。
2. 把模式术语当成架构答案
术语只是描述，真正决定系统成败的是状态、权限和评估边界。
3. 只谈能力，不谈成本和运维
模式越复杂，状态、观测和回归成本通常也越高。
09.总结
AI Agent 模式真正可交付的价值，不是多记几个名词，而是把任务复杂度、系统边界和评估目标对齐起来：
- •先从最简单的模式开始
- •让模式选择服从任务边界
- •用状态、权限和恢复能力托住复杂模式
- •用和模式匹配的指标来评估收益
只要这些原则守住，模式讨论才不会停留在概念层，而会变成真实可交付的架构判断。