Agent 基础范式：从 ReAct 到 Multi-Agent 的工程理解

1
用户输入
2
→ 模型生成
3
→ 输出答案

1
用户任务
2
→ 任务理解
3
→ 状态初始化
4
→ 规划或路由
5
→ 工具调用
6
→ 获取观察结果
7
→ 更新状态
8
→ 检索证据
9
→ 决策或复核
10
→ 安全校验
11
→ 终止或继续
12
→ 输出结果

1
生成一个答案

1
完成一个任务

1
帮我处理一下这个退款申请

1
识别退款意图
2
→ 获取订单号
3
→ 查询订单状态
4
→ 查询物流状态
5
→ 检索平台规则
6
→ 判断责任方
7
→ 判断是否符合退款条件
8
→ 请求用户确认
9
→ 调用退款工具
10
→ 校验退款状态
11
→ 回复用户
12
→ 记录 trace 和评估数据

1
Workflow：流程主要由开发者控制
2
Agent：流程中的一部分由模型动态决定

1
Workflow 控制主流程
2
+ Agent 在局部节点处理不确定性
3
+ Guardrails 约束工具与输出
4
+ Human-in-the-loop 兜底高风险动作

1
Reasoning / Thought
2
Action
3
Observation

1
Thought
2
→ Action
3
→ Observation
4
→ Thought
5
→ Action
6
→ Observation
7
→ Final Answer

1
每一步行动都要有当前状态依据；
2
每一次工具返回都要更新后续决策。

1
CoT 是"想清楚"；
2
ReAct 是"边想边查边做"。

1
模型可以生成工具调用参数

1
模型在多轮 Thought-Action-Observation 中动态决定下一步

1
用户任务
2
  ↓
3
模型理解目标
4
  ↓
5
判断下一步需要什么信息
6
  ↓
7
选择工具并生成参数
8
  ↓
9
工具返回观察结果
10
  ↓
11
模型更新状态
12
  ↓
13
继续调用工具或生成最终答案
14
  ↓
15
达到终止条件

1
用户：我的订单三天没发货，我要退款
2

3
Step 1:
4
需要先确认订单状态。
5
Action: query_order(order_id)
6

7
Observation:
8
订单已支付，商家未发货。
9

10
Step 2:
11
还需要确认物流是否有揽收记录。
12
Action: query_logistics(order_id)
13

14
Observation:
15
无揽收记录，距离付款已超过 72 小时。
16

17
Step 3:
18
需要查询延迟发货退款规则。
19
Action: search_policy("付款后超过72小时未发货是否支持退款")
20

21
Observation:
22
命中规则：商家超时未发货，用户可申请退款。
23

24
Step 4:
25
退款属于高风险动作，需要确认前置条件。
26
Action: verify_refund_precondition(order_id)
27

28
Observation:
29
订单仍未发货，未退款，金额一致。
30

31
Final:
32
当前信息支持进入退款处理流程，但执行退款前需要用户确认。

1
[ ] 设置 max_steps，避免无限循环
2
[ ] 工具必须有 allowlist
3
[ ] 工具参数必须 schema 校验
4
[ ] 工具返回必须结构化
5
[ ] 有副作用工具需要幂等 key
6
[ ] 高风险工具需要用户确认或人工审批
7
[ ] 每一步记录 trace
8
[ ] 工具失败有 fallback 或停止策略
9
[ ] 用户输入和检索内容按不可信上下文处理
10
[ ] 最终答案必须基于工具结果和证据

1
先规划，再执行

1
Planner：把任务拆成步骤
2
Executor：按步骤执行任务

1
ReAct 像"边走边看地图"；
2
Plan-and-Execute 像"先规划路线，再按路线执行"。

1
用户任务
2
  ↓
3
Planner 生成任务计划
4
  ↓
5
Plan Validator 检查计划是否合法
6
  ↓
7
Executor 执行第 1 步
8
  ↓
9
保存 step result
10
  ↓
11
Executor 执行第 2 步
12
  ↓
13
必要时 Replanner 更新计划
14
  ↓
15
执行完所有步骤
16
  ↓
17
汇总结果
18
  ↓
19
输出或进入人工确认

1
用户：我的订单三天没发货，我要退款
2

3
Plan:
4
1. 获取订单号
5
2. 查询订单状态
6
3. 查询物流状态
7
4. 检索延迟发货退款规则
8
5. 判断订单事实是否匹配规则
9
6. 如果满足条件，执行退款前置校验
10
7. 请求用户确认退款
11
8. 调用退款工具
12
9. 校验退款状态
13
10. 回复用户

1
整体路径清晰；
2
每一步职责明确；
3
更适合日志、测试、审计和人工接管。

1
计划第 6 步是退款
2
但第 2 步发现订单已经签收

1
Planner
2
  ↓
3
Plan Schema Validation
4
  ↓
5
Plan Policy Check
6
  ↓
7
Executor
8
  ↓
9
Step Checkpoint
10
  ↓
11
Verifier
12
  ↓
13
Replan / Continue / Stop / Human Review

1
执行后检查结果
2
发现问题
3
总结错误
4
修正后再尝试

1
Execute
2
→ Evaluate
3
→ Reflect
4
→ Retry

1
生成答案
2
→ 自我检查
3
→ 修改答案

1
任务反馈
2
→ 语言反思
3
→ 写入记忆
4
→ 下一轮尝试使用反思经验

1
生成初始结果
2
  ↓
3
Evaluator 判断是否达标
4
  ↓
5
达标：输出
6
  ↓
7
不达标：Reflector 总结问题
8
  ↓
9
将反思内容加入短期上下文或经验库
10
  ↓
11
重新执行
12
  ↓
13
直到成功或达到最大重试次数

1
任务：修复一个单元测试失败的 bug
2

3
Execute:
4
修改代码。
5

6
Evaluate:
7
运行测试，发现仍然失败。
8

9
Reflect:
10
失败原因可能是只修复了输入校验，没有处理空列表边界条件。
11

12
Retry:
13
重新修改代码，补充边界条件处理。
14

15
Evaluate:
16
测试通过。

1
测试是否通过

1
初次判断：
2
用户可以退款。
3

4
Evaluator:
5
检查发现没有确认订单是否已签收。
6

7
Reflect:
8
退款判断缺少 delivery_status 校验，高风险。
9

10
Retry:
11
补充查询物流签收状态后再判断。

1
[ ] max_reflection_rounds 限制反思次数
2
[ ] evaluator 明确判断标准
3
[ ] structured critique 输出结构化批评
4
[ ] retry policy 控制哪些错误可重试
5
[ ] rollback 允许回退到更好版本
6
[ ] memory policy 控制反思是否写入记忆
7
[ ] high-risk review 高风险动作转人工

1
流程由开发者定义，模型只在局部节点发挥作用。

1
Input
2
→ Intent Node
3
→ Slot Node
4
→ Tool Node
5
→ RAG Node
6
→ Decision Node
7
→ Guardrail Node
8
→ Action Node
9
→ Verification Node
10
→ Response Node

1
固定业务阶段
2
明确权限边界
3
明确成功标准
4
明确审计要求
5
明确失败兜底路径

1
用户输入
2
  ↓
3
意图识别
4
  ↓
5
槽位补全
6
  ↓
7
订单查询
8
  ↓
9
物流查询
10
  ↓
11
规则检索
12
  ↓
13
责任归因
14
  ↓
15
动作建议
16
  ↓
17
高风险动作确认
18
  ↓
19
执行工具
20
  ↓
21
状态校验
22
  ↓
23
客服回复
24
  ↓
25
评估记录

1
根据用户输入、上下文和系统状态，将任务路由到合适的流程、工具或专家 Agent。

1
这个请求应该交给谁处理？

1
这个请求最终答案是什么？

1
规则/分类器处理高频明确请求
2
LLM 处理模糊、多意图、长文本请求
3
低置信度转人工或追问

1
{
2
  "route": "refund_workflow",
3
  "confidence": 0.91,
4
  "required_slots": ["order_id"],
5
  "risk_tags": ["high_risk_action_requested"],
6
  "fallback_route": "human_service"
7
}

1
路由错误会导致后续全链路错误。

1
用户问题
2
→ 检索文档
3
→ 生成答案

1
理解问题
2
→ 判断是否需要检索
3
→ 改写 query
4
→ 拆解子问题
5
→ 多轮检索
6
→ 证据筛选
7
→ 判断证据是否足够
8
→ 必要时追问或再检索
9
→ 基于证据生成答案
10
→ 引用校验

1
用户问题
2
  ↓
3
Intent / Query Understanding
4
  ↓
5
Query Rewrite
6
  ↓
7
Query Decomposition
8
  ↓
9
Hybrid Retrieval
10
  ↓
11
Rerank
12
  ↓
13
Evidence Selection
14
  ↓
15
Evidence Sufficiency Check
16
  ↓
17
Answer / Decision Generation
18
  ↓
19
Citation Verification
20
  ↓
21
Safety Check

1
Context Recall
2
Context Precision
3
Citation Accuracy
4
Faithfulness
5
Answer Correctness
6
Evidence Sufficiency Accuracy
7
Refusal Accuracy
8
Policy Recall@K

1
专业角色分工
2
+ 可控协作
3
+ 共享状态
4
+ 明确责任边界
5
+ 可评估轨迹

1
[ ] 每个 Agent 只负责一个清晰角色
2
[ ] Agent 之间传递结构化数据，不传递任意自然语言指令
3
[ ] 共享状态中保留 source、trust_level、risk_tags
4
[ ] Coordinator 负责最终控制权
5
[ ] 高风险动作只能由受控执行层完成
6
[ ] 记录每个 Agent 的输入、输出、耗时、成本和贡献
7
[ ] 有失败归因和回归测试

1
结果是否符合格式？
2
是否有证据支持？
3
是否违反业务规则？
4
是否存在安全风险？
5
是否需要人工确认？

1
{
2
  "pass": false,
3
  "risk_level": "high",
4
  "blocking_reasons": [
5
    "missing_policy_evidence",
6
    "refund_tool_not_confirmed"
7
  ],
8
  "next_action": "human_review"
9
}

1
Format Validity
2
Evidence Coverage
3
Decision Accuracy
4
Unsafe Action Rate
5
Tool Argument Accuracy
6
Regression Pass Rate
7
Task Success Rate
8
Human Review Precision

1
让人类在关键节点拥有确认权、否决权和最终责任。

1
高金额退款或补偿
2
账号权限修改
3
对外发送正式邮件
4
删除或覆盖重要数据
5
合规/法律/医疗/金融建议
6
模型置信度低
7
证据冲突
8
工具结果异常
9
用户强烈投诉
10
疑似 Prompt Injection

1
Plan Review：执行前审核计划
2
Tool Approval：调用高风险工具前确认
3
Decision Review：高风险决策前复核
4
Output Review：对外输出前审核
5
Exception Handling：异常或冲突时接管

1
{
2
  "approval_required": true,
3
  "approval_type": "refund_action",
4
  "reason": "high_risk_action_with_financial_impact",
5
  "review_payload": {
6
    "order_id": "O123",
7
    "suggested_action": "create_refund",
8
    "evidence_ids": ["R001"]
9
  }
10
}

1
用户输入
2
  ↓
3
Input Safety Check
4
  ↓
5
Intent & Slot Router
6
  ↓
7
Workflow 主流程
8
  ↓
9
Order Tool / Logistics Tool
10
  ↓
11
Policy Agentic RAG
12
  ↓
13
Responsibility Decision
14
  ↓
15
Verifier / Reflection
16
  ↓
17
Human Approval（高风险动作）
18
  ↓
19
Refund / Ticket Tool
20
  ↓
21
State Verification
22
  ↓
23
Customer Response
24
  ↓
25
Trace + Eval + Failure Dataset

1
确定性流程交给代码；
2
不确定性判断交给模型；
3
事实查询交给工具；
4
知识依据交给 RAG；
5
高风险执行交给受控后端；
6
异常和低置信度交给人工；
7
质量和安全交给评估与监控。

1
任务能不能用一个确定性函数完成？
2
  ├─ 能：不用 Agent
3
  └─ 不能：
4
      是否需要外部知识？
5
        ├─ 是：考虑 RAG / Agentic RAG
6
        └─ 否：
7
            是否需要多步骤执行？
8
              ├─ 否：普通 LLM
9
              └─ 是：继续判断

1
工具调用路径是否固定？
2
  ├─ 固定：Workflow
3
  └─ 不固定：
4
      工具结果是否会影响下一步？
5
        ├─ 是：ReAct
6
        └─ 否：Plan-and-Execute

1
任务是否高价值、允许多轮迭代、有明确反馈信号？
2
  ├─ 是：加入 Reflection / Verifier
3
  └─ 否：不默认加入 Reflection

1
单 Agent 是否已经能清晰完成任务？
2
  ├─ 是：不要 Multi-Agent
3
  └─ 否：
4
      是否存在清晰专家分工？
5
        ├─ 是：可以 Multi-Agent
6
        └─ 否：先优化 Workflow / Router

1
是否涉及资金、权限、隐私、对外发送、删除、合规？
2
  ├─ 是：必须加入 HITL 或强策略校验
3
  └─ 否：可根据置信度和风险决定是否人工接管

1
在可控边界内释放模型能力。

1
有明确评价标准；
2
允许多轮迭代；
3
任务价值足够高；
4
有停止条件；
5
有回滚机制。

1
1. 普通 LLM 调用与结构化输出
2
2. Tool Calling
3
3. ReAct
4
4. Plan-and-Execute
5
5. Workflow / StateGraph
6
6. Agentic RAG
7
7. Reflection / Verifier
8
8. Router Agent
9
9. Multi-Agent
10
10. Guardrails、HITL、Tracing、Evaluation

1
Intent Accuracy
2
Slot F1
3
Tool Selection Accuracy
4
Tool Argument Accuracy
5
Policy Recall@K
6
Evidence Citation Accuracy
7
Decision Accuracy
8
Unsafe Action Rate
9
Human Handoff Precision
10
End-to-End Success Rate
11
Average Latency
12
Average Cost
13
Regression Pass Rate

1
agent-paradigm-lab/
2
  app/
3
    agents/
4
      react_agent.py
5
      planner.py
6
      workflow.py
7
      verifier.py
8
      router.py
9
    tools/
10
      order_tool.py
11
      logistics_tool.py
12
      policy_tool.py
13
      refund_tool.py
14
    rag/
15
      retriever.py
16
      reranker.py
17
      evidence_selector.py
18
    safety/
19
      guardrails.py
20
      policy_engine.py
21
      approval.py
22
    eval/
23
      datasets/
24
      runner.py
25
      metrics.py
26
  docs/
27
    paradigm_notes.md
28
    architecture.md
29
    eval_report.md
30
  tests/
31
    test_router.py
32
    test_workflow.py
33
    test_tools.py

1
ReAct：
2
边思考边行动，适合动态探索。
3

4
Plan-and-Execute：
5
先规划再执行，适合目标明确的多步骤任务。
6

7
Reflection：
8
执行后反思修正，适合有反馈信号的高价值任务。
9

10
Workflow Agent：
11
固定流程中嵌入局部智能，适合生产级高可靠业务。
12

13
Router Agent：
14
判断任务该交给哪个流程、工具或专家。
15

16
Agentic RAG：
17
让检索过程具备主动改写、拆解、验证和引用能力。
18

19
Multi-Agent：
20
通过专业分工解决单 Agent 难以覆盖的复杂任务。
21

22
Verifier：
23
检查结果是否合格，是质量和安全的刹车系统。
24

25
Human-in-the-loop：
26
让人在关键风险节点拥有确认权和最终责任。

1
开放探索任务：
2
优先 ReAct。
3

4
目标明确的多步骤任务：
5
优先 Plan-and-Execute 或 Workflow。
6

7
高可靠业务流程：
8
优先 Workflow + 局部 LLM。
9

10
复杂结果复核：
11
加入 Verifier / Reflection。
12

13
知识证据链任务：
14
使用 Agentic RAG。
15

16
多业务入口：
17
使用 Router Agent。
18

19
多专家复杂任务：
20
谨慎使用 Multi-Agent。
21

22
高风险动作：
23
必须 Guardrails + HITL + 状态校验。
24

25
简单确定性任务：
26
不要 Agent，直接函数或规则即可。

1
根据任务的不确定性、风险、成本、延迟和可测试性，
2
选择合适的任务控制范式。

1
该自由探索时使用 ReAct；
2
该结构化拆解时使用 Plan-and-Execute；
3
该稳定可靠时使用 Workflow；
4
该查证引用时使用 Agentic RAG；
5
该复核纠错时使用 Reflection / Verifier；
6
该分工协作时使用 Multi-Agent；
7
该人工兜底时使用 Human-in-the-loop；
8
该不用 Agent 时坚决不用 Agent。