Dynamic Workflow 详解
一、从静态到动态：一个根本转变
先理解对比：
静态工作流（Static Workflow）
用户输入 → [固定步骤 A → B → C] → 输出
每次都走同一条路，无论问题是什么
动态工作流（Dynamic Workflow）
用户输入 → [LLM 判断] → 选择路径 → 执行 → [再判断] → …
路径由内容本身决定，每次可能不同
静态工作流是铁路——轨道固定，列车只能沿轨运行。
动态工作流是导航系统——目标固定，路径根据实时状况动态计算。
二、Dynamic Workflow 的核心机制
2.1 路由（Routing）
LLM 作为分类器，判断输入属于哪种类型，然后分发到对应的处理流程。
用户输入
│
▼
┌─────────────────┐
│ Router LLM │ ← 判断：这是什么类型的问题？
└────────┬────────┘
│
┌────┴─────┬──────────┐
▼ ▼ ▼
经文查询 神学分析 历史研究
流程 流程 流程
关键：路由决策本身由 LLM 做出，而非硬编码的 if-else。
2.2 条件分支（Conditional Branching）
根据中间步骤的结果，决定下一步走哪条路。
Step 1: 检索语料
│
▼
检索结果是否充分？
│
┌┴──────────┐
是 否
│ │
▼ ▼
直接分析 扩大检索范围
或询问用户
不同于静态分支（条件预先写死），
动态分支的判断标准本身可以由 LLM 评估。
2.3 循环与迭代（Loop & Iteration）
Agent 持续执行，直到满足某个终止条件。
┌─────────────────────────────
│ 目标：生成一份符合 │
│ Scripture Alignment L4的分析 │
└──────────────┬──────────────
│
┌──────▼──────┐
│ 生成分析 │
└──────┬──────┘
│
┌──────▼──────┐
│ 自我评估 │◄──┐
│ 是否达到L4？│ │
└──────┬──────┘ │
│ │
┌────┴───┐ │
达到 未达到──┘
│
▼
输出结果
这是自我精炼（self-refinement）的基本结构。
2.4 并行执行（Parallel Execution）
多个子任务同时运行，最后汇总结果。
用户：请从三个传统比较”苦难”的神学意涵
┌─────────────────────────────
│ 并行启动 │
▼ ▼ ▼
倪李传统 莫尔特曼 东正教
苦难神学 十字架神学 神化论
分析Agent 分析Agent 分析Agent
│ │ │
└────────┬┘───────────────────
│
▼
汇总比较Agent
│
▼
综合报告输出
效率大幅提升：三个分析同时进行，而非顺序执行。
三、Dynamic Workflow 的判断层级
┌─────────────────────────────
│ Level 3：工作流级判断 │
│ 整个任务是否完成？是否需要重新规划？ │
├─────────────────────────────
│ Level 2：步骤级判断 │
│ 这一步的结果够好吗？下一步是什么？ │
├─────────────────────────────
│ Level 1：工具级判断 │
│ 用哪个工具？传什么参数？ │
└─────────────────────────────
越高层的判断，需要越强的规划能力（planning capability）。
四、与 PanAI 4.0 的具体映射
场景：用户提问”忍耐就是基督在苦难中的意义”
输入：忍耐就是基督——苦难神学的意涵
▼
【路由层】
LLM 判断：这是比较神学问题
→ 启动多传统比较工作流
▼
【并行检索层】
┌─────────────────┬───────────
│ Elasticsearch │ Neo4j 知识图谱 │
│ 全文检索 │ 关系路径查询 │
│ “忍耐” + “基督” │ 忍耐→苦难→基督 │
└────────┬────────┴────────┬──
└────────┬─────────┘
▼
【Scripture Alignment 评估层】
检索结果的经文支撑达到 L几？
→ 若 L1-L2：扩大检索
→ 若 L3-L5：进入分析
▼
【Q五步分析层】
对核心语料执行五步框架
▼
【比较对话层】
与莫尔特曼框架进行结构性对话
▼
【输出格式层】
依调用来源选择格式
→ Telegram Bot：简洁摘要
→ Obsidian：完整学术笔记
→ API：结构化 JSON
每一个”▼”都是一个动态判断点，而非预设的固定步骤。
五、实现方式的技术谱系
简单 ──────────────────────────────
单次调用 链式调用 条件分支 完整Agent
(one-shot) (chain) (routing) (autonomous)
│ │ │ │
直接问答 顺序执行 if/else 自主规划
多步骤 由LLM决定 + 工具调用
分支 + 自我修正
+ 长期记忆
PanAI 4.0 的成熟形态需要右侧的完整 Agent 能力。
六、Dynamic Workflow 的挑战
|挑战 |说明 |应对策略 |
|———|—————|—
|**不可预测性**|路径不固定，难以测试 |记录每次决策轨迹，建立评估集 |
|**成本累积** |多步调用累积 token 消耗|语义缓存（Redis）+ 分层调用|
|**错误传播** |早期判断错误影响后续所有步骤 |每步设置验证节点 |
|**循环风险** |终止条件不清晰导致无限循环 |设置最大迭代次数硬限制 |
|**可解释性** |用户不知道系统做了什么 |输出决策轨迹摘要 |
七、一句话本质
Dynamic Workflow 是让 LLM 不只回答问题，而是参与决定如何回答问题。
静态工作流是你告诉系统每一步做什么；
动态工作流是你告诉系统目标是什么，
然后系统自己找路。
这是从工具到协作者的质的跃升。
